如何计算自动化测试的投资回报？（08-07-28）（获奖名单已公布）

fishy

今天，很多管理者期望软件测试自动化成为银弹，解决测试时间安排，测试成本，跟踪报告等等问题。可以肯定的是自动化测试已经影响很多领域，很多成功案例给了我们希望，自动化测试可以节省金钱和解决一些测试问题。不幸的是也有很多失败的故事，即使在自动化测试已经获益的案例中也有失望和不好的感觉。

本周每周一问，欢迎大家畅所欲言：如何计算自动化测试的投资回报率？
希望通过本次讨论能给大家提供一些了解，计算成本和从自动化测试中获益的实际指导方法。

非常感谢各位会员积极参与，截止至8月2日24：00分，从该贴所有评论中选出部分作出精彩评论的会员予以奖励。礼品和积分将在本周内送出。

获奖名单
奖项	获奖名单	奖励	答案链接
一等奖	rolei	当当网购物卡50元	4#
二等奖	maguschen	300论坛积分	5#
	goal1860		11#

duola1119

占楼编辑。关注

smallkaola

刚好在做的项目要自动化一些case，我有幸能去做这件事情，在我看在自动化的脚本改写要比每天跑case有意思的多，呵呵
从我的角度来说自动化测试确实给了我很多的学习机会，让我了解到了xml，menu tree，tcl，同事积累了个人的测试知识以及经验
但是就我们公司所要实现的自动化测试，只是刚刚应用到实际项目的测试当中来。做到了一些基本功能的简单case的自动化实现，因为我们每个项目的UI都是在变化的，那么xml的维护就是一项工作，需要及时的更新；在着就是tcl脚本的库并不是很完整，需要我们随时需要随时添加更改。
再者我们来比较自动化case与之前手动case的区别，case数量步骤都是一样的，但是手动与自动化工具import的result就会有一些不同：自动化工具没有大脑，他们跑出的只是单纯按照步骤去执行，不会在测试过程中发现些别的交互或者中断；所以单从这点上来看就必然还需要resource去同样做一些周边的发散测试。
这样来看，像我们公司这样的测试工具以及测试环境不是很成熟的情况下，花费人力去维护脚本也是一种resource支出，回报也还亟待我们比较来得出。
所以我认为如果自动化测试工具以及环境成熟的话，会节省很多basic function case的resource投资，测试人员只需要做更加人性化的测试，比如扩展测试等等
另外在duration以及stability测试当中，测试工具是一个很好的执行者，这种长时间或者多次执行的case也是回报大大高过投资的。

以上只是我在前端做自动化测试维护时产生的一些想法，可能不是很专业，但是也是从实际出发的，希望大家能够给我更好的建议，谢谢了

rolei

一点自已的看法

1.软件测试自动化
非常赞同版主将“解决测试时间安排，测试成本，跟踪报告等等问题”归为软件测试自动化的范畴。
大多数的软件测试面试题中都会提到“自动化测试”一词，而面试者往往给出的答案是：我会loadrunner，会rational，会用某某语言编写脚本。将自动化测试与自动化的性能或是功能测试工具划上了等号。
个人理解：软件测试自动化，是所有能够协助测试人员摆脱传统的手工模式，有效完成测试管理和执行工作的工具或是方法。
包括计划工具，任务管理工具，Teat Case编写及生成工具，Bug管理工具、统计工具等等
软件测试生命周期存在于软件开发生命周期的每一个步骤中，因此软件测试自动化也应当可以运用到整个软件测试生命周期中。

2.自动化测试的回报率
问题太大，涉及到的投入太多，相应的人力和物力成本不能一一计算（财务或高管应该知道），因此也没有去算过真正的回报率。
只是简单的用了一个很范范的衡量标准（没有真正实际意义上的度量数据）：是否能够提高测试的效率，是否可以在使用自动化测试后提升整体的效益。
测试工具带来的是测试工作的自动化，测试自动化的实现往往会大大提高我们的测试工作效率，带来较大的收益。这里的工具不仅仅是功能或是性能工具 ：）
公式：
按照 投资回报率（ROI）=年利润或年均利润/投资总额×100% 的算法
使用 投资回报率＝未使用自动化测试前所消耗的人时 － 使用自动化测试后所消耗的人时 ／ 未使用自动化测试前所消耗的人时X100% 对自动化测试进行简的估算。

