在自动化测试中，如果控件不能识别，你会怎么做？

我们知道，在做自动化测试时，总会碰到一些自动化测试工具不能识别的控件，比如WPF控件、用户自己绘制的控件、以及一些复杂的组合控件等。当自动化工具对这些控件无能为力的时候，我们怎么办？
这个时候是最考察自动化测试人员能力的时候，因为能解决多少这种问题，决定了你能够自动化多少Testcase。
解决这种问题的方法我认为大概有一下几种：
1. 如果是因为自动化测试工具的限制，比如对于WinForm的控件，有些自动化工具就不能识别，碰到这种情况，最好是看这个工具有没有扩展可以用，比如Silktest的.Net Framework扩展。如果不行，那只能换自动化测试工具了。所以这个凸显出在做自动化测试以前，选择自动化测试工具的重要性。
2. 如果是因为控件比较复杂，自动化工具可以识别，但是无法操作。这时我们可以通过Window API以及消息的方式来做，比如自己去调Window API来操作窗口，或者请开发实现一下消息的接口来给自动化工具调用等
3. 跟开发沟通，让他们的控件支持IAccessible接口，然后我们通过MSAA来操作（如果是WPF控件，则需要实现UIAutomation定义的一些接口）。不过一般情况下，除了微软这样对软件的Accessible要求很高的公司，其它公司很少会花费时间来实现这个接口……。 另外扯一句，产品的Accessible的程度，实质上决定了一个公司能对产品做自动化测试的程度。
4. 如果以上方法都不行，那只有最后一个双刃剑可以用了，就是鼠标键盘模拟。理论上来说，只要用户可以操作的东西，只要有界面，就可以通过鼠标键盘模拟来实现（君不见N多游戏外挂的键盘鼠标模拟大法）。就如双刃剑一样，这种做法是杀敌一千，自损八百。因为鼠标键盘模拟非常依赖于当前激活的窗口以及光标位置和焦点位置，而且同步起来很困难。这也造成了后期维护成本很高。

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