在測試幾年的過程中，打交道最多的是測試用例，從需求開始到方案，到形成用例，執行過程中與實際的出入，測試完成後用例的修改，維護等，沒有一個過程可以說不需要測試用例之說。但我今天還是寫了關於測試用例的，不是寫如何設計編寫，而是如何寫“好”。讓人看了一目瞭然，就看有新人拿到這個用例，能對程序有一點點基本的瞭解，就可以按照用例完完整整的執行下去。
在短信回執的測試用例裏，我沒有修改過的用例是很少的，在組員編寫測試用例過程中我總會強調簡單明瞭，其實就是精華。我認爲有以下幾點要關注：
- 1、對功能的理解。這個是最重要的，也是能反映出每個人對同一功能描述而有不同的理解方式，故一定要深刻理解功能。
- 2、編寫用例永遠要考慮兩面性。事物都是兩面的，只有一面的事物那是“怪物”，所以在編寫測試用例時先要心中有數。
- 3、確定測試用例的目的。如果不瞭解爲何要寫這個用例，那你達到的目的就是按需求或者按任務來完成而已，這樣的用例是否適用還有待於商榷；只有瞭解這個功能的來源，爲什麼要做這樣的功能，希望最後的結果是什麼，這些通通考慮清楚了，就不會爲了完成任務而去編寫出“普通”的測試用例，而是一份優秀合格的測試用例，這樣會大大提高工作效率及審覈打回的次數。
- 4、測試用例所包含的內容：<span style="color:#6600CC;">最基本最簡單的測試用例應該包含四項內容，即描述、預置條件、操作步驟、預期結果</span>。一般爲更好的管理及維護測試用例，我們會增加測試用例的編號及功能。
1）測試用例的描述項，一般人在寫的時候根本不去關心這到底有何用，有的甚至爲空，更有甚者把需求中的幾個字直接複製過來，不管是否通順與否都放在那裏認爲就可以了，描述項可以說是一個總結語，即你要明白這個用例是要驗證什麼的，因爲一個功能有很多用例，你不可能每個描述都是一樣的，那這樣還不如不要描述。
2）預置條件項，任何一個事務都有起源，有始有終纔是一個完整的過程，預置條件也可以說是一個基礎，基礎打好了，一切才能順利動工。預置條件是爲操作步驟服務的，當然有些可能說不需要預置條件，其實任何用例都是有預置條件的，我們說沒有預置條件只是隱藏了本身的特點而已。簡單來說，發送一條命令測試用例，前期不需要預置條件，但其隱藏的就是有號，且通信正常，還要有MONEY用來發送短信；但實際中我們並不需要寫這些預置條件，因爲是這是本身特點決定的。
3）操作步驟是非常重要的一環，與預期結果是等同的地位。測試用例設計是否高效，由預置條件及操作步驟決定，在操作步驟中，按正常步驟來測試，好像都不會出問題，但真正出問題的就是你想不到的，不是按常規則出牌的纔會發現真正有價值的缺陷，所以在設計測試用例時，不要嫌麻煩，認爲那一項就好了，別的都應該能檢測到，認爲寫某一項是不必要的，多餘的，其實這些想法是錯誤的，問題就往往出現在你認爲這無關功能上。
設計操作步驟還依賴於測試經驗是否豐富，有些經驗豐富的人員設計的測試用例往往會出乎意料，也是在測試階段最容易發現問題的用例。比如很簡單的一個編輯功能，要求其內容不能重複，一般人在寫用例的時候都在編輯中去修改成別的名字，而有經驗的測試人員會直接編輯一下而不改變內容，一般的程序員是不會考慮到此問題的，如果說出現提示錯誤一般都是程序邏輯問題。
4）預期結果，此項是驗證所寫用例是結果如何，所以如果沒有預期結果，在測試時則無任何可參照的，預期結果與操作步驟的關係相當大，一般來說，不同的操作步驟能生成不同的預期結果，因此在測試測試用例的時候，儘可能的考慮不同的操作步驟，是否會產生同一個結果，所有有時在設定測試用例的時候，根據結果來推斷操作步驟，這也應該是設計用例時的一種參照方法。在測試時，預期結果直接導致着測試是否通過。
測試用例作爲測試的一個總綱及指導作用，故，對於測試用例的設計是不能馬虎，不能省略的一個步驟，產品是否上線，測試用例是否通過起着決定性的作用。
----------
編寫測試用例的策略
測試用例編寫策略可以從不同的角度分類。
從測試內容角度可以分爲流程用例和功能點用例。其中流程用例指針對業務流程編寫的測試用例，通常採用場景法，現在的軟件幾乎都是用事件觸發來控制流程的，事件觸發時的情景便形成了場景，而同一事件不同的觸發順序和處理結果就形成事件流。這種在軟件設計方面的思想也可引入到軟件測試中，可以比較生動地描繪出事件觸發時的情景，有利於測試設計者設計測試用例，同時使測試用例更容易理解和執行。功能點用例指針對具體功能點編寫的測試用例，可以採用等價類劃分、邊界值法、因果圖等方法。
根據測試的策略又可以分爲通過測試用例和失敗測試用例，通過測試用例主要爲了驗證需求是否可以實現，一般採用等價類劃分等測試方法。失敗用例的編寫主要爲了儘可能多的發現缺陷，一般採用錯誤推測法、邊界值分析法等測試方法。
在具體的項目中，需要靈活的應用不同的測試策略。對於業務流程比較重要的系統，首先要考慮用場景法編寫流程用例，要求覆蓋所有的基本流和備選流。流程測試用例的完善，可以保證業務流程和業務數據流轉正確無誤，對軟件的質量有了最基本的保障。其次需要編寫功能點測試用例，要求覆蓋所有的需求，保證需求的各個功能都能正常的實現。對於所有的軟件測試，我們首先要考慮通過測試用例，來證明軟件可以滿足需求。在保證軟件可用的基礎上，纔會使用失敗測試用例，來儘可能多的發現缺陷，保證軟件的具有一定的容錯和安全能力。
在測試用例的編寫過程中還需注意其詳細程度，覆蓋功能點不是指列出功能點，而是要寫出功能點的各個方面，如果組合情況較多時可以採用等價類劃分的方法。此外，測試用例的編寫和組織會受到組織的開發能力和測試對象特點的影響。如果開發力量比較落後，編寫較詳細的測試用例是不現實的，因爲根本沒有那麼大的資源投入，當然這種情況會隨着團隊的發展而逐漸有所改善。測試對象特點重點是指測試對象在進度、成本等方面的要求，如果進度較緊張的情況下，是根本沒有時間寫出高質量的測試用例的，甚至有些時候測試工作只是一種輔助工作，因而不編寫測試用例。
總之，在組織和編寫測試用例時，需要根據測試對象特點、團隊的執行能力等各個方面綜合起來決定採用哪種編寫策略，以及如何編寫測試用例。
測試用例的設計
測試用例目前沒有經典的定義，比較通常的說法是：指對一項特定的軟件產品進行測試任務的描述，體現測試方案、方法、技術和策略。內容包括測試目標、測試環境、輸入數據、測試步驟、預期結果、測試腳本等，並形成文檔。隨着中國軟件業的日益壯大和逐步走向成熟，軟件測試也在不斷髮展。其中，測試用例的設計和編制是軟件測試活動中最重要的，它是測試工作的指導，是軟件測試必須遵守的準則，更是軟件測試質量穩定的根本保障。
1、測試用例設計原則
設計測試用例時，應遵循以下原則：
1）基於測試需求的原則。應按照測試類別的不同要求設計測試用例。例如，單元測試依據詳細設計說明，集成測試依據概要設計說明，配置項測試依據軟件需求規格說明，系統測試依據用戶需求（系統/子系統設計說明、軟件開發計劃等）。
2）基於測試方法的原則。應明確所採用的測試用例設計方法，爲達到不同的測試充分性要求，應採用相應的測試方法，如等價類劃分、邊界值分析、猜錯法、因果圖等。
3） 兼顧測試充分性和效率的原則。測試用例集應兼顧測試的充分性和測試的效率；每個測試用例的內容也應完整，具有可操作性。
4）測試執行的可再現性原則。應保證測試用例執行的可再現性。
2、測試用例要素
每個測試用例應包括以下要素：
1）名稱和標識。每個測試用例應有唯一的名稱和標識符。
2）測試追蹤。說明測試所依據的內容來源，如系統測試依據的是用戶需求，配置項測試依據的是軟件需求，集成測試和單元測試依據的是軟件設計。
3）用例說明。簡要描述測試的對象、目的和所採用的測試方法。
4）測試的初始化要求。應考慮下述初始化要求：
● 硬件配置。被測系統的硬件配置情況，包括硬件條件或電氣狀態。
● 軟件配置。被測系統的軟件配置情況，包括測試的初始條件。
● 測試配置。測試系統的配置情況，如用於測試的模擬系統和測試工具等的配置情況。
● 參數設置。測試開始前的設置，如標誌、第一斷點、指針、控制參數和初始化數據等的設置。
● 其他對於測試用例的特殊說明。
5）測試的輸入。在測試用例執行中發送給被測對象的所有測試命令、數據和信號等。對於每個測試用例應提供如下內容：
● 每個測試輸入的具體內容（如確定的數值、狀態或信號等）及其性質（如有效值、無效值、邊界值等）。
● 測試輸入的來源（例如，測試程序產生、磁盤文件、通過網絡接受、人工鍵盤輸入等），以及選擇輸入所使用的方法（例如，等價類劃分、邊界值分析、差錯推測、因果圖、功能圖等）。
● 測試輸入是真實的還是模擬的。
● 測試輸入的時間順序或事件順序。