其次，從數量來講，我覺得很多公司的測試用例太少，甚至遠遠不能覆蓋系統需求，這也是很多測試人員測試開展前期按照用例執行，漸漸憑“意念”去測試的原因。應該說測試用例的數量很難用數學模型來模擬，更沒辦法衡量，但憑借個人經驗來說，一個多于半年開發周期(指從編碼開始直到提交客戶的時間段)的軟件系統，它的用例數量不要低于4000個，甚至更多!也許有人驚訝這一數字，不過了解IBM Microsoft 的人士會認為4000還是很少的。試想，對于一個中型軟件系統，如果設計出5000個用例，那它的測試覆蓋率還怕不高么!
再次，如此眾多的測試用例的管理。是的，需要管理工具軟件!本人從來都反對以word或excel來編寫測試用例，那樣不僅在格式上難于編寫——尤其對于一些共性內容：測試目標、測試環境、參考說明等，每次都要拷貝;而且難于管理——幾千個文檔文件放在一個共享文件夾，你的眼睛要必將經過繚亂的洗禮!更是難于執行——莫非真要針對幾千個用例都是打開一個word、執行測試、輸入測試結果、關閉word?而且，根本沒辦法追蹤測試結果——輸入完本輪回歸測試的結果，下一論輸入哪里?輸入了這些測試結果什么用?用它追蹤什么?追蹤得到嗎?
使用word等軟件編寫測試用例的種種不便不多說，但換個思路思考一下使用集成工具的種種優勢就一見分曉。測試同業者們都了解的測試用例管理工具便是rational testmanager(點擊http://www-900.ibm.com/cn/software/rational/products/testmanager/index.shtml了解其基本功能)，其實還有很多國內外中小型工具，如微創的testcasemanage，他們是專業的測試用例管理工具，其設計出發點就已經考慮到了我們上述的種種困境，因此給予了良好的解決方案，他們是專業的測試用例管理工具，其設計出發點就已經考慮到了我們上述的種種困境，因此給予了良好的解決方案。而且，個人覺得測試行業的快速發展，必將帶來從每個環節都逐漸向自動化和標準化方向邁進，盡早適應這一趨勢，不僅提高了工作效率，也提高了企業的信譽和名譽。
最后，說一下測試用例格式上一般說明外的幾個要點：
一是在測試管理工具中制定適合本公司的測試用例模版
二是模版有關鍵字索引，以方便按關鍵字分類查找，如測試方法(分手工/自動兩種)
三是測試用例要有狀態跟蹤，如執行失敗要鏈接到缺陷報告
四是測試用例的修改及運行都有日志記錄
軟件測試階段，測試負責人劃分不同的測試階段(如集成測試 系統測試 回歸測試 性能測試等)，再劃分不同的子測試周期(如前兩個星期做冒煙測試，可手工，也可自動;接著做第一模塊功能測試，順次…)，再為項目測試人員分配測試用例，測試人員則按照詳細的用例文檔去執行測試，這里要遵循的幾個原則是：
文章來源于領測軟件測試網 http://www.kjueaiud.com/