8.2软件缺陷的生命周期

8.2软件缺陷的生命周期

与生物学的昆虫不同，软件的缺陷要经历一组非常严格的状态（参见图8-2）。在VSTS中，缺陷所允许的缺省的状态和转换依赖于你为项目所选择的过程模板。所选过程的那组规则决定了：选择可允许的状态；定时、授权哪些用户组可以将缺陷推进到下一个状态；允许转换的原因。如果有权限的话，你可以进一步定制这些规则，从而使它们与团队的工作流相匹配。

 

图8-2此状态图是用于CMMI过程改进的MSF中的软件缺陷的生命周期

在VSTS中

·在用于CMMI过程改进的MSF中，缺陷有4个状态，开始状态是已提出状态。在变为活动状态之前，需要有个接受操作。

·在用于敏捷软件开发的MSF中，缺陷只有3个状态，开始状态是活动状态。

任何人都可以提出缺陷，也就是说，请求把它纳入待修复的队列。

项目经理可以激活一个缺陷，然后把它分配给一个开发人员。

在研究或修复了代码后，开发人员会在下一次签入时把缺陷标记为已解决状态（参见图8-3）。不允许开发人员直接关闭缺陷。

 



图8-3 在VSTS中，很少在check In对话框中核对缺陷，开发人员把将交付的变更集与待修复的缺陷相关联。这种关联是永久的，用于填写构建报告和度量元仓库

当相应的源代码被签入时，签入过程自动解决了缺陷。

测试人员可以在相应的查询中看到已修复的缺陷。只有在测试人员确认缺陷通过了测试从而证明它已被修复之后，才能由测试人员关闭缺陷（当然，如果测试失败了，测试人员就会重新激活缺陷）。

实际上，工作流可能更简单也可能更复杂。例如，在敏捷MSF中，不要求在激活之前必须有个已提出状态，也不强制使用不同的权限，反而要依靠信任。反过来，一些过程，尤其是在后期迭代中，在代码被评审之前，不允许签入代码。工作项可以通过一个新状态或者一个单独的字段来强制这一规则，签入政策可以强制这一工作流。

无论这些规则是什么，它们都是你当前项目的过程的可触摸的形式。