4、資料更新
4.1、需要確定哪些地方需要提供手動重新整理、哪些地方需要自動重新整理、哪些地方需要手動+自動重新整理
4.2、確定哪些地方從後台切換回前台時需要進行資料更新
4.3、根據業務、速度及流量的合理分配，確定哪些內容需要實時更新，哪些需要定時更新
4.4、確定資料展示部分的處理邏輯，是每次從服務端請求，還是有快取到本地，這樣才能有針對性的進行相應測試
4.5、檢查有資料交換的地方，均有相應的異常處理
9、push測試
9.1、檢查push訊息是否按照指定的業務規則傳送
9.2、檢查不接收推送訊息時，使用者會不會收到push
9.3、如果使用者設定了免打擾時間段，檢查在免打擾時間段，使用者接收不到push；在非免打擾時間段，使用者可以正常收到push
9.4、當push訊息是針對登入使用者的時候，需要檢查收到push與使用者身份是否相符，沒有錯誤地講其他人的訊息推送過來。一般情況下，只對手機上最後乙個登入使用者進行訊息推送
9.5、push測試時，需要採用真機進行測試
移動應用測試點
1.冒煙測試 monkey monkettalk工具 保證軟體的健壯性 2.安裝，解除安裝 手機端軟體安裝解除安裝 第三方應用的安裝解除安裝 3.業務功能 1 客戶端業務 2 功能點正常 3 與pc端互動是否正常 4 各種異常性測試如 插拔斷網 重複提交等 4.效能測試 1 伺服器介面多執行緒指令碼...
介面測試測試點
大家都知道，測試的本質的發現問題，然後跟蹤解決問題 但是解決問題有個通用成本理論 問題越早發現解決的成本越低，成本從大到小排列為 產品需求規格說明書 開發需求分析報告 開發詳細設計說明書 測試需求分析說明書 測試用例 code review 轉測試驗收 測試人員提交bug 產品 運營驗收 客戶投訴 ...
APP功能測試點
2 根據被測功能點的特性列丼出相應型別的測試用例對其進行覆蓋，如 涉及輸入的地方需要考慮等價 邊界 負面 異常或非法 場景回滾 關聯測試等測試型別對其進行覆蓋。3 在測試實現的各個階段跟蹤測試實現與需求輸入的覆蓋情況，及時修正業務或需求理解錯誤。5 註冊 同表單編輯頁面 使用者名稱密碼長度 註冊後的...