51Testing软件测试论坛

标题: 开放性敏捷自动化测试架构介绍 [打印本页]

作者: benwu 时间: 2008-7-9 21:38
标题: 开放性敏捷自动化测试架构介绍
本人主要是侧重电信领域的软交换及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的一个架构产品，文章后面，我把我们的UT ROBOT和IBM的RATIONAL ROBOT的特性进行了比较。

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

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

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

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

4.可支持多协议

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

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

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

本文建立在多年的测试管理及自动化的心得之上，ROBOT项目是对我成功实施自动化的一次总结,希望与行业的专家共同探讨自动化的前进方向，写得不好，请大家多多指正。如果有兴趣可以发邮件给我：benwu1976@hotmail.com

作者: fishy 时间: 2008-7-11 10:42
标题: 转自楼主在csdn上的回复
BOSS是指为电信运营商提供的营帐支撑系统，因为移动电信的业务的特点是业务非常复杂，有成千上万的价格计划套餐，计费也比较复杂，后台的支持网元有上百个，我们现在整套BOSS系统能支撑软交换，GSM，IPTV等等多业务，现在的BOSS相关网元已经超过300个，所以接口是非常多的，因为这种特点，所以接口协议和后台数据的测试就是主要方面

   UT ROBOT的主要成绩体现在我们通过ROBOT回归的部分网元，在现场实施之后几乎没有再报回归方面的遗漏问题。BUG下降了85%，因为有了这个数据说话，所以坚定了我们在这个架构上的信心



UT Robot强调的是框架，也就是可以适用在多个应用，多业务的测试中，即使不是我们公司的产品也可以应用

自动化测试需要考虑以下方面：
1.CASE执行前的环境准备：这是为了保证批量测试的时候不影响其它CASE的执行
2.CASE执行后的环境清理：这也是为了保证批量测试的时候不影响其它CASE的执行
3.结果检查点：非常重要，这是测试准确性的根本
4.参数的组合关系：只有可以自由组合CASE，才能覆盖各种场景
5.核心思想：CASE的生成，执行，结果记录，以及回归要分离

6.协议无关：具体完成协议发送的功能与框架想分离

7.业务无关

现在Robot已经应用到我们BOSS的部分网元的测试中，并且做到了与协议和业务无关，我们现在的效率是，一周之内就可以支持新的简单网元的自动化测试。

举例：对于WebService的SOAP接口测试，通过CASE的生成，执行，结果记录，以及回归要分离，可以实现数据库基本的所有字段的测试。可以在短时间内完成40个接口，超过5000个CASE的生成，生成的CASE中包括：枚举值、边界值、异常值、各种自定义组合的CASE，这个测试效果非常好，不仅发现了大量的功能问题，同时也发现了大量的版本变更过程中回归业务的问题。因为ROBOT在实现功能测试的同时也要支持自动化回归测试，当然，这是要求测试人员按照规范来写的。

因为采用的是模板定制测试数据的方式，测试人员不需要编写任何代码，只需要关注业务层面，即使webservice发生了变化，也只需要进行数据的变更就可以了，同时数据的版本管理可以很好的适应不同版本的变化情况。

为了更好的说明，我把测试环境中的数据拿出来说明一下，下面是SOAPSERVER几个CASE的返回结果，如第1个case，caseid=InsertAddress_2  从WEBSERVICE返回的值是1，可能有些人认为这个CASE就算PASS了，实际，这还远远不够，我们需要关注的是数据级别的变化，因此，我们需要另外的手段去记录所有数据库变化的情况，一个CASE，所涉及到的结果检查点就达到几十甚至上百个。



说到这里，大家应该明白了，UT ROBOT的特点是将结果检查点与CASE的回归执行时相分离的，否则在一个CASE中同时包含了上百个结果检查点的检查，得写多少脚本才能完成，维护代价得多大？



在这里，还得提到我们的数据库变化追踪技术(就是一次接口的请求带来的后台数据库的所有表所有字段的变化情况)，这个技术保障了所有结果检查点的完整性。

CASESET    CASEID CASETYPE VERSIONID TYPE PARATYPE RESULT
1 SAMSOAPSERVER InsertAddress_1.1_0_0 IMPORT 1 -1600
2 SAMSOAPSERVER InsertAddress_2.1_0_0 IMPORT 1 1
3 SAMSOAPSERVER InsertAddress_2.1_1_0 IMPORT 1 1
4 SAMSOAPSERVER InsertAddress_1 IMPORT 1 1
5 SAMSOAPSERVER InsertAddress_2 IMPORT 1 1  -1 -1555
6 SAMSOAPSERVER UpdateAddress_1.1_0_0 IMPORT 1 1

