自動(dòng)化測(cè)試框架分類與思考
自動(dòng)化測(cè)試一直是敏捷開發(fā)和敏捷測(cè)試的重要基石，也是DevOps和CI/CD必不可少的組成部分。由于不同項(xiàng)目的測(cè)試需求不同，以及各種不同的限制，導(dǎo)致需要的自動(dòng)化測(cè)試框架和工具也不同。比如很多金融和能源類的企業(yè)就傾向于選擇收費(fèi)的企業(yè)級(jí)自動(dòng)化測(cè)試框架或者工具，而新型互聯(lián)網(wǎng)企業(yè)則傾向于開源免費(fèi)的自動(dòng)化測(cè)試框架或者工具，或者基于它們進(jìn)行二次定制開發(fā)，或者重新開發(fā)適合自己的自動(dòng)化測(cè)試框架、工具或者平臺(tái)。
我之前寫過一篇文章——《自動(dòng)化測(cè)試框架Cucumber和RobotFramework的實(shí)戰(zhàn)對(duì)比》僅僅針對(duì)兩種自動(dòng)化測(cè)試框架進(jìn)行了討論，卻引發(fā)了大量的討論，由此可見業(yè)界對(duì)于自動(dòng)化測(cè)試框架存在很多不同的理解和爭議。在我看來，沒有任何一個(gè)自動(dòng)化測(cè)試框架是銀彈，并且適合所有類型的測(cè)試，所以“如何選擇一款適合自己的測(cè)試框架”變成為了一個(gè)首要問題。我將自動(dòng)化測(cè)試進(jìn)行了簡單的分層，見下圖。
自動(dòng)化測(cè)試架構(gòu)分層圖
其中測(cè)試庫和被測(cè)系統(tǒng)緊密相關(guān)，所以可以選擇的范圍不是很大，也很難進(jìn)行統(tǒng)一分類。而測(cè)試框架與被測(cè)系統(tǒng)關(guān)系并不緊密，而是和技術(shù)棧，開發(fā)流程與組織管理等關(guān)系緊密相關(guān)，并且種類繁多，可選擇范圍很多，所以選擇也相對(duì)比較困難。
因此對(duì)測(cè)試框架進(jìn)行統(tǒng)一分類可以更好的幫助團(tuán)隊(duì)選擇適合自己的測(cè)試框架，從而更好進(jìn)行自動(dòng)化測(cè)試開發(fā)。
本文根據(jù)自動(dòng)化測(cè)試用例的呈現(xiàn)方式和管理方式將其分為四種類型：函數(shù)行，單領(lǐng)域語言型，多領(lǐng)域語言型以及富文檔型。
四個(gè)類型：
1. 函數(shù)型
函數(shù)型自動(dòng)化測(cè)試框架是第一代自動(dòng)化測(cè)試框架，也是最輕量的測(cè)試框架。它只是通過函數(shù)的方式來定義測(cè)試用例，并且通過管理這些函數(shù)的調(diào)用來管理測(cè)試用例，從而快速的實(shí)現(xiàn)自動(dòng)化測(cè)試，比如xUnit等。
例子JUnit：
- public class DemoTest {
- @Test
- public void testAddWithTwoNumbers() {
- //測(cè)試實(shí)現(xiàn)代碼
- }
- }
函數(shù)型自動(dòng)化測(cè)試框架由來已久，開發(fā)快速，運(yùn)行穩(wěn)定。雖然它相對(duì)簡單與輕量，但是也存在缺點(diǎn)：很難通過函數(shù)名來描述測(cè)試用例的內(nèi)容和細(xì)節(jié)，并且不方便對(duì)測(cè)試用例進(jìn)行單獨(dú)管理，因?yàn)闇y(cè)試用例的描述函數(shù)名和測(cè)試實(shí)現(xiàn)通常都在一起。
2. 單領(lǐng)域語言型
由于函數(shù)型的自動(dòng)化測(cè)試框架很難通過函數(shù)名去描述一個(gè)測(cè)試用例的內(nèi)容。為了更清晰和容易的描述測(cè)試用例，就出現(xiàn)了單DSL型的自動(dòng)化測(cè)試框架，比如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() {
- //測(cè)試實(shí)現(xiàn)代碼
- });
- });
單領(lǐng)域語言型可以通過自然語言或者關(guān)鍵字形式的領(lǐng)域語言來描述測(cè)試用例，從而以一種更加易讀和理解的方式來描述測(cè)試用例。但是每個(gè)測(cè)試用例只用一句DSL語言，并不能很好的描述測(cè)試用例和被測(cè)場(chǎng)景，不易形成一套好的活文檔。由于它的測(cè)試用例與測(cè)試實(shí)現(xiàn)通常也是在一起的，所以也不方便對(duì)測(cè)試用例進(jìn)行單獨(dú)管理。
3. 多領(lǐng)域語言型
由于單DSL型框架中對(duì)于每個(gè)測(cè)試用例只能使用一句DSL來描述，并不能很好的體現(xiàn)測(cè)試用例場(chǎng)景，比如測(cè)試的前提，行為和結(jié)果等。為了能在測(cè)試用例層更為清晰的描述測(cè)試用例的行為和測(cè)試數(shù)據(jù)等型信息，出現(xiàn)了多領(lǐng)域語言型的自動(dòng)化測(cè)試框架，比如Cucumber，JBehave，SpecFlow，RF等。
例子Cucumber：
測(cè)試用例代碼
- 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 |
測(cè)試實(shí)現(xiàn)代碼
- Given(/^there are two numbers$/) do
- //測(cè)試實(shí)現(xiàn)代碼
- end
- When(/^add two numbers together$/) do
- //測(cè)試實(shí)現(xiàn)代碼
- end
- Then(/^should get sum of two numbers$/) do
- //測(cè)試實(shí)現(xiàn)代碼
- end
多領(lǐng)域語言型的框架可以通過多句或者多個(gè)關(guān)鍵字的領(lǐng)域語言來描述一個(gè)特定的場(chǎng)景，使得測(cè)試用例更容易閱讀和理解，并且比較容易做成一套活文檔系統(tǒng)。由于測(cè)試用例和測(cè)試實(shí)現(xiàn)是分離的，還可以對(duì)測(cè)試用例進(jìn)行獨(dú)立管理。
但是缺點(diǎn)也是比較明顯的，開發(fā)、管理和維護(hù)成本較高，并且如果沒有業(yè)務(wù)分析或者產(chǎn)品人員等非技術(shù)人員參與協(xié)作開發(fā)，那么它的投入產(chǎn)出比就很低，大家往往會(huì)認(rèn)為它是事倍功半。
4. 富文檔型
對(duì)于一些場(chǎng)景十分復(fù)雜，需要通過富文檔的方式來描述軟件測(cè)試場(chǎng)景，甚至需要一些業(yè)務(wù)流程圖或者系統(tǒng)用戶界面等，比如Concordion，F(xiàn)itnesse，Guage等。
例子 Condordion：
測(cè)試用例代碼，其中包含部分測(cè)試代碼，比如斷言等，其中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>
測(cè)試用例呈現(xiàn)文檔：
測(cè)試用例中的函數(shù)實(shí)現(xiàn)代碼：
- @RunWith(ConcordionRunner.class)
- public class CaculatorFixture {
- public String addWithTwoNumbers(String number1, String number2) {
- //測(cè)試實(shí)現(xiàn)代碼
- }
- }
(注：雖然說最新版的Concordion已經(jīng)支持MarkDown了，從而降低了一些開發(fā)成本，但是其對(duì)MarkDown的特性支持有待增加。所以如果需要更為豐富的文檔形式，仍然需要使用HTML來開發(fā)測(cè)試用例。)
富文檔型的框架比多領(lǐng)域語言型擁有更為豐富的文檔，更容易閱讀和理解，從而能做成說明書式的活文檔，使得所有角色的人都能審閱。并且其測(cè)試用例和測(cè)試實(shí)現(xiàn)也是分離的。但是當(dāng)前業(yè)界存在的富文檔型測(cè)試框架的易用性和協(xié)作性都還不是很好，導(dǎo)致其開發(fā)，管理和維護(hù)成本相比前三種是最高的。并且當(dāng)沒有其它各個(gè)角色來協(xié)同開發(fā)，管理和維護(hù)時(shí)，其投入產(chǎn)出比也是最低的，所以它在行業(yè)中的使用率也是很低的。這類測(cè)試框架在易用性和協(xié)作性方面還有很大的發(fā)展空間，并且也是自動(dòng)化測(cè)試框架和活文檔系統(tǒng)的一個(gè)重要的發(fā)展方向。
思考與選擇
自動(dòng)化測(cè)試的代碼實(shí)現(xiàn)層一般是與編程語言強(qiáng)相關(guān)的，而主流的編程語言比較少，所以選擇比較容易：一般建議選擇團(tuán)隊(duì)大部分成員都熟悉的編程語言(這樣可以促使整個(gè)團(tuán)隊(duì)來對(duì)自動(dòng)化測(cè)試進(jìn)行開發(fā)和維護(hù))或者是有特定測(cè)試庫的編程語言(比如需要使用Scapy時(shí)就只能選擇基于Python的自動(dòng)化測(cè)試框架)。當(dāng)確認(rèn)自動(dòng)化測(cè)試開發(fā)語言后，真正的問題是如何在如此眾多的自動(dòng)化測(cè)試框架里面選擇合適自己的自動(dòng)化測(cè)試框架。選擇方法可以根據(jù)以上四種類型來進(jìn)行選擇，從而縮小選擇范圍。
如果團(tuán)隊(duì)只是需要快速實(shí)現(xiàn)自動(dòng)化測(cè)試，沒有知識(shí)的傳遞問題，也不需要與業(yè)務(wù)分析和產(chǎn)品經(jīng)歷等非技術(shù)人員進(jìn)行協(xié)作開發(fā)時(shí)，可以選擇函數(shù)型自動(dòng)化測(cè)試框架。
如果為了解決知識(shí)傳遞問題，讓測(cè)試用例更可讀和易懂，并且沒有非技術(shù)人員參與協(xié)作開發(fā)，這時(shí)可以選擇單領(lǐng)域語言型。
如果為了進(jìn)一步解決和非技術(shù)人員協(xié)作開發(fā)的問題，并且想有一套簡版的活文檔，可以選擇多領(lǐng)域語言型自動(dòng)化測(cè)試框架。
如果為了讓測(cè)試用例擁有更為豐富的表現(xiàn)力，比如包含一個(gè)流程圖來說明被測(cè)場(chǎng)景的流程，或者使用不同的格式或者表格來描述用例的細(xì)節(jié)，以及擁有一套豐富的活文檔，這時(shí)就可以使用富文檔型。不過由于當(dāng)前的富文檔型測(cè)試框架在編寫用例時(shí)需要一定的技能，所以非技術(shù)人員很難直接參與協(xié)作編寫。并且其編寫以及維護(hù)成本更高，可能使得自動(dòng)化測(cè)試開發(fā)人員使用的意愿也不是很高。參考自動(dòng)化測(cè)試工具選項(xiàng)金字塔：
當(dāng)確認(rèn)了測(cè)試框架類型之后，比如只有一個(gè)可選項(xiàng)(Java->函數(shù)型->JUnit)，那么就直接使用了，但是如果存在多選項(xiàng)(JavaScript-> 單領(lǐng)域語言型->Jasmine vs Mocha)，就還需要對(duì)其進(jìn)行深入比較，從而最終選擇自己適合的自動(dòng)化測(cè)試框架。
【本文是51CTO專欄作者“ThoughtWorks”的原創(chuàng)稿件，微信公眾號(hào)：思特沃克，轉(zhuǎn)載請(qǐng)聯(lián)系原作者】
