關於介面測試用例的等級劃分
1) 主體業務功能介面正常典型值用例的優先順序為1（用於冒煙測試的用例）
2) 各模組主功能的正常典型值用例的優先順序為2
3) 除了的正常典型值用例之外的正用例及所有異常用例的優先順序為3
4) 可用性測試以及入參預設值以及開發做了限制處理的引數型別、開發自測容易發現的錯誤等測試的優先順序為5，最低優先順序
還有些問題，是大家都需要考慮的問題。比如你應該思考下你設計的這些部分用例是否是真的有實際意義？有沒有考慮到實際使用者使用場景、需要？是否有可能會出現這種場景？程式設計師對於這些字段有沒有做了限制，他們是不是保證不會犯這樣那樣的錯誤，如果他們已經做了控制保證不會出現你設計的哪幾種異常情況，你還何必多此一舉？
介面測試用例的設計不是業務層，不能純根據數學的排列組合，還要根據實際情況做一下減法
2、測試用例的篩選
對用例做一次篩選，介面測試屬於更底層一點的測試，當然所有手工測試方法都用的上，但介面引數資料需對每個引數根據測試介面的實際的功能進行分析，需要符合業務邏輯的情況下進行邏輯組合排列。
根據測試方法做一下如下篩選：
1) 剔除不重要的介面
2) 異常係用例根據是介面本身相容異常情況還是有前端控制進行去留
3) 根據介面文件，實際業務情況，場景，介面要實現的功能進行選擇
4) 開發協助再篩選一遍
3、測試原則
1) 基礎配置，如網域名稱，環境配置等，單獨檔案配置，方便不同環境測試，指令碼維護
2) 明確介面實現什麼樣的功能，實際需要什麼樣的功能。是否一致
3) 介面測試資料太多，用資料驅動模式更有層次，且易維護
4) 要眾多用例中選出冒煙測試用例及可用於效能測試的用例
5) 先單介面測試，在多介面業務測試
6) 測試完成後，需要清理髒資料
總結以上，在設計測試用例時候我們可以根據專案業務功能情況進行主次分析後，劃分優先順序，先正向思路，再反向，進行歸類劃分，最後有時間再考慮是否要編寫那些優先順序比較低的用例，必要的時候可以畫下思維導圖，思路清晰了再進行編寫。
如此一來，在執行的時候也按優先順序情況進行執行，整個層次就分明了，用例的管理及維護也變得輕鬆起來。
如何寫測試用例
1 了解軟體的原始需求 測試目的 在編寫乙個軟體或者模組的測試用例時候，一定要明白這個功能的原始需求，也就是軟體的使用者 客戶 的需求。理解原始需求後，編寫的測試用例才更有目的性。2 熟悉軟體的功能需求 測試點 這個功能需求是指軟體的細化需求點，這個一般在需求文件裡面都會體現。這裡要做的是把需求穩定...
如何寫軟體效能測試用例
由於效能測試與功能測試有很大的區別，所以討論出的結果可能與預先的設想有一定的區別。效能測試的目的 為了驗證系統是否達到使用者提出的效能指標，同時發現系統中存在的效能瓶頸，起到優化系統的目的。使用者對各項指標提出的明確需求 如果使用者沒有提出效能指標則根據使用者需求 測試設計人員的經驗來設計各項測試指...
如何寫好測試用例
這裡說的不是設計測試用例的數量，而是測試用例的書寫。我在實習期間對乙個內部使用的工具進行測試，負責增刪改查部分。作為實習生，很想有乙個準確的答案告訴我該怎麼做不該怎麼 應試教育的惡果 但實際工作中確實是乙個人有乙個人的風格，聽多了反而不知道該怎麼做。所以我第一批的tc寫的特別詳細，如 前置條件 en...