进行软件系统 的回归测试,已经有越来越多的组织在使用QTP。QTP易学、上手快,其提供的帮助也非常详细,这是它的一个巨大优点。然而,众多的帮助或者范例都是基于 一个个简单的Demo性质的toy案例,都是对某一个或者几个知识点的解说,缺少系统级别的介绍和说明:针对一个现实中完整的系统,如何组织相关的测试用 列?如何设计测试数据?如何产生简洁、明了的测试结果?
QTP在组织测试逻辑时,自身提供了testcase和action两种结构,这两种结构是包含和被包含的关系:一个testcase可以包括多个action。在action里面,众多的测试点可以按照实际逻辑进行组织。相比testcase,action才是真正体现测试用例的地方:每个action都有自己对应的object repository;action可以设置为reused,进行复用;每个action都有自己DataSheet;测试用例的相互调用,也是通过action来进行的... 相比较而言,testcase的概念在QTP中比较“弱”,只是提供一些公共设置的管理,如设置使用到的函数库,错误现场恢复,测试使用的相关参数设置...
根据经验,实际使用中,action跟我们接触的更多。
一 组织测试用例
针对现实中一个完整的测试系统,测试用例到底应该如何组织呢?
1)按照QTP testcase来组织
在QTP中建立多个testcase,每个testcase对应实际系统的功能组;在每个QTP testcase中,通过action 来组织每个测试用例。比如:现在有个测试用例需要测试Edit菜单下的Find功能。在这个测试用例中,有多个部分要测试:a)Find Next的功能;b)测试CountAll功能;C)测试Help的功能。对于Find Next,对每一种情况,如各个checkbox选中或不选时,又分别进行测试
所以,在这种组织模式下,可以将关于Find Next的测试点归类为一个action,将CountAll的所有测试点归类为另外一个action...... 所以这些action,最后形成一个FindNext testcase。
又比如系统中另外一个需要测试的replace window:
同样可以在QTP中建立一个Replace的testcase,然后对每个要测试的功能组,建立action,在每个action内部,对各个相关的测试点进行测试。
这种测试架构的组织模式的优点是:可以组织层次较多的测试用列,结构比较清晰。
缺点是:在QTP中,由于testcase是最高一个级别的组织结构,这样,众多的testcase,其上面就缺少 一层来组织所有这些testcase,有点类似Visual Studio中的solution这个层次(Solution下面包含project,project下包含各种文件和目录...)。这样,必须手工做额 外的工作来弥补这一块,如:QTP只针对每个testcase产生一个测试result report,现在多个testcase,就缺少一个集成的测试结果;又比如,要自动运行这些testcase,必须基于这些testcase再建立一个 更高层次的脚本来管理这些testcase。
2)按照action来组织
整个系统只建立一个testcase,所有的测试功能按照action分类。
可以将上列中的Find 和Replace由testcase级别降级为action,这样,导致每个action中,可能存在多组测试点,层次结构上少了一层,感觉不清晰简洁,尤其对于AUT(Application Under Testing,被测系统)层次结构比较复杂时。
但是,这种模式的优势是:刚好符合QTP自身的组织结构(一个testcase,多个action),产生的result report也是一个集成好的,无须另外集成。
3)按照VBS函数来组织
这种组织模式我没有尝试过,只是见到有人这样做过。建立一个testcase,只包含一个action,然后,所有的测试功能,全部组织成过程或者函数。
我只是担心这种情况下,庞大的过程函数库如何维护?如果能解决这个问题,似乎这也是一个可行的组织模式。
二 测试数据
测试数据是测试中非常重要的部分,由于测试脚本可能要移植到不同的测试机器上执行,也可能AUT(被测试的系统)版 本需要升级以及语言、设置等不同,需要修改相应的测试数据。所以,那种将测试数据全部硬耦合到测试脚本中的做法不行,需要合理处理好测试数据和测试脚本的 分离问题。
QTP提供了一组Excel形式的DataTable对象,可以将数据存放在这里。然而,如何管理这些不同的数据,尤其是,如果测试用例组织是按照上述1)的模式来组织的,则需要统一提供一个integrated 的界面供修改。
三 测试结果
如果测试用例的组织采用了2模式,即QTP自身的testcase+actions,则可以自动产生一个完整的测试 result。如果采用了1模式,则QTP将根据每个testcase都产生一个测试result reporter。所以,需要做一个集成所有这些result reporter的integrated reporter。
实际上,QTP自己产生的reporter不是最好的,尤其是展现测试用例文档和测试结果之间,往往跟要求差距很大。
有一个方法,可以在检查测试点时,同时写一个Excel文件,类似于log,详细记录本次测试点的编号、操作、期望值和测试结果。这样,测试完毕,可以生成一个和测试用列文档一样的测试result reporter。