百度測試架構師眼中的百度QA（一）  《轉載》

發(fā)表于2013-04-09 15:31| 4004次閱讀| 來源架構師Jack的個人空間| 13 條評論| 作者董杰

百度測試QA

摘要：一直以來百度質量部在業(yè)界都比較低調，外部同行鮮能了解百度QA的工作流程，以及如何應對互聯(lián)網(wǎng)研發(fā)節(jié)奏和質量的平衡。為此，百度測試架構師董杰在博客中分享了百度QA的四大核心價值，幫助理解全程軟件測試的意義。

從組織結構上百度所有的QA都歸屬于一個大部門百度質量部統(tǒng)一管理，在一個大部門下的好處是很容易一起跨產品線的協(xié)同作戰(zhàn)，各種測試技術和測試工具能以最快的速度得到傳播，避免重復造輪子的浪費。同時QA們能有一種更強的組織歸屬感、有著專業(yè)的發(fā)展通道與空間、關鍵能交到更多在QA領域與自己志同道合的朋友，擴展視野，所有QA都能從這種大資源池中獲益。這一點對所有做測試的人而言更有利于測試專業(yè)技能的持續(xù)提升。

從我工作所見和感受來看，百度QA有四個主要的工作挑戰(zhàn)：職責范圍廣（覆蓋完整的產品生命周期全流程）、 面對產品技術新（如移動互聯(lián)網(wǎng)、WebOS、推薦引擎）、研發(fā)速度快（互聯(lián)網(wǎng)的節(jié)奏）、大數(shù)據(jù)系統(tǒng)的復雜（百度本質是一個分析處理數(shù)據(jù)的公司）。這些挑戰(zhàn)長期影響著QA日常的工作方式，使得與傳統(tǒng)的tester有著工作模式的不同。

百度QA的工作范圍覆蓋了百度所有形態(tài)的產品從基礎架構的分布式系統(tǒng)、搜索架構系統(tǒng)、到搜索算法、Web前端、Windows客戶端、手機客戶端，以及最新的多媒體技術、機器學習等這些前沿的IT業(yè)務，因此在這里我能最廣泛的接觸到各領域測試的QA同行，聽聽他們的分享，擴展我的測試視野。當然我也有機會到各領域進行測試實戰(zhàn)，從我到百度算起，我已在web前端、windows客戶端、手機客戶端、搜索架構系統(tǒng)、搜索算法、圖片搜索領域進行了各種測試實踐工作，大大豐富和完善了我的測試技術知識體系，受益不少。

另外百度QA會更完整參與到產品研發(fā)流程的周期，從最早的MRD，到設計評審、到產品發(fā)布后的效果評測是端到端的參與完整的產品生命周期。與我過去經歷最大的區(qū)別在于，QA與PM（產品經理）打交道的時間非常多，在整個產品生命周期中幾乎是同步一起從頭到尾密切配合，同時QA還會為PM設計并開發(fā)用于產品評測的平臺對產品設計的影響會更多。對于QA與RD的關系，QA不僅只是響應RD提交代碼的測試，還會主動去幫助RD如何更好地做好UT（單元測試）、如何做好code review。

基于百度QA職責范圍的擴大，在百度QA工程師的職責和發(fā)展路線上目前來看已大致分為QAD和QAT，至少我在進行職稱評定的評審時，已會有意識的區(qū)別評估。QAD就是QA中的軟件開發(fā)者更多側重測試工具和測試系統(tǒng)的軟件開發(fā)，我在參加QAD任職評審1對2活動時，基本是以一個對軟件開發(fā)者和軟件產品設計者的角度來進行review，關注其代碼質量、軟件架構設計思路和產品設計思路的能力。QAT則是標準的Tester，偏重如何盡早的發(fā)現(xiàn)更多軟件質量問題，要求精通產品的應用場景以及各種測試類型。

