作者：黃聞欣，騰訊高階測試工程師

其實這個話題對於身在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下載，各個安裝包大小的下載失敗率是多少，最終讓老大重視了起來，並且確立了安裝包增量監控的工具和流程。另外很重要的是信任關係，而信任關係不可能一蹴而就，需要有產品痛點，沉澱正面和反面案例，老大重視，自身技術過硬，並且持續相互教育，之後的事情就會更加一帆風順了。最後，總的來說，少點埋怨，調整心態，資料說話，堅持底線。