GitChat · 測試 | 大眾點評搜尋測試全揭露:1:9 的測試開發比下 QA 如何前行

NO IMAGE

GitChat 作者:夢婷
原文:大眾點評搜尋測試全揭露:1:9 的測試開發比下 QA 如何前行
關注微信公眾號:GitChat 技術雜談 ,一本正經的講技術

【不要錯過文末活動】

背景介紹

本人2012年7月以應屆生身份進入大眾點評搜尋團隊,整個團隊QA(測試)共3人(包括我,後1人於11月離職),RD(開發)約15人;2013年,QA依舊只有2人,RD增加至20人;2014年8月起因承接點評Web和APP的搜尋相關前端業務,新成立搜尋移動端團隊,當時QA 4人,RD約35人;2015年,專注於演算法的搜尋體驗團隊也獨立並壯大,最後整個部門的RD演變為45人(搜尋平臺團隊15人、搜尋體驗團隊20人、搜尋移動端團隊10人),QA共5人。

  • 搜尋平臺團隊

    該團隊負責整個點評的搜尋引擎平臺和所有業務搜尋系統(100 ),例如大家常用的商戶搜尋、優惠券搜尋、使用者點評搜尋、團購搜尋等。

  • 搜尋體驗團隊

    該團隊負責所有業務搜尋的排序演算法優化、推薦系統,例如如何精準匹配使用者意圖將理想的結果排在前面、如何為搜不到滿意結果的使用者推薦可能感興趣的團購等。

  • 搜尋移動端團隊

    該團隊負責所有搜尋前端業務,例如點評WEB站、APP上所有搜尋提示頁與列表頁。

2012年7月我加入時,整個團隊基本處於這樣一種狀態:RD接業務A需求A1、A2、A3,業務B需求B1、B2、B3,業務C……A1開發完成QA在Alpha環境測試A1功能,A2開發完成QA測試A2功能,A1 B1 C1的程式碼變動一起合入Master分支在Beta環境進行整合測試,然後週二或者週四釋出到預釋出環境、線上正式環境。

QA永遠有做不完的Alpha功能測試、Beta整合測試 迴歸測試、預釋出新功能驗證 迴歸測試、線上驗證與迴歸測試。妥妥的車輪戰,印象中沒有9點之前下班過,臨釋出加班至11點也是常有的事。這樣的節奏與工作狀態,也導致沒有時間進行測試理論或者技術方面的提升,包括效能測試、安全測試等方面的深入,總之就是苦日子看不到頭,而且沒有成長的盼頭。

團隊現狀

在我2016年離開搜尋部門之前,負責搜尋平臺團隊質量保障工作的QA 2人(兼有整個團隊測試工具開發、持續整合系統維護、搜尋測試環境維護職責),搜尋體驗團隊QA 1人,搜尋前端團隊QA 2人。

各團隊QA日常

  • 搜尋平臺團隊

    該團隊2個QA主要負責跟進A級別(可簡單理解為>20人天開發量)專案測試,維護CI系統,維護搜尋所有後端業務測試環境,定位功能自動化迴歸失敗原因並解決,分析效能迴歸失敗原因並與開發共同定位效能問題,為開發提供其他必要測試支援(例如專案風險分析、開發自測側重點分析、對開發進行效能測試培訓、結對測試輔助新入職開發提高程式碼質量),開發測試效率提升工具,定期和RD進行線上缺陷和流程Review,以質量提升為目的進行流程優化,推動開發定期進行降級演練等。

  • 搜尋體驗團隊

    該團隊1個QA主要負責搜尋體驗團隊重點關注的商戶、團購搜尋和推薦效果,維護由於演算法改動造成的對應業務自動化失敗,根據業務發展進行效能迴歸場景變動,分析效能迴歸失敗原因並與開發共同定位效能問題,根據各開發程式碼質量做出不同級別專案的測試支援,嚴控釋出質量。

  • 搜尋移動端團隊

    該團隊2個QA主要負責點評APP Android和iOS客戶端每個版本的搜尋相關需求功能測試、相容測試、基於場景的專項測試、使用者體驗測試,維護Mobile API功能自動化、UI 功能自動化、打點資料上報功能自動化指令碼,並根據每個版本測試情況提供測試報告和各開發程式碼質量優化側重點報告,定期Review推動開發程式碼質量提高。

