軟件測試中的單體測試，單元測試，測試用例

軟件測試中的單體測試，單元測試，測試用例

測試用例（Test Case）是為某個特殊目標而編制的一組測試輸入、執行條件以及預期結果，以便測試某個程序路徑或核實是否滿足某個特定需求。

　　測試用例（Test Case）目前沒有經典的定義。比較通常的說法是：指對一項特定的軟件產品進行測試任務的描述，體現測試方案、方法、技術和策略。內容包括測試目標、測試環境、輸入數據、測試步驟、預期結果、測試腳本等，并形成文檔。

　　不同類別的軟件，測試用例是不同的。不同于諸如系統、工具、控制、游戲軟件，管理軟件的用戶需求更加不統一，變化更大、更快。筆者主要從事企業管理軟件的測試。因此我們的做法是把測試數據和測試腳本從測試用例中劃分出來。測試用例更趨于是針對軟件產品的功能、業務規則和業務處理所設計的測試方案。對軟件的每個特定功能或運行操作路徑的測試構成了一個個測試用例。

　　隨著中國軟件業的日益壯大和逐步走向成熟，軟件測試也在不斷發展。從最初的由軟件編程人員兼職測試到軟件公司組建獨立專職測試部門。測試工作也從簡單測試演變為包括：編制測試計劃、編寫測試用例、準備測試數據、編寫測試腳本、實施測試、測試評估等多項內容的正規測試。測試方式則由單純手工測試發展為手工、自動兼之，并有向第三方專業測試公司發展的趨勢。

　　要使最終用戶對軟件感到滿意,最有力的舉措就是對最終用戶的期望加以明確闡述，以便對這些期望進行核實并確認其有效性。測試用例反映了要核實的需求。然而，核實這些需求可能通過不同的方式并由不同的測試員來實施。例如，執行軟件以便驗證它的功能和性能，這項操作可能由某個測試員采用自動測試技術來實現；計算機系統的關機步驟可通過手工測試和觀察來完成；不過，市場占有率和銷售數據（以及產品需求），只能通過評測產品和競爭銷售數據來完成。

　　既然可能無法（或不必負責）核實所有的需求，那么是否能為測試挑選最適合或最關鍵的需求則關系到項目的成敗。選中要核實的需求將是對成本、風險和對該需求進行核實的必要性這三者權衡考慮的結果。

　　確定測試用例之所以很重要，原因有以下幾方面。

　　測試用例構成了設計和制定測試過程的基礎。 測試的“深度”與測試用例的數量成比例。由于每個測試用例反映不同的場景、條件或經由產品的事件流，因而，隨著測試用例數量的增加，您對產品質量和測試流程也就越有信心。 判斷測試是否完全的一個主要評測方法是基于需求的覆蓋，而這又是以確定、實施和/或執行的測試用例的數量為依據的。類似下面這樣的說明：“95 % 的關鍵測試用例已得以執行和驗證”，遠比“我們已完成 95 % 的測試”更有意義。 測試工作量與測試用例的數量成比例。根據全面且細化的測試用例，可以更準確地估計測試周期各連續階段的時間安排。 測試設計和開發的類型以及所需的資源主要都受控于測試用例。 測試用例通常根據它們所關聯關系的測試類型或測試需求來分類，而且將隨類型和需求進行相應地改變。最佳方案是為每個測試需求至少編制兩個測試用例：

　　·一個測試用例用于證明該需求已經滿足，通常稱作正面測試用例； ·另一個測試用例反映某個無法接受、反�；蛞馔獾臈l件或數據，用于論證只有在所需條件下才能夠滿足該需求，這個測試用例稱作負面測試用例。

·能發現到目前為止沒有發現的缺陷的用例是好的用例；

首先要申明，其實這句話是十分有道理的，但我發現很多人都曲解了這句話的原意，一心要設計出發現“難于發現的缺陷”而陷入盲目的片面中去，忘記了測試的目的所在，這是十分可怕的。我傾向于將測試用例當作一個集合來認識，對它的評價也只能對測試用例的集合來進行，測試本身是一種“V&V”的活動，測試 需要保證以下兩點：

程序做了它應該做的事情
程序沒有做它不該做的事情
因此，作為測試實施依據的測試用例，必須要能完整覆蓋測試需求，而不應該針對單個的測試用例去評判好壞。

