一、關鍵字測試用例的編寫

1.序號

a.簡單、少數。

2.測試說明

或稱測試點、檢查點、測試概述、用例概述、用例說明：用一句話對測試用例進行概述
?a.可以總結測試目的；
b.可以用疑問句表示；
c.可以用“檢查、驗證、測試”等字眼（如驗證QQ默認安裝）；
d.較好看到這句話就能知道如何測試；
e.盡量少數（因果圖、正交表可能會有重復的測試說明）；
f.用例執行多輪時，越往后執行可能越快，如果用例寫得好，直接看概述就行。

3.初始條件（預置條件、前提條件）

a.初始條件要是一個狀態，而且是靜態的，如管理員已登錄后臺； b.初始條件是名列前茅步操作步驟之前的狀態，不能太遠，不用從頭寫到尾
c.很多項目中不寫預置條件。

4.操作步驟

a.若對數據要求高，需要把數據分離出來；
b.步驟要都有序號；
c.每一步用分號分開，最后用一個句號；
d.每一步必須換行；
e.參數前加冒號（如用戶名：admin）；
f.涉及按鈕界面用【】、“”等成對符號間隔；
g.功能的詳細用例步驟4-6步左右；
h.最后一步一定是個動作，不能寫結果。

5.預期結果

a.是一個狀態；
b.如果參考文檔中有描述，原封不動的抄過來；如果文檔中沒有具體要求，則點要一致，可以有幾個點，如QQ默認安裝，應能啟動、默認選項匹配等。

6.用例狀態

a.通過、失敗、阻塞、未執行、擱置、無效用例…
b.初始條件達不到時，一般用例狀態設置為阻塞。
c.看如何執行用例，執行完關心什么來定。

延伸閱讀：

二、用例設計方法總結

通過測試

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.執行完測試用例后進行隨機測試。