职业经验 接口自动化测试框架建设的经验与教训

知無涯 · 2022年03月26日 · 最后由 fiskeryang 回复于 2022年03月28日 · 976 次阅读

为什么选择这个话题?
一是发现很多 “点工” 在转型迷茫期都会问一些自动化测试相关的问题,可以说自动化测试是 “点工” 升级的必经之路;二是 Google 一下接口自动化测试,你会发现很多自动化测试框架相关的文章,但是大部分文章都有一个通病,就是只告诉读者 how(怎么做),很少介绍 why,还有框架开发完成之后的事情(例如如何推广、维护等)。那下面就聊一聊我的接口自动化测试框架建设的一些经验和教训吧,希望能给大家一些借鉴。

工作多年,第一次听说接口测试是在《软件测试的艺术》的书上面,那时候校招复习软件测试理论,当时没有体感,甚至不知道什么是接口。第一次接触接口测试并非来源于项目需要,而是来源于团队 KPI 需要。当时校招刚入职没多久,团队内部有测试相关知识与技能培训(虽然只是测试工具的使用),当时接触的第一个接口测试工具是 JMeter。还记得我同事通过一个 word 文档给我介绍它的一些常用组件,然后就给我安排上了一个任务 - 将团队 xx 平台接口代码覆盖率提升至 40% 以上。当时还不知道代码覆盖率是什么,但是只晓得通过 JMeter 开发更多单接口/业务场景组合的用例就是了,于是乎就开始通过针对单接口的入参类型、边界、是否必传做各种组合,而场景组合用例就做接口间的笛卡尔积生成不同的业务流。第二份工作老板想打造一个团队内部使用的接口测试平台,当时就给我这个机会负责接口测试框架的建设。这也是第一次实践接口自动化测试框架。今天聊的故事就从这里开始。。。

一、为什么要自建测试框架
1.1 先谈谈接口测试
何为接口?通俗来讲生活中常见的电灯开关就是接口,它接收开、关(默认)指令(值),输出对灯泡的控制结果(亮、灭)。接口测试是测试系统组件间接口的一种测试。测试的重点是要检查数据的交换,传递以及系统间的相互逻辑依赖关系等。

1.接口测试 “套路”
根据我举的例子,可以知道对接口测试,从功能上可以把接口当做黑盒进行输入以观察其输出,根据不同的输入去测试其内部的逻辑,我们可以借助边界值分析、等价类等方法设计用例。非功能上要测试接口性能、安全、幂等。此外,如果所测接口存在上下接口调用的依赖,则还需要进行全链路联调测试(不部分接口不是独立存在的,都是和其他接口相互调用的),联调测试是为了保证上下联路接口之间契约的准确性。

2.为什么适合自动化
根据分层测试思想,可以将系统测试分为单元测试、接口测试以及界面测试。一般来说,单元测试就像一座房子的地基,地基打得好,房子也就比较稳固;接口测试就像房子的架子,决定房子的形态;而界面测试就像房子的装修,体现房子的外观。诚然,地基以及房子架子是比较稳定的,变化不大的,而房子的装修是可以根据心情不断更换的。大家都知道变化和成本是成正比的,变化越大成本越高,根据 ROI=产出/投入,分子不变,分母越大,ROI 越小,这也是界面测试不适合自动化的主要原因。当然不代表所有项目都不适合做 UI 自动化,如果 UI 比较固定也是可以做自动化的。

当然,大公司在这方面已经走在了前列了。就拿行业标杆 Google 来说,《How Google Tests Software》书中也有提到,70% 自动化在单测,20% 自动化在接口测试,10% 自动化在 UI 测试。

3.常用的接口测试工具
介绍下我使用过的 JMeter、Postman 这两工具。

总体而言 JMeter 更适合作为接口自动化工具的,虽然官网将其定义为压测工具(The Apache JMeter™ application is open source software, a 100% pure Java application designed to load test functional behavior and measure performance.)因为 JMeter 几乎能满足接口自动化测试的所有诉求,有丰富的函数(类似 utils)(例如生成个随机数、uuid 等,这些都是测试过程经常用的能力,而且还支持自己扩展)、断言丰富、结合 Jenkins 做持续集成、有测试报告、有丰富的插件库可供下载等等,非常适合技术感不强的测试团队。Postman 也是可以做自动化,但是我还没有实践过,平常更多将其作为接口调试的工具,不做过多赘述。

1.2 自动化测试目的
本来这个小标题是 “接口自动化测试目的”,提笔写的时候发现所有自动化目的貌似是公途的。我先抛出来两个论点:发现缺陷?提高测试效率?

大家可能觉得实现自动化的话,这两个目的是自然而然的。当然我不否认但也不完全赞同。那我为什么要把这两个论点拿出来讨论下呢?因为自动化测试是一个有计划的过程,不同的目的可能会有不同的实现过程,有不同的实现侧重点。

