用于执行软件测试的设施、硬件、软件、固件、规程和文档集。

3.72 测试监测和控制过程testmonitoringandcontrolprocess 测试管理过程的子过程。用以确保测试按照测试计划和组织级测试规格说明执行。 3.73 测试对象testobject 见测试项（3.68）。 3.74 测试阶段testphase 测试子过程的具体实例化。 3.75 测试计划 testplan 描述需要达到的测试目标以及实现该测试目标的方法和安排的文档，用于协调测试项的测试活动。 注1，一个项目可以有多个测试计划例如可以有一个项目测试计划（也称为主测试计划)，其包含了该项目所有的 测试活动；更多测试活动的细节可在一个或多个测试子过程计划（即，系统测试计划或性能测试计划）中定义， 注2：通常测试计划是书面记录的，尽管其他的计划形式也可在组织或项目中局部定义， 注3：也可以为非项目活动编写测试计划，例如维护测试计划、 3.76 测试策划过程testplanningprocess 测试管理过程的子过程。用于完成测试策划和开发测试计划。 3.77 测试实践testpractice 便手实施测试的概念框架，该框架可应用手组织级测试过程、测试管理过程和/或动态测试过程。 3.78 测试规程 testprocedure 测试用例的执行序列，以及任何与构建初始前置条件所需的相关动作和执行后的收尾活动。 注；测试规程包括如何连续运行二个或多个测试用创的详细说明，包括设置通用的前提条件，为每个测试用例提供 输人并评价实际结果。 3.79 测试规程规格说明testprocedurespecification 说明一个或多个测试规程的文档。这些测试规程是具有特定目标的测试用例的集合。 注1，测试集内的测试用例按测试规程的需求顺序列出。 注2：测试规程规格说明也称为人工测试脚本，自动化测试运行的测试规程规格说明通常被称为测试脚本， 3.80 测试过程 testprocess 为一个软件产品提供质量信息的过程，通常由多个活动组成，分为一个或多个测试子过程。 注：特定项目的测试过程可能包含多个子过程，如系统测试子过程、测试计划子过程（较大测试管理过程的一部分） 或静态测试子过程， 3.81 测试需求 testrequirement 见测试条件（3.52）。 3.82 测试结果 testresult 指定的测试用例是否通过的标示，即观察到测试项输出的实测结果是否与预期结果一致或有偏差。 3.83 测试脚本 testscript 人工测试或自动化测试的测试规程规格说明。

3.94 无脚本测试unscriptedtesting 测试者的动作不是由测试用例中的书面指令所规定的动态测试。 3.95 容积测试yolumetesting 性能效率测试的一种类型。用于评价测试项在吞吐量、存储容量或两者兼考虑的情况下处理指定 数据量（通常达到最大指定容量或接近最大值）的能力。 3.96 白盒测试whiteboxtesting 见基于结构的测试（3.45）

