硬盤分區(賈德江)_測試用例(第4頁)免費閱讀-短篇小說

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

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

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

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

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

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

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

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

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

讓您第一時間享受最新章節，請訪問𝗼𝗼𝗽.𝘁𝘄

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

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

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

從用例中生成測試用例

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

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

用例的事件流示例

遵循上圖中每個經過用例的可能路徑，可以確定不同的用例場景。從基本流開始，再將基本流和備選流結合起來，可以確定以下用例場景：

場景1基本流

場景2基本流備選流1

場景3基本流備選流1備選流2

場景4基本流備選流3

場景5基本流備選流3備選流1

場景6基本流備選流3備選流1備選流2

場景7基本流備選流4

場景8基本流備選流3備選流4

。況情的次一行執環循的示指3流選備了述描隻8和6、5景場，見起便方為：注

。行執的景場例用定特致導將件條定特個這，的成完來件條定特個某定確過通是例用試測的景場個每成生