360手機衛士的敏捷測試模型都有什麼特點？

導讀ID:TOP100case

導讀：作為一款用戶活躍度過億的產品，360手機衛士一直是中國手機用戶在移動端安全工具上的首選。怎樣支撐這樣一款體量龐大的App實現敏捷發布模型，支持病毒文件的隨時更新，支持產品功能千萬級用戶8小時內的完成升級，支持產品經理每周一個版本迭代的發布頻度，都需要建設一套高度自動化的產品質量保障和灰度發布平台，實現在保障產品發布質量的同時進行快速的功能迭代和缺陷召回。

360手機衛士測試團隊基於業界各類最新的開源實踐建立了適合自己業務特點的專項自動化測試支撐能力，針對安卓手機碎片化分布的特點，開發了各類穩定性，性能及崩潰跟蹤的工具和數據分析支撐系統，在此基礎之上，形成了對軟體開發全生命周期各類工程活動的質量控制和監測模型，將質量保障活動變成了提高整個工程團隊實踐能力和效率的基礎服務，這其中的最佳實踐可以幫助希望建立移動互聯應用的團隊快速提高核心開發能力，實現團隊人員工程水平的卓越化提升。

（全文共4266字 預計閱讀時長：5分鐘）

360手機衛士的開發模型及測試特點

1.1 互聯網產品的開發模型和測試特點

增量迭代式開發，強調用戶體驗在開發中的及時反饋性，通過灰度的方式進行發布；

通過快速變化和反應適應用戶的需求；

測試系統優化和改進的目標在於降低發現問題->修復問題的時間和工程成本。

在互聯網開發團隊中，幾乎不存在大型的工程團隊，產品的功能也不能複雜到像傳統的應用一樣需要完整的功能說明書來描述和鎖定。產品功能多是在不確定、快速、嚴謹的過程中實現優化和適應。

對應的，測試系統也要重點強調敏捷，這就需要發揮持續集成的作用，同時要通過A/B test等形式將測試環節儘可能地融入到產品開發的過程中，而不僅僅定位於一個質量保障和發布前檢查的作用。即互聯網產品的質量標準具有相對性，更多情況下是由客戶主導並參與的，因此測試的功能應該融入到產品開發的各個環節，實現隨時的可測性。

1.2手機衛士的測試挑戰

手機衛士產品開發對工程系統提出以下要求：

上億級別的日活躍用戶，用戶對產品的感知程度非常迅速，將產品交付到用戶的要求也十分迫切，需要有一套快速修改問題，快速交付和升級產品的系統和灰度放量的能力。

安卓世界的碎片化，各種的安卓版本，廠商定製版本，UI系統和硬體設置，導致問題通常被細分在一個小的群體中，很難通過一個完整的測試覆蓋模型在發布前實現全覆蓋，需要有一個高效地模擬系統和通過數據驅動進行問題分析和感知的能力。

安全工具類軟體的使用特點，需要較多地使用系統的底層介面，增加了引起崩潰和不穩定的概率；工具類的產品，在保障性能前題下，應強調盡量少的資源佔用和消耗。

因而，對比傳統的軟體版本發布模型，需要進行以下敏捷化的改造和嘗試。

無論是瀑布模型，還是演進的一些產品開發方法，都會使用明確的階段性定義來控制產品的開發過程，通常包括：Pre-Alpha、Alpha、Beta、Release candidate(RC)、RTM、General availability or General Acceptance (GA)……但這必然會導致較長的發布周期和遲緩的升級速度。在一般的互聯網開發中，使用scrum方式，通過將產品功能進行低顆粒度的劃分，實現較少的耦合和相對獨立的功能改進路徑，以提高發布的敏捷程度，這些都必須對開發過程和質量保障活動進行有效地細化和改造。

通過內部用戶忠誠度較高的種子用戶更大範圍的活躍用戶完整放量用戶的規則來設計產品的發布模型，從而達到準確和高效的灰度發布。

產品開發的指導思想應該是：小步快跑，試錯，儘可能早的用戶參與。

在這個過程中，對產品的工程和發布結構改造，以支持敏捷化開發和灰度發布的結構是必須的一個步驟。

手機衛士的實踐是進行產品的插件化改造，通過升級路徑，源代碼級依賴，瀑布發布（圖1）部件級依賴，局部迭代（圖2）主框架+插件化，多部件獨立發布（圖3），可以實現產品物理結構上的解耦，以支持高效的持續集成和自動化測試的引入。

