網易新聞推薦業務測試質效提升

　　 一 背景

　　隨著推薦策略不斷地迭代更新，網易新聞的內容形態逐漸增加，內容特徵更加精細化，使用者特徵不斷豐富，對應的推薦策略也愈加複雜，保障線上推薦服務的穩定性成為質量保障團隊工作的重要組成部分。透過逐步摸索、探索，質量保障團隊根據新聞推薦系統業務的特點，總結出一套較為適應新聞推薦系統業務迭代的測試方法，從而提高業務測試的質量與效率。

　　本文大致闡述當前新聞推薦業務測試主要方案，主要有：

　　新聞推薦系統的基本特點及測試難點；

　　為應對上述業務測試難點，測試團隊的應對方案；

　　為提高業務測試效率做的應對方案；

　　業務測試未來努力方向。

　　 二 新聞推薦業務測試難點

　　1 推薦整條鏈路環節多

　　一條使用者請求透過客戶端達到推薦系統後，首先召回模組需要根據使用者的畫像、行為等結合相關召回策略召回內容數篇，再經過一系列的過濾規則篩選出可以推薦的內容，接著這些文章經過粗排、精排打分得到各自分數，最後各內容分數結合重排策略選出本次請求最終的推薦結果。每一個環節推薦系統會根據使用者特徵針對各類內容特徵做多種策略調整，各環節的策略都會影響到最後的推薦結果。測試時如果只在最後結果中判斷往往無法驗證中間環節策略的有效性。　　

　　2 使用者畫像特徵複雜

　　推薦策略根據不同使用者特徵維度制定不同的推薦策略，使用者畫像特徵多種多樣，比如基本的使用者資訊（使用者基本資訊等），基於使用者點選、瀏覽等多種行為劃分不同使用者活躍度、使用者偏好等特徵，在做業務測試時，根據策略針對的具體使用者受眾，選取符合條件的使用者畫像進行校驗。

　　3 內容形態多樣，內容特徵多

　　新聞內容的形式除了普通的圖文和影片型別，還有各類UGC內容形式，不同的文章樣式對應的不同推薦策略；除了內容形態，透過模型識別、人工打標等多種方式賦予文章不同維度的特徵屬性，推薦策略會根據不同的文章特徵制定不同的推薦策略。

　　4 上線迭代週期短速度快

　　由於為純服務端工程，需求大多不需跟隨客戶端大版本，平均周需求數10+，產品迭代速度快，平均測試時間1.5h/需求，測試時間短。

　　 三 質量保障改進

　　針對推薦業務測試的難點，結合業務測試現狀，具體問題具體分析，在業務測試、效能測試上分別做了不同維度的測試方法改進，以求提高測試質量。

　　1 業務測試改進

　　1.1 增加各環節日誌輸出

　　在業務測試中，需求可能是對召回、過濾、排序等任意中間環節進行策略調整，其邏輯實現的結果無法直觀的在最後推薦結果中展示，可能存在：

　　對於一些文章提權、降權、截斷的邏輯無法測試實際是否符合邏輯；

　　問題定位只能依賴開發同學debug除錯，效率較低；

　　針對這類問題，在需要精細驗證的環節增加日誌，根據每個環節的邏輯特性增加詳細日誌，規定日誌的統一格式，便於新功能後續解析。　　

　　1.2 測試可控化

　　測試文章召回可控制

　　推薦系統各環節邏輯都是針對本次請求召回的內容做處理，要驗證後續邏輯是否符合預期，召回內容匹配測試需求便極為重要。而召回模組是根據使用者特徵及其本次請求引數來做內容的召回，召回的內容量較大，且召回邏輯複雜，許多測試場景需要經過多次構造請求才可觸發，測試同學無法自行構造召回的內容資料，不能控制測試資料來源，在驗證一些特定內容推薦處理邏輯中，如果召回中沒有此類文章，便無法驗證後續邏輯是否符合。

　　所以針對這一問題，在召回中增加自定義文章編輯，測試同學可以將需要驗證的文章透過配置，寫入本次請求中，從而驗證對應邏輯。　　

　　測試使用者特徵可控制

　　在使用者畫像方面，可以透過重寫特徵構造測試所需的使用者模型。　　

　　在使用者行為上，可以透過向redis中寫入推薦歷史、點選歷史等，模擬使用者行為，構造所需的使用者請求。　　

　　1.3 控制變數

　　由於推薦各環節策略較多，同篇文章可能會命中多種處理邏輯，在這種情況下就很難確定是需要測試的邏輯是否真正生效。比如過濾、權重修改等環節，同篇文章可以命中同一模組多種邏輯，很難確定被測邏輯是否生效。

　　針對這一情況，將過濾器等需要控制變數的邏輯在測試過程中調整為配置化。例如過濾環節有過濾器A、B、C等，增加過濾邏輯黑名單、白名單，黑名單可以做到不走某一指定過濾器（例如不走A、B過濾器），白名單可以做到只走某一指定過濾器（例如只走C過濾器）。本條請求是否走哪條邏輯測試QA可以自己指定，這樣就可以準確將被測的邏輯分離出來，驗證其是否符合預期。

　　1.4 內容強推

　　由於推薦結果不固定，在與後臺客戶端聯調的時候，如果只依靠正常推薦的結果，會存在前端同學想驗證的內容形態推不出的情況，所以針對這一情況，做了內容結果強推，只需要配置指定文章和展示樣式，就可以在配置的賬號中推出，並整合到測試平臺中，前端同學可自己操作，不需要費時費力刷資料。　　

