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

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

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

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

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

　　隨著(zhù)中國軟件業(yè)的日益壯大和逐步走向成熟，軟件測試也在不斷發(fā)展。從最初的由軟件編程人員兼職測試到軟件公司組建獨立專(zhuān)職測試部門(mén)。測試工作也從簡(jiǎn)單測試演變?yōu)榘�括：編�?FONT color=#136ec2>測試計劃、編寫(xiě)測試用例、準備測試數據、編寫(xiě)測試腳本、實(shí)施測試、測試評估等多項內容的正規測試。測試方式則由單純手工測試發(fā)展為手工、自動(dòng)兼之，并有向第三方專(zhuān)業(yè)測試公司發(fā)展的趨勢。

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

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

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

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

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

·能發(fā)現到目前為止沒(méi)有發(fā)現的缺陷的用例是好的用例；

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

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

·測試用例應該詳細記錄所有的操作信息，使一個(gè)沒(méi)有接觸過(guò)系統的人員也能進(jìn)行測試；

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

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

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

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

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

這個(gè)例子可能有些極端，但測試用例與需求和設計不同步的情況在實(shí)際開(kāi)發(fā)過(guò)程中確是屢見(jiàn)不鮮的，測試用例文檔是“活的”文檔，這一點(diǎn)應該被測試工程師牢記。

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

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

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

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

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

用于功能性測試的測試用例來(lái)源于測試目標的用例。應該為每個(gè)用例場(chǎng)景編制測試用例。用例場(chǎng)景要通過(guò)描述流經(jīng)用例的路徑來(lái)確定，這個(gè)流經(jīng)過(guò)程要從用例開(kāi)始到結束遍歷其中所有基本流和備選流。

例如，下圖中經(jīng)過(guò)用例的每條不同路徑都反映了基本流和備選流，都用箭頭來(lái)表示�；�本流用直黑線(xiàn)來(lái)表示，是經(jīng)過(guò)用例的最簡(jiǎn)單的路徑。每個(gè)備選流自基本流開(kāi)始，之后，備選流會(huì )在某個(gè)特定條件下執行。備選流可能會(huì )重新加入基本流中（備選流 1 和 3），還可能起源于另一個(gè)備選流（備選流 2），或者終止用例而不再重新加入某個(gè)流（備選流 2 和 4）。