大數據小白的測試成長之路

引言

22年校招入職京東後,我一直在數據中臺測試部從事測試開發的工作。畢業後,寫的最多的文檔是測試計劃和測試報告,鮮有機會就自己的成長碼字進行回顧和總結。借“up技術人”欄目,也終於是在工作之餘回頭望,對自己這近兩年時光進行一個小總結。

本文是一個大數據測試小白初入職場後的成長總結,有新人入職的迷茫,也有點滴積累後的經驗之談。希望此文能夠對正在迷茫的新人朋友以及對大數據測試有興趣的同學有些幫助。

1.初入職場:站在迷茫的十字路口

我在本科和碩士階段的專業都是計算機科學與技術,研究生時期的研究方向是網絡嵌入,雖有過短暫的實習經歷,但也是偏向業務測試,可以說對大數據是知之甚少。leader 只對我說:“剛開始不會很正常,在學校大概率接觸不到這些,都是一點一點入門的,沒關係,慢慢來。”

剛開始接觸工作,只能說是一個“看不懂”。

大數據領域有很多的專有名詞和英文縮寫,“集羣”、“隊列”、“RSS”、“NN”、“DN”、“NS”等等,面對這些陌生的概念,我實在有點慌,於是我選擇了最“學生”的辦法--看書。

不可否認看書是有用的,但是效率太低了,而且在實際工作中,大數據存算引擎的改造很多是自研而且具有一定實際背景的,依靠專業書並不能切實地幫助我們開展測試工作。

比起專業書,團隊文檔和大膽提問纔是我們初入職場的出路。

團隊文檔不僅記錄了歷史的需求測試記錄,幫助我們瞭解產品背景,而且通過善用搜索功能,我們也能很快地理解陌生的名詞和概念,提高溝通效率。其中,產研測團隊有一些自命名的微服務和小工具,若不是通過團隊搜索,或直接詢問,我們可能需要花費大量不必要的精力去了解。所以一定要主動些,多問多溝通,才能更快的融入團體開展工作。

現在回頭看,還是很想念“新人期”的。每天你不找 mentor,mentor也會找你問問“今天有啥問題嗎”,再簡單的問題也會耐心地爲你解答。此外,新人月報、部門1v1溝通都是很好的機會,藉着“初生牛犢”的身份,有任何疑惑和建議都可以直接和 leader 溝通。雖然那段時光有困難有挑戰,但正是因爲那段時間的點滴積累讓我逐步走上大數據測試領域的職業道路。

2.進階之路:打怪升級要一步步來

2.1 第一步:提交大數據計算任務

相較於傳統軟件測試,大數據測試的核心在於驗證數據分析處理的準確性和可靠性,確保大數據系統能夠高效、穩定地處理海量數據。大數據測試存在一定的門檻,要求我們不僅要具備基本的軟件測試技能,還需熟悉大數據平臺的使用。所以,邁出的第一步不妨是在大數據平臺上提交一個計算任務

說來簡單,其實準備工作有很多:

1. 通過大數據平臺考試:考試提供了一定的培訓課程能夠作爲平臺入門指引,能夠很好地幫助我們對大數據平臺有一個整體的初步認識
2. 申請權限:包括數據權限,以及對數據進行操作的賬號權限
3. 新建一個大數據任務:權限申請通過後,可使用賬號進行讀數據的操作,這就是一個簡單的大數據任務

至此,從用戶視角已成功提交了一個任務,而對於大數據平臺和作爲測試人員對你來說要做的工作還有許多。

2.2 第二步:點亮大數據產品地圖

從提交一個大數據任務的過程中不難看出,大數據平臺提供的服務衆多,不僅包括直接面向用戶的數據權限管理、賬號管理、流程中心等,還有任務提交後任務計算有關的計算引擎、調度引擎、存儲等。

前期跟進需求時,總是會有層出不窮的問題。

“任務找不到計算環境?”
“讀表怎麼沒權限?”
“表的元數據在哪裏看?”
......

測試主體服務只有一個,但涉及到的相關服務有許多,需要了解的背景知識最初可能都不知道去哪裏查、怎麼查。大數據存算引擎的需求來源往往是研發,類型往往是技術改造,雖然改造的僅是數據處理長鏈路中的某一環節,但測試場景的梳理離不開對全鏈路的熟悉。若連大數據平臺的基礎服務及其功能特性都不清楚的話,是無法完成質量保障工作的。

除了日常需求中的積累,我們也需主動去探索大數據平臺。作爲一名大數據測試開發工程師,探索和點亮自己的大數據產品地圖是我們的必修課。大數據平臺的產品離不開數據和對數據處理的任務,不如從這兩點出發思考這個問題。



 

 

熟悉大數據平臺的各服務是作爲大數據測試的基本要求,藉此我們能夠更好地幫助產研團隊進行風險評估。此外,大數據平臺本身面向用戶提供大一系列的數據管理工具也能成爲我們工作的助力。例如元數據查詢,比之自己寫腳本去看錶的相關信息,直接在平臺上就能便捷查詢到表的結構、訪問、存儲等詳細信息。

