其實在開始聽谷歌的張南和潘巖開始演講前,瞭解下 Google Test Certified 會有所幫助。web
甚至,咱們今後次的演講中依然能感覺到,谷歌對創建測試認證標準的努力。下面咱們仔細聊聊此次的演講。less
產品由簡到繁需不一樣的測試體系來支持,如何在開發效能和測試效能以前尋找平衡點是每一個發展中的公司痛苦的事情。谷歌經歷了小城鎮式的開發模式到大都市模式,測試策略也從1.0到測試策略3.0。每一個階段的痛點都不同,所採用的對策也不同。測試模型從大致上,是從bug驅動到測試驅動,到3.0的數據驅動。對於測試的技術要求也是愈來愈高。從ppt上來看,谷歌在2.0階段已經實現了測試全自動化,這在業內仍是屬於領先的。這個有可能和谷歌的業務有關。至少到目前爲止,我經歷的項目中,手工測試的比例仍是佔了大頭(我記得7年前在谷歌作vender的時候,DE項目其實手動比例也有50%左右,可是其餘項目,好比谷歌的image啊,據我所知好像都自動化了)。工具
測試能放心地交給自動化,我想很大一部分應該得益於谷歌工程師的高素質和完善的 code review 機制。Ron Patton 的《軟件測試》中反覆強調一點:問題發現的越早,成本越低。需求階段發現問題,就能夠避免浪費開發資源,開發階段發現問題,就能夠避免浪費測試資源,測試階段發現問題,就能夠避免發佈以後的打patch啊,回滾啊,緊急發佈啊,從而避免線上故障帶來的直接損失。需求階段通常就依賴於強大的pd,可是pd通常都坑,post
因此開發就很是關鍵,而pre-submit 和 post-submit 這兩個階段就變得相當重要,提交前的code review 和提交後的冒煙測試和持續集成就是這兩個階段的利器。單元測試
谷歌的CR作的很是好,LGTM已經深刻人心。我記得我那個時候,提交代碼以後,CR個個把禮拜是正常的事情。碰見一次,搞了半個月,許多開發輪流CR。我還記得有一會測試提交代碼,而後國外的一個耿直boy直接CR後打回,totally useless,所有重寫。反觀咱們目前的狀況,CR大多數狀況是一種流程上的擺設,是開發從新把本身寫的講一遍,不會深刻細節,也不會觸類旁通。不少線上問題,若是有細緻的CR,就不會出現。測試
再來看持續集成,如今國內公司都愛持續集成,可是側重點在解決開發發佈或者出包效率,對於持續集成中的測試工做投入偏少。這可能和咱們的測試類型有關:ui
從咱們一直推崇的測試金字塔來看,本末倒置的很厲害。這樣也就把產品質量日後壓了不少,致使不少事情在集成測試階段以後才發現,而測試也疲於奔命。這也是老生常談的問題了。這麼多年了,彷佛也沒有解決的也很好。也彷佛只有谷歌這樣的公司,搞得不錯,但我仍是那句話,和業務有關。3d
從演講和PPT上不難看出,谷歌也在摸索移動測試。谷歌締造了安卓帝國,可是Android測試未必作的最好。從大會成天的topic來看,國內的移動測試實際上是領先的,有的甚至是超越谷歌的。好比,華爲對標谷歌的實驗室,好比騰訊的專項專題。不過因爲畢竟Android是谷歌親兒子,因此有些內部的能提高效能的工具仍是領先業界一大截,我記得谷歌就有一個內部adb,比正常adb好很是多。而後此次演講講到的 image diffing service,谷歌的移動lab等。code
可是我以爲技術都不是問題,咱們看後半程潘巖的演講,能夠明顯感覺到,他們是在從整個研發測試流程上來提高移動測試的效率,提升自動化比例,解耦普適性和移動特特性,提升可測性,並且也只有這樣,潘巖後面講的工具和測試平臺才能用的上。blog
2013年的時候,James Whittaker的《Google軟件測試之道》的書揭開了谷歌測試的神祕面紗,一度被國內捧爲測試聖經。這一次,張南和潘巖帶咱們再次走進谷歌測試,瞭解了谷歌的移動測試。其實能夠感覺到做爲先行者,谷歌作的很好,可是也沒有到趕超咱們一大截的地步。大道同歸,國內公司在移動上的實踐,方向和策略上也是相似的。我記得我一個老闆曾經說過,整個技術圈,80%都是差很少的,差異在20%的執行者。
這一次,你們瞭解了谷歌的移動測試,再看看本身公司作的,找到一些共鳴,找到一些認同,而後繼續探索和研究,這也是一種收穫。這大概也是在外面參加會議的意義。