來百度工作有些日子了，在未進入百度之前，由于一直以來百度質量部在業界都是比較低調的，外部的測試同行很少能了解到百度的QA們是如何工作的，如何來應對互聯網的研發節奏和質量的平衡。因此我來百度后互聯網上經常都有測試工程師找我打聽百度的QA是如何做測試的？百度的測試是什么樣子？水平如何？對于現在正式QA數已突破1000人的百度質量部所覆蓋的工作范圍和內容是非常之多的，我也很難用幾句話全部描述清楚，因此很想根據我經過這些日子工作對百度質量部的了解，寫幾篇文章來較詳細的給大家分享百度QA是如何工作的。
開篇先說說百度QA們的特點：
從組織結構上百度所有的QA都歸屬于一個大部門百度質量部統一管理，在一個大部門下的好處是很容易一起跨產品線的協同作戰，各種測試技術和測試工具能以最快的速度得到傳播，避免重復造輪子的浪費。同時QA們能有一種更強的組織歸屬感、有著專業的發展通道與空間、關鍵能交到更多在QA領域與自己志同道合的朋友，擴展視野，所有QA都能從這種大資源池中獲益。這一點對所有做測試的人而言更有利于測試專業技能的持續提升。
從我工作所見和感受來看，百度QA有四個主要的工作挑戰：職責范圍廣（覆蓋完整的產品生命周期全流程）、 面對產品技術新（如移動互聯網、WebOS、推薦引擎）、研發速度快（互聯網的節奏）、大數據系統的復雜（百度本質是一個分析處理數據的公司）。這些挑戰長期影響著QA日常的工作方式，使得與傳統的tester有著工作模式的不同。
百度QA的工作范圍覆蓋了百度所有形態的產品從基礎架構的分布式系統、搜索架構系統、到搜索算法、Web前端、Windows客戶端、手機客戶端，以及最新的多媒體技術、機器學習等這些前沿的IT業務，因此在這里我能最廣泛的接觸到各領域測試的QA同行，聽聽他們的分享，擴展我的測試視野。當然我也有機會到各領域進行測試實戰，從我到百度算起，我已在web前端、windows客戶端、手機客戶端、搜索架構系統、搜索算法、圖片搜索領域進行了各種測試實踐工作，大大豐富和完善了我的測試技術知識體系，受益不少。
另外百度QA會更完整參與到產品研發流程的周期，從最早的MRD，到設計評審、到產品發布后的效果評測是端到端的參與完整的產品生命周期。與我過去經歷最大的區別在于，QA與PM（產品經理）打交道的時間非常多，在整個產品生命周期中幾乎是同步一起從頭到尾密切配合，同時QA還會為PM設計并開發用于產品評測的平臺對產品設計的影響會更多。對于QA與RD的關系，QA不僅只是響應RD提交代碼的測試，還會主動去幫助RD如何更好地做好UT（單元測試）、如何做好code review?；诎俣萉A職責范圍的擴大，在百度QA工程師的職責和發展路線上目前來看已大致分為QAD和QAT，至少我在進行職稱評定的評審時，已會有意識的區別評估。QAD就是QA中的軟件開發者更多側重測試工具和測試系統的軟件開發，我在參加QAD任職評審1對2活動時，基本是以一個對軟件開發者和軟件產品設計者的角度來進行review，關注其代碼質量、軟件架構設計思路和產品設計思路的能力。QAT則是標準的Tester，偏重如何盡早的發現更多軟件質量問題，要求精通產品的應用場景以及各種測試類型。因此各種風格和興趣的QA都可以在百度找到自己希望和喜歡的角色，當然有時QAT和QAD也會互換，我個人而言，認為相對而言QAT轉QAD容易，QAD轉QAT要難些，因為百度的QAT大多具備一定的軟件開發能力，平時也會根據工作需求自己做一些自動化測試開發和工具開發的工作。而QAD要轉QAT則還需要補充多種測試類型的知識技能，以及產品的業務知識。我在這里目前算是QAT路線，大多時間在思考如何設計更完整的測試避免問題遺漏，以及如何讓測試人員在短時間內發現更多的深層次問題，當沒有QAD資源來幫助你時，也會自己設計與實現一些小規模的測試系統或測試工具。如果未來某天我的興趣轉換到了QAD的工作內容了也是比較容易獲得機會轉換的。所以當QA工作的平臺足夠大時，個人的興趣也會得到最大化的滿足。
在日常的工作中很多百度QA常常還會面對很多新產品技術的挑戰，這里的“新”是指新形態的互聯網產品（機器學習、推薦系統、多媒體搜索）以及新的軟件應用場景（移動互聯網和Webos），這些新的被測對象所帶來的直接挑戰主要是業界很難有現成的完整的測試方案及測試技術，于是不得不逼迫百度的QA比傳統軟件測試的Tester更加持續地進行測試技術的創新才能滿足“新”產品的質保需求。例如：我今年參加的整個百度質量部層面的移動互聯網測試技術專項topic組的工作，就不得不去填補諸多業界在移動APP穩定性測試領域、性能測試領域、自動化測試領域技術的空白，否則無法達到真正對高質量用戶體驗的追求。當業界大多數APP的穩定性測試只依賴Monkey測試工具時，Monkey測試已只占百度最新APP穩定性測試用例類型不到10％的覆蓋面，其他90％的穩定性測試方法大多是業界還未知但APP應用又必須要考慮的，否則就會出現“為什么用戶會碰到而我無法重現的問題”。當業界還靠移動機型窮盡進行兼容性crash問題的覆蓋時，百度的QA已設計實現了基于靜態代碼自動掃描的兼容性crash問題的快速測試。當很多QA還在為如何在不穩定的2G網絡下得到穩定的測試結果而苦惱時，百度QA已靠不到1000元的低成本技術方案很好地解決該問題。同時在完善移動APP測試方案的過程中QA內部還設計開發了不少APP測試工具填補了業界在移動APP測試領域的很多空白。經過我對內部信息的了解，之前官方對外宣傳較多的移動云測試MTC只代表了百度QA在移動互聯網領域測試技術積累的一部分而不是全部。所以我希望下一步有機會百度質量部能逐漸給業界分享出來，讓大家都能受益從而減少移動互聯網測試的煩惱和困難。據我在百度的觀察我個人總結了一個規律：中國人并不缺創新能力，而是缺逼迫自己去持續創新的壓力和平臺。正是由于百度QA所處的工作環境和測試對象的特點，逼迫他們不得不去創新，結果QA個人的創新能力在不斷提升并形成了創新的習慣。我在這樣的環境下，一年下來自己的創新效率感覺比以前也提升了一倍以上，發現原來測試很多領域都有著創新的可能與空間。有朋友問我在百度累嗎？我說相比過去身體不累但腦子累因為經常都在思考如何創新地解決所遇到的各種沒有現成方案的測試問題。
（第一篇上半部分結束，我會繼續編寫第一章后面的內容，請各位繼續關注）
版權聲明：本文出自 架構師Jack 的51Testing軟件測試博客：http://www.51testing.com/?293557
原創作品，轉載時請務必以超鏈接形式標明本文原始出處、作者信息和本聲明，否則將追究法律責任。