测开造轮子漫谈
参考:https://mp.weixin.qq.com/s?__biz=MzkwNTI2NjAxMA==&mid=2247484083&idx=1&sn=2abc1d87e64878ed040e3f9856c4b0ac&chksm=c0fb1486f78c9d903dfcdc6a3c6adf04c42dc8e740224c57e4bd61c7faceca85058bbeed0c5c&cur_album_id=1979310371207184387&scene=189#wechat_redirect
01 测试人员在卷什么
外圈主要是从行为上提升,比如加班(虽然没什么用,但态度有时候也能体现一些好处)、深入业务,从业务的积累上提升竞争力(只针对特定领域有用,比如金融),敏捷测试(从做事的方法上做出改变,进行新的尝试),内圈主要是从能力上提升,比如专项测试的开展(接口应该不能算专项测试了,基本上是测试人员的必备技能。性能、安全、混沌工程这类的),开发能力的提升(各类平台的搭建、二次开发等)以及测试效能的提升(改进测试过程,解决测试痛点等)。
![](https://img2022.cnblogs.com/blog/733625/202210/733625-20221018135907301-755214178.png)
以上3点理由,让测试同行更愿意走上测试开发这条道路,因为它是最能直观体现个人能力的(虽然不一定能解决问题,但至少看起来很唬人),
02 造轮子能给测试带来什么
通过写写平台,可以有效的提升测试人员的代码能力,主要有以下4个方面:
展示个人经验:团队在招测试开发的时候,最终还是要落地到代码层面,如果你有过造轮子的经验,那么会是个很好的加分项,你写过的平台在一定程度上能够反应你对平台和框架的理解,有助于后续的测开工作开展。
理解研发过程:自己写过代码,就可以比较清楚的知道主流框架的结构是什么样的,会用到哪些组件,这些组件是如何叠加在一起产生作用。会明白前后端是如何交付的,数据库应该怎么设计比较合理。这些内容都会有后续的测试工作中给测试人员带来非常大的帮助。
提升代码能力:写过平台和你只是练习语句,差异还是非常大的。通过写平台,能够把业务问题转换为代码实现,这个能力还是非常重要的。
更多的谈薪优势:这点是必然的。好的代码能力总归是加分项。
03 测试平台如何选择
04 测开的核心价值是什么
具体到团队中,对于测开的能力要求,我简单的划分为以下三类(欢迎拍砖):
入门级:
1. 熟悉几款常用的测试框架,如接口测试用到的Junit,Pytest等,性能测试用到的Jmeter,Locust等,基于UI的Selenium,Airtest等
2. 进一步的,能够针对这些框架,结合团队的具体业务需求,进行简单的二次开发,例如改改报告格式,增加点输出和特定函数等
从团队建设的角度看,这类技能一般会让测试团队内的谁对代码兴趣并能持之以恒的学习,就可以让他去尝试做这类工作。
提升级:
1. 了解不同框架的特性,能够结合不同项目的实际情况,做具体的选型(例如,团队如果普遍代码能力较差,用Jmeter做接口也不是不可以接受。如果被测试系统用的是JAVA框架,引入Junit要比Pytest合适的多)
2. 能够对框架进行重构,以便更好的使用或者更符合业务需求。能够把这些框架集成到其它平台,让其它平台能够快速调用并执行测试用例。
3. 能够洞察测试活动中的真实痛点,并给出解决方案。当你具备了这个能力,才能胜任一个测试开发应该有的责任,否则和开发的区别并不大,又或者只是一个有一定代码能力的测试人员。对团队的重要性并没有那么大。
进阶级:
1. 能够从全局观察测试活动,发现团队存在的共性问题,并提出自己的解决方案并加以落地。
2. 从效能的角度提升团队的测试质量和效率。个人认为,这个是高阶测试开发的核心竞争力。这个时候,测试开发应该关注的是如何提升整个测试团队的效能,同时能够打通研发侧,协助开发一起提升研发效能。
进阶级:
1. 能够从全局观察测试活动,发现团队存在的共性问题,并提出自己的解决方案并加以落地。
2. 从效能的角度提升团队的测试质量和效率。个人认为,这个是高阶测试开发的核心竞争力。这个时候,测试开发应该关注的是如何提升整个测试团队的效能,同时能够打通研发侧,协助开发一起提升研发效能。
3. 需要向业内优秀的团队学习最新的技术实践,现在新的测试技术层出不穷,迭代速度也很快。不能固步自封,只满足于现状。要关注业内技术的发展,但不要盲目地引入到团队中,因为很多时候,你的团队并不具备相对应的能力。
3. 需要向业内优秀的团队学习最新的技术实践,现在新的测试技术层出不穷,迭代速度也很快。不能固步自封,只满足于现状。要关注业内技术的发展,但不要盲目地引入到团队中,因为很多时候,你的团队并不具备相对应的能力。
05 技术为业务服务
见过很多不了解业务的测开,总感觉自己懂一些代码,写写平台,就可以高枕无忧了。其实这类人反而是最危险的。因为你总是在等别人给你任务,或者写一些高大上的功能,是否真的解决了业务问题?团队问题?如果不能解决实际的问题,你的代码能力就没什么值的炫耀的。总归还是要回到业务或者团队中去。代码只是解决问题的工具,并不是唯一解。没有勺子,你就不喝汤了么?