騰訊的專項測試之道

轉自：https://cloud.tencent.com/developer/article/1005945

 

做者簡介：

 

李昶博 騰訊 專項技術測試組長 騰訊專項技術測試組長，專一9年性能測試，人稱「性能哥」，騰訊公司2015年度優秀講師。 經歷PC QQ、手機QQ、Q+桌面、QQ空間、QQ音樂等客戶端項目，多個項目得到了百倍的性能提高。在性能領域，共取得6件國家專利。2012年，QQ性能優化項目團隊獲騰訊公司級重大技術突破獎。

前言

 

做者作了9年的性能測試，一直爲騰訊 SNG 服務，經歷了QQ、QZone、音樂等等項目。騰訊的職業發展通道，各位很熟悉了，這個崗位就是專項技術測試。今年會開拓一個新的領域，叫作音視頻專項測試。

 

騰訊的價值觀就是「以用戶價值爲依歸」，因此用戶滿意，是測試員工作業績舉證的關鍵。你看下圖這個曲線，橫軸是日期，縱軸是投訴量,投訴量是測試員工舉證本身業績的關鍵。

 

上面是我作項目以來給公司帶來的價值，曲線是指數級的，橫軸是時間軸，縱軸是投訴量，半年的時間，10多倍的優化效率。下方這個圖，一發布投訴量上升，如今貼着橫軸，天天0-3個投訴量。

 

一、咱們的專項測試方法論

 

1.1 專項質量體系

 

下圖最左邊的是全流程介入，全部流程都在裏面有本身的方法論。咱們有各類各樣的指標，這是性能測試的關鍵點，不是光測有多長，有多少秒，還得測不少的紅色指標，給全部流程配齊工具。

 

個人部門老大 jeremy，有一個分層測試理論，咱們對全流程都有辦法介入，你們看紅框，各個環節都有。再而後，各類指標和流程。因此性能測試毫不是測一下有多少秒，這個只是時延，紅色的指標是更加專業的東西。

 

最後，咱們有各類工具和手段，如右下角這些，這些工具的名字可能你以爲奇怪，後面會展開介紹。

 

1.2 騰訊專項技術測試員工能力模型

 

騰訊的員工能力模型從實習生到外包都覆蓋了，我在的崗位是專項技術測試，紅色部分值得你們看，可能與其它公司有所不一樣。資深的同事開始閱讀操做性能原碼，甚至實習的同事自然讀過安卓原碼 。

 

要搞定這麼多指標和流程，對員工能力的要求是比較高的。咱們從作手工測試，到自動化，再到使用性能分析工具，甚至看 OS 的源碼來幫開發解決問題，這些技能是逐級提高的，這些領域能夠產生很多的專利。

 

我在招聘的時候看到一些特色，某些實習生在大學期間就開始深刻研究操做系統原理。在職的外包同事也開始作專項自動化測試，這就是團隊競爭力的提高。

 

1.3 速度體驗評測模型

 

方法論裏面有重要的一環，就是需求階段咱們如何介入。天然的就是性能測試標準

 

去項目裏給一些開發發現性能 Bug，首先得有提單的規則，到底多少秒算性能 Bug，這是發佈標準。400毫秒，4秒，進度條在走若是連續四秒走不動用戶以爲焦躁，內部有用戶體驗研究團隊甚至有這樣的研究結論，相同的時長把進度條拉長一點，用戶會以爲走的快。最後這條始終要看到進度在走，流暢度再也不使用 FPS。

 

1.4 技術評審模型

 

上面的方法論裏面還有一條，咱們在開發進入 coding 以前會開展技術評審。

 

全景圖裏講到有一些技術評審流程，初級設計階段概要設計時就會告訴你代碼應該怎麼寫，遇到這些東西所有逐條怎樣與產品經理PK，該不應加進度條，需求是否應該這樣設計，跟開發PK價格設計的方案怎樣，可否作到極簡，每條對應的有須要測試的點。

 

二、咱們的自研平臺工具

 

前文的方法論裏面，講的是如何武裝你的頭腦。如今，我給大家幾把槍，這就是咱們自研的測試平臺和工具。

 

2.1 研發支撐平臺

 

