全網獨家：成長經歷分享 & 我為什麼要寫書？

• 2020 年 4 月 8 日
• 筆記

在當今高速發展的移動互聯網+雲優先的時代，到處充斥著不可預知的變化，有的來自於客戶需求的變化，有的來自於市場環境的變化，面對著這些變化，給企業在市場、渠道、產品、服務各方面都帶來了一系列新的挑戰，每個成功的企業都在培養打造快速適應這種變化的能力。對於企業的產品研發部門來說，面對著愈發不確定的客戶需求，快速並高品質地完成開發工作，使需求早日上線，儘早收集市場回饋，優化產品和服務，是研發響應市場變化的基本原則。但在追求產品快速交付上線的同時，品質底線是每一個成功的產品必須要堅守的紅線，這也意味著研發團隊在提升產品交付速度的基礎下也要同時保證產品品質，而要求保證產品交付效率的同時又要持續保證產品品質，自動化測試引入是一種行之有效的保障實現手段。

在三月中旬，筆者的新書上市了，關於新書的介紹，可查閱：重磅消息 |《自動化測試實戰寶典：從小工到專家》隆重上市！ 本書主要以自動化測試技術為主線，基於Robot Framework框架來展開介紹如何在實際工作中開展自動化測試工作。當前移動互聯網行業的測試工程師有非常多的測試工具、框架和技術可以選擇，但不得不說即便是在這工具泛濫的環境下，Robot Framework框架仍然是其中的佼佼者，它是一個值得推薦給大家深入使用的優秀開源測試框架，既保證了在初級入門時，快速幫助團隊完成自動化測試任務，又能在深入研究時，學習到優秀開源框架的設計理念，提升自身技術能力。

準備寫這本書之前，其實內心還是挺糾結矛盾的，畢竟最近兩三年一直都是從事研發管理的工作，對技術的鑽究上已經無法全身心投入了。如果是已購書的讀者，從作者介紹中，讀者能獲取到一些我的個人從業經歷。回顧過往的幾家工作經歷：剛畢業的第一份工作在一家台資企業，呆了不到一年左右，這份工作給我最大的收穫是：認識到職場和學校的環境差異，職場更講究自己要對自己負責，自己不努力誰都幫不了你，以結果為導向。(這句話也送給那些即將畢業或剛畢業不久的讀者，也適用那些在職場工作幾年但仍在迷茫的人)

第二家公司，由於工作本身比較積極主動、肯擔當，加上自己平時喜歡搗鼓一些新技術，在入職不到半年就晉陞為部門主管（劃重點：筆者畢業不到一年半，就已經晉陞為測試經理）。這份工作開始階段，移動互聯網的浪潮還未真正開始，至少這個期間還沒有明顯感知到行業變化的衝擊，當時市面上比較主流的測試工具還是以QTP、LoadRunner這些為主，當時如果能很好的結合QTP完成產品的自動化測試，就已經相當厲害了（從現在的技術視角來看，之前的那些工具還是弱爆了）。由於第二家公司做的是偏傳統行業的產品(屬物聯網類的產品)，產品類型覆蓋了Web端、PC端、硬體嵌入式類的產品，在帶團隊之餘，自己也會主動去學習接觸一些新的技術，這個狀態持續了三年。這份工作的末期剛好處於移動互聯網快速發展的階段、期間行業湧現出了很多優秀的後起之秀工具，比如Selenium、Appium、Jmeter等。但由於公司產品形態的原因，這些工具技術並不合適當前的產品，帶著英雄無用武之地，要與時代接軌擁抱移動互聯網時代的心態，即便在當時研發老總拋出高薪的誘惑，仍然毅然決定選擇離開了這家公司。

