軟件測試中的功能測試用例的書寫方式
測試用例（Test Case）是為某個特殊目標而編制的一組測試輸入、執行條件以及預期結果，以便測試某個程序路徑或核實是否滿足某個特定需求。
測試用例（Test Case）目前沒有經典的定義。比較通常的說法是：指對一項特定的軟件產品進行測試任務的描述，體現測試方案、方法、技術和策略。內容包括測試目標、測試環境、輸入數據、測試步驟、預期結果、測試腳本等，并形成文檔。
不同類別的軟件，測試用例是不同的。不同于諸如系統、工具、控制、游戲軟件，管理軟件的用戶需求更加不統一，變化更大、更快。筆者主要從事企業管理軟件的測試。因此我們的做法是把測試數據和測試腳本從測試用例中劃分出來。測試用例更趨于是針對軟件產品的功能、業務規則和業務處理所設計的測試方案。對軟件的每個特定功能或運行操作路徑的測試構成了一個個測試用例。
隨著中國軟件業的日益壯大和逐步走向成熟，軟件測試也在不斷發展。從最初的由軟件編程人員兼職測試到軟件公司組建獨立專職測試部門。測試工作也從簡單測試演變為包括：編制測試計劃、編寫測試用例、準備測試數據、編寫測試腳本、實施測試、測試評估等多項內容的正規測試。測試方式則由單純手工測試發展為手工、自動兼之，并有向第三方專業測試公司發展的趨勢。
要使最終用戶對軟件感到滿意,最有力的舉措就是對最終用戶的期望加以明確闡述，以便對這些期望進行核實并確認其有效性。測試用例反映了要核實的需求。然而，核實這些需求可能通過不同的方式并由不同的測試員來實施。例如，執行軟件以便驗證它的功能和性能，這項操作可能由某個測試員采用自動測試技術來實現；計算機系統的關機步驟可通過手工測試和觀察來完成；不過，市場占有率和銷售數據（以及產品需求），只能通過評測產品和競爭銷售數據來完成。
既然可能無法（或不必負責）核實所有的需求，那么是否能為測試挑選最適合或最關鍵的需求則關系到項目的成敗。選中要核實的需求將是對成本、風險和對該需求進行核實的必要性這三者權衡考慮的結果。
確定測試用例之所以很重要，原因有以下幾方面。
測試用例構成了設計和制定測試過程的基礎。 測試的“深度”與測試用例的數量成比例。由于每個測試用例反映不同的場景、條件或經由產品的事件流，因而，隨著測試用例數量的增加，您對產品質量和測試流程也就越有信心。 判斷測試是否完全的一個主要評測方法是基于需求的覆蓋，而這又是以確定、實施和/或執行的測試用例的數量為依據的。類似下面這樣的說明：“95 % 的關鍵測試用例已得以執行和驗證”，遠比“我們已完成 95 % 的測試”更有意義。 測試工作量與測試用例的數量成比例。根據全面且細化的測試用例，可以更準確地估計測試周期各連續階段的時間安排。 測試設計和開發的類型以及所需的資源主要都受控于測試用例。 測試用例通常根據它們所關聯關系的測試類型或測試需求來分類，而且將隨類型和需求進行相應地改變。最佳方案是為每個測試需求至少編制兩個測試用例：
·一個測試用例用于證明該需求已經滿足，通常稱作正面測試用例； ·另一個測試用例反映某個無法接受、反�；蛞馔獾臈l件或數據，用于論證只有在所需條件下才能夠滿足該需求，這個測試用例稱作負面測試用例。
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. 給出一個測試用例的例子該范例已經包含一個測試用例的模板。
備注：本用例未考慮“企業代碼”的輸入情況;測試用例并未涵蓋所有的非法輸入，如非法輸入中可能會有
“user=*,pw=*”的組合，對回車的默認操作，空格輸入，對輸入上溢的處理的處理(可能會跳過身份驗證) 等等。
如果你有興趣，至少可以再補充5-10條左右的輸入組合
(當然，如果步驟超過15步，用例的易操作 性就降低，你可以再創建一個測試用例如TC-TEP_Login_2)。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