决策者需要有关测试项质量特性的信息； 被测项并不总是达到预期效果； 被测项需验证； 一被测项需确认； 被测项的评价需穿整个软件与系统开发生存周期， 无法构建出完美的软件是已经被普遍认同的。因此，在软件发布向用户之前有必要进行测试，降低 软件产品出错的风险，以避免在使用软件时产生负面影响。同样，有必要确保测试能被很好地执行。 错误或缺陷很大程度上是不可避免的。人为引起的错误或差错导致了软件工作产品（例如，个需 求规格说明或软件组件）缺陷的出现。如果在软件使用时未遇到缺陷，缺陷不会对软件的操作产生影 响。但是，如果在一定的条件下使用产品时遇到缺陷，缺陷可能会导致软件产品无法符合用户的合理需 求。由软件失效可能会带来用户体验的严重后果。例如，一个缺陷可能会损害商业信誉、公共安全、商 业可行性、商业或用户的信息安全、环境等。 动态测试是必要的铁路标准规范范本，但无法保证软件能按预期执行。额外的静态测试活动，例如同行评审和静态分 析，应与有效的动态测试活动结合使用。 测试的主要目标是：提供有关测试项的质量信息以及与测试项测试数量相关的任何残余风险：在发 布之前发现测试项的缺陷：并减轻由产品质量不足带给相关利益方的风险。 软件质量信息可用于多种目的，包括： 一通过消除缺陷来完善测试项； 一将提供的质量和风险信息作为决策的基础来改善管理决策； 一通过标识允许出现缺陷和/或可能发现但依然未发现缺陷的过程，来改进组织中的过程。 产品质量有多个方面，包括符合规格说明的要求、没有缺陷，以及满足产品用户需求的符合程度。 可通过测试来测量和评价GB/T25000.10一2016系统与软件质量模型定义的八个质量特性（见4.5.4）。 在给定成本和进度的约束下，软件测试应侧重于提供有关软件产品的质量信息，并在开发过程中尽 草且尽可能多地发现缺陷。 测试考虑的因素包括： 一测试是一个过程。过程是将输入转为输出的一系列相互关联或相互作用的活动。本标准的目

的是提出并描述通用的测试过程（详细内容参见GB/T38634.2测试过程）。 应用于跨组织的项目和功能的测试方针和测试策略，它由组织级测试过程设置和维护。 应对测试进行计划、监测和控制。GB/T38634.2所包含的测试管理过程，可应用于所有开发 生存周期中的测试和探索性测试的管理。 一测试过程和子过程可以应用于任何测试阶段或级别（如系统测试）或任何类型的测试（如性能 测试）。 测试需要检查测试项。 无须在计算机上运行产品也可以进行测试。这种测试技术在本标准和许多行业领域中被称为 静态测试，尽管在其他标准中（例如，GB/T32421一2015）也许更具体地被称为审查、走查或检 查。本标准承认并认可测试者在静态测试活动中的作用，即使这些活动可能在其他标准工作 组或在其他非测试标准中定义。静态测试活动对于全生存周期的测试非常重要，并且测试介 对于卓期缺陷检测，降低项目总成本和保证项目进度至关重要。 一静态测试包括使用静态分析工具在不运行代码的前提下发现代码和文档中的缺陷（例如编译 器、圈复杂度分析器，或代码的安全分析器）。 动态测试不仅仅是运行可执行的测试项，还包括了准备活动和后续活动。GB/T38634.2中描述 的动态测试过程通盖了动态测试所要执行的每一个活动。 验证是通过提供客观证据来认定在给定的工作项中已经满足了指定的需求。 一确认表明用户可以使用该工作项来执行其特定任务。 无论是静态测试还是动态测试，旨在提供验证和确认两种认定所需要的信息，尽管由手发现了 缺陷而无法立即认定。

4.1.2 测试在验证和确认中的作用

软件测试是验证和确认的主要活动，本标准仅涉及验证和确认中的软件测试，不涉及验证和确认 地活动（如V&V分析、形式化方法）。其他标准，如ISO/IEC/IEEE12207和GB/T32423一2015， 其他的验证和确认活动。只有将本标准与其他标准结合使用，并作为整个工程项目的一部分，才能 完整的产品验证和确认活动。有关验证和确认活动的层次结构参见附录A。

由于系统和软件的复杂性，测试不可能覆盖测试项的每个方面。测试人员应该明白穷尽测试是不 可能的，测试活动应聚焦于最能满足测试项的测试目标。基于风险的测试是一种用风险来指导测试工 作的方法。基于风险的测试见4.4

4.1.4 启发式测试

在工程（软件工程）中，启发式是一种基手经验（尝试错误）的方法，可用手帮助解决和设计问题。量 然启发式算法可以用来解决问题，但它并不可靠，无法解决所有问题，或只能解决部分问题。许多系统 和软件的测试都是基启发式。例如，通过对被测系统进行建模，启发式测试非常有用，但是可能无法 对系统完全建模，因此即使测试似乎已经完成，也可能无法找到系统中的缺陷。如果认识到测试方式可 能是错误的.可以采用多种测试策略来降低无效测试策略的风险

