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

benwu · 发表于 2008-7-9 21:21:33

最近阅读微软关于自动化存在明显差异的两派讨论，对微软内部的争论不便置评。我所从事的领域与微软的有一些差异，主要是侧重电信领域的软交换及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架构的特性比较：

	传统自动化体系	ROBOT通用架构
CASE生成	全部CASE需要脚本支持	无需脚本支持
数据驱动	比较困难，不同的应用需要写大量的代码	采用强大的模板解析引擎，数据驱动轻而易举
继承性	自动化脚本容易被测应用的变化而失效	应用逻辑变化只需要调整数据
可读性	不同的脚本编写人员有不同的编码风格	全部基于数据表达，清晰易懂
自然语言	不支持	支持，设计CASE的自然语言可以通过解析器识别，所见即所得
历史CASE转化	比较死板，需要逐一CASE编写脚本	采取全新的自动化思路，CASE转化交给机器
扩展性	增加新的应用需要写大量的脚本	只需对应用进行模板定义
CASE维护	难以维护，需要大量的管理成本	基于数据，维护成本很低
CASE执行	需要很多时间提前准备环境，CASE执行方式单一	可以快速执行
检查点设置	比较单一，通常与CASE写在一起，维护成本非常高	CASE产生与检查点相分离，极低的耦合度，检查点强大无比，维护成本极低
可靠性	不可靠，因为检查点比较单一	可靠，通过数据库跟踪技术，可以确保检查精确到字段级别

下面的表格是IBM RATIONAL ROBOT与ROBOT的特性比较

	IBM RATIONAL ROBOT	ROBOT
CASE生成	全部CASE需要脚本支持	无需脚本支持
后台应用	不支持	主要支持
GUI应用	主要支持	下阶段支持
开放性	较好	较好
数据驱动	支持，不太方便	采用强大的模板解析引擎，数据驱动轻而易举
可读性	不同的脚本编写人员有不同的编码风格	全部基于数据表达，清晰易懂
自然语言	不支持	支持，设计CASE的自然语言可以通过解析器识别，所见即所得
扩展性	比较困难，因为是商用产品	比较好，可根据不同的需求进行扩展
检查点设置	优于传统，但不太灵活	CASE产生与检查点相分离，极低的耦合度，检查点强大无比，维护成本极低