如有ITIL认证、ITIL培训或ITIL考试需求，可点击了解详情

申明：

本系列ITIL 4中文版本由长河领导的ITIL先锋论坛专家委员会组织翻译，国内众多从事ITIL理论推广及落地实践的专家们参与。需要下载最新翻译版本请关注微信公众号：ITILXF，并回复“验证和测试”或“验证”、“测试”即可。

请注意，ITIL先锋论坛专家团队仅仅只是进行了这些著作的语种转换工作，我们并不拥有包括原著以及中文发行文件的任何版权，所有版权均为Axoles持有，读者在使用这些文件（含本中文翻译版本）时需完全遵守Axoles 和 TSO所申明的所有版权要求。

本文档翻译工作参与人员：

翻译：贺欢

审校：李威

总审：长河

审核：汤维

统筹：常宏

1. 关于本文档

本文档为服务验证和测试实践提供了实用指南。分为五个主要部分，涵盖：

• 本实践的概括信息
• 本实践相关的流程和活动及其在服务价值链中的作用
• 实践中涉及的组织和人员
• 支持本实践的信息和技术
• 对本实践的合作伙伴和供应商的考虑

1.1 ITIL®4 认证方案

本文档中的部分内容可作为以下课程的一部分检验标准

• ITIL专家创建，交付和支持
• ITIL专家高速IT

详情请参考各部分教学大纲文档。

2. 一般信息

2.1 目的和描述

关键信息

服务验证和测试实践的目的是确保新产品和服务或对其的变更符合定义的要求。服务价值的定义基于客户、业务目标和法规要求的输入，并作为设计和转换价值链活动的一部分。这些输入将用于设立可度量的质量和性能指标，而这些指标又将作为支持验收标准和测试要求的定义。

服务验证和测试实践涉及减少因新的或更改的产品和服务引入到生产环境的风险和不确定性。在此实践中通过计划并执行适当的测试来操作。

系统越大越复杂，则需要进行的测试越多。但是，由于时间和成本的限制，即使是较小的或简单的系统也无法进行穷尽的测试。因此，选择测试的内容很重要。验证和测试的范围和级别定义的关键注意事项包括：

• 生产或服务必须满足的议定要求
• 影响以及偏离议定要求的可能性。

在可能的背景和偏差影响中理解（测试）需求，有助于对测试的重要领域有一个明智的了解。

该实践关乎对正在测试的服务的质量的信心。这不是说它是完美的。通过测试可以赢得信心，以证明服务将按要求运行，符合要求并且没有重大缺陷。

2.1.1 服务验证

服务验证在产品和服务生命周期的早期阶段（概念和设计）执行。它着重于确认议定的服务设计满足议定的服务要求，并为下一阶段（开发，部署和发布）建立验收标准。这些验收标准将通过测试产品和服务组件、产品和服务得以验证。

验证服务要求应遵循的结构，通常涵盖功用、功效、体验、可管理性和合规性。也可能包括其他要求。

服务验证确保服务验收标准得以定义、验证并记录，并告知测试活动的范围和重点。

2.1.2 测试

基于通过服务验证识别的验收标准，开发并实施测试策略和测试计划。

测试策略定义了总体测试方法。测试策略可以应用于环境、平台、服务集或单个产品或服务。对比在组织内自开发的产品和服务与从供应商获得的产品和服务，测试所覆盖的生产和服务的生命周期阶段可能有所不同。

架构管理、软件开发和管理、项目管理、基础设施和平台管理实践的变更对服务验证和测试实践产生了很大的影响。敏捷方法、IT基础设施数字化，面向服务的架构以及软件开发和管理的自动化给服务验证和测试实践带来了新的挑战和机遇。为了满足当今的需求，服务验证和测试应该更快、更灵活并且不断发展。要做到这一点，仅当本实践与上述实践以及其他实践（包括发布管理、部署管理、事件和问题管理实践）紧密集成在一起时，才有可能实现。

有效的验证和测试基于测试人员、开发人员和操作团队之间紧密的协作以及增强的工具和自动化方法。

另一个重要趋势是将验证和测试范围扩展到产品和服务的技术范围之外，包括用户体验和感知。

