开发团队测试的难与易

       作了多年的研发工程师，在所处的环境中，所接触的开发人员中不多有看重对本身代码进行测试这项工做的。大多研发人员每每是写好了代码运行起来，简单作下测试，甚至不去测试就抛给接口使用者或者质量管理人员。并且理由很充分“没时间...；我以为应该没问题...；这种简单的事让专职人员去测试，不然浪费本身的时间....”从这些话首先该否认的是其人的职业素养，还有就是设计的代码结构很差测试，或者根本就写不出好的测试demo。

       记得咱们曾经的团队开始强调测试是在工程渐渐庞大，模块逐渐细化，人员参与较多时。由于往往在联合调试时，老是相关人员的噩梦，每每每一个人都会被系统的某个bug打断现有工做，还时不时会出现互相埋怨互相推脱bug责任的状况出现，等定位出bug再分到具体的人头上。一个bug牵扯到一个团队，算一笔帐，这个团队有6我的，假设在本身的模块中每人平均出现5个bug，这样在系统中就有30个bug出现，可能在测试过程当中每一个人会被中断30次去协助他人定位bug，这种对一个bug而言，非相关人员产生的中断打扰和时间浪费是明显和巨大的。固然，我只是举个例子，现实中也许不会这么极端，每每是两三我的会出现这种协做状况。可是对相关人员这也是不可忍受的。

       怎么办呢？引入单元测试，反对声很大，其中缘由主要有两个：1.若是不和别人的模块一块联合，无法作测试；2.要本身模拟某种操做还要造数据太浪费时间；第一种状况说白了就是写不出单元测试，在你作这个埋怨时先看看本身设计的程序，我想若是你若是严格作到了高内聚，低耦合；业务和功能分离；或者经典的MVC模型，怎么会作不了单元测试；第二种状况彻底就是捡了芝麻丢了西瓜的典型表现，就拿我刚才举的例子而言，你把时间成本都浪费到后期的联合调试和定位bug责任人，甚至到了质量部门再由于各类边界测试，压力测试找你上门。

      最终咱们的团队仍是没有强制单元测试，也许有程序架构的问题，也许有项目周期太紧张的问题，可是我以为更多的是大多数人没有认识到单元测试对一个大系统重要性，甚至写好程序自我测试都作不到，自信到老是来来回回的不停发布新的fix版本。

      也许是我深受其害，也许是我很在乎别人对我程序的见解，我尽可能要求本身在写代码时作好单元测试，在完成程序时本身多测测，多运行，多点点。由于我以为这样当我提交本身的模块，本身的程序时内心才踏实，否则还真是“担惊受怕”。

附件中有我常常使用的单元测试框架gtest的学习文档，我整理自CoderZh的技术博客