測試用例及其注意事項

2021-10-09 17:15:40 字數 2599 閱讀 9865

簡單地說,測試用例就是:

設計乙個情況,軟體程式在這種情況下,必須能夠正常執行並且達到程式所設計的預期結果

有效性:測試用例是測試人員測試過程中的重要參考依據。

可復用性:良好的測試用例具有重複使用的功能,使得測試過程事半功倍,提高測試效率。

易組織性:即使是小的專案,也可能會有幾千甚至更多的測試用例,測試用例可能在數月甚至幾年的測試過 程中被建立和使用。

可評估性:從測試的專案管理角度來說,測試用例的通過率是檢驗**質量的保證。

可管理性:測試用例也可以作為檢驗測試人員進度、工作量以及跟蹤/管理測試人員的工作效率的標準。

測試用例應該包含以下內容:

識別符號:由測試設計過程說明和測試程式說明引用的惟一識別符號

測試項:描述被測試的詳細特性、**模組等,應該比測試設計說明中所列的特性更加具體。還要指出引用 的產品說明書或者測試用例所依據的其他設計文件。

輸入說明:該說明列舉執行測試用例的所有輸入內容或者條件。

輸出說明:描述進行測試用例預期的結果。

環境要求:是指執行測試用例必要的硬體、軟體、測試工具、人員等。

特殊要求:描述執行測試必須的特殊要求。

用例之間的依賴性:如果乙個測試用例依賴於其他用例,或者受其他用例的影響,就應該在此註明。

測試用例在軟體測試中的作用

1、指導測試的實施

測試用例主要適用於整合測試、系統測試和回歸測試

2、規劃測試資料的準備

除正常資料之外,還必須根據測試用例設計大量邊緣資料和錯誤資料。

3、編寫測試指令碼的"設計規格說明書"

為提高測試效率,軟體測試已大力發展自動測試。自動測試的中心任務是編寫測試指令碼。如果說軟體工程中軟體程式設計必須有設計規格說明書,那麼測試指令碼的設計規格說明書就是測試用例。

4、評估測試結果的度量基準

完成測試實施後需要對測試結果進行評估,並且編制測試報告。判斷軟體測試是否完成、衡量測試質量需要一些量化的結果。

5、分析缺陷的標準

通過收集缺陷,對比測試用例和缺陷資料庫,分析確證是漏測還是缺陷復現。漏測反映了測試用例的不完善,應立即補充相應測試用例,最終達到逐步完善軟體質量。而已有相應測試用例,則反映實施測試或變更處理存在問題。

測試用例編號規則

目的:好的測試用例編號,可以更好的去了解此項用例所針對的模組,也有助於記憶和新用例的增加。

規則:測試用例編號採用「版本+細類+編號」的形式。

備註:其中「版本」為設計此測試用例的軟體版本。

「細類」為小模組中的漢字頭乙個字母,以最多5個字母為標準。

「編號」為bug用例的編號,以4位為標準,依次遞增。

例如:引導系統v2.01版本中,候車點設定,用例編號可以書寫為:

​ 2.01_hcdsz_0001

不要設計「窮舉測試用例」

在詳細測試用例與有效測試時間中找到平衡點

好的測試用例應該多關注「反向測試問題」

測試用例庫應該不斷更新和維護

測試用例可以復用,但要注意資料有效性與環境變化

測試用例是設計出來的,不是寫出來的

多去學習經驗豐富的測試工程師所設計的測試用例

針對不同的需求型別和測試物件,靈活採用不同的測試用例設計方法

1、能發現到目前為止沒有發現的缺陷的用例是好的用例:

測試本身是一種「v&v」的活動,測試需要保證以下兩點:

程式做了它應該做的事情

l程式沒有做它不該做的事情

因此,作為測試實施依據的測試用例,必須要能完整覆蓋測試需求,而不應該針對單個的測試用例去評判好壞。

2、測試用例應該詳細記錄所有的操作資訊,使乙個沒有接觸過系統的人員也能進行測試;

測可以先考慮一下測試的目的。測試的目的是盡可能發現程式中存在的缺陷,測試活動本身也可以被看作是乙個project,也需要在給定的資源條件下盡可能達成目標,因此我們必須在測試計畫階段明確測試的目標,一切圍繞測試的目標進行。

測試用例的詳細程度也需要根據需要確定。如果測試用例的執行者、測試用例設計者、測試活動相關人對系統了解都很深刻,那測試用例就沒有必要太詳細了,文件的作用本來就在於溝通,只要能達到溝通的目的就ok。

3、測試用例設計是一勞永逸的事情;

測試用例與需求和設計不同步的情況在實際開發過程中確是屢見不鮮的,測試用例文件是「活的」文件,這一點應該被測試工程師牢記。

4、測試用例不應該包含實際的資料;

測試用例是「一組輸入、執行條件、預期結果」、毫無疑問地應該包括清晰的輸入資料和預期輸出,沒有測試資料的用例最多隻具有指導性的意義,不具有可執行性。

5、測試用例中不需要明顯的驗證手段;

「預期結果」的含義並不只是程式的可見行為。因此,在乙個用例中,還應該包含對測試結果的顯式的驗證手段:在資料庫中執行查詢語句進行查詢,看查詢結果是否與預期的一致。

寫測試用例注意事項

用例狀態等,沒有的不需要填寫。用例設計,一定要可執行 最好2分鐘內能執行完 改進建議 1 用例狀態 請置空 2 用例步驟不要過長,根據目的適當拆分幾條。3 盡量提煉合併,如文字框,下拉列表,文字介面,瀏覽器,平台等等 測試分類 ui ue 通用測試用例 功能衝突測試 併發 與外部系統互動及影響等 相...

編寫測試用例注意事項

一 測試用例的優化問題 1.問題的提出 乙個用例只測乙個控制項,但效率比較低。每條用例只測試乙個控制項的等價類的方法,比較簡單。最大的問題,會有很多資料冗餘,影響測試效率,只適合初學者 2.如何進行優化 對於不同控制項的有效等價類 或有效邊界值 可以在一條用例中同時進行測試,最大化的減少用例的數量。...

測試用例編寫注意事項和編寫方法

注意事項 1 根據專案的實際情況設計測試用例 2 用例格式不是固定的,不能生搬硬套 3 根據具體的情況編寫 編寫方法 1等價類劃分法 黑盒測試 2邊界值分析法 使用邊界值分析法設計測試用例一般與等價類劃分法結合起來 但它不是乙個等價類中任選乙個例子作為代表,而是將測試邊界情況作為目標,選取正好等價 ...