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

有一段时间没有上来了，前段时间去杭州参加了公司组织的持续创新比赛，UT ROBOT项目作为唯一一个软件测试项目，从初赛的300多个项目中脱颖而出进入16强，最终获得了铜牌成绩，我们的软件测试架构获得公司上下的肯定，也为团队赢得了外出旅游的奖金。
   
    在这里回答帖子中同行所提出的问题：

    1.你提到此框架已经应用于若干项目中，想问一下这些项目是完全不同的项目么？还是框架的实现本身已经包含了对这些项目中共同点的一些假设？
    UT ROBOT强调的是框架，并不是仅为某个应用设计，应用的项目有相似的，也有不尽相同的。当然，对于软件产品，不管怎样都是有相通之处的，对于框架的设计，就是要对不同的软件产品进行高度的抽象，以尽量满足大部分软件产品测试的需要。同时我们也要承认，没有任何一个工具或者框架是放之四海而皆准的，所以，这也是我所提倡的架构要为产品服务，只有根据不同公司的产品特点来进行开发才能提高测试框架的适用性，否则就很容易出现水土不服的情况。测试框架必须来源于对测试深刻理解，象我们即使从事多年软件的测试，每天都会不断的涌现出新的想法，每天看着做出来的框架还是有很多可以改进的地方，试想如果只是简单使用了商用的架构，要把新的想法融合进去是非常困难的。
   
    2.关于CASE的自动生成，是不是主要是测试数据的不同组合，也就是场景相同，测试数据不同的情况？
    Test Case的主要有几个元素：预设场景，数据集合，数据处理，收集结果，环境清理，结果检查点；这些都是UT ROBOT考虑的重要因素，当然还有一点非常非常重要的也是容易被忽视的就是Case的版本控制，这点我将在后面专门阐述。通过实现以上的要点，可以灵活的跟据具体的情况，针对不同的数据组合结合部同的测试场景来自动生成CASE。

    3. 对于GUI测试这个架构能否一样适用？
    简单的说，可以；大家都知道GUI的测试是要有专门的GUI模拟技术来支持，UT ROBOT的核心在于数据，所以通过UT ROBOT+RUBY+WATIR的结合，利用WATIR+RUBY进行封装，通过UT ROBOT进行关键字驱动，从而实现对GUI测试的支持，这个工作正在进行当中。
   
    这里我想重点说说Test Case的版本控制问题，这也是UT ROBOT最新支持的重要特性。在我们的软件产品中，Test Case的版本涉及到以下

几方面的版本变更：
    1.被测试软件本身的版本变更；
    2.不同语言版本的变更
    3.不同国家版本的变更
    4.不同业务的版本变更
    5.不同应用模式的版本变更
    6.不可预期的版本变更
    对于以往的一些测试工具或者架构，以上任何一方面的版本变更都会带来极大的Case维护代价，大家常见的是被测试软件本身的版本变更，这里就不多说；就举不同国家版本的变更来说，我们的产品应用到不同的国家地区，如台湾、巴西、菲律宾、智利等等10几个国家，每个国家的应用模式都不一样，同样的测试参数在不同国家的应用方式都不一样。如果为每个国家都去维护一套CASE的话，不难想象，这种维护量是致命的，更加致命的是还有很多是不可预期的版本变更，这样会带来极大的维护工作，对于传统的通过业务脚本去实现测试业务逻辑的方法而言，版本变更就愈加显得力不从心了，试想，一个业务逻辑的变更要导致10几个国家版本的CASE的变更和其它因素的变更，这种变更CASE的代价就很有可能抵消自动所带来的好处。UT ROBOT考虑到以上的变更因素，尤其是不可预期的版本变更，通过扩展框架数据结构，实现了非常灵活的版本变更管理，只需要维护一套CASE就可以轻松应付以上的种种变更因素，其实现的原理是通过引入变量和条件表达式的方式来处理各种变更情况，从而达到只需要维护一套CASE就可以适用于不同的语言、不同的国家、不同的业务、不同的应用模式的情况。
  
   总结一下，一套健壮的框架需要对测试知识进行高度的抽象，考虑的因素越多，框架就越容易扩展，当然，实现的难度和代价也就越大。和不同的人交流，有助于我们在设计及实现框架的时候少走一些弯路，正所谓：三人行，必有我师焉。