1. 软件测试基础- 1.4测试过程

关键词

覆盖（coverage）、调试（debugging）、缺陷（defect）、错误（error）、失效（failure）、质量 （quality）、质量保证（qualityassurance）、根本原因（root cause）、测试分析（test analysis）、测试依据（test basis）、测试用例（test case）、测试结束（test completion）、测 试条件（test condition）、测试控制（test control）、测试数据（test data）、测试设计（test

design）、测试执行（test execution）、测试执行进度表（test execution schedule）、测试实施 （test implementation）、测试监督（test monitoring）、测试对象（test object）、测试目标 （test objective）、测试结果参照物（test oracle）、测试计划（test planning）、测试规程 （test procedure）、测试套件（test suite）、测试（testing）、测试件（testware）、可追traceability）、确认（validation）、验证（verification）

---

软件测试基础的学习目标

1.1 什么是测试？

FL-1.1.1 (K1) 识别典型的测试目标

FL-1.1.2 (K2) 区分测试与调试的不同

1.2 为什么需要测试？

FL-1.2.1 (K2) 给出为什么需要测试的例子

FL-1.2.2 (K2) 描述测试与质量保证之间的关系，举例说明测试是如何提高软件质量的

FL-1.2.3 (K2) 辨别错误、缺陷和失效

FL-1.2.4 (K2) 辨别引起缺陷的根本原因及其影响

1.3 七项测试的基本原则

FL-1.3.1 (K2) 解释测试的七项基本原则

1.4 测试过程

FL-1.4.1 (K2) 解释测试过程中的环境影响

FL-1.4.2 (K2) 描述测试过程中的测试活动和各自的任务

FL-1.4.3 (K2) 区分用于支持测试过程的工作产品

FL-1.4.4 (K2) 解释在测试依据和测试工作产品之间保持可追溯性的价值

1.5 测试的心理学

FL-1.5.1 (K1) 识别影响测试成功与否的心理因素

FL-1.5.2 (K2) 解释测试活动所需的思维方式和开发活动所需的思维方式之间的差异

---

1.4.测试过程

尽管没有统一的软件测试过程，但是有一些常见的测试活动，如果没有这些测试活动就不太可能实现既定的目标。这些测试活动就组成了一个测试过程。在任何给定的情况下，适当的、特定的软件测试过程取决于很多因素。

测试过程中涉及哪些测试活动，如何实施这些测试活动，以及何时开始这些测试活动，都可以在组织的测试策略中进行讨论。

1.4.1.周境中的测试过程

影响组织测试过程的周境因素包括，但不仅限于以下：

• 使用的软件开发生命周期模型及项目方法
• 考虑的测试级别和测试类型
• 产品风险和项目风险
• 业务领域
• 运行限制，包括但不仅限于：
  • 预算和资源
  • 时间
  • 复杂度
  • 合同和法规要求
• 组织方针和实践
• 所需的内部和外部标准

组织中测试过程的通用方面：

• 测试活动和测试任务
• 测试工作产品
• 测试依据和测试工作产品之间的可追溯性

如果测试依据（对于正在考虑的任何测试级别或类型）具有可度量的覆盖标准，那是非常有用的，覆盖标准可以有效地作为关键绩效指标（KPIs），推动显示软件测试目标实现的活动。

例如，对于移动应用程序，测试依据可能包括需求列表和支持的移动设备列表。每个需求都是测试依据的一个元素。每条需求是测试依据的一个元素。覆盖标准可能要求测试依据的每个元素至少有一个测试用例。执行测试时，这些测试的结果将告诉干系人是否实现了指定的需求，以及是否在受支持的设备上观察到了失效。

1.4.2.测试活动和测试任务

测试过程主要由以下主要的活动组所组成。

• 测试计划
• 测试监督与控制
• 测试分析
• 测试设计
• 测试实施
• 测试执行
• 测试结果
• 测试结束

每个活动组都是由多个活动构成，具体内容将在下面的小节中加以说明。每个活动组中的每个活动都可能由多个单独的任务组成，这些任务可能因项目或发布而不同。

此外，虽然这些活动组的许多活动在逻辑上看起来是顺序的，但它们通常是迭代实现的。例如，敏捷开发设计到软件设计、构建和测试的小迭代，这些迭代都是在持续计划的支持下连续进行的。所以，在敏捷开发的方法中，测试活动也是在迭代的、持续的基础上进行。即使在顺序开发中，活动的阶梯式逻辑顺序也会涉及重叠、组合、并发或省略，所以必须根据系统和项目的周境因素裁剪这些主要活动。

