演講稿 ---- 10年 測試開發

前言

大家好， 我是孫高飛， 目前在第四正規化質量部中負責工程效能方向的工作。 我在這家公司有4年多的時間了， 剛來的時候整個質量部加上我也只有2個人。 基本上我是看著質量部一點點成長起來的。 而在去年年末的時候，經歷了4年時間發展的質量部也是終於正式成立工程效能部， 我也是徹底告別了業務團隊，作為工程效能的負責人開始了新的工作。 而回顧4年前質量部剛成立的時候， 我們做出了一個大膽的決定，那就是從一開始就以測試開發的標準來進行招聘工作， 即便是業務測試人員也要有自己構建自動化測試和開發測試工具的能力， 最終組建一個全員測試開發的技術團隊。 這也是為什麼4年來我們在技術上的實踐好像上了高速公路一樣。 而我個人也拒絕了管理崗的位置，選擇在工程效能團隊繼續在技術領域深耕。 所以今天這個關於一些類似職業發展的分享呢，可能會跟其他人都不一樣。 其他來分享職業經驗的人呢，可能已經走到了一個比較高的位置上了， 分享的內容也是從很全面很綜合的能力上表述的。 而我呢沒有選擇做管理崗， 所以雖然我是公司第28號員工，但是到現在我的title也只是質量部的一個測試開發工程師。 而今天分享的內容也主要是聚焦在技術能力這一個點上開展，並且我們今天不去劃分什麼能力模型， 技能體系，就單純的從我們怎麼去好好的做一個技術崗位上說起。 我覺得這也一個比較好的角度， 因為我們大多數人還都是普通的員工的，而我這已經逼近35歲大坎的一線技術人員今天就來分享一下我這10來年的一些經驗， 希望能對大家有幫助。

做加法

首先我們討論一個很普遍的問題， 當我們進入這個行業的時候，我們該怎麼做。 現在比較主流的聲音是我們要深耕一個領域，在一個領域內成為專家。 這句話是對的，但它有一個前提， 就是你已經在這個行業裡摸爬滾打到了一定的程度了， 你確信自己擅長什麼，自己想做什麼。 而初出茅廬的人往往面對的是一種很迷茫的狀態， 這個時候你什麼都沒見識過， 在這種狀態下你怎麼能確定你未來要伴隨你一生的職業規劃是什麼呢？所以這裡我可能會提出一個不太一樣的聲音。那就是剛進入這個行業的時候，可以不用急於去專研某個領域。 白巖鬆老師曾說過在30歲之前要玩命地做加法，要去嘗試，因為你不知道自己有多少種可能，你也不知道命運將會給你怎樣的機緣，所以，不試試你怎麼知道呢。

同時這也是我對技術的態度，多去嘗試不同的技術，不同的解決方案， 你會發現不一樣的天空。 4年多前一次很偶然間的想法，我想試試最近不少人在談論的docker， 就是這麼一次很突然的想法， 造就了質量部後面大量的docker和k8s的實踐， 也造就了我後面一直以容器生態為核心向外擴充套件的技術棧， 所以不去試試，你可能都不知道一門技術能給你帶來多大的改變。我一直認為最可怕的不是我們學不會一樣東西，而是我們跟本不知道這樣東西能做什麼或者根本不知道這樣東西的存在。 在這個行業裡， 很少出現靠個人努力學不會的東西，只要你肯砸時間耐心的去學， 總有學會的一天。 但是如果你墨守成規， 本著現有的東西已經能滿足業務需要的心態而把自己與其他技術遮蔽掉。 這樣不論新的技術有多好，能提高多少效率，你都不知道了， 那你又何談進步呢。 不要把自己限制在一個小的圈子裡， 因為這個小圈子沒辦法養活你一輩子， 技術永遠在更新在淘汰，永遠都有更好的方案出現。 所以多嘗試，不是一件壞事。

做減法

