淺談功能測試用例 軟件測試
一、功能測試用例的書寫方式
功能性測試用例
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）
二、功能測試用例模板設計
測試用例設計和執行是測試工作的核心，也是工作量最大的任務之一，設計良好的測試用例模板能提高測試用例的設計質量，便于跟蹤測試用例的執行結果，自動生成測試用例覆蓋率報告。這幾年測試技術和理論有了長足的發展，就功能測試用例設計要素而言，樣式上均大同小異，一般都包含主題、前置條件、執行步驟、期望結果等。
測試用例可以用數據庫、Word 、Excel 、xml 等格式進行管理，市面亦有成熟的商業軟件工具和開源工具等，對于一般中小軟件企業，使用文檔來管理測試用例是較為方便、經濟的途徑。 Word 格式的文檔可以滿足設計需要，但不利于跟蹤和自動統計執行結果報告。下面我將介紹自己在多個項目中設計和改進的 Excel 模版，它可以方便地設計測試用例，記錄執行結果并自動統計測試用例覆蓋率。
測試用例 ID —— 用于唯一標識測試用例號，可根據自身需要定義規則，最好易于跟蹤和維護；
測試前置條件 —— 如果有則描述之；
測試用例等級 —— 根據需求重要性區分測試用例等級，測試執行階段可以根據測試用例等級安排測試任務，分為四級：
• 冒煙測試，即版本確認測試，每個測試版本需通過所有該級測試用例，否則拒絕繼續測試；
• 關鍵路徑測試，每個測試版本需執行該級測試用例，若該級測試用例均通過，意味著軟件功能趨于穩定；
• 可接受級測試，該級測試用例只要執行一次通過即可，該級測試用例通過意味著可以準備發布了；
• 建議執行的用例，如果有時間，最好執行該級測試用例，但不作為發布的必要條件。
測試用例執行步驟、期望結果；
測試用例執行結果 —— 執行時填寫，分為通過、失敗、警告、阻塞、忽略。
通過開發 VBA 腳本，可以自動統計每輪測試用例執行結果，得到測試用例覆蓋率結果報告，用于分析測試結果。
測試用例狀態轉換分析
隊列中（ In Queue ） -- 測試用例在排隊等待中；
進程中（ In Progress ） -- 表示測試正在進行，并且可能會持續一段時間，如果一個測試花費的時間少于一天或兩天，只需將它顯示在處于排隊狀態；
阻塞（ Block ） -- 一些外部條件 — 如缺少部分功能 — 將無法執行測試；
忽略（ Skip ） -- 已經決定（或被告知）跳過這個測試用例；
通過（ Pass ） -- 終點狀態，沒問題；
失�。� Fail ） -- 測試用例執行出錯；
警告（ Warn ） -- 結果處于 Pass 和 Fail 之間，錯誤嚴重性等級較輕，不影響功能和性能；
關閉（ Closed ） -- 以前識別出的錯誤都已經被修正。
實際項目中，一個測試用例有多個執行步驟，每個步驟可能有不同結果，如步驟 1 通過，步驟 2 失敗，步驟 3 被步驟 2 中的失敗所阻塞，那么該測試狀態如何？單純指出這個測試用例阻塞或失敗都將遺漏重要的信息。因此必須指定雙重狀態，如 Block/Fail ， Block/Warn ， Skip/Pass ， Skip/Closed 等。然而，如果顯示十幾個狀態，則測試結果可能更難以解釋。如何使結果明了又能精確反映實際結果，需要精明選擇包括哪些狀態。
使用該模板優點：使用維護簡便，方便測試任務分配，易于與項目組其他角色交流，結果報告自動生成。
不足之處：測試變更跟蹤不方便，每個測試用例的規模不等，所以測試覆蓋率結果只是作為參考，結果百分比不能精確反映工作量，需要具體分析項目情況。這個模版沒有跟蹤統計缺陷，同時考慮是否使用加權評估缺陷嚴重性，一個測試用例往往對應幾個缺陷的統計分析。
結論：在實際項目中，應該根據項目特點和開發流程定義測試用例各項。在精確和簡單兩個特性相對立時，需要好好權衡。如果您有好的解決方案，我將很樂意知道。
三、常見的一些功能測試用例
一\登陸、添加、刪除、查詢模塊的測試點
1. 登陸
2. 添加
3. 查詢
4. 刪除
1. 登陸
① 用戶名和密碼都符合要求（格式上的要求）
② 用戶名和密碼都不符合要求（格式上的要求）
③ 用戶名符合要求，密碼不符合要求（格式上的要求）
④ 密碼符合要求，用戶名不符合要求（格式上的要求）
⑤ 用戶名或密碼為空
⑥ 數據庫中不存在的用戶名，不存在的密碼
⑦ 數據庫中存在的用戶名，錯誤的密碼
⑧ 數據庫中不存在的用戶名，存在的密碼
⑨ 輸入的數據前存在空格
⑩ 輸入正確的用戶名密碼以后按[enter]是否能登陸
2. 添加
① 要添加的數據項均合理，檢查數據庫中是否添加了相應的數據
② 留出一個必填數據為空
③ 按照邊界值等價類設計測試用例的原則設計其他輸入項的測試用例
④ 不符合要求的地方要有錯誤提示
⑤ 是否支持table鍵
⑥ 按enter是否能保存
⑦ 若提示不能保存，也要察看數據庫里是否多了一條數據
3. 刪除
① 刪除一個數據庫中存在的數據，然后查看數據庫中是否刪除
② 刪除一個數據庫中并不存在的數據，看書否有錯誤提示，并且數據庫中沒有數據被刪除
③ 輸入一個格式錯誤的數據，看是否有錯誤提示，并且數據庫中沒有數據被刪除。
④ 輸入的正確數據前加空格，看是否能正確刪除數據
⑤ 什么也不輸入
⑥ 是否指出table鍵
⑦ 是否支持enter鍵
4. 查詢
精確查詢：
① 輸入的查詢條件為數據庫中存在的數據，看是否能正確地查出相應得數據
② 輸入正確的查詢條件以前加上空格，看是否能正確地查出相應的數據
③ 輸入格式或范圍不符合要求的數據，看是否有錯誤提示
④ 輸入數據庫中不存在的數據
⑤ 不輸入任何數據
⑥ 是否支持table鍵
⑦ 是否支持enter鍵
模糊查詢：
在精確查詢的基礎上加上以下一點
① 輸入一些字符，看是否能查出數據庫中所有的相關信息
2\設計功能和界面測試用例
1.1 文本框、按鈕等控件測試
1.1.1 文本框的測試
如何對文本框進行測試
a,輸入正常的字母或數字。
b,輸入已存在的文件的名稱；
c,輸入超長字符。例如在“名稱”框中輸入超過允許邊界個數的字符，假設最多255個字符，嘗試輸入 256個字符，檢查程序能否正確處理；
d,輸入默認值，空白，空格；
e,若只允許輸入字母，嘗試輸入數字；反之；嘗試輸入字母；
f,利用復制，粘貼等操作強制輸入程序不允許的輸入數據；
g,輸入特殊字符集，例如，NUL及\n等；
h,輸入超過文本框長度的字符或文本，檢查所輸入的內容是否正常顯示；
i,輸入不符合格式的數據，檢查程序是否正常校驗，如，程序要求輸入年月日格式為yy/mm/dd，實際輸入yyyy/mm/dd，程序應該給出錯誤提示
在測試過程中所用到的測試方法：
1,輸入非法數據；
2,輸入默認值；
3,輸入特殊字符集；
4,輸入使緩沖區溢出的數據；
5,輸入相同的文件名；
命令按鈕控件的測試
測試方法：
a,點擊按鈕正確響應操作。如，單擊確定，正確執行操作；單擊取消，退出窗口；
b,對非法的輸入或操作給出足夠的提示說明，如，輸入月工作天數為32時，單擊”確定“后系統應提示:天數不能大于31；
c,對可能造成數據無法恢復的操作必須給出確認信息，給用戶放棄選擇的機會；
單選按鈕控件的測試
測試方法：
a,一組單選按鈕不能同時選中，只能選中一個。
b,逐一執行每個單選按鈕的功能。分別選擇了“男”“女”后，保存到數據庫的數據應該相應的分別為“男”“女”；
c,一組執行同一功能的單選按鈕在初始狀態時必須有一個被默認選中，不能同時為空；
up－down控件文本框的測試
測試方法：
a,直接輸入數字或用上下箭頭控制，如，在“數目”中直接輸入10，或者單擊向上的箭頭，使數目變為10；
b,利用上下箭頭控制數字的自動循環，如，當最多數字為253時，單擊向上箭頭，數目自動變為1；反之亦適用；
c,直接輸入超邊界值，系統應該提示重新輸入；
d,輸入默認值，空白。如，“插入”數目為默認值，點擊“確定”；或，刪除默認值，使內容為空，單擊“確定”進行測試；
e,輸入字符。此時系統應提示輸入有誤。
組合列表框的測試
測試方法：
a,條目內容正確，其詳細條目內容可以根據需求說明確定；
b,逐一執行列表框中每個條目的功能；
c,檢查能否向組合列表框輸入數據；
復選框的測試
測試方法：
a,多個復選框可以被同時選中；
b,多個復選框可以被部分選中；
c,多個復選框可以都不被選中；
d,逐一執行每個復選框的功能；
列表框控件的測試
測試方法：
a,條目內容正確；同組合列表框類似，根據需求說明書確定列表的各項內容正確，沒有丟失或錯誤；
b,列表框的內容較多時要使用滾動條；
c,列表框允許多選時，要分別檢查shift選中條目，按ctrl選中條目和直接用鼠標選中多項條目的情況；
滾動條控件的測試
要注意一下幾點：
a,滾動條的長度根據顯示信息的長度或寬度及時變換，這樣有利于用戶了解顯示信息的位置和百分比，如，word中瀏覽100頁文檔，瀏覽到50頁時，滾動條位置應處于中間；
b,拖動滾動條，檢查屏幕刷新情況，并查看是否有亂碼；
c,單擊滾動條；
d,用滾輪控制滾動條；
e,滾動條的上下按鈕。
各種控件在窗體中混和使用時的測試
a,控件間的相互作用；
b,tab鍵的順序，一般是從上到下，從左到右；
c,熱鍵的使用，逐一測試；
d,enter鍵和esc鍵的使用；
在測試中，應遵循由簡入繁的原則，先進行單個控件功能的測試，確保實現無誤后，再進行多個控件的的功能組合的測試。
ps:密碼輸入框測試時要特別注意進行字母大寫輸入的測試。
查找替換操作
案例演示:打開word中的"替換"對話框
測試本功能有通過測試和失敗測試兩種情況
通過測試:
1,輸入內容直接查找,或查找全部
2,在組合框中尋找已經查找過的內容,再次查找并確認文檔的內容正確,如,已經查找過"測試用例",再次進入不用重新輸入查找內容,直接在文檔中搜尋就可以.
失敗測試:
1,輸入過長或過短的查詢字符串.如,假設查詢的字符串長度為1到255,那么輸入0,1,2,256,255和254進行測試;
2,輸入特殊字符集,如,在word中.^g代表圖片,^代表分欄符,可以輸入這類特殊字符測試;
替換測試大體相同.
關于編輯操作窗口的功能測試的用例:
1,關閉查找替換窗口.不執行任何操作,直接退出;
2,附件和選項測試.假如,設定"精確搜尋","向后"搜索等附件選項等等來測試;
3,控件間的相互作用.如,搜尋內容為空時,按鈕"搜尋全部","搜尋","全部替換","替換"都為灰色.
4,熱鍵, Tab鍵.回車鍵的使用.
插入操作
1,插入文件
測試的情況
a,插入文件;
b,插入圖像;
c,在文檔中插入文檔本身;
d,移除插入的源文件;
e,更換插入的源文件的內容;
2,鏈接文件
測試方法:
a,插入鏈接文件;
b,在文檔中鏈接文檔本身;
c,移除插入的源文件;
d,更換插入的源文件的內容.
3,插入對象
要測試的內容
a,插入程序允許的對象,如,在word中插入excel工作表;
b,修改所插入對象的內容.插入的對象仍能正確顯示;
c,卸載生成插入對象的程序,如,在word中插入excel工作表后卸載excel,工作表仍正常使用.
編輯操作
編輯操作包括剪切,復制,粘貼操作.
測試剪切操作的方法
a,對文本,文本框,圖文框進行剪切;
b,剪切圖像
c,文本圖像混合剪切
復制操作方法與剪切類似.
測試時,主要是對粘貼操作的測試,方法是:
a,粘貼剪切的文本,文本框及圖文框;
b,粘貼所剪切的圖像;
c,剪切后,在不同的程序中粘貼
d,多次粘貼同一內容,如,剪切后,在程序中連續粘貼3次;
e,利用粘貼操作強制輸入程序所不允許輸入的數據.
界面測試用例的設計方法
1,窗體
測試窗體的方法:
a,窗體大小,大小要合適,控件布局合理;
b,移動窗體.快速或慢速移動窗體,背景及窗體本身刷新必須正確;
c,縮放窗體,窗體上的控件應隨窗體的大小變化而變化;
d,顯示分辨率.必須在不同的分辨率的情況下測試程序的顯示是否正常;
進行測試時還要注意狀態欄是否顯示正確;工具欄的圖標執行操作是否有效,是否與菜單懶中圖標顯示一致;錯誤信息內容是否正確,無錯別字,且明確等等;
2,控件
測試方法:
a,窗體或控件的字體和大小要一致;
b,注意全角,半角混合
c,無中英文混合.
菜單
進行測試時要注意
a,選擇菜單是否可以正常工作,并與實際執行內容一致;
b,是否有錯別字:
c,快捷鍵是否重復;
d,熱鍵是否重復;
e,快捷鍵與熱鍵操作是否有效
f,是否存在中英文混合
g,菜單要與語境相關,如,不同權限的用戶登陸一個應用程序,不同級別的用戶可以看到不同級別的菜單并使用不同級別的功能;
h,鼠標右鍵快捷菜單
特殊屬性
1,安裝界面應有公司介紹或產品介紹,有公司的圖標
2,主界面及大多數界面最好有公司圖標
3,選擇"幫助"->"關于"命令,應 看見相關版權和產品信息
文章來源于領測軟件測試網 http://www.kjueaiud.com/
