功能測試用例的書寫方式

　　功能測試用例的書寫方式  軟件測試

　　功能性測試用例

　　1. 測試的來源，即測試的需求

　　測試用例的主要來源有：

　　1) 需求說明”及相關文檔2)相關的設計說明(概要設計，詳細設計等)3)與開發組交流對需求理解的

　　記錄(可以是開發人員的一個解釋)4)已經基本成型的UI(可以有針對性地補充一些用例)

　　簡而言之，所有你能得到的項目文檔，都盡量拿到。

　　從所得到的資料中，分解出若干小的“功能點”，理解“功能點”，編寫相應的測試用例。

　　2. 用例的組織方式

　　不同的公司有不同的做法，原則上，只要方便管理和跟蹤，怎么組織都可以的。

　　用例可以按大的功能塊組織，如查詢功能模塊的用例，可以組織在一起，打印模塊的測試用例，可以另外組

　　織在一起。

　　在沒有專門的測試用例管理工具的情況下，用例執行后會產生2種狀態：“通過”、“失敗”——這樣加上“未

　　執行”的用例的狀態，共3種狀態。即從“未執行”用例中執行一個用例后，該用例狀態應為“失敗”或“通

　　過”。將同一狀態的用例組織在一起。

　　至于用例文件格式，可以是.DOC或.XLS(如果有專門的測試用例管理工具另當別論)。

　　3. 用例與其他材料的關聯方式，即如何解決用例跟蹤的問題

　　測試用例面臨的比較大的風險有：需求的變更、設計的修改、需求的錯誤和遺漏等等。

　　由于用例的主要來源是需求和設計的說明，所以對用例的跟蹤其實就是對需求和設計的跟蹤，需求和設計的

　　變更勢必引起測試用例的變更。

　　如前所說，將分解的功能點編號，與相應的用例聯系起來。例如，你可以列一個表格，列出各個(編號的)功

　　能點和測試用例間的關聯關系。這樣，當需求和設計發生變化時，你只需要跟蹤“功能點”是否變化，是否增

　　加了新的功能點。

原文轉自：http://www.kjueaiud.com