質量視覺化-讓質量為資料說話演講稿 _美柚孔令雲_20201121

質量視覺化-讓質量為資料說話演講稿

美柚測試總監-孔令雲

建議對照ppt閱讀（連結: https://pan.baidu.com/s/1NSip2sH5v1i6BALS8bYdsg 密碼: h08h）

p1-2 開場

各位測試的小夥伴們，大家上午好，剛才雲層老師講了很多段子，大家有沒有感覺進來的是脫口秀專場啊？講段子的過程中讓大家get到一些測試的點，我覺得非常好，那接下來我們切換到質量保障專場，由我來跟大家分享下美柚質量視覺化管理的相關經驗，希望對大家有一定的幫助或者啟發。

p3 大綱

今天我將從4個方面對我們在質量視覺化方面所做的工作進行分享

1 為什麼要做質量視覺化？

2 質量視覺化的資料有哪些？分別具有什麼意義？

3 質量資料如何採集，以及應用效果展示

4 最後會談一談質量視覺化平臺未來的展望

p4 個人簡介

在正式開始分享前，我先做下自我介紹，我現在在美柚負責測試及質量管理工作。

P5 為什麼要做質量視覺化

接下來我就給大家分享一下我們做質量視覺化平臺的初衷。

p6 美柚App，工具->平臺

隨著業務的不斷髮展，美柚App已經從一個生理期記錄的工具型App成長為涵蓋女性經期、備孕、懷孕、辣媽4個身份，包含資訊、社群、電商、直播等業務在內的一個平臺型App。

p7 美柚系App

同時，除了美柚App以外，我們還形成了主打育兒的柚寶寶、寶寶記App，主打電商的柚子街App，還有返利相關的返還、羊毛省錢等一系列App產品的產品矩陣。

p8 挑戰

在這樣的產品研發背景下，對我們產品質量的保障提出了更多的挑戰，
外部挑戰是：活躍使用者多，裝置碎片化嚴重，尤其是Android裝置，近年來碎片化更加嚴重，top10機型總佔比只有15%， top100也只有67%，iOS相對會好一些， top10佔比達到75%
另外產品根據使用者標籤、推薦演算法、使用者設定等呈現了千人千面的樣式，同時線上存在多個並行的的AB實驗，也增加了測試驗證的成本以及難度，還有一點就是多個App版本並存，需要考慮版本前後相容性的問題

內部挑戰是：美柚App涉及經期、備孕、孕期、育兒不同身份以及社群、資訊、演算法、廣告、電商等不同的業務團隊，研發人員幾百人，各個業務開發節奏、發版週期不盡一致，而且業務耦合性較高，比如廣告會嵌入不同的業務當中，身份與業務也是互相交叉，同時研發資料比較分散，而且App通常以2-3周為一個迭代。

這些都對App質量的保證提出了巨大的挑戰。

p9 測試問題

對於測試內部來講，之前也有很多抱怨，比如：需求經常變更；臨時需求很多；馬上發版了，老闆要加需求；開發提測質量很差；開發提測也比較晚，測試時間被壓縮；對上線沒有資訊，提心吊膽；線上出了問題不知不覺或後知後覺；不知道現場的朋友們是否遇到過類似的問題，有的話，我們可以一起先來看看，是不是可以將問進一步歸類，並且通過資料量化的方式來評估問題，比如：

1） 跟產品相關的問題：

• 迭代週期內，需求變更了多少次？變更率是多少？
• 哪些是臨時需求？臨時需求增加了多少次？
• 老闆需求是否有經過評審確認？是否經常性出現？等等 ### 2） 跟開發相關的問題：
• 是否在提測前有進行自測？
• 開發的task是否規定了提測時間？是否按時提測了？
• 是否確定整合測試時間？整合測試時間佔研發週期比例多少？
  ### 3）跟測試相關的問題：
• 上線的標準是什麼？
• 線上都監控哪些質量相關的指標？
• 線上問題數量，是否符合質量標準？

p10 質量視覺化資料及意義

正是為了解決上述研發過程中跟質量相關或影響質量的問題，我們決定做質量視覺化。

p11 3階段指標

大家可以看到這張圖裡面，我們將整個研發過程分成3個階段，分別是研發-即質量預防階段，測試-即質量保證階段，線上-即質量監控階段，3個階段中間會有兩個卡口，來控制質量，一個是提測節點的卡口，一個是上線節點的卡口，每個卡口都會定義卡口通過放行的質量標準，比如在提測卡口，會重點關注開發提測的及時性以及提測質量，上線卡口呢，則會關注各類bug關閉率情況以及DI收斂趨勢狀況，來評估質量風險。

3個階段中也會制定相應的質量指標，比如在研發階段：

1）針對產品

