測試工程師到底應該作什麼？

測試工程師到底應該作什麼？

周煦辰 2017-05-21

前言

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

公司前段時間有過人事變更，一個新來的測試工程師（還未轉正）被公司裁了。由於以前是我在和這位測試合做，所以他找到我但願我和他談談他在工做中有什麼問題。

實話實說，這位測試老哥是不配「工程師」這個稱呼的——就像只會畫畫原型圖的人不配被稱爲產品經理同樣。我想人家都要離職了，何況都是作技術的，也不妨給了點建議，但願他在之後的職業生涯中能走得順利點。

測試工程師之路的開始

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

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

所以，對於一個測試人員來講，學會使用工具是成爲一個「工程師」的開始，你可能還不知道GET請求有長度限制、不知道簽名驗證是怎麼回事，可是不重要，起碼你知道怎樣纔是測試的正確姿式了，而不是一昧的點擊應用上的按鈕。

描述問題的能力

大部分學習理工科而且工做內容也與理工科相關的人都有一個特色：說話辦事都喜歡遵循必定的邏輯，譬如咱們目前談論的這件事發生問題的場景是怎樣的，前置條件是什麼，後置操做會產生怎樣的反作用。這樣的溝通模式下，問題能夠獲得很快的定位，解決方案的大體雛形也會在溝通中慢慢造成。

對於測試工程師來講也是，程序是人寫的不免會出Bug，可是也是由於是某個程序員寫的，他對於內在的邏輯、可能發生問題的地方會有一個大體的判斷。測試工程師的工做就是，告訴他發生問題數據的ID、發生問題的場景、當時的測試數據是怎樣的等等。而不是，把一個截圖甩給程序員，說：「這地方出錯了啊。」

基礎代碼能力

如何加強對邏輯思惟的鍛鍊？寫代碼啊，又學一門手藝又獲得了大腦的鍛鍊，豈不是美滋滋？

貌似不少測試工程師都喜歡去學Python這門語言，確實這是一門對於代碼入門者很是友好的語言，可是包括那位測試小哥在內都有一個困惑：學了Python能幹嗎？個人建議是從寫爬蟲開始，學習爬蟲的編寫能夠接觸到網絡請求的基本知識、能夠學習到正則表達式，須要爬取大量數據時還能夠順便學習一下數據庫的使用，固然了對於爬蟲來講學習一下非關係型數據庫就能夠了。這一方面是爲本身學習自動化測試鋪路，一方面也能夠爲之後轉崗提供換一個後路：不作測試了我乾脆去寫代碼好了。

樂觀的心態

測試工程師天天面對的是程序中的「錯誤」，而程序員天天都在創造代碼。起碼我做爲一個垃圾代碼的創造者，是很討厭去排錯的。所以就我而言，測試時你很難保證心態的平和，由於你不知道何時會出一個莫名奇妙的錯誤。

假設這麼一個場景，你測試出了一個bug，可是程序員自測以後發現沒法復現，你的第一反應不該該是脫口而出：「不可能！」而應該是比對兩我的的測試用例，發現可能存在的問題。

就說這麼多，祝各位在警察部一路順風，乾杯各位長官！