職業經驗｜我在阿里做測開

Code~Rush發表於2021-09-15

本文是《聊下自己轉型測試開發的歷程》的姊妹篇，上篇講述我的職業歷程，這篇講述我在阿里工作一年對測開崗位的體感以及給想轉測試開發的朋友一些建議：如何轉型測試開發。

1.我對阿里測試開發崗的看法

對測開崗位的理解：測試開發仍屬於“測試”，測試工程師側重“被動”的質量保障，即通過常規的測試手段保障業務質量，但隨著公司業務場景的複雜以及研發週期的不斷縮短，這種傳統的質量保障手段已不能滿足新研發模式下對產品質量的要求，如何在活多人少的情況下保障高質量，這就需要測試人效的提升（同樣的時間做更多的活）和化“被動發現”為“主動出擊”提前發現問題的能力。如何做到這些就必須藉助於技術手段了，而這也就體現測試開發中的“開發”能力了。但測開最終的目標仍是質量保障，所以我認為測開仍屬於測試。

當然知乎上有類似問題的帖子，大家也可以看看：測試開發是什麼？為什麼現在那麼多公司都要招聘測試開發？

我在阿里做什麼

1.阿里測開型別

大家可以在招聘網站看到阿里巴巴開放的質量崗位基本上都是測試開發崗，而入職後具體從事的工作內容是要視你面試的團隊而定(面試過程會告訴你大概的工作內容)。據我瞭解，阿里的測試開發可以分為兩類：

一種是純技術型的，專注質量工具和各種“神器”的開發，他們服務於業務團隊，旨在解決業務測試遇到的各種難題（比如測試有效性、流量回放等。這裡分享一篇南門大佬的文章《阿里研究員：軟體測試中的18個難題》）。
一種是業務測試+技術專項，基本上7/3分，偶爾業務量重的時候10/0分（當然了，團隊內部的測試人員技術水平有高低，而技術相對較好的同學可能業務量稍微輕一些），因為深入一線做業務測試是發現各種測試難題的先決條件，而解決業務測試難題往往要藉助於技術手段，所以技術專項由此而來，而專項課題一般來自於團隊內部測試人員遇到的測試難題。

2.我在阿里的工作內容

我所在的團隊是有承擔業務測試工作的，研發/測試比大約在4:1。我們測試團隊每個成員單獨負責一塊業務測試還兼做專項，例如提效工具/機器人、線上巡檢工具、測試覆蓋率的課題等。

業務測試就是功能測試，不外乎點點點。當然基於技術架構不同，阿里更鼓勵測試左移和右移。左移如參與code review（7有硬性要求）、異常測試等；右移如關注線上監控、應急這些。（安全、效能測試這些都有專門的團隊做，你只需提工單即可）
介面測試用例開發，一般是在測分後提測前開始編寫，利用團隊自研的介面測試框架開發介面測試用例，除了增量測試用例，還要維護存量測試用例。

寫文件。入職以來文件統計資料顯示我每天至少有一篇文件產出，而我竟然毫無察覺。
對外提供支援。對兄弟域聯調&提供造數等工具支援

協調&溝通。不得不說在阿里做專案的溝通成本是比較高的，因為你的兄弟域可能分佈在"五湖四海"，甚至是國外。如果你是主測，那麼你就要負責全鏈路質量保障的責任，協調&溝通各域的測試同學的測試進度、專案風險；上線時候要緊盯線上監控和報警等問題。
技術專項就是我上文說到的，課題來源於測試過程遇到的難題。例如如何證明你的測試是有效的？如何儘可能快的監控到線上報出的問題？

3.重複造輪子問題

也許你會問，都在做專項、做測試平臺？是不是在重複造輪子？

首先告訴你結論，確實是在重複造輪子，而且我認為是必然的。

我入職至今，已經接觸（使用）多達3個介面自動化測試框架，這麼多框架的由來也是有原因的，例如舊框架升級成本高，導致老業務的自動化測試用例沒有完全遷移到新測試框架，進而要維護多套測試框架的用例；還有就是我們經常涉及到跨域測試(補位)，而不同域有自己的一套測試框架，所以你也要掌握。但是我對重複造輪子的態度是中立的，並不反對，我們應該從多方面看待這個事情。

從阿里自身業務架構看，阿里的產品業務複雜度高，技術實現架構是微服務，不同業務模組(也稱為域，例如資金、金融、支付等)是不同的測試團隊負責，各域間既是合作又是競爭的關係。

從業務全鏈路角度看，各域是相互合作的，協同保障產品質量，缺一不可，任何一個域出現問題最終都會影響到使用者體驗。
從團隊角度看，各域又是相互獨立&競爭的。這是因為各域的老闆（一般是8）是不同的，而不同老闆對團隊的管理策略可能是不同的；團隊間要比拼KPI，因而也有一定的“競爭”關係（哈哈，這也可能是大家常常掛在嘴邊的“內卷”吧）。

各域間的質量要求可能不盡相同。例如資金域，對資損是0容忍的。因此各域間對業務質量保障採取的測試策略和方法可能略有不同。

