ITester接口测试框架 (一) ：接口基础知识

本系列教材将主要为大家讲解接口测试框架的设计，本框架属于轻量型的，目前的需求基本都能满足，后续还要不断的完善，最后开源出去。暂且命名为ITester（取名字是一件很蛋疼的事情，要与接口相关，又要不能和其他框架重名）

同样先规划下系列blog目录：
ITester接口测试框架(一)：接口基础知识
ITester接口测试框架(二)：框架简介和流程图
ITester接口测试框架(三)：框架实现细节

接下来开始第一部分，接口测试基础知识的讲解

什么是接口测试

接口是指系统模块与模块或系统与系统间进行交互,一般我们用的多的是HTTP协议的接口、WebService协议的接口,还有RPC (Remote Procedure Call Protocol)——远程过程调用协议的接口。

接口测试是为了测试接口，尤其是那些与系统相关联的外部接口，测试的重点是要检查数据的交换，传递和控制管理过程，还包括处理的次数。
不管是哪种接口,其本质就是发送一个request,然后服务器响应 后返回一个response,然后我们对response进行分析,这即是接口测试。

为什么要做接口测试

• 首先，随着系统复杂程度的上升，传统的测试方法测试成本急剧增加，测试效率大幅下降（数据模型推算，底层的一个bug能够引发上层的 8 个左右bug，而且底层的bug很容易引起全网的宕机。相反接口测试能够提供系统复杂度上升情况下的低成本高效率的解决方案。
• 其次接口测试不同于传统开发的单元测试，接口测试是站在用户的角度对系统接口进行全面高效持续的检测。
• 最后接口测试是自动化并且持续集成的，这也是为什么接口测试能够低成本高收益的根源。

接口测试的核心战略在于：以保证系统的正确和稳定为核心，以持续集成为手段，提高测试效率，提升用户体验，降低产品研发成本。

接口测试要为代码的编写保驾护航，增强开发人员和测试人员的自信，让隐含的 BUG提前暴露出来，要让开发人员在第一时间修复 BUG，要让功能测试人员和性能测试人员在测试的时候更加顺手，最大限度得减少底层 BUG 的出现数量，要让产品研发的流程更加敏捷，要缩短产品的研发周期，最后在产品上线以后，要让用户用得更加顺畅，要让用户感觉产品服务零缺陷。

另外在这个过程中，我们需要几类资源作为支撑，下面做简单描述。
1. 首先最重要的一点是要强调团队的重要性，特别是团队中需要有合理的人力资源配置，在这个团队中，需要全才，也需要专才，需要技术专家，也需要业务专家，既需要高效的执行者，也需要有效的管理者，任何人在这个团队中都可以发挥重要作用。
2. 其次我们需要强大的测试技术以及测试框架去支撑我们的日常工作，包括基于 JAVA 以及基于 C++的测试框架，甚至以后会扩展到其他各个语种的框架，计算机软件的架构发展到今天，特别是分布式软件的发展，导致软件体系结构日益复杂化，各个系统之间的依赖逐渐加强，JAVA、C++以及多种技术的综合使用，使传统的单元测试已经无法满足于针对接口编程的架构方式，我们需要以一种更加干净的层面也就是从业务的层面对接口进行隔离测试，同时为了模拟真实场景，也需要在真实的环境中对系统内根据业务流程对各个接口进行串联测试，
3. 最后以持续集成系统保证被测代码的稳定性。再次要充分重视文档的重要性，包括需求文档，开发技术方案，测试技术方案，接口定义 JAVADOC，测试用例文档等等，完善这些文档可以大大减少软件工程周期中各个团队配合障碍，也可以降低后期软件维护成本。因此贯彻和落实接口测试的战略可以最大程度地提高软件质量的稳定性。

接口的种类

• 系统与系统之间的调用，比如支付宝会提供接口给DJI商城调用，或者说，支付宝会提供接口给天猫调用
• 上层服务对下层服务的调用，比如Service层会调用DAO层的接口，而应用层又会调用Service层提供的接口
• 服务之间的调用，比如注册用户时，会先调用用户查询的服务，查看该用户是否已经注册。

而我们所要做的接口测试，先要了解是基于哪一种类型的接口测试，不同类型的接口测试方法可能是不一致的，总体来说，不管是哪种类型，我们只要把被测接口当做是服务方，而把我们的测试手段当做是客户方，我们的目的就是，通过我们的测试手段，去验证服务端满足了他声明提供的功能。

GET和POST区别

参考我之前的blog：HTTP 学习笔记

GET方式提交

a）地址栏（URI）会跟上参数数据。以？开头，多个参数之间以&分割。

GET /day09/testMethod.html?name=eric&password=123456 HTTP/1.1
Host: localhost:8080
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: zh-cn,en-us;q=0.8,zh;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Referer: http://localhost:8080/day09/testMethod.html
Connection: keep-alive

b）GET提交参数数据有限制，不超过1KB。
c）GET方式不适合提交敏感密码。
d）注意： 浏览器直接访问的请求，默认提交方式是GET方式

POST方式提交

a）参数不会跟着URI后面。参数而是跟在请求的实体内容中。没有？开头，多个参数之间以&分割。

POST /day09/testMethod.html HTTP/1.1
Host: localhost:8080
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: zh-cn,en-us;q=0.8,zh;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Referer: http://localhost:8080/day09/testMethod.html
Connection: keep-alive

name=eric&password=123456

b）POST提交的参数数据没有限制。
c）POST方式提交敏感数据。

接口测试的方法

至于接口测试具体的测试方法，http协议的接口测试，一般会用jmeter去测试，jmeter的好处是不用写测试代码，直接使用jmeter提供的http请求去测试，也可以使用postman，也可以使用HttpClient去测试，好处是可以方便集成和自动化。java接口的测试，则需要编写测试代码去测试，有点类似于单元测试。
　　但是以上的方法都只是通过发送Request，返回Respouse，简单的验证返回值是否正确，它的缺点很多：　　
　　
- 它不能将请求参数完全的覆盖，只是简单的覆盖几个参数
- 手动的一条一条伪造自测数据
- 对于复杂类型的请求参数，例如javaBean对象，无法发送
- 不能自动化的判断返回值是否正确
- 需要手工一条一条去执行接口，效率太低

基于以上缺点，github上有很多同学做了各种不同的接口框架，比如百度的iTest，阿里taobao etao测试团队开发的TOAST，网易的Dagger，但是上述框架都是基于自己公司的业务基础设计开发的，只供参考，我自己设计了一套接口测试框架 ，暂且命名为ITester，详细介绍请看下一篇博文。