接口自动化测试小结

概述

自动化接口测试是防止我们在演进系统的过程中引入新的bug,是一种回归性验证的手段。因为人工的测试非常缓慢，如果我们修改了代码，需要等待很长时间才能知道我们的修改是否正确，这就会给修改代码带来很大的风险，有可能我们就不等待人工测试的结果就交付产品。如果我们有一套能很快运行的自动化测试集，我们就能回归模块代码的修改是否对接口服务的调用产生影响，从而更快的验证代码的修改是否对已有功能造成破坏，是否引入了新的bug。

自动化测试观点:

自动化测试是一种快速反馈的手段。

充分调研项目的可测试性，以可测试性为目标来确定是否开展自动化测试及编写代码. 

测试应该可以重复运行

接口测试的实施优先级 

　　对于一个应用来说，接口测试就是对某一个接口进行测试代码的编写和执行。一般情况下，实施接口测试的优先级是：对暴露在外面的接口(该接口会给第三方调用)进行接口测试;内部的核心功能接口也会做接口测试;内部非核心功能接口的接口测试(很多时候就是单元测试)。当然这个实施的具体细节，还需要根据项目的实际情景和人员的能力技能来确定如何实施接口测试、在哪里做接口测试、为什么要做接口测试、做到什么程度等。

接口测试类型：

●接口逻辑测试：主要根据开发提供的API进行编写测试用例，一般情况下JavaDoc需要包含前提条件，业务逻辑，输入参数，输出值的描述.

●接口出错测试：主要包括以下几个方面：

1）空值输入，如当传入一个对象参数时，需进行NULL值的参数

2）参数属性的测试，如果输入一个未赋值参数

3）异常的测试，制造一些异常的测试场景，测试的异常描述是否清晰

●路径测试

路径测试的目的就是设计尽可能少的用例，来保证各种业务场景下数据是安全可操作的。路径测试用例例子如下

:

此图的用例个数：

1.ABC

2.ABD

3.AE

4.AFG

如果考虑到A这条路径不只一个测试接口可以操作，可在上述用例的基础上再增加以下用例：

5. A’BC

6. A’BD

7. A’E

8. A’FG

如何进行接口测试：

设计接口测试用例：

此阶段需要充分的了解接口的实现功能的业务逻辑、数据流转、接口参数、接口返回值。

功能业务逻辑：例如：外部可以通过调用该接口进行一笔消费业务，具体细节说明如下：

　　    接口参数: 这笔消费的所有信息参数

接口返回值：Result对象，其中包含一些errorcode等基本属性。 

注：接口的测试设计主要关注点：

　　接口中所有的入参都要写测试用例:

每个入参的每个错误类型都要准备一个异常用例。如必须参数缺省、参数类型错误、参数范围错误、参数超过最大位数、参数没有达到最小指定位数、参数的无效值(有效状态外)、参数的小数点超过规定长度、参数含有非法字、参数含有违禁字、参数的关联性检查(如所在省、市，所在地不匹配)等等。

编写接口的测试代码

所有的自动化接口的测试用例  都基本围绕三步进行，传数据，执行，校验返回的数据和期望数据是否一致来构成每个简单的测试用例。

　　对于所有的参数，我们都需要校验一下参数的基本特征，如前面讲到的异常用例一样。那么接口测试代码又是什么样的呢。 

　　step1: 构建测试框架环境，编写测试基类(加载资源、初始化环境)(可选)。 

　　step2: 编写测试类。 

　　step3: 在该测试类中编写测试方法。 

　　step4: 在测试方法中调用被测方法。 

　　step5: 验证预期结果与返回的结果是否一致。 

　　step6: 执行测试 查看测试结果。 

那么针对所有的接口测试用例写接口测试代码，可以看到的是，我们的接口测试代码主要是入参的不同，校验结果的不同，其他区域的测试代码都是一样的。我们要做的是不断的copy前一个测试用例代码，然后修改某个参数、修改某个验证点就搞定了。

另外，所有的测试代码都是基于接口测试框架，框架的选择主要根据实际项目及业务场景的需要来定制，如TestNG，Junit，Nunit及其他开源测试框架等。

接口测试持续集成

当测试代码开发阶段性结束后，接口测试脚本可进行集成到Jenkins持续平台中，这样可以发挥脚本重复利用的特点，减少人为手工回归测试的开销。

如何进行持续集成？

利用Jenkins持续集成平台进行Maven方式的构建集成。

a)搭建项目测试环境，自动进行项目环境的每日构建

b)在Hudson上按模块创建接口测试的job任务，采用Maven命令行执行构建代码。详细任务配置如下图：

新建job,配置页面里添加SVN地址及构建运行Maven test即可，详细如下：

c)执行接口回归性测试，执行效果图如下：

为何要进行接口测试

对于一个复杂的分布式系统，由于业务间的调用相对频繁，接口间的调用会随着更加复杂，接口与接口之间的联调难度很大，项目风险也随之增大。

首先，可以提高测试质量，增大项目的回归测试覆盖率，减少测试遗漏率。尤其是支付类型的项目，每一个bug对公司都有可能会造成难以估量的损失。

其次,在项目初期，接口测试由于存在代码的开发及维护，投入大产出小。 但从长期看，可以提高测试效率。就目前的支付项目，随着系统的规模越来越大，功能点越来越多，开发人员的自测或者测试人员的人工测试非常耗时和繁琐，势必导致测试效率的低下，而自动化接口测试正好解决这些耗时繁琐的任务，在对外接口功能不变的情况下，达到了一次编写，永久使用的效果。

再次，更好地重现系统及代码缺陷，以及快速定位错误。目前支付项目一期已涉及的接口已经有几十个，当接口测试脚本稳定后，由于每次执行都是相同的脚本，一旦开发的接口模块发生代码出错，接口测试必定回归出错，再通过持续集成平台的邮件功能能较为迅速的反馈给开发及测试人员。

还有：降低了这类适合做接口测试的项目不能按时发布的风险。由于接口测试很早就介入，在提交给系统测试前对项目代码的核心模块已经做了详尽的测试，必定加速系统测试的时间，由此来保证项目的按时发布。

当然，也能提高测试人员的开发技能，还能发现一些功能黑盒测试所不能发现的隐藏bug。