标准规范下载简介

GB／T 38634.1-2020 系统与软件工程 软件测试 第1部分：概念和定义.pdf

附录C （资料性附录） 不同生存周期模型中的测试

本附录给出了调试如何适用于不同的软件并发生存周期模型的示例。对于一个给定的项目，需要 确定必要的开发阶段和/或活动，以及在开发生存周期过程中这些阶段和/或活动的相互关系。开发阶 设及其关系的集合称为开发生存周期模型”，或者更简单地称为“生存周期模型”。 多年来，软件行业已经使用了许多生存周期模型。这里按字母顺序（和它们的出现顺序相反）对典 型生存周期模型进行了分类，但这不是一个完整的列表： 敏捷； 一演化； 一顺序（即漆布模型）。 在所有生存周期模型中执行的开发活动或多或少是相同的；主要区别在于它们范围的定义、产生的 文档数量和性质以及它们在开发生存周期中重复的频率。 注：本部分的目的不是对不同的生存周期模型进行标准化，而是建立测试周境以勘于实施这此生存周期

C.2.1敏捷开发原则

T／CECS 541-2018 聚苯乙烯泡沫（EPS）复合装饰线应用技术规程(完整正版、清晰无水印).pdf图C.1Scrum（敏捷）项目生存周期示例

本标准中定义的测试过程模型可以应用于遵循敏捷开发模型项目中执行的测试，

C.2.2敏捷开发中的测试管理

图C.2敏捷冲刺示例

在冲刺展示会上向客户展示了冲刺的可交付成果，团队有机会向利益相关方展示他们所创建的内 容。冲刺的最后一项活动是冲刺回顾，团队评审他们的表现如何，并确定在未来的冲刺中可以进行哪些 收进。因此在Scrum框架内集成了过程改进。 在整个冲刺期间，每天开始时都会举行每日站会，以确保整个团队都了解：已经做了代么，当天将做 十么，以及团队面临的任何同题。他们还可以让敏捷教练决定需要移除哪些障碍以使团队更高效地 前进。 敏捷项目中的考虑的关键因素是管理回归缺陷的风险（因为每个冲刺都基于之前的冲刺），并管理 落求变化的本质及其对测试工件的影响。测试自动化通常用于管理回归风险，而探索性测试可用于管 理缺乏详细需求的影响

C.2.3敏捷开发中的测试子过程

测试活动是敏捷开发项目的一个集成部分，如图C.2所示，测试在整个冲剩中持续进行。可以使用 本标准中的过程来定义和执行测试子过程，以测试用户故事和正在交付的演进系统。 冲刺团队使用的典型测试实践有： 一测试驱动开发（TDD)，这是在编写代码之前为代码编写测试。测试是基于用户故事，可由测 试人员和开发人员共同开发。这些测试通常使用自动化组件测试工具来实现。这可能导致

TDD被视为种编程形式。 自动化构建和持续集成的测试，它用在当系统在签入代码时不断更新和回归测试。用于确保 及时识别和纠正集成和回归向题。 一所有质量特性（即功能和非功能）的系统测试都是针对用户故事和现有的任何高级别需求进行 的。系统测试之后通常会进行验收测试，验收测试时应包括最终用户的参与，以确保交付的功 能满足他们的需求。 一通常需要回归测试来确定当前冲刺中的任何变化对产品的现有功能和特征没有负面影响。 在“理想”的冲结束时，这些特征已经准备好供用户使用，这意味着上述测试都在冲刺中执行 阳图C.2所示）。实践发现，在许多项目中要做到这点很困难，这导致会采用折表的替代方法。例如， 并行但又互补的方式执行测试，或在一个临时的、以测试为主要目标的冲刺中执行测试。

C.3.1顺序开发原则

顺序生存周期模型存在时间最长，并且仍然被广泛使用。基本（和原始的）顺序模型称为瀑布模型， 它由开发阶段描述，这些开发阶段按顺序排列在测试阶段之前，以最终的操作阶段结束。 顺序生存周期模型的特点是，除了后续阶段的反绝对必要之外，不包括明确的重复的阶段。 本标准中定义的测试过程模型可以应用于遵循顺序生存周期模型开发中的测试

C.3.2顺序开发的测试管理

