自动化测试是一项“一旦开始，需要持续投入”的工作，所以它一直是测试领域的一块鸡肋。不做吧，好像手工测试重复得让人有些厌倦，而且手工测试时间也缩短不了。做吧，害怕投入的比回报要多。
没实施自动化的团队有各种各样的困扰。有的说：“项目有太多的老代码需要补充自动化测试脚本，补不起！”有的说：“项目开发太紧张，如果同时还要自动化，等不起！”还有的说：“自动化测试工具太贵了！买不起！”确实，各种各样的“伤不起”使得大量的组织在“要不要自动化”这个问题上总在了解和观望，踌躇不前。
我们阅读了一些关于自动化测试ROI的文章，发现大多都是介绍各种不同的计算方法，但来自实际的数据分享比较少。所以，2011年当我们组织想推行自动化测试的时候，为了打消大家（尤其是管理层）对于自动化测试的投入和产出方面的疑虑，计算我们自己的自动化测试投资回报率ROI（Return on Investment）成了我们启动时考虑的问题。本文将分为四部分介绍我们的实践方法和结果。
第一部分：业界计算自动化测试ROI的方法
简言之，ROI = 收益/投入。但收益如何计算，投入包括哪些，众说纷纭，并没有一个定论。
在Dion Johnson的“test automation ROI”中给出了三种计算自动化测试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 |
接下来，我们尝试了自动化测试脚本和版本构建的持续集成，增加了测试数据的多样性，并随着项目的变化对原有脚本进行了必要的维护。与此同时，我们的项目也意外地碰到了多次硬件设备迁移，软件（操作系统、数据库、底层构架、第三方控件等）版本更新，以及小版本和并行版本的测试。此时我们都借助于自动化测试脚本，迅速地验证了版本，发现了一些缺陷，在项目组面临巨大的时间压力的时候提升了大家对质量的信心，项目经理开始纷纷表示对自动化测试的支持！自动化测试如同零存整取，平时挤一些时间去做，到了紧急需要的时候，那种雪中送炭的感觉真的很棒！
第四部分：结语
我们的自动化测试刚刚起步，度量的ROI结果也并不漂亮，但我们相信只要跨出了第一步，自动化测试的千里之行始于足下。