接口测试总结

什么是接口测试:

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

为什么要进行接口测试:
a)互联网的快速发展，公司内部系统或与外部系统的关联越来越多，一个业务流程关联多个后端系统，它们的关联都是基于接口来实现，接口测试可以将复杂的系统关联进行简化，只要做好每个接口的测试就能够较好的保证系统质量。
b)单个系统的变更，是否会影响到关联业务系统，比较难用常规的测试方面来覆盖相关的应用系统（例如使用此接口的外部系统有N个，不可能每个做功能兼容性测试），但可以通过对接口功能的覆盖来验证是否影响它人对接口的调用。
c)接口功能比较单一，能够比较好的进行测试覆盖，也相对容易实现自动化持续集成，，可以减少人工回归成本与时间，缩短测试周期。
d)接口相对于界面功能，会更底层一些，测试覆盖会更容易（如业务在调用接口时做了判断，当不满足条件时链接就不显示，此时从界面无法测试相关功能是否做好判断，通过接口就比较容易）
接口测试范围:
a)业务功能（包括正常、异常场景是否实现）
b)业务规则（覆盖度是否全面）
c)参数验证（边界、业务规则是否达到要求）
d)异常场景（重复提交、并发提交、事务中断、多机环境、大数据量测试）
e)性能测试（响应时间、吞吐量、并发数、资源要求）
f)安全测试（权限验证、SQL注入等）
接口测试的重点:
1、检查接口返回的数据是否与预期结果一致。
2、检查接口的容错性，假如传递数据的类型错误时是否可以处理。
3、接口参数的边界值。例如，传递的参数足够大或为负数时，接口是否可以正常处理。
4、接口的性能，http请求接口大多与后端执行的SQL语句性能、算法等比较相关。
5、接口的安全性，外部调用的接口尤为重要。
系统化的接口文档
传统的接口文档，一般采用word或wiki等系统来记录，从单次使用上似乎比较简单，因为大家会更习惯这样的操作，但这种形式存在比较大的问题：
a、接口文档非标准化，无法直接与接口测试工具接口使用
b、接口维护困难，接口有变化时比较难标识清楚，沟通成本很高
系统化接口文档，例如rap（淘宝分源的一个系统），具备接口维护标准化、版本化管理、MOCK测试等功能；对标准化的接口内容做二次开发，可以直接导出Soapui等工具使用的格式，直接导入工具中使用，有以下好处：
A、接口测试时不再需要手工输入相关字段，节省时间成本
B、版本化管理，能够清晰的知道哪些接口有变化
标准化的接口规范:
接口管理是做好接口测试很重要的前提，如果一个系统有哪些接口都不太清楚，测试就很难覆盖到，接口管理建议采用以下方式：
A、按接口提供方为单位进行首次划分，按接口使用方进行二次划分，再按业务模块进行细分，分类原则根据内容多少进行优化，不需要固定，如本身接口较少就没有必要分得过细，较多时就需要多划分模块
如：系统A，提供有 1、2、3、4、5、6、7、8、9 这9个接口，接口分别给B系统、C系统使用，其中1、2为公用接口，3、4、5为B专用，6、7、8、9为C系统专用，划分如下：
B、按接口链接URL做为唯一，不同的接口参数做为接口变量，接口有参数变更时在原来接口上进行维护，而不是新增加接口
C、为接口增加版本号，方便清楚哪些接口本次有变更，易于维护用例
JAVA项目使用Swagger 插件:
Swagger是最受欢迎的REST APIs文档生成工具之一，有以下几个特点：
Swagger 可以生成一个具有互动性的API控制台，开发者可以用来快速学习和尝试API。
Swagger 可以生成客户端SDK代码用于各种不同的平台上的实现。
Swagger 文件可以在许多不同的平台上从代码注释中自动生成。
Swagger 有一个强大的社区，里面有许多强悍的贡献者。
它将代码与接口文档整合在一起，避免了接口文档维护困难，接口文档更新不及时不到位等问题；同时它也能够方便的与接口测试工具接合使用，如soapui支swagger插件导入接口文档进行测试
详细内容可查看http://www.cnblogs.com/JoiT/p/6378086.html
接口测试常用工具:
1、JMeter
JMeter是Apache组织开发的基于Java的压力测试工具，能够将请求转换为脚本来实现，并允许使用正则表达式创建断言来对请求返回结果进行判断，具备接口测试功能和性能的能力。
参考：http://www.51testing.com/html/79/n-3708579.html
2、SOAPUI
SoapUI是一个完整的自动化测试解决方案。支持SOAP和REST的Web服务，JMS企业消息层，数据库，丰富的互联网应用，等等。而在SoapUI，你从它的直观和强大的用户界面这一切。对于自动化程度较高，SoapUI还提供了命令行工具，让您运行的功能/负载测试和几乎所有的任务调度程序，或作为您的构建过程中的一个组成部分MockServices集。
3、PostMan
Postman是一款功能强大的网页调试与发送网页HTTP请求的Chrome插件，具备Fiddler\httpwatch之类的工具调试请求的功能，同时具备接口管理功能，官网提升脚本保存同步功能，支持接口导入导出
http://blog.csdn.net/flowerspring/article/details/52774399
4、Loadrunner
HP公司的性能测试工具，使用C语言或JAVA语言编写脚本，易学易用
持续集成接口测试:
对接口测试而言，持续集成自动化是核心内容，通过自动化的手段才能有效降低成本，提高接口测试的价值。如果使用LR、JMeter、SoapUI工具做自动化测试，工具本身支持命令行模式运行，可以接合Jenkins 等自动化平台，实现项目版本更新后的自动化回归测试
关于持续自动化回归测试的建议：
1、接口脚本开发时要注意参数的取值的可用性，不因为时间或数据状态的变化引起脚本不能正常运行，降低脚本维护成本.
2、接口回归功能的覆盖度控制，需要根据脚本的实际功能和重要性判断自动化回归覆盖度，回归内容越多脚本维护成本越高，一般应用接口不建议全功能覆盖（毕竟接口有变化会做详细测试，如果没修改其它变更可能对其产生的影响一般不会影响其逻辑判断）
3、接口脚本需要一定的自动化校验能力，除请求http状态的判断外，还需要对核心内容的正常性做判断（判断内容可与数据库内容匹配等方式，不建议用写死的内容）。
4、持续性能测试，还需要做好相关的监控、性能指标的分析自动化，减少人工操作。

