对Cucumber的一些想法

今天看了一下CucumberCuke4Nuke。前者是ruby社区流行的BDD框架,它使用一种叫做Gherkin的语言来描述story和scenario,然后使用ruby来实现这些scenario。而Cuke4Nuke则可以让你用.NET上的语言(比如C#)来编写scenario的实现部分。相比于在IronRuby下直接跑cucumber,你可以用熟悉的语言(C#)来写测试,也省去了在IronRuby中调用C#代码引入的额外复杂性。

抛开BDD的本来意图,这样将scenario实现为自动化测试的方式至少解决了几个问题:

1. 测试用例的可读性

目前,我在项目中使用xunit.net + selenium来做website的functional test,即使使用page object pattern对selenium进行包装,仍然无法保证test case的可读性。因为代码包含了太多的技术细节,使得原本test case想要表达的意图淹没在代码之中。有两个方法可以部分解决这个问题,一个就是写注释,另一个就是用函数包装,但是这两种办法都是指标不止本。

而使用cucumber意味着你可以用业务领域的语言来表述test case或者叫scenario,这保证了每个人阅读的时候有一致的理解,维护的时候比较方便。

 

2. 区分自动和手动执行的测试用例

如果没有自动化测试,QA需要花费大量的时间做regression测试,随着功能越来越多,进行一次全面测试的时间也就越长。但是即使有了自动化测试,仍然很难保证所有的测试都能够被自动化,有些是因为自动化的代价太大,有些是因为我们还没有找到行之有效的测试手段。 因此QA需要维护一个测试用例文档,并且需要跟踪哪些测试用例已经被自动化了,哪些没有。这样在减少QA工作量的同时,不会有被遗漏的测试用例。不过在实际项目中,这样手工去维护一个excel之类的列表并不是一件容易的事,不仅需要花费大量的精力,还很容易出现错误。

使用cucumber的话,test case可以始终保持一种形态,就是scenario,而不是像现在这样分离为excel中的test case,以及代码中的test case。当scenario可以被执行的时候,哪些不能被执行也就一目了然了。


3. QA和Dev更好的合作

QA在Dev做story之前先把scenario写出来,Dev在做完stroy时,要保证测试能够通过。对于QA来说,可以用业务领域的语言来描述,简单而且直观。甚至也可以早早的就把scenario写出来,等到需要实现story的时候,只需要简单的将scenario移动到一个特定的地方,比如一个文件夹。那么这个scenario就将被包含在下一次的自动化测试中,可以保证Dev确实实现了这个测试。

 

以上只是初步想法,具体效果还有待真实项目的检验。

 

posted @ 2010-03-05 01:30 Nick Wang (懒人王) 阅读(...) 评论(...) 编辑 收藏