一、關鍵字測試用例的編寫
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.執行完測試用例后進行隨機測試。