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

好了，现在开始正题。

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

通过不断的测试执行，测试的投资回报这个时候可以进行一些统计。
先谈谈投资回报（Return On Investment）
ROI不是自动化测试专有的名词, 任何项目都要讲求ROI, 没有事先做过ROI分析的项目都会面临失败的危险
ROI是投入总成本和实际获利之间的一个对比率, 如果实际获利大于实际投入总成本, 则本次投资是合算的
ROI可以由两方面来计算: 在向某件事投入之前, 先估计一下可以获利多少, 在执行之后再看一看实际获利多少, 前者是用度量的方法来预测, 后者是进行评估。
一个针对测试（没有自动化）改进过程的ROI的简单计算如下：

一个简单的自动化测试投资回报率的计算方法
自动化测试成本 = 工具软硬件成本 + 脚本开发所耗成本 + (脚本维护成本 X 脚本执行次数) + (脚本执行成本 X 脚本执行次数)
手工测试成本 = 测试用例设计开发成本 + (测试用例维护成本 X 测试用例执行次数) + (手工测试执行成本 X 测试用例执行次数)
利益 = 手工测试成本 – 自动化测试成本
ROI = 利益/自动化测试成本
注: 自动化测试的ROI无法显示在测试过程中查找出来的缺陷个数
一个可以参考的自动化测试的ROI的计算例子。

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

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

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

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

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

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

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

自从上个月介绍了自动化测试的计划和实施第一阶段，这阵子一直都在忙别的事情，加上博客访问断断续续，所以没有接下去。打算利用这几天的时间把剩下 的几个阶段完整的记录下来。也对打算实施自动化和已经在实施自动化过程中的朋友有点帮助吧。另外，也完成自己的承诺，五一之前完成这几篇文章。嘻嘻。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

第四个阶段:  收获和ROI

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

最近一直比较忙,可能时间不是很连续,初步打算再五一之前能完成这几篇文章. 希望大家有耐心 ^_^ ,同事也希望能多听听大家的意见和对文章的期望.

自己申请的域名终于找到安家立身之所了,在kingofhosts.com申请了一个空间.配置好域名解析服务器,Okay了.

欢迎大家去我的新网站参观访问,比较好记: rickyzhu.com

不过有好的技术文档还是会在这边刊登的.请放心了.

多谢.

一、概述

软件测试自动化，从计算机这一庞大学科发展至今，最根本的意义是解决手工劳动的复杂性，成为替代某些重复性行为模式的最佳工具。

 

二、实施软件测试自动化的理由

1.         提高测试效率和降低测试成本

2.         将重复性强的测试由手工转为可以独立开来自动实现的。

3.         实现快速的回归测试，提高新版本发布的速度和质量，尤其是不能适应目前流行的迭代开发，回归测试频度高、工作量大，人工的测试很难对新的迭代版本作出快速评估。

4.         自动测试可以避免，人工测试容易犯的错误：错误测试、漏测试、多测试和重复测试等

5.         典型的应用，例如多用户并发注册、并发交易请求和并发交易应答，这种情况用人工测试几乎是办不到的，而自动测试却很容易。

6.         对于很常用的功能性边界测试测试，人工测试非常耗费时间，而自动测试很快且准确。

可以说，实施测试自动化是软件行业一个不可逆转的趋势，如果在这个领域走在了前列，无论从企业的核心竞争力还是个人的工作技能来说，都有巨大的优越性。

 

三、软件测试自动化的引入条件

自动化测试能大大降低手工测试工作，但决不能完全取代手工测试。完全的自动化测试只是一个理论上的目标，实际上想要达到 100% 的自动化测试，不仅代价相当昂贵，而且操作上也是几乎不可能实现。一般来说，一个 40-60% 的利用自动化的程度已经是非常好的了，达到这个级别以上将过大的增加测试相关的维护成本。

 

测试自动化的引入有一定的标准，要经过综合的评估，绝对不能理解成测试工具简单的录制与回放过程。实际上，从实现成熟度来说，自动化测试分五个级别：

级别	说明	优点	缺点	用法
一级	录制和回放	自动化的测试脚本能够被自动的生成，而不需要有任何的编程知识	拥有大量的测试脚本，当需求和应用发生变化时相应的测试脚本也必须被重新录制	当测试的系统不会发生变化时，实现小规模的自动化
二级	录制、编辑和回放	减少脚本的数量和维护的工作	需要一定的编程知识；频繁的变化难于维护	回归测试时，用于被测试的应用有很小的变化
三级	编程和回放	确定了测试脚本的设计，在项目的早期就可以开始自动化的测试	要求测试人员具有很好的软件技能，包括设计、开发	大规模的测试套件被开发、执行和维护的专业自动化测试
四级	数据驱动的测试	能够维护和使用良好的并且有效的模拟真实生活中数据的测试数据	软件开发的技能是基础，并且需要访问相关的测试数据	大规模的测试套件被开发、执行和维护的专业自动化测试
五级	使用动作词的测试自动化	测试用例的设计被从测试工具中分离了出来	需要一个具有工具技能和开发技能的测试团队	专业的测试自动化将技能的使用最优化的结合起来

 

 

