根據用戶需求驗證APP的各個功能實現,以用戶使用場景,對比說明或需求,整理出內在、外在及非功能直接相關的需求,構建測試點,並明確測試標準。根據被測功能點的特性列丼出相應類型的測試用例對其進行覆蓋,。緩存
在測試實現的各個階段跟蹤測試實現與需求輸入的覆蓋狀況,及時修正業務或需求理解錯誤。網絡
運行部分測試
1)APP安裝完成後的試運行,可正常打開軟件。ui
2)APP打開測試,是否有加載狀態進度提示。設計
3)APP打開速度測試,速度是否可觀。進程
4)APP頁面間的切換是否流暢,邏輯是否正確圖片
5)註冊資源
--同表單編輯頁面get
--用戶名密碼長度io
--註冊後的提示頁面
--前臺註冊頁面和後臺的管理頁面數據是否一致
--註冊後,在後臺管理中頁面提示
登陸部分
--使用合法的用戶登陸系統。
--系統是否容許屢次非法的登錄,是否有次數限制。
--使用已經登錄的帳號登錄系統是否正確處理。
--使用禁用的帳號登錄系統是否正確處理。
--用戶名、口令(密碼)錯誤或漏填時可否登錄。
--刪除或修改後的用戶,原用戶登錄。
--不輸入用戶口令和用戶、重複點(肯定或取消按鈕)是否容許登錄。
--登錄後,頁面中登錄信息。
--頁面中有註銷按鈕。
--登錄超時的處理。
註銷部分
--註銷原模塊,新的模塊系統可否正確處理。
--終止註銷可否返回原模塊,原用戶。
--註銷原用戶,新用戶系統可否正確處理。
--使用錯誤的帳號、口令、無權限的被禁用的帳號進行註銷
切換部分
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) 檢查有數據交換的地方,均有相應的異常處理。
APP更新部分
1) 當客戶端有新版本時,有更新提示。
2) 當版本爲非強制升級版時,用戶能夠取消更新,老版本能正常使用。用戶在下次啓動APP時,仍能出現更新提示。
3) 當版本爲強制升級版時,當給出強制更新後用戶沒有作更新時,退出客戶端。下次啓動APP時,仍出現強制升級提示。
4) 當客戶端有新版本時,在本地不刪除客戶端的狀況下,直接更新檢查是否能正常更新。
5) 當客戶端有新版本時,在本地不刪除客戶端的狀況下,檢查更新後的客戶端功能是不是新版本。
6) 當客戶端有新版本時,在本地不刪除客戶端的狀況下,檢查資源同名文件如圖片是否能正常更新成最新版本。若是以上沒法更新成功的,也都屬於缺陷。
以上是APP功能測試流程的基礎部分,具體的各個功能點的測試就要看,被測試的APP的具體功能才能設計知足需求的測試用例流程。在APP測試中功能方面一貫是最複雜的工做,幾千條用例不在少數。