Jaa

用Visual Studio实践敏捷测试（二）下

  • Artikkeli

Bug的生命周期

 

    无论采用何种测试形式、执行何种测试任务，都会产生一系列的Bug。而开发团队需要一个健全的Bug管理的机制。一般来说，一个Bug的生命周期大致要经过如下几个过程：

image 图4 Bug的生命周期

    这里大多数的阶段都比较易懂，需要解释一下的可能就是Triage过程。Bug在创建出来以后，首先要经过Triage小组讨论决定是否需要修复。Triage小组一般由项目管理、开发和测试三方的代表组成。对于每一个Bug，小组快速的根据重现步骤、结果等信息，估计其严重程度、可能的原因、修复的代价和风险，以决定是否要修复这个Bug。如果Bug中提供的信息量不足以判断，Triage小组会将其发还给创建者要求补充更多的信息。如果Triage小组无法在短时间内对Bug的成因、修复等做出估计，那么就会将Bug指派给一个相关的开发/测试人员进行调查，并要求他将调查结果附上之后，重新提交Triage。

    另外，如果一个Bug被拒绝修复，但是创建者却坚持己见的话，可以进一步在Bug中添加理由：对用户影响、可能的严重后果等，然后重新提交Triage。类似的，如果一个Bug被批准修复，但是被指派修复的人员认为没有必要修复、修复难度/代价太大时，也可以将理由附上，要求Triage小组重新裁定。

    Triage会的频率在整个产品开发过程中是不相同的。在产品开发的开始阶段，团队的主要活动就是开发新功能，此时可能数天甚至数周才能签入一个功能，Triage会一周一次就足够了，保证本周在大扫除中所发现的Bug都会被及时处理。而当产品逐渐进入开发周期的末尾时，团队主要的活动就是修复Bug，此时就最好能每天Triage，迅速对Bug做出反应，以便能更好的管理项目的进度。

    除了Triage会的频率会随着产品开发而改变外，Triage的标准也会随之调整。在新功能刚签入的时候，可能很小的问题或者改进建议都会被批准，以帮助更好的完善该功能。而当功能相对稳定时，就要开始考虑修复的代价/风险以及为用户带来的价值之间的平衡点了。到产品周期的末尾阶段，此时Triage的标准将会非常严格，只有对用户影响非常大，且修复的代价/风险都比较小的Bug才会被批准修复了。

    Triage的意义在于在较短的时间内，项目管理/开发/测试三方都对团队现有的Bug有整体的了解，并提供各自的意见，快速的剔除重复的、不值得修复的问题，且保证了整个团队对Bug是否需要修复有一个统一的标准。

Bug的管理

    我们的团队采用TFS的作为Bug的管理工具。团队成员可以轻松在Visual Studio或是Test Manager界面中创建、查询、修改Bug。值得一提的是，TFS提供的默认的Bug模板并不一定能满足团队的需要。这里就可以用到TFS提供的修改工作项定义的功能（导出工作项定义->修改->导入工作项定义），将Bug改造为合适的样子。在我们的团队中使用的Bug模板就是我们自己定制的。

    这里我想和大家分享几个我们在实践中得出的有助于Bug管理的域：

1. 子状态（Sub Status）

    Bug的状态一般就只有Active、Resolved和Closed三种，但这并不足以表示针对该Bug的具体工作的执行状态。所以我们添加了一个子状态域，它包括以下几种子状态：

  • Investigating：正在调查问题原因
  • Working on Solution：正在修复问题
  • Fix Available：修复已经准备好了
  • Testing fix：正在测试修复
  • Blocked：暂时无法修复或验证修复（比如有另一个Bug导致无法修复该Bug）

2. 回归（Regression）

    这个域表示该Bug是否是一个回归Bug，即之前经验证的正确行为在后来的某个时刻无法正确执行了。在相同的优先级和严重程度的情况下，回归Bug会得到比新Bug更多的关注。因为我们不希望在修改代码的时候，破坏其他的功能。

3. Triage

    这个域是为了记录Triage结果而专门设立的。Bug创建时通常把Triage状态设为“提交（Submit）”。在Triage小组开会讨论后，会根据处理意见将其分别标注为“同意（Approved）”、“更多信息（More Info）”“调查（Investigate）”、“拒绝（Rejected）”。Triage状态在Bug的整个生命周期中还可能不断变化。比如，一个Bug被拒绝后，创建者还是认为应该被修复，可以将Triage状态改回Submit，然后补充更多的理由或信息；这样Triage小组就会重新讨论并决定对该Bug的处理意见。再比如，一个Bug被修复后，测试人员认为修复后的结果仍然不理想，也可以将Triage状态改回Submit，说明修复之后的行为和理想中的行为分别是怎样的，以及他认为现在的行为不够理想的理由；Triage小组会根据更新过的行为重新讨论是否值得再次修复。

4. 测试用例状态（TC Status）

    对于任何一个Bug，作为测试人员都应该问的问题是：这个Bug已经被我们的测试计划覆盖了么？如果没有，值得我们为它添加一个新的测试用例或是修改已有的测试用例么？这就是“测试用例状态”域的作用。在创建Bug或是Triage的时候应该标注该域为以下几种可能：

  • Exists：测试用例已存在
  • Needed：需要添加测试用例
  • Need Update：需要修改已有的测试用例
  • Not Needed：不需要测试用例

小结

    本篇讨论了敏捷开发中的两种测试任务、三种不同形式的手动测试以及Bug的管理。在开发流程的各个阶段开展不同的测试活动，为产品提供了全方位的测试覆盖。而严格的Bug Triage流程以及Bug信息的填写为使得Bug管理更加有效。然而，手动测试只适用于开发流程中的某些测试活动。下一篇中，我们将进一步讨论敏捷开发流程中需要借助自动化测试的活动、手动测试/自动化测试的关系，以及如何做自动化测试。

林俊彦

 

本文精简版收录于《程序员》7月刊。