自动化测试能提高测试效率，快速定位测试软件各版本中的功能与性能缺陷，但不会创造性的发现测试脚本里没有设计的缺陷。测试工具不是人脑，要求测试设计者将测试中各种分支路径的校验点进行定制,没有定制完整，即便事实上出错的地方，测试工具也不会发觉。因此，制订全面、系统的测试设计工作是相当重要的。

 

自动化测试能提高测试效率，但对于周期短、时间紧迫的项目不宜采用自动化测试。推行自动化测试的前期工作相当庞大，将企业级自动化测试框架应用到一个项目中也要评估其合适性，因此决不能盲目的的应用到任何一个测试项目中，尤其不适合周期短的项目，因为很可能需要大量的测试框架的准备和实施而会被拖跨。

 

实施测试自动化必须进行多方面的培训，包括测试流程、缺陷管理、人员安排、测试工具使用等。如果测试过程是不合理的，引入自动化测试只会给项目团队带来更大的混乱。

 

那么应该具备什么样的条件才可以引入自动化测试呢，才可以最大可能的减少引入风险，并能够可持续性的开展下去呢？

第一，从项目规模上来说，没有严格限制。无论项目大小，都需要提高测试效率，希望测试工作标准化，测试流程正规化，测试代码重用化。所以第一要做到的，就是从公司高层开始，直到测试部门的任何一个普通工程师，都要树立实施自动化测试的坚定决心，不能抱着试试看的态度。一般来说，一个这样的软件开发团队可以优先开展自动化测试工作：测试与开发人员比例合适，比如1：3到1：5，开发团队总人数不少于10个。

第二，从公司的产品特征来说，一般开发产品的项目实施自动化测试要比纯项目开发要优越些。但决不是说做纯项目开发不能实施自动化测试，只要软件的开发流程、测试流程、缺陷管理流程规范了，自动化测试自然水到渠成。

第三，从测试人员个人素质和角色分配来说，除了有高层重视外，还应该有个具有良好自动化测试背景和丰富自动化测试经验的测试主管，不仅在技术方面，更重要的是在今后的自动化测试管理位置起着领导的作用。还要有几个出色的开发经验良好的测试人员，当然也可以是开发工程师，负责编写测试脚本、开发测试框架,还有一些测试执行者，他们要对软件产品业务逻辑相当熟练，配合测试设计者完成设计工作，并在执行自动测试时，敏锐的分析和判断软件缺陷。

综合分析上述三个条件，就可以决定是否推行自动化测试；但是为了减少实施风险，还要预测到其他潜在的风险，做好事先解决问题规避风险的思路。

 

四、对实施自动化测试的风险分析

资金风险，虽然有些项目具备实施自动化测试的条件，但还是要引入自动化测试后组织结构调整等方面的成本估算是很必要的。

 

自动化测试对软件功能类型的切入点的风险，开发的产品业务和功能是否需要自动化测试？包括白盒自动化测试、功能自动化测试和性能自动化测试。

 

软件自动化测试切入方式的风险，一定要将自动化测试与手工测试结合起来使用，不合理的规划会造成工作事倍功半。首先，对于自动化测试率的目标开始是 20/80 （20% 的自动化测试和 80% 的手工测试），当这些目标都实现了，再将自动化测试率提高。

 

时间估算，在评估完前面几项指标后，需要估算实施测试自动化的时间周期，以防止浪费不必要的时间，减少在人员、资金、资源投入上的无端消耗。虽然到测试自动化步入正轨以后，会起到事半功倍的效果，但前期的投入巨大，要全面考虑各种因素，明确实施计划并按计划严格执行，才能最大限度降低风险。

 

工作流程变更风险，测试团队乃至整个开发组织实施测试自动化，或多或少会因为适应测试工具的工作流程，带来团队的测试流程、开发流程的相应变更，而且，如果变更不善，会引起团队成员的诸多抱怨情绪；所以应该尽量减少这种变更，并克服变更中可能存在的困难。

 

五、什么条件下使用自动化测试

一般在这样的条件下使用自动化测试

