1. 引入QTP的目的
对于测试人员,手动测试本来就是很枯燥的事情,但是对于这种枯燥的事情再加上一些重复性的操作就使测试人员家具这种烦躁的心情;对于QTP测试工具,它可以消除手动测试那种既耗时又单调,而且需要投入大量的人力资源的问题。
2. 关键字解释
QTP 及QuickTest Professional的简称。
3. QTP背景
3.1 公司介绍及其软件演变
QTP在V8.2之前被称WinRunner;WinRunner是由Mercury Interactive(美科利)公司研发的测试工具,之后卖给HP(惠普),被称着QTP。
3.2 版本演变和适应的操作系统
|
7.6 |
7.8 |
8.0 |
8.2 |
9.0 |
9.1 |
9.2 |
9.5 |
||||
WR |
√ |
√ |
√ |
|
|
|
|
|
||||
QTP |
|
|
|
√ |
√ |
√ |
√ |
√ |
||||
Windows |
√ |
√ |
√ |
√ |
√ |
√ |
√ |
√ |
||||
Vista |
|
|
|
|
√ |
√ |
√ |
√ |
4. QTP与WR的对比
4.1 共同点
1) 都适用的范围:
Web-Related Environments: IE、Netscape、AOL JDK、Java Foundation Classes、AWT Symantec Visual Café ActiveX Controls
ERP/CRM: Oracle Jinitiator, 11i、NCA
Custom Client Server: Windows C++/C、Visual Basic
Operating Systems: Windows 98、2000、NT、ME、XP
Legacy: 3270,5250 Emulators 、VT100
2) 都能适用于Windows系统
4.2 不同点
1) QTP适用范围
ERP/CRM:SAP、Siebel 7.x、PeopleSoft 8.x
.Net:WinForms、WebForms、.Net controls
Web Services:XML、HTTP、WSDL、SOAP、J2EE、.Net
Multimedia:RealAudio/Video、Flash
2) WR适用范围
Custom Client/Server :PowerBuilder、Forte、Delphi、Centura、Stingray、SmallTalk
ERP/CRM: Baan、PeopleSoft、Windows Siebel 5, 6、GUI Clients Oracle、GUI Forms
3) QTP9.0及以后的版本适用于Vista操作系统
4) 对于脚本,QTP用的是VBS,WR是基于其软件自身的独立脚本TSL;
4.3 工具本身特点对比
验证点问题:WR有四种验证点,QTP有9种验证点(见表一),这种验证点的类型越多提供的验证方式越多,就越减少验证脚本的开发难度,而且有些验证点类型是QTP独有的,比如Xml验证点,WR就没有,所以从这点上来看,验证点多其实简化脚本开发难度,让软件更容易使用,那么和你的团队状况有关系,比如你的团队是技术人员欠缺的话,那么自动化测试工具的易用性更加重要。
表 一:
检查点类型 |
描述 |
用法示例 |
标准检查点 |
检查对象的属性值 |
检查是否选中某单选按钮 |
图像检查点 |
检查图像的属性值 |
检查图像源文件是否正确 |
表检查点 |
检查表中的信息 |
检查表单元格种的信息是否正确 |
页面检查点 |
检查网页的特性检 |
检查加载网页所需要的时间,或者检查网页是否包含中断连接 |
文本/文本区域检查点 |
检查文本字符串是否显示在网页或者应用程序窗口的适当位置 |
检查预期的文本字符串是否显示在网页或对话框 上的预期位置 |
位图检查点 |
将网页或应用程序的某个区域捕获为位图后进行检查 |
检查网页或网页的任何部分是否按预期的进行显示 |
数据库检查点 |
检查网页或应用程序访问的数据库的内容 |
检查数据库查询中的值是否正确 |
可访问性检查点 |
对网站区域进行识别以检查是否符合508部分 |
检查网页上的属性是否含有ALT属性(该属性是W3C Web内容可饭访性要求规定的) |
XML 检查点 |
检查XML文档的数据内容 |
用于检查XML特定的文件;XML应用程序检查点用于检查网页中的XML文档 |
5. QTP的功能点
5.1 创建检查点
1) 检查对象
2) 检查页面
3) 检查文本
4) 检查表
5) 使用检查点运行并分析测试
5.2 参数化测试
1) 定义数据表参数
2) 向数据表中添加数值
3) 修改受参数化影响测试的步骤
4) 运行并分析参数化测试结果
5.3 创建输出值
1) 创建输出值
2) 利用输出值运行并分析测试
5.4 使用正则表达式
1) 正则表达式语法
2) 使用正则表达式
3) 使用正则表达式分析测试结果
5.5 插入新步骤
子录制好的脚本中添加新的步骤(功能点)。
5.6 环境变量
5.7 场景恢复
在测试过程中会遇到测试出错的情况,如果加上场景恢复可以更好的保护脚本。
5.8 对象库属性
5.9 与QC向连接
5.10 描述性编程
6. 手动测试与QTP测试的时间对比
测试类型 |
用 例 步 骤 数 (step) |
时 间 |
总 时 间 |
备注 |
|||||
制 定 脚 本 时 间 |
回 归 /功能 测 试 时 间 (一) |
回 归 /功能 测 试 时 间 (二) |
回 归 /功能 测 试 时 间 (三) |
回 归 /功能 测 试 时 间 (…….N) |
系 统 /功能 测 试 时 间 |
||||
手动测试 |
30 |
无 |
1 小时 |
1 小时 |
1 小时 |
1 小时 |
1 小时 |
5小时 |
|
自动化测试 |
30 |
3 小时 |
0.5 小时 |
0.5小时 |
0.5 小时 |
0.5 小时 |
0.5 小时 |
5.5小时 |
其中的制定脚本时间包括脚本调试时间和部分维护时间;在我们的实际工作中,回归测试的测试可能远大于4次,当回归测试的次数越多时就体现出自动化测试的优势 |
7. 存在的风险及好处
7.1 存在的风险
4) 对于脚本,如果配置库出现问题将导致脚本不可用或者丢失,这就将会使测试时间延误(因为会重录制脚本和增强脚本)
5) 不同的操作系统和QTP版本之间不可移植脚本,所以在测试过程中,每个测试人员使用的QTP版本和操作系统必须一致
6) 对于QTP自身的功能理解不透彻,导致在某些功能点的测试上不如手工测试
7) 在公司自身的软件进行升级后,QTP较低版本有可能无法识别某些控件等,导致必须用较高版本的QTP,这样原有的低版本QTP的录制的脚本就将不适用
8) 由于QTP来自网络破解,在测试工程中可能会出现一些无法识别的错误导致某些功能无法进行测试,最后还是手动测试,与预期的分析不一致
9) 由于公司没有QTP方面的测试专家,如果在测试某些功能时遇到无法解决的问题会导致测试延时,或者回归到手动测试
7.2 QTP测试的好处
1) 从枯燥无味的手动测试中解脱出来
2) 在测试过程中遇到功能相似或者相同的可以用QTP,避免做重复的测试
3) 可以减少人力资源
4) 主要在回归测试过程中减少时间,在测试的初期可能不会减少时间
5) 脚本可维护
6) 脚本可扩张
8. 结论
虽然存在很多风险,大部分都是客观的认为因素,只要条件和时间允许还是能够解决的。
基于在实践中的学习和网络搜索的结果,个人认为QTP对于公司现在的软件还是很适用的,至少可以让测试人员从以前的无味的测试工作中解脱出来,多做点其他与之相关的事情;让测试人员多接触一些先进的测试工具。
基于以上内容和学习的结论向公司推荐QTP,其版本在不断的更新,增加的新功能能适应软件的升级,且在版本9.0及以上的版本的能用于Vista系统下。