例1：以往做测试报告统计，5个人月的项目，需要测试人员花费1个人日（8个人时）进行统计。
利用相应的测试管理工具后，同样的项目，需要测试人员花费4个人时进行统计，并能生成相应的报告。
则 ROI > （8－4）／8 X 100% = 50%
注：
1）这里没有记录和计算引进测试自动化工具本身的成本，如工具的购买和培训等等
2）工具所带来的自动化带给我们的是高效和时间，让我们有更多的时间关注更重要的事，做更多的事

例2：以往程序维护工作对主流程的测试和验证，需要测试人员花费5～6个人时
利用自动化功能测试工具后，同样的维护测试工作量，需要测试人员花费0.5～1个人时（平均了日常的脚本维护时间）。
长期维护项目，脚本可以得到很好的复用和维护。
测试过程中不需要人为干预，并且与编译、布署实现自动化流程作业，尽可能早的发现问题。
则 ROI > (5-1)/5 X 100%= 80%
注：如果只是一个短期的项目，我会放弃使用自动测试测试工具。长期维护和脚本的可复用性节省了大量人力资源，带来的投资回报率非常明显。

例3：维护项目中新加一个功能点（完全独立的功能），人工测试需要1.5个人时，如果通过自动化实现需要 >4个人时
如果使用工具：ROI < （1.5-4）/1.5 X 100%= －166.7%
注：
1）没有复用价值，自动化实现还不如手工效率高
2）如果使用工具只是为了让自己变懒，或是为了满足自己对“技术”的追求，而不能确确实实的给整个项目或是产品带来效益，还是放弃的好。

maguschen

                     
△Ba表示自动化测试相对于手工测试获得的收益
△Ba（t时间内）=∑（自动化测试固定成本的增量*（t/使用寿命））+
                           ∑（在t时间内，运行n2次手工测试的可变成本）-
                           ∑（在t时间内，运行n1次自动化测试的可变成本）   
△Ca表示自动化测试相对于手工测试所增加的成本
△Ca（t时间内）=∑（自动化测试固定成本的增量*（t/使用寿命））+
                           ∑（创建自动化测试的可变成本）-
                           ∑（创建手工测试的可变成本）+
                           ∑（维护自动化测试的可变成本）*（n1/N）         

其中，上面的表达式所涉及到的变量如下：

n2表示手工测试的执行次数
n1表示自动化测试的执行次数
N表示在脚本变更前的自动化测试运行次数


由于文章太长，论坛不允许发那么长~~麻烦大家看楼下……
图片还是上传到51Testing好~

[ 本帖最后由 maguschen 于 2008-8-2 21:42 编辑 ]

maguschen

接着楼上！~~~

1.
测试小组的手工测试团队有8位测试工程师；
2.
由于系统现存测试用例已经开发完成，手工测试用例开发成本可以不计算；
3.
每年系统发布2次，每次发布都需要对5个构建进行回归测试；
4.
每次回归测试需要8位工程师16个工作日的时间来执行；
5.
在每次发布以后，手动测试用例需要3位工程师5个工作日的时间来维护和更新；
6.
自动化测试脚本花了4位工程师80个工作日进行设计和实现，设计使用寿命5年；
7.
在采用自动化测试集后，每次发布需要花费8位工程师7个工作日的执行时间；
8.
实现自动化而采购的机器设备和自动化测试工具的总花费$50,000/年；
9.
在每半年，测试脚本需要2名维护工程师20个工作日的时间进行维护和添加新的测试脚本；
10. 人力资源成本每小时50美元。


分别用 两年（执行回归测试20次），五年（执行回归测试50次）来计算ROI：


△Ba（t时间内）=∑（自动化测试固定成本的增量*（t/使用寿命））+
                                  ∑（在t时间内，运行n2次手工测试的可变成本）-
                                  ∑（在t时间内，运行n1次自动化测试的可变成本）
