数据管理策略的三个案例

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

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);

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

下一篇
举报

扫码关注云+社区

领取腾讯云代金券