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