Category Archives: Testing

Gherkin的Python版本的BDD引擎

Gherkin是一个Domain Specific Language, 它以一种跟自然语言类似的方式来描述业务,因此可以作为BDD的测试用例的描述语言。Gherkin来源于 Cucumber, Cucumber是基于 ruby实现的一个GEM。

其他语言也有实现了这个Gherkin的引擎,这里列出了一些Python的实现:

Behave提供了一个这些引擎的比较:

http://packages.python.org/behave/comparison.html

另外,如果希望在sublime里实现Gherkin的语法高亮,可以安装cucumber插件.

https://github.com/drewda/cucumber-sublime2-bundle

https://github.com/waynemoore/sublime-gherkin-formatter

BDD引擎的比较

BDD的开发模式跟TDD类似,但是测试的层次较高,不在unit level, 而在story level,端到端的测试。BDD的实现,大多基于Gherkin的语法(语法来自于Cucumber), 但是还有其他的框架也是实现了这个语法。下面简单介绍了Gherkin和各种语言的BDD引擎。

Behavior Driven Development (which we will now refer to as “BDD”) follows on from the ideas and principles introduced in Test Driven Development. The key points of writing tests before code really apply to BDD as well. The idea is to not only test your code at the granular level with unit tests, but also test your application end to end, using acceptance tests.

Gherkin Syntax

Acceptance tests usually make use of the Gherkin Syntax, introduced by the Cucumber Framework, written for Ruby. The syntax is quite easy to understand, and, in the Freshen Python package, makes use of the following eight keywords to define your features and tests:

  • Given
  • When
  • Then
  • And
  • Feature:
  • Background:
  • Scenario:
  • Scenario Outline:

Below, you can review these keywords in action, and how they can be used to structure your acceptance tests.

BDD Engine

Cucumber is not the only engine supporting natural language instructions. It’s just one implementation of natural language instructions interpreter. The actual language to write tests with is called Gherkin. And it has different implementations adopted to different programming language. Thus we have:

详细比较参见http://mkolisnyk.blogspot.com/2012/06/gherkin-bdd-engines-comparison.html

基于图像识别的自动化测试框架

这里列出了一些自动化框架:

Project Sikuli: http://groups.csail.mit.edu/uid/sikuli/

RoutineBot: http://www.routinebot.com/

Ranorex: http://www.ranorex.com/

T-Plan Robot: http://www.vncrobot.com/

EggPlant: http://www.testplant.com/

iMacros: http://www.iopus.com/iMacros/irp/

下面的两个link有一些简单的比较分析:

http://www.testandtry.com/2010/02/01/5-great-automation-tools-based-on-image-recognition/

http://testwarriors.blogspot.com/2012/04/comparison-report-sikuli-vs-eggplant.html

 

 

 

基于图像技术的自动化测试工具SIKULI

http://sikuli.org/

挺好玩的一个项目

UI测试的一些讨论

这里有一片文章,叫做:

How to implement UI testing without shooting yourself in the foot

http://gojko.net/2010/04/13/how-to-implement-ui-testing-without-shooting-yourself-in-the-foot-2/

作者是明显不认同做UI automation testing的,但是很多人都愿意这么做,所以作者也给出了几条做UI automation testing的原则。

Things to remember

To avoid shooting yourself in the foot with UI tests, remember these things:

* Think about UI test automation at three levels: business rules, user interface workflow and technical activity
* Even if the user interface workflow automation gets implemented in plain text, make sure to put one level of abstraction above it and describe business rules directly. Don’t describe rules as workflows (unless they genuinely deal with workflow decisions – and even then it’s often good to describe individual decisions as state machines).
* Even if the user interface workflow automation gets implemented in code, make sure to separate technical activities required to fulfil a step into a separate layer. Reuse these step definitions to get stability and easy maintenance later.
* Beware of programming in plain text.

CI server的选择

持续集成(continuous integration)服务器的选择:

CruiseControl (http://cruisecontrol.sourceforge.net/
Hudson (https://hudson.dev.java.net/
LuntBuild (http://luntbuild.javaforge.com/
TeamCity (http://www.jetbrains.com/teamcity/
AntHill Pro (http://www.anthillpro.com/
Bamboo (http://www.atlassian.com/software/bamboo/
QuickBuild (http://www.pmease.com/)