下面是对CASEID=InsertAccount_1的具体表的具体数据的结果，只有到了字段级别的检查才是有效的结果检查
CASESET CASEID CASETYPE VERSIONID TABLE_NAME FIELD_NAME VALUETYPE UNITE_KEY_VAL LAST_VALUE LAST_VALUE2
SAMSOAPSERVER InsertAccount_1  1 ACCOUNT CONTACTPERSON 2 ACCOUNTNUM=114  sdf
SAMSOAPSERVER InsertAccount_1  1 ACCOUNT CANCELDATE 3 ACCOUNTNUM=114
SAMSOAPSERVER InsertAccount_1  1 ACCOUNT BILLINGMONTH 2 ACCOUNTNUM=114
SAMSOAPSERVER InsertAccount_1  1 ACCOUNT CREATEDATE 3 ACCOUNTNUM=114  2008-05-29 00:00:00
SAMSOAPSERVER InsertAccount_1  1 ACCOUNT CREDITLIMIT 1 ACCOUNTNUM=114  30
SAMSOAPSERVER InsertAccount_1  1 ACCOUNT CREDITEXPIREDATE 2 ACCOUNTNUM=114  2008-05-29
SAMSOAPSERVER InsertAccount_1  1 ACCOUNT CREDITCARDNUMBER 2 ACCOUNTNUM=114  2323
SAMSOAPSERVER InsertAccount_1  1 ACCOUNT ACCOUNTNAME 2 ACCOUNTNUM=114  UTStar_SST_Rain
SAMSOAPSERVER InsertAccount_1  1 ACCOUNT AVERAGEUSAGE 1 ACCOUNTNUM=114  20
SAMSOAPSERVER InsertAccount_1  1 ACCOUNT ACTIVATEDATE 3 ACCOUNTNUM=114  2008-06-20 06:53:55
SAMSOAPSERVER InsertAccount_1  1 ACCOUNT BILLINGADDRESSID 1 ACCOUNTNUM=114  654
SAMSOAPSERVER InsertAccount_1  2 ACCOUNT CREDITCARDNUMBER 2 ACCOUNTNUM=109  2323
SAMSOAPSERVER InsertAccount_1  2 ACCOUNT CREDITLIMIT 1 ACCOUNTNUM=109  30
SAMSOAPSERVER InsertAccount_1  2 ACCOUNT CREDITEXPIREDATE 2 ACCOUNTNUM=109  2008-05-29
SAMSOAPSERVER InsertAccount_1  2 ACCOUNT ACCOUNTNAME 2 ACCOUNTNUM=109  UTStar_SST_Rain
SAMSOAPSERVER InsertAccount_1  2 ACCOUNT CREATEDATE 3 ACCOUNTNUM=109  2008-05-29 00:00:00
SAMSOAPSERVER InsertAccount_1  2 ACCOUNT AVERAGEUSAGE 1 ACCOUNTNUM=109  20
SAMSOAPSERVER InsertAccount_1  2 ACCOUNT BILLINGMONTH 2 ACCOUNTNUM=109
SAMSOAPSERVER InsertAccount_1  2 ACCOUNT BILLINGADDRESSID 1 ACCOUNTNUM=109  642
SAMSOAPSERVER InsertAccount_1  2 ACCOUNT ACTIVATEDATE 3 ACCOUNTNUM=109  2008-06-20 04:58:19
SAMSOAPSERVER InsertAccount_1  2 ACCOUNT CONTACTPERSON 2 ACCOUNTNUM=109  sdf
SAMSOAPSERVER InsertAccount_1  2 ACCOUNT CANCELDATE 3 ACCOUNTNUM=109

作者: lilycalla 时间: 2008-7-11 22:50
顶！
实践证明，ROBOT取得很好的测试效果，Robot对基于数据库的应用系统回归测试能很好的支持。
希望更多的人能够关注，并加以应用。

作者: qaarchitech 时间: 2008-7-12 15:31
效果很显著啊。

请问每一步的执行结果和结果检查如何做到分离?

另外，方便告知哪个公司的么？呵呵，我们也想更深入了解框架实现细节

