SAP测试数据管理：脱敏的生产级数据

SAP测试数据管理，就是让每个测试系统都拥有表现得像生产数据的数据，同时不暴露真实人员的信息。我的原则很简单：数据要脱敏，但在数据量和真实度上都要达到生产水平。

单薄的手工数据会把要紧的缺陷藏起来。未脱敏的生产数据，则会把客户、供应商和员工的记录放进管控比生产系统更弱的系统里。

测试数据是更大的测试计划中的一部分。我的SAP测试详解指南讲了各种测试类型、由谁负责，以及它们在SAP Activate中处于什么位置。

一个测试只能发现它的数据能触发的问题。有五个未清项的客户，和有五万个未清项的客户，表现完全不同；一个没人在测试客户端里创建过的定价条件，在测试客户端里永远不会出错。

我见得最多的测试失败，是系统集成测试（SIT）和用户验收测试（UAT）做得不够。薄弱的测试数据，就是这种情况悄然发生的途径之一。测试用例跑完了，结果一片绿色，而那些本来会出错的用例，只是因为没有数据可以出错。

这就是我坚持要用生产级数据的原因。它意味着四件事：

1. 数据量。表的大小接近生产，让报表、作业和搜索针对真实的行数运行。
2. 多样性。生产中实际存在的那些特殊记录：被冻结的供应商、部分交货、贷项凭证、外币、陈年的未清项。
3. 历史。足够多的已关闭期间，让账龄分析、折旧和年终运行有意义。
4. 完整性。在复制和脱敏之后，凭证在各模块之间依然能正确关联。

数据量对性能最重要。性能测试必须在上线前完成，按我的经验，并发测试，也就是大量用户同时工作的测试，才是最重要的。

在一个近乎空的数据库上做并发测试，证明不了多少东西。我的SAP性能测试指南讲了如何搭建这些测试。

测试系统中的生产数据仍然是个人数据。测试系统和质量系统的访问范围通常比生产系统更宽，而这正是脱敏要堵住的风险。

欧盟《通用数据保护条例》（GDPR）是大多数组织参照的依据，许多国家的法律也遵循类似的思路。GDPR序言第26条做出了一个每个SAP团队都应该了解的区分。

1. 假名化数据仍然是个人数据。如果借助额外信息（例如一张映射表）可以把数据关联回某个人，该条例仍然适用。
2. 匿名数据不在其适用范围内。已经无法识别任何人的数据不受其约束。

实际结果是：大多数脱敏产生的是假名化数据，而不是匿名数据。一个脱敏后的测试系统仍然需要访问控制、明确的用途和保留规则。请您的数据保护官在第一次复制之前就商定脱敏规则，而不是等审计师问起之后。

常见的途径有五种。大多数项目会用到不止一种，因为每个测试阶段的需要都不一样。

下表从决定是否合适的几个方面对它们做了比较。

方法	您得到什么	数据量	隐私处理	最适合
完整系统复制	生产系统的精确副本，包括每个客户端和每张表	完整	复制之后、用户获得访问权限之前必须运行脱敏	性能测试、模拟转换、切换演练
客户端复制	在系统内或系统之间复制一个客户端；复制配置文件决定主数据和业务数据是否一起复制	完整，或仅定制	复制应用数据时，与系统复制相同	全新的测试或培训客户端，把客户端重置到已知状态
SAP Test Data Migration Server（TDMS）	按时间或组织单元选取的精简副本，带数据扰乱	精简	工具内的扰乱规则	已经拥有其许可的现有SAP Business Suite系统环境
合作伙伴的选择性复制工具	按需复制选定的业务对象或数据切片，在传输过程中脱敏	精简，有针对性	工具内的脱敏规则，在复制过程中执行	定期刷新、回归测试数据、缺陷复现
自建或迁移的数据	由脚本、迁移加载或手工录入创建的数据	取决于您建多少	从零构建则没有真实的个人数据	早期单元测试、上线前的绿地项目

完整系统复制和客户端复制

