这是一个创建于 601 天前的主题，其中的信息可能已经有所发展或是发生改变。
引言
从《 Google 软件测试之道》到后来的敏捷开发、DevOps ，10 多年了，接口自动化测试一直是测试领域必谈的重点。各种自动化测试工具（ Postman 类）、自动化测试框架、自动化测试平台层出不穷，每个公司/部门甚至每个团队都有一套直接的自动化解决方案。但盲目投入后，反而会感觉越来越鸡肋，食之无用弃之可惜。
接口自动化的价值
不管你是 B/S 还是 C/S 架构，APP 还是小程序，还是什么协议，总体来说是由 GUI 和服务端 API 组成。通常一个迭代是 PM 需求、RD 开发/联调、QA 单功能测试、bugfix(穿插多轮)、合码 QA 集成/回归测试、发版。在这一套模式下，大家常说的接口自动化测试（暂不考虑 UI 自动化）的价值如下：
提高测试效率/降低人力成本？
因为自动化测试执行很快，所以引入接口自动化测试能提高测试效率。但有个很现实的问题，接口自动化只覆盖了服务端 API ，GUI 这部分也有很多逻辑，RD 也是有大量工作量投入的，这部分的测试是少不了的。即使是偏服务端 API 的功能，你的手工 GUI 测试替代率是多少？接口自动化执行完了能不需要手工测试吗？这恐怕不敢打包票吧。所以对于一个端到端的测试团队，反而接口自动化 case 的编写和维护成了额外的负担。
降低人力成本也是无稽之谈，因为你手工 GUI 测试的成本并没有降下来，反而需要投入写接口自动化的人力。除非你之前就有一批人是使用 Curl 测接口的。
提高测试覆盖率？
这个理论上有道理，一些接口参数分支，UI 上无法走到，通过接口则可以直接覆盖到，提升了覆盖率，后面 UI 上增加了此分支能保证基本的质量，提升迭代效率。但事实上产品变化很快，还没等覆盖到新参数分支，需求又变了，接口甚至都得重写一遍。掉入了过早优化的陷阱。
持续集成和持续交付（ CICD ）！
互联网大部分开发模式都是迭代开发、小步快跑。接口开发完成后还没到测试环节，这时候跑一遍自动化（回归测试），能保证基础功能没影响，代码就可以合入了，过几天就自动进入到测试环节。也能尽早发现问题，缩短交付周期。
同时还可以用作线上监控，保障服务稳定性。
保证结果的一致性和准确性！
手工用例总是需要人理解然后执行，因为各种原因，不同的人可能对同一条 case 理解不一样，造成执行偏差。然后人总有惰性，虽然很少，但偶尔还是会有因觉得执行过程偷懒而导致的漏测。而接口自动化一旦成为规模，执行的结果就是可靠的。
总的来说，如果你是想只通过接口自动化这一种方式降本提效，那接口自动化可能会事与愿违。而是应该把提质作为目的，即接口自动化作为质量保障的重要手段，尽早的写（不应该在服务上线了补），穿插到整个研发生命周期里面去，才能发挥更大的作用（特别是现在 DevOps 时代）。合适的度量指标：线上问题召回率（基本不可能通过手工召回）、自动化 Bug 发现比率（含 CICD 过程中发现的）。
接口自动化的成本
在评估自动化收益的时候我们常用这样一个公式：自动化收益 = 迭代次数 x （手工执行成本 用例维护成本）- 用例编写成本。但在接口自动化中不太合适，前面也说了，接口自动化和手工测试并不对等，并不是替代人工。不过自动化测试的成本倒是可以通过类似的公式计算：运行次数 x 用例维护成本 + 用例编写成本。这可能和大家想象的不一样，接口自动化通常被认为是边际成本很低，即用例编写成本会随着运行次数增加而摊薄。但事实上维护成本也不低，而且无法摊薄，因为不运行就不需要维护，只要运行就会出问题，就需要排查、维护。
维护成本的来源可能是多方面的，虽然都有一定的解决办法，但不能忽视这部分的成本，而且分散在日常中还是隐性成本，如果做的不好，甚至会出现团队都很累，但质量又很差的情况。
| 维护成本来源 | 解决方案 |
|---|---|
| 接口参数不兼容改动，需要相关 case 都改动 | 接口适当封装，case 使用封装后的模板或函数，方便使用和维护 |
| 前置变量失效导致 case 失败，比如商品 id 或者说一个新环境的适配成本 | 一方面 case 里面不能写死 id ，需要变量化，数据和逻辑分离；另一方面，case 需要自给自足，相关依赖资源在前置操作中产生，并在后置操作中销毁 |
| case 间的量子纠缠 | 适当的执行用户隔离，一些资源操作加锁 |
很多测试框架/平台把重点放在写 case 这块，但其实都没 Postman 好用，不过也有一些新方式，比如流量录制导入。但拉长 case 周期来看，编写成本是一次性的，10 分钟写完一条 case 和 1 小时写完一条差别不大。更多的应该放在如何写好 case （场景构造、数据准备等）、维护好 case ，这才能降低最终的成本（放心没广告）。
总结
还是那句话：软件工程没有银弹。鸡肋不鸡肋要看目的，降本增效可能不是直接的收益。同时也要注意接口自动化维护成本也不小，需要重点投入解决这块的问题，才能使最终的 ROI 高。
当然，本文看着还是泛泛而谈，并没有说接口自动化该如何写，但我认为具体怎么写都是招式问题，先修一下内功心法总纲更重要。
分享自本人博客： https://iyaozhen.com/api-automation-test-tasteless.html
市面上测试远没有开发火热，我说的可能比较片面，但也希望大家讨论讨论，丰富下这块的话题
 | 1 cleanery 2024-04-08 13:53:40 +08:00 要不然微软砍掉测试部后, win10 怎么 bug 这么多呢? 经过多年的小白鼠人工测试, 终于稳定下来了. |
 | 2 securityCoding 2024-04-08 14:45:11 +08:00 功能变动太快了，版本覆盖率还没上来呢下个版本就动刀 |
 | 3 opentrade 2024-04-08 14:49:28 +08:00 开源 |
 | 4 yule111222 2024-04-08 15:22:21 +08:00 接口自动化测试通常是外部 QA 团队做黑盒测试 测试反馈周期长，维护成本高，测试力度也不行，撑死在整个自动化测试的占比不要超过 10% 真正的自动化测试肯定是黑盒测试，要跑在 CI 环节的，代码提交 5 分钟内就要有反馈 |
