軟件功能測試用例的設計過程及實踐

摘要：該文介紹了軟件功能測試用例的設計過程在RMDB系統中的實踐，并對測試用例進行評審和追蹤，從而提高功能測試用例的設計效率。

關鍵詞：測試用例；評審；追蹤

中圖分類號：TP311文獻標識碼：A文章編號：1009-3044(2008)32-1131-04

The Process of Design and Practice for Software Functional Test Case

YU Jiu-jiu

(Anhui Wenda Information and Technology College，Hefei 231201，China)

Abstract: The article introduces the process of design software functional test case and practice on RMDB system， reviewing and tracing test case， and improve the efficiency on functional test case design.

Key words: test case; review; trace

1 前言

軟件測試用例就是設計一種情況，軟件程序在這種情況下，希望能夠正常運行并且達到程序事先所設計的執行結果。測試用例由測試輸入數據和預期的輸出結果兩部分組成。軟件測試用例的設計和執行是軟件測試工作的核心，也是工作量最大的任務之一，良好的測試用例設計過程能夠提高測試用例的設計質量，便于跟蹤測試用例的執行結果，自動生成測試用例覆蓋率報告。測試用例可以用數據庫、Word 、Excel 、XML 等格式進行管理，市面亦有成熟的商業軟件工具和開源工具等。對于一般中小軟件企業，使用文檔來管理測試用例是較為方便、經濟的途徑。

2 軟件功能測試用例的設計

軟件功能測試是對軟件系統最基本的一類測試，功能測試用例即指軟件產品在交付于用戶前對其是否達到事先所定義的用戶需求規格說明書上說指定的產品功能要求進行測試的測試用例。它是站在用戶角度上，也是較重要的一類測試用例。

2.1 設計原理

測試用例由測試輸入數據和預期的輸出結果兩部分組成。在設計測試用例的輸入條件中應包括合理的輸入條件和不合理的輸入條件。人們往往傾向于過多地考慮合法的和期望的輸入條件，以檢查程序知否做了它應該做的事情，而忽視了不合法的和預想不到的輸入條件。如果開發出的軟件遇到非法情況不能做出適當的反應，會導致軟件的失效。用不合理的輸入條件測試程序時，會比合理的輸入條件進行測試能發現更多的錯誤。所以就軟件功能測試而言，測試用例設計要從4個方面考慮：

1) 系統功能是否符合需求說明；

2) 系統功能是否完善；

3) 系統功能是否有作用；

4) 系統功能是否無錯誤。

2.2 設計方法

測試用例的設計和編制是軟件測試活動中最重要的。測試用例是測試工作的指導，是軟件測試的必須遵守的準則。更是軟件測試質量穩定的根本保障。

測試用例設計的目的就是將系統需求具體化，提取測試需求，通過可測試的方法對每個功能點進行描述。測試用例設計的好壞直接關系到測試質量的高低。用最少的測試用例覆蓋最全的功能點是測試用例設計的目標。

在測試用例的設計過程中，應用一個有效的測試用例模板對用例的管理，測試的執行具有十分重要的作用。

2.3 功能測試用例組成要素

1) 用例場景：描述該測試用例所驗證的需求用例。通常一個需求用例與多個測試用例對應。對每個需求用例，有時可能需要兩個或多個測試用例與其對應。一個測試用例描述正常工作流情況，另一個或多個描述異常處理工作流。通常異常工作流的測試用例往往是正常工作流測試用例的幾倍。

2) 測試用例序號：每個測試用例都有一個惟一的序列號，用于標識。

3) 測試用例描述：對測試內容的簡單描述，讓閱讀者能夠很快對這個測試用例有個大概的了解。

4) 前置條件：描述執行該測試用例需要滿足什么條件。

5) 步驟：實現測試用例的各個操作。

6) 預期結果：每個測試步驟執行之后的預期結果，是建議需求驗證是否被通過的標準。預期結果不是在測試執行當中才被考慮的，應該在測試用例設計階段由需求分析推導而得。

7) 注釋：填寫測試中應當注意的問題或者說明。注釋不是必須填寫的列，而其他列則是必須要填寫的。

8) 真實結果：每一個發布版本對應真實結果的一列。這一列里填寫測試的真實結果（通過/失敗/不可測/跳過）。如果測試用例執行失敗，需要填寫失敗的詳細結果，以及對應的缺陷號。(注：真實結果也可以在相應的測試報告中填寫)

