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

  最近阅读微软关于自动化存在明显差异的两派讨论，对微软内部的争论不便置评。我所从事的领域与微软的有一些差异，主要是侧重电信领域的软交换及BOSS业务的测试，从本人多年所处理的现场问题来看，在现场发生的约80%的问题来源于软件版本升级后引入的新功能带来的对老功能的影响，有过不少沉痛的经验教训。

      我们公司曾经设置过专门的自动化测试部门，轰轰烈烈的从事自动化平台的开发，基本上发动了测试部门的所有同事从事测试CASE的脚本开发，时间力行半年，结果由于众所周知的原因，整个自动化体系以失败告终，最后，该自动化测试部门也就无疾而终了。我总结了一下，主要是下面的原因造成，这基本上也是行业内不同公司实施自动化失败的主要原因：

      1.自动化平台的思路缺乏创造性，基本上都是以脚本编写CASE，录制回放为主。

      2.传统的自动化体系存在以下成本因素，导致自动化的投入产出比较高，从而制约了自动化的有效实施

         2.1 开发成本

      2.2 调试成本

      2.3 维护成本

      2.4 培训成本

      2.5 规范化成本

    众所周知，BOSS系统以业务众多为主，以业务受理单一个接口为例，我们的测试案例库就存在不下3000个CASE，如果通过传统的编写自动化脚本来进行CASE转化的话，从我们以前实施的代价是：由于每个CASE都要涉及到脚本编写，环境清理，环境设置，结果检查，调试等几个步骤，一个人一个月能完成的CASE不过50个，一旦应用的业务发生变化，相关的CASE也就作废了，在这种情况下，大家也就清楚了自动化为何操作不下去的原因了.

    通过分析传统自动化所固有的缺陷，我重新定义了自动化架构的核心新思路：自动化架构必须实现CASE的产生，执行，结果检查三大要素的分离。我把新自动化的架构命名为ROBOT，无巧不成书，IBM也存在名字为RATIONAL ROBOT的一个架构产品，我事先是不知道的，文章后面，我把我们的ROBOT和IBM的RATIONAL ROBOT的特性进行了比较。

    通过将近六个月左右时间的开发，这个架构基本开发成功，并应用到了10多个应用的接口测试中，发现了超过200个问题，实现了以下功能：

    1.对新应用的接口支持只需要不到2周的时间

    2.以通用模板为基础，所有CASE自动产生

    3.结果检查点自动产生，可以快速产生包括100万的结果检查点

    4.可支持多协议

    通过ROBOT框架测试过的产品在多个现场实施之后，竟然在半年的时间内没有报过任何一个问题，以前1个月都跑不了100个CASE通过ROBOT框架可以在2天的时间内完成3000个CASE,50万结果检查点的检查，这点也印证了这篇文章的标题：开放性敏捷自动化测试架构

      下面的表格是传统自动化体系与ROBOT架构的特性比较：

文章来源于领测软件测试网 https://www.ltesting.net/

TAG: 架构 自动化 开放性