圖1 源代碼級依賴，瀑布發布

圖2 部件級依賴，局部迭代

圖3 主框架+插件化，多部件獨立發布

面向質量生成全過程的敏捷測試模型

2.1基於敏捷開發的灰度發布模型

手機衛士基於自身工程模型的特點和質量保障的模型，採用了支持敏捷開發的灰度發布模型，概要如圖4所示。

圖4 支持敏捷開發的灰度發布模型

主框架作為提供插件工作支撐的容器，擔負著基礎網路通信服務，公共數據同步機制，公共UI類庫等基礎設施類的功能；插件實現著各類基本的功能模塊，並通過與主框架的協作機制，與其他插件進行必要的通信和功能調用。

在這個結構之下，主框架和插件可以實現各自獨立的發布節奏和周期。插件可以根據需要實現隨時的故障修復和更新，這樣就擺脫了因為局部的問題必須對整體進行更新的方式。手機衛士包含了30多個插件，並且主框架也可以作為插件的方式，添加到其他的產品和SDK中去。

通過插件的獨立發布機制，手機衛士可以以每天一個插件版本的方式實現頻密的功能更新和升級。由於特定的插件可以部署到特定的目標用戶環境裡面，實際上，對用戶的影響是很小的。

在質量保障方式上，靜態檢查可以通過持續集成的機制，結合構建服務，實現針對每個checkin的及時掃描，保障了很多基本的代碼錯誤可以在構建之前被發現出來。

當插件和主框架分別完成構建之後，BVT（Build Verification Test）就可以馬上發揮作用，針對已經穩定的介面和功能入口點，進行功能回歸和介面兼容性檢查。這種檢查由於通過集成的平台在夜間持續進行，所以可以在不影響白天的手工測試的基礎上，將功能回歸異常的情況和主框架與插件的兼容異常發現並報告上來，從而在第一時間進行分析和修改，擺脫了手工檢查的工作量和效率低下的情況。

基於自動化的BVT檢查，手機衛士可以做到手工測試的任務集中在異變的、新增的功能之上進行，進而可以靈活的調整測試執行路徑，在發現問題較多的地方進行快速的回歸和探索性測試。這樣就避免了UI自動化測試的盲目性和較大的測試資源投入。

2.2敏捷開發模式下的整體質量保障模型

圖5為面向互聯網產品開發最為基礎的五類職能角色，每個階段都需要建立必要的質量保障手段，內容包括以下方面。

圖5 敏捷開發模式下的整體質量保障模型

產品定義和概念化階段：需要通過必要的架構評審和運營數據的分析，建立對相關功能可實現性和實現方案的分析和評估，並根據歷史經驗形成對測試方案的預期。

開發階段：建立更多的白盒測試和單元測試方法，通過介面級別的檢查，實現對深層次質量問題的感知和分析能力。

在產品質量保障和測試活動中：需要建立儘可能自動化的功能回歸能力，實現對版本質量的快速回歸。通過動作驅動的界面檢查實現機器對手工測試的替代性，從而降低手工測試在例行的回歸性工作上的投入，從而將手工測試靈活的聚焦到易變的Bug集中的區域進行。

版本發布階段：需要進行上線前版本的快速回歸，並通過腳本和靜態掃描的機制實現對待發布版本的快速檢查，從而支撐在灰度的條件下，通過多種渠道（自升級，渠道包等）方式進行產品的發布。

在產品存活的全生命周期，建立監控和伴隨性測試機制：這些機制有助於通過感知和了解用戶（統計維度上）的行為特點和規侓性使用路徑，以實現在線的問題監控和反應能力。

為了能夠支撐以上質量控制手段，必須建立項目管理和持續集成的支撐系統，即通過項目任務的進度管理對發布過程的各個活動進行信息和狀態集成，通過建立有效的實時數據監控系統、在線的故障分析和診斷機制實現對問題的快速反饋和解決。

2.3支撐自動化測試構建塊（Building Blocks）

建立一個能夠支撐互聯網產品快速迭代，敏捷發布的自動化測試支撐系統，並非一定要從一個宏大的、複雜的整體架構做起。手機衛士的實踐是先從構建這個完整系統的部件，即構建塊開始做起，每一個構建塊用以快速的解決某一類測試問題，在實現這些構建塊的過程中，完成自動化支撐框架的某一基礎功能的開發，從而逐漸的實現一個完整的自動化測試支撐框架。以下是一些基礎的、必需的自動化測試構建塊。

