自动化测试ROI实践

自动化测试是一项“一旦开始，就需要持续投入”的工作，所以它一直是测试领域的一块鸡肋。不做吧，好像手工测试重复得让人有些厌倦，而且手工测试时间也缩短不了。做吧，害怕投入的比回报要多。

没实施自动化的团队有各种各样的困扰。有的说：“项目有太多的老代码需要补充自动化测试脚本，补不起！”有的说：“项目开发太紧张，如果同时还要自动化，等不起！”还有的说：“自动化测试工具太贵了！买不起！”确实，各种各样的“伤不起”使得大量的组织在“要不要自动化”这个问题上总在了解和观望，踌躇不前。

我们阅读了一些关于自动化测试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的主要业务流程的自动化。我们的投入和收益实际情况如下：

从上述数据中我们可以看到自动化测试的收益并不高。这迫使让我们思考下一步如何才能获得更多的收益。而我们也马上产生了许多具体的想法。1、提高执行的次数。这可能需要我们把自动化测试和每日构建集成起来。2、在增加发现缺陷可能性方面，可以（1）利用现有的自动化测试脚本，但增加数据的多样性，这样脚本方面投入不大，但能增强发现缺陷的可能；（2）增加现有脚本的检查点，发现更多可能的缺陷；（3）分析缺陷，增加对容易聚集缺陷的相关功能的覆盖。3、优化脚本：对脚本的结构进行优化，提高复用性、灵活性、易维护性；加强脚本的稳定性和健壮性，提高其正确执行的概率。

接下来，我们尝试了自动化测试脚本和版本构建的持续集成，增加了测试数据的多样性，并随着项目的变化对原有脚本进行了必要的维护。与此同时，我们的项目也意外地碰到了多次硬件设备迁移，软件（操作系统、数据库、底层构架、第三方控件等）版本更新，以及小版本和并行版本的测试。此时我们都借助于自动化测试脚本，迅速地验证了版本，发现了一些缺陷，在项目组面临巨大的时间压力的时候提升了大家对质量的信心，项目经理开始纷纷表示对自动化测试的支持！自动化测试如同零存整取，平时挤一些时间去做，到了紧急需要的时候，那种雪中送炭的感觉真的很棒！

第四部分：结语

我们的自动化测试刚刚起步，度量的ROI结果也并不漂亮，但我们相信只要跨出了第一步，自动化测试的千里之行始于足下。

自动化测试ROI分析（一）

1.   介绍很多领导将自动化测试视为银弹。他们认为自动化测试能解决诸如测试规划、测试成本、缺陷报告等很多问题。自动化测试在很多方面会带来积极的效果，并且已经有很多成功的案例能使人们认为自动化测试能节省成本和解决一些测试方面的问题。但是，同样存在很多恐怖的故事，失望大于期望、过程的痛苦，甚至出现在某些获得了收益的案例里。我就曾经遇到过很多自动化测试项目最终不幸失败的案例。这些项目进行了巨大的投入，最终都舍弃了花费数年的时间开发出来的自动化测试成果。往复循环虽然能提高生产力和提高质量，也可能导致人员的懒散、关注力逐渐降低、和质量逐渐降低的情况。

b）       测试覆盖率改变的数值难于测量

c）       好的探索性的测试或许比一般的自动化测试更能发现一些不同寻常的情况

d）      手工测试可能使得某些情况或者环境难于进行自动化自动化测试管理的期望值往往在设定上受到媒体、会议、厂商的大肆宣传、相关书籍上对自动化优点的宣扬。部分信息是准确的和可适用的，但是大部分信息是出现在某些特定的环境下，适用于某些特定的项目，并且被过分的强调了成功这个字眼。自动化测试不是一个银弹。它不能解决所有的测试方面的问题，需要进行小心细致的规划。不正确的期望会最终导致一个获得了收益的自动化测试变成了失败的案例。

例如：

1）所有的测试都要自动化。这是不切实际和可望不可即的。

自动化测试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.   总结

自动化测试不总是必须的、适当的、或者是有效成本投入的。有时候，当我们基于一个期望的投入产出比进行决策时，分析可以指导我们知晓自动化测试在哪些方面将会给我们带来收益。计算这些投入产出比的最好方法就是比交自动化测试和手工测试的成本和获得。在是否应用自动化测试来改进测试的管理决策上，需要对自动化测试的成本和收益进行识别和估测。这也能帮助我们识别哪些因素是我们应该关注的，而这些因素引致了大部分的投入。

