功能测试转测试开发的正确姿势

测试工作，通常被认为就是对着程序点点点。作为测试的你，是不是也这么想。

工作了 3~5 年，你可能对整个公司，甚至某个垂直行业的业务流程非常熟练了。对测试任务，能娴熟地进行优先级排序和可测试性分析；甚至能把它轻松地分解成可测试的工作模块；并且针对每一个测试模块，熟练地应用白盒或黑盒的方式进行测试用例设计，最终生成一份覆盖产品需求的、可执行性的测试计划。

在测试行业，这并不是个例。在无数个匆忙发版和 996 的不眠夜晚，你一定有过下面这些疑问：

为什么每次发版时间都这么紧张？这样“工具人”的工作何时能到头？

开发改动了核心代码， 我如何才能在这么短的时间内完成全量回归测试？

手工执行用例、多浏览器重复验证同个功能、单个功能多个测试环境一遍遍点过去……每天重复这样“点点点”的简单工作，我的职业生涯还有拓展空间吗？

这些问题看似没什么关联，但底层逻辑其实都是同一个，那就是：你的职业生涯的下一步应该怎么走？又应该如何安全度过职业生涯的第一个瓶颈期？

功能测试应该何去何从？

目前业界比较清晰的发展路径有两条：一个是业务型测试，另一个是技术型测试，我们看下它们各自的发展路径，如下图所示：

左侧的业务型测试，多见于比较复杂的特定业务场景的行业，比如银行业。若想成为某一领域的业务专家，所需要的付出并不亚于走技术路线，但是相对于技术路线来说，业务路线会把自己的