做UI自动化时想到的几点

UI Automation从项目准备到框架成熟，差不多用去了6个月的时间。这段时间给我了很大的发挥空间和难得的实现自己想法的机会。

 

昨天发现了当时写的笔记，觉得可以记录出来，以后会有用。

 

1. 对需求进行测试。举个例子: 项目起初只考虑在一台机器上运行测试用例，当几乎所有的单机测试用例都完成的时候，发现需要把多机器联合操作(run on multipy machines for inter-operation)的测试用例加进来。可是程序设计的时候都是从单机运行用例的角度考虑的，没有留出可以运行多机情况的想法空间。如果当初就考虑好了多机运行是怎么走的，那么起初在设计单机运行的时候做出弹性的框架来兼容多机模式。为什么需要对需求进行测试？我觉得是因为我们经常在项目中期和后期发现需求中包括逻辑不一致的问题，更能发现我们普通人容易犯的一个错误是:用另外一个或多个缺陷/错误来掩盖或是互相掩盖现有缺陷，换句话说叫一错再错，错到我们不认为错为止。

2. 在团队开发里，在项目伊始，对所有队员描述一个大家共同努力的目标。这样做的好处是在开始的时候就做对的事情，让每个人都清楚和统一目标，否则有的人会因为觉得自己的角色可能不重要，所以不用太用心，给全组士气造成影响。另外一个好处是避免以后再废话。

3.讲述所有人（不同角色的人）所应具备的素质。人就是这样，如果开始的时候就做对的事情，有了警鸣钟，事情进展的会顺利些。虽然这些事情看似多此一举，但不得不考虑人的本性就是如此。

4.经常的去思考如何把技术和产品做到最大限度的优秀。这样会产生一些灵感或想法，来改进现有的东西。

5.使用统一的接口。

6.对领导，要想得到项目的具体实施，需要去争取他们的肯定和共识。

7.要验证的场景很多，找出、设计出不同的场景。比如：COM验证邮件是否发出，邮件文本验证, 不同控件的特有的点击事件，用同一套代码对不同版本产品的验证等等。

8.UI自动化的技术。UI Automation 离不开像Mita, KAF ,Maui这样的对UIA技术框架又封装了一层的框架，准确的应该叫类库。

他们都有各自的特点:

1):Maui是最贴近UIA core的一层了，KAF,MITA 都是在maui的基础上建立起来的，这么说可能不准确，但他们都应用了maui的东西。 2):MITA:要比maui好用，它的架构本身就是应用装饰模式，并且对windows application 支持的还算不错，包括WPF,所以使用MITA做UI自动化简单，宜用，比起UIA框架提供的元素好用多了。

3).KAF:它的内部都引用了Maui和MITA, 可能是考虑到Maui虽低层，但不支持WPF;MITA虽支持wpf,但对外部不公开com. 我觉得KAF就是为浏览器的UI自动化而生。它对浏览器的支持超过前两者。

目前UI自动化的技术还存在很大的缺陷，有三点：

一是在UI element查找时，不支持正则表达式；

二是产品的UI技术总是不断变化，从win32,到wpf,再到Rebun, 这就造成了对同一个界面元素的唯一标识的不一致性。对自动化开发限制和挑战很大，针对于特定系统，特定版本的软件，要有兼容的解决方案才能克服。问题的根源是在产品设计时，开发者就没考虑UI automation自动化这事，windows OS也很难让所有在windows上运行的程序都有唯一而且统一的标识。

三是不支持二级查找。目前都是从UI tree的根节点开始查找，而不能直接从所有的二级或三级节点查找ui element.

9.要想提高开发速度，可以通过良好的成熟的架构设计，工具和管理。

10.使用好日志。记录信息时，需要记录好log lelver, when, where, How. 对troubleshooting很有帮助