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

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可以看出，整合測試需要花費的時間遠遠超過單元測試，直接從單元測試過渡到系統測試是極不妥當的做法。 

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

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