接口测试浅谈

什么是接口

    API（Application Programming Interface，简称：API），又称为应用编程接口，就是软件系统不同组成部分衔接的约定。由于近年来软件的规模日益庞大，常常需要把复杂的系统划分成小的组成部分，编程接口的设计十分重要。程序设计的实践中，编程接口的设计首先要使软件系统的职责得到合理划分。良好的接口设计可以降低系统各部分的相互依赖，提高组成单元的内聚性，降低组成单元间的耦合程度，从而提高系统的可维护性和扩展性。
　　接口也可以看做程序/资源/组件的集成点。它的功能会跟UI有些类似，通过某些特定指令、参数等可以让后台的一堆代码运行起来，最后得到想要的结果。不同的是它不提供可视的按钮文本框之类的界面，而通常是由一个直接和底层代码打交道的链接构成。实现了两个或多个独立系统/模块间的通信和数据交换能力。

什么是接口测试

    接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点联系，测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。
　　接口测试就是通过测试不同情况下传参和响应信息来判断接口是否满足相应的功能正确性、稳定性、安全性要求。接口的性能和[安全性](javascript:;)根据测试策略的不同，会是一个可选测试项。这个可以作为两个单独的问题来讨论。
　　接口测试好处：发现很多页面上发现不了的错误、检查系统的异常处理能力、检查系统的安全性和稳定性，前端随便变，不会影响接口测试的执行。
　　接口测试不同于UI自动化测试，其主要关注在系统的业务逻辑层，所以其主要关注不在于UI操作和用户感观上，更关注调用逻辑关系。
　　接口测试是一个完整的体系，也包括功能测试、性能测试、安全测试。平台越复杂，系统越庞大，接口测试的效果越明显。

为什么要做接口测试

1、测试金字塔
在讨论这个话题之前，我们先来回顾下测试金字塔；

image.png

    如图所示，简单来讲就是说越往上层走的测试，需要投入的成本会越高，而且会越难以维护。在这个结构下，因为UT已经覆盖了绝大部分的代码，所以其上层的集成/接口测试和UI测试可以去除重复测试的部分，从而量也会越来越少，并且会有不错的覆盖率。
　　所以理想中的自动化测试结构应该是大量的UT+适量的集成测试(或者接口测试)+少量的UI测试。

2、为什么要做接口测试

    如今系统越来越复杂，传统的靠前端测试已经大大降低了效率，而且现在我们都推崇测试左移，希望测试能更早的介入测试，那接口测试就是一种尽早介入的方式。例如传统测试，你是不是得等前后端都完成你才能进行测试，才能进行自动化代码编写。而如果是接口测试，只需要前后端定义好接口，那这时自动化就可以介入编写接口[自动化测试](javascript:;)代码，接口测试只需要后端代码完成就可以介入测试后端逻辑而不用等待前端工作完成。
　　现在很多系统前后端架构是分离的，从安全层面来说，只依赖前端进行限制已经完全不能满足系统的安全要求（绕过前端太容易了），需要后端同样进行控制，在这种情况下就需要从接口层面进行验证。前后端传输、日志打印等信息是否加密传输也是需要验证的，特别是涉及到用户的隐私信息，如身份证，银行卡等。
　　接口测试相对容易实现自动化，也容易实现持续集成，且相对UI自动化也比较稳定，可以减少人工回归测试人力与时间成本，缩短测试周期，支持后端快速发版需求。

接口测试准备工作

    首先你得获取目标测试系统的相关接口文档，例如接口对应的参数格式、期望返回结果等（一由开发提供文档，二自己抓包分析。）
　　接口在设计时往往需要编写大量的文档，而且随着接口版本的迭代，接口文档需要同步更新，文档编写维护也是一个很大的工作量。所以在大部分情况下，很多开发甚至都不去编写接口文档，项目小还好办，当项目大了，需要对接的地方多了，就会很麻烦。特别是接口数量多，参数复杂的情况，测试工作量大。接口在版本迭代后，旧的接口常常需要做回归测试，这个工作量也是非常大的。所以作为测试人员，你应该具备以下技能：
Ø 优先去推动开发生成一份合适的接口说明文档；
Ø 掌握抓包技能，能够自己去抓包分析形成接口测试用例；
Ø 至少把http协议掌握，了解其报文结构；
Ø 对用户业务熟悉，能把接口业务逻辑和用户业务结合起来；

接口测试策略

image.png

通用接口测试用例设计

1、通过性验证
首先肯定要保证这个接口功能是好使的，也就是正常的通过性测试，按照接口文档上的参数，正常传入，是否可以返回正确的结果。
2、参数组合
现在有一个操作商品的接口，有个字段type，传1的时候代表修改商品，商品id、商品名称、价格有一个是必传的，type传2的时候是删除商品，商品id是必传的，这样的，就要测参数组合了，type传1的时候，只传商品名称能不能修改成功，id、名称、价格都传的时候能不能修改成功。
3、接口安全
① 绕过验证，比如说购买了一个商品，它的价格是300元，那我在提交订单时候，我把这个商品的价格改成3元，后端有没有做验证，更狠点，我把钱改成-3，是不是我的余额还要增加？
② 绕过身份授权，比如说修改商品信息接口，那必须得是卖家才能修改，那我传一个普通用户，能不能修改成功，我传一个其他的卖家能不能修改成功
③ 参数是否加密，比如说我登陆的接口，用户名和密码是不是加密，如果不加密的话，别人拦截到你的请求，就能获取到你的信息了，如果有加密，那加密规则是否容易破解。
④ 密码安全规则，密码的复杂程度校验；
4、异常验证
异常的，也就是我不按照你接口文档上的要求输入参数，来验证接口对异常情况的校验。比如说必填的参数不填，输入整数类型的，传入字符串类型，长度是10的，传11，总之就是你说怎么来，我就不怎么来，其实也就这三种，必传非必传、参数类型、入参长度。
5、根据业务逻辑来设计测试用例
根据业务逻辑来设计的话，就是根据自己系统的业务来设计用例，其实这也和功能测试设计用例是一样的。 举个例子，拿bbs来说，bbs的需求是这样的：
① 登录失败5次，就需要等待15分钟之后再登录
② 新注册的用户需要过了实习期才能发帖
③ 删除帖子扣除积分
④ ……
像这样的你就要把这些测试点列出来，然后再去造数据测试对应的测试点。

