网上经常有个争论：程序员自己不能测吗？为什么非要单独设一个测试岗？

答案很直接：能做，但做不全，也做不久。

如果一个程序员愿意投入时间，理解业务、设计场景、准备数据、验证结果、持续回归，他当然能承担很多测试工作。但做到这一步，他其实已经在干测试工程师的活了。

问题从来不是“能不能”，而是“值不值、持续不持续、谁来兜底”。

一、一个“导出”按钮，藏着多少你想不到的坑

说个很普通的场景。

后台系统列表页，加了一个“导出”按钮。开发写完代码，点一下，文件下载成功，数据也对。

一次有效验证，没问题。

但接下来这些事呢——

• 普通成员和管理员，导出的数据范围一样吗？

• 页面上设了筛选条件，导出的数据跟不跟着变？

• 用户切换了组织，会不会把上一个组织的数据带出来？

• 导出到一半，权限被撤了，结果该怎么处理？

• 数据量上万条时，导出会不会把数据库跑挂？

这些问题，程序员当然也能想到。但它们需要有人专门花时间梳理，有人明确预期结果，有人准备对应的数据和环境，再一条条验证清楚。

没人做，这些场景就永远停留在“理论上应该没问题”。

二、同样是“点一下”，普通用户和测试的区别在哪

有人说，测试不就是拿软件点一点吗？

真不是。

普通用户完成一次导出，拿到文件就结束了。

测试要做的是：根据业务规则，构造不同的角色、不同的数据状态、不同的操作顺序，再判断结果是否符合预期。

有时候，最难的甚至不是“测”，而是先把“正确结果究竟是什么”问清楚。

比如：员工被移出一个组织后，他之前创建的导出任务还应不应该继续执行？文件还能不能下载？

这个问题需求文档里可能一个字都没写。测试把它提出来，推动产品和开发明确规则——这件事本身就在创造价值。

三、“顺手测”和“持续负责”，是两码事

还有人说：开发写完顺手测一下不就行了？

顺手验证和持续负责，投入程度完全不是一个量级。

一个功能上线之后，后续可能有人改权限逻辑，有人换筛选组件，有人优化查询接口。每个人改的看起来都合理，但拼在一起，导出功能可能又挂了。

这时候需要有人持续关注：

• 这次改动影响哪些流程？

• 哪些历史问题需要回归？

• 时间只剩半天，先验证什么？

• 还有哪些风险根本没测到？

这些问题的答案，直接决定版本能不能发。

开发有开发的主线任务，让他每次都兜底全链路的回归验证，既不现实也不经济。

四、测试真正的壁垒：把经验留给团队

测试还有一个经常被忽略的价值：把踩过的坑变成团队的资产。

某位同事知道“改了成员权限，记得检查导出”，这当然有价值。但如果这件事一直靠他记着，他一请假、一换项目，或者大家赶着上线，就可能漏掉。

如果能把这段经验整理成明确的测试场景、操作步骤和结果判断，后面的版本就能持续复用。

这也是自动化测试真正的意义：让适合重复验证的流程持续跑着，把人的时间留给新变化、复杂判断和未知问题。

五、岗位名称可以变，但这些工作总要有人做

当然，也不是所有团队都必须设专职测试。

业务简单、失败代价低、开发已经建立了完善的验证机制，由开发承担测试完全可以。

但随着系统越来越复杂——业务流程长、权限关系密、服务依赖多——质量验证就需要更明确的投入和分工。

岗位叫不叫“测试工程师”不重要。重要的是：

• 谁来选择测试条件

• 谁来定义预期结果

• 谁来准备数据和环境

• 谁来持续回归

• 谁来沉淀验证经验

这些事，总要有人扛。

六、所以，测试工程师的价值到底是什么

一句话概括：

用有限的时间找出值得关注的风险，提供足够清楚的验证证据，并把这些经验沉淀下来，让后续交付更可靠。

找bug是这种价值最直观的表现。

让团队知道哪里已经验证过、哪里仍有不确定性、下一次怎么避免重蹈覆辙——同样是实打实的贡献。

程序员当然能做测试，而且应该具备测试思维。但专职测试存在的意义，不是替开发“擦屁股”，而是用专业的视角、持续投入和系统化方法，把质量这件事从“碰运气”变成“可管理”。

这才是测试工程师真正的护城河。

EEC工信教考中心，软件测试工程师，北京青蓝智慧科技

马老师135-2173~0416

丁老师135-2209~4648