3 軟件功能測試用例的設計過程在RMDB系統中的實踐

3.1RMDB系統簡介

RMDB系統是某信息公司用來進行人力資源管理和項目分配的數據庫系統，主要用來對當前公司所從事的信息項目進行合理的人員分配，同時管理每個員工的工作信息，個人信息及所在部門的人員行政關系等。該系統還具有對各種類型的員工的工作量進行合理分配并時刻追蹤員工的工作績效等功能。

RMDB系統的功能架構圖如圖1所示。

3.2 功能測試用例（版本）計劃的制定

在功能測試執行之前，需要制定版本的功能測試計劃，對即將進入的測試過程和測試內容進行計劃。版本測試計劃中最難的就是決定選擇哪些功能測試用例，以什么樣的順序來執行，以及預測執行這些測試用例所需要的時間。在實際的項目過程中，由于時間的限制，我們往往無法對系統的每一個版本進行完全的功能測試和回歸測試。因此在有限的時間內選擇怎樣的測試用例集合執行能，能夠減少因為縮減測試用例而帶來的風險，在測試計劃里顯得非常重要。

對于測試測試用例需求復雜度的分析是進行測試執行時間預測的第一步。測試需求的復雜度取決于下列因素：

1) 包含功能驗證點的數目；

2) 測試用例里測試步驟的數目；

3) 執行該測試用例所需環境設置的復雜度。

除了這些因素之外，還需要綜合考慮其他系統因素。通過測試復雜度的分析，我們可以得出一張測試需求復雜度的表。每一個測試用例的復雜度被標記為

‘High’，‘Middle’，‘Low’中的一種。

圖2是RMDB系統中某功能主模塊部分測試用例的測試復雜度分析。

測試用例是在對測試任務進行安排時劃分的最小單位。根據測試經驗對每一個復雜度的測試用例預測一個時間長度。然后可以考慮用MS－ Project對任務進行分配。在分配任務的過程中，需要考慮測試用例之間的依賴性和關聯性，以及測試人員的可用時間（也考慮到一些測試人員可能同時工作在幾個項目上）。

3.3 建立好缺陷分析及預防的系統化流程工作

在測試過程中，需要常常思考怎樣更好地利用以前的測試數據，對今后測試計劃和開發計劃起指導作用。其中對缺陷根本原因的分析，能夠幫助項目管理人員掌握缺陷集中的區域，明晰缺陷發展趨勢，了解缺陷產生的主要原因，以便有針對性地提出遏制缺陷發生的措施，降低缺陷數量，降低測試成本。在今后的測試工作中，測試人員與開發人員一起，建立起一個缺陷分析和預防的流程。

在測試過程中我們針對系統缺陷分析表對系統當前的缺陷狀態和數目進行分析和統計，如果系統某些模塊缺陷數目過多，或者嚴重級別的缺陷數目劇增，我們有必要對這些缺陷進行根本原因的分析。通過分析，可以了解缺陷原因的分布。我們所制定的RMDB系統缺陷分析表如圖3所示。

3.4 RMDB系統功能測試用例的設計及實施

測試用例的設計和編制是軟件測試活動中最重要的。測試用例是測試工作的指導，是軟件測試的必須遵守的準則。更是軟件測試質量穩定的根本保障。

測試用例設計的目的就是將系統需求具體化，提取測試需求，通過可測試的方法對每個功能點進行描述。測試用例設計的好壞直接關系到測試質量的高低。用最少的測試用例覆蓋最全的功能點是測試用例設計的目標。

在測試用例的設計過程中，應用一個有效的測試用例模板對用例的管理，測試的執行具有十分重要的作用。以RMDB測試中的某功能測試用例模板為例。

測試數據工作表中存放每一個測試用例所需要用到的測試數據。同一個測試用例有可能用到不同的數據組合，但是測試步驟是相同的。

測試用例包總結工作表（圖4）中對各個測試周期里以測試包為單位的測試用例執行結果進行統計。通過測試包總結工作表，可以看出每一個測試周期里成功/失敗的測試用例數目，計劃和實際實行的測試用例數目，以及錯誤報告的統計情況。這些數據是我們對某個測試周期的測試結果進行統計的依據。如圖5所示。

3.5 測試用例在軟件測試中的作用

