當然該文檔不是非要不可，筆者只是提倡一種原則，如果有類似的替代文檔或有工具可自動實現此功能，則會倍加受推崇!
筆者之所以推薦IBM Rational系列產品在軟件項目中的應用，是因為IBM Rational倡導的RUP(Rational Unified Process)方法論采用了用例驅動的原則。所謂用例驅動，是以體系結構為中心，采用迭代、增量方式的開發過程;而其Rational工具系列正是將這一理念進行行為表述，是當前軟件工程領域一套無可比擬的強大工具集，從需求到測試，它都以用例為基本模型，全面貫穿軟件開發的每個環節。
3) 軟件開發階段，編寫測試用例。我不想從技術角度探討到底如何編寫功能強大、質量優秀的測試用例(可參考筆者主頁轉載的"如何設計編寫軟件測試用例")，這里只想從管理角度和大家談談如何有效控制和增強測試用例在測試活動中的應用。應該遵守的原則是：
首先，從覆蓋率來說，測試用例庫的用例要達到最大覆蓋軟件系統的功能點。按照我上述所言的方式，測試工程師從前期階段順次下來，編寫測試用例時，基本上就是將《軟件功能點測試描述書》中的每個功能點進行操作上的細化：一是從步驟上描述到達校驗點的方式，二是從內容上描述以何種數據校驗功能點;如此可實現趨向最大需求覆蓋率。
其次，從數量來講，筆者覺得很多公司的測試用例太少，甚至遠遠不能覆蓋系統需求，這也是很多測試人員在測試工作開展初期按照用例執行、而后漸漸憑"意念"去執行測試的原因。應該說測試用例的數量很難用數學模型來模擬，更沒辦法衡量，但憑借個人經驗來說，一個多于半年開發周期(指從編碼開始直到提交客戶的時間段)的軟件系統，它的用例數量不要低于4000個，甚至更多!也許有人驚訝這一數字，不過了解IBM等大公司測試過程的人士會認為4000還是很少的數目。我們試想，對于一個中小型軟件系統，如果設計出5000個用例，那它的測試覆蓋率還怕不高么!
再次，如此眾多測試用例的管理問題。是的，需要管理工具軟件!筆者從來都反對以word或excel來編寫測試用例：
首先，格式上難于編寫--通常方式是企業自己設計表格模版，但編輯上始終存在不便，尤其對于一些共性內容，如測試目標、測試環境、參考說明等，每次都要大量的復制、粘貼。
其次難于管理--如果把幾千個文檔文件放在一個共享文件夾里，即便以子目錄方式管理，但是每次查找一個特定用例，你的眼睛也必將飽受煎熬! 更是難于執行--莫非真要針對幾千個用例都是打開一個word-執行測試-輸入測試結果-關閉word嗎? 最重要的是，根本沒辦法追蹤測試結果--在本輪回歸測試輸入完測試結果，但是下一輪結果輸入到哪里?輸入了這些測試結果什么用?能方便的根據其結果統計軟件質量嗎?還有，可以用它追蹤發現的軟件缺陷嗎?有辦法追蹤嗎? 使用word等軟件編寫測試用例的種種不便大致如上，但換個思路思考一下使用集成工具的種種優勢便更加一見分曉。測試同業者們都了解的測試用例管理工具便是IBM Rational TestManager，它是專業的測試用例管理和測試管理工具，其設計出發點就已經考慮到了我們上述的種種困境，因此給予了良好的解決方案。以其為測試管理平臺，測試人團隊成員可以計劃、管理、組織、執行、評詁以及報告等縱向測試活動，如果與IBM Rational Clearquest集成使用，還可即時跟蹤軟件的需求變更，從而增強整個軟件團隊的橫向溝通與合作。
而且，個人覺得測試行業的快速發展，必將帶來從每個環節都逐漸向自動化和標準化方向邁進，盡早適應這一趨勢，不僅提高了工作效率，也提高了企業的信譽和名譽。 最后，說一下測試用例格式上一般內容以外的幾個要點：
一、是在測試管理工具中制定適合本公司的測試用例模版
二、是用例模版里要有關鍵字索引，以方便按關鍵字分類查找，如測試方法(分手工/自動兩種)
三、是測試用例要有狀態跟蹤，可根據用例執行狀態索引用例(測試通過、測試失敗、測試中斷等)
文章來源于領測軟件測試網 http://www.kjueaiud.com/
