自动化测试ROI分析及实践.docx
《自动化测试ROI分析及实践.docx》由会员分享，可在线阅读，更多相关《自动化测试ROI分析及实践.docx（17页珍藏版）》请在冰豆网上搜索。
自动化测试ROI分析及实践
自动化测试ROI实践
自动化测试是一项“一旦开始，就需要持续投入”的工作，所以它一直是测试领域的一块鸡肋。
不做吧，好像手工测试重复得让人有些厌倦，而且手工测试时间也缩短不了。
做吧，害怕投入的比回报要多。
没实施自动化的团队有各种各样的困扰。
有的说：
“项目有太多的老代码需要补充自动化测试脚本，补不起！
”有的说：
“项目开发太紧张，如果同时还要自动化，等不起！
”还有的说：
“自动化测试工具太贵了！
买不起！
”确实，各种各样的“伤不起”使得大量的组织在“要不要自动化”这个问题上总在了解和观望，踌躇不前。
我们阅读了一些关于自动化测试ROI的文章，发现大多都是介绍各种不同的计算方法，但来自实际的数据分享比较少。
所以，2011年当我们组织想推行自动化测试的时候，为了打消大家（尤其是管理层）对于自动化测试的投入和产出方面的疑虑，计算我们自己的自动化测试投资回报率ROI（ReturnonInvestment）成了我们启动时就考虑的问题。
本文将分为四部分介绍我们的实践方法和结果。
第一部分：
业界计算自动化测试ROI的方法
简言之，ROI=收益/投入。
但收益如何计算，投入包括哪些，众说纷纭，并没有一个定论。
在DionJohnson的“test automationROI”中给出了三种计算自动化测试ROI的方法。
第一种方法“简单ROI”着重从“钱”的方面去看。
它考虑了工具、培训、机器等各种费用，并把测试时间的投入通过单位时间的工资转化成为钱。
第二种方法“效率ROI”与第一种方法不同的是从测试效率的角度，只考虑了时间投入所产生的收益，而没有考虑其它如购买工具方面的投入。
这个方法比较适合测试人员计算收益。
第三种方法“降低风险ROI”着重计算自动化测试与手工测试相比在降低风险方面的收益。
它会假设不做某种自动化测试，相关的风险一旦成为事实所带来的损失，从而计算ROI。
这个方法比较适合管理人员从整体考量自动化的收益。
那么，目前我们的团队期望自动化测试能带来哪些收益，尤其是哪些收益是目前不能奢望的？
我们的经理愿意提供多少资源投入自动化测试呢？
带着这些问题，我们开始了自己对自动化测试ROI的定义和度量。
第二部分：
我们计算自动化测试ROI的方法
在度量自动化测试的收益方面，角度很多。
我们选择的是从“多、快、好、省”四个方面去看。
更多
鉴于我们处于自动化测试的初级阶段，我们打算暂时先不去追求“更多”。
即我们不奢望一年之内整个项目组在一个版本里做更多的工作，因为在自动化投入初期难以提高团队的生产力。
我们也不奢望测试人员马上能有更多时间去做更有价值的工作（相对于一次测试的多次重复执行）。
因为测试人员通过自动化测试从测试执行上节约出来的时间需要投入到自动化工具和技能的学习上去。
更快
在时间维度上，我们希望能够更快地发现和修复稳定的主流程上的明显的严重缺陷。
如果一个测试人员手工测试多个功能，那么测试执行的并行度总有个上限。
而多个并行执行的自动化测试脚本可以更快速地验证版本，一次性地报告问题。
这尤其在测试初期版本不稳定，或者是每日构建的时候有用。
有时，甚至是在我们不觉得有测试必要的时候，自动化测试可以及时报告刚引入的问题。
另一方面，更快地发现缺陷也意味着可能可以更快地修复缺陷。
更好
我们希望自动化测试可以帮助我们实现对“更好”的追求，包括质量、信心、士气三个方面。
1、更好的质量
更好的质量最容易被理解成为更少的缺陷。
但这里需要强调的是“更少的缺陷个数并不仅仅能依靠我们基于界面的自动化测试来达到”。
我们这里希望自动化测试能够帮助我们减少生产环境中某种特定类型的缺陷。
这些缺陷包括环境或者配置相关的缺陷、在主流程上本来正常但因为后期修改影响到的功能、以及容易被忽略的地方（如：
同一功能的多个入口、不常使用的功能）等。
2、更强的质量信心
在内部测试中，我们希望借助自动化测试来提升的是对质量的信心。
这主要体现在：
（1）对于小版本和并行版本的质量更好地把关。
小版本通常要求更快速的响应。
并行版本通常要求测试人员频繁切换环境和被测对象。
而人在压力下也更容易犯错。
所以，我们常碰到的是匆忙中由于疏忽，一些比较重要或者明显的问题没有被及时发现。
（2）对缺陷修复的质量更好地把握。
根据统计，大约7%的缺陷修复会产生新的缺陷，而这些新缺陷有时会出现在前面已经测试过并且不会再手工测试的地方。
对于如上两种情况，重复利用自动化测试脚本可以不需要额外的投入，快速得到关于整个版本稳定性的信息和质量信心。
3、更高的士气
对于测试团队，我们希望自动化测试可以唤起更高的工作热情。
这一方面来自于可以部分地将测试人员从大量重复的测试执行中解放出来，另一方面来自于新技术、新工具带来的新鲜感。
开发团队和终端用户会是自动化测试的间接受益者，因为开发团队能感到问题会更快地暴露出来，终端用户会感到应用程序更稳定了。
甚至在不远的将来，如果测试时间可以借力自动化而缩短，那么用户希望的功能也能更快地交付使用了。
更省
有了自动化测试，我们希望能省去以下工作：
1、在每日构建后不需要手工验证版本的可测试性；2、在非需求（硬件、其它软件）变更的时候，尽量少的（甚至没有）手工主流程测试；3、在上线支持方面的不需要手工批量操作。
从上面的“多快好省”的分析中，我们明确了目前这个阶段我们希望从自动化测试中获得的主要收益，也发现了其中有些收益并不好度量。
简单起见，我们决定记录可以量化的收益如下：
节省的测试人力：
如果需要手工执行自动化测试案例覆盖的功能，那么需要多少人力。
这个数据乘以自动化测试执行的次数，代表节约的手工测试人力。
发现缺陷的收益：
对于自动化测试发现的缺陷，根据其发现的阶段设定不同的权重，并折算成它的风险收益。
根据“持续交付”一书提到的理念，持续集成中“常红”或者“常绿”都是不正常的状态。
类似地，我们认为自动化测试应该在验证版本基本正确性（绿）的基础上增加一些可能失败（红）的脚本/数据。
因此我们将发现内部缺陷当作我们希望的自动化测试收益。
自动化测试的投入这一方面，因为测试工具已经购买而且是共享的，硬件方面也是利用已有资源，我们选择只考虑人力方面的投入，包括测试人员和开发人员一起投入的人力。
因为开发人员有时会和测试人员一起解决自动化脚本的技术问题以及环境问题，如果其投入超过一定数量，我们将纳入计算。
当然，测试人员的投入占绝大部分。
为此，我们设计了一个表格，要求测试人员如实填写自动化测试的相关时间投入。
除了时间，还需要记录其对应的类别，如团队学习（开会、培训）、个人学习（学习、研究）、测试用例设计、脚本开发与维护、环境等。
做类别的区分主要是想看看剥离掉前期学习部分，每个版本在脚本维护方面的平均开销是多少。
第三部分：
我们的结果
在首个半年的实施中，我们多个项目都实现了基于QTP的主要业务流程的自动化。
我们的投入和收益实际情况如下：
QA人数
自动化测试投入（man*hour）
自动化测试带来的收益（man*hour）
项目1
3
160
40
项目2
3
190
32
项目3
2
161
33
从上述数据中我们可以看到自动化测试的收益并不高。
这迫使让我们思考下一步如何才能获得更多的收益。
而我们也马上产生了许多具体的想法。
1、提高执行的次数。
这可能需要我们把自动化测试和每日构建集成起来。
2、在增加发现缺陷可能性方面，可以
（1）利用现有的自动化测试脚本，但增加数据的多样性，这样脚本方面投入不大，但能增强发现缺陷的可能；
（2）增加现有脚本的检查点，发现更多可能的缺陷；（3）分析缺陷，增加对容易聚集缺陷的相关功能的覆盖。
3、优化脚本：
对脚本的结构进行优化，提高复用性、灵活性、易维护性；加强脚本的稳定性和健壮性，提高其正确执行的概率。
接下来，我们尝试了自动化测试脚本和版本构建的持续集成，增加了测试数据的多样性，并随着项目的变化对原有脚本进行了必要的维护。
与此同时，我们的项目也意外地碰到了多次硬件设备迁移，软件（操作系统、数据库、底层构架、第三方控件等）版本更新，以及小版本和并行版本的测试。
此时我们都借助于自动化测试脚本，迅速地验证了版本，发现了一些缺陷，在项目组面临巨大的时间压力的时候提升了大家对质量的信心，项目经理开始纷纷表示对自动化测试的支持！
自动化测试如同零存整取，平时挤一些时间去做，到了紧急需要的时候，那种雪中送炭的感觉真的很棒！
第四部分：
结语
我们的自动化测试刚刚起步，度量的ROI结果也并不漂亮，但我们相信只要跨出了第一步，自动化测试的千里之行始于足下。
自动化测试ROI分析
（一）
1. 介绍很多领导将自动化测试视为银弹。
他们认为自动化测试能解决诸如测试规划、测试成本、缺陷报告等很多问题。
自动化测试在很多方面会带来积极的效果，并且已经有很多成功的案例能使人们认为自动化测试能节省成本和解决一些测试方面的问题。
但是，同样存在很多恐怖的故事，失望大于期望、过程的痛苦，甚至出现在某些获得了收益的案例里。
我就曾经遇到过很多自动化测试项目最终不幸失败的案例。
这些项目进行了巨大的投入，最终都舍弃了花费数年的时间开发出来的自动化测试成果。
本文的目的就是基于有实际意义的指导，使人们能够理解和计算进行自动化测试工作所需的投入和可能获得的回报。
它描述了在建设自动化测试的过程中将会遇到的诸如商务、组织和管理、以及测试工作方面的影响。
在规划自动化测试的时候，要从多方面来考虑。
例如，自动化测试将会改变测试的复杂性，也将会改变从测试设计到测试运行的测试组织和管理方法。
它通常在组织管理方面带来广泛的影响，诸如任务执行、测试方法、甚至在产品的特性上。
在考虑自动化测试的收益和能力上，我们可以将影响因素分为有形的和无形的两类。
在自动化测试的前后可以用现有的测量技术（例如代码覆盖分析）来评估和计算测试的效果。
自动化测试可以达到非常有效的程度，可以增加代码覆盖的程度，可以提供一个新的角度来观察被测软件。
同时，自动化测试为我们提供了一种手工测试无法实现某些特定测试的解决途径。
自动化测试可以产生无数的指令和组合方式，仅仅受限于电脑的能力和可用来运行测试的时间而已。
这些测试可以在覆盖了100%的代码基础上去发现缺陷。
自动化的探针程序可以看到程序的内部，诸如中间处理的结果、内存中的数据、内部程序的状态，从而能判断被测软件是否能完成期望的功能。
2. 管理的观点我们需要在多个方面设置管理上的期望值：
无形成本和收益、不切实际的收益期望、手工测试和自动化测试的共同因素、组织的影响。
我们也要注意测量和计算的方法。
无形成本是非常难于合理的计算的。
在可衡量它们的点上，当我们确定它们的财务上的价值时会存在很大的变数。
在衡量自动化测试能带来多大的改变时也很难计算实际的数值。
通常情况下，有的无形成本是绝对的，有时是相对的，但是绝大部分是无法区分的，这要取决于一个人的观点和处理的方式。
基于这个理解，建议在大多数的案例中，尽量将这些无形成本从投入回报比的计算中省去。
一些无形成本的例子：
1） 无用户干预的测试。
尽管人的成本很容易计算，但是附加的计算机控制行为的成本是很难量化的。
2） 测试机构的经过改良的方法。
这一点通常能提高生产力，但随之而来的是自动化测试所需的新规则和新任务。
3） 测试机构的可观察到的骤然生产力的降低。
这个观察一般基于测试工作启动后人员开始逐渐增加时出现了停滞的现象，安装测试工具和创建自动化测试脚本的延迟。
4） 并非所有测试组里的人都期望改变。
自动化测试会迫使个人习惯产生很大的改变，甚至某些测试人员在仍需继续执行手工测试时，还得进行自动化测试。
5） 发布前软件产品测试循环的次数。
自动化测试能对产品的构建（Build）进行快速确认，并能鼓舞人们多次使用。
但是往复循环虽然能提高生产力和提高质量，也可能导致人员的懒散、关注力逐渐降低、和质量逐渐降低的情况。
6） 测试覆盖率。
既能增加测试覆盖率，也可能反之，主要取决于手工测试的效率，自动化的测试工具，和自动化的测试。
a） 某些测试只能用自动化测试来实现
b） 测试覆盖率改变的数值难于测量
c） 好的探索性的测试或许比一般的自动化测试更能发现一些不同寻常的情况
d） 手工测试可能使得某些情况或者环境难于进行自动化自动化测试管理的期望值往往在设定上受到媒体、会议、厂商的大肆宣传、相关书籍上对自动化优点的宣扬。
部分信息是准确的和可适用的，但是大部分信息是出现在某些特定的环境下，适用于某些特定的项目，并且被过分的强调了成功这个字眼。
自动化测试不是一个银弹。
它不能解决所有的测试方面的问题，需要进行小心细致的规划。
不正确的期望会最终导致一个获得了收益的自动化测试变成了失败的案例。
例如：
1）所有的测试都要自动化。
这是不切实际和可望不可即的。
2）从自动化测试获得立即的回报。
某些自动化测试可能能看到立即的效果，例如Build测试，但通常情况下，回报总是在投入一段时期后才能看到。
需要花费很多的时间和努力来创建大多数的自动化测试内容，而收效总是在一遍又一遍的测试运行之后才能获得。
3）零启动时间。
将测试自动化是要花费时间的。
要选择测试工具、搭建、安装，而规划和实现自动化测试则要花费数倍于手工测试的功夫。
4）自动化所有测试规划的内容。
自动化测试工具无法做所有的事情。
5）使用录制/回放进行回归测试。
这种情况仅适用于被测软件非常稳定，即将来只有极少的测试案例会发生改变。
这种情况非常少。
6）自动缺陷报告（无需用户干预）。
这通常会给测试的组织或开发带来很大的问题。
包括判断是否与已有缺陷重复，错误的失效原因探测，一个错误引起多个测试的失效，无法重现的错误等等。
组织管理方面的影响包括设计自动化测试和执行自动化测试所需的技能、自动化测试工具、自动化测试环境。
开发和维护自动化测试与手工测试之间是有很大的区别的。
在建设自动化测试时，工作技能变了、测试方法变了，甚至测试本身也发生了变化。
自动化测试还会对被测的产品、开发过程和发布过程产生潜在的影响。
我们不得不仔细考虑和分析这些影响中的积极和消极的因素。
自动化测试若想成功，要从管理上设置合理的期望值，要正确地认识到将要从自动化测试中获得哪些益处。
关键是要牢记自动化测试的目标是要在某些方面将测试做的更好。
自动化测试仅仅是一个手段，借助这个手段来完成我们的任务—测试一个软件产品。
在管理测试工作和向测试工作进行投入方面，成本/收益的分析向我们提供了非常有用的信息。
我们也要看到，不同的自动化测试实施行为将会带来好处，也会带来问题。
例如，自动化测试将会减少测试所需的人力资源，从而节省运行测试过程中的人力耗费。
但是，自动化测试也可能会产生各种各样的结果，需要耗费更多的人力进行分析，从而产生比手工测试更多的人力成本耗费。
通常情况下，获得自动化测试的结果后，需要更长的时间去分析和隔离所发现的缺陷。
自动化测试ROI分析
（二）
投入回报比的影响要素
投入回报比（ROI）通常用获得的收益除以投入成本来计算。
如果我们开始一个新的项目，我们就用测试的价值除以测试的成本来计算测试的投入回报比。
有时，自动化测试的引入发生在手工测试已经完成的一段时间之后。
自动化测试的经济成本通常可以描述为固定成本或者可变成本。
固定成本包括设备、工具、培训等。
固定成本不受自动化测试的成果数量和运行次数的影响。
而可变成本随着所开发出来的自动化测试的成果数量以及自动化测试的运行次数而增加或者减少。
自动化测试固定成本的例子：
1）硬件
2）应用软件的许可证
3）应用软件的技术支持
4）自动化测试环境的设计和搭建
5）自动化测试环境的维护
6）脚本开发工具软件
7）脚本开发工具的许可证
8）测试工具的培训
9）测试工具的引入和启动
自动化测试可变成本的例子：
1）自动化测试用例的设计
2）自动化测试用力的实现
3）自动化测试的维护
4）自动化测试用例的执行
5）自动化测试结果的分析
6）缺陷的报告
7）测试结果的报告
8）测试执行数据的保存
9）自动执行的测试
手工和自动化测试具备一些共同的要素。
共同要素的例子：
1）被测软件的分析
2）测试的规划
3）基础测试的设计
4）缺陷的报告
5）测试结果的报告的管理
我们在计算自动化测试的经济要素时，可以将它与两个事物进行比较：
手工测试或不进行测试（接受未知的风险而不进行测试）。
在计算回报时，我们需要选定计算的时间周期（t）。
通常情况下，可以根据一个项目的里程碑来确定计算的时间周期。
而且，自动化测试的回报是发生在新版本发布之后的，也可以基于版本的发布来确定计算周期，同时要与下一个版本发布、下下一个发布保持一致。
以这两种计算周期来计算自动化测试的回报，可有助于我们非常清楚的了解长期和短期的自动化测试收益。
自动化测试的固定成本不是绝对值。
这些成本需要在他们的有用生命周期内进行阶段性的分配，并且用时间周期（t）来调整。
t的值要基于管理因素进行选择，例如产品发布之间的时间间隔、ROI的计算、对工具使用寿命的期望、对测试的寿命的期望等等，以达到使t值被计算时的合理性、有用性和简易性。
这些成本的分配是以成本乘以t，再除以使用寿命。
例如，如果一个工具价格是25000元，期望的使用时间是两年，则第一年的成本是12500元（25000*1/2）。
如果用四年的时间来计算则是50000元（25000*4/2）。
投资的成本在工具的服务年限内都是要计算价值的。
如果工具的服务年限为1年，则第一年的费用就是25000元。
（同样的，如果一个接受完培训的人在培训后就离开了所在部门，就失去了培训的整个成本，就不能把这个成本在时间周期内进行分摊）。
相比于手工测试，自动化测试的最大价值就在于每次测试运行时的低成本。
这就带来了计算ROI时的两个要素：
自动化测试的运行次数（n1）和手工测试运行次数n2。
自动化测试是需要维护的，所以自动化测试脚本在变更之前的运行次数就显得非常重要了。
很多自动化测试难于运行就是因为GUI的频繁改变造成的。
自动化测试组使用录制/回放的技术创建了自动化测试脚本，并且衡量出来用手工测试运行三次所需的工作量。
在确保测试与软件开发同步的过程中，维护工作包括重新录制测试脚本和测试结果。
观察发现自动化测试组好像测试做的少，而不停的进行重新录制。
所以在重新计算自动化测试脚本的平均运行次数（发生变更之前）后，发现这个数字是1.2。
五分之四的脚本只运行了1次（在不得不重新录制它们之前）。
最后，这种低生产力的录制/回放方式不得不被放弃了。
针对成本，这些影响因素可以在更深层次上进行划分，一种是自动化测试和手工测试之间的相同性质的，一种是不断增长或者降低的。
这些共同影响因素可以被摒弃在自动化测试ROI计算之外，因为它们既不是成本也不是收益。
当我们进行自动化测试时，不断增长的影响因素可以看作成本，而不断降低的影响因素则看作收益。
某些因素总是不断增长或者降低，而大多数变化的因素可以是成本或者收益，主要取决于自动化测试的类型和自动化测试取得的效果。
下面是一些例子：
变化的因素（可以是自动化测试的成本，也可以是收益）：
1） 自动化测试环境的维护（可能是不断增加的成本，也可能在整个的维护成本中不断降低）
2） 测试案例的执行
3） 测试结果的分析
4） 缺陷的报告
5） 测试结果的报告
6） 测试数据的生成
自动化测试的收益：
1）测试执行的保存
2）系统自动执行的测试结束后的工作
自动化测试的成本：
1）硬件
2）测试环境中软件的许可证
3）测试环境中软件的技术支持
4）自动化测试环境的设计
5）自动化测试环境的实现
6）脚本工具
7）测试工具的许可证
8）测试工具的培训
9）测试工具的引入和启动
10） 自动化测试用例的设计
11） 自动化测试用例的实现
12） 自动化测试的维护
自动化测试ROI分析（三）
7. 总结
自动化测试不总是必须的、适当的、或者是有效成本投入的。
有时候，当我们基于一个期望的投入产出比进行决策时，分析可以指导我们知晓自动化测试在哪些方面将会给我们带来收益。
计算这些投入产出比的最好方法就是比交自动化测试和手工测试的成本和获得。
在是否应用自动化测试来改进测试的管理决策上，需要对自动化测试的成本和收益进行识别和估测。
这也能帮助我们识别哪些因素是我们应该关注的，而这些因素引致了大部分的投入。
当需要进行自动化测试时，无论是由于合同还是技术上的约束，ROI的计算可能都是不一定能带来帮助的。
回报中包含了很多无形的影响因素，因此用算术来进行计算也无法获得自动化测试的实际的价值。
自动化测试开展策略分析
一般而言，刚开始自动化测试时，很多时候，很多人都不知道如何入手或者还有一部分人都信心满满，决心要建设出一份大的平台，可是事实在于自动化测试面临的问题一在于技术，二在于环境形势。
每个公司有不同的需求、有不同的环境、不同的人员支持，所以做自动化测试所需要涉及的外界因素太多，就如黑天鹅效应中的说法，你所自认为的白天鹅中也许就隐藏着一只黑天鹅，它的出现会导致你的整体计划崩盘。
所以，做自动化测试也一样，所依赖的东西太多，就能引起的整体变化太多，所以我觉得我们的基本策略就是：
不断预测、不断总结，然后是拥抱变化
总结的从开始到一定阶段的建设自动化测试的策略如下（麻烦有不同想法或者别的策略的朋友帮忙补充）：
1、分析需求并且细化需求，自动化测试是急不来的事情，不能指望用他来解决所有问题，所以必须明确需求，将需求一步一步写下来，然后从简单到容易开始击破。
2、评估资源，围绕人力支持、部门测试流程情况以及产品业务来决定自动化测试要先从哪一步开始走，并哪一步为阶段。
自动化测试必须最终与整体的测试流程相结合，才能发挥作用，否则只会越走越远。
3、从最小的需求开始入手，也许是一个工具或者是一个线性脚本。
总之，先解决一点需求，然后从点到面。
获得一个面后，将其授权，然后再做点，这样一步一步进行铺张，其实说白了，也是一个自动化测试信心和价值建立的问题。
4、记：
简单。
要将一个东西发扬出去，那么它必须简单，技术人员的思维有时候总是把东西做的很复杂，因为有时候会觉得很炫，但需要做好一个东西得到发扬的话，则需要将一个复杂的东西让人看起来很简单。
一个工具或者一个框架，最好只有一个修改入口和一些API拓展机制。
让测试人员用起来和拓展起来都很简单。
5、CBB:
CBB在软件开发中俗称“软件模块共享”.而在自动化测试中也是一样，要建立自己的开发库，不仅提供给以后的测试开发使用，更是给测试人员使用，能够在其基础进
升级会员 