首先咱們能看到每一個版本的 bug 解決狀況，包括性能 bug。而後是每一個 DailyBuild，都能看到各個工具的運行狀況。

 

每個 Bug 的解決率，紅色的是 Bug 不達標細化到每個部門，每個部門解決了沒有，可否發佈在平臺裏。底下有一些性能 Bug 直接列在上面，由於這是作性能測試必須推進的事，很是重要。

 

最後是合流控制，全部的工具必須經過了，纔會給開發員工開啓 SVN 的代碼權限。

 

咱們對全部的工具列在這，這些工具肯定的時候才能合流，每個分支天天均可以收到工具的測試報告，並且當工具只要說不到時候，開發沒有權限作合流，權限是流程自動化分配的。

 

2.2 安裝包質量監控：體積、方法數

 

裏面列舉每個需求測試是否經過，安裝包直接細化到它應該有多大，咱們拉一道紅線過了紅線是不合格的。安裝包的體積給每個部門有配額管理，直接告訴對應的部門經理，大家若是想植入新的特性到QQ裏面，必須得使得安裝包在多少K如下，包括方法數也是很是嚴格的要求。

 

如今爲了讓安裝包不增大，方法數必須得零增加，你要上新功能把之前的水分擠乾淨了功能才能上。安裝包檢查很是細緻地檢查條件，不能夠打包符號表進去，把符號表打包進去原碼就泄露了，你們看裏面的各類檢查項。

 

2.3 靜態代碼掃描

 

靜態代碼掃描，很是低成本地接入，提供了兩個內容咱們能夠發現 Bug。對應的測試報告就是圖片中右上方這樣，各類掃描器分別發現了 Bug。

 

再好比在 SVN 掃描出不少 Bug，而且自研了200多條掃描規則，基於下面你們本身看到的這些掃描器，各類各樣的語言能夠自研1700多條掃描規則天天都在運轉，只要提交了基本當天均可以收到對應的 Bug 單。

 

Q: 規則和性能測試有關係嗎？

A: 有，自研十多條和性能有關的規則，頭文件裏若是實現了變量會致使經典的 Bug 在一晚上之間從三兆增加到十三兆，十兆增加到開發把字符串的定義寫在 STDAFX.H 裏，用靜態代碼掃描的語義分析找到 Bug，Bug 的趨勢和全部 Bug 的類型各類分析列在這裏。

 

2.4 性能自動化測試工具：Perflib & QTA

 

手機掛在本身作的牆上 QTA Wall，天天自動運轉，基於自動化測試底下采集全部性能相關的測試指標。內部把 QTA 叫自動化測試平臺，界面上採集性能數據。

 

2.5 穩定性測試工具：New Monkey

 

New Monkey 穩定性測試，要求每個界面 Monkey 的測試留在界面，因此保證它不要跳出，一旦跳出要可以回來。因此咱們有幾個管理指標，界面的覆蓋率以及界面內部的控件覆蓋率，必定要經過若干個小時內把各類界面的各類控件測齊。

 

各類操做類型的機率，滑動、點擊等機率，包括返回 Home 鍵和菜單鍵都是能夠控制機率，很低的接入成本提供天天的安裝包過來就能夠給你出測試報告。

 

因此要接不少產品，半年內剛上線發現4500個 Bug，到如今每半年接的項目愈來愈多，不只有收斂的趨勢，還能夠找出3000多個 Bug。

 

2.6 卡頓監控：Magnifier

 

Magnifier 卡頓監控，這是看不見界面的監控工具就在後臺裏面給內網的實驗室環境作測試。

 

當你的界面發生卡頓時，默默記下相關的分析數據，最後生成了一個對應的分析報告，直接能夠把卡頓問題解決掉。任何一次隨機發生的卡頓均可以把它優化解決掉，當某一個項目接入 Magnifier 之後，它的投訴量降低，這是一百多倍的優化成果。咱們本身寫了 SPK，填入要測的 App 就能夠監控 APP 的卡頓。

 

2.7 專項質量體系

 

咱們把能力分三層次，採集性能數據能夠度量證實它是否有問題。分析工具和全網的數據上報，各類指標都有對應工具，有一些單元格里存在些信息叉，說明目前沒有這個能力，是值得咱們作而且改進的東西。

 

2.8 自動分析工具破解框架效應

 

