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

軟件功能測試用例的書寫方式解答
軟件功能測試用例的書寫方式  功能測試工具

1. 測試的來源，即測試的需求
    測試用例的主要來源有：
    1） 需求說明”及相關文檔
    2）相關的設計說明（概要設計，詳細設計等）
    3）與開發組交流對需求理解的 記錄（可以是開發人員的一個解釋）
    4）已經基本成型的UI（可以有針對性地補充一些用例）
    簡而言之，所有你能得到的項目文檔，都盡量拿到。 從所得到的資料中，分解出若干小的“功能點”，理解“功能點”，編寫相應的測試用例。

2. 用例的組織方式

不同的公司有不同的做法，原則上，只要方便管理和跟蹤，怎么組織都可以的。
    用例可以按大的功能塊組織，如查詢功能模塊的用例，可以組織在一起，打印模塊的測試用例，可以另外組織在一起。
     在沒有專門的測試用例管理工具的情況下，用例執行后會產生2種狀態：“通過”、“失敗”——這樣加上“未 執行”的用例的狀態，共3種狀態。
    即從“未執行”用例中執行一個用例后，該用例狀態應為“失敗”或“通 過”。將同一狀態的用例組織在一起。
    至于用例文件格式，可以是.DOC或.XLS（如果有專門的測試用例管理工具另當別論）。

3. 用例與其他材料的關聯方式，即如何解決用例跟蹤的問題 測試用例面臨的比較大的風險有：

需求的變更、設計的修改、需求的錯誤和遺漏等等。
    由于用例的主要來源是需求和設計的說明，所以對用例的跟蹤其實就是對需求和設計的跟蹤，需求和設計的變更勢必引起測試用例的變更。
    如前所說，將分解的功能點編號，與相應的用例聯系起來。例如，你可以列一個表格，列出各個（編號的）功能點和測試用例間的關聯關系
    這樣，當需求和設計發生變化時，你只需要跟蹤“功能點”是否變化，是否增 加了新的功能點。
    重要和困難的是，不手頭的資料和信息一定要是最新的。

4. 一個好的用例的表述要點，即用例中應當包含的信息

一個優秀的測試用例，應該包含以下信息：
    1） 軟件或項目的名稱
    2） 軟件或項目的版本（內部版本號）
    3） 功能模塊名
    4） 測試用例的簡單描述，即該用例執行的目的或方法
    5） 測試用例的參考信息（便于跟蹤和參考）
    6） 本測試用例與其他測試用例間的依賴關系
    7） 本用例的前置條件，即執行本用例必須要滿足的條件，如對數據庫的訪問權限
    8） 用例的編號（ID），如可以是軟件名稱簡寫-功能塊簡寫-NO.。
    9） 步驟號、操作步驟描述、測試數據描述
    10）預期結果（這是最重要的）和實際結果（如果有BUG管理工具，這條可以省略）
    11）開發人員（必須有）和測試人員（可有可無）
    12）測試執行日期 

原文轉自：http://www.anti-gravitydesign.com