测试执行、缺陷报告与跟踪¶
第 13 章¶
测试执行、缺陷报告与跟踪¶
当测试用例的设计和测试脚本的开发完成之后，就开始严格按照测试用例执行手工测试，或者运行测试脚本进行自动化测试，完成相应的测试任务。自动化测试的管理相对比较容易，测试工具会不打折扣地、百分之百地执行所有的测试脚本，并能准确无误地自动记录下测试结果。而对手工测试的管理相对要复杂得多，在整个测试执行阶段中，管理上会碰到一系列问题，主要有:
了解软件缺陷是什么，在需求和设计评审过程中会发现问题，并通过设计和执行测试用例，能更快地发现缺陷。发现了缺陷，还需描述缺陷产生的过程或现象，报告给开发人员，这就是软件缺陷的报告。
如何报告所发现的软件缺陷？就是要准确、清楚地描述内容，这其中要借助一些工具（如 WinDBG、Soft_ICE) 来创建记录软件缺陷的日志文件。为了更有效地报告和处理缺陷，还要全面理解缺陷的各种属性以及缺陷的生命周期，并掌握分离和再现软件缺陷的技巧，而对于一个软件企业，则要建立基于数据库的软件缺陷跟踪系统。
13.1 软件测试执行与跟踪¶
在项目的管理过程中，经常碰到的问题是：等待做的任务比较多，但人力资源和时间受到限制，要完成所有的任务几乎是不可能的。这时候要解决的就是为各项任务建立优先级，这样就可以根据优先级高低，先后处理各项任务，降低测试的风险，以最小的代价获得尽可能高的质量。但在过程中，始终能够把质量放在第一位，能够制定好测试策略、有计划地安排工作、系统的解决方案等。当遇到问题时，能准确地判断是技术问题还是流程问题，重视解决流程问题，将项目中已有的成功经验能灵活地应用到新的项目中，做好测试项目的风险管理和质量管理。
13.1.1 测试执行过程的要点¶
通过客观的评价标准，减少人为错误，更准确地控制测试进程。要做到这一点，尽量及时、准确、客观地将所有活动产生的有用的数据记录下来，包括会议纪要、审核记录、缺陷报告等。强调以数据说话，跟踪项目状态，监督各项措施落实，这样使整个项目过程具有良好的可测性、可跟踪性。同时，要善于利用各种工具和系统，使这项工作记录的数据更直观、数据化，便于评估。
1. 不同测试阶段的执行要点¶
要对每个测试阶段 (代码审查、单元测试、集成测试、功能测试、系统测试和验收测试、安装测试等) 的结果进行分析，保证每个阶段的测试任务得到执行，达到阶段性的目标。
2. 测试用例执行¶
测试用例执行直接关系到测试的效率和产品的质量，要做好相应的执行工作。首先要努力提高测试人员的素质和责任心，树立良好的质量文化意识，以预防为主。其次，要通过一定的跟踪手段来保证测试执行的质量。例如，测试效率的跟踪比较容易，按照测试任务和测试周期，可以得到期望的曲线，然后每天检查测试结果，了解是否按预期进度进行，如图 13-1 所示为测试执行情况的跟踪曲线。
测试结果的跟踪相对困难些，需要控制好风险。可以通过系统记录每个人所执行的测试用例，一旦某个 Bug 被漏掉，可以追溯到具体责任人。事后发现问题，已经太迟了，这时可以考虑针对风险较大的任务，在第二轮测试时，交换测试人员以加强风险的控制。另外，每个项目都让项目之外的几个经验丰富的测试人员进行两三天的探索式测试，发现一些隐藏比较深的缺陷，也可对前面的测试产生比较大的压力，使每个测试人员都不敢松懈。
3. 团队建设与沟通¶
优秀的项目管理者知道自己首要的任务是领导好团队，服务好整个团队，这些服务包括技术训练和指导、解决问题和冲突、提供资源、建立项目目标和优先级等。测试的任务是要靠大家完成的，团队的绩效才是重要的，只有依靠团队的力量，才能确保项目的成功。所以有良好的意识去关心组员，关注项目组员的情绪，以鼓励为主，不断激励员工，鼓舞士气，发挥每一位员工的潜力，注重团队的工作效率。同时，要注意合理分配任务，明确规定每一个人在测试工作中的具体任务、职责和权限，每个组员都明确自己该做什么、怎么做、负什么责任、做好的标准是什么。做到人人心中有数，为保证和提高产品质量 (或服务质量) 提供基本的保证。
项目管理者具有良好的沟通能力，和其他部门不仅能进行有效沟通，而且可以施加自己的影响 (说服别人), 以促进项目的整体合作、相互理解和流程改进。为了使测试进展顺利，与项目组外部人员的良好沟通是必要的，促进问题解决，提高缺陷处理的效率，还有一些值得推荐的方法，例如:
4. 测试执行结束¶
在测试执行结束前，要对测试项目进行全过程、全方位的审视，检查测试计划、测试用例是否得到执行，检查测试是否有漏洞。如果存在测试漏洞，及时补救。而且，对当前状态的审查，包括产品 Bug 和过程中没解决的各类问题。对产品目前存在的缺陷进行逐个的分析，了解对产品质量影响的程度，从而决定产品的测试能否告一段落。如果所有测试内容完成、测试的覆盖率达到要求以及产品质量达到已定义的标准，可以宣告测试执行结束。
测试执行任务完成，并不意味着测试项目的结束，还需要对测试结果分析、对产品质量进行评估，编制测试报告或质量报告，而且测试报告应获得上级经理的批准。此后，项目组成员一起对项目进行总结 (即 Postmortem), 分析项目的成功经验，并通过对项目中的问题分析，找出根本原因，纠正流程、技术或管理中所存在的问题，改进测试过程。
13.1.2 测试项目进度的管理方法¶
在软件测试管理中最重要、最基本的就是测试进度跟踪。众所周知，在进度压力之下，被压缩的时间通常是测试时间，容易导致实际的进度随着时间的推移，与最初制定的计划相差越来越远。如果有了正式的度量方法，这种情况就能够避免，因为在其出现之前就有可能采取了行动。下面就介绍两种测试项目进度的管理方法：测试进度 S 曲线法、缺陷跟踪曲线法。缺陷跟踪又可以分为新发现缺陷跟踪法和累计缺陷跟踪法，而以累计缺陷跟踪法比较好。
1. 测试进度 S 曲线法¶
进度 S 曲线法通过对计划中的进度、尝试的进度与实际的进度三者对比来实现，其采用的基本数据主要是测试用例或测试点的数量。同时，这些数据需按周统计，每周统计一次，反映在图表中。“S” 的意思是，随着时间的发展，积累的数据的形状越来越像 S 形。可以看到一般的测试过程中包含三个阶段：初始阶段、紧张阶段和成熟阶段。第一和第三阶段所执行的测试数量 (强度) 远小于中间的第二阶段，由此导致曲线的形状像一个扁扁的 S。
X 轴代表时间单位 (推荐以 “周” 为单位), Y 轴代表当前累计的测试用例或者测试点数量，如图 13-2 所示，可以看到:
由于测试用例的重要程度有所不同，因此，在实际测试中经常会给测试用例加上权重 (Test Scores)。使用加权归一化 (Normalized) 使得 S 曲线更为准确地反映测试进度 (这样 Y 轴数据就是测试用例的加权数量), 加权后的测试用例数通常称为测试点 (Test-point)。
一旦一个严格的计划曲线放在项目组前，它将成为奋斗的动力，整个小组的视线都开始关注计划、尝试与执行之间的偏差。由此，严格的评估是 S 曲线成功的基本保证，例如，人力是否足够、测试用例之间是否存在相关性等。一般而言，在计划或者尝试数与实际执行数之间存在 \(15\% \sim 20\%\) 的偏差时，就需要启动应急行动来进行弥补了。
一旦计划曲线被设定，任何对计划的变更都必须经过审查 (Review)。自然，需要严格的程序规范，否则计划成了变化，如同儿戏。同时，一般而言，最初的计划应作为基准 (Baseline), 即使计划做了变更，也留作参考。该曲线与后来的计划曲线的对比显现的不同之处需要给出详尽的理由作为说明，同时也是此后制定计划的经验来源之一。
2. 测试进度 NOB 曲线法¶
测试所发现的软件缺陷数量，一定程度上代表了软件的质量，通过对它的跟踪来控制进度也是一种比较现实的方法，受到测试过程管理的高度重视。在整个测试期间主要收集当前所有打开的 (激活的) 缺陷数 (Number of Open Bug, NOB), 也可以将严重级别的缺陷分离出来进行控制，从而形成 NOB 曲线，它在一定程度上反映了软件质量和测试进度随时间的发展趋势，如图 13-3 所示。
在 NOB 曲线法中，最重要的是确定基线数据或者典型数据，即为测试进度设计一套计划曲线或理想曲线。至少在跟踪开始的时候，需将项目进度关键点 (里程碑) 预期的 NOB 限制等级设置好，以及确定什么时间 NOB 达到高峰，NOB 在测试产品发布前能否降到足够低的水平。比较理想的模式是，相对于之前发布的版本或者基线，NOB 高峰期出现得更早，在发布前降到足够低并且稳定下来。
尽管 NOB 应该一直都被控制在合理的级别上，但是当功能测试的进展是最主要的开发事件时，应该关注的是测试的有效性和测试的执行，并在最大程度上鼓励缺陷的发现。过早地关注 NOB 减少，可能导致目标冲突，导致潜在的缺陷逃逸或者缺陷发现的延迟。因此，在测试紧张阶段，主要应该关注的是那些阻止测试进展的关键缺陷的纠正。当然，在测试接近完成时，就应该强烈关注 NOB 的减少，因为 NOB 曲线的后半部分尤为重要，它与质量问题密切相关。
Myers 有一个关于软件测试的著名的反直觉原则：在测试中发现缺陷多的地方，还有更多的缺陷将会被发现。这个原则背后的原因在于：如果测试效率没有被显著地改善，发现缺陷多的地方，意味着代码质量更低。举一个例子，模块 A 存在 1000 个缺陷，模块 B 存在 200 个缺陷，测试效率都是 95%，那么测试人员在模块 A 中会发现其中的 950 个缺陷，在模块 B 中会发现其中的 190 个缺陷，最后模块 A 中遗漏的缺陷数是 50, 而后模块 B 中遗漏的缺陷数是 10。这个例子，验证了上述原则。另外，修正越多的缺陷时，会引入更多的新的缺陷。因此，遇到这种情况，要挖掘深层次的原因，然后采取不同的处理措施。
（1）如果缺陷发生率与以前发布的一个版本（或模板）相同或更低，就应该考虑当前版本的测试是不是低效？如果不是，那么质量的前景是乐观的；如果是，那么就需要额外的测试。除了要对当前的项目采取措施，还需要对开发和测试的过程进行改善。
(2) 如果缺陷发生率比以前发布的一个版本 (或模板) 更高，那么就应该考虑是否为显著提高测试效率做了计划，并实际上做到了这一点？如果没有，那么质量将得不到保证；如果是这样，那么质量将得到保证或者说质量是乐观的。
13.1.3 测试过程管理工具¶
软件测试管理工具或管理系统比较成熟，拥有比较多的产品，不仅能满足测试管理的需求，而且可以适应不同类型、不同规模软件企业的特点。常见的测试管理工具主要有以下一些。
(1) 商业性工具: HP ALM, IBM Rational Test Manager 和 Team Test, Compuware QADirector, Borland SilkCentral Test Manager 和 Microsoft Visual Studio Team System 等。
(2) 开源工具: TestLink、Bugzilla Test Runner、验收测试管理工具 FitNesse、基于 XML 文件测试用例管理工具 JtestCas、Eclipse 测试和性能工具平台 (Test & Performance Tools Platform, TPTP)。除此之外，还有其他一些测试管理框架，如 TestMaker、SalomeTMF、JTR (Java Test Runner)、Jetif、Marathon、Grinder、TESTARE 等。
下面以 HP ALM 作为示例，帮助读者了解测试管理工具的具体特性以及所发挥的作用。
HP ALM 是一套软件开发与测试管理软件，以需求驱动整个测试过程，规范测试管理的流程，包括测试需求管理、测试计划、测试执行到缺陷跟踪。
(1) 测试需求管理。通过提供一个比较直观的机制将需求和测试用例、测试结果和报告的错误联系起来，从而确保能达到最高的测试覆盖率。即使频繁地更新，仍能简单地将应用需求与相关的测试对应起来。检查应用程序的文档，以确定测试范围和测试目标、策略。构建 “需求树” 的目的是为了确定完全覆盖测试需求，为 “需求树” 中的每一个需求话题建立一个详细的目录，描述每一个需求、分配优先级和链接附件。产生的报告和图表以帮助分析测试需求。
(2) 编制测试计划。指导测试人员如何将应用需求转化为具体的测试计划，组织起明确的任务和责任，并在测试计划期间为测试小组提供关键要点和 Web 界面来协调团队间的沟通。提供了多种方式来建立完整的测试计划，包括从草图上建立一份计划、通过 Test Plan Wizard 快捷地生成一份测试计划、将计划信息的相关文件导入到计划管理器中。测试计划的主要步骤有定义测试策略、定义测试对象、定义测试、创建需求覆盖 (连接每一个测试和测试需求)、设计测试步骤、自动化测试脚本的建立和分析测试计划。例如，为每一个模块确定其测试类型，在测试计划树中为每一个测试点添加基本说明；描述了测试注意事项、检查点、每个测试的预期结果。
（3）安排和执行测试。创建测试套件、分配测试任务和时间表、运行测试任务和分析测试结果。其中，Smart Scheduler 根据测试计划中创立的指标对测试执行监控，能自动分辨是系统还是应用错误，然后将测试切换到网络的其他机器。当网络上任何一台主机空闲，测试任务会安排到这台主机上，也就是能充分利用时间、机器、网络资源等。使用 Graphic Designer 图表设计，可以很快地将测试分类以满足不同的测试目的，如功能性测试、负载测试、完整性测试等。它的拖动功能可简化设计和排列在多个机器上运行的测试，最终根据设定好的时间、路径或其他测试的成功与否，为序列测试制订执行日程。
（4）缺陷跟踪。添加缺陷、检查新的缺陷、修复缺陷、验证修改结果和分析缺陷数据，贯穿整个测试过程。由于同一项目组中的成员经常分布于不同的地方，TestDirector 基于浏览器的特征，使这些用户可以随时随地查询出错跟踪情况。利用出错管理，测试人员只需进入一个 URL，就可汇报和更新错误，过滤整理错误列表并作趋势分析。
（5）人工与自动测试的结合。多数的测试项目需要人工与自动测试的结合，包括健全、还原和系统测试。即使符合自动测试要求的工具，在大部分情况下也需要人工操作。通过自动化切换机制，让测试人员决定哪些重复的人工测试可转变为自动脚本以提高测试速度，并简化这一转化过程，及时启动测试设计过程。
（6）图形化和报表输出。TestDirector 常规化的图表和报告帮助对数据信息进行分析，提供直观且有效的方法来收集测试结果和分析数据，还以标准的 HTML 或 Word 形式提供生成和发送正式测试报告。测试分析数据还可简便地输入到标准化的报告工具，如 Excel、ReportSmith、CrystalReports 和其他类型的第三方工具。
（7）用户权限管理。将不同的用户分成用户组，默认的就有 6 个组 TDAdmin，QATester，Project Manager, Developer, Viewer, Customer。拥有可定制的用户界面和访问权限，用户可以根据需求建立特殊的用户组。每一用户组，都拥有属于自己的权限设置。
（8）和其他工具的集成。TestDirector 可以与 LoadRunner、WinRunner 进行有效的集成，来统一管理测试用例、测试脚本、使用情景与测试结果，并且可以面向发生问题的部分进行错误跟踪，达到与开发部门实时交互。各种功能或负载测试工具的执行信息和结果都会被自动汇集传送到 TestDirector 的数据存储中心。
13.2 软件缺陷的描述¶
开发人员修正缺陷的阶段差不多占整个开发过程的一半时间，而在这个阶段，缺陷成了开发人员和测试人员之间的工作纽带，许多工作都是围绕缺陷展开，测试人员发现缺陷，开发人员修正缺陷，然后测试人员再验证缺陷。缺陷描述不清楚，会极大影响团队的工作效率，而准确有效地定义和描述软件缺陷，可以带来不少好处，例如:
(1) 清晰准确的软件缺陷描述可以减少软件缺陷从开发人员返回的数量。
(2) 提高软件缺陷修复的速度，使每一个小组能够有效地工作。
(3) 提高测试人员的信任度，可以得到开发人员对清晰的软件缺陷描述有效的响应。
(4) 加强开发人员、测试人员和管理人员的协同工作，让他们可以更好地工作。
13.2.1 软件缺陷的生命周期¶
生命周期的概念是一个物种从诞生到消亡经历了不同的生命阶段，软件缺陷生命周期指的是一个软件缺陷被发现、报告到这个缺陷被修复、验证直至最后关闭的完整过程。在整个软件缺陷生命周期中，通常是以改变软件缺陷的状态来体现不同的生命阶段。因此，对于一个软件测试人员来讲，需要关注软件缺陷在生命周期中的状态变化，来跟踪软件质量和项目进度。一个基本的软件缺陷生命周期，如图 13-4 所示，包含三个状态 ——“新打开的”、“已修正” 和 “已关闭”。
在实际工作中，软件缺陷的生命周期不可能像图 13-4 那么简单，需要考虑其他各种情况。图 13-5 给出了一个常
见的软件缺陷生命周期的例子，其中各个状态的说明见表 13-1。综上所述，软件缺陷在生命周期中经历了数次的审阅和状态变化，最终测试人员关闭软件缺陷来结束软件缺陷的生命周期。软件缺陷生命周期中的不同阶段是测试人员、开发人员和管理人员一起参与、协同测试的过程。软件缺陷一旦发现，便进入测试人员、开发人员、管理人员的严密监控之中，直至软件缺陷生命周期终结，这样既可保证在较短的时间内高效率地关闭所有的缺陷，缩短软件测试的进程，提高软件质量，同时减少了开发和维护成本。
表 13-1 软件缺陷状态列表
| 缺陷状态 | 描述 |
| 激活或打开(Active or Open) | 问题还没有解决,存在源代码中,确认“提交的缺陷”,等待处理,如新报的缺陷 |
| 已修正或修复(Fixed or Resolved) | 已被开发人员检查、修复过的缺陷,通过单元测试,认为已解决但还没有被测试人员验证 |
| 关闭或非激活(Close or Inactive) | 测试人员验证后,确认缺陷不存在之后的状态 |
| 重新打开 | 测试人员验证后,还依然存在的缺陷,等待开发人员进一步修复 |
| 推迟 | 这个软件缺陷可以在下一个版本中解决 |
| 保留 | 由于技术原因或第三者软件的缺陷,开发人员不能修复的缺陷 |
| 不能重现 | 开发不能复现这个软件缺陷,需要测试人员检查缺陷复现的步骤 |
| 需要更多信息 | 开发能复现这个软件缺陷,但开发人员需要一些信息,例如:缺陷的日志文件、图片等 |
13.2.2 严重性和优先级¶
软件缺陷对用户使用的影响是不一样的或所造成的后果是不同的。有些缺陷的影响比较小，如界面不美观、操作不够灵活等；而有些缺陷造成的影响很大，例如，造成用户数据丢失、导致重大经济损失。所以，可以通过设定严重性 (Severity) 的级别来衡量软件缺陷对客户满意度的影响程度。虽然软件公司对缺陷严重性级别的定义不尽相同，但大同小异，一般可以定义为以下 4 种级别。
当然，这种严重性级别的定义是相对的，例如，错别字出现在用户经常访问的地方，如站点首页、系统主界面或菜单等，软件缺陷是严重的。除了上述 4 个级别之外，还可以设置 “建议 (Suggestion)” 级别来处理测试人员提出对产品特性改进的各种建议或质疑，如建议操作菜单项的次序改进、按钮位置的改变等，以改善系统的适用性；或对设计不合理、不明白的地方提出质疑。
由于软件的严重性程度不一样，所以不是每个软件缺陷都需要开发人员修复。即使对严重性级别相同的缺陷，开发人员也不能一视同仁，需要区别对待。例如，某个缺陷使测试人员的工作不能继续下去，需要立即修正，而另外一个缺陷非常难，不急于修正。这就是说开发人员修复缺陷有先后次序，越急于修正的缺陷，其优先级越高，而不急于修正的缺陷，其优先级就比较低。所以缺陷具有优先级属性 —— 被修复的紧急程度，“优先级” 的衡量抓住了在严重性中没有考虑的重要程度因素，如表 13-2 所示。
表 13-2 软件缺陷优先级列表
| 缺陷优先级 | 描述 |
| 立即解决(P1级) | 缺陷导致系统几乎不能使用或测试不能继续,需立即修复 |
| 高优先级(P2级) | 缺陷严重,影响测试,需要优先考虑 |
| 正常排队(P3级) | 缺陷需要正常排队等待修复 |
| 低优先级(P4级) | 缺陷可以在开发人员有时间的时候被纠正 |
一般来讲，缺陷严重等级和缺陷优先级相关性很强，但是，具有低优先级和高严重性的错误是可能的，反之亦然。例如，产品徽标是重要的，一旦它丢失了，这种缺陷是用户界面的产品缺陷，但是它阻碍产品的形象，那么它是优先级很高的软件缺陷。
13.2.3 缺陷的其他属性¶
对于测试人员，利用软件缺陷属性可以跟踪软件缺陷，保证产品的质量。软件缺陷需要其他一些属性，包括缺陷标识 (ID)、缺陷类型 (Type)、缺陷产生可能性 (Frequency)、缺陷来源
(Source)、缺陷原因 (Root Cause) 等。
表 13-3 软件缺陷类型列表
| 缺陷类型 | 描述 |
| 功能 | 影响了各种系统功能、逻辑的缺陷 |
| 用户界面 | 影响了用户界面、人机交互特性,包括屏幕格式、用户输入灵活性、结果输出格式等方面的缺陷 |
| 文档 | 影响发布和维护,包括注释、用户手册、设计文档 |
| 软件包 | 由于软件配置库、变更管理或版本控制引起的错误 |
| 性能 | 不满足系统可测量的属性值,如执行时间、事务处理速率等 |
| 系统/模块接口 | 与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表等不匹配、冲突 |
(3) 可能性：指缺陷在产品中发生的可能性，通常可以用频率来表示，如表 13-4 所示。
表 13-4 软件缺陷产生可能性列表
| 缺陷产生可能性 | 描述 |
| 总是(Always) | 总是产生这个软件缺陷,其产生的频率是100% |
| 通常(Often) | 按照测试用例,通常情况下会产生这个软件缺陷,其产生的频率大概是80%~90% |
| 有时(Occasionally) | 按照测试用例,有的时候产生这个软件缺陷,其产生的频率大概是30%~50% |
| 很少(Rarely) | 按照测试用例,很少产生这个软件缺陷,其产生的频率大概是1%~5% |
(4) 来源：指缺陷所在的地方，如文档、代码等，如表 13-5 所示。
表 13-5 软件缺陷来源列表
| 缺陷来源 | 描述 |
| 需求说明书 | 需求说明书的错误或不清楚引起的问题 |
| 设计文档 | 设计文档描述不准确、和需求说明书不一致的问题 |
| 系统集成接口 | 系统各模块参数不匹配、开发组之间缺乏协调引起的缺陷 |
| 数据流(库) | 由于数据字典、数据库中的错误引起的缺陷 |
| 程序代码 | 纯粹在编码中的问题所引起的缺陷 |
（5）根源：指造成上述错误的根本因素，以寻求软件开发流程的改进、管理水平的提高，如表 13-6 所示。
表 13-6 软件缺陷根源列表
| 缺陷根源 | 描述 |
| 测试策略 | 错误的测试范围,误解了测试目标,超越测试能力等 |
| 过程,工具和方法 | 无效的需求收集过程,过时的风险管理过程,不适用的项目管理方法,没有估算规程,无效的变更控制过程等 |
| 团队/人 | 项目团队职责交叉,缺乏培训。没有经验的项目团队,缺乏士气和动机不纯等 |
| 缺乏组织和通信 | 缺乏用户参与,职责不明确,管理失败等 |
| 硬件 | 硬件配置不对、缺乏,或处理器缺陷导致算术精度丢失,内存溢出等 |
| 软件 | 软件设置不对、缺乏,或操作系统错误导致无法释放资源,工具软件的错误,编译器的错误,千年虫问题等 |
| 工作环境 | 组织机构调整,预算改变,工作环境恶劣,如噪声过大 |
13.2.4 完整的缺陷信息¶
任何一个缺陷跟踪系统的核心都是 “软件缺陷报告”，一份软件缺陷报告详细信息如表 13-7 所示。
表 13-7 软件缺陷信息列表
| 分类 | 项目 | 描述 |
| 可跟踪信息 | 缺陷ID | 唯一的、自动产生的缺陷ID,用于识别、跟踪、查询 |
| 软件缺陷基本信息 | 缺陷状态 | 可分为“打开或激活的”、“已修正”、“关闭”等 |
| 缺陷标题 | 描述缺陷的最主要信息 | |
| 缺陷的严重程度 | 一般分为“致命”、“严重”、“一般”、“较小”等4种程度 | |
| 缺陷的优先级 | 描述处理缺陷的紧急程度,1是优先级最高的等级,2是正常的,3是优先级最低的 | |
| 缺陷的产生频率 | 描述缺陷发生的可能性1%~100% | |
| 缺陷提交人 | 缺陷提交人的名字(会和邮件地址联系起来),一般就是发现缺陷的测试人员或其他人员 | |
| 缺陷提交时间 | 缺陷提交的时间 | |
| 缺陷所属项目/模块 | 缺陷所属的项目和模块,最好能较精确地定位至模块 | |
| 缺陷指定解决人 | 估计修复这个缺陷的开发人员,在缺陷状态下由开发组长指定相关的开发人员;也会自动和该开发人员的邮件地址联系起来,并自动发出邮件 | |
| 缺陷指定解决时间 | 开发管理员指定的开发人员修改此缺陷的时间 | |
| 缺陷验证人 | 验证缺陷是否真正被修复的测试人员;也会和邮件地址联系起来 | |
| 缺陷验证结果描述 | 对验证结果的描述(通过、不通过) | |
| 缺陷验证时间 | 对缺陷验证的时间 | |
| 缺陷的详细描述 | 步骤 | 对缺陷的操作过程,按照步骤一步一步地描述 |
| 期望的结果 | 按照设计规格说明书或用户需求,在上述步骤之后,所期望的结果,即正确的结果 | |
| 实际发生的结果 | 程序或系统实际发生的结果,即错误的结果 | |
| 测试环境说明 | 测试环境 | 对测试环境描述,包括操作系统、浏览器、网络带宽、通信协议等 |
| 必要的附件 | 图片、Log文件 | 对于某些文字很难表达清楚的缺陷,使用图片等附件是必要的;对于软件崩溃现象,需要使用Soft_ICE工具去捕捉日志文件作为附件提供给开发人员 |
软件缺陷的详细描述，如上所述，由三部分组成：操作 / 重现步骤、期望结果、实际结果，有必要再做进一步的讨论。
13.2.5 缺陷描述的基本要求¶
软件缺陷的描述是软件缺陷报告中测试人员对问题的陈述的一部分并且是软件缺陷报告的基础部分。同时，软件缺陷的描述也是测试人员就一个软件问题与开发小组交流的主要渠道，特别是对跨地区的软件开发团队。一个好的描述，需要使用简单的、准确的、专业的语言来抓住缺陷的本质；否则，它就会使信息含糊不清，可能会误导开发人员。以下是有效描述软件缺陷的规则。
13.2.6 缺陷报告示例¶
一份优秀的缺陷报告应记录下最少的重复步骤，不仅包括期望结果、实际结果和必要的数据、附件、测试环境或条件，以及简单的分析。下面是一个优秀的缺陷报告记录。
(1) 重现步骤：
① 打开一个编辑文字的软件并且创建一个新的文档 (这个文件可以录入文字);
② 在这个文件里随意录入一两行文字；
③ 选中一两行文字，通过选择 Font 菜单然后选择 Arial 字体格式；
④ 一两行文字变成了无意义的乱字符。
(2) 期望结果：当用户选择已录入的文字并改变文字格式的时候，文本应该显示正确的文字格式不会出现乱字符显示。
(3) 实际结果：它是字体格式的问题，如果改变文字格式成 Arial 之前，保存文件，缺陷不会出现。缺陷仅发生在 Windows 98 并且改变文字格式成其他的字体格式时，文字是显示正常的。
见所附的图片 (有一个链接，单击即可看到)
而一份含糊而不完整的缺陷报告，可能缺少重建步骤，或者没有期望结果、实际结果和必要的图片，如下描述。
重现步骤：
一份散漫的缺陷报告 (无关的重建步骤，以及对开发人员理解这个错误毫无帮助的结果信息) 如下描述:
重现步骤：
期望结果：当用户选择已录入的文字并改变文字格式的时候，文本应该显示正确的文字格式不会出现乱字符显示。
实际结果：我试着选择少量的不同的字体格式，但是只有 Arial 字体格式有软件缺陷，不论如何，它可能会出现在我没有测试的其他的字体格式。
以上给出了几个实例，编写软件缺陷报告的关键是遵循软件缺陷的有效描述规则和分离和再现软件缺陷的步骤，仔细做笔记，这样才能写出简明清晰的缺陷报告。测试人员还需注意应该刚完成测试之后写缺陷报告，写完报告后，应再检查一遍。
13.3 软件缺陷相关的信息¶
前面所叙述的软件缺陷属性，是其基本信息，为了更好地处理软件缺陷，需要了解还有哪些相关的信息。软件缺陷相关的信息包括软件缺陷的图片、记录信息和如何再现和分离软件缺陷。对于某一个软件缺陷报告，测试人员应该给予相关的信息，例如，捕捉到软件缺陷日志文件和图片，保证开发人员和其他测试人员可以分离和重现它。在这一节中重点介绍可以捕捉 Bug 的工具，给出在什么情况下需要添加图片文件和如何分离和再现软件缺陷的建议。
13.3.1 软件缺陷的图片信息¶
软件缺陷的图片、记录信息是软件缺陷报告中重要的组成部分，以下将介绍常用的捕捉软件缺陷的工具、如何使用这些工具、添加软件缺陷图片的作用和为什么要添加图片信息等。
一些涉及用户界面的软件缺陷很难用文字清楚地描述，因此软件测试人员通过附上图片比较直观地表示缺陷发生在产品界面什么位置、有什么问题等。
1. 采用图片的格式¶
测试人员一般采用 JPG、GIF 的图片格式，因为这类文件占用的空间小，打开的速度快。
2. 什么情况下需要附上图片¶
通常情况下，出现在用户界面并且影响用户使用或者影响产品的美观的软件缺陷，附上图片比较直观，例如:
测试人员需要注意，有必要在图片上用颜色标注缺陷的位置，令开发人员一目了然，使得软件缺陷尽快修复。
13.3.2 使用 WinDbg 记录软件缺陷信息¶
WinDbg (http://www.microsoft.com/whdc/devtools/debugging) 是微软公司发布的一款相当优秀的源码级调试工具，可以用于 Kernel 模式调试和用户模式调试，在调试软件崩溃后形成 Dump 文件，包括操作系统的信息、进程运行的状态、时间和环境变量、汇编指令、调用堆栈等，可以查出许多隐性的错误。
1. 配置 WinDbg¶
运行 File->Symbol File Path, 按照下面的方法设置 _NT_SYMBOL_PATH 变量:
即 WinDbg 将先从本地文件夹 C:\MyCodesSymbols 中查找 Symbol, 如果找不到，则自动从 MS 的 Symbol Server 上下载 Symbols。也可以下载完整的、正确版本的 Symbol 安装包并进行安装。最后，使用 lm、!sym noisy、!reload 等命令来验证符号路径是否正确。
2. 使用 WinDbg¶
WinDbg 提供了图形界面和命令行两种运行方式。使用图形界面的 WinDbg 来调试应用程序：
File->OpenExecutable: 可选择一个可执行文件进行调试；
File->Attache to a Process: 可选择一个运行中的进程，并对其进行调试；
File->Kernel Debu: 打开内核调试选择窗口，这时不能使用挂起系统的命令，但可以读写系统内存，可用于检测缺陷产生的原因.
可以建立命令行快捷方式：C:\WinDBG\windbg.exe -c".prompt_allow +dis -reg -ea-src -sym;.enable_unicode 1;.enable_long_status 1;.logopen/t c:\dbglog\dbglog.txt"。再在命令行窗口输入 “x” 加上可执行文件名加上 “!”、代码中的函数名，可以获得函数的入口地址，这样就可以方便地设置调试断点，如输入：
获得 getConstBuffer 的地址。输入 “bp” 加上函数入口地址就可以设置函数断点，如 “bp 004113c0”。也可以合成这两个命令：
使用 u 004113c0 和！address 004113c0 可查看更详细的信息。
3. 调试方式¶
1）远程调试¶
可以从机器 A 上调试在机器 B 上执行的程序。具体步骤如下。
(1) 在机器 B 上启动一个调试窗口 (Debug Session), 既可以直接在 WinDbg 下运行一个程序，也可以将 WinDbg 附加到一个进程上。
(2) 在机器 B 的 WinDbg 命令窗口上启动一个远程调试接口:
其中，PIPE_NAME 是该接口的名字。
(3) 在机器 A 上运行:
其中，SERVER_NAME 是机器 B 的名字。
2) Dump 文件调试¶
如果客户机出现问题，当不能使用远程调试来解决问题时，可以通过 WinDbg 附加到出现问题的进程上，然后在命令窗口中输入:
创建一个 Dump 文件。在得到 Dump 文件后，使用如下命令打开它：
3）本地进程调试¶
可以在 WinDbg 下直接运行一个程序：
也可以将 WinDbg 附加到一个正在运行的程序：
如果想控制一个进程及其子进程，在 WinDbg 的命令行上加上 “-o” 选项或使用命令 “.childdbg”。如果同时调试几个进程，可以使用 “|” 命令来显示并切换到不同的进程。在同一个进程中可能有多个线程，“\~” 命令可以用来显示和切换线程。
4. 常用命令¶
(1) 调出命令帮助信息：.hh keyword。
(2) 下载系统文件的符号: symchk c:\winnt\system32\ntoskrnl.exe/s。
(3) 设置源码路径：.lsrcpath。
(4) 查看 event 对象的信号状态：!object \BaseNamedObjects。
(5) 显示当前线程的上一个错误值和状态值：!gle。
(6) 指定进制形式，0x/0n/0t/0y 分别表示十六 / 十 / 八 / 二进制。
(7) 过滤命令窗口输出信息：.prompt_allow - reg + dis - ea - src - sym。
(8) 格式化命令：. formats @eax。
(9) 查看 eax 上的内存数据: dc eax。
(10) 查看相应内存页的属性：!address eax。
(11) 显示局部变量: dv (Ctrl+Alt+V 切换到更详细的显示模式)。
(12) 查看当前的调用堆栈： \(k^{*}\) 或 \(\sim^{*}kb\) 。
（13）异常处理相关，用 sx，sxd，sxe，sxi，sxn，sxr 等设置异常和事件的处理方式，如 sxe ld 可以在加载 dll 时中断下来。
(14) 内核调试时切换进程：!process 0 0 或 .process xxxxxxxx。
(15) 显示数据结构: dt, 如 dt PEB 会显示操作系统进程结构。
(16) 显示当前线程、进程的环境信息：!teb、!peb。
(17) 显示句柄信息：!handle。
(18) 显示与句柄有关的调用堆栈：!htrace-enable, 再输入！htrace_handle_value。
(19) 显示进程中加载的模块信息：lm。
(20) 查看对象类型: \(\ln\) 。
(21) 显示各线程的锁资源使用情况：!locks，对调试死锁很有用。
(22) 设置代码断点：bp/bu/bm；设置内存断点：ba；显示断点信息：bl。
13.3.3 使用 Soft-ICE 记录软件缺陷信息¶
Soft-ICE 是 Compuware 公司的产品 NuMega DriverStudio 中一个代表性的工具，用于跟踪软件运行时变量、内存等状态，而且可以捕捉系统崩溃时所需的信息。使用它可以记录产品发生缺陷的地方同时生成日志文件。在一般情况下，测试人员需要在软件缺陷报告上附上日志文件，便于开发人员修复软件缺陷。
当遭遇软件崩溃时，如何使用 Soft-ICE? 在开始测试之前，已经安装了 Soft-ICE 并启动了 “faults on” 命令。当软件发生崩溃现象时，可以使用下面的命令去捕捉必要的信息。
如果数据窗口是开启的状态，可以输入 “wd” 来关闭该窗口，然后再输入 “dd esp-20” 命令。stack、dd esp-20 是为了标注跟踪信息。
（1）通过输入 “x”，退出 Soft-ICE 窗口；如果还是无法退出 Soft-ICE，需要输入 “faults off”，然后输入 “x”。
(2) 打开 Soft-ICE 应用程序，立即保存日志文件。一旦再次打开 Soft-ICE, 请输入 “faults on”。
以下是一些常用命令。
当测试人员报告崩溃的软件缺陷的时候，如下几点很重要。
（1）任何造成软件崩溃的缺陷都需要附上 Soft-ICE 的跟踪 Log 文件，使开发人员能够分析这个缺陷的错误信息。
(2) 附上 Soft-ICE 的跟踪 Log 文件之后，重新打开检查 Log 文件信息是无误的。
（3）如果不能附上 Soft-ICE 的跟踪 Log 文件，应该说明为什么不能附上 Soft-ICE 的跟踪 Log 文件。
13.3.4 分离和再现软件缺陷¶
要想有效地分离软件缺陷，需要清楚、准确地描述产生软件缺陷的具体步骤和条件，根据缺陷的描述，一般可以再现软件缺陷。但在某些糟糕的情况下，再现一个软件缺陷并不容易，对条件、环境、技术等各方面要求都非常高，需要耐心地一遍遍操作，才能再现。
1. 分离和再现软件缺陷的步骤¶
为了有效地再现软件缺陷，除了按照软件缺陷的有效描述规则来描述软件缺陷，还要遵循软件缺陷分离和再现的方法，具有较高的技巧性。虽然有时少数几个缺陷很难再现或者根本无法再现，以下介绍分离和再现缺陷的一些常用方法和技巧。
开发人员有时可以根据相对简单的错误信息就能找出问题所在。因为开发人员熟悉代码，因此看到症状、测试用例步骤和分离问题的过程时，可能得到查找软件缺陷的线索。一个软件缺陷分离问题有时需要小组的共同努力。如果尽最大努力分离软件缺陷，也无法表达再现步骤，那么仍然需要记录软件缺陷，因为软件缺陷这个问题还是存在的。
2. 分离和调试软件缺陷之间的区别¶
讨论分离和调试软件缺陷之间的区别，是为了划清测试人员与开发人员的责任，增加界限的清晰度与测试资源的控制能力。面对一个软件缺陷时，开发人员或测试人员为了修复它，会提出一系列分步骤的、处理缺陷的疑问。
(3) 哪些外部因素引起软件缺陷？
(4) 哪些内部因素，是代码、网络、还是环境引起的软件缺陷？
(5) 怎样才能在不产生新的缺陷的条件下使这个软件缺陷得到修复？
(6) 这种修复是否经过调试？单元是否经过测试？
(7) 问题解决了吗？它是否通过了确认和回归测试，确定系统的其余部分仍工作正常？
第 (1) 步证明了一个软件缺陷不是一个意外，同时精练操作步骤。第 (2)、(3) 步分离了这个软件缺陷。第 (4)～(6) 步是调试任务。第 (7) 步涉及确认和回归测试。在整个过程中，缺陷从测试阶段 (第 (1)～(3) 步) 进入开发阶段 (第 (4)～(6) 步), 然后再回到测试阶段 (第 (7) 步)。虽然这个责任流程似乎简单而明显，但其边界不是很清晰 (特别是第 (3)、(4) 步之间的边界), 会产生一些资源重叠而浪费大量的精力。
如果软件缺陷描述清楚，包含第 (1)\~(3) 步中问题的答案，意味着在隔离与调试之间清楚地划上一条界限，测试人员就能专注于测试过程，而不受开发人员的影响。如果测试人员不能完全表现缺陷的特征，导致再现和错误种类的不确定性，因此无法将它分离，测试人员和开发人员就可能会陷入一起调试的过程中。实际上，测试人员在其职责范围内有许多其他的工作，而不应该被卷入调试工作中。开发人员询问测试人员是调试工作的一部分，这是开发人员的职责所在，而测试人员只要在软件缺陷描述的基础上回答问题就可以了。否则，在这个上面，测试人员可能会花费大量的时间去解答开发人员所提的问题。
13.4 软件缺陷跟踪和分析¶
软件缺陷被报出之后，接下来就是要对它进行处理和跟踪，包括软件缺陷生命周期、软件缺陷处理技巧、软件缺陷跟踪的方法和图表、软件缺陷跟踪系统。
软件缺陷跟踪管理是测试工作的一个重要部分，测试的目的是尽早发现软件系统中的缺陷，而对软件缺陷进行跟踪管理的目的是确保每个被发现的缺陷都能够及时得到处理。软件测试过程简单地说就是围绕缺陷进行的，缺陷跟踪管理的目标如下。
（1）确保每个被发现的缺陷都能够被解决，“解决” 的意思不一定是被修正，也可能是其他处理方式（例如，延迟到下一个版本中修正或标为 “已知问题”），总之，对每个被发现的缺陷的处理方式必须能够在开发组织中达到一致。
(2) 收集缺陷数据并根据缺陷趋势曲线识别测试过程的阶段；决定测试过程是否结束有
很多种方式，通过缺陷趋势曲线来确定测试过程是否结束是常用并且较为有效的一种方式。
(3) 收集缺陷数据并在其上进行数据分析，作为组织的过程财富。
上述的第一条容易受到重视，在谈到缺陷跟踪管理时，一般人都会马上想到这一条，然而对第二和第三条目标却很容易忽视。其实，缺陷数据的收集和分析是很重要的，可以为软件质量改善提供许多有价值的第一手数据，也是做好缺陷预防工作的基础。
13.4.1 软件缺陷处理技巧¶
管理员、测试人员和开发人员需要掌握在软件缺陷生命周期的不同阶段处理软件缺陷的技巧，从而尽快处理软件缺陷，缩短软件缺陷生命周期。以下列出处理软件缺陷基本技巧。
测试人员、开发人员和管理者要紧密地合作，掌握软件缺陷处理技巧，及时地审查、处理和跟踪每个软件缺陷，加速软件缺陷处理的节奏，不仅可以促进项目进展的速度，而且有助于提高软件质量。
13.4.2 缺陷趋势分析¶
软件质量标准一般要求：在测试结束前高优先级 (P1、P2) 的缺陷必须被全部处理完，所以有必要监控这类缺陷随时间的变化，例如，生成相应的趋势图，以判断整个产品开发是否按预期进度进行，测试是否可以按时结束。
在一个成熟的软件开发过程中，缺陷趋势会遵循着一种和预测比较接近的模式向前发展。在生命周期的初期，缺陷率增长很快。在达到顶峰后，就随时间以较慢的速率下降，如图 13-6 所示。可以根据这一趋势复审项目时间表，例如，4 个星期的测试周期，在第三个星期缺陷率仍然增长，则显示项目有问题，需要审视代码质量，找出问题的根本原因，必要时需要调整项目进度表。
实际测试过程中，可能出现一些波动现象，而且测试过程要经过单元测试、集成测试、功能测试、系统测试、验收测试等不同的阶段，其波动趋势会表现为周期性。
这种趋势分析还可以延伸到已修复的、已关闭的软件缺陷，用来评估开发团队所做出的努力。理想情况下，已修复的、已关闭的缺陷数和所发现的缺陷数发展趋势相同或相近，只有滞后效应。特别是对 P1、P2 优先级的缺陷，要及时被修复、关闭，这种关闭缺陷的速率应该维持在与打开缺陷的速率相同的水准上，滞后时间不宜超过三天，才能保证项目顺利进行。趋势图的数据采用缺陷累计数量比较好，曲线的趋势更稳定、更具有规律性，如图 13-7 所示。在项目开始时，发现更多的缺陷，新缺陷的速率快，关闭缺陷的速度也快，但随着时间推移，该速率不断降低，而且关闭的趋势与新缺陷的趋势相似，但滞后一周。当新发现的缺陷累积曲线在一条渐近水平线时，说明新发现的缺陷越来越少，产品质量逐渐稳定下来，通常意味着测试快结束了。在测试和修复的过程中，这些曲线在不断地收敛，当收敛非常接近时，开发人员基本上完成了修复软件缺陷的任务了。并且注意到关闭曲线紧跟在打开曲线的后面，这表明项目小组正在快速地推进问题的解决。
图 13-7 给出了一个理想的趋势图。实际情况并非如此，有些差异是自然的，但如果有显著差异，则可能表明存在问题 —— 如测试方法不对、测试能力不足、缺陷处理流程有问题或修复缺陷所需的资源不足等。
通过缺陷龄期、缺陷发现率等分析，可了解有关测试有效性和清除缺陷的状态。例如，如果存在大量龄期较长的、未验证的、已修正的缺陷，则可能表明没有充足的测试人员。微软公司就利用发现的缺陷数和关闭的缺陷数趋势图，找出缺陷的收敛点，来预测产品的下一个阶段计划，如图 13-8 所示。当出现没有激活状态缺陷的第一个时间，被定义为零 Bug 反弹点（Zero Bug Bounce, ZBB），从这一时刻开始，产品进入稳定期。
13.4.3 缺陷分布分析¶
对缺陷进行分析，确定测试是否达到结束的标准，也就是判定测试是否已达到用户可接受的状态。在评估缺陷时应遵照缺陷分析策略中制定的分析标准，最常用的缺陷分析方法有以下 4 种。
这些分析为软件质量、项目管理、开发过程改进等提供了判断依据。例如，预期缺陷发现率将随着测试进度和修复进度而最终减少，这样可以设定一个阈值，在缺陷发现率低于该阈值时才能部署该软件。
例如，在功能分布上缺陷分析，可以了解哪些功能模块处理比较难、哪些功能模块程序质量比较差，有利于程序质量的改进和提高。进一步分析，可以计算出 P1 优先级缺陷从报告到关闭所需要的平均时间，就可以知道开发人员是否按照要求去做，一般来说 P1 优先级缺陷规定必须在 24h 之内被解决。再比如，各个级别的缺陷数量一般遵守这样的规律：P1<P2<P3。
如果不符合正常缺陷分布，如图 13-9 所示，可能说明代码质量不好，需要进一步分析，找出其根本原因。
分析软件缺陷根本原因不仅有助于测试人员决定哪些功能领域需要增强测试，而且可以使开发人员的注意力集中到那些引起问题最严重，最频繁的领域。图 13-10 显示了软件缺陷产生的三个主要来源 —— 用户界面显示、业务逻辑和规格说明书，占软件缺陷总数的 \(75\%\) 。如果从测试风险角度看，这些区域可能是隐藏缺陷比较多的地方，需要测试更细、更深些。从开发角度来说，这些就是提高代码质量的主要区域，假定某个产品前后发现 1000 个 Bug，代码在这三个区域减少一半，则总缺陷数能减少 \(37.5\%\) ，减少 375 个缺陷，代码质量改善效果就会显著。
13.4.4 缺陷跟踪方法¶
缺陷数据是生成各种各样测试分析、质量控制图表的基础，从上述缺陷分析中可以清楚地了解缺陷的发现过程、修复过程以及各类缺陷的分布情况，从而能够有效地跟踪缺陷，改进测试过程，督促开发人员的工作进度，最终保证项目按时完成。
1. 当前缺陷状态¶
软件缺陷情况可以基本反映项目的状态，例如通过如表 13-8 所示软件缺陷列表可以反映项目的缺陷状态。
表 13-8 软件缺陷列表
| 级别 | 总数 | 未处理的 | 正在处理的 | 修正的 | 不是缺陷 | 重复的 | 暂不处理 | 关闭 |
| 致命的 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 2 |
| 严重的 | 216 | 18 | 7 | 5 | 1 | 4 | 20 | 161 |
| 一般的 | 31 | 23 | 1 | 0 | 0 | 0 | 0 | 7 |
| 微小的 | 5 | 2 | 0 | 0 | 0 | 3 | 0 | 0 |
2. 项目发展趋势¶
缺陷打开 / 关闭图表是最基本的缺陷分析图表，它能提供许多有关软件缺陷、项目进度、产品质量、开发人员的工作等信息。
管理者可以知道项目在哪一个时间点出现问题，同时协调开发和测试之间的关系，积极推动项目的发展，从而达到项目里程碑的要求，提高项目发布的质量。例如，从一个测试阶段到另一个测试阶段时，如果发现新发现的缺陷累积曲线有一个突起，这样的凸起就要引起我们的注意，可能说明开发人员修复软件缺陷时引入了较多的回归缺陷或者有些软件缺陷被遗漏到下一个阶段发现了。项目管理人员需要召开紧急会议分析当前项目情况，找到解决办法。
13.5 软件缺陷跟踪系统¶
一般来说，缺陷报告、跟踪和处理都会通过一个基于 Web 和数据库的缺陷管理系统来支持，而不能简单地通过字处理软件和表格处理软件 (如微软公司 Word、Excel 文档) 来处理。如果没有一套特定的系统来帮助管理缺陷，那么缺陷处理效率会很低。例如，不能自动发邮件通知相关人员，将来也无法进行有效的查询、数据统计分析等工作。如果采用特定的系统来管理缺陷，那么就会带来不少益处。例如:
所有缺陷的数据不仅要存储在共享数据库中，还要有相关的数据连接，如产品特性数据库、产品配置数据库、测试用例数据库等的集成。因为某个缺陷是和某个产品特性、某个软件版本、某个测试用例等相关联的，有必要建立起这些关联。同时为了提高缺陷处理的效率，还有和邮件服务器集成，通过邮件传递，测试和开发人员随时可以获得由系统自动发出有关缺陷状态变化的邮件。
简单的缺陷跟踪系统比较容易实现，可以自己开发，也就是用数据库来记录表 13-7 中各项缺陷信息，并提供一些基本的查询条件。但是，已经有不少现存的缺陷跟踪系统供我们选用，可以选用开源软件系统，也可以选用商业化软件产品，无须自己开发。
1. 开源的缺陷管理系统¶
2. 商业的缺陷跟踪系统¶
3. Mantis 缺陷管理工具的特点¶
Mantis (http://mantisbt.sourceforge.net/) 是一款基于 Web 的软件缺陷管理工具，配置和使用都很简单，其主要功能如图 13-11 所示。其功能特点如下。
小结¶
在软件测试项目的管理中，会遇到一系列的问题，如软件质量标准定义不准确、任务边界模糊、软件测试项目的变化控制和预警分析要求高、项目成员的责任心和稳定性对测试项目的质量有很大的影响等。因此，软件测试项目的执行与监控非常重要，工作更需要细致，做好沟通、各个环节的风险控制、流程跟踪等。
本章还讲解了缺陷报告和处理的规范过程，包括缺陷描述的基本信息和缺陷生命周期。除此之外，还介绍了如何正确、有效地描述软件缺陷，并借助像 WinDbg、Soft-ICE 等工具提供各种必要的信息，以及开发人员和测试人员如何协同工作，分离、跟踪和处理软件缺陷，以保证优先级高的缺陷能及时得到解决。
我们需要建立软件缺陷跟踪数据库或系统，收集各种软件缺陷的数据，进行趋势分析和分布性分析，了解测试的进度和产品质量状况，并找到软件开发过程中薄弱的环节，改进软件开发过程。