GDPR——现代化的一课

如果我们回顾GDPR，我相信组织需要更多地研究接口和数据模型。他们通过“合同”或规范告诉我们有效和无效的结构和数据。我们需要使用这些合同和规范进行主动测试，而不是根据数据进行被动测试。我们需要从错误预防的角度考虑，其中质量检查不是事件或特定阶段，而是持续的过程。

在我的职业中，我遇到了许多正在或正在进行数字化转型的客户，其中许多人正在努力解决有关持续交付/部署的难题。在过去的五年中，围绕软件开发的讨论一直集中在速度和质量上。大多数人都说自动化是关键，我也是如此——自动化使任务更快、更可靠、更可重复地执行。

但是，组织正在苦苦挣扎的众多自动化之一是测试自动化，其原因是测试数据。共享测试环境意味着共享和覆盖测试数据。运行测试执行后，数据将变得“脏”，并且如果没有“刷新”，则无法再用于后续测试。

在不到一年的时间内，我们还需要查看有关测试数据的新法规要求。关于GDPR含义的文章数以百万计，但从测试的角度来看，我将坚持要求的内容。

敏感与不敏感

换句话说，已知行为和自由文本与不同的个体不敏感数据的组合变得非常罕见，以至于不再敏感。即，如果典型数据集的深度太浅，则不敏感的数据可能会变得敏感。

您必须问自己以下问题：

• 哪些数据敏感/li>
• 是否有行为，特定的内容，或者有一些不敏感的数据在组合时变得敏感/li>

有时，即使是自由文本中的内容也可能是敏感的。

有两种使敏感数据无法识别的独特方法：匿名化和化名。两者都基于加密算法（密钥）来掩盖数据，但是通过匿名化，您会丢弃密钥，因此它是不可逆的。

完成所有这些数据探测后，我们需要在所有数据库，文件和其他数据存储之间进行同步，这些数据库，文件和其他数据存储由我们正在与之交互的应用程序内部或外部管理。在所有内部应用程序中做到这一点的挑战已经足够困难，但是第三方呢Twitter示例中，假设我正在测试一项新功能，其中一条推文的评论也将显示为对关联的Facebook帐户的评论。某种程度上，我们也需要同步匿名测试数据以完成对该功能的测试。

SSS –合成，模拟和刺激 

对于匿名（或化名）数据，我们人类很难通过数据识别测试用例，因此手动测试将更加困难。另一方面，对于“持续交付”计划，数据匿名化是您最大的利益。

为了使测试自动化发挥作用，我们需要在执行测试用例期间访问的所有系统中正确，同步且未更改的测试数据。

我们需要3个主要目的的测试数据：

1. 馈送我们的测试脚本–手动或自动
2. 馈送我们的SUT –使测试用例的验证与（1）同步
3. 在我们无法控制的数据存储中为同步的测试数据提供模拟/虚拟资产（存根/模拟）

如果我们想更进一步，从自动化测试中走出来，并且希望能够连续进行，那么我们还需要反复进行此操作，最好是从自动化脚本中进行。

主动与被动

如果我们回顾GDPR，我相信组织需要更多地研究接口和数据模型。他们通过“合同”或规范告诉我们有效和无效的结构和数据。我们需要使用这些合同和规范进行主动测试，而不是根据数据进行被动测试。我们需要从错误预防的角度考虑，其中质量检查不是事件或特定阶段，而是持续的过程。