作者: benwu 时间: 2008-7-13 00:27
谢谢fishy帮我的转贴，因为我一直不知道51testing和CSDN在测试上的讨论会更加有效。
不过这段时间倒是有不少的同行对这个架构比较感兴趣，我在这里就多谈一点，我和SAP公司及其他公司的一些从事自动化的同行业做了不少的探讨。
这段时间正在为这个架构申请公司的一个创新大奖，也就准备了一下PPT介绍，我把其中的几页摘下来供大家参考。
有同事推荐这个创新大奖完了之后，我将有可能会去申请一下专利。
下面是对该架构技术的一些重点：

[attach]43903[/attach]

[attach]43904[/attach]
[attach]43905[/attach]

我还想谈一下测试与开发的关系，因为这个架构在测试公司的新项目(Web service类的BOSS业务)中发现了大量的问题，这个新项目设计到的SOAP接口也就是20几个新接口，但是通过ROBOT架构自动产生了超过5000个CASE(其中包括了枚举值，边界值，异常数据，各类自定制的参数组合)，自动产生200000的数据库检查点，完全通过自动化回归的方式进行CASE执行和结果点检查，结果短短几个星期内发现了超过一百个问题，而且很多是严重问题。在刚支持的IPTV业务上，也只是花了几天时间就支持了其中一个应用的自动化测试，结果也发现了几个严重问题，这种成果是以前任何一种架构的自动化所无法比拟的。开发部门也对这个架构刮目相看，专门组织了几次培训来学习这个架构，因此我这段时间也在帮开发建立他们内部的单元测试体系，开发也认真的投入到了测试当中，和我们一起为提高测试质量而共同探讨测试技术，我们也向开发提出了各种要求来配合我们自动化CASE的产生，从这点来看，开发与测试的关系并不一定是对立的，当我们的创新给开发带来了软件质量水平的提高，他们反过来会更加尊敬测试团队。

作者: 青青 时间: 2008-7-14 09:54
我对这个感兴趣，但你们提到的UI robot 是公司自己开发的还是其他公司的产品？？可否留个你们的联系方式交流一下？

作者: benwu 时间: 2008-7-14 12:59
首先更正一下，不是UI ROBOT，是UT ROBOT。这是我们自由知识产权的自动化测试框架，有兴趣的同行可以通过email和我讨论：benwu1976@hotmail.com，或者关注我的博客：http://www.51testing.com/?195689
我将会和大家一起分享设计及开发敏捷的自动化框架的一些思想

作者: raymond1981 时间: 2008-7-14 13:19
UT ROBOT自动化测试框架体系无需脚本支持即可自动生成成千上万个case，执行效率高，测试效果很好，正在学习中。

作者: piterham 时间: 2008-7-15 10:11
赞一个

，使用ing! 非常棒!!!

作者: jackycool 时间: 2008-7-15 14:53
顶一个.使用这种工具可以大大缩减回归测试时的工作量,测试人员只需要合理的编写CASE,而不需要去完成重复枯燥的操作.

作者: sense 时间: 2008-7-16 10:49
从描述来看感觉很好，达到了一个理想的自动化测试状态，非常想了解细节，具体是怎么实现，希望能借鉴提高

作者: benwu 时间: 2008-7-21 22:28
这几天有点忙，我们的BOSS系统已经比较稳定，但是最近根据某个运营商提的需求对系统的框架进行了比较大的改动，安排了几个同事进行新接口的测试，从上星期开始，一切似乎比较正常，没有发现一些大的问题。但是，做测试的人一般都会有这种直觉，没有发现问题才是最大的问题！而且与开发沟通知道改动量并不少，所以有抱着比较怀疑的态度，本来想着在测试的后期再安排回归的，在这种状况下就要把回归提前了。
因为改动的主要是业务受理接口，主要是对这块的CASE进行回归，CASE大概是2000个，结果检查点有200000。于是运用了UT ROBOT框架做了一次回归测试，运行到差不多第100个CASE的时候，以前正常的一个CASE报错，于是查了一下错误的代码，将测试结果交给开发分析，发现对某个表的status字段处理上，对于status=00001与status=000001出了问题，再一细查所有的代码，发现竟然有30多处的判断处理中存在这个问题;而同时进行的手工测试没有发现这个重大问题，与开发沟通知道，这次的改动主要就包括出错的地方。ROBOT再次立功！除此以外，ROBOT也还发现了其它几个重要问题。
   回归迭代测试不可少，有效的框架是解决回归迭代测试的最有效途径!