传统上，服务测试是基于需求规范定义的先验知识，通过检查软件应如何工作或不应如何工作，来确认与明确要求相关的期望的行为。今天，测试还涉及探索和发现有关意外情况的信息，例如产品风险和以下方面的变量：

• 软件
• 有关软件解决方案的想法
• 依据想法创建的制品
• 用户体验和用户接口设计
• 模型和框架
• 架构和代码设计
• 代码
• 工具
• 流程

2. 2 术语和概念

2.2.1基于风险的测试

基于风险的测试是测试行业中的通用术语。通常，人们把风险测试理解为由不同类型产品风险构成的和驱动的测试，它与那些正被测试的功能和产品组件相关。

专注于风险是有益的，因为它突出了服务可能如何失败。然后可以对此进行调查，以发现有关该软件及其质量的信息。

通常在软件测试中，人们关注测试的类型。比如测试类型包括功能测试、回归测试、性能测试、安全测试、可用性测试、浏览器兼容测试、可访问性测试、端到端测试和集成测试。这些测试类型关注不同类型的风险。例如，功能测试着重于功能风险，而回归测试则着重于软件回退的风险。

尽管人们倾向于考虑10到15种测试类型，但许多团队在测试策略中仅包括5到8种测试类型。由于此原因，并且因为影响服务的许多类型的产品风险，很少与一种类型的测试相关联，因此关注基于风险的测试非常重要。

2.2.2 发现风险

在服务验证和测试实践活动中，识别产品风险与确认风险得到有效解决同等重要切有价值。

在产品的早期阶段进行的服务验证和测试活动，将输出有关产品风险，变量，未知数等信息。相反，在产品生命周期的后期阶段进行的测试活动，会发现问题和其他有关服务实际情况的信息，然后组织可以对这些信息做出反应。即便服务在运行中，组织也应继续挖掘有关风险，变量和未知数的信息。反馈仍在继续，但会导致更长的反馈环，返回到想法、用户故事和设计。

例如，在软件开发中，敏捷用户故事制品和验收标准制品很少会关注产品风险。这些制品通常与有关软件功能或互连性的一般期望有关。在定义验收标准时，识别与用户故事相关的风险非常重要。

识别后，应捕获风险。思维导图是常用的工具，因为它可以用来创建一个易用、轻量、易读的风险图，并可以在整个生产生命周期服务设计活动以及以后的阶段进行探索性测试中使用。

识别不同种类的产品风险可能很困难，但是有一些方法可以构造验收标准和测试活动，来提升成功的可能性，例如：

• 在整体层面考虑测试的对象，然后仔细进行测试，包括有形和无形的制品。积极考虑产品、服务或组件的：
  • 潜在目的
  • 属性
  • 不同用户
  • 集成部分
  • 架构
  • 等等
• 探索每个方面的变量。
• 识别并讨论与这些变量有关的产品风险。可以确定的风险示例包括：
  • 可访问性风险
  • 可用性风险
  • 魅力/喜好风险
  • 兼容性风险
  • 环境集成风险
  • 功能风险
  • 接口风险
  • 本地化风险
  • 可维护性风险
  • 可观察性风险
  • 性能风险
  • 可移植性风险
  • 可靠性风险
  • 响应风险
  • 可扩展性风险
  • 安全风险
  • 稳定性风险
  • 可测试性风险
  • 可用性风险
• 评估风险，并决定是否要花费更多的时间和精力来减轻或测试风险。有关此主题的更多信息，请参考风险管理实践指南。
• 如果存在重大风险，请创建一个风险地图。风险图是面向服务设计人员和开发人员的制品。它们还有助于追溯到测试章程，该章程通过对测试特定领域中的特定风险来构建探索性测试。

2.2.3 在不同环境中进行测试

基于风险的方法对于测试环境以及确定在哪个阶段进行测试也很有帮助。

在开发环境中可以测试许多风险。开发环境中的反馈周期非常快，因为通常可以快速编写代码并将其用于测试，以应对多种产品风险，然后在需要时重构代码。但是，某些风险无法在开发环境中进行测试。他们可能需要更严格地集成的环境，例如专用的测试环境。

使用专用的测试环境可能会比较慢，因为创建环境需要时间，如果发现任何问题，重构代码的反馈时间会变得更长，在开发环境中重新测试，然后将这些修订再次合并到测试环境中。在开发环境中完成的测试无需重复测试，但是对开发环境中无法测试的风险则需要进行测试。

