本文前部分阐述了企业引入自动化测试的条件，包括组织结构对自动化测试的支持，以及定义自动化测试过程的方法；文章下半部分，重点说明如何定义自动化测试的计划管理过程，并且利用科学有效的RUP理论设计自动化测试。
一）自动化测试计划管理的必要性
计划管理是自动化测试的关键实现，在一个测试项目里，虽然紧缩或者干脆忽略掉制订计划的过程是相当具有诱惑力的事情，尤其在项目周期短、时间紧的情况下；但是，没有明确的计划，尤其对于初次实施自动化测试的软件企业，根本无法体现自动化测试的种种优势，虽然可以在初期稍稍感觉到自动化测试的甜头。因此，针对自动化测试项目，一定要制订明确良好的计划。
RUP提出计划就是投资。
- 录制/回放脚本的弊端：企业购买自动化测试工具后，通常的做法都是热血沸腾的开始将工具分派给相应部门，并立即着手创建、执行测试，虽然通过录制/回放脚本可以获取短暂的受益和喜悦，但是从长期来看，自动化测试的真正收益来自于脚本的重用，而这根本不是靠简单的录制/回放就能获得的。虽然获取计划的时间和资源比较困难，但是我们也要投资一定的时间和精力，以获取长期回报。越早投资于当前自动化测试项目的计划过程，就会从将来的项目中获取越大的收益。
- 时间、资源需要计划：如果对自动化测试不做时间、资源上的计划安排，可想而知，最终消耗和浪费的东西，不单单是个自动化工具而已。
- 对高层领导的承诺：在从涉众范围获得对自动化测试的支持后，如果没有正规明确的计划流程，就开始盲目推广工具使用，从而导致无法从中获得投入的收益，那么对企业高层领导的承诺也将付诸一炬，如此可想象企业高层将如何处理这一行为，谁又能负担的起呢！
计划要与时俱进。
- 最初的计划无法覆盖全部内容。从来没有第一次做的东西可以涉及全部内容，也从来不会有日后不经修改的。
- 初次的计划必将为今后提供参考。一般来说，初次的自动化测试计划内容包含选择那些易于维护和复用的基本功能结构，然后对其编写测试脚本。从这个意义来说，我们意识到在初始阶段对自动化测试的全部投入，必将对将来测试项目产生深远的影响。如果在第一个项目里我们严谨的实行安装、设计等工作，那么对于后来的项目，工作量将会减少很多。
二） 自动化测试的项目计划
您见过一个软件开发项目没有明确的计划能够成功的么？不能！正如一个软件开发项目一样，自动化测试也包含着种种复杂性，一个稳定的测试计划帮助您分解测试的复杂性，并减少测试的风险。
优秀的测试项目计划包括：
- 以简单术语描述测试项目
- 计划项目的日程安排
- 评估项目的风险
- 设置项目的沟通计划
- 确定项目的所需资源
我们重点讲述后四项内容。
日程管理：一款优秀的日程安排对任何测试项目都是重要的，尤其初次实施自动化测试，必须考虑构建自动化测试的时间。项目计划的日程应考虑如下方面：
- 对项目成员进行自动化测试工具和脚本开发的培训
- 创建自动化测试的基本架构，包括定义测试流程、开发标准、创建自动化测试框架等
- 计划和设计测试用例
- 开发测试脚本
- 创建并执行测试套件
- 评估输入：需求、测试用例、测试策略等
- 配置测试环境：硬件、软件、环境等
计划的编写形式可使用microsoft的project软件，这也是业界通用的计划管理工具。
风险管理：自动化测试项目计划的风险包括：
这四项是概括性描述，实际项目中的风险还要根据实际情况细化并评估，然后写出避免风险的预备方案；如人员中途离职、需求变更造成的时间变更等。
更详细的软件测试项目的风险列表，请参考如下表格：
沟通计划：由于项目成员间的经验偏差，以及交流能力的不足，经常会出现发生问题时不知该找何人负责的麻烦。因此，有必要在自动化测试计划里规定沟通计划的方面。所谓沟通计划，就是事先在计划里预计测试实施中出现的各种错综问题，然后指定每种问题出现时候的责任人，以免到时发生时，左右徘徊。
资源计划：测试项目所需资源包括两方面：
- 人力资源
人数
工作时间
- 设备资源
硬件（服务器、客户端等）
软件
预备时间
三） 项目的自动化测试策略
自动化测试的策略就是确定哪些测试实行自动化测试，以及何时采用自动化测试。
人们对自动化测试的一个误区就是将测试尽可能的实行自动化，并且越早越好；通常的理解是，自动化测试程度越高，自动化测试工具的利用率越高，我们从中获取的投资收益就越大。实际上，我们从自动化测试工具获得的收益应该体现在测试质量上，而不是数量上，选择哪些测试实行自动化，如何开发执行测试脚本，要比究竟多少测试实行自动化要重要的多。
如何选择适合实行自动化的测试呢？通常分三个步骤：
- 提取适合自动化的测试
- 评估每个自动化测试的时间消耗
- 根据测试目标确定自动化测试的优先顺序
首先，制订表格提取适合自动化测试的项目，这里的原则是挑选最能获得投资回报的测试项。表现在：
RUP推荐以下测试类型最适合实行自动化测试：
- 重复性最大－例如数据的边界值测试、回归测试等
- 冒烟测试－每个发布版本提交测试欠的基本功能确认
- 配置测试－需要在不同支持平台的测试
- 郁闷的测试－对于手工测试看似郁闷乏味的测试
- 复杂的测试－难以手工执行，或者容易出错，即便也难于自动化测试，但可做相应考虑
- 需要对测试结果做电子记录的测试
然后，评估自动化测试的时间。目前没有简单的数学模型判断自动测试和手工测试的时间消耗比例；但是根据RUP测试专家的估计，开发一个自动化测试的时间，是手工测试的3到10倍，对于复杂的测试，甚至更长。因此，一个需要100小时的测试套件，如果实行自动化测试，需要300到1000小时或更多的时间。RUP测试专家Cem
Kaner认为从创建、校验、文档化自动测试的时间消耗是手工测试同样过程的3到10倍；自动化测试专家Linda
Hayes认为是5到10倍。
任何估计都是一种猜测而已，我们必须根据企业测试人员的实际测试技能、测试软件的实际特征，以及测试工具的实际使用复杂度进行判断。但是有一点是无可厚非的，就是初次实施自动化测试的时间消耗，要比熟悉工具和测试流程后需要的时间更长。因此在评估自动化测试的时间消耗时，一定要将其考虑在内。例如，一个1600个测试用例的项目，估计前400个用例每个需要4个小时，下400个每个需要2小时，最后的800个，每个只需要1小时，故而全部时间是：1600小时＋800小时＋800小时＝3200小时。我们的基本原则是，挑选时间消耗比例大的测试优先实行自动化测试。
关于如何选择测试的自动化，可以参考Marick. Brian文章
When Should a Test be Automated? 或Pettichord.Bret的
Success with Test Automation.
最后，确定自动化测试的优先顺序。这里最重要的原则就是采用迭代的方式确定自动化测试的执行顺序。首先确定每个迭代的目标，挑选最能获得投资回报的测试，例如冒烟测试几乎总是能立即获得时间和资源上的回报；再挑选最容易开发脚本、最容易理解的测试实行自动化，之后逐渐扩展并迭代。
至此，您可以考虑在您最近实施的自动化测试项目中：
- 哪些手工测试适合成为实行自动化测试候选测试呢？
- 您将如何开始这些自动化测试呢？
四） 自动化测试的标准
为什么需要确定自动化测试项目的标准呢？
- 防止项目成员按照个人工作方式造成实施上的混乱
- 防止随机无序的执行测试过程
- 有助于跟踪测试资源的利用
- 减少脚本的全局变更产生的维护工作量
- 跟踪脚本变更记录
- 减少测试程序变更造成的测试修改
- 更方便于测试脚本的复用
- 更容易调试测试
- 更有效的注意到容易忽略的测试
- 更方便的在测试者之间交换工作
自动化测试标准包含两方面：
测试资源相关的标准，一般来说，包括如下内容：
文件命名习惯举例：
例如：AD_IN_SY_synwithadm_01
表示一个Administrator组件，Integration区域，Sychronizer子区域，测试同步器在管理模块的用例，序号是1。
AD_IN_SB_sybaserepo_02
表示一个Administrator组件，Integration区域，SyBase子区域，测试基于sybase的组件库应用，序号是2。
测试脚本编码规范举例，以Rational Robot为例：
例如：Declare sub writeFile (filename As String, data
As Variant) 表示子程序名称为writeFile，有两个参数，filename是一个字符串类型的数据，data是变量类型的数据。
测试过程相关的标准包括：
一） 自动化测试的设计目标
劣质的测试设计必将破坏自动化测试实施过程，它将导致测试结果不可靠--测试结果出现冲突或者干脆无效。劣质的测试设计也使测试难于维护和复用，如果我们没有特意的去为测试的复用性做出准备，那么自动化测试的收益必将随着时间的流逝而逐渐消失。因此，如果在自动化测试的设计里不把针对测试产品新版本的复用测试考虑在测试脚本库内，那么自动化测试的优势就不能得到最佳体现。
因此，当您设计自动化测试时，需要考虑到当前项目并计划到未来的项目。一个优秀的自动化测试设计，必须具有：
- 易于维护性－减少更新修改的工作量
- 可靠性－测试结果精确
- 复用性－测试脚本可以复用，包括在未来的其他项目里
二） 自动化测试的架构
软件工程里，架构是软件系统的组织结构，系统架构是
- 将产品分离成众多组件
- 在组件间建立通信机制
- 对系统指定数据接口
类似的，自动化测试的架构也是将软件系统的基本测试组件分解并组合的过程。它指定了测试组件的不同特征，以及组件间的关联结构，包括应用程序的测试数据、测试脚本、函数库等。
测试架构的选择主要依赖于测试需求，例如，如果你的测试需求是对被测程序的不同版本进行多次的运行自动化测试，那么选择一种复用性强并维护量小的架构是必要的。
除了测试需求外，测试环境也是影响测试架构的重要因素。换句话说，所有这些方面，包括架构，都影响测试的设计和实现。
许多不同的设计架构支持自动化测试。当然，测试架构最重要方面还是可维护性和可复用性，包括那些拿来自动化测试工具不进行设计，而直接进行录制或编码的测试方式（Cem
Kaner称其为quick and dirty architecture），都可以实现要做的测试工作。以下表格列出Cem
Kaner描述的通用自动化测试架构：
关于自动化测试架构的进一步信息，请参考Cem Kaner的
Avoiding Shelfware: A Managers' View of Automated GUI
Testing。
三） 测试用例的设计
自动化测试架构的选择影响测试用例的设计，测试用例是对特定对象开发的一系列测试输入、执行条件及期望结果的集合，例如练习程序特定执行路径，或检查与特定需求的一致性等。以下是一个查看网上订单的测试用例实例：
1、测试用例描述
查看客户订单，订单包含唯一的标识符、状态、归属人、订单组成、订单数量、总金额等。
2、执行条件
前置条件：
客户登陆系统并且不具有管理员权限，Classics Online主窗口打开，两个数量为1的不同订单显示在客户名下，一个买的是Brandenburg，另一个是小提琴
测试输入：
从订单菜单里选择"View Existing Order Status… " ，查看客户订单后，关闭查看窗口
观察点：
"View Existing Order"窗口弹出，订单的客户名显示正确，其他列的抬头显示ORDERID,
STATUS, COMPOSER, COMPOSITION, QUANTITY, TOTAL 等，滚动条可以正常滚动
控制点：
"View Existing Order"窗口里，具有关闭按钮和X按钮以关闭该窗口，还有Cancel
Selected Order按钮
期望结果：
两个订单有两个不同的标记数字，状态是"Order Initiated "，归属人是Bach，购买物是Brandenburg和小提琴，数量各为1，总金额分别是18.99和16.99
后置条件：
测试完成后，Classics Online主窗口自动激活
测试用例的书写要有相对固定的模板和表现形式，并存储在固定位置以方便执行和跟踪，测试人员也必须严格按照测试用例执行测试或开发测试脚本。
四） 数据驱动的测试方案
数据驱动是目前自动化测试应用最多的架构模式，它把测试脚本和测试数据有效分离，并具有如下优势：
- 测试数据可以快速修改，而不影响测试脚本
- 添加测试用例只需修改测试数据，而很少修改测试脚本
- 测试数据可被众多测试脚本共享
关于测试数据：
需要准备什么样的数据？
- 参考程序流程图或用例设计图。流程图可提供测试系统需要的数据信息，或者数据间的依赖关系，然后定义需要的数据，例如数据库数据、输入框数据、期望数据等。
从哪里获得需要的数据？
- 产品数据或先前版本的数据。首先确定这些数据是否合适，或者从中摘录合适的数据子集。
- 创建数据。
无论哪种获取方式，都不要将无法解决的问题遗留到开始运行测试阶段；可以通过和数据库管理员或系统设计人员交流获得数据，以最大程度减少和测试数据相关的测试中断。
五） Rational自动化测试工具简介
这里介绍IBM的两款自动化测试找错工具，一个是大家非常熟悉的Rational Robot，另一个是IBM近年推出的XDE
Tester。我们不从使用操作上介绍，只从基本功能和特征上做以对比，供大家选择时参考。详细内容还请参考IBM官方网站的介绍，或访问Sincky的主页查阅使用指南。
| 