剛才說的是給自己做加法， 嘗試更多的新的可能性。 但是到了一定的程度後， 要學會給自己做減法。30歲，是你在做了一系列加法和四處亂跑之後，要做一次減法的重要時間，不然就晚了。 為什麼要做減法，因為你不是所有的都適合，也不是適合你的所有的事你都該去做。八條線栓著你，你能跑多遠？這8條線可能還會互相牽制。 我在之前面臨了一個選擇，我到底該做什麼。 尤其是當時從產品上我再推進資料治理方案， 業務上我帶著一條業務測試團隊， 而技術上我當時也正在跟k8s較勁的正起勁。 所以當領導來找我問我要不要轉管理崗的時候，我陷入了沉默。 我給了自己一週的時間來思考，我自己問自己，我可以做很多東西，可以做技術，可以做產品，也可以做管理以及其他一切好玩的東西。但是最後我對自己說不，我發現自己只能做技術， 也最該做技術。 而我能擁有今天的一切，都是因為那時做的減法。

當然做減法不是隻剩下一個技能其他的都減掉。 我們說的深耕也是在一個領域內的深耕而不是在一個技能上的深耕，這中間是有很大的差別的。不少人都很喜歡走極端， 你說要深耕， 要做專家， 那好，我就奔著一樣技術使勁，除了這門技術其他的我都不管了。 這就是一個極端，這就好比獨孤九劍， 獨孤九劍專破天下武功。 有破刀式，破劍式，破氣式，破掌式等一共9式， 每一式又有諸多變化， 比如破刀式裡分為單刀、雙刀、柳葉刀、鬼頭刀、大砍刀、斬馬刀種種刀法。 如果你只學了破刀式裡的單刀， 就算你練的再怎麼出神入化，對敵的時候人家拿一斬馬刀出來， 你怎麼破？ 所以其實我挺不願意回答社群裡總有人提問到底是java好還是python好的問題， 說的好像我們只學一門語言就可以了一樣，你python用的再好當你面對容器領域的工具開發的時候你敢不用golang麼， 你java使的再溜當你要寫一個web的時候你能不用js麼？我們要知道對於一個好的測試開發來說，同時掌握幾門語言和技術是完全是必要的。因為你面對的是各種不同的場景， 這不是一招鮮都解決的。

所以我要強調我們要解決的是這個領域內儘可能多的問題， 而不是隻解決一個問題中的各種細節。解決不同的問題可能會用到不同的語言不同的技術， 這很正常。 不要陷入一個極端的狀態我要做專家，我要把所有精力都放在一樣事情上， 然後專到一個特別細節的東西上去了。 我見過有同學就衝著一個介面測試使勁，一做就是幾年，你一問就說我介面測試做的特別好， 我開發了什麼什麼框架， 什麼什麼平臺。 但是你介面測試做的再好，它也只是介面測試。 它也只是這個領域內龐大的測試體系中的一環。 所以一個領域和一個技能的差別我們需要明白， 如果你只專注一個細節， 那就只能偏安一偶做個執行者，因為你撐不起這個團隊， 你能解決的只是這個團隊要面對的形形色色的問題中的一個。 所以如果你想走的更遠， 就去關注你所在領域裡更多的問題。

幾種不好的思維

走技術路線當中最不好的幾種思維：