如果目的是 发现缺陷,那么自动化测试用例就要覆盖的比较全面且细致(业务层面、断言层面),这无疑会加大自动化测试用例的开发成本,所以投入过程需要重点分析业务以及多排期些开发时间。

而提高测试效率呢?当然这里的提效不仅仅体现在测试过程,而且还体现在测试者的日常工作中,类似造数据等工作内容。因此如果以提效为目标,那么自动化测试用例开发要重点分析哪些业务流是调用比较频繁的,而在断言层面也没有必要太过细致,以造数为例,毕竟提效的目的在于获得结果,只要结果符合预期就是 OK 的。当然,这些都是笔者个人看法,大家可以各抒己见。

1.3 为什么需要自研框架?
上文也说道做接口自动化测试,当下有现成的开源工具 JMeter、Postman 等可以选择,也有一些开源的自动化测试平台。但是,这些开箱即用工具也有弊端:

测试工具开发的测试用例往往不易于维护,试想一下当你维护 JMeter 生成的各种 JMX 文件场景。

大量的测试用例可重用性差,例如登陆模块,每个接口调用前都要获取 cookie,而登陆则是前置模块,使用 JMeter 开发用例需要每个 JMX 文件都要包含登陆,重复度太高。

无法满足自动化平台诉求,短期内确实可以快速实现自动化,但是这些工具对于平台非自动化能力的拓展成本较高,毕竟改动开源工具的成本比自研高很多。

使用开源工具不利于提升团队在自动化技术方面的成长。自动化能力的提升离不开编程能力的提升,使用开源工具能提升工具学习使用能力,最终你的成长无外乎又掌握了一个测试工具的使用。

无法最大化提升自己解决问题的能力。

1.4 接口测试框架选型
关于语言

语言建议和负责项目的系统语言保持一致,如果被测项目语言是 Java,测试框架就选用 Java 语言开发,结合 Spring boot 框架搭建。

关于扩展性

扩展性是非常重要的,因为框架不是一蹴而就的,是一个需要基于业务的迭代不断 “更新” 的,良好的扩展性,可以让你更高效的开发所需的 feature。这点可以参考 JMeter 的架构设计。

关于实现方案

确定使用的技术后,务必要将的实现思路整理出来,写一个实现方案,就像项目的系分文档一样,这样对你来说具备指导意义。仔细想想,测试框架的开发,就是要求自己兼顾产研测的角色(条件可以的话,可以让产品/UI 帮你设计平台草图)。

二、经验沉淀
1.计划的重要性
人、事准备好后,下一步就是制定计划。万事预则立,不预则废。对于测试来说,计划尤为重要。一方面测试框架建设的任务并不会允许你 100% 工作时间去做,因为你还有业务测试工作要负责和跟进。另一方面,老板要看结果,制定每个阶段的里程碑是非常重要的,当然计划这些会在 OKR 里体现的。

以我的经验,可以制定按照 feature 数量给自己排期,例如每周实现 x 个 feature,这样就可以大概推出完成测试框架开发需要的周数,尽量周报里有所体现实现的进度,以及下周的 todo。

2.文档必不可少
为什么文档这么重要?文档其实是另一种 “自动化测试框架” 的实现方式。代码实现框架本身,文字为框架 “穿上衣服”。再者,文档可以节约你未来非常多的 “客服” 时间。文档内容范围不限,总的来说有三类:技术实现文档、使用说明文档以及问题记录的文档。

(1)技术实现文档用于描述框架实现的技术手段以及编码规范,可以在系分文档上继续补充。

(2)使用说明文档用于介绍使用方法,最好是先以快速入门为例,教大家如何利用测试框架开发一个测试用例。再详细介绍如何使用(调用)某些公共组件(工具)。当然建议录制操作视频。

(3)问题记录文档 用于协作开发的时候供其他小伙伴参考使用,毕竟你踩过的坑别人也有可能踩过。这样可以减少同类问题排查和定位时间。(笔者曾经在帮助小组同学排查问题方面就耗费了不少时间。)

3.多人协作下的开发模式
自动化框架最终的是推广给大家使用它去开发接口测试用例,以替代 JMeter 这些接口测试工具。在平台化实现之前,就避免不了多人同时提交开发好的用例代码。针对这个,我建议使用 master\dev 分支,每日的自动化用例运行使用 master 分支代码,而 dev 分支用于大家提交各自分支的代码。这就需要经常 dev 分支的代码合到 master 分支。

