1. 简介
本文关注于一个实施自动化测试框架的组织的主要方面和影响。本文的意图是提供一些能够成功的实施自动化测试的指导方针。
2. 测试自动化的神话
有很多关于自动化测试的神话。其中的一些是真实的，而其他的一些是不正确的设想，这些不正确的设想会严重的威胁到实施自动化测试的成功。本文将向大家介绍几种我们面临的主要几种关于测试自动化的神话：
2.1. 我们在时间上是紧迫的 － 项目已经落后了 － 让我们使用自动化测试吧！
这种情况将不能成为现实。实际上，正确的思想应该是 － 我们时间急迫 － 我们决不应该使用自动化测试。
如果项目已经陷入到了麻烦之中，不建议实施自动化的功能测试。项目很可能因为需要大量的测试框架的准备和实施会被托跨。我饿建议将重点放在以下的事情上：
优化测试的过程。调查并建议在目前工作基础上的测试方法和过程。建议借鉴 RUP 的相关思想和过程。 引进或者使单元/组件测试正式化。这是我们能够快速获得受益的很好的方法。如果正式的组件测试被使用，我建议可以使用 Rational PurifyPlus 进行单元或者组件测试。根据我的经验尽早的使用 Rational PurifyPlus 是非常值得的。在一个引入和 Rational PurifyPlus 的项目中，通常会在组件的级别得到 百分之三十的性能提升。 仅仅在项目团队能够对 下列问题的回答是"Yes"时： 项目能够被适当的推延。 存在能够通过实施自动化测试被达到的精确的目标。 项目具备建立适当的测试框架的必要条件。那么，你可以在一个时间紧迫的项目中适当的实施测试自动化。但是根据经验这种情况是很难发生的。
总而言之，我只能说"对不起，银弹根本不存在"。
2.2. 测试自动化就是捕获和回放
在过去的日子中，自动化的测试工具只是被看作是一种捕获和回放的工具。当前这个神话仍然在很多测试人员的思想中。而事实上自动化测试已经远不止捕获和回放这么简单了。按照成熟度自动化的测试可以被划分为 5 个级别。
2.2.1. 级别 1：捕获和回放
这是使用自动化测试的最低的级别，同时这并不是自动化测试最有用的使用方式。
好处 自动化的测试脚本能够被自动的生成，而不需要有任何的编程知识。 缺点 你会拥有大量的测试脚本，同时当需求胡子和应用发生变化时相应的测试脚本也必须被重新录制。 用法 当测试的系统不会发生变化时 － 小规模的自动化。2.2.2. 级别 2：捕获、编辑和回放
在这个级别中，你使用自动化的测试工具来捕获你想要测试的功能。将测试脚本中的任何写死的测试数据，比如名字、帐号等等，从测试脚本的代码中完全删除，并将他们转换成为变量。
好处 测试脚本开始变得更加的完善和灵活，并且可以大大的减少脚本的数量和维护的工作。 缺点 需要一定的编知识。频繁的变化可能会引起"意大利面条式的代码"，并且变更和维护几乎是不可能的。 用法 当进行回归测试时，被测试的应用有很小的变化，比如仅仅是针对计算的代码变化，但是没有关于 GUI 界面的变化。你能够使用这种技术通过快速的编制一些测试脚本以检验你的想法来探索你的预定的测试设计。当我在没有任何象需求或者设计模型这样的文档的情况下第一次操作一个产品时和我需要获得一系列内部构建版本的稳定性的第一印象时，我使用过这种技术。通常如果适当的软件配置管理（SCM）与良好的内建设计相结合时，使用级别 2 的技术已经足够了。
2.2.3. 级别 3：编程和回放
这个级别是面对多个构建版本的有效使用测试自动化的第一个级别。你需要在实际的投资开始显现之前确保团队和客户对项目的安全感。如果没有对测试自动化工具的适当的培训测试人员将不具备到达这个级别的能力。在自动化测试工具中的所有测试功能都必须被很好的理解，并且要掌握测试脚本语言的知识。
好处 你确定了测试脚本的设计。适当的设计是必要的。编码的习惯必须是适当的。使用与开发中相同的编码习惯是非常好的。这将开始搭建起测试和开发之间的桥梁。在项目的早期就可以开始自动化的测试。你能够在项目的早期就开始进行测试脚本的设计。与开发人员交并调查他们认为可能会存在问题的区域。确保了开发人员关注在获得能够被测试的方案上。 缺点 要求测试人员具有很好的软件技能，包括设计、开发等。 用法 大规模的测试套件被开发、执行和维护的专业自动化测试。级别 3 使你能够使用自动化测试并构建不同的回归测试（重用已有的自动化测试用例）。根据我的经验在看到更多切实的回报之前，为了达到这个级别，有大量的工作和影响项目的活动必须被做。因此快速的建立和证明自动化测试的价值是至关重要的。找到乏味的测试（例如，边缘测试和特定的功能测试用例是首先进行自动化测试的良好候选者）。首先创建少量的能够测试一些基本功能（比如，登陆和创建用户等）的测自动化测试用例。
2.2.4. 级别 4：数据驱动的测试
对于自动化测试来说这是一个专业的测试级别。你现在要利用测试工具提供的所有的测试功能。你拥有一个强大的测试框架，这个测试框架是基于能够使你根据被测试系统的变化快速创建一个测试脚本的测试功能库的。维护的成本相对是比较低的。你在你的测试中会使用到大量真实的数据。
好处 你能够维护和使用良好的并且有效的模拟真实生活中数据的测试数据。 缺点 软件开发的技能是基础，并且需要访问相关的测试数据。 用法 大规模的测试套件被开发、执行和维护的专业自动化测试。级别 4 要求一些非常良好的测试数据。一个测试人员必须要花费一些时间来识别在哪里收集数据和收集哪些数据。使用现实生活中的数据是最基本的以从测试中得到完全的回报。使用适当的数据将为你提供通常仅仅在项目的后期才会发现的或者是有客户发现的错误的能力。现在你能够通过使用现实的数据开运行大量的测试。
2.2.5. 级别 5：使用动作词的测试自动化
这是自动化测试的最高级别。主要的思想是将测试用例从测试工具中分离出来。这个级别要求有一个具有高技能测试人员测小的团队，这些测试人员能够将测试工具的非常深层次的知识与他们具备的较深的编程能力结合起来。这个团队负责在测试工具中生成并维护测试的功能性，能够使测试工具从外部的来源，比如 excel 表或者数据库中执行测试用例。这种测试概念最初是由 CMG 开发的。与 CMG 方案相比，其他的可能的开放源码的方案有被 Carl Nagle 和SAS Institute 开发的 DDE。使用 DDE 的概念，关注点是当在Excel表中创建测试用例的时候，放置使用包括被使用的特定动作词语的一些类型的模板。执行的过程是从 Excel 表中读取测试用例，并将测试用例转换成为测试工具能够理解的形式，然后使用不同的测试功能来执行测试。
这个概念变得越来越流，因为测试与用例一起使用是非常有用的。
好处 测试用例的设计被从测试工具中分离了出来 － 关注在设计良好的测试用例上。允许快速的测试用例的执行和基于用例的更好的估计。 缺点 需要一个具有工具技能和开发技能的测试团队，以提供并维护测试工程（框架）。 用法 专业的测试自动化将技能的使用最优化的结合起来如果工具不具备使用内建的对象映射的可能性，那么这个方案对于消除与 GUI 相关的大部分维护成本是优秀的。在一些组织中已经创建了这种方案，并且他们其中的一些已经实现了高度的自动化（60%），并且他们都得到了巨大的回报。如果测试框架是适当的，我们能够使用 excel 来生成实际的测试用例。
这个级别对于那些按照正规基础使用用例的组织或者项目来说是非常优秀的。有多少测试用的估计是被需要的，并且当用例适当时需要做的工作也是非常简单的。你可以集中时间来生成第一个包含被需要的"对象映射"的测试用例（主流程）。依靠被测试应用的复杂程度，通常这会花费大约半天到一天的时间。后续的被需要的每一个测试用例大概会花费 15 到 20 分钟的时间，因为通常多数的测试用例可以复制已有的测试用例，并对其进行必要的修改，通常这种修改是有限的。动作词语框架能够通过使用用例使紧密的并行测试用例的开发变得可能。
2.3. 我们不需要培训！
我们所有的人都在某一些方面具有一定的经验，我们没有时间能够花费在使用新工具的培训上。当一个对自动化工具还不是很熟悉的组织或者项目团队开始实施自动化测试时，培训和指导是至关重要的。如果我们允许组织或者项目团队在没有关于应该如何做的任何知识的情况下实施自动化的测试，那将肯定会以失败告终。用于实施自动化测试方案的预算会被超出，测试会被延误并且更坏的情况是自动化测试将被放弃。组织和项目团队需要尽量避免一些认识上的缺陷，尤其是自动化测试的维护成本和当测试人员尝试和确认工具如何工作时产生的挫败感。你需要确保你的测试过程是适当的 － 如果测试过程是不合理的，引入自动化测试只会给软件组织或者项目团队带来更大的混乱。因此，我建议希望实施自动化测试方案的组织或者项目团队应该在实施之前建立"训练营"，并将重点放在培训测试团队能够很好的利用一个原型的项目上。
为第一个原型项目制定一个实施计划，下面包括原型项目的最小化的描述：
当先状态 我们希望实现什么 － 建立成功的因素 期待的回报（第一次自动化测试工作被期望验证什么） 找到一个"简单的"测试的痛处并尽力的通过自动化测试解决它，这可以被作为在同一时间上使测试运行在多个平台上的样例 说明被需要的资源和时间 ......一开始你就要大声的说出成功的信心 － 让人们了解你所展示的进展。这将吸引更多的关注和资源。
2.4. 我们必须 100% 的自动化
从管理的角度来说，100% 的自动化目标只是一个从理论上可能达到的，但是实际上达到 100% 的自动化的代价是十分昂贵的。
一个 40-60% 的利用自动化的程度已经是非常好的了。达到这个级别以上将增加测试相关的维护成本。由于对每一个构建版本的需求变化的复杂度，你将花费更多的时间在变更测试用例上以使他们能够正确的运行。在这种情况下，通过告知管理层 100% 的自动化目标是相当昂贵的来确立一个合理的期望值才是明智之举。对于决定自动化一个测试用例的一般规则是这个测试用例必须被运行 4 次以上。这个数字是基于用户对测试工具有良好的技能并且有一个良好的测试框架的。如果情况不是这样的化，整个数字能够是 10-20次或者更高。一个例子，在一个项目中测试人员花费和两周的时间将手工测试的 23天的任务转换成了自动化测试的用例。在完成使，项目能够在 4 个小时在多个平台上运行相同数量的测试用例。
2.5. 测试框架
测试框架对于产生成功的测试自动化的适当基础是重要的。很多考虑必须被解决以使测试自动化更加有效地被使用。重点必须在：
在这个级别上尽量最小化功能的数量，因为它将增加维护工作量。
还有很多有关测试框架的问题，但是这里所提及的是一些基本的要被解决的问题。
3. 在哪里使用自动化测试
有很多的情况下使用自动化的测试可以降低测试成本。我将尽量的突出在自动化测试中的不同的测试技术
4. 什么时候使用自动化测试
我对什么时候应该使用自动化测试和什么时候应该使用手工测试进行了一个概要的总结：
如果你正在从事自动化测试，那么一定要记住要关注将自动化测试与手工测试结合起来使用。首先，对于自动化测试率的目标是 10/90 （10% 的自动化测试和 90% 的手工测试）。当这些目标都实现了，可以将自动化测试的使用率提高。记住创建自动化测试的测试用例要比创建手工测试的测试用例花费更多的时间。不要将你所有的测试时间都用在自动化的测试用例上。同时也要记住在测试期间对每一个被发现的错误都要花费一定的时间去处理。
5. 自动化测试的好处
如果你正在你的组织中引入自动化测试，记住有很多不同的方面被包含了进了。今天在测试工作如何被进行上有很多不同的视图。为了能够成功的实施自动化测试你应该提出这些问题：
这些问题都能够被自动化测试满足。你必须从自动化测试成熟度的级别 1 或者 级别 2 开始，并开始测量结果。根据我的经验快速的向开发人员反馈并每天运行测试对于向自动化测试成熟度的级别 4或者 级别 5 是非常有好处的。
自动化测试有以下的贡献：
降低风险 － 你知道你测试了什么和没测试什么 测试能在项目的早期开始并随着时间一直扩展 快速的反馈 － 自动化测试用例能够随时的运行 在多个平台上的测试能够同时进行 更好的估计 － 你能够对测试进度和被使用的时间有更好的了解 优秀人员的集中 － 你能够得到一个专家的团队，并将他们的知识传播给其他的项目 喜悦 -你和你的团队正获得着成功参考资料 Rational 培训课程 TST170: Principles of Software Testing for Testers Rational培训课程TST275: Essentials of Test Management with Rational TestManager Rational培训课程PRJ480 Mastering the Management of Iterative Development v2003.06.00 参考书：Software Test Automation by Fewster & Graham http://safsdev.sourceforge.net/FRAMESDataDrivenTestAutomationFrameworks.htm
本文地址：http://com.8s8s.com/it/it23909.htm