1) 指導測試的實施

測試用例主要適用于集成測試、系統測試和回歸測試。在實施測試時測試用例作為測試的標準，測試人員一定要按照測試用例嚴格按用例項目和測試步驟逐一實施測試。并對測試情況記錄在測試用例管理軟件中，以便自動生成測試結果文檔。

根據測試用例的測試等級，集成測試應測試那些用例，系統測試和回歸測試又該測試那些用例，在設計測試用例時都已作明確規定，實施測試時測試人員不能隨意作變動。

2) 規劃測試數據的準備

在我們的實踐中測試數據是與測試用例分離的。按照測試用例配套準備一組或若干組測試原始數據，以及標準測試結果。尤其象測試報表之類數據集的正確性，按照測試用例規劃準備測試數據是十分必須的。

3) 評估測試結果的度量基準

完成測試實施后需要對測試結果進行評估，并且編制測試報告。判斷軟件測試是否完成、衡量測試質量需要一些量化的結果。例：測試覆蓋率是多少、測試合格率是多少、重要測試合格率是多少，等等。以前統計基準是軟件模塊或功能點，顯得過于粗糙。采用測試用例作度量基準更加準確、有效。

4) 分析缺陷的標準

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

4 測試用例的評審和追蹤

4.1 測試用例的評審

RMDB系統的需求用例業務邏輯較復雜，在迭代開發的過程中隨著新功能的添加而涉及到與局域網內多個數據應用系統的交互。在開發的過程中，測試人員是根據需求用例和業務背景知識設計測試用例的。系統功能測試用例的設計基本上是在開發詳細設計之前完成。由于系統測試用例是系統需求可測試的描述，開發人員在進行代碼開發的過程中結合測試步驟的流程，對代碼設計和開發十分有幫助。

由于測試用例在項目中成為需求的一部分，需要采取一定的流程對測試用例進行評審，以保證測試用例的正確性。測試用例是軟件測試的準則，但它并不是一經編制完成就成為準則。測試用例在設計編寫過程中要組織同級互查。完成編寫后應組織專家評審，需獲得通過才可以使用。評審委員會可由項目負責人、測試、編程、分析設計等有關人員組成，也可邀請客戶代表參加。通常評審測試用例的衡量標準有：

1) 準確：測試用例符合用例描述中所需測試的內容

2) 概要：包括必須的測試步驟

3) 可重復，容易理解：測試用例是一個可重復的實驗。不同的測試人員進行測試可以得出相同的測試結果。如果僅僅只有設計者知道怎么執行，那么這就不是一個好的測試用例。

4) 合適：測試用例在相應的測試環境下具有可執行性，而不應依賴于測試人員的個人技能和經驗

5) 可跟蹤：在執行每一輪的測試中，需要追蹤共執行了多少測試用例，執行的測試用例中通過的，未通過的及未使用的占多少，未使用的原因是什么。為以后的測試用例更新做準備。

6) 可恢復：測試用例執行后，測試環境需要恢復到測試前的狀態。如果對系統進行恢復測試，需要說明如何使系統回到正常狀態。

在評審會議中，會議主持者負責控制評審的進度和時間，通過評審，把需要澄清和改進的問題記錄下來，由測試用例的設計者會后進行修改，修改完成后的測試用例需要提交再次評審，直到所有的用例通過評審為止。

最后，測試用例在形成文檔后也還需要不斷完善。主要來自三方面的緣故：第一、在測試過程中發現設計測試用例時考慮不周，需要完善；第二、在軟件交付使用后反饋的軟件功能性缺陷，而缺陷又是因測試用例存在漏洞造成；第三、軟件自身的新增功能以及軟件版本的更新，測試用例也必須配套修改更新。

一般小的修改完善可在原測試用例文檔上修改，但文檔要有更改記錄。軟件的版本升級更新，測試用例一般也應隨之編制升級更新版本。

4.2 測試用例的追蹤

因為測試用例具有易組織性，可評估性和管理性，在測試用例執行過程中，實現測試用例執行過程的跟蹤可以有效地將測試過程量化。例如，執行一輪測試中，共執行了多少測試用例，哪些成功的預測到缺陷，那些沒有，等等。當然，這只是一個相對過程，測試人員的工作量不應僅僅憑借測試用例的執行情況來判定，但至少每輪測試后通過對實現所設計的測試用例的追蹤可以判斷當前軟件測試的質量，并對測試的有效性進行評估。

