前言:根據詳細設計文檔編寫測試用例的目的不在于驗證軟件達到的功能,而在于驗證軟件應該達到的功能.這樣可以去除軟件開發過程中的隨意性.
1. 目的：統一測試用例編寫的規范，以保證使用最有效的測試用例，保證測試質量。
2. 范圍：適用于公司對產品的業務流程、功能測試測試用例的編寫。
3. 功能測試用例編寫原則。
3.1單元測試功能用例的編寫目的
單元測試用例的目的在于驗證單個模塊是否達到了詳細設計說明書中規定的功能,由于是單個模塊所以無法檢驗關聯性,可能會牽扯到數據庫的操作,例如:刪除時,需要查看數據庫是否完全刪除了數據.
3.2集成測試功能用例的編寫目的
集成測試功能用例的目的在于驗證軟件連接時,模塊的連接是否正確(及數據的傳遞是否正確).我們的軟件中體現出來的是,是否正確調用界面,界面之間顯示的數據是否正確,特別是財務方面的.
集成測試用例的編寫過程中,經常將功能用例與業務流程用例混合編寫,因為在集成測試時很難將兩者分開.
4. 業務流程測試用例編寫原則。
4.1集成測試業務流程用例的編寫目的
集成測試業務流程用例的目的與集成測試功能用例的目的基本一樣,在于驗證數據的正確性,及界面之間的數據傳遞的準確、無誤.
4.2系統測試業務流程用例的編寫目的
系統測試業務流程用例的目的在于驗證軟件最終數據的準確性.我們的軟件體現為,手工數據與報表數據的一直性.用例與用例之間有著一定的關系,目的性十分明確.
5. 測試用例設計的原則(系統測試業務流程用例可以參考)
5.1全面性
指編寫的測試用例應該覆蓋所有的詳細設計文檔描述的功能.
5.1.1 數據庫程序基本的增、刪、改功能.
增、改測試用例重點在于數據合法性、正確性的檢驗和提示信息的正確性的檢驗.輸入的數據可能有無限種組合,此時可以采用等價類劃分和邊界值法.
刪除的測試用例比較簡單,只有操作沒有數據的輸入,但是應該在備注中注明,刪除的限制條件,以及數據庫中應該刪除的表的情況.有條件限制時,測試用例應該包含各種刪除條件,必要時在添加或修改的測試用例后面或中見,緊跟刪除的測試用例.
5.1.2 對于無輸入的操作,應該詳細描述其具體的操作步驟和結果.例如:選擇商品,可以通過多種途徑進行,此時應具體描述程序從何處進入,通過何種操作,達到商品界面.對于報表的測試用例,最好緊跟在輸入數據的后面,并且應該給出報表輸出的數據的界面圖(含數據).
對于不便書寫測試用例的情況,應該在備注中說明,并寫出可能的操作步驟.例如:對于文件夾的拖動,說明左右拖還是上下拖,結果如何就可以了.
5.1.3 單元測試用例的書寫是使用一條數據,多種可能的情況考慮.但是對于其余各階段的測試用例,必須考慮多條數據時的情況.此時主用是針對新增多條數據后,進行刪、改、拖等情況的考慮.
5.1.4 應考慮存在跨年、跨月的數據
5.2正確性
包括數據的正確性和操作的正確性.
首先保證測試用例的數據正確,其次預期的輸出結果應該與測試數據發生的業務吻合.
操作的預期結果應該與程序發生的結果吻合
5.3符合正常業務慣例
測試數據應符合用戶實際工作業務流程.實際就是測試用例的先后順序,先新增,后修改或刪除.不能將刪除放在第一位.
5.4 仿真性
人名、地名、電話號碼等應具有模擬功能，符合一般的命名慣例；不允許出現與知名人士、小說中人物名等雷同情況。
5.5 可操作性
測試用例中應寫清測試的操作步驟，不同的操作步驟相對應的操作結果不同.達到的目的是,任何人,均可以根據測試用例,單獨進行測試.
文章來源于領測軟件測試網 http://www.kjueaiud.com/
