130 lines
13 KiB
Markdown
130 lines
13 KiB
Markdown
|
# 27｜眼见为实：如何用数据描述你的自动化测试ROI ？
|
|||
|
|
|
|||
|
|
你好，我是柳胜。
|
|||
|
|
|
|||
|
|
在第一模块价值篇，我们反复提到“ROI是自动化测试项目的隐式命脉”。一个自动化测试项目，技术再牛，开发工作量再大，如果它不能产出效益，不被用起来，或者用得不好，那都是事关项目生死的问题。
|
|||
|
|
|
|||
|
|
所以我们需要有效监控当前的项目是否运行健康，观测目前的情况是在向好还是变差，这样才能及时调整，应对变化。不然拖到最后，往往就是项目解散人走空的下场。
|
|||
|
|
|
|||
|
|
这个观测的办法是什么呢？回到我们的主题上来，那就是数据。这一讲，我就和你聊聊如何用数据描述你的项目ROI。客观数据会告诉我们项目发生了什么，而且还能帮你统一团队的看法和认识。
|
|||
|
|
|
|||
|
|
## 再提自动化测试ROI
|
|||
|
|
|
|||
|
|
在前面的模块里，有一个同学在交流区提问说：“领导对自动化测试不支持投入，怎么办？”。这的确是个现实的问题，在其他领域也常见，就是一个团队对一件事情的认识和看法发生了分歧，这种分歧发生在平级的不同角色里，也发生在上下级。
|
|||
|
|
|
|||
|
|
比如，在做产品设计时，有人说UI页面设计成极简风格会受欢迎，另外有人说UI应该把尽可能多的功能暴露出来，用户才使用简单。各有各的说辞，谁也说服不了谁。那怎么达成共识呢？我的建议是“用数据说话”。
|
|||
|
|
|
|||
|
|
具体怎么实现呢？比如我们可以对两种解决方案做A/B测试，收集用户的使用数据。然后通过数据看看，在两种解决方案中，哪个更受用户的喜爱。
|
|||
|
|
|
|||
|
|
所以，今天讲的内容，不仅仅是技术层面的度量模型设计，也是帮你掌握沟通思路方法，这样你再跟其他人沟通自动化测试的问题时，也更容易达成共识。而团队达成一致，多人一心，其利断金，后面推动什么事，就都好办了。
|
|||
|
|
|
|||
|
|
怎么度量呢？我们再来回顾一下ROI计算公式。
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
下面我们要完成的工作就是，把这个ROI公式转换成度量数据。具体该怎么做？可以从这三方面入手：
|
|||
|
|
|
|||
|
|
1.定义度量集合
|
|||
|
|
2.确定度量数据来源
|
|||
|
|
3.度量的实现
|
|||
|
|
|
|||
|
|
## 定义度量集合
|
|||
|
|
|
|||
|
|
在ROI计算公式，我们有4个因子：手工运行的时间、运行的次数、开发成本、维护成本。
|
|||
|
|
|
|||
|
|
我们要用数据度量它们，比如维护的成本，首先要搞清楚的问题就是“自动化测试案例的维护工作量都花在了哪里？”。维护工作量花在多个地方，那这个问题的答案可能不止一个，每个答案都是一个度量点，多个度量点组合在一起就形成了一个集合，我们管它叫做**度量的维度**。
|
|||
|
|
|
|||
|
|
每一个ROI因子的度量都不是单个度量，而是一个维度。我们先画一张初版表格整理思路，后续再逐渐填充完善。
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
在维度一列里，我们列出的是一个领域（比如维护工作量）。现在，每个领域的问题和维度都找到了，怎么细化呢？我给你提供三个方法，完整建模法、关键问题法和最佳实践法。
|
|||
|
|
|
|||
|
|
### 完整建模法
|
|||
|
|
|
|||
|
|
我在[第二十五讲](https://time.geekbang.org/column/article/518825)说过：“内建质量度量就是找出木桶的那块短板”。完成这个工作，需要两步，第一，先找出木桶所有的木板；第二，拿尺子挨个量一下长短，找出最短的那块。
|
|||
|
|
|
|||
|
|
怎么找出木桶所有的木板呢？这就要用到完整建模法。
|
|||
|
|
|
|||
|
|
完整建模法，就相当于把木桶的木板按照一个既定的原则，划分成不同集合，然后每个集合再继续细分，直到明确每块木板。比如为了数清楚木板数量，我们先划分颜色，可以先成蓝色板和绿色板，再分别计数每一种颜色的板数。当然了，板子的类别还有很多分类角度，核心思路就是整体规划，再分而治之。
|
|||
|
|
|
|||
|
|
用这个思路来建模维护工作量，如果按照生命周期来划分，维护工作量就可以分为诊断、修改、验证和上线。如果按照工作量类型来分，就有产品变更维护，扩展自动化维护，问题诊断维护。这就像测试案例设计里的等价类方法，我们总能找到一个角度，把等价类设计得完备。
|
|||
|
|
|
|||
|
|
完整建模法比较适合用在你开始一个新项目，或者新接受一个工作的时候。因为你对情况不了解，通过这种方法，可以帮你按ROI因子梳理自动化测试工作的关注点，然后再分而治之。
|
|||
|
|
|
|||
|
|
不过完整建模法虽然拥有划分完备，不会出现重大遗漏的优势，但缺点也很明显，那就是会产生大量的度量指标。你可以想象，上面我们把维护工作量划分成诊断，修改，验证和上线，而其中的诊断工作量又划分成告警通知时间、Log搜索定位错误的速度、代码修改的效率等等，要做这么完备和大量的度量，这些都要花费大量的人力和时间，从投产比角度来说是不划算的。
|
|||
|
|
|
|||
|
|
### 关键问题法
|
|||
|
|
|
|||
|
|
上面说的完整建模法，是我们面对一个新木桶，通过摸索找短板。如果你已经发现木桶在漏水了，那这个时候你应该赶紧解决漏水的问题，找到短板在哪里。找没找对，以最后解没解决漏水为验证标准。
|
|||
|
|
|
|||
|
|
关键问题法看起来很简单，有问题，通过度量找短板，解决问题。但其实软件项目不像木桶那么直观，甚至有时你都看不到软件项目的木桶在漏水。所以，**提出正确的问题，是关键问题法的重要一步**。
|
|||
|
|
|
|||
|
|
举个例子，我们工作里一个常见的场景这样的：产品规模扩大，设计的测试案例也越来越多，成千上万。这时QA的工作负荷也越来越大，你需要考虑对测试案例进行重构，精简优化。这个时候我们就可以提出一个问题——“有没有低效的案例？哪些案例的设计是好的，哪些是冗余的？”
|
|||
|
|
|
|||
|
|
在自动化测试里，你也会遇到类似的问题。既有概要层面的问题，比如“我的自动化测试案例的健康状况是变好还是变坏呢？”，也有细节上的问题，像是“我的自动化测试对需求覆盖得怎么样？”。
|
|||
|
|
|
|||
|
|
像“怎么样”、“是多少”这类的问题，我把它们叫做**单标**问题，即一个度量数据就能回答单标的问题。比如数学考试，柳胜同学考了多少分，我们告诉他“75分”就可以了。
|
|||
|
|
|
|||
|
|
而“情况在变好还是变坏”、“工作投入重了还是轻了”，这类就属于**对标**问题，也就是通过一组相似数据对比的结果才能回答的问题。比如，上面柳胜同学在数学考试中得了75分，这个分数能说明什么意思呢，是考得好，还是考得差呢？
|
|||
|
|
|
|||
|
|
这时，就需要看75分在班级的排名，然后再看上一次数学考试的班级排名，把它和这次75分的班级排名做对比。这样，我们才能得出一个基本的判断，确认柳胜同学到底在数学上是进步了，还是退步了。在这个排名计算和历史对比过程中，我们消除了考卷难度变化的干扰因素，最终用排名变化来度量“变好还是变坏”的问题。
|
|||
|
|
|
|||
|
|
实践中，**趋势比绝对值更有决策价值**，这是数据度量的又一原则。对于自动化测试ROI度量来说，我们更专注的**是ROI变化的趋势，而不是ROI一个绝对的数字。自动化测试变得更健康了，还是正在衰退，我们是不是在一个正向的积极循环里，这更重要。如果有衰退，我们能尽早采取相应的行动**。
|
|||
|
|
|
|||
|
|
### 最佳实践法
|
|||
|
|
|
|||
|
|
随着度量经验越来越多，你可以总结一些行之有效的度量，并把它推广到其它项目中去，形成一个企业级的最佳实践度量。
|
|||
|
|
|
|||
|
|
比如，你发现你的项目木桶漏水的原因，经常是需求那块木板没做好，那你就可以把“什么是好的需求”这个度量推广到企业的其他项目里，来驱动其他项目的改进。
|
|||
|
|
|
|||
|
|
在第一模块第四讲里，我提到“一份代码，多环境运行，多浏览器运行”能够提高自动化测试ROI。这时，我们就可以用数据把它们表达出来，作为自动化测试ROI的度量之一。
|
|||
|
|
|
|||
|
|
怎么能度量出“一份代码是不是支持了多环境，多浏览器呢”？如果要去一行行检查代码，不仅有人工参与，而且工作量也非常大。这时，你可以换个角度来思考这个问题，如果代码支持多浏览器的话，我们应该会看到什么结果呢？
|
|||
|
|
|
|||
|
|
没错，我们应该看到一份脚本跑出来的多个浏览器测试报告。如果它支持firefox和chrome，就应该会跑出来firefox和chrome的测试报告。这样一来，“一份代码，多环境运行”的度量就转成了自动化测试报告的数据分析。
|
|||
|
|
|
|||
|
|
度量的原则相当重要，所有特征的度量设计都要遵循这些原则才是有效的。为了让你牢牢记住，这里我们再温习一遍：
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
有了三个法宝（完整建模法、关键问题法和最佳实践法）后，我们就可以设计度量了，现在我们把度量的表格更新一下：
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
## 确定度量数据来源
|
|||
|
|
|
|||
|
|
提出了度量之后，我们还要考虑这个数据能不能采集得到。能采集的话，具体是从哪里采集。
|
|||
|
|
|
|||
|
|
这时不要忘记我们刚才提到度量设计第三个原则，**度量数据的来源应该是来自未经人加工的数据。**
|
|||
|
|
|
|||
|
|
按照这个标准，我们排除几个需要人工决策的度量，用红色标注。
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
到这里，我们度量设计环节的主要内容就告一段落了。下面就是实现的环节，需要我们完成一个数据采集、聚合到展现的流程。这个流程更多是技术的实现过程，我会在这个模块的最后一讲，为你分享一个完整思路，为你演示如何搭建一个度量设计平台。
|
|||
|
|
|
|||
|
|
## 小结
|
|||
|
|
|
|||
|
|
今天，我们以自动化测试ROI为例，一起学习了度量的设计方法。
|
|||
|
|
|
|||
|
|
我分别给你分享了三种方法：**完整建模法、关键问题法和最佳实践法**。
|
|||
|
|
|
|||
|
|
完整建模法是按照一定规则从整体分解到细节。比如在第一讲里，我们来度量测试活动的时候，就用到了完整建模法，按照生命周期划分了测试设计、测试执行、测试自动化三部分。它的好处是不会有重大遗漏，但是问题也不小，就是抓不到重点。这适用于你刚接手一个新的项目，用完整建模法来理清大思路。
|
|||
|
|
|
|||
|
|
如果你对工作已经很熟悉了，想快速抓住重点，这时可以用关键问题法，用一个问题来驱动一个度量的建立，实现，直到驱动问题解决。这样就实现了优化和提升。问题可以分成两类，一种是单标问题，用一个数据来回答一个问题；另外一种是对标问题，是用一系列相似条件的数据来回答一个问题。
|
|||
|
|
|
|||
|
|
从数据驱动提升角度看，对标问题更有价值。因为看到项目变化的趋势才能有效决策，而且把一件事儿从差变成好，这个过程也是测试人员工作价值所在，这些都能通过对标度量来驱动，你不妨在自己的工作里试试看。
|
|||
|
|
|
|||
|
|
一个典型的应用场景就是内建质量和交付质量（可以回看[第二十五讲](https://time.geekbang.org/column/article/518825)）。当我们为内建质量做出种种努力和改善的时候，一定要定期观察交付质量的趋势，观测它是在提升，还是在下降。如果是在提升，那就说明内建质量的改善是找对了短板，方向是对的，应该继续坚持。如果在下降，那就说明短板没有找对，我们还需要继续用数据度量寻找短板。
|
|||
|
|
|
|||
|
|
而最佳实践法呢，是把业界一些已经证明行之有效的通用方法，通过度量表达出来，对工作进行驱动和改善。
|
|||
|
|
|
|||
|
|
有了这三种思路的加持，我们就能顺利完成自动化测试ROI的度量体系的建立。你应该已经感受到了，这个建立度量体系的过程，就是我们对问题的认识从模糊到清晰的过程。可以说“**不能量化的工作，就无法在一个规模组织中真正落地**” （记住，这是我说的）。
|
|||
|
|
|
|||
|
|
## **思考题**
|
|||
|
|
|
|||
|
|
开动你的头脑，怎样用数据回答“自动化测试设计得好不好”这个问题？
|
|||
|
|
|
|||
|
|
欢迎你在留言区跟我交流互动。如果觉得今天讲的方法对你有启发，也推荐你分享给更多朋友、同事，我们一起优化测试度量设计。
|
|||
|
|
|