• 第一種是當你所擁有的技能已經完全能滿足當前工作需要的時候， 是即便你學了更多更深的知識也在當前工作中用不到的時候，那種突如其來自滿或者是不安。 這是兩種既然不同的結果。 但怎麼處理好這兩種情緒是很重要的。 自滿是因為覺得一切盡在掌握，他在當前工作裡所有的技術問題他都能解決， 可能會讓他錯誤的認為他能解決這個領域裡所有的問題，或者錯誤的認為這個領域裡就只有這麼多問題了。 處於這種情緒下的人會自然而然的停止自己的腳步，但是你要知道既然你選擇了技術路線那麼你的腳步就是不能停的，技術永遠在不停的更新換代，停下腳步後，吃上幾年老本可能就要被淘汰了。 而不安是因為他意識到自己的腳步已經停下來了以及停下腳步帶來的後果，所以這個時候他不安，因為他沒什麼辦法，當前的工作已經沒辦法驅使他前進了。 自滿和恐慌是幾乎每個技術人都要經歷的， 有些人是先自滿後面慢慢恐慌，有些有經驗經過幾次這種狀態的人可能是直接跳到了恐慌。 比如我現在每年都有幾段時間會陷入不安，通常就發生在要推進的方案都落地並穩定了以後，這時候我就會想我接下來該做什麼。 所以這時候我們要好好的思考一下， 給自己的工作帶來一些變化。 可以是內部申請調整一下業務線， 我們換另一條業務或崗位去尋求一些突破， 因為不同的業務有不同的問題，也許在另外一條業務上你又能折騰一段不短的時間並讓你在自己的領域裡增加更多的競爭力， 又或者我們引進一個全新的測試型別或工具平臺來給自己帶來新的挑戰與機遇。 18年的時候，我曾經陷入過這種狀態， 當時我大概彷徨了有半個月的時間，我一直在思考在糾結下一步要去做什麼。 最後我決定引入混沌工程這種我們以前沒有的測試型別， 在當時我們是沒有能力做這件事的， 因為那會的時候chaos-blade和chaos-mesh都還沒有開源。 所以從技術角度上來講這是一個很大的挑戰， 因為我們面臨的是k8s場景下的故障注入和監控。 這帶來的結果是我必須從以前在業務層使用k8s往下發展， 甚至要去研究k8s的原始碼然後向其中注入不同的故障。 我也曾經調整過業務線， 就在2個月前我還申請去另外一條我沒接觸的產品線去趟坑， 我們的UI自動化已經從selenium 到selenide， 單機到分散式的演進，積累了快3000條測試用例，可以說已經是很成熟了， 但是在這新條業務線上我開始實踐cypress這種使用前端技術棧來做UI自動化的框架。 我希望cypress能為我們帶來一些新的變化，一些好的變化。 所以其實總結一個字就是變， 我們需要經常的變化。產品在變，技術在變，我們自己也要變。 變則活， 困能死。很多公司每年都會做各種組織架構的調整，也是為了能讓變化帶來一些新的東西來。 如果不變化，面臨的可能就是不進則退的記過。 當然變的過程一定是挑戰的， 是痛苦的，因為你要不停的學新的東西， 但我們要知道走技術路線一定是不舒服的， 如果你走的太舒服， 那麼用不了幾年， 你再去找工作的時候，你可能就不會很舒服了。
  
