群里经常有人在讨论一个问题，“我会利用某某框架写自动化测试脚本，算不算是测试开发了呢？在面试的时候，这项技能是否有较大的加分?”。自己从事多年的测试开发，对测开有一定的了解，再结合业内的普遍经验来看，只能说，会利用某个框架写几个自动化脚本，算不上什么测开。通常，这项技能会归结到业务测试团队。

上图是个人总结的开发与测开的异同（欢迎一起讨论）。
服务对象不一样：通常情况下，开发人员对面的是具体业务需求，是在有明确研发目标的情况下进行研发活动，在敏捷的环境下，这点更为明显，因为可被研发的需求一定是个清晰的 “故事”。而测试开发，则更多的需要自己从当前测试团队中，去寻找测试活动、测试流程中的痛点，并加以改进。产出物可以是个小工具，可以是某个框架的定制化开发，也可以是多个平台的集成。

验收标准不一样：开发在实现具体的业务需求时，除了满足功能性要求外，还需要满足各类非功能性需求（性能、操作性、安全性等等），而测开的产出物更多的只是在团队内部使用，对于性能和操作性，甚至于 UI 都不会有太高的要求，主要以解决实际问题为主（当然能同时兼顾到这些更好）。

测开与开发的相同点：就是对代码能力的要求是一样的。至少要熟悉某个语言（JAVA，Python 都可以，不应该有语言鄙视链存在），同时熟悉这个研发语言中的某些常用框架（Spring 全家桶，Django，各类中间件如 MQ、Redis 及常用数据库如 Mysql），需要具备一定的研发思维，把业务转换成代码并加以实现。

注：在当下，具备 DevOps 知识和能力，会是一个较大的加分项，但是越往后，这项技能就是越普及，终将变成一项基本能力，还不具备的同学要加油了哟。

测开的能力要求

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

入门级：

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

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

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

提升级：

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

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

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

进阶级：

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

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

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

这里有一个很有趣的说法：我不懂技术，但是我熟悉业务，能不能招个能力强的开发，一起合作？在某种程度上讲，这个有点自欺欺人。因为大多数情况下，你的表达并不会比专业的产品经理强。产品经理和开发会吵到什么程度你又不是不清楚，对吧。所以，做为测试人员，沉下心来，学习学习代码，并在实际的业务场景中去落地，比什么都强。代码能力已经成为测试人员的一项基本能力了。如果你一窍不通，测试之路将很难再往下走了。

当下的测试环境已经发生了很大的变化，DevOps 理念被越来越多的团队所接受，越来越多的团队在实践 DevOps 相关内容，测试团队一直在被弱化。但是，测试职能却一直在提升，不管是需求侧的 DOD，还是研发侧的 TDD，DDD，都在强调可测试性，强调质量保证。所以，如何在敏捷研发中突显测试职能的价值，成为了全体测试人员都应该思考的一个话题。在当下的大环境中，测试活动如何改善整体的研发效能，有效的缩短反馈路径，成为了大家共同追求的目标。

在测试的职业发展道路上，还有一个职能是测试架构。对于测试架构师而言，他需要的是 “端到端” 的测试把控：

在需求侧，他需要去了解产品的商业目标，去梳理用户的使用场景，输出产品的整体测试策略。

在研发侧，他能够与研发架构师一起面对面沟通，保证研发过程的可测试性，了解技术选型的前因后果，有针对的了解所选技术架构的常见问题并加以提醒，减少在项目研发初期就埋下的 “雷”

在测试侧，需要能够做更好、更有效的测试策略，协助团队尽早的开展测试活动，解决他们遇到的问题，有效的平衡测试效能

在运维侧，协助完成产品的上线，并做好线上监控，尽早、尽快的发现问题，减少损失。

如果大家对测试架构师想要了解更多，可以在《测试架构师修炼之道》中找到更多的答案。这本书非常推荐测试人员去看看，去学习。