脚本执行期间在 IBM Rational Functional Tester 中获取并筛选日志

来源:互联网 发布:c数据分析师就业单位 编辑:程序博客网 时间:2024/06/02 02:20

 引言

各式各样的自动化工具使得测试员可以记录并测试一条记录,然后在稍后的时间内重复使用相同的脚本。判断自动化质量的一个基本的标准就是,设置一系列的确认点以让结果代码和各种错误变得可以预测。IBM® Rational® Functional Tester 支持各种各样的确认点(例如,Data,Properties 与 Image v确认点),它被插入到自动化的测试脚本中,以涵盖程序中所发生的典型问题。但是,在有些情况下,确认点并不适用,或者获取的数据在问题决定过程中并没有什么作用。在这种情况下,测试员不是向测试脚本添加确认点,而是对确认机理编码。本文向您展示了如何做到这一点。

Eclipse 是一种用于多种开发目的的 IDE(集成式开发环境)。IBM Rational Functional Tester 就构建在 Eclipse 之上。本文假设读者对 Eclipse 环境、Rational Functional Tester 对于测试中程序的配置、记录与运行测试脚本以及测试脚本的内容都已十分熟悉,所以并没有涉及到这些方面的具体内容。我们将会把 IBM Rational Application Developer(一种基于 eclipse 的程序)作为测试之中的程序使用。

IBM Rational Application Developer 中最普遍的用例是使用一个向导来创建一个新的项目。在您关闭向导之后,您就会有一个与 Rational Functional Tester 项目相类似的项目了,这取决于您所创建项目的类型,包括 java、XML 与一些属性文件。与项目相关的大多数其他用例,都涉及到了一些基于 GUI 的操作,例如拖拉一个文本框到 .jsp 文件上,这将会对新项目产生一些更改。

IBM Rational Application Developer 会在 Problems 视图中报告所有的汇编时间错误与警告。运行时所报告的所有例外情况都存储在 Error Log (工作区的日志文件)视图中。测试员会记录测试脚本,并将基于功能的确认点插入到测试之中,而且它们会为测试运行期间所报告的错误检查两种视图。

因为问题视图报告了汇编-时间错误,所以简单起见可以使用一个确认点以检测这些错误。Rational Functional Tester 将测试用例标记为错误,并在问题视图中提供报告的错误的快照。

但是,总是使用确认点来获取与测试程序相关的完整内容是不可行的。这是由于在 Error 视图中,例外情况是在执行任务时产生的。因此,您对测试程序所做的操作可能是成功的,但是它们可能并不是简洁的,因为日志文件中有例外情况及警告的存在。

在问题视图中,当错误如此之多以至于导致视图发生拖动时,限制将会上升。由于这些拖动的存在,在 Rational Functional Tester 提供的错误快照中,您就不能将它们尽收眼底了。

在 Error 视图中,由于例外情况具体追踪树不能通过该快照得到报告,所以限制将会上升。

如果您想更好地决定问题,并将忽略某项缺陷的风险性降至最低,那么就需要同时追踪这两个视图了。

本文向您解释了,怎样获得问题视图以及测试程序的错误日志,怎样筛选它们,以及定制它们以决定问题和分析缺陷。本文中对工作区的引用可以适用于生成日志文件的任何程序.

准备 Rational Functional Tester 以测试基于 Eclipse 的程序

为了打开基于 Eclipse 程序的 IBM Rational Functional Tester,您需要配置程序并使环境为测试做好准备。按照下面的方式来配置一个程序:

  1. 打开 Rational Functional Tester。
  2. 在主菜单中,点击 Configure > Configure Application for testing。然后 Application Configuration Tool 窗口就会打开了(见于图 1)。
  3. 添加关于您想要测试的程序的详细信息。
  4. 点击 Finish 以保存您所做的更改。


图 1. 配置程序对话框

准备 Rational Functional Tester 以测试基于 Eclipse 的程序

为了打开基于 Eclipse 程序的 IBM Rational Functional Tester,您需要配置程序并使环境为测试做好准备。按照下面的方式来配置一个程序:

  1. 打开 Rational Functional Tester。
  2. 在主菜单中,点击 Configure > Configure Application for testing。然后 Application Configuration Tool 窗口就会打开了(见于图 1)。
  3. 添加关于您想要测试的程序的详细信息。
  4. 点击 Finish 以保存您所做的更改。


图 1. 配置程序对话框


记录并运行测试脚本

编写测试脚本有很多种方式,这取决于测试员的技巧和测试程序的复杂程度。像其他的自动化测试工具一样,Rational Functional Tester 使得测试员可以简单地记录 GUI 操作,并将它们在测试程序中运行。测试员还可以通过使用工具识别对象,可以在不使用工具的记录功能并获取测试对象的情况下,从而手动地为一个测试用例编码。


获取并筛选其他的日志

得到其他的日志要分两步来完成:首先,获取其他的信息性日志,第二,为更快的分析筛选相关的信息。

这些日志收集方法应该置于测试用例场景的末端,与执行下一次测试用例恢复或者精简测试环境的位置前面之间。


获取其他的日志

通常来说,多个测试用例会添加至一个测试套件中,然后才会运行完整的套件。每次测试之后,测试程序都会恢复到初始的状态,这就会在测试用例运行期间清除所有创建的测试数据。

