一淘網(wǎng)測試架構(gòu)師黃利在他的博客上發(fā)布了翻譯的一個專題系列文章：《谷歌如何測試》，整個系列文章從全局到局部地介紹了谷歌有關(guān)測試的情況。

譯者黃利在《譯者序》中闡述了在軟件開發(fā)模式（尤其是互聯(lián)網(wǎng)）中，近幾年的快速迭代發(fā)布，以Beta版本線上運(yùn)行，讓大家對測試產(chǎn)生了一些誤解：

• 這些應(yīng)用沒有經(jīng)過很好地測試，好多功能使用上都有問題；
• 測試水平比較有限，沒有能及時的發(fā)現(xiàn)潛在問題；
• 測試本身沒有太多的技術(shù)，基本上是功能確認(rèn)，點點鼠標(biāo)、搭建環(huán)境驗證下就可以；
• 只要認(rèn)真仔細(xì)，有責(zé)任心就可以做好測試；

這些誤解讓很多人特別是應(yīng)屆生，都不會把測試作為職業(yè)規(guī)劃來考慮，黃利表示:“想通過這個系列的討論，讓大家清楚測試工作如果做好，方法其實并不是想象中的那么簡單和表面上的膚淺，是非常好有挑戰(zhàn)的。”

關(guān)于《谷歌如何測試》，黃利已經(jīng)翻譯了六篇：

? 第一篇：介紹谷歌工程生產(chǎn)力部門構(gòu)成，以及這種測試人員的項目分離和匯報組織結(jié)構(gòu)的優(yōu)點與缺點。

谷歌沒有真正的測試部門，測試依托在各個產(chǎn)品部門里，即“工程生產(chǎn)力”，這個部門由以下幾個團(tuán)隊組成：工具產(chǎn)品團(tuán)隊（負(fù)責(zé)內(nèi)部和外部開源的促進(jìn)生產(chǎn) 力的工具開發(fā)與維護(hù)）；服務(wù)團(tuán)隊（給產(chǎn)品部門提供一些專業(yè)的建議，包括一系列工具、文檔、測試、發(fā)布管理、培訓(xùn)等方面，這些專家建議涵蓋可靠性、安全、國 際化等，甚至包括產(chǎn)品團(tuán)隊面對的功能問題）；嵌入式的工程師（在需要的時候被產(chǎn)品部門高效地“借”去使用）。

在測試人員的這種項目分離和匯報組織結(jié)構(gòu)中，其優(yōu)點是開發(fā)和測試將具有相同的地位，缺點則由于測試人員被看做外部資源，產(chǎn)品部門團(tuán)隊不能對測試人員有太多的依賴，他們自己必須要合理地控制產(chǎn)品質(zhì)量。

? 第二篇：為了讓開發(fā)人員效率提升，特別是在質(zhì)量方面的提升，在傳統(tǒng)的軟件開發(fā)人員的之上，增加了幾個角色，特別是需要工程技術(shù)方面的特殊角色。

將工程師的角色細(xì)分為：軟件開發(fā)工程師【SWE，Software Engineer】， 就是傳統(tǒng)的開發(fā)人員；軟件測試開發(fā)工程師【SET or Software Engineer in Test】，和軟件開發(fā)工程師一樣是開發(fā)工程師，主要負(fù)責(zé)軟件的可測試性；軟件測試工程師【Test Engineer】，和軟件測試開發(fā)工程師【SET】恰恰相反，主要工作是做測試而不是開發(fā)。

從質(zhì)量的角度來看，軟件開發(fā)工程師對功能開發(fā)和質(zhì)量負(fù)有全責(zé)，軟件測試開發(fā)工程師是提供測試支持的開發(fā)人員，軟件測試工程師的職責(zé)就是最終用戶級別的測試。

? 第三篇：質(zhì)量不等于測試，“質(zhì)量不是被測出來的”。

最簡單的辦法是不要區(qū)分開發(fā)和測試，不要把他們當(dāng)成對立的活動。測試和開發(fā)【注，兩種行為，不是人】最好能手牽手的并行，寫一點代碼就立刻進(jìn)行測 試，寫的越多，測的就要越多。最好是，在編碼的同時，甚至在編碼之前，就考慮清楚這些代碼將如何被測試。測試不是一個單獨(dú)的工作，測試就是開發(fā)的一部分。 所以，質(zhì)量并不等同于測試，當(dāng)把開發(fā)和測試混在一起，攪拌直到分不清他們彼此的時候，就得到了質(zhì)量。

