我对UI自动化测试的理解
引用一位很好的同事也是很好的朋友的一句话“UI的自动化，听起来很神秘，学起来很简单，真正用起来却很困难”。通过自己的经历，我很赞同这句话。最开始确实觉得很神秘，可以用程序来控制鼠标，键盘去操作软件，以前从来没接触过。后来学了一下几个流行的测试工具，感觉没什么东西，就是record and play。可是，真正用到项目里的时候确实是困难重重。这里想谈一下自己的感受，这方面不是专家，不过应该给测试的新手能有所帮助。UI自动化最关键的一点是要选择一个适合自己项目的工具。每个测试工具都有它的优点，有它的缺点，每个被测试的项目也有它自己本身的特点。比如，项目是用什么语言编写的，C, C++, Java, or C#? 还有就是项目是什么类型的，Desktop or Web Application? 很难说一种工具就可以搞定所有或者大部分的项目，也很难说一个项目就能单纯的靠一种工具来搞定。也不太可能你专门开发一个工具来100%或者90%以上适合自己的项目，除非你的公司是微软，Google才有这个实力。因此对测试人员来说就有两个要求，一是要掌握尽可能多的工具，要了解它们的优缺点。这样才能在不同的项目中，一个项目不同的components去合理的应用它们。第二就是要有一定的开发功底，在测试工具不能胜任的时候，自己开发工具来作为补充。当然更可能的情况是每个公司只是拥有一种工具的license, 你没有选择的权利，这样你的开发能力就更加的重要了。（这里所说的开发能力不是自动化脚本的编写，主要是指C, C++, 至少是C#, Java的开发能力）。
下面说说如何去使用测试工具。最初接触就是record and replay， 感觉非常的简单。也碰到有些人竟然认为自动化测试就是record and replay。我必须说他们很无知，有这种思维的人可能以后都很难成大器，因为他们理解问题的能力太浅显了。希望论坛没有朋友会这么认为。（这里我说话不太好听，是因为为这种人生了太多的气了，希望大家谅解）。其实，我们record的script基本上每一句话都需要进行修改和优化。
UI自动化最重要的一件事情就是得到要操作的对象，比如一个textbox or button。必须先能够访问他们，得到他们才能够操作他们。这其实也是recording script的唯一的用途，告诉我们如何能够得到这个对象。这里会有两个问题，一是测试工具不能够得到这个对象。另外就是测试工具的脚本得到了这个对象，可是在replay的时候，对象却不存在。可以说UI自动化最核心的chanllenge就是是否能够得到对象了。得到了对象其他的相对来说都会容易很多。那么如果出现这两个问题怎么办呢？首先要分析是谁的问题？如果是测试工具本身的对象识别能力的问题，那只能找其他的方法绕过去了。比如自己用高级语言编些程序，或者用其他的方法来跳过操作这个对象来执行同样的操作。这个地方最能考查一个人水平的高低了，有些人束手无策，有些人就能够想到有效的办法。而且这个地方的chanllenge往往比一般的开发人员的工作要有难度。如果是程序本身的问题，就可以报bug了，让开发人员来修正。其实，程序的accessibility的bug是很多的，而且大部分公司或者开发人员都不重视，也许你报了也没用，没人理。可是他们如果不fix就会block你的Automation。对accessibility的重视程度也可以看出一个公司的自动化测试水平的高低。
以上讲了UI Automation的核心问题：怎样得到要操作的对象。有问题的话，解决办法是开发人员fix, 等待测试工具的升级，自己想workaround。得到了对象以后的chanllenge更多的是测试流程的控制和对异常的处理。自动生成的script，操作之间的timeout是定死的，这也是我们需要修改script的最重要的原因。我们要操作的对象，往往在timeout之后还没有出现，或者还没有enable。这个时候自动生成的script在replay的时候就会出错。那么我们就需要修改代码来等待足够的时候，一般的测试工具都提供了这样的功能。注意不要只是Sleep，这样的话无论这个对象出现的多快，你都是一定要等这段时间的。通常都是，约定一个时间，对象出现或者可用后就立即返回，无须等待剩余的时间。如果最后还没有出现就抱错吧。还有一个比较重要的问题就是其他意外窗口的干扰，比如一个窗口突然出现盖住了你要操作的对象怎么办？这时候你需要把你要操作的对象重新激活到桌面的最前面，这样鼠标才能正确的点击到目标的身上。还有一个比较好的办法就是不用鼠标去点击，调这个对象的click函数。也就是说，平时是鼠标点击然后激活click函数，我们可以直接用程序激活click函数。这样，即使目标被其他窗口盖住，也可以正确的执行你期望的操作。
以上是我想到的UI自动化的一些基本问题。以我的经验来看，你在自动化的过程中还是可能出现很多你意想不到的问题。这些问题可能的原因也是千奇百怪，可能是软件的bug，可能是测试工具的bug，甚至可能是操作系统的bug。对这些意想不到问题的解决能力非常重要，一方面通过测试经验的积累，另一方面就一定要靠你的想象力和创造力了。从自动化测试遇到的这些难题来讲，比一般的开发工作要困难得多。这里也说一下，水平高的测试人员不比开发人员差，比他们还要强。当然了，开发也有很多的难题，总的来说还是会比测试遇到的难题更多更难。因此，开发，测试没有水平高低的区别。真正的水平就是对难题的解决能力如何。
一般来说，desktop软件要比html网页容易一些，windows程序要比java容易一些。也就是说一般的测试工具对windows deskop的支持都比较好，对jave和html的支持会比较差。这是因为微软对programatic accessiblity有着严格的定义与要求。因此，如果你测试windows程序，自动化起来就省力多了，测试java程序就麻烦多了。我当时选择的Test Complete, 因为公司只有Silktest的license,虽然对java支持，可是支持的很不好，也许是版本太低了。而我发现新版的Test Complete竟然增加了对Java的支持，而且效果还不差，就选择了它。Winrunner我试过，好像得需要插件，我没有。Robot我忘记怎么回事了，好像也不是很好用，装不上还是怎么了。不太清楚他们对Java的支持如何。个人对Test Complete的功能，价钱，灵活性还是比较满意的，可以用来做一些东西，大家如果没经验可以从这个工具入手，建议用jscript语言。 Test Complete确实是个不错的工具sdlkfj3 看了楼主总结的GUI的自动化,基本上算是非常全面了.
我用QTP和WinRunner也做过三年左右的GUI自动化. 楼主说出了大多时候我们遇到的问题也解决的方法.其实很多测试工具本身提供了一些功能,我们只需要很好的利用他.
如果是WinRunner的GUI map还是QTP的OR,都有一定的对象识别和管理功能,只是说适应对象的问题,至于对Java的支持,好像Mercury的产品一直都不是很好, Test Complete没有用过. :(
另外,你说的对象或者窗口被破坏问题,个人认为这是需要自动化的独立环境和独立运行的流程保证的,如果代码能考虑到这个地步,就是很难能可贵了. WinRunner在这点比QTP差很多.
希望多多交流,我的MSN: zhunaldo@hotmail.com 楼主如果是测试JAVA应用程序或者J2EEWEB程序最好还是用Rationa Functional Tester吧
RFT采用Java作为脚本语言,如果你的JAVA功底还不错的话,你可以随心所欲修改你的脚本最大限度你的GUI测试,从我目前使用情况看,RFT还是很不错的,楼主可以尝试一下 RFT支持通过对象的属性动态查找对象方法,find(),对于比较灵活的对象,可以进行动态获得,当然,RFT也提供很丰富的API,可以进行你的脚本开发 总结的不错,本人只学过QTP和Robot,没用过LZ说的Test complete...不过有机会会用下 很好 高手的讨论真能学习到东西啊
回复 #1 cleverman 的帖子
说得很对，深有同感。谢谢楼主。 写的真好 写得真好，我要收藏！ 写的好
页:
[1]
