总结2：适应变化和可测试性

适应变化而不是控制变化

相对于单元测试，接口测试等自动化测试，对基于GUI的测试面对一个很大的问题是GUI是容易改变的。

对于这种情况，QTP给出了SmartIdentification，试图让工具更智能，实践表明大多数时候它只是在帮倒忙。

有些公司出台了一些Policy，限制Developer对GUI元素识别标识符（比如ID）的修改。比如我现在的公司就提出过修改GUI的一些policy，结果是不了了之。因为很多Developer根本就记不住那些约束，或者不愿意被约束。另外，有些时候，一些GUI元素是由工具生成的，其ID变化不在Developer的控制之中。

所以，在设计GUI元素库的时候，如何应对GUI的变化是需要重点考虑的。我的答案是，不去试图控制变化，而是提高自己适应变化的能力。这就是“所见即所得”识别方式背后的动因。相对于“对象库”方式，“所见即所得”不仅仅带来了快速定位GUI元素的能力，它还让修改变得很简单。当GUI元素修改了，如果你只需要花几分钟就能修改好的你的代码，那么你也不会太在意这种修改。

可测试性与代码重用率

可测试性与代码重用率看似两个不相干的东西，但我发现代码重用率高的软件相对有更好的可测试性。简单来说高质量的软件相对具有更好的可测试性，及时developer在开发的时候并没有专门去思考“可测试性”这回事。

有一本叫“重构”(refactory)的书说，“重复的代码”是代码臭味的一种。当代码具有臭味时，你就需要去重构它。通过重构去掉“重复的代码”其实就是在提高代码的重用率。代码的重用率一定程度上也能反映出代码的整体质量。简单来说，通过copy-paste构建的程序肯定比通过抽象构建的程序代码质量差，因为它导致大量的重复代码。

为什么代码重用率高的程序一定程度上也是可测试性高的程序？GUI元素库对于元素定位的每一种基本方法（包括组合元素定位）是针对某一类型的GUI元素的抽象。一个程序，如果它的GUI部分的代码重用率高，那么就有更多的GUI元素其定位标识是有规律的。那么同样数量的定位方法就能覆盖更多的GUI元素。一个程序如果是通过copy-paste建立起来的，因为paste之后，程序员是可以任意修改代码的，这种修改可能破坏了原有的GUI元素定位规律。所以结果就是，不得不写更多GUI元素定位基本方法（或者组合元素）来覆盖所有的情况。

所以，我发现，使用这个GUI元素库，越是高质量的软件，其测试套件开发起来越轻松。