App測試流程及測試點

1 APP測試基本流程

1.1預估測試周期

測試周期可按項目的開發周期來確定測試時間，一般測試時間為兩周（即10個工作日,一人份工作量），根據項目情況以及版本質量可適當縮短或延長測試時間。正式測試前先向主管確認項目整體排期。

與其他項目強耦合適量增加3-5個工作日，弱耦合增加1-2工作日

1.2測試資源

測試任務開始之前，准備測試資源

1.產品文檔
2.原型圖
3.效果圖 即設計交互稿
4.行為統計分析定義文檔
5.測試設備(測試機，平板，系統iOS、Android,不同分辨率)
6.測試人員
7.其他

1.3分析測試內容

• 這里就說的通俗一點
• 比如A要去吃飯，那么他怎么吃飯，用什么吃飯，吃什么飯，吃多少合適。
  • 怎么吃：項目業務流
  • 用什么吃：項目前期准備測試事宜
  • 吃什么飯：明確測試目的，項目背景
  • 吃多少合適：合格點，吃完飯了是不是得確認他是不是吃飽了？

1.4設計測試計划、測試用例

古人雲：凡事預則立，不預則廢。也就是強調預先計划的重要性和必要性

• 測試計划

  • 測試范圍 明確測什么？比如：產品的具體業務需求有哪些？產品是web端的還是移動端的，還是兩者都有？
  • 測試策略 明確怎么測。對不同業務需求，具體要有哪些測試類型、測試場景、測試方法。
  • 資源安排 包括測試人員的安排，測試環境是怎樣的，測試工具的選擇等。
  • 進度安排 在明確測試范圍、方法和人員之后，我們要考慮什么時候開始測試，預計要測試多久？以便和開發計划、上線計划銜接。
  • 發布標准 發布標准是測試完成和產品上線需要滿足的條件，以便項目內所有角色都有一致認可的目標。怎樣才算是測完了？達到怎樣的標准才可以上線？
  • 風險預防 最后，我們需要對整個測試過程中可能存在的風險，以及當這些風險發生時的應對措施提前進行一些考慮和准備，並在測試計划中體現出來。

• 測試用例就不多說了，測試工程師的基本功

1.5用例評審

一千個眼里就有一千個哈姆雷特，所以用例評審很重要，這是一個查漏補缺的過程，不光用例層面的補充，也在某種程度上對其他同事也是一種回顧&梳理其他同事的堵塞點

1.3測試報告

1. 測試人員對每天測試項目發送測試報告(若無要求，則不需要發送日報)
2. 日報所含內容：
   • 對當前測試版本質量進行分級
   • 嚴重阻塞進度的問題提出，提示開發同學優先修改
   • 對版本整體測試進度進行評估
3. 產品上線前，測試發送測試報告

2 APP測試點

2.1 安裝

1. 軟件在不同操作系統（Palm OS、Symbian、Linux、Android、iOS、Black Berry OS 6.0、Windows Phone 7）下安裝是否正常
2. 軟件安裝后的是否能夠正常運行，安裝后的文件夾及文件是否寫到了指定的目錄里
3. 軟件安裝各個選項的組合是否符合概要設計說明
4. 軟件安裝向導的UI測試
5. 軟件安裝過程是否可以取消，點擊取消后，寫入的文件是否如概要設計說明處理
6. 軟件安裝過程中意外情況的處理是否符合需求（如死機，重啟，斷電）
7. 安裝空間不足時是否有相應提示
8. 安裝后沒有生成多余的目錄結構和文件
9. 對於需要通過網絡驗證之類的安裝，在斷網情況下嘗試一下
10. 還需要對安裝手冊進行測試，依照安裝手冊是否能順利安裝

2.2 卸載

1. 直接刪除安裝文件夾卸載程序是否有提示信息
2. 測試系統直接卸載程序是否有提示信息。
3. 測試卸載后文件是否全部刪除所有的安裝文件夾
4. 卸載過程中出現的意外情況的測試（如死機、斷電、重啟）
5. 卸載是否支持取消功能，單擊取消后軟件卸載的情況
6. 系統直接卸載UI測試，是否有卸載狀態進度條提示

2.3 安全性

2.3.1 通訊安全

1. 在軟件運行中，如有來電，SMS，EMS，MMS，藍牙等通訊或充電是，是否能暫定程序，優先處理通訊，並在處理完畢后恢復軟件，繼續執行
2. 創立連接時，應用程序因網絡連接中斷，是否可以告訴用戶連接中斷的情況
3. 可以處理通訊延時和中斷
4. HTTP、HTTPS覆蓋測試
   • APP和后台服務一般是通過http交互，驗證http環境下是否正常
   • 外網免費網絡中一般都要輸入密碼，通過SSL認證來訪問網絡，需要對是使用HTTP Client的library異常做捕獲處理
5. 應用程序關閉，或網絡斷開不再使用時，應該及時關閉

2.3.2人機接口安全

1. 返回桌面應用程序保持可用
2. 指令順序有先后
3. 本機非網絡控制和通知控制，其他設置對應用程序不造成影響

2.3.3 數據安全性