對于質(zhì)量來說，預(yù)防問題比發(fā)現(xiàn)問題本身更重要。質(zhì)量是開發(fā)人員的問題，而不是測試人員的問題。通過把測試工作融入到開發(fā)過程中，我們能降低那些富產(chǎn) Bug的人的出錯機(jī)會，不僅可以避免了大量最終用戶的使用問題，而且還可以極大地降低測試人員報無效Bug的數(shù)量。在谷歌軟件測試工程師的工作目標(biāo)就是檢 查這種預(yù)防措施是否有效，軟件測試工程師不停地尋找一些證據(jù)來證明作為bug的作者和預(yù)防者的“軟件開發(fā)工程師-軟件測試開發(fā)工程師”組合是否存在問題， 一旦發(fā)現(xiàn)任何不正常，就會拉響警笛。

?第四篇：從爬到走、走到跑的模式，在一個產(chǎn)品的核心模塊被開發(fā)后，如果有一定數(shù)量的受益人群就立刻發(fā)布，然后不斷的得到用戶反饋再迭代開發(fā)新功能。

這樣爬、走、跑的模式對分析也有益處。例如，發(fā)現(xiàn)了一個bug，測試人員可以根據(jù)這個bug創(chuàng)建一個測試用例，并針對所有的每一個版本都運(yùn)行這個測試用例，從而可以驗證這個 bug fix是否在所有的版本中都真正得到了修復(fù)。

? 第五篇：測試范圍的定義，以及自動化測試和手動測試。

“哪些需要被測試及測試范圍的確定，這是一個動態(tài)變化的過程，在不同的產(chǎn)品之間會有比較大的差異。谷歌更傾向于頻繁發(fā)布，從產(chǎn)品的外面用戶那里得到反饋之后再迭代開發(fā)。”

“自動化測試和手動測試，對于所有的三種類型測試【小規(guī)模、中等規(guī)模、大規(guī)模測試】來說當(dāng)然更喜歡前者。如果能夠被自動化，而且不需要任何人智力和 直覺判斷，那就應(yīng)該把它變成自動化的。只有在特別需要人為判斷的時候，例如用戶的界面是否漂亮、或暴漏一些涉及用戶隱私的內(nèi)容時，在這些情況下應(yīng)該保留手 動測試。

對于谷歌來說非常重要的是仍然使用了大量的手動測試，不管是使用文本記錄的方式還是使用探索性測試，雖然有些已經(jīng)進(jìn)入了自動化測試的視線。業(yè)界使用 的錄制技術(shù)將手動測試轉(zhuǎn)變成自動化測試，可以在每個版本后自動地重復(fù)運(yùn)行，這樣保證了最少的回歸工作，并把手動測試的重點放在新問題上。而且，谷歌已經(jīng)將 提交BUG的過程和一些手動測試的日常工作也自動化了。

人類智慧的最后一英寸”體現(xiàn)在測試設(shè)計上，谷歌的下一代測試工具也正在這個方向上努力嘗試，將其自動化。

? 第六篇：軟件測試開發(fā)工程師【SET】的生命

“軟件測試開發(fā)工程師【Software Engineers in Test】是軟件工程師，專注在測試實現(xiàn)。首先，軟件測試開發(fā)工程師是開發(fā)角色”

“通常來說，軟件測試開發(fā)工程師不會在早期設(shè)計階段就介入。”

“當(dāng)我說“測試”時，并不是僅僅意味著單純的檢查驗證代碼路徑。測試人員不是從開始就參與進(jìn)來的，但“測試”卻至始至終都有。實際上，一個開發(fā)嘗試去check in代碼的時，測試人員的影響力在這個時刻可能就已經(jīng)顯現(xiàn)出來了。”

轉(zhuǎn)載于:https://www.cnblogs.com/shihao/archive/2012/07/28/2612735.html

總結(jié)

以上是生活随笔為你收集整理的“窥探”谷歌测试的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。