报告发现的问题
设法修复软件缺陷
●没有足够的时间。在任何一个项目中，通常是软件功能太多，而代码编写人员和软件测试人员太少，而且进度中没有留出足够的空间来完成项目。假如你正在制作税务处理程序，4月15日 (赶在应付税务检查之前，译者注)是不可更改的交付期限必须按时完成软件。
●不算真正的软件缺陷。也许有人会说:" 这不算软件缺陷,而是一项功能。"很多情况下，理解错误、测试错误或者说明书变更会把可能的软件缺陷当做功能来对待。
●修复的风险太大。遗憾的是，这些情形很常见。软件本身是脆弱的、难以理清头绪，有点像一团乱麻，修复一个软件缺陷可能导致其他软件映陷出现。在紧迫的产品发布进度压力下，修改软件将冒很大的风险。不去理睬已知的软件缺陷，以避免造成新的、未知的缺陷的做法也许是安全之道。
●不值得修复。虽然有些不中听，但是事实。不常出现的软件缺陷和在不常用功能中出现的软件缺陷是可以放过的，可以躲过(workarounds)和用户有办法预防或避免的软件缺陷通常不用修复。这些都要归结为商业风险决策。另外应该加入到该清单中的一-项是通常可以理解为上述几项的成因:
●无效的软件缺陷修复报告。测试员没有建立足够强大的用例来使特定软件缺陷得以修复。其结果是软件缺陷被误认为不是软件缺陷，认为软件缺陷不够重要到要推迟软件产品发布，认为修复风险太大，或者仅仅简单地以为不值得修复。
软件测试员不必像律师或者调解争端的组长那样，想方设法说服所有人需要修复已发现的软件缺陷。以平常的心态以及基本交流的技巧就可以应付很多情况了。本章后面将介绍用于软件觖陷记录和跟踪的各种系统，但是眼前先看一下报告软件缺陷的基本原则:
●尽快报告软件缺陷。这虽然在前面多次讨论，但是如何强调都不够。软件缺陷发现得越早，在进度中留下的修复时间就越多。假定在软件发布之前几个月从帮助文件中找出一个令人汗颜的拼写错误，该软件缺陷修复的可能性极高。如果在软件发布之前几个小时发现同样的缺陷，不修复的可能性更大。图19-1在图形上显示了时间和缺陷修复之间的关系。
这似乎很奇怪一不 管今天发现还是3个月之后发现，软件缺陷就是缺陷。理想情况下，何时发现不应该有什么关系，仅仅与软件缺陷的内容有关系。然而，实际上修复觖陷的风险随着时间的推移大大增加，而且在做决定过程中的分量不断加重。
●有效描述软件缺陷。假定你是程序员，接到测试员的下述报告:"无论何时在登录对话框中输入一串随机字符，软件都开始进行-些奇怪的动作"。在不知道随机字符是什么，一串字符有多长，产生什么奇怪现象的前提下，从何着手修复这个软件缺陷呢?
●在报告软件缺陷时不要做评价。测试员和程序员之间很容易形成对立关系。如果忘了原因，可参见第3章。从程序员或者开发小组其他人员的角度看，软件觖陷报告是软件测试员对他们的工作的"成绩报告单"，因此需要不带倾向性、个人观点和煽动性。声称"你控制打印机的代码很糟糕，根本无法工作。我甚至无法相信你在送来测试之前做过一点检查。"的报告是无法让人接受的。软件缺陷报告应该针对产品，而不是具体的人，只陈述事实。避免幸灾乐祸、哗众取宠、个人倾向、自负、责怪。得体和委婉是关键。
●对软件缺陷报告跟踪到底。比没有找到重要软件缺陷更糟糕的是，发现了一一个重要的软件缺陷，做了报告，然后把它忘掉了或者跟丢了。大家知道，测试软件是一个艰苦的工作，因此不要让劳动成果，即找出的软件缺陷被忽视掉。从发现软件缺陷的那一刻起，测试员的责任就是保证它被正确地报告，并且得到应有的重视。一个好的测试员发现并记录许多软件缺陷。一个优秀的测试员发现并记录了大量软件缺陷之后，继续监视其修;复的全过程。本章后面将更详细地讲述这一点。
分离和再现软件缺陷
要想有效报告软件缺陷，就需要以明显、通用和可再现的形式描述它。在许多情况下这
很容易。假定有一个画图程序的简单测试用例，检查绘画可以使用的所有颜色。如果每次选择红色，程序都用绿色绘画，这就是明显的、通用的和可再现的软件缺陷。但是如果这个颜色错误的软件缺陷仅在执行一些其他测试用例之后出现，而在重新启动机器之后直接执行专门的错误用例时不出现这些缺陷，该怎么办?假如它随机出现或者只是每月月圆之时出现，该怎么办?最好有一条警犬。分离和再现软件缺陷是充分发挥侦探才干的地方，设法找出收缩问题的具体步骤。好消息是，不存在随机软件缺陷这样的事一如果 建立完全相同的输入和完全相同的环境条件，软件觖陷就会再次出现。坏消息是，验明和建立完全相同的输人和完全相同的环境条件要求技巧性非常高，而且非常耗时。一旦知道了答案，就显得很容易。当不知道答案时，就显得很难。
如果找到的软件映陷似乎要采用繁杂步骤才能再现，或者根本无法再现，如下一些提示
和技巧会打开局面。如果碰到这种情况，尝试用如下清单中的建议作为分离软件的第一 步:
●不要想当然地接受任何假设。记下所做的每一件事一每- 一个步骤、每- ~次停顿、每一件工作。无意间丢掉一个步骤或者增加一个多余步骤会很容易出现的。请一个合作者看着你运行测试用例。利用按键和鼠标记录程序准确记录和回放执行步骤。如果必要，使用录像机记录下测试会话。所有这些的目的是确保导致软件缺陷所需的全部细节可见，并且可以从另一个角度分析。
●查找时间依赖和竞争条件的问题。软件缺陷仅在特定时刻出现吗?也许它取决于输人数据的速度，或者正使用慢速软盘代替快速硬盘保存数据。看到软件缺陷时网络忙吗?在更慢或更快的硬件上运行测试用例。要考虑时序。
●边界条件软件缺陷、内存泄露和数据溢出等白盒问题可能会慢慢自己显露出来。执行某个测试可能导致数据覆盖但是也只有在试图使用这些数据时才会发现一也许在后面的测试中才有可能。重新启动计算后消失，而仅在执行其他测试之后出现的软件缺陷常常属于这一类。如果发生这种现象，就要查看前面执行的测试，也许要利用一些动态白盒技术，看软件缺陷是否在无意间发生了。
●状态缺陷仅在特定软件状态中显露出来。状态觖陷的例子是软件映陷仅在软件第一次运行时出现或者在第一次运行之后出现。软件缺陷也许仅在保存数据之后，或者按任何键之前发生。状态觖陷看起来很像时间依赖和竞争条件的问题，但是你会发现时间并不重要一重 要的是事件发生的次序，而不是发生的时间。
●考虑资源依赖性和内存、网络、硬件共享的相互作用。软件缺陷是否仅在运行其他软件并与其他硬件通信的"繁忙"系统上出现?虽然软件缺陷可能最终会被证实是由于软件的依赖性或者对资源的相互作用进一步恶化的竞争条件、内存泄露或者状态缺陷问题，但是查一查这些影响有利于分离软件缺陷。
●不要忽视硬件。与软件不同，硬件可能降级，不按预定方式工作。板卡松动、内存条损坏或者CPU过热都可能导致像是软件缺陷的失败，但是实际上不是。设法在不同硬件上再现软件缺陷。这在执行配置和兼容性测试中尤其重要。需要知道的是缺陷是在一个系统上还是在多个系统上出现。
并非所有软件缺陷生来就是平等的
在报告软件缺陷时，一般要讲明它们将产生什么后果。测试员要对软件缺陷分类，以简明扼要的方式指出其影响。常用方法是给软件缺陷划分严重性(severity) 和优先级( priority)。当然，具体方法各公司不尽相同，但是通用原则是一样的:
●严重性表示软件缺陷的恶劣程度，当用户碰到该缺陷时影响的可能性和程度。
●优先级表示修复缺陷的重要程度和紧迫程度。
下列严重性和优先级的常用划分方法清单有助于更好地理解两者之间的差别。请记住，这只是示例。有些公司最多使用10个等级，而另一些公司只使用3个等级。然而，不论使用多少个等级，目标都是一致的。
严重性:
1)系统崩溃、数据丢失、数据毁坏，安全性被破坏。
2)操作性错误、结果错误、功能遗漏。
3)小问题、拼写错误、UI布局、罕见故障。
4)建议。
优先级:
1)立即修复，阻止了进-一步测试，立竿见影。
2)在产品发布之前必须修复。
3)如果时间允许应该修复。
4)可能会修复，但是即使有产品也能发布。
软件缺陷的生命周期
从解决状态回到打开状态的附加线涉及软件测试员发现软件缺陷没有被修复的情况。软件缺陷重新打开，重复新的生命周期。从关闭状态和推迟状态绕回打开状态的两条虚线虽然很少发生，但是一定要引起重视。由于软件测试员永远不会放弃，因此原来认为已经修复、测试和关闭的缺陷可能会再次出现。此类软件缺陷一般称为回归缺陷( regressions)。推迟修复的软件缺陷以后也可能被证实很严重，要立即修复。如果发生任意一种情况，软件缺陷就要重新打开，再次启动整个过程。
大多数项目小组都制定规则规定由谁来改变软件缺陷的状态，或者交给其他人来处理软件缺陷。例如，只有项目经理可以决定推迟软件缺陷修复，或者只有测试员允许关闭软件觖陷。重要的是一旦记录了软件缺陷，就要跟踪其生命周期，不要跟丢了，并且提供必要的信息驱使其得到修复和关闭。
软件缺陷跟踪系统
至此，我们清楚了软件缺陷报告的过程是很复杂的，需要大量的信息、详尽的细节和相
当数量的组织纪律才能有所成效。本章到目前为止所讲述的一切表面上看起来很好，但是运
用到实践中还需要某种系统，以便记录发现的软件缺陷，并在其整个生命周期中进行监视。
软件缺陷跟踪系统可以胜任此项工作。
本章以下内容将讨论软件缺陷跟踪系统，并给出使用纸笔方法和使用成熟的数据库跟踪
的示例。当然，使用什么工具可以针对公司或者项目的具体情况定制，但是原则通常在软件
行业中是一致的，因此应该可以在要求使用的任何系统中运用这些技巧。
标准:测试事件报告
我们的好朋友，软件测试文档的IEEE 829标准( 由standard.ee.org提供)定义了一个称为测试事件报告(Test Incident Report)的文档，其目的是"记录在需要调查的测试过程期间发生的任何事件"。简而言之，就是记录软件缺陷。回顾标准对于提炼到目前为止所学的缺陷报告过程，并从总体来看待它是个好的办法。下表列出了标准中定义、采纳和更新了的区域，以反映新近的术语
●标识符。定义软件缺陷报告的惟- -ID， 用于定位和引用。
●总结。用简明扼要的事实陈述总结软件缺陷。要测试的软件及其版本的引用信息，相关
的测试过程、测试用例和测试说明也应该包含在内。
●事件描述。提供下列软件缺陷的详细的描述信息:
日期和时间
测试员的姓名
使用的硬件和软件配置
输入
过程步骤
预期结果
实际结果
试图再现以及尝试的描述
有助于程序员定位软件缺陷和其他现象或者信息
●影响。严重性和优先级，以及测试计划、测试说明、测试程序和测试用例的影响指示。
手工软件缺陷报告和跟踪
IEEE829标准虽然没有定义软件缺陷报告应该采用的格式，但是给出了一个简单文档的例子。图19-5显示 了此类书面软件报告的模样。
注意这个只有一页的表单，可以容纳标识和描述软件缺陷的必要信息。它还包括用于在生命周期中跟踪软件缺陷的域。表单一旦由测试员填好，缺陷就可以交给程序员进行修复了。程序员有填写关于修复的信息的域，包括可能的解决方案的选择。还有一个区域，一旦解决了软件缺陷，软件测试员可以在此提供重新测试和关掉软件缺陷所做工作的信息。表单底端是签名区-- 在许多行业中，当在这一-行签上软件测试员的名字，就表明缺陷被满意地解决了。对于非常小的项目，书面表单足以胜任。在最近的20世纪90年代，即使对于任务严格的大型项目，也使用书面表单对成千上万个软件缺陷进行报告和跟踪。今天仍然存在这样的袖珍本。书面表单的问题是，它是纸。如果走进一家靠书面文件运转的公司，想找点东西，就知道此类系统是多么低效了。
自动化软件缺陷报告和跟踪
正如第18章" 编写和跟踪测试用例"中所述的测试用例和测试程序文档一样， 没有道理不利用现代化的系统把IEEE 829标准更新并应用到工作中来。毕竟，跟踪软件缺陷的信息，即图19-5所示的表单上的数据只是文字和数字一-这 是个完美的数据库应用程序。图19-6给出了这样的-一个自动化软件缺陷报告和跟踪系统，代表工作中可能碰到的类型。
成效评价
通过使用软件映陷跟踪数据库中的信息，可以进行查询，指出发现的软件缺陷类型，发现软件缺陷的速度，以及多少软件缺陷已经得到了修复。测试经理或者项目经理可以看出数据中是否有趋势显示需要增加测试的区域，或者项目是否脱离计划发布日期的轨道。数据摆在那里，问题就是建立能够显示所需信息的报表。
使用软件跟踪数据库中的信息
因为软件缺陷数据库不断更新新的软件缺陷、软件缺陷登记项和修复日期、项目成员姓名、软件缺陷的指派等，所以把描述项目状态一以及 各测试员或者程序员的状态的各种度量放在一起是很自然的。利用软件缺陷数据库进行度量有一个潜在问题。同一个数据库可以告诉所有人，有多少优先级1软件映陷仍然需要修复; ;也能告诉管理部门，某一个程序员制造了多少个软件缺陷。
它还能告诉老板，与小组中其他测试员相比，某位测试员记录了多少个软件缺陷。公布这些信息是好事吗?也许是，如果测试员和程序员都真正擅长测试工作。但是如果测试优秀程序员的代码呢?没有多少软件缺陷能找出来，软件缺陷发现的度量值突然间降低了，与测试满是软件缺陷的代码的测试员无法相比。
在日常测试中使用的度量
软件缺陷跟踪数据库最常用的特性( 除了输入软件缺陷之外)可能就是执行查询，获得感兴趣的软件缺陷清单。不要忘了，软件缺陷数据库存可能存放了成千上万的软件缺陷。在如此大型的清单中手工选择是不可能的。在数据库中选择软件缺陷的美妙之处是让执行查询成为了简单的任务。图20-1 显示了一个典型的查询构造窗口，有一个查询示例准备输入。
把解决方案字段导出到图表程序中，可以生成如图20-5所示的图表，显示Pat发现的软件缺陷大多数最终得以修复(对测试员的友好表示)，只有小部分以不可再现、重复、推迟或者由于某种原因不算问题等方式解决。一旦开始测试，就会找到个人或者小组乐于使用的某种度量来衡量测试过程的进行情况。可以统计自己每天发现了多少个软件缺陷，或者像前面的例子那样，统计"修复率"。重要的是通过从软件缺陷数据库中提取信息，可以构造任何想要的度量。这引出了本章的下一部分，它描述评价整个项目情况的一些常用高级度量。