接口测试 理论贴:谈谈 API 功能测试

大大灰灰狼 · 2016年07月11日 · 最后由 chris 回复于 2017年05月16日 · 236 次阅读

什么是 API 测试

什么是 API

关于定义什么的,直接维基可得:

API(Application Programming Interface,简称:API),又称为应用编程接口,就是软件系统不同组成部分衔接的约定。由于近年来软件的规模日益庞大,常常需要把复杂的系统划分成小的组成部分,编程接口的设计十分重要。程序设计的实践中,编程接口的设计首先要使软件系统的职责得到合理划分。良好的接口设计可以降低系统各部分的相互依赖,提高组成单元的内聚性,降低组成单元间的耦合程度,从而提高系统的维护性和扩展性。

换句话说,API 也可以看做程序/资源/组件的集成点。它的功能会跟 UI 有些类似,通过某些特定指令、参数等可以让后台的一堆代码运行起来,最后得到想要的结果。不同的是它不提供可视的按钮文本框之类的界面,而通常是由一个直接和底层代码打交道的链接构成。

什么是 API 功能测试

API 测试是针对系统所提供的 API 做各方面的验证。API 的性能和安全测试根据测试策略的不同,会是一个可选测试项。这个可以作为两个单独的问题来讨论。

API 的功能测试类似于 UI 功能测试,都是在已知输入内容和期望结果的前提下,使用这个功能/调用这个 API 并且验证是否能返回期望的结果。不同的是 API 测试在返回结果被呈现给客户前就完成了,从而对测试环境的依赖会比较小。

为什么要做 API 功能测试

测试金字塔

在讨论这个话题之前,我们先来回顾下测试金字塔:
[TestPyramid](http://martinfowler.com/bliki/TestPyramid.html)
如图所示。简单来讲就是说越往上层走的测试,需要投入的成本会越高,而且会越难以维护。在这个结构下,因为 UT 已经覆盖了绝大部分的代码,所以其上层的集成/API 测试和 UI 测试可以去除重复测试的部分,从而量也会越来越少,并且会有不错的覆盖率。

所以理想中的自动化测试结构应该是大量的 UT+ 适量的集成测试 (或者 API 测试)+ 少量的 UI 测试。

构建 API 测试的价值

测试覆盖率。UT 关注点是各个单元是否能够完成期望工作,只覆盖一个单元内部工作情况;集成/API 测试关注点是各个模块/单元之间协同工作,它所覆盖的场景也会比单元测试更多。而 UI 测试会更加关注 e2e,模拟用户行为,在所有的程序依赖环境准备完成后再进行操作。相比之下 API 测试不依赖环境,测试成本会比 UI 测试更低,而且覆盖率比 UT 更高。

快速反馈。API 测试速度比 UI 测试更快 (因为无需界面加载/响应),短时间内能跑很多用例。API 测试也能精确的揭露是软件中哪个组件除了问题,如果把你的 API 测试放到 CI 里面,一旦代码修改破坏了现有的功能,就能够快速反馈到团队中。还可以把测试中发现的 BUG 也写到 API 测试里面,让测试成为一堵墙,从而能更好的能保证产品质量。

可复用。API 测试由于不需要浏览器、GUI 等环境,所以可以更加灵活的在各个环境中复用。例如你可以在产品环境中、测试环境、研发环境中使用,你需要做的只是修改下测试数据而已。另外如果是在 TDD 模式下工作的话,API 测试可能会在产品完成前就写完了,后续的工作也会减少很多。

怎么做 API 功能测试 #

API 功能测试的主要手段是使用工具/软件调用待测 API,然后验证是否返回期望的 output。这个 output 通常可能是:

  • 返回成功或者失败的 status
  • 是一段数据或者 information
  • 或者是跳转到其他 API

工具
市面上常见的 API 测试工具我知道的可以分成几大类:

  1. 开源纯代码类,比如基于 nodeJS 的 supertest,基于 Java 的 rest-assured 等,这类工具易于学习,易于和 CI 集成,但是需要使用者有一定的编码能力。
  2. 商用工具,比如 SoapUI,功能强大操作简单,还提供免费社区办可以试用。
  3. 各类插件工具,比如 Chrome 插件 Postman,也有收费版可以玩儿。

工具的选择见仁见智,根据不同的环境选择不同的工具。

测试
在正式开始测试之前,你得先搞清楚几个问题:

  • 待测 API 的目的是什么,谁是使用者
  • 待测 API 会在什么环境下使用
  • 待测 API 在异常环境下会不会有非期望响应
  • 这个测试需要测什么功能点
  • 各个功能点的测试优先级
  • 如何定义期望返回的结果是成功还是失败
  • 待测 API 会不会和其他系统有交互 (修改代码后影响其他系统)

这些问题会影响到你的测试结果是否符合客户需求,或者说这些潜在的风险会影响到这个项目是否成功。

如果你选的是必须得自己写点儿代码的工具,那么接下来得根据选择的工具和项目代码,去 setup 测试环境,让工具能够成功跑起来。

接着是设计你的测试框架,最好是要满足可复用性强,高内聚低内聚什么的原则,记得要有输出测试报告的模块。

然后是用例,上面你已经想好了需要测哪些功能点,针对这些点我们用脑图之类的工具把需要测试的场景记录下来。

最后就是脚本设计和测试数据设计,脚本和数据最好可以分开,这样的话可以复用测试脚本,用不同的测试数据输入去获取不同的期望结果。

验证的过程大致包含下面这些:

  1. 检查 API 是不是根据你输入的数据返回期望的结果
  2. 验证 API 是不是不返回结果或者返回异常结果
  3. 验证 API 是不是正确触发其他 event 或者正确调了其他 API
  4. 验证 API 是不是正确更新了数据等等

完了就是输出测试报告了,好的测试报告可以帮助你轻松定位到出错的地方,使修复流程更加顺畅。

最后的最后,强烈推荐把测试集成到 CI 中去,加速异常反馈,创建墙有力的质量体系。

个人理解,望高人指点。

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 8 条回复 时间 点赞

talk is cheap show me the code

#1 楼 @seveniruby 就知道这种帖子发到这里会被各种吐槽..选工具的code..

#2 楼 @xuxtc 主要是这类内容太理论,有点人人都知道,但没什么卵用的感觉。如果不想纯 show code 的话,建议把自己对上述理论的思考,或者自己实践过程发现的问题和痛点以及解决方法写上来,这才是最有参考价值的。

顶:talk is cheap show me the code

#2 楼 @xuxtc 你前面提到了 4 个验证 api 的关键, 这儿就适合用 code 来表达. 用你们现成的框架做个演示就行了 测试用例如何组织, 结果是什么样子, 应该给个截图. 这样就是精华帖的样子了.

#5 楼 @seveniruby 明白了,下次注意~

最近也在自己开展做接口测试,工具大概用法还是懂,但是一到如何验证这块就懵逼了

验证的过程大致包含下面这些:
检查 API 是不是根据你输入的数据返回期望的结果
验证 API 是不是不返回结果或者返回异常结果
验证 API 是不是正确触发其他 event 或者正确调了其他 API
验证 API 是不是正确更新了数据等等

我看到这里,我表示笑了。都以为这样就是接口测试,接口测试就是通过报文的返回来判断功能是否正常。然后底下回复的也没人觉得这样的想法的错误有多危险和可怕。

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册