測試工程師之路的開始

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

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

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

描述問題的能力

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

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

基礎(chǔ)代碼能力

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

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

樂觀的心態(tài)

測試工程師每天面對的是程序中的“錯(cuò)誤”，而程序員每天都在創(chuàng)造代碼。起碼我作為一個(gè)垃圾代碼的創(chuàng)造者，是很討厭去排錯(cuò)的。因此就我而言，測試時(shí)你很難保證心態(tài)的平和，因?yàn)槟悴恢朗裁磿r(shí)候會(huì)出一個(gè)莫名奇妙的錯(cuò)誤。

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

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