软件缺陷的生命周期

8 . 2 软件缺陷的生命周期

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

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

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

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

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

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

8 . 2 . 1 告缺陷就像写新闻

凯列班有个故事讲的是他最喜欢的缺陷。故事大概是这样的：

我 一个月前在实验室中发现了这个缺陷，然后 告了它。没有人注意到；所以在优先分配中，他们把它标记为被“推迟”。上个星期我们最大的客户也发现了它，突然 之间，这个缺陷就引发了一场危机。现在，我们需要交付一个维护版本，这就意味着我要整个周末都呆在实验室里检查所做的修复。为什么他们在我第一次 告的时 候没注意到这个缺陷呢/span>

真正的原因是什么呢常见的原因就是缺陷 告写得 不清楚，没有把影响充分传达给优先分配小组，所以所 告的缺陷被关闭了。凯列班的经理普洛斯彼罗对于凯列班的故事则有着不同的看法：“为什么凯列班不能把 他的缺陷 告写得清楚些，足以让团队能够对它们有所行动呢（因此，和前面一样，普洛斯彼罗在他的下一个项目中没有选择凯列班。）

从凯列班的经验中得出的教训可以用Kaner、Bach和Pettichord的名言来总结：

你的主张驱动你所 告的缺陷的修复

你所写的任何一个缺陷 告都是一个呼唤修复此缺陷的宣传文档。

有的缺陷永远也不会被修复。你的责任不是去保证所有的缺陷都被修复了。你的责任是以一种能让读者理解问题全部影响的方式精确地 告缺陷。

你研究得好不好， 告写得好不好，这些通常都会对缺陷修复的概率有着很重大的影响。

了解你的读者

你的缺陷 告的第一个读者就是优先分配小组（优先分配已经在第4章中讨论过）。他们会看到一个看起来像图8-4那样的查询。

图8-5 在思考表格和健康交谈历史的字段时，SOAP记忆法是个有用的方法。标题（Title）和症状（Symptom）是主观信息（S）；发现的构建版本 (Found In /[Build/])、发现的环境（Found-in Environment）和重现步骤（Steps to Reproduce）等字段是客观信息（O）；优先级(Priority)、严重程度(Severity)、区域路径(Area Path)和根本原因(Root Cause)是评估（A），而迭代(Iteration)和修复(Fix)是计划（P）

主观（Subjective ）信息： 支持所确定的问题的主观信息；

客观(Objective) 信息： 支持所确定的问题的客观信息；

评估（Assessment ）： 对于问题的评估，包括病源、严重性、当前治疗的高效性/毒性、治疗学上替代方案的列表、每个方案（治疗学上和经济上）的优点和缺点的讨论以及推荐的根本原因；

计划（Plan ）： 对所确定的问题进行管理的计划，包括实现和后续对问题的监控和治疗学响应的特定大纲。

好工匠会观察其他好工匠(包括其他学科的工匠)做什么。在你 告缺陷和评审缺陷 告时，SOAP是一个应当使用的好模型。让我们看一看VSTS在用于CMMI过程改进的MSF中所提供的标准缺陷 告表单。

8 . 2 . 2 主观数据

对 告的读者而言,最重要的问题是：对用户的影响是什么多数时候，回答这一问题，需要进行一番思考。问自己一些与下面这些问题相类似的问题：

 ·当客户看到这一问题时，他会对产品支持人员说什么/span>

 ·根据客户对其他软件（包括竞争者的产品）的体验，这次他们将有什么样的期待/span>

 ·如果销售代表或培训师在演示时遇到了这种情况的话，会说什么呢/span>

 ·这一缺陷会对应用场景产生什么样的影响/span>

 ·这一缺陷会对下游环节产生什么样的影响/span>

 ·会涉及多少用户，频繁程度如何/span>

 ·这是一个孤立的事件吗/span>

 ·这里有安全性的风险吗/span>

 ·其他服务质量会受到影响吗/span>

首先要编写这个故事。你对这些问题的答案将会决定应花多少时间来研究这一缺陷，又会决定应为此 告收集什么样的数据。

标题问题

正如你在图8-4中所看到的，标题通常是读者所看到的唯一信息。如果标题不清晰，当被截断到适合字段宽度时，信息的剩余部分可能永远也不会读到。

描述困惑

关于缺陷的永久的下一级信息是描述。变更历史可能会很长，但是描述应当是关于缺陷的、简洁的细节。

每个缺陷一个 告

