10.3文档、用例和缺陷管理

软件质量保证与测试第10章软件测试组织和管理SoftwareQualityAssuranceandTesting

10.3文档、用例和缺陷管理软件开发人员可以用开发的代码来体现他们所完成的工作量和工作价值。而软件测试人员如何来体现他们所完成的工作量和工作价值呢？例如，有的软件可能质量较好，对其进行了长时间大量的测试，但发现的问题并不多，难道我们的测试工作就白做了。当然不是，软件测试可以用文档来保存测试工作成果，体现测试工作量和工作价值，作为对软件进行评价的客观依据，并可用于测试复用，例如用在回归测试中以及类似的软件测试项目中等。软件测试文档的重要性软件测试文档是对要执行的软件测试及测试的结果进行描述、定义、规定和报告的任何书面或图示信息。它为测试项目的组织、规划和管理提供了一个规范化的架构。软件测试文档的概念主要的测试文档有：测试需求分析、测试计划书、测试设计书、测试用例说明、测试方案说明、测试规程说明、测试日志、测试执行记录、缺陷报告、测试总结报告等。主要的测试文档作为技术文档，各种软件测试文档都有其一定的撰写规范，例如，这是某知名IT企业的“集成测试方案”文档撰写要点。软件测试文档的撰写规范集成测试方案1 引言 2 术语、定义和缩略语3 概述（测试简介、通过准则、构件清单）4 测试内容 5 测试方法 6 测试任务 6.1 <XX接口>测试 6.2 <XX功能>测试 6.3 <XX性能>测试 6.4 <XXXXX>测试 7 其它说明 8 参考文献

一个软件测试项目，首先要做到各种测试文档都齐全规范，这是测试工作过程和工作成果的体现；其次对重要的测试文档要进行评审，以提高质量，只有通过评审后才投入实施，开始下一个环节，防止要重新返工；第三测试文档要长期保存，不仅用作对软件进行最终评价的支撑材料，还可用于测试复用，为后续的测试工作奠定基础，节约工作量。软件测试文档的管理

测试用例（TestCase）是为某个特定的目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或者测试是否满足某个特定需求。完整的测试用例是对一项特定的软件测试任务的详细描述，它可以体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并应形成文档。最简单的情况下，一个测试用例至少应当包括输入数据和预期结果两部分。测试用例的概念测试用例的设计、管理和优化

按照不同的测试方法和技术可以设计得到不同的测试用例，不同的测试员也会设计得到不同的测试用例。

为了便于对大量测试用例进行汇总、管理和分析，可以建立测试用例数据库。为了提高覆盖率并减少测试冗余，需要对测试用例进行分析和优化，补充需要的，删除冗余的。

测试用例的更新

测试用例还需要不断更新和完善。主要原因有三个：第一、在后续的测试过程中可能发现前面设计测试用例时考虑不周，需要补充完善；第二、在软件交付使用后反馈了软件缺陷，而这些软件缺陷在测试时并没有发现，需要补充针对这些缺陷的测试用例；第三、软件版本的更新及功能的新增等，要求测试用例也需要配套修改更新。测试用例的作用测试用例的作用体现在以下几个方面发现和跟踪软件缺陷如果软件中存在缺陷，那么设计的某一个测试用例执行时，就可能发现这一缺陷，并且只要这个缺陷没有被修改处理调，那么每次执行这个测试用例时就都能够发现这个缺陷，并可以通过这个测试用例跟踪这个缺陷，找到问题的源头。测试用例的作用更准确地反映软件的某一特性通过一组测试用例，或者说是一个测试用例集可以反映出软件的某一特性。例如通过一个安全测试用例集的执行，可以反映出一个软件在安全性方面的特性等。测试用例的作用全面地反映软件的性能和质量等通过执行精心设计的大量测试用例，能够对软件进行全面的测试和验证，并最终反映出软件的性能和质量，为软件的质量评价提供依据。测试用例的作用明确故障责任当软件执行出错，甚至是酿成事故时，通过测试用例可以找到错误，并分析明确问题出在什么地方，该由谁来承担责任。测试用例的评审

