測試用例，就是針對特定的功能點、場景，來設計用來驗證功能點和場景正確性的、可執(zhí)行的、可驗證的過程。
功能測試，是針對軟件需求的功能測試。對軟件需求測試之前，就需要把具體的軟件需求做條目化處理，一般是樹形結構。樹形結構的每一個節(jié)點，就是一個需求項。
對于每一個需求項，就需要細分功能點。所謂的功能點，就是這個需求具體實現了哪些功能，從測試的角度，就是哪些功能需要被驗證。
功能點的集合，就是測試大綱。
有了功能點之后，我們就可以根據功能點來設計測試用例。那么測試用例包括什么內容？
測試用例的步驟描述包括：前提條件、測試步驟。步驟又分成具體的操作、相關步驟的數據、預期結果。
我們可以看到，在很多成熟的測試管理軟件中，已經把測試數據從測試步驟描述中分離出來，這樣我們就可以編寫更細致的測試用例。
從早期的測試用例來看，一般是不包含具體的數據，比如“輸入正確的手機號”，“輸入錯誤的手機號”，類似的描述信息，這樣帶來的問題是測試用例的顆粒度比較大。例如，這個功能點需要驗證手機號的有效性，“無效的手機號”，就顯得太粗了，因為無效的手機號包括了很多種情況，比如長度錯誤、格式錯誤等等。
測試用例的數據與步驟描述分離，能夠把相同執(zhí)行步驟的測試用例，通過使用不同的測試數據，很容易的區(qū)分開來，也很容易把測試用例“精確化”，使得測試工程師集中精力于通過測試數據的設計，實現測試用例設計。
測試用例的屬性包括：
用例屬性，一般包括：測試用例的創(chuàng)建人、測試用例的創(chuàng)建時間、測試用例的名稱、測試用例關聯的缺陷編號、測試用例的描述（即這個測試用例的目的是什么，或者相關的功能點描述）。
測試用例具有執(zhí)行歷史，也就是這個測試用例被執(zhí)行了多少次，什么時候執(zhí)行的、誰執(zhí)行的、執(zhí)行的結果是通過還是失敗。
下面談一下測試用例設計。我們知道，測試的目標是發(fā)現缺陷，因此能夠發(fā)現缺陷的測試用例才是好的測試用例。
問題在于，功能點很多，每個功能點都對應了很多個測試用例，這樣就會出現一個問題：測試用例膨脹。膨脹的測試用例，會導致測試用例的數量很多，帶來的后果是執(zhí)行成本非常高，還不一定能夠發(fā)現缺陷。
因此，我們還需要使用盡可能的在不降低覆蓋率的情況下，減少測試用例的個數。
我們先說一下測試用例設計方法。常規(guī)的測試用例設計方法，有邊界值、等價類、錯誤推斷、因果圖、場景法等方法，具體的方法本身我們不在這里討論，只是大概的介紹一下，在什么時候來使用什么方法。
邊界值和等價類。這兩個往往是一起來使用的，能夠達到比較好的效果。邊界值，我們采用各個功能點表述的邊界，即可以容易的找到。等價類，在輸入數據比較小的情況下還是比較有效的，當輸入的參數個數很多，就需要做笛卡爾積正交，這樣就產生非常多的測試用例，使用不當，比如：輸入參數有10個，每個輸入參數有3個選項，那么，測試用例有1000個，造成測試用例膨脹。
錯誤推斷法，其實更多時候是在測試過程中，臨時增加測試用例的方法。比如，你發(fā)現一個特殊的邊界條件，501，那么這個邊界值，可能不只是在你測試的這個功能點會出現，在其他的地方也會出現，因此可以增加測試用例來測試特殊的邊界。錯誤推斷法，更容易發(fā)現某一類問題。比如，一個子系統不支持按鈕級別的權限控制，那么可以推定，幾乎所有的子系統都存在這個問題。再比如，一個下拉列表，當它的選項超過50個，按照設計會有一個快速檢索的功能，如果沒有，就是一個bug。那么，這個選項數據，在其他界面出現的時候，基本上也存在缺少快速檢索功能。
場景法。首先，我們說，什么是場景。場景其實就是一個功能在不同的環(huán)境下，有不同的表現。比如，復制粘貼這個功能，在word里面，可以粘貼純文本、也可以粘貼帶格式的問題、圖片、圖表，這樣就產生了大量的場景。不同的場景，可以對應一個或者多個測試用例。那么場景一般情況下，就是針對功能點做場景分析。大多數的功能點，具有的場景一般只有一個，特殊情況下可能有很多。
另一種情況，就是這個功能本身就是一個流程，那么我們可以把一個流程的分支，作為一個場景。場景之下，每一組數據，都可以作為一個測試用例。
流程測試用例。我們知道功能其實有多個維度，比如當功能或者單個頁面、單個交易的問題，以測試數據組合為目標。流程類的功能，以流程測試為核心，輔助以數據來設計測試用例。
sales@spasvo.com
