每年底除了对上一年的回顾以外,大家是不是都已经到了需要对下一年展望的时候?

让我们回想一下过去的一年中,测试人员最烦的事情是什么呢?

点点点

比"点点点"更可怕的事情是什么呢?

一直点点点

不想一直点点点怎么办?

上自动化!!!

为什么公司之前没上自动化呢?

老板一直没同意。。。

以上的内心OS相信很多测试人员都经历过。

反过来想一下,老板怎样会同意你的提议呢?一般的策略都是"动之以情,晓之以理"。

动之以情这个改天展开说,就算是不混技术圈的老板,其实很多人对技术还是有一定的仰慕之情的。

我今天想聊聊的是晓之以理。

金融学上一般会用ROI来判定一件事情是否值得做。

Wikipedia 对 ROI 的解释为,在金融学中, ROI 被理解为投入产出比(Return on Investment),指投融资的回报率或者有时就指投资回报。它表示相对于投资额的金钱获得或者损失的比例。金钱的获得或者损失可以理解为利益,利润或者损失,浪费。投资额可以理解为资产、本金。

ROI 的最简单的计算公式是: 投资报酬率(ROI)=最终的价值-初始投资/初始投资×100%

ROI计算公式.png

--套用到计算自动化测试的ROI中,首先要解决的问题有两个: 1. 什么是自动化测试的最终价值? 2. 什么是自动化测试的初始投资?

测试的价值是通过找到更多质量缺陷(Defects)使得产品后期投入(Cost)减少而实现的。因此,自动化测试和手动测试一样,最终的价值决定于多少质量缺陷的暴露。这里不是单纯指测试人员找到的缺陷越多越好,而是指系统上线以后侧漏出去的质量缺陷越少越好。

自动化测试的价值可以说是相对于手动测试而言的,影响测试效率的参数可以用以下参数做参考,它们是基于多少个bug会被发现和被遗漏的bug的成本,当然你也可以加上你认为会影响测试效率的因素:

o测试效率的提高率

o基线修复率

o基线停机时间

o平均每小时停机的成本

o基准事故数

o事故平均花费

比如ABC公司发现他们的手工测试场景被自动化后,发现的bug数量相比于以前是2倍,则测试效率提高率为2。 在所有需要被修复的10个bug中又有1个需要被重新修复时,基线的修复率为10%,行业的数据一般是7%。 由于遗漏的缺陷而导致线上系统出现计划外故障的时间为基线年度停机时间,比如90小时。 在系统崩溃的时候会造成的商业损失的每小时成本可记为平均每小时停机成本。 还有年度里的遗漏bug数和为了修复这些bug而花费的平均成本。

可以得出一个以下的图表:

测试效率.png

那什么是自动化测试的初始投资,也就是它的成本呢?我认为有以下两种类型参数可以作为参考: - 测试投入相关参数 - 测试人员总人数 - 每小时测试人员平均成本 - 已存在的手工测试用例数 - 兼容性的测试环境数 - 一定时间类的Release数 - 已存在的手工测试所需总时间 - 迭代的项目的增长范围率 - 迭代的增长范围百分比 - 测试产出相关参数 - 测试场景设计时间 - 测试流程沟通时间 - 测试脚本编写时间 - 测试脚本运行时间 - 手工测试运行时间 - 手工测试变动时间 - 测试对象变动时间

得出的列表类似于下图:

测试投入.png

当然在自动化测试成本计算的时候可能还需要进行工具的选型,如果是商用的工具,就需要记入License的花费以及一些培训及咨询的费用。

开源软件已经很盛行的今天好多企业都会选择一些主流的开源软件进行二次封装,这时组织内就需要考虑招聘不同技术的人才来进行工具的二次开发。

依据以上的不同的参数的取值和一定的权重,你就可以构建你自己的ROI模型了。从ROI的算法中也可以看出,如果只运行一次的自动化测试收益率并不高,也就是说自动化测试的脚本运行次数越多,它的ROI也就越高,和我们所知道的自动化测试多运用于回归测试这一常识是相吻合的。

如果觉得自己做一个ROI模型很麻烦,也有捷径可走。 推荐一个线上的计算自动化测试ROI地址:https://www-01.ibm.com/software/rational/offerings/testing/roi/tool/ROI_Rational.html

IBM的Test ROI.png

网页上部分的问题中就是会计算的参数,下部分展示了预测的成本以及依据时间得出的回报率。(是不是超简单?)

anyway,一个原则,记得对你的老板"动之以情,晓之以理" , 2018年会是自动化测试更加发光发热的一年哦~

查看原文 >>
相关文章