测试数据准备

毫无疑问，稍复杂一点的系统，测试时都会遇到测试数据准备的问题，有些测试中，测试数据准备还是最困难最耗时的工作。

        前面提到测试数据产生的方法：1、GUI界面操作产生；2、调用API接口产生；3、通过操作数据库产生。三者各有特点，对需要把测试数据专门作为一项重要工作来对待的，一般都需要API接口+数据库混合的方式来准备数据。

        小型系统的测试，业务数据一般可以直接获取以前版本的数据，通过SQL数据或某些命令操作，取得当前需要使用的数据。

        对于复杂系统，测试数据准备可能需要封装一系列的API函数，例如一种策略就是先封装出一个完全API调用函数，里面有各种常规默认值，然后再这个基础上针对业务进行封装，面向该操作只需要设定某个特定值的，可以调用该特定封装函数。极个别的，可以直接调原始的完全封装。当然，考虑到一些大公司的情况，可能还需要考虑跨平台测试架构的情况，有些人提出进一步封装，提供RestFul的调用接口来屏蔽开发工具特性。其实，都只有一个目的，尽量把测试数据和产生方法隔离，而只侧重测试的业务属性。

  大量需要业务累积才能形成的测试数据，一般只有一个办法，就是通过大量实际数据脱敏。但如果涉及面向公众业务或国防业务之类，考虑到安全策略限制，就只能用笨办法就通过自动化操作来逐步实施模拟，但是这个方法就是太慢，并且不见得好用。

        对测试数据准备都需要有专人专责的一段时间来做的，就是很大系统很大业务了，这时很有必要对测试数据采取严格的版本管理和配置部署管理。用户需要首先注册数据，注明对应版本。测试运行时，平台会有统一生成的脚手架，对应脚本需要使用的数据必须标明版本。

         而考虑到自动化和灵活性，一般比较通用的方法还是先考虑实际数据脱敏，然后通过SQL脚本为基础，结合API调用，需要灵活配置的部分放到配置文件中，再加上配置管理来保证。这一般只在大型网站、大型系统有这个必要。

         实际测试时，针对测试数据，可能有以下一些策略：1、检索：只允许从现在系统中或已使用的数据中检索，没有的话直接生成数据失败；2、新创建：有些时候需要全新创建数据；3、智能：无所谓，只要有符合要求 ；4、out-of-box：使用缓冲池预先准备的数据。