越改越长的Bug管理流程

(作者：王洪亮）

开发软件中的Bug需要进行科学的管理这样才能够确保正确的跟踪，以较为合适的成本进行Bug的修复，以及针对Bug做出正确的决策。因此各个公司基于各自的情况都设定了对应的Bug管理方法。其中包括采用了何种工具进行Bug的登记，Bug的严重级别如何定义以及Bug的管理流程。

图1 是一个比较典型的Bug管理流程，尽管各自公司的Bug管理流程可能和这个流程并不完全相同，但是大同小异，用这个可以说明本文想要表达的主旨。

图1，一个Bug管理流程的样例

当测试部门通过测试发现了Bug，就要把Bug登记到Bug系统中去。开发部门将收到的Bug进行分析，分析明白原因之后开始进行Bug的修改，修改之后将Bug系统中对应的Bug状态进行修改，并且提交回测试部门进行验收测试。当验收测试通过的时候，该Bug关闭，而验收测试失败的时候，返回到开发部门继续进行修改。这其中涉及到一个指标，就是Bug的返回率。很显然，Bug的返回率越高，则Bug的修改成本越高，而需要的测试轮次就越多，交付的周期就越长。某组织的Bug返回率为20%。已经到了比较严重的程度，对于该组织来说，降低Bug的返回率是一个头等重要的事情。

既然降低Bug返回率这么重要，就不要操之过急，首先要进行Bug返回率居高不下的原因进行调研。而调研的结果显示，开发人员在修改Bug的时候不仔细是首要原因。为了减少由于开发人员的测试不完全造成的高Bug返回率，需要在Bug的管理流程中增加对应的步骤减少开发人员的失误。修改后的Bug管理流程如图2所示。

图2，改进后的Bug管理流程

改进后的Bug管理流程上，增加几个新的步骤，首先开发人员拿到Bug描述之后不要直接进行修改，而要将自己的分析形成文档，交给更高级的技术人员进行确认，只有当更高级的技术人员确认之后才可以进行真实的修改，而修改之后的代码需要交由该高级人员进行确认，该高级人员确认代码和最初的分析资料是一致的。这样就可以减少技术人员的代码错误。这样改进之后按推测应该是可以减少Bug的返回率了吧。实际效果是，Bug的管理流程延长了，而Bug的返回率呢，仍然是20%左右。

那么到底发生了什么事情了呢？为什么Bug管理流程改进了之后，Bug返回率仍然居高不下呢？

其实，真实的原因是：（该组织中）开发人员在修改代码之后，由于时间压力，回归测试覆盖率严重不足造成的，而测试人员则遵照了回归测试的正规步骤进行的回归测试。这就是为什么Bug返回率始终居高不下的原因。而没有找到这个真正的原因，却反而加长Bug管理流程导致了南辕北辙的效果。

针对这个情况，一个建议采取的策略是：增加自动化测试。其实测试人员所进行的人工测试，都是按照scenario进行操作的，而这些机械的，重复的动作是很容易被自动化的。而自动化之后，开发人员就可以很快的自动进行自我测试，从而更快的得到测试的反馈。

采取了自动化测试之后，这种情况大为改善，首先，Bug返回率这个名词不再存在了。因为以前的测试过程模型是按照图3这样构成的。在每个轮次中间都会有一个类似图1那样的Bug管理流程，确保所有的Bug都会被回归测试，并且，将返回的Bug移交到下一个轮次去继续进行修复和验证。而Bug的数量会随着测试的轮次增多而逐步的减少，直到达到“没有”为止。所谓的返回率也是存在于这样一个轮次型测试的大背景下面的。

图3，按照轮次的测试流程

而改为自动化测试的流程之后是图4这样的。开发人员随时提交代码，提交后的代码经过自动测试，可能会发现Bug，而Bug将会在下次提交的时候会再次经过自动测试来验证。由于轮次这个概念消失了，轮次之间的Bug返回率这个词也消失了。

图4，自动化测试的流程

其实在轮次方式下，轮次数量也同样是一个比较重要的参考指标。轮次越多代表测试周期越长，交付周期越长，而Bug返回率间接地影响了测试轮次的多少。经过改进的Bug管理流程不再有轮次和返回率这个概念，那么应该参考什么指标来衡量测试的效果呢？Time to Release如何呢？其实做产品的公司有这样一个指标：Time to Market。这个Time to Release也和Time to Market有异曲同工之妙，也可以应用于项目外包型公司。同样的，最初在轮次的模型下，也是为了最终追求的是保证质量前提条件下的Time to Release。这个指标并没有改变模型而改变。而且，很明显的一个改进是，在轮次模式下的手工测试的效率和准确率，以及Bug描述可理解程度都远远不如自动测试模式下的好。而在自动测试模式下的Time to Release可以得到大幅度缩减。