组织级测试策略应该反映出开发遵循顺序开发模型。在使用包括顺序在内的不同项自的混合开发 模型进行开发的组织中，通常会有一个或多个特定的组织级测试策略，通盖所使用的开发模型。组织级 测试策略应该使用它所涵盖的项目类型所使用的词汇表；此外，组织级测试策略的内容取决于其涵盖的 项目和产品的风险概况，而不是所使用的开发模型。 顺序项目由项目经理管理。在大多数项目中，还定义了开发经理和测试经理的角色。根据项目的 规模，这些角色可以由不同的人担任，或者两个或所有角色可以由同一人担任。 虽然测试计划应该在项目过程中制定，但在顺序开发中的这些计划是为整个项目而制定的。顺序 开发项目可能规模相对较大，并且在开始时可能无法为整个项目以相同详细级别进行计划。此外，还应 制定个项目测试计划，这通常以单个文档形式出现，但可能是整体项目计划的一部分。如果在项目测 试计划中指定要执行的测试子过程，可以生成单独的测试子过程计划。这些计划通常在顺序开发中要 正式记录。

C.3.3顺序开发中的测试子过程

C.3描述的用于演化开发的测试子过程也与顺序项目中的测试相关，虽然它们只执行一次（只有一 饮通过顺序开发模型）。

图C3顺序开发生存周期模型中测试子过程示

注意，图C.3未按比例绘制；所示的测试子过程的相对规模与测试子过程的实际规模无关。例如， 所用时间、工作量或成本。 定义了架构设计测试、详细设计测试和代码测试。对于其中每一项，相应的开发阶段可以根据已完 成的测试结果签署关闭，即当所有详细的开发项都单独进行了测试。 对于编码阶段，有两个不同的测试子过程。第一个是源代码测试子过程，由源代码的静态测试构 成。第二个是组件测试，由可执行代码或可解释代码的动态测试构成。这些测试子过程可以结合，组件 的动态测试依赖于成功的源代码静态测试。 集成阶段的最终结果是一个完整的系统。此时，假设系统测试的执行活动已经根据需求进行了计 划和准备，那么就可以开始系统测试。 这里所提的测试子过程的示例将在附录D中进一步说明

C.4.1演化开发原则

演化开发基于送代和增量交付的两个基本原则。送代充许开发人员将系统开发为一系列较小的部 分，然后他们可以根据对开发的产品以及开发实践的反馈，来改进下一次送代。与传统的顺序周期相 比，迭代能够更早地处理更高的风险，从而增加了处理风险的时间。随着增量开发的进行，每次送代的 结果都会发布给客户，这意味着用户可以在一系列的交付中获得了系统，并且系统具有越来越多的 功能。 送代由所有或部分标准开发活动组成。如果送代的结果交付给用卢，送代将包括验收阶段，否则验 收阶段通常只在最后一次送代中执行。 图C.3显示了顺序生存周期。演化开发生存周期可以表示为许多独立的顺序生存周期，每个生存 周期都为正在开发的系统增加了更多的能力。 本标准中的测试过程模型可以应用于遵循演化开发模型开发中的测试。

C.4.2 演化开发的测试管理

组织级测试策略应该反映开发遵循演化开发模型这 生便用包活演化任内的 开发模型进行开发的组织中，通常会有一个或多个特定的组织级测试策略，涵盖所使用的开发模

组织级测试策略应使用其涵盖的项目类型使用的词汇表，但除此之外，任何组织级测试策略的内容主要 反决于其涵盖项自和产品的风险概况（尽管所使用的开发模型的类型可能会产生测试策略应解决的其 他类型的风险）。 演化开发项目由项目经理管理。在大多数项目中，还定义了开发经理和测试经理的角色。根据项 目的规模，这些角色可以由不同的人担任，或者由同一人担任两个或所有角色。 演化开发中为整个项目和每次送代制定计划。宜制定项目测试计划，可以采用单个文档的形式，也 可以作为整个项自计划的一部分。还可以生成较小的送代测试计划，指定要在送代中执行的测试。计 创可能在演化开发过程中或多或少地正式记录，但它们通常会被保存在文档和/或计划工具中。送代测 试计划和相关子过程测试计划通常会被重复使用，并在送代和选代之间进行必要的修正。 在选代过程中监测测试进度，持续采取必要的纠正措施，并将更新的测试计划传达给利益相关方。

