自动化测试高手价值篇

 自动化测试的最终交付价值是什么：自动化测试项目的最终交付价值是它产生的收益，也就是投入回报率比，ROI，一个成功的自动化测试项目必然是获得了高ROI的收益。
自动化测试高手就是要做出成功的自动化测试项目，不仅要写代码让自动化测试跑起来，
而且要超脱于工具框架的层面，对测试需求和自动化ROI一起抽象建模，对最终ROI负责。

sheng-geek-zhuanlan · GitHub

 自动化测试ROI

ROI计算公式

实践中，n 是测试案例的稳定回归次数

 1.ROI 大于 1 就是赚了，小于 1 就是亏了。那么，给定一个测试案例，要不要对它做自动
化，判断的依据是（自动化测试）预期 ROI 至少要大于 1。

2. 自动化测试是一个长收益模式。在理想情况下，是一次性投入（投入为开发成本），之
后每运行一次，就会增加一份产出。所以，时间越长，次数越多，收到的回报就会越大。（所以自动化测试用来做回归测试）

一个测试案例 A 做不做自动化测试？首先要看看它的 n 能有多大。

在实践中，找到 n 来估算 ROI，能帮你判断一个案例该不该做自动化。

通过 ROI 得出的三个核心观点：
1. 自动化测试是用来做回归测试的。
2. 自动化测试从哪里开始？实施顺序从 ROI 高到低，也就是（给定一个软件系统），优先
做回归次数最高的那部分功能，先做自动化回归次数最高的案例，再做低的，直到 ROI 等
于 1 的案例。在功能模块的初期，可以考虑先做手工测试。
3. 自动化测试什么时候开始？功能模块稳定的时候。

 实际上，有一个很好的测试实践可以匹配上面的要求，那就是冒烟测试。冒烟测试是测试
用例的子集，用来验证系统中基础的、影响发布软件的功能。甄选冒烟测试的一个常用办
法就是二八原则。

在软件领域，80% 用户，常用的是系统中 20% 的功能。冒烟测试覆盖的这部分 20% 功
能。

得到推论：在实践中，可以设定目标，冒烟测试 100% 自动化。这时，自
动化测试就可以和手工测试配合，形成一个新版本发布 + 冒烟测试的简单流水线。

文中提到的“冒烟测试”，我是否可以理解为产品主流程？还是说指的就
是持续集成中某个要提测feature的核心case？
作者回复: 我试着get一下你要说的意思哈，如果产品是基于work flow的，那么冒烟测试应该是产
品中那部分最常用最基本的flow path，应该就是你说的“产品主流程”。所以，冒烟测试的用途是
这样的，如果它失败了，其他的功能都不需要测了，直接返回开发修改。冒烟测试也可以用在很
多场景，提测feature是场景之一。

（个人观点：一般冒烟就是新功能的P1用例，是无法自动化的呀。可能这里指的冒烟是feature合并dev分支后，对dev分支进行的冒烟。）

 “听说你开发了个什么自动化脚本，它给公司带来了什么价值？用量化的数据给我讲一
讲。”

回答：目前每次发布时，回归测试用例有200条，这些用例在每次发布都需要执行，每年30次。

手工运行成本 t*30，开发和运维成本x ROI为t*30/x，

3KU法则：如何找出最优自动化实施截面？

 每层的 ROI。单元测试可以在开发人员每次 code commit 触发运
行，回归频率高；接口测试在每轮集成测试运行，回归频率中；UI 自动化测试在用户验收
测试，回归频率低。

 “自动化测试顺序从 ROI 高到低”，我们优先投入精力做 ROI 最高的单元测试，再做 ROI 中的接口测试，最后完成 UI 测试。

 FURPS 是用 5 个维度来描述一个软件的功能需求，FURPS 这个单词对应着每个需求的英文首字母：
F=Function 功能
U=Usability 易用性
R=Reliability 可靠性
P=Performance 性能
S=Supportability 可支持性

把测试需求和测试类型组合在一起，就整合了后面这个矩阵表格

 整体最优ROI 策略就呼之欲出了。什么是整体最优 ROI 呢？
有 3 个 Key（关键因素）：
这样分配的工作，既不重复，又没遗漏，还遵循了 ROI 的原则。
Useful: 每个测试需求都是有效的；
Ultimate: 每个测试需求的验证都在优先寻找自动化 ROI 高的层面去实现，如果不可
行，按照 ROI 高到低回退，直到 UI 层；
Unique: 每个层面上验证的测试需求都和别的层面都不是重复的。

3KU 策略该怎么执行呢? 按照 3KU 策略，我们把表格里的测试需求，对照下面这三个问
题，按顺序检查一遍：
1. 能在单元测试验证么？

2. 能在接口测试验证么？
3. 能在 UI 测试验证么？

UI 测试关注功能场景测试，易用性测试和可执行性测试；而接口测试关注不同数据的循
环，接口的性能和错误恢复能力；单元测试关注算法的正确性和性能。

 在 3KU 测试金字塔下，每一个测试需求都会选择最大的 ROI 测试截面，通过这样的安
