移動互聯網App測試流程及測試點之功能測試

App 功能測試

根據軟件說明或用戶需求驗證App的各個功能實現 ，採用如下方法實現並評估功能測試過程：

1)採用時間、地點、對象、行爲和背景五元素或業務分析等方法分析、提煉App的用戶使用場景 ，對比說明或需求，整理出內在、外在及非功能直接相關的需求，構建測試點，並明確測試標準，若用戶需求中無明確標準遵循，則需要參考行業或相關國際標準或準則。

2)根據被測功能點的特性列丼出相應類型的測試用例對其進行覆蓋 ，如；涉及輸入的地方需要考慮等價、邊界、負面、異常或非法、場景回滾、關聯測試等測試類型對其進行覆蓋。  

3)在測試實現的各個階段跟蹤測試實現與需求輸入的覆蓋情況 ，及時修正業務或需求理解錯誤。

 
1運行

1）App安裝完成後的試運行，可正常打開軟件。

2）App打開測試，是否有加載狀態進度提示。

3）App打開速度測試，速度是否可觀。

4）App頁面間的切換是否流暢，邏輯是否正確

5）註冊

-- 同表單編輯頁面
-- 用戶名密碼長度
-- 註冊後的提示頁面
-- 前臺註冊頁面和後臺的管理頁面數據是否一致
-- 註冊後，在後臺管理中頁面提示

6）登錄

-- 使用合法的用戶登錄系統。
-- 系統是否允許多次非法的登陸，是否有次數限制。
-- 使用已經登陸的賬號登陸系統是否正確處理。
-- 使用禁用的賬號登陸系統是否正確處理。
-- 用戶名、口令（密碼）錯誤或漏填時能否登陸。
-- 刪除或修改後的用戶，原用戶登陸。
-- 不輸入用戶口令和用戶、重複點（確定或取消按鈕）是否允許登陸。
-- 登陸後，頁面中登陸信息。
-- 頁面中有註銷按鈕。
-- 登陸超時的處理。

7）註銷

-- 註銷原模塊，新的模塊系統能否正確處理。
-- 終止註銷能否返回原模塊，原用戶。
-- 註銷原用戶，新用戶系統能否正確處理。
-- 使用錯誤的賬號、口令、無權限的被禁用的賬號進行註銷

 
2應用的前後臺切換

1) APP 切換到後臺，再回到 app ，檢查是否停留在上一次操作界面。

2) APP 切換到後臺，再回到 app ，檢查功能及應用狀態是否正常， IOS4 和 IOS5 的版本的處理機制有的不一樣。  

3) app 切換到後臺，再回到前臺時，注意程序是否崩潰，功能狀態是否正常，尤其是對於從後臺切換回前臺數據有自動更新的時候。  

4) 手機鎖屏解屏後進入 app 注意是否會崩潰，功能狀態是否正常，尤其是對於從後臺切換回前臺數據有自動更新的時候。  

5) 當 App 使用過程中有電話進來中斷後再切換到 app ，功能狀態是否正常  

6) 當殺掉 app 進程後，再開啓 app ， app 能否正常啓動。  

7) 出現必須處理的提示框後，切換到後臺，再切換回來，檢查提示框是否還存在，有時候會出現應用自動跳過提示框的缺陷。  

8) 對於有數據交換的頁面，每個頁面都必需要進行前後臺切換、鎖屏的測試，這種頁面最容易出現崩潰。

 
3免登錄

很多應用提供免登錄功能，當應用開啓時自動以上一次登錄的用戶身份來使用 app.

1) app 有免登錄功能時，需要考慮 IOS 版本差異。  

2) 考慮無網絡情況時能否正常進入免登錄狀態。  

3) 切換用戶登錄後，要校驗用戶登錄信息及數據內容是否相應更新，確保原用戶退出。  

4) 根據 MTOP 的現有規則，一個帳戶只允許登錄一臺機器。所以，需要檢查一個帳戶登錄多臺手機的情況。原手機裏的用戶需要被踢出，給出友好提示。  

5) app 切換到後臺，再切回前臺的校驗  

6) 切換到後臺，再切換回前臺的測試  

7) 密碼更換後，檢查有數據交換時是否進行了有效身份的校驗  

