1. 程式人生 > >APP測試要點—UI、功能測試

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

設置 前臺 中國 新版本 請求 更換 不同的 有時 存在

一、UI測試

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

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

導航測試

1)按鈕、對話框、列表和窗口等;或在不同的連接頁面之間需要導航

2)是否易於導航,導航是否直觀

3)是否需要搜索引擎

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

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

圖形測試

1)橫向比較。各控件操作方式統一

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

3)頁面標簽風格是否統一

4)頁面是否美觀

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

6)圖片質量要高且圖片尺寸在設計符合要求的情況下應盡量小

7)界面整體使用的顏色不宜過多

內容測試

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

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

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

4)是否有錯別字

5)信息是否為中文顯示

6)是否有敏感性詞匯、關鍵詞

7)是否有敏感性圖片,如:涉及版權、專利、隱私等圖片

二、功能測試

根據軟件說明或用戶需求驗證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時,需要采用真機進行測試。

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