4.2组织和项目环境中的软件测试

从事软件产品开发或采购的企业有兴趣开发和使用有效、高效和可重复的过程。为此，他们通常

研制一套可靠的过程体系，应用于所执行的项自中。本标准既适用于整个组织，也适用于特定项自。组 织在采用本标准时，可在必要时补充其他规程、实践、工具和方针。在组织内开发特定软件或系统时，通 常需符合组织内定义的过程体系，而不用直接符合本标准。在某些情况下，若组织不具备适当的过程体 系，其开展的项目可直接按本标准的规定执行。 在各种类型的软件生产组织中，无论是拥有数千名测试人员的跨国公司还是只有少量测试人员的 小公司，软件测试都宜得到组织管理最高层的承诺，无论是CEO、开源指导委员会或部门经理。承诺作 为组织内所有软件测试的基础，最好以组织级测试方针和一个或多个组织级测试策略表示。通常只有 在成熟度较高的组织中，才其备测试方针和组织级测试策略。在成熟度较低的组织中，缺乏正式的测试 方针和组织级测试策略也可以开展测试，但会造成测试执行在组织内缺乏连贯性，会降低测试执行的效 率和有效性。 软件测试是周境管理的过程。这意味者宜对软件测试进行计划、监测和控制。周境可以是开发项 自（覆盖从多人、多年的正式开发项目到儿个人时的非正式开发项目）或正在进行维护的业务系统。理 解测试周境的因素有：总体预算、进度需求、风险、组织文化、客户/用户期望、可用于测试的基础设施环 境、项目范围、项目重要性等。行业经验显示任何单一的测试策略、计划、方法或过程都不可能适用于所 有情况。组织和项目宜参考本标准来定制和改进测试的细节。 完整的项目计划应考虑将测试活动作为其中的一部分。项目测试计划宜同时反映组织级测试方针 和组织级测试策略以及与组织级指导文件之间的偏差，还宜考虑项目计划中给出的限制因素。项目测 试计划包括项目测试策略和导出此策略的项目特定决策（包括假设）。测试计划的一个重要内容是衡量 各个测试需求和平衡各个测试间的资源，并将分析结果记录在测试计划中。本部分中，风险是决定测试 需求的主要方法（见4.4），4.6中描述的测试实践可归为策略。 个项目的测试通常会包括多个测试子过程，每一个测试子过程可具有相应的测试计划（测试子过 程计划，例如系统测试计划或性能测试计划），其包括与项目测试策略一致的测试子过程策略，以及测试 子过程的具体细节， 图1显示了测试的多层周境。适用时，测试是建立在组织的监管状态下。周境是由法律、法规和行 业标准组成的。在这种监管状态下，组织为了项目能够成功，需制定必要的方针和规程，并执行组织级 的测试策略。在组织内的每个项目都经过实例化，以满足组织已经确定的需求或机会。项目周境有助 于确定选择生存周期模型。在此级别，测试策略的确定基于项目周境和生存周期模型。项目计划和测 试策略构成了项目测试计划的基础。 项目测试计划描述了总体测试策略和测试过程，通过确定目标、实践、资源和进度安排来建立项目 测试周境；问时也确定了适用的测试于过程（如系统测试、性能测试）。然后在于过程测试计划（例如，系 统测试计划、性能测试计划)中描述所识别的子过程。测试计划还描述了所使用的测试设计技术（静态 或动态），包括特定子过程计划中所用的测试技术。有关测试设计技术的更多信息，见4.5.7 和GB/T38634.4。 每个子过程测试计划可用于多个测试级别（例如，信息安全性测试计划可能涉及多个测试级别）和 多个测试类型（例如，系统测试计划用于处理系统测试级别的功能和性能测试）。子过程测试计划还包 括测试执行的策略（例如，脚本、无脚本或两者的混合）。 测试计划包含测试策略。测试策略适用于特定的测试项目周境，用来解决图1中列出的特定项，这 些项在本标准的其他部分中进行了定义。每个测试计划（和策略）都是独一无二的，包含不同的测试子 过程、自动化等级、测试技术、测试完成准则以及日程安排和资源等。在项目早期就应做出计划和选择， 并持续作为风险变化等因素贯穿于测试生存周期。尽管这些变更可能会受到项目、组织及监管约束的 限制.但是测试计划和策略中的大部分内容还是会发生变更