包穩定性測試

強調DailyBuild的作用，研發階段的包內部支持基於配置參數的測試場景切換，實現了只構建一次，測試任務即可根據配置參數進行快速切換的目標。測試時手機上只需要安裝一次包即可完成多種環境下的測試。

自動化測試與測試效率工具

多種靜態掃描引擎，包括適配規則、Crash規則、框架約定規則、安全規則等，並且不斷地將測試階段、線上問題等總結抽象成新的掃描規則補充進入掃描引擎。

持續的自動化測試，形成監控能力，不僅可以提高產品穩定性，也可以發現性能、電量等非功能性問題。

Mock工具、驗證平台等輔助測試工具也提升了測試人員的效率。

發布系統與監控分析

線下質量數據等信息彙集到平台上進行統一的分析告警，不僅能快速的發現問題，而且能通過數據分析幫助快速定位和解決問題。

根據平台中的數據調整自動化場景、發現新的測試路徑和手段，可以使經驗形成閉環，使質量保障工作更加高效。

對以上構建塊及其作用加以梳理和總結，我們發現了一些敏捷測試模型的應具有的共性特點，包括：

對產品質量狀況的感知模式的設計和選取：

實時感知；

數據共享；

態勢分析。

持續集成的作用方式：

分支隔離；

主幹與分支的合并標準。

DailyBuild形成的質量基線：

測試的廣度與深度的關係。

單元測試的作用：

白盒測試目標和實現方法；

如何選取測試方案，有效縮短測試路徑。

BVT的重要性：

冒煙與E2E類型的測試用例分解；

BVT運行的頻度。

最後，我們討論一下自動化測試的策略和價值。

UIAutomation與介面測試自動化的關係和取捨；

自動化測試框架的選擇和使用。

UIAutomator/Expresso

APPium/Robotium/

其他能進行跨進程操作的開源框架

建立測試基準的意義；

對自動化數據進行分析，匯總及可視化的重要性。

移動端應用的專項測試及最佳實踐

專項測試的目標和要解決的問題：

在移動端（無線）產品的測試過程中，專項測試這個概念會被反覆的提及，這部分是來源於移動測試的兩個基本特點：即資源和差異。

所謂資源是指移動端產品要面臨機器資源的限制，無論是運算能力，網路使用和電量，移動產品都必須在可使用的計算資源和產品的功能之間進行平衡和取捨。

所謂差異是指移動端產品具有明顯的個性化，在每個端上，不僅由於硬體平台的差異帶來的天然的區別，也由於使用者不同的愛好和使用方式，形成產品的形態和數據變化的差異性。

這兩個原因都會導致產品的測試方案都是在一個複雜的測試組合中尋找最大的可能性，以實現最佳的問題發現路徑。

下面我們來討論一下專項測試的範圍，它們通常包括一下測試類型：

性能類：CPU，內存，網路流量，存貯及空間佔用，電量

體驗類：滾動，載入時間，易用性

穩定性：ANR，Crash，閃退

兼容性：安裝與升級，系統ROM與UI行為，共存

安全性：漏洞檢查，病毒及惡意代碼掃描，隱私保護及泄露；

而手機衛士基於UI自動化的性能測試方案能夠對以上性能指標和參數進行快速的自動化和半自動化的回歸，以降低發現問題的成本，提高測試的效率，如圖6和圖7所示。

圖6 性能參數自動化獲取及分析的展示

圖7 崩潰問題監控及數據分析後台

最後我們需要重點討論一下APM（APPlication Performance Monitoring）在性能測試上的作用。

APM的目標

變事後反應模式為在線監控；

實現機制

Instrumentation，

後台數據存儲，

自動數據分析；

測試價值

持續地進行灰度測試；

快速定位問題，實現「No More Repro」的測試目標；

測試在工程卓越性方面的實踐心得

作為工程的一個能力分支，測試工作必須向工程卓越性做出貢獻，這裡面涉及到一下問題的討論：

如何正確理解和處理開發與測試的兩個職能的關係

製造問題和發現的矛盾體：警察與小偷？

一個事物的兩個視角：盲人摸象？

應該是紅藍軍的共生和競合狀態

實現測試人員個人技術能力的提升

寬度：全面的技術領域，向全棧測試工程師發展

深度：對開發技術的實踐，堅持一萬小時的鍛煉

測試人員的技術升級路徑

自動化測試測試開發Test- As A Service（TAAS）

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！