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

发表于:2014-12-16来源:uml.org.cn作者:benwu点击数: 标签:
这个比赛的目的是提升公司各个环节的持续改进能力,最终达到提高质量,降低成本,缩短周期的目标。ROBOT作为参赛项目之一,一共有18只队伍参加,参

  这个比赛的目的是提升公司各个环节的持续改进能力,最终达到提高质量,降低成本,缩短周期的目标。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