为什么要强调Independent Test Case?(更新)

在测试案例编写模式,有关案例组织有两种对立的模式: Chained Test CasesIndependent Test Case,Chained Test Case是指前一个测试案例是执行成功是后一个测试案例执行的前置条件,Independent Test Case是指案例之前不应该有上述依赖关系,在这里我强烈推荐Independent Test Case,下面我解释一下原因?

 

让我们看下面的例子,这里ChainedTestCase2会依赖ChainedTestCase1的执行成功

  为什么要强调Independent Test Case?(更新)_第1张图片                           

 

那么按照Independent Test Case模式,测试案例应该初步改写成如下:

 为什么要强调Independent Test Case?(更新)_第2张图片

 

这样改写之后,我听到最多的抱怨有两个:

l  可读性变差,一个案例变得很长;

l  易用性变差,因为一个测试日志会变得很长,不利于问题定位

 

对第一个可读性问题,可以通过再引入一层(测试流程层)分装来解决,案例会改写成类似这样(加注,根据@横刀天笑兄弟的反馈,说明一下,这个测试流程层应该怎么来实现,下面例子只是给出一个示意,后续可以进一步抽象重构,甚至形成一层DSL,这个就不在这篇博客里面讨论了)

 为什么要强调Independent Test Case?(更新)_第3张图片

  

进过上述重构,可读性的问题应该可以得到解决了,但是,日志长的问题并没有得到解决。其实这个问题应该由测试框架来解决,例如,在RobotFramework框架里面,它是使用可以多级级联的HTML格式,可以很好地解决日志定位问题,如下图所示

 为什么要强调Independent Test Case?(更新)_第4张图片

其实目前我看到的很多基于JavaSelenium测试框架在日志方面都比较弱,这个未来另文叙述吧。

 

现在我们来看一下,重构之后的一个独立测试案例相对于两个强依赖测试案例,有什么优势呢?我们可以用MeReST原则来分析一下:

l  对于必备指标,敏感性和可靠性而言,这两种写法没有区别;

l  从高效性来讲,一个独立案例会更胜一筹,但是,在某些企业或团队,对不懂行的领导而言,测试案例多一些也会是一种政治需要,这就另当别论了;另外,从执行效率而言,一个独立案例出错后,马上就会停止,而两个强依赖案例,在前一个案例失败后,还需要想办法不让后一个案例执行,增加额外复杂性;

l  对于可读性而言,增加了测试流程层的一个独立案例还是会更好一些;

l  对于易用性来讲,如果所有案例都是独立案例,一看测试报告就知道有没有案例失败,选择失败案例,马上就可以重跑;而对于强依赖测试而言,就还需要再分析一下,哪些案例是真的失败了,哪些案例是由于前面案例执行失败造成的;

l  最后对于可维护性而言,独立案例在重构、扩展、新增时,不需要考虑案例之间的关联性,更有优势。

 

Chained Test Case的最大问题在于它违反了代码的高内聚,低耦合原则,在原本不应该出现耦合的概念(测试案例,方法)人为又增加了耦合,看起来短期省了力气,但是长期会付出更大的成本。

 

综上所述,当两个所谓的案例之前存在强依赖关系时,还是把它们合并到一个案例里面为好,以保持案例独立性。

 

虽然,强依赖案例还是独立案例,这看起来是个小问题,但是,千里大堤毁于蚁穴,如果不坚守一些原则,自动化测试案例的大厦就会逐步崩溃倒塌了。下一个值得讨论的问题是当一个独立案例流程长时,是否值得把它分成两个独立的案例呢,这是一个案例粒度问题,我将在下一篇博客里面来讨论。

你可能感兴趣的:(重构,测试,敏捷)