| 5 yule111222 2024-04-08 15:22:58 +08:00 @yule111222 说错一句，真正的自动化测试肯定是白盒测试 |
 | 6 nullboy 2024-04-08 15:35:05 +08:00 OP 为什么会得出这样的结论？ pytest 的 conftest, fixture ，hook, parametrize,repeat,reruns,dist 这些不必 postman 强大的多。另外，我一直认为录制的测试用例屁用没有 > 很多测试框架/平台把重点放在写 case 这块，但其实都没 Postman 好用 |
 | 8 iyaozhen OP |
| 9 iyaozhen OP @nullboy 不好意思，说的不准确。应该分两种，1 是工具类，很多轮子，但其实都是类 postman ，甚至很多功能没 postman 全 2 是代码框架，这个就和语言相关了，比如 Python 基本都是 pytest 上封装。这两类间本身不能比较 降低编写成本是很重要，但更应该关注维护成本。我想这也是你说录制的 case 没用的原因，录制一时爽，维护火葬场 |
| 10 nullboy 2024-04-08 16:22:06 +08:00 @iyaozhen 给你分享一组数据。从 2023.1.6 至今，我们自动化项目共执行了 1978 次，共执行用例 81,930 个，共发现 bug 50+。所以，我不认为自动化测试越来越鸡肋 |
| 11 yule111222 2024-04-08 16:38:16 +08:00  1 @iyaozhen #8 额，外部的 QA 团队不是指代外包，就是公司内的 QA ，我始终认为 QA 没有存在的必要 |
 | 12 gsky411 2024-04-08 16:41:46 +08:00 1 能节省自己回归测试时间的自动化测试才有用，否则都是扯淡 |
 | 14 zephyru 2024-04-08 16:48:10 +08:00 1 自动化接口测试...和 postman 不是一码事吧，postman 也就调试阶段能用用...发现自己开发的问题顶天了。 自动化接口测试除了线上环境监测外还能对持续迭代时做保障，使新的修改不会对以前关联的老功能造成连锁破坏，工程大了/时间长了之后，单平台全量手工回归在成本上几乎是不可接受的事情。其它那些测试用例的关联关系天然的是平台业务的说明书，如果人员流动性大，有的时候有做这些功能的测试就是最理解业务的人了。 测试针对业务平台写自动化接口测试就和研发写单元测试一样，场景/项目没有复杂到一定程度时，的确容易投入和产出不成正比，但还远没到鸡肋的地步。 |
 | 15 forQ 2024-04-08 16:50:10 +08:00 测试团队=接口自动化 + UI 自动化 + 手工测试，三个不同的小组。 |
 | 16 linuxsuren 2024-04-08 16:57:03 +08:00 欢迎关注采用 Apache 协议的接口测试开源项目 https://github.com/LinuxSuRen/api-testing |
 | 17 1tangmizou 2024-04-08 17:02:11 +08:00 @iyaozhen 一样，人工发现远大于自动化发现的 bug |
 | 18 ecloud 2024-04-08 17:26:54 +08:00 1 每天下班前要求所有人 push 稳定代码，然后跑一个 daily build ，之后自动跑一套 apifox 的回归测试。早上来了看测试报告，谁的接口有问题扔给谁去看 当然这只适合中小型项目，大型项目 daiy build 不现实 接口测试的真谛不是做完了程序再去写 case ，而是先在 apifox 这种软件里设计接口，写好 mock ，之后程序做好了往上一套（可能会有些修改）就直接用了 |
 | 19 aiwoshishen 2024-04-08 17:35:19 +08:00 via iPhone @yule111222 非常赞同 |
