分享一下自己的簡歷， 拋磚引玉歡迎討論

前言

我看到有同學希望大家能分享一下一些簡歷，大家可以參考討論， 並且我記得也有位同學覺得很多時候學習知識，其實都是有潛在目的的。對著簡歷要求和描述，反過來去選擇學習什麼知識的方式會更有成效。 所以我就來寫這麼這篇文章了。 但亂髮別人的簡歷是不道德的， 所以我把自己的簡歷脫敏後發出來給大家看看。 因為每個人涉及到的領域是不一樣的， 並且工作經驗不同簡歷的內容也是不一樣的。 所以為了我會把自己 15 年的工作經歷拆成幾個階段來展示，並且會解釋一下這個階段主要在做什麼事情

還有就是簡歷會有裁剪，畢竟簡歷內容還是挺多的， 包括什麼興趣愛好啥的或者一些我覺得不重要的東西就直接剪掉了。 還有學歷背景也不寫了， 熟悉我的人都知道就是一個普通三本，電腦科學與技術系。

PS：我本人寫簡歷其實沒什麼技巧， 完全是憑藉著我這些年做面試的心裡活動來倒推用人方喜歡什麼樣的簡歷。

第一階段 -- 畢業 4 年半

首先要說一下因為實習和剛畢業那會實在沒什麼好寫的， 因為真是啥都不會沒有任何經驗。 並且實習的時候直接轉正了，也沒寫過什麼簡歷。實習的時候在文思創新（後來改叫文思海輝， 倆外包公司合併了）， 我都略過了（也沒什麼好寫的， 外包公司麼， 就是點點點，只有在最後一家做了一些自動化的東西）。

個人擅長技術描述：

• 熟悉 java 語言，可使用 java + testng + selenium 編寫自動化測試用例
• 良好的英語水平，可使用英語溝通工作內容

工作經歷

2012/11 -- 2015/5 公司：和益達 (包公司) | 測試工程師
2010/07 -- 2012/11 文思創新 | 測試工程師

專案經歷（一）

Ariba on-demand spend management

專案職責：

• 根據使用者需求以及 bug 描述編寫測試用例和測試計劃。
• 執行程式碼覆蓋率工具（Corbetura）編寫單元測試用例（ariba 採用模組開發，部分資料遷移能力的單測可交給測試人員編寫）。
• 使用 Selenium 編寫 web UI 自動化指令碼。自動化小組 3 人共維護用例規模 -- 4 千。 採取 selenium grid 作為瀏覽器叢集加速用例執行。
• 負責開發測試工具，編寫產品後門程式幫助測試。
• 赴美國參與新功能的開發測試，包括功能，資料遷移等。

專案描述：Ariba 支出管理 (Spend Management) 解決方案，幫助企業分析、理解、及管理整個企業的支出，以節約成本與提升流程效率，其解決方案包括專業諮詢服務、資訊科技、以及供應商網路的全面組合。主要地分為如下幾個部分：1）尋源及招投標為主的上游，2）下游的採購到支付的執行，3）能見度解決方案，以及與其它如 ERP 等應用系統的整合部分。

專案經歷（二）

MSTV（微軟數字電視系統）

專案職責（這份工作偏運維）：

• 根據測試需求配置網路環境以及系統環境，後期編寫 power shell 編寫自動化配置工具。
• 日常測試與開發機器的運維工作，機器規模 -- 300

專案描述：該專案是微軟收購了一家電視公司後成立的，功能與一般數字電視相似. 客戶主要為美國民眾，提供收費電視服務。

總結

嗯， 確實沒了，在外包的這幾年裡能拿的出手的東西確實有限。 不過總算是自動化入了門， 能搞的了 UI 自動化， 能開發一些簡單的小工具， 在微軟那會接觸到了一些運維的東西，那其實對後面幫助不大，因為微軟的技術都是 C# 和 power shell，離了微軟的生態圈是屁用都沒有， 外面的公司是不可能用這套東西的。 不過好歹這段經歷也是個加分項吧，畢竟有運維的經驗和編寫指令碼的經驗。 加上在 ariba 專案中涉及到的 java 和 UI 自動化，單元測試這些，在當時是可以讓我從外包跳槽到網際網路的，畢竟 2015 年那個時候，講道理能寫程式碼的測試也不是很多的。即便是我跳槽到了 58 到家，也發現整個公司幾百人，測試團隊幾十人裡， 能寫程式碼的就那麼幾個人。 那個時候在這些小公司裡測試人員就是點點點的點工，但當時在大廠，已經有很多測試人員懂程式碼了。 再上 15 年那會正是網際網路爆發的那幾年， 創業公司如雨後春筍的冒出來，工作崗位也比較多，所以憑藉著這個履歷也是在 2015 年的時候跳槽到了 58 到家， 這也算是我擺脫了外包的身份進入了網際網路領域。

