自動化測試一直是敏捷開發(fā)和敏捷測試的重要基石，也是DevOps和CI/CD必不可少的組成部分。由于不同項目的測試需求不同，以及各種不同的限制，導(dǎo)致需要的自動化測試框架和工具也不同。比如很多金融和能源類的企業(yè)就傾向于選擇收費的企業(yè)級自動化測試框架或者工具，而新型互聯(lián)網(wǎng)企業(yè)則傾向于開源免費的自動化測試框架或者工具，或者基于它們進行二次定制開發(fā)，或者重新開發(fā)適合自己的自動化測試框架、工具或者平臺。

創(chuàng)新互聯(lián)專注于石林企業(yè)網(wǎng)站建設(shè),響應(yīng)式網(wǎng)站開發(fā),商城系統(tǒng)網(wǎng)站開發(fā)。石林網(wǎng)站建設(shè)公司,為石林等地區(qū)提供建站服務(wù)。全流程按需設(shè)計網(wǎng)站，專業(yè)設(shè)計，全程項目跟蹤，創(chuàng)新互聯(lián)專業(yè)和態(tài)度為您提供的服務(wù)

我之前寫過一篇文章——《自動化測試框架Cucumber和RobotFramework的實戰(zhàn)對比》僅僅針對兩種自動化測試框架進行了討論，卻引發(fā)了大量的討論，由此可見業(yè)界對于自動化測試框架存在很多不同的理解和爭議。在我看來，沒有任何一個自動化測試框架是銀彈，并且適合所有類型的測試，所以“如何選擇一款適合自己的測試框架”變成為了一個首要問題。我將自動化測試進行了簡單的分層，見下圖。

自動化測試架構(gòu)分層圖

其中測試庫和被測系統(tǒng)緊密相關(guān)，所以可以選擇的范圍不是很大，也很難進行統(tǒng)一分類。而測試框架與被測系統(tǒng)關(guān)系并不緊密，而是和技術(shù)棧，開發(fā)流程與組織管理等關(guān)系緊密相關(guān)，并且種類繁多，可選擇范圍很多，所以選擇也相對比較困難。

因此對測試框架進行統(tǒng)一分類可以更好的幫助團隊選擇適合自己的測試框架，從而更好進行自動化測試開發(fā)。

本文根據(jù)自動化測試用例的呈現(xiàn)方式和管理方式將其分為四種類型：函數(shù)行，單領(lǐng)域語言型，多領(lǐng)域語言型以及富文檔型。

四個類型：

1. 函數(shù)型

函數(shù)型自動化測試框架是第一代自動化測試框架，也是最輕量的測試框架。它只是通過函數(shù)的方式來定義測試用例，并且通過管理這些函數(shù)的調(diào)用來管理測試用例，從而快速的實現(xiàn)自動化測試，比如xUnit等。

例子JUnit：

 
 
 
 

  
  
  
  
public class DemoTest {
  
  
  
  
  @Test
  
  
  
  
  public void testAddWithTwoNumbers() {
  
  
  
  
    //測試實現(xiàn)代碼
  
  
  
  
  }
  
  
  
  
}
 
 
 
 

函數(shù)型自動化測試框架由來已久，開發(fā)快速，運行穩(wěn)定。雖然它相對簡單與輕量，但是也存在缺點：很難通過函數(shù)名來描述測試用例的內(nèi)容和細(xì)節(jié)，并且不方便對測試用例進行單獨管理，因為測試用例的描述函數(shù)名和測試實現(xiàn)通常都在一起。

2. 單領(lǐng)域語言型

由于函數(shù)型的自動化測試框架很難通過函數(shù)名去描述一個測試用例的內(nèi)容。為了更清晰和容易的描述測試用例，就出現(xiàn)了單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() {
  
  
  
  
    //測試實現(xiàn)代碼
  
  
  
  
  });
  
  
  
  
});
 
 
 
 

單領(lǐng)域語言型可以通過自然語言或者關(guān)鍵字形式的領(lǐng)域語言來描述測試用例，從而以一種更加易讀和理解的方式來描述測試用例。但是每個測試用例只用一句DSL語言，并不能很好的描述測試用例和被測場景，不易形成一套好的活文檔。由于它的測試用例與測試實現(xiàn)通常也是在一起的，所以也不方便對測試用例進行單獨管理。

3. 多領(lǐng)域語言型

由于單DSL型框架中對于每個測試用例只能使用一句DSL來描述，并不能很好的體現(xiàn)測試用例場景，比如測試的前提，行為和結(jié)果等。為了能在測試用例層更為清晰的描述測試用例的行為和測試數(shù)據(jù)等型信息，出現(xiàn)了多領(lǐng)域語言型的自動化測試框架，比如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   |
 
 
 
 

測試實現(xiàn)代碼

 
 
 
 

  
  
  
  
Given(/^there are two numbers$/) do
  
  
  
  
  //測試實現(xiàn)代碼
  
  
  
  
end
  
  
  
  
When(/^add two numbers together$/) do
  
  
  
  
  //測試實現(xiàn)代碼
  
  
  
  
end
  
  
  
  
Then(/^should get sum of two numbers$/) do
  
  
  
  
  //測試實現(xiàn)代碼
  
  
  
  
end
 
 
 
 

多領(lǐng)域語言型的框架可以通過多句或者多個關(guān)鍵字的領(lǐng)域語言來描述一個特定的場景，使得測試用例更容易閱讀和理解，并且比較容易做成一套活文檔系統(tǒng)。由于測試用例和測試實現(xiàn)是分離的，還可以對測試用例進行獨立管理。

但是缺點也是比較明顯的，開發(fā)、管理和維護成本較高，并且如果沒有業(yè)務(wù)分析或者產(chǎn)品人員等非技術(shù)人員參與協(xié)作開發(fā)，那么它的投入產(chǎn)出比就很低，大家往往會認(rèn)為它是事倍功半。

4. 富文檔型

對于一些場景十分復(fù)雜，需要通過富文檔的方式來描述軟件測試場景，甚至需要一些業(yè)務(wù)流程圖或者系統(tǒng)用戶界面等，比如Concordion，F(xiàn)itnesse，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