The roots of hard work might be bitter, but the fruits are sweet.

发布新日志

  • LoadRunner7.8测试流程

    ooclp 发布于 2007-09-04 10:56:38

    Loadrunner中参数设置详细分析,相信对大家会有用的,这个版本是基于7.8的。
    做负载或者压力测试时,很多人选择使用了Loadrunner测试工具。该工具的基本流程是先将用户的实际操作录制成脚本,然后产生数千个虚拟用户运行脚本(虚拟用户可以分布在局域网中不同的PC机上),最后生成相关的报告以及分析图。但是在录制脚本的过程中会遇到很多实际的问题,比如不同的用户有不同的使用数据,这就牵涉到参数的设置问题。本文就Loadrunner中参数的设置进行说明,希望对大家有所帮助。
        在录制程序运行的过程中,VuGen(脚本生成器)自动生成了包含录制过程中实际用到的数值的脚本。如果你企图在录制的脚本中使用不同的数值执行脚本的活动(如查询、提交等等),那么你必须用参数值取代录制的数值。这个过程称为参数化脚本。
        本文主要包括如下内容:理解参数的局限性、建立参数、定义参数的属性、理解参数的类型、为局部数据类型设置参数的属性、为数据文件设置参数的属性、从已经存在的数据库中引入数据。
        除了GUI,以下的内容适合于各种类型的用户脚本。
    一、关于参数的定义
        在你录制程序运行的过程中,脚本生成器自动生成由函数组成的用户脚本。函数中参数的值就是在录制过程中输入的实际值。
        例如,你录制了一个Web应用程序的脚本。脚本生成器生成了一个声明,该声明搜索名称为“UNIX”的图书的数据库。当你用多个虚拟用户和迭代回放脚本时,也许你不想重复使用相同的值“UNIX”。那么,你就可以用参数来取代这个常量。结果就是你可以用指定的数据源的数值来取代参数值。数据源可以是一个文件,也可以是内部产生的变量。
        用参数表示用户的脚本有两个优点:
    ① 可以使脚本的长度变短。
    ② 可以使用不同的数值来测试你的脚本。例如,如果你企图搜索不同名称的图书,你仅仅需要写提交函数一次。在回放的过程中,你可以使用不同的参数值,而不只搜索一个特定名称的值。
        参数化包含以下两项任务:
    ① 在脚本中用参数取代常量值。
    ② 设置参数的属性以及数据源。
        参数化仅可以用于一个函数中的参量。你不能用参数表示非函数参数的字符串。另外,不是所有的函数都可以参数化的。
     
    二、参数的创建
        可以指定名称和类型来创建参数。不存在对脚本中参数个数的限制。在Web程序的用户脚本中,你可以使用如下过程在基于文本的脚本视图中创建参数。或者,也可以在基于图标的树形视图中创建参数。
        在基于文本的脚本视图中创建一个参数:
    1、 将光标定位在要参数化的字符上,点击右键。打开弹出菜单。
    2、 在弹出菜单中,选择“Replace with a Parameter”。选择或者创建参数的对话框弹出。
    3、 在“Parameter name”中输入参数的名称,或者选择一个在参数列表中已经存在的参数。
    4、 在“Parameter type”下拉列表中选择参数类型。
    5、点击“OK”,关闭该对话框。脚本生成器便会用参数中的值来取代脚本中被参数化的字符,参数用一对“{}”括住。
        注意:在参数化CORBA或者General-Java 用户脚本的时候,必须参数化整个字符串,而不是其中的部分。另外注意:除了Web或者WAP,缺省的参数括号对于任何脚本都是 “{}”。你可以在“General Options”对话框中的“Parameterization”标签(Tools>General Options)中定义参数括号种类。
    6、用同样的参数替换字符的其余情况,选中参数,点击右键,弹出菜单。从弹出的菜单中,选择“Replace More Occurrences”。搜索和替换对话框弹出。“Find What”中显示了你企图替换的值。“Replace With”中显示了括号中参数的名称。选择适当的检验框来匹配整个字符或者大小写。如果要搜索规则的表达式(.,!,?等等),选中“Regular Expression”检验框,然后点击“Replace”或者“Replace All”。
        注意:小心使用“Replace All”,尤其替换数字字符串的时候。脚本生成器将会替换字符出现的所有情况。
    7、如果想用以前定义过的参数来替换常量字符串的话,选中该字符串,点击右键,然后选择“Use Existing Parameter”,子菜单“Use Existing Parameters”弹出。从子菜单“Use Existing Parameters”选择参数,或者用“Select from Parameter List”来打开参数列表对话框。
        注意:如果用以前定义过的参数来替换常量字符串的话,那么,使用“Parameter List”非常方便。同时,还可以查看和修改该参数的属性。
    8、对于已经用参数替换过的地方,如果想取回原来的值,那么,就在参数上点击右键,然后选择“Restore Original value”。
        在Web用户脚本的树形视图中创建参数:
    1、将光标定位在企图参数化的地方,点击右键,从弹出的菜单中选择“Properties”。则相关的属性对话框打开。
    2、点击在要参数化的参量的旁边的“ABC”形状的图标。“Select or Create Parameter”对话框打开。
    3、在“Parameter name”中输入参数的名称,或者从列表中选择一个已经存在的参数。
    4、在“Parameter type”中输入参数的类型。
    5、点击“OK”关闭该对话框。用户脚本生成器会用参数来替换最初的字符串常量,并用一个表格形状的图标替换“ABC”形状的图标。
    6、要恢复参数化以前的值,点击图标,然后从弹出的菜单中选择“Undo Parameter”,则以前的值便会重现。
     
    三、定义参数的属性
        创建参数完成后,就可以定义其属性了。参数的属性定义就是定义在脚本执行过程中,参数使用的数据源。在Web用户脚本中,你既可以在基于文本的脚本视图中定义参数属性,也可以在基于图标的树形视图中定义参数属性。下面的过程将教你如何在基于本文的脚本视图中定义参数属性。
        在基于文本的脚本视图中定义参数属性步骤:
    1、 在参数上点击右键,有菜单弹出。
    2、 在弹出的菜单中,选择“Parameter Properties”。参数属性对话框打开,显示和当前参数类型相关的属性。
    3、 输入参数的属性值。
    4、 点击“Close”关闭参数属性对话框。
        在Web用户脚本的树形视图中定义参数的属性:
    1、将关标定位在参数上,然后点击右键,选择“Properties”。属性对话框打开。
    2、点击要定义属性的参数旁边的表格形状按钮,点击右键,选择“Parameter Properties”。参数属性对话框打开,和参数类型相关的属性显示出来。
    3、 输入参数的属性。
    4、 点击“Close”关闭参数属性对话框。
        使用参数列表:
      使用参数列表可以在任意时刻查看所有的参数,创建新的参数、删除参数,或者修改已经存在参数的属性。
    1、 点击参数列表按钮或者用“Vuser>Parameter List”。参数列表对话框打开。
    2、要创建新的参数,点击“New”按钮。新的参数则被添加在参数树中,该参数有一个临时的名字,你可以给它重新命名,然后回车。设置参数的类型和属性,点击“OK”,关闭参数列表对话框。
        注意:不要将一个参数命名为“unique”,因为这个名称是用户脚本生成器本身的。用户脚本生成器创建新的参数,但是不会自动用该参数在脚本中替换任意选中的字符串。
    3、要删除已有的参数,那么,要先从参数树中选择该参数,点击“Delete”,然后确认你的行为即可。
    4、要修改已有参数,那么,要先从参数树中选择该参数,然后编辑参数的类型和属性。
    四、理解参数的类型
      在你定义参数属性的时候,要指定参数值的数据源。你可以指定下列数据源类型的任何一种:
    Internal Data―― 虚拟用户内部产生的数据。
    Data Files ――存在于文件中的数据。可能是已存在的文件或者是用脚本生成器新创建的。
    User-Defined Functions―― 调用外部DLL函数生成的数据
      Internal Data包括以下几种:
    1、 Date/Time
      Date/Time用当前的日期/时间替换参数。要指定一个Date/Time格式,你可以从菜单列表中选择格式,或者指定你自己的格式。这个格式应该和你脚本中录制的Date/Time格式保持一致。
    2、 Group Name
      Group Name 用虚拟用户组名称替换参数。在创建scenario的时候,你可以指定虚拟用户组的名称。当从用户脚本生成器运行脚本的时候,虚拟用户组名称总是None。
    3、 Load Generator Name
      Load Generator Name用脚本负载生成器的名称替换参数。负载生成器是虚拟用户在运行的计算机。
    4. Iteration Number
      Iteration Number用当前的迭代数目替换参数。
    5、 Random Number
      Random Number用一个随机数替换参数。通过指定最大值和最小值来设置随机数的范围。
    6、 Unique Number
      Unique Number用一个唯一的数字来替换参数。你可以指定一个起始数字和一个块的大小。
    7、 Vuser ID
      Vuser ID用分配给虚拟用户的ID替换参数,ID是由Loadrunner的控制器在scenario运行时生成的。如果你从脚本生成器运行脚本的话,虚拟用户的ID总是-1。
    五、数据文件
      数据文件包含着脚本执行过程中虚拟用户访问的数据。局部和全局文件中都可以存储数据。可以指定现有的ASCII文件、用脚本生成器创建一个新的文件或者引入一个数据库。在参数有很多已知值的时候数据文件非常有用。数据文件中的数据是以表的形式存储的。一个文件中可以包含很多参数值。每一列包含一个参数的数据。列之间用分隔符隔开,比如说,用逗号。
      对数据文件设置参数属性
      如果使用文件作为参数的数据源,必须指定以下内容:文件的名称和位置、包含数据的列、文件格式,包括列的分隔符、更新方法。
      如果参数的类型是“File”,打开参数属性(Parameter Properties)对话框,设置文件属性如下:
    1、 在“File path”中输入文件的位置,或者点击“Browse”指定一个已有文件的位置。缺省情况下,所有新的数据文件名都是“parameter_name.dat”,注意,已有的数据文件的后缀必须是.dat。
    2、点击“Edit”。记事本打开,里面第一行是参数的名称,第二行是参数的初始值。使用诸如逗号之类的分隔符将列隔开。对于每一新的表行开始一行新的数据。
      注意:在没有启动记事本的情况下如果想添加列,就在参数属性对话框中点击“Add Col”,那么“Add new column”对话框就会弹出。输入新列的名称,点击“OK”。脚本生成器就会添加该列到表中,并显示该列的初始值。
    3、 在“Select Column”部分,指明包含当前参数数据的列。你可以指定列名或者列号。列号是包含你所需要数据的列的索引。列名显示在每列的第一行(row 0)。
    4、 在“Column delimiter”中输入列分隔符,你可以指定逗号、空格符等等。
    5、 在“First data line”中,在脚本执行的时候选择第一行数据使用。列标题是第0行。若从列标题后面的第一行开始的话,那就在“First data line”中输入1。如果没有列标题,就输入0。
    6、 在“Select next row”中输入更新方法,以说明虚拟用户在脚本执行的过程中如何选择表中的数据。方法可以是:连续的、随机的、唯一的、或者与其它参数表的相同行。
      6.1、顺序(Sequential):该方法顺序地给虚拟用户分配参数值。如果正在运行的虚拟用户访问数据表的时候,它会取到下一行中可用的数据。
      6.2、随机(Random):该方法在每次迭代的时候会从数据表中取随机数
      6.3、 使用种子取随机顺序(Use Random Sequence with Seed):如果从Loadrunner的控制器来运行scenario,你可以指定一个种子数值用于随机顺序。每一个种子数值在测试执行的时候代表了一个随机数的顺序。无论你何时使用这个种子数值,在scenario中同样的数据顺序就被分配给虚拟用户。如果在测试执行的时候发现了一个问题并且企图使用同样的随机数序列来重复测试,那么,你就可以启动这个功能(可选项)。
      6.4、唯一(Unique):Unique方法分配一个唯一的有顺序的值给每个虚拟用户的参数。
      6.5 、与以前定义的参数取同一行(Same Line As <parameter>):该方法从和以前定义过的参数中的同样的一行分配数据。你必须指定包含有该数据的列。在下拉列表中会出现定义过的所有参数列表。注意:至少其中的一个参数必须是Sequential、Random或者Unique。
        如果数据表中有三列,三个参数定义在列表中:id1,name1和title1,如下:。
    ID Name Title
    132 Kim Manager
    187 Cassie Engineer
    189 Jane VP
        对于参数id1,你可以指示虚拟用户使用Random方法,而为参数name1和title1就可以指定方法“Same Line as id1”。所以,一旦ID“132”被使用,那么,姓名(Name)“Kim”和职位(Title)“Manager”同时被使用。
    7、Updta value on数据的更新方法
    7.1、Each iteration――每次反复都要取新值
    7.2、Each occurrence――只要发现该参数就重新取值
    7.3、Once――在所有的反复中都使用同一个值
    8、When out of values超出范围:(选择数据为unique时才可用到)
    8.1、Abort Vuser――中止
    8.2、Continue in a cyclic manner――继续循环取值
    8.3、Continue with last value――取最后一个值
    9、Allocate Vuser values in the Controller在控制器中分配值:(选择数据为unique时才可用到)
      9.1、 Automatically allocate block size――自动分配
      9.2、Allocate()values for each Vuser――指定一个值
    六、从已存在的数据库中导入数据
      Loadrunner允许你利用参数化从已经存在的数据库中导入数据。可以使用下列两种方式之一:
    1、 使用Microsoft Query(要求在系统上先安装MS Query)。
    2、 指定数据库连接字符串和SQL语句。
        用户脚本生成器在从数据库中导入数据的过程中提供了一个向导。在向导中,你指明如何导入数据-通过MS Query创建查询语句或者直接书写SQL语句。在导入数据以后,以.dat为后缀并作为正规的参数文件保存。要开始导入数据库中数据的过程,在参数属性对话框中点击“Data Wizard”,则,数据库查询向导弹出。
      要创建新的查询
    1、 选择“Create new query”。如果需要MS Query的帮助,选择“Show me how to use Microsoft Query”,然后点击“Finish”。
    如果你还没有安装Microsoft Query,Loadrunner会提示你这个功能不可用。在进行之前,从Microsoft Office中安装MS Query。
    2、 在Microsoft Query中遵循以下步骤,导入期望的表和列。
    3、 在完成数据的导入后,选择“Exit and return to Virtual User Generator”,然后点击“Finish”。在参数属性对话框中数据库记录以data文件的形式显示出来。
    要在MS Query中编辑并查看数据,选择“View data or edit in Microsoft Query”。若要结束,则选择“File>Exit and return to Virtual User Generator”返回到脚本生成器。
    4、 在“Select Column”部分,指定包含当前参数数据的列可以指定列号或者列名。注意:列标题默认为第0行(row 0)。
    5、 从“Select next row”列表中选择一个更新方法来告诉虚拟用户在脚本指定的过程中如何选择表中的数据。可选项是:Sequential、Random、Unique或者Same Line As。其中每一项的含义文章前面已经讲述,就不再赘述。
    6、 如果选择“Advance row each iteration”,虚拟用户在每次迭代的时候会使用新的一行的数据而不是重复同样的数据。
      要指定数据库连接或者SQL语句
    1、 选择“Specify SQL Statement”,然后点击“Next”。
    2、点击“Create”指定一个新的连接字符串。选择数据源的窗口弹出。
    3、选择已有的数据源,或者点击“New”创建一个新的数据源。向导将提示你穿过创建ODBC数据源的过程。在完成后,连接字符串就会在连接字符串框中显示出来。
    4、 在SQL框中,输入或者粘贴SQL语句。
    5、点击“Finish”继续SQL语句并导入数据。数据库记录将以data文件的形式显示在参数属性框中。
    6、 在“Select Column”部分中,指定包含当前参数数据的列。你可以指定列号或者列名。
    7、 从“Select next row”列表中选择一个更新方法来告诉虚拟用户在脚本指定的过程中如何选择表中的数据。可选项是:Sequential、Random、Unique或者Same Line As。
    8、 如果从Update out of values中,选择“each iteration”,虚拟用户在每次迭代的时候会使用新的一行的数据而不是重复同样的数据。
     
  • testlink

    TiZhao 发布于 2007-11-21 10:55:09

    相信测试行业的同学们对这个工具应该是有所耳闻的了——开源的一个测试管理工具。
    对于测试管理来讲,实际上注重的是流程性的东西。
    所以,本文主要从流程的角度来对testlink如何使用做一个简要的说明。
    ——————————————————————————————————————

    根据实际情况,基本上我们可以按照如下的流程来实施我们的测试管理方案:

    首先创建项目

    然后创建需求

    创建计划

    创建用例

    给需求指派用例(可能不止一个)

    给计划添加用例

    为用例指定执行者

    执行计划/报告bug

    查看分析结果

     

     

    1. 创建项目:

    主页左边的列表栏有 “Test Project management”的菜单,子菜单中有 “ create new test project”,通过它可以创建新的测试项目。

    同时,菜单中的其它子菜单可以实现对已存在的test project的编辑,删除,以及设置已存在的用户对于某一个测试项目的权限。

    默认设置下,只有admin组的成员拥有对test project进行操作的权力。

     

    2. 创建需求:

    主页左边的列表栏中有 “Requirements”的菜单,子菜单中有“Requirement Specification”,可以添加编辑需求规格说明书。

    同时,菜单中的另一项可以为需求指定测试用例(结果统计的时候会有一种根据需求覆盖率进行统计的方式)。

    需要说明的一点:每一个需求都必须有相应的多个Req——实际上就是我们对需求进行分析,然后把它分成一条一条的,测试用例是与这些Req相对应的。

    默认设置下,只有admin组的成员拥有对Requirements进行操作的权力。

     

    3. 制定测试计划:

    主页右侧列表,有专门的”Test Plan Management”的菜单,选择其子菜单中的”Test Plan Management”,进入的页面会出现”create”的按钮,点击即可以创建新的测试计划。

     

    4. 创建用例:

    首先需要说明一下testlink 用例树的层次:

    Test project —— test suite —— test case

    所以在创建测试用例之前,需要保证用例隶属于的 test project 和 test suite都已经存在了。

    上面已经讲过如何创建测试项目了,接下来说明一下如何创建 test suite测试集。

    当测试项目创建完毕的时候,选择横向导航条中的“specification”,出现的页面还是分左右两部分——左侧是用例树。

    树的根节点就是咱们创建的测试项目(页面右上角可以切换测试项目,类似mantis)。

    点击测试项目,右侧页面内容中会有“new test suite”的按钮,点击可以创建test suite(测试集——可以理解成测试项目的一个功能模块)。

    Test suite创建完成以后,刷新用例树(左侧页面内容,update tree),可以看到用例树中已经出现了我们刚才创建的测试集。

    点击测试集,右侧页面内容中会出现“create test case(s)”的按钮,点击可以创建新的测试用例。

    测试用例创建完毕以后,刷新用例树,则会看到用例树中test suite的下一级中出现了我们刚刚创建的test case。

    注:用例是可以指定版本的——因为随着需求的变化,或者其他某些因素,用例是要不断变化的,需要用版本号来区别这种变化。

    PS:选择不同的level,右侧页面中会出现不尽相同的各种按钮——每个按钮对应的操作与其字面意思是相对应的,例如

    a)       用例树中我们选择的是一个 test project,右侧页面中会出现如下按钮:

    New test suite —— 创建测试集

    Reorder children —— 对该测试项目的子项(test suite)进行重新排序

    Import test suite —— 导入测试集

    Export all test suites —— 导出所有的测试集

    b)       用例树中我们选择的是一个 test suite,右侧页面中会出现如下按钮:

    Edit —— 编辑测试集

    Delete —— 删除测试集

    Move/copy —— 移动或者复制测试集

    Reorder children —— 对该测试集的子项进行重新排序

    Export test suite —— 导出测试集

    New test suite —— 新建测试集

    Import test suite —— 导入测试集

    Create test case(s) —— 创建测试用例

    Import test case(s) —— 导入测试用例

    Export test case(s) —— 导出测试用例

    c)       用例树中我们选择的是一个test case,右侧页面中会出现如下按钮:

    Edit —— 编辑当前用例

    Delete —— 删除当前用例

    Move/copy —— 移动/复制当前用例

    Deactivate this version —— 将当前用例版本设置为 无效 状态

    Create a new version —— 为当前用例创建一个新版本

    Export —— 导出用例

  • 集成测试的组成以及流程

    Iolia 发布于 2007-06-18 22:45:01

    集成测试的组成以及流程

    集成测试(也叫组装测试,联合测试)是单元测试的逻辑扩展。它的最简单的形式是:两个已经测试过的单元组合成一个组件,并且测试它们之间的接口。从这一层意义上讲,组件是指多个单元的集成聚合。在现实方案中,许多单元组合成组件,而这些组件又聚合成程序的更大部分。方法是测试片段的组合,并最终扩展进程,将您的模块与其他组的模块一起测试。最后,将构成进程的所有模块一起测试。此外,如果程序由多个进程组成,应该成对测试它们,而不是同时测试所有进程。

          集成测试识别组合单元时出现的问题。通过使用要求在组合单元前测试每个单元并确保每个单元的生存能力的测试计划,可以知道在组合单元时所发现的任何错误很可能与单元之间的接口有关。这种方法将可能发生的情况数量减少到更简单的分析级别。

          集成测试是在单元测试的基础上,测试在将所有的软件单元按照概要设计规格说明的要求组装成模块、子系统或系统的过程中各部分工作是否达到或实现相应技术指标及要求的活动。也就是说,在集成测试之前,单元测试应该已经完成,集成测试中所使用的对象应该是已经经过单元测试的软件单元。这一点很重要,因为如果不经过单元测试,那么集成测试的效果将会受到很大影响,并且会大幅增加软件单元代码纠错的代价。

          集成测试是单元测试的逻辑扩展。在现实方案中,集成是指多个单元的聚合,许多单元组合成模块,而这些模块又聚合成程序的更大部分,如分系统或系统。集成测试采用的方法是测试软件单元的组合能否正常工作,以及与其他组的模块能否集成起来工作。最后,还要测试构成系统的所有模块组合能否正常工作。集成测试所持的主要标准是《软件概要设计规格说明》,任何不符合该说明的程序模块行为都应该加以记载并上报。

          所有的软件项目都不能摆脱系统集成这个阶段。不管采用什么开发模式,具体的开发工作总得从一个一个的软件单元做起,软件单元只有经过集成才能形成一个有机的整体。具体的集成过程可能是显性的也可能是隐性的。只要有集成,总是会出现一些常见问题,工程实践中,几乎不存在软件单元组装过程中不出任何问题的情况。从图1可以看出,集成测试需要花费的时间远远超过单元测试,直接从单元测试过渡到系统测试是极不妥当的做法。

          集成测试的必要性还在于一些模块虽然能够单独地工作,但并不能保证连接起来也能正常工作。程序在某些局部反映不出来的问题,有可能在全局上会暴露出来,影响功能的实现。此外,在某些开发模式中,如迭代式开发,设计和实现是迭代进行的。在这种情况下,集成测试的意义还在于它能间接地验证概要设计是否具有可行性。

          集成测试的目的是确保各单元组合在一起后能够按既定意图协作运行,并确保增量的行为正确。它所测试的内容包括单元间的接口以及集成后的功能。使用黑盒测试方法测试集成的功能。并且对以前的集成进行回归测试。

    一、集成测试过程

    二、单元测试工作内容及其流程

    三、集成测试需求获取

          集成测试需求所确定的是对某一集成工作版本的测试的内容,即测试的具体对象。集成测试需求主要来源于设计模型(DESign Model)和集成构件计划(Integration Build Plan)。集成测试着重于集成版本的外部接口的行为。因此,测试需求须具有可观测、可测评性。

          1 集成工作版本应分析其类协作与消息序列,从而找出该工作版本的外部接口。

          2 由集成工作版本的外部接口确定集成测试用例。

    3 测试用例应覆盖工作版本每一外部接口的所有消息流序列。

         注意:一个外部接口和测试用例的关系是多对多,部分集成工作版本的测试需求可映射到系统测试需求,因此对这些集成测试用例可采用重用系统测试用例技术。

    四、集成测试工作机制

          软件集成测试工作由产品评测部担任。需要项目组相关角色配合完成。如图示:

          软件评测部:

          软件项目组:

          集成测试工作内容及其流程工作流程:

    五、集成测试产生的工件清单

          1 软件集成测试计划
          2
    集成测试用例
          3
    测试过程
          4
    测试脚本
          5
    测试日志
          6
    测试评估摘要

    六、集成测试常用方案选型

          集成测试的实施方案有很多种,如自底向上集成测试、自顶向下集成测试、BIg-Bang集成测试、三明治集成测试、核心集成测试、分层集成测试、基于使用的集成测试等。在此,笔者将重点讨论其中一些经实践检验和一些证实有效的集成测试方案。

          ·自底向上集成测试

          自底向上的集成(BOttom-Up Integration)方式是最常使用的方法。其他集成方法都或多或少地继承、吸收了这种集成方式的思想。自底向上集成方式从程序模块结构中最底层的模块开始组装和测试。因为模块是自底向上进行组装的,对于一个给定层次的模块,它的子模块(包括子模块的所有下属模块)事前已经完成组装并经过测试,所以不再需要编制桩模块(一种能模拟真实模块,给待测模块提供调用接口或数据的测试用软件模块)。自底向上集成测试的步骤大致如下:

          步骤一: 按照概要设计规格说明,明确有哪些被测模块。在熟悉被测模块性质的基础上对被测模块进行分层,在同一层次上的测试可以并行进行,然后排出测试活动的先后关系,制定测试进度计划。图2给出了自底向上的集成测试过程中各测试活动的拓扑关系。利用图论的相关知识,可以排出各活动之间的时间序列关系,处于同一层次的测试活动可以同时进行,而不会相互影响。

          步骤二: 在步骤一的基础上,按时间线序关系,将软件单元集成为模块,并测试在集成过程中出现的问题。这里,可能需要测试人员开发一些驱动模块来驱动集成活动中形成的被测模块。对于比较大的模块,可以先将其中的某几个软件单元集成为子模块,然后再集成为一个较大的模块。

          步骤三: 将各软件模块集成为子系统(或分系统)。检测各自子系统是否能正常工作。同样,可能需要测试人员开发少量的驱动模块来驱动被测子系统。

          步骤四: 将各子系统集成为最终用户系统,测试是否存在各分系统能否在最终用户系统中正常工作。

          方案点评: 自底向上的集成测试方案是工程实践中最常用的测试方法。相关技术也较为成熟。它的优点很明显: 管理方便、测试人员能较好地锁定软件故障所在位置。但它对于某些开发模式不适用,如使用XP开发方法,它会要求测试人员在全部软件单元实现之前完成核心软件部件的集成测试。尽管如此,自底向上的集成测试方法仍不失为一个可供参考的集成测试方案

    核心系统先行集成测试法的思想是先对核心软件部件进行集成测试,在测试通过的基础上再按各外围软件部件的重要程度逐个集成到核心系统中。每次加入一个外围软件部件都产生一个产品基线,直至最后形成稳定的软件产品。核心系统先行集成测试法对应的集成过程是一个逐渐趋于闭合的螺旋形曲线,代表产品逐步定型的过程。其步骤如下:

          步骤一: 对核心系统中的每个模块进行单独的、充分的测试,必要时使用驱动模块和桩模块;

          步骤二: 对于核心系统中的所有模块一次性集合到被测系统中,解决集成中出现的各类问题。在核心系统规模相对较大的情况下,也可以按照自底向上的步骤,集成核心系统的各组成模块。

          步骤三: 按照各外围软件部件的重要程度以及模块间的相互制约关系,拟定外围软件部件集成到核心系统中的顺序方案。方案经评审以后,即可进行外围软件部件的集成。

          步骤四: 在外围软件部件添加到核心系统以前,外围软件部件应先完成内部的模块级集成测试。

          步骤五: 按顺序不断加入外围软件部件,排除外围软件部件集成中出现的问题,形成最终的用户系统。

          方案点评: 该集成测试方法对于快速软件开发很有效果,适合较复杂系统的集成测试,能保证一些重要的功能和服务的实现。缺点是采用此法的系统一般应能明确区分核心软件部件和外围软件部件,核心软件部件应具有较高的耦合度,外围软件部件内部也应具有较高的耦合度,但各外围软件部件之间应具有较低的耦合度。

          ·高频集成测试

          高频集成测试是指同步于软件开发过程,每隔一段时间对开发团队的现有代码进行一次集成测试。如某些自动化集成测试工具能实现每日深夜对开发团队的现有代码进行一次集成测试,然后将测试结果发到各开发人员的电子邮箱中。该集成测试方法频繁地将新代码加入到一个已经稳定的基线中,以免集成故障难以发现,同时控制可能出现的基线偏差。使用高频集成测试需要具备一定的条件: 可以持续获得一个稳定的增量,并且该增量内部已被验证没有问题; 大部分有意义的功能增加可以在一个相对稳定的时间间隔(如每个工作日)内获得; 测试包和代码的开发工作必须是并行进行的,并且需要版本控制工具来保证始终维护的是测试脚本和代码的最新版本; 必须借助于使用自动化工具来完成。高频集成一个显著的特点就是集成次数频繁,显然,人工的方法是不胜任的。

          高频集成测试一般采用如下步骤来完成:

          步骤一: 选择集成测试自动化工具。如很多Java项目采用Junit+Ant方案来实现集成测试的自动化,也有一些商业集成测试工具可供选择。

          步骤二: 设置版本控制工具,以确保集成测试自动化工具所获得的版本是最新版本。如使用CVS进行版本控制。

          步骤三: 测试人员和开发人员负责编写对应程序代码的测试脚本。

          步骤四: 设置自动化集成测试工具,每隔一段时间对配置管理库的新添加的代码进行自动化的集成测试,并将测试报告汇报给开发人员和测试人员。

          步骤五: 测试人员监督代码开发人员及时关闭不合格项。

          按照步骤三至步骤五不断循环,直至形成最终软件产品。

          方案点评: 该测试方案能在开发过程中及时发现代码错误,能直观地看到开发团队的有效工程进度。在此方案中,开发维护源代码与开发维护软件测试包被赋予了同等的重要性,这对有效防止错误、及时纠正错误都很有帮助。该方案的缺点在于测试包有时候可能不能暴露深层次的编码错误和图形界面错误。

    以上我们介绍了几种常见的集成测试方案,一般来讲,在现代复杂软件项目集成测试过程中,通常采用核心系统先行集成测试和高频集成测试相结合的方式进行,自底向上的集成测试方案在采用传统瀑布式开发模式的软件项目集成过程中较为常见。读者应该结合项目的实际工程环境及各测试方案适用的范围进行合理的选型。


    附:集成测试计划书 模版

    原创作者:jerry
    转载请注明:来自SAwin系统分析之窗
    最后修改时间:2005-4-27

    1引言
    1.1
    编写目的
    本文是描述****集成测试的大纲文章,主要描述如何进行集成测试活动?如何控制集成测试活动?集成测试活动的流程以及集成测试活动的工作安排。本文主要的读者对象是项目负责人,集成部门经理,集成测试设计师。
    1.2
    背景
    项目名称:***集成测试
    项目相关对象:******************
    1.3
    定义
    **********
    ********************
    1.4
    参考资料
    *********
    2
    测试项目
    本测试主要为***系统的集成测试,目前***的版本为2.0,测试是***的最终集成测试,是建立在开发组程序员开发完毕自己的测试以及开发组测试的基础之上
    3
    被测特性
    3.1
    操作性测试
    主要测试操作是否正确,有无误差?分为两部分:
    3.1.1
    返回测试
    由主界面逐级进入最终界面,按EXIT键逐级返回,检查返回时候屏幕聚焦是否正确
    比如:
    1.
    进入“系统设置”
    2.
    进入“频道搜索”
    3.
    进入“自动频道搜索”
    4.
    EXIT键返回,检查当前聚焦是否为“频道搜索”
    5.
    EXIT键返回,检查当前聚焦是否为“系统设置”
    3.1.2
    进入测试
    由主界面逐级进入最终界面,按MENU键返回主界面,再次进入,检查是否聚焦正确
    比如:
    1.
    进入“系统设置”
    2.
    进入“频道搜索”
    3.
    进入“自动频道搜索”
    4.
    MENU键返回主界面
    5.
    当前聚焦是否为“系统设置”
    6.
    进入“系统设置”,当前聚焦是否为“频道搜索”
    3.2
    功能测试
    测试机顶盒中每个应用的功能是否正确
    3.3
    性能测试
    3.3.1
    疲劳性测试
    测试连续开机1个月不关机器,每3天去运行一次应用。看系统的稳定性
    3.3.2
    大容量数据测试
    前段***数据库表中含有大量数据,测试***功能
    4
    不被测特性
    5
    测试方法
    1.
    书写测试计划
    2.
    审核测试计划,未通过返回第一步
    3.
    书写测试用例;
    4.
    审核测试用例,未通过返回第三步
    5.
    测试人员按照测试用例逐项进行测试活动,并且将测试结果填写在测试报告上;(测试报告必须覆盖所有测试用例)
    6.
    测试过程中发现bug,将bug填写在bugzilla上发给集成部经理;(bug状态NEW
    7.
    集成部经理接到bugzilla发过来的bug
    7.1
    对于明显的并且可以立刻解决的bug,将bug发给开发人员;(bug状态ASSIGNED;
    7.2
    对于不是bug 查看(831) 评论(0) 收藏 分享 管理

我的栏目

数据统计

  • 访问量: 3808
  • 日志数: 6
  • 书签数: 4
  • 建立时间: 2007-02-08
  • 更新时间: 2008-03-17

RSS订阅

Open Toolbar