【复盘】接口自动化测试框架建设的经验与教训!

【复盘】接口自动化测试框架建设的经验与教训!_第1张图片

为什么选择这个话题?

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

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

一、为什么要自建测试框架

1.1先谈谈接口测试

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

1.接口测试“套路”

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

【复盘】接口自动化测试框架建设的经验与教训!_第2张图片

2.为什么适合自动化

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

【复盘】接口自动化测试框架建设的经验与教训!_第3张图片

当然,大公司在这方面已经走在了前列了。就拿行业标杆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也是可以做自动化,但是我还没有实践过,平常更多将其作为接口调试的工具,不做过多赘述。

现在我也找了很多测试的朋友,做了一个分享技术的交流群,共享了很多我们收集的技术文档和视频教程。
如果你不想再体验自学时找不到资源,没人解答问题,坚持几天便放弃的感受
可以加入我们一起交流。而且还有很多在自动化,性能,安全,测试开发等等方面有一定建树的技术大牛
分享他们的经验,还会分享很多直播讲座和技术沙龙
可以免费学习!划重点!开源的!!!
qq群号:110685036【暗号:csdn999】

【复盘】接口自动化测试框架建设的经验与教训!_第4张图片

1.2自动化测试目的

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

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

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

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

1.3为什么需要自研框架?

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

  1. 测试工具开发的测试用例往往不易于维护,试想一下当你维护JMeter生成的各种JMX文件场景。
  2. 大量的测试用例可重用性差,例如登陆模块,每个接口调用前都要获取cookie,而登陆则是前置模块,使用JMeter开发用例需要每个JMX文件都要包含登陆,重复度太高。
  3. 无法满足自动化平台诉求,短期内确实可以快速实现自动化,但是这些工具对于平台非自动化能力的拓展成本较高,毕竟改动开源工具的成本比自研高很多。
  4. 使用开源工具不利于提升团队在自动化技术方面的成长。自动化能力的提升离不开编程能力的提升,使用开源工具能提升工具学习使用能力,最终你的成长无外乎又掌握了一个测试工具的使用。
  5. 无法最大化提升自己解决问题的能力。

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字段值比对等)。

END今天的分享就到此结束了! 点赞关注不迷路!

你可能感兴趣的:(软件测试,安全测试,自动化测试,测试用例,selenium,测试工具,测试工程师,自动化测试,接口测试)