职业经验 如何推动业务测试团队转型自动化测试?

知无涯 · 2021年04月24日 · 最后由 程早起 回复于 2021年06月06日 · 1548 次阅读

作者曾承担团队接口自动化测试专项,参与团队自研测试平台开发、落地,作为自动化小组 owner 在团队内部多次分享自动化测试技术,并推动其他测试小组接入测试框架,最终促成团队所有系统接入测试框架,大大提升团队自动化能力,同时取得了多项技术专利。

业务测试为什么需要转型自动化测试?

员工成长

就个人而言,相信大多数测试同学都遇到过发展瓶颈。当你忙于频繁手工测试看不到个人成长时,大多数表现出对未来职业发展的焦虑,很容易滋生员工产生跳槽的想法。这是团队管理者必须面对的问题。频繁手工让测试缺乏对成长的思考,不到对个人造成负面情绪,团队的氛围也会受影响。想改变这种情况,需要让团队成员持续看到自己的成长。推动员工转型自动化测试则是非常不错的 idea。

项目压力

随着敏捷开发的普及,测试需要应对快速的版本迭代,不断变化的产品需求。纯手工测试属于"旧时代"生产力,已经无法满足敏捷测试对测试的要求,提升测试生产力,则是缓解项目压力的手段。而提高测试生产力,就要求测试人员从纯业务测试向技术转型,鼓励员工使用技术手段解决业务问题!

如何推动团队测试转型自动化测试?
测试自动化是一种意识形态(思维方式),测试转型自动化是一种认知的升级。

如何认知升级,培养测试自动化思维?答案就是 持续学习新技术 + 项目专项实践 + 扎实的编程能力,毕竟实践是检验真理的唯一标准。

下面我就介绍下团队的从业务测试到自动化测试的转型过程。

自动化小组

大家都听说过 头狼效应,自动化小组就是头狼的角色,带头推动团队自动化转型。自动化小组成员都具备自动化测试经验,在各自所在的公司有过成功的自动化实践。大家坐在一起,可以针对当前团队测试过程遇到的最棘手的问题进行脑爆,并提出技术解决手段。

(此外,自动化小组成员都是独立负责项目且有自己的虚拟小组(带外包做项目),小组长也同时担负虚拟小组内部成员自动化转型的责任。虚拟小组是团队的子集,虚拟小组自动化技术的提升,也是团队自动化技术的提升。)

当时所在的团队刚成立不久,正处于快速扩张期,测试基础设施不完善,以当时的测试人力无法承担即将到来的业务压力。通过人员招聘并最终融入团队缓解压力毕竟有时间成本,所以自动化测试被大家提上议程,综合考虑到接口自动化投入低产出高,决定以接口自动化为突破点,打造团队内部接口测试平台,终极目标是中台所有项目接入测试平台实现自动化测试。

项目立项

找到了突破点,怎么做又摆在了眼前。做接口自动化测试,当下有现成的开源工具 JMeter、HttpRunner 等可以选择,既有一些开源的自动化测试平台。但是,这些开箱即用工具也有弊端。1. 无法满足自动化平台诉求,短期内确实可以快速实现自动化,但是这些工具对于平台非自动化能力的拓展成本较高,毕竟改动开源工具的成本比自研高很多。2. 使用开源工具不利于提升团队在自动化技术方面的成长。自动化能力的提升离不开编程能力的提升,使用开源工具能提升工具学习使用能力,最终你的成长无外乎又掌握了一个测试工具的使用。3. 无法最大化提升自己解决问题的能力。

最终结论,我们既不用现成开源测试平台,也不再结合已有的测试工具进行二次开发以搭建自己的测试平台,而是从 0 到 1 搭建自己的接口测试平台,以 Spring + TestNg + Okhttp 底架的方案搭建自动化测试平台。项目分两步走:1. 接口测试框架建设 2. 接口测试平台建设。

做大量的技术专项,不但可以提升你的编程能力,更重要的是锻炼你使用技术手段解决问题的能力,能用代码做的就不要手工做。

打造 “样板房”

接口测试框架开发完成后,我带的小组先进行试用。使用前先给大家做了一次分享,演示框架操作原理,如何开发接口测试用例。为了让大家好理解,我就拿 postman 的使用步骤和框架测试一个接口做类比。既是如此, 大家刚使用测试框架时候仍遇到了不少问题(也是意料之中,大多数外包几乎 0 编程经验),包括接口测试用例开发成本高,外包同学代码能力差遇到问题解决不了,不会 debug 代码,开发好的用例上传 gitlab 经常搞出冲突需要解决,每个同学用例的写法千奇百怪等等。还记得当时那段时间的内容,除了做手上的业务就是帮忙看各种大家在写用例遇到的问题。为了这些问题,我也挤时间编写小白级的测试框架使用说明书,制定测试用例开发规范,其他同学进行 git 使用分享,debug 培训等。针对用例开发成本高的问题,我通过在测试用例开发过程总结到 HTTP 不同请求方法对应的接口测试写法不一样,同方法的测试接口写法几乎一致,突然想到可以使用模板自动生成接口测试用例,然后我就整理几种接口测试用例生成模板(post、get、get 拼接参数等),这样大大降低测试用例开发成本,大家更多在于测试数据的准备和断言。基于此实践,也和同事一起申请一项自动化代码生成专利。

通过几个月的小组内推广使用,几乎解决了所有用例开发到运行过程可能会遇到的问题,将大家遇到的问题也汇总成知识库。

我们小组通过几个月的使用,在一定程度上提升了自动化回归的效率,起到了示范作用,然后就开始将框架推广到其他测试小组使用!

定期周会

我们团队比较大,所谓周会并非每周一次,基本上是半月/一月才会组织一次。

周会也是给团队成员普及自动化测试技术的一场非常好的机会。自动化小组成员可以分享一些最近学习的测试新技术,和大家脑爆是否能够解决当前团队中遇到的问题。也可以分享一个近期项目中利用技术手段解决业务问题的案例。分享形式不限,要能突出技术在工作中的重要性,增加团队成员对技术认知的体感。

对内/外交流

俗话说,山外有山,人外有人。永远要保持一颗谦逊的心。

鼓励与公司其他团队进行技术交流、分享技术上的产出。说不定你解决的问题正是别人当前遇到的。你遇到的问题也可能是别的团队早已解决的。在互联网大厂,通过对外交流能降低重复造轮子的概率。

当然除了与公司内部团队间交流,也可以经常参与对外交流。比如 参加每年的 MTSC 测试开发大会,多听取各大厂测试团队分享的自动化相关议题。

也可以参加公司组织的线下沙龙,将自己团队比较好的自动化实践分享出去,别的公司优秀的技术实践吸收进来。

测试开发技能图谱
前文说到,测试认知升级,离不开大量的技术专项实践,这也要求测试需要具备开发能力,即测试开发。

下面是一份测试开发技能图谱,可以作为大家转型的指导。


共收到 2 条回复 时间 点赞
知无涯 聊下自己转型测试开发的历程 中提及了此贴 06月05日 15:14

请问,可以分享下 xmid 文档的文件吗? 贴图感觉看不清~

请问可以分享一下技能图谱嘛,万分感谢

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