8) 支持自動登錄的應用在進行數據交換時，檢查系統是否能自動登錄成功並且數據操作無誤。  

9) 檢查用戶主動退出登錄後，下次啓動 app ，應停留在登錄界面

 
4 數據更新  

根據應用的業務規則，以及數據更新量的情況，來確定最優的數據更新方案。  

1) 需要確定哪些地方需要提供手動刷新，哪些地方需要自動刷新，哪些地方需要手動 + 自動刷新。  

2) 確定哪些地方從後臺切換回前臺時需要進行數據更新。  

3) 根據業務、速度及流量的合理分配，確定哪些內容需要實時更新，哪些需要定時更新。  

4) 確定數據展示部分的處理邏輯，是每次從服務端請求，還是有緩存到本地，這樣纔能有針對性的進行相應測試。  

5) 檢查有數據交換的地方，均有相應的異常處理。  

 
5離線瀏覽  

很多應用會支持離線瀏覽，即在本地客戶端會緩存一部分數據供用戶查看。  

1) 在無網絡情況可以瀏覽本地數據  

2) 退出 app 再開啓 app 時能正常瀏覽  

3) 切換到後臺再切回前臺可以正常瀏覽  

4) 鎖屏後再解屏回到應用前臺可以正常瀏覽  

5) 在對服務端的數據有更新時會給予離線的相應提示  
6 App更新

1) 當客戶端有新版本時，有更新提示。  

2) 當版本爲非強制升級版時，用戶可以取消更新，老版本能正常使用。用戶在下次啓動 app 時，仍能出現更新提示。  

3) 當版本爲強制升級版時，當給出強制更新後用戶沒有做更新時，退出客戶端。下次啓動 app 時，仍出現強制升級提示。  

4) 當客戶端有新版本時，在本地不刪除客戶端的情況下，直接更新檢查是否能正常更新。

5) 當客戶端有新版本時，在本地不刪除客戶端的情況下，檢查更新後的客戶端功能是否是新版本。  

6) 當客戶端有新版本時，在本地不刪除客戶端的情況下，檢查資源同名文件如圖片是否能正常更新成最新版本。如果以上無法更新成功的，也都屬於缺陷。  

 
7 定位、照相機服務  

1) App 有用到相機，定位服務時，需要注意 系統 版本差異  

2) 有用到定位服務、照相機服務的地方，需要進行前後臺的切換測試，檢查應用是否正常。  

3) 當定位服務沒有開啓時，使用定位服務，會友好性彈出是否允許設置定位提示。當確定允許開啓定位時，能自動跳轉到定位設置中開啓定位服務。  

4) 測試定位、照相機服務時，需要採用真機進行測試。

 
8 時間測試  

客戶端可以自行設置手機的時區、時間，因此需要校驗該設置對 app 的影響。  

--中國爲東 8 區，所以當手機設置的時間非東 8 區時，查看需要顯示時間的地方，時間是否展示正確，應用功能是否正常。時間一般需要根據服務器時間再轉換成客戶端對應的時區來展示，這樣的用戶體驗比較好。比如發表一篇微博在服務端記錄的是 10 ： 00 ，此時，華盛頓時間爲 22 ： 00 ，客戶端去瀏覽時，如果設置的是華盛頓時間 , 則顯示的發表時間即爲 22:00, 當時間設回東 8 區時間時，再查看則顯示爲 10 ： 00 。

 
9 PUSH 測試

1) 檢查 push 消息是否按照指定的業務規則發送  

2) 檢查不接受推送消息時，檢查用戶不會再接收到 push.

3) 如果用戶設置了免打擾的時間段，檢查在免打擾時間段內，用戶接收不到 PUSH 。

在非免打擾時間段，用戶能正常收到 push 。

4) 當 push 消息是針對登錄用戶的時候，需要檢查收到的 push 與用戶身份是否相符，沒有錯誤地將其它人的消息推送過來。一般情況下，只對手機上最後一個登錄用戶進行消息推送。  

5) 測試 push 時，需要採用真機進行測試。  

 

TestBird移動應用測試專家提供基於TestBird雲手機的APP自助功能測試工具,讓移動APP的每一次迭代開發更輕鬆,提高 APP測試 效率,提升測試質量,減少人力投入。