软件测试国际标准ISO/IEC/IEEE 29119-2（2021年第2版）：软件测试过程/流程
0 前言
GB/T 38634.2 是我国的一项国家标准，全称《系统与软件工程 软件测试 第2部分：测试过程》。它是 GB/T 38634 系列标准的一部分，因国标较旧，故进行了29119-2（2021年第2版）的翻译。
第二版取消并取代了经过技术修订的第一版（ISO/IEC/IEEE 29119-2:2013）。
与上一版相比，主要变化如下：
- 更新了测试设计和实施过程的定义（8.2）。在第一版中，该过程基于测试条件的使用。对该标准使用情况的反馈意见强调了用户对"测试条件"的理解及其用于推导测试用例的问题。第二版用"测试模型"取代了"测试条件"。附件 E 提供了这一变化的更多细节。
1 简介
本文档旨在定义软件测试的通用过程模型,任何组织在执行任何形式的软件测试时都可以使用该模型。它包括组织级、测试管理级、动态测试级的软件测试过程的描述,还提供了过程描述的信息图。本标准支持动态测试、功能性和非功能性测试、人工和自动化测试、脚本测试和非脚本测试等。本标准中定义的过程可与任何软件开发生存周期模型结合使用。本文提供的通用过程模板进行定义,并覆盖每个测试过程的目的、结果、活动、任务和信息项。
测试是软件开发中降低风险的关键方法。本部分遵循基于风险的测试方法。基于风险的测试是一种策划和管理测试的最佳实践方法,因为它允许对测试优先级进行排序,并聚焦于最重要的功能和质量属性。
本文档使用了组织和项目的传统概念，但有些组织，尤其是使用敏捷方法的组织，并不按项目组织开发；相反，他们以更持久的产品团队为基础进行产品开发。本文档的用户可以在适当的地方用"产品"代替"项目"。
本标准旨在为负责软件测试的人员提供在任何组织中管理和执行软件测试所需的信息。
2 范围
本文档规定了测试过程，可用于任何组织、项目或测试活动的治理、管理和实施软件测试。它包括定义软件测试过程的通用测试过程描述。此外，还提供了描述过程的辅助信息图。
本文档适用于所有软件开发生命周期模型中的测试。
本文档面向但不限于测试人员、测试经理、开发人员和项目经理，特别是负责治理、管理和实施软件测试的人员。
3 术语和定义
参见：https://mp.weixin.qq.com/s/ppU9GlIa85t6MgztMirsRQ
4 一致性
4.1 预期用途
4.1.1 概述
本文件的要求包含在第 4、6、7 和 8 条中。本文件对软件系统或产品生命周期中适用的一系列测试过程提出了要求。
或产品的生命周期中使用。我们认识到，特定的项目或组织可能不需要使用本文档提供的所有过程。因此，实施本文档通常需要选择和声明一套适合组织或项目的过程。声称实施符合本文档规定的方式有两种--完全符合和量身定制的符合。
组织应声明是完全符合还是有针对性地符合本文档：
声称完全符合有两个标准。达到其中任何一个标准都足以构成完全符合，但应在声明中说明所选择的标准（或标准）。声称 "完全符合任务"，即声明流程集的所有活动和任务要求都已实现。或者，声称 "完全符合结果"，则表明所申报的一套流程的所有要求结果都已实现。完全符合结果 "允许在实施符合要求的流程时有更大的自由度，这对于实施创新生命周期模型中使用的流程非常有用。
注 1 本文件提供了符合性选项，以便在应用本文件时获得所需的灵活性。每个流程都有一组目标（表述为 "结果"）和一组活动和任务，它们代表了实现目标的一种方法。
注 2 实施了所申报的流程集的活动和任务的用户，可以断言完全符合所选流程的任务。然而，有些用户可以有创新的流程变体，在不实施所有活动和任务的情况下实现所申报流程集的目标（即结果）。这些用户可以宣称完全符合所申报流程的结果。这两个标准--符合任务和符合结果--不一定等同，因为在某些情况下，活动和任务的具体实施可能需要更高水平的能力，而不仅仅是实现结果。
注 3 当本文件用于帮助制定采购方和供应商之间的协议时，可以选择或不选择本文件中的条款进行修改后纳入协议。在这种情况下，收购方和供应商声称遵守协议比遵守本文件更合适。
注 4 作为贸易条件，实施本文件的组织（如国家、行业协会、公司）可以规定并公布一套最低要求的过程、结果、活动和任务，这套过程、结果、活动和任务构成供应商对贸易条件的遵守。
注 5 本文件的要求用动词 "应 "表示。建议用动词 "应 "标示。使用动词 "可 "表示允许。然而，尽管使用了动词，一致性要求的选择如前所述。
同时执行脚本测试和探索性测试的组织和项目会发现，在执行探索性测试时，很难满足某些流程（如测试设计和实施）的所有要求。在这种情况下，如果脚本测试满足了流程的所有要求，组织或项目就可以声称脚本测试完全 符合要求（即允许测试人员执行额外的非正式测试，但这些测试不符合本文档定义的全部要求）。
否则，如果组织的测试不符合特定条款的要求，则可根据 4.1.3 要求定制符合性。
4.1.2 完全符合
4.1.2.1 完全符合结果
完全符合的要求声明了要求符合的过程集。要做到完全符合结果，就必须证明所声明的过程集的所有结果都已实现。在这种情况下，无论规定中使用的动词形式如何，对所声明的过程集的活动和任务的规定都是指导而不是要求。本文件的一个预期用途是促进过程评估和改进。
为此，每个过程的目标都以符合 ISO/IEC 33002 规定的 "结果 "形式编写。ISO/IEC 33002 规定对本文件中的过程进行评估，为改进工作提供依据。打算进行过程评估和改进的用户
4.1.2.2 完全符合任务
完全符合的要求声明了要求符合的过程集。要实现与任务的完全一致，必须证明所声明的过程集的所有活动和任务要求都已实现。在这种情况下，无论规定中使用的动词形式如何，对所声明的过程集结果的规定都是指导而不是要求。
注：在收购方或监管方要求详细了解供应商流程的合同情况下，可适当提出完全 符合任务的要求。
4.1.3 量身定制的符合性
当本文件被用作确定一组不符合完全符合性条件的过程的依据时，要记录要求量身定制的符合性的过程子集。要实现量身定制的符合性，必须证明所记录的流程子集已满足所有要求（即 "应 "声明）。
在进行裁剪时，只要未遵循条款 6 至 8 中定义的流程，就必须提供理由（直接或通过引用）。所有调整决定均应记录其理由，包括对任何适用风险的考虑。调整决定应得到相关利益攸关方的同意。
示例：如果组织遵循 ISO 15489-1 或 ISO 9001 等标准中的信息项目管理流程，或使用类似的内部组织流程，则可决定使用这些流程代替本文档中定义的信息项目管理任务。
5 多层测试过程模型
本文档将软件系统生命周期中可能进行的测试活动分为三个流程组。这些流程组中的每个流程都按其目的和预期结果进行了描述，并列出了需要执行的活动和任务。
- 组织测试过程
- 确定创建和维护组织测试规范的流程，如组织测试方针、实践、过程、和其规程他资产。
- 测试管理过程
- 界定涵盖整个项目或项目中任何测试级别（如系统测试）或测试类型（如性能测试）的测试管理过程（如项目测试管理、系统测试管理、性能测试管理）。
- 测试管理流程包括：测试策略和规划过程；测试监测和控制过程；测试完成过程。
- 动态测试过程
- 确定进行动态测试的通用过程。动态测试可在特定测试级别（如单元测试、集成测试、系统测试和验收测试）或项目中的特定测试类型（如性能测试、安全测试和功能测试）进行。
- 动态测试过程包括：测试设计和实施过程；测试环境和数据管理过程；测试执行过程‘’测试事件报告过程（8.5）。
6 组织测试过程
6.1 概述
组织测试过程用于制定和管理组织测试规范。这些规范通常适用于整个组织的测试（即不以项目为基础）。组织测试方针和组织测试实践就是组织测试规范的例子。组织测试过程是通用的，可用于开发和管理其他非项目特定的测试文件，如适用于多个相关项目的计划测试策略。
组织测试方针是一份执行层面的文件，描述了组织内测试的目的、目标和总体范围。它还规定了组织测试实践，并为建立、审查和不断改进组织测试方针、测试实践和项目测试管理方法提供了框架。
组织测试实践是一份详细的技术性文件，规定了如何在组织内进行测试。它是一份通用文件，为组织内的多个项目提供指导，并不针对具体项目。
下图展示了组织测试过程的典型应用情况，它被用来创建和维护组织的测试政策和测试策略。组织过程的两个实例相互沟通。组织测试实践文档需要与组织测试方针保持一致，并将这一活动的反馈信息反馈给测试政策，以便进行可能的流程改进。同样，组织内每个项目使用的测试管理流程也需要与组织测试实践文件（和测试政策）保持一致。这些项目管理人员的反馈意见将用于改进组织测试流程，以制定和维护组织测试规范。
6.2 组织测试过程
6.2.1 概述
组织测试过程包括创建、审核和维护组织测试规范的活动。它还包括监督组织是否遵守这些规范。
该过程的典型输入包括
- 主要利益相关者的意见；
- 对组织内当前测试实践的了解；
- 组织的任务说明；
- IT方针；
- IT 项目管理方针；
- 质量方针；
- 组织测试方针；
- 组织测试实践；
- 测试方针反馈；
- 对测试实践的反馈；
- 行业和/或政府标准。
6.2.2 目的
组织测试过程的目的是开发、监控和维护组织测试规范，如组织测试方针和组织测试实践。
6.2.3 成果
成功实施组织测试流程的结果：
a) 确定组织测试规范的要求。
b) 制定组织测试规范。
c)组织测试规范得到利益相关者的同意。
d) 组织测试规格可供查阅。
e) 监督与组织测试规范的一致性。
f)组织测试规范的更新得到利益相关者的同意。
g) 更新组织测试规范。
6.2.4 活动和任务
6.2.4.1 总则
负责组织测试规范的人员，根据组织测试过程的相关组织政策和程序，实施6.2.4.2～6.2.4.4中规定的活动和任务。
6.2.4.2 制定组织测试规范(OT1)
本活动包括以下任务：
a) 组织测试规范的要求应从组织内的当前测试实践、利益相关者和（或）其它方法中确定。
注：可通过分析相关源文件、研讨会、访谈或其它适当方式来实现。
b) 组织测试规范要求应用于创建组织测试规范。
c)组织测试规范的内容应获得利益相关者的批准。
d) 组织测试规范的可用性应传达给组织内的利益相关者。
6.2.4.3 对组织测试规范的使用进行监控（OT2）。
该活动包括以下任务：
a) 监控组织测试规范的使用情况，以确定其是否在组织内得到有效使用。
b) 采取适当的措施，鼓励利益相关者与组织测试规范保持一致。
6.2.4.4 更新组织测试规范（OT3）
本活动包括以下任务：
a) 对组织测试规范的使用反馈进行审核。
b) 应考虑组织测试规范的使用和管理的有效性，并确定和批准为提高其有效性而进行的任何反馈和更改。
注：可通过研讨会、访谈和其它适当方式，对反馈意见进行审核。
c)如果组织测试规范的更改已确定并获得批准，则应实施这些更改。
d) 组织测试规范的所有更改，应在整个组织内传达，包括所有利益相关者。
6.2.5 信息项
执行此过程后，应产生以下信息项：组织测试规范。
示例 组织测试方针、组织测试实践文件。
参考资料
- 软件测试精品书籍文档下载持续更新 https://github.com/china-testing/python-testing-examples 请点赞，谢谢！
- 本文涉及的python测试开发库 谢谢点赞！ https://github.com/china-testing/python_cn_resouce
- python精品书籍下载 https://github.com/china-testing/python_cn_resouce/blob/main/python_good_books.md
- Linux精品书籍下载 https://www.cnblogs.com/testing-/p/17438558.html
- 如需英文原版可联系微信pythontesting
- 软件测试开发产品项目管理QA等标准 https://github.com/china-testing/python-testing-examples/blob/master/std.md
- 累计几万人的软测测试群，联系钉ding或微信 pythontesting，注明：软件测试
7 测试管理过程
7.1 概述
有三个测试管理过程：
a) 测试策略和计划；
b) 测试监控；
c) 测试完成。
这些通用测试管理过程可应用于项目级别（项目测试管理）、不同测试级别的测试管理（如系统测试管理、验收测试管理）
以及管理各种测试类型（如性能测试管理、可用性测试管理）。
当应用到项目测试管理层面时，这些测试管理过程将用于根据项目测试计划管理整个项目的测试。对于许多项目来说，每个测试级别和类型都需要单独应用测试管理过程进行管理；这些过程通常基于单独的测试计划，如系统测试计划、可靠性测试计划和验收测试计划。
下图说明了三个测试管理过程之间的关系，以及它们如何与组织测试过程、测试管理流过程的其他应用（例如，在大型项目中，如果有一个高层次的测试管理过程，则测试管理过程应与组织测试过程、测试管理过程的其他应用相互影响）相互影响。
例如，在大型项目中，高层测试管理过程适用于针对测试级别或测试类型的低层测试管理过程）和动态测试过程。
测试管理过程需要与组织测试过程的输出相一致，如组织测试方针和组织测试实践文件。根据这些输出的实际执行情况，测试管理流程可对组织测试流程产生反馈。
7.2 测试策略和计划过程
7.2.1 概述
测试策略和计划过程用于明确测试的目的、范围、风险、典型测试活动和所需资源。测试策略和测试计划的设计结果，可记录在项目测试计划或特定级别的测试计划（如系统测试计划）中，也可记录在特定类型的测试计划（如性能测试计划）中。
这一流程的典型输入包括
- 组织测试方针
- 组织测试实践
- 监管标准；
- 项目测试计划（如果计划对项目中的特定阶段或类型进行测试）；
- 事故报告；
- 项目管理计划；
- 适用的产品文档（如系统要求、测试项目规范）；
- 软件开发计划；
- 项目和产品风险；
- 测试计划更新。
要创建测试计划，必须执行下图所示的活动。通过开展定义的活动，测试计划的内容就会出现，测试计划草案就会逐步完善，直到完整的测试计划被记录下来。由于流程的迭代性质，在制定完整的测试计划之前，可能需要重新检查一些活动。最典型的活动是 TP3、TP4、TP5 和 TP6，这些活动需要反复进行，以获得可接受的测试计划。
ISO/IEC/IEEE 29119（所有部分）建议在测试计划中嵌入测试策略，但本文件并不要求这样做。通过设计测试策略，然后考虑测试计划要素（如可用资源），可使最佳测试策略与可用的测试预算、时间表和资源相平衡。测试策略以感知风险为基础，通过活动 TP4 和 TP5 对风险进行明确管理。
注 1：ISO/IEC/IEEE 16085 提供了一套更详细的风险管理活动和任务。该风险管理流程与 ISO 31000 保持一致。
注 2 本文件上一版使用了 "风险缓解 "一词来处理风险。在本版中，使用了风险处理一词，以包括风险缓解和其他处理风险的手段，并与 ISO/IEC/IEEE 16085 和 ISO 31000 中的术语保持一致。
注：该过程显示为纯粹的顺序过程，但在实践中可以迭代进行，对某些活动进行重新审查。
在测试过程中，测试计划可能需要根据实施计划的结果和获得的新信息进行修改。根据修改的规模和性质，需要重新审视各种活动，以维持测试计划。
例如，如果在最初制定测试计划后，发现新的风险威胁到项目或可交付产品，或现有风险的威胁已发生变化，则应在识别和分析风险活动（TP3）时重新进入流程。
或者，如果认为有必要出于风险以外的原因改变测试策略（如使用不同的测试环境），则应在设计测试策略活动（TP5）时重新进入流程。
或者，如果认为有必要因风险以外的原因改变测试的人员配备或时间安排（如开发中测试项目的可用性发生了变化），则应在确定人员配备和时间安排活动（TP6）中重新进入流程。
7.2.2 目的
测试策略和计划流程的目的，是制定、商定、记录并向相关利益方传达测试的范围和方法，以便及早确定测试的资源、环境和其他要求。
7.2.3 结果
成功实施测试计划过程的结果：
a) 分析并理解测试的范围。
b) 确定并告知参与设计测试策略和测试计划的利益相关者。
c)对可通过测试处理的风险进行识别、分析和分类，并商定风险暴露程度。
d) 确定测试战略、测试环境、测试工具和测试数据需求。比如：工具、专用设备、测试环境、办公空间。
e) 确定人员配备和培训需求。
f) 安排每项活动。
g) 计算估算并记录证明估算合理的证据。比如成本、人员和时间表估算。
h) 商定测试计划并分发给所有利益相关者。
7.2.4 活动和任务
7.2.4.1 概述
负责设计测试策略和测试计划的人员将根据测试策略和计划过程的适用组织方针和过程，实施 7.2.4.2 至 7.2.4.10 中规定的活动和任务。
7.2.4.2 了解背景（TP1）
该活动包括以下任务：
a) 应了解软件测试的背景和范围，以支持测试计划的准备。
注 1 软件测试的范围包括确定测试项目。
注 2 可使用以下文档：
- 组织测试规范，如组织测试方针和组织测试实践；
- 项目管理计划，包括影响测试的信息，如分配的测试预算和资源；
- 更高层次的测试计划（如管理较低层次的测试，如系统测试，则为项目测试计划）， 以了解对该层次测试的要求和限制，如测试估算、人员配备和预期交付成果及其 时间安排；
- 适用的监管标准，了解可能影响测试的监管信息；
- 适用的产品文档，如系统要求规格、系统质量特性描述的质量目标和测试项目规格，以获取与该级别或类型测试的可能测试要求有关的信息；
- ISO/IEC 25010 中定义的质量特性；
- 软件开发计划，了解可能影响测试时间表或周期的信息，如预期开发成果及其时间安排；
- 项目风险登记册，了解已确定的项目和产品风险信息；
- 验证和确认计划。
b) 应通过确定相关利益方并与之互动，了解其背景和软件测试要求。
c)应确定并记录测试依据。
d) 应启动沟通计划，并记录沟通渠道。
注 3 在项目的整个生命周期中，将持续开展 "了解背景 "活动。原则上，该活动中的任务可按任何顺序执行。
7.2.4.3 组织制定测试计划（TP2）
这项活动包括以下任务：
a) 根据在 "了解背景 "活动（TP1）中确定的测试要求，确定并安排完成测试设计和测试计划所需的活动。
b) 应确定参与这些活动所需的利益相关者。
c)应获得相关利益方对活动、时间表和参与者的批准。比如：项目经理和/或项目测试经理。
注 这可能需要重复任务 a) 和 b)。
d) 组织利益相关者参与。比如：要求项目经理安排会议，对测试策略进行审核。
7.2.4.4 识别和分析风险（TP3）
该活动包括以下任务：
a) 应审查先前已确定的任何风险，以确定与软件测试有关的风险和/或可通过软件测试处理的风险。比如：项目风险登记册中的风险。
b) 应识别与软件测试相关和/或可通过软件测试处理的其他风险。任何已识别的与软件测试无关的风险，应告知相关利益者。注：这可通过审查产品规格和其它适当的文档、研讨会、访谈或其它适当的方式来实现。
c)应使用适当的分类方案对风险进行分类，至少应区分项目风险和产品风险。
d) 每项风险都应分配一个风险等级（如考虑其影响和可能性）。
e) 风险评估结果应得到利益相关者的批准。
f)应记录风险评估的结果。比如：在测试计划中，在项目风险登记册中。
7.2.4.5 确定风险处理方法（TP4）
该活动包括以下任务：
a) 根据风险类型、分类和风险暴露程度，确定适当的风险处理方法。注：适当的手段可包括测试级别、测试类型、测试设计技术、测试完成标准等。实践者可考虑 ISO/IEC/IEEE 15026-1 或 IEEE 1012 中涉及的软件关键性概念。在已知测试限制（如时间和成本）的情况下，对风险暴露程度低、预计在这些限制条件下无法处理的风险的处理方法，将因此被确定为超出范围。
b) 已确定的风险处理方法应记录在案。比如：在测试计划中，在项目风险登记册中。
7.2.4.6 设计测试策略（TP5）
这项活动包括以下任务：
a) 设计测试战略时，应考虑测试基础、风险以及组织、项目和产品限制。
注1：这需要考虑风险评估的结果，以确定测试活动的优先次序，并确定执行行动所需的资源（如时间、成本、技能、工具支持和环境需求），同时满足组织、项目和产品的限制，如
- 监管标准；
- 组织测试方针和组织测试实践的要求；
- 更高层次的项目测试计划和策略；
- 合同要求；
- 是否有具备适当技能的测试人员；
- 工具和环境的可用性。
如果无法设计出既能满足组织测试实践的所有要求，又能处理所有已识别风险的建议，同时还能满足项目和产品限制的测试策略，那么就需要做出判断，以制定出最能满足这些相互冲突要求的测试策略。如何实现这种折中取决于项目和组织。这可能需要放宽限制条件，确定风险处理方法活动（TP4），并重复这一任务，直到达成可接受的测试策略。在决定偏离组织测试实践时，应在测试战略中记录下来。
注2 ：试策略的格式已在 ISO/IEC/IEEE 29119-3 中定义。它包括测试级别、测试类型、测试内容、测试设计技术、测试完成标准、暂停和恢复标准。
注3：测试策略通常包括静态测试（如审查、检查、静态分析）和动态测试。
b) 应确定实施测试策略所需的活动。
c)应确定用于测试监控的指标（见活动 TMC1 至 TMC4）。
d) 应确定测试数据要求。比如：确定测试数据要求时应考虑的因素包括数据保密规定（可能需要数据屏蔽或加密）、所需数据量和完成后的数据清理。
e) 应确定测试环境要求和测试工具要求。
f)应确定测试交付品，并记录其正式程度和沟通频率。
g) 对实施测试策略的全套活动所需的资源进行初步估算。注：在此步骤中产生的初步测试估算将在记录测试计划活动（TP7）中最终确定。
h) 应记录测试策略。注：测试策略通常是测试计划的一个部分，但在某些情况下也可作为单独的文件记录。
i) 测试策略应获得利益相关者的批准。注：这可能需要重复本活动中先前的任务。
7.2.4.7 确定人员配备和日程安排（TP6）
这项活动包括以下任务：
a) 应确定执行测试策略中描述的测试所需的员工角色和技能。注：这可能需要确定人员招聘和/或培训需求。
b) 测试战略中的每项测试活动应根据估计、依赖性和人员可用性来安排。
c)人员配备和时间安排应得到相关利益方的批准。注：这可能需要重复任务 a) 和 b)，如果测试策略需要修改，则需要重新考虑设计测试策略活动（TP5）。
7.2.4.8 记录测试计划（TP7）
该活动包括以下任务：
a) 应根据设计测试策略活动（TP5）中设计的测试策略，以及确定人员配备和时间安排活动（TP6）中商定的人员配备和时间安排，计算测试的最终估算。
注：如果与之前的初步估计有分歧，则有必要重新进行确定人员和时间安排（TP6）和/或设计测试策略（TP5）活动。
b) 在设计测试策略活动（TP5）中确定的测试策略、在确定人员配备和时间安排活动（TP6）中商定的人员配备情况和时间安排，以及在前一项任务中计算的最终估计值，都应纳入测试计划。
7.2.4.9 就测试计划达成共识（TP8）
该活动包括以下任务：
a) 收集利益相关者对测试计划的意见。注：可通过研讨会、访谈或其它合适的方式来实现。
b) 解决测试计划与利益相关者意见之间的冲突。
c)测试计划应根据利益相关者的反馈进行更新。注：这可能需要重复测试中的早期活动。
d) 获得相关利益者对测试计划的批准。比如：相关人员可包括项目经理、项目负责人或其他指定人员。注：这可能需要重复任务 a) 至 c)。
7.2.4.10 沟通测试计划并提供（TP9）
该活动包括以下任务：
a) 提供测试计划。
b) 向利益相关者传达测试计划的可用性。
7.2.5 信息项
执行此过程后，应产生以下信息项：测试计划。
测试监控过程
7.3.1 概述
如图 7 所示，测试监控流程检查测试是否按照测试计划和组织测试规范（如组织测试方针和组织测试实践）进行。如果测试进度、计划活动或测试计划的其他方面与计划进度、计划活动或测试计划的其他方面有重大偏差，就会启动相关活动来纠正或弥补由此造成的偏差。
该流程的典型输入包括
- 组织测试方针
- 组织测试实践
- 监管标准；
- 项目测试计划（如果计划对项目中的特定阶段或类型进行测试）；
- 事故报告；
- 项目管理计划；
- 适用的产品文档（如系统要求、测试项目规范）；
- 软件开发计划；
- 项目和产品风险；以及
- 测试计划更新。
该过程可用于整个项目（通常由多个测试级别和测试类型组成）的管理，也可用于单个测试级别（如系统测试）或测试类型（如性能测试）的测试管理。在后一种情况下，它是动态测试流程所描述的动态测试监控的一部分。当作为监测和控制在后一种情况下，它将作为动态测试流程所描述的动态测试监控的一部分。
注：该显示为纯粹的顺序过程，但在实践中，它可以迭代进行，对某些活动进行重新审阅。
7.3.2 目的
测试监控过程的目的是确定测试是否按照测试计划和组织测试规范（如组织测试方针和组织测试实践）进行。它还在必要时启动控制行动，并确定对测试计划的必要更新（如修改完成标准或确定新的行动以弥补测试计划的偏差）。
该过程还用于确定测试进度是否符合更高层次的测试计划（如项目测试计划），并管理在特定测试级别（如系统测试）或特定测试类型中执行的测试。
系统测试）或特定测试类型（如性能测试）的测试。
7.3.3 成果
成功实施测试监控流程的结果：
a) 制定了收集适当措施的方法，以监控测试进展和不断变化的风险。
b) 对测试计划的进展情况进行监控。
c)确定、分析新的和变化的与测试有关的风险，并采取必要的行动。
d) 确定必要的控制措施。
e) 将必要的控制措施传达给相关利益方。
f)批准停止测试的决定。
g) 向利益相关者报告测试进展和风险变化。
7.3.4 活动和任务
7.3.4.1 总则
负责测试监控的人员，将根据测试监控过程的适用组织政策和程序，实施 7.3.4.2 至 7.3.4.5 中规定的活动和任务。
7.3.4.2 设置（TMC1）
该活动包括以下任务
a) 如果测试计划或组织测试实践文件中还没有规定监测测试计划进展情况的措施，则应确定这些措施。
b) 如果测试计划或组织测试实践文件中尚未规定识别新的和不断变化的风险的适当方法，则应确定这些方法。
c)监控活动（如测试状态报告和测试指标收集）应落实到位，以收集任务 a) 和 b) 以及测试计划和组织测试实践文件中确定的措施。
7.3.4.3 监控（TMC2）
该活动包括以下任务：
a) 应收集和记录测试措施。
b) 利用收集到的测试结果，监控测试计划的进展情况。比如通过检查测试状态报告、分析测试措施和与利益相关者会面。
c) 应确定与计划测试活动的偏差，并记录阻碍进展的任何因素。
d) 应识别和分析新的风险，以确定哪些风险需要通过测试来处理，哪些风险需要传达给其他利益相关者。
e) 应监控已知风险的变化，以确定哪些风险需要通过测试来处理，哪些风险需要传达给其他利益相关者。比如：将需要测试处理的风险传达给项目经理。
注释 任务 a)至 e)要定期重复，直到确定测试计划中规定的测试可以终止或已经完成，这通常是通过检查是否达到完成标准来完成。
7.3.4.4 控制（TMC3）
该活动包括以下任务：
a) 执行测试计划所需的行动。比如：将测试活动的责任分配给测试人员。
b) 执行上级管理程序的控制指令。比如：如果正在管理特定级别的测试，项目测试经理应采取的行动。
c)应确定管理实际测试与计划测试之间偏差的必要行动。注：这些控制行动可能需要改变测试、测试计划、测试数据、测试环境、人员配备和/或其他领域（如开发）的变化。
d) 应确定处理新发现和变化风险的方法。注：这可能包括指派更多的人员执行特定任务和改变测试完成标准。
e) 酌情
- 应发布控制指令，以改变测试的执行方式；
- 测试计划的更改应以测试计划更新的形式进行；
- 建议的更改应传达给相关利益方。
比如：测试环境的信息技术支持。
f)在开始任何指定的测试活动之前，应确定是否已做好准备。
注：这通常可通过检查测试计划中描述的进入标准来进行。
注：指定的测试活动可以是测试执行。
注：可在测试设计和实施过程和/或测试环境和数据管理过程中确定准备就绪。
g) 应在指定的测试活动完成后给予批准。比如：完成较低级别的测试。
注：这通常通过检查测试计划中描述的退出标准来执行。
h) 当测试达到完成标准时，应批准测试完成决定。
7.3.4.5 报告（TMC4）
此项活动包括以下任务：
a) 根据测试计划的测试进展情况，应在指定报告期的测试状态报告中向利益相关方通报。
b) 新的风险和现有风险的变化应在风险登记册中更新，并传达给相关利益方。
7.3.5 信息项 在执行本程序后，应产生以下信息项目：
a) 测试状态报告；
b) 测试计划更新
c)控制指令（如测试、测试计划、测试数据、测试环境和人员配置的变更）；
d) 项目和产品风险信息。
注：风险信息可保存在项目风险登记册或测试计划中。
7.4 测试完成流程
7.4.1 概述
如下图所示，测试完成过程在测试活动已完成的情况下执行。它将完成特定测试级别（如系统测试）或测试类型（如性能测试）的测试，并完成整个项目的测试。
该过程的典型输入包括
- 项目测试计划
- 阶段测试计划
- 事件报告
- 项目测试状态报告
- 阶段/类型测试完成报告；以及
- 组织测试实践（如相关）。
注：该过程显示为纯粹的顺序过程，但在实践中可以反复进行，对某些活动进行重新审查。
7.4.2 目的
测试完成过程的目的是提供有用的测试资产供日后使用，使测试环境处于令人满意的状态，并记录和向相关利益者传达测试结果。测试资产包括测试计划、测试用例规格、测试脚本、测试工具、测试数据和测试环境基础设施。
7.4.3 结果
成功实施测试完成过程的结果：
a) 测试资产被归档或直接传递给相关利益方。
b) 测试环境处于商定的状态（例如，可用于任何后续测试）。
c)记录测试完成报告。
d) 测试完成报告得到批准。
e) 向相关利益方传达测试完成报告。
7.4.4 活动和任务
7.4.4.1 总则
负责完成测试的人员将根据有关完成测试过程的适用组织政策和程序，实施 7.4.4.2 至 7.4.4.5 中规定的活动和任务。
7.4.4.2 测试资产归档（TC1）
该活动包括以下任务
a) 对那些将来可能有用的或预期以后会重新使用的测试资产，应加以识别，用适当的方法提供并存档。比如：测试计划、手动和/或自动测试程序、测试环境基础设施。又如：在配置管理系统中适当标注要重复使用的测试资产。
b) 可重复使用的测试资产的可用性应记录在测试完成报告中，并告知相关利益方。比如：负责维护测试（实现成功过渡）的人员和项目测试经理。
7.4.4.3 清理测试环境（TC2）
该活动包括以下任务：在完成所有测试活动后，将测试环境恢复到预定状态。比如：将设置和硬件恢复到初始状态。
7.4.4.4 总结经验教训（TC3）
该活动包括以下任务：
a) 应记录项目过程中吸取的经验教训。
注：可通过记录以下内容来实现：
- 在测试和相关活动中哪些进展顺利；
- 测试和相关活动中不顺利的地方；
- 对测试和其它过程（如开发过程）的改进建议。
注：在敏捷项目中，经验教训可以在回顾总结中确定。在传统项目中，有时会在项目后评审会议或经验教训总结会议上总结经验教训。
b) 结果应记录在测试完成报告中，并传达给相关利益者。比如：成果包括对组织层面的反馈，如测试流程的改进。
7.4.4.5 测试完成报告（TC4）
该活动包括以下任务：
a) 应从以下文件中收集相关信息，但不限于以下文件：
- 测试计划（如项目测试计划、系统测试计划或性能测试计划）；
- 测试结果
- 测试状态报告
- 测试级别或测试类型的测试完成报告；例如，单元测试、性能测试、验收测试等，如果这是对整个项目测试完成情况的报告。
- 事故报告。
b) 应在测试完成报告中对收集到的信息进行评估和总结。
c) 测试完成报告应获得相关负责人的批准。
d) 经批准的测试完成报告应分发给相关利益方。
7.4.5 信息项
执行本过程后，应产生以下信息项目：测试完成报告。
8 动态测试流程
8.1 总则
动态测试流程用于在特定测试级别（如单元测试、集成测试、系统测试和验收测试）或测试类型（如性能测试、安全测试、可用性测试）内进行动态测试。第 7 条描述了动态测试的管理流程。
有四个动态测试流程（如图 9 所示），分别是
a) 测试设计和实施
b) 测试环境和数据管理
c) 测试执行；以及 d) 测试事件报告。
下图说明了动态测试流程的交互方式以及与测试管理流程的关系。这些动态测试流程通常作为测试计划中测试级别（如系统测试）或测试类型（如性能测试）测试策略实施的一部分。
注：该流程显示为纯粹的顺序流程，但在实践中可以迭代进行，对某些活动进行重新审视。
对于任何特定测试，动态测试流程将按上图所示顺序执行，但这些流程通常会被调用多次，以完成给定测试级别（如系统测试）或测试类型（如性能测试）的测试。这是因为在设计和运行测试时，监督测试管理流程（测试监控）会（通过测试测量）监控测试进度，并可能要求（通过控制指令）设计和运行更多测试，直至达到该测试活动的测试完成标准。
测试测量是动态测试流程的输出和测试监测与控制流程的输入，可在动态测试流程的任何活动中产生。
测试测量用于向测试管理人员报告测试的状态和进度。例如，测试度量可用于向测试管理人员说明测试团队设计了多少测试用例。测试管理人员还可以用测试测量来评估测试项目的质量，衡量测试和缺陷修复活动的效率和效果。
同样，控制指令是测试管理流程的输出和动态测试流程的输入，可在动态测试流程的任何活动中执行。
控制指令与测试管理人员的指令相对应，规定测试团队应如何进行动态测试。例如，可向测试团队发出控制指令，指示他们为测试经理分配给其团队的新程序功能设计额外的测试用例。
由于测试措施可以在动态测试流程的任何活动中产生，而控制指令也可以在这些流程的任何活动中执行，因此措施的产生和指令的处理并不作为这些流程中任何特定活动的任务。
8.2 测试设计和实施过程
8.2.1 概述
测试设计和实施过程如下图所示，用于生成测试用例和测试程序。
该过程的典型输入包括
- 测试基础
- 所需的测试范围；
- 风险信息。
出于多种原因，测试设计和实施流程可以退出或重新进入。例如，在执行测试程序后，如果发现需要更多的测试用例才能达到所要求的测试完成标准，通常就会重新进入测试程序。因此，在任何一次执行该流程时，都有可能，甚至很有可能只产生满足测试完成标准所需的所有测试用例的一个子集。
这个过程要求测试人员应用测试设计技术来导出测试用例和测试程序，最终目的是达到测试完成标准，通常用测试覆盖率来描述。测试计划中规定了这些测试完成标准和测试设计技术。测试计划中的每项测试完成标准通常都要经过测试设计和实施过程。ISO/IEC/IEEE 29119-4 中定义了测试设计技术和测试测量方法。在某些情况下，测试用例（和测试程序）的推导可通过基于模型的测试自动化形式来实现。
在这一过程中，有许多情况会导致活动之间的迭代。这些情况包括利益相关者不同意某项活动的结果，如测试模型的初始有效性。
同样，也可能出现这样的情况：某项活动的结果清楚地表明，测试战略决策（如测试完成标准的选择）与项目时间表的限制不一致，这就需要重新审视测试管理流程。
注：该流程显示为纯粹的顺序流程，但在实践中可以迭代进行，对某些活动进行重新审视。
8.2.2 目的
测试设计和实施过程的目的是得出测试执行过程中要执行的测试程序。在这一过程中，要对测试基础进行分析，并得出测试模型、测试覆盖项目、测试用例和测试程序。
8.2.3 结果
成功实施测试设计和实施过程的结果：
a) 分析每个测试项目的测试基础。
b) 创建测试模型。
c)确定测试覆盖项目。
d) 得出测试用例。
e) 创建测试程序。
8.2.4 活动和任务
8.2.4.1 概述
负责测试设计和实施的人员，将根据有关测试设计和实施过程的适用组织政策和程序，执行 8.2.4.2 至 8.2.4.5 中规定的活动和任务。
8.2.4.2 创建测试模型（TD1）
这项活动包括以下任务：
a) 分析测试基础，了解测试项目的要求。注：如果在分析过程中发现了测试基础中的缺陷，应使用适当的事件管理系统进行报告。
b) 测试策略应用于确定测试项目中需要测试的部分和/或特性。例如，对于状态转换测试（STT），应确定测试项目中STT适用的部分。
c)测试模型的符号应根据所要求的测试范围决定。注：所要求的测试覆盖率通常是测试计划中测试完成标准的一部分。比如符号可包括需求陈述（包括自然语言）、等价分区、状态转换图、用例描述、决策表、输入语法、源代码、控制流图、参数和值、分类树等。
d) 应为测试项创建测试模型。注：在某些情况下，测试模型可作为开发过程中的人工制品，如设计说明书或源代码。
e) 可利用相关的风险暴露等级，在测试模型中增加优先级信息。
f)测试模型应得到利益相关者的同意。注：必要时，重新讨论任务 a) 至 d)，以获得利益相关者的同意。
g) 测试模型应记录在测试模型规范中。
h) 应记录测试基础与测试模型之间的可追溯性。
8.2.4.3 确定测试覆盖项（TD2）
此项活动包括以下任务：
a) 测试覆盖项目应通过对测试模型应用测试设计技术来获得，以达到测试计划中规定的测试完成覆盖标准。
注：如果测试项目的测试完成标准被指定为小于测试覆盖率的 100%，则需要从达到 100%覆盖率所需的测试覆盖项目中选择一个子集进行测试。
注：在测试计划或组织测试实践中，可以提供标准来帮助进行选择（例如，放弃与低风险暴露相关的测试覆盖项）。有时需要根据后期活动的结果重新进行选择。
b) 测试覆盖目应使用识别和分析风险活动（TP3）中记录的风险暴露级别进行优先排序。
c) 测试覆盖项应记录在测试用例规范中。
d) 应记录测试基础、测试模型和测试覆盖项之间的可追溯性。
8.2.4.4 导出测试用例（TD3）
这项活动包括以下任务：
a) 应通过确定前置条件、选择输入值、必要时选择执行所选测试覆盖项的操作，以及确定相应的预期结果，推导出一个或多个测试用例。
注：在推导测试用例时，一个测试用例可执行多个测试覆盖项，因此有机会在一个测试用例中结合多个测试覆盖项的覆盖范围。这可以减少测试执行时间，但也会增加调试时间。
注：对于风险程度较高的测试覆盖项，可衍生出更多的测试用例，以提高这些测试覆盖项的测试严格性。
b) 测试用例应根据识别和分析风险活动（TP3）中记录的风险暴露等级进行优先排序。
c)测试用例应记录在测试用例规范中。
d) 应记录测试基础、测试模型、测试覆盖项目和测试用例之间的可追溯性。
e) 测试用例规范应得到利益相关者的批准。
注：这可能需要重复任务 a) 和 b)，在某些情况下，还需要首先重复创建测试模型活动（TD1）和/或确定测试覆盖项活动（TD2），以获得利益相关者的同意。
8.2.4.5 创建测试规程（TD4）
该活动包括以下任务：
a) 根据前置条件、后置条件和其他测试要求所描述的依赖关系，对测试用例进行排序，从而得出测试规程。比如：可使用风险优先级对测试用例进行排序。
注：测试程序中可包括任何其它必要的操作，如为测试用例设置前置条件所需的操作。
注：若要使用工具来执行测试程序，则有必要通过增加额外细节来进一步详细说明，以创建自动测试脚本。
b) 应确定测试计划中未包括的任何测试数据和测试环境要求。
注：虽然这项工作有可能在测试程序推导完成后才最终确定，但这项工作通常可以在流程的更早阶段开始，有时甚至可以在测试模型商定后就开始。
c)测试规程的优先顺序应根据识别和分析风险活动（TP3）中记录的风险暴露等级来确定。
d) 测试规程应记录在测试程序规范中。
e) 应记录测试基础、测试模型、测试覆盖项目、测试用例和测试规程（和/或自动测试脚本）之间的可追溯性。
f)测试规程说明应由利益相关者批准。
注4：这可能需要重复 a)至 e)项任务，以获得利益相关者的同意。
8.2.5 信息项
执行本程序后，应产生以下信息项目：
a) 测试规程（测试模型规格、测试用例规格和测试程序规格）和相关的可追溯性信息；
b) 测试数据要求；
c)测试环境要求。
8.3 测试环境和数据管理过程
8.3.1 概述
测试环境和数据管理流程如下图，用于建立和维护执行测试的环境，并管理相应的测试数据。
测试环境和测试数据的维护可能需要根据先前测试的结果进行更改。如果存在变更和配置管理流程，则可使用这些流程管理测试环境的变更。
该流程的典型输入包括
- 测试计划
- 测试环境要求
- 测试数据要求
- 预期/运行环境；
- 测试依据
- 测试规程；
- 测试结果（如有）。
测试环境和测试数据的要求最初将在测试计划中说明，但测试环境和测试数据的详细组成通常只有在测试设计和实施过程开始后才会清楚。
注：该过程显示为纯粹的顺序过程，但在实践中可以迭代进行，对某些活动进行重新审查。
8.3.2 目的
测试环境和数据管理流程的目的是建立和维护所需的测试环境和测试数据，并将其状态告知所有相关人员。
8.3.3 结果
成功实施测试环境和数据管理过程的结果：
a) 测试环境的建立处于可随时进行测试的状态。
b) 将测试环境的状态告知所有相关人员。
c)维护测试环境。
d) 准备测试数据，并使其处于可随时进行测试的状态。
e) 将测试数据的状态通知所有相关人员。
f)维护测试数据。
8.3.4 活动和任务
8.3.4.1 概述
负责测试环境和测试数据管理的人员（如信息技术支持技术人员）将根据测试环境和数据管理过程的适用组织政策和程序，执行 8.3.4.2 至 8.3.4.5 中规定的活动和任务。
8.3.4.2 建立测试环境（ED1）
这项活动包括以下任务：
a) 根据测试计划、测试设计和实施过程中产生的详细要求、对测试工具的要求以及测试的规模/形式，执行以下工作：
- 规划测试环境的设置；比如：要求、接口、时间表和成本。
- 设计测试环境；
- 确定配置管理的应用程度（如适用）；
- 建立测试环境；
注：可酌情包括硬件和软件项。
注 ：测试环境的设计和实施可包括使用各种软件/系统生命周期过程（更多信息请参阅 ISO/IEC/IEEE 12207 或 ISO/IEC/IEEE 15288）。 - 设置测试工具以支持测试（如适用）；
- 在测试环境中安装和配置测试项；
- 验证测试环境是否满足测试环境要求；以及 8) 必要时，保证测试环境满足规定的要求。
b) 应记录测试环境的状态，并通过测试环境就绪报告传达给相关利益方。
注：相关利益方可包括测试人员和测试经理。
c)测试环境准备就绪报告应包括测试环境与运行环境之间已知差异的描述。
8.3.4.3 准备测试数据（ED2）
该活动包括以下任务：
a) 根据测试计划、测试设计和实施过程中产生的详细要求，以及测试的规模/形式，进行以下工作：
- 计划测试数据的准备；
- 准备测试数据；
- 设置测试数据以支持测试；
- 验证测试数据是否符合测试数据要求；以及 5) 必要时，保证测试数据符合规定要求。
b) 应记录测试数据的状态，并通过测试数据就绪报告传达给相关利益方。
注：相关利益方可包括测试人员和测试经理。
8.3.4.4 维护测试环境（ED3）
此项活动包括以下任务：
a) 应按照测试环境要求维护测试环境。
注：这可能需要根据以前的测试结果进行更改。
b) 应将测试环境状态的变化通知相关人员。比如：测试人员和测试经理。
8.3.4.5 维护测试数据（ED4）
该活动包括以下任务：
a) 应按照测试数据要求维护测试数据。
注：这可能需要根据以前的测试结果进行更改。
b) 测试数据状态的更改应通知相关利益方。比如：测试人员和测试经理。
8.3.5 信息项
执行此过程后，应产生以下信息项：
a) 测试环境；
b) 测试环境就绪报告；
c)测试环境更新（如适用）
d) 测试数据
e) 测试数据准备就绪报告；
f)测试数据更新（如适用）。
8.4 测试执行过程
8.4.1 概述
测试执行过程如下图，用于在测试环境和数据管理程序所建立的测试环境上运行测试 设计和执行程序所产生的测试程序。测试执行过程可能需要执行多次，因为不可能在一次迭代中执行所有可用的测试程序。如果问题得到了解决，则应重新进入测试执行程序进行测试。
该流程的典型输入包括
- 测试计划
- 测试规程
- 测试项
- 测试依据
- 测试环境就绪报告；
- 测试环境更新（如有）。
注：该过程显示为纯粹的顺序过程，但在实践中可以迭代进行，对某些活动进行重新审查。
测试结果的比较和测试执行细节的记录通常与测试程序的执行交错进行。
8.4.2 目的
测试执行过程的目的是在准备好的测试环境中执行在测试设计和实施过程中创建的测 试程序，并记录结果。
8.4.3 结果
成功执行测试执行程序的结果是
a) 执行测试程序。
b) 记录实际结果。
c)比较实际结果和预期结果。
d) 确定测试结果。
8.4.4 活动和任务
8.4.4.1 总则
负责测试执行的人员，应根据有关测试执行过程的适用组织政策和程序，执行 8.4.4.2 至 8.4.4.4 中规定的活动和任务。
注：测试执行过程可因某些情况而中断，如在测试用例中发现缺陷，在测试环境中发现问题，或对测试计划进行修改（如因项目成本或时间修改），或在中止标准中规定的情况。在这些情况下，测试过程会在适当的任务处恢复或完全取消。
注：如果在执行一个或多个测试用例后，发现需要执行更多的测试用例才能达到要求的测试完成标准，则会重新进入测试执行程序。因此，在这一过程的任何一次迭代中，只能执行一个测试项目的所有测试用例的子集。
8.4.4.2 执行测试规程（TE1）
这项活动包括以下任务：
a) 在准备好的测试环境中执行一个或多个测试规程。
注：测试程序可以是自动执行的脚本，也可以是记录在测试规范中的手工测试执行程序，还可以是在探索性测试中按设计立即执行的测试程序。
b) 应观察测试程序中每个测试用例的实际结果。
c)应记录实际结果。
注：这可以在测试工具中进行，也可以手动进行，如测试用例说明所示。
注：在进行探索性测试时，可观察实际结果，如实际结果与预期结果相符，则无需记录。
8.4.4.3 比较测试结果（TE2）
这项活动包括以下任务：
a) 对测试程序中每个测试用例的实际结果和预期结果进行比较。
注：预期结果可以记录在测试规范中，也可以是探索性测试中未记录的预期结果。在自动测试中，预期结果通常包含在自动测试脚本中（或相关文件中），测试工具会自动执行比较。
b) 应确定执行测试程序中测试用例的测试结果。如果重新测试通过，则需要通过测试事故报告程序更新事故报告。
注：测试环境的失败和意外变化将导致问题（潜在事件）被传递到测试事件报告程序。将问题（潜在事件）提交给测试事件报告程序。
8.4.4.4 记录测试执行情况（TE3）
该活动包括以下任务：应按照测试计划的规定，记录测试执行的细节。
注：通常记录在执行日志中。
8.4.5 信息项
执行此过程后，应产生以下信息项目：
a) 实际结果；
注：实际结果与预期结果相比较，以确定测试结果。
b) 测试结果；
示例：测试通过、失败或测试结果不确定。
c)测试执行日志。
8.5 测试事件报告程序
8.5.1 概述
测试事件报告程序如下图，用于报告测试事件。
当发现测试失败、测试执行过程中出现异常或意外情况，或重新测试通过时，就会进入该流程。
该流程的典型输入包括
- 测试结果
- 测试规程
- 测试用例
- 测试项
- 测试依据；
- 测试执行日志（如有）。
注：该流程显示为纯粹的顺序流程，但在实践中，该流程可反复进行，某些活动可重新审议。
8.5.2 目的
测试事件报告流程的目的，是向相关利益者报告在测试执行过程中发现的需要采取进一步行动的事件。如果是新测试，则需要创建一份事件报告。如果是重新测试，则需要更新先前提出的事件报告的状态，但如果发现新的事件，也可能需要提出新的事件报告。
8.5.3 结果
成功实施测试事件报告流程的结果：
a) 对测试结果进行分析。
b) 新事件得到确认。
c) 创建新的事件报告细节。
d) 确定以前提出的事件的状态和详情。
e) 酌情更新以前提出的事件报告详情。
f)将新的和/或更新的事件报告传达给相关利益方。
8.5.4 活动和任务
8.5.4.1 概述 负责测试事件报告的人员将根据测试事件报告流程的适用组织政策和程序，执行 8.5.4.2 和 8.5.4.3 中规定的活动和任务。
8.5.4.2 分析测试结果（IR1）
该活动包括以下任务：
a) 若测试结果与先前提出的事件有关，则应分析测试结果并更新事件详情。
b) 如果测试结果表明发现了新问题，则应分析测试结果，并确定该问题是需要报告的事 件，还是无需报告即可解决的行动项目，或无需采取进一步行动。
注： 在适当的情况下，应与发起者讨论不提出事件报告的决定，以帮助双方理解这一决定。
c)应将行动项目分配给适当人员解决。
8.5.4.3 创建/更新事件报告（IR2）
该活动包括以下任务：
a) 应确定并报告/更新需要记录的事件信息。
注：事件报告可针对测试项目和其它项目，如测试程序、测试基础和测试环境。
注：在重新测试成功后，可更新和关闭事件报告。
b) 新的和/或更新的事件状态应通报给相关利益方。
8.5.5 信息项
执行此流程后，应生成以下信息项：事件报告。
附件 A 测试设计和实施流程的应用示例
A.1 概述
本附件提供了测试设计和实施流程活动 TD1 至 TD4 的应用示例。
A.2 测试依据片段
"保险报价系统应生成接受信息、拒绝信息或接受但超额警告信息。
保险报价系统将根据申请人输入的整岁年龄，接受 18 岁以上、80 岁以下的保险申请人的投保申请；所有其他输入将被拒绝。
70 岁及 70 岁以上的申请者将被接受，但会有一个警告，即如果索赔，他们应支付超额保险费"。
A.3 测试完成标准
"测试完成标准是等效分区覆盖率达到 100%，所有测试用例的执行结果必须是 "通过"。
A.4 测试模型（TD1）
根据测试完成标准，可创建下图所示的测试模型，该模型显示了所述系统行为的等效分区 （黑色轮廓）。
图 A.1 中的测试模型是一个显示等效分区的欧拉图。
另外，测试模型也可以纯文本形式呈现：
未指定函数可以是测试基础中指定函数以外的任何函数。识别未指定的功能可能具有挑战性；但是，必须考虑这些功能，因为如果能使其中一个功能运行，那么测试项目、其测试基础或两者中的缺陷都已识别。在本例中，只确定了一个未指定的功能（为 40 至 55 岁的申请人提供折扣信息这一不需要的要求）。请注意，其他测试人员很可能得出完全不同的无效功能。
A.5 测试覆盖项目（TD2）
通过等效分区，可以得出以下八个测试覆盖项，它们将覆盖所有已确定的等效分区：
A.6 测试用例 (TD3)
只要生成的测试用例能对 8 个测试覆盖项中的每个项进行测试，就能实现 100 % 的等效分区覆盖。
在生成测试用例时，我们可以看到，一个测试用例有时会涉及多个测试覆盖项。尽量减少测试用例数量的好处显而易见，因为这样可以缩短测试执行时间，但有时确定最小测试用例集所需的额外时间，以及测试用例针对多个测试覆盖项时可能需要的更复杂调试，会抵消这种好处。
在本例中，有两个测试用例使用了一个以上的测试覆盖项，如下所示：
这七个测试用例表明，所有测试覆盖项目都已执行，因此达到了测试完成标准的覆盖部分。
A.7 测试规程（TD4）
测试规程只需按逻辑顺序排列测试用例。测试用例之间没有依赖关系，因此可以按任何顺序运行。
假设还决定 TCI-1 的风险较高，因为它的运行频率最高。另外，TCI-6 风险较高，因为开发人员的经验表明，他们对特殊字符的处理并不总是完美的。因此，最好运行更多的 TCI-1 和 TCI-6 测试用例。
可以生成一个简单的 14 步测试程序，涵盖所有等效分区，同时还能解决风险问题，具体如下：
- 第 1 步：建立测试环境
- 第 2 步：运行 CASE#1a（"年龄 =53）
- 第 3 步： 运行 CASE#1b（"年龄 =27）
- 第 4 步： 运行 CASE#1c（"年龄 =66）
- 第 5 步： 运行 CASE#1d（"年龄 =38）
- 第 6 步： 运行 CASE#2
- 第 7 步： 运行 CASE#3
- 第 8 步： 运行 CASE#4
- 第 9 步： 运行 CASE#5
- 第 10 步： 运行 CASE#6a ('Age =&')
- 第 11 步： 运行 CASE#6b ('Age =#')
- 第 12 步： 运行 CASE#6c（'Age =！'）
- 第 13 步： 运行 CASE#7
- 第 14 步： 结束测试环境
附件 E（资料性）测试模型
在本文件的上一版本中，测试设计和实施过程（8.2）包括测试条件的使用。对该标准使用情况的反馈意见强调了用户对测试条件的理解问题，以及使用测试条件推导测试用例的问题--许多用户将其描述为 "令人困惑"。因此，我们选择了一种基于测试模型的替代方法。
在 ISO/IEC/IEEE 29119-4 中，测试模型已被成功用于定义每种测试用例设计技术。
IEEE 29119-4 中的每种测试用例设计技术，并利用测试模型为每种技术生成了新的更简单的示例。附件 A 提供了使用测试模型进行测试设计和实施的示例。
使用测试模型可以简化测试设计流程，更容易确定测试覆盖项目。这种简化的测试设计流程由四项活动组成，而不是以前的六项活动。在本文档的上一版中，对于某些测试用例设计技术，导出测试条件和导出测试覆盖项这两项活动的结果是相同的，这表明其中一项活动是多余的。通过使用测试模型（而不是测试条件），测试模型和测试覆盖项之间不存在一对一的映射关系，这意味着每项活动都在进行有效的转换。
测试条件与测试模型之间的区别可能很难把握。测试条件是一个较为抽象的概念，在不同的详细程度上用于描述任何可用作测试基础的东西。在高层次上，测试条件可用于与客户商定测试要涵盖哪些用户功能；在低层次上，测试条件可描述开发人员测试时要执行的一行代码。相比之下，测试模型更有针对性，它描述的是测试项目中测试覆盖范围所需的那部分行为。测试模型可以涵盖与一个或多个测试条件相同的内容（通常会取代多个测试条件）
当测试条件与测试覆盖项密切相关时。创建测试模型的目的是提供一种表示测试项目行为的方法，明确显示测试所要覆盖的测试覆盖项，而测试条件与测试覆盖项的直接联系往往较少。另一个明显的区别是，当创建测试以满足测试目标时，通常可以用一个内聚的测试模型来创建许多测试（通常是特定测试设计技术的所有测试），而要创建同样的测试，通常需要确定许多内聚程度较低的测试条件。
热门相关：最强神话帝皇 全能千金燃翻天 明尊 隐婚99天：首长，请矜持 灭世之门