自动化测试一直是敏捷开发和敏捷测试的重要基石，也是DevOps和CI/CD必不可少的组成部分。由于不同项目的测试需求不同，以及各种不同的限制，导致需要的自动化测试框架和工具也不同。比如很多金融和能源类的企业就倾向于选择收费的企业级自动化测试框架或者工具，而新型互联网企业则倾向于开源免费的自动化测试框架或者工具，或者基于它们进行二次定制开发，或者重新开发适合自己的自动化测试框架、工具或者平台。

创新互联专注于石林企业网站建设,响应式网站开发,商城系统网站开发。石林网站建设公司,为石林等地区提供建站服务。全流程按需设计网站，专业设计，全程项目跟踪，创新互联专业和态度为您提供的服务

我之前写过一篇文章——《自动化测试框架Cucumber和RobotFramework的实战对比》仅仅针对两种自动化测试框架进行了讨论，却引发了大量的讨论，由此可见业界对于自动化测试框架存在很多不同的理解和争议。在我看来，没有任何一个自动化测试框架是银弹，并且适合所有类型的测试，所以“如何选择一款适合自己的测试框架”变成为了一个首要问题。我将自动化测试进行了简单的分层，见下图。

自动化测试架构分层图

其中测试库和被测系统紧密相关，所以可以选择的范围不是很大，也很难进行统一分类。而测试框架与被测系统关系并不紧密，而是和技术栈，开发流程与组织管理等关系紧密相关，并且种类繁多，可选择范围很多，所以选择也相对比较困难。

因此对测试框架进行统一分类可以更好的帮助团队选择适合自己的测试框架，从而更好进行自动化测试开发。

本文根据自动化测试用例的呈现方式和管理方式将其分为四种类型：函数行，单领域语言型，多领域语言型以及富文档型。

四个类型：

1. 函数型

函数型自动化测试框架是第一代自动化测试框架，也是最轻量的测试框架。它只是通过函数的方式来定义测试用例，并且通过管理这些函数的调用来管理测试用例，从而快速的实现自动化测试，比如xUnit等。

例子JUnit：

 
 
 
 

  
  
  
  
public class DemoTest {
  
  
  
  
  @Test
  
  
  
  
  public void testAddWithTwoNumbers() {
  
  
  
  
    //测试实现代码
  
  
  
  
  }
  
  
  
  
}
 
 
 
 

函数型自动化测试框架由来已久，开发快速，运行稳定。虽然它相对简单与轻量，但是也存在缺点：很难通过函数名来描述测试用例的内容和细节，并且不方便对测试用例进行单独管理，因为测试用例的描述函数名和测试实现通常都在一起。

2. 单领域语言型

由于函数型的自动化测试框架很难通过函数名去描述一个测试用例的内容。为了更清晰和容易的描述测试用例，就出现了单DSL型的自动化测试框架，比如RSpec，Jasmine，Mocha，RF等。

例子Jasmine：

 
 
 
 

  
  
  
  
describe("The add function of the calculator can add two numbers", function() {
  
  
  
  
  it("should get the sum after add two numbers", function() {
  
  
  
  
    //测试实现代码
  
  
  
  
  });
  
  
  
  
});
 
 
 
 

单领域语言型可以通过自然语言或者关键字形式的领域语言来描述测试用例，从而以一种更加易读和理解的方式来描述测试用例。但是每个测试用例只用一句DSL语言，并不能很好的描述测试用例和被测场景，不易形成一套好的活文档。由于它的测试用例与测试实现通常也是在一起的，所以也不方便对测试用例进行单独管理。

3. 多领域语言型

由于单DSL型框架中对于每个测试用例只能使用一句DSL来描述，并不能很好的体现测试用例场景，比如测试的前提，行为和结果等。为了能在测试用例层更为清晰的描述测试用例的行为和测试数据等型信息，出现了多领域语言型的自动化测试框架，比如Cucumber，JBehave，SpecFlow，RF等。

例子Cucumber：

测试用例代码

 
 
 
 

  
  
  
  
Feature: The add function of the calculator can add two numbers
  
  
  
  
  Scenario: add two numbers
  
  
  
  
    Given there are two numbers  and 
  
  
  
  
    When add these two numbers 
  
  
  
  
    Then should get  of two numbers
  
  
  
  
  Examples:
  
  
  
  
    | Number 1 | Number 2 | Sum |
  
  
  
  
    | 1        | 2        | 3   |
  
  
  
  
    | -1       | 2        | 1   |
 
 
 
 

测试实现代码

 
 
 
 

  
  
  
  
Given(/^there are two numbers$/) do
  
  
  
  
  //测试实现代码
  
  
  
  
end
  
  
  
  
When(/^add two numbers together$/) do
  
  
  
  
  //测试实现代码
  
  
  
  
end
  
  
  
  
Then(/^should get sum of two numbers$/) do
  
  
  
  
  //测试实现代码
  
  
  
  
end
 
 
 
 

多领域语言型的框架可以通过多句或者多个关键字的领域语言来描述一个特定的场景，使得测试用例更容易阅读和理解，并且比较容易做成一套活文档系统。由于测试用例和测试实现是分离的，还可以对测试用例进行独立管理。

但是缺点也是比较明显的，开发、管理和维护成本较高，并且如果没有业务分析或者产品人员等非技术人员参与协作开发，那么它的投入产出比就很低，大家往往会认为它是事倍功半。

4. 富文档型

对于一些场景十分复杂，需要通过富文档的方式来描述软件测试场景，甚至需要一些业务流程图或者系统用户界面等，比如Concordion，Fitnesse，Guage等。

例子 Condordion：

测试用例代码，其中包含部分测试代码，比如断言等，其中concordion.css使用的是官方样例代码

 
 
 
 

  
  
  
  

  
  
  
  

  
  
  
  
  
  
  
  
  
    
Test Demo
  
  
  
  
    
 Test the add function of  the calculator can add two numbers 
  
  
  
  
    
 The Caculator:
  
  
  
  
    
  
  
  
  
  
    
  
  
  
  
      
Examples
  
  
  
  
      
        
          
          
          
        
        
          1
          2
          3
        
        
          -1
          2
          1
        
      

  
  
  
  

  
  
  
  
Number 1
  
  
  
  
Number 2
  
  
  
  
Sum