接口测试的一些感悟

Posted 2021-04-24 金阳光测试

接口测试的目的

这个算是老生常谈了，但我觉得只要聊到接口这个还是绕不过的，没有目标就没有评判标准，所以测试的目的还是很重要的。

先搬运一下（中文没找到，百度的就算了。。。）：

API testing is a type of software testing that involves testing application programming interfaces (APIs) directly and as part of integration testing to determine if they meet expectations for functionality, reliability, performance, and security.[1] Since APIs lack a GUI, API testing is performed at the message layer.[2] API testing is now considered critical for automating testing because APIs now serve as the primary interface to application logic and because GUI tests are difficult to maintain with the short release cycles and frequent changes commonly used with Agile software development and DevOps).[3][4]

翻译过来就是：

API 测试是一种作为集成测试的一部分，通过直接控制被测应用的接口（API）来确定是否在功能、可靠性、性能和安全方面达到预期的软件测试活动。[1]由于 API 都没有 GUI 界面，API 测试都是在通讯层进行的。[2]现在 API 测试在自动化测试中有着很重要的地位，因为 API 一般是应用逻辑的主要接口，同时 GUI 测试在敏捷开发和 DevOps 的快速迭代和频繁变更中很难维护。[3][4]

[1]:Testing APIs protects applications and reputations, by Amy Reichert, SearchSoftwareQuality March 2015
[2]:All About API Testing: An Interview with Jonathan Cooper, by Cameron Philipp-Edmonds, Stickyminds August 19, 2014
[3]:The Forrester Wave™ Evaluation Of Functional Test Automation (FTA) Is Out And It's All About Going Beyond GUI Testing, by Diego Lo Giudice, Forrester April 23, 2015
[4]:Produce Better Software by Using a Layered Testing Strategy, by Sean Kenefick, Gartner January 7, 2014

然后我目前在工作中 Leader 对我的预期：
发现尽可能多的问题。先说下背景，他是 app 端的主程，他对我做接口测试的期待是尽早发现接口的问题，减少他们 app 和服务端联调是发现的问题。他举了个例子，例如服务器返回一个 {"width":30, "url":""} ，那么有可能存在这个图片的实际宽度和 width 字段不一致。

和大东等曾经做过 API 测试的人的交流：
覆盖业务，包括业务正常/异常的情况

• 我一开始的理解：

发现问题，恩。那就是把文档里说的必须字段缺了试试，只有必须字段试试，必须字段用非法值试试。可选字段缺了试试，可选字段非法值试试。
结果就是：一个接口至少6个用例，甚至更多。而且很多时候不一定测得到业务（如接口只返回成功失败，但有可能实际上失败了但返回的是成功，需要调用其他接口验证）

• 目前的理解（估计还是有点走偏）：

结合业务设计用例。如有翻页参数，那就试试默认值、有效值、最后一页、最后一页+1、无效值。针对各个参数和业务场景去设计用例。

接口测试的实现

在这一点上我走了两条路：Jmeter 和纯 Java 代码。现在看来，两条都不是好路，所以就不分享了。这里主要说下 Testerhome 上最近出现的一些接口测试工具方面的帖子，简单汇总一下他们的实现方式：

序号	文章	主要采用技术	写用例的形式	预测写用例的速度	是否支持灵活的、编程语言级别的断言
1	By	核心基于 Spring RestTemplate ，主要有三个部分：Service 的描述，测试数据，客户端调用。由于各接口代码比较统一，能实现代码自动生成	Java 编写接口最基本的数据获取（testng的DataProvider）和收发请求代码，excel存储测试数据和预期结果	快（接口描述及用例的 Java 代码部分可以自动生成）	不支持，估计只支持字段级别的数据校验
2	By	采用 scala 编写，灵感来自百度内部的 SuperTest	录制成 har + api/dsl/csv 格式传递参数	快（基于录制，因此录制完毕后只需要修改参数和断言即可，不用花时间去写结构方面的东西）
3	By	Jmeter+Jenkins	Jmeter的图形化界面（支持录制）	较快（需要修改的地方略多）	支持（Assertion 通过插件支持 BeanShell、javascript 等语言进行断言）
4	By	GUI使用了jquery. 后端使用java做了公用方法进行解析，基于数据驱动	有通过json串解析输出结构的功能。GUI 上将收集的输入、输出数据以树型结构展现，通过简单的勾选来完成测试用例的输入参数及预期输出结构进行关联生成测试用例。	较快(对于接口基本信息采集有一定工作量)	不支持（支持规则验证、输入参数集合绑定等）
5	By	Jenkins + Svn + Maven+TestNG+ReportNG+(HttpClien+URLConnection)	excel 表格	快	不支持（支持关键字段检查）
6	By	Junit + HttpClient，定位更像 TestNG 这样的执行层框架	Java 代码	较慢(接口数据、接口断言等都需要自己写到用例中)	支持（本身就是 Java 语言）
7	我目前使用的方式（乱入。。。）	TestNG + ReportNG + OKHttpClient + Json 处理库（gson, jsonpath）	Java 代码	这不是预测，一天20条已是极限，平均每条用例需要写30行以上的代码	支持（本身就是 Java 语言）
8	我之前使用的方式：Jmeter	Jmeter	Jmeter 的图形化界面（支持录制）	一般（好吧，我还驾驭不了，或者说我的需求对 Jmeter 要求太高了，基本所有断言都要自己写 Javascript 来做）	支持（可通过 Javascript 语言进行断言）

