第八章QTP自动化测试框架概要.pptVIP

框架的存储结构 Project文件夹，整个工程的最高一级目录，名称可以修改。 Driver目录，这个是QuickTest的脚本文件，整个框架的入口。这个脚本包含了testSet和testcase的驱动脚本。 frameUtil目录，存放用来支持框架的一些函数库。 logs目录，存放脚本运行日志 testData目录，存放测试用例以及测试数据的Excel文件 testScript目录，存放task脚本，全部存储为vbs文件。 driver.vbs文件，使用了QTP的automation object model，也是整个框架的入口。可以直接执行该vbs脚本，因此可以做成Windows的自动任务，在指定时间点执行。 testData和testScript目录下的内容，是真正需要开发的。 数据的组织 Test Set TestCase Test Data Test Data Test Set 数据文件 Test Set数据文件是用来管理测试用例文件的，在这里，扮演了TD的管理测试用例和脚本的角色。很显然，这个数据文件没有TD的功能强大，不能体现测试用例对需求的覆盖，没有测试用例之间的树形结构…但是作为一个轻量级的测试框架，只要能够记录、管理50~100个测试用例文件，就暂时够用了。 IDX：index，“√”表示该行数据有效，“x”表示该行数据无效。主要是考虑到Excel直接面对人，用0，1来标识有效无效，很不直观。 name：测试用例的名字，用中文标示即可，这个字段只是让人看起来比较直观，并不会被用到。 table：这个字段非常重要，它指向测试用例所在的Excel的文件名。可以带后缀，也可以不带后缀。不需要指定文件所在的路径。 sheet：表示测试用例在Excel文件的Sheet名称。如果不填写的话，默认为第一个Sheet。 考虑到有些测试用例极其复杂，仅仅使用Excel形式的测试用例是远远不能实现其复杂的逻辑，也可以把测试用例写成vbs文件，直接执行该vbs脚本。目前暂未实现。 TestCase数据文件 TestCase数据文件中记录的就是测试用例，只要不是太过于复杂的测试流程，都可以直接写在Excel文件中，当然，需要符合一定的规范，很显然，这离自然语言还是有一定的距离 。这种形式比较适合step-by-step的测试用例，并且粒度比较粗，减少了测试用例的步骤数。 IDX：index，“√”表示该行数据有效，“x”表示该行数据无效。 bizName：被测试的业务的名称，比如说“银行收款”这个业务。事实上，这个名称需要与存储改业务的task脚本的名称保持一致，而且需要与task脚本中定义的class的名称也保持一致。在没有做名称的中英文对照字典之前，bizName最好使用英文名，所以最好使用“collection”，而不是“银行收款”。 taskName：task的名称，原子业务的名称，比如新增、修改、删除等。这个名称与task脚本中定义的各个Function的名称应该保持一致。同样，暂时也最好不要使用中文。 TestCase数据文件 bizDataTable：测试数据所在的Excel的Sheet名称。比如说进行登陆操作时，需要输入用户名和密码等数据，这些数据单独放在某个Excel文件中的某个Sheet中，把这个Sheet的名称写到bizDataTable这个字段中即可，框架会自动去加载这个Sheet中的所有数据。 filter：测试数据的过滤条件。可能准备的测试数据比较多，但是在当前这一个step中，只需要执行某一条或几条数据，就可以使用filter这个条件。比如说，登陆时，想用错误的用户名和密码来登陆，那么可以这样写：用户类型=baduser。当然“用户类型”是测试数据所在Excel表格中定义过了的字段。老实说，在这次完成的框架中，只有filter这个想法，觉得有点意思。感谢提出这个需求的同事。 Test data数据文件 Test data数据文件，用来存放测试数据。没有区分输入数据、验证数据、以及输出数据，总之，只要是测试过程中，需要用到的数据，都一古脑的做成一行，放到这个文件中。一是觉得这样在设计测试数据时，比较方便和直观，二是也没有更好的设计思想。 对业务的验证，按照设想，是通过日志文件和测试报告来体现的。所以把验证数据与输入数据放到一起，亦不会有太大的不妥。 数据文件总结 基于把测试设计和脚本开发分开的思路，设计了这三个Excel表格。测试设计时，主要是设计testcase和test data这两个Excel表格。毕竟，这才是自动化测试最核心的价值所在。脚本写得再完美，没有好的测试设计、测试数据，对测试本身并不会有太大的帮助。 因此，希望尽可能把这些Excel表格做得更易用。所谓的框架，就是把这3个Excel