不要仅限于只做测试工作

前几天写了篇性能测试如何入门实践的文章，技术交流群有位同学截取了其中一段表达了自己的观点：性能瓶颈定位和优化，应该是研发来做这件事。然后群里其他同学纷纷参与了这个话题的讨论，表达的观点主要有下面几种：

• 现在技术岗位的职责已经没有明确界限了；

• 性能瓶颈定位优化研发来做，那测试的层次太低了；

• 测试除了做好测试工作，还应该做生产环境的根因分析；

• 如果没有专门的 SRE 团队，那性能根因分析就应该 QA 来做；

我观察了群里同学的发言，可以看到测试圈子整体的认知水平和职责范围相比以前，有了明显的提升。但还是有部分同学依然用原有的思维来看待测试这个岗位，心里不免有点戚戚焉。

这篇文章，我想聊一些我的看法，关于软件测试这个岗位当下的处境，以及未来的发展空间。

软件测试岗位和职责定义

话题要从软件工程说起，最初 IT 行业的分工，应该是从软件工程的角度分工的。从软件工程的角度来说，要研发交付一款软件产品，大概要经过需求、研发、交付三个阶段。而研发阶段细分的话，可以参考瀑布模型：

研发阶段主要分为需求分析、方案设计、编码实现、测试验证、运维发布五个阶段，然后自然而然出现了产品经理、开发工程师、测试工程师、运维工程师等角色。从软件研发交付流程来说，测试工程师的岗位职责主要有如下几项：

• 分析需求：得到这个迭代需要测试的功能点；

• 设计测试方案：如何开展这些功能点的测试工作；

• 设计测试用例：功能点的最小模块，力求尽可能覆盖涉及的场景；

• 测试用例执行：执行测试用例，验证每一个场景的功能实现是否符合预期；

• 跟踪缺陷状态：发现 bug、提交 bug、跟踪 bug 状态、bug 修复验证、关闭 bug；

• 出具测试报告：对本次迭代的测试活动进行完整统一的说明，承诺经过测试满足产品设计预期标准；

软件测试工程师要干的事情主要就是这几项，大多数测试同学在大学学习的课程或者初入职场时，做的也都是这些事情。如果 IT 行业的方法论和知识理念一直不变，商业活动和业务需求一直保持如此状态，IT 技术一直不变，那么这些事情可以保持很久不变。

但是，无论是商业活动还是业务需求抑或 IT 技术一直是变化的，岗位职责也应该跟着变化。

不要被岗位限制了发展空间

近几年软件行业的变化速度在不断加快，从迭代模型、业务需求变更速度到 IT 技术都在变化。

• 迭代模型：瀑布模型、双 W 模型、敏捷方法、版本火车；

• 需求迭代速度：三个月、一个半月、双周、一周一版本；

• IT 技术的变化：单体服务、集群服务、分布式架构、微服务架构、容器化、云原生；

随着这些因素的变化，行业对测试工程师的要求也在不断升级：

• 从最初的 QC(质量验证)到现在的 QA(质量保障)；

• 从点点点到现在啥都要会(写代码/搭环境/线上跟进)；

• 工作范围从测试环境向两头扩展(测试左移/测试右移)；

加上当下如此低迷的就业形势，如果还固守最初对软件测试的认知，不主动学习提升自己，那很快就会被淘汰。我并不是在危言耸听，也不想加深大家的焦虑，近几年程序员“35 岁失业”的梗甚嚣尘上就可见一斑。

IT 行业的特点就是不断涌现新技术新方法，替代原有的老技术旧方法，这本身就是技术进步和生产效率提升的必然结果。今年爆火的 ChatGPT，做技术的同学应该或多或少都有感受。

当然，如果只把软件测试当作一个谋生的手段，做不下去就转行做其他工作，也没错。从事什么行业，做什么工作本身就是个人的选择，没有好或者不好，也没有对错之分。

但如果想在这个领域，在软件测试这个岗位上不断的发展进步，那我个人的建议是：摒弃以往对软件测试的固有认知，不断提升自己的技术能力，不断扩展自己的职能边界，去做更多的能提升效率创造价值的事，才是一个合格甚至优秀的软件工程师该有的职场发展道路。

注意，这里的主语，我并没有说软件测试工程师，而是软件工程师。软件测试只是一个术语，不要将其当作一个能吃一辈子的岗位，成为一个能提高效率和提升软件质量的工程师，才是软件工程最初的理念：解决软件研发过程的不可控因素，聚焦于质量，构建和维护高质量软件。