1樓：淡煙
這裡說的不是設計測試用例的數量，而是測試用例的書寫。
如：前置條件： entity表中有一個 xx欄位 = xx ，oo欄位 = oo 的實體記錄。
等等，把需要準備的資料也寫到tc裡面了。
很費時間！！
而且由於是對內開發的軟體，開發方經常改動頁面，導致tc也要更改。寫的粗一點的還好說，像我寫這麼詳細，改起來真的很痛苦。但不寫這麼詳細又怕不對（我真是如履薄冰一樣的前行啊。）
在各處搜尋了一下，覺得下面這個人說的最有道理，以後可以參考之。
@smilehe:切身感受：
如果自己寫用例並自己測試，除了邊界上或者異常等處必須詳細，之外的可以「自己清楚」；
如果寫給別人用，老老實實的寫詳細；
如果自己寫 用例並打算日後也做為其他專案參考，建議事後補詳細！
在設計用例的時候可以用mm圖將功能點仔細分析，具體每一個用例後，可以在後面列出要輸入資料的型別作為備註，防止在freetest中書寫tc時遺忘。
在freetest上，先寫上名字就行。反正是自己測試，測試點都在mm圖上。等有時間，或者專案接近尾聲的時候/開發不再有改動時，再去完善tc。
2樓：權鶴易尋芳
另外一種觀點就是主張寫的粗些，類似於編寫測試大綱。主張這種觀點的人是因為軟體開發需求管理不規範，變動十分頻繁，因而不能按照歐美的高標準來
編寫測試用例
。這樣的測試用例容易維護，可以讓測試執行人員有更大的發揮空間。
實際上，
軟體測試用例的詳細程度首先要以覆蓋到測試點為基本要求。舉個例子：「使用者登陸系統」的測試用例可以不寫出具體的執行資料，但是至少要寫出五種以上情況（），如果只用一句話覆蓋了這個功能是不合格的測試用例。
覆蓋功能點不是指列出功能點，而是要寫出功能點的各個方面（如果組合情況較多時可以採用等價劃分）。
另一個影響測試用例的就是組織的開發能力和測試物件特點。如果開發力量比較落後，編寫較詳細的測試用例是不現實的，因為根本沒有那麼大的資源投入，當然這種情況很隨著團隊的發展而逐漸有所改善。測試物件特點重點是指測試物件在進度、成本等方面的要求，如果進度較緊張的情況下，是根本沒有時間寫出高質量的測試用例的，甚至有些時候測試工作只是一種輔助工作，因而不編寫測試用例。
功能測試用例模板
因此，測試用例的編寫要根據測試物件特點、團隊的執行能力等各個方面綜合起來決定編寫策略。最後要注意的是測試人員一定不能抱怨，力爭在不斷提高測試用例編寫水平的同時，不斷地提高自身能力。
功能測試用例需要詳細到什麼程度才是合格的？
3樓：匿名使用者
1、指導測試的實施 測試用例主要適用於整合測試、系統測試和迴歸測試。在實施測試時測試用例作為測試的標準，測試人員一定要按照測試用例嚴格按用例專案和測試步驟逐一實施測試。並對測試情況記錄在測試用例管理軟體中，以便自動生成測試結果文件。
根據測試用例的測試等級，整合測試應測試那些用例，系統測試和迴歸測試又該測試那些用例，在設計測試用例時都已作明確規定，實施測試時測試人員不能隨意作變動。 2、規劃測試資料的準備 在我們的實踐中測試資料是與測試用例分離的。按照測試用例配套準備一組或若干組測試原始資料，以及標準測試結果。
尤其象測試報表之類資料集的正確性，按照測試用例規劃準備測試資料是十分必須的。 除正常資料之外，還必須根據測試用例設計大量邊緣資料和錯誤資料。 3、編寫測試指令碼的」設計規格說明書」 為提高測試效率，軟體測試已大力發展自動測試。
自動測試的中心任務是編寫測試指令碼。如果說軟體工程中軟體程式設計必須有設計規格說明書，那麼測試指令碼的設計規格說明書就是測試用例。 4、評估測試結果的度量基準 完成測試實施後需要對測試結果進行評估，並且編制測試報告。
判斷軟體測試是否完成、衡量測試質量需要一些量化的結果。例:測試覆蓋率是多少、測試合格率是多少、重要測試合格率是多少，等等。
以前統計基準是軟體模組或功能點，顯得過於粗糙。採用測試用例作度量基準更加準確、有效。 5、分析缺陷的標準 通過收集缺陷，對比測試用例和缺陷資料庫，分析確證是漏測還是缺陷復現。
漏測反映了測試用例的不完善，應立即補充相應測試用例，最終達到逐步完善軟體質量。而已有相應測試用例，則反映實施測試或變更處理存在問題。
4樓：淚溼緣分
另外一種觀點就是主張寫的粗些，類似於編寫測試大綱。主張這種觀點的人是因為軟體開發需求管理不規範，變動十分頻繁，因而不能按照歐美的高標準來
編寫測試用例
。這樣的測試用例容易維護，可以讓測試執行人員有更大的發揮空間。
實際上，
軟體測試用例的詳細程度首先要以覆蓋到測試點為基本要求。舉個例子：「使用者登陸系統」的測試用例可以不寫出具體的執行資料，但是至少要寫出五種以上情況（），如果只用一句話覆蓋了這個功能是不合格的測試用例。
覆蓋功能點不是指列出功能點，而是要寫出功能點的各個方面（如果組合情況較多時可以採用等價劃分）。
另一個影響測試用例的就是組織的開發能力和測試物件特點。如果開發力量比較落後，編寫較詳細的測試用例是不現實的，因為根本沒有那麼大的資源投入，當然這種情況很隨著團隊的發展而逐漸有所改善。測試物件特點重點是指測試物件在進度、成本等方面的要求，如果進度較緊張的情況下，是根本沒有時間寫出高質量的測試用例的，甚至有些時候測試工作只是一種輔助工作，因而不編寫測試用例。
功能測試用例模板
因此，測試用例的編寫要根據測試物件特點、團隊的執行能力等各個方面綜合起來決定編寫策略。最後要注意的是測試人員一定不能抱怨，力爭在不斷提高測試用例編寫水平的同時，不斷地提高自身能力。
什麼樣的測試用例是好的測試用例,什麼是測試用例
1 用例覆蓋程度 毫無疑問，這一點應該是最重要的，無需多說，覆蓋率最大化是一套測試用例的最重要評價標準，如果漏測就杯具了。2 用例是否已經達到工作量最小化 在滿足用例覆蓋程度最大化的前提下，應該儘量減小執行用例所需要的工作量。這些方面的方法有不少，如條件覆蓋，分支覆蓋，正交覆蓋等方法。面對不同的測試...
和bugfree相容比較好的測試用例管理工具
testlink啊，我已經整合過了，可以把測試用例管理和bug管理結合起來了 一般缺陷管理工具和測試用例管理工具都是分開的，沒有必要整合，如果非要整合，td很不錯。bugfree裡有bug和test case吧 有哪些測試管理工具，能同時管理bug與測試用例的 quality center 請參考 ...
軟體測試用例中報告結果的na是什麼意思
cmcc測試用例中的n a，是指沒有條件或者環境去測這一條case，比如某一條case需要某種輔助工具去測試，而這種輔助工具沒有，那就是n a。總之是不用測或者是沒有測的意思 是指這一條測試用例根本不需要執行，是一條廢棄的或者是沒有用的測試用例 n a 在我們公司是 not available 意思...