自動化情況

搜尋平臺和體驗團隊,所有重要業務的搜尋後端系統,均有用例覆蓋率80%以上的API功能自動化(P1/P2用例覆蓋率100%)和常用場景的效能自動化;搜尋移動端團隊,Mobile API P1/P2功能自動化用例覆蓋率 100%,UI P1/P2功能自動化用例覆蓋率 100%,打點上報P1功能自動化用例覆蓋率 100%。以上所有自動化日常通過率100%,一旦出現Fail,QA第一時間定位原因提交Bug或者修復。

持續整合系統情況

搜尋平臺和體驗團隊

CI(持續整合)系統會每15分鐘輪詢一次程式碼倉庫, 一旦發現Master分支程式碼變動,觸發API功能自動化Job A。該Job會拉取最新程式碼,打包,啟動搜尋Service,執行Beta環境對應功能自動化指令碼。

如果Job A通過,CI觸發對應程式碼自動部署到Beta環境和效能環境。Beta環境主要供搜尋RD自行進行新功能驗證、供其他業務團隊RD&QA聯調使用;效能環境主要服務於效能自動迴歸,將對應業務最新搜尋系統效能和基線版本進行對比,若QPS等指標變化超過閾值則郵件報警,監控顯示屏上對應Job飄紅預警。

如果Job A失敗,CI自動郵件給本次程式碼改動相關RD進行報警,監控顯示屏上對應Job變紅並展示此次程式碼提交責任RD。搜尋平臺或者體驗團隊QA看到紅色Job也會立馬介入,分析本次失敗是Bug還是BCD級別專案的邏輯變動導致,然後提Bug或者根據最新邏輯進行修復。

在2014年本人轉向移動端測試之前,這一整套已經完成並持續服務至今。當時我們的監控視覺化系統其實就是樹莓派的主機 兩個顯示器,可以給大家看一張監控顯示屏的效果圖:

enter image description here

搜尋移動端團隊

移動端團隊RD部署MobileService程式碼到Beta環境後,釋出系統會自動觸發CI上的Mobile API功能自動化迴歸 Job,對於API的功能自動化結果監控與處理,同平臺與體驗團隊。

移動端UI相關程式碼則隨點評APP的版本釋出流程進行合併、測試與釋出,QA會在執行該版本新功能測試之前進行UI功能自動化指令碼維護與迴歸,並在迴歸測試階段進行打點資料上報功能自動化迴歸及指令碼維護。

各團隊RD日常

搜尋平臺和體驗團隊

RD在需求評審會或者開發設計評審會上和QA共同評估專案級別。A類專案QA全程跟進;B-D類專案RD則根據QA提供的風險分析、自測重點分析、自測用例等自行進行業務程式碼和UT開發、Beta環境新功能驗證工作。

如果功能自動化迴歸、新功能驗證都通過,RD自行釋出程式碼到預釋出環境,釋出系統會同時觸發預釋出環境的功能自動化迴歸,RD進行新功能的驗證後,若沒有自動化迴歸失敗導致的簡訊報警,則自行釋出到生產環境。

完成生產環境一臺伺服器的灰度釋出後,釋出系統會自動觸發對應業務的搜尋請求DIFF,即:利用真實使用者請求,對灰度機器和其他任意一臺機器執行相同的搜尋請求,根據結果的對比報告,校驗本次改動是否在預期之內。該工具同時也能反饋出演算法類的改動對排序的影響到底有多大。

在生產環境,QA們維護的線上功能自動化會定期(按級別5-15分鐘不等)輪詢校驗,一旦失敗自動觸發簡訊報警。如果DIFF結果分析沒問題,RD在釋出過程中一邊檢視各臺伺服器Log是否存在異常情況,一邊等待線上功能自動化的驗證,若15分鐘之後一切正常,則本次釋出完成。

每位RD很可能每天都會進行這樣一整套流程,而且由於QA與RD約定後端服務只要避開請求高峰期,5個工作日全天都可隨時進行釋出,因此後端搜尋服務的釋出頻率根據業務需要可以非常高,印象中單單商戶搜尋系統曾經一天釋出5次。

搜尋移動端團隊

