我的dogtail在GUI方面的测试

jupiters

                1. Dogtail的结构

2. 什么是at-spi
这个gnome at-spi(不是dogtail)是Sun公司搞的，是Sun在gnome社区唯一主持并且发布的官方程序，不管Sun是否还存在，Accessibility在Linux/Unix图形方面是非常有用的，尤其是在GUI程序测试方面（如果你知道winrunner在windows平台上的话）。
3. 测试教程
有关测试的具体教程，请参见附录1。
4. sniff组件
在dogtail发行包里面自带了一个sniff的组件，这个组件在GUI程序追踪方面非常有用，可以直接使用这个脚本
# /usr/bin/sniff
之后的界面就会显示一个所有的gnome程序，值得一提的是，Gnome的组件是以tree的形式显示的。所以在sniff程序里面，你可以根据他的显示来明白的知道所要调试程序的layout.
再有，sniff程序只能运行一个实例，如果有多个sniff程序在运行，gnome就会锁死（不知道为什么）。
5. 碰到的问题
在利用dogtail编写GUI测试程序的时候，碰到了一个难题。dogtail只能捕获静态的layout组件，当GTK组件是动态生成的时候，也就是由程序根据当前的Layout在new出来的时候。dogtail虽然能够发现这些组件，但是不能够定位这些组件的名称。这样，当我们试图测试这些生成的组件的时候，根本无法定位这些组件。这个问题似乎是at-spi module的问题，也就是它就无法实时追踪gnome的生成组件，并且掌握他们的信息。没办法，只好在工程上想出一个workaround。就是，利用被测试程序组件之间的layout关系，由已知的组件来定位到未知的生成组件。
具体方法是：
combo_list = KNOWN_COMPONENT.findChildren(predicate.GenericPredicate(
                roleName='combo box'), recursive=True)
其中KNOW_COMPONENT是已知的组件（可能是一个 panel)。而我们想找在其上生成的"combo box"，通过findChildren函数能够找到所有的type是"combo box“的组件。然后，我们可以根据要测的组件是第几个，来确定他们到底是什么。
region = combo_list[2]
country = combo_list[1]
timezone = combo_list[0]
附录:
1. Dogtail: http://www.redhat.com/magazine/020jun06/features/dogtail/
2. ATSPI: http://en.wikipedia.org/wiki/AT-SPI
               
               
               
               
               

本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u/412/showart_1876488.html