接口测试用例模板

接口测试用例模板，一般有哪些字段呢？
① 用例编号
② 模块 这个接口是属于哪个功能模块的
③ 项目 是哪个项目的
④ 接口名称
⑤ 用例标题 用例是干嘛的
⑥ 请求方式 GET/POST
⑦ 请求url url地址
⑧ 请求参数
⑨ 前置条件 有依赖的时候，比如说要测登录失败3次的
⑩ 结果验证 预期结果
⑪ 请求报文
⑫ 返回报文
⑬ 测试结果 通过/失败
⑭ 测试人员

接口测试常用工具

image.png

1、JMeter
JMeter是Apache组织开发的基于Java的压力测试工具，能够将请求转换为脚本来实现，并允许使用正则表达式创建断言来对请求返回结果进行判断，具备接口测试功能和性能的能力。
2、SOAPUI
SoapUI是一个完整的自动化测试解决方案。支持SOAP和REST的Web服务，JMS企业消息层，数据库，丰富的互联网应用等等。而在SoapUI，你从它的直观和强大的用户界面这一切。对于自动化程度较高，SoapUI还提供了命令行工具，让您运行的功能/负载测试和几乎所有的任务调度程序，或作为您的构建过程中的一个组成部分MockServices集。
3、PostMan
Postman是一款功能强大的网页调试与发送网页HTTP请求的Chrome插件，具备Fiddler\httpwatch之类的工具调试请求的功能，同时具备接口管理功能，官网提升脚本保存同步功能，支持接口导入导出

接口测试持续集成

对接口测试而言，持续集成自动化是核心内容，通过持续自动化的手段我们才能做到低成本高收益。如果使用JMeter、SoapUI工具做自动化测试，工具本身支持命令行模式运行，可以结合Jenkins等自动化平台，实现项目版本更新后的自动化回归测试，加速异常反馈，创建强有力的质量体系。
加强自动化的程度，包括但不限于下面的内容：
a) 流程方面：在回归阶段加强接口异常场景的覆盖度，并逐步向系统测试，冒烟测试阶段延伸，最终达到全流程自动化测试。
b) 结果展示：更加丰富的结果展示、趋势分析，质量统计分析等。
c) 问题定位：报错信息、日志更精准，方便问题复现与定位。
d) 结果校验：加强自动化校验能力，如数据库信息校验。
e) 代码覆盖率：不断尝试由目前的黑盒向白盒下探，提高代码覆盖率。
f) 性能需求：完善性能测试体系，通过自动化的手段监控接口性能指标是否正常。

接口测试自动化需要的功能

1、 校验（断言）
这个很好了解，如果没有校验，单纯的执行接口的话，那就谈不上测试了。所以支持对返回值校验是一个必须的功能。除请求响应状态的判断外，还需要对核心内容的正常性做判断（判断内容可与数据库内容匹配等方式，不建议用写死的内容）。
2、 数据隔离
测试脚本和测试数据最好可以分开，这样的话可以复用测试脚本，用不同的测试数据输入去获取不同的期望结果。数据隔离也便于后续维护，一旦需要调整接口用例、新增接口用例时可快速的找到位置，隔离的另一个好处就是可复用，框架可以推广给其他团队，使用者可以使用相同的代码，只需要根据要求填写各自用例即可测试起来。
3、数据传递
接口测试脚本开发时要注意参数取值的可用性，不因时间或数据状态的变化引起脚本不能正常运行，降低脚本维护成本。数据传递是指接口用例之间可以做到向下传参，例如我们通过创建订单接口创建一个订单，该接口会返回一个订单号，接下来我们要进行调用查询订单的接口，从返回的数据中与创建订单用例中的数据进行校验，此时第二个接口的请求数据是需要从第一个接口用例中的返回中提取的。这样的例子比比皆是，所以支持数据传递是又一个必不可少的功能。
4、动态函数
实际用例场景中我们可能会有随机生成一个手机号、字符串加密等需求，在数据与代码隔离之后，此时我们就需要代码可以支持做到识别对应关键字时可以执行对应的函数进行填充。例如在数据中填写${phone}时，具体执行时会被替换成137********，填写 $${__Random(9999,99999,)}时，会被替换成一个五位的随机数等等。
5、可配置
有时我们的需求是用例不单单只能在一个环境上执行，可能需要同一份接口用例可以在dev、sit、uat、生产等多个环境都可以执行。所以框架需要做到可配置，便于切换，调用不同的配置文件可以在不同的环境执行。
6、日志
日志包含具体执行接口、请求方式、请求参数、返回值、校验、请求耗时等关键信息，日志的好处一来是可以便于在有问题时快速定位问题所在，二来是发现bug时方便向开发反馈提供数据，开发可以从触发时间以及参数等信息快速定位到问题所在。
7、可视化报告
最后就是输出测试报告了，一个好的可视化的报告可以帮助你轻松定位到出错的地方，使修复问题更加顺畅。持续性能测试，还需要做好相关的监控、性能指标的分析自动化，减少人工操作。