1樓：匿名使用者
1.測試用例設計有些最基礎的方法，如等價類劃分，邊界值，可以減少冗餘用例。有時候會遇到輸入組合引數的情況，如第一步輸入的引數有6種型別，第二步輸入的引數有6種型別，在不考慮自動化的情況下，如何選擇測試用例個數？
6個兩兩組合，6*6=36個？測試時間充裕，你可以這麼搞，但是總得講成本，時間成本，人力成本等，決定了你不能這麼搞。怎麼辦？
業界對於這類情況早有研究，2-3個兩兩組合帶來的價效比最高，以2個兩兩組合為例，需要12個用例，比36少了24個用例，以3個兩兩組合為例，需要18個用例，少了一半。
2.測試設計層次要清晰，ui，正向，逆向，效能，相容性等等，分開寫。
3.通過**走查，增加遺漏的用例，刪除多餘的，可以很大程度上提高測試用例的覆蓋率和精度。
4.同行評審，基於團隊的力量，發現一些個人沒考慮到的場景，也許有些測試場景其它成員能輕易想到。
5.通常，乙個優秀的測試lead或者經理，是需要比所有測試人員更了解被測系統，至少站在整個系統的層面，理解的更透徹，所以他的評審也很重要，比如可能會告訴你和其它模組有關聯，需要增加用例進行覆蓋。
6.來自開發人員，需求人員的評審，在正規的測試流程中不可避免，開發也許會發現有些測試用例根本沒必要，有些新增**分支沒有相關的測試用例覆蓋，通過這一輪評審，也能提高用例的覆蓋率和較少不必要的用例。
2樓：匿名使用者
業務流程和測試資料的有效性決定了測試用例的有效性。
如何確保測試用例是執行過的
3樓：匿名使用者
是測試過程中很重要的一部分內容，用例的編寫也是一項很考驗測試人員對業務知識的理解和分析能力的工作，所以編寫用例的水平也能一定程度上反映出測試人員的測試水平，而很多測試人員特別是剛進入測試行業的測試人員，往往都忽視了測試執行的重要性，不屑於做測試的執行工作，覺得測試執行沒什麼技術含量。
我在之前的兩家公司，因為人員結構或者測試組織方面的原因，沒執行過別人寫的用例，都是自己寫好了自己執行。來到現在公司後，由於專案已經進入了尾聲，用例也已經比較完整了，所以就安排我先做用例的執行工作。一方面在不熟悉業務的情況下，執行用例相對編寫用例會簡單點，另一方面也可以通過執行用例來熟悉業務。
我執行的用例是我們部門主管寫的用例，所以也算是用例交叉執行的乙個過程。在用例的執行過程中，一方面是對我業務理解能力的檢驗，另一方面也是對用例編寫者所編寫的用例的檢驗。用例的執行環境、前提條件、操作步驟、和預期結果都會影響到用例能否順利的執行，這些如果都寫的清晰了，用例執行的效率也就更高，對業務的理解也就更容易。
對於業務邏輯簡單的用例，對著用例的輸入步驟和預期結果就可以較順利的執行，對於業務邏輯比較複雜的，加上一些前提條件可能也沒有在用例中說的很完整，就需要通過用例編寫人員給予業務邏輯的講解才能理解，而講解業務的過程，又是對業務更進一步理解的過程。
我現在參與的專案是oa系統，執行用例過程中，發現在執行多部門協調性要求比較強的業務的用例時，往往需要頻繁的登入和退出系統，在使用者多的時候，可能容易出錯，也不太好保持測試的連貫性。通過一段時間的用例執行工作，也總結了點經驗，和大家分享。
4樓：摩羯腿毛小金剛
抽測制度
責任明確劃分，並有懲罰制度
有些管理工具有這種功能，記錄你測試每乙個步驟，時間，還有的會截圖。建議去研究下。以上。
軟體測試不寫測試用例回測的時候怎樣保證測試質量
5樓：匿名使用者
經驗，靠經驗，真正的高手寫的測試用例數量很少，大部分都是靠經驗來進行測試，因為他們不想把太多的時間用在編寫和執行測試用例上面。新手的話最好還是從用例編寫開始。
6樓：匿名使用者
依據標準的測試流程，測試用例是必須的，不僅是你提到的回歸測試，標準化的測試用例也是自動化過程的乙個基礎。
國內很多專案因為工期緊張，成本有限，另外對測試不重視，所以無法或者不願編寫測試用例。對於短週期的專案，僅應用簡單的手工黑盒系統功能測試的確不需要非常詳細的測試用例。對於長週期，高複雜度的專案，培訓成本玩兒死你；白盒測試沒見不寫用例的；自動化測試必須有用例，有的指令碼就是用例；其他效能測試，相容性等等，可以沒有用例，但有各自的要求。
如果你只知道經驗，你就是個測試員而已。
7樓：匿名使用者
可以只列乙個checklist
軟體測試用例的幾種設計方法，常見的測試用例設計方法都有哪些
終極至尊 一 等價類劃分 等價類劃分主要適用於單個輸入條件，輸入為數值型的情況，如果輸入規定了輸入區間，可劃分出乙個有效等價類，兩個無效等價類 如果輸入只規定了輸入範圍，可劃分出乙個有效等價類，乙個無效等價類。二 邊界值 邊界值方法也是適用於單個輸入條件的情況，輸入型別可以數值 字元等，要測試的邊界...
軟體測試用例設計的關鍵是什麼，做好測試用例的關鍵是什麼
面試時回答 覆蓋率與冗餘 1.使用者需求，需要了解需求。不瞭解需求，設計測試用例無從談起。2.把需求分析進化成需求點列表。這樣才能保證覆蓋率。也是後期核查測試覆蓋率以及更新新增測試用例的依據。3.瞭解功能的層次，哪些是主要功能，需要詳細設計，全面覆蓋，哪些是不常用的功能，可以粗線條的設計。哪些功能是...
求web相容性測試用例
育知同創教育 參考下面方法 一 分別在不同電腦上安裝不同版本的ie 優點 準確性高，三臺電腦分別安裝ie6 7 8，顯然測試得出的結果是最準確的。缺點 浪費伺服器資源，測試人員操作麻煩，需要不斷切換測試機器。二 在一臺電腦上安裝ietest 優點 能90 的模擬出不同瀏覽器的渲染效果，只需安裝在一臺...