使用App過程中，最煩的莫過於接收到各種已安裝的App發送的各類通知，而這些通知的行爲和觸發的方式又各有不同，讓用戶感到無所適從。
測試App安裝時是否明確申明在用戶使用App時需要用到的權限，否則App在提交到操作系統官方應用商店時會被拒絕，或者在用戶安裝App的時候被拒絕。
測試App在用戶使用過程中是否有合適的通知和消息顯示，例如GPS、藍牙、用戶照片或短信、用戶位置等資源。如果測試人員在使用App過程中改變權限獲取本不該得到的權限時，在iOS上App會訪問不到它想獲得的資源，在Android平臺上，操作系統會彈出安全性異常的提示框，並強制關閉App。
在此時，如何才能提高向用戶申請訪問權限的成功率？不妨檢查一下App在需要用戶授權時是否遵循以下的設計原則和實踐：
第一點，App向用戶申請訪問權限的第一次很關鍵
第一次申請訪問權限的契機很重要，一旦用戶點擊了“不允許”後很難再改變用戶的想法，例如iOS系統設置中如需改變權限需要較爲繁瑣的步驟。因此，不要在用戶第一次打開App時候直接申請訪問權限，過於突然，安全考慮，用戶更傾向於選擇“不允許”。而是先向用戶講述授權後的便利，用戶有所瞭解後再次申請訪問權限。
第二點，給用戶更多機會了解App之後再次申請權限
在申請權限時，“Not Now”比“Don't Allow”更有效，可以等用戶對App有更多瞭解後再次詢問。雖然這種方法會向用戶詢問兩次，但是避免了第一次被用戶直接拒絕。另外，也可在第一次申請時使用圖片等形式更形象地展示授權的好處。
第三點，讓用戶來觸發什麼時候對App進行訪問權限的授權
讓用戶來觸發什麼時候對App進行訪問權限的授權，因爲只有用戶在清楚自己下一步想要做什麼的時候，纔會對App申請的訪問權限作出正確的判斷。但是這種方式在考量和設計方面最爲複雜。
可以看出，對於用戶越是友好和便利的App申請訪問權限的方式，測試用例的設計也就越複雜，因此測試用例中需要覆蓋能觸發每種App申請訪問權限的方式的測試路徑。
測試App在後臺運行時是否有合適的通知和消息顯示，由於用戶可以在iOS的通知中心中對App的通知方式進行單獨設置，如果爲App設置了不同通知方式，測試人員需要對這幾種通知方式都進行測試，來避免出現諸如用戶關閉了鎖屏頁面的App消息通知，但是卻看到了App通知的狀況。
還有兩個App測試點需要注意：
第一點，iOS的狀態欄在通話、導航、錄音、使用熱點等情況下會變爲雙倍寬度顯示，需要測試人員在使用App中狀態欄從標準寬度變爲雙倍寬度，還有從雙倍寬度變爲標準寬度的情況進行測試。另外，根據App展示通知和消息時，需要思考用戶可以對App進行什麼樣的操作，比如點擊通知或消息，進入App等。
第二點，iOS允許App在其圖標右上角顯示未讀信息的計數。值得注意的是，計數顯示是由iOS操作系統處理的，但是計數的數字卻是App提供的。這樣會出現一個問題：已經通過通知欄等方式讀取了信息，但是並沒有從App計數中減去，導致App圖標右上角未讀信息的計數顯示和真實的計數不一致。
測試App的消息推送功能，針對不同的推送消息方式，測試人員需要爲它們單獨設計測試用例。
對App自己完成消息推送的情況，測試人員需要測試關閉App自身服務或App後臺服務器時，App是否會崩潰，App對於新消息的處理，以及App消息推送的性能等。
對App採用推送通知框架的情況，測試人員可以讓推送通知框架的提供商關注後臺服務器出錯的場景，但是依然需要測試在App接收到錯誤的推送通知，推送通知框架服務不可用時App會如何處理。
測試App在出錯時是否有合適的通知和消息顯示。在測試正常功能的消息顯示之外，測試人員還需要測試在出錯的場景中App是否給用戶顯示了恰當的信息。顯然，給用戶只顯示便於技術人員定位問題的錯誤代碼並不能解決用戶的問題；給用戶顯示很長或者步驟很多的解決方法或提示也不能解決用戶的問題；給用戶顯示的提示信息裏打印出log就更不可取了。在信息過剩的時代，用戶不會一直停留在App中關注消息的變化，所以我們需要通過消息的推送和展示，增加用戶對於App的粘性。
