中搜网站提交,全球十大软件公司排名,网站的技术分析,某互联网公司开发官网的首页做了多年的研发工程师#xff0c;在所处的环境中#xff0c;所接触的开发人员中很少有看重对自己代码进行测试这项工作的。大多研发人员往往是写好了代码运行起来#xff0c;简单做下测试#xff0c;甚至不去测试就抛给接口使用者或者质量管理人员。而且理由很充分“没时间… 做了多年的研发工程师在所处的环境中所接触的开发人员中很少有看重对自己代码进行测试这项工作的。大多研发人员往往是写好了代码运行起来简单做下测试甚至不去测试就抛给接口使用者或者质量管理人员。而且理由很充分“没时间...我觉得应该没问题...这种简单的事让专职人员去测试否则浪费自己的时间....”从这些话首先该否定的是其人的职业素养还有就是设计的代码结构不好测试或者根本就写不出好的测试demo。 记得我们曾经的团队开始强调测试是在工程渐渐庞大模块逐渐细化人员参与较多时。因为每每在联合调试时总是相关人员的噩梦往往每个人都会被系统的某个bug打断现有工作还时不时会出现互相埋怨互相推脱bug责任的情况出现等定位出bug再分到具体的人头上。一个bug牵扯到一个团队算一笔账这个团队有6个人假设在自己的模块中每人平均出现5个bug这样在系统中就有30个bug出现可能在测试过程中每个人会被中断30次去协助他人定位bug这种对一个bug而言非相关人员产生的中断打扰和时间浪费是明显和巨大的。当然我只是举个例子现实中也许不会这么极端往往是两三个人会出现这种协作情况。但是对相关人员这也是不可忍受的。 怎么办呢引入单元测试反对声很大其中原因主要有两个1.如果不和别人的模块一块联合没法做测试2.要自己模拟某种操作还要造数据太浪费时间第一种情况说白了就是写不出单元测试在你做这个埋怨时先看看自己设计的程序我想如果你如果严格做到了高内聚低耦合业务和功能分离或者经典的MVC模型怎么会做不了单元测试第二种情况完全就是捡了芝麻丢了西瓜的典型表现就拿我刚才举的例子而言你把时间成本都浪费到后期的联合调试和定位bug责任人甚至到了质量部门再因为各种边界测试压力测试找你上门。 最终我们的团队还是没有强制单元测试也许有程序架构的问题也许有项目周期太紧张的问题但是我觉得更多的是大多数人没有认识到单元测试对一个大系统重要性甚至写好程序自我测试都做不到自信到总是来来回回的不停发布新的fix版本。 也许是我深受其害也许是我很在意别人对我程序的看法我尽量要求自己在写代码时做好单元测试在完成程序时自己多测测多运行多点点。因为我觉得这样当我提交自己的模块自己的程序时心里才踏实不然还真是“担惊受怕”。 附件中有我经常使用的单元测试框架gtest的学习文档我整理自CoderZh的技术博客 附件http://down.51cto.com/data/2361908 本文转自永远的朋友博客51CTO博客原文链接http://blog.51cto.com/yaocoder/1081054如需转载请自行联系原作者 yaocoder
