小道消息听陈磊老师说接口测试（上篇）

兔子🐰 for 一起听播客 · 2022年07月14日 · 最后由 halu 回复于 2024年06月20日 · 4996 次阅读

本期嘉宾：陈磊，前京东测试架构师，阿里云 MVP、华为云 MVP，中国商业联合会互联网应用工作委员会智库专家，中关村智联软件服务业质量创新联盟软件测试标准化技术委员会委员，Asian Journal of Physical Education & Computer Science in Sports 编委会委员。图书《接口测试方法论》和《京东质量团队转型实践从测试到测试开发的蜕变》作者，极客时间专栏《接口测试入门课》作者，拉勾教育专栏《软件测试第一课》作者《测试敏捷化白皮书》编委。

本文是根据嘉宾的分享，精简和提炼出的文字版本。点击收听完整音频分享：https://m.ximalaya.com/sound/551575080
本周日（7 月 17 日）晚 8 点艾辉老师返场，一起来的还有另一位老朋友，戳此链接了解详情。

嘉宾寄语

接口测试有点儿像袍丁解牛，在这个方向做多了以后就会发现：接口测试是一个很大的方法论，并不只是测一个接口那么简单；它可以被拆解成一个个小部分和一个个细分的关键技术，每一个关键技术精益求精后又是一个新方向。

01 接口测试最早可以在什么阶段就介入？

首我们先说测试最早在什么阶段能够介入（软件开发流程），再来说接口测试。无论是瀑布流，还是敏捷的开发模式，我们一直提倡测试要在需求阶段就发挥作用。怎么发挥作用呢？以敏捷开发来说，会有故事卡，然后把故事卡拆分成多个开发任务。在故事卡拆分的子任务进入研发（简称开发）前，开发工程师会给产品经历和测试工程师讲述自己对需求的理解，测试同学此时就可以站在自己对系统横向理解的基础上，指出某个故事卡下验收条件的缺失或者需求的丢失。在补齐缺失的内容后，测试同学就可以询问前后端开发同学，了解本次需求开发是否涉及前后端接口的变动，此时就可以引入接口测试了。

也就是说，接口测试最早可以在需求确认后、正式进入开发前就开始。要实现这一点，需要一些先决条件，比如：团队中的开发同学对系统代码非常熟悉，团队中没有追责甩锅或者将 bug 数量纳入 KPI 考核等情况。

大家可能会觉得有点不理解，在需求确认后、进入开发前，连接口文档都没有，怎么进行接口测试？如果团队中的开发对系统和代码非常熟系，在开卡时，他们就已经知道这次功能开发可能涉及的老接口变动，以及新增接口怎样描述。开发可以提供 scamper，我们根据这个进行接口测试用例的编写。

02 功能测试能否省略接口测试已经覆盖的方面？

这个话题，可以从自动化测试模型说起。自动化测试的分层模型——金字塔型——最下面是单元测试，往上一层是接口测试，最上一层是 UI 自动化。自下而上发现的问题，修复成本越来越高，离真实业务场景也越来越近。每一层的测试范围都有一定的差异性和侧重点。而随着软件行业的发展，单元测试的比例在减少，接口测试的比重在增加。接口测试又细分为单接口测试和多接口测试：单接口测试可以弥补单测的不足，多接口测试可以覆盖一定的业务逻辑。UI 自动化是串联整个比较主要的业务流程，也叫黄金业务流程。

就质量特性的检测范围来说，接口测试和 UI 自动化测试其实都隶属于功能测试，是针对功能性而实施的质量保障的行为，与之相对的还有安全测试、性能测试等。所以接口测试和功能测试只是范围不同，但可以说是同一件事。

在针对系统功能的测试方面，接口测试有可能和手工测试有很多的重叠，所以比较推荐的方式是：在做接口测试时，尽最大的可能测试所有的入参，保证我们所设计的每一条 case 都是一个完善的 case（要能够检测每一种可能出现的输入情况）；把多个接口串到一起，进行一些业务场景的模拟，并且覆盖到正确和异常的业务。要达到上述效果，推荐大家使用边界值、等价类、因果图和场景法这些测试用例设计方法。

