01 ROI价值内核：自动化测试的价值可以量化么？
你好，我是柳胜。
作为测试人员，我们都想做好自动化测试，但是每个行业都有自己的规律，也就是说常说的道，自动化测试也有自己的道。所以，在这个模块，我们的目标是了解自动化测试的道是什么，怎么能运用它让自己的测试工作更加有成效。
今天是价值篇的第一讲，我们先来弄清楚自动化测试的价值究竟是什么？看到这你可能有点困惑，自动化测试有那么多公司都在搞，自然是有价值的啊，有啥可讨论的呢？
其实这个问题非常关键，在开始工作之前，要把我们的工作价值想清楚，后续工作才能事半功倍。我列几个工作中我们频繁听到的问题，你会更有感触。
- （上级沟通）“产品要上线了，QA人手紧，能不能搞一下测试自动化，减少点人手？”
- （调动人手）“什么？你还要再增加2个自动化测试开发工程师来完成这个项目，他们都要做什么？”
- （工作述职）“听说你开发了个什么自动化脚本，它给公司带来了什么价值？用量化的数据给我讲一讲！”
这样的问句是不是似曾相识？其实它们都指向了一个硬核问题“自动化测试项目的价值是什么？”
在这节课，我要和你捋一下，为什么要做自动化测试，并且带你找到度量它价值的方法。掌握了这些，就能对自己的工作目标更清楚、更有信心，别人问到的时候，我们也能讲清楚、说明白，得到了团队理解工作将事半功倍。
为什么要搞自动化测试
开篇词中我提了出海捕鱼的场景，不只自动化测试，整个测试工作就像织网一样，会有弹性的空间，网眼大了、小了，捕到多少鱼，这些都有不确定性，但是这个不确定性又关系到成本和收益这些敏感问题，这是测试工作的一个特点。
我曾经跟我的团队说过 “咱们做测试工作，甭管用什么方法和技术，目标就是用最小的成本，得出对软件质量最大的确定性结论”。
自动化测试也面临相同的困难，为了解决这样的不确定，我们有必要好好分析一下，自动化的成本和收益究竟怎么算？
如果感觉这样问还有些抽象，我们不妨换个问法，自动化测试实施之前和之后，自动化带来的改变是什么？为了进一步完善思路，我们结合一个更具体的例子来做推理、估算。
这个例子是：一个Web UI 订火车票的软件，成功订一张火车票这个测试案例，要做自动化所花费的成本、还有得到的收益，会是多少呢？
自动化实施之前，测试案例的执行要靠手工完成，一个工程师需要花费0.5个小时，运行完登录、订车票，查看数据库这样一个测试流程。
而自动化测试实施之后，流程可以用Selenium脚本自动完成，原先手工测试半个小时的工作量就省下来了。那么，省下来的这半个小时这就是自动化测试带来的价值。对不对？
对，但还不全面，我们衡量效益，不应该只看回报，还要看成本，我们要算上开发自动化测试花费的成本。为了开发Selenium订火车票的这个脚本，自动化测试工程师花费了1天的时间，合计就是8个小时。
现在，这个Selenium自动化测试案例，它的投资收益比ROI应该这么计算（产出和投入都用时间作为单位）：
产出/投入 = 0.5/8= 0.0625
结果不到7%。哇，投入了8个小时，才收获了0.5个小时。如果这是一项投资的话，那肯定是亏本的。哪个公司愿意做这样的买卖呢？
但是，上面的公式只计算了运行一次自动化测试案例的ROI。实际上，自动化测试案例开发出来后，肯定不止运行一次的。多运行一次，就会多节省下来一份工作量，如果用n来指代运行次数，t指代单次测试时间，现在的产出变成了n*t，n越大，产出就会越大。
那上面订火车票案例，运行多少次才能收回成本呢？1/0.0625=16，只要这个selenium脚本运行超过16次，我们就可以让ROI=1，收支平衡，收回成本了。
太棒了，现在你就可以对公司说：“我的自动化测试收益是可以量化的，只要我保证开发出来的脚本，能运行超过16次，就是为公司省钱了。”
且慢，还有一笔账没有算，除了开发成本，还有维护成本。自动化测试开发出来后，还需要维护版本升级、诊断错误、优化结构等等的工作，这笔成本是需要持续投入的。
现在这个Selenium在它线上运营生命周期内的ROI计算公式，变成了后面这样：
产出/投入 = 0.5*N/(8+维护成本）
我们把它提炼成一个计算公式，就是：
这个公式很简单，但仔细揣摩可以推导出几个有意思的结论。
1.ROI大于1就是赚了，小于1就是亏了。那么，给定一个测试案例，要不要对它做自动化，判断的依据是（自动化测试）预期ROI至少要大于1。
2.自动化测试是一个长收益模式。在理想情况下，是一次性投入（投入为开发成本），之后每运行一次，就会增加一份产出。所以，时间越长，次数越多，收到的回报就会越大。
3.关于开发成本（包括开发成本d和维护成本m），类似估算软件开发工作量，代码行法、功能点法，我们也可以引入到估算开发工作量里，比较好掌握。但维护成本就有点模糊了，这里包含了多种可变因素，是自动化测试项目风险的主要来源。
维护成本来自于多个地方。一段代码从产生以后，就会持续产生维护工作量，而且，因为存在架构腐化等问题，维护工作量增加速度是以非线性来增长的。
到了最后，一个陈旧的老破系统，加入一个新功能需要写10行代码，只要花5分钟。但是搞清楚这10行代码，应该加到哪个文件里，要花费3天时间。在这种时候，这个软件系统就已经不可维护了，它要寿终正寝了。自动化测试代码的维护成本更复杂，不仅面临着腐化的问题，还有被测产品更新带来的维护等等。
所以，在实践中，你看不到前面图里，那样简单漂亮的ROI直线，它会表现为一段曲线：自动化的ROI增长速度，要比运行次数增长慢一些，直到最后，每运行一次，花费的维护工作量，比节省的工作量还多，自动化就该退休了，也就是下线，重构完了再上线。
这里我想提醒你注意，ROI模型提供的是一种自动化测试投资收益比的量化思路，方便我们明确哪些因素影响着自动化测试效益。不可能存在一个万能的公式，把参数往里一带，就会算出ROI的数字如果世间的事都这么简单，还需人类干什么。我们需要做的是尽可能量化，你对量化的了解越多，对自动化测试的理解就会更加深入全面。
做不做自动化测试，能用数据说话么？
从ROI的公式来看，自动化测试的收益取决于t和n，t指的是节省下来的手工工作量，还是比较容易理解的。在字面上，n是一份自动化测试案例重复运行的次数，那么在实践中，n是什么呢？
聪明的你可能已经猜到了，n是测试案例的稳定回归次数。软件的新功能开发出来后，第1次测试之后，第2次，第3次到第n次，都是对第1次的回归。它们都是重复的工作，应该被自动化替代。
你看，从ROI公式，我们很容易推导出业界熟知的经验“自动化测试是用来做回归测试的”。自动化是开发出来不会只运行一次，除非它的t特别大，实现了手工测试做不到的事情，比如单元测试、性能测试。
我们再回到回归测试，n作为回归测试次数，对自动化测试工作有什么启发呢？它的作用很大，因为它能帮助我们量化地去回答一个 “做不做自动化测试” 的关键问题
一个测试案例A做不做自动化测试？首先要看看它的n能有多大。
假设软件发布周期持续一年，每两周迭代一次，每次迭代都需要一次测试，那么在这一年里，需要回归测试次数至少是365/14=26次。如果还考虑一些紧急feature、patch的发布，那实际的回归次数要大于26次。这样，我们就能得到一个n的估算值，比如说30次。
得到估算值后，你的决策不再依赖直觉，而是有了可量化的思考逻辑。30次能不能收回来成本？能！那这个测试案例A就可以搞自动化。不能，你就面临亏本风险，自动化一顿操作猛如虎，测试工作还是苦，这是项目组里的每一个人都会感受到的。
刚才说的是基于软件发布周期不变的情况下，如何估算回归次数n。在实际工作中，自动化测试一旦做起来，带来的变化是：测试执行时间变快，软件发布周期缩短，又反过来增加回归次数n，自动化测试的收益也在增加。
这里我们又得到一个结论：软件发布周期变短是自动化测试ROI提升的产物。
总结来说，只要我们把注意力关注放在ROI上，后面的好处都会相继而来，测试质量提高了，发布周期缩短了，团队也更加有信心了。
实践中，冒烟测试是你自动化的开始
紧接着，咱们再考虑下一个问题，测试案例A需要30次回归，是不是在刚引入新功能A的第1次迭代，就开始运行自动化？我的答案是要根据情况来判断。
上面说到n是测试案例的稳定回归次数，注意稳定这两个字，它代表功能A已经稳固下来，不再变了。更精确地说，功能A即使有变化，但是变化规律已经可以被自动化测试吸纳。这种情况下，自动化测试运行才能发挥效益。
这里你可以看看后面这张图，画的是加特纳的技术成熟曲线，它也可以用来描述软件功能的发展过程。
通过加特纳成熟度曲线可以看出，新功能在产生初期，一般是不稳定的，和它的预期有一个差距。经过几轮调整后，才会进入到一个平缓的阶段，这也是稳定回归测试的阶段。而不同类型的软件，它的功能成熟时间长短，变化剧烈程度可能是非常不一样。
有的软件是做标准化产品的，比如专业性强的B端财务软件，计税模块发布出来就很稳定，我们采取的策略是在第1个版本做计税模块的自动化。
有的互联网软件第1版是投放试验性的，我看过国外一个招聘网站经过产品设计，AB测试多轮后，打磨了x版才稳定下来简历模块，那么这时的策略是在x版本进行简历模块自动化。
还有的生命周期比较短的软件项目，虽然有迭代，但功能一直无法稳定，那可能需要考虑完全手工测试，根本不需要自动化测试。其实这些都可以通过ROI模型讲得通。
到这里，咱们总结一下我们通过ROI得出的三个核心观点：
1.自动化测试是用来做回归测试的。
2.自动化测试从哪里开始？实施顺序从ROI高到低，也就是（给定一个软件系统），优先做回归次数最高的那部分功能，先做自动化回归次数最高的案例，再做低的，直到ROI等于1的案例。在功能模块的初期，可以考虑先做手工测试。
3.自动化测试什么时候开始？功能模块稳定的时候。
实际上，有一个很好的测试实践可以匹配上面的要求，那就是冒烟测试。冒烟测试是测试用例的子集，用来验证系统中基础的、影响发布软件的功能。甄选冒烟测试的一个常用办法就是二八原则。
二八原则又叫帕累托原则，在因果关系中，仅有20%的因素会影响80%的结果。它在各个领域都有体现，比如在市场营销领域，80%的利润是由20%的用户创造的；在经济学里，80%的财富掌握在20%的人的手里。
在软件领域，80%用户，常用的是系统中20%的功能。冒烟测试覆盖的这部分20%功能，是常用的，一般也是核心的，最先被开发出来的。所以，它同时满足稳定和回归次数高两个特点。
进而我们就可以得到推论：在实践中，可以设定目标，冒烟测试100%自动化。这时，自动化测试就可以和手工测试配合，形成一个新版本发布+冒烟测试的简单流水线。
如图所示，先从代码管理工具比如CVS、Gitlab中的开发分支中拉取代码，build构建，做一轮冒烟测试。如果冒烟测试通过，开发分支可以merge到发布分支，如果冒烟测试失败，那开发人员必须修改代码，直到冒烟测试通过。
这个流水线Pipeline充分利用了自动化无人参与，执行速度快的特点，可以帮助开发人员在第一时间验证代码的正确。由于是每次分支归并都会调用冒烟测试，所以n的次数高，自动化测试的ROI也会高。
小结
今天这一讲，我们通过一个投资产出视角来观察自动化测试，它的成本是什么，它的产出是什么，还学习了ROI的计算公式。
我们通过ROI的收益规律，不仅可以推导出自动化测试业界的已有共识，比如：“自动化是用来做回归测试”，“冒烟测试优先做自动化”……而且，我们还能挖掘出一些新的合理观点，比如：“ROI从高到低，来做自动化测试”。
这说明业界的实践已经有意或无意地践行ROI规律，因此可以说，ROI是一个自动化测试项目的隐式命脉。
同时，我们又详细介绍了ROI公式的因子n，测试案例的回归次数。在实践中，找到n来估算ROI，能帮你判断一个案例该不该做自动化。
ROI公式里，除了n还有其它因子。在后面的课程中，我们再一一介绍其它因子，像m维护成本，现在这个概念看起来还有点模糊，我还会帮你把它分解，直到可操作和可度量的粒度，让ROI的方法论更有效地指导你的工作。
思考题
学习ROI之后，你可以从开篇的三个问题里选择一个或多个，试着回答一下。
- “产品要上线了，QA人手紧，能不能搞一下测试自动化，减少点人手?”
- “什么？你还要再增加2个自动化测试开发工程师来完成这个项目，怎么算出来的？”
- “听说你开发了个什么自动化脚本，它给公司带来了什么价值？用量化的数据给我讲一讲。”
欢迎你在留言区记录你的收获和思考。如果这一讲对你有启发，也可以推荐给身边更多同事、朋友，跟他一起学习进步。
- Evan 👍（1） 💬（1）
1、先做稳定的主业务流程的自动化。 2、再做手工执行次数高的自动化。 3、尽量少做/不做页面变动频繁的自动化。 以上三点可以覆盖这三个问题： 1、根据（执行次数*执行时间）/开发时间 来比较回答。 2、ROI公式甩出去 3、根据ROI公式节省的时间与业界普遍的测试薪资挂钩，给出一个实际价值LOL。
2022-07-05 - 羊羊 👍（3） 💬（1）
在实际工作中，我们是先从技术实现的角度，筛选出可以实现自动化的case，然后按照case的优先级排序，再计算开发脚本的时间，分批自动化case。学习了老师这节课程，终于找到理论依据了
2022-04-19 - 李慧文 👍（7） 💬（1）
ROI 是一个自动化测试项目的隐式命脉，说的太对了，可以说现在所有的工作，包括计算机行业外的工作，都完全离不开ROI
2022-03-21 - who am i 👍（5） 💬（1）
问题1“产品要上线了，QA 人手紧，能不能搞一下测试自动化，减少点人手?” ，重点是产品要上线了是时间成本限制问题，临近上线时间节点和投入自动化开发时间是否符合，如果不符合不能搞自动化，且自动化主要是用来回归测试，产品上线功能是都是稳定还是待定
2022-03-31 - chin 👍（5） 💬（1）
冒烟测试进行自动化确实是最合理的选择，现在有了ROI这个武器，拒绝自动化测试无限扩大就有底气了。天下苦无限自动化测试久矣！
2022-03-22 - 闲不住的令狐冲 👍（3） 💬（1）
既然作者的公式提到了d，那么我也分享一下个人在工作中的心得。因为本人做过十多年开发，代码功底凑合，所以在加入测试团队后，根据产品特点（注意这个），重构了团队自动化框架，大幅减小了d（当然也因为更好的可维护性和可扩展性顺带缩短了m），收益也非常明显，特别是在迭代的流量项目中。 所以，我建议有余力同时也想在工作中脱颖而出的tester们，抽空学习一下经典开发框架的原理和设计模式。
2022-04-21 - willwchen 👍（2） 💬（2）
自动化测试提升节约了多少测试时间的度量标准，感觉只适用于测试团队内部度量，怎么把这种价值传递到整个业务团队，能让业务团队感知到自动化对业务带来的价值，这个是目前最大的挑战，现实是业务团队对提升的测试效率感知不强，不感兴趣，2个100万的自动化工程师，对业务团队的感知提升，可能不如4个50万的业务测试工程师，对比衡量，是不是4个50万业务测试工程师价值更大，这4个业务测试工程师除了本身测试工作，还能再完成70%-80%自动化测试工程师的工作，这是尴尬之处
2022-03-23 - 追风筝的人 👍（2） 💬（1）
note 1. 自动化测试是用来做回归测试的 2.软件发布周期变短是自动化测试 ROI 提升的产物。 3.ROI 是一个自动化测试项目的隐式命脉。
2022-03-22 - 萧瑟 👍（1） 💬（1）
按照目前所在公司的实际情况，产品已经要准备上线了，能不能搞一下自动化，我会说不能搞，因为手工回归测试的时间成本要远小于自动化脚本的开发工作（因为熟悉程度高，手工回归更加快速）
2022-05-04 - Even 👍（1） 💬（1）
ROI=(n×t)/(d+m)。
2022-03-27 - woJA1wCgAAUtR8JWp4a3IwtyFaATrSyg 👍（1） 💬（3）
开发没有完成的情况下，怎么用自动化去写冒烟用例给开发自测呢
2022-03-22 - 随片 👍（0） 💬（1）
answer： 1、主要考虑功能是否可以自动化，能：可以搞；不能：没法搞。 2、时间成本的考虑，如果需要在定时时间内完成自动化测试脚本，那么三个人开发减少开发工作日是ok的；如果时间并不是那么急，我想一个人保质保量的处理是ok的。 3、能够在开发新部署后，检查主流程的原有功能。从手工执行时间、自动化覆盖面积和执行次数说明量化数据。
2022-06-28 - 豁之一晶 👍（0） 💬（1）
感谢老师的分享。我有一个疑问：当产品迭代时间较短的时候，偏向做接口自动化测试够不够？
2022-06-14 - IT学堂笔记 👍（0） 💬（1）
听说你开发了个什么自动化脚本，它给公司带来了什么价值？用量化的数据给我讲一讲。 答： 开发了自动化脚本，最大的价值我认为是可以在快速迭代周期中能够进可能多的测试，这些测试不一定非要是回归测试使用，往往用于小单元的冒烟测试更加合适一些。 回归测试引入自动化就需要按照作者提出的ROI模型进行分析，看看投入产出比，维护成本，新脚本使用的迭代次数等，即使写好了一批自动化脚本，但是系统不稳定或者测试迭代次数少，这样投入的人员，时间跟后期维护代码都是不值得的
2022-05-10 - Geek_d00d65 👍（0） 💬（1）
1、项目临上线投入自动化，时间成本上不允许，而且自动化测试是用来做回归测试、冒烟测试的 2、通过ROI，用数据说服上级，多投入人力能得到什么回报，并且自动化搞起来后会缩短测试周期 3、通过ROI解释自动化能带来什么价值同时也把数据摆出来了
2022-04-20