自动化测试开展策略分析

一般而言，刚开始自动化测试时，很多时候，很多人都不知道如何入手或者还有一部分人都信心满满，决心要建设出一份大的平台，可是事实在于自动化测试面临的问题一在于技术，二在于环境形势。每个公司有不同的需求、有不同的环境、不同的人员支持，所以做自动化测试所需要涉及的外界因素太多，就如黑天鹅效应中的说法，你所自认为的白天鹅中也许就隐藏着一只黑天鹅，它的出现会导致你的整体计划崩盘。所以，做自动化测试也一样，所依赖的东西太多，就能引起的整体变化太多，所以我觉得我们的基本策略就是：不断预测、不断总结，然后是拥抱变化        总结的从开始到一定阶段的建设自动化测试的策略如下（麻烦有不同想法或者别的策略的朋友帮忙补充）：        1、分析需求并且细化需求，自动化测试是急不来的事情，不能指望用他来解决所有问题，所以必须明确需求，将需求一步一步写下来，然后从简单到容易开始击破。        2、评估资源，围绕人力支持、部门测试流程情况以及产品业务来决定自动化测试要先从哪一步开始走，并哪一步为阶段。自动化测试必须最终与整体的测试流程相结合，才能发挥作用，否则只会越走越远。        3、从最小的需求开始入手，也许是一个工具或者是一个线性脚本。总之，先解决一点需求，然后从点到面。获得一个面后，将其授权，然后再做点，这样一步一步进行铺张，其实说白了，也是一个自动化测试信心和价值建立的问题。        4、记：简单。要将一个东西发扬出去，那么它必须简单，技术人员的思维有时候总是把东西做的很复杂，因为有时候会觉得很炫，但需要做好一个东西得到发扬的话，则需要将一个复杂的东西让人看起来很简单。一个工具或者一个框架，最好只有一个修改入口和一些API拓展机制。让测试人员用起来和拓展起来都很简单。        5、CBB:CBB在软件开发中俗称“软件模块共享”.而在自动化测试中也是一样，要建立自己的开发库，不仅提供给以后的测试开发使用，更是给测试人员使用，能够在其基础进行很快速的共享和拓展。        6、覆盖率分析：单纯的用例自动化很难突显自动化测试后，其到底覆盖了多少点，通过了哪些点，一个用例的拓展也不是很好拓展。因此需要划分为点的方式，即可以每个脚本对应一个测试点，每次测试，可以统计覆盖了多少个点，通过率如何，即产用产品-模块-测试点统计覆盖率的方法。        7、ROI分析：在自动化测试一定阶段后，做好自动化测试ROI分析，绝对不打没有目标性的仗，我们到底为了什么做自动化测试，很多人会说是为了保证质量，首先，大家都明白，自动化测试不是用来发现问题的，这个说法没有错，但是问题在于，好不容易做起来的自动化测试，结果没有好的ROI分析机制，乱做了一通，该做的测试用例没有自动化，不该做的做了一堆，结果导致自动化测试的开发和维护成本很高，收效成本很少，所以，到中期阶段，需要有一个ROI分析机制帮助评估自动化测试脚本的建设。        8、成熟度模型：现在业界有一些人已经提出了自己的自动化测试阶段，这些阶段在一定基础上是值得参考的，但是上面也说了，每个公司、每个部门的情况和需求是不一样的，其依赖的因素很多，所以在自动化测试发展过程中，可以从一个试点产品或者一个项目中不断分析抽象，建立一套自己的成熟度模型，然后进行推广。在每个阶段评估不同项目、不同产品的自动化测试成熟度。        总结：做自动化测试不是一件容易的事情，但也不是一件值得怀疑的事情，它有它的价值，正所谓存在即合理，也许我们做的是要找到正视它的价值，不浮夸它，也不贬低它，踏踏实实做它应该带来的效果。

自动化的收益浅谈

自动化测试是一个需要持续投入的系统工程，如何去衡量它的投入成本和收益回报之间的关系呢，这一直都是我们在思考的问题，如何让自动化测试给我们带来高的投资回报。

我们先来看看自动化需要哪些成本的投入，1、需要研发成本的投入，我们需要构建一个自动化框架，而且这个投入是持续性的，因为不仅需要维护，也需要不断完善。2、自动化工具成本，我们在构建自动化框架时，可能需要引入一些成熟的工具的使用。3、机器成本，搭建一个自动化测试是必须的。4、培训成本，自动化在测试组内的推广需要做大量的培训。5、学习成本，测试人员需要花时间去学习自动化。6、自动化脚本开发成本。7、自动化脚本维护成本。等等。

