2019年10月26日，由Testin主辦的第二屆NCTS中國云測試行業峰會在京召開，此次峰會以“AI+未來”為主題，匯聚來自國內外測試領域的知名專家學者、領先企業決策者、高層技術管理者、媒體從業者等，共同探討高端云測試技術，幫助測試從業者了解最前沿行業趨勢，及最新的行業實踐。

[[283754]]

會上，360搜索測試總監彭興強做《360搜索質量保障體系介紹》。彭興強分享了360搜索業務，通過CI/CD全流程自動化、功能、性能、接口測試自動化，再加上業務監控、線上產品質量的自動化分析、AB實驗以及一套完善的數據分析系統來保障線上服務質量。

以下為彭興強演講實錄：

大家上午好！360剛剛舉辦了一場測試嘉年華，當時有很多同學參加并提出了一個問題，測試未來的方向在哪里？今天聽了徐琨總的分享，我覺得Testin確實走在了行業的前列，對我很有啟發。下面我為大家分享一下360搜索在質量保障體系建設上的一些經驗。

我之前在阿里工作了四年，之后到360，在360待了七年，這期間一直負責搜索業務的測試，經過七年時間，打造出一套質量保障體系。今天主要從業務介紹、質量保障體系實踐經驗、問答三個環節進行介紹。

第一，業務情況。在搜索領域，大家應該都接觸過360搜索。

搜索的基本流程是這樣的，首先，我們會積累一批鏈接庫，spider通過鏈接庫中的鏈接獲取線上網頁數據進入網頁庫，再經過篩選、過濾，最后成為我們線上索引數據，用戶通過前端搜索框查詢訪問索引庫數據得到需要的結果。

搜索業務有什么特點呢？首先是系統龐大，整套服務需要上萬臺服務器、數十個在線業務模塊、數億的日PV、核心業務單例運行需要幾百臺服務器、多個團隊開發維護；其次業務邏輯復雜，大規模的線上服務互相依賴、完整的一套業務流程需要經歷十幾個業務模塊、結果展現需要經歷數十個算法策略模塊；第三，數據量大且變化快，百億的離線數據，時刻都在更新的實時數據，特型展現的結構化數據，垂直領域的專項數據，所有數據都要能及時準確的滿足用戶需求；第四，測試場景復雜，系統的龐大和復雜造成幾十個關聯服務需要把控，眾多模塊由不同團隊開發完成，線上query多樣性造成case場景的千變萬化。

征對這樣的業務，我們是如何保證質量的呢？下面給大家簡單講一下。

首先，我們在流程自動化方面做了全流程的自動化體系建設。在項目管理上，我們也做了很多事情，比如把時光軸、項目時間節點都和數據關聯起來。在功能自動化、前端自動化、接口自動化都有自己的一套平臺。在專項測試上，有性能測試平臺和DIFF平臺。

最近也有人問我一個問題，人工測試能不能被替代？經過這么多年的實踐，我們發現人工測試是沒有辦法被替代的，自動化流程只是一些固有的、已實現的流程的自動化，人工測試在新功能驗證上仍然必不可少。

在整個編譯打包發布流程中，由于系統復雜，核心功能單列運行就需要幾百臺機器，開發、測一個項目要熟悉所有模塊難度很大。我們在測試之初面臨過一個問題，很多同學，特別是新來的同學在不熟悉項目的時候，部署環境非常耗時，要把整個模塊摸透，他至少需要一周的時間。而通過自動化的構建，實現全流程自動化之后，任何一個新同學，只要關心自己模塊的變化，通過自動化系統部署自己需要的環境，這樣就可以快速的切入到業務，使整體工作效率得到大幅提升。另外，很多既有功能的自動化，包括自動化發布，整個發布基本不用人工干涉，功能的自動化回歸也有一套平臺，另外，線上會出現一些badcase，很多并不是因為測試漏測引起的，可能是數據，或新產品類型的出現，導致結果不能滿足用戶需求，這些都是通過線上質量的自動化分析系統進行保障。產品質量的好壞最終衡量者是用戶，通過A/B實驗分流讓一部分用戶先用起來，快速上線，多實驗版本的對比，再通過詳細的數據指標分析，了解實驗產品的用戶使用情況，發現一些不好的版本，把優質版本推到線上。還有監控，我們的業務這么復雜，接口這么多，流程這么長，靠人去盯是不現實的，必須有一套自動化的監控模式，通過一整套的監控體系發現整個流程中存在的問題。