完整系统复制提供的是您能用来测试的最真实的数据。它也把生产系统中的每一项隐私风险都复制了过来。如果您使用这种方式，在脱敏运行完毕并经过检查之前，系统要一直锁定。

客户端复制是创建和重置客户端的日常工具。关键的决定在于复制配置文件，因为它决定了是只移动配置，还是把主数据和业务数据一起移动。

SAP Test Data Migration Server

SAP Test Data Migration Server（TDMS）用生产数据创建精简的非生产系统，并对敏感字段进行扰乱。它是在SAP Business Suite上成长起来的，SAP Help Portal上当前的文档适用于4.0 SP14版本。

我找不到SAP关于TDMS对当前S/4HANA版本的支持范围、或关于某个指定后继产品的官方说明。如果您打算依赖它，请以书面形式向SAP确认它是否支持您的目标版本和部署模式，包括RISE with SAP。

SAP Landscape Transformation与空壳复制

SAP Landscape Transformation是一组分析和转换工具，SAP在选择性数据迁移中使用它们。SAP Learning把空壳转换描述为：复制生产系统但不带主数据和业务数据，然后再转换为S/4HANA。

同样的思路也有助于测试数据。一个空壳给您生产系统的资源库和配置，不带任何业务数据，然后您只填入某个测试需要的数据。

有几款合作伙伴产品能把选定的业务数据复制到SAP测试系统中，并在复制过程中做脱敏。下面列出的是我能在厂商自己的网站上核实其说法的产品，排名不分先后。

1. EPI-USE Labs Data Sync Manager。一套在SAP ABAP系统环境中复制和脱敏数据的工具，包括精简客户端、对象级复制和带预定义规则的脱敏。EPI-USE Labs表示，Data Sync Manager已获得与SAP S/4HANA和S/4HANA Cloud集成的认证，并支持RISE with SAP。
2. SNP Kyano Test Data Organizer。只提取某个测试需要的数据，而不是整个系统，并在提供数据时对敏感数据进行脱敏。SNP称Test Data Organizer与RISE with SAP Private Cloud Edition兼容。
3. Qlik Gold Client。把选定的业务数据从生产系统复制并同步到非生产目标系统，对现有系统做静态脱敏，对传输中的数据做动态脱敏。
4. Natuvion DCS Protect。查找个人数据，并在测试、质量、开发和培训系统中进行匿名化或假名化处理。Natuvion把它定位于测试迁移和日常运营，该页面没有提到S/4HANA，所以请直接确认其支持范围。

购买之前，请每家厂商在您自己的系统上回答这些问题：

1. 它目前支持哪些S/4HANA版本和部署模式？
2. 它是在数据离开生产系统之前脱敏，还是在数据进入目标系统之后脱敏？
3. 脱敏在相互连接的系统之间是否保持一致，使S/4HANA中脱敏后的某个客户，与您的CRM或数据仓库中的同一客户相匹配？
4. 在生产数据量下，刷新一个公司代码需要多长时间？
5. 当您增加自定义表或字段时，由谁来维护脱敏规则？

每个测试阶段需要数据的原因都不一样。我在S/4HANA项目中规划测试数据时，就从这里开始。

测试阶段	数据必须做到什么	通常的来源
单元测试	让开发人员证明一个对象能正常工作	自建数据，或一小片脱敏数据
多轮系统集成测试	跨模块、跨接口运行完整的流程链	脱敏的生产级副本或选择性副本
多轮用户验收测试	看起来像业务用户自己的数据，让他们认得出自己的案例	脱敏的生产级数据，每一轮之前刷新
回归测试	保持稳定，让每次运行的结果可以比较	一套固定、可重置的数据集，外加刷新计划
性能测试	与生产数据量相匹配，让并发结果有意义	完整的脱敏副本，或生产规模的数据量
模拟转换和切换演练	用真实的数据形态证明迁移可行	生产系统的完整副本，核心团队以外的人有访问权限时需脱敏

UAT值得格外用心。用户验收测试应该归业务部门负责，在我看来它至少需要6到8周。

