目前手機App測試還是以發現bug為主，主要
測試流程就是服務器
接口測試，客戶端功能性覆蓋，以及自動化配合的性能，適配，壓測等，對于App安全性測試貌似沒有系統全面統一的標準和流程，其實安全性bug也可以是bug的一種，只不過更加隱秘，難以發現，尤其針對于手機App。近期時間比較充裕，研究了一下安全性相關的東西，并對于我們自身的產品測試了一下(更主要的目的是游戲作弊刷分)，發現了不少問題，總結一下。
我的理解，包括以webview為主體的app，站在入侵或者攻擊的角度來講，安全隱患在于http抓包，逆向工程。談這之前先講講webview相關的app，前一段時間有個曝工資的軟件很火，但有查詢次數的限制，抓包研究了一下，發現其主要還是webview，通過抓包詳細分析，才明白他記錄查詢次數的手段，每一個用戶都會分配一個id，以及一個代表查詢次數count以cookie的形式保存到本地，通過維護cookie達到限制查詢次數的目的，所以清除cookie就可以無限制的查詢了，個人覺得，webview相關的app安全性測試應該還是
web測試那一套，xss攻擊，sql注入等（沒搞過web安全測試，僅推測）。
大部分app還是走的http或者https，所以防http抓包泄露用戶信息以及系統自身漏洞是必要的，畢竟像
騰訊那種通過自身通信協議增加安全性的還是少數的（抓過微信和qq的沒抓著，不知道有沒有相關工具可以抓手機tcp的包）。既然有接口測試為什么還需要單獨對客戶端進行抓包驗證安全性呢？這么說吧，接口測試其實最主要的驗證接口邏輯，可用性，邊界值，異常檢查，但并不能預先保證客戶端調用不出問題，一個針對多個app抓包都發現的問題可以說明：抓了好多社交性app，發現對于用戶資料隱私泄露還是很嚴重的，當你查看一個陌生用戶信息時，一些
手機號，qq等信息頁面上應該不顯示的，但這些信息不顯示并不代表服務器沒有下發，好多都是客戶端限制的，通過抓包，完全可以查看到陌生用戶的app。再如好多發帖，push消息的應用，如果沒有消息有效性的驗證，抓到包之后篡改消息，服務器一點反應都沒，這就會留有極大的隱患。
至于逆向工程這點，對于android就很好理解了，反編譯，修改或者插入自己的代碼，以達到相應目的。真見過幾個沒有代碼混淆的app，包括我們自己的以及大名鼎鼎snapchat，記得有個游戲特搞笑，游戲主題是C#寫得，結果
java的代碼混淆了，C#的代碼沒有，修改了幾個參數值，插了幾段自己的代碼，就作弊成功了。尤其好多開放平臺的游戲，通過開放平臺sdk文檔，再加上反編譯后些許信息，即使代碼混淆了，也能推測出好多東西。這些都是安全性隱患。
以上這些只是最近一段時間對于手機app安全性測試的一點認識，很膚淺，
安全性測試對于測試人員素質要求還是很高的，尤其好多都是經驗性的東西，只有通過不斷增加經驗，才能更好的做好測試。