基础要点：

1.确保新的或变更的产品与服务能够满足既定的要求。

2.服务验证：建立部署和发布管理验收的标准，侧重于服务的功能与效果，圈定了测试的活动范围和重点。

3.测试策略：基于服务验收的标准，保证利益相关者的要求，确保针对内部开发的系统和外部解决方案的测试，符合风险偏好和测试目的。

4.功能性测试：单元测试、系统测试、集成测试、回归测试。

5.非功能性测试：性能与能力测试、安全测试、合规测试、运营测试、保障需求测试、用户验收测试。

解读：

新版ITIL 4 里的服务验证与测试实践，是由ITIL v3以及2011 版的“服务转换”发展而来，当然此处所讨论的内容会更加具体与深入。

总的说来，其基本次序是：服务验证在先，测试在后。通常情况下，我们需要服务提供方的业务负责人和技术负责人，来共同参与和协商服务验证的相关标准。也就是说，为了确保后续的测试活动能够及时、有效地开展，我们应当在服务验证环节明确如下关键要点：

1.概括性地描述产品、以及服务中的待测对象。

2.明确测试的目标、量化预期的效果。

3.根据需求文档和SLA，准备相应的测试用例。

4.定义即将采取的测试方法、工具、类型与步骤。

5.明确测试中需要涉及到的人员角色和工作量估算。

6.定义可能调用的软、硬件及环境资源，以及产生的费用与成本开销。

7.揭示测试可能带来的风险。

那么在完成开发或应用搭建之后，我们就需要通过测试来证明系统和服务是否符合前面所制定的验证标准，能否达到当初的设计初衷，以及用户的需求。这同时也是服务提供方能够顺利交付产品的前提。

可见，测试主要应当关注已完成产品和服务的如下三个方面：

是否满足那些指导其设计和开发的业务和技术需求；是否能够按需运行，并提供稳定的服务；既定的服务功能与效果是否能够重复实现与交付。

在测试方法上，服务提供方既可以采取传统的手动测试，也可以运用时下流行的自动化测试方法。两者之间的不同在于：

手动测试是测试人员需要针对目标，手动执行每一个测试用例，人工提供不同的结果集，并仔细记录每一个环节的成败率。当然，有时也需要人工进行测试结果的判断，因此，手动测试不但费时费力，而且难免会产生人为的疏忽。

自动化测试是测试人员凭借一些能够自动化运行的工具，开展诸如回归、或频繁密集的测试（例如：模拟不同的操作系统及不同的浏览器，反复登录某个页面，或是输入各种数据），以实现更高的效率、更少的人力，以及更低的出错几率。

正如前面基础要点中所提到的，我们首先需要开展的是功能性测试。此类测试一般会涉及到如下四个层次：

1.单元测试：着眼于开发出的系统与服务是否符合详细设计中的要求。通过划分出最小的测试单元，我们应尽快地找出各个模块或组件中的明显错误，以提高单个服务功能项的质量，并减少后期返工的成本。

2.集成测试：检查各个服务组件能否协同工作，测试整个系统能否通过成功构建达到预期的效果。我们应当在此环节发现系统架构与模块之间、模块与模块之间是否存在接口问题，并记录下测试的结果。

3.系统测试：关注的是作为产品的系统是否符合前期规格说明的要求。我们可以通过运行整个系统，来根据在验证环节中制定的测试用例，执行全面测试，验证并确证系统的功能与性能，是否符合需求规格说明中的要求。

4.回归测试：在整改了在上述三种测试中所发现的问题之后，我们需要重新进行测试，以确认没有给系统或服务引入新的错误或缺陷。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。有时候为了保证最终用户的满意度，我们甚至需要邀请用户参与进来，共同检测系统或服务的平稳度和易用性。

在完成并通过了上述功能性测试的相关步骤之后，我们就可以采取非功能性测试了。可以说，此类测试更注重的是发现系统或服务在某种环境或临界状态下的反应状态及鲁棒性。也就是说，我们在实际测试中，需要模拟在非常规或非标准化的内、外部场景中，使用待测系统与服务，并收集相关的特征参数。

我们经常会在非功能性测试中引入极限测试。该测试的好处不言而喻。不过值得注意的是，如果我们过于苛求测试的全面性和真实性的话，则会在无形中给增加测试前期的准备，以及开发的整体成本。因此，我们应当注意上述基础要点中提到的要“符合风险偏好”。

显然，测试的输出就是要发现被测服务与实际需求之间的差距，以及自身存在的错误与缺陷。为了有针对性地进行及时整改，我们可通过如下三步来实现缺陷管理：

定位与分析缺陷，进而填写并提交缺陷报告；完成整改后发起变更需求，并在获批后予以实施和修复；再次验证与测试整改的有效性，并留下最终记录。

当然，对于经过测试和后期整改仍无法解决的问题，我们应当及时将其纳入前文提到的已知错误知识库中，以便尽早告知用户。

最后，需要注意的是，对于那些持续发展或经历过变更的系统与服务，我们需要定期进行跟进验证与测试，以向用户证明其能够维持原有服务级别水平。

实务：

企业通常会在新的系统和服务尚未完工之前，就事先确定好了有哪些标准需要满足，有哪些功能需要实现，以及有哪些影响用户使用体验的重点。在此基础上罗列出系统和服务的各种特征，并圈定测试的范围与深度。

当然，这些都属于服务验证的基本准备工作。

如果说服务验证主要关注和设定的是最低要求的话，那么我们在服务测试环节则会更加全面。为了提高产品的质量，确保服务的有效性，以及系统的稳定性，我们设计出了如下测试用例的基本类型：

功能性测试用例；

错误输入测试用例；

图1 通用处置流程

逻辑与流程测试用例；

物理与运行环境测试用例；

用户接口与界面测试用例。

值得一提的是，针对测试中出现的错误、问题和缺陷，我们采取了如图1 所示的通用处置流程。

图中的每一个节点所对应的解释如下：

1.新建：这是缺陷被首次提交时初始状态。不过，对于一些复杂的问题或缺陷则可能需要测试人员予以进一步的确认。

2.审核：由主管人员审核该缺陷的真实性，并判断是否属于重复提交。一旦确认，他们则会分配给相应的研发人员或团队接手处理，否则直接“关闭”或进入下面的“整改”环节。

3.分析：研发人员受理该缺陷，通过深入分析，以便制定整改方案。如果该缺陷的优先级不高，或是交付时间较为宽松，则会被设置为“延期”，直至下一个版本才予以修复。

4.整改：研发人员通过变更管理流程对缺陷实施修复与整改，并在完成后流转给测试人员。

5.测试：测试人员针对原有缺陷展开新一轮的测试。如果通过，该缺陷的状态变更为“已修正并关闭”；如果未能通过，则重返“分析”环节；如果循环多次仍无法修复，其状态应被设置为“已知错误”。

当然，在整改与测试完成之后，我们应当及时且彻底地清理系统中残留的测试数据、各类警告信息，以及历史日志等，以便系统或产品能够顺利地流转到正式部署或交付环节。