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

上一篇 / 下一篇  2011-03-02 15:26:09

    作为迈向开发生命周期一部分的软件自动化测试的第一步,测试团队可以利用 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:可重复流作为可链接内容进行复用

图 1:可重复流作为可链接内容进行复用

有效的人工测试

        IBM Rational Manual Tester 是书写和执行人工测试的工具,它支持以模块化、构件方法书写测试。传统上用于书写人工测试的工具,如 MS Word 和 Excel,不能支持甚至不能启用此构件方法。Manual Tester 支持在其多信息文本编辑器中进行模块化及复用。它还支持图像和文件附件以改善测试可读性,并允许测试团队引入已经存在的基于 Microsoft Word 和 Excel 的人工测试。

        通过支持模块化,Manual Tester 允许测试人员从为应用程序的一个小区域的测试而编写的一组步骤的可复用流程中汇集测试。测试人员可以复用这些流来汇集许多有必要用来验证应用程序的测试脚本。

        Manual Tester 不只是一个编写工具,通过辅助的数据输入和验证特性,他还改善了人工测试执行的生产率。这些特性加速了人工测试的执行并通过减少人的错误来改善结果。Manual Tester 还允许测试人员将测试结果引入或导出到用逗号隔开的与首选的第三方工具(包括电子表格、数据库其它记录和分析工具)兼容的文件中。

向测试自动化推进

        在 Manual Tester 中书写或引入人工脚本时,支持测试工作的人员可以在他们工作时将他们的人工测试脚本组织成可复用的模块。这些开始步骤为关键字驱动测试设置了基础,这安置了进行可支持的自动化的团队。

        Manual Tester 包含一个复用视图,通过它测试团队可以共享可复用流程。该列表帮助测试人员快速地识别,当第一次在 IBM Rational Functional Tester 中进行自动化时,他们应该记录哪些可复用的流。Functional Tester 用 Java 或 VB.NET 记录脚本 —— 根据测试人员的参数选择 —— 以确保结合可用到的技能。

        测试自动化工程师执行以下步骤来记录可重复流:

        启动 Functional Tester 和 Manual Tester,打开期望的人工测试脚本。

        启动被测应用程序并执行提前进行自动化的模块的人工测试脚本中的所有指导。依照人工测试脚本中的步骤。

        既然应用程序处于正确的状态可以开始自动化可重复流了,运行 Functional Tester 的记录工具栏。

        记录在从 Mannual Tester 中选出的可复用模块(可重复流)中描述的步骤。测试人员可能随时暂停记录,以回顾人工测试脚本。

        停止记录并保存已自动化的脚本模块用于复用。
        现在,在人工测试时,在任何时候测试团队遇到该模块,其都可以简单地调入已自动化的脚本。团队甚至可以用 Rational 测试管理特性集来排列人工和自动化测试片段的流程。这将确保所有测试人员最大化地使用可用到的自动化。

        在将最普遍的复用模块自动化时,测试团队也将识别他们应该自动化的全部的测试。通过复用以前记录的复用模块,测试团队在记录全部测试时可以前进到自动化的下一个级别。

        自动化测试工程师将执行以下步骤由可复用流建立完整的测试脚本:

运行 Functional Tester。

利用 Functional Tester 的“start application”特性来启动在测应用程序。开始记录。

对在测应用程序执行人工步骤。

        当工程师在人工脚本中遇到复用模块时,Functional Tester 的“Call Script”功能将启用,调用前面记录的脚本(参见图 2)。这保持了自动化测试中的模块性。暂时暂停记录,确保在测软件处于可继续的正确状态。

        当测试完成时,在 Functional Tester 中停止记录。整个人工脚本现在已自动化。

        复用是必要的,因为传统的记录和回放方法要求您回到每一处执行相同工作的地方并更新可重复流。通过模块化,所需的更新被集中到一个单一的核心构件块中,克服测试脚本的衰退。该模块化方法将整体成本降低到一个测试人员可以通过将这些所需更新在软件生命周期内进行集中来支持脚本的位置。

32/3<123>

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

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

数据驱动测试

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

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

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

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

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

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

可重复流的复用

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

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

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

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

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

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

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

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

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

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

解决方案

        设想您通过在一处更新可重复流而不是在使用过的每一处的方式来书写测试。如果此种书写脚本的新方法加快书写速度,那么测试人员可以轻易地克服每个版本的开销工作。测试人员会有时间建立有创造性的测试并更好地测试软件。

        Manual Tester 可以让非程序员轻易地以将重复流作为链接内容而复用的方式书写测试脚本,如图 1 所示。测试人员可以简单地拖拽(通过复用视图)或复制粘贴链接(通过 CTRL-L)来创建模块化测试脚本。IBM Rational 即将专利化的用户界面简化了不论技术水平的模块化脚本的书写。Functional Tester 使得记录调用其它脚本的脚本变得简单。这保留了在书写和细化人工测试时所发现的模块性。

        将可重复流作为链接内容而复用是必要的,因为传统的人工测试和记录或回放自动化方法要求您重复修改每个执行可重复流的脚本。


图 2:Functional Tester Call Script. 功能 

图 2:Functional Tester “Call Script”功能

结束语

        IBM Rational Functional Test 工具包含对自动化框架的丰富支持,甚至支持那些缺少时间或专业技术来开发精细基础结构的团队。人工测试脚本作为易读的文档帮助团队成员快速地理解自动化脚本的意图并指导维持的自动化。事实上,所有技能等级的测试人员向关键字驱动的测试的好处推进,其作为使用 IBM Rational Manual Tester 而进行的更有效的人工测试的免费副产品。

 


TAG:

 

评分:0

我来说两句

日历

« 2024-03-07  
     12
3456789
10111213141516
17181920212223
24252627282930
31      

数据统计

  • 访问量: 9322
  • 日志数: 19
  • 建立时间: 2011-02-14
  • 更新时间: 2011-09-13

RSS订阅

Open Toolbar