问题视图中报告的错误是特定项目的汇编-时间错误。因此,在运行完成之后,项目会被删除掉,而信息也会随之丢失。

反过来,日志文件中的信息是作为测试员操作的。日志文件的缺陷在于,在测试套件的结尾您无法去决定什么例外与什么测试用例相对应。

因此,在测试用例运行之前,您必须删除或者精简日志文件,以确保日志条目只属于最近所运行的测试用例。

在日志文件删除以后,编写文件处理方法的代码,以从该日志文件获取具体的信息,并在测试执行方法或者代码之后将方法置于测试脚本之中。为了得到最佳的结果,将测试脚本记录并维护成最原始的格式;这就是说,每个测试脚本中使用一个用例。


从问题视图中获取信息

正如本文前面所提到的那样,Rational Functional Tester 提供的确认点可以指出汇编性错误的发生情况,并且提供关于问题视图的快照。但是如果您想要更好地决定问题和分析问题,您需要匹配汇编列表,这将使其不在快照中显示出来。接下来的方法解释了怎样获取该列表。

既然方法中有通过的论断,数据将会从日志文件得到场景名。这就会把 ErrorDetails 文件中的数据与场景联系起来,因为日志文件中条目的前面就是场景名。


从问题视图中收集数据的范例代码

接下来的范例代码首先打开了问题视图,然后检查问题视图是否包含有一个条目。如果您找到了一个条目,那么代码会检查条目是否是一个错误(视图中会列出警告,以及错误和信息)。如果条目是一个错误,那么代码将会在 C:/TestResults 中创建文件 ErrorDetails.text

清单1:从问题视图中收集数据的范例代码


从 Error Log 视图(日志文件)中获取信息

除了在 Problems 视图中报告了汇报-时间错误和警告,那么在 Eclipse 工作区的日志文件中将会报告例外的情况。因此,您必须在每次场景执行之后以及测试运行期间检查该文件。在每次场景之后检查文件,可以确保您去决定什么例外属于什么场景。

接下来的范例代码首先会检查测试用例完成以后日志文件是否做了一个条目。如果日志中没有条目,那么代码就会跳过方法的其余部分,因为测试用例的执行是干脆的,并没有得到什么信息。如果日志文件中包含有什么条目,那么代码就会创建基于场景名的文本文件,浏览日志文件,并将条目写入到文本文件中。

清单 2:从日志文件中获取数据的范例代码


筛选获取的信息(日志)

前面的范例获取了其他的日志文件,但是并不确定它们之间的相关性。但是,在问题决定与问题分析期间,团队最感兴趣的是与构件相关的错误或者例外。这一章节讨论了,怎样筛选获取的日志。为了筛选日志,您可以传递一条基于您想要筛选的信息的字符串,例如您的构件或者插件名。

您要将筛选日志文件的位置,作为可以使用场景名(例如,C:/TestResults/Test Scenario_Filter.txt)的参数,和我们将会使用到以筛选日志文件的字符串传递。LogPath 与上面使用到的方法相同,所以您必须将其设置为筛选的文件。

清单 3:筛选/分类需求日志的范例代码


ErrorDetails 文件的内容

使用上面的方法,您会得到可定制的及筛选的日志,如图 3 所示。ErrorDetails 文件包含了工作区中对所有执行测试所发生的汇编性错误,包括 Rational Functional Tester 快照所丢失的条目。

图 3. 生成的日志文件的列表


图 13 列出了像 IBMbasic_WP61.text,IBMbasic_WP70 stub.text,IBMfaces_WP61.text,JSRbasic_WP70 stub.text 这样的多个文件。但是其中只有两个文件拥有与其名字相关的词 _Filter。这意味着只有两个场景匹配代码中提供的 Filter 字符串,以及对问题决定感兴趣。

图 4 显示了一个典型 ErrorDetails.text 文件的内容。从这个文件中,您可以决定与特定测试用例相关的汇编性错误。在图 4 中尼将会看到“创建目标为 WebSphere 端口 6.1 版本 jsrbasicPortlet 时出现的错误”。它是一个在方法 errorDetails() 中作为一个字符串传递的标题,该字符串可以得到定制,并将特定用例中使用的多个参数或者下面的列表,与问题中所列出的下一个标题联系起来,同时执行测试用例。

图 4. ErrorDetails 文件的内容

结论

该方法的优势在于:

  • 日志提供了关于例外情况与汇编错误的具体信息,以解决缺陷问题与改进的情况。
  • 一旦测试场景完成您就可以得到日志了,您不需要等待所有的场景都完成以进行日志分析。因此,问题决定过程就会非常的快。
  • 匹配筛选字符串的例外情况会复制到文件中,文件的名字与文件名中的 _Filter 相关。这使得您可以识别和检查相关的日志,稍后浏览其他的日志。
  • 您可以保存日志,并考虑用于前期测试运行特定构建之中的已存在缺陷的引用问题。

 

转载:http://www.ibm.com/developerworks/cn/rational/10/capturingandfilteringadditionallogsduringscriptsexecutioninibmrationalfunctionaltester/index.html

原创粉丝点击