Tags in a Keyword-Driven Test Automation Framework

我想以前应该有提到过我们公司有个自动化测试的框架软件,叫Robot,我是杭州的keyuser之一。这两天在给大家做一个Robot Advanced Training,项目上忙,所以我只承担了讲解tags这一部分的内容。讲解被我分为两部分,技术上很简单,就是通过“Force Tags”或者“Default Tags”,或者是case里使用“[Tags]”就可以达到目的。第二部分,我认为如何使用和规划以及合理地使用tags更加重要一些。


  • juha.html
  • sami.html
  • yi.html



Setting  Value  Value  Value  Value 
Force Tags  Juha 
Variable  Value  Value  Value  Value 
Test Case  Action  Argument  Argument  Argument 
Juha Rantanen  [Tags]  Rantanen 
Log  Juha Rantanen 
Juha Vehmas  Log  Juha Vehmas 
Juha Puonti  Log  Juha Puonti 
Keyword  Action  Argument  Argument  Argument 


Setting  Value  Value  Value  Value 
Force Tags  Sami 
Variable  Value  Value  Value  Value 
Test Case  Action  Argument  Argument  Argument 
Sami Pesonen  Log  Sami Pesonen 
Sami Lilja  Log  Sami Lilja 
Sami Tilander  Log  Sami Tilander 
Sami Rantanen  [Tags]  Rantanen 
Log  Sami Rantanen 
Keyword  Action  Argument  Argument  Argument 


Setting  Value  Value  Value  Value 
Force Tags  Yi 
Default Tags  Male 
Variable  Value  Value  Value  Value 
Test Case  Action  Argument  Argument  Argument 
Xu Yi  Log  Xu Yi 
Yao Yi  Log  Yao Yi 
Lv Yi  Log  Lv Yi 
Sun Yi [Tags] Female
Log Sun Yi
Keyword  Action  Argument  Argument  Argument 

很喜欢以前Elisabeth Hendrickson的培训里面提到的一点,自动化测试很重要的一点就是“变量”,凡是可能会变化或者不同的事物间有区别的属性都可以作为变量。而在此处,只要是有意义的属性,就可以用来作为tags。


同样,yi.html里面的人物可能还会具有其他的一些属性,我们猜测所有名“yi”的人可能大多数都是男性,但我们又不是很确定,所以不能设为无法被改写的“Force Tags”。此时,我们可以选择使用“Default Tags”,设置为“Male”,然后为“Sun Yi”这个特殊情况设置自己独特的tags —— “Female”。



Test Automation Frameworks


Test Automation can be measured by standards in different aspects. A feasible measurement for automated script can be divided to five levels :

  1. Linear
  2. Structured
  3. Modular
  4. Data-Driven
  5. Keyword-Driven

Test Automation Framework (TAF) is required in order to achieve later three automation levels. TAF provides a set of reusable supporting functions both for the framework and the Application Under Test (AUT). Supporting functions for framework are main application-independent, can be easily used in other products’ automation scripts/programs, e.g. string handling, file handling, variable handling and so on. The supporting functions for AUT should be framework-independent, hidden application specific implementaions to provide abstract level interfaces which the TAF recognizes as library routines or scripts.

These supporting functions can be provided in two formats : library routine or keywords. Library Routine – implementes those common-used basic functionalities which can be called by different automated testcases; Keywords – keywords are literal strings which can be recognized and processed by the TAF, its under-layer is the supporting functions for AUT or in other words component functions.

Reusability performs an important role in TAF, it’s better that we can reuse functions and even automated testcases. A concept for Keyword-Driven (so called Table-Driven sometimes) TAF abstracts automated testcases into three levels – Step Tables, Suite Tables, Cycle Tables.

  • Step Tables contain steps which uses a single keyword and arguments to execute certain task. One step table can represent one testcases, or a part of bigger testcases (represented by Suite Table or Cycle Table) which have same combination of operations.
  • Suite Tables mainly contain Step Tables as its operation steps, and also can be a part of bigger testcases (represented by Cycle Table).
  • Cycle table may contain Suite Tables or Step Tables as its operationi steps.

This kind of division is only one alternative, basically it’s a way that tables can be reused no matter it’s Step or Suite or Cycle table.

TAF can not be designed despite of other aspects in software development lifecycle, especially it should be considered together with testing strategy, there are some suggested essential guiding principles we should follow when developing our overall test strategy :

  • Test automation is a fulltime effort, not a sideline.
  • The test design and the test framework are totally separate entities.
  • The test framework should be application-independent.
  • The test framework must be easy to expand, maintain, and perpetuate.
  • The test strategy/design vocabulary should be framework independent.
  • The test strategy/design should remove most testers from the complexities of the test framework.

We can not consider TAF separately out of the Testing scope, like we can not consider Testing separately out of the Software Developing Lifecycle. Different TAFs represent different views on TA, have different abstract levels and corresponding responsibilities, also have different suitable circumstances.

Modular type TAF may require the engineer has comprehensive abilities, include framework development and supporting library function implement and testcase implementation ability, they should be familiar or master some programming languages, experienced in software development practices, and also should know the product features. In order to ensure that our automation build the code (automation code) right, and also build the right code.

While we use Data-Driven TAF, at least we can separately have two responsibles, one takes care of test datas to be verified, one takes the rest of above described responsibilities. But the goal does not change, we should provide reliable automated testcases.

Keyword-Driven have more detailed divisions between responsiblities. Somebody develop and maintain the framework itself, someone takes care of supporting functions or in other words component functions, also some engineer should implement material automated testcases, e.g. Step/Suite/Cycle Tables and so on.

Reference Articles :

More References Going-On :

Robot Framework中文站欢迎您!

建立Robot Framework中文站的目的在于为大家提供一个集中的资源和经验分享、交流讨论切磋的地点,希望能够汇聚国内的专家和用户!


– https://groups.google.com/forum/#!forum/robotframework-cn