非一般的测试

Rational Automatic Function Test实践总结

faye — Sun, 14 Sep 2008 07:47:00 GMT

一、Rational 工具能把整个体系集成于一体管理：测试计划、测试执行、缺陷管理，每个环节的关系都紧密相关:

1）Test Manager管理测试计划：测试需求，测试用例，并把测试用例关联测试需求、测试脚本。

2）Robot管理自动测试脚本，脚本就是把执行测试的所有动作，转化为基于Robot自有的语言—SQA.

而当今常被提到的自动测试框架，其实就是把ALL测试动作所操作对象写成公共函数，调用公共函数时只需求提供将要操作是哪个对象、什么动作，而不需要你去写脚本。这样不需要大量的时间去维护脚本，节省测试成本；而且这样的自动化功能测试非常容易维护，当被测试的软件界面及业务逻辑被改变时，你只需要修改界面的对象及动作顺序,这样即使是一个无技术的测试人员，维护脚本也是小菜一碟的事情。

3）ClearQuest, 管理软件缺陷。当运行脚本的测试结果出来后，你可以直接对有缺陷的软件功能提交缺陷。

这样紧密一环扣一环的关系（测试计划-->测试用例-->测试脚本-->缺陷），我们就好容易找出其家族成员来。

图1

试想想要需求被变更后，test manager会自动检测到其影响的测试用例，这是多舒服的事情，而不需要你自己手动去找“被变更需求”的相关测试影响。

不过，需求的文件格式及表达形式，Test manager还是非常有讲究的，在下面会说到如何设置。

二、其实这个工具弱势在哪呢？

1．自动化测试强调的是容易维护，举例来说：当做回归测试时，只需要动一下鼠标键让ROBOT运行脚本，然后就可以得到测试结果。但代价却是前期得花比手工测试3倍的测试时间来创建测试脚本，那要是整个软件周期在1-3个月、无计划要重用的小型项目，不建议用此工具。

2. IBM中国区售后技术支持人员还是挺高效及高质的，你要是有问题，只需要一个邮件，他们半天肯定给你解答。IBM策略是只确保ROBOT的原来功能没有缺陷，你要是提了一些好基本的新需求，他们是决不会修改的，他们现在主推RFT(Rational Functional Test), RFT是IBM收购Rational后在ROBOT的基本上优化而做出来的软件。性能及功能方面远超于ROBOT。

三、下面会对Test Manager, Robot详细说明使用技巧、不能满足我们需要的哪些基本需求、缺陷：

1. Test Manager

A．导出Test log文件后，如何用转换成html后文件？

脚本play back后生成Test log，当把这些log文件导出后，其文件为*.rtpar, 默认可以以txt来打开，但看起来都是排版好乱的一堆字符。要是用html file打开，比较整体。转换方法如下：

Ø 用edit打开*.rtpar

Ø 确认第一个行为“<?xml version="1.0" encoding="UTF-8"?>”

Ø 在第一行的后面插入新行，并加上以下内容“<?xml-stylesheet type="text/xsl" href="TestLogDetail.xsl"?>”

Ø 存盘

Ø 把*.rtpar的后缀名改为xml.

B. 测试用例如何对应测试脚本、测试需求

测试用例关联测试脚本：

图2

测试用例关联测试需求：

图3

D．不支持Microsoft应用软件的中文内容

Ø 导出suite log到CSV文件或Word文件，所有被导出的中文都会成为乱码。

Ø 从excel文件中导入的测试用例到test manager, 所有被导入的中文都会成为乱码。

Ø 从excel文件中导入的manual test script到test manager, 所有被导入的中文都会成为乱码。

E．Test Case 只能逐条导入。

Test case可以从外部文件中导入，它提供你选择外部源文件如excel, 并要求指定取源文件的哪个行列中的内容。这个是挺有用的功能。

但一次只能导入一个测试用例，这个功能严重影响工作效率。试想想，要是excel中一行就是一个测试用例，那要是有200个测试用例，那我要导入200次。

2．Inspector 工具

A．Inspector是个检测被测试软件的对象属性的好工具，当被测试软件是基于java开台开发的二层以上人嵌套的窗体时，用“SQAgetproperty (window, object property, 变量)” 函数时, 在window里不能只写一层窗体，而是嵌套了多少层就要写成多少层，要不，窗体是写不到位的。层与层之前用此符分隔“;\;”如下例子所示：

图4

