测试数据管理-数据管理策略的三个案例

本文不是讲述测试数据管理的具体技术，而是测试数据管理的策略。

Seed Data

之前在外企做UI自动化的时候，有一套所谓的Seed data。这套数据是产品的一部分，安装完就有，业务上主要给客户做demo用。我们用它来做自动化的上下文。
譬如在项目管理系统JIRA中，如果需要报告一个缺陷，需要的上下文是：项目、缺陷工作流、系统、版本、报告人员、开发人员等业务对象。
所谓的Seed Data就是类似一个项目A、几个系统B/C，若干个人员(甲乙丙丁、admin)以及默认的工作流等等这些业务对象的集合。
有了这个套数据之后，类似新建缺陷、新增任务等测试用例就可以直接在包含了这套数据中运行了。
如以下的一个用例：

作为用户(甲),我可以登陆项目A,报告一个缺陷。该缺陷可以关联到系统B。

只要被测系统已经被安装，上述用例就可以被运行。

Dump Data

第二个套路是针对某个金融系统的。这类系统的问题是里面的业务对象都是在变化的，譬如产品/合约/价格/客户等等。例如，贵州茅台这个股票的价格每天都是变化的。这与第一个案例中的固定数据是不同的。
我们采用的是自给自足控制上下文的套路。每次业务改造的测试开始前，先基于基础环境准备一套数据dump，然后所有人的测试用例是基于这套数据写的，也只能在这套dump下运行。
运行时先部署环境，在一个干净的只有二进制的环境里倒入数据，包括系统配置，再运行用例,如：

作为一个股民，我希望通过多普达手机，购买1000手贵州茅台，成交价格为100元。

回归测试的时候，只要和用例配套的dump data已经导入系统，相关的用例就能保证可以正确运行。甚至极端情况下，如数据库接口/配置项异常测试时，每个用例都有一套属于自己的Dump Data，用来控制系统以确保在用例运行时处于正确的上下文。
所以日积月累，就累积了几十套数据，体积上有10G左右。除了体积庞大之外，如果新版本改造过程中涉及数据格式、配置文件等调整，就需要维护所有的用例集的dump 数据，有不少的工作量。

动态数据

这块目前还在试点，应用范围较小。主要目标是解决第二套方法中，用例和数据绑定的问题。希望能够通过用例与数据解耦，可以不用维护庞大的dump data,而是在运行时根据规则，可以动态的去query/filter，产生可用的数据来作为输入/预期结果,如以下的案例：

Bean order = new Order;
order.stock=findAStockWithHighestPrice();
order.number=MimValidQuantity();
order.price=LastPrice();
buy(order);

目前主要是在系统线上运行，发挥冒烟测试的功能。