图 1 .多层次测试周境图

图2详细描述了通用测试过程、通用测试子过程、测试级别/阶段和测试类型之间的关系，展示了通 用测试过程作为特定的测试级别和测试类型的实现。通用测试子过程可以应用在以下几个方面 一在测试级别或阶段方面，即每个测试级别是测试子过程的特定应用（例如，组件测试阶段，验收 测试级别）； 一在测试类型方面，即每种测试类型是通用测试子过程的特定应用（例如，性能测试、易用性测 试； 测试级别子过程可包含多个测试类型子过程（例如，功能和性能测试作为系统测试的一部分）： 项自测试过程可包含一系列测试子过程（例如，组件测试、集成测试、系统测试和验收测试子过 程）。 图2还明确了测试类型和质量特性之间的关系（如GB/T25000.10一2016定义的系统和软件质量 模型）。每种测试类型都针对个特定的质量特性。测试类型和质量特性之间关系的更多信息 见4.5.4。

本标准采用了三层过程模型。图3给出了高层次的模型其详细描述见GB/T38634.2。过程模型 以管理高层（组织级）测试规格说明的组织级开始，如组织级测试方针和组织级测试策略。中间层是测 试管理（项目测试管理、阶段测试管理、类型测试管理），底层定义了用于动态测试的测试过程。 三层过程模型如图3所示

图3测试过程之间的多层关系

则试方针是用业务不衣达 主要对象是高层管理者。测试方针还指导了有关组织级测试策略的制定和组织级测试过程的实施。组 织级测试方针的创建、实现和维护由组织级测试过程定义。 组织级测试策略表达了对组织内运行的所有项目执行测试管理过程和动态测试过程的要求和约 束。当组织内各项目间性质上存在较大差异时，可制定多个组织级测试策略。组织级测试策略与组织 级测试方针保持一致，并措述如何执行测试。组织级测试策略的创建、实施和维护也由组织级测试过程 定义。 测试管理过程中对执行测试的过程提出管理要求。对已识别项目风险和约束条件进行分析，并考 虑组织级测试策略，提出项目级测试策略。在策略中定义和详细阐述要执行的静态和动态测试、总体人 员配置、平衡给定约束（资源和时间）、要完成的测试工作范围和质量要求等方面，并记录在项目测试计 划中。在测试期间，执行监测活动以确保测试按计划进行，并确保风险得到正确处理。同时，如果需要 对测试活动进行任何变更，则向相关测试过程或子过程发出控制指令。在监测和控制期间，可定期生成 测试状态报告，以告知利益相关方测试进度。项目测试的总体结果记录在项目测试完成报告中。 测试管理过程如图4所示

项目的整体测试通常分解为较小的测试子过程（例如组件测试、系统测试、易用性测试、性能测试）， 这些子过程也宜以类似于整体测试项目的方式进行管理、执行和报告。测试管理过程也可应用于测试 子过程。例如，测试子过程计划可以是系统测试计划、验收测试计划或性能测试计划。 测试子过程可包含静态测试和动态测试。 动态测试过程在图5中概述，并在GB/T38634.2中详 细说明。静态测试过程由其他已发布的标准（例如，GB/T32421一2015）描述，

有关测试过程的更多信息，包括组织级测试过程、测试管理过程和动态测试过程， GB/T38634.2。