这里只举一层的关系的例子，B嵌套在A中。

B被嵌套在多层中时,就在B前按顺序加上,并以;\;分隔.

B．inspector工具的性能不好。

Ø 打开时，要3-5分钟才能开启。

Ø 用其去检测软件的对象属性，就更慢，要是你选择检测的是更个WINDOW，而不是window里具体的一个控件，10分钟未测检是常事，而且中途会出错，一出错就产生一连串的关联错误，非要令PC死机不可, 提示通常理由“memory can’t be read”。解决办法只能是重启PC或注销用户。

Ø 有时侯Inspertor检测试的对象属性不正确，当出现此情况时，以ROBOT中的GUI Insert工具为准。GUI Insert还是比较稳定的。

3．ROBOT

Ø 在测试项目初期，建议请先建立应用测试工具的相关规范，让你们的测试团以同一标准更有序地进行测试。定义的内容有哪些：Script 编码规范、动作文件Excel格式及内容规范，用例、脚本、函数命名规范。

Ø 回头想想当初定义的自动化测试框架是相当值得的，因为：

减少测试人员编写测试脚本的时间，让他更多时间去考虑测试用例的设计。

创建的框架，不光只能用在当前的项目，而且可能用在所有不同开发平台的项目的测试，这是测试组的经验财富。

测试框架的结构我不再多说，大家可以参考前一篇文章：http://cmmionline.net/blogs/fayetest/archive/2008/03/30/1783.aspx

应用过程的会有一部分修改，但结构大同小异。

4．数据修复：

在administrator中有一个DataStrore Doctor功能。这个功能好有用，当你因为各方面原因而导致数据包产生问题，这个Datastrore Doctor可以帮到你忙。我曾经遇的问题是：不能在test plan中创建测试用例（创建时报错并自动退出test manager）,当运行Datastrore Doctor还是不能解决问题时，建议把项目迁移到别一个新位置后，运行Datastrore Doctor。

再不行，使用以下方案(但注意操作前一定要做好数据库备份工作):

Ø 用以下段两个脚本分别造成check.bat及populate.bat

Ø 修改以下两段脚本的内容:把以下关于目录内容,改成你本地的真实项目目录名:

Ø 运行check bat

Ø 再运行populate.bat.注意运行此bat的目的是重建数据库关系,但你已创建的项目数据还是存在的.而且在运行此BAT前,它会自动备份原始数据库到同一项目目录中.

文件Check.bat的内容：

图5

文件populate.bat的内容：

图6

5．项目迁移

方法1：在Rational administraotr创建新项目，再引用existing datastore.

方法2：把旧项目所有文件复制到新目录，然手动修改以下文件的项目目录为最新的目录。

     <project>\<project>.rsp
     <project>\TestDatastore\project.dat
     <project>\TestDatastore\datastore.dat
     <project>\TestDatastore\DefaultTestScriptDatastore\project.dat
     <project>\TestDatastore\DefaultTestScriptDatastore\datastore.dat
     <project>\TestUsersAndGroups\project.dat
     <project>\TestUsersAndGroups\datastore.dat
     <project>\TestDatastore\TMS_TestScriptSources\*.rtxml
        注意：你还要修改Robot Menu Tools->General Option->Presferences->SQABasic Path

-----全文完-----

特别声明：
如需转载此文，请给出指向本网站的连接，如下：
作者：关滨飞
摘自：http://www.cmmionline.net
如不能按此要求，请不要转载此文。

Rational Robot 自动测试框架(Robot Autotest Framework)

faye — Sat, 29 Mar 2008 17:05:00 GMT

作者：关滨飞
摘自：http://www.cmmionline.net
摘要：
1.框架的重要性.
2.什么是框架？
3.框架的特征.
4.如何实现框架.

1.首先先提出疑问: 什么是框架呢?

框架，即Famework。其实就是某种应用的半成品，就是一组组件，供你选用完成你自己的系统。简单说就是使用别人搭好的舞台，你来做表演; 一个没思想的机械人。而且，框架一般是成熟的，不断升级的。

2.测试为什么要用框架？

回归测试每个版本发布都包括新增加的功能和已有的功能，已有的功能已经在以前的版本中进行过测试，但是还需要在此版本中执行回归测试。在这种情况下，测试部门往往会考虑到，既然回归测试的测试用例都已经存在并且已经在上一个版本中执行过，那么在新版本中能否自动的执行这些测试？如果能这样的话，将极大的节省时间和资源，将有限的资源投入到新功能的测试上，缓解测试的压力。那我们就会想到用自动化功能测试代替手工测试.