03 接口测试用例的设计方法

IEEE 610 中关于测试用例的定义：测试用例应该包含测试的执行条件，测试输入的过程，还有预期结果。对于接口测试来说，要访问的接口 URL、要访问的服务的路由就是执行条件；要采用怎样的参数调用，参数都如何取值，这些是输入；不同入参调用接口所产生的不同结果就是我们的预期。所以接口测试还是测试用例的一种技术的继承，并没有重新定义测试用例，或者是让它变另外一种方式，只是实践手段不同了。

针对单接口测试：

比较推荐大家用尽可能全面的测试输入进行检测，在测试入参的设计上，推荐大家使用边界值加等价类的方法。测试用例的设计方法是可以嵌套使用的，并不是用了等价类就不能用边界值，用了边界值就不能用因果图。但是测试用例的设计方法也是有专攻的，没有一个测用例设计方法可以被当做银弹，在不同的地方套用。

了解代码里如何实现业务逻辑分支，是通过测试的条件覆盖去验证每一条业务逻辑。也就是说，如果我们设计的入参能覆盖每一个条件分支，那就可以覆盖更多的接口返回。要做到这一点，有一种接近极致的方法：正交实验，来覆盖到更全面的接口测试，把单接口测试做得更为完善。

针对业务接口测试：

即根据业务场景，把多个接口串到一起。
我个人比较推崇使用场景法来做，因为这时候我们更希望站在真正业务方的角度来考虑，设想用户进行真实的软件操作时会产生怎样的接口调用，来覆盖业务逻辑分支。

接口测试断言：

推荐大家至少用两个断言：第一个断言是判断业务逻辑是正确，第二个断言是判断服务是否正确。并且我更推荐把第二个断言放到前面，因为我们要先知道这个服务是对的，再进行逻辑对错的判断。比如，倘若返回服务已经死了，就不用再去做后面的逻辑判断了。断言和测试预期都不是随便设计的，希望大家在设计预期的时候体现层次，每一个断言失效的时候，能够通过失效的断言就知道可能存在怎样的问题。

在软件开发中，返工是最大的浪费。如果说本来不是一个 bug 却被提到缺陷系统中，经历缺陷的生命周期，需要不同人付出时间进行排查，就是浪费大家的时间和精力。所以我们更期望在确定是 bug 后再计入缺陷系统，即先做是否误报的判断。现在有一种新方向，缺陷的自动提交和和误报缺陷自动过滤，已经逐渐在不同的框架里被开发出来进行应用。能够提高所有人的效率，减少更大的浪费。

04 相比于 UI 自动化和压测，接口测试更加 “新手友好”？

我个人觉得测试是一个技术岗，测试工程师也应该懂代码，否则在当下就业市场会很吃亏。大家随便在招聘网站上找一个测试岗位看一下就明白。而对于这三个专项的难易程度，应该跟每个人的实际情况有关。

说压测难，是难在工作中接触的少、实践机会少。因为有可能很多个迭代才做一次压力测试，也就是十天半个月，甚至是一季度半年才做一次。并不是说压测本身在技术上有多难。

而对于接口测试和 UI 自动化，从代码和实践的角度来说差别不大，接口测试的实践机会相对更多。大家不用太纠结接口测试和 UI 自动化到底该学哪个，工作中能接触到哪个就可以选哪个。而且关键是要真的上手去做。如果你已经掌握了一门编程语言，那就用这门语言来写接口测试或者 UI 自动化小工具。如果你编码能力比较弱，做不到马上上手开发，那至少也可以通过 Postman 的代码导出功能，先导出现有的接口测试的代码进行学习。或者暂时什么编程语言都不会，那就选一门编程语言进行学习，特别是团队中流行的语言。做为测试，我们身边总会有一群相对更懂代码的开发同学，不用 “害羞” 多向他们请教。