相比後端團隊RD而言,這個團隊的RD可能更“幸福”一些,因為釋出遵循APP版本釋出流程,有專門的團隊進行打包釋出,不需要他們操心。他們除了開發程式碼,更多的對質量的支援在於輔助QA進行一些提高測試效率的工具開發、每個版本之後和QA共同Review質量問題,根據QA的報告和自己的薄弱點有意識地進行質量提升。

3年裡我們到底做了些什麼

搜尋平臺和體驗團隊

自動化困境與破局

本文第一部分描述了2012年QA的慘狀,當時其實RD也很慘,所有搜尋業務的程式碼全部都在一個應用裡面,每次釋出RD需要跟著QA耗上一整天。因為沒有靠譜的自動化,一個小的改動都會怕影響整個系統,影響所有搜尋業務,所以需要人肉進行各環境的迴歸測試和釋出,必須要一天。

RD們甚至選出了釋出值日生,輪流和QA一起跟進發布。測試和釋出的低效,導致QA沒有時間進行技術上的提升,無論是測試理論提升,還是能提高效率的工具開發水平提升。

為了破解這個惡性迴圈,2013年搜尋的RD Leader一方面帶著整個團隊進行新搜尋平臺系統開發,目標是業務解耦、模組解耦;一方面給QA培訓開發知識,幫助QA提升程式碼水平。然後,RD&QA的Leader做出了一個大膽的決定:在新系統開發期間,QA放棄原先的專案測試,全部精力投入CI系統、新的自動化系統建設。除了新搜尋平臺系統這種絕對A類大專案,所有專案一律開發自測自己上線。

所以,本人就有幸經歷了獨立搭建搜尋CI系統,和RD以及當時公司的敏捷教練一起規劃並實現新自動化系統的整個過程。

自動化框架選型

這個新的自動化系統,必須要解決以下問題:

新增測試指令碼低效的問題:為了滿足快速的迭代要求,需求評審會結束,驗證點一旦確定,就希望對應功能驗證指令碼快速開發完成。

無法迅速擴充套件到新業務搜尋系統的問題:搜尋部門的目標是承接公司無論大小,所有業務的搜尋系統。在公司快速發展的過程中,業務搜尋系統也會井噴式增長,因此對應的自動化測試指令碼必須跟上業務發展速度。

對資料的依賴問題:以防別的團隊QA改動DB資料,進而導致搜尋的功能自動化不是因為真正的Bug失敗。

對特定環境的依賴問題:搜尋這種基礎服務,Beta環境必須保持穩定,不能頻繁部署未經驗證的功能程式碼,故不能利用Beta環境進行自動化測試。

除了需要解決上述痛點,它還要支援靈活的Case管理,允許根據級別從Case裡方便的選出一部分單獨執行,要有詳盡的報告方便快速定位問題。

最終,我們選擇了Python Shell RobotFramework。Shell指令碼完成從拉取程式碼到打包到啟動服務的過程,Python用於開發底層Lib,RobotFramework用於管理Case和出具報告。

為什麼這樣的選型能滿足團隊要求?

因為RobotFramework是關鍵字驅動的框架,而且搜尋服務架構穩定後,各業務搜尋系統基本功能不會有太大變化,所以只要底層API封裝好,橫向從一個業務的搜尋系統擴充套件到另外一個業務搜尋系統相對快速,所有底層API和準備指令碼都可以共用。

對於新入職的QA而言,Python比Java上手快得多,根據已有Case完成一個新的Case甚至兩行程式碼就可以搞定。

為了不依賴特定環境的DB,RD在新的搜尋平臺裡新增了對CSV這種資料來源的支援;對各種配置儘量利用獨立的文字檔案,不依賴任何線上配置系統;為了方便快速定位問題,對於這種只需要RPC介面的系統,他們也提供了HTTP方式的訪問方式。

所以,對我們的自動化而言,只要提前準備好CSV檔案作為資料來源,在服務啟動之前利用Shell指令碼改動配置檔案為所需,啟動服務後,校驗大部分後端API的過程其實就是傳送HTTP請求,校驗Json格式的Response,完美解決資料和環境依賴問題。

用過RobotFramework的同學也應該清楚,它的Tag非常靈活,一個Case多個Tag可以並存,它的Html報告也十分詳盡,所以之前提到的Case管理和報告問題也解決了。

