功能測試用例的書寫方式
來自：51cmm.***
發表日期：2004/07/26
功能性測試用例
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）測試執行日期
5. 給出乙個測試用例的例子該範例已經包含乙個測試用例的模板。
專案/軟體
技術出口合同網路申領系統 （企業端）
程式版本
1.0.25
功能模組名
login
編制人
***
用例編號-
tc-tep_login_1
編制時間
2002.10.12
相關的用例
無 功能特性
使用者身份驗證
測試目的
驗證是否輸入合法的資訊，允許合法登陸，阻止非法登陸
預置條件
無 特殊規程說明
如資料庫訪問許可權
參考資訊
需求說明中關於「登陸」的說明
測試資料
使用者名稱=yiyh 密碼=1
操作步驟
操作描述
數 據
期望結果
實際結果
實際結果
測試狀態
1 輸入使用者名稱，按「登陸」按鈕。
使用者名稱=yiyh，密碼為空
顯示警告資訊「請輸入使用者名稱和密碼！」
2 輸入密碼，按「登陸」按鈕。
使用者名為空，密碼=1
顯示警告資訊「請輸入使用者名稱和密碼！」
3 輸入使用者名稱和密碼，按「登陸」按鈕。
使用者名稱=yiyh，密碼=2
顯示警告資訊「請輸入使用者名稱和密碼！」
4 輸入使用者名稱和密碼，按「登陸」按鈕。
使用者名稱=***，密碼=1
顯示警告資訊「請輸入使用者名稱和密碼！」
5 輸入使用者名稱和密碼，按「登陸」按鈕。
使用者名稱=***，密碼=2
顯示警告資訊「請輸入使用者名稱和密碼！」
6 輸入使用者名稱和密碼，按「登陸」按鈕。
使用者名稱=空，密碼=空
顯示警告資訊「請輸入使用者名稱和密碼！」
7 輸入使用者名稱和密碼，按「登陸」按鈕。
使用者名稱=yiyh，密碼=1
進入系統頁面。
8 輸入使用者名稱和密碼，按「登陸」按鈕。
使用者名稱=admin，密碼=admin
進入系統維護頁面。
9 輸入使用者名稱和密碼，按「登陸」按鈕。
使用者名稱=yiyh',密碼=1
顯示警告資訊「請輸入使用者名稱和密碼！」
10 輸入使用者名稱和密碼，按「登陸」按鈕。
使用者名稱=yiyh，密碼=1'
顯示警告資訊「請輸入使用者名稱和密碼！」
11 輸入使用者名稱和密碼，按「重置」按鈕。
使用者名稱=yiyh，密碼=1
清空輸入資訊
測試人員
開發人員
專案負責人
備註：本用例未考慮「企業**」的輸入情況；測試用例並未涵蓋所有的非法輸入，如非法輸入中可能會有
「user=*,pw=*」的組合，對回車的預設操作，空格輸入，對輸入上溢的處理的處理（可能會跳過身份驗證） 等等。
（當然，如果步驟超過15步，用例的易操作 性就降低，你可以再建立乙個測試用例如tc-tep_login_2）。
功能測試用例的書寫方式
功能測試用例的書寫方式 功能性測試用例 1.測試的 即測試的需求 1 需求說明 及相關文件 2 相關的設計說明 概要設計，詳細設計等 3 與開發組交流對需求理解的 記錄 可以是開發人員的乙個解釋 4 已經基本成型的ui 可以有針對性地補充一些用例 簡而言之，所有你能得到的專案文件，都盡量拿到。從所得...
測試用例書寫規範
用例的拆分與劃分 較大的功能建議拆分成不同的用例檔案，方便查閱和載入 同一應用下，按照產品拆分如 工作流，多租賃 同一產品下，按照功能模組拆分，比如登陸，表單，列表，搜尋表單 功能下，不可拆分用例，可以分層書寫用例，可按照不同的功能點做分層 比如列印功能，可分功能點為列印預設詳情頁和指定詳情頁 功能...
測試用例書寫規範
本文摘自 測試架構師修煉之道 乙個通用的模板 測試用例編號 測試用例的唯一標記 用力標題 概述測試用例的主要內容，明確該測試用例的意圖 預置條件 測試用例順利執行的前提條件，如一些基本的配置 測試資料 測試時使用的測試資料 測試步驟 如何執行這個測試用例，每步的操作是什麼 預期結果 和測試步驟對應起...