詳細說說 Google Test Certified 的各級——Level 2,3

轉載請聯繫做者，謝謝！

 

 

 

• No releases with red tests
  基於Level1搭建的持續集成，持續發佈選用的CL(changelist)就能夠取自CI系統最後跑通的CL，由於持續集成中包含了冒煙測試，那麼發佈到開發或測試環境上的系統，測試關注的是其餘類別的用例。

• Require smoke test suite to pass before a submit
  在Level1中已經劃分出了冒煙測試集，在每次代碼審覈經過後，開發在提交代碼前再次運行冒煙測試，這樣保證每次提交代碼，冒煙測試都是經過的，節省了後期修復的成本。(不知道你是否遇到過開發提交代碼後通知測試能夠測了，但是你一訪問系統就碰到問題，因此相似的BVT是強制的，而且推到每一次代碼提交)
  代碼審覈工具能夠定義規則，只有經過冒煙測試後才能成功提交代碼到代碼庫，若是失敗，發送郵件給開發。

   

   

• Incremental coverage by all tests >= 50%
  這一步是真正的須要提交測試代碼。你團隊的新代碼至少要有50%是有測試代碼的。它沒有規定必定是哪一種測試類型，也沒有規定哪部分代碼，也不是每次變動都要有50%覆蓋率，而是新代碼總的覆蓋率要有50%。這樣方便團隊靈活的決定在何處什麼時候提升測試覆蓋率。開發能夠經過TAP工具跟蹤增長的覆蓋率。

• Incremental coverage by small tests >= 10%
  新代碼小型測試覆蓋率至少10%。從歷史數據上看，小型/中型/大型的比例是70/20/10，這個比率不是硬性規定，能夠給各團隊做爲參考。

• At least one feature tested by an integration test
  雖然小型測試很重要，用來驗證各個獨立組件是否工做正常，但同時也須要更大的端到端的測試來驗證系統功能是否正常工做。這個指標要求至少有一個集成測試來驗證一個功能點。好比一個webdriver用例來驗證web應用。

Level2除了持續發佈的配置，後幾項都與測試代碼相關，從中能夠看出，想要得到認證，須要搭建起UT框架，填充測試用例；須要搭建UI測試框架，幷包含一個用例驗證一個功能點

 

 

 

• Require tests for all nontrivial changes
  全部變動都須要有對應的測試，這個要求開始須要辛勤的勞動了。換句話說，這也是項目受益的開始。沒有測試你沒法發現開發過程當中的問題，對你的代碼修改是否工做沒有信心。測試是對代碼健康和穩定的投資，部分經驗和數據代表，Google認爲測試是一個軟件項目專業與否的標誌。因此這項指標是團隊承諾將測試看成開發流程一部分的關鍵點。

• Incremental coverage by small tests >= 50%
  小型測試覆蓋率至少50%，這是Level2的延續。

• New significant features are tested by integration tests
  新作的大功能都要有對應的集成測試，這個重要功能根據團隊本身定義。