|
|
|
|
|
# 开篇词 | 做性价比最高的自动化测试
|
|
|
|
|
|
|
|
|
|
|
|
你好，我是柳胜。很高兴通过这个专栏和你探讨自动化测试。
|
|
|
|
|
|
|
|
|
|
|
|
先简单介绍一下我自己，我在摩托罗拉和甲骨文做过开发工程师、测试工程师、测试经理和高级开发经理。从B端的企业应用测试到C端的云计算开发，我都做过。在甲骨文工作的13年时间里，我带领团队设计、开发了Automation Center框架，补全了视频会议二十多年来的自动化测试解决方案空白。
|
|
|
|
|
|
|
|
|
|
|
|
相比开发，我在自动化测试领域里得到的收获最多，教训也最多。因此，我把这些踩坑的血泪史总结沉淀，期待通过专栏的形式分享给你，帮助你在自动化测试的职业工作中，建立全局思维，找准工作的焦点，让手中的测试项目事半功倍。
|
|
|
|
|
|
|
|
|
|
|
|
## 自动化测试的终点是什么？
|
|
|
|
|
|
|
|
|
|
|
|
刚入门的自动化测试工程师，很容易陷入到工具和框架的汪洋大海里。的确，从代码静态扫描到单元测试、API测试、系统测试、性能测试，每个细分领域的工具都不少。
|
|
|
|
|
|
|
|
|
|
|
|
但是，工具之后呢？
|
|
|
|
|
|
|
|
|
|
|
|
从普通开发到架构师，软件开发的职业体系清晰可见。测试则不然，我观察过业界自动化测试人员的职业发展路线，有的公司有自动化测试架构师这个职位，有的公司设立了测试架构师，自动化架构算作测试架构师的职责之一，更多的公司根本就没有自动化测试的高级角色，各个产品线测试和开发混在一起玩。
|
|
|
|
|
|
|
|
|
|
|
|
我也问过测试业界不少朋友，你的公司为什么要自动化测试？预期的效果是什么？
|
|
|
|
|
|
|
|
|
|
|
|
答案是五花八门，有的说是节省手工开支，有的说是业界趋势，还有的说我们研发领导非常重视，干就是了。在团队中，基本认识都出现了这么大的差别，后面的乱象就出来了，项目投入不稳定，可多可少跟着感觉走。自动化测试人员严重缺乏表达自己工作价值的话语权，被迫和开发人员一起内卷技术工具。
|
|
|
|
|
|
|
|
|
|
|
|
经历了这些，你甚至怀疑自动化测试工作的尽头就是工具，随后一边“内卷”，一边在忙碌中更加迷茫。其实，**要想成为高手，就必须要看到并解决更有价值的问题，对更高的结果负责**，对应的职位和收入会随后而至，它可能叫自动化架构师，也可能叫测试专家，或什么ABC。
|
|
|
|
|
|
|
|
|
|
|
|
既然说到“更高的结果”，我们就有必要以终为始，先想想自动化测试的最终结果是什么？换个问法，自动化测试的最终交付价值是什么？
|
|
|
|
|
|
|
|
|
|
|
|
* 是自动化跑起来么？这个要求太初级了。
|
|
|
|
|
|
* 是领导满意么？我见过很多案例，一个自动化测试项目因一个领导的支持而发起，但成也萧何，败也萧何，往往也因为换了一个领导，项目就半途而废。
|
|
|
|
|
|
* 是100%自动化么？理想很丰满，现实很骨感，高度自动化并不会一定带来高质量，我也见过开发人员为了达到100%单元覆盖率，就写一个Test函数，把程序运行起来了事，有的连一个检查点都不做。
|
|
|
|
|
|
|
|
|
|
|
|
所有这一切，都让我深深意识到，无法清晰认知自动化测试的价值，测试工作就会举步维艰。在我看来，**自动化测试项目的最终交付价值是它产生的效益，也就是投入回报率比ROI。一个成功的自动化测试项目必然是获得了高ROI的收益**。自动化测试高手就是要做出成功的自动化测试项目。
|
|
|
|
|
|
|
|
|
|
|
|
## 怎样成为高手？
|
|
|
|
|
|
|
|
|
|
|
|
明确了目标，我们还需要找到高效的实现路径。
|
|
|
|
|
|
|
|
|
|
|
|
**我对自动化测试架构师的定义是，不仅仅是写代码让自动化测试跑起来，而且能够超脱于工具框架的层面，对测试需求和自动化ROI一起抽象建模，对自动化测试项目的最终ROI负责。**
|
|
|
|
|
|
|
|
|
|
|
|
为了达到这个目标，有两种学习路径。
|
|
|
|
|
|
|
|
|
|
|
|
第一是升级打怪型。
|
|
|
|
|
|
|
|
|
|
|
|
先是提高代码能力，学习编程、操作系统和数据库。这个的确很重要，尤其对于刚入门的朋友，首先搞一个Hello World程序，有个感官的体验，后面再逐步深入。
|
|
|
|
|
|
|
|
|
|
|
|
然后是工具能力，使用各种工具和框架，Xunit系列、API测试框架、系统测试工具，编写自动化测试案例，运行、出报告，之后和DevOps pipeline集成。
|
|
|
|
|
|
|
|
|
|
|
|
最后是架构能力，熟悉测试需求和技术架构，设计自动化测试整体方案和技术路线，能够选型工具和框架，搭建测试基础设施。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
这是我们熟知的自底向上学习路线，是认知方法的归纳法。见过的鱼多了，就知道鱼是什么了，逐渐积累捕鱼的经验。这个方法的优点是门槛低，缺点是耗时，周期长。
|
|
|
|
|
|
|
|
|
|
|
|
第二种是航海指南型。
|
|
|
|
|
|
|
|
|
|
|
|
和第一种方法相对应，另外一种认知学习方法是自顶向下，属于认知方法中的演绎法。从道术器三个层面从高到低推进，每一步都有自己的逻辑。
|
|
|
|
|
|
|
|
|
|
|
|
知道什么是鱼和它的游动规律，就相当于带着导航去捕鱼，甚至你还可以发明新的捕鱼工具。这个方法优点是速度快，但需要你自带脑袋瓜，跟着我一起思考。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
**专栏中我们采取的学习方法是以自顶向下为主，自底向上为辅。**通过整个专栏的学习，你将系统了解自动化测试的道、术、器，同时收获一种颠覆性的认知，跳出工具和框架的层面重新审视自动化测试设计，知道自己想要什么样的自动化测试架构。
|
|
|
|
|
|
|
|
|
|
|
|
自动化测试道的部分，主要是逻辑和常识，你不需要有工作经验和技术，也能听得懂，我期望你会和我一起演绎思考，就是说，这些方法如果应用到我的工作，会怎么样。
|
|
|
|
|
|
|
|
|
|
|
|
术的部分会涉及度量数据分析、代码逻辑和Job建模，这个也对应着软件开发里的数据、算法和建模。我会在GitHub上创建一个[repo](https://github.com/sheng-geek-zhuanlan/autmation-arch)（随课程进展陆续更新），放入专栏所讲到的整体代码和相关文件，希望你能动脑思考，动手运行代码。手脑结合，学习效果会更好。
|
|
|
|
|
|
|
|
|
|
|
|
器，也就是工具和框架。在第三讲里会列出业界主流工具框架以及选择策略和落地实践。在每个模块里也会穿插一些具体的落地案例，介绍相应的工具和代码相关例子。
|
|
|
|
|
|
|
|
|
|
|
|
不过，本专栏里具体工具和代码的篇幅不会超过20%。我这样克制，是因为这些东西网上搜搜也能免费获取。我会在最后附上全栈自动化测试工具列表，从单元测试到性能测试相关的网站地址。相信你通过自学，就能掌握个七七八八。
|
|
|
|
|
|
|
|
|
|
|
|
授之以鱼，不如授之以渔。我不希望你一下子扑到工具技术的茫茫大海里，等过几年之后，有一种学不完、学不精、用不好的绝望，这都是我曾经历过的。如果能再来一次，我更愿意早点了解鱼的规律，带着导航驶入大海，有方法地探索，最后满载而归。
|
|
|
|
|
|
|
|
|
|
|
|
## 这门课如何安排
|
|
|
|
|
|
|
|
|
|
|
|
课程一共分成了四大模块，分别是：价值篇、策略篇、设计篇与度量篇，自动化测试的道、术、器会贯穿其中。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
**第一模块价值篇**会带你重新审视自动化测试的基本概念和规律，掌握自动化测试效益的量化思维方法——**投入产出比ROI模型**。它是自动化测试项目成长的DNA，也是隐藏的命脉，在工作中紧紧抓住它，效果就来了：自动化测试使用的场景越来越丰富，越来越稳定和可信，交付发布的速度越来越快。
|
|
|
|
|
|
|
|
|
|
|
|
这些都可以帮你在述职报告中，用ROI的方式表达业绩，比如：“老板，我做的自动化测试案例，去年一年被n个场景使用，重复运行x次，发现bug y个，节省手工工作量z人月”。
|
|
|
|
|
|
|
|
|
|
|
|
ROI如何落地呢？我们会从立项、设计、代码、运营各个阶段逐步深入解读。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
通过这个模块的学习，你会获得一个新的思维角度，用它来审视自动测试项目，判断项目中哪些是过度工作，哪些是工作做得还不够。同时你也掌握了一门和管理者和团队沟通的语言，在述职、评审等交流环节，能把自己工作的价值表达清楚。
|
|
|
|
|
|
|
|
|
|
|
|
到了**第二模块策略篇**，我们会从一个订餐系统的例子出发，从单体应用升级到微服务集群，来观察测试需求的变化。针对微服务集群关系复杂、依赖多的挑战，建立起多层测试策略：单元测试、集成测试、接口测试、契约测试、UI测试和验收测试，通过逐层测试来全面验证需求。
|
|
|
|
|
|
|
|
|
|
|
|
每一种测试策略，我会用一讲的篇幅来讲述它的方法论和工具，能做什么、不能做什么，如何设计自动化测试案例。
|
|
|
|
|
|
|
|
|
|
|
|
在**第三模块设计篇**，我们一起推演模型设计。像开发的设计模式一样，自动化测试设计也应该有自己的方法论。
|
|
|
|
|
|
|
|
|
|
|
|
这里我提出的微测试Job模型，也是业界首创，会让你耳目一新。在这个Job模型里，没有TestSuite和TestCase的概念，也没有具体工具和框架的依赖，而是面向测试需求和自动化测试ROI要求设计。它可以帮你厘清测试的场景、工作流、需要代码实现的案例原子，同时内建自动化测试ROI需求，这正是自动化测试设计阶段需要关注和要做的事情，对吗？
|
|
|
|
|
|
|
|
|
|
|
|
基于Job模型的设计产出是一个XML的树形结构文档，描述了我们的自动化测试任务，基于这个需求，我们的工具选型就会更加科学。**一个测试案例，A工具和B工具都能做自动化，那它们都可以去实现需求，将来它们被替换成C工具，对其他案例没有影响，我们的自动化测试设计也依然保持不变。这就保证自动化测试项目有了持续重构优化的能力，而不是走向腐化。**
|
|
|
|
|
|
|
|
|
|
|
|
同时，我给出了3个案例，分别针对领域业务型金融交易自动化测试设计，DevOps型持续集成pipeline设计，分布式型的复杂场景视频会议系统自动化测试设计，帮助你理解怎么使用Job模型来设计不同的自动化测试场景。
|
|
|
|
|
|
|
|
|
|
|
|
掌握了怎么把一个自动化测试项目送入到它的运行轨道，就可以坐享ROI的红利了么？不，还不够，你还要考虑怎么让这个项目始终可观测、可控，有反馈，这样就能保证这个项目始终在预定轨道上推进，即使有偏离，也能第一时间发现纠正回来。在**第四模块度量篇**，我还会提供一些度量模型和驱动改进的流程样例，供你参考实践。
|
|
|
|
|
|
|
|
|
|
|
|
另外，本专栏提出了不少新的方法论，3KU测试金字塔（第二讲），Job模型（第十七讲），而且是业界第一次出现，你刚看到不一定会很快适应。有时可以多看几遍，我相信你每次看都会有不同的收获。
|
|
|
|
|
|
|
|
|
|
|
|
马斯克最近说过一句话，我对此很有感触，也分享给你：
|
|
|
|
|
|
|
|
|
|
|
|
> 死亡对我们来说很重要，因为大多数时候人们不会改变主意，他们只是死去。如果人们长生不老，我们可能会成为一个非常僵化的社会，导致新想法无法成功。
|
|
|
|
|
|
|
|
|
|
|
|
我思故我在，思维的碰撞是痛苦的，也是快乐的。期待你加入我的自动化测试专栏，一起扬帆探索自动化测试的深海区！
|
|
|
|
|
|
|
