功能測試用例的書寫

功能性測試用例

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

測試用力的主要來源有：

1）需求說明及相關文檔

2）相關的設計說明（概要設計，詳細設計等）

3）與開發組交流對需求理解的記錄（可以是開發人員的一個解釋）

4）已經基本成型的UI（可以有針對性的補充一些用例）

簡而言之，所有你能得到的項目文檔，都盡量拿到。從所得道德資料中分解出若幹小的“功能點”，理解“功能點”，編寫相應的測試用例。

2.用例的組織方式

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

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

在沒有專門的測試用例管理工具的情況下，用例執行狗會產生兩種狀態：

即從“未執行”用例中執行一個用例後，該用例狀態應為“失敗”或“通過”。將同一狀態的用例組織在一起。

至於用例文件格式，可以是。DOS或是。XLS（如果有專門的測試管理工具另當別論）

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

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

由於用力的主要來源是需求和設計的說明，所有對用例跟蹤其實就是對需求和設計的跟蹤，需求和設計的變更勢必引起測試用例的變更。

如前所說，將分解的功能點編號。與相應的用例聯系起來。例如，你可以列一個表格，列出各個（編號的）功能點和測試用例撿的關聯關系。

這樣，當需求和設計發生變化時，你只需要跟蹤“功能點”是否發生變化，是否增加了新的功能點。

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

一個優秀的測試用例應該包含以下信息:

1)軟件或項目的名稱

2)軟件或項目的版本（內部版本號）

3)功能模塊明

4)測試用例的簡單描述，即該用例執行的目的或方法

5)測試用例的參考信息（便於跟蹤和參考）

6)本測試用例與其他測試用例間的依賴關系

7)本測試用例的前置條件，及執行本用例必須要滿足的條件，如對本數據庫的訪問權限

8)用例的編號（ID）,如可以是軟件名稱簡寫—功能塊簡寫—NO. 。

9)步驟號、操作步驟描述、測試數據描述

10)預期結果（這是最重要的）和實際結果（如果有

11)開發人員（必須有）和測試人員（可有可無）

12)測試執行日期

給出一個測試的例子該範例已經包含一個測試用例的模板。

功能測試用例的書寫