基于selenium测试框架设计之MVC模式 2

上一篇 / 下一篇  2013-06-24 18:03:00 / 个人分类:自动化

测试控制(control)从大的来讲就是测试用例结构流程的控制,从小的来讲就是如何驱动测试的展开
selenium测试通常和单元测试框架整合,比如在java上就是junit或者testng。单元测试框架的作用就是控制测试执行的策略。testng相较junit提供更多的控制方式,比如组策略,类控制等,这种灵活的机制很大程度地扩展了我们设计执行框架的空间。
有时我们要执行所有回归测试用例,但更多的时候执行部分。最简单的办法是把要测试的类列在testng配置文件里,然后按类执行。有时候我们需要的测试用例混杂在不同的类里边,那组策略就比较合适了。
在设计测试结构时有个重要的因素时测试的依赖性。适度的依赖性可以提升测试效率,但是牺牲测试独立性。比如登陆和浏览是两个用例。登陆是浏览的前提用例。我们来看一下两种不同的设计方式
一:
测试准备-》登陆-》浏览-》测试关闭

二:
测试准备-》登陆-》测试关闭-》测试准备-》登陆-》浏览-》测试关闭

方式一的好处是减少了测试时间,方式二的好处两个用例可以独立执行,但是重复代码多,设计要求高。

测试准备-》登陆-》测试关闭
测试准备-》登陆-》浏览-》测试关闭
当测试用例完全独立的时候我们可以采用并发的方式缩短测试时间。但是实际情况中这种依赖性很难完全消除,还有些约束条件要考虑,比如A先完成和B先完成可能将导致不同的结果。所以在设计的时候就要充分考虑这些情况以保证选择性测试可以实现。
单个测试用例独立性集中体现在手工测试和自动测试的集成。有些集成管理工具比如QC允许测试人员启动单个自动测试脚本并传回结果。在testng框架下充分利用不同层级的setup和teardown可以很大程度提升测试的独立性。

下面谈一下测试的驱动模式。常见的是关键字驱动和数据驱动。还有事件驱动,即测试的顺序由事件的发生顺序而确定,而行为驱动可以看作是事件驱动的一种特例。基于selenium的框架用于web测试,因此关键字驱动是最直观也是最重要的驱动方式。

设计测试过程的时候最重要的原则是可读性。个人一直认为测试代码的设计和应用程序代码的设计原则是不同的。应用程序注重的外部行为,即人们只关心这个接口能做些什么,确不关心内部到底怎么做的。测试代码则不同,读代码的人非常需要了解内部细节和步骤是的实现。所以测试脚本更具有面向过程而不是面向对象的本质(所以我们称之为脚本)。人对过程的理解相当程度是线性的,所以要尽量减少代码的分支和跳转。重复代码在一定程度上是可接受的,条件是增加可读性。方法的封装要适度。比较理想的是代码语句和手工测试用例步骤相呼应。尽管精巧的命名可以大大提升可读性,测试代码注释行的量仍然应当比应用程序代码多得多。

TAG: Selenium selenium 测试 控制 自动化

 

评分:0

我来说两句

Open Toolbar