軟件測試中的功能測試用例的書(shū)寫(xiě)方式
測試用例（Test Case）是為某個(gè)特殊目標而編制的一組測試輸入、執行條件以及預期結果，以便測試某個(gè)程序路徑或核實(shí)是否滿(mǎn)足某個(gè)特定需求。
測試用例（Test Case）目前沒(méi)有經(jīng)典的定義。比較通常的說(shuō)法是：指對一項特定的軟件產(chǎn)品進(jìn)行測試任務(wù)的描述，體現測試方案、方法、技術(shù)和策略。內容包括測試目標、測試環(huán)境、輸入數據、測試步驟、預期結果、測試腳本等，并形成文檔。
不同類(lèi)別的軟件，測試用例是不同的。不同于諸如系統、工具、控制、游戲軟件，管理軟件的用戶(hù)需求更加不統一，變化更大、更快。筆者主要從事企業(yè)管理軟件的測試。因此我們的做法是把測試數據和測試腳本從測試用例中劃分出來(lái)。測試用例更趨于是針對軟件產(chǎn)品的功能、業(yè)務(wù)規則和業(yè)務(wù)處理所設計的測試方案。對軟件的每個(gè)特定功能或運行操作路徑的測試構成了一個(gè)個(gè)測試用例。
隨著(zhù)中國軟件業(yè)的日益壯大和逐步走向成熟，軟件測試也在不斷發(fā)展。從最初的由軟件編程人員兼職測試到軟件公司組建獨立專(zhuān)職測試部門(mén)。測試工作也從簡(jiǎn)單測試演變?yōu)榘ǎ壕幹?FONT color=#136ec2>測試計劃、編寫(xiě)測試用例、準備測試數據、編寫(xiě)測試腳本、實(shí)施測試、測試評估等多項內容的正規測試。測試方式則由單純手工測試發(fā)展為手工、自動(dòng)兼之，并有向第三方專(zhuān)業(yè)測試公司發(fā)展的趨勢。
要使最終用戶(hù)對軟件感到滿(mǎn)意,最有力的舉措就是對最終用戶(hù)的期望加以明確闡述，以便對這些期望進(jìn)行核實(shí)并確認其有效性。測試用例反映了要核實(shí)的需求。然而，核實(shí)這些需求可能通過(guò)不同的方式并由不同的測試員來(lái)實(shí)施。例如，執行軟件以便驗證它的功能和性能，這項操作可能由某個(gè)測試員采用自動(dòng)測試技術(shù)來(lái)實(shí)現；計算機系統的關(guān)機步驟可通過(guò)手工測試和觀(guān)察來(lái)完成；不過(guò)，市場(chǎng)占有率和銷(xiāo)售數據（以及產(chǎn)品需求），只能通過(guò)評測產(chǎn)品和競爭銷(xiāo)售數據來(lái)完成。
既然可能無(wú)法（或不必負責）核實(shí)所有的需求，那么是否能為測試挑選最適合或最關(guān)鍵的需求則關(guān)系到項目的成敗。選中要核實(shí)的需求將是對成本、風(fēng)險和對該需求進(jìn)行核實(shí)的必要性這三者權衡考慮的結果。
確定測試用例之所以很重要，原因有以下幾方面。
測試用例構成了設計和制定測試過(guò)程的基礎。 測試的“深度”與測試用例的數量成比例。由于每個(gè)測試用例反映不同的場(chǎng)景、條件或經(jīng)由產(chǎn)品的事件流，因而，隨著(zhù)測試用例數量的增加，您對產(chǎn)品質(zhì)量和測試流程也就越有信心。 判斷測試是否完全的一個(gè)主要評測方法是基于需求的覆蓋，而這又是以確定、實(shí)施和/或執行的測試用例的數量為依據的。類(lèi)似下面這樣的說(shuō)明：“95 % 的關(guān)鍵測試用例已得以執行和驗證”，遠比“我們已完成 95 % 的測試”更有意義。 測試工作量與測試用例的數量成比例。根據全面且細化的測試用例，可以更準確地估計測試周期各連續階段的時(shí)間安排。 測試設計和開(kāi)發(fā)的類(lèi)型以及所需的資源主要都受控于測試用例。 測試用例通常根據它們所關(guān)聯(lián)關(guān)系的測試類(lèi)型或測試需求來(lái)分類(lèi)，而且將隨類(lèi)型和需求進(jìn)行相應地改變。最佳方案是為每個(gè)測試需求至少編制兩個(gè)測試用例：
·一個(gè)測試用例用于證明該需求已經(jīng)滿(mǎn)足，通常稱(chēng)作正面測試用例； ·另一個(gè)測試用例反映某個(gè)無(wú)法接受、反�；蛞馔獾臈l件或數據，用于論證只有在所需條件下才能夠滿(mǎn)足該需求，這個(gè)測試用例稱(chēng)作負面測試用例。
1. 測試的來(lái)源，即測試的需求
測試用例的主要來(lái)源有：
1) 需求說(shuō)明”及相關(guān)文檔
2)相關(guān)的設計說(shuō)明(概要設計，詳細設計等)
3)與開(kāi)發(fā)組交流對需求理解的 記錄(可以是開(kāi)發(fā)人員的一個(gè)解釋)
4)已經(jīng)基本成型的UI(可以有針對性地補充一些用例)
簡(jiǎn)而言之，所有你能得到的項目文檔，都盡量拿到。 從所得到的資料中，分解出若干小的“功能點(diǎn)”，理解“功能點(diǎn)”，編寫(xiě)相應的測試用例。
2. 用例的組織方式
不同的公司有不同的做法，原則上，只要方便管理和跟蹤，怎么組織都可以的。
用例可以按大的功能塊組織，如查詢(xún)功能模塊的用例，可以組織在一起，打印模塊的測試用例，可以另外組 織在一起。
在沒(méi)有專(zhuān)門(mén)的測試用例管理工具的情況下，用例執行后會(huì )產(chǎn)生2種狀態(tài)：“通過(guò)”、“失敗”——這樣加上“未 執行”的用例的狀態(tài)，共3種狀態(tài)。
即從“未執行”用例中執行一個(gè)用例后，該用例狀態(tài)應為“失敗”或“通 過(guò)”。將同一狀態(tài)的用例組織在一起。
至于用例文件格式，可以是.DOC或.XLS(如果有專(zhuān)門(mén)的測試用例管理工具另當別論)。
3. 用例與其他材料的關(guān)聯(lián)方式，即如何解決用例跟蹤的問(wèn)題 測試用例面臨的比較大的風(fēng)險有：
需求的變更、設計的修改、需求的錯誤和遺漏等等。
由于用例的主要來(lái)源是需求和設計的說(shuō)明，所以對用例的跟蹤其實(shí)就是對需求和設計的跟蹤，需求和設計的 變更勢必引起測試用例的變更。
如前所說(shuō)，將分解的功能點(diǎn)編號，與相應的用例聯(lián)系起來(lái)。例如，你可以列一個(gè)表格，列出各個(gè)(編號的)功 能點(diǎn)和測試用例間的關(guān)聯(lián)關(guān)系。
這樣，當需求和設計發(fā)生變化時(shí)，你只需要跟蹤“功能點(diǎn)”是否變化，是否增 加了新的功能點(diǎn)。
重要和困難的是，不手頭的資料和信息一定要是最新的。
4. 一個(gè)好的用例的表述要點(diǎn)，即用例中應當包含的信息
一個(gè)優(yōu)秀的測試用例，應該包含以下信息：
1) 軟件或項目的名稱(chēng)
2) 軟件或項目的版本(內部版本號)
3) 功能模塊名
4) 測試用例的簡(jiǎn)單描述，即該用例執行的目的或方法
5) 測試用例的參考信息(便于跟蹤和參考)
6) 本測試用例與其他測試用例間的依賴(lài)關(guān)系
7) 本用例的前置條件，即執行本用例必須要滿(mǎn)足的條件，如對數據庫的訪(fǎng)問(wèn)權限
8) 用例的編號(ID)，如可以是 軟件名稱(chēng)簡(jiǎn)寫(xiě)-功能塊簡(jiǎn)寫(xiě)-NO.。
9) 步驟號、操作步驟描述、測試數據描述
10)預期結果(這是最重要的)和實(shí)際結果(如果有BUG管理工具，這條可以省略)
11)開(kāi)發(fā)人員(必須有)和測試人員(可有可無(wú))
12)測試執行日期
5. 給出一個(gè)測試用例的例子該范例已經(jīng)包含一個(gè)測試用例的模板。
備注：本用例未考慮“企業(yè)代碼”的輸入情況;測試用例并未涵蓋所有的非法輸入，如非法輸入中可能會(huì )有
“user=*,pw=*”的組合，對回車(chē)的默認操作，空格輸入，對輸入上溢的處理的處理(可能會(huì )跳過(guò)身份驗證) 等等。
如果你有興趣，至少可以再補充5-10條左右的輸入組合
(當然，如果步驟超過(guò)15步，用例的易操作 性就降低，你可以再創(chuàng )建一個(gè)測試用例如TC-TEP_Login_2)。
文章來(lái)源于領(lǐng)測軟件測試網(wǎng) http://kjueaiud.com/