4.3软件生存周期中的通用测试过程

软件从最初构想到最终退役都有 本条概述了软件开发生存周期以及其子过程和测试过程之间关系的示例：ISO/TEC/IEEE12207：201 详细描述了软件生存周期。ISO/IEC/TEEE15288详细描述系统生存周期过程。系统的生存周期样例 如图6所示。

图6系统生存周期样例

软件生存周期通常包括多个子生存周期。图6表明了一个软件生存周期准往由一个或多个开发生 存周期和一个或多个运营生存周期组成的。 从构想到最初发布被称为开发生存周期，是软件生存周期的子集。开发生存周期在开发项目中管 理和控制。 系统从首次发布到退役之前一直处于运行状态；这可能是几个小时到几十年的时间跨度。运行期 通常包括使用特定版本系统的时间点，同时新版本正在开发，以待发布。任何正在开发的新版本都应视 为一个开发项目，其中包含相应的测试。通常还会进行持续维护以保持系统可用并可按预期运行。

在没有相应开发项目的情况下，可在运营系统上进行测试的情况，例如试运行”灾难恢复测试。本 标准提出的过程也可适用于这种情况。 测试的执行也可用于评价购买的软件是否满足业务需求。GB/T25000.51一2016提供了用于评价 和测试就绪可用软件（RUSP）的框架。

4.3.2开发项目子过程及其结果

软件和系统开发通常由儿个常见的构建模块组成。在软件行业，这些构建模块通常被称为“阶段 “时期”“步骤”“级别”或更普遍地称为“开发子过程”。包括： 一需求工程； 一架构设计； 一详细设计： 一编码。 组织或项目采用特定的系统开发方法来决定如何策划开发子过程。在顺序开发项目中，需求分析 本身可以是一个初始过程。在敏捷开发项目中，每隔几周就会为每次增量交付确定需求。 在每个开发子过程中都会产生一些成果；可以是一个高度结构化的详细文档，也可以是非正式记录 未记录的决策。 在任何给定的开发项目中，各个开发子过程可以执行一次，或者根据需求重复执行。通用开发子过 程和相关工作产出物、子系统和完整软件系统如图7所示，

每个工作产品、软件系统组件和完整的软件系统都是潜在的测试项。 请注意，开发模型的定义超出了本标准的范围。图7中描述的阶段仅是说明测试如何应用于开 示例。

3.3持续维护及其结果

发布的维护，则会包含选定的修正或变 通常会尽快实施维护和发布。如固定周期的版本维护，则可 以在该时间段内根据商定的优先级进行修正或变更。各发布阶段的输出示例如图8所示。

图8维护发布阶段示例

根据发布目标的不同，图8中所示的每个输出可以在单个发布时段中产生，或者依据需求提供部分 输出。例如，临时修正可能不会影响需求和设计，而只影响编码和已完成的系统；也可能是所有工作产 品在系统准备发布之前受多次影响。 可依据需要在系统的运营生存周期内 发布阶段

4.3.4软件开发生存周期的支持过程

在组织内，需要支持过程来帮助软件开发生存周期。其中包括： 质量保证； 项目管理； 配置管理； 过程改进。

4.3.4.2质量保证和测试

质量保证是一套计划的、系统的支持过程和活动，用以提供足够的信心，相信过程或工作产品满足 既定的技术或质量要求。其通过加强方法、标准、工具和技能来实现的，这些方法、标准、工具和技能被 认为是周境中的适当实践。质量保证的过程使用测试结果和其他信息来调查、排序和报告软件工程过 程设计、策划或执行中的任何问题（包括风险）。 应在测试过程中收集测度，该测度可提供有关测试过程、测试项质量信息及其在每个项目中的应用 效果。

4.3.4.3 项目管理和测过

目中的测试管理。无论谁负责各个 过程，项目管理都和测试管理过程密切相关，如图9所示

图9整体项目和测试项目的关系