當然從側面說明阿里的質量基建建設已經比較完善了，在國內已經是top級別了，畢竟經過了20多年的發展。
從測試(特別是小P)自身看，我認為技術產出相對業務產出顯得更重要。因為做好業務測試是基本工作，話說人無我有，技術產出對於衡量團隊成員間績效就顯的非常重要了（不可否認一部分輪子確實生而為績效）。

客觀來看，正像國家提出的“大眾創新，萬眾創新”的口號一樣，提供一種競爭氛圍也許是一件好事，黑貓白貓捉到老鼠就是好貓。也正是眾多輪子的存在，才襯托出最終“贏家”的可貴。

當然了，重複造輪子的缺點就是人力資源的浪費，對於公司來說是一種用人成本損失，我相信國內的大廠或多或少都會有類似的問題吧。

2.測試開發職位要求

想做測開，首先就要明確其崗位要求。不同公司對測開崗位的招聘要求是大同小異的，大家可以看下BAT發出來的招聘資訊。

2.1BAT測開

BAT對開發崗位的要求總結：

與國外測試開發（SDET）崗位職責的比較

1.自動化用例開發

精通專案語言（Java、Javascript、C# ）
與開發人員協作review單元測試和整合結果以進行覆蓋率分析

設計、開發、執行和除錯自動化測試用例和指令碼

2.CI/CD

為高質量的自動化可交付成果建立分支策略
持續整合，將自動化指令碼整合到 CI/CD pipeline。

3.測試框架

為團隊測試框架選型
使用不同的自動化工具和技術提高自動化效率和覆蓋率

4.質量度量

設計實時自動化儀表板以衡量構建質量並向敏捷交付團隊提供反饋

綜合比較下，國外對測開要求和國內的差別不是太大，建議大家可以參心儀公司的招聘要求準備，哪裡不會補哪裡。當然了，一定要有專案基礎哦。

2.2測開VS測試薪資對比

直接看圖對比已經比較直觀了，測開和測試工程師薪資之間差一個測試工程師。

2.3職業發展前景

測試開發崗位增速是測試工程師崗位的將近4倍，預測未來仍會保持高增速。現階段來看，測試未來是就是測試開發！

3.測試工程師如何轉型測開

3.1擺好心態&開放眼界

我始終認為掌握技術最重要，title不重要。測試工程師和測開只是title不同，工作內容並沒有明確的邊際，這個完全取決你對測試的看法！有可能一些公司的測試工程師做的是某些公司測開的乾的活，而一些公司的測開可能做的是某些公司測試工程師的活。就像我在位元組時候，title是測試工程師，工作內容是業務測試+介面測試平臺開發7/3分。而在阿里則也是差不多（甚至阿里的業務還更重些）。對於我來說兩家公司的工作內容是沒什麼區別的，只是title不一樣而已。

對於想轉測開的測試工程師建議：調整心態，不要以“測開”唯是，提升自己的技術能力才是重點，要養成持續學習的習慣，多接觸一些知識，擴充自己的眼界，在業務測試過程養成“偷懶”的習慣，多思考自動化手段減少手工測試工作。

3.2夯實基礎&運用技術

1.程式設計能力要過關

至少精通一門語言。而且使用該語言開發過工具或平臺最佳。一是測開面試通常要程式設計寫程式碼，這個是門檻。二是有開發經驗能側面證明你對開發語言的熟練程度。

至少掌握一個開發框架。例如spring boot、flask、Django等。

2.基礎演算法要熟悉，學習的同時建議結合LeetCode練習。

1 快速排序演算法

2 堆排序演算法

3 歸併排序

4 二分查詢演算法

5 BFPRT（線性查詢演算法）

6 DFS（深度優先搜尋）

7 BFS（廣度優先搜尋）

8 Dijkstra演算法

9 動態規劃演算法

10 樸素貝葉斯分類演算法

3.有所專長(亮點)

前文說到過的一個道理，人無我有。在大家都掌握相同“技能”的前提下，你能做的更深入或者有別具一格的idea，則這就是你的亮點。例如擅長效能測試、擅長效率工具開發、擅長平臺搭建等。當然這個因人而異，視各人興趣點而定。

4.多利用技術手段解決業務問題

我認為這個是最重要的。縱然你掌握上述能力後，但是缺乏運用技術解決實際問題的能力，仍然是紙上談兵。正如第2節所說的，測試開發崗位職責都要求解決複雜問題的能力。而我在面試中問到的最多的問題就是為什麼做這個東西？你這做的東西解決了什麼問題？後面我會附上面試經驗分享，裡面包含所有面試題目。而如何提升解決問題的能力，第一步就是要善於發現問題，這就要求工作中大家保持懷疑心態。

3.3“創新”意識

不可否認創新是屬於少數人的專利。但是並非大多人不能創新，作為普通大眾的我們可以二次“創新”，將前人作出的成果二次創新運用到我們的業務中並解決一定的問題，我覺得對於普通人來說這就足夠了。

如何保持開放心態？建議大家多參加測試沙龍和論壇，業界比較專業的測試論壇如：每年兩場的MTSC大會，議題質量是相當高的，基本都是BAT議題佔了半壁江山，可以說BAT的議題成果就是國內測試界的發展標杆和方向（雖然BAT的議題可能是別人玩剩下的）。此外，關注各大廠的技術公眾號，多看看他們發的文章提升眼界。