對於搜尋這種只依賴資料的底層服務,因為解決了對資料和環境的依賴,所以後來我們的自動化一旦失敗,90%就是因為有Bug,只要維護及時甚至可以說100%就是有Bug,可信度極高。

CI系統

為什麼要依賴CI?

試想,每個RD每天改動那麼多程式碼,即便自動化全部搞定了,如果不在改動之後立即對整個系統進行整合校驗,一旦出問題,誰的程式碼,哪一行程式碼導致的問題,RD們去定位必然也極其耗時耗力。而整合測試,能保證最新的程式碼只要自動化驗證通過,系統就可以提供完整的主流程服務。

所以我們充分利用了CI這一點,有問題快速暴露、快速定位、快速解決。當然,這也需要每一位RD養成及時Commit,持續提交強可讀性Comment的程式碼提交習慣。這也需要我們的自動化迴歸必須15分鐘內執行完成,跟得上CI輪詢程式碼倉庫的節奏。曾經為了達到這個目的,我們把Sonar靜態程式碼掃描獨立成額外的Job,不讓它拖累自動化迴歸Job。

2013年,由於搜尋應用的特殊性(人家都是War包,容器使用Tomcat,搜尋是Tar包,容器用Jetty),它無法接入運維為其他部門提供的釋出系統(當時運維的釋出平臺也不完善),所以我把應用的打包部署也配成Job,讓RD們可以自助進行任何環境的部署工作。

效能迴歸

對於搜尋這種對穩定性和效能要求極高的應用,功能自動化最多可以暴露穩定性方面的問題,那麼效能呢?如果只是每週或者定期做個效能體檢,或者大促活動之前進行一次壓測,等發現系統無法滿足業務要求的時候,一切為時已晚。到時即便知道效能不達標,也不知道是這段時間哪些改動造成的。所以,我們讓效能也能自動迴歸。

由於支援HTTP的呼叫方式,所以我們選擇了Jmeter Shell。Shell指令碼的作用依舊在完成從程式碼拉取到服務啟動的過程,Jmeter做壓測,最後的報告和郵件報警使用的是公司測試工具組利用Python開發的一個專門針對.jtl文字的解析與郵件預警工具。

效能自動化迴歸最重要的點在於結合業務場景進行的壓測場景細分,例如商戶搜尋,就分為根據關鍵詞進行搜尋、根據分類導航進行搜尋、以使用者經緯度為中心的附近搜尋等等。場景規劃好,jmx檔案設定好,一切就都在掌控之中了。

最後我們還發現這個迴歸有個副產品:幫忙暴露多執行緒功能Bug。本人就曾經因為跟蹤效能迴歸出現的一個詭異問題,最終和RD定位出一個隱藏很深的高P缺陷。

DIFF工具

大家可以想想每到XX系統重構的時候是不是都會超級抓狂?沒有人力去梳理所有Case的時候,直接用大量真實使用者請求DIFF新老系統,被我們認為是最高效最全面暴露問題的方式。

所以我們把它用在灰度釋出,幫助把住倒數第二道關;我們把它用在大專案重構後的快速測試;我們把它用在排序演算法的效果分析。

只要是API類、只讀資料來源、需要滿足冪等特性的應用,我認為就可以考慮使用這種思路,後來承接前端業務後我們也把它用在Mobile API開發的自測和灰度把關上了。事實證明,效果槓槓滴,QA可以放心地不跟進Mobile API的任何專案,全年也沒有任何P3以上線上Bug。

搜尋移動端團隊

UI自動化

談到UI自動化,大家都會說維護成本太高啦,投入產出比太低啦等等。其實我也這麼覺得,所以我們只做主流程UI自動化,也就是多個版本幾乎萬年不變的功能自動化。

由於搜尋的前端業務流程相對簡單,點評APP的搜尋提示和搜尋列表頁面都是純Native,所以我們才決定試試UI自動化迴歸。對於那些每個版本都會變得不成樣子的頁面,做UI自動化的動機、效果和投入產出比,我表示強烈懷疑。

搜尋移動端團隊的UI自動化在平時維護成本低,偶爾也能幫忙發現一些問題,所以效果還行,雖然不像後端的功能自動化收益那麼高。