1. 密碼等敏感數據不會保存在設備中，同時密碼不會被解碼
2. 輸入密碼講不以明文展示
3. 支付相關的密碼一律不被儲存在欲輸入位置上
4. 若應用程序可進行備份操作，備份數據應進行加密操作，恢復數據應考慮恢復過程中的異常，通訊中斷等
5. 在數據刪除之前，應用程序應當通知用戶或者應用程序提供一個“取消”命令的操作
6. 應用程序應當能夠處理當不允許應用軟件連接到個人信息管理的情況
7. 在沒有用戶明確許可的前提下不損壞側除個人信息管理應用程序中的任何內容
8. 不能再安全警告前，利用顯示誤導信息欺騙用戶，應用程序不應該模擬進行安全警告誤導用戶
9. 如果數據庫中重要的數據正要被重寫, 應及時告知用

2.4 功能測試

根據軟件說明或用戶需求驗證App的各個功能實現

• 采用時間、地點、對象、行為和背景五元素或業務分析等方法分析、提煉App的用戶使用場景，對比說明或需求，整理出內在、外在及非功能直接相關的需求，構建測試點，並明確測試標准，若用戶需求中無明確標准遵循，則需要參考行業或相關國際標准或准則。
• 根據被測功能點的特性列丼出相應類型的測試用例對其進行覆蓋，如；涉及輸入的地方需要考慮等價、邊界、負面、異常或非法、場景回滾、關聯測試等測試類型對其進行覆蓋
• 在測試實現的各個階段跟蹤測試實現與需求輸入的覆蓋情況，及時修正業務或需求理解錯誤

2.4.1 程序運行

1. 安裝后可正常打開
2. 注冊
   • 用戶密碼長度
   • 注冊后提示
   • 注冊成功數據是否前后一致
3. 登錄
   • 登錄是否互斥
   • 是否可進行異地登錄
   • 是否允許非法登錄
   • 使用已在線賬號登錄，登錄系統是否處理正常
   • 使用禁用賬號登錄系統，系統處理是否正常處理
   • 登錄賬號密碼數據錯誤登錄是否成功
   • 登錄超時如何處理
4. 注銷
   • 注銷后用戶再次登錄是否成功
   • 注銷后，數據是否已經刪除（物理刪除，或邏輯刪除）

2.4.2 程序切換

1. APP切換到后台，再回到app，檢查是否停留在上一次操作界面
2. APP切換到后台，再回到app，檢查功能及應用狀態是否正常，IOS4和IOS5的版本的處理機制有的不一樣
3. app切換到后台，再回到前台時，注意程序是否崩潰，功能狀態是否正常，尤其是對於從后台切換回前台數據有自動更新的時候
4. 手機鎖屏解屏后進入app注意是否會崩潰，功能狀態是否正常，尤其是對於從后台切換回前台數據有自動更新的時候
5. 當App使用過程中有電話進來中斷后再切換到app，功能狀態是否正常
6. 當殺掉app進程后，再開啟app，app能否正常啟動
7. 出現必須處理的提示框后，切換到后台，再切換回來，檢查提示框是否還存在，有時候會出現應用自動跳過提示框的缺陷
8. 對於有數據交換的頁面，每個頁面都必需要進行前后台切換、鎖屏的測試，這種頁面最容易出現崩潰

2.4.3 保留TOKEN（免登）

2.4.4 APP更新

1. 當客戶端有新版本時，有更新提示
2. 當版本為非強制升級版時，用戶可以取消更新，老版本能正常使用。用戶在下次啟動app時，仍能出現更新提示
3. 當版本為強制升級版時，當給出強制更新后用戶沒有做更新時，退出客戶端。下次啟動app時，仍出現強制升級提示
4. 當客戶端有新版本時，在本地不刪除客戶端的情況下，直接更新檢查是否能正常更新

2.4.5 離線加載

很多應用都可以加載數據到本地，給用戶提供在離線情況下可以瀏覽

2.4.6 消息推送

1. 在不禁用通知的情況下，push消息是可以直接推送到手機且可以在通知欄查看
2. 在push消息推送到手機的情況下，可以點擊消息進入喚醒且進入APP
3. 當push消息是針對用戶進行推送的時候，需核實push消息與用戶身份是否相符
4. push消息是否是按照業務規則進行推送
5. 用戶設置免打擾時間內，用戶是接收不到push消息的
6. 測試push時，需真機測試

2.5 UI測試

用戶界面 (GUI) 測試用於核實用戶與App之間的交互，包括用戶友好性，人性化測試。  一個好的App要有一個極佳的分辨率，而在其他分辨率下也都能可以運行。GUI 測試的目標是確保用戶界面會通過測試對象的功能來為用戶提供相應的訪問或瀏覽功能。另外，GUI 測試還可確保 GUI 中的對象按照預期的方式運行，並符合公司或行業的標准

1. GUI測試主要測試在不同分辨率下，測試用戶界面(如菜單、對話框、窗口和其它可視控件)布局、風格是否滿足客戶要求，文字是否正確，頁面是否美觀，文字，圖片組合是否完美，操作是否友好等。
2. GUI測試的目標是確保用戶界面會通過測試對象的功能來為用戶提供相應的訪問或瀏覽功能。確保用戶界面符合公司或行業的標准，包括用戶友好性、人性化、易操作性測試

