提及来人生第一家互联网公司，教会了我蛮多的东西，虽然比较杂。如运维、测试、实施、开发等。基本上那个时候，哪里有须要，哪里就有我。html
以前曾写过这么一篇文章论单元测试之重要性
这篇文章的背景是我处于创业公司的时期，那个时候作的比较杂，因为先后端一块儿作，功能愈来愈多，bug也就愈来愈多。最后发现由于赶着发布周期，不得不快，快的咱们连单元测试以及自测都懒得弄。最后发布前，经理测试了一下，发现了一堆bug。因而咱们周末加班改bug。
持续了一段时间后，以为老这样也不行，因而就开始写单元测试。还别说，由于写了单元测试后，bug率果真降低不少，bug率降低不少后，虽然也有一些bug，但并非很重要，能够慢慢改。总而言之，咱们不用周末来加班了，能够有一个美好的双休。前端
以前个人领导是R哥，后来变成了D姐。D姐教我如何写测试用例。
根据测试用例，而后界面上进行操做，这样的测试一般叫功能性测试。
测试有不少种，功能测试是测试人员最基本的，也是最基础的。数据库
测试分类以下:后端
黑盒测试——不是基于内部代码和设计的知识，而是基于需求和功能。安全
白盒测试——基于应用程序的内部逻辑的知识，经过语句，分支，路径和条件的覆盖率。服务器
单元测试——测试中的最小单位，测试特殊的功能或代码模块。因为须要对内部代码和设计的详细知识，该测试通常由开发者完成而不是由测试人员完成。该测试的容易程度同代码设计的好坏直接相关。网络
增量型的集成测试——随着新功能的增长，不断的对应用程序进行测试。在程序的全部部分完成以前，须要一个应用程序的各个部分之间可以相对独立的进行工做。这类型测试能够有开发者或测试者完成运维
集成测试——测试应用程序结合的部分来肯定它们的功能结合到一块儿是正确的。在这里‘部分’的概念多是代码模块，独立的应用程序，在网络上的客户端和服务器断程序等等。这类型测试典型的是于客户/服务器和分布式系统相关。分布式
功能测试——是一种黑盒测试，同应用程序的功能需求紧密相关。这类型测试应当有测试人员来完成。这并不意味着开发人员在发布版本以前就不须要检查他们的代码。工具
端到端测试——同系统测试相似，包括模拟现实世界对一个完整的应用环境进行测试。例如同数据库进行交互、使用网络通讯，或者其余的软件、硬件和系统进行交互。
理智测试——这是一种典型的原始测试，其目的是要肯定一个新的软件版本在一些主要的测试努力下表现的足够好而且能够接受。例如：若是一个新软件每五分钟宕机一次，使系统执行速度极其缓慢，或者破坏系统数据，那么该软件就处于不够‘理智’状态，必须保证在当前状态下进行进一步测试。
回归测试——在软件或环境被修改后进行的再测试。可能很难肯定咱们须要进行多少的再测试，尤为接近到开发过程的末期。自动测试工具可能会有很大的帮助。
可接受性测试——基于最终用户的规格进行的最后测试。或者基于最终用户在必定的时间范围内的测试。
负荷测试——在高负荷条件下进行的测试。
压力测试——该术语一般同负荷测试和性能测试是可交换的。也可用于描述这样一些测试如：在不正常的负荷状态下，过度的重复某些动做或输入状况下进行的系统功能测试。
性能测试——该术语一般同负荷测试和压力测试是可交换的。理想的性能测试是定义在需求文档或QA测试计划中的。
安装和反安装测试——测试彻底、部分或升级的安装/反安装过程。
恢复测试——测试当出现崩溃，硬件错误或其余灾难性问题时，系统的表现状况。
安全性测试——测试系统对于内部和外部非法入侵、故意损坏时的表现状况。可能须要复杂的测试技术。
兼容性测试——测试系统在不一样的平台/硬件/操做系统/网络上的表现状况。
ALPHA测试——在开发进行结束的时候进行的测试。针对测试的结果可能还会进行一些小的设计更改。这类测试典型的是由用户进行的，而不是由开发者或测试人员进行的。
BETA测试——在开发和测试已经所有结束后，而且在最终版本发布以前进行的测试。这类测试典型的是由用户进行的，而不是由开发者或测试人员进行的。
那段时期作过最多的仍是功能性测试。
那段时期也比较苦恼，以为功能性测试没有一点技术含量，有过辞职的念头，因而将本身的苦恼跟导师诉说。导师很快给我回复，虽然如今记不得很清楚他的原话，但内容大概是，测试并非没有技术含量的，高级的测试是须要会写代码的，同时你以为哪些是重复性、单调的工做你能够学习一些自动化工具来提升你的测试效率。
因而我才坚持下来作了一段时期的测试工做。功夫不负有心人，最终我仍是成功转到了开发部门，开始写我喜好的Code。
在创业公司作咱们本身的产品，我在这篇文章较为详细的说过创业公司这两年
仔细想一想，咱们的产品类型分为以下:
咱们公司组织结构除了研发就是产品，没有测试。因此咱们研发人员不管是后端仍是安卓端的，基本上都须要兼任测试职责。
就像我在前面说到的那样，前期咱们不是很注重测试环节甚至过滤掉，致使咱们没必要要的加班改bug。后期咱们造成了一套流程，周一到周四开发阶段，周五发版测试，若是没有问题，周五下班前直接发给经理，由经理再测试验证，随后再到老板那，若是有问题，问题比较严重，周五改不过来，那么咱们就须要周六或周日来加班，
最初咱们的测试也就是点点，但后来发现这样不行，由于点点仅仅是确认这个功能是否会报错如500等之类的，但并不能确保业务流程是对的。
因而咱们改进了，写了几个业务流程的思惟导图，而后测试，这样有针对性的测试，让咱们测试就有了方向，不至于东点点西点点浪费没必要要的时间。
教育SAAS有专门的测试人员和完善的测试机制。可是做为开发人员，咱们部门明确一点要求，那就是每一个人写的Java程序，必需要有对应的测试代码，以确保没必要要的错误和代码质量。
每两周发版一次，分为开发周和测试周，开发周写本周产品提出的需求，每周周五开发周将终止，进行内部发版，发到测试环境，周一或者周五下午由测试人员进行冒烟测试。
你们或许对冒烟测试不太了解，其实我以前也不明白。
针对每一个版本或每次需求变动后，在正式测试前，对产品或系统的一次简单的验证性测试。
为正式测试前，验证是否产品或系统的主要需求或预置条件是否存在bug。
通过冒烟测试验证Ok没问题后，而后测试人员才会进行下一步测试如功能性测试。
通过这家公司的洗礼，我才发现测试人员仍是要有很强的功底如必须对业务很是熟悉和很是细心和严谨，同时还得熟练掌握一些自动化测试工具如LoadRunner或Selenium等。
因为没待过流程体系较为完善的公司，我在这家公司作的第一个功能就出现了近一百多个bug。那个时候我既要写后端，也要写前端。后端bug二十来个，前端bug近一百个。看到禅道上给我指派的bug，我都快哭了。那个时候很想揍那位测试小哥哥。我刚来没多久，就对我这么不友好。想了想，先把bug改完再说。改完后，我逐渐意识到也不能怪那位测试小哥哥，毕竟是人家的职责所在。经过此次我发现自身存在不少问题，如代码写的不严谨、对一些细节不注重、不细心、对于功能差很少就好等缺点，因而后来我努力改进，虽然写的功能或多或少会有bug，但基本上控制在个位数上，改起来也不费劲，自那之后我和测试人员就处的很愉快，bug少，我轻松，他们也轻松。
我所待的三家公司里，测试工做的经历告诉我一个很重要的道理:
不管研发、测试、运维或者是其余行业的工做，作到最后都在围绕一我的最重要的素养，那就是责任心，一样这个责任心也是作人最重要的品质之一。