测试自动化的计划和实施
测试自动化的计划和实施系列文章，近开始酝酿思路，初步打算分为四个部分来组织，这也是我亲身经历的一个自动化项目的四个阶段，大家可以对号入座，看看你所在的公司或者组织处于自动化实施的哪个阶段？
第一个阶段：从无序到有序
这个阶段主要是自动化测试的引入，从一开始的无序的自动化测试，摸着石头过河，到慢慢找到一些窍门，其中的关键点/转折点是自动化测试系统或者说自动化测试平台的出现。这个时间大概持续了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无法显示在测试过程中查找出来的缺陷个数
至此，这个系列的原创文章全部结束。