2.8.1 框架效應：PK致使效率底下

 

測試和開發怎樣吵架？把你們帶入到環境測那麼多指標是爲何?

 

咱們測試向開發提了一個 Bug，17秒，我看到接 Bug 的開發把個人 Bug 拒絕了，理由是17秒的體驗能夠接受。作開發的每天面對編譯器確定慢，因此他會接受。但用戶不接受，基本的測試標準超過4s，你的進度條得出來，要否則接受不了。

 

以前咱們提性能 BUG 跟開發吵架PK，開發認爲不影響用戶能夠接受。而後咱們去實驗室裏進行證實，證實你作的產品性能真的是不合格，接着就會決策上升交給領導解決，領導看了之後以爲這的確是慢應該仍是要改。

 

接着開發會想你測出的結果十幾秒這是你的測試機性能差，個人機器性能挺好的，認爲測試數據不穩定。開發懟咱們說「你若是不能在我這兒作我怎麼改Bug」，咱們的測試會說「你來個人環境下」。

 

在咱們的環境底下能夠復現還會遇到這樣的問題這個好辦，復現不了怎麼查，最後雙方證實查了一堆問題之後發現這是系統 API 的 Bug，開發說我改不了，這不是個人問題。

 

最後咱們仍是鬆口了，經過了測試，付出的計算量和開銷仍是這麼大，最後發佈到外網的時候用戶體驗仍是照樣投訴。咱們QQ幾個億的用戶，多寫幾兆字節的東西用戶均可以感覺到並投訴了。問題推到了測試這，測試不是實驗室體驗的很好的嗎。

 

像這樣的PK解決不了的問題困擾我不少年，我爲此去研究了社會心理學這本書，你們找到告終論—框架效應。

 

這是人性啊，框架效應有不少的心理學測試頗有意思，能夠找到奇妙的心理學測試案例。

 

作個比較簡單的測試例子，如今的大腦跟着我說的去想，不要去想母老虎，不要想華南虎，不要想東北虎，不要想老虎，這個時候你在想老虎，這就是框架效應。而框架效應真是拉低效率問題的根源。

 

2.8.2 實現定位隨機性能Bug無需重現規律

 

乾貨來了，團隊的共同努力，使得前面的那種低效狀態發生了改變。如今，咱們能作到不須要復現規律，也能夠定位隨機性能 bug。

 

由於咱們提供了全面的分析工具，只要你的隨機性能問題暴露在個人工具下面，就能把問題定位解決。

 

解決方案是這樣，咱們把全部的用戶體驗卡多久，時長多少切割成硬指標，CPU、內存、流量等配上所有的分析工具。自研的IO，流量利用傳統的 TCPDump 能夠抓包。

 

閉環的環境下測試本來承擔度量和驗證，但在個人新體系下革新，將分析環節從測試這邊拿過來，由性能測試團隊提供了分析工具都是自研的，這時一切的一切都變化了。

 

因此呢，從產生問題到發現問題，再到解決、驗證的閉環裏面，測試團隊提高了分析能力。十年前別人可能會說，你能力這麼強，啥時候轉開發啊；如今，開發會說，性能哥幫咱們看下這個 bug 的解決方案吧，甚至有開發同事主動轉來咱們團隊。

 

2.8.3 性能自動化分析能力破解框架效應

 

性能自動化分析實施以後觸發了一個良性循環，咱們提供了帶分析能力的性能自動化測試，上一個版本對應的指標是多少，這個版本是多少，合格仍是不合格，全部的指標咱們列在這裏，並且是帶分析數據的。

 

這些指標若是不達標當即去分析工具裏面找對應的日誌，你能夠分析出來，分析到代碼。如今有了分析能力給你提單，QQ某一個業務邏輯用了20兆的IO，你會怎麼想呢？

 

這個IO太多不合理。若是有一個開發者跳出來，告訴架構師你這樣的設計確定不行，這得改，我很欣慰，之前是開發跟我吵說這個 Bug 不須要改了，又不影響用戶體驗。

 

如今有其它的T3級的資深開發站在我身邊，說這個代碼寫的不行得優化，一會兒測試與開發之間的關係變的親密，咱們只須要作這點，你的代碼寫的好很差，經過框架效應在人性上解決這個問題。

 

