什么時候算是完成了測試用例的設計工作?
上面幾條可以算是網絡上測試用例設計方面最熱的問題，而且每隔一段時間就會被不同的人重新提起。提問的有剛剛進入測試行業的朋友，也有工作一段時間后重新陷入迷茫的“老手”。這幾個問題看似簡單，可是要想回答的讓大家都感到滿意，還真是不容易。這樣的高難度，筆者也不敢有太多的奢望，還是把自己的經驗寫出來，希望對大家有些參考價值吧。
測試用例是為特定目標開發的測試輸入、執行條件和預期結果的集合。這些特定目標可以是：驗證一個特定的程序路徑或核實是否符合特定需求�！@是RUP中關于測試用例的定義。而在實際工作中，對于測試用例的設計和選擇，是考察一個測試人員工作能力和經驗的最好方法。
如果您像筆者前面說的那樣，已經在工作中開展了測試需求的整理工作，那么測試用例的設計工作就會變成一件自然而然的事情了。如果您在需求階段就開始了對測試需求的整理，那么當這部分測試需求整理完后，就可以開始相應測試用例的設計了。而隨著開發工作的繼續，在測試需求被不斷的增補、調整后，也應該添加或修改相應的測試用例，以保證測試用例的有效性。這里筆者要特別強調一點：測試用例的完成并非是一勞永逸的，因為測試用例是來源于測試需求，而測試需求的來源包括了軟件需求、系統設計、詳細設計，甚至包括了軟件發布后，在軟件產品生命周期結束前發現的所有軟件缺陷。來源的多元化注定了測試需求是非常容易發生變化的。一旦測試需求發生變化，則測試用例必須重新維護。
如果您對于軟件開發的迭代方法比較熟悉，那么就可以對測試用例的設計采用同樣的方法。而最終的結果，是您的團隊將逐漸擁有越來越全面細致的測試需求和測試用例庫，測試人員越來越多的精力，可以放到對測試過程的考慮和測試用例的選擇方面。
至少在筆者的實踐中，這種方法雖然前期需要相對大量的投入，但隨著時間的遷移，在沒有使用自動化測試工具的情況下，同樣大大提高了每個測試人員單位時間內測試工作的效率。
關于設計測試用例的方法，無論是在已經出版的專業測試書籍還是網絡上的專業測試論壇中，都已經有了很多非常好的文章來專門講解，筆者也不打算占用太多篇幅重新引用，大家如果有這方面需要，通過網絡都可以很容易的找到這些資料。在這里，筆者只是想簡單的評論一下很多初學者對這些方法容易產生的誤解。
相信對于任何一個測試人員來說，等價類劃分法和邊界分析法都是最早接觸，也是最基本、最容易使用的測試用例設計方法。很多朋友也都知道先使用等價類劃分法劃分出等價類，然后使用邊界分析法確定測試需要的邊界值。但是很多朋友也提到，在工作了一段時間后，發現這兩中方法所能應用的地方越來越少，難道這兩種方法真的只能應用在檢查編輯框輸入類型和輸入長度的時候嗎?當然不是。對于一些剛剛接觸測試工作的朋友提出的這個問題，筆者認為現在市面上的很多測試書籍都要承擔很大的責任。比如很多書中，在講到測試用例設計時，都不約而同的使用同一個例子——Windows計算器程序。通常是告訴你對于計算器有一個允許的輸入范圍(比如允許輸入一個大于0小于等于100的整數)，然后要求設計相應的包含合法數據和不合法數據的測試用例。當然，僅僅是這樣一條簡單的描述，我們已經可以設計出很多測試用例和測試數據了，比如對于輸入范圍的考慮，對于輸入數據類型的考慮，對于輸入長度的考慮等等。但是在我們的實際工作中，很多時候看到的并不是這樣過于簡單的軟件需求描述，很多時候這些內容都是隱含在一些算法或業務規則中的。
我們現在舉個例子來看一下：
“雙倍余額遞減法是在不考慮固定資產殘值的情況下，以平均年限法折舊率(不扣殘值)的兩倍作為折舊率，乘以每期期初固定資產折余價值求得每期折舊額的一種快速折舊的方法。
年折舊率=2÷預計使用年限×100%
月折舊率=年折舊率÷12
文章來源于領測軟件測試網 http://www.anti-gravitydesign.com/
