APP測試要點—UI、功能測試

1、UI測試

測試用戶界面(如菜單、對話框、窗口和其它可規控件)佈局、風格是否知足客戶要求、文字是否正確、頁面是否美觀、文字、圖片組合是否完美、操做是否友好等。

UI測試的目標是確保用戶界面會經過測試對象的功能來爲用戶提供相應的訪問或瀏覓功能。確保用戶界面符合公司或行業的標準。包括用戶友好性、人性化、易操做性測試。

導航測試

1）按鈕、對話框、列表和窗口等；或在不一樣的鏈接頁面之間須要導航

2）是否易於導航，導航是否直觀

3）是否須要搜索引擎

4）導航幫助是否準確直觀

5）導航與頁面結構、菜單、鏈接頁面的風格是否一致

圖形測試

1）橫向比較。各控件操做方式統一

2）自適應界面設計，內容根據窗口大小自適應

3）頁面標籤風格是否統一

4）頁面是否美觀

5）頁面的圖片應有其實際意義而要求總體有序美觀

6）圖片質量要高且圖片尺寸在設計符合要求的狀況下應儘可能小

7）界面總體使用的顏色不宜過多

內容測試

1）輸入框說明文字的內容與系統功能是否一致

2）文字長度是否加以限制

3）文字內容是否表意不明

4）是否有錯別字

5）信息是否爲中文顯示

6）是否有敏感性詞彙、關鍵詞

7）是否有敏感性圖片，如：涉及版權、專利、隱私等圖片

 

2、功能測試

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

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

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

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

運行

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

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

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

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

5）註冊

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

6）登陸

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

7）註銷

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

應用的先後臺切換

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) 測試定位、照相機服務時，須要採用真機進行測試。

時間測試 

       客戶端能夠自行設置手機的時區、時間，所以須要校驗該設置對app的影響。 

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

 PUSH測試

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

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

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

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

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

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