给用户他们认得出的数据：他们自己的客户、物料和价格表，即使名称经过了脱敏。我的SAP用户验收测试指南讲了如何执行。

模拟转换遵循同样的逻辑。在棕地转换项目中，我会安排三次模拟转换，每一次都应在生产系统的最新副本上运行。

按我的经验，数据迁移占项目工作量的30%到40%，所以要与迁移团队一起规划这些运行所需的数据访问。我关于SAP数据迁移为何失败的文章讲了各次模拟加载如何衔接。

两套环境，两份刷新计划

在项目期间，我会运行两套独立的环境：一套给项目，一套给日常运营（BAU）。这样线上支持变更和项目变更就分开测试。

每套环境都需要自己的测试数据计划。BAU测试需要接近当前生产的数据，因为支持修复针对的是当下的问题。

项目测试需要与新设计相匹配的数据，可能是一份转换后的副本，也可能是一次选择性加载。为两者各自保留一份刷新日程，让一边的刷新永远不会抹掉另一边仍然需要的测试数据。

测试约占项目工作量的35%。在这部分工作量之内规划测试数据，而不是在SIT开始前一周才去想。

我会按以下顺序来做：

1. 把原则写下来并达成一致。脱敏的生产级数据，由项目发起人、数据保护官和业务负责人签字确认。
2. 找出个人数据和敏感数据。客户、供应商、员工、银行信息、联系人、自由文本字段、附件，以及存放这些数据的所有自定义表。
3. 编写脱敏规则。逐个字段决定替换、保留还是删除，并在相互连接的系统之间保持替换一致。
4. 把数据对应到每个测试阶段。以上面的表格为起点，先为性能测试和并发测试确定数据量。
5. 选择复制方法和工具。数据量要紧的地方用完整复制，速度和频率要紧的地方用选择性复制，并核实工具对您的版本的支持情况。
6. 制定刷新日程。每套环境一份计划，刷新时间安排在每一轮SIT和UAT以及每次模拟转换之前。
7. 在脱敏通过检查之前锁定访问。在脱敏检查通过之前，核心技术团队以外的任何人都不能登录新复制的系统。

然后把它变成一个关口。每个周期的策略、准入标准和退出标准，都在我的S/4HANA测试策略指南里，而测试数据是否就绪，应该写进每一轮的准入标准。

具体的下一步：列出目前存有生产数据副本的每一个非生产系统，检查其中哪些做过脱敏。

如果您想就S/4HANA项目的测试数据方法或测试计划听取独立意见，您可以在这里联系我。

什么是SAP测试数据管理？

它是您如何规划、创建、复制、脱敏和刷新SAP测试系统中的数据。目标是让数据在数据量和真实度上表现得像生产数据，同时不把真实的个人数据暴露给不该看到的人。

SAP测试可以使用生产数据吗？

只有在脱敏之后才可以，而且即使脱敏了也要有访问控制。根据GDPR，假名化数据仍然是个人数据，所以脱敏后的副本仍然需要明确的用途、访问规则和保留规则。在第一次复制之前，与您的数据保护官商定脱敏规则。

SAP TDMS还能用于S/4HANA吗？

SAP Help Portal上当前的TDMS文档适用于4.0 SP14版本，而TDMS是在SAP Business Suite上成长起来的。我找不到SAP关于它对当前S/4HANA版本支持范围的官方说明。在围绕它做规划之前，请以书面形式向SAP确认。

哪些工具可以创建选择性的SAP测试数据？

SAP Test Data Migration Server，以及EPI-USE Labs Data Sync Manager、SNP Kyano Test Data Organizer和Qlik Gold Client等合作伙伴产品。Natuvion DCS Protect专注于对测试系统中的数据做匿名化和假名化处理。请对照您的S/4HANA版本和部署模式逐一核实。

SAP性能测试需要多少测试数据？

生产级的数据量。性能问题会在真实的表大小和大量并发用户下暴露出来，所以在单薄的数据集上做测试证明不了多少东西。性能测试和并发测试通常使用生产系统的完整脱敏副本。