天貓技術專家：測試十二年，六道輪回后的初心能否找回

摘要：?本期作者簡介：高翔，天貓技術部測試開發專家。很久沒寫文章了，之前測試十年，也是在自己有變化的時候，強迫自己寫了一篇文章，說了自己的困惑和痛苦和思考，也得到一些共鳴。現在測試十二年了，相當于一個輪回，也有一些新的痛苦和感悟，趁還在這個圈子里面，紀念一下，當然了，YY比較多，干貨也不多，反正紀念下，或許我是真的不太可能寫測試15年的文章了。

本期作者簡介：高翔，天貓技術部測試開發專家。

很久沒寫文章了，之前測試十年，也是在自己有變化的時候，強迫自己寫了一篇文章，說了自己的困惑和痛苦和思考，也得到一些共鳴。現在測試十二年了，相當于一個輪回，也有一些新的痛苦和感悟，趁還在這個圈子里面，紀念一下，當然了，YY比較多，干貨也不多，反正紀念下，或許我是真的不太可能寫測試15年的文章了。大家有任何問題，歡迎討論，歡迎吐槽。

其實寫這篇文章之前，我一直是猶豫的，感覺寫不出啥花樣來，一是因為水平有限，另外就是因為測試這個圈子里面說不出啥新花樣出來，還是老生常談的那些，而且不同水平的讀者想看的內容也不一樣，很難寫的深入人心，反正真的差點放棄了；但是我內心是渴望的，想說些那些不一樣的，了解我的人都知道，我是不甘平庸的，是有自己的思考和底線的，很多時候可能被現實打敗，但是我還會站起來，繼續戰斗。

12年 / 這兩年我干了啥

我是一個很懷舊的人，簡單說說這2年干啥了，這兩年做天貓新零售的業務，這是一個新業務，大家應該理解新業務的背后的意義吧，我這里就不贅述了，團隊成員都非常給力，拿到了不錯的結果；其實大家都知道，測試在一個業務的發展過程中，自己能起到了哪些作用，不管這個業務是發展了多長時間，我們都是會經過三步走，很多時候我們就是在平衡這三步的比例和深度。

【質量】

測試人員核心的產出，發現bug，提升產品質量和用戶體驗，盡量少的把bug遺漏到線上去，讓用戶或者監控發現；是的，這兩年來，對于一個新業務來說，我們在這么多、這么變、這么復雜的需求和迭代項目中，我們拼勁了全力，新業務的質量有了穩步的提升，線下bug的數量、線上bug的數量和趨勢、系統的穩定性等各個角度來看結果，都說明了我們真的不錯，是的，這是我們的基本工作，也就那樣吧。

【效率】

對于一個新業務，對測試效率的要求也是更加考驗，新零售是鏈接線上和線下、商家和消費者之間的橋梁，我們在測試效率上也是面對很大的考驗；是的，這兩年來，對于一個新業務來說，我們在這么多、這么變、這么復雜的需求和迭代項目中，我們繼續拼勁了全力，新業務的研發效率有了穩步的提升，開發自測質量提升、初級bug、ISV對接效率、全網回歸效率、10+測試數據工具等各個角度來看結果，都說明了我們真的不錯，是的，這好像也是我們的基本工作，有了一些進步，還不錯的，不過也就那樣吧。

【技術驅動業務】

你是開玩笑吧，是的，我沒有開玩笑，對于測試來說，驅動業務簡直是難如登天，開發是天生的，測試是后天養的；天貓智慧門店在線下業務的拓展過程中，我們對每一個商家、每一個線下門店都會有質量的責任，我們經歷過雙11，經歷了痛點。是的，這兩年來，對于一個新業務來說，我們在這么多、這么變、這么復雜的需求和迭代項目中，我們再次拼勁了全力，我們在商家業務配置檢查、商家ISV驗收、線下門店預演等一系列的結果上來驅動天貓新零售商家和門店的規模化發展，我覺得我們是技術驅動業務了，為業務高速發展提供了保護傘，都說明了我們真的不錯，是的，這好像也可能是我們的基本工作，有了更多進步，還不錯的，不過好像技術含量比較低，擴展性一般，其實也就那樣吧。