试计划和相关子过程测试计划通常会被重复使用，并在代和送代之间进行必要的修正。 在选代过程中监测测试进度，持续采取必要的纠正措施，并将更新的测试计划传达给利益相关方。 C.4.3演化开发中的测试子过程 在每次送代中，可以测试工作产品和完成的系统。可以使用本标准中的过程来定义和执行测试子 过程，以测试可执行的工作产品和正在生产的系统。 本例中第个开发阶段是需求工程，其中指定了业务、功能/非功能以及系统需求。图C.3只显示 了与第一阶段（需求测试阶段）相关的测试子过程，以避免图像混乱。被指定的需求测试可以看作由静 态测试组成的子过程。这个测试子过程的形式取决于产品的风险概况，但由于需求是选代工作的基础， 因此应该倾向于选择更正式的静态测试设计技术。 可以为两个设计阶段以及编码阶段定义类似的测试子过程。图C.3所示的开发模型示例可能 包括： 一架构设计测试； 一详细设计测试； 一源代码测试。 这些测试子过程通常对应延伸到相关的开发阶段的大部分过程，它们集中于一种类型的测试项，例 如需求，并包括测试项的不同测试方法，例如走查和技术评审。在根据测试子过程计划，在测试所有开 发的需求之前，需求测试子过程不会完成。通常有一个或多或少的正式里程碑标志着需求工程阶段的 结束，这通常取决于需求测试子过程的结果。 类似地，设计和源代码测试于过程直到根据测试子过程计划对所有开发的测试项进行了测试，才可 能结束，并且相应的开发里程碑将取决于测试子过程的结果。 验收测试于过程如图C.3所示。如果在本次送代中，需求发生重天变化的风险低于启动测试于过 程的益处，则验收测试子过程中的计划和准备活动可以启动。测试设计将揭示需求中的缺陷，从而有助 于提供关于需求的信息。对涉及动态测试的其他开发里程碑，可以定义类似的测试子过程。对于 图C.3所示的开发模型示例，这可能包括以下与验收子过程类似的子过程： 一组件测试； 一集成测试； 一系统测试。 在图C.3的示例中，还定义了性能测试。特定的测试子过程可能被定义为涵盖需求的特定类别或 需求描述的系统的特定区域，通常取决于系统的风险概况。这种特定的测试子过程可能延伸到许多开 发阶段，因此可能有各种测试项和相关的测试依据、测试职责、技术和环境，以及测试目标、完成标准和 计划，尽管测试子过程只有一个重点，在这种情况下，性能需求以及它们如何在系统中描述、设计和 实现。 上面描述的所有测试都可以在后续达代中执行。 由于产品不断扩展，因此在每次送代中应对之前已接受的内容进行广泛的回归测试。应为每次送

C.4.3演化开发中的测试子过程

代定义回妇测试子过程。回归测试子过程可以包括送代中扩展的所有项的回归测试，包括需求、设计、 原代码和系统，或者可以根据风险概况只包含其中的一部分。对个项的所有扩展类型，还可以单独定 义回归测试子过程，以便从迭代到选代的回归测试中获得更大的灵活性

代定义回归测试子过程。回归测试子过程可以包括送代中扩展的所有项的回归测试，包括需求、设计、 原代码和系统，或者可以根据风险概况只包含其中的部分。对一个项的所有扩展类型，还可以单独定 义回归测试子过程，以便从迭代到选代的回归测试中获得更大的灵活性

附录D （资料性附录） 详细的测试子过程示例

本附录列举了测试子过程的示例。这些示例以字母表的顺序排列。该列表只显示了一些示例；在 特定的测试项目中可能需要许多其他的特定子过程。 示例如下： 一验收测试： 详细设计测试； 一集成测试： 性能测试； 回归测试； 复测； 一故事测试； 系统测试； 一组件测试。 需要注意，回归测试和复测已经被包含在特定的测试子过程中。这些可以适当地包括在任何其他 测试子过程中。 每个示例的测试子过程的描述包括： 测试子过程的目标； 一计划的测试子过程内容，要执行的静态和动态测试过程。 对于计划用于测试子过程的每个静态或动态测试过程，描述包括： 一测试目标； 一测试项； 一测试依据； 适用的测试过程； 建议的测试设计技术（如适用）。 请注意，示例只供参考。在实际情况下，应根据产品的风险情况进行选择。

这些示例表示与开发生存周期的验收阶段相关联的测试子过程。 则试子过程目标：向客户演示最终系统在其指定要求方面的可接受性。 计划的测试子过程内容：动态测试1：预演， 动态测试2：演示