這裡想說一句， 其實跳出外包圈子進入網際網路在當初那個時期也沒那麼容易， 雖然我上面寫的輕描淡寫的。 但在外包公司裡想找個能寫程式碼的工作其實是很不容易的。9 成 9 的人都是在點點點。 甚至我入行的時候底子更差，實習的時候就不是測試工種，有點類似行政人員一樣， 在微軟的辦公區裡打雜。 後來發生過很多事情，比如：

• 離職被卡，導致下家公司說好的專案沒進去，因為都是在微軟專案中，就是換了個公司，導致原公司到微軟投訴了，當時這個行為還是挺敏感的。 所以那個專案我就沒進去，然後我就被安排到了一個偏遠的小屋子裡，去看著人做類似眾包測試了，就是當時有個練習用手機打字的軟體（嗯，那會智慧機剛剛冒頭很多人其實不會用手機打字），然後請那些小時工（大多都是學生兼職掙外快的，請過來幹幾個小時就結算幾個小時的錢）。 我就負責看著這些學生，然後收集測試結果， 我有時候也上手測試，但其實就是用軟體打字。
• 實習的時候就不是測試團隊的， 為了能擠進測試團隊（雖然只是個本地化國際化測試小組），我自己私下找了一些測試組長，求他們收留我。 後來總算是微軟的 hotmail 組把我收編了，算是入行了測試領域。 當然這就是個做本地化國際化的，沒有任何技術含量，甚至測試用例都是美國那邊寫好了我們執行的。所以就沒寫在簡歷裡，因為實在不是什麼光彩的崗位。
• 在微軟的時候為了能接觸自動化又是求爺爺告奶奶的， 主動找到 manger 希望能去自動化小組。 後來幾經輾轉，總算是拿到了這個機會。 算入門自動化了， 那段時間工作很努力， 天天寫程式碼非常開心。
• 去美國也不是很舒服， 語言不通（我的英語都是工作用於，生活上很難）， 再加上窮，連個頭都捨不得減（那邊剪頭是真的貴，找個街邊菲律賓的剪頭師傅都得 20 美元），所以在美國最長的一次有大半年， 天天都吃酒店和公司的免費餐， 但免費的大家都懂得， 沒什麼好東西。 週末就去吃快餐， 那邊麥當勞倒是很便宜， 2.5 美元就是一個最簡單的套餐，並且可樂無限續杯。 在那 2 年裡有一半時間都在美國待著， 吃著這些垃圾食品，其實對身體是有害的，我現在腸胃很不好， 也懷疑是那個時候落下的病根。 還記得有一次是在饞的受不了了， 讓我們老大帶我們找了一家中國餐館。 我們看見菜上桌的時候眼睛都綠了， 就跟那狼群進了羊圈一樣。 全程沒人說話， 就是在風捲殘雲的吃。不過老實講那那段物質上欠缺了一些， 精神上還是不錯的， 練了英語，矽谷工作環境也好，時不時的老大會帶我們出去走走（基本不花錢那種），感覺像旅遊一樣。

上面說的挺多的，其實就是想表達在當初從外包轉到網際網路，尤其還是進網際網路的寫程式碼的崗位，也是很不容易的。 挺多時候機會是需要自己爭取的，就像為了能出來實習，我們 4 個同學晚上給導員送禮（當時學校不讓我們出來實習， 因為我們報的培訓機構本來是和學校有合作的，但後來合作談崩了，學校就不讓我們出去了。所以我們才來求導員睜一隻眼閉一隻眼）。實習和工作的時候為了能進更好的組也是主動找領導去聊，主動去跳槽到更好的團隊，這些都是要自己爭取的。 並且我大二那年就報了培訓班學了 3 個月 java，學習期間成績很好，爭取到了機會在大三免費給培訓班老師打了一年工練手。所以有 java 的底子的，這在後面找自動化測試的工作才算有了一定程度的依仗。 很多時候真的， 機會不是什麼都不做就等著從天上掉下來的。