自动化测试作为一种测试手段，从直接效益来说，给我们带来工作成本的节约，那么这样的自动化测试实施算是成功的。我们从一个项目角度来分析自动化实施的效益，这里我们忽略前期自动化成本的投入，所以我们来看一个比较简单的投资回报（ROI）的计算公式：

ROI = （V手-V自）/V自

V手：手工执行用例的成本       V手 =  设计成本+用例数*次数*手工时间+问题分析成本

V自：自动化执行用例的成本   V自 = 设计成本+脚本开发成本+脚本维护成本+问题分析成本

上面公式中，我们带入后成为：

ROI = （（用例数*次数*手工时间）-（用例数*开发时间+脚本维护成本））/（设计成本+脚本开发成本+脚本维护成本+问题分析成本）

演化后的公式，我们假设用例数为10，次数为1，手工时间为5分，开发时间为10分，脚本维护时间为20分。

那么在这样的情况下，“（（用例数*次数*手工时间）-（用例数*开发时间+脚本维护成本）”是负数，也就是投资回报是负的。

如果我们增加用例的执行次数呢，增加到3次，大家会发现投资回报变正了，这个时候我们才有了收益。

我们想继续扩大我们的收益，还能怎么做呢，从公式我们不难看出，我们需要降低“开发时间”、“维护成本”，让我们的脚本能更简单、更快速的产生，并且更方便的维护。

另外“设计成本”、“问题分析成本”这些都是我们可以去降低的，让我们的自动化用例覆盖更合理，自动化结果分析更智能话，都可以很大程度的提高我们自动化实施的收益

当然自动化测试的投入远不止这么简单，考虑的因素很多，会带来很多无形成本的投入，带来的收益也不仅仅只是成本的节约，所以这里只是简单的论述自动化的投资回报，带来一些对我们自动化方向上的思考。

测试自动化的计划和实施

测试自动化的计划和实施系列文章，最近开始酝酿思路，初步打算分为四个部分来组织，这也是我亲身经历的一个自动化项目的四个阶段，大家可以对号入座，看看你所在的公司或者组织处于自动化实施的哪个阶段？

第一个阶段：从无序到有序

这个阶段主要是自动化测试的引入，从一开始的无序的自动化测试，摸着石头过河，到慢慢找到一些窍门，其中的关键点/转折点是自动化测试系统或者说自动化测试平台的出现。这个时间大概持续了1年左右。这部分重点介绍如何找到通往有序的方法和思路。

第二个阶段：从烦杂到豁然开朗

这个阶段主要介绍基于原始的自动化测试系统开发积累到一定程度的问题显现。逐步暴露的问题在这个阶段到了非解决不可的程度，主要的问题是什么？解决的思路是什么？到也是我们自动化测试进展最艰难的时候。希望能对你有所帮助。

第三个阶段：从点到面铺开

这个阶段主要介绍自动化测试系统和平台的推广，好的平台是推广和大面积使用的前提和保证。如何保证平台在推广过程中能顺利？推广过程中我们遇到了哪些阻力？我们是如何解决这些阻力和克服困的？

第四个阶段：收获和ROI

这个阶段分析在自动化测试推广以后的一些问题，我们应该如何计算我们的产出和投入，投资回报应该如何计算？ 这个阶段我们会遇到什么问题？如何解决？

自动化测试的计划和实施第一阶段

从自动化测试决策的制定到决定进行实施，这中间有很多工作要做。包括说服你的老板，自动化是一个持续投入的过程，而且初期投入很大，短期内无法看到回报，而且要持续进行投入，不能半途而废，投入的过程中需要各个部门的通力合作，上至包括系统分析师，研发人员特别是研发部门经理，项目经理。下至系统测试部门等等，每个环节都跟自动化测试有着直接和间接的关系。一旦决定开始进行实施自动化测试，就基本上没有回头的道路，因为前期的巨大的投入，导致如果想要中途终止，那么前期的巨大投入就是严重的资源浪费。

开头讲了一点题外话，现在开始介绍实施的第一阶段——从无序到有序。