△Ba（2年）= 0 + 8×16×8×50×8 - 8×7×8×50×8 = 230400
△Ba（5年）= 0 + 8×16×8×50×20 - 8×7×8×50×20 = 576000
△Ca（t时间内）=∑（自动化测试固定成本的增量*（t/使用寿命））+
                                  ∑（创建自动化测试的可变成本）-
                                  ∑（创建手工测试的可变成本）+
                                  ∑（维护自动化测试的可变成本）*（n1/N）
△Ca（2年）= 50000×0.4 + 4×80×50 – 0 + 2×20×4×50 = 44000
△Ca（5年）= 50000×1 + 4×80×50 – 0 + 2×20×10×50 = 86000
ROI（2年）= 230400÷44000 = 5.23
ROI（5年）= 576000÷86000 = 6.69

以上蓝色部分是以前的计算结果，然后稍微解释一下里面的数据

• 在计算△Ba的时候，为什么“∑（自动化测试固定成本的增量*（t/使用寿命））”这一项是0呢？因为当时的情况是，已经有现成的测试用例供我们使用，所以不需要额外编写测试用例，所以固定成本的增量为 0 ，整个式子就为 0 ，所以上面的部分就没有介绍变量t是什么东西了（其实是我偷懒了）
• 为什么计算的时候，n1 n2是相等的？其实这里是假设测试是必须执行的，所以无论用的是自动化测试还是手工测试，都必选完成测试，n1 n2相等的。但是，更加一般的情况是，如果实施了自动化以后n1自动化测试的次数应该会比n2手工测试执行的次数要大。因为对于已经完成的自动化测试来说，运行一次测试的成本是很低的，大家也就比较爱用了。
• 我的这个计算有没有问题？我觉得这个公式是没有问题的，但是我选取的数据有可能不太合理，需要大家指正。

看完了公式计算，说一下我个人的感受。自动化测试不是银弹，大家都知道。但是无可否认，实施的比较好的自动化测试，它的ROI是比较高的，从上面的计算可以得出，自动化测试使用的时间越长，ROI会越大。还有一个很重要的问题，就是怎么选择实施自动化测试的用例~不过这又是另外一个问题啦

附上参考资料！！

参考资料：Douglas Hoffman．Cost Benefits Analysis of Test Automation．Software Quality Methods，LLC，1999

chuming

哪位高人能否给出一个简单的计算公式呀？简单说清楚问题，才是高手哟，呵呵！！！

marco

maguschen 说的很详细啦,没啥好补充的了....

zhouboeric

很详细啊，刚开始做，还没怎么研究~~

makyoung

学习学习，占楼学习

goal1860

呵呵，要估算自动化的效益，必须根据本公司的实际情况建立一个模型，前面几位大佬提的就是经典的估算模型，我根据自己的实践给个简化的：

基本公式：手工执行成本+脚本建立成本+脚本维护成本+脚本执行成本x执行次数+其他相关成本<手工执行成本x执行次数

解释：成本的计算单位大多上可以用时间，对于有些用货币估计的应当折算成有效工时。由于脚本执行可以在夜间进行，应当乘以一定的折扣，甚至于可以忽略不计。 最难计算的是维护成本，同时也是自动化测试风险比较集中的一块。它由多重因素决定，比如开发流程的类型，自动化介入的时机，需求和设计的稳定程度，工具的选择，测试人员的能力（直接决定了脚本质量），测试框架的质量，测试对象的可测试程度。。。。。。
其他相关成本包括：做决定（通常会有很多会议）、自动化测试计划、框架实施、研究、额外软硬件等，多为一次性投资
脚本建立成本和手工执行成本可以比较容易地从历史统计数据得出

这仅为参考模型，实际应用中由于风险的存在，当自动化测试的收益难于估计或估计收益不大时，很多公司会选择放弃（本人也一样：）
其他因素：当人力无法取代自动化，如大规模性能测试

lindaweng

学习学习

44705618

谢谢各位的赐教

黑五类

大家都在谈论自动化测试，我也是刚学习一段时间，谈一下我自己的看法。