好吧，剛剛都是自夸，看不下去了吧；其實我想說的是，這兩年，我們做的還不錯，各個層面都有結果，特別是第三個層面的，有的時候是可遇不可求的，總體上團隊能力和技術都有提升，但是在某些結果上的確不讓人滿意，我們的一些測試大佬們既要、也要、還要、反正什么都要，你要是哪個沒有，不好意思，只能這樣了。說實話，我有時候也能理解他們，真的理解。

12年 / 國內測試都在關注啥？

這個話題有點大，其實真的不敢寫，但是無知者無畏，雖然在阿里干測試9年多了，自我感覺蠻了解的，比起”阿里測試都在關注什么”，我覺得我更敢寫這個，其實也有點心虛的。這些年，我一直專注在我們自己的業務和系統、測試問題，這些細節非常多，我們的目標和規劃都圍繞這個來，非常接地氣；是的，說這個就說明我對國內測試在發生什么，在追求什么，其實對細節了解不多，但是在微博、在大會的主題、在相關的ppt和群討論中，還是能感知到一些的，接下來就說說，很多理解不一定對和全面的，歡迎大家補充討論。

在正式的說之前，大家回想我之前說的一句話，我們干測試的，很多時候就是在平衡這三步的比例和深度，在質量、效率、驅動業務上不斷的調整策略和戰術，根據不同的業務階段、根據不同的目標、根據當前的大事件驅動等。
我們最怕干的是就是平衡，因為平衡的好，前途光明，平衡的不好，萬丈深淵。大家都知道我們干測試的，雜活特別多，很多事情都需要投入一點，很多事情做起來很多人看來也沒有亮點，那我們很多時候就是在不斷的平衡一些事情，但是不管怎么樣，我們的目標還是比較聚焦的，就是對應自己的業務和開發技術，以及未來的業務發展，在質量和效率上如何做的更好，成本上越來越低，解決方案也越來越有技術含量。

大家都知道，不同行業對應測試的要求是不一樣的，那么測試技術和要解決的問題也是不一樣的，但是有幾個套路其實是差不多的，大體上分這幾個方向。

