[转贴]测试工具自动化的最佳实践

[转贴]测试工具自动化的最佳实践

 

1.             测试的定义

作为一个主要的入口点,定义测试需要有一种方法以将脚本分类为出色的功能元素,每一个元素负责自动化技术的不同方面。研究这种方法,自动化脚本的元素需要录制回放技术,了解应用程序的细节同了解工具的对象一样多,使用loop语句执行业务逻辑,批处理过程和后台操作(Back end)的测试数据可访问性。最后我们需要这种特征来运行以在正确的时间点活动得到正确的输入。为了满足这些条件,我们需要在开始自动化测试脚本之前要做大量的计划。

1.1         测试录制器(Test Recoder)

1.1.1          对象VS动作

在自动化工具里,测试录制器有两种模式,分别是以对象和动作模式(Object based and Action Mode)。采用哪一种模式都需要一种谨慎但又简化的方法。尽管我们尽量避免使用动作操作模式,但是在终端(TE)的应用程序中还是要大量的使用。作为一种好的习惯,对象模式是一种被广泛接受并在测试自动化中强制使用的模式。为了将来的扩展,我们要尽量避免使用动作模式,坚持使用对象模式。

1.1.2          常见的测试环境选项

以下是我们需要在“General Option”菜单中设置的一些常见的设置。

1.       “Default Recording Mode”为“Object mode”;

2.       “Synch Point time”为10秒,缺省设置;

3.       如果“Test Execution”为“Batch Mode”时,确信所有的选项设置为关闭以便批量测试运行不受干扰;

4.       如果不可以识别应用程序中的文字,那么在文字识别(Text Recognition)中设置为缺省的字体群(Default Font Group)。如果文字群可以被用户定义的名字识别,那就把它放入“General Option”中。

1.1.3          测试属性

1.   在录制之前,确信每个脚本默认的属性是主测试(Main Test);

2.   主测试中不要带任何参数;

3.   (即便要)从测试的选项中载入对象库不是一个好的习惯。与其在脚本中载入对象库,不如使用适当的工具命令。 这样将真正地消除脚本中的隐藏设置,并且同每次在测试包运行时手工设置对象库的装载/卸载相比,它可以更好地在测试脚本中动态地执行;

4.       确信在“Add-ins”标签中的Add-ins是正确的。

1.2         脚本环境(Script Environment)

设置测试床(Test Bed)最好的办法是测试包必须是便携的,同时在假定的初始条件下,容易运行在任何一个环境中。要达到这个目的,自动化工具要支持许多功能以演化出一种通用的方法使我们能够在测试包开始执行脚本之前隐藏全部的built-ins 运行 。换句话说,组织测试脚本的方法保留在测试自动化开发人员的头脑里以预告问题和用少量的程序就可以避免的障碍。

1.2.1          Automation Inits ()

初始化脚本中常见的功能是:

1.       使用built-in命令来保持动态地载入测试路径。用选项排除测试路径的定义;

2.       在Inits 测试脚本中关闭所有的对象文件和数据文件;

3.       应该在Inits 测试脚本中完成数据库连接;

4.       常常卸载并装载对象库,并且只应该在Inits 测试脚本中执行;

5.       在Inits 测试脚本中定义所有的公共变量;

6.       在Inits 测试脚本中建立数据库连接。

1.2.2          测试脚本的元素

在开发测试脚本之前,需要一个正确的计划来确定测试脚本的风格。让我们看看一些有关确定测试元件的输入。

