大數據時代已經來臨，百度的測試團隊在這個時代遇到了很多挑戰和難題，他們是如何解決并進行發展新探索的呢?目前測試團隊的構成情況是怎樣的，對于新入行者又有哪些指導建議?帶著這些問題，51CTO記者采訪了百度測試經理錢承君老師，他將為大家深入解析這些問題。　　

　　錢承君，具有多年互聯網研發、測試、管理經驗，在基礎架構與大數據方向有著豐富的實戰經驗。曾任職大眾點評研發，參與了點評團隊最初始的設計。目前負責百度大數據測試部門的技術管理工作，下屬團隊規模百人左右。

　　大數據給百度測試團隊帶來哪些挑戰

　　大數據相關的測試其實已超出傳統的測試范疇，按IEEE對軟件測試的定義，軟件測試是驗證(verify)軟件系統吻合需求定義(requirement and specification)的行為過程，更多地偏向傳統的工程類軟件項目。常用手段是構建系統的輸入與預期的輸出，來確保系統符合預期。

　　但是，從大數據的角度來看，整個測試理念和測試方法已經出現非常大的變革。我們拿百度搜索來舉例。首先，測試輸入無法窮舉，可以輸入的內容千變萬化，按傳統測試的方法論，覆蓋工程實現的邏輯分支遠無法確保結果的質量。其次，輸出內容怎樣算是正確的，沒有一個定論，奇差的結果，完全不相干的結果， 用戶能直接說這個返回不行，但可能就有一個更好更貼近搜索的結果沒有被返回啊!這個系統的輸出，一直在“理想中的好”和“極致的差”之間游移，傳統的測試方法論未必能給出解答。這就是一類典型的“non-test-oracle”問題，這類問題非常常見，例如電商的結果推薦。對于大數據類的場景，除了做好傳統的、工程上的、代碼準確性的驗證，還需要對產品本身的質量進行“驗收(validation)”，這些是我們要探索的內容。

　　測試團隊工作中遇到的最大難題

　　從工程實現的角度，相對于一個小型網站或手機應用，做大數據或者底層的基礎架構是更困難的。百度涉及的數據規模超出了一般開源系統能承載的范疇，例如需要跨機房，需要混用計算密集與存儲密集型設備。當自行改動一些復雜的基礎架構，例如改造Hadoop，或索性自研發大型分布式文件系統等，由于技術的復雜度，對質量保障的要求是非常高的。

　　從數據的測試方法論的角度，針對算法、針對大數據挖掘的結果，判斷這些產出是否吻合用戶需求，以及幫助業務持續提升數據質量，是一個持續探索的話題。百度搜索每一段時間都要更新策略與搜索內容，或許某一次發布對用戶的搜索體驗有了壞的影響，質量團隊需要評估、預判、防衛這些問題的發生，也需要在發生問題的第一時間捕獲、定位、止損。這是一項很困難的工作。

　　從團隊建設的角度，由于當前整個行業的低技術含量工作更多，較難培養和吸引更多優秀的人才加入我們，來從事這些復雜的工作。團隊對人員的要求在持續上升，但從業人員的素質沒有及時跟上，對于團隊的組建會非常困難。

　　測試組織的具體架構介紹

　　這里介紹幾種常見的測試組織結構。從匯報關系角度看，常見的測試團隊有兩類，一類是測試團隊隸屬產品線與特定業務，屬于業務的一部分；一類是整個企業共享質量團隊，屬于企業的基礎技術服務。在百度，測試團隊的組織架構屬于后者，是一個近兩千人的大部門，直接匯報給技術高管，下屬子團隊與業務一一對應，但沒有匯報關系。值得一提的是，也有各種知名的例外，例如谷歌模式中，測試資源是流動的，測試人員具備某種專業能力，可以是某種工具的使用，可以是提升可測性的經驗。這些流動的資源進駐到產品線，把相應能力帶給產品線，離開后相應的能力會在產品線留存。

