S/4HANA测试策略：测试周期、准入退出标准与角色

一份S/4HANA测试策略要决定您运行哪些测试周期、按什么顺序、每个周期由谁负责，以及凭什么证据才能从一个周期进入下一个。在我的项目中，它涵盖分轮进行的系统集成测试（SIT）、分轮进行的用户验收测试（UAT）和回归测试，每个周期都有书面的准入和退出标准，以及指定的签字人。

在我规划的S/4HANA项目中，测试约占项目工作量的35%，所以测试策略值得像构建计划一样用心。

各种测试类型本身，在我的SAP测试详解指南中已经讲过。本文讲的是策略层面：测试周期、标准、角色和文件提纲。

SAP Activate把大部分测试放在Realize阶段。SAP自己的S/4HANA Cloud Private Edition测试策略资料把单元测试和串测视为非正式测试。完整业务流程测试、集成测试、数据迁移测试和用户验收测试是正式测试，必须形成文档。

这是我在S/4HANA项目中规划的顺序：

S/4HANA测试周期

1. 01

   单元测试和串测

   顾问在构建过程中测试每个配置好的功能和短链条。

2. 02

   多轮SIT

   跨模块、跨接口、带迁移数据的完整流程链。

3. 03

   多轮UAT

   业务用户逐轮证明系统能运行他们的流程。

4. 04

   回归测试

   在修复、传输和发布之后，重新测试已经通过的内容。

5. 05

   模拟转换和演练

   按上线当晚的方式运行切换，对照检查清单。

6. 06

   上线

   只有在商定的切换检查清单全部完成后才上线。

单元测试和串测

顾问和开发人员在构建每个配置项和每项开发时对其进行测试。串测把几个步骤串在一起，例如从销售订单一直走到交货。

按SAP的说法这是非正式测试，但并非可有可无。

分轮进行的系统集成测试

SIT测试跨模块、跨接口、带有转换或加载数据的完整业务流程。我把它分成多轮来规划，而不是当作一次性事件，这样一轮之后修复的缺陷会在下一轮重新测试。

SIT轮数我没有固定的数字。轮数取决于范围内的流程、接口和实体数量，测试策略应写明要跑几轮以及为什么。

分轮进行的用户验收测试

UAT是业务部门用自己的人和接近真实的数据，确认系统能运行其流程的环节。和SIT一样，我把它分成多轮来规划，这样一轮的修复会在下一轮重新测试。

UAT至少需要6到8周。业务测试人员是在本职工作之外做这件事，他们需要时间跑不止一轮。我的SAP用户验收测试指南详细讲了测试脚本、测试轮次和签字确认。

回归测试

每一次修复、传输和发布，都可能弄坏已经通过的东西。回归测试在每次变更之后，重新运行要紧的流程，项目期间如此，上线之后也如此。

SAP的资料把回归测试主要放在Run阶段，即版本升级之后，但项目在更早的时候就需要它。具体做法、影响分析和环境设置，请看我的SAP回归测试指南。

模拟转换和切换演练

在棕地转换项目中，我会在切换前安排三次模拟转换。每一次测试的都是转换本身、耗时和对账，而不只是流程。

最后一次演练应该像真正的上线当晚那样运行：同样的顺序、同样的人、同样的检查清单。我的S/4HANA迁移时间表和项目计划说明了这些运行在计划中处于什么位置。

最重要的一项负责人决定是：用户验收测试归业务部门负责。不是系统集成商，也不是IT部门。

集成商可以准备脚本、修复缺陷。只有负责您的财务结账、订单到收款或工厂运营的人，才能确认这些流程能正常运行。

SAP自己的指导也是同一个方向。合作伙伴的配置专家编写测试用例，客户的业务线专家执行UAT并记录结果。

这是我会如何在各个周期之间划分负责人：