• 第二種比較不好的思維是對追新技術的質疑。 不少人在想技術更新的太快， 現在去學這些技術有什麼用， 用不了多久就會有新的技術出現。 所以他就不去學習新的技術了，他相信自己把基礎學好了， 比如把把計算機原理，演算法和資料結構學好了就可以了。 我發現真的有不少人這麼想， 這兩年業界比較強調學習能力， 認為快速的學習能力才是最重要的，我記得去年還是前年有人提出來測試界的全棧其實就是快速的學習能力。 而不少人堅信只要把這些基礎學的紮實了，他碰到什麼都能立馬學會，因為這些是一切的基礎。 我不太清楚為什麼他們會認為在不去真正的戰場上真刀真槍的走一遭就能練出一身的本事。 這個所謂的學習能力到底是怎麼來的。 要知道學習能力從來都不是自己憋出來的，學習能力是你自己一步一步，一個坑一個坑趟出來的經驗。 對於大多數人來說，學習能力其實就是一種經驗。 是一種你在面對一個新技術的時候， 你發現你以前用過的一個東西也有這種場景， 所以你立刻就能反應出來幾種解決方案， 然後看這個新技術是用哪個方案解決這個場景的。 所以你能立刻明白這個新技術的設計原理， 使用方式，而不是冥思苦想。 所以你比其他人學的都快， 對於大多數人來說，這種經驗才是學習能力。而不是一些人盲目迷信的基礎知識。 比如大資料領域技術的更新換代也是很快的， 最早的時候我們還在用MapReduce去擼程式碼， 後面有了一系列很快速的更新換代， 當初spark的出現是一個里程碑， 但是這兩年flink出現後大有一種flink要取代spark的架勢，尤其是flink的流式是做了變革性的設計。 但這並不妨礙spark使用者用一種較為輕鬆的狀態去學習flink， 因為他們都是解決相同的場景的技術，flink再怎麼創新也是在這個領域裡， 它要解決的也是這個領域的問題。 所以它本身解決問題的方式很多是沒有變的。 比如partition的設計是類似的， shuffle， checkpoint這些在分散式計算領域都是這樣的解法。 你知道了spark的這些東西是怎麼設計的後就能很快的反應過來flink是怎麼設計的以及為什麼這麼設計的。 streaming是大資料領域很經典的場景， 不管是spark streaming還是flink streaming 去對接比如kafka這種場景的時候， 要解決的事也是一樣的， 你在spark和kafka的場景裡要解決精準一次性語義的問題，那你在flink 和kafka裡也一樣要解決的。 你也一樣是要用相應的包去開啟kafka producer 的冪等和事務。 所以對於一個spark使用者和非spark使用者， 他們誰的學習能力強，不是一目瞭然麼。 當然這個例子可能大家不太熟悉， 我說一個大家熟悉的。 之前我去調研cypress作為新的UI自動化框架的時候， 我幾乎是在一個下午的時間裡，就瞭解了它的一個大概的樣子。 當天我寫了一篇文章，叫《在你使用cypress前你要知道的》。 裡面是我再使用cypress的一些憂慮和對應的解決方法。 尤其是在cypress的分散式執行的弱點以及基於js語言帶來的一些侷限性。 而我之所以能在一個下午就瞭解到這些東西，是因為我已經用selenide在UI自動化上做到了一個很複雜的程度了並且也對js這門語言也比較熟悉。 在去看cypress之前，我心裡就有一些問號， 比如cypress是怎麼處理分散式執行的， cypress怎麼與中介軟體，比如資料庫，kafka，hdfs等打交道來輔助UI自動化測試的， 又比如cypress這種跟pytest一樣很多功能是靠外掛來補充的機制， 那麼各個外掛之間是否會有衝突， 因為我再用pytest的時候就發現了外掛之間的互相沖突。 再比如js這種語言由是依靠eventloop來處理非同步操作的，它的同步和非同步程式碼的處理從來都是js裡面的一個比較重要的問題， 而cypress的文件裡清清楚楚的寫著，cypress 的command都是一種類promise的設計，全是非同步執行。那麼在我們寫case的時候我們的流程控制會不會出問題。 而後面在我去在專案中實踐cypress的時候剛才說的問題確實都遇到了坑。 我再有了之前的這些經驗的時候，帶著這些問題去翻看cypress的文件， 學習的速度就會很快， 因為你不需要別人再跟你解釋cypress的這些設計是為了什麼，很多東西你都能夠心領神會。 所以其實我們在學習一門技術的時候，最寶貴的東西其實不是這門技術本身， 而是使用這門技術要解決的那個場景，以及解決這個場景使用的方式。 所以我建議不管我們去使用哪門技術來解決你的問題， 不要只學API， 而要多去學習和思考它背後的一些東西。 而學習能力就是解決問題的經驗， 是這些經驗讓你面對新東西的時候，進展的更快。
• 第三種比較不好的思維是，眼前工作上用不到的東西我不用去學習。 這也是一種常見的想法。 但是首先你的業務是不會停下腳步的，它也會從簡單走到複雜。 我們是需要為了未來要面臨的問題而儲備一些技能的， 我後面也會講到， 機會是給有準備的人的，我們還是要儘量避免書到用時方恨少的情況的。 再一個有些時候沒去了解一些東西的時候， 你真不知道它有多有用， 也許它對你現在的工作有一個很大的優化的作用， 但你不知道。 這也我說在做加法的時候強調過的。 我一直都建議多去學習研發會用到的技術，它不僅僅在做工具開發的時候提供幫助， 很多時候他能讓你測試的更好。 因為你更懂你的產品架構是怎麼樣的。 還是拿kafka舉個例子， 非常多的公司都會引入kafka作為訊息中介軟體或者作為流式資料的中介軟體。 如果你認真學習過kafka的話，就會知道它有一個經典的精準一次性語義問題。 在生產者push訊息的時候， 如何保證訊息不丟的同時，還不能重複。 不丟好解決， 引數多設定幾次重試， 但是訊息不重複就很難，因為你有重試機制就會有可能會出現一個訊息重複的推送到broker上。你在任何一本kafka的書籍裡都能找到一大段篇幅在講他是如何通過設定冪等性引數和事務性引數來解決這個問題的。這是一段不算簡單的配置， 它需要producer，broker和consumer都做一定的引數設定和程式碼結構的變化。不注意的話挺容易出錯的。 我們就曾經出現過在flink streaming的場景中， 這個流是從kafka到kafka。也就是用flink從一個kafka中讀取資料，然後做清洗，處理，再傳送到另外一個kafka上。 這是一個很常見的流式場景。在這個場景裡我們就遇到過由於flink與kafka的精準一次性語義沒有設定對而導致的訊息重複傳送問題， 這個是我們在針對flink和kafka做專門的故障注入的時候發現的。 實際上訊息不的不丟失， 不會重複記錄，不會重複消費是一個需要好好設計的測試場景。 而一般如果沒有好好的學過kafka，或者沒有好好研究過訊息中介軟體的話， 是很難能想出針對性的測試用例的。 就算是我告訴你我這裡有故障注入工具，你不瞭解flink和kafka，你都不知道要往哪裡注入故障，以及注入什麼樣的故障。 外面總會有人說甚至連我們自己都說客觀條件上研發其實是最適合測試工作的，因為是他們自己開發系統，沒有人比他們更熟悉自己開發的東西了。 測試一個東西的前提一定得數對他熟悉。 所以如果你想測的更全面，更深入，那你就應該去學習研發領域裡那些足夠深，足夠底層的東西。 如果你一直都在表面那層業務上折騰，那是永遠沒辦法突破自己的瓶頸的。 所以不要覺得你現在工作上用不到就不去學， 你不去學的話當然就用不上。所以引申一個東西就是技術是什麼， 不是說只有開發了什麼什麼工具和平臺才是技術，技術是你解決問題的能力。 在剛才我說的場景裡，就算一個人他一行程式碼沒寫， 故障都是拿工具手動注入的，但他知道怎麼測試這個場景並執行了測試，我就覺得他是有技術的。