| 20 iyaozhen OP @yule111222 哈哈 那我不得“失业”了。QA 这个岗位可能不需要，但质量保障这个事情还得需要 |
 | 21 nothingistrue 2024-04-08 17:43:37 +08:00 1 自动化测试，是让人腾出收来干其他活的，不是让你把人踢走的。如果你关注在成本上，那就只能降本增笑。 AI 也是同理，那些用 AI 将本的，注定要么增本要么增笑。 |
| 23 iyaozhen OP @zephyru 其实 postman 他们做的不仅仅是调试，你可以看下他们的付费版本，也能协作和 CI 。当然这不是重点，postman 指的是这类自动化平台（ web 端或者客户端工具） 嗯嗯 我也是反思我们做的不好的地方，其实我们业务量特别大、特别复杂，而且环境特别多，这就导致我们的维护成本倍增 |
| 24 nothingistrue 2024-04-08 17:54:01 +08:00 @ecloud #18 不管是测试现行，还是接口现行，都是有巨大的成本的，需要考虑是否值得。如果你在一个一次性使用的接口（很不幸的是，国内绝大部分软件开发过程，代码都是一次性的）上搞测试先行/接口先行，那就真是牛刀杀鸡。 那种只盯着结果的 QA ，真得是多余。但是真正盯着过程的 QA ，是第一顺位急缺的。 |
 | 25 chensuixiang 2024-04-08 18:12:47 +08:00 题外话：老哥你好几个论坛都发呢，敢情你这是到处宣传。 正经回答：接口自动化测试很鸡肋，在大部分公司都很鸡肋，起不到什么大作用。但是原因不是接口自动化没用，是真的做的不好（不契合项目），进而导致各种成本增加。这跟开发项目一样，你一开始就没做好，留下各种坑，后面就是得花费更多投入成本。 QA 是一个极具技术的岗位，但是在国内给人玩成了点工，没得玩。 |
