移動應用專項測試要怎麼作

做者：黃聞欣，騰訊高級測試工程師

其實這個話題對於身在BAT的我來講，是個難題。由於BAT對測試自己的投入力度，在行業內是走在前面的。一直在這個環境成長，可能會不理解其餘小團隊的痛。可是我意識到，必須寫一篇文章，一方面是由於最近確實接觸了一些騰訊系公司，瞭解了他們的測試現狀，我以爲須要有所總結； 另外一方面是但願本身透過這個文章有更進一步的思考，最終能給出一些能夠真正幫助到測試行業內其餘團隊的意見。

心理篇

我在《手Q專項測試最佳實踐》中曾經提過，專項測試有資源類性能、交互類性能、穩定性、兼容性和安全性等等。但仔細想一想，對於一個小團隊，一個創業或創業初成的團隊須要管那麼多嗎？不用，只要心中有概念， 並有對應保底措施便可。對於小團隊來講，更重要的應該是打痛點，由於痛點是產品發展的最大障礙，具有極高的性價比。可是什麼是痛點呢？表面上不少產品都知道本身的痛點，其實並不是如此。在不瞭解用戶反饋的狀況下，說本身明白用戶的痛點，而且創造產品需求的比比皆是。因此對於專項測試而言，第一步無疑是找痛點。

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

第二步是找底線和目標。咱們有了反饋系統，知道了用戶的實際狀況，這時咱們就須要根據數據讓團隊自上而下地明確底線和目標，從而提高後續團隊合做的效率。目標能夠是，Crash率是多少不讓發佈，Crash率是多少能夠不FIX, 切換界面底線是多少，百分之多少的用戶的流暢度是多少，用戶反饋的卡頓問題從TOP10問題剔除等等。

第三步是解決問題。有痛點有解決痛點的目標，咱們就要行動，爲了達成目標，解決問題。咱們以及咱們的平臺須要具有以下三個能力：

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

工具篇

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

流量大/速度慢：移動應用必然面對流量問題，咱們至此爲止都會看到月末時候的流量效應，就知道這個的重要性。何況對於小公司來講，更痛的可能仍是帶寬，CDN的費用問題。

弱網絡兼容差：用戶面向的網絡狀況實際上是時好時壞的，可是用戶期待業務能執行成功，哪怕多耗費一點時間。

待機時間短/手機發燙：自IPHONE開始，每一個手機都須要「吊鹽水」（使用移動電源）。若是他發現你在耗電排行榜TOP1, 卻一直在後臺毫無建樹，相信用戶會好不猶豫地刪掉。

業務專項問題：不一樣的產品有不一樣的業務專項問題，單獨說出來是由於前面4個是通用的，請你們不要限制本身的思惟。根據業務特質還有一些專項的指標會產生，例如地圖應用定位的準確性，廣告能力推送的準確性，音樂軟件播放的音質，圖片應用圖片的質量。

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

Android

IOS

通用

結局篇

跟不少不小不大的互聯網公司都交流過，測試的人力投入是很是有限的。固然更不可能有成建制的專項測試團隊。因此正如前面說起的，找業務的痛點很重要，不求大而全。既然是痛點，就容易得到至上而下的支持，若是沒有支持，就給信息給數據來講服，而後定底線定目標讓事情持續有效。手Q的安裝包就是個典型的案例，看到安裝包一個版本就大10M，其實沒有感受到任何的痛和擔憂，咱們用數聽說話，多少用戶用3G下載，各個安裝包大小的下載失敗率是多少，最終讓老大重視了起來，而且確立了安裝包增量監控的工具和流程。另外很重要的是信任關係，而信任關係不可能一蹴而就，須要有產品痛點，沉澱正面和反面案例，老大重視，自身技術過硬，而且持續相互教育，以後的事情就會更加一路順風了。最後，總的來講，少點埋怨，調整心態，數聽說話，堅持底線。