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

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

好久沒寫文章了，以前測試十年，也是在本身有變化的時候 ，強迫本身寫了一篇文章，說了本身的困惑和痛苦和思考，也獲得一些共鳴。如今測試十二年了，至關於一個輪迴，也有一些新的痛苦和感悟，趁還在這個圈子裏面，記念一下，固然了，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年，很漫長，若是我不幹測試了，我也會關注大家的。青山不改，綠水長流。

本文做者：雲效鼓勵師

閱讀原文

本文爲雲棲社區原創內容，未經容許不得轉載。