D.3详细设计测试子过

该示例表示与开发生存周期的详细设计阶段相关的测试子过程。 测试子过程目标：提供详细设计质量的信息。 计划的测试子过程的内容：静态测试1：详细设计项文档， 静态测试2：详细设计项易用性（不是系统的易用性）， 静态测试3：详细设计项完整性。 在详细设计阶段，根据架构设计会开发一些设计项。每项都可以接受为这个测试子过程定义的静 悉测试。因此，可以计划静态测试的实例，其中测试项被定义为特定的详细设计项。静态测试的实例可 以与测试项目定义为一个具体的详细设计项目。详细设计测试子过程仅在所有计划的测试完成后（或 银据实际情况放弃）完成。 静态测试1：详细设计项文件 测试目标：提供关于详细设计项记录方式的信息。 测试项：详细设计项。 测试依据：内部和/或外部检查表，指定详细的设计文档规则， 测试设计技术：技术评审或审查。 静态测试2：详细设计项可用性 测试目标：提供有关详细设计项目可用性的信息，例如编码或测试。 测试项：详细设计项。 测试依据：不适用， 测试设计技术：程序员或测试人员对示例的走查。 静态测试3：详细设计项完整性 测试目标：提供详细设计项的完整性信息。 测试项：详细设计项。 测试依据：更高层次设计和/或需求的可追溯信息。 测试设计技术：技术评审。

这些示例表示与开发生存周期中的集成阶段相关的测试子过程，其中（被测试的）组件

示与开发生存周期中的集成阶段相关的测试子过程，其中（被测试的）组件正在遂步

集成。 在集成阶段，产生了许多类似的测试项，即正在集成的两个组件。本示例中的动态测试是通用的 可以对正在集成的任何两个组件执行，从最初的两个组件集成到=个组件，到最后两个组件集成到完整 的系统。集成测试子过程仅在所有计划的测试完成后（或根据实际情况放弃）完成。 集成可以在不同的层次进行。它可以是将源代码组件集成到更大的组件，直至一个完整的系统，不 同类型的子系统（硬件、软件、数据、培训材料等）集成到一个完整的系统，或完整的系统被集成到一个 更大的）系统组件中。虽然形式取决于风险概况，但原则是相同的。 测试子过程目标：提供关于集成组件交互的信息。 计划的测试子过程内容：静态测试：直接接口， 动态测试1：直接接口， 动态测试2：间接接口， 动态测试3：共存。

静态测试1:性能需求文档

静态测试4.性能详细设讯

测试目标：提供关于需求记录方式的信息。 测试项：所选的需求（全部或一组）。 测试依据：内部和/或外部检查列表，例如关于特定需求文档样式，和/或关于相关信息，例如唯一标 识、优先级和发起者。 测试设计技术：技术评审或审查（审查之前应进行非正式或技术评审，以确保要审查的需求有一定 的成熟度）。 静态测试2：需求的可用性 测试目标：提供有关设计或测试需求的可用性信息。 测试项：所选的需求。 测试依据：不适用。 测试设计技术：与开发人员或测试人员走查。 静态测试3：需求完整性 测试目标：提供关于组需求完整性的信息。 测试项：所选的需求（全部或一组）。 测试依据：检查表和/或更高层次需求的可追溯信息。 测试设计技术：技术评审

D.8故事集测试子过程

该示例表示一个测试子过程，该子过程与根据当前项目待办事项列表在特定sprint中处理的待办 事项列表的选择相关。 测试子过程目标：提供关于在特定的sprint中工作的故事集质量的信息。 计划的测试子过程内容：静态测试：故事的可行性。 静态测试：故事的可行性 测试目标：提供关于选择的故事集的信息。 测试项：选择的故事。 测试依据：检查列表，例如对故事的理解和估计的开发时间，以及故事之间的依赖性和一致性。 则试设计技术：非正式的评审或技术评审，

该示例表示一个测试子过程，该子过程与故事实现的完成相关，然后将故事包含在日常构建中（或 者按照确定的生成新构建的速度）。 在开发冲刺待办事项列表中的故事时，会产生许多类似测试项，即故事的实现。因此，整个故事测 试子过程可以覆盖一个或多个故事的测试，这取决于在构建之前实现了多少个故事。实施的故事以类 以的方式单独测试。本例中的动态测试是通用的，可以对任何故事进行测试。故事测试的子过程只有 在所有计划的测试完成（或根据情况放弃）时才完成。 测试子过程目标：在构建中包含实现的故事之前，提供关于它的信息。 计划测试子过程内容：静态测试：源代码质量属性。 标中

