測試工程師之路的開始

我對技術(shù)人員的定義的一個核心觀點是：他的工作是否能夠被非技術(shù)人員替代。比如說，一個不懂技術(shù)但是能說會道的產(chǎn)品經(jīng)理（又黑產(chǎn)品）能否讓一個經(jīng)驗老道的銷售或者運營替代？測試時只會點點畫面看看結(jié)果是否正確的測試人員能否拉一個知曉這塊需求的運營來兼任？問題的關(guān)鍵就在這里，你的職位叫做“測試工程師”，那你就必須有勝任“工程師”這個稱號的能力。

就我有限的觀察而言，我所見到的、聽說的創(chuàng)業(yè)公司的測試人員無非就是寫寫測試用例、點點畫面、看看結(jié)果，能力稍強(qiáng)的會用一下Postman做一下模擬請求、抓個包看一下應(yīng)用的接口返回結(jié)果，但是也就止步于此了，況且抓包和模擬請求只是對工具的應(yīng)用而已，還遠(yuǎn)遠(yuǎn)談不上會一門手藝。話說回來，在培訓(xùn)班大行其道的今天，你都不能指望你們團(tuán)隊的Android開發(fā)人員會抓包。

因此，對于一個測試人員來說，學(xué)會使用工具是成為一個“工程師”的開始，你可能還不知道GET請求有長度限制、不知道簽名驗證是怎么回事，但是不重要，起碼你知道怎樣才是測試的正確姿勢了，而不是一昧的點擊應(yīng)用上的按鈕。

描述問題的能力

大部分學(xué)習(xí)理工科并且工作內(nèi)容也與理工科相關(guān)的人都有一個特點：說話辦事都喜歡遵循一定的邏輯，譬如我們目前談?wù)摰倪@件事發(fā)生問題的場景是怎樣的，前置條件是什么，后置操作會產(chǎn)生怎樣的副作用。這樣的溝通模式下，問題可以得到很快的定位，解決方案的大致雛形也會在溝通中慢慢形成。

對于測試工程師來說也是，程序是人寫的難免會出Bug，但是也是因為是某個程序員寫的，他對于內(nèi)在的邏輯、可能發(fā)生問題的地方會有一個大致的判斷。測試工程師的工作就是，告訴他發(fā)生問題數(shù)據(jù)的ID、發(fā)生問題的場景、當(dāng)時的測試數(shù)據(jù)是怎樣的等等。而不是，把一個截圖甩給程序員，說：“這地方出錯了啊。”

基礎(chǔ)代碼能力

如何增強(qiáng)對邏輯思維的鍛煉？寫代碼啊，又學(xué)一門手藝又得到了大腦的鍛煉，豈不是美滋滋？

貌似很多測試工程師都喜歡去學(xué)Python這門語言，確實這是一門對于代碼入門者非常友好的語言，但是包括那位測試小哥在內(nèi)都有一個困惑：學(xué)了Python能干嘛？我的建議是從寫爬蟲開始，學(xué)習(xí)爬蟲的編寫可以接觸到網(wǎng)絡(luò)請求的基本知識、可以學(xué)習(xí)到正則表達(dá)式，需要爬取大量數(shù)據(jù)時還可以順便學(xué)習(xí)一下數(shù)據(jù)庫的使用，當(dāng)然了對于爬蟲來說學(xué)習(xí)一下非關(guān)系型數(shù)據(jù)庫就可以了。這一方面是為自己學(xué)習(xí)自動化測試鋪路，一方面也可以為以后轉(zhuǎn)崗提供換一個后路：不做測試了我干脆去寫代碼好了。

樂觀的心態(tài)

測試工程師每天面對的是程序中的“錯誤”，而程序員每天都在創(chuàng)造代碼。起碼我作為一個垃圾代碼的創(chuàng)造者，是很討厭去排錯的。因此就我而言，測試時你很難保證心態(tài)的平和，因為你不知道什么時候會出一個莫名奇妙的錯誤。

假設(shè)這么一個場景，你測試出了一個bug，但是程序員自測之后發(fā)現(xiàn)無法復(fù)現(xiàn)，你的第一反應(yīng)不應(yīng)該是脫口而出：“不可能！”而應(yīng)該是比對兩個人的測試用例，發(fā)現(xiàn)可能存在的問題。

就說這么多，祝各位在警察部一帆風(fēng)順，干杯各位長官！