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

掃描上述二維碼或點我直達 免費領！

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

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

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

12年 / 這兩年我幹了啥

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

【品質】

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

【效率】

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

【技術驅動業務】

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

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

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

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

在正式的說之前，大家回想我之前說的一句話，我們幹測試的，很多時候就是在平衡這三步的比例和深度，在品質、效率、驅動業務上不斷的調整政策和戰術，根據不同的業務階段、根據不同的目标、根據目前的大事件驅動等。

我們最怕幹的是就是平衡，因為平衡的好，前途光明，平衡的不好，萬丈深淵。大家都知道我們幹測試的，雜活特别多，很多事情都需要投入一點，很多事情做起來很多人看來也沒有亮點，那我們很多時候就是在不斷的平衡一些事情，但是不管怎麼樣，我們的目标還是比較聚焦的，就是對應自己的業務和開發技術，以及未來的業務發展，在品質和效率上如何做的更好，成本上越來越低，解決方案也越來越有技術含量。

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

1. 基于模型的測試：這塊領域很多人不太熟悉，而且在不同的行業的實踐和效果是差異比較大的，但是不能否定這個方向帶來的價值，在通訊、IOT、嵌入式等領域都有非常多的實踐，效果也不錯，我認為是測試前移比較重要的一塊；但是很多人對于這塊隻是基本的了解，很多時候都有可能直接放棄；最後的結果，可能是我們的開發同學先開始業務模組化，先開始各種模型抽象，提升開發效率，然後再到測試的模型和效率提升，很顯然，我們是被動的，而且很多時候我們錯過了一些風景，可能感覺不到呢。
2. 可測試性：這塊話題，其實是大家聊的比較少的，因為很多方面是偏理論的，真正落到實踐到項目過程中，和業務項目的技術架構、技術能力、技術人員思維都有比較大的關系；而這塊對于大公司是比較看重的，特别是微軟、google級别的重視技術展現的公司，我們作為測試開發工程師的重點是從開發角度去做測試工作，會把主要精力投入在系統設計和編碼階段。開發人員關注某個功能最優實作方案，而我們測試要有整體産品的視野。是以測試在設計階段，幫助開發人員完成代碼複用和子產品互動方面的設計，在設計review的時候，保持目的性：完整性、正确性、一緻性、設計、接口與協定、測試（可測試性）。還有一個明顯的，就是做這塊，需要沉下心來，慢慢積累和思考，對于很多急功近利的公司來看，績效和沉澱方面難說了，而且這塊的确是我們測試的短闆，接下來我覺得還是有可能會重新重視起來。
3. 自動化測試：這個是很明顯的提升測試效率的手段，這裡面不同的行業的自動化測試政策和架構也可能不一樣，但是的确是網際網路企業發揚光大的，包括分層自動化測試實踐，其效果也是非常顯著的，不管是什麼行業領域，都是逃不掉的；不管你是采用流量錄制和回放、頁面錄制和回放、關鍵字驅動、資料驅動的自動化腳本運作，這些經驗和沉澱目前也是國内的公司強烈關注的，為什麼非要關注這塊，說實話，這些能帶來XX平台的沉澱，XX平台的開發和技術品牌、XX平台的能力透出；如果我們加上功能依賴分析、系統依賴分析、代碼覆寫率等各個因素的影響，我們可以加上精準測試的方向，進一步提升自動化測試效率，這塊上國内有一些公司都在沉澱和探索，也有一些不錯的結果。
4. 灰階&監控：這塊話題，是測試右移的核心思路，基本上也是網際網路和移動網際網路企業的測試政策的标配，測試和開發一起共建，來加強灰階的落地，監控覆寫率和提升；但是測試在其中的展現到底多少，價值多少，這個就很難說了，我們的沉澱的方向到底是什麼呢？我們開發有沒有加上這塊的監控、開發為什麼沒有加上這塊的監控、我們測試是不是要監控開發是否加上了某塊的監控、我們測試是不是要來Review開發是否加了某些監控、監控的方法和政策的沉澱開發和測試的關系在哪裡。這也是測試自己沒辦法的政策，很多時候我們不怕出現線上bug，我們就怕不能快速fix bug；我們就怕我們的系統監控沒有發現這樣的線上bug，反而讓客戶主動報了相關線上bug；但是這個政策是不是唯一的，依賴它的程度到底是多少，我們測試線下需要做到什麼樣的程度，又是一個平衡的問題了，這塊上，我們可以再思考多一點，想想測試在這裡面的定位是什麼，是和開發綁在一起，分享系統穩定性的結果，還是思考它對于測試體系的位置到底什麼樣的。
5. 大資料測試：有兩種情況，一種是大資料産品的本身的測試體系的建設，包括常态化的測試政策和大資料的資料監控政策，這裡面的監控可能是測試工程師的重點産出；另外一個情況是利用大資料的手段來提升測試效率，來監控線上品質，反過來驅動線下測試覆寫率和效率。第一個應該有比較成熟的體系了；第二個也是在探索階段，對于産品特點、體系架構有一定關聯，同時配合多個手段來提升，如果加上某些機器學習、和算法、精準測試政策、可能會包裝成AI智能化測試，解決大資料量情況下的功能測試問題。但是這方面可能不僅僅是測試這個領域，包括運維和體系化架構設計等一個閉環的打造，測試其中啟到什麼關鍵的作用，還是值得期待的。
6. 探索式測試：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幾年的測試工程師們，我們還能找回初心嗎，還能靜下心來思考我們真的是正确的做測試嗎？真的隻有這樣的一條路嗎？我們還能有其他的路嗎，對于絕大部分測試同仁來說，我們都無法找回初心，我們隻能在這現實世界裡面随波逐流，當然，很有可能包括我自己。

12年 / 忘記我所寫的

感謝你能看到這裡，看到了那麼多的廢話，那麼從現在開始，忘記我所寫的，繼續寫代碼，繼續開發測試平台，繼續解決問題，你會成長的很快很多的。以上所有的觀點都隻是我的個人看法，很多地方說的容易被人挑戰，被人罵SB，是的，但是又有什麼關系呢。

我思故我在，在此紀念測試十二年的酸甜苦辣。

下一個輪回，又是12年，很漫長，如果我不幹測試了，我也會關注你們的。青山不改，綠水長流。

最後打個廣告，天貓新零售測試團隊還缺人，歡迎大家自薦和推薦，聯系季哥或直接扔履歷到季哥郵箱[email protected]。

點選“

此處

”阿裡巴巴的測試服務！