當然， 運氣也很重要， 而且十分重要，並且在那個時候網際網路剛興起， 從業人員不多，所以工作相對比現在好找太多了，這也算入行早的優勢，能在早期用比較低的門檻進入這個行業，然後快速的去積累行業經驗在這裡站穩腳跟，後面的路就順暢多了。 現在入行的小同學們。。。。嗯， 是真的難

第二階段 -- 2015 年的 10 個月

2014 年和女王大人相識相戀，談婚論嫁，讓我更加迫切的感受到了經濟壓力。 所以離開外包進入網際網路迫在眉睫。 當時 O2O 興起， 58 也入了局，成立了一家新的公司 -- 58 到家， 我聞聲而動找了在裡面工作的同學， 把簡歷推薦了進去。 獲得了面試機會併成功進入這家公司。 但由於很多操蛋的事情也就呆了 10 個月就走了。 這段時間的履歷補充在下面。

個人擅長技術描述：

• 熟悉 java 語言，可使用 java + testng + selenium 編寫自動化測試用例
• 熟悉 jmeter，可根據 jmeter 公開的工具包進行二次開發，可分析效能缺陷，使用監控工具。
• 熟悉介面自動化測試，可獨立開發介面自動化測試框架
• 良好的英語水平，可使用英語溝通工作內容

工作經歷

2015/5 - 2016/3 58 到家

專案經歷（一）

nocode 介面自動化測試工具獨立開發：

• 該工具使用 java 語言，由於業務測試人員普遍不懂得編寫程式碼，所以採取關鍵字驅動的設計，利用反射原理，把使用者在 execl 中編寫測試用例翻譯成程式碼執行介面自動化測試。
• 推廣該工具，並帶領業務測試人員完成相關的介面自動化測試工作。

專案經歷（二）

56 到家 APP 測試工作

• 測試以及線上環境巡檢監控工具的開發： 為解決線上和測試環境不穩定的問題，開發相關自動化工具週期性巡檢環境並在異常時告警，主要方式有服務的心跳檢測（埠探活），自動化測試的定期巡檢。整合到公司的 jenkins 平臺中穩定執行。
• 測試環境資源管理平臺開發 (包括自動化部署，資源管理，許可權管理等等。參與後端開發)
• 引入 Jemeter，並培訓業務線人員進行效能測試。制定效能測試方案並排查與分析效能缺陷。 整體方案使用 jmeter+influxdb+grafana，監控平臺為 58 內部平臺。
• 資料恢復工具與資料準備服務的開發。實現一鍵準備測試資料。簡化業務線測試人員的測試工作
• 推進持續整合，使用 jenkins 編寫 job，將自動化測試加入到持續整合流水線中。
• 定期組織技術分享會，培訓業務線人員技術能力。

總結

在 58 只呆了 10 個月， 但我其實很珍惜這個能進入網際網路，並且還是在測試開發組裡工作的機會。 所以這段時間拼命的學習， 我記得看了 mysql 的一本書， 看了 jenkins 的一本書，還看 linux 的部分內容（主要看效能分析上了， 全套的真沒看下來）。 所以做出的成果也不少， 搞了介面自動化測試工具的開發（當時還興沖沖的搞了關鍵字驅動的，但在後來我十分看不上關鍵字驅動的東西。。。。），把效能測試也搞下來了（看 linux 和 mysql 的書也是為了效能測試），還二開了 jemeter。 入門了持續整合，搞了 jenkins。零零碎碎的小工具也有一些。 這個時候就徹底轉型成技術工種了， 這也為後面進入第四正規化打好了底子，因為第四正規化的測試團隊真是全員測試開發，不會寫程式碼的連外包崗都進不去。

這裡有個小插曲，我當時寫簡歷的時候還厚顏無恥的給自己加了個測試架構師的 title，當時眼光很淺，覺得自己挺了不起了。 畢竟當時圈子裡的 9 成 9 的人都是在點點點， 我這又二開 jmeter，又玩 jenkins 又開發測試框架的，著實是自大了一把。 後來進了正規化以後， 接觸了那麼多更復雜的技術棧，才明白， 在 58 的這個時期的我，充其量也是小桌坊， 屬於矬子裡拔大個的水平。