廣度是深度的附屬品

可能我一直都在表達一種不太一樣的聲音。 基本大多數人都會告訴你要做專家，這句話是沒錯的， 但是這個專是有一個度的，不能專的太窄， 你專的越窄，你的路就越窄。 能力越大責任越大， 你能力大，就應該去負責更多更高維度的事。 這時有人可能會說我們不是要一直專注於深度麼， 怎麼聽上去好像你要讓我們往廣度發展。這裡我要表達一個觀點就是我一直認為廣度是深度的附屬品， 有深度的人在廣度上一般都不會差。 我們說的深度的是深入這個領域裡解決這個領域裡足夠多足夠深的問題，而在解決一個又一個的問題的時候，我們就會接觸各種各樣的技術。 我給大家舉個我自己的例子。 熟悉我的人都知道我很多的精力都在容器化的路上折騰，我們的整個產品架構，測試環境，測試服務等在容器化的路上歷經了4年的演進。 從一開始的單機裸docker執行，到現在的k8s叢集排程， 我們所精進的不僅僅是容器技術本身。 容器這個領域會面臨很多問題。 我來列一下。

• 要解決所有模組的編譯->映象製作->推送->部署->測試。 我們需要一條完整的pipeline來完成這項工作， 並且由於任務非常多我們需要負載均衡和高可用的解決方案， 所以開始使用jenkins pipline與k8s整合的方式。 而這是我第一次學習jenkins pipeline。 深度上，我在k8s與jenkins整合上學習到了K8S各種知識， 廣度上，在k8s與jenkins通訊上學習到了數字證照，RBAC等。並且我學習了jenkins上的各種玩法， 尤其是pipeline。
• 部署是一件非常複雜的事， 就算已經生成了映象但是各種配置管理，啟動順序，k8s模板生成，資源用量等問題都很難讓測試人員執行部署操作。 為了解決一鍵部署的問題我們做了很多事情。 專門開發了部署工具。 並且從深度上我們使用了更多的k8s的特性，但是廣度上部署指令碼使用python以及對應的k8s client和cli框架。這是我第一次用python。
• 大幾十個模組部署在K8S上，幾乎所有測試服務，自動化任務，瀏覽器叢集等都執行在K8S上。 我們在各種測試中都需要一套行之有效的監控方案。 所以開始使用基於普羅米修斯的容器監控方案。 深度上我瞭解了k8s監控的整個方案和原理，而且這是第一次瞭解k8s operator，也是為我之後編寫自己的k8s operator做了知識儲備。 廣度上通過普羅米修斯我不僅做了容器監控， 我們後續上面做了黑盒監控，物理機監控，程式監控，自定義exporter等各種實踐。 算是各種監控場景幾乎被我們玩了個遍。
• 產品執行在k8s上， 利用了很多k8s的特性，比如負載均衡和高可用的方案。 要驗證研發使用的這些方案的效果。 需要一個完善的混沌工程來進行測試。 而當時是沒有一個開源的能在k8s上使用的故障注入工具的。 所以我們自己去研究k8s和容器的特性，開發了自己的故障注入工具以及全自動化的測試方案。 深度上為了編寫故障注入工具，我開始學習k8s的client-go， 開始編寫自己的k8s operator， 開始研究k8s原始碼。 這是開啟我k8s相關開發的轉折點，是我再k8s學習上的重要事件。 而廣度上， 第一次學習golang， 而在case中對將測試資料上報到普羅米修斯的pushgateway最後計算出可用性， 為了在這過程中監控是否有記憶體洩漏和fd洩露我又自己編寫了普羅米修斯的exporter。 這也補充了我們在普羅米修斯監控方案上的最後一個使用場景。 而為了注入故障，我又學習了一些linux相關的東西 ，比如namespace，iptables，tc等等。
• 我們還面臨一個問題就是上述所有操作都是分散的命令列， jenkins job等。 為了給業務線一個良好的使用方式。 需要一個web服務來解決， 所以js， typescript，angular學起來。

