#自動化測試框架的4種有效分類與使用選擇

時間 2019-11-10

原文原文鏈接

前言
有人喜歡創造世界，他們作了開發者；有的人喜歡開發者，他們作了測試員。什麼是軟件測試？軟件測試就是一場本該在用戶面前發生的災難提早在本身面前發生了，這會讓他們生出一種救世主的感受，拯救了用戶，也就拯救者這個軟件，避免了他們被卸載的命運。css

自動化測試一直是敏捷開發和敏捷測試的重要基石，也是DevOps和CI/CD必不可少的組成部分。因爲不一樣項目的測試需求不一樣，以及各類不一樣的限制，致使須要的自動化測試框架和工具也不一樣。好比不少金融和能源類的企業就傾向於選擇收費的企業級自動化測試框架或者工具，而新型互聯網企業則傾向於開源免費的自動化測試框架或者工具，或者基於它們進行二次定製開發，或者從新開發適合本身的自動化測試框架、工具或者平臺。html

以前一篇文章——《自動化測試框架Cucumber和RobotFramework的實戰對比》僅僅針對兩種自動化測試框架進行了討論，卻引起了大量的討論，因而可知業界對於自動化測試框架存在不少不一樣的理解和爭議。在我看來，沒有任何一個自動化測試框架是銀彈，而且適合全部類型的測試，因此「如何選擇一款適合本身的測試框架」變成爲了一個首要問題。我將自動化測試進行了簡單的分層，見下圖。面試

自動化測試架構分層圖編程

其中測試庫和被測系統緊密相關，因此能夠選擇的範圍不是很大，也很難進行統一分類。而測試框架與被測系統關係並不緊密，而是和技術棧，開發流程與組織管理等關係緊密相關，而且種類繁多，可選擇範圍不少，因此選擇也相對比較困難。架構

所以對測試框架進行統一分類能夠更好的幫助團隊選擇適合本身的測試框架，從而更好進行自動化測試開發。框架

本文根據自動化測試用例的呈現方式和管理方式將其分爲四種類型：函數型，單領域語言型，多領域語言型以及富文檔型。編程語言

四個類型：

函數型

函數型自動化測試框架是第一代自動化測試框架，也是最輕量的測試框架。它只是經過函數的方式來定義測試用例，而且經過管理這些函數的調用來管理測試用例，從而快速的實現自動化測試，好比xUnit等。函數

例子JUnit：工具

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

函數型自動化測試框架由來已久，開發快速，運行穩定。雖然它相對簡單與輕量，可是也存在缺點：很難經過函數名來描述測試用例的內容和細節，而且不方便對測試用例進行單獨管理，由於測試用例的描述函數名和測試實現一般都在一塊兒。性能

單領域語言型

因爲函數型的自動化測試框架很難經過函數名去描述一個測試用例的內容。爲了更清晰和容易的描述測試用例，就出現了單DSL型的自動化測試框架，好比RSpec，Jasmine，Mocha等。

例子Jasmine：

describe("The add function of the calculator can add two numbers", function() {
  it("should get the sum after add two numbers", function() {
    //測試實現代碼
  });
});

單領域語言型能夠經過天然語言或者關鍵字形式的領域語言來描述測試用例，從而以一種更加易讀和理解的方式來描述測試用例。可是每一個測試用例只用一句DSL語言，並不能很好的描述測試用例和被測場景，不易造成一套好的活文檔。因爲它的測試用例與測試實現一般也是在一塊兒的，因此也不方便對測試用例進行單獨管理。

若是對軟件測試、接口測試、自動化測試、性能測試、LR腳本開發、面試經驗交流。感興趣能夠175317069，羣內會有不按期的發放免費的資料連接，這些資料都是從各個技術網站蒐集、整理出來的，若是你有好的學習資料能夠私聊發我，我會註明出處以後分享給你們。

多領域語言型

因爲單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 <Number 1> and <Number 2>
    When add these two numbers 
    Then should get <Sum> 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

多領域語言型的框架能夠經過多句或者多個關鍵字的領域語言來描述一個特定的場景，使得測試用例更容易閱讀和理解，而且比較容易作成一套活文檔系統。因爲測試用例和測試實現是分離的，還能夠對測試用例進行獨立管理。

可是缺點也是比較明顯的，開發、管理和維護成本較高，而且若是沒有業務分析或者產品人員等非技術人員參與協做開發，那麼它的投入產出比就很低，你們每每會認爲它是事倍功半。

富文檔型

