自动化测试：对象库VS描述性编程

自动化脚本编写都涉及到对控件的操作，那么是把这些要操作的控件放在一起进行管理，还是把控件放到脚本中在操作时进行描述呢，这一直都是很有争论的问题。两种操作方式都有其优劣，不能绝对的说其中某一种一定比另一种好，根据不同的应用场景，选择不同的操作方式，才能扬长避短。

对象库，就是把控件放在一处地方集中进行描述、管理，使用时只需要使用该控件的别名即可。如：

LoginPage.StandButton.click

它的优点：

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

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

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

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

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

六、其它…………

它的缺点：

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

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

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

描述性编程，就是在编写测试脚本时描述需要操作的控件。如：

p.button(“#name_submit”).click

它的优点：

一、脚本编写很灵活

二、脚本可读性相对对象库来说，会好很多

三、整个自动化测试框架会相对简单，带来的是自动化测试相对稳定

四、一定程度上降低了脚本之间的耦合性，控件的维护不会影响到其它脚本

五、其它…………

它的缺点：

一、最大的缺点是显而易见的，脚本的维护难度加大了，如果控件发生了变化，维护的工作量很大

二、控件的描述要反复的做，不能共享

三、测试脚本相对来说变的复杂了，没有对象库的脚本简洁

四、正是因为脚本的编写依赖着控件的描述，所以脚本的编写也很难提前

上面罗列了部分两种操作模式各自的优缺点，如何做出正确的选择，就需要根据应用场景有所取舍。

对于大型的、持续优化的被测系统，对象库使用的选择要优与描述性编程，这种场景下的自动化测试不是各自独立的，不是临时性的。对象库的前期投入，表面上可能是会加大自动化的成本，但它的共享和维护都降低了后续自动化的成本，而且为自动化测试脚本的关键字驱动打下了基础，并且可以推动控件定义中的一些标准和规范的实施，这是可以提高被测试系统的可测试性以及稳定性。