UI自動化選型

2015年時為了去了解一下當時火得不要不要的Appium,而且因為團隊QA習慣用Python,所以最終選擇了這樣一個能支援Python,傳說能一份程式碼適用多類終端的工具。它的社群Testerhome比較活躍,有問題容易找到解決方案,也是我們入坑原因之一。

用Python Unitest Appium還有一個最大的好處是Python指令碼可以隨時中斷,寫一句執行一句,除錯相對容易。

資料上報功能自動化

提到打點測試這個東西,很多QA可能恨得牙癢癢,因為測它純屬體力勞動,枯燥無趣,就算出現Bug,也不影響使用者體驗,所以真想把它扔掉,扔給產品自己去驗。

由於對搜尋團隊而言,打點非常重要,一個新的演算法效果如何,全指望著打點資料包表指明方向,所以雖然起初我們是懷著極大的怨恨心理從產品同學那裡把這部分工作接過來的,但是後來發現其實我們的業務場景,只要保證P1主流程的打點不出問題就OK了,邊角的小問題不影響大局,而且把這部分工作自動化還變成了QA的KPI亮點工程。

經過幾次打點問題的分析,發現問題基本出現在客戶端RD改動業務邏輯,導致誤傷打點邏輯,而非資料上報後續流程中。那麼如果能截住APP在各種場景上報的資料,對它進行校驗,就能暴露這部分問題。既然我們做了主流程的UI自動化,那麼順手就可以把這部分校驗工作自動化。

所以我們尋求移動架構組幫助,請RD們在Debug版本里加入一個功能,讓我們可以在Debug面板裡設定上報資料接收的伺服器,執行自動化時將其設定為本地啟動的一個Server,擷取所有上報資料並進行校驗。這樣一個開關也不會影響正式版本,避免插樁。

最終,這部分自動化指令碼在半年內幫助發現過三個以上的P1級別打點缺陷。

如果你也處於這種高開發測試比的團隊,怎麼辦

基本認知

質量是整個團隊的事情

雖然QA的本職在幫助暴露缺陷,但需求是PM提的,程式碼是RD寫的,QA不應該為質量負全責。包括面對當前的Bug情況,是否可以釋出,本來也應該是整個團隊一起拍板決定的(如果有正規的專案經理,那麼更多時候是專案經理拍板),QA更多的作用在於呈現風險,為決策提供參考。

要相信RD同學保質保量的能力

既然我們的老闆對一個團隊在配備相對少的QA的情況下的質量依舊有信心,說明老闆對招募的RD能力非常有信心,招募的必然都是精英,那麼QA也應該要對RD同學有信心。而且,大家都知道缺陷暴露越早修復成本越小,評估風險後認為可以完全開發自測上線的,就全部放手讓RD同學盡情發揮吧。少了和QA溝通Bug的成本,自己發現的問題自己修復起來肯定也是速度極快成本極小的,自己要負全責的時候必然也是兢兢業業打起十二分精神的。

有什麼資源做什麼事

大家在起步階段的創業公司很少會看到QA,那麼說明其實團隊沒有QA也玩得轉,那麼為什麼老闆還要招募QA? 難道招你來是為了幫RD做本來可以在沒有QA的情況下自己做的事的嗎?必然不是。因此我認為,在高開發測試比的團隊,QA更多的職責在於輔助開發更好地自測,提供必需的測試工具、必要的測試培訓、QA看問題發現問題的角度、更專業的測試而非檢查

你可以做什麼

基於上述三大基本認知,我認為大家可以嘗試做下面的事:

弄清楚,開發自己做不好自己的“檢查”,為什麼?

是因為缺乏發現問題的眼睛?那麼可以嘗試提供結對測試支援,提供自測Checklist、帶領RD一步步學會換個角度看世界。

是因為不會做效能測試?那麼提供壓測工具、提供壓測理論培訓、提供壓測諮詢服務。

是因為只瞭解自己的一個小模組,怕改動以後對整個系統造成巨大影響?那麼請RD自己弄好自己小模組的UT,QA和RD一起搭建、完善針對整個系統的IT,讓他們提交程式碼後,能快速從自動化或者哪裡得到自己會不會、會多大程度影響整個系統的反饋。

努力提升自己質量保障工作的能力