有时，搭建一个发布前的环境（准生产环境）是明智的。某些风险只能在共享的测试环境中进行测试，例如与数据流有关的风险，平台风险或某些集成风险。

最后，某些风险只能在实际的生产环境中进行测试。

图2.1代表了可执行大部分测试的环境

图2.1测试三角形

大多数风险都可在开发环境中尽早测试。其余的大多数可在团队测试环境中测试。另外剩余的大多数也可在准生产环境中得以测试。最后遗留的风险在生产环境中可进行测试。

2.2.4 断言（脚本）和探索（研究）测试

测试为生产或服务的决策提供信息。信息包括已知和未知的。

已知信息有两种状态：

• 显性信息
• 隐性信息。

未知信息有两种状态：

• 已知存在但尚未被访问的信息
• 未知是否存在的信息。

想了解更多关于信息类型及其相关实际含义的详细信息，请参阅知识管理实践指南。

根据信息的不同状态，关于软件测试有两种观点：

• 断言（或脚本）测试旨在验证组件、生产或服务是否满足基于议定要求的预定义标准。
• 探索性（或研究性）测试旨在发现有关服务、组件、产品、服务或环境的未知信息，以识别预定义标准尚未解决的风险。

这两种方法应结合起来并维持平衡；仅遵守其中一个会降低有关产品和服务的信息的质量，这可能会导致管理决策无法达到最优。图2.2说明了测试如何影响可用信息。

图2.2测试有助于确认和发现信息

2.2.4.1 断言测试方法

断言测试确认关于服务应如何设计、开发和执行的明确期望是否得到满足。

这种类型的测试依赖于明确表达和记录的期望（通常以验收标准的形式），还需要创建经过测试的制品。

可以根据要测试的内容以及组织是否具有所需的工具来手动或自动执行断言测试。无论哪种方式，断言测试都基于已记录的测试脚本，这些脚本以日常或编程语言来描述验收标准、测试操作以及通过/不通过的标准。自动化测试在软件和数字化基础设施中很常见，但它也可以应用于服务的其他方面，包括管理、通信、系统集成以及与用户的交互。

因其本质，断言测试受到一些限制：它只能在有限的情况下减少已知和记录的风险。它也受要测试的产品或服务的测试策略的限制；为了提供足够的而不是彻底的保证，可以省略一些已知的风险。

2.2.4.2 探索性测试方法

探索性测试基于对产品、服务或环境中的未知因素的调查，目的是发现与服务的感知质量和价值相关的信息。它依赖于横向和批判性思维技能，并且通常基于对可能的产品漏洞和相关威胁的探索。

探索性测试通常被误认为是随机的，非结构化的。实际上，它是由称为测试章程小型测试任务构成的，这些任务将测试重点放在目标区域，调查特定的产品风险。

在敏捷开发以及信息和组织系统日益复杂的情况下，这种方法就显得至关重要了。它使（我们）能在产品和服务生命周期中进行快速学习和反馈循环，这实现了产品和服务的持续改进。

2.2.5 持续验证和测试

服务验证和测试实践不仅仅是测试可发布并运行的产品或服务，这些活动还应该贯穿整个服务生命周期，如图2.2中所示。

验证和测试活动创建了重要的反馈回路，这些反馈回路告知数字化产品生命周期的每个步骤，如表2.1所示。

表2.1整个数字化产品生命周期的验证和测试

2.3 范围

服务验证和测试实践的范围包括：

• 将产品或服务的需求转换为部署和发布管理验收准则
• 建立测试方法，并为新的或变更的产品和服务定义测试计划定义测试计划
• 通过测试消除新的或变更的产品和服务的风险和不确定性
• 不断审查测试的方法，提升测试效率

有一些活动和职责范围，尽管它们与服务验证和测试实践密切相关，但并未包含在本实践中。表2.2中列出了这些内容，以及在哪些实践中可以找到这些信息的指引。重要的一点是记住：ITIL的实践仅仅是价值流背景下使用的工具的集合；它们应视情况酌情结合。

表2.2 在其他实践指南中描述的与服务验证和测试实践相关的活动

2.4 实践成功因素

定义： 实践成功因素

