## 測試資源及準備 1. 產品需求文檔、產品原型圖、接口說明文檔以及設計說明文檔等 2. 測試設備及工具：IOS和andriod不同版本的真機，以及相關測試工具（如：抓包工具、VPN等） 3. 確定被測試的APP的版本號和操作系統類型 ## 設計測試用例： 1. 根據產品需求文檔、產品原型圖、接口說明文檔以及設計說明文檔等編寫功能測試用例。 2. 用例評審、修改、完善，評審通過后，根據測試用例進行測試 ## 測試階段：UI測試、功能測試、性能壓力測試、異常測試等 ## 移動測試測試常見的測試點 ## UI測試（User Interface 用戶界面） 1. UE（User Experience）用戶體驗 - 布局與交互圖保持一致，風格是否滿足用戶需求，若有用戶體驗方面的建議，可以先與產品經理確認，確認通過后，可以正式向開發提出用戶體驗方面的問題； - 真機效果與UE圖沒有視覺上的嚴重偏差，如字號，字體大小，加粗，字體顏色，行高，行間距，按鈕擺放位置，間隔，尺寸等； - 資源圖正確使用，沒有不必要的拉伸，壓縮或其他效果； - 各種提示，文字通順不產生歧義，展示符合用戶使用習慣； - 動畫效果不卡頓，正常展現； - 由于測試環境中的數據為模擬數據，測試時必須預先考慮到正式環境中可能出現的數據類型。 2. 頁面操作 - 是否有防重復點擊，即連續快速點擊不會出現多個頁面或彈窗 - 單指滑動，單指單擊，單指雙擊，單指長按，單指縮放，多指點擊 - 搖一搖，橫豎屏切換，前后臺切換 - 長時間使用，長時間放在后臺 3. 不同場景下的頁面操作 - 不同網絡，弱網下的頁面跳轉，點擊響應的展現效果 - 修改本地參數后的頁面操作展現效果，如修改日期，時間，時區，語言，鍵盤等 - 修改系統權限后的頁面操作展現效果，如打開關閉定位，攝像，照片，通訊錄等的授權等 - 頁面操作過程中有系統打斷，如來電，短信，鬧鐘提醒，日歷提醒，藍牙提醒，插拔數據線，插拔耳機，待機，鎖屏，低電量提醒等 - 頁面操作過程中進行前后臺切換，如當頁面數據交換時，有彈窗，提示框的時機進行切換容易發現問題。 - 針對非主線程調用的接口，前端要對異常及無網絡情況做異步處理，不提示異常且不影響主線程操作。 4. 頁面數據獲取和展現 - 頁面是否有緩存，緩存機制是怎樣的，緩存的內容有哪些 - 在提交頁面數據失敗后是否有重試機制，重試的接口參數是否保持不變 - 在頁面操作過程中，異步接口返回的內容，是否對用戶透明（客戶端兼容忽略請求返回msg） - 在頁面操作過程中，對于接口返回的異常數據，客戶端需兼容，保證程序不崩 # 功能測試 1. 功能測試時主要依據編寫的功能測試用例進行軟件功能的遍歷； 2. 涉及的測試主要包括基本功能測試，安裝、卸載、運行測試，異常處理（包括網絡突然斷開或者網速過慢、機器內存不足等異常情況的處理）測試。 3. 業務邏輯測試：主要測試客戶端業務能否正常完成。 4. 功能點測試：主要測試客戶端功能點是否正常使用 5. 關聯性測試：主要測試客戶端與pc端的交互，客戶端處理完后，pc端與客戶端數據一致 ## 安裝、卸載測試： 1. 生成apk文件在真機上可以安裝及卸載； 2. Android手機端通用安裝工具。如：豌豆莢 3. 應用程序應能正確安裝到設備驅動程序上 4. 能夠在安裝設備驅動程序上找到應用程序的相應圖標 5. 是否包含數字簽名信息 6. JAD文件和 JAR包中包含的所有托管屬性及其值必需是正確的 7. JAD文件顯示的資料內容與應用程序顯示的資料內容應一致 8. 安裝路徑應能指定 9. 沒有用戶的允許,應用程序不能預先設定自動啟動 10. 卸載是否安全,其安裝進去的文件是否全部卸載 11. 卸載用戶使用過程中產生的文件是否有提示 12. 其修改的配置信息是否復原 13. 卸載是否影響其他軟件的功能 14. 卸載應該移除所有的文件 ## 運行測試 1. App安裝完成后的試運行，可正常打開軟件。 2. App打開測試，是否有加載狀態進度提示。 3. App打開速度測試，速度是否可觀。 4. App頁面間的切換是否流暢，邏輯是否正確 ## 注冊 1. 同表單編輯頁面 2. 用戶名密碼長度 3. 注冊后的提示頁面 4. 前臺注冊頁面和后臺的管理頁面數據是否一致 5. 注冊后，在后臺管理中頁面提示 ## 登錄 1. 使用合法的用戶登錄系統。 2. 系統是否允許多次非法的登陸，是否有次數限制。 3. 使用已經登陸的賬號登陸系統是否正確處理。 4. 使用禁用的賬號登陸系統是否正確處理。 5. 用戶名、口令（密碼）錯誤或漏填時能否登陸。 6. 刪除或修改后的用戶，原用戶登陸。 7. 不輸入用戶口令和用戶、重復點（確定或取消按鈕）是否允許登陸。 8. 登陸后，頁面中登陸信息。 9. 頁面中有注銷按鈕。 10. 登陸超時的處理 ## 注銷 1. 注銷原模塊，新的模塊系統能否正確處理。 2. 終止注銷能否返回原模塊，原用戶。 3. 注銷原用戶，新用戶系統能否正確處理。 4. 使用錯誤的賬號、口令、無權限的被禁用的賬號進行注銷 ## 軟件權限 1. 扣費風險：包括發送短信、撥打電話、連接網絡等 2. 隱私泄露風險：包括訪問手機信息、訪問聯系人信息等 3. 對App的輸入有效性校驗、認證、授權、敏感數據存儲、數據加密等方面進行檢測 4. 限制/允許使用手機功能接人互聯網 5. 限制/允許使用手機發送接受信息功能 6. 限制/允許應用程序來注冊自動啟動應用程序 7. 限制或使用本地連接 8. 限制/允許使用手機拍照或錄音 9. 限制/允許使用手機讀取用戶數據 10. 限制/允許使用手機寫人用戶數據 11. 檢測App的用戶授權級別、數據泄漏、非法授權訪問等 ## 中斷測試 1. APP切換到后臺，再回到 App，檢查是否停留在上一次操作界面。 2. APP切換到后臺，再回到 App，檢查功能及應用狀態是否正常，IOS4和IOS5的版本的處理機制有的不一樣。 3. App切換到后臺，再回到前臺時，注意程序是否崩潰，功能狀態是否正常，尤其是對于從后臺切換回前臺數據有自動更新的時候。 4. 手機鎖屏解屏后進入App注意是否會崩潰，功能狀態是否正常，尤其是對于從后臺切換回前臺數據有自動更新的時候。 5. 當 App使用過程中有電話進來中斷后再切換到App，功能狀態是否正常 6. 當殺掉 App進程后，再開啟 App，App能否正常啟動。 7. 出現必須處理的提示框后，切換到后臺，再切換回來，檢查提示框是否還存在，有時候會出現應用自動跳過提示框的缺陷。 8. 對于有數據交換的頁面，每個頁面都必需要進行前后臺切換、鎖屏的測試，這種頁面最容易出現崩潰 ## 免登錄 很多應用提供免登錄功能，當應用開啟時自動以上一次登錄的用戶身份來使用 App。 1. App有免登錄功能時，需要考慮IOS版本差異。 2. 考慮無網絡情況時能否正常進入免登錄狀態。 3. 切換用戶登錄后，要校驗用戶登錄信息及數據內容是否相應更新，確保原用戶退出。 4. 根據MTOP的現有規則，一個帳戶只允許登錄一臺機器。所以，需要檢查一個帳戶登錄多臺手機的情況。原手機里的用戶需要被踢出，給出友好提示。 5. app切換到后臺，再切回前臺的校驗 6. 切換到后臺，再切換回前臺的測試 7. 密碼更換后，檢查有數據交換時是否進行了有效身份的校驗 8. 支持自動登錄的應用在進行數據交換時，檢查系統是否能自動登錄成功并且數據操作無誤。 9. 檢查用戶主動退出登錄后，下次啟動app，應停留在登錄界面 ## 數據更新 根據應用的業務規則，以及數據更新量的情況，來確定最優的數據更新方案。 1. 需要確定哪些地方需要提供手動刷新，哪些地方需要自動刷新，哪些地方需要手動+自動刷新。 2. 確定哪些地方從后臺切換回前臺時需要進行數據更新。 3. 根據業務、速度及流量的合理分配，確定哪些內容需要實時更新，哪些需要定時更新。 4. 確定數據展示部分的處理邏輯，是每次從服務端請求，還是有緩存到本地，這樣才能有針對性的進行相應測試。 5. 檢查有數據交換的地方，均有相應的異常處理。 ## 離線瀏覽 很多應用會支持離線瀏覽，即在本地客戶端會緩存一部分數據供用戶查看。 1. 在無網絡情況可以瀏覽本地數據 2. 退出 App再開啟 App時能正常瀏覽 3. 切換到后臺再切回前臺可以正常瀏覽 4. 鎖屏后再解屏回到應用前臺可以正常瀏覽 5. 在對服務端的數據有更新時會給予離線的相應提示 ## App更新 1. 當客戶端有新版本時，有更新提示。 2. 當版本為非強制升級版時，用戶可以取消更新，老版本能正常使用。用戶在下次啟動App時，仍能出現更新提示。 3. 當版本為強制升級版時，當給出強制更新后用戶沒有做更新時，退出客戶端。下次啟動app時，仍出現強制升級提示。 4. 當客戶端有新版本時，在本地不刪除客戶端的情況下，直接更新檢查是否能正常更新。 5. 當客戶端有新版本時，在本地不刪除客戶端的情況下，檢查更新后的客戶端功能是否是新版本。 6. 當客戶端有新版本時，在本地不刪除客戶端的情況下，檢查資源同名文件如圖片是否能正常更新成最新版本。如果以上無法更新成功的，也都屬于缺陷。 ## 定位、照相機服務 1. App有用到相機，定位服務時，需要注意系統版本差異 2. 有用到定位服務、照相機服務的地方，需要進行前后臺的切換測試，檢查應用是否正常。 3. 當定位服務沒有開啟時，使用定位服務，會友好性彈出是否允許設置定位提示。當確定允許開啟定位時，能自動跳轉到定位設置中開啟定位服務。 4. 測試定位、照相機服務時，需要采用真機進行測試。 ## 時間測試 1. 客戶端可以自行設置手機的時區、時間，因此需要校驗該設置對 app的影響。 2. 中國為東8區，所以當手機設置的時間非東8區時，查看需要顯示時間的地方，時間是否展示正確，應用功能是否正常。時間一般需要根據服務器時間再轉換成客戶端對應的時區來展示，這樣的用戶體驗比較好。比如發表一篇微博在服務端記錄的是10：00，此時，華盛頓時間為22：00，客戶端去瀏覽時，如果設置的是華盛頓時間,則顯示的發表時間即為22:00,當時間設回東 8區時間時，再查看則顯示為10：00。 ## 兼容性及適配測試 1. 硬件的適配：不同手機廠商(華為、OPPO、錘子等)、硬件性能，不同屏幕大小的適配（3.5到5.0屏幕在UI顯示有區別，要支持最大到最小）； 2. OS版本的兼容：IOS6-9；Andriod3以上等，如果用了一些新的API在老的系統上不支持會導致crash； 3. 不同分辨率屏幕的適配：移動設備的分辨率多種多樣，如果APP沒有做比較合適的處理就可能會顯示不好，甚至影響功能的操作。 4. 兼容性測試必須在一定數量的真機上進行，由于真機類型過多，尤其Android在做兼容性測試時，可以選取典型的幾種運用較多的真機，進行兼容性測試； 5. 另外可以借助開源測試testin云測，進行更多機型的兼容性測試，testin云測提供基本的運行情況和一些截圖，以及簡單的測試報告，有助于擴大測試的范圍。 6. 網絡的兼容性：2G\\3G\\4G\\WIFI,弱網下、斷網時 7. app跨版本的兼容性 ## 穩定性測試 1. 安卓APP的穩定性常常使用monkey命令進行測試，通過隨機事件流模擬人的操作，對檢查程序的內存溢出、空指針有很大的作用。 2. Monkey主要用來檢測系統ANR及Crash等問題 ## 數據安全性 1. 當將密碼或其他的敏感數據輸人到應用程序時，其不會被儲存在設備中，同時密碼也不會被解碼 2. 輸人的密碼將不以明文形式進行顯示 3. 密碼，信用卡明細，或其他的敏感數據將不被儲存在它們預輸人的位置上 4. 不同的應用程序的個人身份證或密碼長度必需至少在4一8個數字長度之間 5. 當應用程序處理信用卡明細，或其他的敏感數據時，不以明文形式將數據寫到其它單獨的文件或者臨時文件中。以防止應用程序異常終止而又沒有刪除它的臨時文件，文件可能遭受人侵者的襲擊，然后讀取這些數據信息。 6. 當將敏感數據輸人到應用程序時，其不會被儲存在設備中 7. 備份應該加密，恢復數據應考慮恢復過程的異常通訊中斷等，數據恢復后再使用前應該經過校驗 8. 應用程序應考慮系統或者虛擬機器產生的用戶提示信息或安全替告 9. 應用程序不能忽略系統或者虛擬機器產生的用戶提示信息或安全警告，更不能在安全警告顯示前,，利用顯示誤導信息欺騙用戶，應用程序不應該模擬進行安全警告誤導用戶 10. 在數據刪除之前，應用程序應當通知用戶或者應用程序提供一個“取消”命令的操作 11. “取消”命令操作能夠按照設計要求實現其功能 12. 應用程序應當能夠處理當不允許應用軟件連接到個人信息管理的情況 13. 當進行讀或寫用戶信息操作時，應用程序將會向用戶發送一個操作錯誤的提示信息 14. 在沒有用戶明確許可的前提下不損壞刪除個人信息管理應用程序中的任何內容 15. 應用程序讀和寫數據正確。 16. 應用程序應當有異常保護。 17. 如果數據庫中重要的數據正要被重寫，應及時告知用戶 18. 能合理地處理出現的錯誤 19. 意外情況下應提示用戶 ## 通訊安全性 1. 在運行其軟件過程中，如果有來電、SMS、EMS、MMS、藍牙、紅外等通訊或充電時，是否能暫停程序，優先處理通信，并在處理完畢后能正常恢復軟件，繼續其原來的功能 2. 當創立連接時，應用程序能夠處理因為網絡連接中斷，進而告訴用戶連接中斷的情況 3. 應能處理通訊延時或中斷 4. 應用程序將保持工作到通訊超時，進而發送給用戶一個錯誤信息指示有連接錯誤 5. 應能處理網絡異常和及時將異常情況通報用戶 6. 應用程序關閉或網絡連接不再使用時應及時關閉或斷開 7. HTTP、HTTPS覆蓋測試 –App和后臺服務一般都是通過HTTP來交互的，驗證HTTP環境下是否正常； –公共免費網絡環境中（如：麥當勞、星巴克等）都要輸入用戶名和密碼，通過SSL認證來訪問網絡，需要對使用HTTPClient的library異常作捕獲處理。 ## 人機接口安全性 1. 返回菜單總保持可用 2. 命令有優先權順序 3. 聲音的設置不影響應用程序的功能 4. 應用程序必需利用目標設備適用的全屏尺寸來顯示上述內容 5. 應用程序必需能夠處理不可預知的用戶操作，例如錯誤的操作和同時按下多個鍵 ## PUSH測試 1. 檢查push消息是否按照指定的業務規則發送 2. 檢查不接受推送消息時，檢查用戶不會再接收到push. 3. 如果用戶設置了免打擾的時間段，檢查在免打擾時間段內，用戶接收不到PUSH。 在非免打擾時間段，用戶能正常收到push。 4. 當push消息是針對登錄用戶的時候，需要檢查收到的push與用戶身份是否相符，沒有錯誤地將其它人的消息推送過來。一般情況下，只對手機上最后一個登錄用戶進行消息推送。 5. 測試push時，需要采用真機進行測試 ## 交叉事件測試 針對智能終端應用的服務等級劃分方式及實時特性所提出的測試方法。交叉測試又叫事件或沖突測試，是指一個功能正在執行過程中，同時另外一個事件或操作對該過程進行干擾的測試。如；App在前/后臺運行狀態時與來電、文件下載、音樂收聽等關鍵運用的交互情況測試等。交叉事件測試非常重要，能發現很多應用中潛在的性能問題。 1. 多個App同時運行是否影響正常功能 2. App運行時前/后臺切換是否影響正常功能 3. App運行時撥打/接聽電話 4. App運行時發送/接收信息 5. App運行時發送/收取郵件 6. App運行時切換網絡（2G、3G、wifi） 7. App運行時瀏覽網絡 8. App運行時使用藍牙傳送/接收數據 9. App運行時使用相機、計算器等手機自帶設備 ## 圖形測試 1. 橫向比較。各控件操作方式統一 2. 自適應界面設計，內容根據窗口大小自適應 3. 頁面標簽風格是否統一 4. 頁面是否美觀 5. 頁面的圖片應有其實際意義而要求整體有序美觀 6. 圖片質量要高且圖片尺寸在設計符合要求的情況下應盡量小 7. 界面整體使用的顏色不宜過多 ## 支付測試 1. 支付結果的確認，數據庫查詢 2. 請求報文是否加密 3. 不同場景的支付:金額足夠、金額不足、重復支付、無網支付、弱網支付、同賬號多平臺一起支付、余額寶微信信用卡等多種支付方式、不同支付方式的組合、密碼正確/錯誤、支付上限等情況 4. 選擇付款方式為‘支付寶’，測試是否提示“允許打開支付寶” 5. 測試支付寶沒有安裝的情況下，APP是否有正確提示（未安裝支付寶） 6. 測試支付寶正確安裝的情況下，未登錄支付寶，是否提示登錄頁面 7. 測試支付寶正確安裝的情況下，已登錄支付寶，是否提示支付頁面 ## 性能測試 1. 客戶端性能測試重點關注：安裝卸載時間、啟動時間、頁面加載時間、主要功能占用的CPU、內存、流量、耗電量等，以及與同類產品相比較是否有優勢； 2. 其中頁面加載時間可以利用Android調試工具DDMS獲取到，在DDMS里面搜索Displayed關鍵字就可以看到頁面加載時間； 3. 運行過程中主要功能占用的CPU、內存、流量等可以借助開源工具emmagee（適用于Android）獲取到； 4. 至于服務器端的性能，主要利用接口對服務器施加壓力，重點關注響應時間、吞吐量、并發數、事物通過率等，可以視同工具loadrunner、jmeter進行測試。 ## 回歸測試 bug修復后的回歸測試，上線交付前進行全部的回歸，驗證 ## 移動端程序的開發流程  **版本流程詳解：** 版本流程共分為5大部分，分別為需求、開發、測試、發布、反饋收集。 ### 需求部分 1、需求池：產品會將各組需求進行優先級排序，跟進技術資源的數量來安排當前版本可以做哪些需求。 2、立項：需求較大，涉及較多不同開發組、或部門的需求需要立項，項目進度與資源有獨立的項目經理跟進。 3、需求評審：其中包含需求預審，需求預審是各組老大對該版本的需求進行一次預審與工作量初步評估。確定版本需求后產品經理會在規定的時間節點內召集開發、測試進行需求評審。 ### 開發部分 4、設計評審：服務端開發接口設計完成后進行設計評審，與android、iOS開發溝通清楚接口設計。確保信息一致性。 5、開發編碼：開發各自根據需求進行開發。 ### 測試部分 6、用例設計、用例評審：在開發編碼過程中進行用例設計，用設計完成后召集產品、相關開發、相關測試進行TC評審 7、功能預演：在開發提測時進行功能預演，最好能邀請產品參加，產品提前介入能夠提前發現需求、交互與產品預想中的差異。降低修改成本 8、冒煙測試：功能預演通過后進行冒煙測試，冒煙測試如果遇到主干流程不通可以直接打回。冒煙測試過程中需要保證主要功能正常，不影響后續測試。 9、功能測試：根據項目復雜度確定功能測試輪數 10、適配測試：手工適配，挑選用戶量占比較多的手機進行適配測試，保證不同分辨率，不同操作系統的手機都能正常使用。自動化適配，使用自動化工具在機房進行monkey測試，測試APP在不同操作系統、機型上的安裝、卸載、啟動、跟穩定性。 11、服務端性能測試：根據需求、預估線上用戶量，是否需要提交申請性能測試。需要在上線前完成性能測試與性能調優。 12、客戶端性能測試：理論上來說新增的功能都需要進行性能測試。需要用工具檢查APP的內存占用、CPU占用、FPS、流量、電量等指標是否符合預期。 13、bugbash：在完成功能測試后進行bugbash，需要邀請產品、交互、視覺、開發、測試參與，將bugbash中發現的問題匯總修改完成后可以進入發布流程。 ### 發布部分 14、發布計劃制定：發布計劃分為兩部分，一為服務端發布，二為客戶端發布。 服務端發布根據項目涉及到的應用，制定發布順序，一些獨立工程或者獨立項目可以以項目上線流程提前上線。剩余應用排定順序后在發布日按順序發布。 客戶端根據需求制定需要灰度的時間，策略，渠道等。灰度完成后再正式發布到市場。 15、發布執行，在服務端發布日當天如果涉及應用較多可以進行集中發布，將PE、開發負責人、測試負責人集中到一起進行發布。具體發布細節可以參考發布流程。 16、客戶端發布：服務端發布完成后客戶端打渠道包進行渠道灰度，一般2~3天左右，根據收集的問題修復后，測試進行客戶端大回歸，大回歸通過后，發布到各個應用市場 ### 反饋收集 17、發布完成后分析crash日志，收集用戶反饋將收集的問題加入到需求池。 ## 常見的移動端測試流程