接口测试这个词语，相信大家都不陌生了吧。目前我个人的理解，接口测试应该属于白盒测试的范畴，也是很多测试工程师很想从事和向往的一个测试手段。大家都觉得白盒测试深不可测，但实际上是怎么样的呢。
接口测试的实施优先级
对于 Web 应用来说，接口测试就是对某一个接口进行测试代码的编写和执行。一般情况下，实施接口测试的优先级是：对暴露在外面的接口（该接口会给第三方调用）进行接口测试；内部的核心功能接口也会做接口测试；内部非核心功能接口的接口测试（很多时候就是单元测试）。当然这个实施的具体细节，还需要根据项目的情景和人员的能力来确定如何实施接口测试、在哪里做接口测试、为什么要做接口测试、做到什么程度等。
接口测试的实施条件
接下来说下，接口测试实施需要的一些条件。第一个就是测试人员的能力，代码的熟悉能力、接口测试框架的使用能力、接口测试环境的搭建能力、接口测试设计的能力、基础代码的编写能力、基础 Debug 能力等。第二个就是接口测试框架，框架是否定制化一些功能（比如自动加载 java bean、方便初始化数据、方便校验数据库数据等）。第三个就是测试团队和测试流程的支持，测试团队需要支持测试人员对核心接口进行接口测试（包括时间上、精力上、技术上等支持）；测试流程上需要保证接口测试的效率和项目接入性（在项目当中实施接口测试，充分考虑开发团队和功能测试团队合作等）。
接口测试的实例
接下来会通过一个案例来说明接口测试的一些基本考虑点，这里不涉及到详细的接口测试流程和注意点，只会把接口测试的一些想象展示给大家。
public interface IdleItemService {
Result<ExtraItem> publish (ExtraItem extraItem);
/**
* taobao.idlesell.item.update
* 编辑闲置宝贝
*/
Result<ExtraItem> update (ExtraItem extraItem);
/**
* taobao.idlesell.item.get
* 查询闲置宝贝
*/
Result<ExtraItem> query (Long itemId,Boolean hasDesc,Boolean hasPic,String appKey);
} 上面的代码是淘宝的提供出去的某个 Top 接口代码，测试人员需要针对这个 Top 接口做最严格的接口测试，那他该怎么做呢，需要持续关注什么呢。
接口测试之前，需要充分的了解接口的实现功能的业务逻辑、接口参数、接口返回值。功能业务逻辑：外部可以通过该接口发布一个闲置二手的宝贝，具体细节不做说明。
接口参数: 一个宝贝的所有信息参数。见图：
接口返回值：Result<IdleItemResult>，其中包含一些 errorcode 等基本属性。
接口的测试设计主要关注点
- 接口中所有的入参都要写测试用例。
- 每个入参的每个错误类型都要准备一个异常用例。如必须参数缺省、参数类型错误、参数范围错误、参数超过最大位数、参数没有达到最小指定位数、参数的无效值（有效状态外）、参数的小数点超过规定长度、参数含有非法字、参数含有违禁字、参数的关联性检查（如所在省、市，所在地不匹配）等等。
- 对于正常系的用例，要把所有入参的各种合法的有效值都执行到。所有入参的最大位可以用一个测试用例执行掉。所有可缺省的参数不要（只输入必须参数）的测试用例也要做一个。
- 对于搜索接口，应该把每个参数单独作为搜索条件来确认搜索结果是否正确，然后再确认多条件输入后的结果。
如下是部分参数的接口测试设计的截图：
接口的测试代码的编写
大家应该发现了对于所有的参数，我们都需要校验一下参数的基本特征，如前面讲到的异常用例一样。那么接口测试代码又是什么样的呢。
- step1: 编写测试基类（加载资源、初始化环境）（可选）。
- step2: 编写测试类。
- step3: 在该测试类中编写测试方法。
- step4: 在测试方法中调用被测方法。
- step5: 验证预期结果与返回的结果是否一致。
- step6: 执行测试查看测试结果。
那么针对所有的接口测试用例写接口测试代码，可以看到的是，我们的接口测试代码主要是入参的不同，校验结果的不同，其他区域的测试代码都是一样的。我们要做的是不断的 copy 前一个测试用例代码，然后修改某个参数、修改某个验证点就搞定了。
接口测试自动化生成框架
对于这些比较重复的测试代码编写工作，大家肯定想到是否可以自动生成这些脚本，还会想到自动生成的脚本是否可以和测试数据一起自动运行测试代码呢。这里可没想象那么简单，需要考虑业务逻辑、接口环境、测试数据、接口测试框架等一系列的组合。
我们来简单点吧，我们的目的，在一定的测试范围内，充分利用工具来自动化生成测试用例，保证测试用例的覆盖率。 两种程度的复用该测试套件，一种是测试用例的生成和复用，一种是测试代码的生成和复用。 请看下面的自动化生成框架的架构图：
模板引擎架构图如下：
相关术语解释：
- All Pairs：利用参数来定制化生成测试用例的攻击，入口是 Excel 准备的参数文件；出口是 txt 文件的测试用例。这个工具是开源的，可以自己定制化开发，具体请见：http://www.infoq.com/cn/news/2011/08/combination-test
- 业务 API 库：由于需要生成测试代码，需要知道业务逻辑所涉及到的接口和类，比如 IC 中的发布宝贝的发布接口。
- 模板：根据业务逻辑规则制定的逻辑描述，可以利用因果图分析法中的“或与非”来描述接口业务功能逻辑（需要抽象出相应的关键因子，也就是部分的接口入参）
- 测试用例分析器：将 txt 文件格式的测试用例进行分析，分析每个用例的参数和参数值和业务逻辑。
- 测试数据分析器：将 xml 文件格式的测试数据进行分析，与生成的每个测试用例代码进行组合和处理，生成带数据的测试代码。
那么接下来我们需要做什么呢。迭代去开发我们需要的组件就行，第一步考虑自动生成接口测试框架代码，定制化的选择接口来自动生成框架代码（包括集成了现成的接口测试框架）；接下来考虑如何让我们的用户（测试人员）来输入我们的测试数据，并考虑与框架代码生成进行集成融合；另外一块就是测试环境的 API 的调用了，如何能自动运行自动生成的测试代码并反馈结果给测试人员等一系列的问题需要进一步深入挖掘。
这里还需要说明的是，我们不期望这个框架能解决所有接口功能接口测试代码的自动生成（有些接口实现业务逻辑较复杂），我们能解决掉一部分重复工作（某个接口的 60% 的测试代码），且能告诉大家我们可以做一些事情更智能化和简单化。
关于作者
高翔(花名季哥) 淘宝软件有限公司资深测试工程师，曾任职于华为南京研究所和群硕软件有限公司。有着通讯、ERP、互联网等多种行业的测试经验，对需求分析、测试流程、测试设计方法、风险分析有较深的理解，擅长于测试模型的建立、用例架构的设计、公共组件功能的抽象和应用、探索式测试流程和方法实践。