通过有效的手工测试向测试自动化推进

　　本文来自于 Rational Edge：作为迈向开发生命周期一部分的软件自动化测试的第一步，测试团队可以利用 IBM Rational Manual Tester 来调整并组织他们使用最频繁的测试流，然后用 IBM Rational Functional Tester 将这些实践自动化。本文阐明了必要的步骤和好处。

　　现代软件开发的快速节奏给测试团队带来了极大的难题。在线的软件更新和频繁的版本周期为测试自动化工作生成了“移动的目标”。

　　没有逾越简单记录或回放自动化测试的企业不久将了解到所记录的测试脚本将在一些被测软件的项目迭代中废弃。从历史观点上看，成熟的测试企业试图通过大力投入自动化框架或关键字驱动方法来缓解该问题。他们期望该方法可以随时间推移给投资带来回报。然而，在今天的市场中，很少的测试企业可以承受将他们大部分高级团队成员分配去建立很少能立即获得回报的框架。

　　本文概括了 IBM 推荐的解决测试自动化难题的方法，并且了解了大多数测试首先是手动完成的。IBM Rational Manual Tester 迅速地增加了人工测试的效力。当书写人工测试脚本时，它还鼓励所有技能水平的测试人员通过拖拽和复制粘贴来建立链接的内容。Manual Tester 的复用视图中的此链接的内容允许测试团队首先集中于将最频繁的重复流自动化。IBM 的方法加速了投资回报以及实现关键字驱动测试的好处，同时，它提供了更好的测试脚本文档。

　　为了使用 Manual Tester 更容易地组织测试内容，我们将查看一个最佳实践方案。一旦组织完成了，测试内容就可以准备由 IBM Rational Functional Tester 进行自动化了。此种由 Manual Tester 开始的模块化方法减少了人工和自动测试的维护成本。通过采用此种测试自动化的增量且迭代的方法，您将从人工测试工作中得到立即的投资回报，而同时将您的测试团队推向可靠的自动化实践。

　　不投入框架成本但能获得框架的益处

　　测试自动化专家经常为支持跨多个在测软件版本的自动化宣称框架的好处。然而，这些好处出自对建立框架的巨大前期投资的代价。与其重访对前期投资的不同业务情况，在没有前期的框架成本而将测试企业推向框架利益时，让我们考虑人工测试如何立即地有效实现投资回报。

　　我们可以将自动框架的本质提出一些核心思想，最重要的是：1) 数据驱动测试、2) 从测试脚本中提取用户界面细节，以及 3) 重复流的复用。支持前两个思想的工具不是新的，所以我们将简要地说明 IBM Rational 工具如何实现这些。然而，缺乏对第三种思想的可达到的解决方案已经阻止大多数非开发人员的测试人员不能完成可以忍受的测试自动化。我们将在剩下的文章中介绍重要的思想“重复流的复用。”我们将描述测试企业如何通过采用 IBM 的经过有效的人工测试推进测试自动化的方法，不花费框架成本来获得框架的好处。

　　数据驱动测试

　　人工测试经常要求测试人员向被测应用程序中输入数据并验证结果信息与期望值匹配。如果测试人员不注意地输入了错误的数据或漏看了不匹配数据，测试结果就无效了。通过为测试人员将数据输入和数据验证过程自动化，IBM Rational Manual Tester 减少了人的错误。

　　测试人员经常需要用不同的数据多次执行同样的事务处理。IBM Rational Functional Tester 的数据驱动测试向导使自动化该工作变得简单。使用类似电子表格的数据编辑器，测试人员创建或引入定制的数据集，在回放的过程中插入到脚本中。

　　Manual Tester 和 Functional Tester 在不需要构建单独的框架基础结构的情况下交付数据驱动测试。

　　从测试脚本中提取用户界面细节

　　在人工测试人员记录测试脚本时，Functional Tester 自动地创建用户界面细节的对象地图。该对象地图存储着当测试在方便的地方执行过程中所需的信息。改变现有测试界面细节不再需要测试人员修改每个测试脚本。测试人员可以在一处进行修改，因为所有自动的脚本都参照此集中的对象地图。

　　Functional Tester 由其即将注专利的 ScriptAssure™ 技术进一步推进。ScriptAssure 是一个匹配系统，在为改变的用户界面细节而定制的参数中寻找最合理的匹配。该功能使测试脚本在一次次的普通的用户界面修改中得到保护。

　　可重复流的复用

　　测试是乏味且重复的。测试团队为已知的软件项目书写并执行成百甚至上千的测试脚本文档。当开发人员改变在测软件时，测试人员就必须修改这些文档。这些文档，以及后继的自动记录，有许多共同的流程，包括：

　　建立被测的应用程序(例如，启动，登录)

　　填写表单(例如，创建客户账户)

　　导航到应用程序中的具体位置(例如，导航到订单输入屏)

　　执行公共的验证(例如，数据库正确地表现事务了吗?)

　　超过应用程序功能的期望值或界限(例如，当输入无效的信用卡号时，恰当的错误处理启动了吗?)

　　数据驱动测试脚本的一个子流程(例如，登录并为五十个不同用户账户执行相同的事务)

　　执行高阶的业务流，包括那些构成其他可重复流的内容(例如，下订单，卖股票)

　　内容副本问题

　　大部分测试人员在他们许多的测试脚本间重写或复制粘贴这些可重复的流。记录或回放误导许多测试人员使用自动化来分别地重复记录可重复流的每个实例。两种方法都会导致内容副本。

　　测试脚本中的内容副本是隐伏的，因为软件变更需要测试人员修改可重复流出现的每个脚本。从维护适当的文档到确保可重复的且一致的测试工作，该开销阻碍了测试团队。维护此复制的内容是乏味的且增加人出错误的风险。这个根本的原因使测试团队不能在多重软件版本中维持自动化。

原文转自：http://www.ltesting.net