第三階段 - 入行 AI 大資料與雲原生階段

這裡的簡歷就比較長了， 因為在第四正規化呆了差不多 5 年半， 時間太長了， 所以做的東西有些多。

工作經歷

2016/3 - 2021/7 質量部下屬工程效能組組長

自我介紹/個人擅長

• 熟悉程式語言：golang, java, python, js ，ts
• 擅長容器領域（docker&&k8s）內的各種實戰專案。曾經推動並設計開發了公司內的各項容器化專案，包括但不限於：
  • 公司核心心產品，自動化測試等工程的容器化改造。
  • 設計並開發基於原生雲架構下的混沌工程工程。
  • 編寫基於 k8s 的產品部署工具和環境治理系統。
  • 整合 jenkins pipeline 與 K8S 最佳化 CICD 流水線。
  • 編寫 k8s operator 最佳化各項測試工具。
• 擅長大資料領域的各項測試方案，主要應用 spark，flink 和 kafka 相關技術棧，曾經推動並設計開發了公司內資料平臺內各項場景的測試方案。包括：
  • 大資料的批處理和流計算的黑盒，白盒，效能，相容性，穩定性，一致性測試
  • 資料質量監控
  • 大規模造數平臺的開發
• 擅長機器學習領域相關業務，熟悉機器學習的商業模式，各項演算法測試方法， 主導並設計了公司內演算法的效果，效能，相容性等測試方案和工具的開發工作。 曾經帶領過演算法平臺的測試團隊。
• 擅長各項自動化測試實踐， 設計並開發了公司內大部分的自動化測試專案，包括:
  • Web 端 UI 自動化測試
  • 介面自動化測試
  • SDK 自動化測試
  • 部署自動化測試
  • CLI 自動化測試
• 熱愛技術分享，在國內最大的測試社群 Testerhome 撰寫專欄《測試開發之路》。 參與了 2017 到 2021 年的 MTSC 測試開發大會（講師和幕後工作都有涉及）

專案經歷（一）

基於原生雲的混沌工程平臺
產品全部圍繞機器學習的生態構建，並且核心產品均使用微服務 +k8s 的架構，而由於機器學習業務資料量大，計算時間長的特點。 如果程式碼，環境，或其他原因造成的不穩定導致任務失敗所帶來的成本代價非常大，而因為產品使用微服務架構，我們需要涉及到上百個服務的故障注入，工作量巨大。基於此背景下，由工程效能部發起成立混沌工程專項，開發全自動化混沌工程專案，實現全自動化的針對每個服務進行故障注入，測試驗證以及結果分析。 目前該專案已經到 20 年的 MTSC 深圳大會上進行分享。 我的角色是該專案的負責人，初中期負責整個專案的推進溝通和程式碼開發工作，後期交給團隊成員負責。

主要的技術實現簡介如下：

• 對於 K8S 故障注入採取容器領域常見的 side car 模式，向業務 POD 注入故障生成容器，配置引數共享網路，程序，目錄名稱空間。可以達到最細粒度的故障注入且不會影響其他服務正常執行。對於物理機和虛擬機器採用開源工具 chaos-blade 直接以 server 模式啟動， 排程程式控制 server 執行故障的注入和恢復。最後整合 K8S 和物理機兩種注入方式統一排程。
• 監控技術採用取普羅米修斯，監控 K8S 叢集和物理機的各項指標
• 由於 TO B 型別的業務沒有線上環境導流，所以測試過程採取在測試環境針對單個服務注入故障的同時執行全自動化測試用例，同時測試用例對接普羅米修斯，統計測試用例的執行情況最終計算出每個服務的 SLA。
• 分層測試方案上，要求測試人員把服務介面的冪等性測試列為常規的迴歸測試內容。

專案經歷（二）

資料平臺測試專案
資料平臺核心產品之一， 實際上在所有產品中都涵蓋到了非常多的資料能力（包括離線批處理和線上流計算）。所以需要在整個公司產品層面設計一個合理的資料質量保障方案。 我的角色是該專案的負責人，初中期負責方案的設計執行，開發對應的測試工具。 後期交給業務線 QA 獨立完成。

