对象库编程VS描述性编程

在自动化测试的实践中，对象库编程和描述性编程是两种截然不同的实现路径，常常让初学者感到困惑。简单来说，这其实是在问：你把要操作的那些控件，是集中放在一个地方统一管理，还是在脚本里写代码的时候，现场描述它们的特征？

这个问题没有绝对的答案，不能说某种方式就一定比另一种好。关键是要看你的应用场景，学会扬长避短。

对象库编程：集中管理，统一调度

对象库编程的思路，是把所有需要操作的控件都放在一个“仓库”里，集中进行描述和管理。在脚本里调用时，只需要使用这个控件的别名即可，比如：

LoginPage.StandButton.click

这么做的好处很明显：

• 脚本看起来非常简洁，逻辑清晰。
• 对控件的描述只需要在对象库里做一次，不需要在脚本中反复编写。
• 如果控件的属性发生变化，你只需要维护对象库，而不需要去翻遍所有的脚本逐个修改。
• 对象库里的控件还可以共享，一个人做完了，其他人可以直接拿来用。
• 从项目推进的角度看，对象库可以提前构建，不依赖控件的具体实现。这意味着测试脚本可以提前编写，把整个自动化工作往前推。

当然，它也有自己的短板：

• 虽然脚本简洁了，但可读性变差了。对于一个新加入的同事来说，读脚本的成本其实是增加了的。
• 所有控件放在一起管理，就必须建立一套严格的命名规范，否则很容易乱成一锅粥。
• 维护的时候，评估影响范围是个难题。因为你可能不知道这个对象库里的控件，到底被哪些脚本引用了。

描述性编程：灵活编码，现场描述

描述性编程的思路正好相反，它不在对象库里做定义，而是在编写测试脚本时，直接描述需要操作的控件。比如：

p.button("#name_submit").click

它的优点同样突出：

• 脚本编写非常灵活，想怎么写就怎么写。
• 可读性比对象库要好得多，因为你一眼就能看到正在操作哪个控件。
• 整个自动化测试框架会相对简单，带来的结果是测试过程更稳定。
• 脚本之间的耦合性降低了，维护一个控件时，不会影响到其他脚本。

但它的缺点也同样明显：

• 最大的问题是，如果控件属性发生变化，维护的工作量会非常大，因为你得去每个脚本里找到对应的描述并修改。
• 控件的描述需要反复在脚本里写，无法像对象库那样共享。
• 测试脚本本身会变得复杂，没有对象库那么简洁。
• 正因为脚本依赖控件的具体描述，所以脚本的编写也很难提前，必须等控件做出来才能开始。

怎么选？看场景，看取舍

从上面的对比可以看出来，这两种方式各有优劣，关键在于如何根据你的实际情况来取舍。

对于大型的、需要持续迭代优化的被测系统，对象库编程可能是更好的选择。这种场景下的自动化测试不是临时的，也不是孤立的。前期投入精力搭建对象库，表面上看起来增加了成本，但它的共享性和后期维护的便利性，会大大降低后续的长期成本。更重要的是，它为测试脚本的关键字驱动打下了基础，同时也能推动控件定义中的标准和规范被落实，这反过来会提升被测试系统的可测试性和稳定性。

而对于一些小型的、快速迭代的短期项目，或者是对脚本灵活性要求极高的场景，描述性编程可能更适用。它上手快，写起来直接，不会因为对象库的维护而拖慢节奏。