2.6 性能測試

性能測試用來測試App在真實環境中的運行性能，以及與硬件、網絡資源的匹配度，最終度量系統相對於預定義目標的差距，通過極限測試方法，發現系統在極限或惡劣的環境中自我保護能力，主要驗證系統的可靠性。 性能測試測試主要通過以下幾項測試完成

2.6.1 負載測試

負載測試是在一定的軟硬件及網絡環境下，通過模擬不同的用戶，執行一種或多種業務，觀察系統在不同負載下的性能表現。在這種測試中，將使測試對象承擔不同的工作量，以評測和評估測試對象在不同工作量條件下的性能行為，以及持續正常運行的能力。
負載測試的目標是確定並確保系統在超出最大預期工作量的情況下仍能正常運行。 此外，負載測試還要評估性能特征，例如，響應時間、事務處理速率和其他與時間相關的方面。

2.6.2 強度測試

強度測試是一種性能測試，實施和執行此類測試的目的是找出因資源不足或資源爭用而導致的錯誤。如果內存或磁盤空間不足，測試對象就可能會表現出一些在正常條件下並不明顯的缺陷。而其他缺陷則可能由於爭用共享資源（如數據庫鎖或網絡帶寬）而造成的。強度測試還可用於確定測試對象能夠處理的最大工作量。

2.6.3 穩定性測試

穩定性測試評價系統在一定負荷情況下，長時間的運行情況。在一定的軟硬件及網絡環境中，通過模擬大量的用戶執行多種業務處理大量數據，使系統在極限環境下長時間運行，目的在於尋找系統的失效點。

2.7 兼容測試

兼容適配性測試（配置測試），是核實測試對象在不同的App、硬件配置中的運行情況，測試系統在各種軟硬件配置，不同的參數配置下系統具有的功能和性能。

在大多數環境中，不同終端、屏幕、OS版本、網絡連接的規格都會有所不同，而這些因素都可能運行許多不同的配置環境組合，從而占用不同的資源（如CPU、內存、瀏覽器版本、OS版本等）。

1. 新老版本兼容
2. 設備兼容
3. 設備系統兼容
4. 分辨率兼容
5. 瀏覽器兼容

2.8 接口測試

服務端一般會提供JSON格式的數據給客戶端，所以我們在服務端需要進行接口測試，確保服務端提供的接口並轉換的JSON內容正確，對分支、異常流有相應的返回值。此塊測試可以采用itest框架進行測試。最方便的是采用httpclient進行接口測試。
一般來講，APP做接口測試不是特別適合

2.9 用戶體驗可用性測試

用戶體驗可用性測試主要是檢測用戶在理解和使用系統方面到底有多好，是否存在障礙或難以理解的部分。

用戶體驗可用性的測試方法，一般是通過用戶訪談，或邀請內測、小范圍公測等方式進行，通過不同實驗組的運營結果來判斷是否存在可用性缺陷。但由於缺乏有效的測試工具，必須要大量的測試樣本才能獲得比較真實的測試數據，投入資源較多，測試周期較長。

2.10 網絡測試

手機的網絡目前主要分為2G、3G、4G、wifi。

• 無網絡時，執行需要網絡的操作，給予友好提示，確保程序不出現crash。
• 內網測試時，要注意選擇到外網操作時的異常情況處理。
• 在網絡信號不好時，檢查功能狀態是否正常，確保不因提交數據失敗而造成crash。
• 在網絡信號不好時，檢查數據是否會一直處於提交中的狀態，有無超時限制。如遇數據交換失敗時要給予提示。
• 在網絡信號不好時，執行操作后，在回調沒有完成的情況下，退出本頁面或者執行其他操作的情況，有無異常情況。此問題也會經常出現程序crash

2.9 回歸測試

回歸測試是以上所有測試完成后的一個最為重要的環節，是App發布、維護階段，對缺陷進行修復后的測試
目的是驗證缺陷已經得到修復，檢測是否引入新的缺陷

2.9.1 回歸測試流程

1. 在測試策略制定階段，制定回歸測試策略
2. 確定需要回歸測試的版本；
3. 測試版本發布后，按照回歸測試策略來執行回歸測試；
4. 回歸測試通過，關閉缺陷跟蹤單；
5. 回歸測試不通過，缺陷跟蹤單返回給開發人員，開發人員重新修改BUG。再次提交給測試人員回歸測試

2.9.2 回歸測試策略

1. 完全重復測試：重新執行前期設計的用例，來確認問題修改的真確性和修改的擴散局部影響性；
2. 選擇性重復測試：
3. 覆蓋修改法：針對被修改的部分，選取或重新構造測試用例驗證沒有錯誤再次發 生的選擇方法
4. 周邊影響法：該方法包括覆蓋修改法，還要分析修改后對擴散的影響；
5. 指標達成法：先確定一個達成的指標，基於這種要求選擇一個最小的測試用例集合

備注：部分引用整理別人作品，非原版作品，只提供個人學習，與任何商業行為無關。