一次性使用的测试数据，让很多同事在自动化测试执行中最头疼的可能就是这种测试的数据准备工作了，因为只能使用一次，每次运行之前都要准备新的数据，工作量不可谓不大，而且如果数据本身比较复杂或者稀少，这个数据准备工作就更让人怀疑这些功能用自动化的方式来测试是否价值了。那么对于这种一次性的测试数据，我们用什么方法去争取一劳永逸的效果呢？
a) 如果数据存量较多，则考虑直接链接数据库查询满足测试需求的数据，注意，满足测试需求或许不是简单的一两个SQL语句能决定的，需要仔细了解系统业务、设计逻辑，争取让测试数据是绝对可用的。
b) 如果数据较少，运行存在数据不足使用的潜在隐患的话，可以考虑该业务功能的互逆操作，从系统中寻找现成的具有数据对称性的功能，如果有这种功能的存在，那么两个功能串联在一起测试运行，能够起到操作回退的作用。
c) 如果业务系统中不存在互逆的功能，考虑后台数据的回归和删除，例如保单状态修改，系统中不支持保全回退。考虑在测试数据库中建立一个JOB，对操作进行回滚，修改和删除所有影响到该笔数据下次继续运行的数据库记录，根据测试执行的频率决定JOB对应的运行频率，保证每次测试运行之前运行一次Rollback测试数据的JOB。
d) 不断生成新的可用的测试数据，增加可用数据量。寻找数据最初的来源，例如我们说的这两个操作所需要的数据，他们都可以由新契约承保生成测试数据，如果契约承保系统功能正常、自动化能够正常运行，那么我们将会不断得到新的数据，从而避免数据量过少又不可复用的尴尬。只不过这种方式对关联系统功能和自动化测试程序运行的稳定性依赖性较高，很难保证。
笔者个人建议：无论是什么类型的数据，使用什么样的方法，只要相同的数据能够长时间反复使用，那么将这写数据使用数据文件存储，映射到测试程序上去。存储数据的载体文件如EXCEL，统一保存在测试框架下指定的目录中，降低测试运行对人工测试数据准备的要求，最好能保证在首次运行成功之后还能够运行30次以上。对于不可复用的数据或者实时性要求很高的数据，则从被测系统数据库从获取，而对于完全不可复用也不可状态回退的测试数据，如第二章结尾所述，是否要进行自动化测试是值得商榷的。