主要的方案條目如下：

• 白盒測試方案： 公司所有產品均使用 spark 和 flink 完成產品的離線和線上業務，所以白盒測試方案上我們深入研發程式碼中， 規範研發的程式碼規範。 第一步針對數以百計的 UDF 和 UDAF 進行最小粒度測試。 第二步要求研發拆流，講計算流按業務拆分成若干子流，QA 針對子流進行整合測試。
• 黑盒測試方案：主要分為兩種形式，第一種編寫 spark 程式掃描資料表，分析資料分佈，值閾，型別等維度，建立 Data Profiling 機制驗證資料本身的質量以及資料處理程式是否按預期執行。 第二種透過造數平臺，在離線和線上業務上透過造數工具準備固定的資料，精確驗證資料處理程式是否如預期執行。
• 效能和異常場景測試方案：開發造數平臺，建立不同的資料分佈（針對資料傾斜）資料規模（針對大資料和寬表）資料型別（針對各個業務對欄位的要求）異常場景 (空表，空列，異常字元) 等等滿足各種場景的測試需要。 造數平臺採取 spark+hadoop 技術棧， 利用 spark 的分散式計算特性和 hadoop 的叢集資源在短時間內造出數十億甚至百億級別資料。
• 資料相容性測試：公司內部各個產品使用了不同的資料處理框架，比如 spark1，spark2，spark3，和 flink，而整個產品策略上各個產品線的資料需要能夠互相流轉形成閉環。 所以測試方案上要求每個資料處理演算法都要相容各種資料格式， 包括 txt，parquet，csv。同時也要相容各個資料框架產出的資料，也就是所有運算元都要能夠處理其他演算法框架產出的資料。 所以我們建立相應測試框架，讓每個演算法都在不同的資料上執行驗證相容效能力。
• 一致性：在整個機器學習生命週期中保持資料離線和線上的一致性非常重要，所以測試方案上驗證離線的資料處理結果與線上的結果需要一致。
• 穩定性：主要涉及流計算業務，產品要求我們的資料需完成進準一次性語義，保證資料不會出現丟失，重複和重複消費的情況， 所以我們以混沌工程的思維，使用故障注入的方式驗證流計算的過程中不會出現上述情況。 同時也是保證流計算所有節點均有精準一次性語義的設計。
• 效果測試：機器學習業務要求每個演算法要達到一定的效果方能上線， 所以我們成立 beachmark 委員會，與客戶溝通，收集脫敏資料，在固定資料集上執行演算法，統計相應的評估指標，驗證演算法效果是否回退。

專案經歷（三）

由於公司產品採取微服務 +k8s 架構，我們面臨上百個模組的每日的更新與構建，過於複雜的架構和人肉的工作方式會嚴重拖慢產品迭代程序。 所以需要一個高度工程自動化的持續交付系統來滿足公司的對釋出週期的需求。我的角色是該專案的負責人， 前中期主要負責專案的推進，設計與開發， 後期交給每個模組的研發與測試人員自行維護。

主要的技術方案如下：

• 主要採取 jenkins 與 K8S 整合的方式， 利用 K8S 動態啟動 jenkins slave node 的形式執行 pipeline，利用 K8S 的分散式能力加強持續交付系統的負載均衡和高可用能力。
• pipeline 中加入 UT，程式碼掃描，映象製作，環境部署，自動化測試一整套鏈條。 部署工具同樣基於 K8S 進行部署。
• 開發測試平臺，其中包括環境治理，專案管理，提測管理和質量視覺化模組。 打通公司內各個平臺的資料，在各個流程加入卡點， 比如研發提測時會檢查提測環境的 dailybuild 是否執行，測試透過率是否滿足要求，當前是否還存在 Block 級別 bug 等卡點。如不滿足需求降阻止提測。 而質量視覺化模組會收集到公司各平臺內的資料統計專案進度，場內工單，bug，dailybuild 等等資料，完成數字化的全鏈路視覺化度量。
• 測試團隊同樣接入 pipeline，完成全量部署到版本釋出的整個聯調的流水線化處理，在整個流程中加入 UI 自動化， 介面自動化， sdk 自動化，部署測試自動化工具等型別的自動化測試。

總結

