关于GDPR，如何从测试的角度看数字化转型
在我的专业领域，我遇到了很多正在开始或正在进行数字化转型的客户，他们中的很多人都在试图解决围绕持续交付/部署的难题。在过去的5年里，围绕软件开发的讨论一直集中在速度和质量上。大多数人都说自动化是关键，我也是这么认为的——自动化让任务执行得更快、更可靠、更可重复。
不过，在众多自动化中，组织正在努力解决的问题之一是测试自动化，原因是测试数据。共享测试环境意味着共享和覆盖测试数据。一旦测试执行运行后，数据就会“脏”了，在没有“刷新”情况下，无法再用于后续的测试。
在不到一年的时间里，我们还需要关注监管部门对测试数据的新要求。关于GDPR的影响的文章有上百万篇，但我将坚持从测试的角度来阐述。（本文的举例截图有点老，不过不影响意思的表达。）
敏感与不敏感
姓名、地址、信用卡号、账号、电话号码、账户名等显然都是敏感数据，但真正的挑战是找到不敏感数据的局限性，让任何数据都变得敏感。例如，下面我将作者、账号和图片进行了匿名化处理，但由于“已知行为”，大部分人都能重新识别这条记录。
换句话说，已知行为和自由文本与不同的单独不敏感数据的组合会变得非常罕见，以至于它不再不敏感。即，如果一个典型数据集的深度太浅，不敏感的数据就会变得敏感。
你必须问自己这些问题：
- 什么数据是敏感的？
- 是行为、特定的内容，还是有一些不敏感的数据组合在一起就变成了敏感数据？
有时，即使是自由文本中的内容也可能是敏感的。
有两种独特的方式可以使敏感数据无法识别，即匿名化和假名化。两者都是基于加密算法（密钥）来掩盖数据，但如果是匿名化，你会把密钥扔掉，所以不可逆。
一旦所有这些数据管道都完成了，我们需要在所有数据库、文件和其他数据存储中进行同步，这些数据存储是由我们与内部或外部的应用程序管理的。在所有内部应用中做到这一点的挑战已经够难了，但第三方呢？在Twitter的例子中，让我们假设我正在测试一个新功能，在这个新功能中，对一条推文的评论也会显示为对一个连接的Facebook账户的评论。某种程度上，我们也需要同步我们的匿名测试数据，以实现该功能的测试。
SSS——合成、模拟和刺激
对于匿名化（或假名化）的数据，我们人类很难通过数据来识别测试用例，因此手动测试将更加困难。另一方面，对于持续交付计划来说，数据匿名化对你最有利。
为了使测试自动化工作，我们需要在执行测试用例期间访问的所有系统中获得适当的、同步的、未被触及的测试数据。
我们需要测试数据有3个主要目的：
- 为我们的测试脚本提供数据——手动或自动的
- 为我们的SUT提供数据——使测试用例的验证同步于（1）
- 将模拟/虚拟资产（存根/模拟）与同步测试数据一起送入我们无法控制的数据存储中
当我们想更进一步，从自动化测试中走出来，并希望能够连续地进行测试时，我们也需要反复地进行测试，最好是从自动化脚本中进行测试。
主动式与被动式
如果我们把目光投向过去的GDPR，我认为组织需要更多地关注接口和数据模型。它们通过“合同”或规范告诉我们有效和无效的结构和数据。我们需要使用这些合同和规范进行主动测试，而不是被动地针对数据进行测试。我们需要从bug预防的角度考虑，QA不是一个事件或一个特定的阶段，而是一个持续的过程。
