高手进，关于自动化测试框架的问题！
两种方式：1.QTP自身可以调用action的方式，将不同模块整合成一个流程，所有数据在DataTable里面配置。
2.编写程序，使用语言**编写的框架，所有数据放入外部一个excel里面，使用excel调用脚本及配置数据。
高手来一下，第二种比第一种的绝对优势在哪里呢？现在很多大型的公司都在开发自定义自动化测试的框架，请问你们所开发的测试框架，优势在哪里呢？
从整体上来看：我个人感觉没有实质上的飞跃 我之所以没觉得优越主要是：
1.数据，一样需要配置。
2.如果说要简写Browser等等代码，我同样写一个VBS的调用进来就可以了。 简单点说
第1种方式，只是循环填数据，无法适应变化、而且维护麻烦
第2种方式，数据外部改比QTP自己的DataTable清晰，外部配置不只是数据的，也可以是关键的识别属性、流程的控制等等，也就是说，如果做的好，不需要动脚本即可以适用于任何类似或者可兼容的被测程序 按照3楼说的，我只能理解为：直观性比较强，配置数据方便！
修改数据，我直接打开EXCEL一样可以看得清除，不过如果将所有的变量信息集中在DataTable，流程一长，模块一多，那就看起来相当费神了，如果是外部的EXCEL里面的数据，可以将所有的模块分页开来，这样直观性就很强，配置起来相对方便。 但如果仅仅是这样而已，其实并没有实质性的飞跃，操作上，还是相差无几，实现的效率，仍然差不多。因为我如果每个action调用，那么调用只不过几个操作步骤而已，一下子就好了。
外部框架写了还要调用，配置，这个可能费更多时间，但数据的维护相对可能直观，或许减少时间。
但我们自动化都是回归的，几乎配置一次不用配置第二次（当然也有部分数据需要每次修改，但应该来说很少的一部分），那么两者总体来看，时间效率，几乎没区别，那么为何费时间去开发一个框架呢？ 只是用来回归的自动化也就是这样的感觉了，你说的内容更像 代码模块化+数据驱动
模块化之后还是可以继续优化的，甚至说100个新页面，不要增加任何脚本即可全部测试，当然做脚本的人要对所有可能的情况全部考虑到。（除非极特殊的地方带过一下，可以是直接录制点几下完事的） 继续关注，Mark下 回复 1# 鹭岛
1. 你可以考虑一下将action里面的测试脚本放在外部文件里（如：vbs）
2. 把你QTP里的对象库文件，看看能不能用描述性编程来替代它
3. 将测试数据单独保存在外部文件中（如excel\xml）
4. 考虑一下报表及日志信息该以什么方式展现
5. 最后，为你的测试脚本做个版本管理吧 记得前段时间我一直都纠结在到底是使用录制来完成自动化测试还是使用描述性编程来完成自动化测试呢，后来想明白了，方法的使用是根据需求来判断的，需要什么就用什么方法，就这么简单。
页:
[1]