实践为达成目的所必需的功能组件的组合。

实践的成功因素（PSF）不仅仅是一项任务或活动，因为它涵盖了服务管理四维模型的组件。一个实践中PSF的活动与资源的本质相互之间可能有所不同，但它们共同作用确保实践有效进行。

服务验证和测试实践包含以下PSF：

• 定义并议定验证及测试组织的产品、服务和组件的方法，符合组织对服务变更的速度和质量要求；
• 确保新的和变更的组件、产品和服务符合议定的准则

2.4.1 定义并议定验证及测试组织的产品、服务和组件的方法，符合组织对服务变更的速度和质量要求

服务验证应该建立一种方法来捕获关于产品、服务和组件的所有功用和功效需求。此方法应涉及不同的利益相关者及其信息源，例如客户和用户需求和反馈、业务需求、内部和外部合规及法规要求、风险和安全、以及其他需求来源。同时，还应提出将需求转换为服务验收标准的方法。

测试策略将定义为达成项目目标应如何执行测试。测试计划应以测试策略为基础。测试策略还定义了测试管理方法，包括如何组织和控制测试。

测试策略定义了范围内的测试阶段（或级别）和类型。其中，测试阶段包括：

单元测试：由开发人员执行，验证他们开发的内容是否符合需求，（测试）单元通常是被测试隔离的完整系统的组件。

• 集成测试：当开发完成到可以开始集成不同的系统时，需要进行系统间集成的测试。
• 系统测试：在验证系统组件可集成后执行本测试，系统测试考虑的是系统的端到端功能。
• 验收测试：用户验收测试（UAT）是正式的测试阶段，由最终用户验证并确认拟交付的产品是否满足其要求。

测试策略还必须考虑在每个测试阶段适合哪种测试类型。测试类型包括：

• 功能性测试：测试拟交付的系统能做什么。
• 非功能性测试：测试系统中与功能性需求不直接相关的方面。常见的非功能性包括：
  • 性能：正常条件下的行为。
  • 负载：负载增加后的行为。
  • 压力：接近运行上限时的行为。
  • 安全：授权和身份验证系统控制。
  • 可用性：系统用户与系统如何有效契合。
• 回归性：新功能开发（升级）和错误修复（调试）可能会引入意外的系统行为。回归测试旨在验证变更之后，系统是否仍按要求运行。

测试计划将定义每个测试阶段的详细活动、预估工作量和时间表。因此，测试策略定义整体范围和方法，而测试计划则详细说明每个测试阶段。表2.3对此进行了概述。

表2.3 测试策略

2.4.2 确保新的和变更的组件、产品和服务符合议定的准则

项目不尽相同，测试策略必须适合于相关的项目和组织结构。每个测试策略都应达成如下目标：

• 平衡效果和效率，在可用的时间内实现最佳的测试范围覆盖
• 务实，符合项目群的需求及可用资源和技能
• 与开发方法论、所采用的技术以及正开发的系统性质保持一致
• 尽早建立对软件交付的高度信心
• 确认提供的软件的准确性（功能属性）
• 减轻实施新软件带来的业务风险
• 随项目推进，继续改进和优化测试流程
• 识别与测试相关的风险、问题和弱项，并提供适当建议。

为此，测试策略需包含如下内容：

• 测试组织
• 测试计划和控制
• 测试分析和设计
• 测试准备和实施
• 测试进展和报告
• 事件管理
• 测试关闭和退出准则

测试策略必须考虑项目所采用的开发方法。瀑布开发模型通常可以对捕获的用户需求进行早期静态测试和验证。而迭代式的开发方法在编码开始之前可能都无法提供完整的用户需求。所以测试策略应与之相适应。

测试策略还必须考虑所涉及的系统/ 服务的类型。例如，在年底测试一个财务系统采用的方法就与测试电子商务网站的方法截然不同。综合考虑构成测试环境的基础很重要，即验证质量所需的流程、系统、资源和管理。

测试不仅限于测试软件制品本身。数据迁移、培训、运行准备情况，发布管理和报告也是测试需要特别关注的领域。

2.4.2.1 测试组织

进行系统测试的人员应与系统开发人员相互独立。测试人员和开发人员的思维模式各不相同。开发人员通常旨在证明他们开发的东西符合要求，而测试人员旨在证明需求已被满足，且未引入其他问题。