基于模型的測試：這塊領域很多人不太熟悉，而且在不同的行業的實踐和效果是差異比較大的，但是不能否定這個方向帶來的價值，在通訊、IOT、嵌入式等領域都有非常多的實踐，效果也不錯，我認為是測試前移比較重要的一塊；但是很多人對于這塊只是基本的了解，很多時候都有可能直接放棄；最后的結果，可能是我們的開發同學先開始業務建模，先開始各種模型抽象，提升開發效率，然后再到測試的模型和效率提升，很顯然，我們是被動的，而且很多時候我們錯過了一些風景，可能感知不到呢。
可測試性：這塊話題，其實是大家聊的比較少的，因為很多方面是偏理論的，真正落到實踐到項目過程中，和業務項目的技術架構、技術能力、技術人員思維都有比較大的關系；而這塊對于大公司是比較看重的，特別是微軟、google級別的重視技術體現的公司，我們作為測試開發工程師的重點是從開發角度去做測試工作，會把主要精力投入在系統設計和編碼階段。開發人員關注某個功能最優實現方案，而我們測試要有整體產品的視野。所以測試在設計階段，幫助開發人員完成代碼復用和模塊交互方面的設計，在設計review的時候，保持目的性：完整性、正確性、一致性、設計、接口與協議、測試（可測試性）。還有一個明顯的，就是做這塊，需要沉下心來，慢慢積累和思考，對于很多急功近利的公司來看，績效和沉淀方面難說了，而且這塊的確是我們測試的短板，接下來我覺得還是有可能會重新重視起來。
自動化測試：這個是很明顯的提升測試效率的手段，這里面不同的行業的自動化測試策略和框架也可能不一樣，但是的確是互聯網企業發揚光大的，包括分層自動化測試實踐，其效果也是非常顯著的，不管是什么行業領域，都是逃不掉的；不管你是采用流量錄制和回放、頁面錄制和回放、關鍵字驅動、數據驅動的自動化腳本運行，這些經驗和沉淀目前也是國內的公司強烈關注的，為什么非要關注這塊，說實話，這些能帶來XX平臺的沉淀，XX平臺的開發和技術品牌、XX平臺的能力透出；如果我們加上功能依賴分析、系統依賴分析、代碼覆蓋率等各個因素的影響，我們可以加上精準測試的方向，進一步提升自動化測試效率，這塊上國內有一些公司都在沉淀和探索，也有一些不錯的結果。
灰度&監控：這塊話題，是測試右移的核心思路，基本上也是互聯網和移動互聯網企業的測試策略的標配，測試和開發一起共建，來加強灰度的落地，監控覆蓋率和提升；但是測試在其中的體現到底多少，價值多少，這個就很難說了，我們的沉淀的方向到底是什么呢？我們開發有沒有加上這塊的監控、開發為什么沒有加上這塊的監控、我們測試是不是要監控開發是否加上了某塊的監控、我們測試是不是要來Review開發是否加了某些監控、監控的方法和策略的沉淀開發和測試的關系在哪里。這也是測試自己沒辦法的策略，很多時候我們不怕出現線上bug，我們就怕不能快速fix bug；我們就怕我們的系統監控沒有發現這樣的線上bug，反而讓客戶主動報了相關線上bug；但是這個策略是不是唯一的，依賴它的程度到底是多少，我們測試線下需要做到什么樣的程度，又是一個平衡的問題了，這塊上，我們可以再思考多一點，想想測試在這里面的定位是什么，是和開發綁在一起，分享系統穩定性的結果，還是思考它對于測試體系的位置到底什么樣的。
大數據測試：有兩種情況，一種是大數據產品的本身的測試體系的建設，包括常態化的測試策略和大數據的數據監控策略，這里面的監控可能是測試工程師的重點產出；另外一個情況是利用大數據的手段來提升測試效率，來監控線上質量，反過來驅動線下測試覆蓋率和效率。第一個應該有比較成熟的體系了；第二個也是在探索階段，對于產品特點、體系架構有一定關聯，同時配合多個手段來提升，如果加上某些機器學習、和算法、精準測試策略、可能會包裝成AI智能化測試，解決大數據量情況下的功能測試問題。但是這方面可能不僅僅是測試這個領域，包括運維和體系化架構設計等一個閉環的打造，測試其中啟到什么關鍵的作用，還是值得期待的。
探索式測試：4-5年前比較火，目前基本上是冷卻了一大半了，現在是邰曉梅老師一個人獨立堅守著，在國內各個公司和線下活動不斷的布道和實踐，目前來看，國內的很多公司都有了解和參與，在測試的本身價值上，測試本身的能力建設上還是有很多的進步的，這些對于持續在測試能力上有特定思考(包括和敏捷測試的結合)的同學，他們的體感會非常強，但是對于一些開發技術為核心套路的可能覺得偏理論，不夠技術含量，很難繼續深挖，很難形成平臺化效應，是的，我本人也是最近幾年都沒有在這方面進行學習和探索，很是愧疚和遺憾，但這就是現實。

總體上來看，國內測試技術和方向也是解決部分的問題，還有些可能是大趨勢中找到自己的位置，到底有幾分是自己獨立思考的，有幾分是在真正的研究和探索的，目前看到的不多，很多都是在圍城里面走套路，大家一起走，反正現實有很多的問題需要解決。另外就是很多行業領域里面的測試技術探索，比如游戲測試領域、IOT領域、AI領域、區塊鏈領域、三方生態領域等。

12年 / 國外測試在走什么方向？

好了，我們的所有測試技術和方向的探索，國外基本上前幾年都已經開搞了，有些領域可能領先十幾年，有些大家都在同步探索階段。我們需要更大視野去看國外測試技術和體系的發展，不僅僅是某個框架或工具的角度去看，甚至不是某個行業的測試解決方案來看。我們知道某一個技術的開始和發展，不僅僅是和企業的工程領域有關系，很多時候和學術領域有關；國外測試領域里面包括很多學派，它們分別代表了不同的測試領域的思考和沉淀，不僅僅是不同的測試類型，還包括很多測試理論上的思考，包括自動化測試學派、質量保障和規范學派、上下文驅動學派、開發測試學派等，每個學派都有自己主張的觀點、方法、實踐方案、工具體系等，而且每年都是有序的討論和發展（有那種百家爭鳴的感覺，在工程和學術領域同步開花結果）；在這里，我們在看看一個很明顯的區別點，國外的測試大會上和國內的測試大會上的topci就可以看到一些區別了。