好比，年前團隊發現一個性能 bug，提單的時候就說了，QQ的AR紅包致使啓動性能降低。

 

開發的潛意識就是怎麼優化AR紅包，好比年後下架防止長期影響，而不會去想5秒慢不慢，測試能不能復現等等。語境的變換，就打破了心理學框架效應。測試和開發越過吵架的環節，直奔解決問題。

 

2.9 獲取原子級硬指標—基準測試套件工具

 

跟你溝通時直接聊代碼質量怎樣，不聊用戶體驗，這是軟改硬，軟指標是用戶體驗，硬指標就是IO、CPU內存，直接開始寫對應的代碼。優化以後進行測試驗證，代碼從原來的20兆減小到1兆，咱們的性能提高20倍，並且90%的用戶都會用到，確定全網的用戶都會受益。

 

2.9.1 CPU測試

 

CPU 測試，你們確定想到 CPU 佔用率，但你能想過 windows 下 CPU 曲線率嗎？

 

咱們的創新點在於哪裏呢？你看 CPU 佔用率有什麼問題，你忽高忽底有沒有問題。給你一個曲線是否合格很差判斷，除非是持續反對，持續99%怎麼辦，持續50%算不算問題。

 

其它的 App 爲有傳染，操做系統剛啓動有不少的其它程序在加載，那你的性能怎樣保障。安卓 4.X 系列有 Bug 的，你看黑色框裏的最後一行，-98萬，這個 Bug 怎麼回事？

 

明明有開銷但操做系統不可能讓 CUP 佔有率輸出一個負值因此輸出0，那你能測出 Bug 嗎。

 

爲了解決這個問題使用最新的時間片測試，用掉了多少的時間片，能夠直接表徵你的代碼計算量。換句話說運行某一段模塊和代碼以前，我取一下時間片，運行了之後取一個，二者作減法，這是這段代碼用到的時間片，這個時間片咱們拿去和之前的版本作對比超標不合格確定有多的，沒超標是經過的。

 

對應的 CPU 咱們配上分析工具，windows 下的 WPT 就能夠分析 CPU 超標的問題。

 

2.9.2 IO測試

 

IO測試，提一個 Bug 啓動12秒，之前但是6秒，慢了一倍，開發連續三週都沒有找到緣由。咱們只好引入IO分析，忽然發現啓動IO增大三倍多。增加的部分是由於某一個組件致使的，把那個組件去掉性能就還原。

 

咱們分析成本兩個小時，因此咱們是一個60倍的效率提高。咱們自研的分析工具是這樣，這是它輸出的日誌，對應的函數站打出來，能夠直接跟蹤是哪一行代碼。

 

有了它之後開始推廣，全部的各類場景一股腦的清掃乾淨所有的性能問題，30多倍的性能提高，主線程IO清掃到0，這一會兒在其中一個項目中就換得100倍左右的投訴量降低。

 

2.9.3 內存測試

 

內存測試，這是最簡單的就是打開關閉，對應的指標就是從開始是基準，泄露就是這樣算的。

 

首次打開以前在第一次關閉之後有的內存是複用的，緩存是否合理要監測出來。內存分析工具，MAT，咱們自研了分析工具 Finder。

 

對應測試性能自動化腳本這樣寫，復循環，打開關閉，打開關閉，對應的採集性能測試數據，最後給你強大的性能測試報告，並且自帶分析能。memdump 能夠找出內存爲何增加。

 

2.9.4 GC測試

 

GC測試。由於它有一類問題是必定解決不了，用傳統的方式打日誌發現某一行代碼有性能問題，但過一下子測又不是這行代碼又是別的行數爲漂移？

 

我看過操做系統安卓的原碼，能夠把進程的全部線程都休眠，包括你的主線程。這意味着GC發生的瞬間壯大了函數，一個函數的耗時長。從傳統的函數調用上解決問題，絕對解決不了GC致使的性能問題。

 

咱們自研了一個工具 AIIocTrace，每個對象分配了多少字節多少次，這個對象被誰哪一段代碼分配的，能夠直接的找到問題所在解決，把這個複用之後GC能夠減小。

 

2.9.5 掉幀率（流暢度）測試

 

