為了提高軟件測試的效率，增進(jìn)測試工作的廣度和深度，越來(lái)越多的公司開(kāi)始引入自動(dòng)化測試。本文通過(guò)筆者對測試用例設計和表達上的一些理解，闡述如何寫(xiě)好功能自動(dòng)化測試友好的用例，供大家參考。
自動(dòng)化測試有其自身的特點(diǎn)，按照筆者的經(jīng)驗，自動(dòng)化在一個(gè)項目，乃至一個(gè)公司開(kāi)展的成功與否，并不是僅僅依靠QTP等工具使用者的腳本編寫(xiě)水平的提高就可以掌控的。而因為其他的一些因素，一旦自動(dòng)化測試失去了它本身的高效、可控的特點(diǎn)的話(huà)，那反而是得不償失，會(huì )增加項目的成本。
自動(dòng)化測試人員進(jìn)入項目的時(shí)間可能不是最早的，對需求的理解并不是在第一時(shí)間就很容易做到的。測試用例作為測試需求的載體、測試執行的依據和工作量的評估，它設計和表達的優(yōu)劣直接影響到自動(dòng)化測試開(kāi)展的前幾個(gè)階段，如：需求學(xué)習、篩選適合自動(dòng)化測試的用例以及提取公司級或項目的可重用腳本等方面的工作效率。
1.步驟和數據的分離：
好的測試用例，在執行的步驟(Step)的表達上應該是盡可能和數據相分離。舉例來(lái)講，有一個(gè)ATM機取款的功能，可能有以下幾個(gè)場(chǎng)景：
1. 密碼正確的登錄
2. 密碼錯誤的登錄
3. 密碼輸入三次錯誤，卡被鎖定
4. 取少于余額的款項
5. 嘗試取大于余額的款項
6. 嘗試取等于余額的款項(考慮手續費)
6. 取款額度大于當次的限制
7. 取款額度大于當天的限制
7. 取款次數大于限制次數
等等
不管你用什么用例設計的方法論來(lái)做指導，作為這個(gè)簡(jiǎn)單的例子，有經(jīng)驗的人都應該能看出，此處的很多步驟是可以重用的，總結下來(lái)如下(此處只列出了操作的步驟，略去了系統的交互中的反饋結果)：
1. 插入卡->A:輸入密碼->B:按“確定”鍵->重復A-B
2. A:選擇取款功能->B:填寫(xiě)取款金額->C:點(diǎn)擊“確定取款”的按鈕->D:取現金->重復A-D
因此，我們只需要寫(xiě)出兩套比較完整的步驟，將密碼和取款金額多數字用參數來(lái)表達即可。這樣是不是簡(jiǎn)單了很多呢?
2. 單獨的測試基礎數據準備工作
第一個(gè)例子中的輸入數據比較簡(jiǎn)單，但我們同樣需要考慮的一個(gè)問(wèn)題是：在測試中究竟我們輸入什么樣的具體數據呢?什么是”正確的密碼“?什么又是”大于余額的款項“呢?
對于大的應用系統，數據之間的關(guān)系和準備過(guò)程都會(huì )很復雜，甚至也有其他外部系統導入、傳輸或計算出的數據。 一個(gè)比較好的做法是，將這些測試數據提前準備好，在每個(gè)階段性測試前導入到系統中。一個(gè)比較典型的例子，假設要求你單獨去測試幾張復雜的財務(wù)報表，用其他的模塊和外部系統，自己逐一的去創(chuàng )造數據，那會(huì )非常耗時(shí)耗力。這時(shí)，基礎數據的準備就顯得尤為重要，以此才能保證測試工作是高效的、測試結果是精確的。
如果有可能，復雜的測試基礎數據最好是提前準備好的，類(lèi)似這里例子中簡(jiǎn)單的 一個(gè)帳號為1234567890，密碼為66666的有效銀行卡，里面有人民幣1000元正，等等。將這些內容預先準備好(可以用自動(dòng)化工具來(lái)準備，或導出已有的數據為一個(gè)SQL的腳本)，寫(xiě)到你單獨的測試數據準備文檔中，而不是分散到 所有使用到它的case中才去描述。
3. 測試用例的前置條件和后置條件
除了第二點(diǎn)中談到的數據需要準備外，在測試用例這個(gè)Level，必須有一些條件滿(mǎn)足，您才能開(kāi)始執行它。比如準備一個(gè)初始設置條件下的IE瀏覽器和已安裝過(guò)老版本該軟件的XP系統。這些可重用的準入條件，可以考慮不作為特定用例的Step，而是把它提取出來(lái)，作為Setup Section或叫Pre-Condition。
對于后置條件或Post-condition，往往我們用它來(lái)做一些處理或恢復，比如在上面的取款例子中，如果我們要用相同的帳號重復測試，在正好取完所有金額，余額為零的情況下，可以通過(guò)一些步驟或數據庫腳本重置帳號余額。同樣，您為某個(gè)用例設置瀏覽器禁用了Cookie，執行完該用例后，是不是也是需要回復到默認設置的狀態(tài)呢?
集中的把這些步驟整理成一個(gè)相對獨立的操作單元，具體用例中只要引用就可以了，這樣會(huì )便于對用例的理解和在多處復用。
順便說(shuō)一下，對于一些類(lèi)似軟件運行環(huán)境的條件，比如安裝和配置測試中，需要3種操作系統和3種瀏覽器的組合等，我們可以把他放在Test Set這個(gè)Level上來(lái)，不用寫(xiě)多個(gè)用例，只是在測試計劃和執行的管理系統中作為測試集的一個(gè)環(huán)境參數，恰當地表達出來(lái)就可以。
4. 常用業(yè)務(wù)操作(Knowledge Base)
對于一個(gè)大型的應用，比如銀行系統，開(kāi)發(fā)和測試工作是長(cháng)期的，持續的一個(gè)過(guò)程，這樣的系統很適合引入自動(dòng)化測試。它業(yè)務(wù)邏輯復雜，測試技術(shù)性要求高，往往使用了不同廠(chǎng)商的工具和多種腳本語(yǔ)言(如Shell，Python等)，也存在了很多可用的遺留腳本。
這些完成一些預定業(yè)務(wù)操作的腳本單元，是可以直接借用的。為了在公司和產(chǎn)品層面，管理好這些可復用的資源，一種好的方式是給它們標上號，如KB_PRJ01_Module02_XXX，集中管理起來(lái)，以后的用例中只要調用即可。
舉例來(lái)說(shuō)，在銀行業(yè)務(wù)測試中我們，需要模擬和銀聯(lián)的接口，讓測試帳號向外匯款，取得響應信息，并保存結果，這可能是個(gè)復雜而底層的處理過(guò)程，對一般員工是不需要，也沒(méi)有權限去深入掌握的。這時(shí)，將他們包裝成一個(gè)個(gè)Shell腳本或小工具，做好使用說(shuō)明和統一建檔，在以后的項目測試中，只要調用就可以了。如此，可以大大提高各個(gè)有相關(guān)接口的模塊的自動(dòng)化測試工作效率。
文章來(lái)源于領(lǐng)測軟件測試網(wǎng) http://kjueaiud.com/