排，实现了整体最优 ROI 的目标。

 03｜工具选择：什么工具框架值得用？

自动化测试案例是如何产生的，目前在业界，主要有 5 种方式。
方法一：录制和回放方法 

如selenium IDE

方法二：关键字编程

如 robot framework

方法三：模块库开发

方法四：BDD 混合框架

行为驱动开发，它通过 Gherkin 语法定义测试场景。

Gherkin 语法包含一套类自然语言的关键字：when、given、then，given 描述条件，
when 描述行为，then 描述结果。这样一个场景的 3 要素：上下文、动作和结果就说明白
了。如Cucumber。

 方法五：更高 ROI 的探索，自动化前沿技术

AI 根据规则自动生成测试案例

工具四维成熟度

选取工具的原则

1. 按照团队的技术能力、项目的预期长短、将来扩展的规模大小，选择 ROI 最大的工具框
架；

2. 当工具框架带来的 ROI 无法升高时，就考虑按照原则 1 重新评估，选择 ROI 更好的工
具框架。 

04丨脚本复用：什么样的代码才值得写？

提高复用率：一份代码，多浏览器运行

提高复用率：一份代码，多数据运行

提高复用率：一份代码，多环境运行

 dev，test，stage，productin 

提高复用率：一份代码，多语言运行 （用于产品支持多种语言）

降低自动化测试的维护成本，比
如：
1.Log 规范 +ELK+Grafana 实现告警实时传达。
2. 检查点 + 日志 + 屏幕截图甚至视频，提高诊断效率。
3. 高内聚低耦合的模块化设计，能够实现隔离错误，缩小影响范围，快速修复的效果。
4. 自动化测试上下线的标准和流程的建立。

05丨AutoGenAuto：所有测试工作即代码

黑盒测试领域的 Auto Gen Auto？

怎么做到 Auto Gen Auto 呢？用代码生成代码，前提是测试需求得有一定的规则或模式，
然后代码才能解析规则，根据规则生成最终的测试代码。

业界已经有了现成的工具，有 Spring Clond Contract，也有OpenAPI
generator。-可以直接把yaml文件中的接口文档，生成接口测试代码？

访问https://github.com/OpenAPITools/openapi-generator，按照指令，运行
generator 命令，在 Python，Javascript，Java，Go 四种语言里选一种生成代码。

06丨左移&右移：测试如何在Dev和Ops领域大展身手？

 自动化测试左移到开发的日常活动中，开发人员每天做一次 code commit，做一次版本
构建就会触发自动化测试，运行频率随之提高。一旦自动化测试运行失败，要么是发现了
回归 bug，要么是自动化测试需要维护了，问题发现得越早，修复越快，自动化测试就越
健康，越稳定可用。在磨合调试的动态过程里，自动化测试越跑越稳定高效，团队也能实
实在在体会到它的用处。

测试右移是指测试活动介入线上运维，用户画像等工作。这里我
说的自动化测试右移，意思是自动化测试也可以在生产环境里运行，起到一个自动检查监
测的作用。

只要我们在客户遇到 bug 之前发现它，
测试工作仍然是有价值的。
这时我们可以建立一个机制，通过自动化测试来定时监测生产环境。每天定时触发自动化
测试任务的运行，去检测生产环境的业务功能是否正常，然后生成测试报告。

07｜需求提炼（一）：单体应用要测什么？

用户故事

一个软件软件功能需求要回答这三个问题：第一，这个功能存在的价值是什么？第二，软件是怎么实现这个价值的？第三，这个功能能给谁带来价值？

这三个问题，到后来就成了 User Story 的表达 3 要素，WHY 为什么、WHAT 是

什么和 WHO 为谁，把这三个要素说明白了，这个功能也就表达出来了。

功能需求的主要目的是描述功能的商业价

值逻辑，而不是刻画实现的细节。

用了这样一组关键字，as a 说明用户的角色，I want to 后面是描述用户的行为，so that是获得的商业价值。

 测试需求 BDD Feature

BDD 的全称叫做 Behavior Drive Development，行为驱动开发模式。

 把 User Story 细化成一个或多个 feature，每一个 feature 都是一个可测试的场景。

这个 feature 的文件书写也是有格式要求的，通过一个叫做 Gherkins 的语法关键字模版来
写 feature 文件。
Gherkins 提供的常见关键字有：
Given: 用户场景的前提条件，可以是时间条件，也可以是另外一个用户场景的输出结果。

When: 用户在这个场景里做的行为操作
Then: 行为的输出结果
And: 连接多个关键字
Gherkins 还提供了更多其他关键字

  Feature 要细化到什么程度呢？从测试角度来看，要达到可测试的程度，也就是说要能够通过 feature 来验收 UserStory，所以，feature 在敏捷开发里又叫 Accept Criteria，在传统测试里叫做验收标准。

（这里把用户故事拆分的feature定义为测试需求） 