周期	负责人	执行者	签字确认
单元测试和串测	构建团队负责人	顾问和开发人员	功能负责人和技术负责人
多轮SIT	测试经理	顾问，关键用户在后几轮加入	测试经理和流程负责人
多轮UAT	业务部门，通过指定的流程负责人	关键用户和业务测试人员	流程负责人，然后是项目发起人
回归测试	测试经理	测试团队，业务量足够时做自动化	测试经理和变更委员会
模拟转换和演练	切换负责人	技术、数据和功能团队	切换负责人、数据负责人和项目发起人

在测试策略中写上名字，而不是角色。“财务流程负责人”是一个角色；一位已经同意签字的具体人员才是负责人。

准入标准防止一个周期在还不可能成功时就开始。退出标准防止它仅仅因为日历到了就结束。

在Realize阶段开始之前、还没有人承受截止日期压力的时候，把这两者都写好。我的SAP质量关口指南讲了这些标准如何变成正式的关口，并由一位能说“还没准备好”的负责人把关。

下表是供您调整的参考，而不是照抄的标准。与您的项目发起人一起设定百分比和缺陷上限，并把它们记录在测试策略中：

周期	准入标准	退出标准
单元测试和串测	设计已签字确认；待测项目的配置和开发已完成	所有项目已测试并记录；缺陷已修复，或已登记到SIT
一轮SIT	范围内流程的单元测试已完成；测试环境已搭建，接口已连通；测试数据已加载；脚本已评审	商定比例的脚本已执行并通过；没有未关闭的严重缺陷；每个未关闭的较低级别缺陷都有负责人和修复日期
一轮UAT	已满足SIT退出标准；业务测试人员已指定并从日常工作中抽出；脚本已由流程负责人评审；测试系统培训已完成	每个范围内的流程都已由业务用户执行；没有未关闭的严重缺陷；流程负责人已为各自的流程签字
回归测试	一项变更、一批修复或一个版本已准备好移动；已商定受影响流程的回归测试包	回归测试包已通过；任何失败都已修复并重新测试，然后变更才能继续移动
模拟转换或演练	已有生产系统副本；切换检查清单和运行手册已起草；对账规则已商定	转换或加载在计划的时间窗口内完成；对账已由数据负责人签字；检查清单已根据经验教训更新
上线	之前所有退出标准均已满足；切换检查清单已事先商定	检查清单的每一项都已完成并签字；上线/不上线决定已由项目发起人记录在案

让这张表起作用的有两条规则。每一项标准都给出“是”或“否”的答案，每一个退出环节都有指定的签字人。

如果一个周期没有达到退出标准，而业务部门仍想继续推进，就把它变成一项书面决定。写明是谁接受了风险，以及有哪些缺陷被带到了下一阶段。

测试经理在Prepare阶段或Explore阶段早期编写它，由项目发起人批准。篇幅要短到流程负责人愿意读完。

这些是我期望看到的部分：

1. 范围和目标。测试哪些流程、实体、接口和报表，哪些明确排除在外。
2. 测试类型和周期。单元测试、串测、多轮SIT、多轮UAT、回归测试、性能测试、数据迁移测试和模拟转换，写明轮数和理由。
3. 进度和工作量。每个周期在SAP Activate计划中的日期，UAT至少有6到8周，并按测试约占35%的比例编制工作量预算。
4. 角色和负责人。上面那张负责人表，写上名字。
5. 准入和退出标准。每个周期一套，每套都有签字人。
6. 环境。哪个周期用哪些系统，如何刷新，以及项目变更如何与线上支持变更分开。
7. 测试数据。数据从哪里来，如何脱敏，各轮之间如何刷新。我的SAP测试数据管理指南对此有深入讲解。
8. 缺陷管理。严重程度定义、分诊节奏、谁决定优先级，以及每个严重程度的目标修复时间。
9. 工具。测试用例、结果、缺陷和签字确认存放在哪里，只用一个记录系统。
10. 自动化方法。哪些测试做自动化，哪些保持手工，以及原因。
11. 报告。每周测试报告显示什么，发给谁。
12. 切换和上线标准。切换检查清单、证明它可行的演练，以及由谁做上线/不上线的决定。
13. 风险和假设。测试人员能否到位、环境日期、数据准备情况，以及对第三方的依赖。

