該範例已經包含一個測試用例的模板。

3、測試用例設計的誤區

1、能發現到目前為止沒有發現的缺陷的用例是好的用例：

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

l 程序做了它應該做的事情

l 程序沒有做它不該做的事情

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

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

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

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

除了資源上的約束外，測試用例的詳細程度也需要根據需要確定。如果測試用例的執行者、測試用例設計者、測試活動相關人對系統了解都很深刻，那測試用例就沒有必要太詳細了，文檔的作用本來就在於溝通，只要能達到溝通的目的就OK。

在我擔任測試經理的項目中，在測試計劃階段，一般給予測試設計30% - 40%左右的時間，測試設計工程師能夠根據項目的需要自行確定用例的詳細程度，在測試用例的評審階段由參與評審的相關人對其把關。

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

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

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

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

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

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

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

4、測試用例在軟件測試中的作用

1、指導測試的實施

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

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

2、規劃測試數據的準備

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

除正常數據之外，還必須根據測試用例設計大量邊緣數據和錯誤數據。

3、編寫測試腳本的"設計規格說明書"

為提高測試效率，軟件測試已大力發展自動測試。自動測試的中心任務是編寫測試腳本。如果說軟件工程中軟件編程必須有設計規格說明書，那麽測試腳本的設計規格說明書就是測試用例。

4、評估測試結果的度量基準

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

5、分析缺陷的標準

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

5、試用例編號規則

目的：好的測試用例編號，可以更好的去了解此項用例所針對的模塊，也有助於記憶和新用例的增加。

規則：測試用例編號采用“版本+細類+編號”的形式。

備註：其中“版本”為設計此測試用例的軟件版本。

“細類”為小模塊中的漢字頭一個字母，以最多5個字母為標準。

“編號”為BUG用例的編號，以4位為標準，依次遞增。

例如：引導系統V2.01版本中，候車點設置，用例編號可以書寫為：

2.01_HCDSZ_0001

九、集成測試

集成測試（也叫組裝測試，聯合測試）是單元測試的邏輯擴展。它的最簡單的形式是：兩個已經測試過的單元組合成一個組件，並且測試它們之 間的接口。從這一層意義上講，組件是指多個單元的集成聚合。在現實方案中，許多單元組合成組件，而這些組件又聚合成程序的更大部分。方法是測試片段的組 合，並最終擴展進程，將您的模塊與其他組的模塊一起測試。最後，將構成進程的所有模塊一起測試。此外，如果程序由多個進程組成，應該成對測試它們，而不是 同時測試所有進程。

集成測試識別組合單元時出現的問題。通過使用要求在組合單元前測試每個單元並確保每個單元的生存能力的測試計劃，可以知道在組合單元時所發現的任何錯誤很可能與單元之間的接口有關。這種方法將可能發生的情況數量減少到更簡單的分析級別。

集成測試是在單元測試的基礎上，測試在將所有的軟件單元按照概要設計規格說明的要求組裝成模塊、子系統或系統的過程中各部分工作是否達 到或實現相應技術指標及要求的活動。也就是說，在集成測試之前，單元測試應該已經完成，集成測試中所使用的對象應該是已經經過單元測試的軟件單元。這一點 很重要，因為如果不經過單元測試，那麽集成測試的效果將會受到很大影響，並且會大幅增加軟件單元代碼糾錯的代價。

集成測試是單元測試的邏輯擴展。在現實方案中，集成是指多個單元的聚合，許多單元組合成模塊，而這些模塊又聚合成程序的更大部分，如分 系統或系統。集成測試采用的方法是測試軟件單元的組合能否正常工作，以及與其他組的模塊能否集成起來工作。最後，還要測試構成系統的所有模塊組合能否正常 工作。集成測試所持的主要標準是《軟件概要設計規格說明》，任何不符合該說明的程序模塊行為都應該加以記載並上報。

所有的軟件項目都不能擺脫系統集成這個階段。不管采用什麽開發模式，具體的開發工作總得從一個一個的軟件單元做起，軟件單元只有經過集 成才能形成一個有機的整體。具體的集成過程可能是顯性的也可能是隱性的。只要有集成，總是會出現一些常見問題，工程實踐中，幾乎不存在軟件單元組裝過程中 不出任何問題的情況。從圖1可以看出，集成測試需要花費的時間遠遠超過單元測試，直接從單元測試過渡到系統測試是極不妥當的做法。

集成測試的必要性還在於一些模塊雖然能夠單獨地工作，但並不能保證連接起來也能正常工作。程序在某些局部反映不出來的問題，有可能在全 局上會暴露出來，影響功能的實現。此外，在某些開發模式中，如叠代式開發，設計和實現是叠代進行的。在這種情況下，集成測試的意義還在於它能間接地驗證概 要設計是否具有可行性。

集成測試的目的是確保各單元組合在一起後能夠按既定意圖協作運行，並確保增量的行為正確。它所測試的內容包括單元間的接口以及集成後的功能。使用黑盒測試方法測試集成的功能。並且對以前的集成進行回歸測試。

測試實例