首先，我们先明确一下自动化测试的范畴。自动化测试应该是指通过通用的或者自己研发的自动化测试工具进行和开展的测试活动，应该是测试执行阶段一个重要手段（也可能在测试用例设计和测试报告）。自动化测试在我的理解里面应该是一把双刃剑，如果使用好了会使测试的效率大大提高；如果使用不好，结果也是相当的可怕的。

关于自动化测试的投资回报率来说，应该是具体问题具体分析，个人认为很难提出一个比较简单的计算方法或者是计算模型。举一个例子来说明，现在有一个网站的性能需要测试。网站要保证同时在线10000人时，任然能使用户的响应时间在0.3m以内。这个测试就必须使用自动化测试工具了，如果不使用自动化测试工具，还使用手工测试的话，成本将是相当恐怖的（招10000个测试工程师，买10000台电脑）。如果需求在出项变更，改变为要满足50000人同时在线。这个时候测试负责人在不使用自动化测试公具的时候就应该哭死了。从这个例子中我们可以看到，自动化测试的投资回报率可能跟随用户需求的变化而变化。再说一个例子，某公司一直从事某一个行业的软件开发，项目和项目之间只有一些小小的变化，测试人员可以从以前的项目中，直接继承很多自动化测试的脚本而进行自动化测试。这个时候针对一个项目的自动化测试的投资回报率就很不好计算了，做过的项目越多，自动化测试的投资回报率就越高，这时我们可以看到自动化测试的投资回报率不能是针对一个项目的计算，应该是针对一个公司和这段时间内所复用的比例来决定的。

从上面两个例子中，不难看出孤立的纯粹的计算自动化测试的投资回报率不能准确的计算，但是在一个项目开始之前没有一个简单的衡量，就没有依据来判断到底进行自动化测试还是不进行。在一个项目开始之前还是要分析一下这个项目具体有没有自动化测试的必要的。个人觉得主要从以下几个方面进行考虑：

            项目是否有延续性，有延续性的以后会有很多能复用的地方，适合做自动化测试；没有延续性的，可能就不是很适合；
            项目的开发模式和开发计划，    需要有很多次的重复测试的，适合作自动化测试；测试重复次数不多的，不适合；
            项目人员的素质问题，有自动化测试相关经验的，是合作自动化测试，没有自动化测试相关经验的人员，不适合；
            项目构架的稳定性   稳定的适合做自动化测试，不稳定不适合。（需求总是变更，界面原型总是变更很难开展自动化测试）
            项目时间的问题      如果以前没有任何可以继承的东西，项目时间紧的情况下不适合做自动化测试。


以上的这些只是个人从自己的经验总结的一点东西，可能还不是很完善。但是，根据我们现在的软件行业的自身情况，可能做不做自动化测试也不是项目经理或者测试负责人说了算的，可能是公司的大领导说了算，还可能是用户强行要求的。所以分析也只是停留在技术层面上的东西。

还是那句话，哲学上已经告诉我们了，什么事情都不可能存在银弹的，关键的还是要具体问题具体分析。自动化测试这并双刃剑，我们一定要把它砍向敌人！

[ 本帖最后由 黑五类 于 2008-7-31 18:22 编辑 ]

deicalin

本人现在所在的公司测试的人少的可怜 对于自动化测试 还不是很明白 何谓自动化测试？具体包括哪些东西？实现的步骤是怎样的？需要哪些资源和工具以及硬件配置？谢谢!!学习中。。。。。。

deanaa

