軟件測試設計 測試用例設計
測試設計是一個很大的課題，測試階段、測試方法、測試類型、甚至軟件類型、性質，以及用戶群的不同，其測試設計方法也不同。在此文檔中只總結集成測試中功能測試的黑盒測試的設計。針對我們正在測試的指標管理軟件，如此也就進一步固定了軟件類型、性質，以及用戶群，也更有利于闡述測試設計的方法。
就是如此狹義上的測試設計也有許多的設計方法，其中包括用例分析法、逐步精細法、數據驅動法、功能分解組合法等。本文檔只總結被廣泛接受的RUP內的用例分析法。
測試設計的幾個原則
不要測試非常簡單的事情
一般來說，對被測試程序的每一個（公共）功能，你都需要有一個測試用例涉及到它。但是對于一些顯然不可能出錯的地方，設計測試用例幾乎沒有意義。譬如窗口的關閉，一方面它們實現的功能非常直截了當，另一方面每個人測試時都在不斷關閉窗口。當然，如果這些窗口關閉不是非常的直截了當，對它們的操作會觸發其他一系列工作，例如分情形打開不同的窗口等，你可能需要為它設計測試用例。
為這些簡單、直接、繁瑣的功能設計測試用例，不能提高軟件質量，同樣對增進測試也沒有好處。相反，它可能使得測試設計人員厭倦這樣的測試設計，測試人員也會喪失對于測試的信心。
測試任何可能出錯的地方
XP 的測試原則之一說：“測試任何可能出錯的地方”
可能做到嗎?更何況80/20規則告訴我們80%的利益來自于20%的活動，為每一種行為的組合寫上一個測試不但不可能，同時也是沒有實際意義的。
但在很多次讀到這樣的規則或聲明之后，自然就逐漸意識到這句話所含的深意，這一條規則其實想告訴我們不要測試什么��！測試所有可能出錯的地方也就是告訴我們不要測試不可能出錯的地方，正如前面所說：不要測試非常簡單的事情。
這條規則相當容易引起誤會。
我們知道要完全達到100%測試是不可能的，0-BUG只是一個理想。況且，對軟件不進行充分測試就是犯罪，同樣，過分的測試也是一種嚴重的浪費行為。既然知道不可能，所以問題發生的時候我們并沒有太大的壓力。
那么什么是這條規則真正要告訴我們的東西呢?
程序功能越復雜，要完全測試它的難度就越大。相反，程序功能越簡單，完全測試(我們心目中的理想)它的可能性就越大。
可以得出結論：這條規則告訴我們，應當讓程序功能盡可能簡單，盡可能容易理解，因此也就更加容易測試，更加不會出錯。
反饋到測試設計就是說，當你覺得完全不可能做到這條規則時，你應該考慮當前程序實現的程序功能是否太復雜了，是否包含了太多的責任和狀態。是否將多個功能生硬地雜糅到了一起。你也許會建議程序設計人員把這個設計好的功能分為2 個甚至3個功能，讓他們更容易測試。也許你會得出更簡化實現功能所必須步驟的復雜程度的方法，并建議程序設計人員簡化實現功能的步驟；當用戶不得不每次按照同樣的順序來完成一個功能，而這些步驟的單獨部分沒有被其它功能使用，我們也許就應該建議程序設計人員合并這些步驟，以更方便用戶的理解以及操作，同時也更避免了出錯的可能性，因為程序對于用戶封閉的越多，由于用戶的誤操作引發的錯誤就越少。從這一點來說，測試促發了程序的合理的設計變更。
測試邊界條件
這些地方屬于傳統的測試角落。對于邊界條件，你必須保證考慮到了所有可能出錯的地方。集合是否為空？第一個？最后一個？諸如此類的問題必須小心考慮。對于這些邊界條件的確定和測試用例編寫， 如：
未初始化：程序的參數沒有初始化，最好解決方法是要求程序員在定義每個參數都先賦予一個明顯沒有意義的錯誤的數據，如此在錯誤發生的時候，測試立刻可以判斷出此處有錯誤，而不是一個似是而非的數據，例如界面上顯示數學成績的結果為w w，我們立刻可以判斷錯誤出現了，而看到結果為65，但實際上應該85，我估計就很難判斷了。此處臨時舉了一個不恰當例子，本意是能說明問題就好。如果以上不能做到，沒有辦法，只能是認真詳盡檢查，同時要求測試設計時也得仔細設計能夠讓問題發生的用例。
文章來源于領測軟件測試網 http://www.kjueaiud.com/