4.做好代码 review 工作
正如经验 3 一样,确定好开发模式之后,同样不能避免有些同学在提交代码时 “乱来”(不规范开发和提交,例如随意修改别人的代码等),导致代码冲突。而作为项目的负责人,就像一个门神,要做好代码 review 工作。这样可以在一定程度上降低代码冲突的概率。总之尽量不要将宝贵的时间消耗在这些代码管理的问题上。

5.推广小组试用
框架开发好后,不建议急于大批量推广,建议先 “小流量” 灰度试用。我们大团队下面分了很多小团队,基本上业务 owner 带一些外包保障项目质量。而管理者注重框架的结果。框架开发者是全职员工,框架的使用者主要是外包和偏业务测试全职同学。当时搞定框架开发之后(算是 1.0 版本,已经可以使用),就在我的小组进行使用。这样可以先搜集一下使用效果和反馈的问题,先做一版小迭代,把他们觉得比较影响使用的问题先解决掉。

6.分享和培训
先给大家做了一次分享,演示框架操作原理,如何开发接口测试用例。为了让大家好理解,我就拿 postman 的使用步骤和框架测试一个接口做类比。即使如此, 大家刚使用测试框架时候仍遇到了不少问题(也是意料之中,大多数外包几乎 0 编程经验),包括接口测试用例开发成本高,外包同学代码能力差遇到问题解决不了,不会 debug 代码,开发好的用例上传 gitlab 经常搞出冲突需要解决,每个同学用例的写法千奇百怪等等。还记得当时那段时间的内容,除了做手上的业务就是帮忙看大家在写用例遇到的各种问题。为了解决这些问题,我也挤时间编写测试框架使用说明书,对大家进行 git 使用培训,debug 培训等,鼓励大家多学点 Java,多读读《Java 编程思想》。

7.注重大家的使用反馈
使用反馈是非常重要的。因为它是你进行版本迭代的驱动力。其实就和产品做项目一样,每个版本都要分析用户的使用反馈,根据反馈进行版本优化和迭代。可以和使用者沟通,发现一些他们使用过程的痛点。当然这只是第一步,更重要的是要有解决方案。

8.考虑代码生成
针对用例开发成本高的问题,我通过在测试用例开发过程总结到 HTTP 不同请求方法对应的接口测试写法不一样,同方法的测试接口写法几乎一致,突然想到可以使用模板(freemarker)自动生成接口测试用例,然后我就整理几种接口测试用例生成模板(post、get 等),这样大大降低测试用例开发成本,大家更多在于测试数据的准备和断言。

个人觉得代码生成是每个测试框架设计的必须考虑的点,因为像 postman、jmeter 等这些工具本质上和你开发测试框架是雷同的,如果做到用例之间可以相互转化,可以提高用例的可迁移性和复用性。

三、教训总结

1.缺乏自动化效果的统计&度量
上文说了,相比过程,老板更看重结果。如何体现结果,那就是要有数据统计与度量。记得被开发挑战过,你们搞得自动化发现了多少缺陷、节约了多少时间等问题。这块当时做的不好。

1 是框架本身还没有平台化,当时实现的功能是测试用例开发模块的实现,统计数据没有落 DB,这块需要靠人工统计比较费时间(当时为了统计自动化用例运行结果数据,在 Jenkins 服务器上捞日志,简直是痛苦)。
2 是当时没有明确的度量目标,像节约了多少时间这类,确实难以衡量。

现在我觉得当时的框架设计之初是遗漏了这个问题的,建议后来者可以将测试数据都落 DB。

2.没有对测试进行测试
这个主要是没有对测试框架本身进行测试,特别是多人协作开发模式,单测尤为重要,单测在一定程度上是保障代码质量的手段,可以有效避免部分同学 “乱改” 别人的代码。当然,如果时间充足,建议对测试框架写单测。

3.自动化用例开发计划没有突出侧重点
这个也是教训 1 的一个原因。框架完成之后,我们就在 okr 里计划 xx 完成接口 100% 自动化覆盖,刚开始阶段没有对被测接口重要性做分析,导致没有将时间花在核心的接口用例开发上,也间接导致产出不高。

现在想想,其实是计划不明确且没有突出重点的问题,颗粒度还不够,现在的建议是大家要优先实现核心接口,这些接口流量大,更容易有产出。不要为了追求覆盖率而本末倒置。

4.断言的不完善
当时的框架没有开发 DB checker,所以断言全靠 http 响应,其实这样的用例是质量不高的,也就是测试预期不全面,可能会存在漏网之鱼(遗漏缺陷)。

建议大家一定要断言模块重点考虑到。包括 http 层面(响应时间、响应码、key 字段断言、状态码等)、DB 层面(key 字段值比对等)。

推荐阅读:
https://testerhome.com/topics/31145
https://testerhome.com/topics/30291

共收到 1 条回复 时间 点赞

总结的很好 基本上都是在自动化落地过程中遇到过的问题

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