下面的是IBM RATIONAL ROBOT与UT ROBOT的特性比较
ibm RATIONAL ROBOT UT ROBOT
CASE生成 全部CASE需要脚本支持 无需脚本支持
后台应用 不支持 主要支持
开放性 较好 较好
数据驱动 支持，不太方便 采用强大的模板解析引擎，数据驱动轻而易举
可读性 不同的脚本编写人员有不同的编码风格 全部基于数据表达，清晰易懂
自然语言 不支持 支持，设计CASE的自然语言可以通过解析器识别，所见即所得
扩展性 比较困难，因为是商用产品 比较好，可根据不同的需求进行扩展
检查点设置 优于传统，但不太灵活 CASE产生与检查点相分离，极低的耦合度，检查点强大无比，维护成本低
BOSS是指为电信运营商提供的营帐支撑系统，因为移动电信的业务的特点是业务非常复杂，有成千上万的价格计划套餐，计费也比较复杂，后台的支持网元有上百个，我们现在整套BOSS系统能支撑软交换，GSM，IPTV等等多业务，现在的BOSS相关网元已经超过300个，所以接口是非常多的，因为这种特点，所以接口协议和后台数据的测试就是主要方面
UT ROBOT的主要成绩体现在我们通过ROBOT回归的部分网元，在现场实施之后几乎没有再报回归方面的遗漏问题。BUG下降了85%，因为有了这个数据说话，所以坚定了我们在这个架构上的信心
UT Robot强调的是框架，也就是可以适用在多个应用，多业务的测试中，即使不是我们公司的产品也可以应用
自动化测试需要考虑以下方面：
1.CASE执行前的环境准备：这是为了保证批量测试的时候不影响其它CASE的执行
2.CASE执行后的环境清理：这也是为了保证批量测试的时候不影响其它CASE的执行
3.结果检查点：非常重要，这是测试准确性的根本
4.参数的组合关系：只有可以自由组合CASE，才能覆盖各种场景 软件测试
5.核心思想：CASE的生成，执行，结果记录，以及回归要分离
6.协议无关：具体完成协议发送的功能与框架想分离
7.业务无关
现在Robot已经应用到我们BOSS的部分网元的测试中，并且做到了与协议和业务无关，我们现在的效率是，一周之内就可以支持新的简单网元的自动化测试。
举例：对于WebService的SOAP接口测试，通过CASE的生成，执行，结果记录，以及回归要分离，可以实现数据库基本的所有字段的测试。可以在短时间内完成40个接口，超过5000个CASE的生成，生成的CASE中包括：枚举值、边界值、异常值、各种自定义组合的CASE，这个测试效果非常好，不仅发现了大量的功能问题，同时也发现了大量的版本变更过程中回归业务的问题。因为ROBOT在实现功能测试的同时也要支持自动化回归测试，当然，这是要求测试人员按照规范来写的。
因为采用的是模板定制测试数据的方式，测试人员不需要编写任何代码，只需要关注业务层面，即使webservice发生了变化，也只需要进行数据的变更就可以了，同时数据的版本管理可以很好的适应不同版本的变化情况。
为了更好的说明，我把测试环境中的数据拿出来说明一下，下面是SOAPSERVER几个CASE的返回结果，如第1个case，caseid=InsertAddress_2 从WEBSERVICE返回的值是1，可能有些人认为这个CASE就算PASS了，实际，这还远远不够，我们需要关注的是数据级别的变化，因此，我们需要另外的手段去记录所有数据库变化的情况，一个CASE，所涉及到的结果检查点就达到几十甚至上百个。
说到这里，大家应该明白了，UT ROBOT的特点是将结果检查点与CASE的回归执行时相分离的，否则在一个CASE中同时包含了上百个结果检查点的检查，得写多少脚本才能完成，维护代价得多大?
文章来源于领测软件测试网 https://www.ltesting.net/