流暢度測試，FPS 不要用，咱們這裏是一秒 60 FPS。若是每一幀時延稍微長一點，用戶會以爲有問題，這時 fps 仍是50。卡頓的總時長除以滑動的總時長，這樣就是百分之零。

 

你們記得掉幀率相比 FPS 這是更加敏感的指標，這是騰訊內部的創新。平均化，性能測試要測不少次，測十次有其中一次是50，那最後得出的結論是59，你告訴項目組合格，就永遠發現不了剛纔的十幀卡頓的問題。

 

咱們只測一次，第一次測合格了，第二次測有性能問題，你趕忙提 Bug，提了 Bug 的問題是什麼，對應的都有分析工具。咱們把卡頓那一瞬間的主線程報上去了，你直接查對應的問題是什麼，直接把卡頓的問題解決掉。

 

在這套生態環境下，咱們在某一個項目裏優化它的性能，甚至超越了 Facebook。

 

2.9.6 流量測試

 

流量測試。若是你使用操做系統安卓提供的 TrafficStats 時，谷歌的官網說over all interfaces，這說明它是有問題的，最基本的指標離不開用戶投訴量，這是其中的一個項目。性能投訴最原始排第一，很高，優化後排名成倍降低，數量也是成倍降低，這是基本的法則。你的項目裏看用戶的投訴。

 

3.2 Crash全網上報

 

再一個，也是最基礎的，Crash 率你要監控起來。

 

Crash 作全網上報，咱們內部有這樣的平臺，大家外部會知道這是騰訊的Bug ，咱們內部用了更高級的版本，用戶體驗好一點。天天發一個日報，跟領導商量好了，這個指標的精品標準有多少，咱們定的很是嚴格，必定要作成精品。

 

3.3 卡頓全網上報

 

卡頓全網上報優化了6倍，由於每次卡頓都上報了對應的函數對站，能夠造成閉環解決。

 

咱們能夠在後臺看到這樣的圖，每個卡頓事件對應的函數站能夠點進去仔細查閱是什麼性能的緣由。

 

當構建這樣的閉環之後，對應的項目投訴量呈百倍的減小，對於你的用戶體驗全網耗時也報上來，這個圖我相信你們第一眼喜歡看最底下的那個，逐個版本明顯的增多。

 

經驗不是看下面小於1秒的用戶體驗，應該看長尾。若是一個用戶之前啓動時長要7秒左右，如今優化到3秒的區間，這是一個超過2倍的性能提高。這是相當重要的。

 

若是你是從1.1s優化到1.0s，用戶的感知不大，因此要看長尾。長尾下面真的是少了一半的用戶，那對咱們過億的產品而言，長尾幾百萬用戶少一半了不得，對應的投訴也是正相關的。

 

3.4 SNG APM：掉幀率

 

掉幀率，若干個版本之後有質的提高，甚至排在其它場景的 TOP3。全部的函數站放在這裏，直接看到哪個函數耗時多少，直接定義在某一個函數致使卡頓的機率最大。

 

3.5 SNG APM：IO、DB、內存

 

咱們作 APM，把IO、數據庫和內存泄露和內存觸頂率的創新指標記錄下來，這些裏面不詳細展開。重複IO，你將一個文件打開再關閉，而後又從新打開讀一遍再關閉，這很顯然是性能問題。

 

咱們常常會發現一個問題，某一個客戶端本地的文被計算三次，啓動時再校驗一遍用以前再算一遍，這爲了肯定要不要更新，這種都是很顯然的性能問題。

 

咱們在數據庫裏複製進去，直接看對應的執行計劃，這對含有全表掃描的咱們認爲這是性能問題，由於全表掃描這是忌諱的問題，咱們有不少的手段能夠解決，不要在用戶的集成上作全表掃描。手機本來性能不必定很好，有貴的也有便宜的，因此這些是個人演講內容。

 

四、總結

 

咱們第一條全流程，每個流程給你們的方法論講了性能UI和進度條，技術評審怎樣跟開發PK，怎樣與產品PK。咱們測了這麼多的指標，最後第二條各類專項指標，第三條就是各類專項分析工具，因此是全流程各類專項指標以及分析定位工具，這三者齊備就是一個成熟的專項測試團隊。