我参与的这个产品的自动化项目开始于二零零三年初，从一开始就缺少经验，我们走过的每一步现在回想起来都是痛苦的经历。因为大家都没有类似的自动化经验，加上团队的每个成员基本上都是开发出身，加上项目进度紧张，缺乏必要的自动化测试理念和自动化测试的相关培训。更严重的事，这个时候，自动化刚刚起步，没有一个自动化的平台支持。结果是每个工程师把一个单独的自动化测试项目（一个模块）作为一个独立的工具进行开发。结果导致自动化测试用例的混乱，而且无法进行维护。不同工程师开发出来的东西也是千奇百怪。自动化团队的工程师慢慢的失去了耐心和信心，产生了抵触情绪，这个为以后的自动化测试的顺利开展带来了一定的障碍。

这个时候的教训就是不能急于求成，不能为了一味的追求速度和效率。自动化团队的经理应该控制项目的节奏，不能妥协于项目的巨大压力。逐步培养自动化开发工程师的兴趣和探索动力。

另外就是自动化团队成员没有系统全面的培训和严格的规范约束，即使每个人都有能力开发出来自动化测试脚本，但是却难于维护和执行。这个时候我们就认识到自动化测试平台或者架构的重要性不仅仅在于使得测试脚本的开发更加容易进行，而且可以统一大家的思想和测试脚本的一致性。在这之前我们对自动化测试平台的认识比较肤浅。

在不同的阶段，自动化团队的成员构成也不尽相同。在这个阶段，自动化团队的成员基本上都是自动化开发工程师。就是把手工的测试模块进行脚本化。然后可以自动化进行执行。

自动化测试的计划和实施第二阶段

第二阶段的副标题：从烦杂到豁然开朗

其实这是我们经历的真实的过程，从一开始的没有完整的自动化平台和对平台重要性的认识不足，加上缺乏相关的经验，这个过程可谓吃尽了苦头。这这个阶段，即使有了测试平台的支持，随着脚本技术的进步，我们仍然要为以后的维护和扩展付出很大的代价。

这样的痛苦过程经历了大概半年左右的时间，当随着脚本技术的探索思路越来越清晰的时候。其中最关键的里程碑是API概念的提出，就是一个分层的概念。其实也没有多少创意而言，只是在自动化测试概念中提出来，颇有一些不同。

自动化测试的被测试对象总是千差万别的，针对不同的测试对象开发不同的API显然不是办法，我们提出了三层API的概念。底层API，针对一些基本的操作，比如界面GUI的操作，封装一些基本的原子操作方法：按钮，下拉框，列表框等。针对服务器的操作，封装一些telnet，执行命令，获返回结果等。针都数据库操作（oracle和mysql分开进行），封装一些查询，提交，连接等原子操作的API.随着业务的不断变化，这些原子操作不需要进行维护，只有在需要的时候进行扩充。原子层之上是逻辑层，这一层的API变化的可能性比较大，对他们进行版本管理，这是一个颗粒相对较大的封装，可以充分一些原子层的操作进行组装。最大限度的重用原子层的代码。最上层就是业务层的操作，这部分的颗粒更大。利用业务层的接口进行组装。需要注意的是，对于每一层的API，接口要进行很好的设计和论证，充分考虑扩充和重用。必要的时候利用变参。

上面讲了一些具体实现，这是从技术的实现角度考虑的。另外，平台的开发工作是同步进行的。好的技术实现离不开平台的支撑。还需要重复那句话：好的平台不仅仅使得测试开发变得更加容易，而且可以统一测试开发人员的思想和规范性。

平台的东西只做简单介绍，我们平台开发基于Linux，主要语言是前台的Java和后台的Tcl，数据库选的Oracle.整个系统是一个分布式的测试平台，前端是Web浏览器，后端是执行引擎。用户可以直接利用前面说的原子API在平台上书写测试用例，并进行执行。这是一个很好的IDE.有很多比较强大的功能，包括测试执行，定制，开发，统计。

至此，自动化进入了相对来说正规化的阶段。

自动化测试的计划和实施第三阶段

进入到自动化测试的第三阶段，此时距离当初开始实施自动化测试的决定，两年三个月已经过去了，可见自动化测试的实施不是一蹴而就的，更不可急功近利。第三个阶段的标志是有点到面的全面铺开。

自动化测试开展的初期，可以是一个小组，几个人进行小面积的试点，这样投入的成本不是很大，即使失败了，也是可以理解和接受的，而要想取得投资回报或者大面积的试用和推广，前提的试点也是必须的。但是仅仅靠几个人是不可能把自动化测试做起来的。自动化测试的开发工作是一个持续的过程，又是一个矛盾体。

