http接口测试资料整理系列1--概念简介

http接口测试相关介绍

常见的几种测试模式

功能测试：

编写测试用例（测试用例当中最主要的是测试步骤和预期结果）—-》测试人员根据测试用例执行操作步骤—–》然后通过眼睛和思考判断实际结果与预期结果是否相等（如果相等，测试通过；如果不相等，测试失败）

自动化测试：

自动化测试要做的事情与功能测试是一致。这里的自动化主要包含三个层面的自动化，单元测试自动化，接口测试自动化和web测试自动化。当然，不同层面的自动化关注点是不一样的

单元测试自动化：

调用被测试的类或方法，根据类或方法的参数，传入相应的数据。然后，得到一个返回结果。最终断言返回的结果是否等于预期结果。如果相等，测试通过；如果不相等，测试失败。所以，这里单元测试关注的是代码的实现与逻辑。

接口测试自动化：

根据接口文档，到底是传get请求呢？还是post请呢？调用被测试的接口，构造相应的数据（id=1,name=zhangsan），得到返回值，是200成功，并返回查询结果。还是10021，用户名不能为空。不管输入的参数是怎样的，我们都将得到一个结果。最终断言返回的结果是否等于预期结果。如果相等，测试通过；如果不相等，测试失败。所以，接口测试关注的是数据。只要数据正确了，功能就做成大半，剩下的无非是如何把这些数据展示在页面上。

web测试的自动化（UI自动化）：

这种测试更贴近用户的行为，模拟用户点击了某个按钮，向个输入框里输入了什么。但是用户可以看到登录成功了，但web自动化并不知道它刚才的点击有没有生效。所以，要找“证据”，比如，登录成功后页面右上角会显示“欢迎，xxx”。这就是登录成功的有力“证据”。于是，当web自动化登录成功后，就去获取这个数据进行断言。断言如果相等，测试通过；如果不相等，测试失败。所以，web自动化的关注点用户操作形为，页面上真正的按钮和输入框是否可用。

各种测试的区别：

本质上没啥区别，唯一的区别是，一个由人来执行，一个由代码或工具执行

什么是接口测试？为什么要做接口测试？（注意接口测试的重点是接口交互数据的准确性，不是测试功能）

接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。
　　接口测试适用于为其他系统提供服务的底层框架系统和中心服务系统，主要测试这些系统对外部提供的接口，验证其正确性和稳定性。接口测试同样适用于一个上层系统中的服务层接口，越往上层，其测试的难度越大。
　　接口测试实施在多系统多平台的构架下，有着极为高效的成本收益比，接口测试天生为高复杂性的平台带来高效的缺陷监测和质量监督能力。平台越复杂，系统越庞大，接口测试的效果越明显。
　　基于接口测试的重要性，以及它比较容易自动化的特性，通过持续集成的接口监控能够及时的发现项目中存在的问题，这对持续运营的项目来说，非常重要

接口测试的流程

1、项目启动后，测试人员要尽早找到开发人员拿到接口测试文档
　　2、获取接口测试文档后，就可以进行接口用例的编写和调试
　　3、接口用例编写调试完成后，部署到持续集成的测试环境中，
　　4、设定脚本运行频率，告警方式等基本参数，进行接口的日常监控
　　5、每日进行接口脚本的维护更新，接口异常的处理

接口测试的用例设计

假设我要验证发表朋友圈的 接口，它的工作流程如下：

• 上传图片，服务器返回这些图片的 url
• 发表朋友圈，包含朋友圈文字内容和各个图片 url 两个主要字段。服务器只会返回是否成功以及这条朋友圈的 id

我设计的正常发朋友圈的用例如下：

• 用上传图片接口上传图片，验证图片是否上传成功，各 url 对应文件的 md5 是否和我本地上传的图片的 md5 吻合。
• 用发本地圈接口发本地圈，其中图片 url 来自第一步的返回值
• 用查看本地圈接口查看发出的本地圈，检查它的内容、图片是否正确.

咋看之下好像没啥问题（相信做过 api 测试的童鞋已经看出问题了），但其实这个用例本身存在一个严重的问题： 接口成为了手段，验证点其实是功能。
我交流后得到的 api 测试用例主要应该有两类：
1.单一接口测试。调用一个接口就是一个用例
2.多接口的业务测试。会调用多个接口，且接口之间可能存在数据传递。api 测试最简单，并且每个接口都应该至少有一个的用例应该就是使用 默认参数调用 单个接口。重点在这里：单个。像我上面这样的用例已经不是验证发朋友圈的接口了，而是验证 发朋友圈的功能。

那么发朋友圈的接口应该有什么用例呢？我按照现在的测试接口的思路重新想了一下，主要有这几个：
1.有图片、有文字，预期返回发布成功
2.无图片，有文字，预期返回发布成功
3.有图片，无文字，预期返回发布成功
4.无图片，无文字，预期返回发布失败
5.有图片、有文子，预期返回发布成功，同时数据库中的记录符合预期
每一个用例测试一个点，发布成功这个返回值是否正确由一个单独的用例来覆盖就足够了。

开源框架那么多，为什么还要自己码代码造轮子

好处：
1）可解决一些不常用的body格式数据的解析
2）对于多接口关联的处理比使用工具更方便
3）可方便的使用第三方库，如数据加密处理等
4）维护起来更方便，但初期用例编写时间相对较长
5）将代码稍作修改即可用于稳定性、性能测试及测试环境准备