測試用例設計得不可能天衣無縫，測試執行過程里肯定會發現有些測試路徑或數據在用例里沒有體現;那么事后該將其補充到用例庫里，以方便他人和后續版本的測試;如果沒有這樣做，那么測試部門負責人和每個測試員都難辭其疚，是該重新坐下來思考一下公司的測試用例管理規范或流程了。
那么究竟如何做，才能盡量避免上述問題呢?我們不妨從需求階段就把這些問題考慮進去，以便從初始就力爭將問題縮到最小，以防后期出現問題是互相推卸責任或干脆束手無策!
軟件需求分析階段，我從來認為測試人員從軟件生命周期的需求階段就開始介入，因為測試人員的工作通常開展在該周期的末尾，如果前期不涉入，如何通曉整個系統的架構而對其測試呢?雖然該觀點被大多數同行所認可，但我知道依然有很多公司為了節省費用，不讓測試人員參與前期調研或制定需求，經常的做法是等到系統開發完畢或將近完成，跟測試經理說一聲“這邊有個項目，你找幾個人來測一下吧!”經驗表明，這樣的做法實不可取。
測試人員在需求階段的任務有：
全面了解系統需求，從客戶角度考慮軟件測試需要達到的驗證值。
參與軟件需求調研，以測試角度分析需求的可測性;對不可測問題與客戶或項目經理協調解決。
如果企業采用類似與rational requistepro的需求管理工具，這個工作也需要測試人員的配合實施。
軟件分析設計階段，測試人員除制定測試計劃書等本職工作外，我認為還有一個必不可少的任務，那就是將系統的可測性落實到書面文檔，以備將來編寫測試用例。之所以要這么做，是因為考慮到很多企業編寫測試用例直接參考需求規格說明書或者分析流程圖，這樣跨度大，難度也大，是造成測試用例不完備、覆蓋范圍小的重要原因。
如果公司采用類似于rational rose的建模分析工具，這個工作更好執行;如果沒有，那么測試人員更有必要編寫一份《軟件功能點測試描述書》，它是軟件的詳細測試分析文檔，其主旨是將系統分析人員的分析文檔加工成站在測試角度的功能點分析文檔，重要的是描述對系統分解后每個功能點逐一的校驗描述，包括何種方法測試 何種數據測試 期望測試結果等，這些信息都是描述性的，無須具體數據;它的作用是據此編寫測試用例，以及測試執行時的參考依據，它直接來源于需求，覆蓋最全，也最貼近客戶。
當然該文檔不是非要不可，我只是提倡一種原則，如果有類似的替代文檔或有自動工具可實現此功能，則會倍加受推崇!軟件開發階段，編寫測試用例。我不想從技術角度探討到底如何編寫功能強大質量優異的測試用例(可參見我在“天若有情”轉載的這篇文章- 如何設計編寫軟件測試用例)，這里只想從管理角度和大家談談如何有效控制測試用例的流程。應該遵守的原則是：
首先，從覆蓋率來說，測試用例庫的用例要達到最大覆蓋軟件系統的功能點。按照我上述所言的測試工程師從前期階段順次下來，編寫測試用例時，基本就是將《軟件功能點測試描述書》中的每個功能點進行操作上的細化：一是將從步驟上描述到達校驗點的方式，二是從內容上以何種數據校驗功能點。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
