这种测试架构的组织模式的优点是：可以组织层次较多的测试用列，结构比较清晰。

　　缺点是：在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。