詳細說說 Google Test Certified 的各級——Level 1

轉載請聯繫做者，謝謝！

當你做爲初創企業或項目的惟一測試人員，一我的一槓槍，你如何開始測試的工做？你是做爲一條孤狼，面對10個甚至更多的開發，努力的作一條龍服務(加班加到死)；仍是想從1到11的轉變？

也許你聽到過這些話：

 

 

 

 

2006年Google內部2位工程師建立了一個項目叫Testing Grouplet(這是一個20%時間的項目，Gmail就是20%時間孕育的產品)，此項目旨在推進開發人員測試，這是一個文化轉變的項目。

 

• 提升對自動化測試重要性的認識
• 經過不斷改進測試框架和組件來減輕編寫測試的痛苦
• 提供信息和指導開發人員達到良好的測試實踐

咱們的座右銘：Debugging sucks. Testing rocks.

 

 

Testing Grouplet下面又包含好幾個項目，好比Testing on the Toilet(每週在廁所裏貼張測試小技巧)， Design for testability principles(代碼可測試性)還有今天要介紹的Test Certified。
以上交代下TC背景，下面開始解說下TC Level 1，如何從0到1。

---

 

 

 

• Set up test coverage bundles

代碼覆蓋率系統能夠識別你運行的測試針對的是哪行代碼，這有2個好處，1個能夠查看哪些地方須要更好的覆蓋，另外一個是能夠衡量覆蓋率，以便改進。內部基礎工具提供了一個代碼覆蓋工具，只須要在build文件中加上配置，那麼在代碼審查的時候，代碼審查系統會自動計算覆蓋率，默認使用的是語句覆蓋，若是須要條件/斷定覆蓋，那麼修改配置就好。
Google內部是使用blaze(如今開源了，叫Bazel)來編譯代碼，只須要配置build文件，對於開發人員來講沒有壓力，第一步就這樣走出了。

 

• Set up a continuous build
  搭建持續集成，相信不少公司已經這麼作了。Google的持續集成系統叫作TAP (Test Automation Platform)，開發每提交一個CL(changelist)， TAP系統就會進行編譯和測試。
  可是僅僅是持續集成仍是不夠，若是編譯失敗或是裏面的測試失敗，須要及時的修復，因此須要從開發人員中徵集志願者來組成一個build cop，及時的處理失敗，這樣後續的發佈系統才能拿到跑綠的Cut CL。

• Classify your tests as Small, Medium, and Large
  將測試分紅小型、中型、大型，爲何不叫單元測試、集成測試、系統測試呢，這是由於要和系統資源匹配，當在代碼中指定測試的size(一個簡單的標識)，那麼基礎工具分配給相應的資源。雖然說Google的服務器分佈在世界各地，幾百萬上千萬的服務器分配到內部成千上萬的項目後也是緊巴巴的。

   
  
  理想狀態下你須要不少小規模快速的測試來覆蓋大部分的代碼，這樣你可以快速的獲得運行結果來修復問題。這是一個單元測試養成習慣的過程，隨着項目的進展，提交單元測試成爲吃飯睡覺同樣的天然。

   

• Identify nondeterministic tests
  識別不肯定行測試。對同一個代碼運行測試後會獲得不一致的行爲，可能有幾個緣由，好比測試依賴外部系統，測試運行須要某種特定條件(時間或地點)，相互干擾的測試。
  那麼你確定不但願這類測試打斷持續集成，這樣會浪費時間精力來定位究竟是失敗仍是flaky，提早隔離出來單獨運行分析。一樣的在build文件中能夠加入規則。

• Create a smoke test suite
  建立一個冒煙測試集，冒煙測試不能發現全部問題，可是能夠保證產品功能主幹正常運行，能夠發現最大的問題。持續集成加入冒煙測試後按每CL的頻率運行，這樣團隊對產品的信心更強。

---

完成Level 1大概也就1個月的時間，這個過程可讓測試人員和開發人員緊密的合做起來，同時也給開發人員不斷灌輸質量的意識。