qqApp = Application（"QQ"）

 

　　loginPanel = qqApp.launch（）

 

　　buddylistPanel = loginPanel.login（"27373636","ffssdd"）

 

　　aioPanel = buddylistPanel.findAndOpenAIO（"28282828"）

 

　　aioPanel.sendMsg（"hi"）

 

　　好，这个伪脚本，有什么特点呢？对，没有见到控件。控件要封装到界面类里面。具体一下说，自动化脚本的隔离变化基本上可以分四个层次，

 

　　a. 用例逻辑，通常有个用于继承的TestCaseBase， 用来封装用例的逻辑，类似teardown, setup，run之类。

 

　　b. 业务逻辑，通常就是继承TestCaseBase，用例实现的本身。封装业务逻辑的变化。c. 界面逻辑，通常就是界面类，例如上面的LoginPanel。隔离了控件与业务逻辑，让控件位置，ID的变化，可以控制在界面类中。

 

　　d. 控件驱动，通常就是基本的获取控件树，检索控件。封装控件获取方式。

 

　　3.控件定位要用类似XPath的方式。这种方式的好处就是方便阅读，把复杂的位置描述封装到一条短短的字符串里面了。（有写朋友误会了，是XPATH, 是类似XPATH的东西，但是要把他比较复杂的部分去掉，只支持属性，节点的简单定位就行。不然跟正则表达式一样，又是一对学习成本了）

 

　　4.通过分Step的脚本化繁为简。UI自动化脚本都有个特色。长～！一个脚本通常我们希望验证好几点，登录，打开聊天窗口就不容易了，因此除了验证发消息，我们还希望可以发图，发表情，那么这个时候，最好可以把用例分割成几个Step。出了问题，就集中排查某个Step的日志就OK了。补充一下， 大家肯定想个一个问题，每个用例都要独立的，要互不影响，重新登录，为了稳定，多补点时间我不在意，但是现实你有发现这些时间会增加用例出错之后的修复，验证的时间成本。所以“分Step”无疑意思是给大家一个合并用例来提升用例执行速度，但是又不影响用例与用例之间的独立性。

 

　　5.不要再给UI操作/验证本身压力了。例如输入文本这些操作，也没有必要用键盘事件来触发，如果你是注入方式的，获取到控件对象，直接setText吧，这样会稳定很多。还有端到端的UI自动化，如QQ发消息到另外一端的QQ的测试，我们就可以利用网络协议，发送消息，另外一端用UI验证接收消息。

 

　　6.定时重启手机和，出错的用例再跑一次，可能会帮助回避一些问题，可以做。但是不能以此来麻木自己对错误的敏感的感觉。

 

　　7. 稳定你的环境，这些环境包括网络，系统，账号资源，电脑/手机。

 

　　a. 网络， 假如我们的UI自动化是验证功能逻辑的，那网络就一定要被牢牢地控制，独立的路由器，并且监控着网络情况，如果存在严重的丢包和断连，这信息一定要及时同步出来，甚至可以自动控制你的用例，在网络差时暂停，网络回复后再跑。

 

　　b. 系统， 系统经常有各种更新的弹窗，特别是IOS。利用网络，屏蔽这些无用的推送把。android则是找个稳定的ROM。

 

　　c. 账号资源，有很多软件账号资源都是不能重用的，或者重用了之后，用例之间会相互影响。这里需要有账号资源池的概念，类似SVN, 通过CGI, 来取了资源，可以加锁，还回去，再解锁。

 

　　d. 手机与电脑，肯定不能长时间运行，不然他们也会发脾气。所以定期重启手机和电脑，似乎是必不可少的一步。

 

　　*UI自动化测试的未来

 

　　有很多人问， UI自动化应不应该投入，有没有前途。这个问题没有绝对的，要看项目的类型，像做Android手机的，因为项目相对来说比较稳定，CTS本身就有一定的用例量，几千个UI自动化测试，都能维护过来，而且通过率极高。做前端应用的，像我们PC QQ，开发在控件唯一标识的问题上，给予了不少支持，因此用例的量和稳定性也是非常高。说虚一点的，如果这个事情至上而下都是支持的，想做的，投入的方向没有错，价值认识正确，肯定是有积极的产出的。另外，UI自动化是测试生来无法回避的一种能力，可以不依赖他，但是你需要他。

原文转自：http://www.uml.org.cn/Test/201611021.asp