摘要：本文通過對測試原則與用況驅動思想的分析，提出了用況驅動系統測試用例設計的思想。從功能性測試、性能測試、回歸測試等三方面，闡述了該思想在測試用例設計過程中的必要性和應用方式。并重點以功能性測試為例，給出一些該思想應用于實踐的方法和經驗。
關鍵詞：用況驅動；系統測試；測試用例設計
一、系統測試用例設計原則和優點
軟件測試是為了發現錯誤而執行程序的過程，一般來說橫跨軟件生命周期的兩個階段：開發階段和測試階段。其中開發階段的測試工作主要是指單元測試和集成測試，一般由開發人員完成；測試階段是軟件生命周期的一個獨立階段，主要的任務是進行系統測試，由專門的測試人員完成。無論單元集成測試，還是系統測試，都應該進行必要的測試用例設計，本文的側重點在于系統測試的用例設計。
系統測試在待測系統組裝到一起并通過了單元和集成測試之后進行，一般采用黑盒測試的 方式，側重于測試軟件的功能性需求，兼顧性能、壓力等各方面的因素。系統測試的意圖在于發現系統與用戶期望的差距，通過測試暴露出軟件中隱藏的錯誤和缺 陷，權衡并改進系統。Davis曾經提出了一組測試原則，其中包括兩點：一是所有測試都應該可以追溯到用戶需求；二是窮舉測試是不可能的。
正如我們所知，軟件測試的目的在于發現錯誤，而最嚴重的錯誤莫過于導致程序無法滿足需求的錯誤。因此測試用例的設計必須充分考慮用戶需求，是否正確的滿 足了用戶需求是判別一個軟件系統是否能夠通過測試，是否合格產品的最重要標準。在實際的測試工作中，追求系統測試用例對用戶明示和隱含需求的100%覆 蓋，試圖窮舉用戶需求進行測試是不現實的。系統測試用例的設計原則應該是盡可能覆蓋用戶工作中使用本系統的各種工作場景和情況（包括正常方式使用和異常方 式使用的情況），至少應完全覆蓋用戶日常工作使用系統的全部場景和情況。
用況驅動（Use-Case Driven）是統一過程（UP）的核心思想之一，也是其精髓所在。統一過程的目標是指導開發人員有效的實現并實施滿足用戶需求的系統。統一過程一般被認為是一種OO（面向對象）開發方法，實際上它的思想也同樣支持非OO系統的開發。統一過程特點在于：用況驅動、以框架為中心、迭代和增量的。
用況（Use-Case）的目的在于捕獲真正的需求和使用適于用戶、客戶、開發、測試等各方人員理解的形式將捕獲到的需求加以描述。它幾乎普遍用于捕獲 軟件系統需求。但它的作用不僅如此，還能夠驅動整個開發過程，在尋找和確定類、子系統和接口、尋找和確定測試用例、規劃開發迭代和系統集成時，均可以將用 況作為主要輸入。因而可以毫不夸張地說，在應用統一過程思想指導軟件開發過程中，用況的驅動作用貫穿整個軟件生命周期。
用況驅動設計與 開發過程的思想，目前已被軟件業內人士廣泛接受，并越來越多地付諸于實踐；而用況驅動思想在測試領域的實踐中卻并未得到應有的重視。我們的測試團隊也經歷 了一個對此思想逐步認知的過程，在工作實踐中積累了一些相關的思路和方法，并且還在繼續摸索，希望能對測試過程持續改進。
與傳統系統測試用例設計相比，強調用況驅動的思想會體現出一定的優越性。
首先，利于系統測試用例貼近用戶需求。用況描述用戶對系統的期望和真正的需求，這恰恰與系統測試的主要目標不謀而合。因此系統測試用例的設計由用況驅 動，以用況為輸入，實現對用況的追蹤與覆蓋，是確保系統測試用例設計滿足功能和場景覆蓋，達到系統測試用例設計的質量要求的捷徑。
其次，便于與其它小 組溝通，便于對用戶需求實施追蹤。若該項目的需求、設計、開發、維護等過程同樣以統一過程思想、用況驅動的思想作為指導，則在整個項目內部更易形成溝通， 在該軟件系統生命周期涉及到的各個產物之間能很容易的進行追蹤。將以用況為指導形成的系統測試用例應用于測試活動，得到的測試結果直接體現用戶需求的實施 情況。
二、用況驅動系統測試用例設計實踐
用況是需求分析階段的產物，系統測試用例的質量在一定程度上依賴于用況的質量，只有用況描述的真實、全面、易理解，系統測試用例才有可能達到相應的質量目標。
對于系統測試的分類，業界有很多種說法，不盡相同。最常見的包括：功能性測試、性能測試、回歸測試等。下面將主要就功能性測試，說明用況驅動思想在其測試用例設計過程中的作用；同時說明用況驅動思想對性能測試和回歸測試用例選取原則的影響。
1．功能性測試
（1）用況驅動功能性測試的組成
傳統概念中的功能性測試和性能測試主要是針對功能點進行的，這主要源于傳統的軟件功能相對單一、獨立。當前軟件發展趨勢，越來越綜合化、系統化、全面 化，軟件系統越來越龐大、復雜，單一、割裂的功能點往往難以滿足用戶實際需求，將各功能點按用戶實際使用場景，以不同的順序組合起來，才能真正滿足用戶實 際應用的需要。換言之，用戶的需求可以體現為一個個用況，而用況在系統中的實現則體現為功能點的有序組合。
傳統意義上，功能性測試用例，一般會針對功能點設計，經歷從功能點到測試點、再到測試用例的逐步細化、擴充的過程。而用況驅動的功能性測試，除了包含對基于功能點的測試外，還包括對基于場景（用況）的測試。
基于功能點的測試是用況驅動功能性測試的基礎，只有通過了基于功能點的測試（通過的意義并不是完全沒有缺陷），基于場景測試的實施才是有意義 的。因此基于功能點的測試應該是基于場景測試的“前傳”。從功能點到測試點的擴充，是基于對該功能在各種場景應用中可能出現的使用、操作上的正向、反向分 支的考慮，是該功能測試中所應關注的關鍵點的體現。從測試點到測試用例的擴充，則主要是對該測試點的不同情況、取值等的考慮，以及對測試中一些細節的描 述。
基于場景的測試更傾向于對軟件系統能否滿足用戶需求進行測試，關心用戶做什么而不是產品做什么，它意味著通過用況捕獲用戶必須完成的任務，然后 測試時應用它們或它們的變體。基于場景的測試往往在單個測試中處理多個子系統。正如目前軟件行業廣泛認可的一個觀點所述，“最好的軟件不是沒有缺陷的軟 件，而是滿足用戶使用要求的軟件”。在實際的測試工作中，試圖窮舉用戶需求進行測試是不現實的，對用戶來說實用的系統就是好的系統。因此，盡可能覆蓋用戶 日常工作場景進行測試顯得尤為重要。而基于場景測試用例的組織，也要求綜合考慮用戶業務、用戶工作流程、系統實現的功能點等多方面進行，對測試人員的邏輯 思維能力和業務理解能力都有較高的要求。
我們遇到的一個比較典型的例子——業務流程正常流轉的用況：用戶按照自身角色的不同，在流程的不同步驟參與流轉，流程流轉到某一步時，當前用戶 需要根據自己的權限實施業務的配置后才能讓流程繼續流轉。我們分別針對給用戶指定業務配置權限、給用戶指定流程角色、流程正常流轉、業務配置等功能點組織了測試用例并通過了測試。而后針對整個流程設計場景測試用例時，包含了指定A用戶同時具備流程中與業務配置對應步驟的角色和業務配置的權限。當時應用系統 沒有通過這個場景測試用例，原因是A用戶同時具有的業務配置權限與流程角色發生了沖突，導致業務配置任務無法實施。可見，所有相關的功能點均通過測試，也 不表示全部由這些功能點構成的用況能正確實現，因此基于場景的測試是十分必要的。
（2）測試用例與測試包
每個測試場景是由不同的測試功能點按照一定的順序組合而成的，組合順序不同，預期結果也有可能會不同。針對每個測試功能點都組織了相應的功能點測試用例，而對于場景的測試用例，如果重復描述構成場景的各個功能點的測試用例內容，會帶來一些問題：
1）加大了測試用例編寫的工作量。
2）給測試用例的維護帶來困難。同樣的內容的修改要在多處體現，很容易遺漏，從而帶來不一致。
3）測試用例的結構層次不清晰。功能點測試用例和場景測試用例的關系體現不出來。
鑒于上述原因，在場景測試用例的編寫過程中，我們引入了測試用例包的概念。測試用例包是測試用例在一定條件下的有序組合。必要的時候，可以將已有的功能點測試用例以適當的順序組織起來，加上必要的條件限制，構成測試用例包，形成場景測試用例。
（3）測試用例的描述工具和測試用例包的組織形式
1）測試用例描述工具
實際上，測試用例可以采用自然語言、表格等各種方式加以描述。以UML語言加以描述也是可選的方法之一。
UML（統一建模語言）[3]很好地體現了統一過程思想，因而可以在以統一過程思想為指導的軟件開發過程中普遍應用于各個階段。用況驅動是統一 過程思想的核心思想，如果項目的需求分析、設計等工作成果均以UML方式描述，則在以用況驅動的測試活動中，采用UML組織測試用例，會更利于項目內部交 流。我們的測試團隊曾嘗試用UML描述測試用例，以下是對我們試用過的一些方法的說明。
第一種，可采用用況圖與活動圖結合的方式描述測試用例。例如：圖1是用活動圖形式描述的日志管理部分功能測試用例的例子。這個活動圖中包含7個 測試用例，每個end點對應一個測試用例，測試用例編號、測試目的、預期結果、測試數據等測試用例的信息。在相應end點的屬性中以文字形式說明。
圖1 活動圖形式描述測試用例舉例
第二種，可在同一張用況圖中以分層的方式描述出功能點/場景（用況）-測試點-測試用例的逐級細化關系。例如圖2，這是以用況圖形式體現的用戶權限管理部分的功能點-測試點的細化。
圖2 用況圖描述功能細化舉例
第三種，可采用狀態轉移圖、活動圖、順序圖、協作圖等方式或者將它們結合以對測試用例加以描述。
2）測試用例包的組織形式
描述測試用例包中測試用例的順序和條件限制關系，并不拘泥于具體的形式。我們曾采用過兩種方式，即表格形式和動圖形式。
例如：前面提到的業務流程正常流轉用況的測試用例以及相關功能點測試用例可以以下面的表格形式體現。
在活動圖中，使用對子活動的嵌套，可以實現在當前測試用例中對其它測試用例的引用，從而方便的實現了測試用例間的組合重用，完成了測試用例包的組織。
2. 性能測試
廣義上的性能測試一般包括常態下的性能測試、壓力測試和負載測試等，而實際工作中經常遇到的性能測試往往是對典型用 戶環境下使用情況的模擬，在此基礎上所進行并發性和持續性壓力測試，而并非考驗系統極限值的測試。系統的性能指標和性能測試所遵循的都應該是“適度”原 則。系統性能指標優越，性能測試充分當然好，但是這是要付出高昂的代價的。實際上，實際而有效的性能測試也應該是由用況驅動的，是針對用戶使用場景所設計 的，需要根據用戶對各項指標所提出的明確需求，或者根據用戶現場的實際情況，結合測試人員的經驗設計出相應的性能測試方案和數據，并依照實施。
例如：一個正常情況下最多只有50個并發用戶的系統，就沒有必要進行1000個用戶的并發測試，而一個每天夜間自動重起的系統，就沒必要對其實施持續一周的負載測試。
3．回歸測試
用況驅動的思想同樣指導回歸測試用例的選取。由于時間和成本的限制，每次回歸測試，都將所有功能和場景重新測試一遍是不現實的，如何能既盡量降低風險，又提高測試效率呢？就需要在測試用例選取的過程中注意把握平衡。
回歸測試用例的組織應該是分層次、分優先級的，基于用戶最常用的場景的測試用例處于最高優先級。每次執行回歸測試 時，基于軟件修改所影響的范圍，根據時間、人員、成本等因素，按照優先級次序抽取適量的相關測試用例，構造一個優化的測試用例組來完成回歸測試，才是正確 的選擇。
三、結語
用況驅動系統測試用例設計，是軟件系統發展的需要，更符合軟件生命周期的規律，廣泛應用于功能性測試、性能測試、回歸測試等各測試領域。用況驅動系統測試用例設計之路尚在探索之中，并無定式，在實踐中不斷嘗試和改進才是提高測試用例設計水平、提高軟件質量的正確途徑。