功能測試用例的書寫

功能測試用例的書寫

功能性測試用例

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

  測試用力的主要來源有：

1）需求說明及相關文檔

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

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

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

   簡而言之，全部你能獲得的項目文檔，都儘可能拿到。從所得道德資料中分解出若干小的「功能點」，理解「功能點」，編寫相應的測試用例。

2.用例的組織方式

  不一樣的公司有不一樣的作法，原則上，只要方便管理和跟蹤，怎麼組織均可以。

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

  在沒有專門的測試用例管理工具的狀況下，用例執行狗會產生兩種狀態：「經過」、「失敗」——這樣加上「未執行」的用例狀態，共3種狀態。

   即從「未執行」用例中執行一個用例後，該用例狀態應爲「失敗」或「經過」。將同一狀態的用例組織在一塊兒。

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

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

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

因爲用力的主要來源是需求和設計的說明，全部對用例跟蹤其實就是對需求和設計的跟蹤，需求和設計的變動勢必引發測試用例的變動。

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

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

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

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

1)軟件或項目的名稱

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

3)功能模塊明

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

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

6)本測試用例與其餘測試用例間的依賴關係

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

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

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

10)預期結果（這是最重要的）和實際結果（若是有bug管理工具，這條能夠省略）

11)開發人員（必須有）和測試人員（無關緊要）

12)測試執行日期

 

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

項目/軟件	技術出口合同網絡申領系統	程序版本	1.0.25
功能模塊名	Login	編制人	xxx
用例編號	TC-TEP_Login_1	編制時間	2000.1.1
相關的用例	無
功能特性	用戶身份驗證
測試目的	驗證是否輸入合法的信息，容許合法登陸，阻止非法登陸
預置條件	無	特殊規程說明	如數據庫訪問權限
參考信息	需求說明中關於「登陸」的說明
測試數據	用戶名=yiyh 密碼=1

 

 

 

操做步驟	操做描述	數據	指望結果	預期結果	實際結果	測試狀態
1	輸入用戶名稱按「登陸」按鈕	用戶名=yiyh 密碼爲空	顯示警告信息「請輸入用戶名和密碼」
2	輸入密碼，按「登陸 」按鈕	用戶名爲空 密碼=1	顯示警告信息「請輸入用戶名和密碼」
3	輸入用戶名和密碼，按「登陸」按鈕	用戶名=xxx 密碼 =2	顯示警告信息「請輸入用戶名和密碼」
4	輸入用戶名和密碼，按「登陸」按鈕	用戶名=xxx 密碼 =1	顯示警告信息「請輸入用戶名和密碼」
5	輸入用戶名和密碼，按「登陸」按鈕	用戶名=xxx 密碼 =2	顯示警告信息「請輸入用戶名和密碼」
6	輸入用戶名和密碼，按「登陸」按鈕	用戶名=空 密碼 =空	顯示警告信息「請輸入用戶名和密碼」
7	輸入用戶名和密碼，按「登陸」按鈕	用戶名=yiyh 密碼 =1	進入系統界面
8	輸入用戶名和密碼，按「登陸」按鈕	用戶名=Admin密碼 =admin	進入系統界面
9	輸入用戶名和密碼，按「登陸」按鈕	用戶名=yiyh’密碼 =1	顯示警告信息「請輸入用戶名和密碼」
10	輸入用戶名和密碼，按「登陸」按鈕	用戶名=yiyh 密碼 =1’	顯示警告信息「請輸入用戶名和密碼」
11	輸入用戶名和密碼，按「登陸」按鈕	用戶名=yiyh 密碼 =1	清空輸入信息
測試人員		開發人員			項目負責人