追蹤測試用例的形式一般有以下幾種:

1) 記憶：憑借個人的記憶力來追蹤測試用例，方法是不可取的。

2) 書面文檔：使用書面文檔記錄測試用例，主要使用列表的形式。但作為組織和搜索數據分析時，這種方法是很局限的。

3) 電子表格：通過表格中列出的測試用例的跟蹤細節，可以直觀的砍刀測試狀態以及分析合同及測試用例的通過與否，它與軟件缺陷相關聯。這為測試中有效管理和分析測試過程以及軟件的質量提供了有效的量化依據。

4) 自定義數據庫：通過自己定義的數據庫來跟蹤測試用例的執行和覆蓋率，并通過自己編寫的工具生成相關報表，分析圖等。當然，這種方法所花費的成本是最高的。

根據RMDB系統實際測試環境的現狀，我們所采用的是電子表格形式對每一輪測試后的測試用例進行追蹤。所用的測試用例覆蓋缺陷追蹤統計表模板主要由以下幾部分組成，分別是測試輪數，被測模塊號，模塊名，模塊測試狀態，缺陷號，未覆蓋標識，覆蓋標識（執行的用例號，為被執行的用例號），覆蓋缺陷率。

1) 測試輪數：表明這是第幾輪測試的統計表。

2) 被測模塊號：每個被測模塊都有一個惟一的序列號，用于標識。

3) 模塊名：每個被測模塊都有一個惟一的模塊名，用于標識。

4) 模塊測試狀態：指該模塊內是否發現缺陷（無論是哪一種缺陷），一般用Pass/Fail 標識。

5) 缺陷號：指在某一模塊中所發現的一或多個缺陷序列號，每個缺陷序列號唯一，用于標識。

6) 未覆蓋標識：指該缺陷未被事先設計的測試用例所覆蓋到（預測到），標明相應的缺陷序列號。

7) 覆蓋標識（執行的用例號）：指該缺陷被事先設計的測試用例表中所覆蓋到（預測到），并且該缺陷發生的結果與測試用例表中反映的一致。標明相應的測試用例序列號。

8) 覆蓋標識（未執行的用例號）：指該缺陷被雖然被事先設計的測試用例表中所覆蓋到（預測到），但是該缺陷發生的結果與測試用例表中反映的不一致。標明相應的測試用例序列。

9) 覆蓋缺陷率：統計此輪測試后，事先設計的測試用例表中成功的覆蓋到（預測到）實際所發現缺陷的比率。（一般來說，若這個比率應不低于60%，則說明事先所設計的 測試用例是有效的。）

圖6為RMDB系統在某一輪測試結束后測試用例評審時的跟蹤統計工作表模版。

在每一輪測試工作結束后，測試人員要花一定時間對已發現的缺陷情況并結合已有的測試用例做測試用例的更新工作（若用戶對系統的某些功能方面提出了新的需求，也是要進行相應測試用例更新操作）。這樣一方面為下一輪的測試做好準備，另一方面可以有效的對測試用例進行科學化管理，從而提高測試用例的設計效率。

5 結束語

基于現代化軟件開發規律，軟件在其生命周期中會頻繁地被修改和不斷推出新的版本，修改后的或者新版本的軟件會添加一些新的功能或者在軟件功能上產生某些變化。隨著軟件的不斷完善，軟件的某些功能發生了演變，原有的測試用例可能會失去針對性和有效性，而另一些測試用例可能會變得過時，還有一些測試用例將完全不能運行。為了保證測試用例庫中測試用例的有效性，還需要對測試用例進行維護。同時，被修改的或新增添的軟件功能，僅僅通過重新運行以前的測試用例并不足以揭示其中的問題，有必要增加新的測試用例來測試這些新的功能或特征。因此，測試用例的維護工作還應包括開發新測試用例，這些新的測試用例用來測試軟件的新特征或者覆蓋現有測試用例無法覆蓋的軟件功能或特征。

參考文獻：

[1] 朱少明.軟件測試方法和技術[M].北京:清華大學出版社，2005.

[2] 鄭人杰.計算機軟件測試技術[M].北京:清華大學出版社，1995.

[3] Black R.測試流程管理[M].北京:北京大學出版社，2001.