测试元件(Test Ware

测试库(Test Repository

测试包(Test Suite)

应该包括子文件夹(Sub Folders),异常处理器(Exception Handlers),全局对象文件(Global Object files),数据文件(Set Data file),驱动脚本(Driver Scripts),初始化和结束脚本(Initialization & Termination scripts)

驱动器脚本(Driver Script)

对象检查(Object Checks),二进制图像检查( Bit Map Checks),文字检查(Text Check),Web检查(Web Check),用户定义的函数,全局测试报告文件夹(Global test Report Folder)

驱动脚本(Driven Script)

GUI/二进制图像/GUI/文字检查(GUI/Bit/Text Check),外部的库文件,I/O Handlers

 

1.3         控制点(Control points)

在任何给出的自动化工具里,AUT中全部的控制都是通过对象识别技术。通过这个独特的功能,工具将应用程序认为是向测试人员询问提供的输入和测试业务逻辑灵活性的中介。通过调用这种对象识别技术,测试工具拥有一定的控制功能,它可以在不同的给定的时间点上检查应用程序。大量的条件,无数的对象处理器,许多的预定条件是确定所谓的功能检验点功能,它是以对象为基础的。每个测试人员对定义控制点有不同的看法。

1.3.1          If. … Else

1.             在我们开始 “if else”之前,构造控制点的本质如下注释

         # Home Page Validation

            If (<return-code> == “0”)

                  print (“Successfully Launched”);

            else

                              print (“Operation Unsuccessful”);

2.             为了所有的数据表操作,必须在“if else”构造中处理Open函数的返回代码。

1.3.2          检查点(Check Points)

1.             任何的检查点不需要带X & Y轴值。在一些实际的期间里,如果有带X和Y轴参数的检查点,那么这个检查点的可用性对于测试下的应用程序来说就没有任何的意义。以下是一些表示检查点的需要和不需要的标准。

 

No

Check Point

Include

Exclude

1

Text Check

Capture Text,

Position of the Text, Font & Font Size, Text area,

2

Bitmap Check

only the picture

Window or Screen that holds the picture, x-y co-ordinates,

3

Web Check

URL Check, orphan page

Avoid any text validation

 

2.             作为一个案例研究,在这里我们用WinRunner自动化工具作为创建检查点的例子。使用OBJ_CHECK_INFO或WIN_CHECK_INFO可以避免和劝导总是用多属性的GUI检查点的思想。它的好处是可以识别每一个小的对象和它的子项,属性和和先前版本的属性。这不仅可以做为回归的对照,并且它给予你在所有对象的物理状态里定义GUI检查点的灵活性。

 

 

1.4         数据访问(Data Access)

在自动化测试中,在应用程序中控制,补充和传递数据变得非常重要。在自动化工具中,用excel数据表或.csv文件存储测试数据。在多数回归的批量测试中,用合适的分配方法将测试数据分别存储在各自的数据表中。

1.4.1          Data Handlers

可以通过built-in的数据函数访问测试数据。一些常见的习惯可以用一种正确的方式帮助测试人员利用数据表.

1.             单独数据表(SINGLE DATA TABLE): 缺省每一种自动化工具把数据表作为输入文件,数据表可以使用工具向导或使用CSV文件创建。向导可以帮助我们创建一个数据表,测试对象中的对象作为其列名。利用这种概念,我们能够演化一种技术来装载任何文件或按预定的用例集操作AUT。

2.             多个数据表(Multiple Data Table) : 许多的测试脚本使用单独的缺省数据文件是一个常见的习惯。在这种情况下通常数据表的用量约束为一个文件。不建议处理多个数据表,而且这样还会导致处理表格操作的大量的冗余代码。常见的方法是数据文件对应每个脚本。这意味着为了使数据访问更加容易,并且数据操作也变得容易维护,每个测试脚本将拥有一个唯一的数据表。

在Compuware的QARun使用如下代码。

// Run a test script

    TestData (“CreditLogon.csv”)

    Call TestFunc1

 

例如在Mercury Interactive的WinRunner里,

   call_close “Test_Script1” (dTable1.xls) ;

   #

   call_close “Test_Script2” (dTable2.xls);

3.             在用简单的工具命令开始前,传递一个标准的模板数据表到真实的模板里,需要初始化数据文件。通过这个练习,可以避免在每次在数据表中运行之后删除数据。

在Mercury Interactive的WinRunner中,以下的代码段解释了数据表的初始化过程。

#/***************Data Table Initialization*****************

ddt_open(Template, DDT_MODE_READ);
ddt_open(dTable, DDT_MODE_READWRITE);
ddt_export(Template,dTable);
ddt_save(dTable);
ddt_close(dTable);
ddt_close(Template);
ddt_close_all_tables();

#/***************Data Table Initialization*****************

4.             从数据库操作中动态地载入数据是最明智而值得遵从的习惯,但是用一些谨慎的程序来处理db的操作总是能有利于测试人员避免许多冒险的操作和减少从远程的数据库服务器到本地数据表的数据访问时间。

当我们使用db命令时,一些需要在WinRunner的TSL中遵从的技巧。

在编写数值到数据表之前,设置行号。

例如使用如下TSL命令

public count;

count  = 1;

ddt_set_row (dTable, count);

现在我们通过行命令使用已设置的数值以在它里面编写数值。

ddt_set_val_by_row (dTable, count, “CTS_EMP_NAME”, value);

 

为了避免混淆,象在数据库表中看到的一样,最好使用相同的列名。并且在WinRunner数据表的列名之间的前或后都决不要插入任何列。比较好的方法是同后台数据库的数据一起载入数据表。

 

2.             测试的执行

 

2.1   在线VS批量执行

 

2.1.1          在线的测试脚本

 

1. Q. 我们怎样使用在线的脚本?

 

A.   使用对话功能 ,我们可以使用交互式测试完成.

 

在Mercury Interactive中可使用如下代码    

SSN = create_input_dialog ("Please Enter the SSN Number"); 

在Compuware’s QARun中可使用如下代码 

Dialog “Array_A” Array_A [] 

USER = Array_A[“Userid”] 

Pass = Array_A[“Password”] 

2.1.2          用户输入

 

2. Q. input_dialog_box函数应该放在驱动器文件里或在一个独立的脚本中呢?

 

A.  这个函数应该放在驱动器文件中(主驱动和每种类型的驱动器文件中)

 

2.1.3         测试结果(Test Results

  

3. Q. 即使脚本是独立的,都有必要将结果返回给驱动器文件吗?结果应该怎样返回?

  

A. 如果你的脚本是独立的,不需要返回结果给驱动器脚本。

 

2.1.4          可重运行的测试(Re-Runnable Tests

  

4.Q.设置脚本可否变得可重运行?如果可以,为什么呢?使它可重运行的最佳方法是什么?(它要附带一个随机数字的字符串或要用if语句来检查数据是否已经存在吗?)

  

A. 最好创建可重运行的脚本,但是我们也知道所有的设置类型的脚本都变的可重运行是不可能

  5.Q. 可否从一个驱动器文件中调用另一个驱动器文件?这可行吗?

  A. 不行。

 

2.2   函数&已编译的模块

 

2.2.1          装载库 Load Library

 

装载库文件和内存问题,例如,如果一个库文件包含了100歌函数并且只有一个使用了,那么就没有比较装载所有的函数到内存中。我们是制作多个小一些的库文件并且频繁地装载、卸载库文件还是只做一个大的库文件并且在主驱动器脚本执行时一直装载它在内存中呢?

 

已知的问题

 当装载100个函数到内存中时,会出现内存溢出问题。

2.2.2          数据获取

 

2.Q.在驱动器脚本中我们可以打开数据表并从中读取数据吗?为什么可以或为什么不可以?

A. 驱动器脚本的目的是设置应用程序,然后调用每一个独立的脚本。打开,读取和关闭数据文件应该放在独立的测试脚本那一级中。

2.3   用户定义的函数

 

3. Q. 创建用户定义的库文件和函数:如果一个脚本有一个函数如何访问它—什么是使脚本成为一个函数的前提条件?反过来,使那个函数成为一个脚本并被驱动器文件调用?

A. 首先在你能够在函数库外调用任何一个函数之前,你必须装载函数库。使用用户定义的函数在一定意义上更有效率,因为它们在调用函数之前已经被编译了并且装载在内存中,并且函数可以反复使用而不需要重新编译函数库。 

 

2.4   通配符

 

5.Q. 每当应用程序发生一个改动时,我都需要更改对象名并且重运行测试脚本。有什么好的建议吗?

 A.     如果应用程序中的对象只是做一个小的改动,那么最好是在对象属性中使用通配符。

 http://blog.csdn.net/imlogic/article/details/415395


posted @ 2006-07-08 15:19  卖烧烤的鱼  阅读(3159)  评论(0编辑  收藏  举报