1.測試用例的定義和內容
（一)測試用例的定義
A.、對一項特定的軟件產品進行測試任務的描述，指定輸入，預期結果和一組測試項的執行條件的文檔。
a.體現測試方案、方法、技術和策略；
b.內容包括測試目標、測試環境、輸入數據、測試步驟、預期結果、測試腳本等。
(二）測試用例的元素
A、測試用例必須給出測試測試目標、測試對象、測試環境要求、輸入數據和操作步驟，概括為5W1H。
a. 測試目標：Why——為什么而測？功能、性能、可用性、容錯性、兼容性、安全性等。
b.測試對象：What——測什么？被測試的項目，如對象、函數、類、菜單、按鈕、表格、接口、整個系統等。
c.測試環境：Where——在哪里測？測試用例運行時所處的環境，包括系統的配置和設定等要求，也包括操作系統、瀏覽器、通訊協議等單機或網絡環境。
d.測試前提：When——什么時候可是測？測試用例運行時所處的前提或條件限制。
e.輸入數據：Which——那些數據？在操作時，系統所接受的各種可變化的數據，如數字、字符、文件等。
f.操作步驟：How——如何測？執行軟件和程序的先后次序步驟等。如打開對話框、點擊按鈕等。
2.測試用例的寫作說明
（一)測試用例的格式？模板？
A、序號
a.簡單、唯一。
B、測試說明（或稱測試點、檢查點、測試概述、用例概述、用例說明）：用一句話對測試用例進行概述
a.可以總結測試目的；
b.可以用疑問句表示；
c.可以用“檢查、驗證、測試”等字眼（如驗證QQ默認安裝）；
d.最好看到這句話就能知道如何測試；
e.盡量唯一（因果圖、正交表可能會有重復的測試說明）；
f.用例執行多輪時，越往后執行可能越快，如果用例寫得好，直接看概述就行。
C、初始條件（預置條件、前提條件）
a.初始條件要是一個狀態，而且是靜態的，如管理員已登錄后台；
b.初始條件是第一步操作步驟之前的狀態，不能太遠，不用從頭寫到尾
c.很多項目中不寫預置條件。
D、操作步驟
a.若對數據要求高，需要把數據分離出來；
b.步驟要都有序號；
c.每一步用分號分開，最后用一個句號；
d.每一步必須換行；
e.參數前加冒號（如用戶名：admin）；
f.涉及按鈕界面用【】、“”等成對符號間隔；
g.功能的詳細用例步驟4-6步左右；
h.最后一步一定是個動作，不能寫結果。
E、預期結果
a.是一個狀態；
b.如果參考文檔中有描述，原封不動的抄過來；如果文檔中沒有具體要求，則點要一致，可以有幾個點，如QQ默認安裝，應能啟動、默認選項匹配等；
F、用例狀態
a.通過、失敗、阻塞、未執行、擱置、無效用例…
b.初始條件達不到時，一般用例狀態設置為阻塞。
c.看如何執行用例，執行完關心什么來定。
G、優先級
a.用例的執行順序。
3.測試用例的評審和管理
（一）保證測試用例質量的方法
a.首先，要對用戶需求、服務質量要求、產品特性有深刻且全面的理解
b.其次，采取正確、恰當的方法進行用例設計；
c.再者，按照測試用例的標准格式或規范的模板來書寫測試用例；
d.最后，對測試用例的檢查、評審，也是提高測試用例質量的主要且有效的手段。
（二）測試用例評審要點
a.根據檢查單或檢查表（Check List）進行評審。
（三）測試用例的優先級
（四）如何設置測試用例的優先級
a. 考慮成本、時間、人員等因素。
b.考慮用例的關聯性。
c.考慮用例的干擾性。
d.決定執行用例的先后順序。
（五）注意
a. 兼顧測試充分性和效率。
b.考慮測試執行的可再現性。
（六）測試用例的維護
A、通常情況下，測試用例需要更新，可能有以下幾種原因：
a.先前的測試用例設計不全面或者不夠准確。隨着測試的深入和對產品規格說明書的深入研究，對某些功能、特性、邏輯等的理解越來越清楚、深刻
b.所發現的嚴重的軟件缺陷沒有被目前的測試用例所覆蓋。
c.編寫的測試用例不規范或者語句錯誤。
d.新的版本中有新功能的需求或者原有功能的增強而需要發生改動。
e.舊的測試用例已經不再適用，需要刪除。
（七）使用工具管理測試用例
Excel
Bugfree
ZenTao
ALM/QC
...
4.用例設計方法總結
（一）通過測試
a.主要用於驗證系統和它陳述的需求一致，確認軟件至少能做什么，一般通過分析需求說明書來設計測試用例。
（二）失敗測試
a.純粹為了破壞軟件而設計和執行的測試案例，也稱迫使出錯測試。主要用於證明“一個系統不會做不需要它做的事情” 。
（三）隨機測試
A、也稱即興測試（ad hoc testing），是指臨時准備的、即興的Bug搜索測試過程。
e.g.如果讓一百萬只猴子在一百萬只鍵盤上敲一百萬年，它們最終就可能寫出莎士比亞話劇等巨著。
B、缺點
a.無法度量隨機測試的實際覆蓋率。
b.許多測試都是冗余的。
c.測試數據因為是隨機的，重復測試是不可能的。
（四）應用群集效應
a.找到的軟件缺陷越多，說明那里的軟件缺陷越多，若在測試中發現大量的上邊界條件缺陷，則在測試時應注重上邊界。
b.程序員傾向於修復報告出來的問題，要保證除此之外可能存在的其他問題不會出現。
（五）探索性測試
a.可以說是一種測試思維技術。
b.探索性測試是一種精致的、有思想的過程。
c.探索性測試強調測試設計和測試執行的同時性。
d.測試人員通過測試來不斷學習被測系統，同時把學習到的關於軟件系統的更多信息通過綜合的整理和分析，創造出更多關於測試的主意。
e.測試設計，測試執行，測試日志的記錄似乎是無關緊要的工作。
f.測試人員必須根據測試章程在規定的時間內完成。
g.適合於
- 沒有或只有少量的有價值的文檔
- 常用於在時間壓力下。
- 為補充合適的、正式和形式化測試。
（六）如何選擇測試方法
a.使用大綱法、場景法、因果圖設計測試用例。
- 如果程序的功能說明中含有輸入條件的組合情況，則應在一開始就選用因果圖法。
b.用等價類划分方法、邊界值分析方法、錯誤猜測法補充測試用例。
c.執行測試時進行探索性測試或隨機測試。
d.執行完測試用例后進行隨機測試。