当用工具进行自动化功能测试时,每个测试用例对应N个测试脚本,那算起来,脚本真是N多呀.那录制及维护这些脚本的测试人员就会叫苦连天,另一方面项目进度及成本的压力,根本没有太多余的时间给测试人员去花时间在自动化功能测试.

测试其实好多东西都能重用,假想我们把这个舞台都搭好了,你只需要集中精力完成系统的业务逻辑的测试,把这此业务逻辑转化成一批数据,那框架只需要读取数据就可以实现你的逻辑测试.例子就正如我们希望机械人给我们测试，那你只需要告诉他对象，动作，他就能实现你的工作，而不需要你去写脚本。智能吧。继续看下来吧。

3.Robot测试框架

那这个机械人是如何运作的呢。人类应该给他怎样的指令，他才能读懂并工作呢？

使用Robot的SQABasic脚本开发的Robot测试技术框架。此Robot测试技术框架以表驱动为指导思想，读入动态结构，解释并执行动态结构中的每一项，这是自动化测试的引擎。

（图1: 三者交互工作图）

下面我会以Window Calculator 作为例子解释，而测试目的是：测试Calculator所以功能的正确性。

数据驱动：Datapool及外部数据表驱动

Datapool是Robot的数据存贮文件，Robot可对它进行读写。

这里的表是指Robot 外部表，如EXCEL表，它可以嵌套（OLE）在Robot里，Robot可对它进行读写。

数据表是测试人员向Robot下达业务测试命令的媒体。传送的内容有：对象（窗体及控件）、动作、期望值。如下表所示:

（图2: 数据表图）

这个表中这里一共针对Calculator工具中三种不同的控件进行操作：Menu, PushButton, EditBox.

每一行代表是要求Robot操作的一个动作。这个表的动作逻辑就是：

1）．计算1+80=？，然后判断值是否正确

2）．Sqrt(81)=?, 然后判断值是否正确

3). 点击不同的菜单。然后判断。

那ROBOT如何脚本实现框架化？

把脚本分两部分维护即可：主程序（sub main）+子程序(sub-function/sub)

主程序要实现功能是把“指定表名”传入到子程序中。

Sub-function是实现对主程序传入的数据表名的内容进行不同动作处理。分为两层，第一层读取主程序传入数据表名，读取数据表的内容，判断数据表的控件是什么,并对号入座到不同处理过程（第二层）。第二层就是对不同的动作进行相关操作。

为什么要判断控件呢：原因是robot对不同的控件类型所做一系列动作都是不同，那可它放动不同的sub-function中处理。如Robot对一个PushButton控制进行Click 操作和DBClick对都不同的,所以分类处理.

（图3: 交互图）

以上图可以清楚地看到主程序和子程序和计算器之间的交互.

(图4: 活动图)

(图5: 活动图)

以上图可以看到主程序及子程序的内部处理动作.

以ROBOT语言说明:

以下实例将以读取datapool的数据为例。

(图6: 为主程序)

ApplicationDatapoolData这些是sub-function. 读取名为”FWCalcData”的数据表名名到sub-function中.

(图7:ApplicationDatapoolData)

这个sub-function的作用是打开数据表,读取数据内容,按不同的控件类型转到不以sub-function中. 如当控件类型是PushButton时,就调用sub-function “processPushButton”.

所有这些子程序应放到Global.shl文件作为公共调用,这样就会方便多了。

(图8)

上图8为sub-function”ProcessPushButton”. 是对PushButton这种控件的不同动作的进行处理.

另外在图2 数据表图中,还有部分是Verify Result的动作,其目的是判断实际值与数据表中期望值不一致时传到 Robot回放结果窗体显示。

Function如下:

总结

我分别使用了交互图、活动图去表达了1）人与Robot是主要是通过数据表数据驱动交互；2）主程序与子程序之间是如何嵌套实现测试框架，以及Robot程序的一系列动作有哪些。其实实现这些框架并不困难，只需要把握好以数据表数据驱动设计框架，不段补充数据表的动作，及不同异常的处理。相信以后你的机械人可越来越聪明。

-----全文完-----

特别声明：
如需转载此文，请给出指向本网站的连接，如下：
作者：关滨飞
摘自：http://www.cmmionline.net
如不能按此要求，请不要转载此文。