這里面有一些共性的topic包括敏捷測試、Test in ops、性能測試、監控、安全測試、自動化測試、國際化本地化測試；但是國外的很多topic是強調測試本身的思考的，包括測試信息輸入論、探索式測試、基于風險的測試、測試管理、測試策略和計劃、某領域的測試設計方法。這里，很多人其實都看到了不同點，國內這方面的沉淀相對來說少很多，很多人都不感興趣的，覺得都是理論的多，對我的技術沒有幫助。

另外一個層面來看國外測試就是測試大師們，國內從事一線測試工作的工程師基本上10年以下的，10年以上的基本上都是管理的、或者走其他路線了；持續在某個領域進行測試技術體現的研究在國內很難找到，但是也是有的（陳能技、朱老師、領測賀老師、CSATQB周老師、阿爾卡特鄭老師、顧問邰老師等等，這些老師很有可能和其他些人觀點非常沖突，互相不被認可），整體上來看還是缺少很多的，大部分人對于測試生涯、測試價值、測試發展、測試方向都有一種悲觀的預感。反看國外測試工作10-20幾年的測試大師們非常多，他們在測試本身價值上進行了非常多的思考和沉淀，一點點形成自己的思考和理論，一點點去實踐自己想要的測試方式和思路，感興趣的同學可以去多看看國外的測試論壇，你肯定會看到不一樣的測試理解的，好了，我也好久沒看了，趕緊補課去（對績效啥好處都沒有，我真的要看？）。

12年 / 測試生涯還剩多少？

我們先討論一個熱門詞語“測試開發工程師”，大家可以思考下為什么不叫"開發測試工程師"呢？大家都知道的是未來開發測試是融為一體的，很多一些外企也做到了，開發測試的融合，互相backup，互相對產品質量和穩定性負責，其樂融融的感覺。說實話，最近幾年我對外企里面測試的理解不多，這里不敢多說，怕說錯了；但是國內的測試里面，大家其實都能感覺到，那就是我們更多的在關注我們是不是會寫自動化測試腳本，會寫java代碼，懂很多開發技術，做過很多平臺或工具等。這里面的技能重要不重要，當然重要了，但是不是我們考察一個測試開發工程師唯一的思考點呢；我們的批判性思維、我們的打破砂鍋問到底的精神、我們的錯誤猜測的思路、我們的細心專一的用心、我們的異常邏輯判斷的方法、我們的流程優化的意識等等，這些我們到底有多關心呢，不好意思，不怎么關心，因為干了這么久，干了這么多，看不到產出、說不清投入、顯不出能力。

我們再分析下，我們測試開發工程師要干的事情到底哪些呢，之前就是說過了，保障產品質量和提升研發效率，這兩塊我們的投入的比重呢，這兩塊我們看結果的思路呢，這兩塊我們要沉淀的方向和方法的抽象呢？這些說實話，大家看到的都很少，我自己也是一樣。說直白了，未來測試工程師會越來越少，質量很多時候都是開發去負責、或者其他灰度監控手段去避免，那意味著我們在質量上的投入會越來越少，在效率上投入會越來越多，其中的道理大家都應該理解的吧。

當我們第一眼要追求的是效率問題時，我們更多的關心開發技術的提升，以及開發技術在解決效率問題時的應用，因為這些價值是顯而易見的，是被高度認可的（對于無線適配測試平臺，阿里每個大BU都有，起碼6-7個平臺，但是80%的功能是一樣的）；我們打著效率提升的口號，似乎也能解決質量的問題，但是捫心自問，真的能解決嗎？大家知道自己產品的用戶是怎么用我們的產品的嗎，我們的用戶遇到了哪些問題嗎，每天都暴了哪些線上bug給你嗎，其實很多時候，我們都是不敢正視這些問題的，因為我們會被徹底打敗，太丟人了啦。好了，我知道了，測試不可能測試全面的，那樣成本也是非常高的，我們還是快速發布第一位的。因為我們不能真正的去面對這些線上bug，所以大家有真正的去思考線上bug遺漏的真正原因嗎，有多少是從測試設計角度去思考的，更多是從監控、fix效率等角度來加強和避免。