在第三家公司（酷狗音樂），由於對技術的熱衷和追求，從管理崗轉型測試開發崗（純技術崗），在這家公司工作期間，可以說是我技術成長最快、最大的，在所負責的事業部門，先後主導過後端介面自動化、App UI自動化等項目，並參與持續集成系統、測試平台等系統的開發建設。也正是在這份工作期間，接觸了Robot Framework框架，說來也挺有意思的，在引入介面自動化測試之前，當時事業部現狀是各個產品線測試工具太過於雜亂，有Postman、Jmeter、Unittest等用的五花八門，為了便於整個事業部各產品線介面測試的統一管理和資源復用，研發BOSS下定決心要堅決把介面自動化測試做起來，在我們處於技術選型期間，還是研發BOSS將Robot Framework框架推薦給了我們。剛開始接手Robot Framework框架，其實我內心是抵觸的，因為當時的我認為通過直接編碼或採用類似Pytest、Unittest這類框架來組織測試用例，效率上會更快捷。但是當我真正深入使用了Robot Framework框架之後，它的一些優秀特性深深的吸引了我，也是得益於它在酷狗音樂工作期間落地了很多優秀的測試實踐，包括後續的App UI自動化。通過它帶來的一些成功實踐，打開了我看待問題、解決問題的角度和深度，期間我也做過很多其它的一些測試技術實踐，並且申請通過了9個國家技術專利（當時在酷狗音樂，申請通過的專利獎金還是不菲的）。

在第四家公司，做的是研發效率提升，加入這家公司其實是一個很偶然的機會，當時無意間恆捷(TesterHome社區管理員)聯繫上了我，交談了一兩次之後，覺得大家的想法理念一拍即合，所以很快就同意加入（對於職場，能有一個志同道合，理念想法相當的人並肩作戰很重要）。其實大家當時的想法很簡單，就是想一起通過技術的手段，提升研發的效率和品質，起碼是真心想要做成一些事情。由於某些原因，呆了一年多就離開了這個團隊，對於我來說”拋棄”恆捷還是有些愧疚的，雖然進來之後，建設起來了測試平台、CI的一些能力，但終究覺得離我們當初的雄心壯志還遠遠不夠。

最近的一家公司，算是又一次從技術轉向管理，而促使我寫這本書的初衷，也是最近一兩年，感受到越加明顯的一個行業不良現狀：“測試人員能力的兩極分化太過於嚴重”。一類是行業小白，這裡說的小白，並不一定指的就是剛畢業或剛跨入這個行業的同學，更多指的是測試思維和測試技術一直處於小白狀態。即便是有些工作了很多年的同學，仍然有很多一直處於手工測試點點點的工作狀態中、他們不主動或者不願意去理解業務架構、技術架構，甚至根本沒有想過通過提升來改變這種工作狀態。在幾家公司中，我也面試過很多人，這類不求變或者說不求突破的純手工功能測試的群體並不在少數。說這些話，雖然可能會刺痛一些讀者，但我還是希望通過把問題真正拋出來，讓大家去正視直面自己的不足，只有敢於正視不足，才有可能克服解決這些不足，也只有這樣才能變成更好的自己。除了一類是行業小白，另外一類則是行業大師，這類群體的佔比是極為稀缺的，也是軟體行業最為搶手的一類人。這類人無論從知識的廣度還是深度，都可以媲美開發架構師的能力，甚至有些還會超過開發架構師的水平，因為測試作為一個“高危職業”，它需要比產品經理（或SA需求分析）想得更全面，要比開發更懂需求，要能讀懂甚至能修改開發的程式碼。這個觀點和《Google測試之道》一書中提到的一條理念很相似，在Google他們對測試工程師的定位是這樣認為的“如果一個測試人員業務能力不比產品強，編碼開發能力沒有RD牛，你怎麼能發現他們的問題呢？這也足已說明產品的測試品質工作，絕對不是隨隨便便就能做好或者誰都可以勝任的。

前面介紹了作者的從業經歷和工作過程的一些感悟，希望對正在讀文的你，有一些啟發和幫助。

本書的寫作目的並不是為了簡單地告訴讀者如何使用一個自動化測試工具，這並非我的初衷，我希望讀者在學習本書的內容後能提高綜合的技術高度與寬度，從而擺脫簡單的手工測試，向成為一名新時代的優秀測試工程師道路邁進。如今移動互聯網的技術和知識迭代都是非常快的，技術棧也涉及比較廣，建議讀者在學習本書的內容同時要自己學會Google相關技術的官方文檔，構建一個屬於自己的知識體系，從而有一個系統全面的理解，千萬不要指望在書中找到所有的答案，這個在移動互聯網時代是不現實的。

正所謂：“授人以魚，不如授人以漁”。互聯網行業的工程師就好比運動員，要想在競技場上獲勝，需要在訓練場里長期刻苦地練習技巧，想要成為一個不被時代拋棄的技術人，就需要不斷的更新迭代自己的知識體系，加油讀者們，共勉！