因此各種風格和興趣的QA都可以在百度找到自己希望和喜歡的角色，當然有時QAT和QAD也會互換，我個人而言，認為相對而言QAT轉QAD容易，QAD轉QAT要難些，因為百度的QAT大多具備一定的軟件開發(fā)能力，平時也會根據(jù)工作需求自己做一些自動化測試開發(fā)和工具開發(fā)的工作。而QAD要轉QAT則還需要補充多種測試類型的知識技能，以及產品的業(yè)務知識。

我在這里目前算是QAT路線，大多時間在思考如何設計更完整的測試避免問題遺漏，以及如何讓測試人員在短時間內發(fā)現(xiàn)更多的深層次問題，當沒有QAD資源來幫助你時，也會自己設計與實現(xiàn)一些小規(guī)模的測試系統(tǒng)或測試工具。如果未來某天我的興趣轉換到了QAD的工作內容了也是比較容易獲得機會轉換的。所以當QA工作的平臺足夠大時，個人的興趣也會得到最大化的滿足。

在日常的工作中，很多百度QA常常還會面對很多新產品技術的挑戰(zhàn)，這里的“新”是指新形態(tài)的互聯(lián)網(wǎng)產品（機器學習、推薦系統(tǒng)、多媒體搜索）以及新的軟件應用場景（移動互聯(lián)網(wǎng)和Webos），這些新的被測對象所帶來的直接挑戰(zhàn)主要是業(yè)界很難有現(xiàn)成的完整的測試方案及測試技術，于是不得不逼迫百度的QA比傳統(tǒng)軟件測試的Tester更加持續(xù)地進行測試技術的創(chuàng)新才能滿足“新”產品的質保需求。例如：我今年參加的整個百度質量部層面的移動互聯(lián)網(wǎng)測試技術專項topic組的工作，就不得不去填補諸多業(yè)界在移動APP穩(wěn)定性測試領域、性能測試領域、自動化測試領域技術的空白，否則無法達到真正對高質量用戶體驗的追求。

當業(yè)界大多數(shù)APP的穩(wěn)定性測試只依賴Monkey測試工具時，Monkey測試已只占百度最新APP穩(wěn)定性測試用例類型不到10％的覆蓋面，其他90％的穩(wěn)定性測試方法大多是業(yè)界還未知但APP應用又必須要考慮的，否則就會出現(xiàn)“為什么用戶會碰到而我無法重現(xiàn)的問題”。

當業(yè)界還靠移動機型窮盡進行兼容性crash問題的覆蓋時，百度的QA已設計實現(xiàn)了基于靜態(tài)代碼自動掃描的兼容性crash問題的快速測試。當很多QA還在為如何在不穩(wěn)定的2G網(wǎng)絡下得到穩(wěn)定的測試結果而苦惱時，百度QA已靠不到1000元的低成本技術方案很好地解決該問題。同時在完善移動APP測試方案的過程中QA內部還設計開發(fā)了不少APP測試工具填補了業(yè)界在移動APP測試領域的很多空白。

經過我對內部信息的了解，之前官方對外宣傳較多的移動云測試MTC只代表了百度QA在移動互聯(lián)網(wǎng)領域測試技術積累的一部分而不是全部。所以我希望下一步有機會百度質量部能逐漸給業(yè)界分享出來，讓大家都能受益從而減少移動互聯(lián)網(wǎng)測試的煩惱和困難。

據(jù)我在百度的觀察我個人總結了一個規(guī)律：中國人并不缺創(chuàng)新能力，而是缺逼迫自己去持續(xù)創(chuàng)新的壓力和平臺。正是由于百度QA所處的工作環(huán)境和測試對象的特點，逼迫他們不得不去創(chuàng)新，結果QA個人的創(chuàng)新能力在不斷提升并形成了創(chuàng)新的習慣。我在這樣的環(huán)境下，一年下來自己的創(chuàng)新效率感覺比以前也提升了一倍以上，發(fā)現(xiàn)原來測試很多領域都有著創(chuàng)新的可能與空間。有朋友問我在百度累嗎？我說相比過去身體不累但腦子累因為經常都在思考如何創(chuàng)新地解決所遇到的各種沒有現(xiàn)成方案的測試問題。

