淺析軟件測試用例管理
2.2 測試用例執行結果分析
測試用例執行結果可以從覆蓋率、執行率、通過率等幾個方面進行分析和考察。測試用例覆蓋率是指測試用例覆蓋的功能與測試需求功能的比值;測試用例執行率是指已執行的測試用例數與測試用例總數的比值;測試用例通過率是指成功執行的測試用例數與測試用例總數的比值。
測試用例的覆蓋率需要達到100%,也就是說,測試用例必須覆蓋全部的測試需求,否則測試用例的設計則是不全面的,無法保證測試質量,需要補充或者重新設計相應測試用例。測試用例執行率是衡量測試效率的因素,一般說來,在測試完成時測試用例的執行率也需要達到100%,也可能因為某些特殊原因導致測試中斷而沒有全部執行測試用例,可針對具體的情況進行分析。測試用例通過率是衡量用例本身設計質量和被測軟件質量的因素,對于未能成功執行的測試用例,要分析是用例設計錯誤還是被測軟件錯誤,導致用例無法順利執行。
3、測試用例維護
軟件產品的版本是隨著軟件的升級而不斷變化的,而每一次版本的變化都會對測試用例集產生影響,所以測試用例集也需要不斷地變更和維護,使之與產品的變化保持一致。以下原因可能導致測試用例變更:
1)軟件需求變更:軟件需求變更可能導致軟件功能的增加、刪除、修改等變化,應遵循需求變更控制管理方法,同樣變更的測試用例也需要執行變更管理流程。
2)測試需求的遺漏和誤解:由于測試需求分析不到位,可能導致測試需求遺漏或者誤解,相應的測試用力也要進行變更。特別是對于軟件隱性需求,在測試需求分析階段容易遺漏,而在測試執行過程中被發現,這時需要補充測試用例。
3)測試用例遺漏:在測試過程中,發現測試用例未覆蓋全部需求,需要補充相應的測試用例。
4)軟件發布后,用戶反饋的缺陷:表明測試不全面,存在尚未發現的缺陷,需要補充或者修改測試用例。
對于提供軟件服務的產品,其多個版本常常共存,而對應的測試用例也是共存的,而且測試用例需要專人定期維護,并遵循以下原則:
(1)及時刪除過時的測試用例
需求變更可能導致原有部分測試用例不再適合新的需求要求。例如,刪除了某個功能,那么針對該功能的測試用例也不再需要。所以隨著需求的每一次變更,都要刪除那些不再使用的測試用例。
(2)及時刪除冗余的測試用例
在設計測試用例時,可能存在兩個或者多個用例測試相同內容,降低回歸測試效率,所以要定期整理測試用例集,及時刪除冗余的測試用例。
(3)增加新的測試用例
由于需求變更、用例遺漏或者版本發布后發現缺陷等原因,原有的測試用例集沒有完全覆蓋軟件需求,需要增加新的測試用例。
(4)改進測試用例
隨著開發工作進行,測試用例不斷增加,可能會出現一些對輸入或者運行狀態比較敏感的測試用例。這些用例難以重用,影響回歸測試的效率,需要進行改進,使之可重用可控制。
總之,測試用例的維護是一個長期的過程,也是一個不斷改進和完善的過程。
4、總結
測試用例管理是軟件測試過程中的重要內容,測試用例的好壞對軟件測試質量有著重要的影響。本文介紹了測試用例的開發、執行及維護等管理過程,為測試過程中的用例設計提出相關建議,同時也希望從測試用例設計的角度為軟件開發提供參考。摘要:開發和維護測試用例是軟件測試過程中的重要步驟之一,也是衡量軟件測試質量的核心影響因素。本文從開發、執行和維護幾方面對測試用例管理過程進行分析,提出了測試用例開發、維護的相關原則。
關鍵字:軟件測試;測試用例
1、測試用例開發
1.1 測試用例編寫依據
一般說來,測試需求就是為了達到測試目標,項目中需要測試什么。測試過程中所有活動都可以追溯到測試需求。例如,制定測試計劃時,需要明確以下基本要素:首先需要明確測試需求,也就是測試的目標內容;然后才能決定怎么測,即采用什么測試方法;再評估需要多少測試時間,需要多少測試人員,也就是測試的進度安排;最后明確測試的環境是什么。此外,還包括其他因素,例如測試中需要的技能、工具以及相應的專業背景知識,測試中可能遇到的風險等,以上所有的內容結合起來就構成了測試計劃的基本要素。制定測試計劃的重要依據就是測試需求,而測試計劃中的所有內容都可以追溯到測試需求,所以說測試需求是測試計劃的基礎與重點。同樣的,測試方案、用例、內容都要以測試需求為基礎。
測試需求是從軟件需求映射而來,所以其詳細程度與軟件需求的詳細程度有密切關系。在編寫時,在保證與軟件需求一致的前提下,力求表達準確詳細,避免測試的遺漏與誤解。
測試用例的編寫應該覆蓋所有的測試需求,而測試需求是由軟件需求轉換而來,因此所有測試用例的執行結果最終都會追溯到軟件需求,因此測試用例的編寫依據主要是軟件需求。此外,還應遵守相關的編寫規則、規范等。
1.2 測試用例開發原則
測試用例的設計原則包括:
1)依據原則:測試用例編寫的主要依據為項目提供的需求說明書和相關技術規范文檔;
2)全覆蓋原則:對于需求說明書和相關技術規范中要求的主要功能點進行全覆蓋測試,要求所有功能均能正常實現;
3)規范原則:所有測試案例的編寫要求規范,對于所有被測的功能點,應用程序均應該按照需求說明書和相關技術規范中的給定形式,在規定的邊界值范圍內使用相應的工具、資源和數據執行其功能;
4)全面原則:測試不僅僅針對系統功能特性進行測試,對系統的其他質量特性也進行全面的測試與評估。
測試用例編寫應該滿足的具體量化要求包括如下幾點:
(1)用戶經常使用、關系到系統核心功能、優先級別較高的功能點,測試用例應該達到100%覆蓋率;
(2)針對各個系統端到端的功能以及與其它系統的接口的測試應該達到100%覆蓋率;
(3)測試用例包括正常輸入和正常業務流程測試,也包括對非法數據輸入和異常處理的測試,且對系統非正常操作的測試用例應占到總數的20%-30%;
(4)測試用例中包括中文特性及系統本地化測試,如中文信息的顯示、錄入、查詢、打印和報表顯示測試等。
2、測試用例執行
2.1 測試用例對測試需求的覆蓋
首先看一下什么是測試需求覆蓋。測試需求來源于軟件需求,與軟件需求的關系是一對一,或者是多對一。如果一個軟件需求可以轉換為一個或者多個測試需求,那么測試需求已經覆蓋了全部的軟件需求,可以說測試需求的覆蓋率為100%。但是這不能說明測試需求的覆蓋程度達到了100%。因為一般的軟件需求只明確了顯性的功能與特性,而隱性的功能與特性(沒有被明確指出但是卻應該具有的功能和特性)并沒有在需求中直接體現。這部分需求也應該成為測試需求,因此在進行測試需求分析時,要同時分析軟件的顯性和隱性需求,或者根據實際測試中發現的缺陷,對測試需求進行補充或優化,并更新測試用例,以此來提高測試需求的覆蓋程度。
好的測試用例集應該覆蓋全部的測試需求。以系統功能舉例說來,測試用例包括功能點和業務流程。對于功能點,設計的測試用例需要覆蓋全部需求中的功能點,除了正常情況的測試用例,還應設計異常情況的測試用例,且異常情況測試用例占整個測試用例集的20%~30%。同樣的,業務流程的測試用例也包含正常流程和異常流程。