自动化功能测试对软件设计的影响

　　功能测试的目的是为了模拟用户操作，从而验证系统能按照预想的方式运行，因此自动化测试的脚本无可避免地需要访问软件的用户界面。相信很多放弃使用自动化功能测试的团队对于自动化功能测试的态度和我刚刚接触自动化测试时一样，UI的易变性和测试脚本与UI的紧密耦合，加上维护测试脚本的团队（测试）和UI开发的团队（开发）往往不是同一个团队（或同一个人），导致了维护测试脚本的成本非常高。

　　但自动化功能测试的确能提高测试质量，并且减少人的重复劳动，这点收益足以能让我们想办法去解决上述的问题。和单元测试一样，从系统设计的时候就考虑到适应自动化测试，是成本最低的解决自动化测试问题的方法。如果对一个本来就对自动化测试不友好的系统重构，改变就可能涉及到系统的基础架构了，这个时候投入的人力物力就会几何级数的上升。

　　瘦客户端的设计

　　既然UI的频繁变更是影响自动化测试最重要的原因，那么我们是否可以跳过UI来进行自动化测试呢？我是一个很直观的想法，而且在某些情况下是可以实现的。MVC模式告诉我们，View层是不应该包含业务处理逻辑的，因此我们可以使用系统为UI层暴露的接口（公用API）对系统进行功能测试，从而避开UI层频繁变更的问题。

　　这种设计要求系统的UI层足够的简单，不能包含一丁点的业务逻辑，公用API的功能也需要足够的完备，能完成系统所有的业务逻辑处理。另外值得注意的一点，测试使用的API也必须是UI层调用的API，否则就没有办法很好地模拟真实的系统行为。我们已经对系统真实情况做了妥协，就不能无底线地一直妥协下去。

　　Web应用的情况可能相对好一点，由于Web架构的特性，我们只需要直接组装HTTP请求发送到Web服务器，便可以绕过UI进行功能测试。尽管这依然需要UI层足够的薄，但这已经是大部分Web开发者的共识了。

　　客户端驱动模式

　　正如上面说的，使用公用API测试是一种妥协的做法，对于那些有着极高用户体验要求的系统，就算是UI的显示逻辑，都可能是非常复杂的。这个时候，就算业务逻辑处理能被证明是没有bug的，但也不能说明系统的质量就足以达到交付的要求，毕竟用户是通过UI操作系统，而不是通过公用API与系统交互的。

　　在软件设计界有一句很经典的话：“大部分的软件耦合问题，都可以通过在中间加一层解决”。所谓的客户端驱动模式，也是通过在中间加一层来解决测试脚本与系统UI高耦合的问题的，我们姑且把中间的这层成为客户端驱动层。下图是使用客户端驱动模式设计的自动化测试的架构图：