从软件行业的角度，我更愿意把投资回报率用投入产出比来度量。投入产出比是一个量化值，最终反映出来的是一个数字。但是我更关心的是为了获得这个数字我们进行分析的过程。是否引入自动化测试的决策，自动化测试引入和执行过程中的跟踪，管理和调整，以及项目完成后对于自动化测试结果的分析总结，都可以通过我们对自动化测试的投资回报率的分析，得出结论。而这个，应该才是我们计算投资回报率或者投入产出比的终极目标。
我们从投入和产出两个角度来看这个问题。
从投入的角度看，自动化测试的投入可以分为显性和隐性投入。显性投入是指容易量化的，直接的投入，包括用于自动化测试的软硬件投入，对自动化测试的设计，编码，测试，实施和执行所投入的直接人力投入。隐性的投入则是指由于引入自动化测试对组织，项目带来的不可量化的影响，包括测试流程变化的影响等。对于显性的投入，我们可以把自动化测试看成一个小项目来进行分析。硬件软件的投入是最直接和可量化的；而对于人力成本，除了前面列出来的直接人力成本外，我们需要特别关注变更的成本，简单来说，对于一个功能尚不稳定的产品，当我们引入自动化测试的以后，功能上的变更所引起的自动化测试维护成本的上升（重新设计case，编码和测试），可能比开发过程中的成本更高。对于隐性投入，我们需要对组织的现状做出评估，特别需要分析自动化测试的引入对于项目的开发测试流程的影响。
从产出的角度来看，引入自动化测试的初衷一般都是希望能减少重复测试的人力成本支出，让机器取代人来完成一些重复性的工作。一般来讲，我们可以用引入自动化测试前后执行同样case所投入的人力差别，来衡量产出。
通过上面的分析，我们可以得出一些定性的结论：
自动化测试比较适合满足以下这些条件的项目
1.项目功能比较稳定，变更比较少
2.项目和组织相对成熟，流程的变更带来的影响比较小
3.测试用例得到很好的维护，测试用例本身的质量较高
有一些项目可以部分引入自动化测试，比如
1.项目部分模块功能已经稳定，可以针对相对稳定的模块引入自动化测试
2.项目大流程比较稳定，可以先对冒烟测试引入自动化测试
最后，必须要明确的是质量第一的原则。自动化测试切忌以量取胜，如果自动化测试脚本本身都的质量都成问题，试问怎么能成为衡量另一个产品质量的标准，这样的脚本所给出的测试结果又怎么能真实反应产品的质量呢。

tongyue0822

得好好学喽！

51testingalbert

写得真详细啊
得仔细研读！

sun_0910

一个简单的自动化测试投资回报率的计算方法
自动化测试成本 = 工具软硬件成本 + 脚本开发所耗成本 + (脚本维护成本 X 脚本执行次数) + (脚本执行成本 X 脚本执行次数)
手工测试成本 = 测试用例设计开发成本 + (测试用例维护成本 X 测试用例执行次数) + (手工测试执行成本 X 测试用例执行次数)
利益 = 手工测试成本 – 自动化测试成本
ROI = 利益/自动化测试成本
注: 自动化测试的ROI无法显示在测试过程中查找出来的缺陷个数

pires

对自动化测试的收益，我更倾向于定性的去考量。
如果从收益的角度来看，常见的三个方面是：
1.测试环境的自动化搭建。
这点极易被忽视。有一套快速稳定的搭建系统的策略可节省时间及减少很多问题。
2.自动回归测试。
测试驱动开发的理念是关键，可根据实际情况选择，自主开发测试用例或选用商业工具。
3.自动性能测试（压力，负载等）。
一般可采用loadrunner等商业测试工具，需要熟悉数据库知识。

成本主要体现在商业测试工具的购买，对理念和技术的培训及建立较完善的自动化测试流程所需的人力和时间。
收益体现在完成纯粹的手工测试不能完成的任务，及同样的任务所节约的人力和时间。
事实上，自动化测试必然与手工测试结合起来。
其效果主要应体现在快速高效的发现手工测试难以发现的问题。
而同样的任务所节约的人力和时间其实无法计算（世界上不会有同样的任务）。

像单元测试及持续集成等理念，开发部门必然要直接参与其中并带来软件质量的稳步提高。
这是很难计算具体收益的，然而所有参与项目的人员都应该感受到效果。

如上面几位同学所说，自动化测试重在测试过程的建立。
和技术相比，管理或者说架构更为重要。
不能奢望通过一个项目完成很好的自动化测试过程，因此，投入是长期的。
需要有能力的测试人才领导整个团队稳步提升能力。

事实上，现代的大型软件开发，自动化测试是必然的需求。
真正的问题在于找到和培养优秀的测试人才。
由于懂行的人太少，这方面的投入产出比是可想而知的。
关键在于寻找有想法的测试人员，而不是强调多少年的测试经验或者商业测试工具的掌握。
不管是手工或者自动化测试，所谓探索性测试的理念都是重中之重。