曾有多位互聯(lián)網(wǎng)的測試友人網(wǎng)上問我：“百度是如何進行面向互聯(lián)網(wǎng)的快速測試的？”對于這個問題，我最大的感受是互聯(lián)網(wǎng)研發(fā)速度與質量的平衡讓百度的QA必須持續(xù)通過測試技術的改進來實現(xiàn)該目標，靠智慧的測試而不是加班來同時滿足進度與質量的需求。為了滿足這些需求百度質量部有大型測試平臺如百度TIP(Test in production)系統(tǒng)、百度眾測平臺、百度MTC、分布式并行自動化測試等支持大多數(shù)產品組同時獲得研發(fā)速度加快和研發(fā)質量提升的收益。

我個人認為百度TIP應該是國內在beta測試領域做得非常智能和系統(tǒng)的beta測試系統(tǒng)，可大大提升beta測試的效率和質量。而百度眾測平臺則是國內第一個也是規(guī)模最大的眾測社區(qū)，依靠互聯(lián)網(wǎng)上的熱心用戶資源幫助產品盡早發(fā)現(xiàn)更多用戶場景特有的問題，減少了百度QA測試時間資源和測試物料的投入，值得國內各公司借鑒。如何更好地把用戶吸引進來參與beta測試，花點錢是必須的，空手套白狼是不可能的，但是投入產出比是值得的。百度移動云測試MTC平臺則通過對已有測試物料和測試資源的共享管理及自動化應用幫助各產品APP測試縮短了在兼容性測試領域和性能測試領域的測試時間，并且讓各產品APP獲得更廣的測試覆蓋從而獲得更高質量的APP。

除了這些公司級的測試平臺幫助各產品QA加快測試速度外，在日常的測試工作中一線百度QA還會主動積極學習和廣泛地應用業(yè)界優(yōu)秀的測試技術：持續(xù)集成、code review實踐、靜態(tài)代碼自動測試工具、環(huán)境一鍵搭建、監(jiān)控系統(tǒng)、分布式并行測試、探索測試等都在大多數(shù)產品組普及落地，希望靠先進的技術手段生產力來提升測試效率，縮短研發(fā)測試周期。

據(jù)我所知百度質量部的探索測試在國內應該是應用產品范圍最廣的，從windows客戶端、移動APP、web產品都在例行應用，探索測試幾乎覆蓋百度所有產品線，應用和實施探索測試的QA數(shù)達到上百人以上，涌現(xiàn)出不少內部探索測試教練，實施了探索測試的產品在沒有增加測試周期和測試人力的前提下能提前發(fā)現(xiàn)更多問題減少漏測，部分產品探索測試發(fā)現(xiàn)的問題數(shù)所占比例已達30％以上，提升了發(fā)現(xiàn)單個缺陷的測試效率。

我個人認為對比靠延長工作時間和減少必做測試類型來加快研發(fā)速度的做法，靠主動持續(xù)應用各種新測試技術實踐和成果是一種更可持久更科學更人性化的做法。關于百度如何進行“快測試”的咨詢，我想這里已給出了一個已驗證的解決方案了，希望值得各位同行借鑒和思考。

對于當前很熱門的“大數(shù)據(jù)”及大數(shù)據(jù)如何測試？我覺得百度有些實踐值得大家了解，給大家一些大數(shù)據(jù)測試的啟發(fā)思路。

 因為百度天生就是一個大數(shù)據(jù)公司，百度大數(shù)據(jù)系統(tǒng)的復雜度很高導致一直要求百度的QA既要保證高負載數(shù)據(jù)處理系統(tǒng)的穩(wěn)定性、還要挖掘大數(shù)據(jù)中的badcase，尤其要擅長算法的測試。在保障高負載數(shù)據(jù)處理系統(tǒng)的穩(wěn)定性領域，既有“線下百度”這樣集系統(tǒng)化的穩(wěn)定性測試方案與監(jiān)控系統(tǒng)為一體的專項測試系統(tǒng)，也有不少申請了專利的可靠性測試工具來解決穩(wěn)定性測試中異常構造和測試流量構造的問題。同時幾乎所有產品線都通過百度的大型后臺系統(tǒng)的穩(wěn)定性測試實戰(zhàn)培養(yǎng)起了該領域的測試高手。