　　2 效能測試改進

　　2.1 壓測資料改造

　　最初的效能測試，採用的是各引數自行構造後隨機組合構成壓測請求，以便於覆蓋多種業務場景。但真正使用一段時間後，發現對場景、各類使用者的覆蓋能力還是存在較大缺陷，而且靈活度低，新增引數、版本號更新都需要將配置檔案進行同步更新。所以後續在壓測請求的構建上採用引入線上真實流量，提高了測試場景的覆蓋率，針對一些特定少數使用者群體的策略，針對性構造壓測資料。　　

　　2.2 推薦質效平臺-效能測試平臺落地

　　之前的效能測試在日常應用中主要存在以下問題：

　　需要對所有使用NPT平臺的人員進行統一培訓，每次壓測都需要建立新的壓測任務，一段時間不用可能會出現一些誤操作導致原始指令碼發生改動，操作缺乏便利性；

　　NPT記錄的壓測資料，只有一些基本的效能資料，推薦測試所需的（如召回數、過濾數等）需要額外記錄；

　　每個欄目效能測試是否測過，沒有衡量標準，壓測時非測試負責人無法確定效能資料是否符合預期。

　　針對這些問題推薦質效平臺-效能測試平臺結合推薦效能測試的基本需求，將NPT壓測觸發與哨兵平臺資料進行整合，不同欄目透過配置將任務id對映到NPT對應任務，並將壓測介面所需引數、效能衡量標準配置化。壓測時，透過壓測平臺呼叫NPT介面實現自動觸發。完成壓測後，自動從哨兵中獲取對應欄目配置的監控項，並將所有壓測資料儲存至資料庫中。同時，將本次壓測的所有監控資料格式化返回到前端進行展示，並將資料是否在各欄目規定閾值內予以標註。　　

　　平臺落地使用後，效果如下：

　　操作便利化。只需要輸入必要項（伺服器IP、時間、併發數）就可以進行對應欄目的效能測試。　　

　　各個服務效能測試標準化、個性化。在資料收集上，採用配置化，可以根據每個欄目的具體需求選擇需要收集的哨兵監控項及判斷閾值，制定效能測試透過的標準閾值，壓測結束後自動生成測試報告，對於超過標準的資料予以提醒，開發自測時也可以直接檢視效能資料是否測試透過。　　

　　效能測試報告輸出更具靈活性。對於一些超過標準的壓測資料可以根據具體情況修改其是否符合預期。壓測過程中出現的異常，判斷是否符合預期，可透過平臺進行忽略或者標註。　　

　　效能測試資料對比視覺化。自動將本次壓測配置的監控項資料寫入資料庫中，檢視時生成生成圖示，便於查詢及對比。　　

　　效能測試結果和需求單打通。針對具體需求的效能測試不再需要手動記錄效能測試結果與資料，壓測透過後可直接同步至對應JIRA，便於檢視及後續覆盤。　　

　　 四 效能提升

　　除了對業務測試質量進行提升，效率的提升也尤為關鍵。對此質量保障團隊針對測試效率痛點做出切實有效的改進。

　　1 測試用例配置化、自動化

　　由於推薦需求的特殊性，大多數策略是透過ab實驗的模式進行，且有些ab實驗之間是互斥的，測試中頻繁在崑崙平臺修改實驗配置低效且易出錯；引擎遷移至諾亞容器以後，介面地址不再為以前固定的物理機地址，而是不固定例項IP，現有測試架構不支援對不同IP進行快速響應測試，要修改測試程式碼，同時也無法靈活隨客戶端版本升級修改版本號等其他引數等；針對一系列的測試問題，對現有構建引數方式進行改造，部分變動類引數例如version等提取出，不再寫死在程式碼中，改造為可配置化，實現引數可配置化，對於ab實驗的配置上，也和開發商議對測試介面進行改造，新增引數，透過引數直接將需要驗證、排除的實驗配置，輸出測試結果，極大的提高了測試效率，縮短了測試時間。　　

　　2 需求管理集中化

　　推薦系統的每個需求正式上線前，一般需要線上上進行ab測試，資料符合全量條件後，除了工程程式碼需要全量，測試case也相應需要加入到迴歸case中，但由於需求量大，很容易在增加全量回歸case時遺漏部分需求，所以為使需求管理更明確，避免漏掉某些全量需求，結合推薦測試現狀在測試中增加需求管理，清晰直觀的展示目前case現狀。　　

　　3 提供自測工具，釋放測試人力

　　對於部分模組測試，每週需求迭代較多，QA人力緊張，比如召回模組，之前平均每週的需求10+，天均需求達到8+，且存在冒煙case 跑不通的提測情況，反覆溝通QA和開發都耗時耗力。針對這一情況，結合具體專案的測試現狀與專案邏輯的具體情況，開發測試自測工具提供給開發同學，制定自測透過的衡量標準，儘可能釋放測試人力。召回欄目提供自測工具後，極大釋放了QA人力，顯著提升了測試效率。　　

　　 五 未來規劃

　　後續在新聞推薦業務系統的測試上，重點依舊傾向於測試效率和測試質量的提升，將還未測試全面的業務場景逐步挖掘進行深入測試，儘可能保證各環節邏輯都應測盡測，提升整體測試質量；提取更多需求測試共性，將這些共性結合推薦系統特點開發自動化測試工具，提高測試效率，不斷最佳化及完善推薦業務測試架構。