测试活动的估算、风险分析和进度安排应与整体项目策划统一。项自计划是项自管理过程中的信 息项，因此在用于管理测试项目时，它是测试管理过程的输人。 在测试项目过程中，测试经理会分析从详细的测试活动中收集的测量结果，并将其传达给项目经 理，以便在项自周境中进行分析。这可能会导致影响测试项自目的项自计划变更，更新的项自计划和相应 的指令应发布到测试项目中，以帮助确保测试项目得到控制。 当测试子过程或测试项目完成时，向项目经理提供一份总结测试子过程或测试项目的过程和结果 的完成报告。

4.3.4.4配置管理和测试

配置管理是测试交互的另一组支持过程。配置管理的自的是建立和维护工作产品的完整性。好的 做法是在运营使用之前对组织或项目的配置管理系统进行测试，以确定其是否符合组织或项目要求。 配置管理过程包括产品周期内所选工作产品、统组件和系统的唯一标识、受控存储、发布审核、变 更控制和状态报告。配置管理的对象称为配置项。配置管理过程是事件驱动的，即都是依据各自的过 程独立启动的。 测试过程中的工作产品可以纳入配置管理，包括： 一组织级测试规范（例如测试方针、组织级测试策略）； 一测试计划； 一测试规范： 一测试环境配置项，如：测试工具、测试数据（库）、驱动、桩模块。 本标准中定义的测试过程模型中的三个层次都可以与配置管理进行交互。提供给测试过程的配置 项是过程需要作为输入并纳入配置管理的工作产品。从测试过程传递的配置项是测试过程产生的工作 产品，其需要纳人配置管理。 例如，组织级测试过程可以产生测试方针和组织级测试策略，其被纳入配置管理。项目测试经理可 以从配置管理中获取项目计划，并作为项目测试计划的基础，随后该项目测试计划纳入配置管理。执行 动态测试子过程的测试人员可以从配置管理中获取需求规格说明，并作为测试规格说明的基础，该测试 规格说明随后纳入配置管理。 为了能够复现问题以便进一步分析，最好的做法是（在可能的情况下）使配置管理系统足够全面和 健壮，以便在将来的任何时候都可以在恰好与以前相同的条件情况下重复测试。只要在组织级测试策 略或项自计划中明确异常，就可以从重复性需求中排除某些类型的测试，例如单元测试。 测试过程的配置管理报告宜提供分析事件进度和状态所需的详细措施

4.3.4.5过程改进与测试

组织级测试策略为组织中的测试设定周境。在这样做时，宜识别可能影哨测试过程的组织风险。 列如，生产医疗软件的组织可能需要遵守严格的质量标准，该组织的组织级测试方针可能包括处理安全 相关标准的要求，从而尝试减轻业务失效时的影响。 组织级测试策略宜提出在测试过程中管理风险的方法。在上述生产医疗软件组织的示例中，组织 级测试策略可以提供在组织中执行测试的指南，以助于管理不符合监管标准的风险。除此之外，组织级 则试策略可以强制要求采用特定方法进行测试管理过程中的风险管理。

4.4.3测试管理过程中使用基于风险的测试

计，用 确定需对项目执行哪些测试。例如，风险评分可用于确定测试的严格程度（如测试子过程、测试设计技 术、测试完成准则）。风险的优先级可以用来确定测试时间表（通常较早处理高优先级风险相关的测 式）。风险类型可用于决定最合适的测试形式。例如，如果组件之间的接口存在可感知的风险，则有必 要进行集成测试如果感知到存在用户发现应用程序难以使用的风险，那么有必要进行易用性测试。

好的做法是尽可能广泛地让利益相关方参与这些活动，以确保识别出尽可能多的风险并确定其各 自的缓解活动（或者决定不处理这些风险）。 该方法的好处是，在任何时候，交付风险都可以作为残余风险简单地传达给利益相关方。 针对已感知的风险以及不断变化的业务情况进行测试，自然会导致风险概况随时间变化，因此需将 基于风险的测试视为持续的活动。

