硬實力和軟實力,哪個對測試人來說更重要?
說到測試或者測試工程師,人們的第一反應大概是“找碴”、“雞蛋裡找骨頭”、“背鍋俠”…… 加我VX:atstudy-js 回覆“測試”,進入 自動化測試學習交流群~~
其實這是對於測試這行的一個很大的誤解。測試過程對於絕大多數行業來說是非常重要的一環,廚師在烹飪的時候會嘗一嘗菜品的味道,一棟樓在建造之前和竣工之後要進行檢測,軟體在釋出之前也要進行很多輪的測試來驗證軟體的各項效能指標。
作者從事多年測試工作,經歷了對測試一無所知到略知皮毛,也對測試工作有了更深的理解。如何成為一個合格的測試工程師是一個很大的話題,無論從事這行的工程師還是研究測試的專家都在思考怎麼進行更有效的測試,如何提高相關從業者的認知水平。
如果有人問我是不是一個合格的測試工程師?這是一個很難回答的問題。從事多年的測試工作,不可否認會積累一些知識和心得,但因為測試中需要了解的知識很多,我掌握的知識還不足以證明自己是一個合格的測試人員,但還是跟大家分享一下多年來在測試工作中體會到的心得。
硬技能
依稀記得入職第一家公司時,坐在工位上把嶄新的電腦開機輸入密碼後開啟outlook,郵箱裡很快收到好多郵件:第一封是經理發的歡迎新員工郵件,剩下的郵件大部分是部門同事發的測試報告,我一封封的開啟看,裡面寫的字我都認識,合在一起就不認識了,非常多的通訊行業術語。
看著這些郵件,自己新入職的喜悅瞬間消散,心裡想著自己會不會不到試用期結束就被掃地出門。
在這裡,非常感謝當時招我進公司的部門經理,當時的我根本不知道通訊裝置是什麼,更不要說通訊協議。學校學習的專業是物理學,跟通訊幾乎沒有交集。經理居然招收了我這個超級小白,到現在我也不太明白當初經理為什麼會給我offer,他幫助我開啟了通訊行業的大門。
在試用期部門會給新員工安排導師,在導師的幫助下以及公司提供的各種學習文件,很快就可以學著進行測試,測試過程中遇到問題可以查詢相關文件,也可以嚮導師求助,他會幫著我解決。
雖然不太清楚為什麼要按照用例中的測試步驟進行測試,也不太明白為什麼跟預期結果不符就是問題,但是起碼可以進行初步的工作。
當試用期結束,導師和經理經過評估終於接受了我這個“門外漢”之後就開始獨立進行測試了。這時會遇到各種各樣的問題,導師也有自己的工作,遇到問題就去找導師不可能也不現實。
技術深度
從此我就開始了一段記憶非常深刻的新員工之旅——測試過程中,我發現需要掌握的東西會越來越多、越來越複雜。
這時,就需要自己來理清楚輕重緩急。先掌握在工作中用到的最主要技術然後再慢慢擴充套件到人際交往、情緒管理、心理調節等方面。
在技術方面,測試中遇到技術問題時,最好的辦法是在公司的資源庫裡去找,無論是內部網站論壇還是文件庫裡,總會找到類似問題的解決辦法。
有一句話說得好:並不是你一個人遇到這種問題。做測試需要一定的廣度,通俗來講就是什麼都要會一點。
舉個例子,實驗室需要重新搭一套全新的測試環境,從裝置的安裝到除錯全流程需要自己來處理。
首先找到裝置的說明書和安裝除錯手冊,然後按照步驟一點一點進行下去。在這期間會遇到各種各樣的問題:裝置間需要使用交換機來連線,要配置VLAN、路由。為了解決問題,就要問熟悉相關配置的同事。
提示一下,有些配置最好找相關的同事,因為配置不好的話不僅會影響自己負責的裝置,還會涉及連線到同一個交換機上面的裝置。
把硬體安裝好以後還要確認需要安裝的軟體版本、從什麼地方能得到軟體、如何安裝、如果安裝失敗後要採用什麼辦法重新安裝……
當硬體、軟體全部安裝好以後要進行除錯,包括配置各種引數,配置成功後要進行業務的除錯等步驟。基站裝置有非常多的引數,如果一些重要的引數沒有修改正確,業務根本做不起來,更不要說測試用例。
這又是一個很考驗工程師的地方,雖然有引數模板可以參考,但是有些引數是不可能全盤接收。在不斷地嘗試、厚臉皮問有經驗的同事的過程中,瞭解到整個裝置的執行和除錯流程。
以上步驟完成,就可以開始測試用例,基本也是一路問,一路查的節奏。從開始一天只能測一到兩個用例到後來增加到四個五個或者更多……
這就是一個新手要經歷的過程,沒有任何捷徑能走。
技術廣度
大約經過一年左右的時間,我們已經熟悉了測試工作中的流程,面對測試中的問題,逐漸有自己的見解和解決方法,也開始對工作中涉及的一些感興趣的技術進行深入的研究。
當然這個興趣點最好是工作當中會頻繁用到的,畢竟我們需要提升工作業績來展現自己的價值。比如對程式設計感興趣,那不妨繼續學習下去——進行自動化測試的前提是有自動化的指令碼,而寫指令碼的前提是要求工程師有一定的程式設計基礎。
再比如熱衷於通訊協議,那也請堅持學習下去,通訊相關的協議非常多,只要把一種型別的協議精通了,大機率會成為牛人。
在我認識的一些技術大牛中,表面上看他們貌似只對一門技術很精通,其實他們對其他的技術也非常在行。
每一種技術是不可能單獨存在的,在學習中間會遇到其他的技術問題擴充套件開來後會接觸到更廣闊的技術面。新技術也好舊技能也罷,他們之間一般都會有相關聯的知識點,只要抓住核心的邏輯就能觸類旁通。
在測試工作中我們還會接觸到用例設計、用例評審、測試方法等等問題。由於篇幅所限,就不在這裡一一展開了。以上每一個話題都可以作為一個很大的專題來討論,學術界和工業界對它們的研究一直沒有停下,這方面有很多的書籍和文章可以供大家參考。
軟技能
溝通能力
在測試過程中技術層面相對來說比較簡單,只要我們肯下功夫,大部分技術都可以掌握,相對來說一些軟技能則需要更長時間的鍛鍊,比如交流溝通能力。
這個技能在工作中會起到很大的作用。工作中我們需要與不同角色的人交流,包括同事、組長、直屬經理、其他部門同事……
對於同一部門的同事,無論是老員工還是新員工,大家的本職工作都是測試,在工作中互相幫助,八小時之外有可能會成為要好的朋友。
在測試中如果遇到問題,應該馬上跟組長或者直屬領導彙報,畢竟一個小問題有可能會釀成大事故。
這個不是危言聳聽,因為測試工程師、組長、經理看待問題的角度是非常不一樣的:
工程師可能只關心今天測了多少用例,透過多少個失敗幾個;
組長看到的是他負責的某一項大功能是不是有問題;
而再高一級的經理或者更高職位的主管,他們看到的是整個專案狀態的變化情況。
所以遇到問題需要及時的溝通,也許你只是看到大樓少了一塊磚,其他人卻看到整棟樓都歪了。在測試中發現問題後,第一時間要找的人大機率是對應模組的編碼同事,需要找這位同事確認是不是問題。
在找對應的編碼同事前,第一步要確保測試步驟是正確的。要證明別人的不合理,首先確保自己的操作是合理、遵循規範的。
第二步是測試期間一定要儲存log。詳細的log有利於分析和定位問題,如果是一個可復現的問題,log可以重複抓。但是對於一些偶發性的問題,這一次沒有抓到log,沒有人會預測到這個問題什麼時候才會出現,這會引發版本的隱性風險。
確保這兩步做完,我們就可以找編碼同事確認問題,也許交流過程會很輕鬆,也許會出現爭執,這個時候要儘量保持冷靜。我們要明確的一點是:測試和編碼的目的都是為了專案。
我們在與對應的開發同事交流時,雙方交流的焦點最好是集中在問題上而不是一些情緒上面,起碼有一方是在關注專案,這樣會減少很多交流上面的內耗從而集中精力來解決問題。
心理狀態
心理狀態也是測試工程師必須瞭解的一個方面。工作中難免會遇到各種各樣的問題,比如問題無法復現、與同事的爭執、加班太多……種種的問題都會擾亂我們的心緒,情緒越急躁,越沒有辦法穩妥的處理事情。
以我自己為例,測試工程師的前幾年我非常熱衷於找bug,原因是我覺得如果找不到bug,是一件非常丟臉的事情,以至於自己提了很多bug,但是有效bug的數量其實並沒有顯著的提高,自己陷入了認為測試的價值在於不停的提bug的怪圈。
漸漸我發現以上的做法會使自己和其他同事忙於應付源源不斷的bug。當我把心態轉變為注重質量——即一個高質量的bug,比提十個無效bug要有用,自己的心態會很輕鬆,而且也節省了公司的資源,大家可以把有效的工作時間聚集到真正的問題上來。
在工作中也會另外一種情況:bug被提交後編碼的同事會一次又一次的要求複測,原因可能是log抓得不全、懷疑測試環境有問題、還有覺得測試步驟不對……
聽到這些質疑,測試工程師肯定會覺得這是對自己的不尊重,潛意識裡的想法是:我們是專業的人員,怎麼可能會犯這些低階的錯誤?
換位思考一下,大多數情況下編碼同事也是為了確保這個bug是真正的問題,我們彼此不用為了一個無效的bug來做更多的無用功。
如果我們測試方面多做一些,會為其他同事節省多一些時間,幫助他人也是在幫助我們自己。都站在自己的角度處理問題的話,問題會變得越來越複雜,然後事物性的問題慢慢會變成情緒性的衝突。
很常見到的一個現象就是:一個小問題在郵件當中進行討論,帶入情緒以後郵件列表中漸漸加入彼此的組長、經理,甚至更高層級的領導。
當我現在回想起來類似的事情,不禁會笑,也會反思,若當初大家都保持著就事論事的態度,問題會很快得到解決。
在我們做過的很多專案中,最大的困難並不是技術層面,而是在交流溝通以及專案相關方之間的利益衝突上。如果後者出現問題,且沒有處理好的話,再小的問題都會導致專案延期或者失敗,給個人甚至公司帶來損失。
以上寫了這麼多,相信大家對如何成為一個合格的測試工程師需要具備的條件已經有了大致的瞭解:掌握技術的廣度和深度、成熟的心智、熟練的交流能力,還有對專案的理解程度。
我曾經的一位經理說過這樣一句話:“看一個人適不適合這個工作,先要了解他的非技術能力。技術很好學的,普通人很快就會掌握一門技術,但是非技術能力才是更重要的方面。”
現在的我更能理解這句話的含義:技術是硬技能,只要我們肯下功夫,在市場上見到的測試技術、工具或者程式語言都可以很快掌握,無論是通訊測試、網際網路測試,其中的邏輯都是相通的。把一件事情做到極致,與其相關聯的其他方面也不會差到哪裡。
但是像溝通、心理調節這樣的軟技能則是需要不斷提醒自己才會有一些改變。所謂江山易改本性難移,如果每次都做出一些小小的改變,那麼會對自己的職業發展帶來很大的提升。
最後:
可以到我的個人V:atstudy-js,可以免費領取一份10G軟體測試工程師面試寶典文件資料。以及相對應的影片學習教程免費分享!其中包括了有基礎知識、Linux必備、Mysql資料庫、抓包工具、介面測試工具、測試進階-Python程式設計、Web自動化測試、APP自動化測試、介面自動化測試、測試高階持續整合、測試架構開發測試框架、效能測試等。
這些測試資料,對於做【軟體測試】的朋友來說應該是最全面最完整的備戰倉庫,這個倉庫也陪伴我走過了最艱難的路程,希望也能幫助到你!
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31407649/viewspace-2909266/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- java 對測試來說真的不重要嗎Java
- 開發者漲薪指南:提升軟、硬實力
- 架構師所需的硬實力與軟技能架構
- 如何快速提升自己硬實力
- 介面壓測實踐-壓力測試常見引數解釋說明
- 軟體壓力測試流程和測試工具分享,讓你寫壓力測試報告再也不愁測試報告
- 如何構建測試團隊的軟實力 - 高學文
- 軟體壓力測試怎麼做?出具壓力測試報告軟體測評中心測試報告
- 軟體測試與開發崗位對比,哪個更適合你?
- APP壓力測試6--monkeyrunner實踐APP
- 超實用壓力測試工具-ab工具
- jmeter壓力測試實現負載均衡JMeter負載
- 軟體壓力測試知識分享,2022好用壓力測試工具有哪些?
- 新國潮榮威遇上百年故宮:把文化軟實力變成發展的硬實力
- 讓測試事半功倍軟體壓力測試工具分享,壓力測試報告怎麼收費?測試報告
- 平板和膝上型電腦哪個更實用 平板和膝上型電腦哪個更實用
- 壓力測試
- 實用測試技能分享:APP壓力穩定性測試之Monkey入門實戰APP
- 有自驅力的測試開發實習生
- 實現Python壓力測試工具|Python 主題月Python
- 壓力測試redis redis-benchmark 優化實踐Redis優化
- 軟體產品為什麼要做壓力測試?壓力測試報告如何獲取?測試報告
- laravel壓力測試Laravel
- sysbench 壓力測試
- ORACLE壓力測試Oracle
- MACOSXApacheab壓力測試MacApache
- 軟體測試培訓分享:軟體測試和軟體開發學哪個好呢
- 力學示意圖繪製軟體哪個好,怎麼畫力學示意圖
- 如何對 ElasticSearch 叢集進行壓力測試Elasticsearch
- 【SWINGBENCH】使用SwingBench對Oracle進行壓力測試Oracle
- 軟體壓力測試有哪些測試流程?軟體測試報告收費情況測試報告
- 顯示卡鎖算力和不鎖算力的區別 顯示卡鎖算力和不鎖算力的哪個好
- 軟解析、硬解析的一個小測試
- 如何聊才能突出自己軟實力,打動面試官面試
- 可靠資料的驅動力:使用實際輸入來測試微應變慣性感測器
- 中美科技實力對比:全球視角
- .net和java串列埠通訊壓力測試對比, java完勝Java串列埠
- 針對 “測試用例最佳實踐” 的說明