·測試用例應該詳細記錄所有的操作信息，使一個沒有接觸過系統的人員也能進行測試；

不知道國內有沒有公司真正做到這點，或者說，不知道有國內沒有公司能夠將每個測試用例都寫得如此詳細。在我的測試經歷中，對測試用例描述的詳細和復雜程度 也曾有過很多的彷徨。寫得太簡單吧，除了自己沒人能夠執行，寫得太詳細吧，消耗在測試用例維護（別忘了，測試用例是動態的，一旦測試環境、需求、設計、實 現發生了變化，測試用例都需要相應發生變化）上的時間實在是太驚人，在目前國內大部分軟件公司的測試資源都不足的情況下，恐怕很難實現。但我偏偏就能遇到 一些這樣的老總或者是項目負責人，甚至是測試工程師本身，全然不顧實際的資源情況，一定要寫出“沒有接觸過系統的人員也能進行測試”的用例。

在討論這個問題之前，我們可以先考慮一下測試的目的。測試的目的是盡可能發現程序中存在的缺陷，測試活動本身也可以被看作是一個Project，也需要在 給定的資源條件下盡可能達成目標，根據我個人的經驗，大部分的國內軟件公司在測試方面配備的資源都是不足夠的，因此我們必須在測試計劃階段明確測試的目 標，一切圍繞測試的目標進行。

除了資源上的約束外，測試用例的詳細程度也需要根據需要確定。如果測試用例的執行者、測試用例設計者、測試活動相關人對系統了解都很深刻，那測試用例就沒有必要太詳細了，文檔的作用本來就在于溝通，只要能達到溝通的目的就OK。在我擔任測試經理的項目中，在測試計劃階段，一般給予測試設計30% - 40%左右的時間，測試設計工程師能夠根據項目的需要自行確定用例的詳細程度，在測試用例的評審階段由參與評審的相關人對其把關。

·測試用例設計是一勞永逸的事情；

這句話擺在這里，我想沒有一個人會認可，但在實際情況中，卻經常能發現這種想法的影子。我曾經參與過一個項目，軟件需求和設計已經變更了多次，但測試用例 卻沒有任何修改。導致的直接結果是新加入的測試工程師在執行測試用例時不知所措，間接的后果是測試用例成了廢紙一堆，開發人員在多次被無效的缺陷報告打擾 后，對測試人員不屑一顧。

這個例子可能有些極端，但測試用例與需求和設計不同步的情況在實際開發過程中確是屢見不鮮的，測試用例文檔是“活的”文檔，這一點應該被測試工程師牢記。

·測試用例不應該包含實際的數據；

測試用例是“一組輸入、執行條件、預期結果”、毫無疑問地應該包括清晰的輸入數據和預期輸出，沒有測試數據的用例最多只具有指導性的意義，不具有可執行 性。當然，測試用例中包含輸入數據會帶來維護、與測試環境同步之類的問題，關于這一點，《Effective Software Test》一書中提供了詳細的測試用例、測試數據的維護方法，可以參考。

·測試用例中不需要明顯的驗證手段；

我見過很多測試工程師編寫的測試用例中，“預期輸出”僅描述為程序的可見行為，其實，“預期結果”的含義并不只是程序的可見行為。例如，對一個訂貨系統， 輸入訂貨數據，點擊“確定”按鈕后，系統提示“訂貨成功”，這樣是不是一個完整的用例呢？是不是系統輸出的“訂貨成功”就應該作為我們唯一的驗證手段呢？ 顯然不是。訂貨是否成功還需要查看相應的數據記錄是否更新，因此，在這樣的一個用例中，還應該包含對測試結果的顯式的驗證手段：在數據庫中執行查詢語句進行查詢，看查詢結果是否與預期的一致。

七、從用例中生成測試用例

用于功能性測試的測試用例來源于測試目標的用例。應該為每個用例場景編制測試用例。用例場景要通過描述流經用例的路徑來確定，這個流經過程要從用例開始到結束遍歷其中所有基本流和備選流。

例如，下圖中經過用例的每條不同路徑都反映了基本流和備選流，都用箭頭來表示�；�本流用直黑線來表示，是經過用例的最簡單的路徑。每個備選流自基本流開始，之后，備選流會在某個特定條件下執行。備選流可能會重新加入基本流中（備選流 1 和 3），還可能起源于另一個備選流（備選流 2），或者終止用例而不再重新加入某個流（備選流 2 和 4）。