为提升测试效果，组织应鼓励将测试与开发进行区分。应明确定义参与测试的人员的角色和职责，包括测试管理、测试分析人员的角色，以及涉及事件管理、配置管理、变更控制、部署和发布的支持者的角色。

2.4.2.2 测试计划和控制

如果软件开发生命周期遵循基于sprint的方法，则测试应包含在sprint计划中。即使需要必备的存档和驱动程序，每个sprint都应交付该sprint范围内的可测试的产出物。

可用来测试的发布版本包括了累加的有效载荷（新事物）和回归影响（需要测试以确认它们可以继续按照要求工作）。

从连续和回归方面来看，对发布的威胁通常包括：

• 为满足需求而引入的新功能（连续和回归威胁）。该威胁源自现有的项目。
• 对新功能的错误修复（连续和回归威胁）。该威胁源自现有的项目。
• 生产环境服务的修补（回归威胁）。该威胁源自生产服务提供者。
• 对生产环境服务的维护发布（回归威胁）。该威胁源自生产服务提供者。

2.4.2.3 测试分析和设计

仅从整体覆盖率维度报告测试进度不能支持已知的风险评估。为了使测试进度报告有意义，测试应该与项目可交付成果和需求相结合。

每个提交测试的发布都包含一个有效负载。有效负载可以分为有效负载元素（PE）。每个PE都有一个可进行报告的离散的测试包。

例如，在一个基于Web的订单系统中，计划进度表已定义了一个sprint：

• PE 1：为客户提供短代码查找功能（带有回归影响的连续可交付物）
• PE 2：允许通过信用卡付款（带有回归影响的连续可交付物）
• PE 3：将订单总额作为自动更新的字段，显示到订单页上，代替用户需手动点击“计算订单总额”的功能（带有回归影响的连续可交付物）
• PE 4：此冲刺中有多达十小时用于缺陷修复，以解决先前sprint（连续和回归交付物）中未解决的缺陷。

测试审查了项目计划表、需求和功能设计文档副本后，预计需要45个测试案例以覆盖这个sprint的所有累加交付物。另外，在考虑sprint的回归风险后，测试又识别了另外25个测试案例，因为这个sprint的开发影响了系统的核心功能。

如果计划在单个功能测试阶段执行两个三天的测试周期，那么就会是一个包含70个测试案例的测试包。

第一个测试周期的报告可能会显示，测试第二天结束前80％的测试案例已运行并通过。但在未确认哪些测试已运行哪些将要运行之前，就不能认为这是一个好结果。所有回归测试案例都通过了测试将表明该sprint没有引入回归性问题。

对功能进行测试并记录测试沟通过的结果，但未执行回归测试，会造成对新开发的产品充满欣喜，但这并不代表系统未收到损害。重要的是要考虑实现PE并预先对其进行汇报。

在上例中，按计划还剩一天用来测试，还有十项回归测试和五项累加测试未完成，这将成为其余测试工作的重点。

为进一步细分回归测试案例，测试人员可以根据待测试系统的核心功能，定义测试的重点领域。订单输入是一个重点领域，客户计费则是另一个。通过对重点领域的回归测试进行分类，可以更好评估遗留的的测试风险。

2.4.2.4 阶段和周期

定义了所需测试范围后，测试人员可以按PEs和重点领域考虑测试时间表。测试环境部署和发布后，应立即开始测试。要着重考虑PEs和重点领域测试的顺序。默认是尽快测试最复杂或最新的开发内容（这些开发通常有最高的风险）。

必须先确定测试范围，并预估测试执行时长。并且考虑到缺陷会影响测试的执行情况，也需要预估缺陷率，并将其影响列入测试执行计划中。

要规划针对全新系统的测试会比较难。对于计划而言，基于产出结果的估算非常重要，并且由于系统已通过迭代测试，估算也可相应优化。

用测试案例来表达缺陷的影响可能很有用。

例：

测试团队已分析了最新销售订单处理系统中的下一个发布。对PEs和重点领域的分析已经完成。已经确定了172个测试案例可以涵盖PEs，但同时圈定了包含150个测试案例的标准回归包，以及根据PEs特性筛选的另外60个回归测试案例，得出的回归测试包总量有210个测试案例。在此示例中，回归测试要手动执行。

