1.接口测试概述
1.1 什么是接口测试
接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。
1.2 为什么要做接口测试
a) 如今的系统复杂度不断上升，传统的测试方法成本急剧增加且测试效率大幅下降，接口测试可以提供这种情况下的解决方案。
b) 接口测试相对容易实现自动化持续集成，且相对UI自动化也比较稳定，可以减少人工回归测试人力成本与时间，缩短测试周期，支持后端快速发版需求。接口持续集成是为什么能低成本高收益的根源。
c) 现在很多系统前后端架构是分离的，从安全层面来说：
1、只依赖前端进行限制已经完全不能满足系统的安全要求（绕过前面实在太容易）， 需要后端同样进行控制，在这种情况下就需要从接口层面进行验证。
2、前后端传输、日志打印等信息是否加密传输也是需要验证的，特别是涉及到用户的隐私信息，如身份证，银行卡等。
1.3 接口测试分类
接口测试大体分为两类：模块接口测试和web接口测试。
模块接口测试
模块接口测试是单元测试的基础,它主要测试模块的调用与返回。经常需要编写一些桩模块与驱动模块。
主要测试要点如下：
检查接口返回的数据是否与预期结果一致。
检查接口的容错性，假如传递数据的类型错误时是否可以处理。
接口参数的边界值。例如，传递的参数足够大或为负数时，接口是否可以正常处理。
接口的性能，接口处理数据的时间也是测试的一个方法。牵扯到内部就是算法与代码的优化。
接口的安全性
Web接口测试
web接口测试又可分为两类：服务器接口测试和外部接口测试。
服务器接口测试：是测试浏览器与服务器的接口。用户输入的数据是输入到的前端页面上，怎样把这些数据传递的后台的呢？通过http协议的get与post请求来实现前后端的数据传递。这也可认为是接口测试。
外部接口测试：这个很典型的例子就是第三方支付，比如在我们应用中在充流量时，交话费时，都会调用第三方支付接口。
主要测试要点如下：
请求是否正确，默认请求成功是200，如果请求错误也能返回404、500等。
检查返回数据的正确性与格式；json是一种非常常见的格式。
接口的安全性，一般web都不会暴露在网上任意被调用，需要做一些限制，比如鉴权或认证。
接口的性能，这直接影响用户的使用体验。
1.4 测试用例设计与原则
因为在实际工作中测试的接口都是基于HTTP协议的，所以下面的测试用例及原则也是针对此类接口。
测试用例
正面测试用例：
a覆盖所有的必选参数
b.组合可选参数
c.参数边界值
如果参数的取值范围是枚举变量，需要覆盖所有枚举值
还应考虑实际业务应用场景，去设计输入参数的组合。（这些用例可用来测试功能，作为SMOKE用例。也可将来用于压力测试模拟实际业务场景，但要注意保证用例的独立性，因为压力测试是多线程的。比如我们测试ACCOUNT 创建接口，NAME是不能重的，在写测试用例时，给NAME赋值时可以加一个时间戳, 这样用例在多线程并发测试时也不会有问题）
负面测试用例：
a.空数据或null
b.包含特殊的字符
c.越界的数据
d.错误的数据
验证点：
1.status code （正常情况下，所有请求都应该返回200）
2.响应信息数据结构（目前大多数情况下，返回信息都是JSON, 我们应该验证相应的结构当数据信息发生改变时）
3.验证结点的类型
4.验证结点的值 （主要是针对固定的值或者值遵循某些规则，我们能知道预期的结果的）
5.对于列表，应该根据请求参数，也应该验证列表的长度是否与期望值一致
6.负面测试用例，应验证ERROR INFO是否与实际相匹配
测试基本原则
测试用例应该是独立的、可读的、抗变的、可维护的，其实这也是所有自动测试应该遵循的
1.每个测试用例都是独立的
2.测试用例都是可重复运行的 (这主要是说一些测试数据不能写死，不同的环境数据可能不同。在实际工作中，解决方案有二：自已创建所需要的数据，比如你要测试接口需要输入参数ACCOUNTID,你可以先调用创建ACCOUNT API, 然后从响应值拿到ACCOUNTID, 当你3.测试完你要测的接口后，再把新建的ACCOUNT删除，也就是说一个测试用例分了三步。另外一种方法就是读取数据库，从数据库获取数据，这种方法在测试开发与测试环境还OK，但如果测线上环境就比较困难了，因为我们不能随意更新上面的数据，也不能放过多的4.测试数据在上面。因此我个人比较推崇第一种方法，虽然增加开发用例的工作量，但一劳永逸）
5.测试能被运行在不同的环境里（平常测试环境至少会分DEV/TEST/STAGING/ONLINE，我们在测试过程中，应该把域名，token/apikey等应放在一个变量里，当切换环境时，我们只需改变变量的值即可
6.测试数据与业务相分离（测试数据包括参数接口数据/ 测试执行所需要的系统数据)
7.尽量统一共用的测试环境变量
8.测试完成后，要删除不必要的测试数据。
1.5 接口测试持续集成
对接口测试而言，持续集成自动化是核心内容，通过持自动化的手段我们才能做到低成本高收益。目前我们已经实现了接口自动化，主要应用于回归阶段，后续还需要加强自动化的程度，包括但不限于下面的内容：
a) 流程方面：在回归阶段加强接口异常场景的覆盖度，并逐步向系统测试，冒烟测试阶段延伸，最终达到全流程自动化。
b) 结果展示：更加丰富的结果展示、趋势分析，质量统计和分析等
c) 问题定位：报错信息、日志更精准，方便问题复现与定位。
d) 结果校验：加强自动化校验能力，如数据库信息校验。
e) 代码覆盖率：不断尝试由目前的黑盒向白盒下探，提高代码覆盖率。
f) 性能需求：完善性能测试体系，通过自动化的手段监控接口性能指标是否正常。
1.6 接口测试质量评估标准
a) 业务功能覆盖是否完整
b) 业务规则覆盖是否完整
c) 参数验证是否达到要求（边界、业务规则）
d) 接口异常场景覆盖是否完整
e) 接口覆盖率是否达到要求
f) 代码覆盖率是否达到要求
g) 性能指标是否满足要求
h) 安全指标是否满足要求
1.7 接口测试流程
一、需求评审，熟悉业务和需求
二、开发提供接口文档
三、编写接口测试用例
四、用例评审
五、提测后开始测试
六、提交测试报告
1.8 接口用例模板
接口测试用例模板 （可根据项目实际情况设计增减）
1、项目 测试针对哪个项目
2、模块 哪个功能模块
3、用例id
4、接口名称
5、用例标题 测试用途概括
6、请求方式 GET/POST
7、请求url URL地址
8、请求参数
9、前置条件 执行当前请求依赖的条件，不满足就不能正确执行
10、结果验证 预期结果
11、请求报文 可以不写
12、返回报文 一定要写，这里应该是你请求返回的真实结果
13、测试结果 通过/失败
14、测试人员
2.Http协议简述
2.1 简介
HTTP是Hyper Text Transfer Protocol（超文本传输协议）的缩写。
HTTP协议是用于从WWW服务器传输超文本到本地浏览器的传送协议。它可以使浏览器更加高效，使网络传输减少。它不仅保证计算机正确快速地传输超文本文档，还确定传输文档中的哪一部分，以及哪部分内容首先显示(如文本先于图形)等。
HTTP是一个应用层协议，由请求和响应构成，是一个标准的客户端服务器模型。HTTP是一个无状态的协议。
2.2 请求响应结构图
2.3 工作流程
一次HTTP操作称为一个事务，其工作过程可分为四步：
1）首先客户端与服务器建立连接。
2）建立连接后，客户端发送一个请求给服务器。
3）服务器接到请求后，给予相应的响应信息。
4）客户端接收服务器所返回的信息通过浏览器显示在用户的显示屏上，然后客户端与服务器断开连接。
如果在以上过程中的某一步出现错误，那么产生错误的信息将返回到客户端，有显示屏输出。对于用户来说，这些过程是由HTTP自己完成的，用户只要用鼠标点击，等待信息显示就可以了。
2.4 主要特点
HTTP协议的主要特点可概括如下：
1.支持客户/服务器模式。
2.简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。
3.灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。
4.无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。
5.无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。
HTTP的报文并非是直接交付给用户去看的，最常见的场合是HTTP协议将超文本交付给浏览器或者其他超文本解析的软件来进行处理，超文本可以使用任意的标签语言如HTML，XSL，XML，XHTML。
2.5 http状态码简述
每发出一个http请求之后，都会有一个响应，http本身会有一个状态码，来标示这个请求是否成功，常见的状态码有以下几种：
1、200 2开头的都表示这个请求发送成功，最常见的就是200，就代表这个请求是ok的，服务器也返回了。
2、300 3开头的代表重定向，最常见的是302，把这个请求重定向到别的地方了，302重定向，相当电话呼叫转移
点击一个页面，跳转到另外一个页面
3、400 400代表客户端发送的请求有语法错误，401代表访问的页面没有授权，403表示没有权限访问这个页面，404代表没有这个页面，404路径不存在
4、500 5开头的代表服务器有异常，500代表服务器内部异常，504代表服务器端超时，没返回结果
2.6 cookie与session的区别：
1）Cookie将状态保存在客户端，Session将状态保存在服务器端；
2）Cookies是服务器在本地机器上存储的小段文本并随每一个请求发送至同一个服务器。Cookie最早在RFC2109中实现，后续RFC2965做了增强。网络服务器用HTTP头向客户端发送cookies，在客户终端，浏览器解析这些cookies并将它们保存为一个本地文件，它会自动将同一服务器的任何请求缚上这些cookies。Session并没有在HTTP的协议中定义；
3）Session是针对每一个用户的，变量的值保存在服务器上，用一个sessionID来区分是哪个用户session变量,这个值是通过用户的浏览器在访问的时候返回给服务器，当客户禁用cookie时，这个值也可能设置为由get来返回给服务器；
4）就安全性来说：当你访问一个使用session 的站点，同时在自己机子上建立一个cookie，建议在服务器端的SESSION机制更安全些.因为它不会任意读取客户存储的信息。
由以上比较，所以个人建议：
1.将登陆信息等重要信息存放为session
2.其他信息如果需要保留，可以放在cookie中
2.7 GET与POST方法的区别
1.一般来说，get是从服务器上获取数据，post是向服务器传送数据。
2. get是把参数数据队列加到提交表单的ACTION属性所指的URL中，值和表单内各个字段一一对应，在URL中可以看到。post是通过HTTP post机制，将表单内各个字段与其内容放置在HTML HEADER内一起传送到ACTION属性所指的URL地址。用户看不到这个过程。
3. 对于get方式，服务器端用Request.QueryString获取变量的值，对于post方式，服务器端用Request.Form获取提交的数据。
4. get传送的数据量较小，一般不能大于2KB。post传送的数据量较大，一般被默认为不受限制。但理论上，IIS4中最大量为80KB，IIS5中为100KB。（IIS是一种Web（网页）服务组件）
5. get安全性非常低，post安全性较高。但是执行效率却比Post方法好。
由以上比较，提供建议如下：
1、 get方式的安全性较Post方式要差些，包含机密信息的话，建议用Post数据提交方式
2、 在做数据查询时，建议用Get方式；而在做数据添加、修改或删除时，建议用Post方式；
3. 接口测试工具简述
3.1 jmeter工具
3.1.1 简介
Apache JMeter是100%纯JAVA桌面应用程序，被设计为用于测试客户端/服务端结构的软件(例如web应用程序)；能满足接口功能自动化、批量数据准备、性能测试等多重需求；当前业界最主流的接口测试工具之一，很多公司的接口自动化平台和性能测试平台都是基于其内核扩展的，不仅适合个人学习和使用，更适合规模化和团队化使用。
3.1.2 jmeter优势与缺点
优势:
- 开源，他是一款开源的免费软件，使用它你不需要支付任何费用
- 小巧，相比LR的庞大（最新LR12将近4GB），它非常小巧，不需要安装，但需要JDK环境，因为它是使用java开发的工具。
- 支持功能扩展开发。
- 学习成本比较低，容易上手。
- 验证功能时候，能够跳过前端页面数据限制，验证服务端对数据是否有限制等
缺点：
- 支持想协议没有loadrunner多，不过目前主流协议基本上都支持
- 压测的结果分析报表没有loadrunner详细丰富，不过一些主要的性能指标都支持生成展示了，比如TPS,QPS,吞吐量等
3.1.3 jmeter简单使用步骤
前置条件：因为jmeter是纯java语言编写的一款工具，所以运行此工具需要先配置好jdk，具体怎么配置此处不讲解，自己搜索一下配置步骤即可。
1.打开jmeter工具后，右击Test Plane(测试计划)，新建一个线程组（Thread Group），如下图所示（此步骤说明以中文形式界面，需要英文形式的请自行修改语言配置）
2.根据收集到的接口信息（此处以HTTP协议接口为例子讲解），右击线程组，新建个HTTP请求，并填写请求相关信息：
3.根据实际需要，增加配置文件。
右击线程组，添加HTTP请求默认值（假如一个线程组中所有接口的协议，ip和端口等数据是一样的，可以添加这个配置，然后线程组的那些接口请求就可以不用每个单独去写协议，ip，端口等数据了，因为它们默认使用了这个HTTP请求默认值配置中的数据）；
还可以增加CSV数据文件设置（给请求中的参数进行参数化的一个配置文件，具体如何配置请自行搜索，很简单，此处不做讲解）
HTTP信息头管理器（这个配置文件一般都必须添加的，在此配置文件对请求头信息进行配置）如下图所示：
4.新增监听器配置文件
可以右击线程组或右击HTTP请求新增查看结果树（察看结果树在HTTP请求下面，则只显示该请求的请求响应情况，在线程组下面，则显示整个线程组下所有HTTP请求响应结果）
还可以右击线程组新增聚合报告（用来查看压测结果的监听器）
也可以右击HTTP请求，添加保存响应文件（可以根据实际需要，保存请求失败的响应结构到指定文件中，压测完成后便于对失败请求进行分析查看）
5.添加响应断言
右击HTTP请求，添加响应断言（判断请求是否成功），便于查看请求是否成功以及统计压测过后的失败率。响应断言仅仅是判断响应中是否包含某字符串，至于其他断言可以根据实际需要进行选择。
6.其他常用插件简介
逻辑控制器：有时候脚本可能会比较复杂，这时候我们可以利用逻辑控制器，使脚本能够顺利开发出来。
脚本调试请求：
有时候我们开发脚本过程中，存在许多参数，我们要查看参数的取值是否按照我们希望的进行取值，这时候我们可以添加个Debug Sampler:请求，查看每个参数的取值情况。
其他的插件，建议根据实际开发过程中需要用到的时候再去自行查询用法，反正也是比较简单的，这里就不一一说明了。
3.2 badboy录制工具
有时候我们需要开发大量接口，这时候我们可以先利用badboy工具录制脚本，然后保存成.jmx文件，再把这个文件导入到jmeter中去，进行一定修改然后即可完成大量脚本的开发工作。
具体使用方法此处就不介绍了，相当简单，需要用到的时候自行查找教程就好了。