當我們去加強測試工具的開發、測試平臺的建設、監控平臺的建設時，我們測試開發工程師還剩下什么？我們只能做這些事情嗎？難道就因為這些能拿到好的績效、能體現你的技術能力、能快速晉升？好了，不能說太多了，這里有可能會帶來吐槽。其實我不反對這些事情的價值所在，我只是想想我們在干這些事情的時候，有沒有去思考測試本身的核心定位，測試本身的經驗教訓到底是什么？

12年 / 六道輪回后的初心是什么？

你猜對了，前面一大堆都是廢話，現在才到正題，測試的目的和初心到底是什么，我們為什么要干這件事情，是用戶需要我們干，是系統需要我們干，那我們干到什么程度呢，我們到底是做測試，還是做校驗，還是做驗證，還是做探索；每個人心中都有自己的理解，可能不一樣，沒關系，有一點你肯定無法否認，不管你是誰，你肯定是某個產品的用戶，你都肯定遇到這些產品的bug，你都可能是傻笑、生氣、發飆、投訴、卸載、放棄等，然后沒有了，沒有了。

前面也是談了非常多了，關于測試核心工作產出上，有不得不必須要干的、有可干可不干的、有非常想去干的、有老大們逼著去干的、有大家都在干的我也想干的；在這里，我想談談我個人認為的我們可能忽略的一些問題，大家聽到測試技術或測試方法時，第一能想到的是什么呢？如果說到測試設計方法時，你第一能想到的又是什么呢？如果說到測試架構師，你第一能想到的又是什么呢？如果說到項目測試負責人，你第一能想到的又是什么呢？

建議大家先看看《google測試分享-SET和TE》我們是測試開發工程師的title，但是我們干的什么活呢，基本上把SET的工作和TE的工作合二為一，放在一個人的身上，大家其實也看到了SET和TE的技術和要求是不一樣的，我們測試團隊的測試開發工程師都能很好的具備SET和TE的能力嗎，我們真正的測試工作的初心到底是什么呢？我們的測試開發工程師都能在產品的測試過程中發揮這么多的作用嗎？在技術日新月異的時代里面，開發都在全棧了，測試也是該全棧了，不僅僅測試類型上，在不同的領域測試上也有這樣的要求，但是這里面有一個基本的基石，那就是如何更好的去測試，去想到測試什么地方，去抓到那些隱藏的bug，去識別到那些隱藏的風險。

好了，言歸正傳，通用的基石有那么幾塊，最核心的當然是使用什么方法去測試了，知道測試哪里了，所以測試設計是一切測試活動和技術的基礎及前提; 同時，我們需要考慮需求文檔不足下的測試設計怎么做? 我們還需要思考測試模型該怎么建立，而且測試模型分為測試方法模型和業務測試模型，所有設計都是基于模型的，我們也知道好的測試設計能提高測試執行效率，但是我們如何有一個好的測試設計呢。我們先從大家最熟悉的黑盒測試方法來說，大家都熟悉的等價類劃分、邊界值分析等測試方法，很多人都說一個正常的工程師都能在一個下午學會和理解大部分的黑盒測試方法。對此觀點，我是不敢茍同的，這就討論到這些黑盒測試方法的深度的問題了（這個話題之前就是打架無數了，好像最后我們沒輸，但是也沒贏）。

（1）學會和理解測試方法的使用步驟是很簡單的，但是真正的在項目需求中應用起來可不是一朝一夕的。這就好比給你一張撲克一樣，高手就能拿它殺人，一般的人能做到什么程度呢。這個也很像有些人能發現你不能發現的bug一樣。至于原因有很多，具體看在淘兩年的blog。

（2）談談我自己的感想吧，我自己在工作前兩年也是認為這個黑盒測試方法一下午就可以學會的，找幾個例子試著使用下，感覺自己掌握到這些黑盒測試方法，但是后來我看過很多這些測試方法的背景以及應用的注意點后。我發現自己真的是了解了一些皮毛，沒有深入的了解。對于個項目需求，如何快速且完整的應用這些黑盒測試方法設計出不多不少的測試用例，這個需要的經驗的積累，也就是你測試價值的核心體現。