| 27 iyaozhen OP @nothingistrue 哈哈，还想写一篇 AI 的呢，也是失败的经历 |
| 28 iyaozhen OP @nothingistrue [国内绝大部分软件开发过程，代码都是一次性的] 扎心了，最近还裁员 |
| 29 iyaozhen OP @chensuixiang 哈哈 我这也没文末小广告嘛。其实是想看看大家的想法，不一样的角度，改进现在自己的业务。 |
| 30 ecloud 2024-04-08 21:10:25 +08:00 1 @jefferyJQ 单元测试跟接口测试是一回事？单元测试的 mock 跟接口测试的 mock 就更不是一回事了，接口测试的 mock 是给前端用的 |
| 31 ecloud 2024-04-08 21:13:21 +08:00 1 |
 | 32 nuo7mi7 2024-04-08 21:32:07 +08:00 via Android 1 这 v2 基本都是开发多一些吧，毕竟还能看到有些觉得可以取消 QA 这个岗位的 其实什么自动化都是没用的，测试内卷的产物罢了，接口自动化可能还有点用，ui 自动化投入产出比极其低 往大说了测试这一行劣币驱逐良币，有点技术的看不上测试都去干的开发，再加上早些年培训班的大量宣传，教个测试方法就能去公司点点点，长时间后开发可能也看不起测试 多说一点，其实这行现在有点本末倒置，测试最重要的功能测试反而现在成了最不重要的，包括在流程中和产品对线，和开发对线，推进程，当整个流程的润滑剂，其实一个好的测试也挺难做的，不过国内都注重到技术上了，追求测试左移，测试右移，什么接口自动化，ui 自动化，现在又流行什么测试开发，精准测试，其实都算是测试体验不出自己的价值，从而倒逼自己必须体现价值，测试最重要的能力其实就是解决问题的能力，不局限任何技术，毕竟我只要点的够快就不需要自动化（手动狗头） 当然测试对于一个产品还是很重要的，毕竟没有测试过的电梯你敢坐吗，没有测试过的交易系统，你不怕亏钱吗 |
 | 33 Friday2333 2024-04-08 21:39:30 +08:00 ZAP 、CATS 、 |
 | 34 Zeyes 2024-04-08 22:24:25 +08:00 @securityCoding 太赞同了，一个功能还没上线没几个月能改个几轮，维护成本太高了。 |
 | 35 kaneg 2024-04-08 22:28:08 +08:00 via iPhone 1 自动化测试的最大意义是防止后续的改动造成 regression 。 开发过程中的测试，人工测试还是必不可少的，无论是开发还是 QA 。但纯粹把 QA 裁掉来降低成本的做法，就是杀鸡取卵，引用一句俗话，欠下的迟早要还的。 |
 | 36 BoomMan 2024-04-08 22:34:02 +08:00 1 谈谈我的观点，前提：不是所有的场景都需要测试。 如果你的产品本身就不是很重要，自然测试左移很正常，甚至现在是全栈工程师一个道理，产品、测试、前后端一起搞。 如果你的产品重要，不能出错，那么自动化测试、测试是很重要的，因为没人能保证最熟悉产品的人不跑路，一定要留下验收上线资产，这个资产可能就是自动化测试，最少自动化测试出问题了需要逻辑自洽去解答为什么出问题，而不是盲目上线。 |
 | 37 james122333 2024-04-08 22:45:36 +08:00 via Android curl 非常好阿 |
 | 38 GPLer 2024-04-09 00:53:56 +08:00 via Android 测试是保证维护和重构的，不是保证开发的，对开发人员来说鸡肋很正常。 |
 | 39 cctv6 2024-04-09 01:38:09 +08:00 1 我感觉趋势就是以后“自动化测试”的程度会越来越高，也会越来越好，同时也看好这个方向。或许将来基于 AI 的自动化测试可能是一个比较好的方向，不管是 API 还是 UI 的自动化，有希望能解决现在很多自动化的不足。 但是说实话工作几年了，基本上没见到过“优秀”的测试工程师，我现在对测试的要求只有两个，1. 能理解产品和理解业务 2. 能写测试用例 。 |
 | 40 msg7086 2024-04-09 01:40:46 +08:00 啊？提高测试覆盖率是过早优化？ |
 | 41 afxcn 2024-04-09 08:23:50 +08:00 1 写好测试用例有时候比写代码本身还麻烦。 |