其實在正規化這麼多年， 不可能只有這三個專案， 但是其他的我當時都沒有寫。 我自己覺得，簡歷麼，不能太長篇大論。 我自己做面試官的感受是每天工作很忙， 不想在簡歷裡花太多時間， 要是候選人寫了特別多的東西， 在一家公司的經歷裡我最多看前三個。 而且寫的太多了，我就比較難判斷出他最擅長什麼的。 所以我寫簡歷的時候就習慣了只寫 3 個我覺得最有亮點的東西。 當初挺糾結的， 因為簡歷寫 AI 的東西少了很多， 沒有突出在 AI 方面的亮點。 比如在專案中開展的模型效果測試， 機器學習框架的測試等等，這也算當初寫簡歷的時候一個敗筆吧， 當時沒太重視 AI 的東西。 如果現在讓我寫，我就會把 AI 的東西放到最前面了。

其實在正規化這邊簡單來說就比較深入的研究了 3 個領域吧：

• AI
• 雲原生（docker 和 k8s）
• 大資料

在這 5 年半里的成長真的是飛速的， 技術上我覺得是質的改變。 在這之前的都是通用領域的東西，不管自動化測試方案還是效能測試這些其實技術難度都不高。 有底子有機會的同學花個 1,2 年時間都能做的到。 底子和機會沒有那麼好的同學（比如我）， 花個 3,5 年也差不多了。 而在正規化裡研究的這三個領域，就算是有門檻了，因為這裡面的東西是真的難， 到現在我都覺得我在這幾個領域裡的造詣在真大牛面前不值一提。 而且這幾個領域相對小眾，當初能拿到機會從事這個領域的測試人員非常少（幹這個事的公司也少， 在阿爾法狗出現之前我們公司去談客戶都不敢說自己是搞 AI 的，怕人家以為我們是騙子， 誰又能想到後面阿爾法夠和大模型的出現，給 AI 續了這麼長時間的命，我覺得這也算運氣了， 我當初選這個賽道是真沒想到後面是這樣的）。所以感覺運氣這個東西也很奇妙的，當初選擇深入研究這 3 個領域， 然後偏偏這三個領域這幾年卻都火了起來。 這也導致了我在 21 年跳槽的時候（正好滿 35 歲），完全感受不到 35 歲危機，畢竟火了那招的人就多。

第四階段 -- 當前公司

因為當前公司的高壓線實在不敢碰，所以我不敢寫當前公司的東西。 而且我也沒有跳槽的打算，簡歷也沒有寫。 不過如果寫的話大概也就是強調突出以下幾個方面：

• 雲原生方面，參與測試了商用 K8S 的測試工作，重點測試效能和高可用。期間開發了一些工具。 比如：
  • 效能測試方面引入 kubemark 開發了模擬大規模 K8S 節點的工具，模擬了 2000 節點的效能測試。
  • 效能測試方面引入普羅米修斯，開發監控平臺，開展容量測試，自動化的效能測試
  • 高可用方面二次開發了 chaos-mesh，新增了部分故障型別。
  • 根據 k8s 的 listandwatch 機制，在監控平臺中開發了 k8s 異常事件監控
• AI 方面，對比在第四正規化的時候接觸了計算機視覺和大模型的產品測試工作。比如：
  • 計算機視覺：負責產品超過 100 個識別場景的效果測試，開發 sdk，微服務和端到端的自動化效果測試框架，需要強調的是端到端效果測試中引入了 orc 能力來識別告警幀。
  • 計算機視覺：使用 opencv/ffmpeg/easydawin（流媒體伺服器）/blink 模型/yolo 模型 等技術開發出了一套資料處理工具鏈。 可實現資料採集，挖掘，增強，裝置模擬，抽幀，影片合成等功能來輔助效果，效能和功能測試。
    
  • 大模型方面：主要是接觸了一些智慧客服產品（其實做的有限），瞭解到了大模型的各種測試場景。
• 大資料方面：這個沒什麼太多可以說的， 因為跟在正規化的時候用的技術棧是一樣的，無非就是多學習了一些大資料元件，比如 ck， 在 ck 上還開發了一些效能分析的工具什麼的。

結尾

這些年的工作履歷就差不多這樣了， 當前公司的東西實在不敢提跟業務有關的一個字，所以也就寫寫測試技術上的東西。