針對產品，我們會關注產品的需求變更率指標，針對需求的微小調整是允許的，但我們不希望出現頻繁的需求大改以及一些本身不明確的需求就進入開發測試階段，我們遵循的質量原則是“第一次就將正確的事情做正確”，另外，在上線時間確定的情況下，需求的頻繁變更勢必會壓縮開發和測試時間，從而增加質量風險，所以，我們通過統計需求變更率的指標，一方面減少不必要的變更，另一方面和產品一起持續提升需求本身的質量，讓需求邏輯、互動、邊界更加明確，從而減少返工造成的內耗；

2）針對開發

針對開發，我們會關注靜態程式碼掃描通過率的指標，比如我們將sql語句規範中的禁止出現“select *”作為強制的規則，掃描出此類bug，就直接提bug，並與開發同學達成一致，此類問題必須修改；

針對開發，我們還會關注bug日清率的指標，bug不能做到日清，通常有兩種可能，一個是bug多，改不完，一個是bug難，不好改，這又反映出程式碼複雜度高、耦合性高、可讀性差、可維護性差、歷史遺留問題多等一系列更深層次的技術及管理問題；

3）針對測試

我們會關注自動化測試覆蓋率、bug一次修復成功率、App打包的成功率，還有App包大小、啟動時間、閃退、記憶體洩漏、卡頓、cpu記憶體等佔用率、耗電量等專項指標；

4）對於線上

針對線上，我們會關注bug漏測率，也就是線上bug與線下bug的比值，還有App補丁包的更新率、後臺及api上線回滾率、App閃退、卡頓率以及api效能等線上指標。

p12 採集及應用

有了這些質量資料的指標定義以後，接下來我介紹下我們是如何採集這些質量指標資料並進行應用的。

p13 資料來源及應用

我們的資料來源包括研發管理平臺、效能檢測sdk、第三方監控平臺（如通過bugly、oppo運營後臺等獲取閃退、卡頓、ANR等指標資料）、elk日誌（獲取線上api響應時間等指標資料）、持續整合系統（獲取App打包、上線回滾等指標資料）、自動化測試系統（獲取自動化測試覆蓋率，case測試通過率等指標資料）。

p14 指標資料具體來源

這張圖展示了質量資料的具體來源，不同顏色代表資料來源於不同的資料來源。

比如測試階段的App專項效能指標，有部分就來自於效能測試sdk，我們通過執行App端的UI遍歷測試程式，自動去檢測App執行過程中的閃退、卡頓問題，如果發現問題，就通過資料服務介面上報bug到研發管理平臺，並將資料儲存在資料庫中，同時ETL服務會定時同步研發管理平臺的bug資料進行儲存，並在視覺化平臺中做彙總、統計及展示應用。

p15 需求管理

接下來我以部分指標為例，分享下我們為了採集這些指標，需要具體做哪些工作：
首先是需求管理，所有需求，不管是業務需求還是技術需求，都需要記錄在需求管理系統中，同時比較重要的業務、技術需求會有需求稽核的過程，確保需求的質量。

p16 需求拆分task

有了需求之後，開發同學分解需求並拆分成task，預估開發時間，這裡面的結束時間將作為提測的時間節點。

p17 需求變更

如果需求有變更，會記錄在系統裡面，我們需求變更率的統計就是以此為依據進行統計。

p18 測試確認

剛才在結束task的時候有提到，測試人員將會以task結束的時間點作為提測的時間點，如果到時間點沒有提測，那麼測試人員就會將此任務標記為“未及時提測”，對於已提測的task，測試人員會通過冒煙測試驗證該task是否測試通過，同樣標記測試結果，這樣，每一個task就得到了兩個維度的結果，一個是是否及時提測，另一個是測試是否通過

p19 迭代報表

再來看報表，每一天的任務結果我們通過累加，就可以得到當天的提測及時率和通過率資料，這個就可以作為衡量開發質量、進度的很重要的依據；另外，還有一個衡量產品質量變化趨勢的值就是DI（defect index，即缺陷指數），每一個嚴重級的缺陷會定義一個權重，各個嚴重級bug權重和數量之和即為DI，如圖，這是一個迭代週期內，DI的變化趨勢，先增加後減少，從圖中能看出，質量是逐步趨於穩定的。

p20 閱讀報表

那麼每個月，我們會出一個業務報表，包含產品需求變更率的情況、開發提測及時率、通過率情況，還有bug日清率以及DI指數等資訊，各個業務可以橫向對比。

p21 線上bug

針對測試，很重要的一個衡量測試成效的指標就是漏測率，漏測率跟線上bug直接相關，所以就需要先登記線上bug。

p22 線上bug列表

登記的所有線上bug，都會彙總線上上bug列表欄中。

p23 報表

最後，我們會以月、年等維度統計出各個業務的漏測率資料，作為該業務測試團隊測試質量評價的重要參考。

p24

