51Testing软件测试论坛

标题: QTP与模拟器的较量 [打印本页]

作者: Jackc 时间: 2009-2-11 14:55
标题: QTP与模拟器的较量
环境：QTP 8.2 （由于近段时间在忙其他的东西，一直没有时间在重新好好学习QTP，不知道9.5版本的QTP能否识别WM模拟器呢）
目标：WM模拟器GUI界面
问题：无论安装什么组件，QTP无法识别模拟器内组件（当然，Robot也不行），所有录制只能使用“坐标大法”。但是在回放时，出现click步骤实效的问题，即正常回放但是不对坐标点进行点击操作。
解决方法：
1.对click步骤进行检查
Object.click x,y
wairt times
Do while object.check(checkpoint())=ture
            Object click x,y
Loop
其中times根据实际情况而定，可能是1秒，也可能是0.5秒。
虽然这样作规避了click丢失的问题，但是带来了两个新的问题：脚本代码过于庞大/运行周期过长。
2.录制完成后，将其中的click改成dblclick，意外发现“click问题”解决了，同时也有新问题出现：比如dblclick一个界面x,y处的buttonA,如果在下一个界面相同位置有一个buttonB ,结果在回放这个双击步骤时，得到的输出：有时是只点击了buttonA，有时却连buttonB也一同点击了...
3.于是将1和2进行了简单的组合，录制完一个脚本后，先将所有的click改成dblclick，再回放几次（偶一般回放10次左右），然后找出有问题的dblclick，把它们改称1种描述的click检查。

注意事项：
1.在设置位图检测点时，应该注意以下几点：

  a、  检测点具有代表性，能够代表步骤成功后的特殊效果；

  b、  设置检测点时，尽量采用较小的图片作为检测点，较大的图片可能会出现意料之外的情况：比如设置检测点时，数据比较少，图片内某些部分是空白的，但是在回放脚本循环运行几次后，实际图片内的相同位置出现一些其他的信息，可能会导致检查的失败。

  c、  设置检查点时,选择的图片最好不要包括以下信息：

      •       鼠标图标

      •       高亮或未高亮的数据信息,比如在电话本界面点击一条信息后，此条信息会变亮

      •       操作后会变化的文字信息，比如下拉框选项

2，根据自己的机器反应速度不同设置不同的等待时间。

等待时间的设置可以更高效和稳定的完成测试回放。比如：从主界面切换到电话本界面，等待时间设置为1秒或0.5秒就可以完成，而且不会出现下一个步骤已经执行，界面还未切换成功的问题。

总的来说，这个方法还是比较繁琐，不知道大家有没有更好的方法，能让QTP识别类似于WM模拟器这样的窗口?

作者: Jackc 时间: 2009-2-11 15:52
难道没有人在手机GUI测试中使用自动化？
都是黑盒手动？

作者: wan_xie2007 时间: 2009-12-28 09:56
标题: 这方面资料好少啊
我最近也在搞这方面的，包括BREW，WM，andriod平台应用自动化测试。
有时间可以交流一下。MSN：wanbiao2008@hotmail.com

作者: shanxi 时间: 2009-12-28 11:37
LZ这种自动化没意义因为根本没有对每步的ui进行verify过

严格意义上来做根本说不通。

作者: Jackc 时间: 2010-5-21 21:39

原帖由 shanxi 于 2009-12-28 11:37 发表
LZ这种自动化没意义因为根本没有对每步的ui进行verify过

严格意义上来做根本说不通。

老兄，你没试过怎么知道不行？你可知道NOKIA的ASTE是怎样实现UI自动化测试的？
当年我也是误打误撞利用了其中的一些技巧而已，而WINCE的自动化测试已经被我这种粗枝大叶的试探成功引入到项目流程中了，主要是做一些性能上的测试，比如次数和时间测试。

我们操作button或输入数据，都会有特殊的痕迹遗留在UI界面上，比如操作Button，一般都会弹出另一个界面，而这个界面的Title则是最好的verify图片。
而对于编辑框，输入字符“A”，那么在编辑框的第一个位置必然会出现一个“A”字符的图片，编辑框的第一个字符输入位置可以使用坐标得到，那么只需要验证这个坐标是否有A字符图片即可；如果继续输入B，同理，在编辑框第二位置坐标就会出现B字符图片....如果输入一串随机数呢？根据输入字符的顺序确定verify字符图片的位置，再每个或几个对应字符图片直接去verify即可。

