上一次分享了google測試分享-分層測試，有很多自動化測試的政策和實施都要有一個重點和計劃，那這次會把google是如何來對sut制定測試計劃的分享下。
為了讓這些blog分享更有邏輯性，我打算分幾個專題來分享google測試相關的測試理念。
<a href="http://blog.sina.com.cn/s/blog_6cf812be0102vbnb.html" target="_blank">google測試分享-set和te</a>
<a href="http://blog.sina.com.cn/s/blog_6cf812be0102vctg.html" target="_blank">google測試分享-分層測試</a>
google測試分享-gta
google測試分享-測試經理
google測試分享-問題和挑戰
google測試分享-未來測試
在講gta之前，必須先講下測試計劃，而測試計劃對于很多人來說都不陌生，很多測試書籍裡面都會描述如何編寫一個好的測試計劃，需要考慮多少内容，當然，這個也是測試工程師面試的必備題目。在這裡，我隻想引用某個大師說的話：測試計劃本身的價值不是測試計劃最後的文檔，而是制作測試計劃的過程。我還想讓大家知道的是james bach有個很好的指導書，就是關于如何編寫測試計劃的。參考下面的圖:
《測試計劃圖》
這裡可以看到制定測試計劃的過程很負責，需要考慮很多因素，某些因素都會影響着計劃的有效性，雖然實際工作過程中，我們不可能一步步按照上面的方法去check這些因素，但是其思想和意識是值得大家思考的。相信各自團隊都有自己的測試計劃模闆，裡面會涉及到很多的内容。一般來說，測試計劃包含：及時地更新、描述了軟體的目标和賣點、描述了軟體的結構、各種元件和功能特性的名稱、功能和操作簡介。而且測試計劃還必須要避免散漫的文字，推薦使用簡明的清單；不必推銷；保持内容簡潔；不要把不重要的、無法執行的東西放進測試計劃；多采用漸進式的描述；真正的指導計劃者的思路；當然最終結果應該還是測試用例。但是我這裡還想強調三點：
第一點是這個看起來非常全面的測試計劃模闆是傳統行業測試的測試模闆，不适合網際網路産品測試的特點，之前做完一個項目的測試計劃需要2-3天，其中過程中就不說了，現在采用靈活方式來做項目，測試計劃隻需要2-3個小時就完成了，更多的也是類似于one page plan。
第二點是真正展現價值的不是最後輸出的測試計劃結果，而是得出這樣的計劃的過程，其中有多少是融合了執行計劃、政策、範圍、風險以及項目上下文背景資訊。
第三點是我們是否充分的了解測試計劃的共享性、有效性、可變性、以及在測試階段的引導性，這個說起來比較玄乎，其實這個是實時在在發生的，測試執行整個周期，我們的計劃肯定是改變的，都是我們展現出來了嗎；靈活變化的結果是否得到一緻認可；怎樣讓計劃和風險和範圍靈活變化且受控制；怎樣提前預估風險和計劃的差異性等。
同樣的，google也同樣認為測試計劃是最早出現、最先被遺忘的測試産物。但是google測試理念更加認為測試文檔的作用不可擴大化，測試人員不應該對測試文檔過于珍愛，大家最關心的是代碼庫，包括測試代碼庫。
為了充分的了解被測産品，google開發了一個測試計劃工具gta來展現被測産品和測試計劃的關系。gta：google test analytics 來記錄計劃裡面的acc（特質、元件、能力），這也是個開源工具：https://code.google.com/p/test-analytics/。當測試人員完成一個被測系統的acc設定後，有幾個測試政策可以參考：
（1）使用10分鐘編寫測試計劃：花費30分鐘左右，80%的完整性
（2）分組展示産品能力，按照測試組進行bug bash，或幫助執行探索式測試執行的計劃
（3）我們無法避免風險，但是我們首先需要進行風險分析，考慮兩個要素：失敗頻率和影響。然後進行打分。風險分析的目标不是對一個風險給出一個精确的值，而是要識别一個可執行的有優先級的執行計劃。
（4）邀請開發、pm、營運、pd、管理層一起review風險。
（5）te是緩解風險活動的協調人，決定對風險較大的領域進行内部測試，要求swe和set增加回歸測試。也可以借助dogfood使用者、beta使用者以及衆包進行測試
（6）te仔細思索高風險的區域，咨詢可能的復原和恢複機制。同時對風險最高的領域負有個人責任，必須編寫測試指導。
（7）對于風險較低的區域，可以降低要求，為這些區域編寫特定的測試用例是得不償失的，我們更多的是選擇探索式測試，或衆包測試。
（8）按照風險順序進行測試。原則：如果不能全測，就先測最重要的，也就是風險最大的。
補充一下，風險因子裡面的失敗頻率包括：罕見、少見、偶爾、常見。影響包括：最小、一些、較大、最大。
（9）te在了解了set和swe的測試後，評估這些測試對風險的影響，實時改變測試計劃和政策。對于高風險區域的每個bug都應該有一個回歸測試用例與之對應。
為了更多的引導開發自測以及團隊品質意識的培養，google測試團隊對一個開發團隊進行測試認證，完成了一系列的測試任務。set或te可能會變成測試認證教練。
google的te在編寫測試用例時，需要對tc進行标簽化，建立的時候設定name、content、public fables/ private fables。另外，對于使用者回報的bug，使用了聚類算法來自動識别充分記錄并确定最頻繁的問題。而測試人員自己發現bug後，應該花些時間細細品味。不僅僅是有權利享受自己勞動的果實，而且，了解此bug微妙的細小差别及其出現的條件是很重要的。還應該找同伴來分享他的發現。
現在再來了解下gta，gta是根據項目的acc得到項目的風險熱圖，再進行内部資料庫的綁定，比如bug資料庫、代碼樹、測試用例的位置或查詢，随着這些名額的變化，通過簡單的線性代數來自動更新風險級别。gta 包括這些内容：項目規格（項目介紹、acc）；風險（總覽）；導入資料（測試用例、bug、checkins）；資料設定（資料源、資料篩選）。
gta 可以很快的把能力清單變成一次測試執行，包括了一個簡單的概要測試用例清單。gta可以幫忙te根據測試執行背後的acc矩陣來配置設定測試人員。gta旨在使風險分析足夠的簡單和實用，以便人們能夠真正的用起來。
為了最高效的做web産品測試，google設定了一個零成本測試流程：通過gta進行測試計劃；測試覆寫度，quality bot區分回歸和新特性，區分手工和自動化測試；bug評審，利用bite來快速判斷；探索式測試，外包和早期使用者執行；bug送出，sut裡面進行bug快速送出；bug triage和調試；重新部署新版本回到第一步。
上面是大概說了下google是如何使用gta來管理整個測試階段，特别是測試計劃的安排，總的說來，流程開放、簡單、直接、有效。希望大家對google如何進行測試計劃和測試管理有一定的了解。下期準備分享google測試經理是如何帶領團隊進行測試技術創新和團隊管理的，google測試分享-測試經理。
轉載自：http://blog.sina.com.cn/s/blog_6cf812be0102viuh.html