我們的測試開發比是比較高的，這么高的測試開發比怎么保證質量？首先是項目管理，剛才也有老師提到了測試前置，測試的極致是沒有測試，完全由開發自己保證質量，但由于開發水平參差不齊，業務也很復雜，不同的開發團隊，很難通過開發自己保證質量，需要測試建立整套的測試流程。在項目管理上，項目一定要規范立項，我們發現前期測試，溝通過程中會出現很多問題，比如需求不明確，低級問題不斷出現，中間反復溝通，消耗了很多精力，其實大多數項目在整個項目周期里留給測試的時間并不多，如果前期規劃不好，會浪費很多時間，所以項目的合規性非常重要，必須要建立規范流程、有項目說明、有項目文檔。另外，全周期的平臺化管理，任何一個節點，任何一個事項，在平臺里可以追溯，所有的項目都有一個時光軸，可以追溯到任何一個節點，暫停，打回，bug修復，或者測試通過，我們都可以看到，可以快速定位到某一個節點，比如項目延期，為什么延期，哪個環節出了什么問題，通過平臺上的記錄我們都能夠很清楚的知道。通過將項目管理平臺和數據分析平臺進行綁定，可以了解項目上線之后是什么狀況，進而進一步的掌控線上產品質量。測試的極限就是沒有測試，要保證質量，減少后期測試的投入，就要盡可能的加強開發自身質量建設，不能出現低級的Bug，要在前期質量建設上做好鋪墊。

在流程方面，我們做了很多事情，比如編譯打包自動化、環境部署自動化、基本功能測試自動化，前端的，性能的，接口的，整個體系都有自動化建設來支撐。

傳統流程是開發，開發之后是自測，提測，冒煙測試，如果不通過就打回，冒煙測試通過就進入QA測試環節。我們做了一件事情，將前面的所有部分抽象出來，都放在全自動化測試流程，編譯打包，提測，冒煙測試和自動化測試，所有都放到一個全自動化測試流程里。這個環節目前不需要測試來參與，現在成為開發全自動化測試，提測這兩個環節，然后有兩種情況，如果是性能測試QA直接確認結果，同意上線，另外一種是有新功能需要驗證，測試同學完成新功能的測試，比如某版塊進行了新的優化，因為我們整個流程是全自動化的，并不需要測試同學去參與，只需要走完所有的自動化驗證，我們能夠支持自動化上線。

全自動化的流程，一個項目提出來之后，首先會進行公共代碼的檢查，因為它可能會影響到其它模塊，公共代碼是我們必須要檢查的，其次是配置文件的檢查，在配制文件方面，很多開發同學有一個誤區，改配制不需要測試，我們后來發現這是一個很大的誤區，因為改配制導致項目出現了很多問題。因此，我們把配制的驗證作為自動化建設的一個基本環節。另外是功能的回歸，功能、接口、模塊，離線建庫，性能測試，DIFF測試，兼容性測試等，因為線上可能存在不同的版本，版本上線之后，對當前版本是支持的，對上下版本的兼容需要進行測試，所有環節都是在自動化的過程中來實現的。

接口自動化，我們對線上的數據進行收集，成為我們的測試用例，當然這些是不夠的，還需要構造特定場景下自己的測試數據，公共層對常用的函數進行封裝，比如抓取函數、日志分析、寫數據、發郵件的基本功能，配置層進行配制項的管理，通過這個平臺實現接口的自動化測試。

服務端也有一套自動化的程序，完成對測試架構及基本功能封裝達到業務測試人員不用關心測試架構代碼，只需要按照格式，把case輸入進去運行就可以得到自動化的結果。把測試框架跟case分離，降低測試人員參與自動化測試的難度，讓大眾都能參與進去。

前端自動化平臺，主要是通過python+shell+selenium實現。

性能測試自動化，搜索有一個特點，對性能要求特別嚴格，我們很多工作都是對系統性能進行測試。之前所有的性能測試都是測試同學來做的，工作量比較大，工作內容相似。我們開發了自動化性能測試平臺，把測試人員釋放出來，讓開發同學自己去做性能測試，我們只做平臺功能和數據分析和最后結果的確認和檢驗，降低測試人員的工作量。

通用性能測試平臺的測試結果，主要是關注機器的資源消耗情況，平臺使用簡單，只需要提供相應的地址，選擇需要的數據，平臺全自動化的運行。我們還有定制化的，比如引擎，有時候會關注特定的指標，我們將基準版的數據指標集成到自動化里面去，把基本的指標標準化后和原有的數據進行對比，如果發生變化了，就需要人工去進行分析，定位看是哪里出了問題。

