一、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里不能只写一层窗体，而是嵌套了多少层就要写成多少层，要不，窗体是写不到位的。层与层之前用此符分隔“;\;”如下例子所示：

Result = HTMLLinkVP (CompareProperties, "Caption=CMMI on line - CMMI速成 - Microsoft Internet Explorer;\;HTMLText=版权声明", "Text",SResult)

图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：把旧项目所有文件复制到新目录，然手动修改以下文件的项目目录为最新的目录。

注意：你还要修改Robot Menu Tools->General Option->Presferences->SQABasic Path

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