代替測試用例的檢查表

　　2004年底在大連出差的時候，幫一個項目做測試，順便寫下這個檢查表，這個檢查表對測試的初學者積累經驗比較有用，實際對于有經驗的測試人員尤其對于測試業務管理信息系統，基本上大量的測試不需要再編寫測試用例，當然對業務流程、復雜邏輯還是要設計詳細的測試用例的。如果你測試的系統是有大量人機交互的業務管理信息系統，而且你又比較懶惰，那就可以使用這個檢查表檢查了。

　　因此我總結了這類系統中常用的測試的檢查項，供當時項目組的測試人員使用，現在再次整理出來發于博客。

　　1 針對測試組長或測試經理

　　1.1 測試管理工作檢查表：

　　1. 檢查每輪測試開始時測試環境是否準備好(包括軟件硬件、測試基本數據等);

　　2. 確保測試環境(數據和程序)與開發分離，除了測試組之外其他人不能更新測試環境的數據和程序;

　　3. 每輪測試根據上一輪的情況和總體測試計劃做分工調整;

　　4. 檢查case庫的填報情況，抽查執行過的case;

　　5. 檢查BUG提交情況，抽查提交的BUG是否規范;

　　6. 每天晚上統計BUG情況，填寫每天的BUG報告;

　　7. 根據每天的測試情況，決定是否開發組要發布新的BUILD;

　　8. 每輪測試結束后填寫測試總結。

　　2 下面是針對測試執行人員的：

　　2.1 輸入、編輯功能的驗證檢查點：

　　1. 必輸項是否有紅星標記，如果不輸入提示是否跟相應的Label對應，提示的順序是否跟Form輸入域的排列次序一致;

　　2. 輸入的特殊字符是否能正確處理：`~!@#$%^&*()_+-={}[]|\:;”’<>,./?;

　　3. Form下拉菜單的值是否正確，下拉菜單的值通過維護后是否正確顯示并可用;下拉菜單比如是機構編碼，要到機構編碼的維護界面查詢一下是否Form列出的與其一致;

　　4. 涉及到下拉菜單的編輯修改Form，要檢查在編輯和修改From中，下拉菜單是否能正確顯示當前值;

　　5. Form提交后，要逐項檢查輸入的內容跟通過查詢的結果一致;

　　6. 有多層下拉菜單選擇的情況要校驗兩層菜單的選擇是否正確，比如：a) 部門

　　人員

　　7. 備注字段的超常檢查;

　　8. 提交保存后能否轉到合適的頁面;

　　9. 編輯Form顯示的數據是否跟該記錄的實際數據一致;

　　10. 編輯權限的檢查，比如：user1的數據user2不能編輯等;

　　11. 可編輯數據項的檢查，比如：數據在正式提交之前所有的屬性都可以編輯，在提交之后，編號、狀態等不能編輯，要根據業務來檢查是否符合需求;

　　12. 對于保存有事務Trasaction提交，比如一次提交對多表插入操作，要檢查事務Trasaction的處理，保證數據的完整和一致;

　　13. 其他的合法性校驗。

　　2.2 查詢功能檢查點：

　　1. 查詢輸入Form是否正常工作，不輸入數據是否查詢到全部記錄;

　　2. 當查詢的數據非常多的時候，性能有無問題;

　　3. 查詢的下拉菜單列出的數據是否正確;

　　4. 查詢結果是否正確;對于復雜的查詢要通過SQL來檢查結果;

　　5. 如輸入%*?等統配符是否會導致查詢錯誤;

　　6. 查詢結果列表分頁是否正確，在點擊下一頁上一頁時，查詢條件是否能帶過去，不能點擊翻頁時又重新查詢;

　　7. 對于數據量比較大的表查詢時，不容許無條件查詢，避免性能問題的出現;

　　8. 對于查詢輸入項的值是固定的要用下拉菜單，比如狀態、類型等;

　　9. 分頁的統計數字是否正確，共X頁，第N頁，共X條記錄等;

　　10. 對于查詢有統計的欄目，比如：總計、合計等要計算數據是否正確;

　　11. 查詢結果有超鏈接的情況要檢查超鏈接是否正確;

　　12. 查詢權限的檢查，比如：user1不能查詢到user2的數據等;

　　2.3 刪除功能檢查點：

　　1. 必須有“確認刪除”的提示;

　　2. 根據需求檢查是軟刪除還是硬刪除，來檢查數據庫中是否還存在該條記錄;

　　3. 是否有相關的數據刪除，如果有要確認該相關的數據也已經刪除，并且在同一事務中完成;

　　4. 是否有刪除約束，如果有刪除約束，要檢查該記錄是否被約束，如果被約束該記錄不能被刪除;

　　5. 如果是軟刪除，用查詢、統計界面檢查該條記錄能否被查詢出來，數據是否被統計進去;

原文轉自：http://www.uml.org.cn/Test/200809174.asp