如果你有2个缺陷，就应该写2个 告。保持每个观察到的缺陷都在它自己的 告中，这会让所有 告都更易于理解。

8 . 2 . 3 客观数据

在编写了关于此缺陷的主观数据之后（参见图8-6），就到了收集客观数据的时候了。

图8-6这里所说的缺陷工作项类型，来自于用于CMMI过程改进的MSF，它捕获了用户在查询、跟踪和分析缺陷时所需要的所有信息

服务质量

要清楚你所 告的问题的类型——服务质量受到了什么影响。

相关特性或代码

如果你能把缺陷与你所测试的特定特性或受测源代码的特定区域关联起来，那就这么做。

重现测试

如果你有一个测试来重现这个缺陷，那就标识出它。

附件

你可以附加什么样的数据到缺陷 告上，从而演示这一缺陷发生在怎么样的条件下果适用的话，所有这些都会有用的：

 ·屏幕快照

 ·数据文件

 ·配置文件

 ·跟踪文件

 ·服务器日志

 ·Dr.Watson日志

重现步骤

你如何在最小的设置中以最少的步骤来重现这一缺陷开发者针对缺陷的工作中，80%的工作量往往就在于重现步骤——你能把缺陷发生过程简化到什么程度何不必要的东西显然都是浪费。要确保重现步骤精确和清晰。在提交缺陷之前，要检查它们。

前置条件

重现这一错误，比如加载一个特定的数据库，是否需要特殊的设置果问题能够通过产品数据或客户数据演示出来，这就特别有说服力。

8 . 2 . 4 评估数据

在缺陷的生命周期中，评估会发生多次变化，因为人们需要精细化诊断和观察、调试源代码、努力修复和测试修复、研究相关的缺陷等等。你的任务就是要保证缺陷历史的精确性和全面性，因为对于缺陷及其条件你所知甚多。

在初始 告中，你能够做一些评估，而更多的评估会随着缺陷的历史和会话而演进。

它是不是重复的

应花一点时间查询整个数据库，从而确定这到底是关于已发现缺陷的更多的信息呢，还是一个新发现的缺陷。但是不要过分沉迷。稍后别人将你 告的缺陷标为重复，这也很容易。显然，如果你发现了关于已有的缺陷的更多信息，就应该把发现更新到该缺陷 告中。

它的一般性如何

去除你的边际情形（corner case）的边际性。通常，你会使用极限数值、不常见的配置或者长输入序列来发现缺陷。理解缺陷重要性的根本就是要知道缺陷发生所必须的特殊性条件或一般性条件。这里是一些提示：

 ·使用不同的数据。 如果你是用一组特定的输入值发现的缺陷，那么就尝试一下不同的输入值。尤其是要尝试不同的等价类。缺陷的表现对特定值或特定等价类的依赖程度如何/span>

 ·使用不同的配置。 如果你是在硬件和软件构件的一个特殊配置下发现的缺陷，那么应该在一组非常不同的机器上试一下。

 ·使用不同的流。 如果缺陷出现在一个特殊的操作序列（尤其是很长的序列）下，那么看看是不是有其他（最好是更短的）路径可以得到同样的结果。

 ·寻找可疑的交互。 如果有的事情好像是一个奇怪的副作用，但你又不确定，要继续刺探。例如，在你使用了一个程序之后，另一个可能突然变慢了。可能它们依赖一些相同的部件、数据或者OS服务。

 ·还有更多的吗/strong> 猜测类似的缺陷还会潜伏在哪里。寻找它们。

它的严重性如何

当你第一次发现一个缺陷时，会有一种巨大的诱惑让你感到满意并要 告它。实际上，可能还有很多更严重的问题。注意初始的症状并继续使用受测软件。你可能会发现没有被妥善处理的错误路径和异常，以及未预料到的交互和其他会给用户（或技术支持人员）造成困惑的问题。

8 . 2 . 5 计划

在初始 告中，你手中主要的计划工具是优先排序和归属关系。根据你的不同过程，这些可能只能由优先分配小组来设定，或者在不太正规的组织中，也可能由提交者直接填 。处理优先排序的方式应当与它在项目管理中所采用的方式相同。

迭代

仔细考虑计划中的迭代。在早期迭代中，所提出的缺陷往往都集中在那些现在还不能工作的功能上。优先分配的目的之一正是从开发人员的直接队列中清除这种噪音。

文章知识点与官方知识档案匹配，可进一步学习相关知识MySQL入门技能树数据库组成表31716 人正在系统学习中