只会“点点点”，凭什么让开发看得起你？

Posted 2022-04-02 软件测试自动化测试

众所周知，如今无论是大厂还是中小厂，自动化测试基本是标配了，毕竟像双 11、618 这种活动中庞大繁杂的系统，以及多端发布、多版本、机型发布等需求，但只会“写一些自动化脚本”很难胜任。这一点在招聘要求中就能看出来。

然而，现实却很难招到一个成熟的自动化测试工程师。

最近我面试了不少来自大厂的测试工程师：华为、沃尔玛、腾讯、字节……等等，每次都以为稳了，寻思在大厂应该都参加过自动化测试吧，实际却是很多工作 10 年的测试工程师，仍然在做功能测试，或是以功能测试为主。

为什么自动化测试人才稀缺？我归纳了 3 点：

• 对自动化测试领域局限在工具和框架的使用，缺乏整体认知；

• 对于自动化测试设计理解不深入，一些方法、套路停留在概念理解，无法灵活运用；

• 测试工作的价值被低估，长期发展受限，被迫和开发人员一起内卷技术工具。

做性价比最高的自动化测试

先思考下，我们自动化测试的“终点或价值”是什么？

• 是自动化跑起来吗？这个要求太初级了；

• 是领导满意吗？有时因为换了一个领导，项目就半道中卒；

• 是 100% 自动化吗？高度自动化也并不一定会带来高质量；

好像一时半会很难说清，自动化测试的价值是什么。直到我看到了下面这张图，完全颠覆了我的认知 —— 自动化测试项目的最终交付价值是它产生的效益，也就是投入回报率比 ROI。

乍一听，有点难理解，但仔细一想，可不就是这么回事吗。

打个比方，在年终述职报告中时，用 ROI 的方式表达业绩：“老板，我做的自动化测试案例，去年一年被 n 个场景使用，重复运行 x 次，发现 bug y 个，节省手工工作量 z 人月”。

是不是很直观？要想成为高手，就必须要看到并解决更有价值的问题，对更高的结果负责。

成为自动化测试高手

比起 80% 的测试工程师熟知的从“代码能力→工具能力→架构能力”的认知路线，这种新的模型，一下子打穿了测试高手工作的本质 —— 要懂业务、懂技术、懂架构，而不是局限在工具和框架上。

比起市面上只聊工具与框架、代码等像操作说明书一样的资料不同，专栏最吸引我的，是作者独创了很多「自动化测试」在业内第一次出现的方法论（下面详细说），带你跳出工具和框架的层面，重新审视自动化测试设计。

像专栏中老师和一位同学所探讨的：

现在很多测试人员都学习应用层上面的工具，很少从底层和架构上面思考问题

就导致只能写一些自动化脚本跑，但是无法了解问题本身的原因，特别是性能问题，很多测试人员都只知道加压跑起来，却不知道系统，网络，应用之间的关系。

专栏中涉及度量数据分析、代码逻辑和 Job 建模，也对应着软件开发里的数据、算法和建模，他还在 GitHub 上创建了一个 repo 放入专栏所讲到的整体代码和相关文件，方便大家动手运行。

当然，虽然 80% 的内容在于「认知」上的拔高，但他也会列出业界主流工具和框架，以及选择策略和落地实践，并附上全栈自动化测试工具列表。但这部分只占 20% ，毕竟这些东西网上都能搜得到。

百里是谁？

其实，之前就读过百里的文章，立刻被他新鲜的角度吸引，可以感受到他对测试岗位的理解非常透彻，这也源自于他独特的经历：

• 曾就职于摩托罗拉、甲骨文中国，历任测试经理、高级开发经理、测试总监等职位

• 带领团队设计分布式自动框架 Automation Center，填补了甲骨文 20 多年来在视频会议系统自动化测试领域的空白；

• Qcon 全球软件开发大会的讲师；

日常测试人的工作中，只能接触到“造轮子”的局部，视野受限。而像百里这样的实战专家，能让你从更高层次认识测试岗位，这才是最难得的。

为什么值得推荐？

一、颠覆认知

百里在专栏中提出了不少新的方法论，而且是业界第一次出现：

• “微测试 Job 模型”，在这个 Job 模型里，没有 TestSuite 和 TestCase 的概念，也没有具体工具和框架的依赖，而是面向测试需求和自动化测试 ROI 要求设计；它可以帮你厘清测试的场景、工作流、需要代码实现的案例原子等等；

• “ 3KU 矩阵”，用于梳理 UI 测试、接口测试和单元测试每个截面的测试能力；3KU 测试金字塔，分层测试各层有自己的关注点，但又能在整体上实现互相配合、补偿；

• 案例 DM 分析表，可以分析不同类型的自动化测试开发成本和维护成本；

• 工具四维度成熟度模型，用于框架选型分析决策；

• ......

这些还只是冰山一角，已经让我大开眼界、期待不已了。

二、内容体系化

百里把整个专栏拆分为了 4 个阶段：

第一模块带你重新审视自动化测试的基本概念，掌握自动化测试效益的量化思维方法——投入产出比 ROI 模型。

第二模块从一个订餐系统的例子出发，从单体应用升级到微服务集群，来观察测试需求的变化，通过逐层测试来全面验证需求。

第三模块一起推演模型设计。像开发的设计模式一样，自动化测试设计也应该有自己的方法论。

第四模块会提供一些度量模型和驱动改进的流程样例，一起思考怎么让一个项目始终可观测、可控，有反馈。保证项目始终在预定轨道上推进，即使有偏离，也能第一时间发现纠正回来。

下面是专栏的具体内容：

当然除了干货，我也为大家争取到了福利！