l         具有良好定义的测试策略和测试计划（知道要测试什么，知道什么时候测试）

l         对于自动化测试你拥有一个能够被识别的测试框架和候选者

l         能够确保多个测试运行的构建策略

l         多平台环境需要被测试

l         拥有运行测试的硬件

l         拥有关注在自动化过程上的资源

 

如下条件下是宜采用手工测试：

l         没有标准的测试过程

l         没有一个测试什么、什么时候测试的清晰的蓝图

l         在一个项目中，测试责任人是一个新人，并且还不是完全的理解方案的功能性和或者设计

l         整个项目在时间的压力下

l         在团队中没有资源或者具有自动化测试技能的人

 

六、各测试阶段的自动化测试评估

测试阶段	描　　　　　　　述	备　　　　注
单元测试/ 组件测试	这个测试工作通常是开发人员的职责，很多不同的方法能够被使用，比如"测试先行"，它是一个测试框架，开发人员在编写代码前编写不同的单元测试，当测试通过时，代码也被完成了。	通过使用正式的单元测试，不仅能够帮助开发人员产出更加稳定的代码，而且能够是软件的整体质量更加的好。
集成测试	这里的测试工作集中在验证不同的组件之间的集成上。	这种类型的测试通常是被测试系统的更加复杂测试的基础，大量的边缘测试被合并以制造出不同的错误处理测试。
系统测试	这种测试是通过执行用户场景模拟真实用户使用系统，以证明系统具有被期望的功能。	这里不需要进行自动化的测试。安装测试、安全性测试通常是有手工完成的，因为系统的环境是恒定不变的。
其它两种非常重要的测试
回归测试	回归测试实际上是重复已经存在的测试，通常如果是手工完成的化，这种测试只在项目的结尾执行执行一到两次。	这里完全有潜力应用自动化的测试，能够在每次构建完成后执行自动化的回归测试，以验证被测试系统的改变是否影响了系统的其他功能。
性能测试	性能测试包括以下不同测试形式： - 负载测试 - 压力测试 - 并发测试 -.....	使用自动化的测试工具，通过模拟用户的负载实现的高密集度的性能测试。

 

上周参加公司的自动化测试研讨会，今年的主题是ROI（投资回报），个人感觉这是一个很严肃的话题，也是领导最关心的一个问题。不过谈测试自动化的投资回 报似乎并不是一件容易的事情。测试自动化本身是一个需要持续投入的系统工程。他并不像开发过程一样那么容易衡量产出和回报。另外，对于测试自动化的投资回 报似乎不应该在一开始提到一个很高的高度。否则对自动化的开展非常不利。

另外，测试自动化并不是简单的把手工的测试转化成自动化的代码或 者脚本这么简单的过程，而是要贯穿在产品的生命周期中，进行不断地执行，只有不断地执行，才能得到收益，根据经验，回归测试的自动化测试用例在不考虑被测 对象改变带来自动化测试脚本维护的前提下，反复执行4-7轮才能收回成本。如果被测对象本身不是十分稳定，或者缺陷比较多，产品不成熟，这个时候介入测试 自动化是非常得不偿失的。

测试自动化在很大程度也依赖于被测对象或者被测设备的稳定性，系统的设计应该考虑到可测试性，Design for Test。测试自动化越早加入到产品的开发周期，成功的机会越大。
关 于测试自动化的效果衡量不是简单的发现了多少缺陷，其实自动化测试并不能比手工测试发现更多的缺陷，如果要发现更多的缺陷，一定要进行必要的手工测试。自 动化测试的效果或者投资回报可以通过其他一些方法进行衡量，比如节省的测试人力成本，可以通过统计手工测试的时间，自动化测试的开发时间，自动化测试的执 行之间，执行次数，刨去维护时间，进行计算得到。另外，还可以从回归测试能加快产品的发布时间上进行衡量。

最后，关于产品的自动化程度， 究竟多少比例的产品需要被自动化，这个取决于产品本身，以及这个产品本身可以被自动化的程度有关系，还要考虑自动化所需要花费的代价。一般来说，不是所有 的测试用例都需要自动化，也不是所有的测试用例都能够自动化。据个简单的例子，有一个测试用例，需要重新启动机房里面一台服务器，常规来说，是不能也不需 要自动化。但是有没有可能自动化呢？肯定有，不过肯定不会为了这个自动化这个测试用例而去花费巨大的代价开发一个机器人帮你完成这个任务。当然这是一个极 端的例子。目的是告诉大家，不是所有的测试用例都需要自动化，也不是所有的用力都能自动化。衡量的依据是不同产品和代价得多少。