V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
iyaozhen
V2EX  ›  程序员

十多年了,接口自动化测试越来越鸡肋?

  •  4
     
  •   iyaozhen ·
    iyaozhen · 261 天前 · 6421 次点击
    这是一个创建于 261 天前的主题,其中的信息可能已经有所发展或是发生改变。

    引言

    从《 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

    市面上测试远没有开发火热,我说的可能比较片面,但也希望大家讨论讨论,丰富下这块的话题

    53 条回复    2024-04-09 23:46:37 +08:00
    cleanery
        1
    cleanery  
       261 天前
    要不然微软砍掉测试部后, win10 怎么 bug 这么多呢?
    经过多年的小白鼠人工测试, 终于稳定下来了.
    securityCoding
        2
    securityCoding  
       261 天前
    功能变动太快了,版本覆盖率还没上来呢下个版本就动刀
    opentrade
        3
    opentrade  
       261 天前
    开源
    yule111222
        4
    yule111222  
       260 天前
    接口自动化测试通常是外部 QA 团队做黑盒测试
    测试反馈周期长,维护成本高,测试力度也不行,撑死在整个自动化测试的占比不要超过 10%

    真正的自动化测试肯定是黑盒测试,要跑在 CI 环节的,代码提交 5 分钟内就要有反馈
    yule111222
        5
    yule111222  
       260 天前
    @yule111222 说错一句,真正的自动化测试肯定是白盒测试
    nullboy
        6
    nullboy  
       260 天前
    OP 为什么会得出这样的结论? pytest 的 conftest, fixture ,hook, parametrize,repeat,reruns,dist 这些不必 postman 强大的多。另外,我一直认为录制的测试用例屁用没有
    > 很多测试框架/平台把重点放在写 case 这块,但其实都没 Postman 好用
    iyaozhen
        7
    iyaozhen  
    OP
       260 天前
    @opentrade 额 开源是啥意思?
    iyaozhen
        8
    iyaozhen  
    OP
       260 天前
    @yule111222 嗯嗯 你说的这个赞同

    但 [接口自动化测试通常是外部 QA 团队做黑盒测试] 这个和我知道了不一样,可能我都是在互联网公司,这块并没有外包或者类似项目审计那种
    iyaozhen
        9
    iyaozhen  
    OP
       260 天前
    @nullboy 不好意思,说的不准确。应该分两种,1 是工具类,很多轮子,但其实都是类 postman ,甚至很多功能没 postman 全
    2 是代码框架,这个就和语言相关了,比如 Python 基本都是 pytest 上封装。这两类间本身不能比较

    降低编写成本是很重要,但更应该关注维护成本。我想这也是你说录制的 case 没用的原因,录制一时爽,维护火葬场
    nullboy
        10
    nullboy  
       260 天前
    @iyaozhen 给你分享一组数据。从 2023.1.6 至今,我们自动化项目共执行了 1978 次,共执行用例 81,930 个,共发现 bug 50+。所以,我不认为自动化测试越来越鸡肋
    yule111222
        11
    yule111222  
       260 天前   ❤️ 1
    @iyaozhen #8 额,外部的 QA 团队不是指代外包,就是公司内的 QA ,我始终认为 QA 没有存在的必要
    gsky411
        12
    gsky411  
       260 天前   ❤️ 1
    能节省自己回归测试时间的自动化测试才有用,否则都是扯淡
    iyaozhen
        13
    iyaozhen  
    OP
       260 天前
    @nullboy 执行次数没啥意义吧,你们总 bug 数多少呢? 我们自动化发现的 bug 比率极低
    zephyru
        14
    zephyru  
       260 天前   ❤️ 1
    自动化接口测试...和 postman 不是一码事吧,postman 也就调试阶段能用用...发现自己开发的问题顶天了。
    自动化接口测试除了线上环境监测外还能对持续迭代时做保障,使新的修改不会对以前关联的老功能造成连锁破坏,工程大了/时间长了之后,单平台全量手工回归在成本上几乎是不可接受的事情。其它那些测试用例的关联关系天然的是平台业务的说明书,如果人员流动性大,有的时候有做这些功能的测试就是最理解业务的人了。
    测试针对业务平台写自动化接口测试就和研发写单元测试一样,场景/项目没有复杂到一定程度时,的确容易投入和产出不成正比,但还远没到鸡肋的地步。
    forQ
        15
    forQ  
       260 天前
    测试团队=接口自动化 + UI 自动化 + 手工测试,三个不同的小组。
    linuxsuren
        16
    linuxsuren  
       260 天前
    欢迎关注采用 Apache 协议的接口测试开源项目 https://github.com/LinuxSuRen/api-testing
    1tangmizou
        17
    1tangmizou  
       260 天前
    @iyaozhen 一样,人工发现远大于自动化发现的 bug
    ecloud
        18
    ecloud  
       260 天前   ❤️ 1
    每天下班前要求所有人 push 稳定代码,然后跑一个 daily build ,之后自动跑一套 apifox 的回归测试。早上来了看测试报告,谁的接口有问题扔给谁去看
    当然这只适合中小型项目,大型项目 daily build 不现实
    接口测试的真谛不是做完了程序再去写 case ,而是先在 apifox 这种软件里设计接口,写好 mock ,之后程序做好了往上一套(可能会有些修改)就直接用了
    aiwoshishen
        19
    aiwoshishen  
       260 天前 via iPhone
    @yule111222 非常赞同
    iyaozhen
        20
    iyaozhen  
    OP
       260 天前
    @yule111222 哈哈 那我不得“失业”了。QA 这个岗位可能不需要,但质量保障这个事情还得需要
    nothingistrue
        21
    nothingistrue  
       260 天前   ❤️ 1
    自动化测试,是让人腾出收来干其他活的,不是让你把人踢走的。如果你关注在成本上,那就只能降本增笑。

    AI 也是同理,那些用 AI 将本的,注定要么增本要么增笑。
    jefferyJQ
        22
    jefferyJQ  
       260 天前
    @ecloud 那为啥不直接写单元测试的时候 mock 呢
    iyaozhen
        23
    iyaozhen  
    OP
       260 天前
    @zephyru 其实 postman 他们做的不仅仅是调试,你可以看下他们的付费版本,也能协作和 CI 。当然这不是重点,postman 指的是这类自动化平台( web 端或者客户端工具)

    嗯嗯 我也是反思我们做的不好的地方,其实我们业务量特别大、特别复杂,而且环境特别多,这就导致我们的维护成本倍增
    nothingistrue
        24
    nothingistrue  
       260 天前
    @ecloud #18 不管是测试现行,还是接口现行,都是有巨大的成本的,需要考虑是否值得。如果你在一个一次性使用的接口(很不幸的是,国内绝大部分软件开发过程,代码都是一次性的)上搞测试先行/接口先行,那就真是牛刀杀鸡。

    那种只盯着结果的 QA ,真得是多余。但是真正盯着过程的 QA ,是第一顺位急缺的。
    chensuixiang
        25
    chensuixiang  
       260 天前
    题外话:老哥你好几个论坛都发呢,敢情你这是到处宣传。
    正经回答:接口自动化测试很鸡肋,在大部分公司都很鸡肋,起不到什么大作用。但是原因不是接口自动化没用,而是真的做的不好(不契合项目),进而导致各种成本增加。这跟开发项目一样,你一开始就没做好,留下各种坑,后面就是得花费更多投入成本。
    QA 是一个极具技术的岗位,但是在国内给人玩成了点工,没得玩。
    iyaozhen
        26
    iyaozhen  
    OP
       260 天前
    @forQ 有些团队不是这样,如果把接口自动化、UI 自动化都让手工(功能)测试的同学做,负担就很重了
    iyaozhen
        27
    iyaozhen  
    OP
       260 天前
    @nothingistrue 哈哈,还想写一篇 AI 的呢,也是失败的经历
    iyaozhen
        28
    iyaozhen  
    OP
       260 天前
    @nothingistrue [国内绝大部分软件开发过程,代码都是一次性的] 扎心了,最近还裁员
    iyaozhen
        29
    iyaozhen  
    OP
       260 天前
    @chensuixiang 哈哈 我这也没文末小广告嘛。其实是想看看大家的想法,不一样的角度,改进现在自己的业务。
    ecloud
        30
    ecloud  
       260 天前   ❤️ 1
    @jefferyJQ 单元测试跟接口测试是一回事?单元测试的 mock 跟接口测试的 mock 就更不是一回事了,接口测试的 mock 是给前端用的
    ecloud
        31
    ecloud  
       260 天前   ❤️ 1
    @nothingistrue 如果你们都是 0 文档就埋头垒代码的,那我只能说告辞。


    应用 apifox 这种软件”写“接口文档比特么以前写 word 要简单方便多了,这都要省?是个正规软件公司么?
    nuo7mi7
        32
    nuo7mi7  
       260 天前 via Android   ❤️ 1
    这 v2 基本都是开发多一些吧,毕竟还能看到有些觉得可以取消 QA 这个岗位的

    其实什么自动化都是没用的,测试内卷的产物罢了,接口自动化可能还有点用,ui 自动化投入产出比极其低
    往大说了测试这一行劣币驱逐良币,有点技术的看不上测试都去干的开发,再加上早些年培训班的大量宣传,教个测试方法就能去公司点点点,长时间后开发可能也看不起测试

    多说一点,其实这行现在有点本末倒置,测试最重要的功能测试反而现在成了最不重要的,包括在流程中和产品对线,和开发对线,推进程,当整个流程的润滑剂,其实一个好的测试也挺难做的,不过国内都注重到技术上了,追求测试左移,测试右移,什么接口自动化,ui 自动化,现在又流行什么测试开发,精准测试,其实都算是测试体验不出自己的价值,从而倒逼自己必须体现价值,测试最重要的能力其实就是解决问题的能力,不局限任何技术,毕竟我只要点的够快就不需要自动化(手动狗头)

    当然测试对于一个产品还是很重要的,毕竟没有测试过的电梯你敢坐吗,没有测试过的交易系统,你不怕亏钱吗
    Friday2333
        33
    Friday2333  
       260 天前
    ZAP 、CATS 、
    Zeyes
        34
    Zeyes  
       260 天前
    @securityCoding 太赞同了,一个功能还没上线没几个月能改个几轮,维护成本太高了。
    kaneg
        35
    kaneg  
       260 天前 via iPhone   ❤️ 1
    自动化测试的最大意义是防止后续的改动造成 regression 。

    开发过程中的测试,人工测试还是必不可少的,无论是开发还是 QA 。但纯粹把 QA 裁掉来降低成本的做法,就是杀鸡取卵,引用一句俗话,欠下的迟早要还的。
    BoomMan
        36
    BoomMan  
       260 天前   ❤️ 1
    谈谈我的观点,前提:不是所有的场景都需要测试。
    如果你的产品本身就不是很重要,自然测试左移很正常,甚至现在是全栈工程师一个道理,产品、测试、前后端一起搞。
    如果你的产品重要,不能出错,那么自动化测试、测试是很重要的,因为没人能保证最熟悉产品的人不跑路,一定要留下验收上线资产,这个资产可能就是自动化测试,最少自动化测试出问题了需要逻辑自洽去解答为什么出问题,而不是盲目上线。
    james122333
        37
    james122333  
       260 天前 via Android
    curl 非常好阿
    GPLer
        38
    GPLer  
       260 天前 via Android
    测试是保证维护和重构的,不是保证开发的,对开发人员来说鸡肋很正常。
    cdlnls
        39
    cdlnls  
       260 天前   ❤️ 1
    我感觉趋势就是以后“自动化测试”的程度会越来越高,也会越来越好,同时也看好这个方向。或许将来基于 AI 的自动化测试可能是一个比较好的方向,不管是 API 还是 UI 的自动化,有希望能解决现在很多自动化的不足。

    但是说实话工作几年了,基本上没见到过“优秀”的测试工程师,我现在对测试的要求只有两个,1. 能理解产品和理解业务 2. 能写测试用例 。
    msg7086
        40
    msg7086  
       260 天前
    啊?提高测试覆盖率是过早优化?
    afxcn
        41
    afxcn  
       260 天前   ❤️ 1
    写好测试用例有时候比写代码本身还麻烦。
    james122333
        42
    james122333  
       260 天前   ❤️ 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. 脚本即文档

    我都讲了以后我可以在公司用了
    james122333
        43
    james122333  
       260 天前
    基本上还不只可以用作测试
    毕竟还可以指定 output 输出档案,使用 cookie 等
    iyaozhen
        44
    iyaozhen  
    OP
       260 天前
    @nuo7mi7 确实,目前(好) QA 就业面太窄了,只有大公司才能玩得动。之前百度的时候 QA 晋升明确是两条线:1 就是你说的项目推动,功能测试等部分 2 是技术线,做平台 中阶的话两则差不多,但往后确实技术线更好晋升
    iyaozhen
        45
    iyaozhen  
    OP
       260 天前
    @cdlnls 我这么多年来看,主要是好 QA 的生存环境要求高,基本只有大公司才有空间。我同事都还好,比如提 bug 能定位到研发代码行模块/行。PM 需求评审能给出建设性意见
    iyaozhen
        46
    iyaozhen  
    OP
       260 天前
    @msg7086 我的意思是要警惕过早优化陷阱。我们很多功能生命周期很短。和研发讨论也有类似困境,架构设计非常好、一行行代码死扣,但最终功能上线一个月就被砍了,甚至整个产品都没了
    iyaozhen
        47
    iyaozhen  
    OP
       260 天前
    @james122333 哈哈哈 我说的 curl 只是代指,一些没有规划设计临时性的脚本,也包含本地 postman 临时请求
    pojol7
        48
    pojol7  
       259 天前   ❤️ 1
    来试试 gobot 呢, 开源的游戏通用测试工具 https://github.com/pojol/gobot
    pojol7
        49
    pojol7  
       259 天前
    1. c/s 架构,在 ci 中可以随意触发一个机器人进行接口测试
    2. prefab 节点,每个逻辑节点都是一个 prefab 如果接口有变化,直接在 prefab 中修改,即可影响到所有引用的地方
    3. 支持压力测试
    4. 有状态(任何测试逻辑都可以进行准确覆盖
    等等等
    james122333
        50
    james122333  
       259 天前 via Android   ❤️ 1
    @iyaozhen

    我知道 但我觉得 curl 可以弄的很好
    taihengw
        51
    taihengw  
       259 天前   ❤️ 1
    我做过 QA 岗位,也做过开发岗位,个人体验,软件开发本来是一个高度工程化的行业,和建筑业、制造业很像。但是国内由于软件发展时间较短+非常容易内卷的文化,把这个行业变成了一个劳动密集型的手工行业。所以本来全球范围内很多行业先例总结出来的优秀经验,在这里无法落地和被理解,更不用说被有效执行下来。再细化到开发和测试岗位,开发工作本身因为前面说的原因已经挤压变形为“手工纺织”行业,背后的工程规律被无视和践踏,相应的衍生行业:测试岗,就更加无法按照理性逻辑去理解。所以会出现很多同一概念执行结果千差万别的现象。我举个最简单的例子:冒烟测试,或者核心用例测试,拿这个概念去问 QA 行业的任何员工,100 个人可以出现 500 种不同的解释,而且无法达成共识。这就反映出行业的基本逻辑都非常混乱,所以整个行业有点无源之水、无根之木的虚浮感,总是感觉有很多可以做的事情,但是又很难理清哪些是重要的,哪些是次要的事情。根本的工程规律不被重视,其上生长出来的各种产物很难不畸形。就好像盖房子如果不按照基本的建筑原理和建筑进度来实施,在该筑梁的阶段不去筑梁,反而被一堆路人指指点点窗户位置不合适要去修改窗户,那么建筑工人永远也无法建出合格的房子,还会整日陷入疲于奔命的状态。
    iyaozhen
        52
    iyaozhen  
    OP
       259 天前
    @pojol7 哈哈 我觉得不是工具的问题,我就是就平台的,但是没有开源,不然我敢说秒杀市面上绝大部分
    iyaozhen
        53
    iyaozhen  
    OP
       259 天前
    @taihengw 老哥说的一针见血呀,但我想有机会还是可以把我局部的产品/业务做好,至少进步空间还是有的
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5251 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 28ms · UTC 07:18 · PVG 15:18 · LAX 23:18 · JFK 02:18
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.