（3）多次和其他公司的測試同學交流，發現很多同學說自己都說自己是工作2-3年的人，已經遇到瓶頸了，感覺測試很單調和無味。我給的建議其實很簡單，那就是真正的理解和掌握所有的黑盒測試方法。怎么來驗證呢，我自己就是這樣：給你一個白板，你能把所有測試方法的5W2H(What、Why、When、Where、Who、How、How Much)都能非常清晰明了的演講出來，記住是不需要參考ppt或其他資料的情況下。

就像火影里面的鳴人一樣，他只會螺旋丸這個核心的攻擊忍術，但是在擴展其他忍術之前，他會把這個忍術的深度發揮到機制，從而研究出威力更強的超大螺旋丸、超大玉螺旋丸、風遁螺旋丸等等。

大家再想想，這些黑盒測試方法都是20年前國外的測試大師們發明的了，然而20年后的今天我們在學習測試方法的理論時還是這些，這是為什么呢？這里面有幾方面的原因，一方面我們的測試同學很多是非科班畢業的，本身技術能力和邏輯能力相對來說薄弱，這樣在測試生涯過程中更加無法變幻出更多的測試方法，另一方面，我們在各個行業領域內更多的關注效率問題，更多的關注如何快速的測試，而不是如何更正確的測試，所以我們都很難沉下心來來思考改領域內的一些通用的測試方法，從而能分享和傳承給所有測試同仁；說我們不愿意去做，或者說我們沒有意識去做，可能是樂觀了，其實這個非常有難度，這個方法的抽象和建模非常的難（之前做過一些測試模型的抽象，感興趣的可以了解下），不是在某個領域扎根多年的測試大師們無法做到的，前提還是這個大師在這塊上有更多的思考和沉淀和總結。

這里強調我可沒說初心就是黑盒測試，個人看法，初心是從本質上去想和思考怎么去測試，什么方法和策略，測試哪里，說到黑盒測試方法只是其中舉了一個例子而已，想想你如何回答你是通過什么方法來測試”它“的，你不可能說我用自動化測試來測試它，我開發了一個平臺來測試它，需要你想想你的回答有沒有傳承性。這里是有一套方法的思路的；至于技術本來就是解決問題的思路；怎么去做的方法，這個可能比較虛，就像道一樣，這些思維方式的思考，我們平時做的太少了，而是更多的去做開發自動化測試框架，不是說不好，去想想為什么，是體現你的技術，還是覺得這個是潮流，大家都干，還是覺得這個是某一個價值的；等等。而這些是不是符合最初你的本心。

12年 / 我們還能找回初心嗎？

好了，前面說了蠻多了，大家在現實面前還是需要現實一點，隨著開發測試比例的提升，測試人員會更加專注在效率上，而不是質量上，我們都有一個美好的愿望，就是我們先把問題解決了，先把效率提升了，我們就有時間好好研究如何正確的測試SUT了，如何創新出新的測試方法了。理想很豐滿，現實很骨感，就像需求列表里面一樣，都是P0的需求，我們都在想P0需求做完了，下一期我們做P1P2的需求，然后你會發現P0的需求永遠做不完，同理，我們的效率和問題解決也是做不完的，那我們的重心和目標規劃還是在這上面，這有錯嗎？沒有錯，對SUT來說、對質量和效率來說、對業務發展來說、都沒錯。

當然很多人會說我測試效率提升了，質量也會同步的提升，這個仔細想想還真不一定哦；前面其實也提到了，我們在平衡質量和效率上的投入，到底平衡到什么程度，我們自己也不知道，很多時候為了功利、為了自己、為了未來、為了測試行業本身，我們做的選擇可能有所不同，最關鍵是你做出了什么選擇，你是如何平衡這些的，在這個平衡中，你學到了什么，你知道了測試這個產品有什么樣的坑，你的測試經驗教訓到底有幾條，哪些是對他人是有價值的，你有沒有總結和抽象出。

回答問題，在這個現實世界里面，我們工作10幾年的測試工程師們，我們還能找回初心嗎，還能靜下心來思考我們真的是正確的做測試嗎？真的只有這樣的一條路嗎？我們還能有其他的路嗎，對于絕大部分測試同仁來說，我們都無法找回初心，我們只能在這現實世界里面隨波逐流，當然，很有可能包括我自己。