到目前为止的做过的接口测试的总结

PS：通过 git 统计了一下我每天的代码量，大概在1000左右，但用例数还是每天15个左右。

可以看出，我的速度主要是慢在了代码量太大，时间都用在打代码上了，而且代码调试起来又会花一定的时间，所以效率自然低。所以如果优化写用例的方式，就算吐血也写不快了。接下来得总结一下那些地方可以抽取出来，用录制或者自动生成的方法来完成，把写用例精简成填表格或者纯填数据。

Updated

今天和 Monkey 以及公司另一位有做过 api 测试的同事交流了一下，发现了一个最根本的问题： 我的用例设计有问题

• 上传图片，服务器返回这些图片的 url

• 用上传图片接口上传图片，验证图片是否上传成功，各 url 对应文件的 md5 是否和我本地上传的图片的 md5 吻合。

• 用发本地圈接口发本地圈，其中图片 url 来自第一步的返回值

• 用查看本地圈接口查看发出的本地圈，检查它的内容、图片是否正确。

咋看之下好像没啥问题（相信做过 api 测试的童鞋已经看出问题了），但其实这个用例本身存在一个严重的问题： 接口成为了手段，验证点其实是功能。

我交流后得到的 api 测试用例主要应该有两类：

1. 单一接口测试。调用一个接口就是一个用例

2. 多接口的业务测试。会调用多个接口，且接口之间可能存在数据传递。

1. 有图片、有文字，预期返回发布成功

2. 无图片，有文字，预期返回发布成功

3. 有图片，无文字，预期返回发布成功

4. 无图片，无文字，预期返回发布失败

5. 有图片、有文子，预期返回发布成功，同时数据库中的记录符合预期

每一个用例测试一个点，发布成功这个返回值是否正确由一个单独的用例来覆盖就足够了。

用例确定了，那么可以看出接口测试其实有很多可以重用的点。接口测试的本质是通过测试参数的排列组合验证返回值/数据库变更是否符合预期，从而确定接口相关代码是否正确。从业务角度考虑的意思是这些排列组合不是随便想出来，而是业务中有可能出现的排列组合。

这也是为什么不少接口测试用例采用 excel 表格来编写，因为参数的排列组合用表格呈现是最简单快捷的。

还有一个例子说明用例越简练越好。

例如列表接口有个翻页的功能。它有一个入参：lastTopicId ，返回值里有一个 isMore 的字段。lastTopicId 表示从哪个 topic 开始显示， isMore 表示是否存在下一页（1为有，0为无）。

针对这个接口的其中一个用例，需要验证 isMore 字段在最后一页时是否为0。我一开始的思路是像功能那样，不断翻页，直到达到一个很大的页数或者到达 isMore 为 0 的情况。由于页数不确定，因此就算这个很大的页数设得非常大也没有十足的把握绝对不会超出这个页数。所以思路本身有问题。

和 Monkey 和我的同事交流后，他指出正确的思路应该是：

1. 通过一个可信的途径（从服务器数据库直接计算，或者有一个端口告诉你最有一页的 lastTopicId 是什么），用一个步骤知道怎么一次性去到最后一页。

2. 直接去到最后一页

3. 验证 isMore 参数值

有些东西开发可以很方便地给到我们，那么我们没有必要那么艰难地自己去计算出来，而是直接让开发增加一个接口让我们能直接获取到数据就好。让接口测试做得更好，开发的协助是分不开的。

做好接口测试并不像之前想象得那么简单，但也没有刚开始的时候做得那么艰难。不管怎样，既然开始了，那就要想办法把它做好。接下来我会使用新的设计用例思路做剩下的接口测试用例，并修改 Java 代码让其支持使用 excel 作为用例。感悟中如果有不对的地方，欢迎大家及时提出。

特别感谢 Monkey，testly，大东等给过我意见和建议的人。