上面是我列出來的一些主要的問題， 在解決這些問題的過程中，可以看出來我的主線還是容器領域的應用， 一開始是產品的編譯，部署這種常規的k8s應用，到後面解決k8s周邊的類似監控場景， 使用k8s開源的client定製exporter，定製運維工具。 在到後面研究k8s原始碼，自己開發k8s的operator往容器中注入故障。 這一切還是圍繞著k8s一步一步的深入k8s的各類場景中。 而在這一系列過程中，我們為了更好的解決問題而學習應用了python，golang，js，typescript 4種語言（如果算上其中編寫測試用例的語言的話，那就還得算上java），涉及前端，後端， CI，監控等各種技能。 所以我說廣度是深度的附屬品，因為只要在這個領域裡解決足夠多的問題，你必然就要面對形形色色各種不同的技術。

放棄偏見和強烈的個人偏好

我這裡還想表達一個很重的觀點就是在技術上儘量的不要帶個人的喜好憎惡。 而帶著強烈的個人喜好的工作方式其實是很危險的。 我見過不少人強烈的對技術有非常大的偏好，比如我見過只喜歡Go語言的，只喜歡python的，他們非常不喜歡其它的語言， 我也見過只喜歡做介面測試強烈排斥UI自動化的。 或者只喜歡寫服務端的強烈排斥寫前端的。 這些個人偏好足以讓一個未來會很優秀的人被毀掉，因為，這個時代沒有限制他，他的能力也沒有限制他，但是他的意識完完全全地限制了他。 他把自己的技術棧封閉起來，自己封閉了自己的視野。偏見和不開放，對一個人的限制是真正有毀滅性的。主動讓自己成為一個瞎子和聾子，主動把自己的能力閹割掉，這是一件很令人痛心的事。 要知道當你放棄一門語言或者一門測試型別的時候， 你放棄的是其對應的一整個的生態。 要記住技術是不分三六九等的，他們是解決問題的工具，就算很多人覺得這個技術再簡單再low，但是遇到相應的場景的時候，你還就只能用它。 同樣在技術人眼裡，問題也不應該分三六九等的， 不管是簡單的還是困難的， 最終你都是要去解決的。比如你不能覺得UI自動化low，就不去做它，因為做好UI自動化是大部分團隊要面對的問題， 你需要為你的團隊負責。 如果你的目標是能在技術上成為這個團隊的領導者， 那我希望大家能放棄各種偏見和優越感。

如果陷入了這種帶有偏見狀態，那你一樣撐不起一個團隊。因為你這個人都已經在搞閉關鎖國了，你怎麼能在技術上去引領一個團隊的發展呢。 你怎麼能解決這個團隊遇到的不同的問題呢， 就像我剛才拿我自己舉的例子。 解決這一系列的問題涉及了多種語言及其技術棧， 而這種需要多種技術棧配合解決的問題，才正是我們工作中總會遇到的。 可能大家會說你不用一個去做這些事啊， 去指派會這些其他技術的人一起工作不就好了。 但是我想說的是哪來的那麼多人讓你指揮呢， 你在做事情的時候， 尤其是剛開始做這些事的時候， 哪來那麼多資源投入進來呢。 做測試開發這個職位， 其實大多時候我都是習慣靠自己的。當然說到這裡也可能會有人說我剛才舉的例子中， 感覺我乾的好多事情不是QA應該做的， 應該是devops或者研發做的。 這也是一種限制自己的行為， 你把自己限制在自己認為的QA的職責邊界中， 放棄了去接觸新的技術和解決更復雜的問題的機會。 而我認為技術的深度往往取決於你平日裡解決的問題的複雜程度。只有經歷過足夠複雜的場景，才能鍛煉出足夠專業的能力。