對於一些場景十分複雜，須要經過富文檔的方式來描述軟件測試場景，甚至須要一些業務流程圖或者系統用戶界面等，好比Concordion，Fitnesse，Guage等。

例子 Condordion：

測試用例代碼，其中包含部分測試代碼，好比斷言等，其中concordion.css使用的是官方樣例代碼

<html xmlns:concordion="http://www.concordion.org/2007/concordion">
<link href="concordion.css" rel="stylesheet" type="text/css" />
  <body>
    <h1>Test Demo</h1>
    <p> Test the add function of  the calculator can add two numbers </p>
    <p> The Caculator:</p>
    <div> <img src="./Calculator.png"/> </div>
    <div concordion:example="add">
      <h3>Examples</h3>
      <table>
        <tr>
          <th>Number 1</th>
          <th>Number 2</th>
          <th>Sum</th>
        </tr>
        <tr concordion:execute="#sum = addWithTwoNumbers(#number1,number2)">
          <td concordion:set="#number1">1</td>
          <td concordion:set="#number2">2</td>
          <td concordion:assert-equals="#sum">3</td>
        </tr>
        <tr concordion:execute="#sum = addWithTwoNumbers(#number1,number2)">
          <td concordion:set="#number1">-1</td>
          <td concordion:set="#number2">2</td>
          <td concordion:assert-equals="#sum">1</td>
        </tr>
      </table>
    </div>
  </body>
</html>

測試用例呈現文檔：

測試用例中的函數實現代碼：

@RunWith(ConcordionRunner.class)
public class CaculatorFixture {
  public String addWithTwoNumbers(String number1, String number2) {
    //測試實現代碼
  }
}

（注：雖說最新版的Concordion已經支持MarkDown了，從而下降了一些開發成本，可是其對MarkDown的特性支持有待增長。因此若是須要更爲豐富的文檔形式，仍然須要使用HTML來開發測試用例。）

富文檔型的框架比多領域語言型擁有更爲豐富的文檔，更容易閱讀和理解，從而能作成說明書式的活文檔，使得全部角色的人都能審閱。而且其測試用例和測試實現也是分離的。可是當前業界存在的富文檔型測試框架的易用性和協做性都還不是很好，致使其開發，管理和維護成本相比前三種是最高的。而且當沒有其它各個角色來協同開發，管理和維護時，其投入產出比也是最低的，因此它在行業中的使用率也是很低的。這類測試框架在易用性和協做性方面還有很大的發展空間，而且也是自動化測試框架和活文檔系統的一個重要的發展方向。

總結與選擇

自動化測試的代碼實現層通常是與編程語言強相關的，而主流的編程語言比較少，因此選擇比較容易：通常建議選擇團隊大部分紅員都熟悉的編程語言(這樣能夠促使整個團隊來對自動化測試進行開發和維護)或者是有特定測試庫的編程語言（好比須要使用Scapy時就只能選擇基於Python的自動化測試框架）。當確認自動化測試開發語言後，真正的問題是如何在如此衆多的自動化測試框架裏面選擇合適本身的自動化測試框架。選擇方法能夠根據以上四種類型來進行選擇，從而縮小選擇範圍。

若是團隊只是須要快速實現自動化測試，沒有知識的傳遞問題，也不須要與業務分析和產品經歷等非技術人員進行協做開發時，能夠選擇函數型自動化測試框架。
若是爲了解決知識傳遞問題，讓測試用例更可讀和易懂，而且沒有非技術人員參與協做開發，這時能夠選擇單領域語言型。
若是爲了進一步解決和非技術人員協做開發的問題，而且想有一套簡版的活文檔，能夠選擇多領域語言型自動化測試框架。
若是爲了讓測試用例擁有更爲豐富的表現力，好比包含一個流程圖來講明被測場景的流程，或者使用不一樣的格式或者表格來描述用例的細節，以及擁有一套豐富的活文檔，這時就可使用富文檔型。不過因爲當前的富文檔型測試框架在編寫用例時須要必定的技能，因此非技術人員很難直接參與協做編寫。而且其編寫以及維護成本更高，可能使得自動化測試開發人員使用的意願也不是很高。參考自動化測試工具選項金字塔：

當確認了測試框架類型以後，好比只有一個可選項（Java->函數型->JUnit），那麼就直接使用了，可是若是存在多選項（JavaScript-> 單領域語言型->Jasmine vs Mocha），就還須要對其進行深刻比較，從而最終選擇本身適合的自動化測試框架。