如何作好接口测试？

本文转载：http://www.51testing.com/html/95/n-3718695.html

1、接口测试简介

一、什么是接口测试？
接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等

二、为何要作接口测试
a)互联网的快速发展，公司内部系统或与外部系统的关联愈来愈多，一个业务流程关联多个后端系统，它们的关联都是基于接口来实现，接口测试能够将复杂的系统关联进行简化，只要作好每一个接口的测试就可以较好的保证系统质量。
b)单个系统的变动，是否会影响到关联业务系统，比较难用常规的测试方面来覆盖相关的应用系统（例如使用此接口的外部 系统有N个，不可能每一个作功能兼容性测试），但能够经过对接口功能的覆盖来验证是否影响它人对接口的调用。
c)接口功能比较单一，可以比较好的进行测试覆盖，也相对容易实现自动化持续集成，，能够减小人工回归成本与时间，缩短测试周期。
d)接口相对于界面功能，会更底层一些，测试覆盖会更容易（如业务在调用接口时作了判断，当不知足条件时连接就不显示，此时从界面没法测试相关功能是否作好判断，经过接口就比较容易）

三、接口测试范围
a)业务功能（包括正常、异常场景是否实现）
b)业务规则（覆盖度是否全面）
c)参数验证（边界、业务规则是否达到要求）
d)异常场景（重复提交、并发提交、事务中断、多机环境、大数据量测试）
e)性能测试（响应时间、吞吐量、并发数、资源要求）
f)安全测试（权限验证、SQL注入等）

四、接口测试的重点
一、检查接口返回的数据是否与预期结果一致。
二、检查接口的容错性，假如传递数据的类型错误时是否能够处理。
三、接口参数的边界值。例如，传递的参数足够大或为负数时，接口是否能够正常处理。
四、接口的性能，http请求接口大多与后端执行的SQL语句性能、算法等比较相关。
五、接口的安全性，外部调用的接口尤其重要。

2、作好接口测试的前提

一、系统化的接口文档
传统的接口文档，通常采用word或wiki等系统来记录，从单次使用上彷佛比较简单，由于你们会更习惯这样的操做，但这种形式存在比较大的问题：
a、接口文档非标准化，没法直接与接口测试工具接口使用
b、接口维护困难，接口有变化时比较难标识清楚，沟通成本很高
系统化接口文档，例如rap（淘宝分源的一个系统），具有接口维护标准化、版本化管理、MOCK测试等功能；对标准化的接口内容作二次开发，能够直接导出Soapui等工具使用的格式，直接导入工具中使用，有如下好处：
A、接口测试时再也不须要手工输入相关字段，节省时间成本
B、版本化管理，可以清晰的知道哪些接口有变化
Rap参考 http://rapapi.org/org/index.do

二、标准化的接口规范
接口管理是作好接口测试很重要的前提，若是一个系统有哪些接口都不太清楚，测试就很难覆盖到，接口管理建议采用如下方式：
A、按接口提供方为单位进行首次划分，按接口使用方进行二次划分，再按业务模块进行细分，分类原则根据内容多少进行优化，不须要固定，如自己接口较少就没有必要分得过细，较多时就须要多划分模块
如：系统A，提供有 一、二、三、四、五、六、七、八、9 这9个接口，接口分别给B系统、C系统使用，其中一、2为公用接口，三、四、5为B专用，六、七、八、9为C系统专用，划分以下：

B、按接口连接URL作为惟一，不一样的接口参数作为接口变量，接口有参数变动时在原来接口上进行维护，而不是新增长接口
C、为接口增长版本号，方便清楚哪些接口本次有变动，易于维护用例

 

3、接口测试经常使用工具

工具名	类型	特色	使用建议
JMeter	开源	开源	我的以为使用起来仍是比较麻烦，对JMeter很是熟悉的建议使用，新手不建议使用
JMeter	开源&商业	开源版本有功能限制，不能直接使用循环等、支持groovy语言	操做比较简单，但对具备必定的流程的接口测试用例不是太方便维护，对于独立的接口推荐使用
PostMan	免费	流利器插件，易用，功能相对简单	相对比较简单的接口
Loadrunner	免费	主要作性能测试使用，具有接口请求录制自动生成脚本、添加判断等功能	具备必定流程性的接口、及具有LR使用经验的人使用