测试计划

测试计划包括的活动有定义测试目标以及在周境因素限制下达到测试目标的方法（例如，指定适合的测试技术和适当的测试任务，并制定满足截止期限的测试进度表）。根据测试监督与控制活动的反馈，可以重新审议测试计划。

测试监督与控制

测试监督包括使用测试计划中定义的测试监督度量，对实际进度与测试计划进行持续的比较。测试控制包括采取必要的措施来满足测试计划的目标（目标可能会随时间的变化有所更新）。测试监督与控制是通过评价出口准则来支持的，出口准则在一些软件生命周期中被称为"完成的定义"。例如，作为给定测试级别的一部分，对测试执行的出口准则评估可能包括：

• 根据指定的覆盖准则检查测试结果和日志。
• 根据测试结果和日志评估组件或系统的质量级别
• 确定是否需要做更多的测试（例如，如果原本旨在达到某个级别的产品风险覆盖率的测试失败了，则需要编写和执行额外的测试）

在测试进度报告中向干系人通报测试进度，包括偏离计划的情况和帮助决定结束测试的信息。

测试分析

在测试分析过程中，分析测试依据以识别可测试特性和定义相关的测试条件。换句话说，测试分析根据可测量的覆盖标准来确定“测试什么”。

测试分析主要包括以下活动：

⚫ 分析所考虑测试级别的测试依据，例如：

◼ 需求规格说明，如业务需求、功能需求、系统需求、用户故事、史诗、用例或类 似的工作产品，其中指定了所需的功能和非功能的组件或系统行为

◼ 设计和实现信息，如系统或软件架构图或文档、设计规格说明、调用流、模型图 (例如 UML 或实体关系图 ERD)、接口规格说明或类似的工作产品，其中指定了组 件或系统的结构

◼ 组件或系统本身的实现，包括代码、数据库元数据、查询和接口

◼ 风险分析报告，其考虑了到组件或系统的功能、非功能及结构问题

⚫ 评估测试依据和测试项，以识别各种类型的缺陷，例如:

◼ 歧义

◼ 遗漏

◼ 不一致

◼ 不准确

◼ 矛盾

◼ 多余的表述

⚫ 识别被测特性和特性集

⚫ 根据对测试依据的分析，并考虑到功能、非功能和结构特征、其他业务和技术因素以及风险级别，界定每个特征的测试条件并确定其优先次序

⚫ 在测试依据的每个元素与相关测试条件之间获取双向可追溯性

在测试分析过程中，使用黑盒测试技术、白盒测试技术、基于经验的测试技术 ，可以减少遗漏重要测试条件的可能性，并且能更精确和准确的定义测试条件。

在某些情况下，测试分析得到的测试条件，这些条件将作为测试章程中的测试目标。在某些 基于经验的测试中，测试章程是典型的工作产品。当这些测试目标可以追溯到 测试依据时，就可以测量基于经验的测试中实现的覆盖率。 在测试分析过程中识别缺陷是一个重要的潜在收益，特别是在没有使用其他评审过程和/或测 试过程与评审过程之间间隔很短的情况下。这样的测试分析活动不要仅验证需求是否一致、是否表达正确以及是否完整，还需验证需求是否正确满足客户、用户和其他干系人的需求。例如，行为驱动开发(BDD)和验收测试驱动开发(ATDD)等技术，它们都需要在编码之前，从用户故事和验收标准中生成测试条件和测试用例，同样要在用户故事和验收标准中验证、确认和发现缺陷。

测试设计

在测试设计时，将测试条件细化成概要测试用例、概要测试用例集和其他测试件。因此，测试分析回答了“测试什么？”的问题，而测试设计是回答了“如何测试？”的问题。

测试设计包括以下的主要活动:

⚫ 设计测试用例和测试用例集，并确定其优先级

⚫ 识别所需的测试数据以支持测试条件和测试用例

⚫ 设计测试环境并识别所需的基础设施和工具

⚫ 撷取测试依据、测试条件、测试用例和测试规程之间的双向追溯性

在测试设计过程中，将测试条件细化为测试用例和测试用例集，常常会涉及到使用测试技术。 与测试分析一样，测试设计也可能在测试依据中识别出相似类型的缺陷。与测试分析一样，测试设计过程中识别出缺陷也是其重要的潜在效益。

