一、
用例
測試
編寫準備
從員處申請軟體配置：《需求規格說明書》和《設計說明書》；根據需求規格說明書和設計說明書，詳細理解使用者的真正需求，並且對軟體所實現的功能已經準確理解，然後著手制訂測試用例。
配置管理
二、測試用例制定的原則
測試用例要包括欲測試的功能、應輸入的資料和預期的輸出結果。測試資料應該選用少量、高效的測試資料進行盡可能完備的測試；基本目標是：設計一組發現某個錯誤或某類錯誤的測試資料，測試用例應覆蓋方面：
1、正確性測試：輸入使用者實際資料以驗證系統是滿足需求規格說明書的要求；測試用例中的測試點應首先保證要至少覆蓋需求規格說明書中的各項功能，並且正常。
2、容錯性（健壯性）測試：程式能夠接收正確資料輸入並且產生正確（預期）的輸出，輸入非法資料（非法型別、不符合要求的資料、溢位資料等），程式應能給出提示並進行相應處理。把自己想象成一名對產品操作一點也不懂的客戶，在進行任意操作。
3、完整（安全）性測試：對未經授權的人使用軟體系統或資料的企圖，系統能夠控制的程度，程式的資料處理能夠保持外部資訊（或檔案）的完整。
資料庫
4、介面間測試：測試各個模組相互間的協調和通訊情況，資料輸入輸出的一致性和正確性。
5、資料庫測試：依據資料庫設計規範對軟體系統的資料庫結構、資料表及其之間的資料呼叫關係進行測試。
6、邊界值分析法：確定邊界情況（剛好等於、稍小於和稍大於和剛剛大於等價類邊界值），針對我們的系統在測試過程中主要輸入一些合法資料/非法資料，主要在邊界值附近選取。
7、：輸入10條記錄執行各個功能，輸入30條記錄執行，輸入50條記錄執行……進行測試。
壓力測試
8、等價劃分：將所有可能的輸入資料（有效的和無效的）劃分成若干個等價類。
9、錯誤推測：主要是根據測試經驗和直覺，參照以往的軟體系統出現錯誤之處。
10、效率：完成預定的功能，系統的執行時間（主要是針對資料庫而言）。
11、可理解（操作）性：理解和使用該系統的難易程度（介面友好性）。
12、可移植性：在不同作業系統
及硬體配置情況下的執行性。
14、比較測試：將已經發版的類似產品或原有的老產品與測試的產品同時執行比較，或與已往的測試結果比較。
說明：針對不同的測試型別和測試階段，測試用例編寫的側重點有所不同。
1、 其中第1、2、6、8、9、13項為模組（元件、控制項）測試、組合（整合）測試、系統測試
都涉及並重點測試的方面。
2、 單元（模組）測試（元件、控制項）測試：重點測試第5項。
3、 組合（整合）測試：重點進行介面間資料輸入及邏輯的測試，即第4項。
4、 系統測試：重點測試第3、7、10、11、12、14項。
5、 其中壓力測試和可移植性測試如果是公司的系列產品，可以選用其中有代表性的產品進行一次代表性測試即可。
6、 gmps基礎測試用例設計完成後，其他
的測試專案只編寫設計與之不同部分的測試用例。
7、 對於每個測試專案測試的測試用例不是一成不變的，隨著測試經驗的積累或在測試其他專案發現有測試不充分的測試點時，可以不斷的補充完善測試專案的測試用例。
三、測試用例的填寫
乙個軟體系統或專案共用一套完整的測試用例，整個系統測試過程測試完畢，將實際測試結果填寫到測試用例中，操作步驟應盡可能的詳細，測試結論是指最終的測試結果（結論為：通過或不通過）。
編寫規範的測試用例
測試用例是測試的核心，如何設計出能發現問題，有效能覆蓋需求，沒有冗餘的用例是每個測試工程師必須跨過的一道門檻。編寫測試用例的目的是為了測試工作更加有序 減少功能點漏測。優秀的測試用例標準應該如下 1 需求點要100 覆蓋。2 被測功能點或控制項100 覆蓋。3 執行起來效率高，沒有冗餘步驟，每步都是...
介面測試用例編寫規範
1.通過性驗證 先肯定要保證這個介面功能是好使的，也就是正常的通過性測試，按照介面文件上的引數，正常傳入，是否可以返回正確的結果。2.引數組合 現在有乙個操作商品的介面，有個字段type，傳1的時候代表修改商品，商品id 商品名稱 有乙個是必傳的，type傳2的時候是刪除商品，商品id是必傳的，這樣...
介面測試用例編寫規範
1.通過性驗證 先肯定要保證這個介面功能是好使的，也就是正常的通過性測試，按照介面文件上的引數，正常傳入，是否可以返回正確的結果。2.引數組合 現在有乙個操作商品的介面，有個字段type，傳1的時候代表修改商品，商品id 商品名稱 有乙個是必傳的，type傳2的時候是刪除商品，商品id是必傳的，這樣...