所以，怎样去verify，是很讲究技巧的。而NOKIA则在这方面做的更为细致，他们先将每个UI界面定义出来（这里应该用到他们在image中留下的一些API），再将公共UI和特殊UI提取出来，当ASTE读到不同的UI的API时，自动将出当前UI用各个公共UI和界面特殊UI组合出来。
而对于字符的识别，NOKIA直接使用XML导入字库来解决的（我以前没有现成的字库，只能自己做图片，其实也相当于做了个简化版的字库了，呵呵），这样在编辑框输入字符的时候，能将字符图片转化为字符串来识别。

呵呵，不知LS的老兄是否还觉得WINCE无法用QTP做自动化测试呢？

作者: Jackc 时间: 2010-5-21 21:42
至于每步verify的问题，
在checkpoint这里，我检查的是正是制定坐标的位图
Do while object.check(checkpoint())=ture
Object click x,y

作者: TIB 时间: 2010-5-22 09:42
可以考虑使用专门的手机自动化测试工具，例如TestQuest、mShell之类的
http://www.m-shell.net/

另外，QTP也有一些第三方的专门测试手机应用的插件，例如Jamo 、 DeviceAnywhere的解决方案
参考：
http://blog.csdn.net/Testing_is_ ... /01/03/5125043.aspx

作者: shanxi 时间: 2010-5-23 14:02
标题: 回复 5# 的帖子
感谢你的详细回复题外话你好像是做手机测试的吧所以你对手机界面自动化感觉经验很逼真。

很常时间有人问过一个同样的问题你做界面自动化的验证点在哪？
我通常的回答是，其实你做每一步就进行了verify。拿QTP做例子，你点击"OK" button录制后显示的是OK这个标题的button,当回放时QTP肯定是进行过验证。可惜我说过的内容好些人仍然在反复地问验证点在哪,为何呢？因为他们从来都是从自动化工具来做，而从没有只用系统api做过，所以很难对此有深刻的理解。

我之所以这么说，是因为传统的自动化界面测试工具对你操作的每一个步骤都会进行verify，而LZ所说的按照坐标来点击，却正好缺少了每步的verify。你所说的结果即操作几步后会出现相应的界面变化，这个我很认可，但这样的策略在设计时就需要想的很清楚到底哪个地方需要verify，还有一个问题就是这样执行后出错了很难直观找到真正问题出自哪，会影响报bug的效率。

界面自动化是所有自动化测试中最最耗费资源，也最最可能达不到预期的自动化测试。其脚本设计、开发和维护各个环节都需要耗费大量的人力机器等投入，非产品有极大价值，否则别轻易投入。

作者: Jackc 时间: 2010-5-24 10:06
标题: 回复 8# 的帖子
太感谢了，LS一语中地，解决了我多年闷在心里的疑问。
当时做WINCE测试的时候是2007年，那时用的QTP8.2还没有专门的手机的插件，无法识别模拟器窗口组件，所以只能用很复杂的位图verify。

而对于QTP自己的verify功能，基本都没用，所以才出现了一个问题：
click某个坐标，可是实际上在反复重放时有15%的可能性是没有点到

当时也问了一些人，都没有说清楚。听LS一番话，才明白测试工具自身也会存在verify操作的属性，而对于不识别的组件，QTP可能没有去verify，所以消耗了我大量的时间去弥补这个属性。

我是做手机测试的，我对自动化测试领域这块至多只能算是了解吧，所以当年我的策略很简单，阿尔法测试目标达到后，剩余的时间和人力资源决定自动化测试的范围。至于范围的优先级则根据需求来定。老实说，除了在编辑框取得比较好的效果外，其他位置的测试效果只能用一般来形容。

这篇帖子是我07年总结的，当时其实是希望和更多做手机UI自动化测试的同仁交流，可惜，那时做这个的好少……
现在在用NOKIA的ASTE，测试环境上好了很多，则少了很多以前专研问题的劲头，也渐渐的淡忘了

