本文内容是 5 月 21 号在深圳第 13 届 MeetUp 上的分享记录，主题是 “测开造轮子漫谈”，缘由是观察到了现在大多数的测试同行都是卷测试平台（是就 “造轮子”），各类接口的，UI 的平台也见了好多，这是不是个好的现象呢，接着往下聊。

01 测试人员在卷什么

外圈主要是从行为上提升，比如加班（虽然没什么用，但态度有时候也能体现一些好处）、深入业务，从业务的积累上提升竞争力（只针对特定领域有用，比如金融），敏捷测试（从做事的方法上做出改变，进行新的尝试），内圈主要是从能力上提升，比如专项测试的开展（接口应该不能算专项测试了，基本上是测试人员的必备技能。性能、安全、混沌工程这类的），开发能力的提升（各类平台的搭建、二次开发等）以及测试效能的提升（改进测试过程，解决测试痛点等）。

以上 3 点理由，让测试同行更愿意走上测试开发这条道路，因为它是最能直观体现个人能力的（虽然不一定能解决问题，但至少看起来很唬人），

02 造轮子能给测试带来什么

通过写写平台，可以有效的提升测试人员的代码能力，主要有以下 4 个方面：

展示个人经验：团队在招测试开发的时候，最终还是要落地到代码层面，如果你有过造轮子的经验，那么会是个很好的加分项，你写过的平台在一定程度上能够反应你对平台和框架的理解，有助于后续的测开工作开展。

理解研发过程：自己写过代码，就可以比较清楚的知道主流框架的结构是什么样的，会用到哪些组件，这些组件是如何叠加在一起产生作用。会明白前后端是如何交付的，数据库应该怎么设计比较合理。这些内容都会有后续的测试工作中给测试人员带来非常大的帮助。

提升代码能力：写过平台和你只是练习语句，差异还是非常大的。通过写平台，能够把业务问题转换为代码实现，这个能力还是非常重要的。

更多的谈薪优势：这点是必然的。好的代码能力总归是加分项。

注：笔者也见过只是纯粹复制别人的代码，就说是自己研发的情况。这类场景需要在面试的时候多加识别，其实也很容易就能问出来。毕竟做过和看过是两码事。

03 测试平台如何选择

面对那么多的测试平台，如何选择其实是非常考验团队 Leader 的。不管是采用成熟的平台，还是自研。都需要想清楚三个问题：

我需要平台解决什么问题？

团队的资源和成员能力是否可以支撑？

为什么要选它？

04 测开的核心价值是什么

具体到团队中，对于测开的能力要求，我简单的划分为以下三类（欢迎拍砖）：

入门级：

1. 熟悉几款常用的测试框架，如接口测试用到的 Junit，Pytest 等，性能测试用到的 Jmeter，Locust 等，基于 UI 的 Selenium，Airtest 等

2. 进一步的，能够针对这些框架，结合团队的具体业务需求，进行简单的二次开发，例如改改报告格式，增加点输出和特定函数等

从团队建设的角度看，这类技能一般会让测试团队内的谁对代码兴趣并能持之以恒的学习，就可以让他去尝试做这类工作。

提升级：

1. 了解不同框架的特性，能够结合不同项目的实际情况，做具体的选型（例如，团队如果普遍代码能力较差，用 Jmeter 做接口也不是不可以接受。如果被测试系统用的是 JAVA 框架，引入 Junit 要比 Pytest 合适的多）

2. 能够对框架进行重构，以便更好的使用或者更符合业务需求。能够把这些框架集成到其它平台，让其它平台能够快速调用并执行测试用例。

3. 能够洞察测试活动中的真实痛点，并给出解决方案。当你具备了这个能力，才能胜任一个测试开发应该有的责任，否则和开发的区别并不大，又或者只是一个有一定代码能力的测试人员。对团队的重要性并没有那么大。

进阶级：

1. 能够从全局观察测试活动，发现团队存在的共性问题，并提出自己的解决方案并加以落地。

2. 从效能的角度提升团队的测试质量和效率。个人认为，这个是高阶测试开发的核心竞争力。这个时候，测试开发应该关注的是如何提升整个测试团队的效能，同时能够打通研发侧，协助开发一起提升研发效能。

3. 需要向业内优秀的团队学习最新的技术实践，现在新的测试技术层出不穷，迭代速度也很快。不能固步自封，只满足于现状。要关注业内技术的发展，但不要盲目地引入到团队中，因为很多时候，你的团队并不具备相对应的能力。

05 技术为业务服务

见过很多不了解业务的测开，总感觉自己懂一些代码，写写平台，就可以高枕无忧了。其实这类人反而是最危险的。因为你总是在等别人给你任务，或者写一些高大上的功能，是否真的解决了业务问题？团队问题？如果不能解决实际的问题，你的代码能力就没什么值的炫耀的。总归还是要回到业务或者团队中去。代码只是解决问题的工具，并不是唯一解。没有勺子，你就不喝汤了么？

所以，你觉的测试造轮子好么？感谢收看、收听。

关注公众号"CKL 的思考空间" 并回复 “测试开发”，获取完整 PPT 及 B 站直播回放地址。感谢支持。

往期推荐：

从团队的角度理解自动化

你对测试开发是否有误解

构建性能测试知识体系