4.4.4动态测试过程中使用基于风险的测试

图10测试子过程的通用示例

发生存周期（即，瀑布或螺旋式开发周期不能确定其自身所需的测试子过程的数量）。 附录D详细介绍了测试子过程的示例。 测试目标、测试项目、测试依据和风险是每个测试子过程特有的，用于指导测试子过程中所执行的 则试活动和所使用测试设计技术的选择。下面给出了测试目标、测试项、测试依据和测试设计技术的

测试的执行用于实现一个或多个目标。本标准所涵盖的测试目标包括： 一向风险管理活动提供信息： 一提供有关产品质量的信息； 一评价产品是否符合利益相关方的期望； 一评价缺陷是否已正确修复，同时未引人其他不良影响； 一评价变更是否正确实施，同时未引入其他不良影响； 一评价需求满足的情况（如：规范、设计、合同等）。 测试是用以完成特征或特征集的测试目标。所测的特征类型将决定所需的测试类型。特征可用于 体现需满足的质量特性。测试者通过特征或特征集所组成的质量特性来确定达到测试目标所需使用的 则试类型。 一些测试目标可能仅与特定测试子过程或测试项类型相关。确定测试项的相关测试目标有助于确 定合适的测试子过程。例如，在测试商业现货产品时，评价缺陷修复的测试目标可能不适用了，因为供 应商已经完成了健壮性测试并修复缺陷。因此，在这种情况下采用验收测试子过程以满足测试目标，即 实施变更而未引人其他不良影响

应依据测试项的预期对测试项进行测试；这种预期是由测试依据（见4.5.5）描述。测试项是诸如管 理、开发维护、测试本身或其他支持过程等活动的结果。 测试项示例包括： 一代码相关测试项： ·可执行的软件组件； ·子系统； ·完整系统。 一文件相关测试项： ·计划，例如项目计划、测试计划或者配置管理计划； ·需求规格说明； ·架构设计； ·详细设计； ·源代码； ·手册，例如用户手册或安装手册； ·测试规格说明和测试规程。 上述列表中的最后一条表明，尽管测试规格说明和测试规程是由测试人员开发的，但也应接受测试 （静态测试），因为它们并非没有缺陷。

4.5.4质量特性的测试

GB/T25000.102016系统与软件质量模型概述了软件的质量模型。该模型描述了八个质量特 生，用于定义测试项目的质量属性。测试是一种测量给定测试项的重要质量特性的活动。八个质量特 生如下： 一功能性：在指定条件下使用时，产品或系统提供满足明确或隐含功能的程度。 一性能效率：性能与在指定条件下所使用的资源量有关。

兼容性：在共享相同的硬件或软件环境的条件下，产品、系统或组件能够与其他产品、系统或组 件交换信息，和/或执行其所需功能的程度。 一易用性：在指定的使用周境中，产品或系统在有效性、效率和满意度特性方面为了指定的目标 可为指定用户使用的程度。 一可靠性：系统、产品或组件在指定条件下、指定时间内执行指定功能的程度。 一信息安全性：产品或系统保护信息和数据的程度，以使用户、其他产品或系统具有与其授权类 型和授权级别一致的数据访问度。 一维护性：产品或系统能够被预期的维护人员修改的有效性和效率的程度。 可移植性：系统、产品或组件能够从一种硬件、软件或其他运行（或使用）环境迁移到另一种环 境的有效性和效率的程度。 为了测试质量特性，需要具体化测试子过程。例如，策划和执行测试用以测量信息安全性可能需要 实施信息安全性测试子过程（安全测试）。 每一个质量特性具有多个子特性，可以对其进行测试以提供质量的整体视图。另外，并非所有质量 手性都适用于所有系统，例如，可移植性对于专用嵌入式系统可能并不重要。注意，上述质量特性不一 是详尽的，可为特定测试项定义更为适合的质量特性。 测试从业人员通常将功能性的测试称为“功能测试”，并将其他质量特性的测试称为“非功能性”测 式。用于测量功能性以外的质量特性的测试类型通常被称为非功能性测试，可包括负载测试、压力测 式、渗透测试、易用性测试等。 在制定测试计划时，测试经理应考虑所有质量特性。针对不同的质量特性及其特性的测试重点 可能会根据以下情况而变化： 一正在开发系统的风险概况；例如，安全关键应用可能会强调可靠性。 一正在开发系统的业务门类：例如银行应用程序可能会强调信息安全性

