從軟件測試用例看測試的問題及變化 軟件測試

　　對于一個測試人員來說測試用例的設計與編寫是一項必須掌握的能力。但有效的設計和熟練的編寫卻是一個十分復雜的技術，它需要你對整個軟件不管從業務還是功能上都有一個明晰的把握。如何系統、結構的對用例加以規范將直接影響到其后的測試效率和效果，同時測試用例也將用來控制軟件的整體執行覆蓋，對最后的測試結果給出一種量化的評估標準。

　　一、問題：

　　許多測試類的書籍都有大幅篇章介紹用例的設計方法，如等價類劃分，邊界值，錯誤推斷，因果圖，判定表等。但實際應用中這些理論卻不能給我們很明確的行為指導，尤其是業務復雜，關聯模塊緊密，輸入標準和輸出結果間路徑眾多時，完全的遵循這些方法只能讓我們在心理上得到一種滿足，而無法真正有效的提高測試效率，并且我們也沒有足夠的時間和資源編寫完備的用例。通常我們只能依靠以前項目的用例編寫經驗(或習慣)，希望能在這一個項目中更加規范，但多數情況下我們規范的只是“書寫的規范”，在用例設計上以前存在的問題現在依舊。

　　當好不容易用例基本完成，我們卻發現面對隨之而來的眾多地區特性和新增需求，測試用例突然處于一種十分尷尬的境地：

　　* 從此幾乎很少被執行

　　* 已經與程序的實現發生了沖突(界面變動，功能變動)

　　* 執行用例發現的bug很少

　　* 根本沒有時間為新的功能需求增補用例

　　* 有時間補充，但用例結構越來越亂

　　* 特性的用例與通性用例之間聯系不明確(以新增需求為主線列出所有涉及到的更改，但特性與通行之間的數據或業務聯系在用例中逐漸淡化)

　　知道怎樣執行這個用例，但它要說明什么呢?(多數用例給我們的感覺是只見樹木，不見森林，只說明某一功能的實現，無法串起)

　　通過上面的一系列問題可以看到，似乎測試用例給我們帶來的問題遠多于益處，也正是因為在實際過程中遇到的問題積累，導致我們有很充分的理由忽視或拒絕用例的應用。

　　但沒有用例或簡略用例的編寫我們又會舒服很多么?不言自明，誰也不想倒退發展。

　　2010年下半年軟考成績查詢時間及方式匯總

　　2011年上半年計算機軟考時間及科目安排

　　2011年軟件水平考試軟件測評師基礎知識輔導匯總

　　2011軟考軟件測評師測試技術輔導匯總