這裡說的不是設計測試用例的數量，而是測試用例的書寫。
我在實習期間對乙個內部使用的工具進行測試，負責增刪改查部分。作為實習生，很想有乙個準確的答案告訴我該怎麼做不該怎麼（應試教育的惡果），但實際工作中確實是乙個人有乙個人的風格，聽多了反而不知道該怎麼做。所以我第一批的tc寫的特別詳細，
如：前置條件： entity表中有乙個 xx欄位 = xx ，oo欄位 = oo 的實體記錄。
等等，把需要準備的資料也寫到tc裡面了。
很費時間！！
可能一天都花在書寫tc上了，文字重複量也很多，一天下來什麼成就感都沒有。
而且由於是對內開發的軟體，開發方經常改動頁面，導致tc也要更改。寫的粗一點的還好說，像我寫這麼詳細，改起來真的很痛苦。但不寫這麼詳細又怕不對（我真是如履薄冰一樣的前行啊。）
在各處搜尋了一下，覺得下面這個人說的最有道理，以後可以參考之。
[html]view plaincopy
?@smilehe:
切身感受：
如果自己寫用例並自己測試，除了邊界上或者異常等處必須詳細，之外的可以「自己清楚」；
如果寫給別人用，老老實實的寫詳細；
如果自己寫 用例並打算日後也做為其他專案參考，建議事後補詳細！
在設計用例的時候可以用mm圖將功能點仔細分析，具體每乙個用例後，可以在後面列出要輸入資料的型別作為備註，防止在freetest中書寫tc時遺忘。
在freetest上，先寫上名字就行。反正是自己測試，測試點都在mm圖上。等有時間，或者專案接近尾聲的時候/開發不再有改動時，再去完善tc。
如何寫好測試用例
注意優先順序和重要級不一定成正比關係。比如 週末出去玩，但是公司突然加班 優先順序 出去玩 重要級 回公司加班 當然結果是回去加班 如何選擇適當的資料子集，來代表整個資料集。通過降低測試的資料去實現 合理的 覆蓋，覆蓋了更多的可能資料，以發現更多的軟體缺陷 使用邊界值分析方法設計測試用例時一般與等價...
如何寫好測試用例設計
測試用例設計的輸入文件是什麼？1 開發文件 這裡的開發文件是乙個統稱，不同組織對其的稱呼不同，包含了系統需求規格 概要設計規格 詳細設計規格等不同的開發文件。2 使用者需求 軟體測試同時包含了驗證 verification do you build the product right？與確認 val...
軟體測試如何寫好測試用例？
軟體 資料 程式 文件 測試時就是運算元據，操作的主體就是程式，文件就是工作時的視覺化 軟體測試的基礎 軟體測試就是保證軟體質量，滿足使用者需求的一種手段 測試流程 需求分析 制定計畫 編寫用例與執行 對測試結果的分析報告 測試的生命週期 測試計畫，測試設計，測試開發 測試用例的編寫 測試執行，測試...