Categories
程式開發

詳解優酷客戶端質量評估體系


一、客戶端質量評估體系的需求

移動客戶端的質量包括功能和體驗兩方面。在不同階段,客戶端質量保障能力建設的粒度和廣度的需求並不相同。早期可能快速試錯是一種更為高性價比且有效的手段,但是隨著應用的規模和用戶體量逐漸增加,合理的質量保障投入就成為了一個必需品。明確質量保障的需求和範圍,找到質量保障的成本和質量出現問題的修復成本的有機結合點,實現質量和成本收益最大化,是在設計和實施質量保障工作前務必要考慮清楚的事情。

體系化建設主要包括兩個維度的實踐:通過評估手段和方法的建設實現“有法可依”,通過流程和監督體系的建設實現“有法必依”。本文將介紹優酷技術質量部在“有法可依”維度進行的一系列建設,希望能給讀者提供一些參考。

二、客戶端質量評估體系的建設

根據優酷質量保障的需求和業務特點,我們重點在如下圖示的幾個重要階段進行了投入,並且在構建打包階段、整包驗證階段和線上驗證階段進行了重點建設。

詳解優酷客戶端質量評估體系 1

1. 需求評審階段

需求評審是整個開發測試流程的起點,佔據非常重要的位置。質量控制團隊在需求制定和評審階段有效介入,確認需求的合理性以及質量的可評估性,在需求中強調對質量風險的處理能力以及對測試支持的友善性,將會對後期軟件質量的可控起到非常重要的作用。我們在每個版本啟動階段進行需求評審,除了明確需求細節之外,會對新需求潛在的質量和用戶體驗影響、以及可測試性進行討論,最大限度的暴露問題並尋求解解方案,極大的節省了後續定位問題和返工的成本。

2. 編碼開發階段

我們通過推動Code Review以及單元測試來評估這一階段的質量情況,主要扮演了協調者和監督者的角色,編碼開發階段的規範化也是我們在加大力度進行建設的部分。

3. 構建打包階段

構建打包階段相對整個應用版本的生命週期來說仍然處於一個較早期的階段,適合的能力針對性的投放在這個階段可以做到以小博大,投入少,產出明顯,例如靜態代碼掃描、包大小健康度檢查等等。優酷技術質量部也是優先在這個環節發力,解決了較多相對埋藏較深的歷史遺留隱患。

4. 整包驗證階段

通過測試分層、分類,加強自動化能力建設以及拓展新的測試能力這幾個手段,我們在整包測試環節取得了不錯的進展,提升了測試能力和測試效果。

針對優酷客戶端測試的需求和組織形式,我們優先根據測試的目的從兩個維度對測試內容進行分層操作:服務端+客戶端,白盒+黑盒。

常規的端上黑盒驗證存在一些固有弊端:場景多、鏈路長、執行過程複雜,難以維護和提效。通過服務端和客戶端的測試分層,在服務端的接口處設置一道驗證屏障,保證服務端的邏輯正確,可以有效減少測試驗證的鏈路長度和復雜度,簡化客戶端的測試場景,從而減小客戶端的測試壓力。服務端的自動化驗證是相對容易實現和部署的,執行效率高,成本低;經過簡化的客戶端驗證因為少了很多待驗證場景,去掉了相當多的pre-condition設置和環境/場景切換動作,自動化可行性也大大提高。

在此基礎上,我們又對客戶端側的測試進一步進行細化。部分可以通過白盒測試解決的場景,可自動化程度極高,維護成本非常低,例如通過白盒直接控製播放器接口的方式對播放器進行操作,比UI操作的準確性和穩定性都要高很多。設想一個拖拽快進播放的場景,通過UI自動化實現幾乎是一場噩夢,多機適配更是一個不可能的任務,但是白盒化測試來實現卻易如反掌。但確實有些測試確實需要走到UI層用黑盒的方式操作才能實現,或者在UI層的操作才能觸及到驗證點,測試團隊只有在這種情況下測試團隊會選擇黑盒方式完成測試。通過兩次分層,各層測試場景的數量和復雜度均比較可控,可自動化程度極大提高,需要人工投入的成本和壓力減少。

為了最大化的提效,我們對端上測試又進行了分類,如:回歸測試、遍歷測試、兼容性測試和適配測試等等,其目的是為了進一步提升測試的針對性,減少測試外延,降低測試複雜度。通過測試分類,不同的測試類型關注不同的驗證點,進一步拆分了測試場景,降低了每一種類型的測試複雜度,從而使得回歸、遍歷和兼容性測試可以更好的進行自動化轉化,快速高效的完成核心場景的檢查,並通過適配測試補齊自動化測試在覆蓋面上的短板。對幾種測試類型的選擇使用和組合使用,將使得測試策略更加靈活,測試效率和效果大大提高。

詳解優酷客戶端質量評估體系 2

除了功能驗證外,客戶端性能測試不可或缺。優酷在性能測試上投入了較多的精力進行建設,取得了不錯的成績。

5. 線上驗證階段

經過編碼開發階段、打包構建階段和整包階段三個階段不同維度的驗證,可以最大限度的減少問題上線。但是線上用戶的使用設備和使用環境千差萬別,使用場景也很隨機,線下測試基本無法做到對線上場景進行窮舉驗證。因此應用發布上線後,很大概率還是帶著這樣那樣的問題的,仍然需要有效的質量保障手段支持。

減少線上用戶影響的一個有效方法是控制用戶範圍,發布灰度版(beta版、試用版)或分批發布都是比較可行的辦法。灰度發布不是簡單的隨機圈一波用戶進行測試版推送,推送的策略非常重要。我們分析了線上用戶的各項特徵指標,建設了用戶分佈模型,並基於此實現了可控的灰度推送策略,幫助優酷在灰度發布的效果和效率上取得到了較大的提升。

減少線上用戶影響的另一個方法是快速止血,這需要建設完備的線上監控體系:

首先,要求有一個可靠的數據平台,有效的收集和回流線上的特徵數據信息;

其次,需要根據自身業務的特點,針對性的製定監控策略,有效的利用數據平台的數據。

無論是在灰度期間還是應用正式上線全量之後發現的問題,都是對線下測試的有益補充,應該有效的加以利用。我們建設了從灰度發佈到線上全量的自動化體系,串聯起了灰度發布、正式發布、線上監控等環節,並對監控發現的問題自動進行分發並回收結果。基於這套自動化的流程,不僅可以確保線上問題得以及時發現,還可以加強線上問題的處理效果,目前已經成為了優酷版本發布流程中的必備環節。另外,線上問題尤其是影響面比較大的,應該進行深入分析,對可以提煉出問題路徑或者驗證方法的問題轉化為線下驗證用例。當前優酷在構建打包階段的靜態代碼掃描和整包驗證階段的BadCase回歸,都有基於線上問題轉化而來的用例,來補充線下測試在測試設計階段難以預估的測試場景。

6. 平台服務化

從需求評審到線上驗證,質量保障工作貫穿於每一個需求的整個生命週期,涉及的驗證環節眾多且分散。我們是通過提供統一的、標準化、規範化的測試平台服務來串聯各個環節的測試能力,由平台負責實現、管理、調度各種客戶端測試手段,並對接各個業務團隊的測試需求,提供各業務一致的解決方案。另外,測試平台利用流程服務的驅動在優酷版本發布的過程中實現關鍵節點的測試驗證和結果展示,幫助業務方、PMO等核心角色確認當前集成版本的質量。通過平台化建設,整合客戶端的各種測試能力實現的這一套測試體系,真正構成了優酷的客戶端質量評估體系。

作者介紹

翀宸,阿里文娛技術專家。