LoginPage.StandButton.click

         它的优点：

               一、这样的脚本看起来很简洁

               二、控件的描述只需要在对象库做一次，不需要反复的在脚本中做

               三、如果控件发生了变化，那么你需要做的仅仅是维护对象库，不需要去维护所有的脚本

               四、控件对象可以共享，你做过的工作，不需要别人再来做一次

               五、对象库可以提前构建，不依赖对象的具体实现，这样我们的测试脚本也就可以提前编写，推动整个自动化工作前移

它的缺点：

               一、脚本是很简洁了，但其可读性变差了，至少增加了读脚本的成本

               二、既然放在一地方进行维护，就涉及到命名规范的建立，否则就会乱

               三、维护的时候，加大了评估所带来的影响的难度，因为你可能不知道这个对象在哪里被引用了

对于第一条缺点，我认为还不至于那么影响，只要在脚本里加清楚注释，描述好业务，并且对象名称起得够有语义的话，可读性反而会更强。第二条缺点正是我深受其害的，规范的建立既需要考虑业务知识，又需要考虑团队的使用习惯，制定好的规范难，就算有了好的规范，如果规范不是强制执行的话，那还是等着乱吧。第三条缺点其实也是可以解决的，只要给对象库中对象建立统一的引用，当对象有更改时，所有引用了这个对象的脚本就会自动更新。

lmsg100补充：

对于对象库，我是很有心得了，当年研究RFT的对象库管理真是能够吐血啊，不过后来录制和查找两种方式下

的对象都被我管理的井井有条，还是很有欣慰的。

上面兄弟提到的早早的建立命名规范，这一天我想到的比较早，所以这方面我没有吃过亏。

对象库最好还要区分公共对象库和私有对象库，区分管理。

自动化如果想做好，一定要管理好控件对象，否则对于GUI自动化来讲就是一场噩梦