一.測試用例方法總結
通常，在確定測試方法時，應遵循以下原則：根據程式的重要性和一旦發生故障將造成的損失來確定測試等級和測試重點認真選擇測試策略，以便能盡可能少的使用測試用例，發現盡可能多得程式錯誤。要在測試過度和測試不足中找平衡點
二.測試方法選擇
通常在確定測試方法時，有以下幾條參考原則
1.拿到乙個測試任務時，先關注它的主要功能和業務流程，業務邏輯是否正確實現，考慮使用場景法
2.需要輸入資料的地方，考慮採用等價類劃分法，包括輸入條件和輸出條件的等價劃分，將無限測試變成有限測試
3.在任何情況下都必須採用邊界值分析法。這種方法設計出的測試用例發現程式錯誤的能力最強
4.如果程式的功能說明中含有輸入條件的組合情況，則一開始就應該考慮選用因果圖和判定表法
5.對於引數配置類的軟體，需要考慮引數之間的組合情況，考慮使用正交排列法選擇較少的組合方式（最少的測試用例來獲得最大的測試覆蓋率）
6.對照程式邏輯，檢查已設計出的測試用例的邏輯覆蓋程度。如果沒有達到要求的覆蓋標準，則應該再補充更多的測試用例
7.採用錯誤推測法再追加測試用例——依靠工程師的經驗和智慧型
三.測試用例的力度
測試用例可以寫的很簡單也可以很複雜
測試用例寫的過於複雜或詳細，會帶來兩個問題：乙個是效率問題，另乙個時維護成本問題。另外，測試用例設計的過於詳細，留給測試執行人員的思考空間就比較少，容易限制測試人員的思維。
大多數的測試團隊編寫的測試用例的力度介於兩者之間
**測試用例的本質 **
測試用例的設計本質應該是在設計的過程中理解需求，檢驗需求，並把對軟體系統的測試方法的思路記錄下來，以便指導將來的測試。
基於需求的測試用例設計
基於需求的用例場景來設計測試用例是最直接有效的方法，因為它直接覆蓋了需求，而需求是軟體的根本，驗證對需求的覆蓋是軟體測試的根本目的。
- 要把測試用例當成活的文件，因為需求是活的，善變的。因此在設計測試用例方面應該要把敏捷方法的「及時響應變更比遵循計畫更有價值」這一原則體現出來。
不要認為測試用例設計是乙個階段，測試用例的設計也需要迭代，在軟體開發的不同階段都要回來重新評審和完善測試用例。
**測試用例評審 **
同行評審
使用者評審
「顧客的協作比合同談判更有價值」。
軟體測試基礎知識 測試用例，測試用例的設計方法
測試方案和測試用例均屬於測試的設計文件，測試用例描述了輸入動作和乙個期望結果，目的是確定程式的某個功能是否能正常工作 參考依據 需求規格說明書，需求分析結果，測試方案 編寫人和時間編寫工具和輸出文件 編寫工具 excel，word，zentao，buggree，testlink 輸出文件 測試用例 ...
軟體測試基礎知識 測試用例
測試用例 test case 是為某個特殊目標而編制的一組測試輸入 執行條件以及預期結果，以便測試某個 程式 路徑或核實是否滿足某個特定需求。測試用例用到的技術 一 白盒技術 白盒測試 是結構測試，所以被測物件基本上是 源程式 以 程式 的內部邏輯為基礎設計測試用例。邏輯覆蓋 程式內部的 邏輯覆蓋 ...
軟體測試基礎 測試用例詳解
軟體測試是軟體質量管理中最實際的行動，也是耗時量最大的一項工作，所以在測試過程中需要有組織 有步驟 有計畫的開展，需要能夠被量化管理，而測試用例就是將測試行為具體量化的方法之一 一 什麼是測試用例?測試用例 就是設計一種情況，軟體在這種情況下能夠正常或異常執行並達到預期結果 而程式如果在這種情況下不...