测开之路：大厂测试开发工作四年的感悟

news2025/1/21 3:14:38

经历

在两个大厂分别做了两年的测试开发工作，暂且成为 N 厂和 A 厂吧。负责过游戏自动化框架开发、专项测试工具开发、版本质量保障、Devops 平台开发，也带过小团队。每个厂，每份工作都力求突破，过程辛苦，自然结果都是很满意的，都拿到了不错的绩效。

测开的岗位定位

虽然在经历过的项目中，测开的定位大部分都是 “测试”，在 N 厂里面架构会比较特别，将测试开发与业务测试彻底分开。测试开发更多是做 测试平台和效能提升相关工作；业务相对单纯，整个团队会一起 面向功能测试痛点、研发痛点从质量检查角度出发做工具与平台，解决研发过程和测试过程的痛点。

这份经历回想起来，还是很有意义：做事非常专一，技术也获得了不少成长。唯一不足的是，这些工具、平台也好，是否真正让业务产生了更实质上的提升，很难去精准量化。后期也做了很多量化工作的事情，建设量化的数据模型；所以切入 Devops 赛道，学习了很多 Devops 理念，造了一些轮子。当然一个人的精力是有限的，在一个成本中心里面，想去做 Devops 是很容易上手，但是做完善一整套 Devops 落地，几乎不可能的。

后来的工作，就开始跟业务了，能非常明显感觉到，业务带队水平的提升，沟通能力的提升，更多从一个质量保障的角度去做质量输入和输出，也算是亲身体会到了 QA 这个职业的 “不容易”：人在工位坐，锅从空中来，深有体会。

两段不同的经历碰撞，对测试开发这个岗位有了更纵深的思考，包括岗位价值、核心竞争力、行业发展有了一些思考。

大厂测试开发教程：2023全网最牛，字节测试开发大佬现场教学，从零开始教你成为年薪百万的测试开发工程师_哔哩哔哩_bilibilihttps://www.bilibili.com/video/BV1hX4y187wi/?spm_id_from=333.999.0.0

测开核心价值

测开的定位既然也是测试，那么它的核心价值其实一句话可以总结：为质量买单，为产品保值，为过程降本。

测开本质上归属于测试序列，哪怕再厉害的测试技术、测试平台、测试工具，不要被这些所谓的 “高大上” 的技术名词掩盖了真相。做这些自动化、平台工具最终都是为了更短的时间、更低的成本输出质量，然后（这里是重点）根据输出的质量去买单。这里说的直白一点，做的这些事情当然有意义，但是跳出本位思维，站在老板，站在项目经理的角色去看待，想要的只是质量结果和谁为这些结果买单。

总有人需要为结果买单，为过程买单，核心价值也就出来了。作为测试序列的一员，最重要的存在即为质量买单。也就催生出了，为什么测试要负责过程管理、左移右移，很少见到开发提到右移到测试。测试岗位的内容自然就杂而不精了：不是一个很合格的项目管理、却又要参与项目管理环节；不是一名单纯的技术，却又要在业务测试中兼顾工具开发。甚至个别项目或者公司要求测试也要负责需求的质量把控。

因此，在一个买单岗位他的存在大部分除了输出质量之外，本身不产生直接的商业价值，成为了一个背负成本的节能减排部门。也就是上面提到的为质量买单，为产品保值，为过程降本。

测开的职业瓶颈

在参与了很多项目之后，越来越能体会到，对话维度不同的平台，更能体现测试岗位的无力感，也是焦虑感。当你明白了核心价值后，那么谈发展时候，谈行业纵深时候，就会发现很现实的问题：

部分项目核心的前后端业务逻辑和代码是保密的，或者只开放冰山一角，很难真正全貌去做业务纵深，不利于个人的长线成长；
测试序列作为一个成本保值部门，自然要肩负很多杂活脏活，零碎的时间和权限壁垒很难像做一款产品一样，去完整形成价值链，没有价值链谈什么个人价值呢；
技术路线的测开会发现，纯测试开发技术大部分都服务于 QA 或者小部分人群，这些系统都未经标准化的开发管理，也没有外网的海量验证，技术的深度和广度在上游开发看来，不值一提。