二、原因：

　　事實上我們在測試用例編寫和設計上遇到的一系列問題只是一種表面的呈現，究其原因我認為有如下幾點：

　　1、沒有適合的規范

　　“適合的規范”或稱“本地化的規范”。這是我們在測試過程中遇到的第一個問題，通常也是很容易習慣且淡忘的。我們擁有相當多的流程文檔、指導步驟和書本上的定義，但它適合我們當前的項目么?

　　每一個測試工程師在進入這個職業的初期都會了解一些測試上的概念和術語，進入公司或項目組后也會進一步學習相應的文檔，例如怎樣規范編寫，怎樣定義bug級別，軟件實現的主要業務等。但當測試經理開始給我們分配某一模塊的用例編寫時，又有多少人知道該怎樣去寫，怎樣寫算是好?

　　在測試論壇中常能看到介紹用例編寫方法的帖子，而迷茫于怎樣應用到實踐的回復也不為少數。為何我們無法在公司和項目組內找到明確且適合的規范?于是我們只得選擇從書本或之前的用例中復制，不管是結構還是方式都依賴于以往的經驗，我并不是說這樣就是錯誤的，但不能總結成文的經驗無法給予測試更多幫助。我們有太多經驗，但卻沒有形成適合的規范。

　　2、功能與業務的分離

　　我們知道怎樣列舉一個輸入框的用例，但卻很少考慮說明這個輸入框是用來做什么的，如果仔細分析不難發現，用例中這種功能與業務的分離越來越普遍也越來越明顯。

　　邊界值、等價類劃分、因果圖，這些用例方法是一種高度提純的方法，本身就很偏向于功能及代碼，所以怎樣編寫業務的用例我們就從理論上失去了參考。

　　復雜的業務會貫穿于整個軟件，涉及眾多功能點，里面組合的分支更不可勝數。測試用例務求簡潔、明確，這一點也與業務“格格不入”。功能用例依賴程序界面，業務描述依賴需求文檔。于是我們更偏向于根據已實現的界面編寫功能用例，列舉出眾多的邊界值、等價類。流程的操作只有憑借經驗和理解，這時測試出的bug是最多的，但我們卻無法使這個bug對應到一個用例中(點擊一個按鈕報出的錯誤有時原因并不在這個按鈕或按鈕所在的窗體)，只能自己添加note向開發人員指出可能出錯的源頭。正因為我們沒有很好的積累業務上的用例，才使得我們感到執行用例時發現的bug不多。

　　用例結構的劃分一定程度上也造成了功能和業務的分離，依照界面模塊建立文件夾，并在其中新建不同用例，這使得用例從結構上就很難聯通起來。

　　3、測試未能跟上變化

　　變化!想象一下，當我們越來越多的聽到開發人員在那里高呼“擁抱變化”“敏捷開發”的時候，測試又有什么舉措呢?當地區特性，軟件版本越來越多的時候，測試是否在積極響應呢?變化是我們面臨的最大挑戰，我認為測試未能跟上變化是造成測試過程中遇到種種問題和矛盾的主要原因。

　　對需求和程序的變化測試人員的感受是非常深的，測試總是跟在需求和開發后面跑，使得所有風險都壓在自己身上。不斷壓縮的時間和資源使我們只能放棄那些“不必要”的工作：盡快投入測試，盡快發現bug，而非從整體把握軟件的質量情況，統籌策略。

　　疲于應對的直接影響就是程序質量無法準確度量，進度無法控制，風險無法預估。用例與程序脫節，新增用例混亂和缺少。長此以往我們只得放棄修改、增補用例，甚至放棄之前積累的所有成果。用例變為程序變更的記錄摘要，沒有測試數據的保留，測試步驟和重點無法體現，新加功能與原來的程序逐漸“脫離”，可能還會出現相互違背的情況，但這我們卻無法及時發現。

　　永遠是變化決定我們的下一步工作，這也是混亂的開始。

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

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

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

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