設計測試用例是個很大的主題，而且其中所需要的方法也很多。我計劃一點一點的總結并記錄下來。我這次討論的不是針對一個軟件的測試用例設計，而是針對一個模塊或多個模塊用例的設計。
今天我要寫的主要是我自己在工作中所用的一些方法，當然不是最好用的。但我一直在研究最高效，最實用的方法。
首先我們要了解一下為什么要設計測試用例以及它在軟件測試中的地位。
影響軟件測試的因素很多，軟件本身的復雜程度，開發人員的素質（包括分析，設計，編程和測試），測試方法和技術的應用。那么如何保證測試質量的穩定呢？測試用例就可以把一些人為的因素減低，因為人員的流動不會造成測試用例的流動，而且我們可以在以后的測試中不斷的維護和更新測試用例。所以說測試用例的設計和編制是軟件測試活動中最重要的。它是測試工作的指導和軟件測試必須遵守的準則。它更是軟件測試質量穩定的根本保障。
當自己接受到一個設計測試用例的任務時，如何對一個龐大的模塊進行設計測試用例呢？這時候測試用例的劃分就顯的尤為重要。
我總結的測試用例的劃分有三種：
1）按照功能劃分
2）按照路徑（業務流程）劃分
3）按照功能和路徑（業務流程）劃分
目前我用的方法是第三種。第一種按照功能劃分，優點是最簡捷，但其缺點是：對于復雜操作的程序模塊，其各功能的實施是相互影響，緊密相關，環環相扣的。如果沒有嚴密的邏輯分析，很容易產生遺漏。第二種純粹按照路徑劃分也容易造成對功能點的遺漏。所以我基本都是大方向用功能塊的劃分來走，然后再結合上路徑（業務流程）的劃分方法。
例如下面的一個模塊測試，我就先按照功能劃分為幾大塊，然后針對每個功能塊再按照路徑（業務流程）來劃分：
那么有人會問，當我拿到一個任務的時候，簡單一點還好辦，一旦復雜了就沒有頭緒，無處下手了。我告訴大家不會的。只要你按照我的這個流程來設計我認為是不會無處下手的的：
在這個流程當中，我要強調的重點是前兩步："Understand Software Requirement" and "Be familiar with the corresponding functions".
1、Understand Software Requirement: 當接到一個任務的時候，我們首先接觸到的是需求說明書，那就要了解需求說明，或者應該說掌握其需求說明。其中的任何一個細節都不能忽略，都要把它搞得很清楚。不僅要搞清楚每個功能塊所實現的功能，更要從業務的角度理解其功能塊之間的關系。因為任何的軟件測試都不能脫離實際的業務邏輯，否則測試是沒有意義的。
2、Be familiar with the corresponding functions.如果這個模塊已經實現，那就更好辦了。可以結合需求說明直接操作該軟件，以便提高對該軟件功能的理解。
我們接到測試用例設計的任務，不要急著下手，首先按照我上面所說的兩步來完成。等把這些前提工作完成了，現在基本就對要設計的軟件了解差不多70％了。
當我們完成前兩步以后，開始對測試用例進行劃分，就可以采用我上面推薦的功能加上路徑（業務流程）的劃分方法。當我們羅列出很多測試用例以后，那我們是否要對所有的測試用例進行詳細的設計呢？這個就不一定了，因為往往時間或者資源的關系我們無法覆蓋到所有的測試用例。那我們這里就需要采取優先級的順序來進行選取了。
我們為每個測試用例設置優先級需要采取兩個原則：
1、將使用頻率比較高的設置為高優先級的。
2、根據測試用例失敗后對系統的影響大小還設置其優先級。
這樣將兩者相加就得到了每個測試用例的優先級了。根據優先級的排序就可以更有針對性的進行測試用例的詳細設計了。這是我們先不急著設計測試用例，我們還要為每個測試用例設計相關的測試數據。
我們對測試數據的設置有兩個要求：
1、正常數據
2、非法數據
我們要優先考慮正常數據，而且正常數據的設計必須是有實際意義的。然后再考慮設計非法數據。這兩種數據中都應該包含邊界數據，因為邊界數據往往是容易出錯的地方。
當我們設計完測試數據后，就可以開始對測試用例進行詳細設計了。具體測試用例的模板可以根據自己公司的要求來定義。我這里給出測試用例模板的一些要包括的要素：
1、Objective
2、Testing Configuration
3、Test Steps & Results
另外在具體的測試步驟中，我們需要包含的主要內容是：操作步驟，測試數據以及期望結果。
當我們完成了這些工作，一個完整的測試用例就寫完了。