提升測試案例專業性的八個步驟_軟體測試

　 測試案例的編寫可不簡單呢，寫一份專業的測試案例，是所有測試 工作者考慮的內容，其實用例的編寫是可以通過一些思路來進行，不少比較成熟的公司為了提升用例的專業性，就會有自己的用例庫，包括流程、關注點，以及自己定義的模板。 　　今天作為測試老鳥的我經過幾年的經驗沉澱總結出來的一套測試案例編寫思路，該思路累計共有八步，經驗過驗證幾乎所有功能性測試都可以依據該架構思路來進行，將最大限度提升 用例設計 的專業程度 　 　第一步、UI體驗測試 　　1.風格、樣式、顏色是否協調 　　2. 介面布局是否整齊、協調（保證全部顯示出來的，盡量不要使用捲軸 　　3. 介面操作、標題描述是否恰當（描述有歧義、注意是否有錯別字）。 　　4. 操作是否符合人們的常規習慣（有沒有把相似的功能的控制項放在一起，方便操作） 　　5. 提示介面是否符合規範（不應該顯示英文的cancel、ok，應該顯示中文的確定等） 　　6. 介面中各個控制項是否對齊 　　7. 日期控制項是否可編輯 　　8. 日期控制項的長度是否合理，以修改時可以把時間全部顯示出來為準 　　9. 查詢結果清單列寬是否合理、標籤描述是否合理 　　10. 查詢結果清單太寬沒有橫向滾動提示 　　11. 對於資訊比較長的文本，文字框有沒有提供自動豎直捲軸 　　12. 資料錄入控制項是否方便 　　13. 有沒有支援Tab鍵，鍵的順序要有條理，不亂跳 　　14. 有沒有提供相關的熱鍵 　　15. 控制項的提示描述是否正確 　　16. 模組調用是否統一，相同的模組是否調用同一個介面 　　17. 用捲軸移動頁面時，頁面的控制項是否顯示正常 　　18. 日期的正確格式應該是XXXX-XX-XX或XXXX-XX-XXXX:XX:XX 　　19. 頁面是否有多餘按鈕或標籤 　　20. 視窗標題或表徵圖是否與功能表列的統一 　　21. 視窗的最大化、最小化是否能正確切換 　　22. 對於正常的功能，使用者可以不必閱讀使用者手冊就能使用 　　23. 執行風險操作時，有確認、刪除等提示嗎 　　24. 操作順序是否合理 　　25. 正確性檢查：檢查頁面上的form, button, table, header, footer,提示資訊，還有其他文字拼字，句子的文法等是否正確。 　　26. 系統應該在使用者執行錯誤的操作之前提出警告，提示資訊. 　　27. 頁面解析度檢查，在各種解析度瀏覽系統檢查系統介面友好性。 　　28. 合理性檢查：做delete, update, add, cancel, back等操作後，查看資訊回到的頁面是否合理。 　　29. 檢查本地化是否通過：英文版不應該有中文資訊，英文翻譯準確，專業。 　　30.背景灰階凍結 　 　第二步、功能完整性測試 　　1.使用所有預設值進行測試 　　2.根據所有產品文檔、協助文檔中描述的內容要進行遍曆測試 　　3.輸入判斷 　　4.所有介面出現是和否的邏輯，要測試 　　5.異常處理 　　6.敏感詞 　　7.根據需求文檔的流程圖遍曆所有流程圖路徑 　　8.根據程式內容，遍曆if elif else switch的邏輯點要遍曆 　　9.介面各種控制項測試 　 　第三步、商務程序測試 　　商務程序，一般會涉及到多個模組的資料，所以在對商務程序測試時，首先要保證單個模組功能的正確性，其次就要對各個模組間傳遞的資料進行測試，這往往是容易出現問題的地方，測試時一定要設計不同的資料進行測試。 　　如某一功能模組具有最基本的增刪改查功能，則需要進行以下測試： 　　1.單項 功能測試 （增加、修改、查詢、刪除） 　　2.增加——>增加——>增加 （連續增加測試） 　　3.增加——>刪除 　　4.增加——>刪除——>增加 （新增加的內容與刪除內容一致） 　　5.增加——>修改——>刪除 　　6.修改——>修改——>修改 （連續修改測試） 　　7.修改——>增加（新增加的內容與修改前內容一致） 　　8.修改——>刪除 　　9.修改——>刪除——>增加 （新增加的內容與刪除內容一致） 　　10.刪除——>刪除——>刪除 （連續刪除測試） 　 　第四步、容錯機制測試 　　1.輸入系統不允許的資料作為輸入。 　　2.把某個相關模組或者子系統停掉，驗證對當前系統的影響。 　　3.設定檔刪除或者配置錯誤。 　　4.資料庫注入錯誤資料。 　 　第五步、常規性測試 　　1.系統不間斷運行（7*24），驗證是否記憶體泄露、系統其他資源是否存在泄露 　　2.如果很緊急上線，可以跑一晚上或者周末跑兩天。 　　一般壓力很大的情況下， 資料庫連接數問題、記憶體泄露問題會曝露的比較快但是死結可能不能體現，所以要看系統重要性，如12306穩定性則最好7*24小時 　　 第六步、 效能測試 　　1.連線速度測試 　　使用者串連到Web應用系統的速度根據上網方式的變化而變化，他們或許是 電話撥號，或是寬頻上網。當下載一個程式時，使用者可以等較長的時間，但如果僅僅訪問一個頁面就不會這樣。如果Web系統回應時間太長（例如超過5秒鐘），使用者就會因沒有耐心等待而離開。 　　另外，有些頁面有逾時的限制，如果響應速度太慢，使用者可能還沒來得及瀏覽內容，就需要重新登陸了。而且，連線速度太慢，還可能引起資料丟失，使使用者得不到真實的頁面。 　　2.負載測試 　　負載測試是為了測量Web系統在某一負載層級上的效能，以保證Web系統在需求範圍內能正常工作。負載層級可以是某個時刻同時訪問Web系統的使用者數量，也可以是線上資料處理的數量。例如：Web應用系統能允許多少個使用者同時線上。如果超過了這個數量，會出現什麼現象。Web應用系統能否處理大量使用者對同一個頁面的請求。 　　3.壓力測試 　　負載測試應該安排在Web系統發布以後，在實際的網路環境中進行測試。因為一個企業內部員工，特別是項目組人員總是有限的，而一個Web系統能同時處理的請求數量將遠遠超出這個限度，所以，只有放在Internet上，接受負載測試，其結果才是正確可信的。 　　進行 壓力測試 是指實際破壞一個Web應用系統，測試系統的反映。壓力測試是測試系統的限制和故障恢複能力，也就是測試Web應用系統會不會崩潰，在什麼情況下會崩潰。駭客常常提供錯誤的資料負載，直到Web應用系統崩潰，接著當系統重新啟動時獲得存取權。 　　壓力測試的地區包括表單、登陸和其他資訊傳輸頁面等 　 　第七步、互動體驗測試 　　1.系統介面的控制項是否可以通過tab鍵遍曆，並且順序合理 　　2.主要功能的入口和操作是否易於理解 　　3.介面是否布局合理，功能是否易於尋找和使用 　　4.操作步驟 　　5.操作習慣 　　6.有足夠的提示資訊，且資訊文字描述準確 　 　第八步、相容性測試 　　相容性測試不只是指介面在不同 作業系統或 瀏覽器下的相容，有些功能方面的測試，也要考慮到相容性， 　　包括作業系統相容和應用軟體相容，可能還包括硬體相容 　　比如涉及到ajax、jquery、javascript等 技術的，都要考慮到不同瀏覽器下的相容性問題。 　　除了上面所說的這些測試以外，還有演算法測試、配置測試、安全性測試等等，在工作中不斷總結和分析，形成自己的功能測試架構，當你把這份工作做起來以後，對於你自己對於測試團隊而言都是一份很有價值的事情，你的測試思路也會變得更全面。
End.
更多熱門文章： http://www.51testing.com