一、JMeter
JMeter是Apache组织开发的基于Java的压力测试工具，可以将请求转换为脚原本实现，并容许使用正则表达式建立断言来对请求返回结果进行判断，具有接口测试功能和性能的能力。
参考：http://www.51testing.com/html/79/n-3708579.html
二、SOAPUI
SoapUI是一个完整的自动化测试解决方案。支持SOAP和REST的Web服务，JMS企业消息层，数据库，丰富的互联网应用，等等。而在SoapUI，你从它的直观和强大的用户界面这一切。对于自动化程度较高，SoapUI还提供了命令行工具，让您运行的功能/负载测试和几乎全部的任务调度程序，或做为您的构建过程当中的一个组成部分MockServices集。
三、PostMan
Postman是一款功能强大的网页调试与发送网页HTTP请求的Chrome插件，具有Fiddler\httpwatch之类的工具调试请求的功能，同时具有接口管理功能，官网提高脚本保存同步功能，支持接口导入导出
http://blog.csdn.net/flowerspring/article/details/52774399
四、Loadrunner
HP公司的性能测试工具，使用C语言或JAVA语言编写脚本，易学易用

4、接口自动化测试实例

RAP+SoapUI
一、接口文档rap系统录入

二、导出wadl格式文件

三、接口导入测试工具进行测试
打开soapui，新建project,右键添加WADL


确认导入后结果以下：

右键对应的项目生成测试用例

界面以下：

备注：这里可选择为每个资源生成一个单独的用例，也能够选择将全部请求生成到一个用例中，使用时建议，请求将多时选择，较少时选择
，以方便用例管理
确认后，将生成以下的测试用例集

接下来对每个用例进行完善，进行参数化、添加检查点来判断结果

注：
一、参数化方式有多种形式，支持直接维护参数列表、读取参数文件、直接使用SQL语句查询数据等。若是数据是比较固定的可使用直接维护参数列表；若是数据状态之类的会发生变化，建议使用SQL语句查询，这样能保证参数的有效性
二、检查点也支持多种形式，经常使用contains、Xpatch Match,支持本身编写脚原本判断
RAP+PostMan
PostMan支持导入功能，能够直接导入
Postman Collection, Environment, data dump, curl command, or a RAML / WADL / Swagger(v1/v2) / Runscope file

将上面导入SOAPUI中的WADL文件导入，结果以下：

PostMan与soapui接合
Soapui 新版本支持直接导入PostMan Collection，以下图

这样你们也能够将使用PostMan测试的记录导入到Soapui中使用

5、持续集成接口测试

对接口测试而言，持续集成自动化是核心内容，经过自动化的手段才能有效下降成本，提升接口测试的价值。若是使用LR、JMeter、SoapUI工具作自动化测试，工具自己支持命令行模式运行，能够接合Jenkins 等自动化平台，实现项目版本更新后的自动化回归测试
关于持续自动化回归测试的建议：
一、接口脚本开发时要注意参数的取值的可用性，不由于时间或数据状态的变化引发脚本不能正常运行，下降脚本维护成本.
二、接口回归功能的覆盖度控制，须要根据脚本的实际功能和重要性判断自动化回归覆盖度，回归内容越多脚本维护成本越高，通常应用接口不建议全功能覆盖（毕竟接口有变化会作详细测试，若是没修改其它变动可能对其产生的影响通常不会影响其逻辑判断）
三、接口脚本须要必定的自动化校验能力，除请求http状态的判断外，还须要对核心内容的正常性作判断（判断内容可与数据库内容匹配等方式，不建议用写死的内容）。
四、持续性能测试，还须要作好相关的监控、性能指标的分析自动化，减小人工操做。