工具方面，SAP Cloud ALM是新项目的默认选择。SAP表示SAP Cloud ALM没有单独的许可：它包含在Enterprise Support之中，它的测试管理应用承载正式的测试用例、测试运行和结果。

SAP Solution Manager 7.2仍在许多项目中使用，但它的主流维护于2027年底结束。在自动化方面，SAP销售SAP Test Automation by Tricentis，它与Cloud ALM配合使用；我的SAP测试工具比较讲了更广泛的选择。

我见得最多的测试失败，是UAT和SIT测试做得不够。

一个常见的机制是：构建延误，上线日期不变，于是时间从测试周期里挤出来，因为它们排在计划的最后。

以下是导致这种情况的模式，以及对每一种该怎么做：

1. 单元测试还没完成，SIT就开始了。第一轮SIT变成了一轮单元测试。守住准入标准。
2. UAT只规划了两三周。业务用户在这么短的时间里，无法一边做本职工作一边好好测试。规划至少6到8周，并让测试人员脱产参与。
3. 由集成商替业务部门执行UAT。脚本都通过了，业务部门却在上线后才发现缺口。让UAT的负责权留在流程负责人手里。
4. 测试只作为一个小的预算项。测试约占35%的工作量，如果只按其中一小部分来编预算，它会第一个被砍。
5. 退出标准在周期进行中才写。结果标准总会和团队已经做到的东西一致。在Realize阶段之前写好它们。
6. 上线凭信心决定，而不是凭检查清单。没有人能拿出当初商定了什么，所以也没有人能说清还缺什么。

最后这一点是我坚持的。我的上线标准，是一份与业务部门、IT部门和集成商事先商定的详尽切换检查清单。

它涵盖技术步骤、数据加载、对账、业务验证、接口切换、用户访问，以及上线/不上线的决策点。只要有一项没有完成并签字，项目就没有准备好，无论日期怎么说。

在Realize阶段开始之前，向您的测试经理要来测试策略文件，对照上面的提纲检查一遍。如果文件里没有指定的UAT负责人，给UAT的时间少于6到8周，或者没有每个周期的准入和退出标准，先把这些问题解决。

如果您想就测试策略或上线检查清单获得独立评审，我可以为您的组织提供这方面的帮助。您可以在这里联系我。

什么是S/4HANA测试策略？

它是一份计划，决定运行哪些测试周期、按什么顺序、每个周期由谁负责并签字确认，以及凭什么证据项目才能从一个周期进入下一个。在S/4HANA项目中，它通常涵盖单元测试和串测、多轮SIT、多轮UAT、回归测试、数据迁移测试和切换演练。

测试占S/4HANA项目的多大比例？

在我规划的项目中，测试约占项目工作量的35%。从一开始就按这个水平编制预算，因为构建一延误，资金不足的测试就会第一个被砍。

S/4HANA项目的UAT应该持续多长时间？

至少6到8周。业务测试人员是在本职工作之外执行UAT，他们需要时间跑不止一轮，以便第一轮的修复能重新测试。

SAP用户验收测试应该由谁负责？

由业务部门负责，通过指定的流程负责人来落实。系统集成商可以准备脚本、管理环境、修复缺陷，但只有运行这些流程的人，才能确认系统对他们是可用的。

SAP测试中的准入和退出标准是什么？

准入标准是一个周期开始前需要满足的条件，例如单元测试已完成、环境已搭建、测试数据已加载。退出标准是一个周期结束前必须满足的条件，例如脚本已执行、没有未关闭的严重缺陷、流程负责人已签字确认。每一项都应该给出“是”或“否”的答案，并有指定的签字人。

S/4HANA上线检查清单应该包含什么？

技术切换步骤、数据加载和对账、业务验证、接口切换、用户访问，以及上线/不上线的决策点。事先商定它，在模拟转换或彩排中演练它，只有在每一项都完成并签字后才上线。