質量體系建設之路的分分合合

前言

賈鵬博是聲網的測試開發工程師，負責聲網 SDK 的測試以及建立健全相關的測試工具。待過金融公司，看的了股票，算的了傭金，有內容分發、電商、小遊戲相關測試經曆。

本文基於賈鵬博在「聲網開發者創業講堂• 第三期丨創業初期如何保障產品質量」活動中分享內容二次整理。關注公眾號「聲網開發者」，回複關鍵詞「JT0611」即可下載活動相關 PPT 資料。

01 質量體系建設的背景

首先，由圖 1 可知，從需求創建，到評估、建立、需求的提測分發，再到最後的測試，需求的工作流是非常長的，我們需要建設和跟踪工作流，以便更好地保障業務運行。其次，數據記錄用於複盤、改進和增效。因為質量體系建設涵蓋了方方面面，其中也包括一些文檔的落地，隨著發版以及測試任務的增加，各種各樣的版本以及測試數據都會有相應的積累，在這個過程中要進行數據分析，獲取數據並分析複盤、改進，以促進質量體系的建設。

最後，建設質量體系是為了得到高質量的產品。從研發自測、提測階段的推進、需求標准對齊、制定測試規範、Jira 信息可視化與追踪，以及其他方方面面的跟進。我們所做的一切服務都是為了版本的上線，給用戶提供高質量、高可靠的產品和服務。

■圖 1

圖 2 綜合展示了建立質量體系之前和現在，質量程度、線上問題、測試問題的閉環、過程的改進、用例增加以及如何協調手工 case 和自動化 case 。通過“以前”的圖，很難得出相關的結論，只有建立體系進行不斷的分析，才會得相應的結論或者指標來改進。由圖 2 可知“以前”是如何做的，現在通過建立體系能達到哪些效果，以及實現體系需要做的舉措。這些舉措是方方面面的，不僅需要落地，有的可能還要不斷對齊和複盤。

■圖 2

02 方法論

1、小步快跑

小步快跑用來快速上線，有時需求可能會非常緊急，只是簡單地了解目的，與開發或者產品經理對接後就要開始工作了，測試用例可能都來不及維護和更新。而且因為是快速增長階段，可能還需要通過並行。

所謂的並行如圖 3 所示，多個人有 N 個需求，這 N 個需求由不同的人跟踪，但是這些需求都是新增的，只需要添加並快速上線就可以了。這一時期的特點是，需求是新增的，只測試自己負責的這一部分即可，其他的需求跟自己無關，也不需要回歸，直接補充上線就可以。需要注意的是，因為只注重快速上線，所以只要保證一定的質量即可，對於細節的把控是不到比特的。

■圖 3

2、穩中求“勝”的高質量

當公司處於平和期時注重質量，需要多方面的考量。一個需求在初步建立時可能要拆分成個 N 個子需求，這些子需求由不同的人負責測試。另外，在測試的過程中需要不斷地交互，通過不同的測試點以及覆蓋不同的測試內容來實現交付，整個測試過程可能是比較長的，因為需要多方面驗證，包括手工測試、自動化測試、性能測試、實驗室測試等，用綜合測試結果判定該版本有沒有回退或者質量問題等。如果整體是良好的狀態，就可以發布。

這種穩中求“勝”的方法更多適用於質量要求嚴格的公司，比如銀行，因為其對於錢財的把控嚴格，所以它的持續周期是非常長的，對測試過程中的質量問題非常關注，需要不同的人交叉以及通過交換測試內容和測試用例來完成相關的測試任務，是該時期的特點。

3、規範流程的文檔派

此時公司仍處於平和期，在經曆小步快跑以及長時間的測試需求迭代的過程中，已經積累了各種各樣的經驗，這些經驗需要轉化成流程的提昇以及功能的改進，如何發現更多的問題是對於需求梳理以及數據記錄能力的考驗，具體如圖 4 所示：

■圖4

從需求開始設計測試用例，測試用例可能包括 Xmind 和 Excel，接下來開發 review 相關的 case，此時可能要站在代碼的設計角度以及產品使用和 QA 的角度改善 case，修改以達到上線要求。當然，在上線過程中可能會遇到各種問題，這些問題需要覆蓋住功能、性能，並且要求在不斷迭代的過程中（不管是測試環境，還是預發布環境、線上環境等），功能都是正常的，沒有回退問題產生。這個階段的主要特點就是從需求開始到結束都需要追踪、歸納和總結。同時，需要對文檔進行梳理並注意其中的規範，避免重複的文檔等。

■圖 5

