軟件測試之前的“戰略部署” 軟件測試
測試用例的編寫作為QC特定的概念、技能，成為唯一廣泛公認的東西。在項目測試過程中，最值得考慮的、最重要的當屬測試用例的設計以及創建有效的測試用例。
但是，仍然有不少的測試團隊和測試人員認為沒有必要編寫和設計測試用例，尤其是當敏捷開始盛行后，很多人更是認為編寫和設計測試用例是浪費時間。
為什么要寫測試用例?
測試用例的創建至少會有兩個用途或目的：
(1)如果顧客有要求的話，測試用例會是交付給顧客的產品中的一部分。測試用例在這里充當了提高可信度的作用。
(2)測試用例只作為內部使用。在這里測試效率是目的。在代碼尚未完成時，我們基于設計編寫測試用例，以便一旦代碼準備好了，我們就可以很快地測試產品。
但是隨著敏捷的盛行，第二點逐漸受到很多人的置疑�！邦A先設計好的測試用例對指導測試執行有多大的作用呢?而且我們采用的是探索性測試方法，不寫測試用例也能做測試�！�
沒錯，預先寫好的測試用例很可能要在測試執行的過程中不斷地修改，尤其是在那些需求不明朗的項目中。但是預先的設計就好比提前的探索，除了能學習到軟件涉及的業務知識外，還能對即將出現的軟件進行一次測試的“演練”，在這個“演練”的過程中，往往能發現需求分析和設計的很多缺陷，將可能由此引致的BUG“扼殺”在萌芽期。
探索性測試雖然很少寫正式的測試用例，但是并不意味著沒有對測試進行設計。只是測試的設計是在探索過程中、測試過程中進行的，測試的設計與測試的執行同步進行。并且根據Jams Bach介紹的基于Session的探索性測試管理的方法，是要寫測試用例的，只不過不被稱為測試用例，而是被稱為“探索任務”。
基于Session的測試管理把測試過程劃分成多個Session，或者叫“探索任務”，每個Session都是目的驅動的，每個Session由一名測試員負責執行，在一個Session結束后，測試員提交一份session報告，附上關于測試過程的重要信息。
“探索任務”可包括如圖1所示的任務矩陣中列出的方面。
圖1 探索性測試任務
由此可見，探索性測試也有測試的設計，也有測試用例，只是相比起傳統意義的測試用例編寫而言，其測試用例更偏向于“設計”，并且其設計是與測試執行和探索行為同步進行的。
測試永遠也無法保證發現所有的錯誤。測試用例的“設計”如此重要正是因為完整的測試是不可能的，任何項目的測試都是不完整的，因此，很顯然我們需要通過設計測試用例，讓測試盡可能的完善。在有限的時間和資源下，測試的關鍵問題是：哪些測試用例是最有可能發現最多錯誤的呢?
圖2 某個程序的結構流程圖
文章來源于領測軟件測試網 http://www.kjueaiud.com/
