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结果也并不漂亮，但我们相信只要跨出了第一步，自动化测试的千里之行始于足下。