Google上海如何測試搜索產品(2)

　　One Page Test Plan

　　整個產品的測試計劃一般就一頁紙但并不是說只能一頁紙，而是一個輕文檔的概念，里面包括了產品背景、測試策略、測試內容、哪些功能需要測試、哪些功能目前還沒有加入測試、使用了哪些測試類型、目前在線的功能、測試環境、日程/進度表、資源、風險和依賴等等。

　　針對具體某個比較大的功能模塊也同樣適用，也就是說測試計劃包括整個產品的還包括產品內部功能模塊的。

　　Test Env

　　見上文介紹，這里面還會有Global和Local的多語言環境，需要和其他辦公室的團隊協同工作。

　　Test Cases

　　測試用例在Google內部是通過一個叫TestScribe的工具來管理，各個產品創建自己的產品的測試用例，一般會根據頁面->功能來，產品所有測試用例創建好后，需要團隊來審核，根據反饋做修改，同時也要把發現的Bug當做用例補充進來。

　　Test Scribe里還有一個Test sets概念，也就是說根據不同的測試策略，從所有測試用例中選取相應部分保存成Test set，例如Basic Test、Full Test、Automated Test等等，當具體執行測試時，可以創建Build從這些Test sets選取合并在一起。

　　Bug

　　前面有提到過Bug庫是使用Buganizer來管理，但是Bug庫不僅僅是存放缺陷，需求和改進以及你認為有問題的都需要記錄進去，根據優先級跟蹤開發修復，同時可以根據不同類型，比如新功能或每周發布版本建立Hotlists，將對應的Bug保存便于跟蹤統計。

　　Test Report

　　測試報告，每一輪測試執行結束后，通過TestScribe都可以生成相應的測試報告，例如每周發布的回歸測試，會有對應的測試報告，記錄測試使用了哪些用例、發現了哪些Bug、嚴重程度如何，當然，也可以通過TestScibe和Buganizer提供的接口自己建立一個狀態頁面。

　　Matrix

　　搜索產品都是基于Web的，這就涉及到兼容性測試，需要根據具體產品監控的反饋統計出用戶的喜好情況，建立對應的平臺和瀏覽器Matrix，里面會有一個百分比關系，根據百分比來劃分優先級，分配測試資源。

　　Metrics

　　產品質量的情況反饋需要有一些度量，那么會建立哪些度量呢，需要建立一些矩陣：

　　a.發布的矩陣，哪些bug是手工測試發現的、哪些是自動化發現的、驗證了哪些bug、哪些是新功能的bug

　　b.每周回歸的矩陣，回歸發現了哪些新bug、回歸驗證哪些bug

　　c.功能發布記錄，某個新功能是在哪個版本第一次發布，新功能發布到哪個國家或地區，新功能做了第幾次試驗

　　Findit

　　大家一起來找茬，就是邀請所有員工來找bug，發現有效bug的員工會獲得一件T-shirt和其他獎品，T-shirt的圖標一般是一只狗狗拿個放大鏡照骨頭。有點類似于微軟的"bug bash"，但是這個是整個公司的，bug bash一般是在團隊使用，會在某個新版本發布前，整個團隊一起來找bug并且使用一周時間一起修復bug。那么根據多國家地區和多語言的特點，還可以分為ChinaFindit，JapanFindit，比如我參與的香港財經項目，就需要邀請懂粵語或就是香港員工來幫忙做一些習慣用語或當地風俗或當地使用習慣的測試。

　　TotT

　　Testing on the Toilet，在Google辦公室的廁所，你會發現墻上經常貼著各種文檔，這個是Google專有的廁所文化。

　　文檔一般都是各個產品使用工具或做測試的例子，目的是吸引所有工程師做更多的測試，這個文化被Google離職工程師帶到了百度，可惜他們沒有把頁首和頁眉去掉，模板也改改吧。

　　示例見此文，TotT: Better Stubbing in Python

　　四、工具

　　從上面可以看出，搜索產品一般是一周一發布的頻率(稱為Weekly Push)，測試人員除了做常規的RC測試，還需要了解新功能的需求、提早介入新功能測試、編寫測試計劃和測試用例，和開發人員協作提高代碼質量，那么時間有限，提高效率就需要工具的幫助，下面介紹一些使用到的工具或策略。

　　Clearsilver Diff Tool

　　我們知道測試里面的"二八原則"，很多新的功能會發現大量的bug，同時在舊功能也會發現由于新功能或是代碼修改引入的bug。

　　通過Diff工具，我們可以了解新版本和上一版本的區別，更利于測試資源的分配，關注修改部分的質量，而原有功能模塊的質量通過自動化來做回歸測試。

　　Selenium UI Automation

　　UI的自動化，其實解決的更多是各個瀏覽器上的功能測試，界面的測試還是需要通過人來查看，當然也可以通過UI自動化截取圖片，運行完成后統一查看。在搜索產品中有個原則，由于UI的頻繁變更，推薦UI的自動化率一般達到30%即可，太多了對于維護是個很大的成本。

　　Data Comparison Tool

　　數據比較工具，在財經搜索產品中使用，因為財經產品有些特殊，數據來源是第三方提供后解析保存到Google的數據庫，而不像其他產品都是爬蟲爬取的，使用這工具可以和其他流行的財經網站做數據對比。

　　提到數據的準確性，除了各個產品團隊對關鍵字的結果進行對比，Google還有專門的搜索質量團隊。

　　Lflip

　　內部工具，通過此工具，可以將TestScribe中的每條測試用例都嵌在Iframe中自動運行，不過每個測試用例都需要指定運行環境的URL。

　　Puppet

　　搜索產品中大量使用的基于JS的冒煙測試工具，在產品編譯后執行，可以提前發現問題。

　　Statix

　　性能測試工具，支持Jmeter的JMX文件，通常運用在每周發布后的回歸性能測試上，自動生成Dashboard，可以和上一周版本對比。

原文轉自：http://www.kjueaiud.com