只会“点点点”，凭什么让开发看得起你？
众所周知，如今无论是大厂还是中小厂，自动化测试基本是标配了，毕竟像双 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 模型。
第二模块从一个订餐系统的例子出发，从单体应用升级到微服务集群，来观察测试需求的变化，通过逐层测试来全面验证需求。
第三模块一起推演模型设计。像开发的设计模式一样，自动化测试设计也应该有自己的方法论。
第四模块会提供一些度量模型和驱动改进的流程样例，一起思考怎么让一个项目始终可观测、可控，有反馈。保证项目始终在预定轨道上推进，即使有偏离，也能第一时间发现纠正回来。
下面是专栏的具体内容：
当然除了干货，我也为大家争取到了福利！ 