行動裝置 App專項測試

標籤：gpo   開始   概念   div   最大   ras   互動   品質   遇到   

專項測試有資源類效能、互動類效能、穩定性、相容性和安全性等等。但仔細想想，對於一個小團隊，一個創業或創業初成的團隊需要管那麼多嗎？不用，只要心中有概念， 並有對應保底措施即可。對於小團隊來說，更重要的應該是打痛點，因為痛點是產品發展的最大障礙，具備極高的性價比。但是什麼是痛點呢？表面上很多產品都知道自己的痛點，其實並非如此。在不瞭解使用者反饋的情況下，說自己明白使用者的痛點，並且創造產品需求的比比皆是。所以對於專項測試而言，第一步無疑是找痛點。

第一步是建設反饋系統，找痛點。這種反饋包括各種使用者反饋的收集分析，各種專項資料的前段和後端的上報分析。有一些如聽雲、OneAPM，Bugly其實已經有一些這種監控上報的能力，只可惜在使用者反饋收集和分析上，暫時沒見到對應的系統。所以在應用現有系統的基礎上，可能還需要自建。那麼，假如有了這些系統，協助我們知道有多少使用者遇到卡死， 實際Crash率是多少，多少使用者說耗費流量，實際終端耗費流量上報結果是多少。這時，痛點自然就一目瞭然，未來能達成的目標也清晰可見，老闆也許會更加清楚地瞭解問題的嚴重性，從而下定決心改善。

第二步是找底線和目標。我們有了反饋系統，知道了使用者的實際情況，這時我們就需要根據資料讓團隊自上而下地明確底線和目標，從而提升後續團隊合作的效率。目標可以是，Crash率是多少不讓發布，Crash率是多少可以不FIX, 切換介面底線是多少，百分之多少的使用者的流暢度是多少，使用者反饋的卡頓問題從TOP10問題剔除等等。

第三步是解決問題。有痛點有解決痛點的目標，我們就要行動，為了達成目標，解決問題。我們以及我們的平台需要具備如下三個能力：

第四步是回到反饋系統，展示效果。開發，測試忙活了許久，達成了效果，卻沒有展示，那就是錯失了開發與測試形成信任關係閉環的最佳時機。當然也缺失了進一步改進，做就精品的機會。就如我們的上傳圖片，一開始的目標僅僅是提高成功率，然後就是讓頻寬好的傳輸速度更快，再後就是讓網路差的也能在保證成功的基礎上再快點，再想辦法搭救更多的在演唱會時發送不出訊息和圖片的使用者，一路上都是不斷地看資料上報，分析，解決問題，展示效果，再分析，再解決，再展示效果，形成閉環。

工具篇

一般來說，使用者最痛苦的專項問題，通常是最表面和直觀的問題，包括： 
閃退：包括CRASH，系統強殺，ANR，直接影響使用者的使用。 
卡頓：包括丟幀，動畫幀率低，相應使用者操作速度慢，甚至是卡死，但卻沒有觸發ANR或者watchdog timeout。這些給使用者的感覺就是用得不爽，尤其是有對比的時候。

流量大/速度慢：行動裝置 App必然面對流量問題，我們至此為止都會看到月末時候的流量效應，就知道這個的重要性。況且對於小公司來說，更痛的可能還是頻寬，CDN的費用問題。

弱網路相容差：使用者面向的網路情況其實是時好時壞的，但是使用者期待業務能執行成功，哪怕多耗費一點時間。

待機時間短/手機發燙：自IPHONE開始，每個手機都需要“吊鹽水”（使用移動電源）。如果他發現你在耗電熱門排行榜TOP1, 卻一直在後台毫無建樹，相信使用者會好不猶豫地刪掉。

業務專項問題：不同的產品有不同的業務專項問題，單獨說出來是因為前面4個是通用的，請大家不要限制自己的思維。根據業務特質還有一些專項的指標會產生，例如地圖應用定位的準確性，廣告能力推送的準確性，音樂軟體播放的音質，圖片應用圖片的品質。

下面針對這些問題，我們來看下我們有什麼工具可以協助到我們。沒有像BAT這樣的資源投入，但是問題還要解決。下面小V給大家推薦一些跟我們內部的建設思路近似的外部開源工具來協助大家解決問題。（PS: 我只推薦我認為落地成本低產出最高的工具給大家，所以有些工具我不是不知道，而是投入的問題。並且下面我不再說專項指標，我會說是痛點，因為專項指標肯定不只有這些。下面的內容我盡量客觀，但是不排除有一些主觀判斷，畢竟我沒有每個都深入使用。）

Android

IOS

通用

行動裝置 App專項測試