重要級別： 定義測試用例的優先級別，可以籠統的分為 “ 高 ” 和 “ 低 ” 兩個級別。一般來說，如果軟件需求的優先級為 “ 高 ” ，那么針對該需求的測試用例優先級也為 “ 高 ” ;反之亦然，
測試輸入： 提供測試執行中的各種輸入條件。根據需求中的輸入條件，確定測試用例的輸入。測試用例的輸入對軟件需求當中的輸入有很大的依賴性，如果軟件需求中沒有很好的定義需求的輸入，那么測試用例設計中會遇到很大的障礙。
操作步驟： 提供測試執行過程的步驟。對于復雜的測試用例，測試用例的輸入需要分為幾個步驟完成，這部分內容在操作步驟中詳細列出。
預期結果： 提供測試執行的預期結果，預期結果應該根據軟件需求中的輸出得出。如果在實際測試過程中，得到的實際測試結果與預期結果不符，那么測試不通過;反之則測試通過。
軟件測試用例的設計主要從上述 6 個域考慮，結合相應的軟件需求文檔，在掌握一定測試用例設計方法的基礎上，可以設計出比較全面、合理的測試用例。具體的測試用例設計方法可以參見相關的測試書籍，白盒測試方法和黑盒測試方法在絕大多數的軟件測試書籍中都有詳細的介紹，這里不作贅述。
重用同類型項目的測試用例
如果我看得遠，那是因為我站在巨人的肩上 --牛頓。
一般來說，每個軟件公司的項目可以分為固定的幾大類�？梢园礃I務類型劃分，比如 ERP 軟件、產品數據管理軟件、通信軟件、地理信息系統軟件等等;可以按軟件結構來劃分，比如 B/S 架構的軟件、 C/S 架構的軟件、嵌入式軟件等等。參考同類別軟件的測試用例，會有很大的借鑒意義。如果，公司中有同類別的軟件系統，千萬別忘記把相關的測試用例拿來參考。如果，系統非常接近，甚至經過對測試用例簡單修改就可以應用到當前被測試的軟件。 “ 拿來主義 ” 可以極大的開闊測試用例設計思路，也可以節省大量的測試用例設計時間。
利用已有的軟件 Checklist
在上面一個小節中，按照不同的規則劃分了不同的軟件類型。每種類型的軟件都有一定的測試規范，比如， WEB 軟件系統在系統測試過程中，會有一系列的范式，比如針對 Cookie 就會有很多測試點。在設計測試用例的時候，不妨到網上去搜索相關的 Checklist ，不過國內外的網站很少有這方面的資料，即便有，也不是特別系統�？梢韵日乙环荽植诘� Checklist ，然后，在設計測試用例的時候不斷的去完善它，以作為下次測試用例設計的基礎。
加強測試用例的評審
測試用例設計完畢后，最好能夠增加評審過程。同行評審是 CMM3 級的一個 KPA ，如果因為公司沒有通過 CMM3 級，就不開展同行評審是不恰當的。測試用例應該由產品相關的軟件測試人員和軟件開發人員評審，提交評審意見，然后根據評審意見更新測試用例。 如果認真操作這個環節，測試用例中的很多問題都會暴露出來，比如用例設計錯誤、用例設計遺漏、用例設計冗余、用例設計不充分等等;如果同行評審不充分，那么，在測試執行的過程中，上述本應在評審階段發現的測試用例相關問題，會給測試執行帶來大麻煩，甚至導致測試執行掛起。
定義測試用例的執行順序
在測試用例執行過程中，你會發現每個測試用例都對測試環境有特殊的要求，或者對測試環境有特殊的影響。因此，定義測試用例的執行順序，對測試的執行效率影響非常大。比如某些異常測試用例會導致服務器頻繁重新啟動，服務器的每次重新啟動都會消耗大量的時間，導致這部分測試用例執行也消耗很多的時間。那么在編排測試用例執行順序的時候，應該考慮把這部分測試用例放在最后執行，如果在測試進度很緊張的情況下，如果優先執行這部分消耗時間的異常測試用例，那么在測試執行時間過了大半的時候，測試用例執行的進度依然是緩慢的，這會影響到測試人員的心情，進而導致匆忙地測試后面的測試用例，這樣測試用例的漏測、誤測就不可避免，嚴重影響了軟件測試效果和進度。因而，合理地定義測試用例的執行順序是很有必要的。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
