軟體測試用例的認識誤區

2021-05-21 19:01:04 字數 1617 閱讀 3013

軟體測試用例是為了有效發現軟體缺陷而編寫的包含測試目的、測試步驟、期望測試結果的特定集合。正確認識和設計軟體測試用例可以提高軟體測試的有效性,便於測試質量度量,增強測試過程的可管理性。

在實際軟體專案測試過程中,由於對軟體測試用例的作用和設計方法的理解不同,測試人員(特別是剛從事軟體測試的新人)對軟體測試用例存在不少錯誤的認識,給實際軟體測試帶來了負面影響,本文對這些認識誤區進行列舉和剖析。

誤區之一:測試輸入資料設計方法等同於測試用例設計方法

現在一些測試書籍和文章中講到軟體測試用例的設計方法,經常有這樣的表述:測試用例的設計方法包括:等價類、邊界值、因果圖、錯誤推測法、場景設計法等。這種表述是很片面的,這些方法只是軟體功能測試用例設計中如何確定測試輸入資料的方法,而不是測試用例設計的全部內容。

這種認識的不良影響可能會使不少人認為測試用例設計就是如何確定測試的輸入資料,從而掩蓋了測試用例設計內容的豐富性和技術的複雜性。如果測試用例設計人員把這種認識拿來要求自己,則害了自己;拿來教人,則害了別人;拿來指導測試,則害了測試團隊。聽起來似乎是「小題大做」,但是絕不是「危言聳聽」。

無疑,對於軟體功能測試和效能測試,確定測試的輸入資料很重要,它決定了測試的有效性和測試的效率。但是,測試用例中輸入資料的確定方法只是測試用例設計方法的乙個子集,除了確定測試輸入資料之外,測試用例的設計還包括如何根據測試需求

、設計規格說明等文件確定測試用例的設計策略、設計用例的表示方法和組織管理形式等問題。

在設計測試用例時,需要綜合考慮被測軟體的功能、特性、組成元素、開發

階段(里程碑)、測試用例組織方法(是否採用測試用例的資料庫

管理)等內容。具體到設計每個測試用例而言,可以根據被測模組的最小目標,確定測試用例的測試目標;根據使用者使用環境確定測試環境;根據被測軟體的複雜程度和測試用例執行人員的技能確定測試用例的步驟;根據軟體需求文件和設計規格說明確定期望的測試用例執行結果。

誤區之二:強調測試用例設計得越詳細越好

在確定測試用例設計目標時,一些專案管理人員強調測試用例「越詳細越好」。具體表現在兩個方面:盡可能設計足夠多的設計用例,測試用例的數量閱讀越好;測試用例盡可能包括測試執行的詳細步驟,達到「任何乙個人都可以根據測試用例執行測試」,追求測試用例越詳細越好。

這種做法和觀點最大的危害就是耗費了很多的測試用例設計時間和資源,可能等到測試用例設計、評審完成後,留給實際執行測試的時間所剩無幾了。因為當前軟體公司的專案團隊在規劃測試階段,分配給測試的時間和人力資源是有限的,而軟體專案的成功要堅持「質量、時間、成本」的最佳平衡,沒有足夠多的測試執行時間,就無法發現更多的軟體缺陷,測試質量更無從談起了。

編寫測試用例的根本目的是有效地找出軟體可能存在的缺陷,為了達到這個目的,需要分析被測試軟體的特徵,運用有效的測試用例設計方法,盡量使用較少的測試用例,同時滿足合理的測試需求覆蓋,從而達到「少花時間多辦事」的效果。

軟體測試 用例

三 什麼是測試用例的有效性 四 測試用例的粒度和評價 軟體測試 用例 本節重點 1.測試用例的基本要素 2.測試用例的設計方法 3.測試用例的有效性 4.測試用例的粒度和評價 測試用例就是向被測試系統發起的一組集合,包含測試資料,測試環境,操作步驟,預期結果 要素 測試前期 測試版本 功能模組 重要...

軟體測試與軟體測試用例

程式設計要寫 測試要寫用例。做了這麼多年的軟體測試工作,經歷了對測試用例認識的不同階段。第一階段,入門。編號,測試點,測試環境,測試資料,測試步驟,預期結果,設計人,設計時間,執行結果,執行時間,備註。所有的一切都要寫的清清楚楚,詳詳細細。設計 評審 修改,迴圈往復。這個階段提到的有關測試用例設計最...

toft 測試用例rat 軟體測試用例型別

rat rat release acceptance test 發布驗收測試 rat又稱為構建驗證測試或者煙霧測試,rat會在每個開發版本發布之後進行。以確定系統處於穩定狀態 所有的主要功能都具備並且能夠在 正常 條件下執行的測試用例。rat用來評斷這個build能否進行後續的測試,如果rat測試失...