测试实施

在测试实施期间，创建和/或完成测试执行所需的测试件，包括将测试用例排序为测试规程。所以，测试设计回答了“如何测试”的问题，而测试实施则回答了“我们现在是否已经有了运行测试所需的一切条件?”

测试实施包括以下主要活动:

⚫ 开发并确定测试规程的优先级，如有可能，并创建自动化测试脚本

⚫ 根据测试规程和(如果有的话)自动测试脚本来创建测试套件。

⚫ 在测试执行进度表中，以促进有效测试执行的方式安排测试套件

⚫ 构建测试环境(包括可能的，测试工具、服务虚拟化、模拟器和其他基础设施项目)，并验证一切所需都已正确设置

⚫ 准备测试数据并确保在测试环境中正确地加载

⚫ 确认并更新测试依据、测试条件、测试用例、测试规程和测试套件之间的双向可追溯性

测试设计和测试实施任务通常是结合在一起的。

在探索性测试和其他基于经验的测试类型中，测试设计和实施可能作为测试执行的一部分得 到执行和记录。探索性测试可以基于测试章程(作为测试分析的一部分生成)，在探索性测试时直接进行设计和实施 。

测试执行

在测试执行期间，测试套件按照测试执行进度表运行。

测试执行包括以下主要活动:

⚫ 记录测试项或测试对象、测试工具及测试件的 ID 和版本

⚫ 手工或者使用测试执行工具执行测试

⚫ 将实际结果与预期结果进行比较