当大量的测试用例被设计出来后，为保证其质量，应对其进行评审，评审的要点有：是否覆盖到了测试需求上的所有功能点？用例编号是否和测试需求相对应？是否包含非功能性测试用例？测试设计是否包含了正面和反面的测试用例？测试用例是否明确了测试特性、步骤、执行条件和预期结果等？测试用例的评审测试用例是否具备可操作性？测试用例的优先级安排是否合理？是否已经删除了冗余的用例？测试用例是否简洁、复用性强？例如，可将重复度高的步骤或过程抽取出来，定义为可复用的标准化测试过程。缺陷管理

软件中的缺陷（Defect或Bug）是软件开发过程中的“副产品”。一个规模很大的软件，通过测试可能会发现成千上万的缺陷，对于这些缺陷，需要进行有效的管理，可以建立缺陷数据库，也有专门的缺陷管理工具软件可供使用。首先要对每一个缺陷进行记录，并有详细的缺陷描述。例如，缺陷记录一般应当包含的要点如表所示。可追踪信息缺陷ID缺陷ID唯一，可以根据该ID追踪缺陷。缺陷基本信息缺陷状态缺陷的状态，分为“待分配”、“待修正”、“待验证”、“待评审”、“关闭”。缺陷标题描述缺陷的标题。缺陷的严重程度描述缺陷的严重程度，一般分为“致命”、“严重”、“一般”、“建议”。缺陷的紧急程度描述缺陷的紧急程度，从1到4，1是优先级最高的等级，4是优先级最低的等级。缺陷类型界面缺陷、功能缺陷、安全性缺陷、接口缺陷、数据缺陷、性能缺陷等。缺陷提交人缺陷提交人的姓名和邮件地址。缺陷提交时间缺陷提交的时间。缺陷所属项目/模块缺陷所属的项目和模块，最好能精确到模块。缺陷指定解决人缺陷指定的解决人，在缺陷“提交”状态为空，或在缺陷“分发”状态下，由项目经理指定相关开发人员修改。缺陷指定解决时间项目经理指定的开发人员修改此缺陷的期限。缺陷处理人最终处理缺陷的处理人。缺陷处理结果描述对处理结果的描述，如果对代码做了修改，要求在此处体现出修改。缺陷处理时间缺陷处理的时间。缺陷验证人对被处理缺陷验证的验证人。缺陷验证结果描述对验证结果的描述（通过、不通过）。缺陷验证时间对缺陷验证的时间。缺陷详细描述对缺陷的详细描述；对缺陷描述的详细程度直接影响开发人员对缺陷的修改，描述应尽可能的详细。测试环境说明对测试环境的描述。必要的附件对于某些文字很难表达清楚的缺陷，使用图片等附件是必要的。缺陷记录和描述

对缺陷进行记录，除了要有缺陷ID、缺陷状态、缺陷标题、严重程度、紧急程度、缺陷类型、缺陷提交人、提交时间、所属项目/模块等基本信息之外。还要有缺陷详细描述、测试环境说明、甚至是必要的附件。缺陷管理

其次，要对缺陷进行统计和分析。如分析缺陷主要分布在哪些模块，因为发现缺陷越多的模块隐藏的缺陷可能也越多；分析缺陷产生的原因主要有哪些，以便后续改进；根据已知缺陷数据，基于数学模型分析预测隐含的缺陷等。

缺陷管理

第三，要跟踪缺陷的状态。缺陷的状态变化过程如图所示。缺陷被发现后，测试人员进行提交，然后分配到项目开发人员修改，开发人员完成修改并通过测试验证后缺陷关闭，有的缺陷开发人员可以不修改，陈述理由、采取一些弥补措施，通过评审也可以关闭。缺陷跟踪就是要确保每个被