量特性保持一致。非功能性需求与部分或所有功能相关，并且通常功能性需求可与单独或 组的非功能性需求相关联。

变电站标准规范范本4.5.6 复测和回归测试

复测是评价事件的解决方案是否已到正原有同题的测试。复测通常通过重新运行产生原有同题非 预期结果的测试用例来执行。然而，为了有效地进行复测，可识别、分析新的测试条件并编写新的测试 用例。 回归测试是对先前已经过测试的系统或组件进行选择性测试，以验证变更未引起意外影响，并且系 统或组件仍然符合其原有需求。回归测试的目的是确定变更未在系统的未改变部分中引起缺陷。在策 划测试时应考虑回归测试和复测，因为通常同时需要两者来完成子过程的测试。测试执行进度安排宜 考虑两者所需的时间。

4.5.7测试设计技术

测试设计技术包括静态测试技 助领试人员尽日育 和高效地发现测试项的缺陷。静态测试通 档测试项中的明显缺陷(“问题”)或源代码 异常来实现。动态测试通过 实现此自的

4.5.7.2静态测试设计技术

4.5.7.3动态测试设计技术

动态测试的测试设计技术用于识别测试条件、测试覆盖项以及随后在测试项上执行的测试用例 动态测试设计技术根据测试输入的导出方式分为三类。分别是基于规格说明、基于结构和基于经验的 技术。GB/T38634.4详细描述了每类动态测试设计技术。 基于规格说明的测试设计技术用于从描述测试项的预期行为的测试依据导出测试用例。使用这些 技术，从测试依据中导出测试用例测试的输人和预期结果。特定情况下选择哪种基于规格说明的测试 没计技术取决手测试依据和/或测试项目的性质和所涉及的风险。GB/T38634.4中涉及的基于规格说 明的测试设计技术示例包括边界值分析、状态转移测试和判定表测试。 基于结构的测试设计技术基于结构特征导出测试用例，例如源代码结构或菜单结构。如果将这些 技术用于应用程序源代码，则测试用例的预期结果将从测试依据导出。在任何特定情况下选择使用哪 种基于结构的测试设计技术取决于测试依据的性质和所涉及的风险。在GB/T38634.4测试技术中详

灭火系统标准规范范本细定义和描述了该类技术。GB/T38634.4中涉及的基于结构的测试设计技术的示例包括分支测试、状 态测试和数据流测试。

4.4中所描基于风险的测试已被广泛采用，是本标准的基本方法。有许多不同的实战用手策划 和实施项目的测试。传统的实践是依据需求进行测试，在测试执行前人工设计测试用例，并混合使用人 工和自动化测试来执行。使用基于风险的测试并不意味着不能使用这些实践作为声称符合 GB/T38634.2的测试计划的一部分。测试策略的选择取决于各种风险，例如组织、项目和测试项目的 风险。例如，如果组织无法确保每项要求都经过测试，则可能面临违反合同的风险。因此，使用基于需 求的实践将是管理组织风险的方法。本条介绍了多个测试实践，每个测试实践都可以作为符合 GB/T38634.2创建的测试策略的一部分。通常这些测试实践中的任何一种都不可能单独使用，而是用 作更大的测试策略的一部分。 本条闻述了当前使用的一些测试实践，以演示一些可在测试计划时使用的选项。