前言
有人喜歡創造世界，他們做了開發者；有的人喜歡開發者，他們做了測試員。什麼是軟件測試？軟件測試就是一場本該在用戶面前發生的災難提前在自己面前發生了，這會讓他們生出一種救世主的感覺，拯救了用戶，也就拯救者這個軟件，避免了他們被卸載的命運。
自動化測試一直是敏捷開發和敏捷測試的重要基石，也是DevOps和CI/CD必不可少的組成部分。由於不同項目的測試需求不同，以及各種不同的限制，導致需要的自動化測試框架和工具也不同。比如很多金融和能源類的企業就傾向於選擇收費的企業級自動化測試框架或者工具，而新型互聯網企業則傾向於開源免費的自動化測試框架或者工具，或者基於它們進行二次定製開發，或者重新開發適合自己的自動化測試框架、工具或者平臺。
之前一篇文章——《自動化測試框架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），就還需要對其進行深入比較，從而最終選擇自己適合的自動化測試框架。