淺談測試用例分析和設計
測試用例的重要性是毋庸置疑的，它是軟件測試全部過程的核心，是測試執行環節的基本依據。下面我們來淺談下測試用例的分析和設計過程。
一、測試用例分析階段
測試用例設計的基礎文檔是需求文檔，如果測試人員能拿到一份完整的準確的需求文檔，那么對測試人員來說，工作量可以減輕大半，工作效果會大幅提高。但是我們在需求分析階段，即便是在需求評審之后，我們拿到的需求文檔，仍然是存在一些疑義的或者是分析不透，表達不清的一些需求文檔。這樣的時候，測試人員是否有自己的分析方法，顯得尤為重要。
測試人員對付需求文檔，從操作策略上來說，可以從以下兩點出發：
（一）、對于需求規格全面、完整的需求文檔來說，我們可以采取“切割策略”，把需求按一定的粒度進行分解，來編寫測試用例。
（二）、對于簡單不全面、需求規格含糊的需求文檔，我們可以采取的策略：“聯想策略”。這點還是主要來自工作經驗及對該行業的理解，把一些含糊的內容補充起來。
在參與需求文檔閱讀的過程中，我們還可以采用一些小方法，把需求吃透。例如：
1、在參與需求閱讀的過程中，我們可以把需求中的一些邊界或者異常的情況列出來，這些往往是以后bug的多發地帶。
2、對于需求文檔中的一些隱式缺陷，我們需要補充清楚質量屬性，例如一些安全性、性能、UI等的一些質量屬性內容，我們需要補充清楚。
3、對需求文檔的閱讀，我們還可以采用一些工具：思維導圖工具及UI界面設計工具，把圖給畫出來，有助于我們理解需求，找到測試點。例如思維導圖工具，通過名詞+動詞的方法，可以把測試數據和操作動作列出來，有利于理清測試的要點。
通過以上的一些策略和方法，我們大致上可以把需求測試分析做的比較到位了。
測試人員對需求文檔分析后，接下去還需要對設計文檔進行分析，大部分的測試人員，不是太注重開發組的這份設計文檔，覺得與己無關，其實，理解設計文檔，有利于降低我們的測試規模，降低勞動負荷。一般來說缺陷會與內部結構映射，如果你了解了代碼的結構，一般來說，我們都可以找到缺陷出現的真正原因了。這里有一種工具，可以幫助我們進行這方面的工作，就是UML的反向工程獲得設計模型，該工具網上大家也可以找到。
二、測試用例設計階段
通過以上對需求文檔和設計文檔的分析，下面我們來淺談下測試用例的設計，測試用例一般由三部分內容組成：步驟、數據、標準。步驟一般與需求規格說明書相對應，對于某些共享步驟，可以進行參數化，或借用工具進行管理，步驟的描述應該無二義性。測試標準，主要為預期值與結果值的對比方式。
對于測試數據的設計，這里我們講解以下幾種方法：
1、最原始的方法：排列組合。
通過排列組合，把所有的數據都遍歷過，這樣的窮舉的方法，盡可能的把系統都測試到位。但數據龐大，這樣窮舉的方法，會讓測試陷入困境。
2、邊界值和等價類的方法。
通過邊界值和等價類劃分，可以大大的縮小測試范圍，提高了測試效率。在任何情況下都必須使用邊界值分析方法，經驗表明用這種方法設計出測試用例發現程序錯誤的能力最強。必要時用等價類劃分方法補充一些測試用例。
3、因果圖表和決策表法。
如果程序的功能說明中含有輸入條件的組合情況，則一開始就可選用因果圖法。因果圖分析法，是為了解決邊界值分析和等價劃分的一個弱點：未對輸入條件的組合進行分析。而因果圖恰恰有助于用一個系統的方法選擇出此類高效的測試用例集，并且可以指出規格說明的不完整性和不明確之處。步驟如下：
1）將規格說明分解為可執行的片段；
2）確定規格說明中的因果關系；
3）分析規格說明的語義內容，并將其轉換為連接因果關系的布爾圖，即：因果圖；
4）給圖加上注解符號，說明由于語法或環境的限制而不能聯系起來的“因”和“果”；
5）經過仔細地跟蹤圖中的狀態變化情況，將因果圖轉換成一個有限項的判定表；
6）將判定表中的列轉換成測試用例。
4、“猜”技術。
為特殊測試點準備測試數據。
看完了上面的測試用例設計方法，我們來看下測試用例的設計步驟：
1）構造根據設計規格得出的基本功能測試用例；
2）邊界值測試用例；
3）狀態轉換測試用例；
4）錯誤猜測測試用例；
5）異常測試用例；
6）性能測試用例；
7）壓力測試用例。
以上我主要講解了一些平時比較常用的測試用例設計方法，如果更細化，還可以找出更多的測試用例設計方法。其實，這些方法和設計步驟通過我們的加工，都融入到了測試用例中去了，所以測試用例是測試的靈魂，一點都不為過。有時可以不需要很完美的測試用例模板，但是一定要有完美的覆蓋率的測試用例。
【編輯推薦】
