背景
在研发流程管理中，测试环节，不管是白盒测试还是黑盒测试，都是确保研发交付质量的关键。在过往的工作经验之中，测试数据构造一直是影响开发人员自测和测试人员测试质量的一个重要因素，开发人员疲于为测试或者产品体验构造特定场景所需的测试数据，而测试人员往往总因为测试数据不符合用例前置条件的要求，被迫等待开发人员构造数据，最终导致大量的沟通成本和时间成本。
为什么测试数据构造会如此麻烦？我认为主要还是业务本身的流程过长带来的问题，比如看一个典型的供应链商品采购仓储环节的流程：
在一个黑盒测试的场景下，假如测试人员需要针对“入库预约”环节进行测试，为了避免脏数据导致业务流程中断，最好的方式是从流程起点重新构造整套测试数据，然而在人手操作的情况下，这显然是难以完成的。
测试数据管理
我调研了国内外关于测试数据构造相关的一些讨论，发现了测试数据管理，英文 Test Data Management，为了逼格，可以简称“TDM”，这个术语的存在。关于测试数据管理，大家都在说它的成本有多高，但是至今却也没有找到相对通用的解决方案，更别说成熟的解决方案了。
测试数据管理的方案思考
按照测试数据管理的切入点以及执行的方式，我觉得可以归纳总结出以下几种形式：
- 复制生产环境数据：这种方式产生的数据，一般都满足严格的业务测试需求，数据的质量比较高，但是引入隐私安全和监管风险，且数据量比较大，存储成本高；
- 复制部分生产环境数据：这种方式降低存储成本，但是提高了维护成本，特别是关系型数据库，在所谓“部分”数据的前提下，需要针对不同库表指定不同的数据过滤方案；
- 复制生产数据，进行数据混淆处理：这种方式可以起到一定的隐私安全防护，但是类似复制生产环境数据的方案，需要针对不同库表指定不同的数据混淆规则，同时需要注意关系数据库的主键外键关系等；
- 执行接口调用，生成业务数据：这种方式在接口正常符合和逻辑正确的前提下，方便获得符合测试条件的数据。但是有维护开发成本，需要跟着接口设计调整，改动相对高频。另外特定场景，比如支付，需提供后门接口，以便测试脚本绕过支付等涉及第三方服务的业务，留下安全隐患。另外脚本不得不适配不同的接口协议和复杂接口认证流程等；
- 直接向数据库插入符合测试前置条件的新数据：自由度最高，数据完整度可控，能够获得隔离性最高的测试数据集。维护成本高，耦合技术方案存储层设计。管理成本高，需要一种高效组织和检索的方式以避免重复和凌乱的测试数据集。但是这种方式是相对稳定的方案。
我的方案
（待续……）
参考资料
版权声明：本文为原创文章，转载请注明来源：《对于测试数据管理的思考 - Hackerpie》，谢绝未经允许的转载。