问题:

后端接口都测试什么？:

--回答这个问题，我们可以从接口测试活动内容的角度下手，看一下面这张图，基本反应了当前我们项目后端接口测试的主要内容：

怎么叫做接口测试:
由于我们项目前后端调用主要是基于http协议的接口，所以测试接口时主要是通过工具或代码模拟http请求的发送与接收。工具有很多如：postman、jmeter、soupUI、java+httpclient、robotframework+httplibrary等。

后端接口测试一遍，前端也测试一遍，是不是重复测试了？
--回答这个问题，我们可以直接对比接口测试和app端测试活动的内容，如下图为app测试时需要覆盖或考虑内容：
从上面这两张图对比可以看出，两个测试活动中相同的部分有功能测试、边界分析测试和性能测试，其它部分由于各自特性或关注点不同需要进行特殊的测试，在此不做讨论。接下来我们针对以上三部分相同的内容再进行分析：

1、基本功能测试：

　　由于是针对基本业务功能进行测试，所以这部分是两种测试重合度最高的一块，开发同学通常所指的也主要是这部分的内容。

2、边界分析测试：

　　在基本功能测试的基础上考虑输入输出的边界条件，这部分内容也会有重复的部分（比如业务规则的边界）。但是，前端的输入输出很多时候都是提供固守的值让用户选择（如下拉框），在这种情况下测试的边界范围就非常有限，但接口测试就不存在这方面的限制，相对来说接口可以覆盖的范围更广，同样的，接口出现问题的概率也更高。

3、性能测试：

　　这个比较容易区分，虽然都需要做性能测试，但关注点确大不相同。App端性能主要关注与手机相关的特性，如手机cpu、内存、流量、fps等。而接口性能主要关注接口响应时间、并发、服务端资源的使用情况等。两种测试时的策略和方法都有很大区别，所以这部分内容是需要分开单独进行测试的，理论上来说这也是不同的部分。

综论：

1、接口测试和app测试的活动有部分重复的内容，主要集中在业务功能测试方面。除此之外，针对各自特性的测试都不一样，需要分别进行有针对性的测试，才能确保整个产品的质量。

　　2、接口测试可以关注于服务器逻辑验证，而UI测试可以关注于页面展示逻辑及界面前端与服务器集成验证