持续的过程体现在：随着回归测试的不断进行，老的功能不断被自动化起来，就有一定的维护工作量，另外，新功能的测试不断完善和稳定，又变成可以进行自动化测试的老功能。所以自动化测试是一个持续进行的过程，另外，又是一个持续改进的过程，随着自动化测试技术的不断成熟和测试业务的不断丰富，以前的老功能的测试用例或者测试脚本也同样需要进行更新和维护。

矛盾体体现在两个方面：首先自动化测试的开发和维护本身需要对测试脚本和测试业务有一定的熟悉。实际情况往往并非如此，精通测试业务的测试工程师一般情况下对测试脚本甚至自动化测试一无所知。而对测试开发非常熟悉的自动化测试工程师又不熟悉业务，所以矛盾就这样产生了。另外，从整体来看，自动化测试工程师的数量肯定远远小于手工测试工程师，这样，对业务测试工程师熟悉自动化测试知识，了解测试平台和测试脚本就提出了更高的要求。如果有一半的测试工程师都能熟悉测试脚本，可以试用测试平台进行相关的自动化测试开发，那么可以肯定的说：自动化测试已经成功了一大半。

矛盾的另外一个方面是资源的问题。手工测试工程师往往由于测试进度的压力疲于应付，所以对自动化测试平台或者脚本的学习缺少时间，这个时候，测试经理就需要有很好的协调能力，可以从团队内部抽调部分懂开发，学习能力快的测试工程师进行集中的培训，在测试团队内部形成一种自动化测试的氛围，从而引导整个测试团队更好的进行自动化测试的开展。还有一种问题，就是我们在实际操作过程中遇到的，虽然不是典型，不过也应该注意避免这种情况的发生，手工测试工程师有些保守的观念，对自动化测试技术是排斥的。他们错误的认为，自动化测试的开展是对手工测试的冲击，如果所有的feature都被自动化执行了，那么手工测试就被取代了。其实这是一种十分狭隘的心态，至于道理为什么，前面也已经提及了，自动化测试是一个持续的过程。这里就不多说。

如果自动化测试可以顺利在一个系统测试团队中开展，并且很好的坚持下去，很快自动化测试的效果和投资回报就能体现出来了。

自动化测试的计划和实施第四阶段

第四阶段，也是最后一个阶段了。在开始这个阶段之前，还想多说几句，今天又有朋友说他们公司打算实施自动化测试了，开发经理主导的。他们对测试自动化的认识还是停留在自动化测试工具上。只是十分要命的。自动化测试的初衷是要缩短测试周期，出发点是好的，但是步骤明显有问题，测试周期的缩短是可以靠提高测试效率，改进测试方法和引进测试工具来达到的，但是不是决定因素。测试流程的规范才是最根本的，如果一个组织测试流程不规范，想通过引入自动化测试来规范这一流程是很不现实的。

好了，现在开始正题。

自动化测试的第四阶段是收获和ROI（投资回报）

进入这个阶段，基本组织的测试自动化已经步入正轨和良性的发展，随着回归测试的不断深入，自动化测试的投入也初显成效。一方面，通过不断的回归测试，测试的质量得到了一定程度的提高，另外，测试效率也大大提高。同事，因为测试和开发的沟通渠道日益畅通，产品的稳定性和可测性也有了改进。这是一个良性的互动过程。

通过不断的测试执行，测试的投资回报这个时候可以进行一些统计。

先谈谈投资回报（Return On Investment）

ROI不是自动化测试专有的名词， 任何项目都要讲求ROI， 没有事先做过ROI分析的项目都会面临失败的危险

ROI是投入总成本和实际获利之间的一个对比率， 如果实际获利大于实际投入总成本，则本次投资是合算的

ROI可以由两方面来计算： 在向某件事投入之前， 先估计一下可以获利多少， 在执行之后再看一看实际获利多少，前者是用度量的方法来预测， 后者是进行评估。

一个简单的自动化测试投资回报率的计算方法

自动化测试成本 = 工具软硬件成本 + 脚本开发所耗成本 + （脚本维护成本 X 脚本执行次数）+ （脚本执行成本 X 脚本执行次数）

手工测试成本 = 测试用例设计开发成本 +（测试用例维护成本 X 测试用例执行次数） + （手工测试执行成本 X 测试用例执行次数）

利益 = 手工测试成本 – 自动化测试成本

ROI = 利益/自动化测试成本

注： 自动化测试的ROI无法显示在测试过程中查找出来的缺陷个数

至此，这个系列的原创文章全部结束。

转载来自 ：https://wenku.baidu.com/view/132e15cce109581b6bd97f19227916888486b9c1.html