另外，这几天也在忙于IPTV业务的Web Service的自动化支持模板改造，可能要几天之后才能完成，到时再给大家报告新动向。

   还有一个事情，就是我们公司最近招聘测试人员，要求如下：
   具备以下三项技能
   1.熟悉电信业务
   2.熟悉C/C++,JAVA,TCL或其它语言
   3.掌握测试理论，有2年以上相关工作经验
   4.熟悉7号信令，GSM业务流程
   5.熟悉IPTV业务。
工作地点在深圳，有兴趣的人可以发简历到我的邮箱，benwu1976@hotmail.com

作者: zmy5163 时间: 2008-7-22 09:34
谢谢楼主的接受..对UT Robort 很感兴趣...关注此贴..

作者: 国米一卡通 时间: 2008-7-22 17:41
标题: 问一个实在的问题
不知道此工具对于返回多条数据的检查点如何循环检查的？

作者: velata 时间: 2008-7-30 22:05
弱弱的问下楼上某几位你们咋试用UT ROBOT的类？
楼主提供滴？
楼主打发我一个吧

作者: x1j2l3 时间: 2008-8-1 16:20
这么好的东西不能沉了让更多人分享

作者: 东北小熊猫 时间: 2008-8-1 23:17
标题: 楼主挺专业，细节哪
好像了解一下楼主的UT ROBOT的细节啊，想你学习

作者: benwu 时间: 2008-8-2 00:18
多谢大家的捧场！刚过去的一周事情比较多，除了培训，日程项目安排管理，为下周的客户来公司参观准备DEMO环境之外，也刚刚参加完公司的一个比赛。
   这个比赛的目的是提升公司各个环节的持续改进能力，最终达到提高质量，降低成本，缩短周期的目标。ROBOT作为参赛项目之一，一共有18只队伍参加，参赛队伍覆盖了从生产线、质量部、客服部、技术支持部、研发部等各个环节的部门；大部分的队伍都是与生产线有关，因为生产线是最好量化及体现成本节约成果的。我们的队伍是两只与软件测试相关的队伍之一。比赛在杭州与深圳通过视频会议两地同步进行，总体感觉演讲的效果还不错，赢得了不少的掌声。有幸的ROBOT项目进入了8强，下周要参加在杭州的总决赛。
   言归正传，我们还是来讨论自动化技术方案。上周末参加了IBM举办的技术加油站，主要是以介绍工具为主，感觉IBM的测试工具就是进行界面的自动化录制等等，与行业的LR,QTP没有太本质的区别，对于接口测试，举了SOA应用的例子，感觉也就是简单的手工接口测试，要想实现大规模的接口回归测试还有很大的差距，如果要想支持不同特点的应用的测试就更加不可能。
   我一直提倡用有效性来衡量一项创新的用途，包括自动化测试也一样，如果自动化测试单纯停留在宣传上说又多么多么的重要，多么多么的节省人力，另外一方面却发现不了问题，没有数据的支撑的话，是经不起时间考验的，更不能说服别人心甘情愿的学习和推行自动化。另外一方面，如果自动化很有效果，但要花很多时间去写自动化脚本的话，其维护量是惊人的，这条路走起来代价非常大，测试人员根本享受不到自动化带来的便捷，因为我们以前是走过弯路的，所以感受特别深；试想，当你开发了一万个CASE，但是一旦系统修改了设计，要去修改一半的CASE，即使你再有耐心，也会被这种修改脚本的无意义劳动所打倒。
   如果想当然的认为一个软件版本到一定程度就能稳定，那是理想的状况，一般情况下除非小软件或者软件被废弃了才会有这种情况，实际情况下，对于有一定规模的软件公司，其软件版本的代码超过千万行是很普遍的，而且系统会随着不同客户的需求不断的增加修改和删除，这就是软件缺陷的来源。UT ROBOT就是在这种背景下产生的，把ROBOT比喻为一条生产线的话，解析引擎是核心，抽象的模板的机器运转的传输带，数据就是原料，数据整合部分一个过滤器，分离的结果检查点则是自动质检系统，每一部分看似都是独立的部分，因为独立也就意味着低耦合，这也就是ROBOT能实现不同类型的软件自动化测试的原因。
   有很多人发邮件问我ROBOT怎么可能不需要编写脚本，其实大家有所误解，ROBOT与业务无关，但是对于数据模板的解析还是要根据不同的应用进行模块化扩充的，实际的扩充代价是比较少，因为我把模板中的标签进行了自动解析识别，增加模板中的元素只需要配置解析的规则就可以轻易支持新的模板。另外如果有新的传输协议，还是要增加底层支持的。一旦新的模板加入，测试人员就只需要根据接口文档进行业务数据接口配置，再通过ROBOT的编译引擎产生大量的自动化可执行CASE，一定业务逻辑发生了变化，只需要在数据配置文档进行数据的修改，重新编译数据文档就可以重新生成自动化CASE，维护代价是非常低的。
   我认为如果要推行自动化测试，就不要盲目的使用商业测试工具，从长远来讲，要根据各行业各公司的特点去开发符合自己需求的的自动化框架。测试无止境，需要我们在平时的工作中敢于发现问题、多从不同的角度去思考，才能真正开发出有效的自动化测试软件，技术不是自动化最重要的因素，好的想法才是王道。
   时间不早了，有空再和大家探讨。

