自动化功能测试友好的设计
作者:网络转载 发布时间:[ 2013/7/24 15:06:14 ] 推荐标签:
自动化功能测试对软件设计的影响
功能测试的目的是为了模拟用户操作,从而验证系统能按照预想的方式运行,因此自动化测试的脚本无可避免地需要访问软件的用户界面。相信很多放弃使用自动化功能测试的团队对于自动化功能测试的态度和我刚刚接触自动化测试时一样,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高耦合的问题的,我们姑且把中间的这层成为客户端驱动层。下图是使用客户端驱动模式设计的自动化测试的架构图:
相关推荐
更新发布
功能测试和接口测试的区别
2023/3/23 14:23:39如何写好测试用例文档
2023/3/22 16:17:39常用的选择回归测试的方式有哪些?
2022/6/14 16:14:27测试流程中需要重点把关几个过程?
2021/10/18 15:37:44性能测试的七种方法
2021/9/17 15:19:29全链路压测优化思路
2021/9/14 15:42:25性能测试流程浅谈
2021/5/28 17:25:47常见的APP性能测试指标
2021/5/8 17:01:11