准备不可重复使用的测试数据，其实是一件比较让人头疼的一件事。
因为只能使用一次，每次运行之前都要准备新的数据，工作量不可谓不大。而且如果数据本身比较复杂或者稀少，这个数据准备工作就更让人怀疑这些功能用自动化的方式来测试是否有价值。
那么对于这种一次性的测试数据，我们用什么方法去处理比较好呢？
①. 如果数据存量较多，则考虑直接连接数据库，去数据库查询满足测试需求的数据。(注意，满足测试需求或许不是简单的一两个SQL语句能决定的，需要仔细了解系统业务、设计逻辑，争取让测试数据是绝对可用的。)
②.如果数据较少，运行存在数据不足使用的潜在隐患的话，可以考虑该业务功能的互逆操作，从系统中寻找现成的具有数据对称性的功能，如果有这种功能的存在，那么两个功能串联在一起测试运行，能够起到操作回退的作用。(比如，份额质押and份额解押，A份额过户给B，B再份额过户给A等类似的业务场景)
③.如果业务系统中不存在互逆的功能，考虑后台数据的回归和删除，例如保单状态修改，系统中不支持保全回退。考虑在测试数据库中建立一个JOB，对操作进行回滚，修改和删除所有影响到该笔数据下次继续运行的数据库记录，根据测试执行的频率决定JOB对应的运行频率，保证每次测试运行之前运行一次Rollback测试数据的JOB。
④.不断生成新的可用的测试数据，增加可用数据量。寻找数据最初的来源，例如我们说的这两个操作所需要的数据，他们都可以由新契约承保生成测试数据，如果契约承保系统功能正常、自动化能够正常运行，那么我们将会不断得到新的数据，从而避免数据量过少又不可复用的尴尬。只不过这种方式对关联系统功能和自动化测试程序运行的稳定性依赖性较高，很难保证。（比如手机号码、身份证号码，统一社会信用代码，这些在当前项目当中需保证唯一性，所以可以借助Faker这个Python第3方库，每次生成新的数据）
个人认为：无论是什么类型的数据，使用什么样的方法，只要相同的数据能够长时间反复使用，那么就可以把写数据、使用数据文件存储，映射到测试程序上去。存储数据的载体文件如EXCEL，统一保存在测试框架下指定的目录中，降低测试运行对人工测试数据准备的要求，最好能保证在首次运行成功之后还能够运行30次以上。对于不可复用的数据或者实时性要求很高的数据，则从被测系统数据库从获取。（而对于完全不可复用且回退比较麻烦的测试场景，并且生成新的可用的测试数据如果也无法避免出现重复数据的情况，那么是否要进行自动化测试是值得商榷的。）
标签：数据库,测试数据,重复使用,测试,自动化,数据,运行 From： https://www.cnblogs.com/SuperLee017/p/18281306