转发同事总结：一个BUG引发的血案（经过篇）

序：

博文《转发同事总结：一个BUG引发的血案（起因篇）》说了项目初验不成功的总结，本期刊登同事P对过程的经过分析。

原文如下：

2. 经过

EVENT3：被逃过的测试 TIME：初验会前3个月～初验会前1周

第一轮测试工作中，测试人员测出了很多问题，但是上述两个问题并未测出，这是为什么呢？首先，测试用例并未详尽到这个程度。而问题1如果不是挨个核对确实很难发现，所有表格都挨个核对工作量又比较大，导致非专业的测试人员很容易疏忽。问题2出现的前提是正式表里有已经汇总好了的数据，我们在第一轮测试时数据库中还完全是测试数据，用例中也不是穷举了所有的情况，这个自然也很难测出来。

看样子这两个bug隐藏的比较深，在第一轮测试中这种问题确实很难发现。试运行以后是具备重现条件的，项目组却又忙于需求变更、二期工作等其他事务，一直没能抽出一整片时间组织大家进行第二次覆盖性测试，但是我们真的没有机会发现它们吗？

SOLUTION3：化整为零进行测试

其实并不是，我们应该了解到用户的关注点在哪，覆盖性测试也可以分阶段进行，其实很早之前我们就了解到了用户最关注的是F1，F1是否计算准确更是重中之重，而推动力度最大的也是F1信息填报的功能。

既然如此，我们就应该采用这么一种策略：在用户正式大规模推广使用之前，一定要覆盖性测试F1相关的功能。从数据录入一直跟踪到前台展示，防患于未然。采用分阶段进行的方式可以化整为零，减少每次测试需花费的资源和时间，具有更大的灵活性。不会因为无法协调测试所需资源而导致测试工作搁浅。

正因为没考虑到这种做法，导致我们错过了先于客户发现问题的黄金时间。

EVENT4：异地沟通的障碍 TIME：初验会前3天

测试工作的不到位，导致问题潜伏了很久，最终的发现者还是客户。客户发现导入和导出的数据不一致后，十分不满，因为他认为这是一个系统应该满足的基本要求。

接收到客户抱怨的时候，我正在公司，当天另一个维护人员在客户处值班。同事L在了解到这种安排时，马上告诉我可能会存在沟通问题。他果然一语成谶。

值班的维护人员对于这一块的数据处理其实是并不太明确的。在我协同开发者，远程联络设计者，同时安排维护人员测试的情况下，问题很快被锁定了，也明确了修改办法。其实是很容易处理的，只需要把SQL中的每一个字段的decode算法略加修改即可。

确定了处理办法之后，我在QQ上告诉维护人员修改哪一个文件，如何修改。此时沟通障碍产生了，忙中出错，我把修改第一个字段的方法发了过去，却忘了加一句其他字段也类似的进行修改，维护人员也忠实的执行了我的要求，只改了第一个字段。就这样我们给自己埋下了一个地雷。

SOLUTION4：沟通效果的改进

此问题的主要原因毫无疑问是任务分配时表达的失误，对于执行者并不太清楚的领域或模块，安排任务时应详细说明，多次确认。异地沟通的情况需要尽量避免，沟通的准确性也必须更着重关注。

另一方面站在执行者的角度上，也应该发挥主观能动性。看到同一个报表中一模一样算法的若干个字段，对为什么只修改第一个产生疑问；修改了一处指标的算法，就想一想系统中还有没有其他部分需要修改，也就是自发的进行impact analysis。如果能做到这样相互补位，多问些为什么，多从项目整体考虑，沟通产生问题的几率就会小很多了。

（未完待续）