一、測試用例設計的基本原則
在測試用例設計時,除了需要遵守基本的測試用例編寫規范外,還需要遵循些基本的原則。
1盡量避免含糊的測試用例
含糊的測試用例給測試過程帶來網難,甚至會影響測試的結果。在測試過程。}一,測試用例的狀態是惟一的,通常情況下,在執行測試過程。}J,良好的測試用例一般會有二種狀態:通過(PAss)、未通過(Failed)以及未進行測試(Not Done),如果測試術通過,一般會有測試的錯誤(bug)報告進行關聯:如未進行測試,則需要說明原因(測試用例本身的錯誤、測試用例目前不適用、環境因素等),因此,清晰的測試用例使測試人蚰在測試過程中小會出現模棱兩可的情況,不能說這個測試用例部分通過,部分未通過,或者是從這個測試用例描述中小能找到問題,但軟件錯誤應該出現在這個測試用例巾。這樣的測試用例將會給測試人員的判斷帶來團難,吲時也不利于測試過程的跟蹤。
例如,還用上斷的例子來說明,對J:Ij戶登錄的頁面校驗測試進行測試用例鼓計:
· 輸入JF確的用戶和密碼,所有程序工作上【=常。 . 輸入錯誤的用戶和密碼,程序_:|二作小正常,井彈出對話框。
在L而這樣的測試用例設計,未能清楚地描述什么樣是程序正常工作狀態,什么樣是程序不正常工作狀態,這樣含糊不清的測試用例必然會導致測試過程‘{1問題的遺漏。
2盡量將具有相類似功能的測試用例抽象并歸類
一直強調軟件測試過程是無法進行窮舉測試的,因此,對相類似的測試用例的抽象過程顯得尤為重要,一個好測試用倒應該足能代表組或者一系列的測試過程。
3盡量避免冗長和復雜的測試用例
這樣做的主要目的是保證驗證結果的惟一性。這也是和第一條原則相一致的,為的是在測試過程執行過程th確保測試用例的輸出狀態惟性,從而便于跟蹤和管理a在一些很長和復雜的測試用例設討過程中,需要將測試用例進行合理的分解,從而保證測試用例的準確性。在某些時候,rj測試用例包含很多不I司類型的輸入或者輸乩或彳}測試過程的邏輯復雜而幣連續,此時需要對測試用例進行分解。張實際的測試用例設計中,需要將前述的基本原則和考慮兇素結臺起來,遵循基本的測試用例編寫規范。按照實際測試的需求靈活地組織設計測試用倒。 在測試Hj例設計rh E監考慮白盒測試用例年u黑盒測試用例。
二、如何定義測試用例的質量標準
在定義測試用例的質量標準之前,先要了解設計測試用例的目的。測試用例是測試工作中最重要的元素或測試件(test ware)之一,是測試執行的基礎。測試用例不僅能有效地幫助實施后繼的回歸測試、知識的傳遞和測試的管理等,而且更重要的是能更快、更有效地發現缺陷,確保測試的系統性和全面性,在測試的深度和廣度達到所期望的目標。也就是說,測試用例的質量就是滿足測試目標的程度,體現在 “測試覆蓋率和測試執行效率”兩個方面。所以,測試用例最基本的質量標準就是:
達到已定義的或所要求的測試覆蓋率,如大于98%。
使測試執行的效率達到最好的水平,如最有效的途徑并使60%以上的測試用例被測試工具執行。
但是,按照這樣的標準,很難在測試執行前或執行過程中評估測試用例的質量,而不得不在執行完這些測試用例之后進行度量,特別是測試覆蓋率。所以,理想的情況要求在測試用例設計過程中,可以按照某種特定的質量標準對測試用例進行復審(review)、實施評估。那么,這種特定的質量標準是什么呢?
根據多年的實踐經驗,測試用例的標準不能局限于一個層次,因為測試用例設計類似于軟件設計,軟件設計有架構設計(結構設計/概要設計)和詳細設計,所以對于測試用例的質量標準,也應分為兩個層次來考慮:
(1)高層次——滿足某一個測試目標或測試任務來整體看測試用例,衡量一組測試用例的結構、設計思路和覆蓋率等指標。
(2)低層次——從單個測試用例看,衡量其描述的規范性、可理解性和可維護性等指標。
朱少民-軟件測試和質量專欄 版權所有
1.高層次(high-level)標準
高層次標準是從滿足某一個特定的測試目標出發來進行定義,分析一組測試用例的設計思路、設計方法和策略,包括測試用例的層次、結構等。從高層次看,測試用例設計的關鍵點是:始終從客戶需求的角度(出發)想,始終圍繞測試的覆蓋率和執行效率不斷思考,最終通過有效的技術方法完成測試用例的設計。
對于一整套的測試用例組(集合),可定義如下的質量標準:
(1) 測試用例的目標清楚,并能滿足軟件質量的各個方面,包括功能測試、性能測試、安全性測試、故障轉移測試、負載測試等。
(2) 設計思路正確、清晰。例如,通過序列圖、狀態圖、工作流程圖、數據流程圖等來描述待測試的功能特性或非功能特性。
(3) 在組織和分類上,測試用例層次清楚、結構合理。測試用例的層次與產品特性的結構/層次相一致,或者與測試的目標/子目標的分類/層次相一致,并具有合理的優先級或執行順序。
(4) 測試用例覆蓋所有測試點、覆蓋所有已知的用戶使用場景(User scenario),也就是說每個測試點都有相應數量的測試用例來覆蓋,而且將各種用戶使用場景通過矩陣或因果圖等方式列出來,找到相對應的測試用例。
(5) 測試手段的區別對待。在設計測試用例時,就要全面考量測試的手段,哪些方面可以通過工具測試,哪些方面不得不用手工測試,對不同手段的測試用例區別對待。
(6) 有充分的負面測試。作為測試用例,不僅要測試正確的輸入和操作,還要測試各種各樣的例外情況,如邊界條件、不正確的操作、錯誤的數據輸入等。
(7) 沒有重復、冗余的測試用例,滿足相應的行業標準等。
2.低層次(low-level) 標準
低層次標準是考察單個測試用例是否滿足測試的需求,是否能被更有效地執行。測試用例設計的結果就是交付測試用例,使測試用例被執行,所以除了覆蓋率,執行的效率也是測試用例的一個重要屬性。測試用例越清楚,越容易被理解和執行。執行效率越高就說明測試用例越好,如果測試用例能被機器(computer)執行,當然執行效率得到體現。
對于具體的某個測試用例,不妨可定義如下的質量標準:
(1) 測試用例的出發點是發現缺陷,即單個測試用例在“暴露缺陷”上具有較高的可能性。
(2) 測試用例的單一性。一個測試用例面向一個測試點,不要將許多測試點揉在一起。例如,通過一個測試用例發現1~2個缺陷,而不能發現5~10個缺陷甚至更多的缺陷。
(3) 符合測試用例設計規范或測試用例模板,見下面附表所示。
(4) 描述清楚,包括特定的場合、特定的對象和特定的術語,沒有含糊的概念和一般性的描述。例如,測試用例名稱為“登錄功能使用正!,就是一個描述不清楚的例子,而這樣的描述“登錄功能中用戶名大小寫不敏感性驗證”、“登錄功能中用戶名唯一性驗證”和“用戶帳號被鎖定后再進行登錄操作”等就比較好。
(5) 操作步驟的準確性,按照步驟的操作得到唯一的測試結果。
(6) 操作步驟的簡單性。操作步驟不應該太復雜,過于復雜的操作步驟意味著測試用例需要被分解為多個測試用例或者分解為多個環節進行驗證。
(7) 所期望的測試結果是可驗證的,即能迅速、明確地判斷測試的實際結果是否與所期望的結果相同或相匹配。例如,在測試用例中描述期望結果為“登錄成功”,這實際是不可驗證的。要使這個期望結果具有可驗證性,我們就應該這樣描述所期望的結果——“‘退出(log out)’按鈕出現”。
(8) 測試環境的正確性、測試數據的充分性。
(9) 前提條件、依賴性被完全識別出來。
這樣,測試用例具有很好的可理解性和可維護性,可以提高測試執行的效率。并能保證不同的人員執行相同的用例能獲得統一的結果。步驟的準確性和期望結果的可驗證性,非常有助于測試執行的自動化實現。也只有實現了測試執行的自動化,測試執行的效率才是最高的,而且測試人員才有更多的時間去思考、去設計更優秀的測試用例,進入良性循環,相互促進,不斷地提升測試的質量和效率。
附表 測試用例模板
MILY: 宋體; mso-ascii-font-family: 'Times New Roman'; mso-hansi-font-family: 'Times New Roman'">字段名稱 |
類型 |
注釋 |
標志符 |
整型 |
唯一標識該測試用例的值,自動生成 |
測試項 |
字符型 |
測試的對象,可以從軟件配置庫中選擇 |
測試目標 |
字符型 |
從固定列表中選擇一個 |
測試環境要求 |
字符型 |
可從列表中選擇,如果沒有,則直接輸入新增內容 |
前提 |
字符型 |
事先設定、條件限制,如已登錄、某個選項已選上 |
輸入數據 |
字符型 |
輸入要求說明、或數據列舉 |
操作步驟 |
字符型 |
按1., 2., … 操作步驟的順序,準確詳細地描述。 |
期望輸出 |
字符型 |
|
所屬模塊 |
整型 |
模塊標識符。 |
優先級 |
整型 |
1,2,3 (1-優先級最高) |
層次 |
整型 |
0,1,2,3 ( 0 – 最高層) |
關聯的測試用例 |
整型 |
上層(父)用例的標識符。 |
執行時間 |
實型 |
分鐘 |
自動化標識 |
布爾型 |
T,F |
關聯的缺陷 |
枚舉型 |
缺陷標識符列表。 |
文章來源于領測軟件測試網 http://www.kjueaiud.com/