测试目标：提供关于源代码质量的信息。 测试项：由故事实现创建或影响的源代码。 测试依据：内部和/或外部检查列表，例如关于特定代码编写风格，和/或编码异常，例如在声明变

T／CECS G：Q71-2020 公路桥梁管理系统技术规程.pdfD.10系统测试子过程

D.11 组件测试子过程

测试行业内的不同角色有不同的名称，因此本标准不提供一个完整的列表，列出旨在代表测试职业 同的角色和责任。以下角色是这样捕述的：担任该角色的人员可能将负责完成本标准中描述的测 过程的某个方面。每个角色可能不止一个人。 测试策略者 建立并确保符合组织级测试过程。 测试经理 开发、管理并确保符合测试管理过程。测试经理还策划和控制动态测试过程。 测试人员 开发测试可交付成果，并完成与动态测试过程相关的过程。 实际工作中，本标准中所列出的过程很可能由一系列职位不同的人完成

测试行业内的不同角色有不同的名称，因此本标准不提供一个完整的列表，列出旨在代表测试电 不同的角色和责任。以下角色是这样描述的，担任该角色的人员可能将负责完成本标准中描述的 过程的某个方面。每个角色可能不止一个人，

建立并确保符合组织级测试过程。 测试经理 开发、管理并确保符合测试管理过程。测试经理还策划和控制动态测试过程。 测试人员 开发测试可交付成果，并完成与动态测试过程相关的过程， 实际工作中，本标准中所列出的过程很可能由一系列职位不同的人完成

试人贝安组 天方（如：试项日的开发人贝、 产品赞助商、支持团队以及销售和营销人员）进行沟通， 。测试状态需要根据项自进度及时沟通。沟通可 基手书面文档，例如组织级测试策略、测试计划、测试状态报告和测试完成报告。书面文档可以附有 1头陈述，就像在更正式的顾序或演化开发中出现的情况一样。在更加非正式的开发机制中，例如敏捷

者发现自已工作中的缺陷比独立测试人员找到相同缺陷更困难。产品独立性评价在许多行业中都很常 见，例如出版业，由编辑进行评价；有质量控制的制造业，由建筑检查员检查房屋建设质量。 开发者和测试人员的独立性按照如下顺序递增： a）开发者测试自已的产品； b）测试由不是开发本产品的开发者设计和执行，如：本产品开发者同一组织单位的另一位向同 经理汇报的开发者； 测试由与开发者同一组织单位的测试人员设计和执行，并向同一经理汇报； d 测试由独立于开发组织单位的测试人员设计和执行，但仍然是内部的； 测试由外部组织（顾问）雇用的测试人员设计和执行，但与开发者在同一组织中工作：； 门 测试由外部组织中的测试人员设计和执行（第三方测试）。 独立测试目的是在项目的时间、预算、质量和风险限制范围内，在设计测试和生产测试项的人员之 间获得尽可能多的独立性。组织级测试策略应确定组织中必要的测试独立性程度，并在项目测试计划 和当前测试子过程计划中继承。风险较高的情况通常会导致更高的独立性。IEEE1012.2014中提出

了验证和确认活动（包括测试）中独立性的概念。 对于不同的测试子过程，独立性的程度通常是不同的。在动态组件测试中，经常可以看到最低程度 的独立性（即没有独立性），即使在同行评审中应用相同程度的独立性（开发者进行的静态测试）通常也 不被认为是可接受的。 如果在敏捷项目中进行测试，那么由开发人员和测试人员组成的团队通常意味着很难有高级别的 独立性。在这种情况下，应注意确保尽可能多的独立性，

了验证和确认活动（包括测试）中独立性的概念。 对于不同的测试子过程，独立性的程度通常是不同的。在动态组件测试中，经常可以看到最低程度 的独立性（即没有独立性）DB33／T 1222-2020 新建住宅小区生活垃圾分类设施设置标准.pdf，即使在同行评审中应用相同程度的独立性（开发者进行的静态测试）通常也 不被认为是可接受的。 如果在敏捷项目中进行测试，那么由开发人员和测试人员组成的团队通常意味着很难有高级别的 独立性。在这种情况下，应注意确保尽可能多的独立性