MILY: 宋體; mso-font-kerning: 0pt; mso-bidi-font-size: 10.5pt; mso-ascii-font-family: 'Times New Roman'; mso-hansi-font-family: 'Times New Roman'"> 自動化測試有其自身的特點，按照筆者的經驗，自動化在一個項目，乃至一個公司開展的成功與否，并不是僅僅依靠QTP等工具使用者的腳本編寫水平的提高就可以掌控的。而因為其他的一些因素，一旦自動化測試失去了它本身高效、可控的特點的話，那反而是得不償失，會增加項目的成本。
自動化測試人員進入項目的時間可能不是最早的，對需求的理解并不是在第一時間就很容易做到的。測試用例作為測試需求的載體、測試執行的依據和工作量的評估，它設計和表達的優劣直接影響到自動化測試開展的前幾個階段，如：需求學習、篩選適合自動化測試的用例以及提取公司級或項目的可重用腳本等方面的工作效率。
1.步驟和數據的分離：
好的測試用例，在執行的步驟(Step）的表達上應該是盡可能和數據相分離。舉例來講，有一個ATM機取款的功能，可能有以下幾個場景：
1) 密碼正確的登錄
2) 密碼錯誤的登錄
3) 密碼輸入三次錯誤，卡被鎖定
4) 取少于余額的款項
5) 嘗試取大于余額的款項
6) 嘗試取等于余額的款項（考慮手續費）
6) 取款額度大于當次的限制
7) 取款額度大于當天的限制
8) 取款次數大于限制次數
等等
不管你用什么用例設計的方法論來做指導，作為這個簡單的例子，有經驗的人都應該能看出，此處的很多步驟是可以重用的，總結如下（此處只列出了操作的步驟，略去了系統的交互中的反饋結果）：
1) 插入卡->A:輸入密碼->B:按“確定”鍵->重復A-B
2) A:選擇取款功能->B:填寫取款金額->C:點擊“確定取款”的按鈕->D:取現金->重復A-D
因此，我們只需要寫出兩套比較完整的步驟，將密碼和取款金額多數字用參數來表達即可。這樣是不是簡單了很多呢？
2. 單獨的測試基礎數據準備工作
第一個例子中的輸入數據比較簡單，但我們同樣需要考慮的一個問題是：在測試中究竟我們輸入什么樣的具體數據呢？什么是”正確的密碼“？什么又是”大于余額的款項“呢？
對于大的應用系統，數據之間的關系和準備過程都會很復雜，甚至也有其他外部系統導入、傳輸或計算出的數據。一個比較好的做法是，將這些測試數據提前準備好，在每個階段性測試前導入到系統中。一個比較典型的例子，假設要求你單獨去測試幾張復雜的財務報表，用其他的模塊和外部系統，自己逐一的去創造數據，那會非常耗時耗力。這時，基礎數據的準備就顯得尤為重要，以此才能保證測試工作是高效的、測試結果是精確的。
如果有可能，復雜的測試基礎數據最好是提前準備好的，類似這里例子中簡單的 一個帳號為1234567890，密碼為66666的有效銀行卡，里面有人民幣1000元正，等等。將這些內容預先準備好（可以用自動化工具來準備，或導出已有的數據為一個SQL的腳本），寫到你單獨的測試數據準備文檔中，而不是分散到 所有使用到它的case中才去描述。
3. 測試用例的前置條件和后置條件
除了第二點中談到的數據需要準備外，在測試用例這個Level，必須有一些條件滿足，您才能開始執行它。比如準備一個初始設置條件下的IE 瀏覽器和已安裝過老版本該軟件的XP系統。這些可重用的準入條件，可以考慮不作為特定用例的Step，而是把它提取出來，作為Setup Section或叫Pre-Condition。
對于后置條件或Post-condition，往往我們用它來做一些處理或恢復，比如在上面的取款例子中，如果我們要用相同的帳號重復測試，在正好取完所有金額，余額為零的情況下，可以通過一些步驟或數據庫腳本重置帳號余額。同樣，您為某個用例設置瀏覽器禁用了Cookie，執行完該用例后，是不是也是需要回復到默認設置的狀態呢？
集中的把這些步驟整理成一個相對獨立的操作單元，具體用例中只要引用就可以了，這樣會便于對用例的理解和在多處復用。
順便說一下，對于一些類似軟件運行環境的條件，比如安裝和配置測試中，需要3種操作系統和3種瀏覽器的組合等，我們可以把他放在Test Set這個Level上來，不用寫多個用例，只是在測試計劃和執行的管理系統中作為測試集的一個環境參數，恰當地表達出來就可以。
4. 常用業務操作(Knowledge Base)
對于一個大型的應用，比如銀行系統，開發和測試工作是長期的，持續的一個過程，這樣的系統很適合引入自動化測試。它業務邏輯復雜，測試技術性要求高，往往使用了不同廠商的工具和多種腳本語言（如Shell，Python等），也存在了很多可用的遺留腳本。
這些完成一些預定業務操作的腳本單元，是可以直接借用的。為了在公司和產品層面，管理好這些可復用的資源，一種好的方式是給它們標上號，如KB_PRJ01_Module02_XXX，集中管理起來，以后的用例中只要調用即可。
舉例來說，在銀行業務測試中我們，需要模擬和銀聯的接口，讓測試帳號向外匯款，取得響應信息，并保存結果，這可能是個復雜而底層的處理過程，對一般員工是不需要，也沒有權限去深入掌握的。這時，將他們包裝成一個個Shell腳本或小工具，做好使用說明和統一建檔，在以后的項目測試中，只要調用就可以了。如此，可以大大提高各個有相關接口的模塊的自動化測試工作效率。
根據以往工作中常見的一些問題，對于如何寫好測試用例（不僅針對自動化測試），做以下做幾點補充：
|
推薦 |
不推薦 |
|
將用例的內容描述清楚，強調怎么操作，驗證什么，然后期待的結果是什么。 |
Copy需求和設計文檔中的內容；描述成：什么條件下，邏輯會是怎樣。這樣對測試用例的閱讀和執行人員，不具有可操作性。 |
|
期待的結果要寫具體，如：系統反應是什么；結果數字是多少；用戶被帶到什么頁面；顯示什么成功信息；后臺或數據庫中該記錄的修改后結果是怎么樣的。 |
描述成：”驗證系統返回正確結果“；”頁面元素顯示跟SPEC一致“；”操作成功“等 比較抽象的說法。 |
|
業務邏輯性較強的應用軟件，做到以業務流為主線，來組織用例。 |
以頁面形式組織用例。 |
|
以Module、Function、測試類型、基本業務流、備選業務流的樹狀結構形式，分層次組織用例；使用用例管理工具。 |
Word格式的扁平組織結構，不利于管理和閱讀。 |
|
用一個屬性字段，建立用例和Spec等文檔的某個章節間的映射。 |
無法和需求對應，以后難以計算 用例覆蓋率，測試執行覆蓋率。 |
|
每個Module、Function、特定業務的一組測試用例，之間做到獨立、沒有耦合。 |
|
|
在時間和成本允許的情況下，盡量做到：用例粒度為“一種不同的操作，得到不同的結果，就單獨寫一個用例“。 |
在用例中的操作步驟中，甚至期待結果中，仍然存在條件分支。 |
|
對于復雜的業務操作過程，如”一次順序的表單簽核過程“和”一次完整的信貸手續“，單獨增加一些貫穿整個業務流的大型測試用例。 |
對于一個長業務操作，只存在比較零散的細節用例。 |
|
將用例分優先等級，便于在回歸測試時挑選核心業務或用戶操作密集的用例。 |
用例 沒有優先級和重要程度的定義。 |
文章來源于領測軟件測試網 http://www.kjueaiud.com/