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

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

　　大數(shù)據(jù)給百度測試團隊帶來哪些挑戰(zhàn)

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

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

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

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

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

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

　　測試組織的具體架構介紹

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

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

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

　　百度測試團隊人員構成

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

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

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

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

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

　　給年輕入行者的成長建議

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

　　預期在11月深圳WOT峰會上分享哪些內(nèi)容

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