在测试计划阶段，假定20％的PE测试案例（共34个）和10％的回归测试案例（共21个）将导致缺陷。

并非所有缺陷都是平等的。有些很容易分类和修复，而有些则微不足道。缺陷被分类为复杂、标准或轻微的问题，并分配了相应的解决时长。

表2.4列示了预估的55个缺陷的信息。

表2.4 调整后的缺陷总数

加权因素可用于结合缺陷的复杂性进行总数调整。调整后的缺陷总数可视为要执行额外的测试案例。将这些计入测试范围，会为缺陷修复留出余地。

对于测试执行环节的计划中，需要假定测试人员执行一个测试案例需要多长时间。

估算时以“每人每天测试案例数”（TPTPD）为单位可能会很有用。与缺陷估计一样，并非所有测试都是相等的：某些测试比其他要花费更长的时间。

表2.5概述了示例范围中的382个测试案例（172个PEs和210个关注区域）的信息。

表2.5 382个 测试案例的执行时长估计

表2.5显示了测试全覆盖时预计的测试时长。要缩短测试时长，就要增加测试人员，或缩小测试范围。

在以上示例中，PEs和重点领域得到同等对待。通过分别估计这些数据可以获得更大的精度。

测试时间表应按测试阶段来组织，并分成一个或多个周期。每个周期都明确定义测试范围，包括PEs和重点领域，风险最高的一般优先测试。

较大型的测试阶段通常有三个周期。表2.6概述了三个测试周期测试内容如何选择的具体方法。

表2.6 包含3个周期的测试阶段

2.4.2.5 测试准备和执行

测试执行的规划可能是一项艰巨的任务。需要预见许多因素，以便测试执行可以推进。需要计划诸如环境创建、数据创建、用户帐户和角色配置等因素。

计划安排测试准备阶段的活动并确定其作用和责任。通过每日旁站会跟踪进度可能很有用。测试准备本身应作为项目来对待，需要常规的项目管理技术来确保成功。

在正式执行测试之前，需要成功运行商定数量的环境测试和系统验证测试。此外，应保护好准备的测试数据。生成测试数据通常很耗时。仅当待测试的系统可以支持测试范围时，才使用已创建的数据。

执行测试时，确保持续的动力很重要。通常，测试初期会完全走不通，这应是意料之中的。应有合适的问题解决小组待命，优先支持并快速解决早期问题。通常，问题解决小组是被占用的，在待命的同时，支持正在进行的开发任务，准备系统的下一个发布。

通常，测试的最大威胁是事件。为确保始终专注于测试执行，缺陷经理的责任是确保缺陷快速解决，并确定优先级以支持测试执行进度。

作为缺陷管理流程的一部分，需要明确定义缺陷严重性和优先级。严重性衡量缺陷对系统发布的影响。优先级是支持测试计划的。但是，重要的是要记住，关键严重缺陷不一定是最高优先级。

如果开发人员采用sprint的开发管理模式，则每个sprint中需要将数小时分配给测试缺陷修复（可分配问题解决小组的资源来支持测试）。测试缺陷经理应确保缺陷得到调试、修复和部署并重新测试，支持测试执行计划。

测试缺陷经理应关注KPI，例如发布中识别的缺陷数，以确定可能需要额外培训和支持的地方。KPI专注于那些可能有最大化改进的领域。

2.4.2.6 评估测试准出标准和报告

测试人员知道何时应停止测试，这很重要。

测试准出标准是测试分析和设计阶段所定义的，用于识别所测试的系统何时足够好。测试报告将引用测试准出标准和项目成果，汇报例如测试是否将按时完成。如果报告显示按时完成存在问题，则需要采取改正措施。从PEs和重点领域的角度考虑测试执行很有用。通过这种方式，报告使您可以更直观地了解所具有的风险。

如果在常规发布的回归测试中重复出现相同的重点领域的功能，则通过标准化测试执行时间表，并将发布中测试的执行进度与上一次的X版本进行比较，可以清楚地了解测试的轨迹趋势。

至少应该每天和每周报告测试状况，详细说明测试执行的覆盖范围以及以PEs和重点领域（回归测试）为维度的测试通过/失败率。这些报告将提供有关测试能力绩效的度量标准，例如实际TPTPD，缺陷率（严重性分布），调试率和首次修复率，并评估测试执行的轨迹。

