我们都知道，传统瀑布式开发模式下面测试在整个开发周期里面是很靠后的，测试人员往往在版本发布之前才开始测试，理解需求通常是通过阅读很久之前就写好的需求说明和设计文档，因为一些我们都知道的原因，这些文档理解起来总会存在各种问题，带来额外的沟通成本，即使测试人员准确无误地理解了需求并发现了bug，在这个阶段修正bug的成本也会变的很高，给代码腐坏埋下种子。

上面的问题比较容易发现，而且也并不是没办法解决，但更严重或者说更难以被察觉的的是下面这些影响。

度量

瀑布式的开发模式下，测试和开发是完全独立开来的，所以往往会配置独立的测试团队甚至是独立的测试部门，其考核kpi的设置和开发团队是互相对立的，几乎所有采用这种开发模式下的团队都会讲 bug 数量作为权重最大的 kpi 。

开发团队

被外部发现的bug越多说明外部质量越差。

为了减少外部发现的bug数量，开发团队也会投入很大的精力进行内部系统测试，我以前经历过的项目中，往往在版本发布给测试团队之前会预留一周甚至更长的时间专门进行内部系统测试（基本都是人肉测试）。

还有一个常用的奇葩指标，相信很多人都不陌生——“内外故障比”。就是说假如测试团队发现了10个bug，没关系，只要我们在内部测试发现了100个内部bug，那么我们的内外故障比这个指标就是10:1，大概的逻辑假设是这样的：

“内外故障比高，说明在内部测试阶段已经发现了绝大多数的bug”

基于这样一个假设，项目经理往往会期望在内部测试时发现的故障数越多越好，如果告诉项目经理内部测试发现的故障数不多，项目经理多半怀疑内部测试阶段开发人员是不是在磨洋工，我记得在前几年项目在内部测试阶段项目经理还会专门在测试环境盯着，要求开发人员必须到现场进行测试，哪怕你说是远程访问来进行测试也是不行的！

测试团队

发现的bug越多越说明自己的工作量足够饱满，存在的价值越高。

为了提升测试发现的bug数，测试人员会更倾向于测试比较容易发现问题的地方，比如gui，异常提示，国际化，而场景构造起来比较复杂的测试则得不到应有的投入。

这里不得不提的一个东西就是bug管理工具，这个相信所有的软件公司都有，其中比较出名的是IBM 的 CQ。个人对这个工具是喜(shen)闻(wu)乐(tong)见(jue)，从毕业到现在为止耗在这个东西上的时间至少占据了所有工作时间的 20%，我发现我们的组织对这个工具的使用堪称艺术，随着时间积累，各种状况慢慢出现的时候，这个工具会被定制的越来越复杂，流程越来越长，状态越来越多，权限等级越来越森严……测试人员提交在上面的任何一个 bug 都像是测试人员的私有财产一样神圣不可侵犯，即使不是 bug 也得花上半个小时来进行解释，否则无法关闭。

能力提升

前面也提到为了追求 kpi ，测试人员倾向于将精力投入到像 gui 异常提示 这种比较容易产出 bug 的地方，而一旦长时间投入在这些工作中，测试人员的业务水平和工作成就感也会下降，这并不是危言耸听，我就亲眼见过很多开发人员转岗测试的，在测试岗位混迹一两年之后工作状态就明显下降最后被淘汰的。

包括非常多的开发人员（这个比例非常之高，即使说是99%可能也不为过）都觉得测试是一件很low逼的工作，特别有些开发人员天天以geek自居的，所以开发人员本身对测试工作也是抵触的，哪怕不是人肉系统测试，而是单元测试，自动化测试，也一样存在这种内心深处的鄙夷。而这种情绪或者偏见，反过来也会导致开发人员自身的测试水平无法提升。这个很好理解，一个不喜欢打麻将的人是很难打好麻将的。

组织文化

开发和测试立场上的对立，往往体现为开发和测试人员关系的紧张和互相的鄙视，在沟通上的不顺畅甚至猜忌。而组织层面为了追求各自的 kpi ，往往在某种程度上鼓励开发和测试的对立，实在是不像是一个由理性人组成的现代化的高科技公司该有的feel。

小结

估计很多人看到这里会觉得有点奇怪，觉得这难道不是再正常不过的事情么？的确在这种开发模式下工作久了，潜移默化的就会觉得再正常不过，但如果我们回到初心，问一问测试的初衷是什么？

“软件测试是为了确保开发出来的软件准确且可靠的实现了用户需求”

从这个角度出发至少单纯的bug数量并不能说明什么问题，正相反，bug数量越多正说明我们的产品达成“准确且可靠的实现用户需求”这个目标的风险越大，这种时候项目经理不是越放心而是应该越上火才对！