當然我也受益于百度的穩(wěn)定性測試工作，通過為某百度第二大流量的產品進行穩(wěn)定性測試方案的改進，在這里真正地把我過去在可靠性測試、壓力測試、長時間測試領域的經驗系統(tǒng)地結合起來形成了我自己完善的穩(wěn)定性測試模型，并通過大數(shù)據(jù)處理系統(tǒng)的測試應用檢驗了我的穩(wěn)定性測試模型的完整性，確保有各種測試方法可提前發(fā)現(xiàn)所有可產生穩(wěn)定性問題的風險。

另外為了更好地對大數(shù)據(jù)時代的數(shù)據(jù)挖掘和推薦效果算法進行效果評估，而不僅僅只是進行新算法程序正確性驗證，百度的QA們還積極應用機器學習的思想、算法和工具對諸多產品的推薦效果算法進行產品算法集有效性的自動化評測，各產品線QA們設計的badcasse自動化挖掘系統(tǒng)在很多產品都能達到85％－95％的準確性，提供大量的量化數(shù)據(jù)幫助產品的算法設計者重新優(yōu)化算法，而不只是修改算法的程序bug。

同時為了更早更快更準地體現(xiàn)算法效果測試的價值，有的QA還積極進行該領域的其他創(chuàng)新，諸如：網(wǎng)頁搜索的QA把badcase自動化挖掘系統(tǒng)與百度眾測結合后大大減少了研發(fā)人員大規(guī)模分析與定位badcase的成本。圖片搜索的QA甚至實現(xiàn)了線下badcase自動挖掘的算法，突破了搜索業(yè)界傳統(tǒng)依靠線上用戶數(shù)據(jù)進行用戶體驗測試的限制，能在大數(shù)據(jù)產品上線前未獲得用戶數(shù)據(jù)前就提前自動發(fā)現(xiàn)大量的badcase數(shù)據(jù)，為用戶提供更好的推薦結果。大數(shù)據(jù)領域的測試涉及很多，由于我個人所見有限，就先給大家分享到這里。

如果非要我用一句話來總結百度QA的特點那就是：“持續(xù)技術創(chuàng)新與積極學習”。

平時在微博上測試同行們常討論QA的核心價值是什么，甚至常有開發(fā)領域的老兵也來參與辯論。當然在百度內部也會有關于QA核心價值的討論，從我了解的情況來看百度QA的核心價值在內部已得到了一些共識和不可替代性的證明。

百度QA的第一個核心價值是：全流程質量保障中心

全流程質量保證確保所有百度產品的程序質量。從需求/設計/編碼/產品發(fā)布的全流程都會有QA介入并提供各類質量保障手段。從盡早發(fā)現(xiàn)問題，到缺陷預防，到減少發(fā)布后遺漏問題的影響都是百度QA投入和支撐的目標。

百度產品的全生命周期的質量保障是百度QA的首要工作目標，也是在百度不可或缺的核心價值，大部分的QA都一直為將漏測率降低到千分之幾，甚至是零漏測長期進行著持續(xù)的測試創(chuàng)新和技術改進工作。

百度QA的第二個核心價值是：公司用戶體驗測試技術能力中心

前面所介紹的百度QA的工作范圍和工作目標不只是傳統(tǒng)tester所涉及的內容，他們被要求不僅要發(fā)現(xiàn)程序的錯誤，還要發(fā)現(xiàn)產品效果的問題，要求對用戶體驗質量全面負責。所以，百度QA除了廣泛應用各種軟件測試技術幫RD找bug還會積極進行產品的應用效果評測工作為PM提供用戶體驗方面的缺陷，badcase自動化挖掘系統(tǒng)、百度眾測平臺等都是這方面的典型代表。我覺得從這點來看百度QA的用戶體驗定義的覆蓋含義遠超過了很多人所認知的易用性感受。