機會是留給有準備的人的

可能有些同學會說我遇不到複雜的場景， 或者能鍛鍊技術的工作崗位輪不到我。 這是一個很現實的問題， 當你的技能不夠好的時候，相應的工作崗位或者機會可能是不會選中你的， 這也是為什麼我們要在平時就去主動學習的原因。 當你的技能不足以勝任你心儀的工作崗位的時候， 你就要努力的讓自己的水平無限的接近那個崗位的要求。 這樣機會來的時候你才能抓的住。 就如在我們這裡是QA先搞了k8s，推行了測試環境上k8s叢集的實踐， 而沒有把這個任務交給devops，直到現在我們這的k8s叢集都是我們自己搭建自己維護，每個專案的一整條持續整合的pipeline 包括從環境部署到最後的質量看板的負責人都是QA。 那當初為什麼沒有交給devops， 也很簡單， 因為當時公司規模小根本沒成立專門的devops團隊。 打從以前就是qa跑來主動承擔了研發和測試環境的搭建和維護。而這個沒有人來做的現狀就是機會。 但是在這個機會的背後， 在我去找boss要接下來k8s這個活的背後。 是我已經私下學習了k8s整整3個月並且我自己拿k8s重新搭建一套測試環境。 所以這個機會來的時候，我才能抓的住，否則的話，一個對k8s一點都不瞭解的人跑去請命要攬下這個任務，那可能就是個笑話了。 機會永遠是給有準備的人的， 不想努力的去準備，還想讓機會像天上掉餡餅一下砸中你， 那是做夢。 我聽過好多人說我沒有環境鍛鍊技術，只要給我個機會我能怎麼樣怎麼樣的。 或者說只要給我個機會我一定好好努力學習工作等等等等。 但是我都一直特別想說一句， 憑什麼呢。 憑什麼這個機會就要給一個什麼都不會的人呢？ 我們為什麼不招一個有經驗的或者起碼是自學過懂一點的呢。 所以有些時候， 我們真的要改變一下思維方式， 不是有了機會才去努力， 而是努力了才能有機會。先盡人事，才能聽天命。

永遠要留給自己學習的時間

說到學習就要聊一下我們總會說到的問題， 就是很多人忙到了沒時間學習的程度， 他們一直都在加班。 這個問題也很現實。 但是沒辦法， 我們一定要想盡辦法留給自己學習的時間，減少一點娛樂活動，少打一點遊戲，多留給自己一點時間學習和思考。這也是為什麼我每到一個專案， 可能第一件事就是開始想怎麼做自動化。 一個專案比較好的狀態是： 投入自動化專案-- 節省人力成本 -- 有更多的時間去投入到技術專案來 -- 節省更多的人力成本 -- 有更多的時間去做別的事情， 良性迴圈。 而比較差的狀態是：自動化投入不夠--專案加班--加班太多沒時間做自動化--繼續加班， 惡性迴圈。 惡性迴圈也稱技術債。 你越是把自動化專案往後拖延，你的技術債就越多， 因為產品是不會停下來的， 它會一直向前走。 會有越來越多的功能被開發出來需要被測試。 你越是往後拖延，你就越沒有時間去做你想做的事情。 所以要從一開始就想盡辦法去擠時間去把自動化專案建設起來， 即便是多加加班。

親自去做

最後我想分享的一個經驗就要多去自己感受， 如果要開發一個測試工具，或者要在業務線推廣一個自動化測試型別。 不要只去聽業務線上的人說什麼， 最好要親自去業務去做跟一輪專案。 因為這世上是沒有什麼感同身受的， 我習慣親自去感受業務線上的痛點，而不是聽其他人描述。 溝通的再怎麼順暢都會有資訊的缺失。 所以自己去測試這個任務， 自己去開發這個工具，自己去使用這個工具。 才能得到好的結果。

尾聲

好了今天就講到這裡，希望這些經驗對大家有用