前言

距離上一次寫博客已經(jīng)很久了，來瞎扯點(diǎn)東西，談?wù)勗谖疫@個(gè)菜鳥程序員眼里，測(cè)試工程師到底應(yīng)該做什么？

公司前段時(shí)間有過人事變動(dòng)，一個(gè)新來的測(cè)試工程師（還未轉(zhuǎn)正）被公司裁了。因?yàn)橹笆俏以诤瓦@位測(cè)試合作，因此他找到我希望我和他談?wù)勊诠ぷ髦杏惺裁磫栴}。

實(shí)話實(shí)說，這位測(cè)試?yán)细缡遣慌洹肮こ處煛边@個(gè)稱呼的——就像只會(huì)畫畫原型圖的人不配被稱為產(chǎn)品經(jīng)理一樣。我想人家都要離職了，況且都是做技術(shù)的，也不妨給了點(diǎn)建議，希望他在以后的職業(yè)生涯中能走得順利點(diǎn)。

測(cè)試工程師之路的開始

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

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

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

描述問題的能力

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

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

基礎(chǔ)代碼能力

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

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

樂觀的心態(tài)

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

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