4. 测试数据设计原则：数据覆盖度、数据独立性、数据可重复性、数据安全性

测试数据怎么设计？这个问题我入行头三年都没想明白。

那时候我总觉得，数据嘛，随便造几条能跑通用例就行。结果呢？线上出了个bug，测试环境死活复现不了。后来一查，是生产环境里有个边界值，我们的测试数据压根没覆盖到。

嗯，从那以后，我开始认真琢磨测试数据的设计原则。今天聊的这四个点——覆盖度、独立性、可重复性、安全性，是我这些年踩坑踩出来的经验。

4.1 数据覆盖度：别让漏测成为你的噩梦

数据覆盖度，说白了就是你的测试数据能代表多少真实场景。

我见过太多团队，测试数据就两套：一套正常数据，一套异常数据。正常数据永远是“张三，男，25岁，北京”，异常数据永远是“空字符串”。

你想想看，这能覆盖什么？

我个人习惯把覆盖度拆成三个维度：

1. 业务覆盖度：每个业务流程分支都要有对应的数据。比如订单状态，从“待支付”到“已取消”到“已退款”，每个状态都要有数据支撑。
2. 边界覆盖度：数值的上下限、字符串的最大长度、日期的临界点。我记得有一次，一个金额字段上限是999999.99，测试数据只用了1000和100000，结果上线后用户输入了999999.98，系统直接报错——因为数据库字段精度不够。
3. 组合覆盖度：多个条件组合在一起的情况。比如“男性+年龄大于60+有慢性病史”，这种组合数据你准备了吗？

4.2 数据独立性：别让测试用例互相“打架”

数据独立性，这个坑我踩得最深。

曾经有一次，我负责一个支付系统的测试。A用例创建了一笔订单，B用例去支付这笔订单。看起来没问题对吧？但问题是，A和B的执行顺序不固定。有时候B先跑，找不到订单，直接失败。有时候A和B同时跑，数据冲突，订单状态乱掉。

为什么会这样？因为数据不独立。

数据独立性的核心要求：

• 每个用例的数据互不干扰。用例A的数据，用例B不能依赖，也不能修改。
• 用例执行前后，数据状态可恢复。我建议每个用例都自己创建数据，用完自己清理。不要依赖其他用例留下的“遗产”。
• 并发执行时数据不冲突。如果用例要并发跑，数据一定要隔离。比如用不同的用户ID、不同的订单号。

4.3 数据可重复性：让bug可以“复现”

数据可重复性，就是同一个测试数据，每次跑都能得到同样的结果。

你想想看，如果测试数据里带了“当前时间”、“随机数”、“自增ID”，那每次跑出来的结果都不一样。bug到底是代码问题还是数据问题？你根本分不清。

我总结了几条可重复性的实践：

原则	说明	示例
固定数据源	测试数据不要从生产环境实时拉取，要用固定的数据集	用CSV文件或数据库快照，而不是实时查询
避免随机性	所有数据值都要明确指定，不要用随机函数生成	不要用RAND()，用固定的1001
时间戳固定	如果涉及时间，用固定日期而不是NOW()	用2024-01-01而不是CURRENT_DATE
数据版本化	每次修改测试数据，都要记录版本号	数据文件命名为test_data_v2.1.csv

4.4 数据安全性：别把“家底”都露出去

数据安全性，这个不用我多说吧？

我见过有人直接把生产数据库导出来当测试数据用。里面用户的手机号、身份证号、银行卡号，全都在测试环境里裸奔。这要是泄露了，公司得赔到破产。

数据安全性的几个底线：

• 脱敏处理：生产数据必须脱敏才能进测试环境。手机号中间四位用****代替，身份证号只保留前六位和后四位。
• 最小权限：测试环境的数据，只有测试人员能访问。开发人员如果需要，走审批流程。
• 数据隔离：测试环境和生产环境的数据要物理隔离。别把测试数据库和生产数据库放在同一个服务器上。
• 定期清理：测试数据用完就删，不要长期保留。尤其是涉及用户隐私的数据。

4.5 四个原则的关系：一张图说清楚

这四个原则不是孤立的，它们互相影响。我画了一张图，帮你理清它们的关系：

你看，这四个原则其实是一个整体。覆盖度不够，漏测风险高；独立性不好，用例互相干扰；可重复性差，bug没法定位；安全性不达标，公司可能吃官司。

我个人建议，每次设计测试数据时，都拿这四个原则过一遍。缺哪个补哪个，别偷懒。

---

公众号:蓝海资料掘金营，微信deep3321