Version 23.1 by superadmin on 2022/01/16, 20:59
Show last authors
1 **申明：**
2
3 本系列ITIL 4实践中文版本由ITIL先锋论坛专家委员会组织翻译，国内众
4 多从事ITIL理论推广及落地实践的专家们参与，需要下载最新翻译版本请关注微信
5 公众号：ITILXF，也可访问ITIL4中文知识库网站：itil4hub.cn。
6
7
8 请注意，ITIL先锋论坛专家团队仅仅只是进行了这些著作的语种转换工作，我们并不拥有包括原著以及中文发行文件的任何版权，所有版权均为Axoles持有，读者在使用这些文件（含本中文翻译版本）时需完全遵守Axoles 和 TSO所申明的所有版权要求。
9
10
11 本文档翻译工作参与人员：
12
13 翻译：贺欢
14
15 审校：李威
16
17
18 总审：长河
19
20 审核：汤维
21
22 统筹：常宏
23
24
25
26 ----
27
28 {{box cssClass="floatinginfobox" title="**Contents**"}}
29 {{toc/}}
30 {{/box}}
31
32 = **1. 关于本文档** =
33
34 本文档为服务验证和测试实践提供了实用指南。分为五个主要部分，涵盖：
35
36 * 本实践的概括信息
37 * 本实践相关的流程和活动及其在服务价值链中的作用
38 * 实践中涉及的组织和人员
39 * 支持本实践的信息和技术
40 * 对本实践的合作伙伴和供应商的考虑
41
42
43 == **1.1** **ITIL®4 认证方案** ==
44
45 本文档中的部分内容可作为以下课程的一部分检验标准
46
47 * ITIL专家创建，交付和支持
48 * ITIL专家高速IT
49
50 详情请参考各部分教学大纲文档。
51
52
53
54 ----
55
56 = **2. 一般信息** =
57
58
59 == **2.1** **目的和描述** ==
60
61 (% class="wikigeneratedid" id="H5173952E4FE1606F" %)
62 **关键信息**
63
64 服务验证和测试实践的目的是确保新产品和服务或对其的变更符合定义的要求。服务价值的定义基于客户、业务目标和法规要求的输入，并作为设计和转换价值链活动的一部分。这些输入将用于设立可度量的质量和性能指标，而这些指标又将作为支持验收标准和测试要求的定义。
65
66
67 服务验证和测试实践涉及减少因新的或更改的产品和服务引入到生产环境的风险和不确定性。在此实践中通过计划并执行适当的测试来操作。
68
69 系统越大越复杂，则需要进行的测试越多。但是，由于时间和成本的限制，即使是较小的或简单的系统也无法进行穷尽的测试。因此，选择测试的内容很重要。验证和测试的范围和级别定义的关键注意事项包括：
70
71 * 生产或服务必须满足的议定要求
72 * 影响以及偏离议定要求的可能性。
73
74 在可能的背景和偏差影响中理解（测试）需求，有助于对测试的重要领域有一个明智的了解。
75
76 该实践关乎对正在测试的服务的质量的信心。这不是说它是完美的。通过测试可以赢得信心，以证明服务将按要求运行，符合要求并且没有重大缺陷。
77
78
79 === 2.1.1 服务验证 ===
80
81 服务验证在产品和服务生命周期的早期阶段（概念和设计）执行。它着重于确认议定的服务设计满足议定的服务要求，并为下一阶段（开发，部署和发布）建立验收标准。这些验收标准将通过测试产品和服务组件、产品和服务得以验证。
82
83 验证服务要求应遵循的结构，通常涵盖功用、功效、体验、可管理性和合规性。也可能包括其他要求。
84
85 服务验证确保服务验收标准得以定义、验证并记录，并告知测试活动的范围和重点。
86
87
88 === 2.1.2 测试 ===
89
90 基于通过服务验证识别的验收标准，开发并实施测试策略和测试计划。
91
92 测试策略定义了总体测试方法。测试策略可以应用于环境、平台、服务集或单个产品或服务。对比在组织内自开发的产品和服务与从供应商获得的产品和服务，测试所覆盖的生产和服务的生命周期阶段可能有所不同。
93
94 架构管理、软件开发和管理、项目管理、基础设施和平台管理实践的变更对服务验证和测试实践产生了很大的影响。敏捷方法、IT基础设施数字化，面向服务的架构以及软件开发和管理的自动化给服务验证和测试实践带来了新的挑战和机遇。为了满足当今的需求，服务验证和测试应该更快、更灵活并且不断发展。要做到这一点，仅当本实践与上述实践以及其他实践（包括发布管理、部署管理、事件和问题管理实践）紧密集成在一起时，才有可能实现。
95
96 有效的验证和测试基于测试人员、开发人员和操作团队之间紧密的协作以及增强的工具和自动化方法。
97
98 另一个重要趋势是将验证和测试范围扩展到产品和服务的技术范围之外，包括用户体验和感知。
99
100 传统上，服务测试是基于需求规范定义的先验知识，通过检查软件应如何工作或不应如何工作，来确认与明确要求相关的期望的行为。今天，测试还涉及探索和发现有关意外情况的信息，例如产品风险和以下方面的变量：
101
102 * 软件
103 * 有关软件解决方案的想法
104 * 依据想法创建的制品
105 * 用户体验和用户接口设计
106 * 模型和框架
107 * 架构和代码设计
108 * 代码
109 * 工具
110 * 流程
111
112
113 == **2. 2 术语和概念** ==
114
115
116 === 2.2.1基于风险的测试 ===
117
118 基于风险的测试是测试行业中的通用术语。通常，人们把风险测试理解为由不同类型产品风险构成的和驱动的测试，它与那些正被测试的功能和产品组件相关。
119
120 专注于风险是有益的，因为它突出了服务可能如何失败。然后可以对此进行调查，以发现有关该软件及其质量的信息。
121
122 通常在软件测试中，人们关注测试的类型。比如测试类型包括功能测试、回归测试、性能测试、安全测试、可用性测试、浏览器兼容测试、可访问性测试、端到端测试和集成测试。这些测试类型关注不同类型的风险。例如，功能测试着重于功能风险，而回归测试则着重于软件回退的风险。
123
124 尽管人们倾向于考虑10到15种测试类型，但许多团队在测试策略中仅包括5到8种测试类型。由于此原因，并且因为影响服务的许多类型的产品风险，很少与一种类型的测试相关联，因此关注基于风险的测试非常重要。
125
126
127 === 2.2.2 发现风险 ===
128
129 在服务验证和测试实践活动中，识别产品风险与确认风险得到有效解决同等重要切有价值。
130
131 在产品的早期阶段进行的服务验证和测试活动，将输出有关产品风险，变量，未知数等信息。相反，在产品生命周期的后期阶段进行的测试活动，会发现问题和其他有关服务实际情况的信息，然后组织可以对这些信息做出反应。即便服务在运行中，组织也应继续挖掘有关风险，变量和未知数的信息。反馈仍在继续，但会导致更长的反馈环，返回到想法、用户故事和设计。
132
133 例如，在软件开发中，敏捷用户故事制品和验收标准制品很少会关注产品风险。这些制品通常与有关软件功能或互连性的一般期望有关。在定义验收标准时，识别与用户故事相关的风险非常重要。
134
135 识别后，应捕获风险。思维导图是常用的工具，因为它可以用来创建一个易用、轻量、易读的风险图，并可以在整个生产生命周期服务设计活动以及以后的阶段进行探索性测试中使用。
136
137 识别不同种类的产品风险可能很困难，但是有一些方法可以构造验收标准和测试活动，来提升成功的可能性，例如：
138
139 * 在整体层面考虑测试的对象，然后仔细进行测试，包括有形和无形的制品。积极考虑产品、服务或组件的：
140 ** 潜在目的
141 ** 属性
142 ** 不同用户
143 ** 集成部分
144 ** 架构
145 ** 等等
146 * 探索每个方面的变量。
147 * 识别并讨论与这些变量有关的产品风险。可以确定的风险示例包括：
148 ** 可访问性风险
149 ** 可用性风险
150 ** 魅力/喜好风险
151 ** 兼容性风险
152 ** 环境集成风险
153 ** 功能风险
154 ** 接口风险
155 ** 本地化风险
156 ** 可维护性风险
157 ** 可观察性风险
158 ** 性能风险
159 ** 可移植性风险
160 ** 可靠性风险
161 ** 响应风险
162 ** 可扩展性风险
163 ** 安全风险
164 ** 稳定性风险
165 ** 可测试性风险
166 ** 可用性风险
167 * 评估风险，并决定是否要花费更多的时间和精力来减轻或测试风险。有关此主题的更多信息，请参考风险管理实践指南。
168 * 如果存在重大风险，请创建一个风险地图。风险图是面向服务设计人员和开发人员的制品。它们还有助于追溯到测试章程，该章程通过对测试特定领域中的特定风险来构建探索性测试。
169
170
171 === 2.2.3 在不同环境中进行测试 ===
172
173 基于风险的方法对于测试环境以及确定在哪个阶段进行测试也很有帮助。
174
175 在开发环境中可以测试许多风险。开发环境中的反馈周期非常快，因为通常可以快速编写代码并将其用于测试，以应对多种产品风险，然后在需要时重构代码。但是，某些风险无法在开发环境中进行测试。他们可能需要更严格地集成的环境，例如专用的测试环境。
176
177 使用专用的测试环境可能会比较慢，因为创建环境需要时间，如果发现任何问题，重构代码的反馈时间会变得更长，在开发环境中重新测试，然后将这些修订再次合并到测试环境中。在开发环境中完成的测试无需重复测试，但是对开发环境中无法测试的风险则需要进行测试。
178
179 有时，搭建一个发布前的环境（准生产环境）是明智的。某些风险只能在共享的测试环境中进行测试，例如与数据流有关的风险，平台风险或某些集成风险。
180
181 最后，某些风险只能在实际的生产环境中进行测试。
182
183 图2.1代表了可执行大部分测试的环境
184
185 (% style="text-align:center" %)
186 [[image:1639667941877-898.png]]
187
188 图2.1测试三角形
189
190
191 大多数风险都可在开发环境中尽早测试。其余的大多数可在团队测试环境中测试。另外剩余的大多数也可在准生产环境中得以测试。最后遗留的风险在生产环境中可进行测试。
192
193
194 === 2.2.4 断言（脚本）和探索（研究）测试 ===
195
196 测试为生产或服务的决策提供信息。信息包括已知和未知的。
197
198 已知信息有两种状态：
199
200 * 显性信息
201 * 隐性信息。
202
203 未知信息有两种状态：
204
205 * 已知存在但尚未被访问的信息
206 * 未知是否存在的信息。
207
208 想了解更多关于信息类型及其相关实际含义的详细信息，请参阅知识管理实践指南。
209
210 根据信息的不同状态，关于软件测试有两种观点：
211
212 * 断言（或脚本）测试旨在验证组件、生产或服务是否满足基于议定要求的预定义标准。
213 * 探索性（或研究性）测试旨在发现有关服务、组件、产品、服务或环境的未知信息，以识别预定义标准尚未解决的风险。
214
215 这两种方法应结合起来并维持平衡；仅遵守其中一个会降低有关产品和服务的信息的质量，这可能会导致管理决策无法达到最优。图2.2说明了测试如何影响可用信息。
216
217
218 (% style="text-align:center" %)
219 [[image:1639667988401-414.png]]
220
221 图2.2测试有助于确认和发现信息
222
223
224 ==== 2.2.4.1 断言测试方法 ====
225
226 断言测试确认关于服务应如何设计、开发和执行的明确期望是否得到满足。
227
228 这种类型的测试依赖于明确表达和记录的期望（通常以验收标准的形式），还需要创建经过测试的制品。
229
230 可以根据要测试的内容以及组织是否具有所需的工具来手动或自动执行断言测试。无论哪种方式，断言测试都基于已记录的测试脚本，这些脚本以日常或编程语言来描述验收标准、测试操作以及通过/不通过的标准。自动化测试在软件和数字化基础设施中很常见，但它也可以应用于服务的其他方面，包括管理、通信、系统集成以及与用户的交互。
231
232 因其本质，断言测试受到一些限制：它只能在有限的情况下减少已知和记录的风险。它也受要测试的产品或服务的测试策略的限制；为了提供足够的而不是彻底的保证，可以省略一些已知的风险。
233
234
235 ==== 2.2.4.2 探索性测试方法 ====
236
237 探索性测试基于对产品、服务或环境中的未知因素的调查，目的是发现与服务的感知质量和价值相关的信息。它依赖于横向和批判性思维技能，并且通常基于对可能的产品漏洞和相关威胁的探索。
238
239 探索性测试通常被误认为是随机的，非结构化的。实际上，它是由称为测试章程小型测试任务构成的，这些任务将测试重点放在目标区域，调查特定的产品风险。
240
241 在敏捷开发以及信息和组织系统日益复杂的情况下，这种方法就显得至关重要了。它使（我们）能在产品和服务生命周期中进行快速学习和反馈循环，这实现了产品和服务的持续改进。
242
243
244 === 2.2.5 持续验证和测试 ===
245
246 服务验证和测试实践不仅仅是测试可发布并运行的产品或服务，这些活动还应该贯穿整个服务生命周期，如图2.2中所示。
247
248 验证和测试活动创建了重要的反馈回路，这些反馈回路告知数字化产品生命周期的每个步骤，如表2.1所示。
249
250
251 表2.1整个数字化产品生命周期的验证和测试
252
253 |数字化产品生命周期阶段和相关制品|验证|断言测试|探索性测试
254 |理念|-|-|评估这些理念，以及其与客户和组织的需求的相关性
255 |史诗、用户故事、功能、促成因素等|验证史诗、用户故事以及功能/促成因素，生成对UX/UI设计、架构和代码设计的验收标准|-|评估史诗、用户故事以及功能，发现不一致和错失的机会
256 |UX / UI设计|(((
257 验证设计，以确认其基于史诗，用户故事和功能，并且与定义的规则准则相匹配。
258
259 定义或更新架构及代码设计验收标准。
260
261
262 )))|测试UX / UI线框，以确认其符合架构的设计策略和准则（如果适用）|评估探索UX / UI线框，以发现识别不一致和错误
263 |架构和代码设计|(((
264 验证设计，确认其基于史诗，用户故事和功能，并与定义的准则相匹配
265
266 生成开发代码的验收准则
267 )))|测试对架构和代码设计产出物制品进行测试，以确认其满足架构和设计策略和准则（如果适用）|评估探索架构和代码设计产物制品，以识别发现不一致和错误
268 |代码单位|(((
269 代码的验证，以确认其根据商定的设计开发，并已经完整完成，同时遵守商定的架构标准。
270
271 更新可运行的软件的验收准则
272 )))|执行自动化单元测试（有时是手动的单元测试），以确认每个单元均按照商定的准则进行设计|(((
273 同行评审，结对编程和其他探索性测试，以识别验收标准未涵盖的错误
274
275
276 )))
277 |可运行的软件|(((
278 基于议定的标准进行软件的验证，以确认它是否具备完整性，并遵守议定的架构标准。
279
280 定义并更新部署和发布的验收标准
281 )))|根据议定的准则，执行自动化单元测试（有时是手动的单元测试），确认软件是否按设计执行|对软件进行评审和评估探索，发现错误和验收准则中未涵盖的错误和机会
282 |部署和发布流水线|(((
283 验证部署和发布工具的流程和方法，以及确认其它们是否符合议定的需求。
284
285 更新部署和发布的验收准则
286 )))|对流水线发布的工具和流程进行自动化测试（有时是手动测试），确认其按照约定工作|评估探索发布的流水线工具和流程，发现验收准则中未涵盖的错误和机会
287 |软件部署|(((
288 验证部署的完整性和正确性
289
290 更新发布验收标准和回归测试准则
291 )))|对已部署的制品进行自动化测试，以确认其满足议定的验收准则|评估探索已部署的制品和环境，发现验收准则中未涵盖的错误和机会
292 |服务发布|(((
293 验证已发布的服务，以确认其完整性，并且符合商定的设计规范
294
295 更新实时服务验证准则
296 )))|执行服务运营的自动化和手动测试，包括用户验收及用户销售活动测试|评估探索发布的服务，发现验收准则中未涵盖的错误和机会
297 |运维中的服务|基于议定的准则和服务级别管理信息，验证服务质量（含功用、功效和体验级别）基于公认的准则和服务级别管理信息。|执行回归测试，以确认以前的测试结果仍然有效|混沌工程学，发现服务漏洞和，以及验收准则和正式的服务质量控制控件未涵盖的混沌工程至探索服务漏洞以及其他的错误和机会
298
299
300 == **2.3 范围** ==
301
302 服务验证和测试实践的范围包括：
303
304 * 将产品或服务的需求转换为部署和发布管理验收准则
305 * 建立测试方法，并为新的或变更的产品和服务定义测试计划定义测试计划
306 * 通过测试消除新的或变更的产品和服务的风险和不确定性
307 * 不断审查测试的方法，提升测试效率
308
309 有一些活动和职责范围，尽管它们与服务验证和测试实践密切相关，但并未包含在本实践中。表2.2中列出了这些内容，以及在哪些实践中可以找到这些信息的指引。重要的一点是记住：ITIL的实践仅仅是价值流背景下使用的工具的集合；它们应视情况酌情结合。
310
311
312 表2.2 在其他实践指南中描述的与服务验证和测试实践相关的活动
313
314 (% style="width:626px" %)
315 |(% style="width:436px" %)**活动**|(% style="width:188px" %)**实践指南**
316 |(% style="width:436px" %)(((
317 建立关于新产品或服务或其变更的功用和功效的详细要求。
318
319 分析现有功用和功效之外的新的服务要求
320 )))|(% style="width:188px" %)业务分析
321 |(% style="width:436px" %)(((
322 控制测试的成本
323
324 制定测试预算
325 )))|(% style="width:188px" %)成本
326 |(% style="width:436px" %)开发和管理软件|(% style="width:188px" %)软件开发和管理
327 |(% style="width:436px" %)开发和管理基础架构|(% style="width:188px" %)基础设施和平台管理
328 |(% style="width:436px" %)与用户的操作沟通，并收集反馈|(% style="width:188px" %)服务台
329 |(% style="width:436px" %)部署服务和组件|(% style="width:188px" %)部署管理
330 |(% style="width:436px" %)发布服务|(% style="width:188px" %)发布管理
331 |(% style="width:436px" %)持续管理和改进实施|(% style="width:188px" %)持续改进
332
333
334 == **2.4 实践成功因素** ==
335
336 **定义： 实践成功因素**
337
338 实践为达成目的所必需的功能组件的组合。
339
340
341 实践的成功因素（PSF）不仅仅是一项任务或活动，因为它涵盖了服务管理四维模型的组件。一个实践中PSF的活动与资源的本质相互之间可能有所不同，但它们共同作用确保实践有效进行。
342
343 服务验证和测试实践包含以下PSF：
344
345 * 定义并议定验证及测试组织的产品、服务和组件的方法，符合组织对服务变更的速度和质量要求；
346 * 确保新的和变更的组件、产品和服务符合议定的准则
347
348
349 === 2.4.1 定义并议定验证及测试组织的产品、服务和组件的方法，符合组织对服务变更的速度和质量要求 ===
350
351 服务验证应该建立一种方法来捕获关于产品、服务和组件的所有功用和功效需求。此方法应涉及不同的利益相关者及其信息源，例如客户和用户需求和反馈、业务需求、内部和外部合规及法规要求、风险和安全、以及其他需求来源。同时，还应提出将需求转换为服务验收标准的方法。
352
353 测试策略将定义为达成项目目标应如何执行测试。测试计划应以测试策略为基础。测试策略还定义了测试管理方法，包括如何组织和控制测试。
354
355 测试策略定义了范围内的测试阶段（或级别）和类型。其中，测试阶段包括：
356
357 **单元测试：**由开发人员执行，验证他们开发的内容是否符合需求，（测试）单元通常是被测试隔离的完整系统的组件。
358
359 * **集**成测试：当开发完成到可以开始集成不同的系统时，需要进行系统间集成的测试。
360 * **系**统测试：在验证系统组件可集成后执行本测试，系统测试考虑的是系统的端到端功能。
361 * **验收测试：**用户验收测试（UAT）是正式的测试阶段，由最终用户验证并确认拟交付的产品是否满足其要求。
362
363 测试策略还必须考虑在每个测试阶段适合哪种测试类型。测试类型包括：
364
365 * **功**能性测试：测试拟交付的系统能做什么。
366 * **非**功能性测试：测试系统中与功能性需求不直接相关的方面。常见的非功能性包括：
367 ** **性**能：正常条件下的行为。
368 ** **负载：**负载增加后的行为。
369 ** **压力：接**近运行上限时的行为。
370 ** **安**全：授权和身份验证系统控制。
371 ** **可**用性：系统用户与系统如何有效契合。
372 * **回**归性：新功能开发（升级）和错误修复（调试）可能会引入意外的系统行为。回归测试旨在验证变更之后，系统是否仍按要求运行。
373
374 测试计划将定义每个测试阶段的详细活动、预估工作量和时间表。因此，测试策略定义整体范围和方法，而测试计划则详细说明每个测试阶段。表2.3对此进行了概述。
375
376
377 表2.3 测试策略
378
379 | |(% colspan="4" %)测试策略
380 |类型/级别|单元|集成|系统|用户验收测试UAT
381 |功能性|(% rowspan="3" %)单元测试计划|(% rowspan="3" %)集成测试计划|(% rowspan="3" %)系统测试计划|(% rowspan="3" %)用户验收测试计划
382 |非功能性
383 |回归测试
384
385
386 === 2.4.2 确保新的和变更的组件、产品和服务符合议定的准则 ===
387
388 项目不尽相同，测试策略必须适合于相关的项目和组织结构。每个测试策略都应达成如下目标：
389
390 * 平衡效果和效率，在可用的时间内实现最佳的测试范围覆盖
391 * 务实，符合项目群的需求及可用资源和技能
392 * 与开发方法论、所采用的技术以及正开发的系统性质保持一致
393 * 尽早建立对软件交付的高度信心
394 * 确认提供的软件的准确性（功能属性）
395 * 减轻实施新软件带来的业务风险
396 * 随项目推进，继续改进和优化测试流程
397 * 识别与测试相关的风险、问题和弱项，并提供适当建议。
398
399 为此，测试策略需包含如下内容：
400
401 * 测试组织
402 * 测试计划和控制
403 * 测试分析和设计
404 * 测试准备和实施
405 * 测试进展和报告
406 * 事件管理
407 * 测试关闭和退出准则
408
409 测试策略必须考虑项目所采用的开发方法。瀑布开发模型通常可以对捕获的用户需求进行早期静态测试和验证。而迭代式的开发方法在编码开始之前可能都无法提供完整的用户需求。所以测试策略应与之相适应。
410
411 测试策略还必须考虑所涉及的系统/ 服务的类型。例如，在年底测试一个财务系统采用的方法就与测试电子商务网站的方法截然不同。综合考虑构成测试环境的基础很重要，即验证质量所需的流程、系统、资源和管理。
412
413 测试不仅限于测试软件制品本身。数据迁移、培训、运行准备情况，发布管理和报告也是测试需要特别关注的领域。
414
415
416 ==== 2.4.2.1 测试组织 ====
417
418 进行系统测试的人员应与系统开发人员相互独立。测试人员和开发人员的思维模式各不相同。开发人员通常旨在证明他们开发的东西符合要求，而测试人员旨在证明需求已被满足，且未引入其他问题。
419
420 为提升测试效果，组织应鼓励将测试与开发进行区分。应明确定义参与测试的人员的角色和职责，包括测试管理、测试分析人员的角色，以及涉及事件管理、配置管理、变更控制、部署和发布的支持者的角色。
421
422
423 ==== 2.4.2.2 测试计划和控制 ====
424
425 如果软件开发生命周期遵循基于sprint的方法，则测试应包含在sprint计划中。即使需要必备的存档和驱动程序，每个sprint都应交付该sprint范围内的可测试的产出物。
426
427 可用来测试的发布版本包括了累加的有效载荷（新事物）和回归影响（需要测试以确认它们可以继续按照要求工作）。
428
429 从连续和回归方面来看，对发布的威胁通常包括：
430
431 * 为满足需求而引入的新功能（连续和回归威胁）。该威胁源自现有的项目。
432 * 对新功能的错误修复（连续和回归威胁）。该威胁源自现有的项目。
433 * 生产环境服务的修补（回归威胁）。该威胁源自生产服务提供者。
434 * 对生产环境服务的维护发布（回归威胁）。该威胁源自生产服务提供者。
435
436
437 ==== 2.4.2.3 测试分析和设计 ====
438
439 仅从整体覆盖率维度报告测试进度不能支持已知的风险评估。为了使测试进度报告有意义，测试应该与项目可交付成果和需求相结合。
440
441 每个提交测试的发布都包含一个有效负载。有效负载可以分为有效负载元素（PE）。每个PE都有一个可进行报告的离散的测试包。
442
443 例如，在一个基于Web的订单系统中，计划进度表已定义了一个sprint：
444
445 * PE 1：为客户提供短代码查找功能（带有回归影响的连续可交付物）
446 * PE 2：允许通过信用卡付款（带有回归影响的连续可交付物）
447 * PE 3：将订单总额作为自动更新的字段，显示到订单页上，代替用户需手动点击“计算订单总额”的功能（带有回归影响的连续可交付物）
448 * PE 4：此冲刺中有多达十小时用于缺陷修复，以解决先前sprint（连续和回归交付物）中未解决的缺陷。
449
450 测试审查了项目计划表、需求和功能设计文档副本后，预计需要45个测试案例以覆盖这个sprint的所有累加交付物。另外，在考虑sprint的回归风险后，测试又识别了另外25个测试案例，因为这个sprint的开发影响了系统的核心功能。
451
452 如果计划在单个功能测试阶段执行两个三天的测试周期，那么就会是一个包含70个测试案例的测试包。
453
454 第一个测试周期的报告可能会显示，测试第二天结束前80％的测试案例已运行并通过。但在未确认哪些测试已运行哪些将要运行之前，就不能认为这是一个好结果。所有回归测试案例都通过了测试将表明该sprint没有引入回归性问题。
455
456 对功能进行测试并记录测试沟通过的结果，但未执行回归测试，会造成对新开发的产品充满欣喜，但这并不代表系统未收到损害。重要的是要考虑实现PE并预先对其进行汇报。
457
458 在上例中，按计划还剩一天用来测试，还有十项回归测试和五项累加测试未完成，这将成为其余测试工作的重点。
459
460 为进一步细分回归测试案例，测试人员可以根据待测试系统的核心功能，定义测试的重点领域。订单输入是一个重点领域，客户计费则是另一个。通过对重点领域的回归测试进行分类，可以更好评估遗留的的测试风险。
461
462
463 ==== 2.4.2.4 阶段和周期 ====
464
465 定义了所需测试范围后，测试人员可以按PEs和重点领域考虑测试时间表。测试环境部署和发布后，应立即开始测试。要着重考虑PEs和重点领域测试的顺序。默认是尽快测试最复杂或最新的开发内容（这些开发通常有最高的风险）。
466
467 必须先确定测试范围，并预估测试执行时长。并且考虑到缺陷会影响测试的执行情况，也需要预估缺陷率，并将其影响列入测试执行计划中。
468
469 要规划针对全新系统的测试会比较难。对于计划而言，基于产出结果的估算非常重要，并且由于系统已通过迭代测试，估算也可相应优化。
470
471 用测试案例来表达缺陷的影响可能很有用。
472
473 (% class="wikigeneratedid" id="H4F8BFF1A" %)
474 **例：**
475
476 测试团队已分析了最新销售订单处理系统中的下一个发布。对PEs和重点领域的分析已经完成。已经确定了172个测试案例可以涵盖PEs，但同时圈定了包含150个测试案例的标准回归包，以及根据PEs特性筛选的另外60个回归测试案例，得出的回归测试包总量有210个测试案例。在此示例中，回归测试要手动执行。
477
478 在测试计划阶段，假定20％的PE测试案例（共34个）和10％的回归测试案例（共21个）将导致缺陷。
479
480 并非所有缺陷都是平等的。有些很容易分类和修复，而有些则微不足道。缺陷被分类为复杂、标准或轻微的问题，并分配了相应的解决时长。
481
482 表2.4列示了预估的55个缺陷的信息。
483
484
485 表2.4 调整后的缺陷总数
486
487 |分类|固定利率|假设百分比|假定的缺陷数|加权因素|调整后的总计
488 |复杂|3天|50|27（55的50％）|2|54 (27 * 2)
489 |标准|2天|30|17（55的30％）|1.5|26 ( 17 * 1.5)
490 |轻微|1天|20|11（55％的20％）|1|11 ( 11 * 1)
491 |总计| | | | |91
492
493 加权因素可用于结合缺陷的复杂性进行总数调整。调整后的缺陷总数可视为要执行额外的测试案例。将这些计入测试范围，会为缺陷修复留出余地。
494
495 对于测试执行环节的计划中，需要假定测试人员执行一个测试案例需要多长时间。
496
497 估算时以“每人每天测试案例数”（TPTPD）为单位可能会很有用。与缺陷估计一样，并非所有测试都是相等的：某些测试比其他要花费更长的时间。
498
499 表2.5概述了示例范围中的382个测试案例（172个PEs和210个关注区域）的信息。
500
501
502 表2.5 382个 测试案例的执行时长估计
503
504 |TPTPD|假设百分比|测试案例数|一名测试人员的工作时长
505 |5|40%|153|31天
506 |3|35%|134|45天
507 |1|25%|96|96天
508
509 表2.5显示了测试全覆盖时预计的测试时长。要缩短测试时长，就要增加测试人员，或缩小测试范围。
510
511 在以上示例中，PEs和重点领域得到同等对待。通过分别估计这些数据可以获得更大的精度。
512
513 测试时间表应按测试阶段来组织，并分成一个或多个周期。每个周期都明确定义测试范围，包括PEs和重点领域，风险最高的一般优先测试。
514
515 较大型的测试阶段通常有三个周期。表2.6概述了三个测试周期测试内容如何选择的具体方法。
516
517
518 表2.6 包含3个周期的测试阶段
519
520 |**周期1**|**周期2**|**周期3 最终测试周期– FTC**
521 |高风险/ 优先级PEs|较低优先级PEs|最终修复
522 |高优先级重点领域|较低优先级的重点领域|优先重点领域
523 | |周期1的修复|优先的PEs待办项
524 | |周期1的待办项|
525
526
527 ==== 2.4.2.5 测试准备和执行 ====
528
529 测试执行的规划可能是一项艰巨的任务。需要预见许多因素，以便测试执行可以推进。需要计划诸如环境创建、数据创建、用户帐户和角色配置等因素。
530
531 计划安排测试准备阶段的活动并确定其作用和责任。通过每日旁站会跟踪进度可能很有用。测试准备本身应作为项目来对待，需要常规的项目管理技术来确保成功。
532
533 在正式执行测试之前，需要成功运行商定数量的环境测试和系统验证测试。此外，应保护好准备的测试数据。生成测试数据通常很耗时。仅当待测试的系统可以支持测试范围时，才使用已创建的数据。
534
535 执行测试时，确保持续的动力很重要。通常，测试初期会完全走不通，这应是意料之中的。应有合适的问题解决小组待命，优先支持并快速解决早期问题。通常，问题解决小组是被占用的，在待命的同时，支持正在进行的开发任务，准备系统的下一个发布。
536
537 通常，测试的最大威胁是事件。为确保始终专注于测试执行，缺陷经理的责任是确保缺陷快速解决，并确定优先级以支持测试执行进度。
538
539 作为缺陷管理流程的一部分，需要明确定义缺陷严重性和优先级。严重性衡量缺陷对系统发布的影响。优先级是支持测试计划的。但是，重要的是要记住，关键严重缺陷不一定是最高优先级。
540
541 如果开发人员采用sprint的开发管理模式，则每个sprint中需要将数小时分配给测试缺陷修复（可分配问题解决小组的资源来支持测试）。测试缺陷经理应确保缺陷得到调试、修复和部署并重新测试，支持测试执行计划。
542
543 测试缺陷经理应关注KPI，例如发布中识别的缺陷数，以确定可能需要额外培训和支持的地方。KPI专注于那些可能有最大化改进的领域。
544
545
546 ==== 2.4.2.6 评估测试准出标准和报告 ====
547
548 测试人员知道何时应停止测试，这很重要。
549
550 测试准出标准是测试分析和设计阶段所定义的，用于识别所测试的系统何时足够好。测试报告将引用测试准出标准和项目成果，汇报例如测试是否将按时完成。如果报告显示按时完成存在问题，则需要采取改正措施。从PEs和重点领域的角度考虑测试执行很有用。通过这种方式，报告使您可以更直观地了解所具有的风险。
551
552 如果在常规发布的回归测试中重复出现相同的重点领域的功能，则通过标准化测试执行时间表，并将发布中测试的执行进度与上一次的X版本进行比较，可以清楚地了解测试的轨迹趋势。
553
554 至少应该每天和每周报告测试状况，详细说明测试执行的覆盖范围以及以PEs和重点领域（回归测试）为维度的测试通过/失败率。这些报告将提供有关测试能力绩效的度量标准，例如实际TPTPD，缺陷率（严重性分布），调试率和首次修复率，并评估测试执行的轨迹。
555
556
557 ==== 2.4.2.7 测试完成 ====
558
559 一旦最终测试结束（已满足准出标准），就可以启动测试完成环节。根据系统的性质，这可能在测试结束时触发。在其他情况下，测试完成后，在系统部署和发布后也可能会有前期支持（ELS）或维护阶段。通常，在预定义的ELS阶段关键的测试资源会保留，直到系统在生产环境稳定运行。
560
561 这将涉及：
562
563 * 将资源从测试活动中正式释放，并移交给日常业务（BAU）运维
564 * 归档并列示测试资产，包括测试策略，计划，报告和脚本
565 * 基于测试资产开展移交给BAU的工作，尤其要考虑BAU运维支持所需维护的回归测试包。
566
567 记录测试中的经验教训，包括做得好的和不好的。为了支持持续改进实践，重要的是要确保将汲取的教训纳入测试策略。详细说明哪些经验教训正在处理/未复现/未处理。默认情况下，那些未处理和/或重复的经验教训应转移到下一个经验教训环节。
568
569
570
571 == **​​​​​​​2.5** **关键指标** ==
572
573 ITIL实践的有效性和绩效，应该以每个实践所贡献的价值流的背景进行评估。与任何工具的性能一样，实践的绩效只能在应用的背景下评估。但是，工具在设计和质量上可能会有很大差异。在使用这些工具时，这些差异决定了工具的潜力或能力是否有效。有关度量标准，关键性能或绩效指标（KPI）的其他有助于此技术的进一步指导，请参见度量和报告实践指南。
574
575 服务验证和测试实践的关键指标已映射到其PSF。它们可以用作价值流背景中的KPI，以评估实践对这些价值流的效果和效率的贡献。表2.7罗列了一些关键指标的示例。
576
577
578 表2.7 实践成功因素的关键指标示例
579
580 |**实践成功因素**|**关键指标**
581 |定义并商议验证和测试组织的产品、服务及其组件的方法，符合组织的速度和服务变更的质量要求|(((
582 组织产品组合中遵守一致的服务验证和测试方法
583
584 利益相关者对所选的服务验证和测试方法表示满意
585
586 利益相关者对于组织提供相当质量的产品和服务的能力表示满意
587
588 客户对产品和服务的满意度符合要求
589 )))
590 |(((
591
592
593 确保新的组件、产品和服务及其变更，符合约定的准则
594 )))|(((
595 满足功用和功效要求的产品和服务的百分比
596
597 利益相关者对所选的服务验证以及测试模型和方法的满意度
598
599 利益相关者对组织具备的测试产品和服务的能力的满意度
600
601 因测试中忽略造成的服务事件和问题带来的损失
602 )))
603 |(((
604
605
606 实践的汇总指标
607 )))|服务验证和测试生产效率索引
608
609 对于正在进行中的价值流的管理，以及服务验证和测试实践的周期性评估和持续改进来说，将指标正确累加到复杂的指标集中，将使数据使用更加容易。没有唯一的最佳解决方案。
610
611 度量标准将基于整体的服务战略和组织的优先级，以及实践所贡献的价值流的目标。
612
613
614
615 ----
616
617
618 = **3. 价值流和流程** =
619
620
621 == **​​​​​​​3.1** **价值流的贡献** ==
622
623 像任何其他ITIL 管理实践一样，服务验证和测试实践也贡献多个价值流。重要的是要记住，价值流永远不会由单个实践形成。服务验证和测试实践与其他实践相结合，为消费者提供高质量服务。本实践贡献的主要价值流活动是：
624
625 * 设计和转换
626 * 获取或构建。
627
628 图3.1中显示了服务验证和测试实践对服务价值链的贡献。
629
630 (% style="text-align:center" %)
631 [[image:1639668366918-254.png]]
632
633 图3.1 服务验证和测试实践对价值链的贡献热图
634
635
636 == **​​​​​​​3.2** **流程** ==
637
638 每个实践可能包含一个或多个履行该实践目的所必需的流程和活动。
639
640 **​​​​​​​定义：流程**
641
642 一组相互关联或交互的活动，可将输入转换为输出。流程接受一个或多个定义的输入，并将其转换为定义的输出。流程定义活动的顺序及其依赖关系。
643
644
645 服务验证和测试的活动构成了三个流程：
646
647 * 测试方法和模型管理
648 * 服务验证
649 * 执行测试。
650
651 === 3.2.1 测试方法和模型管理 ===
652
653 该流程包括表3.1中列出的活动，并将输入转换为输出。
654
655 表3.1测试方法和模型管理的输入、活动和输出流程
656
657 |**关键输入**|**活动**|**关键输出**
658 |(% rowspan="3" %)(((
659 服务模型和设计
660
661 更新的发布管理方法和模型
662
663 发布计划
664
665 现有测试型号和发布模型
666
667 更新的发布管理方法和模型
668
669 发布计划
670 )))|(((
671 定义测试策略和评审
672
673
674 )))|(% rowspan="3" %)(((
675 测试策略和测试模型标准，包括测试成功准则
676
677 改进措施
678
679 知识管理文章更新
680 )))
681 |定义测试标准和评审
682 |定义测试模型和评审
683
684 图3.2显示了这个流程的流程图。
685
686 (% style="text-align:center" %)
687 [[image:1639668454199-663.png]]
688
689 图3.2测试方法和模型管理流程的工作流
690
691
692 表3.2描述了测试方法和模型管理流程中的活动。
693
694
695 表3.2 测试方法和模型管理流程中活动的描述示例
696
697 (% style="width:741px" %)
698 |(% style="width:149px" %)**活动**|(% style="width:590px" %)**描述**
699 |(% rowspan="2" style="width:149px" %)(((
700
701
702 定义测试策略和评审
703 )))|(% style="width:590px" %)(((
704
705
706 服务测试经理定义测试策略，描述服务提供者组织所采用的测试验证的方法。
707 )))
708 |(% style="width:590px" %)该策略确立了组织的基线风险偏好以及相关的测试投入和资源。应定期检查测试策略，以确保持续实现质量目标。
709 |(% style="width:149px" %)定义测试标准和评审|(% style="width:590px" %)(((
710 服务测试经理定义适用于不同产品和服务的各种测试类型的标准，以及记录测试输出的标准。应监控所有验证和测试活动，判断是否符合标准。
711
712
713 )))
714 |(% style="width:149px" %)定义测试型号和评审|(% style="width:590px" %)服务测试经理按需建立可重复的测试模型，以确保产品和服务更新采用一致的测试方法。或者可以针对一次性大型服务推出专门生成一个测试模型，作为整体项目规划活动之一。
715
716
717 === 3.2.2 服务验证 ===
718
719 该流程包括表3.3中列出的活动，并将输入转换为输出。
720
721
722 (% class="wikigeneratedid" id="H88683.3670D52A19A8C8BC16D417A0B76848F93516530016D3B52A8548C8F9351FA" %)
723 表3.3 服务验证流程的输入、活动和输出
724
725 |**关键输入**|**活动**|**关键输出**
726 |(((
727 服务设计封装
728
729 功用和功效需求
730
731 测试策略和标准
732
733 测试模型
734
735 发布计划
736 )))|(((
737 记录验收标准
738
739 验证验收标准
740 )))|(((
741 服务验收标准
742
743 服务测试范围和关注点
744
745 服务验收公告
746 )))
747
748 图3.3显示了流程的工作流图。
749
750 (% style="text-align:center" %)
751 [[image:1639668546990-435.png]]
752
753 图3.3 服务验证流程的工作流
754
755
756 (% class="wikigeneratedid" id="H88683.4670D52A19A8C8BC16D417A0B4E2D6D3B52A87684793A4F8B8BF4660E" %)
757 表3.4 服务验证流程中活动的示例说明
758
759 |**活动**|**描述**
760 |(((
761
762
763 记录验收标准
764 )))|(((
765
766
767 服务验证专家需要了解功用和功效，以服务设计实践和业务分析实践为参考，简历服务及其组件通过测恶事需要遵循的准则。此活动贯穿整个服务解决方案交付的设计阶段 。
768 )))
769 |确认验收标准|服务验证专家接受测试的结果，并向利益相关者保证，在特定的测试之后，已经满足了验收准则。此活动贯穿整个服务解决方案交付的转换阶段。
770
771 === 3.2.3 执行测试 ===
772
773 该流程包括表3.5中列出的活动，并将输入转换为输出。
774
775
776 (% class="wikigeneratedid" id="H88683.56D4B8BD576848F93516530016D3B52A8548C8F9351FA6D417A0B" %)
777 表3.5 测试的输入、活动和输出流程
778
779 |**关键输入**|(% style="width:471px" %)**活动**|(% colspan="2" style="width:422px" %)**关键输出**
780 |(% rowspan="3" %)(((
781 发布模型
782
783 测试模型
784
785 验收标准
786
787 测试策略和标准
788 )))|(% style="width:471px" %)测试规划和准备|(% colspan="2" rowspan="2" style="width:422px" %)(((
789 已配置的测试环境
790
791 测试和准出验证报告
792
793 经验总结
794 )))
795 |(% style="width:471px" %)(((
796 执行测试
797
798 评估测试准出标准和报告
799 )))
800 |(% colspan="2" %)测试完成|
801
802 图3.4显示了流程的工作流图。
803
804
805 (% style="text-align:center" %)
806 [[image:1639668707084-573.png]]
807
808
809 图3.4执行测试的工作流
810
811
812 (% class="wikigeneratedid" id="H88683.66D4B8BD56267884C4E2D76846D3B52A87684793A4F8B8BF4660E" %)
813 表3.6测试执行中的活动的示例说明
814
815 |**活动**|**描述**
816 |(((
817
818
819 测试规划和准备
820 )))|(((
821
822
823 服务测试经理会评估正在测试的服务或产品的验收标准，并使用总体测试策略、标准和适用模型来计划执行测试所需的环境，人员，硬件和其他组件。
824 )))
825 |(((
826
827
828 执行测试
829 )))|(((
830
831
832 服务测试专家使用手动或自动测试，观察并记录输出。
833 )))
834 |评估测试准出标准和报告|服务测试专家检查测试结果，并得出结论：是否满足测试成功标准（或测试准出标准）。
835 |(((
836
837
838 测试完成
839 )))|(((
840
841
842 服务测试经理评估测试报告，如果满足测试模型要求，则正式确认测试完成。
843 )))
844
845
846 ----
847
848
849 = **4. 组织和人员** =
850
851
852 == **​​​​​​​4.1** **角色、能力和责任** ==
853
854 实践指南不描述实践管理角色，如实践所有者、实践负责人或实践教练。相反，指南关注特定的每个实践的专门角色。每个角色的结构和命名可能因组织而异，因此不应强制，甚至不应推荐ITIL中定义的任何角色。
855
856 请记住，角色并非职位头衔。一个人可担任多个角色，一个角色也可以分配给多个人员。
857
858 对角色的描述以流程和活动为背景。每个角色都具有基于表4.1中所示模型的能力概括。
859
860
861 表4.1能力编码和能力概括
862
863 表4.2中列出了服务验证和测试实践涉及的角色示例，以及相应的能力概括和特定技能。
864
865
866 表4.2负责服务验证和测试活动的角色示例
867
868 |活动|负责角色|能力侧写|特定技能
869 |(% colspan="4" %)**测试方法和模型管理流程**
870 |定义测试策略和评审|服务测试经理|LMTA|(((
871 强大的设计思维
872
873 具备测试方法相关知识
874 )))
875 |定义测试标准和评审|服务测试经理|LMCA|(((
876 具备测试方法相关知识。
877
878 沟通技巧，以确保符合实现合规性标准
879 )))
880 |(((
881
882
883 定义测试模型和评审
884 )))|(((
885
886
887 服务测试经理
888 )))|(((
889
890
891 MTA
892 )))|具备测试方法相关知识
893 |(% colspan="4" %)**服务验证流程**
894 |(((
895
896
897 记录验收标准
898 )))|(((
899
900
901 服务验证专家
902 )))|(((
903
904
905 MTC
906 )))|(((
907 具备服务验证方法相关知识
908
909
910 了解业务需求要求
911 )))
912 |验证验收标准|服务验证专家|MTC|(((
913 具备服务验证方法相关知识
914
915
916 了解业务要求
917 )))
918 |(% colspan="4" %)**执行测试流程**
919 |(((
920
921
922 测试规划及准备
923 )))|(((
924
925
926 服务测试经理
927 )))|(((
928
929
930 MACT
931 )))|(((
932 强大的资源规划能力
933
934
935 有能力在具有优先级冲突下进行规划的能力
936 )))
937 |执行测试执行|(((
938 服务测试专家
939
940 服务的用户（用于UAT）
941 )))|MT|(((
942 注重注意细节
943
944
945 具备测试方法相关知识
946 )))
947 |(((
948
949
950 评估测试准出标准和报告
951 )))|(((
952
953
954 服务测试专家
955 )))|(((
956
957
958 MT
959 )))|(((
960 强大的记录保持技能
961
962
963 具备将所发现的清晰罗列的的能力
964 )))
965 |测试结束|服务测试经理|MTC|能够将测试结果与测试策略中注明的风险对齐。
966
967 == **4.2 组织架构和团队** ==
968
969
970 === 4.2.1 组织服务验证和测试 ===
971
972 大多数服务提供者都保留服务验证和测试实践，以确保其基于风险的质量保证方法是一致的。重要的是要考虑到测试（或经常是质量保证）是最容易适用于软件生命周期的术语。服务验证是一个更广阔的领域，除了软件、文档和数字化基础设施之外，还包括产品和服务组件。从历史上看，这意味着测试团队和验证团队是不同的：测试团队专注于应用程序测试，验证团队更接近服务设计师和架构师。两者都应在测试策略中概述的风险偏好内起作用。
973
974
975 === 4.2.2 服务验证专家 ===
976
977 服务的设计人员或架构师可以满足此角色的要求，以确保在测试期间满足业务中建立的验收标准或技术要求和约束，并且更新后的服务和产品也符合要求。
978
979
980 === 4.2.3 服务测试专家 ===
981
982 这是本实践中的核心角色，通常称为“测试人员”或“ QA工程师”。他们的职责包括：
983
984 * 执行测试计划和设计中定义的测试
985 * 记录和报告测试结果，包括不成功的测试引发的bug或事件记录
986 * 管理测试环境和相关资源。
987
988
989 ----
990
991 = **5. 信息和技术** =
992
993
994 == **​​​​​​​5.1** **信息交流** ==
995
996 服务验证和测试的有效性是基于所使用的信息的质量。这些信息包括但不限于：
997
998 * 测试策略
999 * 测试标准
1000 * 测试模型
1001 * 测试计划
1002 * 测试记录
1003 * 测试结果和报告。
1004
1005 这些信息可以采用各种形式。实践的关键输入和输出在第3节中列出。
1006
1007 服务验证和测试实践可以从自动化中大大受益。在可行且有效的地方，可涉及表5.1中列示的解决方案。
1008
1009 表5.1 服务验证和测试活动的自动化解决方案
1010
1011 |**流程活动**|**自动化手段**|**关键功能**|**对实践效果的影响**
1012 |(% colspan="4" %)测试方法和模型管理流程
1013 |定义测试策略和评审|(((
1014 资源规划工具
1015
1016 协作工具
1017
1018 分析和报告工具
1019 )))|沟通策略和策略的更新|中
1020 |(((
1021
1022
1023 定义测试标准和评审
1024 )))|(((
1025 资源规划工具
1026
1027 协作工具
1028
1029 知识管理工具
1030 )))|(((
1031
1032
1033 沟通标准和标准的更新
1034 )))|(((
1035
1036
1037 中
1038 )))
1039 |(((
1040
1041
1042 定义测试模型和评审
1043 )))|(((
1044 标注和工作流工具
1045
1046 知识管理工具
1047 )))|(((
1048
1049
1050 工作流程设计和跟踪
1051 )))|(((
1052
1053
1054 高
1055 )))
1056 |(% colspan="4" %)**服务验证流程**
1057 |(((
1058
1059
1060 记录验收标准
1061 )))|(((
1062 协作工具
1063
1064
1065 知识管理工具
1066 )))|(((
1067
1068
1069 保留验收标准的记录
1070 )))|(((
1071
1072
1073 中
1074 )))
1075 |验证验收标准|(((
1076 协作工具
1077
1078
1079 知识管理工具
1080 )))|保留验收标准的记录|中
1081 |(% colspan="4" %)**执行测试流程**
1082 |(((
1083
1084
1085 测试规划及准备
1086 )))|(((
1087 标注和工作流程工具
1088
1089 知识管理工具
1090 )))|(((
1091
1092
1093 任务规划
1094 )))|(((
1095
1096
1097 高
1098 )))
1099 |(((
1100
1101
1102 执行测试执行
1103 )))|(((
1104
1105
1106 自动化测试工具集和环境
1107 )))|(((
1108
1109
1110 测试和启用自动化
1111 )))|(((
1112
1113
1114 高
1115 )))
1116 |(((
1117
1118
1119 评估测试准出标准和报告
1120 )))|(((
1121 标注和工作流程工具
1122
1123 知识管理工具
1124 )))|(((
1125 处理工作流
1126
1127
1128 保留记录
1129 )))|(((
1130
1131
1132 高
1133 )))
1134 |(((
1135
1136
1137 测试结束
1138 )))|标注和工作流程工具|(((
1139
1140
1141 处理工作流
1142 )))|(((
1143
1144
1145 高
1146 )))
1147
1148
1149 ----
1150
1151 = **6. 合作伙伴和供应商** =
1152
1153 很少有服务仅使用组织的自有资源。即便不是全部，大多数服务都依赖于其他通常由组织之外的第三方提供的服务（请参阅ITIL Foundation：ITIL 4出版物的2.4节，可找到服务关系的模型）。服务设计、架构管理和供应商管理的ITIL实践中介绍了由支撑服务构成的关系和依赖。
1154
1155 通常，服务提供商寻求外部质量保证和测试职能以自然减轻测试的偏差。外部管理的服务提供者、团队和个人提供在软件领域以及特定的非功能测试领域中的测试能力、服务和产品。但是，针对特定服务客户部署的整体验证服务通常需要由服务提供者组织，来促进内部服务测试和验证实践，确保在服务引入过程中全面覆盖验收标准。
1156
1157 在由外部商业服务提供者管理服务交付价值流的情况下，客户组织可能会寻求另外的专业的服务部署能力，以确保满足其要求。也存在外部的独立的（这一点最重要）服务验证和测试供应商的保证服务。
1158
1159 在组织旨在确保快速有效的服务验证和测试的情况下，他们通常会试图与合作伙伴和供应商达成合作协议，消除不利于沟通、协作和决策方面的正式官僚的障碍（更多信息，请参见供应商管理实践指南）。
1160
1161
1162
1163
1164 ----
1165
1166 = **7. 重要提醒** =
1167
1168 实践指南的大部分内容应视为组织在建立和培育自身实践相关领域时可考虑的建议。实践指南是组织可以考虑的主题目录而非答案列表。在使用ITIL实践指南的内容时，各组织应始终遵循ITIL指导原则：
1169
1170 * 聚焦价值
1171 * 从你所处的地方开始
1172 * 基于反馈迭代推进
1173 * 协作和提升可视化程度
1174 * 通盘思考和工作
1175 * 保持简单实用
1176 * 优化和自动化。
1177
1178 关于指导原则及其应用的更多信息，请参见ITIL Foundation：ITIL 4 出版物的4.3节。
1179
1180
1181
1182
1183 ----
1184
1185 = **8. 致谢** =
1186
1187 AXELOS有限公司感谢所有为该指南的开发做出贡献的人。这些实践指南融合了ITIL社区前所未有的热情和反馈。AXELOS特别要感谢以下人员：
1188
1189
1190 == **​​​​​​​8.1** **作者** ==
1191
1192 Peter Bodman and Dan Ashby,
1193
1194
1195 == **​​​​​​​8.2 审稿人** ==
1196
1197 Roman Jouravlev and Dinara Adyrbai
1198
1199
深圳市艾拓先锋企业管理咨询有限公司