如何做好測試開發？| 破解測試人技術成長常見的 3 種錯誤思維！（如何做好測試開發）

本文為第四范式質量部工程效能負責人，霍格沃茲測試學社特邀嘉賓山治老師關于測試開發工程師技能成長的精彩分享。進階學習文末加群。

前言

大家好，我是山治老師，目前在第四范式質量部中負責工程效能方向的工作。我在這家公司有 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 么？

我們要知道對于一個好的測試開發來說，同時掌握幾門語言和技術是完全是必要的。因為你面對的是各種不同的場景，這不是一招鮮都解決的。

所以，我要強調**我們要解決的是這個領域內盡可能多的問題，而不是只解決一個問題中的各種細節。**解決不同的問題可能會用到不同的語言不同的技術，這很正常。

不要陷入一個極端的狀態我要做專家，我要把所有精力都放在一樣事情上， 然后專到一個特別細節的東西上去了。我見過有同學就沖著一個接口測試使勁，一做就是幾年，你一問就說我接口測試做的特別好，我開發了什么什么框架，什么什么平臺。但是你接口測試做的再好，它也只是接口測試。它也只是這個領域內龐大的測試體系中的一環。

所以一個領域和一個技能的差別我們需要明白，如果你只專注一個細節，那就只能偏安一偶做個執行者，因為你撐不起這個團隊，你能解決的只是這個團隊要面對的形形色色的問題中的一個。如果你想走的更遠，就去關注你所在領域里更多的問題。

幾種不好的思維

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

第 1 種是：當你所擁有的技能已經完全能滿足當前工作需要的時候，是即便你學了更多更深的知識也在當前工作中用不到的時候，那種突如其來自滿或者是不安。

這是兩種截然不同的結果。但怎么處理好這兩種情緒是很重要的。

自滿是因為覺得一切盡在掌握，他在當前工作里所有的技術問題他都能解決，可能會讓他錯誤的認為他能解決這個領域里所有的問題，或者錯誤的認為這個領域里就只有這么多問題了。處于這種情緒下的人會自然而然的停止自己的腳步，但是你要知道既然你選擇了技術路線那么你的腳步就是不能停的，技術永遠在不停的更新換代，停下腳步后，吃上幾年老本可能就要被淘汰了。

而不安是因為他意識到自己的腳步已經停下來了以及停下腳步帶來的后果，所以這個時候他不安，因為他沒什么辦法，當前的工作已經沒辦法驅使他前進了。

自滿和恐慌是幾乎每個技術人都要經歷的，有些人是先自滿后面慢慢恐慌，有些有經驗經過幾次這種狀態的人可能是直接跳到了恐慌。比如我現在每年都有幾段時間會陷入不安，通常就發生在要推進的方案都落地并穩定了以后，這時候我就會想我接下來該做什么。

所以這時候我們要好好的思考一下，給自己的工作帶來一些變化。可以是內部申請調整一下業務線，我們換另一條業務或崗位去尋求一些突破，因為不同的業務有不同的問題，也許在另外一條業務上你又能折騰一段不短的時間并讓你在自己的領域里增加更多的競爭力，又或者我們引進一個全新的測試類型或工具平臺來給自己帶來新的挑戰與機遇。

18 年的時候，我曾經陷入過這種狀態，當時我大概彷徨了有半個月的時間，我一直在思考在糾結下一步要去做什么。最后我決定引入混沌工程這種我們以前沒有的測試類型，在當時我們是沒有能力做這件事的，因為那會的時候 chaos-blade 和 chaos-mesh 都還沒有開源。所以從技術角度上來講這是一個很大的挑戰，因為我們面臨的是 K8S 場景下的故障注入和監控。這帶來的結果是我必須從以前在業務層使用 K8S 往下發展，甚至要去研究 K8S 的源碼然后向其中注入不同的故障。

我也曾經調整過業務線，就在 2 個月前我還申請去另外一條我沒接觸的產品線去趟坑，我們的 UI 自動化已經從 Selenium 到 Selenide，單機到分布式的演進，積累了快 3000 條測試用例，可以說已經是很成熟了，但是在這新條業務線上我開始實踐 Cypress 這種使用前端技術棧來做 UI 自動化的框架。 我希望 Cypress 能為我們帶來一些新的變化，一些好的變化。

所以其實總結一個字就是變，我們需要經常的變化。產品在變，技術在變，我們自己也要變。變則活，困能死。很多公司每年都會做各種組織架構的調整，也是為了能讓變化帶來一些新的東西來。如果不變化，面臨的可能就是不進則退的記過。

當然變的過程一定是挑戰的，是痛苦的，因為你要不停的學新的東西，但我們要知道走技術路線一定是不舒服的，如果你走的太舒服，那么用不了幾年，你再去找工作的時候，你可能就不會很舒服了。

第 2 種比較不好的思維是：對追新技術的質疑。