那天偶尔翻出来看，结果让我对自动化工具的认识提高了，再次感谢

作者: Jackc 时间: 2010-5-24 12:33
标题: 回复 7# 的帖子
谢谢TIB的链接，其中DeviceAnywhere的方案与ASTE有异曲同工之妙。

不过在普通公司里，要说服老总买一个licence还是一件比较艰难的工作

作者: TIB 时间: 2010-5-24 16:39

原帖由 Jackc 于 2010-5-24 12:33 发表
谢谢TIB的链接，其中DeviceAnywhere的方案与ASTE有异曲同工之妙。

不过在普通公司里，要说服老总买一个licence还是一件比较艰难的工作

可以找找有没有开源的

或者自己开发

这个也可以参考一下：
http://blog.csdn.net/vincetest/archive/2010/01/28/5265414.aspx

作者: Jackc 时间: 2010-5-25 13:37
标题: 回复 11# 的帖子
那篇博客文章思路写的很清晰，不过套路倒是蛮老的了，呵呵

开源的工具大都只能搭建一个局部的环境。

说到底，要搭建完整的环境，只能自己设计。

现在手机测试工具专业开发的职位不是很好找到。

目前国内手机行业比较糜烂，要么是在当年稳定的产品上增增减减（比如ZTE和HW），要么就直接买方案（比如MTK、展讯等方案），再像Google这样的新平台，调研的公司倒是不少，真正做出产品却寥寥可数。

所以，导致了三个问题：
1、大公司已经有了自动化工具了，而小公司连开发人员的薪资都压得很低，哪里会高薪找个工具开发呢？

2、专业的工具开发人员不容易培养，而单纯的自动化测试人员对工具开发也很难达到精通（个人观点，隔行如隔山嘛）。

3、大多公司集中在第三方软件开发的层次，缺少一些核心AP，很难实现完整自动化工具环境的搭建。

哎，只能是做多少算多少了

[ 本帖最后由 Jackc 于 2010-5-25 13:39 编辑 ]

作者: TIB 时间: 2010-5-25 14:07

原帖由 Jackc 于 2010-5-25 13:37 发表
那篇博客文章思路写的很清晰，不过套路倒是蛮老的了，呵呵

开源的工具大都只能搭建一个局部的环境。

说到底，要搭建完整的环境，只能自己设计。

现在手机测试工具专业开发的职位不是很好找到。

目前国 ...

分析得比较到位！

作者: gascend 时间: 2010-6-11 17:05
jackc能共享一个NOKIA的ASTE的链接么，怎么没有找到啊

作者: Jackc 时间: 2010-7-1 17:54
标题: 回复 14# 的帖子
这个……，如果你感兴趣的话，我们可以私下交流。

因为它的下载地址，需要特殊权限访问的。

[ 本帖最后由 Jackc 于 2010-7-2 11:11 编辑 ]

作者: neal2009 时间: 2010-9-7 13:55
我最近也是在潜心研究手机如何自动化测试的问题。Feature phone的时代已经过去，迎来的内容将更加的复杂，投入测试的人力也将不断的被扩充变大，而这个对于管理来说，是很大的挑战，所以引入自动化，控制人员规模，降低测试成本，提高测试质量，迫在眉睫。

我的qq:768483996
欢迎加入讨论。

[ 本帖最后由 neal2009 于 2010-9-7 13:57 编辑 ]

作者: smallpigpig_26 时间: 2010-12-27 21:24
本帖最后由 smallpigpig_26 于 2010-12-27 21:25 编辑

回复 3# wan_xie2007

请问有什么学习心得吗，分享一下啦~~

作者: smallpigpig_26 时间: 2010-12-27 21:26
确实很少手机应用方面的测试，成功案例也很少吧，资料很难找，不知国外的发展水平如何呢

作者: hy861127 时间: 2011-4-11 10:19
Jackc,我目前是做android平台的测试的，之前是做互联网网站的自动化测试，前几天用了就在想您当初那问题把自动化和性能引进到手机模拟器上，找了些工具如robotium用了下，觉得这个开发成本太高了我研究了半天看了大量的android API接口和函数类，觉得用robotium不太现实。QTP有自带的手机应用平台插件？有**的没嘿嘿希望能和你交流下技术

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)