[ 本帖最后由 benwu 于 2008-8-2 00:36 编辑 ]

作者: pires 时间: 2008-8-4 08:11
标题: 好的想法才是王道，楼主说的很好
关于自动化测试，最近几个月我也有很多想法。
有机会和楼主做详细交流。。

作者: aries1979 时间: 2008-8-25 22:17
想问一下楼主，你的自动化测试框架是不是主要应用与电信项目的接口测试？
另外，你提到此框架已经应用于若干项目中，想问一下这些项目是完全不同的项目么？还是框架的实现本身已经包含了对这些项目中共同点的一些假设
还有关于CASE的自动生成，是不是主要是测试数据的不同组合，也就是场景相同，测试数据不同的情况。
谢谢

作者: 陈能技 时间: 2008-8-26 10:47
如果项目的系统是涉及到很多界面层的自动化测试，不知道这个UT ROBOT是否能有效支持？

作者: liangges 时间: 2008-8-31 01:22
好像很神奇的样子哦，努力学习ing……楼主太强了，佩服佩服！

作者: 5am 时间: 2008-9-1 10:43

原帖由 陈能技 于 2008-8-26 10:47 发表
如果项目的系统是涉及到很多界面层的自动化测试，不知道这个UT ROBOT是否能有效支持？

同问对于GUI测试这个架构能否一样适用？

作者: benwu 时间: 2008-9-17 23:50
有一段时间没有上来了，前段时间去杭州参加了公司组织的持续创新比赛，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就可以适用于不同的语言、不同的国家、不同的业务、不同的应用模式的情况。
总结一下，一套健壮的框架需要对测试知识进行高度的抽象，考虑的因素越多，框架就越容易扩展，当然，实现的难度和代价也就越大。和不同的人交流，有助于我们在设计及实现框架的时候少走一些弯路，正所谓：三人行，必有我师焉!

作者: bugclearer 时间: 2008-10-7 11:11
楼主能否讲解一下该架构的实现原理呢？

作者: 5am 时间: 2008-11-5 20:28
顶期待楼主更新！

作者: benwu 时间: 2009-2-23 16:49
有一段时间没有更新了，在这里给大家继续汇报一下UT ROBOT的进度，希望与有兴趣的朋友继续交流

灵活支持不同类型的应用程序：
1.接口类型测试
2.面向过程应用测试
3.Web Service测试
4.Web GUI测试
5.回归测试

特点：
1.无需编写脚本
2.轻易支持新应用
3.关系型数据驱动
4.自动产生CASE脚本
5.CASE版本管理
6.灵活的结果检查点管理
7.支持多用户
8.动态日志跟踪
9.运用于多个项目测试

“五年磨一剑，鼠标一点，轻轻松松完成新功能测试及自动化测试”

截图1：增加新应用
[attach]49314[/attach]
截图2：灵活版本管理，支持主线开发及分支开发

[attach]49315[/attach]

截图3：灵活的测试任务管理
[attach]49316[/attach]

截图4：轻松的CASE执行方式

[attach]49317[/attach]
截图5：CASE脚本的动态编译及实时查看

[attach]49318[/attach]

截图6：灵活的CASE选择
[attach]49319[/attach]

截图7：动态日志跟踪

[attach]49320[/attach]
截图8：轻松的结果检查点配置

[attach]49321[/attach]

[ 本帖最后由 benwu 于 2009-2-23 18:04 编辑 ]

作者: x1j2l3 时间: 2009-2-23 17:38
截图怎么没有。。。

作者: benwu 时间: 2009-2-23 18:09
图片看不到可能是图片文件太大的原因，已经缩小图片的尺寸

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)