在自动化测试中控件不能识别怎么办

我们知道，在做自动化测试时，总会碰到一些自动化测试工具不能识别的控件，比如WPF控件、用户自己绘制的控件、以及一些复杂的组合控件等。当自动化工具对这些控件无能为力的时候，我们怎么办？

这个时候是考察自动化测试人员能力的时候，因为能解决多少这种问题，决定了你能够自动化多少Testcase。

解决这种问题的方法我认为大概有一下几种：

1、如果是因为自动化测试工具的限制，比如对于WinForm的控件，有些自动化工具不能识别，碰到这种情况，好是看这个工具有没有扩展可以用，比如 Silktest的。Net Framework扩展。如果不行，那只能换自动化测试工具了。所以这个凸显出在做自动化测试以前，选择自动化测试工具的重要性。

2、如果是因为控件比较复杂，自动化工具可以识别，但是无法操作。这时我们可以通过Window API以及消息的方式来做，比如自己去调Window API来操作窗口，或者请开发实现一下消息的接口来给自动化工具调用等

3、跟开发沟通，让他们的控件支持IAccessible接口，然后我们通过MSAA来操作（如果是WPF控件，则需要实现UIAutomation定义的一些接口）。不过一般情况下，除了微软这样对软件的Accessible要求很高的公司，其它公司很少会花费时间来实现这个接口……。 另外扯一句，产品的Accessible的程度，实质上决定了一个公司能对产品做自动化测试的程度。

4、如果以上方法都不行，那只有后一个双刃剑可以用了，是鼠标键盘模拟。理论上来说，只要用户可以操作的东西，只要有界面，可以通过鼠标键盘模拟来实现（君不见N多游戏外挂的键盘鼠标模拟大法）。如双刃剑一样，这种做法是杀敌一千，自损八百。因为鼠标键盘模拟非常依赖于当前激活的窗口以及光标位置和焦点位置，而且同步起来很困难。这也造成了后期维护成本很高。

总之，碰到界面控件不能操作的问题我们需要开动我们的思维，能绕过去的尽量绕过去；能不通过界面操作可以做的，一定不通过界面；实在绕不过去的，找一个稳定的方式去做；后还没有办法用鼠标键盘模拟吧，总比没法做强……

注：AutoRunner是黑盒测试工具，可以用来完成功能测试、回归测试、每日构建测试与自动回归测试等工作。是具有脚本语言的、提供完善的针对脚本跟踪和调试功能的、支持IE测试和Windows native测试的自动化测试工具。