在研发流程管理中，测试环节，不管是白盒测试还是黑盒测试，都是确保研发交付质量的关键。在过往的工作经验之中，测试数据构造一直是影响开发人员自测和测试人员测试质量的一个重要因素，开发人员疲于为测试或者产品体验构造特定场景所需的测试数据，而测试人员往往总因为测试数据不符合用例前置条件的要求，被迫等待开发人员构造数据，最终导致大量的沟通成本和时间成本。
为什么测试数据构造会如此麻烦？我认为主要还是业务本身的流程过长带来的问题，比如看一个典型的供应链商品采购仓储环节的流程：
在一个黑盒测试的场景下，假如测试人员需要针对“入库预约”环节进行测试，为了避免脏数据导致业务流程中断，最好的方式是从流程起点重新构造整套测试数据，然而在人手操作的情况下，这显然是难以完成的。
我调研了国内外关于测试数据构造相关的一些讨论，发现了测试数据管理，英文 Test Data Management，为了逼格，可以简称“TDM”，这个术语的存在。关于测试数据管理，大家都在说它的成本有多高，但是至今却也没有找到相对通用的解决方案，更别说成熟的解决方案了。
按照测试数据管理的切入点以及执行的方式，我觉得可以归纳总结出以下几种形式：
| 切入点 | 执行方式 | 优点 | 缺点 |
|---|---|---|---|
| 数据库 | 从数据库中查找符合测试条件的已有数据 | 理想情况下直接利用现有数据，无需重复构造，成本最低 | 成功率低测试环境数据一般都会有脏数据，找到的数据可能测试到一半才发现不满足要求，需要重新查找测试数据，或者改用其他方式 |
| 数据库 | 从生产环境数据库复制符合测试条件的真实数据 | 除非是新的业务数据模型，一般相对测试环境更容易找到所需数据，且数据完整度高 | 引入隐私安全风险，带来更多的管理成本操作不慎，可能干扰正常业务（比如在测试环境给真实用户推送了测试信息） |
| 数据库 | 直接向数据库插入符合测试条件的新数据 | 自由度最高数据完整度可控，能够获得隔离性最高的测试数据集 | 维护成本高，耦合技术方案存储层设计管理成本高，需要一种高效组织和检索的方式以避免重复和凌乱的测试数据集 |
| 业务接口 | 模拟用户角度，按照业务流程发起一系列接口调用，最终获得符合测试条件的业务状态 | 成本中等，在接口正常符合和逻辑正确的前提下，方便获得符合测试条件的数据 | 有维护开发成本，需要跟着接口设计调整，改动相对高频可能需要适配不同的接口协议和复杂接口认证流程等 |
未完待续……
未完待续……
这么好的文章，路过的人不测试一下吗？
支持
支持表格了～