圖 5 記錄了當前版本的 bug 數以及占比，不同團隊的 bug 數能够一定程度反映其解决問題的時間，有助於歸納測試進度，以及把控住 highlight 任務，從而推動功能的如期上線。圖 6 記錄了問題解决時長以及解决問題解决時長方差。其實文檔派記錄的文檔數據都是為了更好地推進測試進度，保證及時或實時上線。

■圖 6

4、百花爭豔的工具流

目前已經推出各種測試工具，可根據不同的業務來使用對應的測試工具以提高效能，及時地交付測試任務。圖 7 所示為測試工具的八個分類，這只是簡單的列舉，市面上的測試工具遠遠不止這些。

■圖 7

5、精益求精的開發流

此時公司可能已經處於成熟期了，當前的工具流已經完全不能支撐測試任務，需要針對業務借助工具流進行開發，比如 STF（Smartphone Test Farm）以及騰訊的 Bugly，都是為了貼合自身的業務而進行的二次開發。當然，現在也有很多的工具流，包括 sonic、httprunner 等，它們涉及方方面面，包括接口自動化性能、性能測試等，這些都可以貼合業務進行二次開發。這個時期的主要特點是，對代碼要求比較高，需要充分理解業務，並通過代碼能力滿足業務的需求。

圖 8 所示為我們公司對於當前工具進行的二次開發以及相關的實踐，我會在後面進行簡單的闡述。

■圖 8

03 落地和實踐

1、SDK 崩潰數據的實時高效閉環處理

我們公司主要測試的是 SDK，相對於各大市場上的 App 可能一些差別，它的落地實踐主要是 SDK 崩潰數據的實時高效閉環處理。市面上有一些這樣的工具的，比如 Bugly，但是我們發現 Bugly 在處理 SDK 上報崩潰的過程中還有一些不足，比如 SDK 發生崩潰了，但是 Bugly 並沒有監控到。所以我們對於這方面進行了一些改進，整體的過程如圖 9 所示，我們的 SDK 是為客戶服務的，嵌在客戶的 App 中，它的整個閉環為，程序正常執行來監控是否發生 crash，然後通過監控 crash 狀態找到守護進程感知捕獲，接下來生成 dmp 文件並提交到崩潰搜集器，以解析相關的系統，此時會有一些相關信息入庫，最後對信息進行整合並發給用戶。

■圖 9

圖 10 展示了對 SDK 崩潰數據的實時高效閉環處理，首先提取到堆棧關鍵信息，然後根據哈希值進行判斷，若相同版本 Hash 值存在，則關聯相關 JIRA。這部分的處理邏輯就是在取得崩潰日志後將其提供給相關的開發人員及時進行處理。

■圖 10

圖 11 展示了在收集日志並通過解析系統編譯獲取 crash 之後，在 JIRA 中展示和指派。首先獲取崩潰信息，然後上報給 JIRA 並附帶一些關鍵信息，同時通知相關的開發人員，使其進行修複。簡單來說，SDK 崩潰數據的實時高效閉環處理就是在 SDK 嵌入 App 之後，判斷是否是由我們的 SDK 發生的 crash，因為有一些可能是客戶 App 本身的crash，我們會對這一部分進行判斷，若是 SDK 的 crash 會直接上報然後通過編譯系統解析並上報給 JIRA，在這個過程中會提交給相關的開發人員進行處理，完成整個鏈路。

■圖 11

2、電路插拔

這部分主要介紹耳機插拔的試驗，因為我們的 SDK 可能在測試過程中需要不斷地插拔耳機。圖 12 是對電路圖的簡化，簡單來說就是在主板線路，把耳機中的線跟電路圖中的線進行了焊接。

原電路圖很複雜，學過集成電路的同學應該知道，其中有各種各樣的節點，對這些點進行試驗，結合電路圖的原理，通過程序控制電路就能達到插拔耳機的作用。我們在以前測試插拔耳機的過程中耗費的人力很長，保守估計一個人 3 天全部 online 在上面才可以完成所有的 case。但是在完成這個電路圖之後，只需要一個小時就能完成相關所有的 case。在電路圖上我們會對相關的數據展示（包括網頁數據的分析，以及性能指標的裁剪等）進行整合，相當於對於耳機插拔的產品化。

■圖 12

3、HENGE測試平臺

圖 13 是基於 STF 二次開發的雲平臺，它的主要鏈路就是動態獲取測試包得到其信息，然後動態下發給雲真機進行測試，接著把相關的測試結果提交給相關的測試人員，方便他們獲得測試報告以便得出測試結論。圖中主要展示了我們測試的 App 下發流程後裝包運行，運行完成之後查看報告，當然其中包括 crash 日志以及相關的功能。