（这里的feature更像我么现在所做的需求分析）

09丨3KU法则：为一个订餐系统设计全栈测试方案

自动化测试设计中的四大基本问题：做不做自动化？在哪里做、怎么做、怎么运行。

测试四象限法则能帮我们有效完成这个思考过程。这个测试四象限，是布雷·麦瑞克提出来
的方法模型：根据需求的性质和等级 2 个维度，对测试需求进行分类。
一个维度是测试需求的性质，是技术性还是业务性的？

另一个维度是测试需求的等级，也就是需求属于关键性的还是精益性的？

测试四象限

 针对每个象限，测试四象限法建议自动化测试实施策略如下：
 第一象限里的测试需求是 100% 全部自动化；
 第二象限里的测试需求是自动化 + 手工；
 第三象限里的测试需求是手工测试；
 第四象限里的测试需求是通过工具和框架来执行，追求 0 代码

设计 ROI 高的自动化测试的运行场景是很关键的，而软件部署管 线 Deployment Pipeline 就是重要的自动化测试运行场景之一。

沿着部署管线发布的方向，也就是从左向右，自动化测试的运行速度由快变慢，而 ROI 也 是由高到低。越靠近代码，活动越频繁，ROI 就越高，

 10｜单元测试（一）：原来测试可以这么高效

12｜集成测试（一）：一条Happy Path扫天下

测试需求首先要找 ROI 最高的截面来验证

15｜UI测试：如何让UI测试更轻快便捷？

22丨设计实战（二）：一个全周期自动化测试Pipeline的设计

pipeline分为devjob包括buildjob和unitestjob(Junit)输出devpackage
testjob包括APITesJob（RestAssure）和E2ETestJob(可以用selenium)输出releasepackage
DeploymentJob进行部署，把package部署到生产环境输出serviceurl
 

 pipeline变更：
可以加入sonar扫描，sonarjob添加为DevJob下的第一个子Job

23｜设计实战（三）: 一个分布式多端视频会议自动化测试设计

25丨找准方向：如何建立有效的测试度量体系？

 质量三角图

 这三个因素中有一个因素发生变化，就会影响其他两个因素

用这三个指标来代表交付质量。

1. 交付速度，是版本迭代的速度，我们可以用发布的周期来度量。

2. 交付范围，是新功能的规模，可以用新增代码行数来度量。

3. 质量，用生产环境发现的 Bug 数量来度量。

自动化测试是能够提升这三个指标的

内建质量可以划分成四个维度：需求质量、设计质量、开发质量和测试质量。每个维度展开以后，都是一组度量指标。

 “You can’t improve what you cannot measure”
学过 Job 模型后，你应该掌握了一个把复杂问题简单化的解决思路。那就是先做划分，再定位实现。
测试活动的度量？
不建议用生产环境发现的bug数量作为评价指标，会造成大家任务测试对最终质量负责的误区。
 评价测试的有效性，尽量不要以绝对数字来判断好坏。
建议指标：
Bug 泄漏率 = 生产环境的 Bug 数量 /Bug 总数量 （质量）
冒烟测试 Bug 泄漏率 = 生产环境的关键 Bug/ 关键 Bug 总数量
测试需求覆盖率 = 被测试的需求条数 / 总需求条数 （测试范围）
测试执行效率 = 自动化测试的案例 / 总共测试案例  （时间）

27丨眼见为实：如何用数据描述你的自动化测试ROI

28｜解决问题：如何保证自动化测试的可信性？

通过自动化提升质量保障效率
所在的研发团队结合自身产品的特点，在软件架构、分支策略、GUI 测试框架、Mock 测试、Pipeline 流水线等多个方面，对产品进行了全方位的改造。
个人小程序实践：
把自动化下移至单元测试，并保证业务层代码 85% 以上的单元测试覆盖率；
通过将单元测试接入提交流水线，实现每次提交自动测试；
GUI 测试，通过手工测试覆盖关键路径。

专栏内容我通常会“刷上三遍”：
1. 第一遍略读，了解课程内容；
2. 第二遍精读，边读边做笔记；
3. 第三遍直接看笔记，看能否回忆起课程内容，如果回忆不起来，就再补充笔记

自己画思维导图，加深理解。

“从书中学，和高手聊，在事上练”

那些未达预期的自动化方案，应该如何改进？我的答案是，
首先要拉通开发和测试，应用 3KU 法则，制定产品整体的质量保障策略。
接下来通过 Job 模型进行自动化设计，对各层自动化进行分工。
最后是建立度量模型，提升整体的自动化 ROI。

最重要的还是在事上练，也就是拿实际的项目练手，可以先找一个比较容易的问题，做单点突破，然后再逐渐扩展试点范围。
“每个人都会有一段异常艰难的时光，生活的压力，工作的失意，学业的压力，爱的惶惶不可终日，挺过来的，人生就会豁然开朗，挺不过来的，时间也会教你，怎么与它们握手言和，所以不必害怕，光明总在前方。”