性能測試自動化的平臺，它是數據定制化的，針對每塊業務，我們可以定制化數據，開發不用關心數據，只要選擇做什么業務，選擇什么樣的數據，點擊確認就可以。平臺支持數據上傳，有特定的數據去驗證，可以自己上傳需要的數據。另外，支持多機器、多機房的發壓，我們要對不同的機房發壓，平臺也可以支持。另外是實時日志，如果測試需要觀察實時數據的狀況，有些性能測試不需要把整個測試做完之后再看結果，比如10分鐘，20分鐘，發現問題了可以停止測試，去排查問題，我們支持秒級的數據察看。另外是歷史任務管理，指標變化情況，都可以在平臺里進行察看。進程監控，在特定的任務里面需要關注某些進程的情況，需要把進程名稱填進去，可以通過平臺察看。

結果Diff，搜索引擎的case非常多，全覆蓋非常困難，每次測試，到底關注哪些query？我們只關注變化的那部分，只關注當前這一版本到底結果發生了哪些不同的變化，比如Diff不同位置的占比。

前面講的是搜索業務線是很長的，不僅有現場的流程，還有復雜的線下流程，怎么能夠保證？業務監控這塊是非常重要的一個環節。我們分下面幾個方面，一個是基礎數據的監控，從抓取萬億級的到百億級的網頁庫，這是非常復雜的過程，整個數據是什么狀況，有可能中間某個環節出現了問題，數據突然停止更新了，或者突然消失了，我們需要通過監控來判斷這個數據是不是存在。另外，每一個新的數據都有時間標識，我們要判斷這個時間戳是不是最新的。另外，數據的大小，如果發生了明顯的變化，是需要去關注的。還有，字段值是不是發生變化，都要通過監控來發現。接口的監控，接口的變化率，接口的正確性也是需要關注的。還有是查詢失敗率，我們控制在百分之一，甚至千分之一以內，如果超過了可能就出現了問題。還有時效性，新聞查詢有最新的結果。泛時效性，比如購房新政，都會有最新的消息，我們只關注近幾年的結果，你再出幾年前的數據就沒什么用處，所以這些信息也需要判斷。還有事件查詢有特型展現結果，比如國慶閱兵這樣的專題，是很新的事件，需要有特型展現的，給客戶更好的體驗。另外是官網及高質量url，比如淘寶、京東，如果最優質的結果沒有排在前面，有可能是我們的數據環節，索引環節，甚至數據篩選環境出現了問題，也是需要關注。

上面是測試基本環節應該做的事情，測試完了之后呢？效果怎么樣？最終還是用戶說了算，你如果覺得做的是非常好的產品，但是用戶不使用，有可能說明產品質量還是有問題的，怎么驗證呢？A/B實驗就是很好的檢驗方式。

AB實驗是很重要的環節，一個是分流，另外是數據。把我們整個搜索流量分成不同的桶，根據實驗配置進行分流，決定某個實驗到底命中哪些用戶，再通過后面的數據分析，看整個效果的好壞。AB實驗也是全自動化的流程，全方位、多角度的對產品數據指標進行分析。

上面都做完了可能還是不能完全保證質量，為什么？因為我們還是會收到用戶反饋，使用過程中還會有各種問題，并不是測試漏測出現的，而是因為產品復雜，query千變萬化，很難覆蓋每一個場景，所以我們開發了線上自動化的分析系統。

從效果上來看，我們做了一些嘗試，比如截圖聚類，把我們的頁面截取下來，去掉無關的信息進行機器學習的訓練，把一些特征更好的結果篩選出來，把特征不好的結果也篩選出來，發現我們在設計方面的質量問題。

另外是sug，就是我們的智能推薦，也有可能出現badcase。我們會進行語料的處理，進行主題向量變換，相似度的計算，找出推薦的badcase。比如推薦出現了重復，比如2399小游戲，有很多重復性的數據，通過數據處理之后，發現有些很相似的去掉。整個自動化分析涉及一些比較好的技術，比如圖片處理，機器學習，包括算法。

現在大家都在探討測試左移，左移最重要的事情就是更好的去提升正式測試前版本的質量，減少測試無謂的消耗。

還有就是測試右移，左移是提升開發的質量，右移是基于用戶數據去做分析，做預測，做質量的自動化建設。

這就是我今天要講的所有內容，謝謝大家！