功能性測試用例
1. 測試的來源，即測試的需求
測試用例的主要來源有：
1) 需求說明”及相關文檔
2)相關的設計說明(概要設計，詳細設計等)
3)與開發組交流對需求理解的 記錄(可以是開發人員的一個解釋)
4)已經基本成型的UI(可以有針對性地補充一些用例)
簡而言之，所有你能得到的項目文檔，都盡量拿到。 從所得到的資料中，分解出若干小的“功能點”，理解“功能點”，編寫相應的測試用例。
2. 用例的組織方式
不同的公司有不同的做法，原則上，只要方便管理和跟蹤，怎么組織都可以的。
用例可以按大的功能塊組織，如查詢功能模塊的用例，可以組織在一起，打印模塊的測試用例，可以另外組 織在一起。
在沒有專門的測試用例管理工具的情況下，用例執行后會產生2種狀態：“通過”、“失敗”——這樣加上“未 執行”的用例的狀態，共3種狀態。
即從“未執行”用例中執行一個用例后，該用例狀態應為“失敗”或“通 過”。將同一狀態的用例組織在一起。
至于用例文件格式，可以是.DOC或.XLS(如果有專門的測試用例管理工具另當別論)。
3. 用例與其他材料的關聯方式，即如何解決用例跟蹤的問題 測試用例面臨的比較大的風險有：
需求的變更、設計的修改、需求的錯誤和遺漏等等。
由于用例的主要來源是需求和設計的說明，所以對用例的跟蹤其實就是對需求和設計的跟蹤，需求和設計的 變更勢必引起測試用例的變更。
如前所說，將分解的功能點編號，與相應的用例聯系起來。例如，你可以列一個表格，列出各個(編號的)功 能點和測試用例間的關聯關系。
這樣，當需求和設計發生變化時，你只需要跟蹤“功能點”是否變化，是否增 加了新的功能點。
重要和困難的是，不手頭的資料和信息一定要是最新的。
4. 一個好的用例的表述要點，即用例中應當包含的信息
一個優秀的測試用例，應該包含以下信息：
1) 軟件或項目的名稱
2) 軟件或項目的版本(內部版本號)
文章來源于領測軟件測試網 http://www.k11sc111.com/
