群里经常有人在讨论一个问题,“我会利用某某框架写自动化测试脚本,算不算是测试开发了呢?在面试的时候,这项技能是否有较大的加分?”。自己从事多年的测试开发,对测开有一定的了解,再结合业内的普遍经验来看,只能说,会利用某个框架写几个自动化脚本,算不上什么测开。通常,这项技能会归结到业务测试团队。
测开与开发的区别
上图是个人总结的开发与测开的异同(欢迎一起讨论):
**注:在当下,具备DevOps知识和能力,会是一个较大的加分项,但是越往后,这项技能就是越普及,终将变成一项基本能力,还不具备的同学要加油了哟。
测开的能力要求
具体到团队中,对于测开的能力要求,我简单的划分为以下三类(欢迎拍砖):
入门级:
从团队建设的角度看,这类技能一般会让测试团队内的谁对代码兴趣并能持之以恒的学习,就可以让他去尝试做这类工作。
提升级:
进阶级:
这里有一个很有趣的说法:我不懂技术,但是我熟悉业务,能不能招个能力强的开发,一起合作?在某种程度上讲,这个有点自欺欺人。因为大多数情况下,你的表达并不会比专业的产品经理强。产品经理和开发会吵到什么程度你又不是不清楚,对吧。所以,做为测试人员,沉下心来,学习学习代码,并在实际的业务场景中去落地,比什么都强。代码能力已经成为测试人员的一项基本能力了。如果你一窍不通,测试之路将很难再往下走了。
当下的测试环境已经发生了很大的变化,DevOps理念被越来越多的团队所接受,越来越多的团队在实践DevOps相关内容,测试团队一直在被弱化。但是,测试职能却一直在提升,不管是需求侧的DOD,还是研发侧的TDD,DDD,都在强调可测试性,强调质量保证。所以,如何在敏捷研发中突显测试职能的价值,成为了全体测试人员都应该思考的一个话题。在当下的大环境中,测试活动如何改善整体的研发效能,有效的缩短反馈路径,成为了大家共同追求的目标。
在测试的职业发展道路上,还有一个职能是测试架构。对于测试架构师而言,他需要的是“端到端”的测试把控:
在需求侧,他需要去了解产品的商业目标,去梳理用户的使用场景,输出产品的整体测试策略。
在研发侧,他能够与研发架构师一起面对面沟通,保证研发过程的可测试性,了解技术选型的前因后果,有针对的了解所选技术架构的常见问题并加以提醒,减少在项目研发初期就埋下的“雷”
在测试侧,需要能够做更好、更有效的测试策略,协助团队尽早的开展测试活动,解决他们遇到的问题,有效的平衡测试效能
在运维侧,协助完成产品的上线,并做好线上监控,尽早、尽快的发现问题,减少损失。
如果大家对测试架构师想要了解更多,可以在《测试架构师修炼之道》中找到更多的答案。这本书非常推荐测试人员去看看,去学习。