我在百度做軟件測試工作的趣味性在於可以接觸到很多新IT技術的產品和把新IT技術知識應用到測試中，這些是我在百度最有趣的事。典型的代表就是如何儘可能找出不是bug但影響用戶體驗的設計問題，在百度被稱爲效果測試或產品評測。從測試目的而言這類測試不是發現軟件編碼的錯誤，而是發現產品設計的不足。應用的技術和方法有：基於大數據思想進行相關性分析自動挖掘數據badcase、衆測、百度TIP中的AB testing、產品評測體系。以我所瞭解的信息來看目前百度很多產品已開展了產品效果評測，如網頁搜索、圖片搜索、地圖搜索、視頻搜索、商業搜索、衆多的移動APP產品等。QA們在完成產品bug的挖掘後，會繼續進行產品validation的工作爲提升產品設計的用戶體驗繼續貢獻測試人員的價值。
今天我先分享下在百度學到的如何自動進行badcase挖掘的評測方法，因爲我覺得這是我在百度遇到的最有趣的一種新測試類型，很好地解答了我內心關於算法效果測試方法的疑惑。先介紹下什麼是badcase——“badcase是一個不符合用戶心理預期的產品輸出結果集”，例如：搜索結果中出現的“文不對圖”現象，以及低質量的輸出結果排在前面等現象。傳統測試方法中並沒有對此類問題現成的技術或方法，因此爲了從數千萬的輸入數據中找出那些輸出結果集質量不滿足用戶體驗的問題，靠人工的方式對每個輸出結果進行人眼判斷顯然是不行的。因此，百度的QA應用了大數據思想從數據的相關性入手，從大量的badcase中找到A現象與B結果的相關性，當我們得到一個可以達到80%以上相關性的準確率時就可得到一個靠譜的測試模型，當然這個測試模型天生就是自動化的，從而支持我們從海量的數據中自動地挖出海量badcase，而測試人員要做得就是設計這個自動挖掘badcase的測試模型。以前我們應用人工的方式進行相關性測試模型的規則抽取與驗證，後來開始應用機器學習的思想和方法，實現先自動訓練相關性測試模型達到一定準確性後，再應用這個測試模型自動的進行badcase挖掘。以前此類產品評測的最大困難是靠人工方式進行產品效果評估，一個PM一天能評估的輸入數據也就最多幾百個，而現在我們可以實現一天評估數十萬的輸入數據，工作效率提升上千倍。而這一切就是大數據思想和機器學習新技術應用到測試設計中的效果，自動化測試的概念又提高了一個新的層次。也許未來測試人員的工作方式會像我們的工作方式一樣：先基於業務專家經驗設計一個測試模型的架構和主要因子，然後通過真實數據集自動訓練測試模型得到測試模型中每個變量因子合適的取值範圍，最終自動得到一個測試結果高準確率的測試模型。未來是大數據時代，我認爲利用大數據思想不去追求精準的因果關係，而是追求相關性的準確性，將是未來測試設計師們必須要掌握的一種IT技能。
在過去挖出足夠數量的badcase是QA最大的挑戰，現在的新挑戰則變成了我們如何用最快的速度和最低的成本完成這些大量badcase的分析定位工作。通常第一步會自動地針對挖掘出來的badcase進行影響嚴重度的評級（依然是使用大數據思想和機器學習的方法），這樣可自動選出影響較嚴重的badcase集。第二步：如果產品形態支持通過構建決策樹模型自動地定位分析問題根因，那麼將通過設計自動分析定位系統對badcase集進行處理。如果某些產品形態不支持通過構建決策樹實現自動分析定位，則會通過百度的衆測平臺，引入用戶資源通過一些衆測活動來對badcase再次進行標註，這樣也能大大降低工程師分析定位的成本與時間。對百度衆測感興趣的同行可以到平臺test.baidu.com上去了解更多相關信息。在此我先簡單介紹下：百度衆測是國內第一個基於衆包思想實現的一種“人工測試雲”，它充分發揮公司產品愛好者的資源價值，不僅幫助發現產品bug還可以爲產品優化設計體驗提供用戶數據，例如：通過百度衆測用戶對badcase的標註可幫助QA收集大量標註數據爲改善產品效果貢獻價值。目前網頁搜索、地圖搜索、圖片搜索等產品都已通過衆測的用戶標註活動優化產品的效果設計質量和降低badcase的分析定位成本。
Badcase的自動挖掘和分析工作對於強算法類產品的用戶體驗改進幫助很大，而對於弱算法類產品如一些應用APP產品而言，百度QA則通過建立各自產品的評測體系的技術活動以量化方式對產品進行用戶體驗評測，產品經理和開發人員將根據評測結果輸出產品改進的story和非功能質量屬性的優化方向。
產品評測報告與傳統測試報告的區別在於：傳統測試報告是測試用例執行結果和bug數據的分析材料是用於分析軟件存在的實現錯誤。而產品評測報告更多是產品在不同用戶功能應用場景和非功能屬性應用場景的評價數據（例如不同用戶場景下的性能響應值和不同用戶環境場景下的兼容性表現），以及與同類產品的對比數據，因此對產品設計者（PM）會更有用戶體驗提升的指導價值，通過更直觀的產品用戶體驗數據支撐產品設計決策。QA則通過設計產品的評測體系對產品價值的貢獻不僅在於發現bug，還擴展延伸到直接爲產品設計和產品用戶體驗提升提供有量化數據支撐的改進方向。在百度內部移動APP的評測工作中會對APP在不同網絡質量、不同機型、不同軟件平臺版本下進行產品基礎功能、APP響應性能（業務級和系統級）、APP資源消耗性能（耗電量/流量/OS資源等）、UI流暢度等領域進行評測數據收集，QA會在評測數據基礎上先進行第一輪的數據分析給出定性的結論，給出改進的建議和技術方案提供給PM或RD參考。爲了最大化的提升移動APP的評測效率在內部除了各產品組獨立開展的評測活動外、還有支持一鍵評測的百度評測平臺對內部評測技術進行技術共享與重用幫助各產品QA提升評測工作效率。
測試人員要設計出一個靠譜的產品用戶體驗評測體系，必須先要對所負責產品的主要用戶場景（功能和非功能）有充分的瞭解和理解，以及用戶對產品體驗的需求有足夠完善的整理，才能對產品整體的用戶體驗進行科學客觀地評價。然後評測體系還需要做“橫向”同類產品、“縱向”歷史版本的對比測試，並根據產品的“設計思想”進行評測驗證是否達到預期的設計定位。最後通常一個好的評測體系一定是一個鬆耦合的產品測試平臺，在這個測試平臺上無論是自有產品還是其他公司的相似產品都能得到統一標準的測試數據評估，這樣能幫助QA/PM/RD對產品用戶體驗數據的價值進行更好的分析，從而提升產品競爭力。從某種角度看QA要做好產品評測體系就必須擁有至少“半個產品經理”的用戶需求場景知識，從這方面來看對QA的要求又提高了，不僅要懂軟件技術會挖掘程序錯誤，還要有豐富的產品領域用戶場景的知識（功能的/性能的/兼容性/穩定性等）。雖然對QA的技能要求提高了，但是無論對產品競爭力的提升還是對QA自身價值的提升都是有着很積極地作用。
另外我認爲在公司內只有QA最適合做產品評測體系設計這件事，產品經理PM更擅長功能性需求的設計和創新，對如何設計嚴謹和完善的測試系統並不是很專業（QA出身的PM除外）。RD則更擅長產品架構的設計和實現，擅長從白盒層面來理解產品，對於用戶應用行爲黑盒層面的理解則相比QA有限。而QA卻因爲長期從事功能和非功能的黑盒測試活動的經驗積累了很多產品在用戶體驗方面的知識，因此QA相比PM和RD更適合設計一個用戶體驗層面嚴謹的產品評測體系，而這也是QA在公司中獨特價值之一的體現。
最後我的感慨是大數據思想、機器學習、衆包、基於用戶體驗量化的產品評測這些所謂時髦的名詞已不只是虛幻的理論或概念，把這些新的IT技術和理念應用到質量保障工作中爲產品用戶體驗提升提供測試方法論，改變舊有的測試模式是已被實踐證明可行的、是有價值的。希望我此次分享的百度QA在用戶體驗提升領域的實踐經驗能幫大家更好地提升產品用戶體驗和測試人員在公司中的產品價值。