不少人在想技術更新的太快，現在去學這些技術有什么用，用不了多久就會有新的技術出現。所以他就不去學習新的技術了，他相信自己把基礎學好了，比如把把計算機原理，算法和數據結構學好了就可以了。

我發現真的有不少人這么想，這兩年業界比較強調學習能力，認為快速的學習能力才是最重要的，我記得去年還是前年有人提出來測試界的全棧其實就是快速的學習能力。而不少人堅信只要把這些基礎學的扎實了，他碰到什么都能立馬學會，因為這些是一切的基礎。

我不太清楚為什么他們會認為在不去真正的戰場上真刀真槍的走一遭就能練出一身的本事。這個所謂的學習能力到底是怎么來的。要知道學習能力從來都不是自己憋出來的，學習能力是你自己一步一步，一個坑一個坑趟出來的經驗。

對于大多數人來說，學習能力其實就是一種經驗。是一種你在面對一個新技術的時候，你發現你以前用過的一個東西也有這種場景，所以你立刻就能反應出來幾種解決方案，然后看這個新技術是用哪個方案解決這個場景的。所以你能立刻明白這個新技術的設計原理，使用方式，而不是冥思苦想。所以你比其他人學的都快，對于大多數人來說，這種經驗才是學習能力。而不是一些人盲目迷信的基礎知識。

比如大數據領域技術的更新換代也是很快的，最早的時候我們還在用 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，而要多去學習和思考它背后的一些東西。

而學習能力就是解決問題的經驗，是這些經驗讓你面對新東西的時候，進展的更快。

第 3 種比較不好的思維是，眼前工作上用不到的東西我不用去學習。

這也是一種常見的想法。但是首先你的業務是不會停下腳步的，它也會從簡單走到復雜。我們是需要為了未來要面臨的問題而儲備一些技能的，我后面也會講到，機會是給有準備的人的，我們還是要盡量避免書到用時方恨少的情況的。

再一個有些時候沒去了解一些東西的時候，你真不知道它有多有用，也許它對你現在的工作有一個很大的優化的作用，但你不知道。這也我說在做加法的時候強調過的。我一直都建議多去學習研發會用到的技術，它不僅僅在做工具開發的時候提供幫助，很多時候他能讓你測試的更好。因為你更懂你的產品架構是怎么樣的。

還是拿 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 Pipeline 與 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 一點都不了解的人跑去請命要攬下這個任務，那可能就是個笑話了。機會永遠是給有準備的人的，不想努力的去準備，還想讓機會像天上掉餡餅一下砸中你，那是做夢。

我聽過好多人說我沒有環境鍛煉技術，只要給我個機會我能怎么樣怎么樣的。或者說只要給我個機會我一定好好努力學習工作等等等等。但是我都一直特別想說一句，憑什么呢。憑什么這個機會就要給一個什么都不會的人呢？我們為什么不招一個有經驗的或者起碼是自學過懂一點的呢。

所以有些時候，我們真的要改變一下思維方式，不是有了機會才去努力， 而是努力了才能有機會。先盡人事，才能聽天命。

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

說到學習就要聊一下我們總會說到的問題，就是很多人忙到了沒時間學習的程度，他們一直都在加班。 這個問題也很現實。 但是沒辦法，我們一定要想盡辦法留給自己學習的時間，減少一點娛樂活動，少打一點游戲，多留給自己一點時間學習和思考。這也是為什么我每到一個項目，可能第一件事就是開始想怎么做自動化。

一個項目比較好的狀態是：

投入自動化項目\-\- 節省人力成本 \-\- 有更多的時間去投入到技術項目來 \-\- 節省更多的人力成本 \-\- 有更多的時間去做別的事情，良性循環。

而比較差的狀態是：

自動化投入不夠--項目加班--加班太多沒時間做自動化--繼續加班，惡性循環。

惡性循環也稱技術債。你越是把自動化項目往后拖延，你的技術債就越多，因為產品是不會停下來的，它會一直向前走。會有越來越多的功能被開發出來需要被測試。你越是往后拖延，你就越沒有時間去做你想做的事情。

所以要從一開始就想盡辦法去擠時間去把自動化項目建設起來， 即便是多加加班。

親自去做

最后我想分享的一個經驗就要多去自己感受，如果要開發一個測試工具，或者要在業務線推廣一個自動化測試類型。不要只去聽業務線上的人說什么，最好要親自去業務去做跟一輪項目。因為這世上是沒有什么感同身受的，我習慣親自去感受業務線上的痛點，而不是聽其他人描述。溝通的再怎么順暢都會有信息的缺失。

所以自己去測試這個任務，自己去開發這個工具，自己去使用這個工具。才能得到好的結果。

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

獲取更多內容：

https://qrcode.testing-studio.com/f?from=hwyun&url=https://ceshiren.com/t/topic/16586

點擊查看

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。