开放性敏捷自动化测试架构介绍(5)

　　这个比赛的目的是提升公司各个环节的持续改进能力，最终达到提高质量，降低成本，缩短周期的目标。ROBOT作为参赛项目之一，一共有18只队伍参加，参赛队伍覆盖了从生产线、质量部、客服部、技术支持部、研发部等各个环节的部门;大部分的队伍都是与生产线有关，因为生产线是最好量化及体现成本节约成果的。我们的队伍是两只与软件测试相关的队伍之一。比赛在杭州与深圳通过视频会议两地同步进行，总体感觉演讲的效果还不错，赢得了不少的掌声。有幸的 ROBOT项目进入了8强，下周要参加在杭州的总决赛。

　　言归正传，我们还是来讨论自动化技术方案。上周末参加了IBM举办的技术加油站，主要是以介绍工具为主，感觉IBM的测试工具就是进行界面的自动化录制等等，与行业的LR,QTP没有太本质的区别，对于接口测试，举了SOA应用的例子，感觉也就是简单的手工接口测试，要想实现大规模的接口回归测试还有很大的差距，如果要想支持不同特点的应用的测试就更加不可能。

　　我一直提倡用有效性来衡量一项创新的用途，包括自动化测试也一样，如果自动化测试单纯停留在宣传上说又多么多么的重要，多么多么的节省人力，另外一方面却发现不了问题，没有数据的支撑的话，是经不起时间考验的，更不能说服别人心甘情愿的学习和推行自动化。另外一方面，如果自动化很有效果，但要花很多时间去写自动化脚本的话，其维护量是惊人的，这条路走起来代价非常大，测试人员根本享受不到自动化带来的便捷，因为我们以前是走过弯路的，所以感受特别深;试想，当你开发了一万个CASE，但是一旦系统修改了设计，要去修改一半的CASE，即使你再有耐心，也会被这种修改脚本的无意义劳动所打倒。

　　如果想当然的认为一个软件版本到一定程度就能稳定，那是理想的状况，一般情况下除非小软件或者软件被废弃了才会有这种情况，实际情况下，对于有一定规模的软件公司，其软件版本的代码超过千万行是很普遍的，而且系统会随着不同客户的需求不断的增加修改和删除，这就是软件缺陷的来源。UT ROBOT就是在这种背景下产生的，把ROBOT比喻为一条生产线的话，解析引擎是核心，抽象的模板的机器运转的传输带，数据就是原料，数据整合部分一个过滤器，分离的结果检查点则是自动质检系统，每一部分看似都是独立的部分，因为独立也就意味着低耦合，这也就是ROBOT能实现不同类型的软件自动化测试的原因。

　　有很多人发邮件问我ROBOT怎么可能不需要编写脚本，其实大家有所误解，ROBOT与业务无关，但是对于数据模板的解析还是要根据不同的应用进行模块化扩充的，实际的扩充代价是比较少，因为我把模板中的标签进行了自动解析识别，增加模板中的元素只需要配置解析的规则就可以轻易支持新的模板。另外如果有新的传输协议，还是要增加底层支持的。一旦新的模板加入，测试人员就只需要根据接口文档进行业务数据接口配置，再通过ROBOT的编译引擎产生大量的自动化可执行CASE，一定业务逻辑发生了变化，只需要在数据配置文档进行数据的修改，重新编译数据文档就可以重新生成自动化CASE，维护代价是非常低的。

　　我认为如果要推行自动化测试，就不要盲目的使用商业测试工具，从长远来讲，要根据各行业各公司的特点去开发符合自己需求的的自动化框架。测试无止境，需要我们在平时的工作中敢于发现问题、多从不同的角度去思考，才能真正开发出有效的自动化测试软件，技术不是自动化最重要的因素，好的想法才是王道。

原文转自：http://www.uml.org.cn/Test/2008090410.asp