剛才介紹了一個業務專案從需求到開發到測試最後上線整個過程中質量相關指標的採集及應用，在這個過程當中還涉及到一些自動化測試的工作以及自動化相關的指標資料的採集及應用。

針對App的效能自動化，我們通過Monkey以及UI遍歷程式（已開源在GitHub，大家有興趣可以下載，地址：https://github.com/MeetYouDevs/UIWalker） ，在UI遍歷自動化測試過程中，我們會自動切換使用者身份、AB實驗等，目前UI遍歷的頁面覆蓋率能達到80%左右，測試過程中我們會利用效能檢測sdk自動檢測crash、記憶體洩漏、ANR、卡頓以及主執行緒非法呼叫的問題，並通過介面將問題日誌上報效能資料處理服務，這個服務對問題日誌進行分析、過濾去重、聚合等操作後，將確認是bug的通過呼叫bug管理系統的介面建立bug，同時，對開發標記為已修復，並3次未再復現的bug自動進行關閉。

p25-27

這幾個分別是自動提單上報的crash、ANR、主執行緒非法呼叫的bug。

p28

這一張是自動關閉bug的示例，可以看到建立bug的“變更人”是我們的自動化測試程式“exserver”，bug被開發同學將狀態修改為“已解決”以後，經程式自動驗證bug已被解決，凌晨1:05，該bug給關閉，可以看到變更人是“exserver_auto_close"

p29

上面這張圖是自動化測試bug每日的關閉率情況，下面這張圖是版本維度的bug關閉率，通常在一個版本迭代中，App的效能問題bug關閉率需要達到90%以上，我們才允許發版，可以看到從779版本到782版本，每個版本的關閉率均在90%以上，783是正在開發中的版本，目前關閉率還比較低，通過在測試環境的這些測試以及卡口約束，我們線上的App crash率維持在一個相對較低的水準。

p30 卡頓

這張圖是自動化測試檢測出來的卡頓資訊列表，按卡頓次數做了排序，開啟詳情可以看到卡頓的具體資訊。

p31

前面我分享了App效能自動化測試以及資料採集的過程，接下來分享幾個線上資料監控的具體例子，這張圖是線上95分位api效能，每天我們都會從elk中將前一日的訪問日誌撈出來做分析，對於95分位超過300ms的介面，針對性分析原因，並配合開發一同優化。

p32

這兩張圖是美柚App Android版線上卡頓率、ANR從2019年1月1號截止到現在的趨勢圖，可以看到卡頓率下降非常明顯，目前穩定在一個非常低的水平上，ANR中間雖有波動，但總體還是下降的一個趨勢。

p33

這張圖是我們視覺化平臺的看板頁面，使用者也可以定製顯示自己關注的指標到看板。

p34 績效

這張圖是開發人員的績效統計圖表，包括開發人員的提測及時率、通過率，bug日清率，線上線下bug數等等，實際上，這些指標一開始是我們測試對開發的一些要求，我們認為只有開發自身重視質量，提測質量有一定保證，整個產品的質量才能得到更好的保障，後來呢，這些指標逐漸被各各個開發小組接納，作為開發同學績效考核指標，寫入了okr裡面。

p35-p36 質量視覺化平臺未來展望

最後，我介紹一下我們質量視覺化平臺未來的展望，目前，我們正處於由1.0向2.0升級的階段，1.0階段是我們測試自己建設，包括質量指標的定義、質量資料的採集以及應用推廣等均由測試自己建設，隨著質量視覺化對於質量提升效果的顯現以及對於研發績效考核的幫助，產品和開發同學也逐漸會提出一些需求給我們，來共同完善質量視覺化平臺，比如產品同學提出的需求有：業務需求評審通過率；開發同學提出的需求有：開發工時統計、人均bug數統計等等。除此之外，2.0版本中還將增加基於線上監控資料的智慧預警功能，更有效的對潛在的質量風險進行識別並採取相應的風險防範措施。

p37 slogon

我們質量視覺化平臺的slogon是：讓資料為質量說話，捍衛產品的質量以及使用者體驗，提升研發質量以及研發效率。

p38 個人微信及專欄

最最後面，打個廣告，我個人的微訊號，大家可以掃碼關注交流，同時我的技術專欄《介面測試之程式碼例項21講》（https://www.nowcoder.com/tutorial/10032/index） 11月初在牛客網正式上線，隨專欄開源了5個GitHub專案，包含介面示例的程式碼、介面自動化測試框架程式碼以及一個簡易電商網站的程式碼，我也列出了有專欄的地址，大家有興趣可以閱覽，也歡迎大家轉發。

大家的印象裡，可能覺得測試總監是不是就不做具體的技術了，實際上，我的主要工作可以用3個詞6個字概括，就是“技術”、“流程”、“團隊”，技術在我的工作裡面永遠是排在第一位的。

我的分享完畢，感謝聆聽！