2.4.2.7 测试完成

一旦最终测试结束（已满足准出标准），就可以启动测试完成环节。根据系统的性质，这可能在测试结束时触发。在其他情况下，测试完成后，在系统部署和发布后也可能会有前期支持（ELS）或维护阶段。通常，在预定义的ELS阶段关键的测试资源会保留，直到系统在生产环境稳定运行。

这将涉及：

• 将资源从测试活动中正式释放，并移交给日常业务（BAU）运维
• 归档并列示测试资产，包括测试策略，计划，报告和脚本
• 基于测试资产开展移交给BAU的工作，尤其要考虑BAU运维支持所需维护的回归测试包。

记录测试中的经验教训，包括做得好的和不好的。为了支持持续改进实践，重要的是要确保将汲取的教训纳入测试策略。详细说明哪些经验教训正在处理/未复现/未处理。默认情况下，那些未处理和/或重复的经验教训应转移到下一个经验教训环节。

​​​​​​​2.5 关键指标

ITIL实践的有效性和绩效，应该以每个实践所贡献的价值流的背景进行评估。与任何工具的性能一样，实践的绩效只能在应用的背景下评估。但是，工具在设计和质量上可能会有很大差异。在使用这些工具时，这些差异决定了工具的潜力或能力是否有效。有关度量标准，关键性能或绩效指标（KPI）的其他有助于此技术的进一步指导，请参见度量和报告实践指南。

服务验证和测试实践的关键指标已映射到其PSF。它们可以用作价值流背景中的KPI，以评估实践对这些价值流的效果和效率的贡献。表2.7罗列了一些关键指标的示例。

表2.7 实践成功因素的关键指标示例

对于正在进行中的价值流的管理，以及服务验证和测试实践的周期性评估和持续改进来说，将指标正确累加到复杂的指标集中，将使数据使用更加容易。没有唯一的最佳解决方案。

度量标准将基于整体的服务战略和组织的优先级，以及实践所贡献的价值流的目标。

3. 价值流和流程

​​​​​​​3.1 价值流的贡献

像任何其他ITIL 管理实践一样，服务验证和测试实践也贡献多个价值流。重要的是要记住，价值流永远不会由单个实践形成。服务验证和测试实践与其他实践相结合，为消费者提供高质量服务。本实践贡献的主要价值流活动是：

• 设计和转换
• 获取或构建。

图3.1中显示了服务验证和测试实践对服务价值链的贡献。

图3.1 服务验证和测试实践对价值链的贡献热图

​​​​​​​3.2 流程

每个实践可能包含一个或多个履行该实践目的所必需的流程和活动。

​​​​​​​定义：流程

一组相互关联或交互的活动，可将输入转换为输出。流程接受一个或多个定义的输入，并将其转换为定义的输出。流程定义活动的顺序及其依赖关系。

服务验证和测试的活动构成了三个流程：

• 测试方法和模型管理
• 服务验证
• 执行测试。

3.2.1 测试方法和模型管理

该流程包括表3.1中列出的活动，并将输入转换为输出。

表3.1测试方法和模型管理的输入、活动和输出流程

图3.2显示了这个流程的流程图。

图3.2测试方法和模型管理流程的工作流

表3.2描述了测试方法和模型管理流程中的活动。

表3.2 测试方法和模型管理流程中活动的描述示例

3.2.2 服务验证

该流程包括表3.3中列出的活动，并将输入转换为输出。

表3.3 服务验证流程的输入、活动和输出

图3.3显示了流程的工作流图。

图3.3 服务验证流程的工作流

表3.4 服务验证流程中活动的示例说明

3.2.3 执行测试

该流程包括表3.5中列出的活动，并将输入转换为输出。

表3.5 测试的输入、活动和输出流程

图3.4显示了流程的工作流图。

图3.4执行测试的工作流

表3.6测试执行中的活动的示例说明

4. 组织和人员

​​​​​​​4.1 角色、能力和责任

实践指南不描述实践管理角色，如实践所有者、实践负责人或实践教练。相反，指南关注特定的每个实践的专门角色。每个角色的结构和命名可能因组织而异，因此不应强制，甚至不应推荐ITIL中定义的任何角色。

