2)根據被測功能點的特性列丼出相應型別的測試用例對其進行覆蓋 ，如；涉及輸入的地方需要考慮等價、邊界、負面、異常或非法、場景回滾、關聯測試等測試型別對其進行覆蓋。
3)在測試實現的各個階段跟蹤測試實現與需求輸入的覆蓋情況 ，及時修正業務或需求理解錯誤。
1執行2註冊
-- 同表單編輯頁面
-- 使用者名稱密碼長度
-- 註冊後的提示頁面
-- 前台註冊頁面和後台的管理頁面資料是否一致
-- 註冊後，在後台管理中頁面提示
3登入-- 使用合法的使用者登入系統。
-- 系統是否允許多次非法的登陸，是否有次數限制。
-- 使用已經登陸的賬號登陸系統是否正確處理。
-- 使用禁用的賬號登陸系統是否正確處理。
-- 使用者名稱、口令（密碼）錯誤或漏填時能否登陸。
-- 刪除或修改後的使用者，原使用者登陸。
-- 不輸入使用者口令和使用者、重複點（確定或取消按鈕）是否允許登陸。
-- 登陸後，頁面中登陸資訊。
-- 頁面中有登出按鈕。
-- 登陸超時的處理。
4登出-- 登出原模組，新的模組系統能否正確處理。
-- 終止登出能否返回原模組，原使用者。
-- 登出原使用者，新使用者系統能否正確處理。
-- 使用錯誤的賬號、口令、無許可權的被禁用的賬號進行登出
5應用的前後臺切換
7) 出現必須處理的提示框後，切換到後台，再切換回來，檢查提示框是否還存在，有時候會出現應用自動跳過提示框的缺陷。
8) 對於有資料交換的頁面，每個頁面都必需要進行前後臺切換、鎖屏的測試，這種頁面最容易出現崩潰。
6資料更新
根據應用的業務規則，以及資料更新量的情況，來確定最優的資料更新方案。
1) 需要確定哪些地方需要提供手動重新整理，哪些地方需要自動重新整理，哪些地方需要手動 + 自動重新整理。
2) 確定哪些地方從後台切換回前台時需要進行資料更新。
3) 根據業務、速度及流量的合理分配，確定哪些內容需要實時更新，哪些需要定時更新。
4) 確定資料展示部分的處理邏輯，是每次從服務端請求，還是有快取到本地，這樣才能有針對性的進行相應測試。
5) 檢查有資料交換的地方，均有相應的異常處理。
1) 當客戶端有新版本時，有更新提示。
4) 當客戶端有新版本時，在本地不刪除客戶端的情況下，直接更新檢查是否能正常更新。
5) 當客戶端有新版本時，在本地不刪除客戶端的情況下，檢查更新後的客戶端功能是否是新版本。
6) 當客戶端有新版本時，在本地不刪除客戶端的情況下，檢查資源同名檔案如是否能正常更新成最新版本。如果以上無法更新成功的，也都屬於缺陷。
testbird
Web應用功能測試測試點
做了幾年的 功能測試，也經手了好幾個web應用的專案，在做專案當中積累了一些經驗。在這裡我對通用一些功能模組的測試點做個記錄，一來梳理一下 測試用例設計的思路，以便加快相似專案的測試用例的設計，二來有利於設計出更加全面完善的測試用例。以後隨著自己的 測試技術的進步，也可以在這裡對測試用例進行補充，查...
Web應用功能測試測試點
做了幾年的功能測試，也經手了好幾個web應用的專案，在做專案當中積累了一些經驗。在這裡我對通用一些功能模組的測試點做個記錄，一來梳理一下測試用例設計的思路，以便加快相似專案的測試用例的設計，二來有利於設計出更加全面完善的測試用例。以後隨著自己的測試技術的進步，也可以在這裡對測試用例進行補充，查漏補缺...
Web應用功能測試測試點
做了幾年的功能測試，也經手了好幾個web應用的專案，在做專案當中積累了一些經驗。在這裡我對通用一些功能模組的測試點做個記錄，一來梳理一下測試用例設計的思路，以便加快相似專案的測試用例的設計，二來有利於設計出更加全面完善的測試用例。以後隨著自己的測試技術的進步，也可以在這裡對測試用例進行補充，查漏補缺...