0 前言
国际标准化组织（ISO the International Organization for Standardization）和国际电工委员会（IEC the International Electrotechnical
Commission）构成了世界标准化的专门体系。作为国际标准化组织或国际电工委员会成员的国家机构通过各自组织设立的技术委员会参与国际标准的制定，这些技术委员会负责特定领域的技术活动。国际标准化组织和国际电工委员会的技术委员会在共同感兴趣的领域开展合作。与国际标准化组织和国际电工委员会联络的其他国际组织、政府组织和非政府组织也参与了这项工作。
ISO/IEC 指令第 1 部分描述了用于制定本文档的程序以及用于进一步维护本文档的程序。特别应注意不同类型的 ISO/IEC 文件所需的不同批准标准。本文档是根据 ISO/IEC 指令第 2 部分中给出的规则起草的（请参阅 www.iso.org/directives 或 www.iec.ch/members_experts/refdocs）。
IEEE 标准文件由 IEEE 学会和 IEEE 标准协会 (IEEE-SA) 标准委员会的标准协调委员会制定。IEEE 通过美国国家标准协会批准的共识制定流程制定其标准，该流程汇集了代表不同观点和利益的志愿者，以完成最终产品。志愿者不一定是协会的成员，并且无偿服务。
虽然 IEEE 管理该流程并制定规则以促进共识制定流程的公平性，但 IEEE 不会独立评估、测试或验证其标准中包含的任何信息的准确性。
请注意，本文档的某些元素可能属于专利权的主题。ISO 和 IEC 不负责识别任何或所有此类专利权。在制定文件期间确定的任何专利权的详细信息将在简介中和/或 ISO 收到的专利声明列表（请参阅 www.iso.org/patents）或 IEC 收到的专利声明列表（请参阅 https://patents.iec.ch）中列出。
ISO/IEC/IEEE 29119-1 由联合技术委员会 ISO/IEC JTC 1、信息技术、小组委员会 SC 7、软件和系统工程与 IEEE 计算机学会系统和软件工程标准委员会合作制定，依据 ISO 和 IEEE 之间的合作伙伴标准开发组织合作协议。
此第二版取消并取代了第一版 (ISO/IEC/IEEE 29119-1:2013)，第一版已进行技术修订。
主要变化如下：
删除了本文件未涉及的测试术语及其定义。因此，本文件从 “概念和定义 “更名为 “一般概念”。
测试概念的覆盖范围更加简洁，并重新排序。
测试子过程的概念因其复杂性已被删除，取而代之的是测试过程实例化的更多内容。
明确了测试策略的预期内容。
描述了简化的测试设计流程，测试用例的推导现在基于测试模型而非测试条件。
指标和衡量标准的内容已从附件移至文件正文。
删除了解释测试如何融入不同生命周期模型的附件。
新增了一个附录，举例说明不同领域的系统如何与某些特性和测试方法相关联。
1 简介
ISO/IEC/IEEE 29119 系列的目的是定义一套国际公认的软件测试标准，任何组织在进行任何形式的软件测试和使用任何生命周期时都可使用。
我们认识到，软件、软件组织和方法有许多不同类型。软件领域包括信息技术 (IT)、个人电脑 (PC)、嵌入式、移动、科学和许多其他分类。软件组织的规模有大有小，有位于同一地点的，也有遍布全球的；有商业性的，也有提供公共服务的。软件开发方法包括面向对象、传统、敏捷和 DevOps。这些因素和其他因素都会影响软件测试。ISO/IEC/IEEE 29119 系列可支持多种不同情况下的测试。
本文档通过介绍 ISO/IEC/IEEE 29119 系列所依据的一般概念，为使用 ISO/IEC/IEEE 29119 系列中的其他部分提供便利。
软件测试的一般介绍。介绍了软件测试在质量管理中的作用，以及作为验证和确认的一部分；定义了软件测试在静态和动态测试中的实施形式。解释了详尽测试的不切实际性和抽样的必要性；说明了测试基础和测试准则的重要性。介绍了测试独立性的好处。
基于风险的测试是 ISO/IEC/IEEE 29119 系列所推荐的测试战略和管理方法，它为测试的优先级和重点提供了基础。测试级别、测试类型和测试设计技术（及相应措施）是测试战略的一部分，在此背景下对其进行了描述。
介绍了各种测试框架，包括测试流程（和测试流程改进）、测试指标、测试文档、配置管理和工具支持。
介绍了基于测试模型的测试设计和执行的性能。考虑了几个最重要的测试设计和执行选择，包括脚本测试和探索性测试方法、创建测试用例的测试设计技术的重要性、测试模式、复测和回归测试、手动和自动测试、背靠背和 A/B 测试。
还介绍了直接支持测试设计和执行的几项活动，包括测试环境、测试数据管理、沟通和报告以及缺陷和事件管理。
附录A 简要介绍了一些系统特征和建议的相关测试方法。如果测试人员能够确定哪些系统特征适用于他们正在测试的系统，那么他们就应该考虑针对该特征列出的专门测试是否适合纳入他们的测试策略。
附件B 介绍了几种通用测试角色，并简要说明了他们的职责。
ISO/IEC/IEEE 29119 系列所依据的测试流程模型在 ISO/IEC/IEEE 29119-2 中有详细定义。ISO/IEC/IEEE 29119-2 涵盖了组织层面、测试管理层面和动态测试层面的软件测试过程。测试是处理软件开发风险的主要方法。本文件定义了基于风险的测试方法。
ISO/IEC/IEEE 29119-3 中定义了测试过程中产生的测试文档模板和示例。ISO/IEC/IEEE 29119-4 中定义了测试过程中可使用的软件测试技术。
虽然本文件是资料性的，但 ISO/IEC/IEEE 29119-2、ISO/IEC/IEEE 29119-3 和 ISO/IEC/IEEE 29119-4 是规范性的，这意味着它们包括了对想要声称符合这些标准的任何人的要求。如果用户不遵守每项要求（例如，采用敏捷方法进行开发和测试），只要说明并同意调整的程度和理由，就可以要求符合调整的要求。每个标准的相关一致性条款都提供了一致性的具体细节。
ISO/IEC/IEEE 29119 系列标准可单独使用，也可作为涵盖软件生命周期其他方面的更大套标准的一部分使用。例如，有些用户使用 ISO/IEC/IEEE 12207 来定义适合其产品和服务的软件系统生命周期模型（有些可能使用相应的系统工程标准 ISO/IEC/IEEE 15288），并参考 ISO/IEC/IEEE 29119 系列来满足其软件测试需求。
ISO/IEC/IEEE 29119 系列旨在为利益相关者提供在任何组织中管理和执行软件测试的能力。
2 范围
本文件规定了软件测试的一般概念，并介绍了 ISO/IEC/IEEE 29119 系列的关键概念。
3 术语和定义
参见：https://www.cnblogs.com/testing-/p/18350056
4 软件测试概念
4.1 软件测试简介
4.1.1 概述
ISO/IEC/IEEE 29119 系列基于业界对软件测试的广泛共识。为便于所有读者理解 ISO/IEC/IEEE 29119 系列，本条款记录了这一共识。
4.1.2 与质量管理的关系
质量管理包括质量保证 (QA) 和质量控制 (QC)。质量保证的重点是正确实施流程和改进流程，而质量控制的重点是支持实现适当质量水平的活动；测试是质量控制的一种形式。测试结果为质量保证（QA）和质量控制（QC）所用。
4.1.3 验证（Verification）和确认（Validation）
验证和确认是两个独立的过程，它们都将测试作为主要实践之一。验证的重点是测试项目是否符合规范、特定要求或其他文件，而确认的重点是测试项目在按预期使用时是否能满足利益相关者的需求。如下图，测试（静态和动态）同时支持验证和确认。有关验证和确认的更多详细信息，请参阅 IEEE 1012。
4.1.4 测试项
术语”测试项”是指作为测试对象的工作产品。测试项”的其他术语包括 “测试对象”、”被测软件 “和 “被测系统”。
测试项可以是一个完整的系统，也可以是更大系统的一部分，包括硬件、软件和相关文档。测试项可以是可执行的（如二进制代码、某些模型），也可以是不可执行的（如文档规范）。如果测试项可执行，则可进行动态测试，否则（不可执行）只能通过审核、静态分析和模型验证进行静态测试。
虽然 ISO/IEC/IEEE 29119 系列的重点是软件和相关文件，但其中描述的许多概念也适用于其它测试项目，如由硬件和软件组成的完整系统。
4.1.5 静态和动态测试
测试有两种形式：静态和动态。
静态测试是在不执行代码的情况下对测试项目进行评估，可以手动（如审查）或使用工具（如静态分析）进行。对于静态测试，测试项目可以是文档或源代码，也可以在生命周期的任何阶段进行。ISO/IEC 20246 详细描述了评审和评审类型示例。评审的形式多种多样，包括检查、技术评审、演练和非正式评审。静态分析包括使用工具在不执行代码的情况下检测代码或文档中的异常（如编译器、循环复杂性分析器或代码安全分析器）。
动态测试包括执行代码和运行测试用例。因此，动态测试只能在可执行代码可用的生命周期阶段进行。
4.1.6 穷举测试和抽样
为了通过动态测试证明特定测试项目在所有给定情况下满足所有要求，需要测试所有可能 状态下的所有可能输入值组合。这种不切实际的活动被称为 “穷举测试”。对于一个简单的软件程序来说，输入值组合的数量是非常庞大的（例如，一个处理两个 64 位数字的程序需要进行 2128 次测试才能覆盖所有可能的输入组合）。实际上，测试项目往往越来越复杂，因此不可能采用穷举测试。
因此，在软件测试实践中，测试套件是从（极其庞大的）可能的输入组合和状态集合中抽样得到的。
可能的输入组合和状态。选择最有可能发现相关问题的测试子集，是测试人员最艰巨的任务之一。ISO/IEC/IEEE 29119 系列推荐使用基于风险的测试（见 4.2.2）作为选择测试的基础。
4.1.7 启发测试
在工程（和软件工程）中，启发式是一种基于经验的（试错）方法，可作为解决问题和设计的辅助手段。然而，尽管启发式方法可用来解决问题，但它也有缺陷，有时可能无法解决问题，或只能部分解决问题。
许多系统和软件测试都基于启发式方法。例如，在创建待测系统模型时，启发式方法很有用；但在创建完整的系统模型时，启发式方法可能会失败，因此，即使测试看似完成，也可能找不到系统中的缺陷。由于认识到测试的方式可能有误，因此可以通过在测试策略中采用多种方法，部分地处理测试方法无效的风险。
4.1.8 测试目的
测试通常不止一个目的。典型的目的包括但不限于
a) 发现缺陷–这样就能随后消除缺陷，从而提高软件质量；
b) 收集测试项目的信息 – 测试产生信息；这些信息可用于不同目的，如
开发人员可以利用这些信息来消除缺陷、提高代码质量或学习如何在将来创建更好的代码；
测试人员可以利用这些信息创建更好的测试用例；
管理人员可以利用这些信息决定何时停止测试；
用户最终从更高的产品质量中受益。
c)建立信心和作出决定–通过提供测试项目在特定情况下正确运行的证据，利益相关者对测试项目在运行中正确运行的信心就会增加；有了足够的信心，利益相关者就可以决定发布测试项目。
测试可能出于上述部分或全部目的，也可能出于未列出的其它目的；这些目的应作为任何测试活动的出发点加以确定并达成一致。
4.1.9 测试依据
术语 “测试依据 “是指开发测试和测试用例时使用的信息。通常，它用于决定测试用例的重点、测试输入和预期结果；因此，测试依据 定义了测试项目的预期行为。
如果测试依据可以作为单个文件或一组文件提供，就能为测试的创建和审查提供共同的参考。在实践中，所需的信息可能只能以口头等非结构化或非正式的方式提供。
如果信息缺失或不充分，就无法完成测试用例的分析和设计。
4.1.10 测试准则
测试准则是用来确定测试通过或失败的信息源。测试指标可以是，但不限于
需求或设计规范；
另一个类似系统（如因速度太慢而被替换的系统）；
人类专家或专家小组。
测试准则并非总能提供预期结果。在某些情况下，测试字典包含一个约束条件，用于定义通过/失败标准（如实际结果大于 10）。
测试字典可以是完整的（提供测试项目所需的全部信息），也可以是部分的（只提供所有测试用例的一个子集所需的信息）。
如果测试字典是完整和正式的，那么就有可能创建一个自动测试字典，并随后实现自动测试。实际上，这很少可能，还需要人类专家；这通常被称为测试准则问题。测试准则问题的第二部分是当测试项目的复杂性（如基于人工智能的大数据分析系统）使得人类专家无法知道测试项目何时通过或失败。
4.1.11 测试的独立性
测试的独立性是指进行测试的人员与开发测试项目的人员之间的分离程度。如果进行测试的人员与进行开发的人员不同，则测试的独立性就高，如果开发和测试的人员相同，则测试的独立性就低。
一般来说，高度的测试独立性被认为是可取的，原因有二。第一个原因是，独立的测试人员不太可能做出与开发人员相同（错误）的假设，因此更有可能发现开发人员工作中的缺陷。第二个原因是，开发人员在测试自己的工作时可能会出现确认偏差，即他们可能会寻找那些能证实他们在开发过程中所做的决定是正确的结果。
另一方面，有些人认为，开发人员测试自己的工作更有效率，因为他们熟悉自己的工作。测试人员和开发人员共同工作的折中方案，以及开发人员在编写代码之前先编写测试的 “测试先行 “方法，也得到了推崇。
4.2 测试计划和测试策略
4.2.1 概述
测试计划描述测试的目标，以及为实现这些目标而要开展的活动。测试策略是测试计划的一部分（也可单独记录），其中说明了活动的选择。活动的选择基于与目标相关的风险，而目标主要涉及满足产品和项目要求。测试计划中除测试策略外的大部分内容都是描述测试策略的实施，如提供时间安排和人员配置细节。
测试计划及其测试策略可适用于整个项目、一个或多个测试级别或一个或多个测试类型。
测试计划中的活动要采用各种测试方法，选择这些方法是为了管理预期风险。这些测试方法的选择并不简单。在理想的情况下，只需处理暴露程度较高的风险，直到达到可接受的总体风险暴露水平。
但在实际操作中，风险往往是相互关联的。例如，如果决定通过执行更严格的测试来处理产品风险，那么测试超时（可能在时间和预算方面都超时）的风险很可能会被引入（或增加）。因此，在测试战略中选择测试方法通常是一项复杂的工作。
4.2.2 风险和风险管理
4.2.2.1 风险类别
风险可分为产品风险和项目风险。
产品风险与可交付产品（测试项目）有关，包括因产品未按要求运行而可能对用户或其他利益相关者造成的伤害。
项目风险与产品的开发方式有关，包括开发人员和其他项目成员缺乏必要技能的危险，或产品延迟交付或超出预算的危险。
4.2.2.2 风险管理流程
通过测试管理风险的流程（通常称为基于风险的测试）与大多数其他风险管理流程类似。首先要识别潜在风险，有时要使用基于质量特性的核对表，如 ISO/IEC 25000 SQuaRE 系列标准中定义的核对表。然后，对这些风险进行分析，以确定一旦发生风险，它们（对交付产品或项目）将产生的潜在影响（严重性）。根据需求质量、员工能力、系统复杂性和历史信息等因素，确定每种风险发生的可能性。然后，在综合考虑每种风险的影响和可能性的基础上，确定风险暴露等级。然后对风险进行相应的优先排序，并在适当（或可能）的情况下决定降低风险的行动–始终牢记，对一种风险的处理可能是另一种风险的起因或增加风险。
4.2.3 风险和要求是测试策略的基础
产品不能满足利益相关者要求的风险往往是选择测试方法的主要驱动力。有时，人们会混淆测试方法的选择是基于风险还是基于需求。这并不是在替代方案之间进行选择–不满足利益相关者的要求通常是任何项目的最高风险之一–因此，选择有助于确保满足要求的测试方法是基于风险的测试策略的有效且重要的组成部分。
注意：可考虑的要求包括（但不限于）测试项目要求、项目要求、法规要求、组织要求、合同要求。
比如：测试策略可以基于多种测试方法和测试实践。在特定情况下，测试经理可以决定使用单元测试、集成测试和系统测试作为测试级别。
功能测试和负载测试是常用的测试类型。对于功能测试，会选择等价分割和边界值分析等测试设计技术，并要求达到结构测试覆盖率。此外，测试策略还规定，在这种情况下，用户应使用脚本测试、探索性测试和测试自动化等测试方法。所有这些决定都记录在测试策略中，其目的是实现测试经理确定的测试目标，并解决感知到的风险。
功能测试通常用于检查功能需求的实现情况，而非功能类型的测试，如性能和渗透测试，则用于检查性能和安全方面的需求是否得到满足。
4.2.4 测试方法
4.2.4.1 一般测试方法
测试方法的选择是基于其处理已知风险的能力。每种测试策略都至少包括其中几类测试方法。例如，在项目测试战略中，要选择测试级别和测试类型。如果动态测试被确定为一种必要的风险处理方法（在生命周期的早期，没有可执行文件时，不能选择动态测试来管理风险），那么测试策略中就会包括测试设计技术和（通常）相应的测试完成措施（以测试覆盖率措施来定义）。
4.2.4.2 测试级别
项目测试在生命周期的不同阶段进行，通常称为测试级别。每个测试级别都与一类测试项目（如模块、系统）相关联，都有特定的目标，并用于处理特定的风险。例如，集成测试的目标是使软件部件协同工作，用于处理与测试项目之间的接口有关的风险，并试图帮助确保它们正确通信。
测试级别可能与静态和动态测试有关，并与开发活动密切相关。对于动态测试，每个测试级别通常都需要特定的测试环境。
常见的测试级别，按其通常执行的顺序和测试项目的大小（从单个单元或模块到完整系统）排列：
单元测试
集成测试
系统测试；
验收测试。
4.2.4.3 测试类型
不同类型的测试如下图，详见 ISO/IEC/IEEE 29119-4。
4.2.4.4 测试设计技术/测量方法
用于创建测试用例的测试设计技术和用于测量测试设计技术使用完整性的测试覆盖率测量方法如下图，详见 ISO/IEC/IEEE 29119-4。
4.2.4.5 测试实践
作为测试策略的一部分，可实施多种测试实践。下图列出了一些较常见的测试方法，当然也可能有其他方法。
4.2.4.6 静态测试
在测试计划中，使用静态测试有助于形成最佳测试策略。静态分析和评审可在动态测试之前进行，并能在执行测试之前发现缺陷。大多数软件项目都使用评审（见 ISO/IEC 20246）作为在生命周期早期发现问题的方法。
4.2.5 开发和维护生命周期中的测试
ISO/IEC/IEEE 29119 系列定义的测试过程、文档和技术是通用的，同样适用于软件的开发和维护，以及敏捷和传统的生命周期。可以根据具体情况调整这些标准的使用，例如，可以在敏捷项目中规定文档的精简程度。
开发和维护过程中的测试都应基于可感知的风险。在维护过程中，风险还需要考虑到所做的更改以及这些更改的预期影响。
4.2.6 领域和系统特性
ISO/IEC/IEEE 29119 系列适用于所有领域的软件，包括但不限于医疗设备、商业系统、国防系统、电信和健康。特定领域的系统有一些相似之处，这些相似之处可以延伸到对它们进行的测试。
然而，由于某些领域的系统种类繁多（有些系统跨越两个或多个领域），因此很难仅仅根据领域来确定一套合适的测试方法。
一个特定领域的系统通常具有多种系统特征。例如，未来的航空电子系统可能包括以下特征–嵌入式、实时、自主和人工智能。由于系统特性没有领域那么抽象，因此更容易将特定的测试方法与这些特性联系起来。
如果已知与给定系统相关的系统特性，就可以提出应考虑纳入测试策略的测试类型（以及执行基于风险的测试后确定的测试类型–有关基于风险的测试的更多信息，请参阅 4.2.2）。
附件A提供了各种系统特性和常见相关测试方法的更多细节。
4.2.7 测试策略内容
测试策略的预期内容如下：
测试方法选择：
测试级别（作为项目测试计划的一部分）；
测试类型（如果专门测试计划的这一部分侧重于单一的系统特性，如可用性，则 有时只有一种测试类型）；
选定的测试实践 -选定的静态测试选项 -测试设计技术（通常根据团队技能和熟悉程度、测试基础的格式以及根据经验对预期缺陷类型的看法来选择）；
测试可交付成果（可能受监管要求的驱动，处理的风险部分不符合规定的标准）；
测试完成标准（如有选择，应与测试技术相匹配，因为这些标准提供了一种了解测试何时已执行完毕的方法）；
进入和退出标准（针对每项测试活动；这些标准通常用于管理测试过程）；
独立程度（见 4.1.11）；
要收集的指标（通常与测试完成标准有关，但也可包括支持测试过程改进的指标）；
测试数据要求（可使用更真实的数据来处理与数据有效性有关的风险）；
测试环境要求（通常通过平衡使用不具代表性的测试环境的风险与此类环境的成本来选择，此处应明确规定所需的测试自动化水平）；
重新测试和回归测试（需要在了解开发人员进行更改的相关风险的基础上确定水平）；
暂停和恢复标准（通常是为测试人员提供一套商定的条件，开发人员必须满足这些条件，测试才有价值）；
偏离组织测试实践（也许还有测试政策）。
4.3 测试框架
4.3.1 测试过程
4.3.1.1 一般过程
描述一系列将输入转化为输出的相互关联或相互作用的活动。将测试活动与开发（及其他）活动分开考虑通常是有用的，这些活动用测试流程来描述。在 ISO/IEC/IEEE 29119-2 中，测试过程被定义在三个层面–组织层面、管理层面和动态测试层面。本文档中定义的测试流程具有通用特性，可广泛应用于各种情况。组织和项目可采用这些通用测试流程，并根据需要补充其他活动、程序和实践。
4.3.1.2 组织层面的测试
组织层面的测试主要是定义和维护适用于整个组织而非特定项目的政策和测试实践。测试政策和一份或多份组织测试实践文件中定义的规则和指导，是组织内所有软件测试的基础。这些规则和指导的存在为项目提供了约束，消除了重复决策的需要（例如，记录在案的组织测试实践可能会规定所有项目都要使用特定的测试自动化框架），并鼓励项目间的技能再利用和交流。测试政策和组织测试实践文件通常出现在更成熟的组织和运行多个项目的大型组织中。成熟度较低的组织可以在没有测试政策和组织测试实践文档的情况下进行测试，但这会降低组织内部测试的一致性，并可能降低测试的效果和效率。
4.3.1.3 基于项目的测试
在开发和维护软件时，利益相关者通常会执行一系列由生命周期模型定义的相互关联的过程。生命周期模型是沟通和理解软件初始开发和后续维护的共同参考。
项目中使用的测试流程可由监管标准（如安全相关软件）、组织约束（如组织测试实践文件）和项目的特定需求强制规定。
ISO/IEC/IEEE 29119 系列在两个层面上定义了基于项目的测试流程：支持测试管理和支持动态测试。静态测试技术，如审查和静态分析，在单独的标准（如 ISO/IEC 20246）中定义。因此测试流程总体分为三个层次。
4.3.1.4 测试管理过程
测试管理过程描述了对测试的管理。最初，在测试战略和规划流程中，根据对已识别风险和项目限制的分析，并考虑到组织测试实践文件（如有），制定测试计划。测试计划包括针对具体项目的测试策略、人员配置和测试时间安排。
测试计划推动测试，测试通过测试监控流程进行管理。
测试完成后，测试完成流程包括生成测试完成报告、清理测试环境、归档测试工具和总结经验教训等活动。
4.3.1.5 动态测试过程
动态测试流程描述如何开发测试用例、设置测试环境、执行测试用例和报告任何问题。动态测试流程的互动如下图。请注意，该图只显示了单个测试的逻辑顺序（这些流程将在项目测试中多次运行），某些流程的运行频率可能高于其他流程（例如，环境设置的频率通常低于测试执行的频率）。此外，在实践中，其中一些流程可能并行运行（例如，测试设计可能与测试环境设置同时进行）。
4.3.1.6 测试过程的实例化
4.3.1.6.1 概述
ISO/IEC/IEEE 29119-2 中定义的八个测试过程需要根据具体情况加以应用，不同的组织、不同的项目和项目内部的情况都会有所不同。
4.3.1.6.2 组织级实例化
在组织级，有一个单一的组织测试流程，可用于制定和维护任何组织级测试规范。因此，在制定和维护每个单独的组织级测试规范时，都要对该流程进行实例化。
通常情况下，这意味着该流程要实例化两次；一次用于测试策略，一次用于组织测试实践文件（如果组织内的项目各不相同，需要制定不同的规则和指南，则组织可能会有多个组织测试实践文件，在这种情况下，每个单独的组织测试实践文件都需要单独实例化组织测试流程）。
4.3.1.6.3 测试管理级别的实例化
在测试管理级别，三个管理级别的测试流程（测试策略与计划、测试监控与控制、测试完成）可用于管理不同级别和类型的测试。例如，它们可用于管理项目级测试、组件测试、集成测试、系统测试、验收测试、可用性测试、性能测试和安全测试。
因此，在一个大型项目中，可能需要多次实例化三个管理级别的测试流程（它们几乎总是作为三套完整的流程实例化）。而在小型项目中，可能只需要实例化一次。
对所有项目而言，都有必要将它们实例化，以管理项目级别的测试。如果决定对较低层次的测试（如组件测试、系统测试）进行单独管理，则需要为每个单独管理的测试层次实例化测试管理流程。同样，如果决定对某一测试类型进行单独管理（如可用性测试、安全性测试），则同样需要为每一类型的测试实例化测试管理流程。决定是否有必要将其实例化的一种方法是，决定特定测试级别或测试类型需要单独的测试管理者角色。
当一个项目有多个测试管理过程时，为项目级测试实例化的过程将用于管理其他测试管理过程下级测试过程也可以管理其他测试过程，从而形成测试管理的层次结构，但这只适用于非常大的项目。右侧层次结构中的所有测试管理过程都是从三个基本测试管理流程实例化出来的。项目测试管理过程将由项目测试经理负责。更低级别的测试管理过程通常由更低级别的测试经理负责（例如，性能测试经理将负责性能测试管理过程）。
4.3.1.6.4 动态测试层面的实例化
在动态测试层面，通常需要多次实例化动态测试流程集。通常情况下，每个不同的测试级别和测试类型（如组件测试、集成测试、系统测试、验收测试、性能测试、可用性测试、安全测试）都要分别实例化。
在实践中，对系统不同部分的测试分别实例化也很常见（例如，对组件测试的不同模块分别实例化，或对与特定利益相关者相关功能的验收测试分别实例化）。这样，与特定功能相关的测试的设计和执行就可以与其他功能的设计和执行分开进行。下图显示了为每个测试级别和三个不同模块的组件测试分别实例化的动态测试流程。
4.3.2 测试文档
4.3.2.1 概述
测试文档是执行测试流程的结果，在 ISO/IEC/IEEE 29119-3 中有详细规定。这些输出的目的地要么是利益相关者（如提交给项目经理的测试状态报告），要么是其他流程（如指导动态测试执行的测试计划）。
由于测试文档来自流程，因此可按三个测试流程层面的输出进行分类。
4.3.2.2 组织级文档
4.3.2.2.1 概述
组织测试流程制定和维护组织测试规范。这些规范通常采用测试政策或组织测试实践文件的形式。
4.3.2.2.2 测试方针
测试方针以业务术语表达组织对软件测试的期望和方法。虽然它对参与测试的任何人都有用，但它的对象是行政人员和高级管理人员。测试政策中描述的方法（组织希望实现的目标）指导组织测试实践文件的内容，该文件描述组织如何实现这一目标。
4.3.2.2.3 组织测试实践
组织测试实践文件与测试方针保持一致，并对如何在组织内运行的所有项目中进行测试提出要求和限制（除非这些项目的性质过于不同，在这种情况下，可生成多个组织测试实践文件）。
4.3.2.3 测试管理级别文档
4.3.2.3.1 概述
三个测试管理流程中，每个流程都会生成一份主要的测试文档。测试计划是测试策略和计划的结果；测试状态报告是测试监控流程为记录测试工作进度而生成的；测试完成报告是测试完成流程为总结测试工作而生成的。
4.3.2.3.2 测试计划
测试计划详细描述如何对相关的测试管理流程进行测试。由于测试管理流程可以实现各种目标（如项目测试管理、系统测试管理、性能测试管理），相应的测试计划也必然会根据测试原因而有不同的侧重点。不过，无论计划进行哪种形式的测试，测试计划中包含的信息类型往往是相同的。
测试监控流程会使用测试计划作为管理测试的基础，但动态测试流程也会使用测试计划，因为它规定了应如何执行动态测试（例如，它规定了所需的测试技术、测试完成标准、谁应在何时执行测试）。测试计划还用于规定如何进行静态测试（如审查和静态分析）。测试监控流程可对测试计划进行更新，例如，由于需求变化（如测试完成日期提前）或指定的测试无法完成时或测试人员无法完成指定的测试。
4.3.2.3.3 测试状态报告
测试状态报告由测试监控程序生成，提供测试计划的当前测试进度信息。项目经理可使用这些报告来衡量进度，如果测试管理是在较低层次进行，则可使用这些报告向项目测试经理通报较低测试层次的进度。测试状态报告通常是定期生成的（如测试计划中规定的），尽管在测试接近尾声时报告的频率可能会增加。
4.3.2.3.4 测试完成报告
测试完成报告总结测试期间进行的测试，详细说明存档的测试软件和测试环境的状 态，并介绍测试过程中吸取的经验教训。如果测试完成报告针对的是较高层次的测试，则还应包含较低测试层次的测试细节（例如，如果是项目测试完成报告，但有单独的系统测试计划，则应包含系统测试的细节，这些细节应在系统测试完成报告中提供）。通常情况下，与每个测试计划相关的测试都会生成一份测试完成报告。
4.3.2.4 动态测试级文档
4.3.2.4.1 概述
动态测试过程所产生的测试文档数量会有很大差异，因为不同形式的测试对测试用例设计、测试环境和测试结果的文档要求会有很大不同。测试文档的要求应在测试计划中说明，根据测试自动化程度，部分文档可保存在测试管理工具中。
4.3.2.4.2 测试规范
测试规范应提供足够的细节，以确定测试程序中的测试用例是如何从测试基础中推导出来 的，以及它们是否达到了所要求的测试覆盖水平。
测试规范可采用测试程序（支持手动测试执行）或自动测试脚本（支持自动测试执行）的形式。需要从测试用例追溯到测试基础，以确认覆盖范围，并支持在发生变化时选择重新运行的测试。
4.3.2.4.3 测试环境要求和测试数据要求
如测试计划中未包括测试环境要求和测试数据要求，则应说明这些要求。
4.3.2.4.4 测试环境报告和测试数据就绪报告
测试环境（如可用性）和测试数据的状态应报告给相关利益方。
4.3.2.4.5 测试执行日志
测试的执行情况，包括实际结果，均记录在测试日志中。
4.3.2.4.6 测试事件报告
必要时，生成事故报告（也称缺陷报告），以便在认为成本效益高时，消除缺陷。
4.3.3 文档要求
ISO/IEC/IEEE 29119-3 对文档的要求极为灵活。ISO/IEC/IEEE 29119-3 规定了所需记录的信息，但不要求使用特定的命名或术语；也不要求创建特定的文档（信息可存储在多个文档中，或合并为一个文档）。文档不一定是纸质的，可以通过电子方式或测试自动化工具来保存信息。
4.3.4 配置管理（Configuration management）和测试
配置管理（Configuration management）（在 ISO 10007 中定义）是测试流程在所有三个层次上所使用的一组活动，它可以唯一地识别配置项（如测试程序、测试脚本），记录这些配置项的变更，并报告配置项的当前状态。
测试人员特别关注的配置项是测试流程的输入和输出，包括前几小节提到的所有测试文档，以及被测试的项目（如系统及其组件）和相应的测试基础（如需求规格）。
在可能的情况下，为了能够重现问题以便对其进行进一步分析，配置管理系统应支持在未来的任何时候，在与之前相同的条件下重复测试。可接受的做法是，将某些类型的测试（如单元测试）排除在可重复性要求之外，只要将例外情况记录在案即可。
参考资料
软件测试精品书籍文档下载持续更新 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，注明：软件测试
4.3.5 工具支持
ISO/IEC/IEEE 29119-2 中定义的测试管理和动态测试过程中描述的许多任务和活动，以及 ISO/IEC/IEEE 29119-4 中描述的测试技术的各个方面，均可使用工具支持（通常称为测试工具）。下面的列表举例说明了测试工具所涵盖的一些领域：
测试用例管理
测试监控
测试数据生成
静态分析
测试用例生成
测试用例执行；
测试环境的实施和维护。
测试自动化工具种类繁多。这些工具可以是内部开发的，也可以从商业渠道或开源社区获得。
4.3.6 过程改进和测试
过程改进包括确定和实施对组织流程的更改，使其更有效、更高效地实现组织的业务目标。
测试过程与过程改进在两个方面相互影响：
a) 测试提供过程的信息可作为流程改进变革的依据；
b) 测试过程本身也是流程改进的对象。
当测试为过程改进提供信息时，信息通常来自经验教训总结活动，这是测试完成过程的一部分。
当测试流程得到改进时，它可以是涵盖所有开发、测试和支持过程的更广泛计划的一部分，也可以是针对测试过程的更局部的计划。
4.3.7 测试度量（Test metrics）
为有效控制测试流程，可使用度量来进行监控。应谨慎选择指标，以便收集到控制流程所需的信息，避免收集不必要的指标。
可用于测试的指标举例如下：
残余风险：已识别风险的数量与已处理风险的数量相比；
累计缺陷：打开的缺陷数量与关闭的缺陷数量的比较；
测试覆盖率：已执行测试覆盖的需求数量；
缺陷检测百分比：测试中发现的缺陷数量与总体发现的缺陷数量的比较。
4.4 测试的设计和执行
4.4.1 测试模型
测试模型是测试设计的基础–它是测试项目所需行为的模型，用来生成测试用例，以达到模型所要求的覆盖水平。下图显示了测试设计所涉及的主要测试工件之间的关系，其中测试模型是关键部分。
测试模型所使用的符号是通过考虑所需的测试覆盖率来选择的；这表明了测试覆盖项的形式–这些覆盖项被纳入测试模型。例如，假设所需的测试覆盖范围是测试项目可能处于的状态之间的所有有效转换。测试覆盖项就是这些有效的转换，因此需要选择一个测试模型来清楚地显示这些转换。此时，测试人员可以选择不同的状态模型符号（如状态转换图或状态表）。
测试策略中规定了所需的测试覆盖率，作为测试完成标准之一。所需行为在测试基础中定义，随后在测试模型中建模。测试模型用于确定明确的测试覆盖范围项目，然后生成涵盖这些项目的测试用例。测试程序（测试脚本）包含测试用例序列，多个测试程序组成一个测试套件。
ISO/IEC/IEEE 29119-2 规定了如何使用测试模型生成测试用例（以及随后的测试程序）。ISO/IEC/IEEE 29119-3 规定了测试模型的文档（测试模型规范）。ISO/IEC/IEEE 29119-4 规定了测试设计技术对测试模型的使用。
4.4.2 基于模型的测试
基于模型的测试（MBT）使用模型来系统地自动生成测试用例。对于 MBT 来说，模型是被测项目所需行为的正式或半正式表示。可以为整个软件系统或系统的一部分开发模型。使用 MBT，测试人员可以设计和实施不同抽象级别的测试。MBT 语言和符号可以在语法上正式定义，在某些情况下也可以在语义上正式定义。通过使用 MBT 工具支持环境，测试用例可以从模型中快速生成并自动执行。因此，MBT 可以支持自然语言和人工执行所无法支持的改进测试。
4.4.3 脚本测试和探索性测试
4.4.3.1 概述 根据每个项目的需要，测试设计和执行可采用多种方式：
脚本测试，可以是
手动
自动；
探索式。
在实践中，通常会结合使用，因为脚本化测试有助于达到所需的测试覆盖率水平，而探索性测试则可在需要时发挥创造性并快速执行测试。
4.4.3.2 脚本测试
在脚本测试中，测试用例被记录下来（如记录在测试管理工具或电子表格中），然后可手动执行或使用自动测试工具自动执行。每个测试用例所需的详细程度（如测试步骤和预期结果的粒度）通常取决于项目的文档要求，而文档要求通常是在测试计划期间决定的（见 4.2）。详细程度还取决于测试是否是自动的（自动测试通常要求更详细）。对于人工测试，详细程度也取决于测试执行者的知识、经验和能力（包括他们的系统和测试领域知识）。
4.4.3.3 探索性测试
在探索性测试[16]中，测试是在测试人员与测试项目交互和了解测试项目的过程中即时设计和执行的。会话表通常用来安排探索性测试会话（例如，设定测试的重点和时间限制）。
例如，设定每个测试环节的重点和时间限制）。这些会话表还用于记录测试内容和观察到的异常行为。探索性测试通常不完全是无脚本的，因为高层次的测试方案（有时称为 “测试想法”）通常会记录在会话表中，为探索性测试会话提供重点。
4.4.4 测试设计技术
在脚本测试和探索性测试中，通常使用测试设计技术（如 ISO/IEC/IEEE 29119-4 中定义的技术）来创建测试。在脚本测试中，测试的设计通常是系统和有条不紊的，一次只使用一种技术，如 ISO/IEC/IEEE 29119-4:2021，附件 B 和 C 中的示例。在探索性测试中，通常使用相同的测试设计技术，但其应用通常更加非正式，各种技术交错使用，测试文档较少。
在探索性测试中应用测试设计技术的目的通常是针对特定类型的缺陷，”覆盖 “需求、规格或源代码的特定方面。与脚本测试中使用测试技术的主要区别是，各种技术都用于生成测试用例，以测试测试项目的特定方面，因此一种技术可能用于生成一个测试用例，然后另一种技术用于下一个测试用例，以探索测试项目的不同方面。
无论测试是脚本测试还是探索性测试，通常都需要各种测试设计技术来适当覆盖任何系统。
4.4.5 基于经验的测试
4.4.5.1 概述 基于经验的测试基于以下方面
以往的测试经验
特定软件和系统的知识
领域知识；
以往项目（组织内部和行业）的衡量标准。
基于经验的测试实践通常不依赖大量文档（如测试程序）来执行测试。从脚本测试到非脚本测试，这些基于经验的测试实践主要是非脚本测试。使用这类测试方法可能意味着只能实现符合 ISO/IEC/IEEE 29119-2 标准的定制测试。
ISO/IEC/IEEE 29119-4 描述了基于经验的错误猜测测试设计技术。其它基于经验的测试方法包括（但不限于）探索性测试（见 4.4.3.3）、巡回测试、攻击测试和基于检查表的测试。
4.4.5.2 导览
参观提供通用的测试建议，引导测试人员参观应用程序的路径，就像导游带领游客参观大城市的地标一样。导览的目的不是指导用户选择哪些测试输入值，而是为测试设计提供更高层次的指导。例如，导览可以建议在两小时的探索性测试中应重点关注应用程序的哪些方面。
“地标之旅”就是用于探索性测试的一个例子。在这个游览过程中，测试人员选择关键功能，决定访问它们的顺序，然后从一个地标到另一个地标探索应用程序，直到访问完所有地标为止。
4.4.5.3 攻击
攻击是根据其利用特定故障模型的可能性来识别的。故障模型是一种思考软件如何以及为何会出现故障的方法。故障模型可以是基于行为的，这样测试人员就可以寻找有效的测试（攻击）来识别软件故障。例如，在进行专业测试时，可以使用特定的故障模型来设计可能导致安全受损的攻击（如用于安全测试）。
安全攻击的一个例子是阻止访问软件库。这种攻击基于一种故障模型，即如果应用程序所依赖的软件库无法加载，应用程序就会出现不安全行为–开发人员假定对这些库的调用每次都能正常工作，而没有对无法正常工作的情况作出任何规定。
4.4.5.4 基于检查表的测试
基于核对表的测试是测试人员根据预先确定的项目清单生成测试。
清单上的项目可基于个人经验、常见缺陷和感知风险等。基于核对表的测试通常侧重于特定的质量特性（如用户界面核对表）。核对表应定期审查和更新，以免过时，并继续针对最重要的缺陷。核对表可以关注不同层次的细节，根据核对表生成的测试可以是脚本化的，也可以是非脚本化的。
核对表的来源多种多样，例如，可能是测试人员个人或组织的专用核对表，可能是网络共享核对表，也可能是监管标准的一部分。
4.4.6 重测和回归测试
当开发人员修复缺陷时，要进行测试以检查修复是否成功；这称为重新测试或确认测试。在大多数情况下，重新测试会使用与修复代码相关的原始测试用例，但有时也会补充新的测试用例，以提高覆盖率。
当开发人员对现有软件进行修改（如修复缺陷、增加功能、改变非功能特性）时，要进行测试以检查软件的原始行为（修改后应保持不变）是否受到修改的不利影响；这就是所谓的回归测试。
4.4.7 手动和自动测试
测试用例既可由人工测试执行者手动运行，也可由测试自动化工具执行。
决定进行手动或自动测试取决于多种因素，包括以下几点。
测试用例可能被重新执行的次数。一个常见的启发式方法是，如果一组测试用例要执行 5 次或更多次（例如，在回归测试的多个周期中），那么自动测试通常具有成本效益。测试用例重新运行的次数取决于所使用的生命周期方法（例如，传统的生命周期可能要求不经常进行回归测试，而敏捷项目通常要求至少在每个冲刺阶段进行回归测试，而使用持续集成（CI）的项目可以在每次构建或每天重新运行一次测试用例）。因此，在敏捷或 CI 方法中，回归测试用例的重新运行次数极有可能超过 5 次。
项目测试人员的能力，因为大多数测试自动化工具通常要求测试人员具备一定的编程能力。
用于获取和试用测试自动化工具的预算和时间。
用于聘用和/或培训测试人员使用测试自动化工具的预算。
测试设计和执行自动化有三种常见方法。它们是
捕获-重放
数据驱动
关键字驱动（详见 ISO/IEC/IEEE 29119-5）。
4.4.8 连续测试
在连续测试中，测试执行是通过自动化流程启动的，该流程可按需进行，如每晚将代码检查到中央存储库，或每当构建部署到测试或生产环境时。持续测试通常在持续集成（CI）和持续交付（CD）的背景下进行。
应用持续测试和持续集成可实现早期测试。
4.4.9 背对背测试
在背对背测试中，系统的另一版本（如已存在的、由不同团队开发的、使用不同编程语言实现的、可执行的设计模型）被用作对比系统，从相同的测试输入生成预期结果进行对比。
因此，背靠背测试不是一种测试用例生成技术，因为测试输入不会生成。
只有预期结果是由功能等效系统自动生成的。当与生成测试输入（随机或其他）的工具一起使用时，它就成了执行大容量自动测试的强大方法。
4.4.10 A/B 测试
A/B 测试是一种统计测试方法，可让测试人员确定两个系统中哪个表现更好–有时也称为分割运行测试。它通常用于数字营销（如在面对客户的情况下，它通常被用于数字营销（例如，寻找获得最佳响应的电子邮件）。例如，A/B 测试通常用于优化用户界面设计。例如，用户界面设计师假设，将 “购买 “按钮的颜色从当前的红色改为蓝色，销售额就会增加。于是，设计人员创建了一个带有蓝色按钮的新变体界面，并将这两个界面分配给不同的用户。对两个变体的销售率进行比较，在统计使用次数的情况下，可以确定假设是否正确。这种形式的 A/B 测试需要统计大量的使用次数，可能会很耗时，尽管可以使用工具来支持它。
A/B 测试不是测试用例生成技术，因为测试输入不会生成。A/B 测试是利用现有系统作为部分准则来解决测试准则问题的一种手段。
4.4.11 基于数学的测试和模糊测试
当测试项目所需的行为、输入空间或输出空间能被足够详细地描述（如使用形式化语言）时，基于数学的测试实践可用于规划、设计、选择数据和设置输入条件。正式规范语言可用于支持基于模型的测试，源代码的正式分析可用于识别潜在风险并为测试策略提供信息。
数学是 ISO/IEC/IEEE 29119-4 中描述的一些测试用例设计技术（如随机测试用例选择）的基础，也可用于支持组合测试方法。同样，模糊测试使用工具生成大量测试输入数据，然后使用简单的测试oracle（如检查程序是否崩溃）对程序进行测试。模糊测试在发现缺陷方面的效果令人惊讶，但与随机测试一样，测试覆盖率很难测量。当需要对模糊测试的置信度进行测量时，可以使用统计方法，根据测试运行的次数来确定测试结果的重要性。
由于使用数学方法通常可以生成大量输入，因此通常需要自动化工具。
4.4.12 测试环境
测试环境的要求应作为测试计划的一部分加以考虑，以便在测试执行前获取、设置、 配置和验证所有必要的组件，并在执行后进行清理。测试环境要求可包括
软件 – 如操作系统、程序和其他应用程序；
服务 – 如虚拟或云服务；
硬件 – 如服务器和终端用户台式电脑、笔记本电脑和移动设备；
网络–如交换机、路由器、特定速度的网络连接；
接口–如连接内部、虚拟或第三方系统的接口；
外围设备–如打印机、扫描仪和卡片扫描仪；
数据 – 包括存储在数据库中的数据；
测试工具–如测试管理和执行工具；
可用性–如每天的工作时间和设置时间。
测试环境要求应记录在案，以便沟通和理解。
如果测试环境是由另一个团队建立的，则该团队应编写测试环境就绪报告，以确认环境已按要求建立、配置和验证。对于单独的小组，应签订服务水平协议（SLA），明确规定何时以及如何解决环境问题。
4.4.13 测试数据管理
应确定测试数据的设置和清理要求，以确保系统处于能够执行和重新执行每个测 试案例的状态。例如，在测试信用评级系统时，需要客户的历史银行数据来确定客户的信用分数。
私人数据可能需要进行匿名化或净化处理，以帮助满足数据隐私法规的要求。
测试数据的设置、清理和消毒可手动进行，也可使用脚本自动进行。测试数据和自动脚本应进行版本控制，并置于源控制之下。
4.5 项目管理和测试
项目管理是指用于计划和控制项目进程的支持流程，包括整个项目中的测试管理。如图 9 所示，无论各流程由谁负责，项目管理和测试管理流程都密切相关。
测试活动的估算、风险分析和时间安排应与整体项目规划相结合。项目计划是项目管理过程中的一个信息项目，因此也是测试管理过程的一个输入。
在测试过程中，测试经理会对从详细测试活动中收集到的测量结果进行分析，并传达给项目经理，以便在项目背景下进行分析。这可能会导致项目计划的变更、项目计划的更新和适当的指令，这些都需要向测试人员发布，以帮助确保测试与项目计划保持一致。
4.6 沟通和报告
测试人员应及时向利益相关者提供适合受众的相关信息。这些信息可为开发人员提供所需的修改细节，提醒项目经理注意进度和预算，或向外部各方通报测试结论。
测试计划将规定测试任务报告的性质和时间。持续时间较长的任务可能需要定期报告状态。状态报告可说明是否需要调整先前计划的优先级、时间表或资源分配。完成报告说明测试的执行情况和结果。
4.7 缺陷和事件管理
测试失败作为可能存在缺陷的迹象，需要系统地进行调查，以确定缺陷是存在于被测系统中，还是存在于测试本身（这可能表明需求有缺陷或缺失）。与预测行为不同的测试结果被视为一个事件，需要记录、调查并在可能的情况下加以解决。缺陷可通过动态和静态测试以及分析、验证和确认等其他活动发现。
附件 A系统特征与测试 – 示例
A.1 概述
每个系统都可以用一组描述系统某些方面的特征来分类。如果仔细选择这些系统特征，就可将已知适合许多（但非所有）情况的特定测试方法与这些特征联系起来。
本附件简要介绍了一些系统特征（还可以确定更多的特征）和相关的测试方法。如果测试人员能确定哪些系统特性适用于他们正在测试的系统，那么他们就应考虑针对该特性列出的专门测试是否适合纳入其测试策略。这应是对基于风险的测试（见 4.2）的补充，而不应被视为替代。
当系统特性有 “关联特性 “时（如：实时性是闭环的关联特性），适用于关联特性的测试也可能适用（如：为实时系统建议的测试也应适用于闭环系统）。
A.2. 人工智能（AI）
A.2.1 说明
人工智能有多种形式（如分类、优化、规划），并用于解决一系列问题（如搜索引擎、 图像识别、语音识别、理解和合成）。无论人工智能系统采用哪种形式，通常都很复杂，难以理解。它们在本质上通常也是概率性的，这意味着大多数基于人工智能的系统都是非确定性的。
A.2.2 相关特征
典型的相关特征是科学/技术特征（见 A.14）。
A.2.3 专门测试
背靠背测试和变形测试都解决了非确定系统的测试问题。
基于人工智能的系统（如大规模并发的神经网络）具有独特的计算架构。
这意味着，如果使用基于结构的测试，就需要使用特定的结构覆盖标准（如神经元覆盖）。
与人工智能相关的不同架构和开发流程意味着测试人员（或担任测试角色的数据科学家）需要具备专业技能。
有关人工智能系统测试的更多详情，请参阅 ISO/IEC TR 29119-11。
A.3 自主系统
A.3.1 描述
自主系统涉及广泛的应用领域，其实施技术也有很大差异。自主系统是指不受人类控制而持续工作的系统。这一定义意味着自动系统和自动化系统也是自主系统的一种形式。如表A.1所示，自主系统可按其不同程度的灵活性加以区分。
A.3.2 相关特性
典型的相关特性是实时性（见 A.11）。
A.3.3 专门测试
自主性测试的一种方法是试图迫使系统放弃自主行为，并要求系统在未指定的情况下进行干预（消极测试的一种形式）。消极测试也可用于试图 “愚弄 “系统，使其在要求干预时认为自己在控制之中（例如，通过在其运行包络的边界上创建测试情景–建议将边界值概念应用于情景测试）。
A.4 定制系统
A.4.1 描述
定制系统是为特定客户和目的而制造的（即它们不是 COTS 系统–见 A.6）。
A.4.2 相关特性
没有相关特性。
A.4.3 专门测试 为特定客户（和用户）进行验收测试。
A.5 闭环（Closed loop）
A.5.1 描述
系统在试图达到预期状态的同时，也以反馈的形式监控当前状态（例如，加热控制器将控制加热以保持预期的输入温度，同时也监控当前温度以帮助其达到目标）。
A.5.2 相关特性
典型的相关特性是实时特性（见 A.11）。技术/科学特性通常也与闭环系统有关（见 A.14）。
A.5.3 专门测试
在测试闭环系统时，测试人员应考虑先前的测试输入如何产生反馈，而反馈又是被测 系统的输入。这与测试开环系统不同，在开环系统中，所有输入都由测试人员直接控制。
在闭环系统准备好在其完整的运行环境中进行测试之前，闭环系统的测试是特殊的，因为需要工厂和环境模型来模拟根据其输出对系统的反馈。工厂模型模拟控制系统对受控工厂（如发动机、变速箱、制动器）的作用结果，环境模拟控制系统对更广泛环境的作用结果。
A.6 现成的商用系统（COTS）
A.6.1 说明
为出售给许多客户而设计的系统（如收缩包装软件，而不是定制软件）。
A.6.2 相关特征
没有相关特征。
A.6.3 专门测试
了解未知买家的操作环境可能比较困难，因此通常采用 alpha 和 beta 测试。
A.7 嵌入式
A.7.1 描述
嵌入在较大系统中的软件系统，通常提供较大系统的控制部分，如机械臂控制器、健身追踪器或飞机上的航空电子系统。嵌入式系统是为特定目的而开发的，通常使用比通用计算机功耗更低的特殊加固型处理器和硬件，并为此目的进行优化。
A.7.2 相关特性
嵌入式系统通常具有实时特性（见 A.11）。
A.7.3 专门测试
嵌入式软件将在某些时候与嵌入式系统的专门目标硬件集成并在其上进行测试。
有些嵌入式系统将在恶劣的环境中运行。在这种情况下，可能需要使用仿真技术在极端条件下进行测试。
有些嵌入式系统由于运行环境的原因（如作为核反应堆的一部分），或由于许多系统的维修费用无法收回（如洗衣机控制器），因此系统上线后的维修费用可能会很高。这种高昂的修复成本往往意味着需要进行严格的测试。
由于嵌入式系统通常与专用硬件交互，故障注入测试可用于测试系统对硬件故障的响应。
嵌入式系统通常在尺寸、重量和成本方面都有严格的限制，这意味着它们通常只配置了能支持系统的最小内存量。在这种情况下，可适当进行内存泄漏测试。
A.8 适合和遗忘
A.8.1 描述
适合和遗忘系统是指在其运行寿命中不会（或不能）更新的系统（如深空探测器、水下系统）。
A.8.2 相关特性
嵌入式典型相关特性（见 A.7）。
A.8.3 专门测试
由于在系统投入使用后无法修复任何缺陷，对 “即装即忘 “系统的测试必须更加严格。
故障注入测试可用于测试系统在出现内部和外部故障时的稳健性。
A.9 物联网（IoT）
A.9.1 描述
基于互联网技术的可扩展系统，允许具有不同计算能力的各种设备（如传感器、处理或聚合节点，或许还有执行器）进行通信。通信协议和距离各不相同，大多数物联网系统在三个层面上进行通信：设备之间、边缘（云）和跨云。物联网系统可能由来自不同供应商的许多设备组成，因此通信标准化和所提供功能的规范尤为重要。
物联网系统通常分为消费物联网（如可穿戴设备、联网汽车）和工业物联网（如智能零售、交通运输）。
A.9.2 相关特性
部分嵌入式特性有时与物联网系统有关（见 A.7）。例如，智慧城市物联网系统通常使用许多嵌入式子系统，这些子系统向非嵌入式中央系统报告。
A.9.3 专门测试
在单个物联网系统中有多个交互设备时，可使用兼容性测试。
互操作性测试可用于测试来自不同供应商的各种设备能否相互通信和相互理解。
物联网系统通常有能力更换现有设备并向系统中添加新设备，因此可扩展性测试可能很有用。
由于需要遵守通信标准，因此接口测试非常重要。
工业物联网往往会使用大量数据，这可能会引起一般数据隐私法规（GDPR）的关注。
的担忧。这可能会影响测试，因为必须使用经过消毒的数据。
物联网系统通常还存在安全问题，因此需要进行安全测试。
A.10 移动系统
A.10.1 说明
移动系统通常是便携式计算设备，没有通信或电源的物理连接（如通常由电池供电）。由于便携性的需要，移动设备通常小到可以随身携带。移动设备的例子包括智能手机、媒体播放器、智能手表和智能卡。
A.10.2 相关特性
嵌入式典型相关特性（见 A.7）。
A.10.3 专门测试
经常使用模拟网络连接中断（如 WiFi、蜂窝电话、蓝牙）的测试。
基于功耗和电池故障的测试通常适用于电池供电设备。
互操作性测试有助于确认应用程序可在多个操作系统和设备上运行。
A.11 实时
A.11.1 说明
实时系统在有限的时间范围内对外部事件作出反应（如汽车防撞系统）。工资单系统通常不是实时系统，因为它可以现在运行10 分钟后运行或通宵运行。
实时系统通常采用并发方式来实现实时性能。
A.11.2 相关特性
没有相关特性。
A.11.3 专门测试
需要进行专门测试，以检验因并发设计或实施缺陷而导致的故障。
性能测试通常用于确认是否满足实时限制。
A.12 法规
A.12.1 描述
在某些领域，已有法规要求系统符合特定的要求。法规可能由政府或行业自律。对系统进行监管可能是为了达到一定的安全水平（见 A.13），也可能是为了执行旨在实现各种目标的法规，如数据隐私权（如《全球数据隐私权法案》）。
A.12.2 相关特性
没有相关特性。
A.12.3 专门测试
审核通常用于验证是否符合标准。
法规通常是软件测试要求的良好来源。
A.13 与无害有关的
A.13.1 描述
与安全无害的系统是指一旦发生故障，会危及人的生命、健康、财产或环境的系统。例如飞行控制系统、医疗设备和消防系统。
这些系统通常会产生一系列与确保安全和远离危险相关的特殊风险。这些风险通常是在开发的早期阶段通过安全/危险分析确定的。
与安全相关的系统通常需要符合相关的安全标准，如 IEC 61508（电气/电子/可编程电子安全相关系统的功能安全）。
A.13.2 相关特性
对典型的相关特性作出规定（见 A.12）。
A.13.3 专门测试
故障注入测试可用于测试系统的错误处理（如检查单个故障不会导致整个系统失效）。
测试可采用模拟方式，以测试那些可能过于危险的情况。
A.14.科学/技术
A.14.1 描述
科学/技术软件支持工业和学术界的研究和开发，通常包含复杂的算法。典型的系统收集、管理和分析数据，模拟物理世界，并支持结果的可视化。
科学/技术软件通常面向科学家终端用户，他们使用软件在自己的特定领域进行科学研究–因此，这些软件大多是针对特定领域的。
A.14.2 相关特性
没有相关特性。
A.14.3 专业测试
复杂算法的测试通常需要专业领域的知识。
对于复杂的科学/技术算法，通常使用可执行模型进行早期测试。
由于执行算法的独创性和复杂性，可能难以计算预期结果，因此可采用变形测试。
A.15 网络
A.15.1 描述
网络应用程序基于客户机-服务器结构，客户机在网络浏览器中运行，后台通常包括数据库。例如，网上零售系统、网上银行和网上办公软件。
A.15.2 相关特征
典型的相关特征是移动性，网站经过优化，可通过移动设备使用（见 A.10）。
A.15.3 专门测试
由于任何互联网用户都可使用基于网络的软件，因此可能会出现与残疾人使用应用程序有关的问题。这些问题通常通过可访问性测试来解决。
由于应用程序易于访问，安全测试通常很重要。
在网站吸引大量并发用户的情况下，负载和响应时间测试可能很重要。
附件 B 测试角色
测试行业中的不同角色有各种不同的名称，因此本文件并不提供一份详尽的不同角色和职责清单，旨在代表全球测试行业。相反，本文件概述了以下角色，只要能胜任该角色的人员将负责完成本文件概述的测试过程的某些方面。以下每个角色都可能由一个以上的人负责。
测试架构师
为计划和项目确定测试战略、测试环境和测试计划。明确组织测试要求，帮助确保符合这些要求。
测试经理
开发、管理并帮助确保符合测试管理流程。测试经理还负责规划和控制动态测试流程。
测试设计师 开发测试设计工件。
MBT 建模员
以模型的形式制定正式的测试规范，用于生成测试用例，作为基于模型的测试的一部分。
测试自动化员
在测试自动化框架内执行测试用例/脚本。
测试员
开发测试成果并完成与动态测试流程相关的过程。
测试分析师
开发工具和/或分析测试结果的正确性和问题。
专项测试
执行特定质量特性的测试，如可用性、可访问性、安全性、性能。
在现实中，本文档中概述的流程可能会由不同职称的人员完成。
声明：文中观点不代表本站立场。本文传送门：https://eyangzhen.com/422100.html
