接触接口测试已经有一段时间，从一开始的熟悉实现原理到后来的实际编写。在这段探索过程中，对单一简单用力的编写已经比较熟悉了，但是在将接口测试真正运用到实际项目中却出现了一些问题，较之严重的就是一个数据准备过程。

　　任何程序的运行其实就是一个处理数据的过程，可见数据准备在所有测试中都是不可或缺的。进行接口测试前必须准备好该接口需要的输入参数，即测试数据。一开始的时候，数据都是比较单一，但是当系统比较庞大，业务比较复杂时，数据之间难免会出现相互依赖和影响。这种情况大大加大了数据准备的难度和复杂度。

　　总结实际可以做的数据准备方法，主要有两类：一类是通过数据库操作直接准备用例所需的所有数据；另一类是通过已有的API调用来产生数据。

　　通过数据库操作来准备操作优点显而易见：操作简单，只需了解基本SQL语句语法就可以执行；异常数据准备简单，一般只需要通过insert操作来完成。缺点也比较明显：需要测试人员对项目的数据库的结构有一定程度的了解；极易产生垃圾数据，导致将部分精力透支在由垃圾数据产生的bug上；代码只为单一用例准备数据，不可重用。

　　通过已有的API调用来准备数据优点在于：极易保证数据的准确性，大大降低了产生垃圾数据的可能性；可以验证接口间的组合调用的正确性；代码重用率高。同样暴露的缺陷也明显：不易准备遗产数据，通过API调用参数基本为正常数据；接口之间依赖比较严重，如新建的API没有完成前，无法进行更新的验证。

　　在实际项目中，我们发现目前数据库想当庞大，表之间依赖也较多，了解熟悉并掌握业务相关的数据库，投入较大；由于对数据结构了解不够深入产生垃圾数据的可能性比较大。而通过API产生的数据非遗产数据，但是正常流程过程中本身就很难出现这些异常流程，这个缺陷还是在可以接受范围中。故我们在目前的项目中采用调用API的方式来准备数据。

　　在任何测试中，最耗时和最有深度的事是测试用例设计，如果在接口测试中让测试人员即要设计测试用例又要自己准备数据，且数据准备有需要一定的时间（包括梳理业务流程和编写需要但目前还未提供的API），那么接口测试用例的编写的投入太大。因此我们组实行由专人提供基础的API，为用例设计者准备数据。这样做可以使用例设计者可以集中力量来设计用例，而不需要分出时间来准备数据，独立出来的准备数据的人员可以通过准备的一些基础API，简单的为用例设计者提供所需数据，且这些API在以后的功能测试时，也可以很好的使用，提高工作效率。