一個測試開發的十年心路歷程 - 從改變自己做起
從事測試開發十多年,期間經歷不少角色轉換,以下是他在測開成長升級、質量體系建設、專項建設方面的總結,以及職場上的一些思考。
引言
不知不知覺,已經從事測試開發這個行當 10 來年了,從上大學到參加工作,從南方到北方再回南方,輾轉了大半個中國,如今算算進公司已經開啟了第五個年頭,今年就要五年陳了。兜兜轉轉這十多年間,雖然一直都在質量領域,但其實也經歷過不少的角色轉換,這幾年學習了很多,也收穫了很多,希望藉此機會跟大家分享自己這些年在質量域和職場上自己的一點思考和總結,寫在現在,也寫給未來的自己,記錄今天的所思所想。
一、測開的成長
我眼中的測試開發
質量的概念最初僅用於產品,在工業時代興起的時候,質量的概念就已經存在,生產線上下來的產品質量決定著公司的良次品率、成本乃至公司的興衰,慢慢的也誕生了國際質量認證體系,而在這之後質量逐漸擴充套件到服務、過程、體系和組織,以及以上幾項的組合。如今網際網路公司的測試開發,最重要的就是透過多手段保障軟體產品的質量和穩定性,保持對質量的高度敏感和追求。作為一個測試開發,傳統意義上的職責主要負責測試用例,測試方法,測試框架的設計,支援測試流程的自動化、持續整合和持續交付,更深一步的職責需要同時具備測試和開發技能,熟悉專案技術架構,根據研發流程中的痛點,能夠開發測試工具和平臺,用技術解決問題,降低門檻,減少人工操作和測試周期,提高測試效率和質量。
測開的成長之路
不得不承認,我們算是趕上了一個好時代,21 世紀網際網路浪潮開啟,隨之而來誕生了非常多職業,我們測開也是其中之一。個人總結一個測開的成長,可分為功能測試->自動化測試->測試開發->專項保障->測試架構這個幾個階段,而測開的工作職責,也從業務測試->質量保障->效能保障->使用者體驗不斷遞進。
在初級功能測試階段,我們需要熟悉測試流程和理論,軟體研發流程和生命週期,資料庫&Linux,測試流程體系,各種測試方法等。進階介面測試階段,需要了解前後端介面測試框架,介面協議和抓包,web 端,移動端的互動體系,灰盒/白盒測試方法等,總而言之,需要全方面瞭解業務和軟體生命週期。業務功能穩定後,我們就要想辦法提高測試效率,而透過編寫可重複執行的測試指令碼和程式來自動執行測試,可減少人工測試周期,提高測試和迴歸效率,實現測試左移和測試右移。當年在北京時,各種 UI 自動化 UIAutomator,APP 自動化 Appium,web 自動化 Selenium,錄製回放自動化 QTP,介面自動化 Robot Framework,Pytest,單元測試 JUnit,TestNG 等,都嘗試在業務中使用過,也有一兩年的時間,主要一大塊工作內容就是用 python,C#,java 等語言透過各種自動化測試框架編寫自動化指令碼,然後在 Jenkins 實現持續整合和持續交付,也為版本回歸大大提高了效率。2019 年進入阿里之後,我們開始測開轉型,測試角色不再侷限於功能和自動化測試,我們需要熟悉程式語言,熟悉自己業務的技術架構,參與開發的技術評審,根據業務測試、資料、流程,運維上的痛點,透過編寫指令碼,開發工具和平臺等方式來提高測試效率、測試廣度、測試深度,用更高的測試覆蓋率來保障專案質量,隨之而來也誕生了各種自動化平臺,持續整合 devops,資料生產平臺等等。掌握了測開技能,下一階段就需要在各個專項上橫向擴充了,在 2020 年後開始接觸各種各樣的專項,比如 APP 專項(啟動效能、安全測試、弱網測試、相容性測試等),效能專項(壓測,效能監控,幀率/卡頓率),穩定性專項(容量規劃,監控預警,1-5-10,預案,限流等),資金專項(三圖一表,資損場景,離線/實時對賬,應急止血),效能專項(測試效能、研發效能)等,而在這些專項上的深耕,有助於真正瞭解整個軟體全生命週期的質量保障,也能讓測開不只停留於質量保障,可以往前一步做的更多。再往後一步的測試架構,個人覺得應該是可以根據不同專案型別,合理規劃測試資源和測試手段,具備敏銳的風險識別和應對能力,透過質量分析和評估,給出一些開發架構和測試策略上的有效建議,同時也能聯動多方整合資源進行有效溝通,還能持續探索,引入新技術或新方法以不斷提升測試效能。
一階:如何搭建一個合格的業務質量保障體系
一個新業務完整 + 健康的質量保障體系建設,應是能串通整個研發生命週期,解決需求交付上各個節點的核心痛點的。就拿之前做用增時搭建的一個質量保障體系舉例,首先最重要的是業務全流程梳理和技術架構分析,這個節點花的時間最多,也最複雜,但一定記得磨刀不誤砍柴工,只有摸清了前中後整條鏈路業務流轉,以及上下游依賴,包括介面資料傳遞情況,才能總結出真正的痛點,比如當時用增需求交付就存在觸點多驗證週期長,跨平臺配置鏈路長,排查問題難,鏈路資料構造難等核心痛點。摸清了全鏈路痛點,接下來就簡單了,對症下藥即可,我們透過資料驅動&基建完善,讓新觸點驗證從 3 天縮短到 0.5 天,策略曝光率提升 20%。同時推動研發模式升級和測試左移,讓自動化發現 Bug 率提升 10%,保障線上 0 故障。另外針對運營全鏈路配置難&排查難的問題,由點到面搭建全鏈路測試工具,可實現每月提效 10+ 人日。從下圖可見,一個符合業務特性的精細化使用者運營質量保障體系就基本建設完成了。
二階:巧用工具解決重複問題
在測試開發的工作過程中,肯定會遇到不少資料上、效率上、問題排查等方面重複性問題,這時候可以運用一些指令碼、工具、平臺來解決。首先可以橫向瞭解集團內同型別業務是否有對應的解決方案,有的話快速複用即可,如果沒有,可以考慮先用低成本的方式開發一個小工具,可高效解決問題即可,如果後續有可複用、可擴充性,再考慮搭建平臺來系統化的解決一類問題。比如我們之前運營策略配置,每天總有同學來問我為什麼他配的策略無法透出,而排查時跨業務系統多、溝通成本高,鏈路異常問題排查耗時長,各域侷限單節點排查,一個個系統往下捋非常耗時。於是我在日常工作之餘花了差不多兩週時間寫了一個全鏈路測試工具,使用者可自由選擇業務鏈路,進行鏈路節點視覺化串聯,支援按域快速排查與定位問題,針對異常節點明確標識 ,同時有可讀性強的異常錯誤原因&解決方案,也能看到介面資料透傳詳情,讓不熟悉上下游鏈路的運營&PD&產技同學也可無門檻進行自查,策略無法透出原因一查便知,排查時間可降低 95%。
當然,針對用工具解決問題的策略,個人覺得不要為了造輪子而造輪子,小而美的工具就挺好,重點還是要能快速解決問題,不管白貓黑貓,能抓到耗子的就是好貓。
更多內容可以學習《測試工程師 Python 工具開發實戰》書籍、《大話效能測試 JMeter 實戰》書籍
三階:從 0 到 1 建設資金安全專項
質量體系搭建完,工具平臺建設完,就不能再只守著自己眼前的一畝三分地了,文章開頭介紹過 APP、效能、穩定性、資金、效能等專項深耕,下面我想從最熟悉的資金專項來介紹下通盤的專項建設之路。彼時還是跨境電商的業務,故障風險嚴峻,財年理論資損和實際資損風險高,但大家都沒防控經驗,線上也是 0 場景 0 布控,無問題發現能力,後續融合風險還高。於是我們向集團各 BU 前輩取經,快速明確了第一要務為快速挖掘全量資損場景,建設資損發現能力,高效推進監控/核對覆蓋率,具備資損快速止血能力,因此在 4 月份開始從上到下正式拉起資金安全專項攻堅戰。在這過程中,我們沉澱了 “三圖一表” 和 “靈魂三問” 的特色化防控方法,結合當時會員電商的業務特性,我們用了一年的時間分三階段建設了一套資損防控體系:人員帶練 + 防控體系建設 + 資料化運營。經過一年的執行,我們帶練出了一批資金專家,同時推進前中後六大業務域挖掘幾百個資損場景,新增布控指令碼上千個,挖掘幾十個潛在故障,財年的實際資損控制在了很小的一個數額,最終斬獲集團的 “攻堅克難獎” 和 “超強特攻隊” 獎項,不可謂不強。
存量風險基本防控完成後,我們就要開始考慮可持續問題,也就是增量風險和人員效率,於是我們結合原先的線下流程,建設了資金安全中心,把流程約束落進系統、把風險精準分析能力沉澱進工具,將看似割裂的經驗和技術能力 “無形” 織入到高頻工作的各環內,整體串成一條 “線” 來改變大家的工作模式,旨在儘可能動用少的人力,卻能覆蓋儘可能多的風險。
往細剖析了一下,在資金安全引擎中,我們實現了變更程式碼的資金風險精準分析,並且把風險識別和卡點到了研發流程中,首先利用系統上資金欄位的沉澱,透過位元組碼分析程式碼拓撲資金入口,到資金方法,再到資金 DB 欄位的鏈路呼叫圖,來掃描識別變更程式碼 diff 中是否改動到該資金鍊路,然後再把這部分結果資料納入風險評估引擎,實現變更資金風險的精準識別,一直到現在,這套流程還執行的非常好。
二、這些年的一些思考
鈍感力 - 論堅持的動力
坦白講,我自認為不是一個聰明人,在學習和工作的過程中,我見過不少我理解意義上的聰明人,他們的學習能力更強,可以短時間內學習和掌握一項技能,而且還輕輕鬆鬆,舉一個最典型的例子就是一起玩同一個遊戲,他們永遠比你上手快,操作好,這也讓我十分佩服。工作中一路走來,我覺得天賦固然重要,但堅持,是一個後天可修煉的難能可貴的品質。很多人會吐槽工作都是 “重複做相同的事”,但正是一開始的 “重複” ,才給了一個新手成長最好的契機。而且重複並不代表一成不變,我們需要在重複中堅持不斷學習,不斷進階,尋求堅持後創新和突破,才能讓自己最終成為這個領域的專家。近一兩年行業變化比較多,大家也都會變的焦慮,但其實對於我們搬磚的同學來說,其實大部分訊息和變化都沒那麼重要,可提前佈局的事也不多,再說臨時抱佛腳也晚了。適當的保持一份鈍感力,不要為沒有發生的事情而焦慮,在 “不確定” 的世界中,不如更專注把當下確定的事情做好,多學一點專業知識和技能,我覺得反而更有用。多看書,多成長,與其焦慮,不如行動,知識和經驗才是真正屬於自己的。 有志者,事竟成,破釜沉舟,百二秦關終屬楚;苦心人,天不負,臥薪嚐膽,三千越甲可吞吳。
體系化的解決問題
在日常工作過程中,肯定會碰到大大小小許多難題和挑戰,比如主管給了一個新方向,或需要推一個新專項,很多時候一開始可能會讓人覺得沒有頭緒,甚至產生自我懷疑:這個挑戰我真的能解決/勝任嗎?問題的常見解決方式有很多,比如通用流行的 5W2H 法,PDCA 迴圈,SMART 原則等。我自己的一套體系化解題思路是,做一件事情或解決一個問題前自己先想清楚解題四象限,所謂解題四象限就是:背景,挑戰,解題思路,結果,其實類似任務分解法(WBS)。首先想清楚問題的背景,也就是核心要解決問題是什麼,審題很重要。其次要明確解決上述問題,目前最大的幾個挑戰是什麼,資源、時間還是方式方法。等理清楚了問題和挑戰,那麼接下來就是解題思路了,是流程機制最佳化,還是工具平臺創新,最好是沙盤推演過的/資料論證過的,且有一點很重要的是一定要讓共同協作的人理解和認可,多一些溝通,大家認可解題步驟才能有真正的驅動力。幾個解題的核心點都拆成任務完成之後,只要沙盤推演/資料論證的沒問題,結果大機率就能達成了。之前負責的資金安全專項,就是用這個解題四象限去推進和解決的,事實證明效果還不錯。
如何從 “借力” 到 “合力”
很多工作單憑一個人之力,是無法推進下去的,特別是跨團隊協作和橫向事項,那麼勢必就需要 “借力”,而如何 “借力” 也是一個有很深學問的命題。
個人覺得有幾個點可以參考:首先,要跟自己的產品、開發、運營同學們建立良好的革命友誼,平時有需要幫忙的地方積極伸手,站在對方的角度思考和解決問題,這樣將來有你需要 “借力” 的時候相信他們也會很願意幫忙。其次,把事情從 “借力” 變為 “合力” ,要想清楚這個 “借力” 能為對方帶來什麼價值,能幫他解決什麼問題,做方案時換位思考,幫對方也多想一步,也許就能快速達成一致形成 “合力”。最後,至上而下推進事情,大家認可共同價值,以合作模式推進,如果是一些關鍵事項,可以進合作雙方的 OKR,這樣就能形成真正的 “合力” 。
機會,努力與自我價值
這些年來,遇到過很多的挑戰,也碰到過很多機會。有位職場前輩曾經跟我說過一句話,讓我記憶深刻:這輩子,能夠讓你往前跨一大步的機會也許就這麼幾個,可能幾年才會有一個,所以,日常需要多積累,當機會來臨時,付出百分之兩百的努力,牢牢抓住他,不要給自己留遺憾。 我始終相信,機會,是留給有準備的人。還記得幾年前剛做遷移融合,做資金安全專項,寫工具平臺的時候,都覺得挑戰很大,但辦法總比困難多,也許要比別人付出更多的努力,但真正達成目標的時候,還是會有很大的認同感和成就感的,說實話這也將會是你以後跳槽的資本。所以,挑戰也是機會,當一個人有更大的機率能把事情做好,那麼他在贏得信任後通常又會有更大的機會。其實回頭看,你覺得最難的時候,也是你成長最快的時候。 我就是抱著這種信念感一步步往前走,過程中肯定也有失敗,但不要害怕犯錯,犯錯會讓人變的更好,在犯錯後總結經驗再前進,這樣的成功才更有意義,也才能真正的實現自我價值。這幾年來,不管是做資金專項時取得的 “春雷·春雨 行動先鋒獎”,還是財年取得的阿里安全生產 “FY22 紅蘋果” 獎,以及中間水到渠成的晉升成功,作為講師參加 MTSC 2022 第十屆中國網際網路測試開發大會,還有最近 2023 年雙 11 作為大促 PTM 取得的 “捨我其誰獎”,都是對自己抓住機會,努力拼搏後最好的褒獎。
永遠年輕,永遠熱淚盈眶
它山之石,可以攻玉,保持學習的習慣,開放性是我們幹網際網路這行的一個重要特點,所以每天都會有很多新的技術更新迭代,因此我們需要保持一份危機感,如果一直在吃老本,終有被淘汰的那一天。比如十幾年前的手機,前幾年的電動汽車、短影片、直播,以及這兩年大火的 AI,都會或多或少影響我們的行業技術棧和業務方向。前幾天看到一個關於 AI 行業分析的文章,對我觸動蠻大的,ChatGPT 的橫空出世,讓大家都有了危機感,AI 領域上每天這種快速的變化是在以往的科技史上都還沒出現過的,而未來大機率是 AI 的時代,這也可能是接下來增長最快的一個領域,但也是我們代差最大的一個領域,所以這中間就存在巨大的挑戰和機遇,因為 “算力” 未來可能就會像錢一樣變為現金等價物。所以對新鮮事物,保持學習和探索,會讓我們始終都領先別人一步。保持閱讀,保持自律,這是一個很好的習慣,書對人的影響是潛移默化的,家裡有小朋友的建議一定從小培養好閱讀的習慣,會讓人終身受益,這在很多公司主管和名人身上都見過。但說實話我沒有做的很好,我家裡有好幾個書架,但都是我家屬的書,我看過的只有一小部分,所以新一年裡我也給自己定個小目標,先從 6 本開始。
更多內容可以學習《測試工程師 Python 工具開發實戰》書籍、《大話效能測試 JMeter 實戰》書籍
三、寫在最後
在文章的結尾,借用康德的一句話來總結:我始終只求克服自己,不求克服命運;只求改變自己的慾望,不求改變世界秩序。 這也是羅翔老師前幾天來公司講座時贈予大家的一句話,希望我們都從一點一滴改變自己開始,也許你能改變的就不止一點點,謹以此句贈予一路上披荊斬棘且奮勇前行的質量人們,加油!吾心自有光明月,千古團圓永無缺。
相關文章
- 使用Electron開發一個吸色工具的心路歷程
- 一個C#開發編寫Java框架的心路歷程C#Java框架
- 一個C#開發者重溫C++的心路歷程C#C++
- 一個C#開發者用Java搭建Android框架的心路歷程C#JavaAndroid框架
- 功能測試轉向自動化測試 / 開發。10年 心路歷程——願測試人不再迷茫
- 從谷歌面試翻車到offer收割的心路歷程谷歌面試
- 萬字心路歷程:從十年老架構決定重構開始架構
- 分享一下某個debugger心路歷程
- 從開發轉測試:我從零開始,一干就是6年的自動化測試歷程
- 《SELF 自己》開發心路
- 一位 sealer maintainer 的心路歷程AI
- 一個低學歷程式設計師開發逆襲大廠的心路歷程,看完真心給跪了程式設計師
- Kotlin之心路歷程Kotlin
- 十年測試,發現自己一無是處
- 改變自己從學習linux開始Linux
- PHP 開發入門自動化測試歷程(一)PHP
- .net工程師學習vue的心路歷程(一)工程師Vue
- 記一次破解某APP的心路歷程APP
- 新手測試開發的成神之路:面試歷程分享面試
- 個人自學python方法整理以及心路歷程Python
- 《死亡之門》開發者淺談遊戲設計的心路歷程遊戲設計
- 工作三年心路歷程
- 三年 React 開發經驗的我,遷移到 Vue 的心路歷程ReactVue
- PicGo的star數破1000的心路歷程PicGo
- Flutter 找到所需元件心路歷程反思Flutter元件
- Python實訓的心路歷程——第5天Python
- 學習嵌入式的心路歷程分享
- 塗鴉智慧選型 TiKV 的心路歷程
- 我作為前端工程師的心路歷程前端工程師
- 張永林在丰采網的歷練過程與心路歷程GLR
- PHP 開發入門自動化測試歷程(三)PHP
- PHP 開發入門自動化測試歷程(二)PHP
- 一個web前端開發者學習Flutter 的歷程(一)Web前端Flutter
- 歷經2個月從後端轉行到前端的改變後端前端
- Zoho Books十年發展歷程
- 各種ID轉化之心路歷程
- .net工程師學習vue的心路歷程(二)工程師Vue
- .net工程師學習vue的心路歷程(三)工程師Vue