| 42 james122333 2024-04-09 10:45:49 +08:00 1 我来解释一下为何 curl 非常好 首先 curl 有许多用法 最常用就是通常命令行的用法或者外加输出其他命令使用 但其实还能够写成脚本并带入变量 以下我从来没在公司用过 在公司我都故意写 shell+curl 命令写法 而不是 shell+curl 脚本写法 以下为小小范例 如果你如果同样是指令仔以下可以参考 命令行是很精妙的 #!/usr/bin/curl -K variable: "%DOMAIN" variable: "%QUERY=123" expand-url: "https://{{DOMAIN}}/search?q={{QUERY}}" header: "Test: 123" header: "Test2: 789" request: "GET" 第一行 variable 是从环境变量取得 DOMAIN 值 第二行 variable 是直接指派变量的值 第三行本来应写为"url:" 但由於需要置入变量需要前头"expand-" 第四五行为指定 header 第六行指定 method 所有选项可透过 man curl 查看双 dash 开头(--XXX)的参数参考 可加入注解 为什么你用 curl 该用这种方法 1. 方便管理 一个档案一个请求 2. 方便版本管控 3. 可搭配其他语言 4. 脚本即文档 我都讲了以后我可以在公司用了 |
| 43 james122333 2024-04-09 10:48:46 +08:00 基本上还不只可以用作测试 毕竟还可以指定 output 输出档案,使用 cookie 等 |
| 44 iyaozhen OP @nuo7mi7 确实，目前（好） QA 就业面太窄了，只有大公司才能玩得动。之前百度的时候 QA 晋升明确是两条线：1 就是你说的项目推动，功能测试等部分 2 是技术线，做平台 中阶的话两则差不多，但往后确实技术线更好晋升 |
| 45 iyaozhen OP @cdlnls 我这么多年来看，主要是好 QA 的生存环境要求高，基本只有大公司才有空间。我同事都还好，比如提 bug 能定位到研发代码行模块/行。PM 需求评审能给出建设性意见 |
| 46 iyaozhen OP @msg7086 我的意思是要警惕过早优化陷阱。我们很多功能生命周期很短。和研发讨论也有类似困境，架构设计非常好、一行行代码死扣，但最终功能上线一个月就被砍了，甚至整个产品都没了 |
| 47 iyaozhen OP @james122333 哈哈哈 我说的 curl 只是代指，一些没有规划设计临时性的脚本，也包含本地 postman 临时请求 |
 | 48 pojol7 2024-04-09 20:09:54 +08:00 1 来试试 gobot 呢， 开源的游戏通用测试工具 https://github.com/pojol/gobot |
| 49 pojol7 2024-04-09 20:12:40 +08:00 1. c/s 架构，在 ci 中可以随意触发一个机器人进行接口测试 2. prefab 节点，每个逻辑节点都是一个 prefab 如果接口有变化，直接在 prefab 中修改，即可影响到所有引用的地方 3. 支持压力测试 4. 有状态（任何测试逻辑都可以进行准确覆盖 等等等 |
| 50 james122333 2024-04-09 20:49:08 +08:00 via Android 1 |
 | 51 taihengw 2024-04-09 21:15:34 +08:00 1 我做过 QA 岗位，也做过开发岗位，个人体验，软件开发本来是一个高度工程化的行业，和建筑业、制造业很像。但是国内由于软件发展时间较短+非常容易内卷的文化，把这个行业变成了一个劳动密集型的手工行业。所以本来全球范围内很多行业先例总结出来的优秀经验，在这里无法落地和被理解，更不用说被有效执行下来。再细化到开发和测试岗位，开发工作本身因为前面说的原因已经挤压变形为“手工纺织”行业，背后的工程规律被无视和践踏，相应的衍生行业：测试岗，就更加无法按照理性逻辑去理解。所以会出现很多同一概念执行结果千差万别的现象。我举个最简单的例子：冒烟测试，或者核心用例测试，拿这个概念去问 QA 行业的任何员工，100 个人可以出现 500 种不同的解释，而且无法达成共识。这就反映出行业的基本逻辑都非常混乱，所以整个行业有点无源之水、无根之木的虚浮感，总是感觉有很多可以做的事情，但是又很难理清哪些是重要的，哪些是次要的事情。根本的工程规律不被重视，其上生长出来的各种产物很难不畸形。就好像盖房子如果不按照基本的建筑原理和建筑进度来实施，在该筑梁的阶段不去筑梁，反而被一堆路人指指点点窗户位置不合适要去修改窗户，那么建筑工人永远也无法建出合格的房子，还会整日陷入疲于奔命的状态。 |
| 54 linuxsuren 123 天前 最纯粹的开源接口开发测试工具发布 v0.0.20 https://github.com/LinuxSuRen/api-testing/releases/tag/v0.0.20 |
Select Language