|
IBM Rational Robot实际是一个套件, 在安装Robot后会有两个运行程序, 一个是开发脚本的Robot, 另一个是运行脚本的TestManager.
Robot是以前瀑布型开发的产物. 该工具的假设是Robot只上在软件产品的后期由专门的测试人员对软件产品进行测试, 因此测试脚本语言是Visual Basic. 此外,虽然RUP提出要进行迭代化开发, 要尽早测试. 但由于Robot开发的脚本是存储在专门的存储库中(也就是Rational Test Project), 很难进行版本管理, 而尽早测试必然要求对脚本进行版本管理, 所以尽早测试这个最佳实践很难通过Robot来落实.
总结来看, Robot做功能测试面临如下不足:
1. Robot采用专业的测试脚本语言, 从而导致需要学习专门的API以及专门的语法外, 用过程化的Visual Basic作为脚本语言, 导致脚本重用受到很大限制.
2. Robot和测试管理工具耦合太紧, 不能对脚本进行很好的版本管理, 也无法进行灵活的测试执行.
3. Robot不能和IDE集成, 这样导致开发人员不想学. 测试自动化技术不是只能由专业的测试人员才能用.
4. Robot在识别非标准控件上扩展能力不强, 导致Robot的使用范围受到限制.
基于上述不足, IBM Rational决定在全新的架构上开发Functional Tester. Functional Tester具有如下特点:
1. 采用Java或VB .NET作为测试脚本语言, 避免学习新语言的成本. 而且测试人员在学习了RFT后, 可平滑过度到承担软件开发工作.
2. 直接嵌在Eclipse以及Visual Studio .NET中, 这样开发人员也可以开发自动化测试脚本.
3. 测试脚本基于文件系统, 容易进行版本控制
4. 和测试管理工具耦合低, 可实现灵活的测试执行策略.
5. 提供对非标准控件的扩展编程接口.
因此, 进行自动化测试, Functional Tester是一个更好的选择. 可参考.
http://www.ibm.com/developerwork ... s/functionaltester/
评估版本:
http://www.ibm.com/developerwork ... GX23&S_CMP=DWNL |
|