⚫ 分析异常现象以确定它们可能发生的原因(例如，出现失效可能是由于代码中的缺陷， 但也可能出现假阳性结果（误报）

⚫ 根据实际观察到的失效报告缺陷(参见第 5.6 节)

⚫ 记录测试执行的结果(例如通过、失败、阻塞)

⚫ 作为对异常现象采取行动的结果，或作为计划要测试的一部分(例如，执行修正后的测试、确认测试和/或回归测试) ，重复测试活动

⚫ 确认并更新测试依据、测试条件、测试用例、测试规程和测试结果之间的双向可追溯性

 

测试结束

测试结束活动从已完成的测试活动中收集数据，以强化经验、测试件，以及任何其他相关信息。测试结束活动出现在项目里程碑点，例如：当软件系统发布时、当测试项目完成（或取消）时、当敏捷项目的迭代完成时（例如作为回顾会议的一部分）、当测试级别完成时，或当维护版本完成时。

测试结束包括以下主要活动：

⚫ 检查是否所有的缺陷报告已关闭，为测试执行结束时仍未解决的缺陷，是否已创建需求变更或产品待办事项

⚫ 创建测试总结报告，并将信息传达给干系人

⚫ 最后确定并归档测试环境、测试数据、测试基础设施及其他相关测试件，以便以后重复使用

⚫ 将测试件移交给维护部门、其他项目团队和/或其他可以从使用测试件中获益的干系人

⚫ 从已完成的测试活动中，分析所获得的经验教训来确定以后迭代、版本和项目所需的变更

⚫ 使用收集到的信息来改进测试过程的成熟度

1.4.3. 测试工作产品

测试工作产品作为测试过程中的一部分被创建。正如不同的组织在实施测试过程的方式时存在明显差异一样，在测试过程中创建的工作产品的类型也存在明显差异，这些工作产品的组织和管理方式，以及这些工作产品的名称也都存在明显差异。本大纲遵循上述测试过程以及本大纲和ISTQB 术语表中描述的工作产品。ISO 标准(ISO/IEC/IEEE 29119-3)也可以作为测试工作产品的指南。

本节所描述的很多测试工作产品都是可以使用测试管理工具和缺陷管理工具来获取和管理的。

测试计划工作产品

测试计划的工作产品通常包括一个或多个测试计划。测试计划包括关于测试依据与其他测试工作产品之间可追溯性的相关信息(，以及测试监督与控制期间使用 的出口标准(或“完成的定义”)。

测试监督与控制工作产品

测试监督与控制的工作产品通常包括各种类型的测试报告，包括测试进度报告(持续和/或定期生成的)和测试总结报告(在各种已结束里程碑上生成的)。所有的测试报告都应该提供在截止日期前与测试受众相关的细节，包括一旦获得测试执行结果后的总结。测试监督与控制的工作产品还应该解决项目管理所关心的问题，例如任务完成度、资源的分配和使用，以及工作量。测试监督与控制，及在这些活动中创建的工作产品。

测试分析工作产品

 

测试分析工作产品包括已定义的和按优先级排序的测试条件，理想情况下每一个测试条件都可以双向追溯到它所覆盖的测试依据的特定元素。对于探索性测试，测试分析可能涉及到创建测试章程。测试分析还可能发现和报告在测试依据上的缺陷。

测试设计工作产品

测试设计生成测试用例和测试用例集，以覆盖测试分析中定义的测试条件。通常设计概要测试用例是一种很好的做法，概要测试用例里没有具体的输入数据和预期结果的值。这样的概要测试用例可以在使用不同具体数据的多个测试周期中重复使用，同时仍能够充分记录测试用例的范围。理想情况下，每个测试用例都可以双向追溯到其覆盖的测试条件。测试设计还需要设计和/或识别必要的测试数据、设计测试环境以及识别基础设施和工具，尽管记录的这些结果范围差别很大。测试分析中定义的测试条件可以在测试设计中进一步细化。

测试实施工作产品

测试实施工作产品包括:

⚫ 测试规程以及这些测试规程的顺序

⚫ 测试套件

⚫ 测试执行进度表

理想情况下，一旦测试实施活动完成，就可以基于测试用例和测试条件，通过测试规程和测试依据的特定元素之间的双向可追溯性，来证明测试计划中确定的覆盖率准则是否实现。 在某些情况下，测试实施涉及使用工具创建工作产品，例如服务虚拟化和自动化测试脚本。测试实施还可能需要创建和验证测试数据和测试环境。数据和/或环境验证结果的文档完整性可能会有很大差异。测试数据为测试用例的输入和预期结果指定具体的值。这些具体的值，以及使用具体值的明确指示，将概要测试用例转换为可执行的详细测试用例。当在测试对象的不同版本上执行时，相同的概要测试用例可能使用不同的测试数据。使用测试结果参照物来识别与具体的测试数据相关的明确的预期结果。在探索性测试中，可以在测试执行的过程中创建某些测试设计和测试实施的工作产品，尽管探索性测试文档化的范围(以及它们对测试依据中的特定元素的可追溯性)可能会差异很大。测试分析中定义的测试条件可以在测试实施中进一步细化。

测试执行工作产品

测试执行工作产品包括:

⚫ 记录各单个测试用例或测试规程状态的文档(例如准备运行、通过、失败、阻塞、故意跳过等)

⚫ 缺陷报告

⚫ 测试过程中包含测试项、测试对象、测试工具及测试件的文理想情况下，一旦完成了测试执行，可以通过与测试规程相关的双向可追溯性来确定和报告测试依据中每个元素的状态。例如，我们可以说哪些需求通过了所有计划的测试，哪些需求的测试败了，和/或有与该需求相关的缺陷，以及哪些需求的测试已经计划好了但在等待运行。这样就可以验证是否满足了覆盖标准，以及确认干系人是否可以理解这些测试结果报告。

测试结束工作产品

测试结束的工作产品包括测试总结报告、改进后续项目或迭代的行动项 (例如在敏捷回顾之 后)、变更请求或产品待办事项，以及最终的测试件。

 

1.4.4. 测试依据和测试工作产品之间的可追溯性

测试工作产品以及这些工作产品的名称差别很大。无论差异如何，为了实施有效的测试监督与控制，如上所述，在测试依据的每个元素和与该元素相关联的各种测试工作产品之间建立和维护整个测试过程的可追溯性是很重要的。除了评估测试的覆盖率外，良好的可追溯性支持：

⚫ 分析变更的影响

⚫ 测试的可审计

⚫ 符合 IT 管理标准

⚫ 提高测试进度报告和测试总结报告的易理解性，包括测试依据中元素的状态。（例如通过测试的需求、未通过测试的需求以及有待完成测试的需求）

⚫ 将测试的技术方面与干系人关联起来，使干系人能够理解

⚫ 根据业务目标，提供评估产品质量、过程能力和项目进展的相关信息

某些测试管理工具提供了与本节中描述的部分或全部测试工作产品相匹配的测试工作产品模型。有些组织建立了自己的管理系统来管理工作产品，并提供他们所需的可追溯性信息。