測試用例編寫的“侯式標準”

　　作為軟件測試人員，執行測試用例是我們進行測試工作的主要手段，測試用例設計的好壞，直接影響著測試工作的質量。一個“好”的測試用例能保證測試的質量，規范測試的進程，進而提高我們的測試效率。

　　那什么樣的用例才是好的測試用例?這已經是一個老生常談的問題，大家見仁見智 ，眾說云云，不一而足。

　　而我的TL--候風的一句話，讓我對用例的有了新的認識。他是這樣說的：一個好的測試用例，就是在保證測試質量的前提下，做到以下幾點：當一個不熟悉業務的人，看到你的用例后，要知道用例的測試目的什么，知道你要做什么，怎么做，為什么這樣做，取得了什么什么成果。

　　做什么?

　　做任何事情，都要有的放矢。我們在編寫一個測試用例的時候，應該知道我們要的是什么，這也是編寫一個用例最基本的前提。

　　怎么做?

　　即具體的如何設計用例。就是要明確用例的執行過程，這樣在測試的時候才能有章可循，摸著石頭過河

　　為什么這樣做?

　　這要求用例編寫者要明確設計用例時用到的方法(如邊界值，等價類等等)，以及用這種方法的好處。

　　取得了什么成果?

　　這要求用例編寫者明確通過這個測試用例,我們將取得什么效果。比如一個采用邊界值設計的用例，取得的效果是在極端的數據下，軟件是否能夠正常執行功能。

　　標準規范中包含的主要元素如下：

　　測試名稱(Test Name)：測試用例編號和測試用例名稱。

　　創建日期(Creation Date)：測試用例創建時間，系統自動產生。

　　設計人員(Designer)：測試用例設計人員

　　狀態(Status)：測試用例狀態

　　描述(Descrīption)：測試用例詳細描述

　　步驟名稱(Step Name)：測試步驟名稱

　　步驟描述(Step Descrīption)：測試步驟詳細描述。

　　預期結果(Expected Result)：測試預期結果。

　　要是按照“候風標準”(暫且這樣命名，還沒申請侯哥批準)，我們要對上面的標準進行規范的優化以及內容的明確

　　1測試名稱

　　A)用例根據各用例的功能來命名，盡量做到簡潔明了。

　　B)一級目錄使用各項目的頂級菜單名稱來命名，如功能、業務、查詢三大類;

　　C)二級目錄使用頂級菜單下的二級菜單名稱類命名，用戶可根據名字判別該用例是測試哪個模塊的。

　　2 描述(Descrīption)：測試用例詳細描述

　　要用通俗易懂而又簡潔的語言描述描述用例的設計目的，讓其他人能夠明白我們在什么

　　3 步驟描述

　　步驟描述要詳細而不臃腫，條理而不凌亂。

　　同時，在規范上要增加以下幾項

　　測試目的(Purpose)：編寫這個測試用例的目的

　　測試方法選擇依據(Foundation)：即用這樣方法的好處

　　測試取得的成果(Achievement)：通過執行用例取得的成果

　　用例執行的前提條件(Precondition)：執行用例的需要滿足的前提

　　這樣，一個完整的用例包含的元素如下：

　　測試名稱(Test Name)

　　測試目的(Purpose)

　　測試方法選擇依據(Foundation)

　　用例執行的前提條件(Precondition)

　　創建日期(Creation Date)

　　設計人員(Designer)

　　狀態(Status)

　　描述(Descrīption)

　　步驟名稱(Step Name)

　　步驟描述(Step Descrīption)

　　預期結果(Expected Result)

　　測試取得的成果(Achievement)

　　綜上所述，測試用例的“侯式標準”的精髓，就是把自己的思維過程盡可能的展現到用例中，做到即使一個完全不懂業務的人，看到我們的用例后，也能知道業務的需求和流程，知道測試的過程，能夠無障礙的執行我們的用例。

　　以上是我學習用例編寫過程中的一些體會，不足之處請大家批評指正。讓我們一起交流分享，共同進步成長。

　　參考書籍

　　《軟件測試》 作者：[美]Paul C.Jorgensen 譯者：韓柯 杜旭濤 機械工業出版社

原文轉自：http://www.uml.org.cn/Test/201208294.asp