■圖 13

4、Moonlight

我們公司的產品 Moonlight 已經開源（https://github.com/AgoraIO-Community/MoonLight）了，它是一個 SDK，用於自動化性能數據的采集，感興趣的同學可以查看相關代碼。對它進行的一些性能測試顯示，它能以較低的資源消耗獲取到非常准確的 CPU、memory 等系統信息。

04 體系圖

從為什麼做質量體系，再到五個時期可能會采取的不同的策略，以及在策略過程中可能誕生的各種的小工具都是服務於我們提供的高質量的產品，這是最後的唯一指標。所有的測試任務，包括質量體系的建設都是為了維護當前的業務發展。因此不管使用哪些策略，不管是文檔派、工具流，還是二次開發，所有的節點或者任務事件，都是服務於自己的業務體系。

圖 14 展示了一個質量體系，包括需求階段、開發階段、代碼融入、測試階段、上線前、交付、質量追踪，這是從 0 到 1 的裏程碑，因為你能看到需求管理開發過程中的規範代碼准入原則、測試的各種測試指標項、上線前的各種對齊、交付之後的報告總結複盤，一直到最終上線之後對於整個數據的監控，完成了一個基本的質量體系圖。

■圖 14

06 問答環節

1、怎麼做覆蓋率檢查？

覆蓋率檢查是使用了工具 bullseye，這個工具在 CI 編輯過程中會生成一個 Cov 文件，運行相關 case 的 Cov 文件中對應模塊的開發的代碼的覆蓋率會發生改變，最後所有模塊運行以後根據標准去進行對應和比對就可以。

2、在創業公司中 CI/CD 主要是放到哪一個階段呢？

對創業可能要放到提測階段，我們主要負責 CI 的出包，因為 SDK 編譯出包之後，會直接生成相關的 zip 包並觸發編譯相關的 App，這些都是我們的測試工具。因為聲網主要是做 SDK 測試，所以我們會把我們的 SDK 嵌入到自研開發的測試 App 中用於測試任務。當然我們公司將其分為兩套，開發部門有相關的 UT，在提交代碼之後會有相關的代碼檢查，如果 UT 不過是無法提交的，這是開發部分；測試部分主要用於 工具出包，因為我們公司 SDK 測試的特殊性，如果是市面上大多數工不需要內嵌sdk都是自己功能開發的 app，一般分成兩部分。在開發的提交代碼之後，有的人可能會進行 test case，在測試環境之前可能還有備份測試環境，在這個環境中會有相關的測試任務。把相關的測試 test case 跑通，達到一定的通過率，然後才會提交成功，進行下一步測試。當然，要看你是否有精力去維護兩套環境，因為這個環境是在代碼提測之前，而且相關的要求也會高一點。如果說開發的代碼 UT 過了，然後發布到測試環境運行 test case，case 可能會分兩種，一個是新增的功能，這個是過不了的，因為根本就沒有新增功能。另一個是已有的舊功能，可能需要打 tag 來判斷是否要進行測試用例的覆蓋，如果是舊功能，可以通過設定通用率來判斷是否要打回，所以需要根據不同的業務類型進行調整。

3、端到端性能測試時怎麼測？有工具嗎？埋點數據不准怎麼辦？

端到端的性能測試工具有很多，test home 中好像有人分享了安卓方面的工具，大家可以去看一下。那個工具是開源的，安裝之後在運行相關的 App 時，它會將相關的數據進行展示。另一個是開源工具使 tidevice，它是通過 Python 調取的 Apple 的 API 來獲取數據。如果是 iOS 或 Mac 可以用 moonlight，Windows 本身也有一些性能工具能直接監控。如果想嘗試二次開發，iOS 就自己調私有 api，安卓就是 adb 調用。蘋果官方還有 instrument，iOS 和 Mac 都是通過 instrument 的調用獲取新的數據。

對於埋點不准這個問題，其實埋點更多的是一個開發任務，因為開發是在代碼中進行了相關任務的日志寫入，我認為應該是開發去埋這些點，然後去它會有一系列它的一些調用鏈。我們的任務就是通過理解開發的需求，然後拿到這些數據來驗證它的埋點是否正確。

活動預告

7 月 16 日下午，聲網開發者創業講堂 • 第 4 期將以「創業團隊如何保障產品業務的安全合規？」為題，邀請環信、遊族、白山雲三家優秀企業的技術專家為大家帶來精彩的分享。

心動不如行動，趕快掃描二維碼報名吧！