既然檢查交給RD同學了,那麼QA自己要具備去做質量保障領域其他事情比如測試的能力,並且讓整個團隊看到QA的價值,不然要QA何用?

所以,你可以去了解學習下專業的測試知識,例如《測試架構師修煉之道:從測試工程師到測試架構師》、探索性測試等等。

如果公司沒有專門的SQA,可以去了解下如何利用流程,優化流程等等來達到質量保障的目的,然後在團隊裡實施起來。

還可以多參加些線上線下的沙龍(如果你看到本文了,說明你已經開始做這件事了,祝賀,請堅持),多和不同公司、不同行業的QA們交流,看看人家是怎麼做的,有哪些可以用在自己團隊,著手去嘗試。

多和老闆溝通、和RD Leader溝通,確保自己想做的事有人支援

本來這應該是最重要的,應該放在第一條,但是如果沒有上面兩條,可能一開始老闆和RD Leader根本不相信你除了檢查還能做別的事。所以,我最後說下最重要的這一點。

上文提到的我們做的所有事,都是基於一個前提條件:搜尋RD們、運維們和我的上司們極大極大的支援。不然,CI弄得再好,自動化弄得再好,可能也就是KPI工程,起不到實際作用。在測試資源不足時,我們的RD甚至可以做到每個迭代,自己自測的東西做完後,自己去根據邏輯變動維護自動化指令碼。我們的DIFF工具,是RD主力開發完成的,QA更多在根據專業眼光提工具優化需求。當然,我們RD的UT也是非常完備的,金字塔基非常牢固。

為什麼RD願意做這些事?我姑且以小人之心妄自揣測一下。因為質量是整個團隊的責任這一價值觀從上到下的統一;因為有Bug被精英RD們認為是非常羞恥的一件事,他們一直認為QA是來幫忙的,本來他們應該自己全部搞定這些事;因為一旦他們自己能搞定這些事了,專案上線效率提升非常大(畢竟質量達標才能上線),俗一點講,每年多做點事,少一點線上缺陷,KPI也更好看等等等等。

後記

回過頭看這4年,我覺得非常幸運,剛畢業就踏入這樣一個三觀正到不能再正的團隊,一起完成了這麼多有意義的事。有這樣一群同事,我上輩子是修了多大的福。

在點評搜尋團隊時,曾經天真的認為所有團隊RD都是這樣,所有團隊QA都可以仿照移植我們這一套。離開這個團隊以後,才知道以前自己多麼幸福,能完成這一套是匯聚了多少天時地利人和。

我親歷過這段歷史,所以想為大家呈現這段歷史,讓一些剛步入社會就被996壓得無力喘息的同學看到另外一種工作狀態的可能性。以下借用《未來簡史》中尤瓦爾·赫拉利的一段話,與大家共勉。

現在的狀況既非自然而然,也不會永恆不變。過去曾經是另一個樣子,只是有了一連串的偶然事件,才創造出現在這個不公平的世界。只要我們採取明智的行動,就能改變並創造出更好的世界。

最後,感謝我的Boss佰智,感謝RD Leader召剛、新利、玉璞、志田,感謝我那群可愛的搜尋同事們。謹以此文,粗略地記錄下搜尋團隊那些年的光輝歲月,向我們一起並肩作戰的日子致敬!!!


實錄:《夢婷:測試開發比例懸殊下 QA 前行實戰解析》


彩蛋

重磅 Chat 分享:《如何在三年內快速成長為一名技術專家》

分享人:
方騰飛 併發程式設計網創始人,支付寶架構師
Chat簡介:
工作前三年是職業生涯中成長最快的幾年,在這段時間裡你會充滿激情,做事專注,也容易養成良好的習慣。
在我們公司有些同學在前三年中就快速成為某一個領域的技術專家,有些同學也可能止步不前。本場Chat和大家一起探討下如何在三年內快速成長為一名技術專家。
學習方法:
掌握良好的學習心態 掌握系統化的學習方法
知識如何內化成能力
實戰技巧:
你需要學會的編碼習慣 如何在普通專案中提高自己的能力
在業務團隊做
引用文字開發如何成長

想要免費參與本場 Chat ?很簡單,公眾號後臺回覆「技術專家」

這裡寫圖片描述