百度QA不只關心程序錯誤這一點突破了許多公司目前對tester的限定，因此我建議各公司的tester們應該更積極主動的行動起來，在公司內部開展對產品業(yè)務有效性的評測而不僅是正確性的評測，因為只有這樣才是真正的產品測試，而不僅是軟件測試，測試者的價值能夠獲得更多的體現(xiàn)。

百度QA的第三個核心價值是：公司研發(fā)效率提升能力中心

百度QA們從最開始關注如何提升測試過程的效率，到現(xiàn)在考慮如何通過提供研發(fā)輔助工具和流程改造，提升公司整體的研發(fā)效率。我看到的是除了百度質量部層面的質量工程中心、還有產品線層面的EP專職團隊、以及分布在各產品組的QA們都在積極貢獻各種提升測試效率和開發(fā)效率的工具及系統(tǒng)。百度TIP系統(tǒng)、持續(xù)集成等是研發(fā)流程層面的典型代表，分布式并行測試系統(tǒng)、各種代碼自動掃描工具等是測試效率提升的典型代表，提供給UE的單測工具FIS、提供給RD的UT技術支持服務則是研發(fā)效率能力提升的另一種形式。我認為在研發(fā)效率提升方面，百度的QA們擔負起了最大的職責和貢獻了最大的價值。因此各公司的tester們如果要跳出測試價值的狹義定義，可以考慮參考百度QA的工作模式，積極擔負起公司研發(fā)效率提升的擔子。

百度QA的第四個核心價值是：百度技術部的人才“黃埔軍校"

在很多公司測試部或質量部都是向各部門培養(yǎng)人才的輸送部門，這是因為測試工作的綜合性讓很多測試者獲了全面的鍛煉。成為一個懂技術的產品經理，成為一個懂質量的研發(fā)人員都是測試人員轉崗的優(yōu)勢。

不過在百度我看到這里的QA在質量部內部得到了更多綜合性的鍛煉，不依靠轉崗也能在質量部內部專注做產品研發(fā)、做產品經理。因為有的QA團隊本身就在做產品，承受著做產品的質量標準壓力，如百度移動云MTC本身就是百度移動云戰(zhàn)略產品的一部分，百度眾測也是一個完整的互聯(lián)網(wǎng)產品，QA們在其中擔任起了互聯(lián)網(wǎng)產品經理，互聯(lián)網(wǎng)產品運營，互聯(lián)網(wǎng)產品研發(fā)角色，能參與這些項目的QA是比較幸運的，這些經歷對他們未來的發(fā)展都是一次很全面的鍛煉。同時前面談到QA從MRD到產品發(fā)布后的全程介入工作，也使得QA能掌握大多數(shù)PM的技能和更深入的了解產品的完整生命周期成為“半個PM”。

因此QA的發(fā)展空間和路徑是很廣闊的，關鍵看自己在公司內部如何去推動，如何去影響周邊團隊，讓自己的工作范圍擴大的更多。沒有人說“你不能做什么？”只有自己內心限制了自己“不能做什么”。從這點來看，百度的QA玩得還挺“風生水起”的，希望國內其他公司的測試人員們能跳出原有思路，擴大自己的影響范圍。

原文鏈接：上半部分   下半部分

思科-網(wǎng)迅（中國）軟件有限公司資深QA總監(jiān)朱少明點評道：

第一篇的下半部分更精彩，談到了百度QA的四大核心價值：全流程質量保障中心、用戶體驗測試技術能力中心、研發(fā)效率提升能力中心和人才中心。使大家更深刻理解全程軟件測試的意義，軟件測試=軟件產品的測試，軟件測試不是成本中心，它可以提高軟件開發(fā)生產力。期待更具體的分享。

百度測試團隊這幾年增加比較快，希望將來能看到百度分享一些移動測試方面、專業(yè)性很強的文章。