怎樣做一名合格的測試工程師

前言

距離上一次寫博客已經很久了，來瞎扯點東西，談談在我這個菜鳥程序員眼里，測試工程師到底應該做什么？

公司前段時間有過人事變動，一個新來的測試工程師（還未轉正）被公司裁了。因為之前是我在和這位測試合作，因此他找到我希望我和他談談他在工作中有什么問題。

實話實說，這位測試老哥是不配“工程師”這個稱呼的——就像只會畫畫原型圖的人不配被稱為產品經理一樣。我想人家都要離職了，況且都是做技術的，也不妨給了點建議，希望他在以后的職業(yè)生涯中能走得順利點。

測試工程師之路的開始

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

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

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

描述問題的能力

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

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

基礎代碼能力

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

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

樂觀的心態(tài)

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

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