把測試系統的操作步驟按照一定的格式用文字描述出來
1）理清思路，避免遺漏
複雜的專案需要我們把功能細分，根據每乙個功能來編寫測試用例，
整理我們的測試系統思路，避免遺漏要測試的功能點
2）跟蹤測試進度
通過測試用例執行後的統計結果，方便我們跟蹤專案進度
3）回歸測試
在不同的測試環境，不同的測試人員在不同的階段執行相同的測試用例，用回歸測試來規範我們的測試行為
4）歷史參考
在做專案的各個版本中，有很多功能是相近的，對於這類功能設計的測試用例，
以後遇到類似的功能可作為參考，也是分析缺陷的參考依據
1）分析需求文件，得到測試點
需求分析，了解需求的實現背景，需求的合理性，需求的範圍，
挖掘需求文件中隱藏的需求，通過需求交底的過程，確定開發的初步實現思路和方法，
列出需求的框架，包含測試範圍及各個功能點，測試的場景等，對於需求中的遺漏和
疑問要找產品確認
2）分析測試用例優先順序
讓測試更有側重點，一般分為高中低三個優先順序
3）細化測試點，變成可執行測試用例
根據測試需求得到的需求框架（這個不應該有遺漏），梳理細化測試點，
根據測試點，細化具體的測試用例，注意各個點的組合情況和反向測試情況，
參考公共測試用例，但不照搬，要思考本次需求自己特有的測試點，把握好測試點細化的度
4）及時更新測試用例
需求會有變動要維護，測試用例也一樣需要維護，
在測試評審時，評審人員對你的測試用例是否有測試點，場景遺漏，
測試用例描述模糊，測試結果輸出模糊等提出的問題，我們要及時更改
1）熟悉業務，了解系統
熟悉業務才能更有效的使用系統，對系統越熟悉，越容易發現系統和業務的問題
2）站在使用者的角度
客戶需要什麼，不需要什麼，即客戶的使用場景，有利於我們更好的挖掘和思考隱含的需求，
至於這個需求該不該做，那是需求人員的職責，這個需求做起來複雜不複雜，那是開發人員的事，
作為測試人員，我們首先要考慮的就是我們所設計的測試用例是不是包含使用者常用到的場景以及基本不會
用到的場景有哪些
3）多思考，不要被慣性思維和經驗束縛
4）多總結
把常用的用例設計誤區和一些好的測試用例設計總結並抽象出來以便以後的復用
測試用例總結
軟體測試不僅要驗證正確的行為，還要驗證軟體在非法操作的情況下具體響應 反應 人機互動 正確引導使用者，去做正確的事情 反應 友好提示資訊，更注重 體驗 等價類相同的一類為乙個等價類 對比目標 男人 女人 胖的 瘦的 高 低 有效等價類 無效等價類 有效 有效的輸入 無效 無效的輸入 輸入框邊界值 0...
Web測試用例總結
關於 web測試 1頁面部分 1 頁面清單是否完整 是否已經將所需要的頁面全部都列出來了 2 頁面是否顯示 在不同解析度下頁面是否存在，在不同瀏覽器版本中頁面是是否顯示 3 頁面在視窗中的顯示是否正確 美觀 在調整瀏覽器視窗大小時，螢幕重新整理是否正確 4 頁面特殊效果 如特殊字型效果 動畫效果 是...
測試用例方法總結
雖然對於設計用例的各種方法的理論概念都已經足夠了解，但是當專案開始需要編寫測試用例時對於如何合理熟練運用各種方法還是不夠明確，經驗不夠，對此這幾天查閱了一些資料，對此做乙個總結。一.myers提出了使用各種測試方法的綜合策略 2 必要時用等價類劃分方法補充一些測試用例。3 用錯誤推測法再追加一些測試...