如何在不泄露真实客户信息的情况下生成测试数据
我曾在一个测试数据库中发现生产环境的信用卡号。绝不再犯。以下是我构建逼真的假数据而不让任何人面临风险的方法。
坦白说：在我职业生涯早期，我用我自己的信用卡测试了一个支付流程。真实的卡号。真实的有效期。真实的 CVV。我那时 22 岁，周五晚上一个人，心想"能出什么问题呢？"
我现在仍然会做噩梦，梦到那个 CSV 文件飘在某个地方。
如今我谨慎多了。实际上，是非常谨慎。被自己的愚蠢烧过一次就够了。
真实数据的问题
当你构建一个处理支付、管理账户或存储个人信息的应用时，你需要逼真的测试数据。假名字、假邮箱、看起来有效但实际上无效的假信用卡号。问题在于，大多数开发者会选择最简单的方案：把生产数据扔进测试环境然后完事。
数据泄露就是这么发生的。你就是这么以"未加密数据库暴露……"为标题登上 Hacker News 首页的。
我目前的方案
我配合使用两个工具，它们彻底改变了我的工作流。
首先，UUID generator。我系统中的每个测试用户都获得一个 UUID 而不是自增 ID。为什么？因为 UUID 不会泄露信息。它们不会告诉别人我有多少用户，或者哪个用户最先注册，或者任何那些顺序 ID 会无意中暴露的元数据。而且它们让我的测试数据库看起来很酷很先进。
其次——这才是真正的利器——我使用 test credit card generator（是的，我们有这个工具）。它会生成通过 Luhn 算法校验的数字（所以它们看起来足够真实，能通过验证逻辑），但它们来自已知的测试号段。Visa 测试号以 4 开头。MasterCard 以 5 开头。没有一个能真的扣款。我把 CI 流水线设置为每次测试运行都生成新的卡号。没有存储、没有风险、没有压力。
不仅仅是卡号和 ID
对于其余的测试数据，我采用类似的思路。从随机名字生成器获取假名。邮箱地址指向一个兜底的测试域名。地址来自 USPS 官方的虚构地址列表（是的，确实存在——邮政局对假想场景出乎意料地宽容）。
黄金法则：如果它可能是真实个人的数据，它就不应该出现在你的测试数据库里。这包括你 Linda 阿姨的电话号码、你前室友的邮箱，或者——天哪——你自己的信用卡。
你不需要偏执，只需要小心
我不是说你每次跑单元测试都需要安全审计。但花五分钟生成合适的测试数据——在这里用 UUID generator，在那里用 test card generator——就是安全的开发工作流与等待发生的灾难之间的区别。而且说实话，这更有趣。假数据意味着你可以给你的测试用户起"Crash Override"和"Acid Burn"这样的名字而不用担心被起诉。
相信我。你未来的自己——还有你的客户——会感谢你的。