|
ITIL4 服务验证和测试实践【中文】2.1 目的和描述关键信息 服务验证和测试实践的目的是确保新产品和服务或对其的变更符合定义的要求。服务价值的定义基于客户、业务目标和法规要求的输入，并作为设计和转换价值链活动的一部分。这些输入将用于设立可度量的质量和性能指标，而这些指标又将作为支持验收标准和测试要求的定义。 服务验证和测试实践涉及减少因新的或更改的产品和服务引入到生产环境的风险和不确定性。在此实践中通过计划并执行适当的测试来操作。 系统越大越复杂，则需要进行的测试越多。但是，由于时间和成本的限制，即使是较小的或简单的系统也无法进行穷尽的测试。因此，选择测试的内容很重要。验证和测试的范围和级别定义的关键注意事项包括：
在可能的背景和偏差影响中理解（测试）需求，有助于对测试的重要领域有一个明智的了解。 该实践关乎对正在测试的服务的质量的信心。这不是说它是完美的。通过测试可以赢得信心，以证明服务将按要求运行，符合要求并且没有重大缺陷。 2.1.1 服务验证服务验证在产品和服务生命周期的早期阶段（概念和设计）执行。它着重于确认议定的服务设计满足议定的服务要求，并为下一阶段（开发，部署和发布 ITIL认证）建立验收标准。这些验收标准将通过测试产品和服务组件、产品和服务得以验证。 验证服务要求应遵循的结构，通常涵盖功用、功效、体验、可管理性和合规性。也可能包括其他要求。 服务验证确保服务验收标准得以定义、验证并记录，并告知测试活动的范围和重点。 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 定义并议定验证及测试组织的产品、服务和组件的方法，符合组织对服务变更的速度和质量要求服务验证应该建立一种方法来捕获关于产品、服务和组件的所有功用和功效需求。此方法应涉及不同的利益相关者及其信息源，例如客户和用户需求和反馈、业务需求、内部和外部合规及法规要求、风险和安全、以及其他需求来源。同时，还应提出将需求转换为服务验收标准的方法。 测试策略将定义为达成项目目标应如何执行测试。测试计划应以测试策略为基础。测试策略还定义了测试管理方法，包括如何组织和控制测试。 测试策略定义了范围内的测试阶段（或级别）和类型。其中，测试阶段包括： 单元测试：由开发人员执行，验证他们开发的内容是否符合需求，（测试）单元通常是被测试隔离的完整系统的组件。
测试策略还必须考虑在每个测试阶段适合哪种测试类型。测试类型包括：
测试计划将定义每个测试阶段的详细活动、预估工作量和时间表。因此，测试策略定义整体范围和方法，而测试计划则详细说明每个测试阶段。表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：
测试审查了项目计划表、需求和功能设计文档副本后，预计需要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阶段关键的测试资源会保留，直到系统在生产环境稳定运行。 这将涉及：
记录测试中的经验教训，包括做得好的和不好的。为了支持持续改进实践，重要的是要确保将汲取的教训纳入测试策略。详细说明哪些经验教训正在处理/未复现/未处理。默认情况下，那些未处理和/或重复的经验教训应转移到下一个经验教训环节。 2.5 关键指标ITIL实践的有效性和绩效，应该以每个实践所贡献的价值流的背景进行评估。与任何工具的性能一样，实践的绩效只能在应用的背景下评估。但是，工具在设计和质量上可能会有很大差异。在使用这些工具时，这些差异决定了工具的潜力或能力是否有效。有关度量标准，关键性能或绩效指标（KPI）的其他有助于此技术的进一步指导，请参见度量和报告实践指南。 服务验证和测试实践的关键指标已映射到其PSF。它们可以用作价值流背景中的KPI，以评估实践对这些价值流的效果和效率的贡献。表2.7罗列了一些关键指标的示例。 表2.7 实践成功因素的关键指标示例
对于正在进行中的价值流的管理，以及服务验证和测试实践的周期性评估和持续改进来说，将指标正确累加到复杂的指标集中，将使数据使用更加容易。没有唯一的最佳解决方案。 度量标准将基于整体的服务战略和组织的优先级，以及实践所贡献的价值流的目标。 ...... |