　　測試團隊內部，曾經比較流行的是細分工，在一些傳統的大型企業還有留存，有專門管流程實施的，有專門做工具平臺的，有專門負責發布的，有專門負責管理外包的，有專職做測試設計與測試執行的。每個人所做的工作是整個研發閉環中的一個小部分。這種模式在快速變化的互聯網團隊中不能很好適應，逐漸演化成百度目前的做法，百度的測試工程師更偏全棧和綜合，每個人既需要懂業務，也需要能從代碼中定位問題，還需要能開發工具。這種做法對工程師能力要求很高， 對個人發展很有好處，但是對公司來而言，是需要付出額外的培養成本的。到目前為止，百度仍堅持高技術標準，是一家秉持技術信仰的公司。

　　百度目前的測試團隊，鼓勵測試人員做一些橫向的流動，期望人員有更全面的視野，曾經也有不少測試人員在經驗豐富后轉崗產品經理或者研發，因為培養的路徑比較好的補足了各種短板，是很受歡迎的復合型人才。

　　百度測試團隊人員構成

　　百度各個測試團隊情況不同，我所在團隊由于需要涉及基礎架構與大數據，比較特殊，行業中沒有太多對口的人力資源。團隊成員主要包含幾類來源：第一類是工作時間不太長還有持續培養潛力的社會招聘，比如我們招到過來自一線公司從事分布系統開發的工程師。第二類是高級別的架構師，匹配的人才非常少。第三類也是最大的團隊人員構成，吸引優秀畢業生，并給更大的空間，持續培養。有些學校的實驗室有非常對口的背景，比如從事大數據方向 data quality 研究的，比如做分布式系統中調度算法的，比如一些有機器學習與挖掘背景的。團隊主要構成是一線院校的碩士研究生。我們的團隊一直在持續尋找優秀人才的加盟。

　　研發、測試和運維三塊工作是一個密不可分的整體

　　從研發到測試到運維，很難去切割那塊是誰的工作，很多已經走向融合。現在很流行說的詞是全棧工程師，一個人從開發做到測試做到運維。通常情況下，測試團隊在這些場景與運維會比較密切地合作：

　　1.項目發布后的風險與預案，一般由開發、測試、運維多方聯合演練。很多系統未自動恢復的容錯場景是需要人工介入的，這時候需要測試人員評估這些風險和模擬場景，并促成預演。這樣的演練可以在線上，在預上線環節，也可能是在線下環境。

　　2.很流行的一個概念叫“test after release”。現在越來越多的場景過于復雜或資源消耗過多，尤其是談到大數據，動輒幾千臺機器，線上環境很難保證與生產環境的一致性。所以主張在上線 之后，在運維監管和看護下，對線上注入一些異常，注入一些抖動，加一加壓，來查看系統在極端環境下的表現，這是運維跟測試比較好的結合點。

　　給年輕入行者的成長建議

　　真正好的工程師不論先進入哪一個行業，或者進入哪一個角色，從事測試、研發還是運維，你真正關注的應該是這個角色之外的東西，注重培養和修煉在某一個領域上的強積累，這個積累是別人很難通過看幾篇文章，做一個小APP那么容易獲得的，這里的重點是需要找到能夠持續積累的領域。我們看到很多年輕人隨著行業浮躁，不愿意深耕和積累，頻繁跳槽來獲取現金回報的增長。其實最終一個人才的價值在于稀缺性與不可替代性，需要找到這樣的一個能持續積累的領域，在深入之后別人很難在數年時間內超過你，這才是專業人員的修煉正途。

　　預期在11月深圳WOT峰會上分享哪些內容

　　在51CTO WOT 2015峰會上，錢老師會介紹三方面內容。首先是大數據帶給測試的挑戰以及我們目前探索到的一些應對方案。其次是大數據能力對質量保障乃至研發的過程帶來哪些新的可能性。最后，相信也是更多人感興趣的部分，會聊聊百度大數據在做什么，未來的走向如何。敬請期待！