实战UI自动化开发，记录过程的点滴心得

1.test case的执行过程大部分都是通过一系列的鼠标点击动作构成的;执行完毕就到验证阶段了.

Excuting of test case run with a set of mouse-click event mostly; The next to excuting steps is verification.

 

2.有了类似UIA这样的自动化测试框架，Excute a test case变得相对简单很多,然而模拟人去验证程序是否有错，就要难好多.

Due to a new UI testing automation framework named UIA come up, Excute a test case become more easier. But, that how to animotion as a man to verify if a programme goes wrong, is much harder than it.

 

比如说验证从邮箱里新建的一封邮件的文本信息。 看似只要用正则表达式就能完成。没错，这个方法当然可以。

i.e. to verify a text format of a new mail is created from mailbox. It looks it can be done by Regular Expression.

Sure, of course.

 

有这么一个还没有解决的bug，文字间距出错。这种bug虽然不严重，但是很容易被人发现，验证程序不见得。我是说，一些想不到的地方在将来某个时间就可能出现了错误，人很难预料到，所以写出的正则表达式不见得就能够检查出错误来。这仅仅是验证程序会遇到的一个小例子. 对于自动化来说，验证要比执行case要艰巨的多，因为是人把人特有的脑力思维交给了不太智能的计算机。验证是一种需要大量创造性的脑力劳动，并且还要用正确的方式。

 

撇开这个问题不谈，我们进入下一个话题，如果有效测试。

Drop this topic and let us go through the next sector "Be Effective Testing".

 

假设所有的test case都可自动化执行了,运行一晚上，第二天一来，发现100 test case就跑了10个，90个都没执行。

这种情况很可能发生。原因很多,客观原因有test case基于对网络环境不稳;server出问题了;系统安全或更新的限制；其他应用程序弹出的对话框的遮挡。

 

有效测试的第二点， 通过设定好的明确的测试验证点，来管理项目当前的测试程度。 换句话说，知道测试了什么和没测试什么。

 

第三点:对于自动化测试中涉及到的多软件交互场景，会有一些excuting steps很长的case, 如果这样的case失败了，测试人员需要很多时间来重现问题，找出问题。 一个好的办法是找到验证的功能点所要调用的COM 接口，并且尝试把步骤化烦为简，隔离外界因素，直接去调用接口试试。

 

第四，从开始就要有个开发文档，来记录进度，case完成情况。

 

第五，写自动化测试，会陷入开发人员固有的思维模式，写不出能完整、正确的验证test case。 要记住一点，测试的思想是发现问题，细心观察。Verify才是自动化测试开发的困难所在。

 

第六，领导喜欢有很多的test case, 觉得这样automation 的进展很快。如果去迎合老板，在没有重构框架，优化代码的时候去追求test case的数量，就失去了踏实做事的品德。

 

第七，做统一的接口，发挥团队成员的创作力来做verification可以弥补第一点的不足。

 

第八，即使领导不特别懂技术，也要把自己的想法及时跟领导沟通，争取得到领导的理解和认可。没有领导的支持，在以后做一些决策的时候，老板不会考虑/理解你的前瞻性的好想法，到时候再说服就很难了。

 

<<<To be continued .....>>>>

 

Go on this section:

Section 2:

在实际使用中，发现微软的UI Automaiton库不是很稳定，比如说当调用UIAutomation.Element.SetFocus()，有时会抛出InvalidOperationException；会找不到界面元素或者找界面元素的时间乎长乎短，用户体验非常不好。

这几点非常困扰我，因为它直接关系到test case是否成功。

 

目前要想改善，就得引用win32的方法，获取界面的element id，相当于重写UIAutomaiton.Element.SetFocus().

痛苦。。。