2.3 第三步:走進大促備戰工作

大促活動通常會引發流量的顯著增長和數據處理需求的激增。爲保障大促活動期間服務的穩定運行,大數據平臺會有一些關鍵的備戰措施,例如壓測、應急演練、應急預案等。

我剛入職第一次經歷雙十一備戰時,當時主負責的是一個新的大數據服務,所以其大促備戰方案許多是從零開始的挑戰。由於缺乏經驗,我也體驗了第一次在京東的跨夜加班。

核心時段不能壓

現有的壓力測試工具雖然能夠支持接口級別的壓力測試,但如何安排壓測時間、確定壓測時長和流量大小、以及壓測數據的來源等問題仍然存在。由於缺乏經驗前期準備時間較長,最終一直到封板日當天纔開始實操。且準備開始操作的我並不知道核心時段的問題,還是經研發同學提醒當前時段有風險才及時停止了動作。壓測環境通常無法完全獨立於線上環境,更何況我們是一次操作新服務的壓測,因此必須避免在覈心時段進行壓測。

讀接口也會產生髒數據

在梳理壓測接口時,我們區分讀接口和寫接口的目的是爲了更好地理解和控制壓測過程中可能產生的數據一致性問題。但這也會對我們產生一定的誤導:由於壓測接口被標識爲讀接口,且壓測數據是獨立構造的,我們沒有考慮到該接口可能包含審計相關的寫操作。直到壓測快接近結束時,我們接到下游服務的告警電話,通知我們的壓測對他們的服務產生了影響,這才意識到該讀接口也會產生髒數據。

應急預案不能只有預案沒有動作

應急預案是對線上問題的一種應急手段,其操作存在一定的風險。我記得在預案評審階段,由於涉及高危操作,我們原本打算在預發環境中申請資源進行演練操作。然而,ldr 提出了一個關鍵的問題:如果在備戰期間都不進行實際操作,大促期間真遇到問題了怎麼辦?他強調,只有儘早發現並解決問題,才能確保線上服務的穩定。

至今,我已經參與了三次大促的備戰工作,明顯感受到了大促備戰方案和執行流程的日益成熟。即便在這樣的背景下,我們仍然需要嚴格遵循備戰方案,確保關鍵操作步驟與產品研發團隊協調一致,並且提前公告相關信息,以保證上下游服務和平臺用戶能夠預判風險。

此外,基於公司現有的平臺,大促備戰正逐步轉變爲常態化工作,備戰任務已經逐漸機制化和自動化,形成了可靠的解決方案。這一系列的線上服務保障措施,不僅能夠爲大促提供堅實的支持,還能夠對每次服務上線進行風險評估,確保問題能夠被及時發現並更早解決。

3.能力回顧:給新手的幾點建議

對大數據測試有興趣的同學,以下四點是值得關注的準備方向:

1. 掌握大數據基礎:熟悉如Hadoop、Spark等大數據處理框架的核心概念及其在實際場景中的應用
2. 編程與腳本技能:精通至少一種編程語言(例如Java或Python),並熟練運用基本的Shell命令
3. 測試專業能力:具備紮實的軟件測試基礎知識,瞭解基本的質量保障手段
4. 學習與解決問題的能力:擁有快速學習新技術的能力,並能以問題解決爲導向,高效分析並簡化複雜問題

ps. 這幾點非常像招聘要求,所以大家也可以多多關注有興趣的崗位的招聘信息,從崗位需求出發培養自己的專業能力~

4.未來在握:風起雲湧的技術浪潮

在不斷湧現的各種新興應用中,應用層的測試工具和質量保障方法正在經歷一個成熟和進步的過程。隨着衆多應用的實踐檢驗,一個新 APP 和 Web 應用在上市前所需的基準測試,以及上線、監控和應急自愈等手段已經變得日益標準化和系統化。然而,與應用層的測試相比,大數據相關產品的測試則更加依賴於個人的專業能力,並且通常需要更高的專業門檻。因此,大數據測試的覆蓋率往往低於應用層的測試。這就爲我們提供了許多潛在的探索機會。

1. 功能測試 -> 質量保障:測試工作已逐漸從功能測試向質量保障的方向轉變。這要求測試工作不僅要關注產品本身,還要涵蓋全平臺的質量和穩定性。沒有接觸這份工作之前,我們可能會用“點點點”來描述測試的工作內容,但在質量保障的大環境下,測試工作還包括效能工具建設、安全合規保障、流程規範制定等多個維度。
2. 技術效能:測試開發工程師的主要職責之一是維護和完善效能工具。對於大數據平臺來說,雖然自動化測試工具至關重要,但數據生成、全程監控等環節目前也仍主要依賴人工操作。如何將這些環節自動化,是我們面臨的一項挑戰。

每年都有像我一樣的 JD star 加入京東,加入數據中臺,也許你能比我多些大數據相關的知識儲備,也許你也像我一樣從零開始,但我相信這裏不會讓你失望。不管是遇到難關,還是想要大展拳腳,都有團隊站在你的身邊爲你助力,都有前輩們高瞻遠矚地爲你指路。我們在京東等你。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章