请记住，角色并非职位头衔。一个人可担任多个角色，一个角色也可以分配给多个人员。

对角色的描述以流程和活动为背景。每个角色都具有基于表4.1中所示模型的能力概括。

表4.1能力编码和能力概括

表4.2中列出了服务验证和测试实践涉及的角色示例，以及相应的能力概括和特定技能。

表4.2负责服务验证和测试活动的角色示例

4.2 组织架构和团队

4.2.1 组织服务验证和测试

大多数服务提供者都保留服务验证和测试实践，以确保其基于风险的质量保证方法是一致的。重要的是要考虑到测试（或经常是质量保证）是最容易适用于软件生命周期的术语。服务验证是一个更广阔的领域，除了软件、文档和数字化基础设施之外，还包括产品和服务组件。从历史上看，这意味着测试团队和验证团队是不同的：测试团队专注于应用程序测试，验证团队更接近服务设计师和架构师。两者都应在测试策略中概述的风险偏好内起作用。

4.2.2 服务验证专家

服务的设计人员或架构师可以满足此角色的要求，以确保在测试期间满足业务中建立的验收标准或技术要求和约束，并且更新后的服务和产品也符合要求。

4.2.3 服务测试专家

这是本实践中的核心角色，通常称为“测试人员”或“ QA工程师”。他们的职责包括：

• 执行测试计划和设计中定义的测试
• 记录和报告测试结果，包括不成功的测试引发的bug或事件记录
• 管理测试环境和相关资源。

5. 信息和技术

​​​​​​​5.1 信息交流

服务验证和测试的有效性是基于所使用的信息的质量。这些信息包括但不限于：

• 测试策略
• 测试标准
• 测试模型
• 测试计划
• 测试记录
• 测试结果和报告。

这些信息可以采用各种形式。实践的关键输入和输出在第3节中列出。

服务验证和测试实践可以从自动化中大大受益。在可行且有效的地方，可涉及表5.1中列示的解决方案。

表5.1 服务验证和测试活动的自动化解决方案

6. 合作伙伴和供应商

很少有服务仅使用组织的自有资源。即便不是全部，大多数服务都依赖于其他通常由组织之外的第三方提供的服务（请参阅ITIL Foundation：ITIL 4出版物的2.4节，可找到服务关系的模型）。服务设计、架构管理和供应商管理的ITIL实践中介绍了由支撑服务构成的关系和依赖。

通常，服务提供商寻求外部质量保证和测试职能以自然减轻测试的偏差。外部管理的服务提供者、团队和个人提供在软件领域以及特定的非功能测试领域中的测试能力、服务和产品。但是，针对特定服务客户部署的整体验证服务通常需要由服务提供者组织，来促进内部服务测试和验证实践，确保在服务引入过程中全面覆盖验收标准。

在由外部商业服务提供者管理服务交付价值流的情况下，客户组织可能会寻求另外的专业的服务部署能力，以确保满足其要求。也存在外部的独立的（这一点最重要）服务验证和测试供应商的保证服务。

在组织旨在确保快速有效的服务验证和测试的情况下，他们通常会试图与合作伙伴和供应商达成合作协议，消除不利于沟通、协作和决策方面的正式官僚的障碍（更多信息，请参见供应商管理实践指南）。

7. 重要提醒

实践指南的大部分内容应视为组织在建立和培育自身实践相关领域时可考虑的建议。实践指南是组织可以考虑的主题目录而非答案列表。在使用ITIL实践指南的内容时，各组织应始终遵循ITIL指导原则：

• 聚焦价值
• 从你所处的地方开始
• 基于反馈迭代推进
• 协作和提升可视化程度
• 通盘思考和工作
• 保持简单实用
• 优化和自动化。

关于指导原则及其应用的更多信息，请参见ITIL Foundation：ITIL 4 出版物的4.3节。

8. 致谢

AXELOS有限公司感谢所有为该指南的开发做出贡献的人。这些实践指南融合了ITIL社区前所未有的热情和反馈。AXELOS特别要感谢以下人员：

​​​​​​​8.1 作者

Peter Bodman and Dan Ashby,

​​​​​​​8.2 审稿人

Roman Jouravlev and Dinara Adyrbai