我是Dzreal，工作三年的測試開發工程師。以下是我在測試工作中不斷總結實踐的，測試工程師需要具備一些軟實力。
先看目錄：
一、情商
二、溝通
三、責任心
四、流程控制
五、風險意識
這個話題，我相信80%的工程師都不會特別重視，因爲這個東西說起來很虛，技術上有那麼多東西要學，哪有時間提升什麼軟實力啊！
真香警告：你到底硬不硬，不是你的硬實力決定的，而是你的軟實力決定的。
假如你的技術能力很紮實，你到35歲乃至65歲之後都還有能力寫代碼；但是你的軟實力不行的話，可能你到30歲之後，你就很難在這個行業進步了，你周邊剛畢業的同事都在跟你做同樣的工作，你又拿什麼跟他們拼？你頭髮還剩多少？
在這裏，我分享幾個我親身經歷的小事，藉此跟大家聊聊這個話題，大家也就當聽聽故事。行文不易，假如對大家有幫助、有共鳴的，歡迎 收藏/點贊/在看/分享。
一、情商
要聽話，千萬不要自大！
曾經因爲自大，我給自己和團隊挖了一個天坑！
記得就在畢業第二年的秋天，因爲自己會寫一些ui自動化的腳本，被劃分到部門的自動化效能團隊一起做一些測試工具。
在此之前，做過一些app的測試，覺得app的埋點測試，手工測試的話，耗費很多精力，但是因爲埋點這塊又一直出問題，就想做一個工具來“造福”業務測試的同事。
當時帶我一起做這個項目的領導是剛入職的，對這塊也不是很瞭解，也是硬着頭皮跟我一起做這個工具了。
方案很快就定好了，採用app抓包的形式，將埋點數據進行攔截，轉發埋點數據到測試平臺，測試平臺做埋點規則校驗，再把結果報告展示到測試平臺web頁面上。
當時抓包工具是用anyproxy做二次開發，我在項目中主要負責前端採集埋點數據並轉發http請求。後端是我的領導開發。
一開始，領導就囑咐我說，前端的工具，做成命令行就行，越簡單越好，做成可配置、可移植的，以後有可能的話，做成平臺化的工具。
我當時真的很自大，真的要膨脹到爆炸了。沒有明白設計爲先的原則，也懶得去體會領導的用意，就自己開發自己的。
我心裏只考慮到，團隊的測試同學多是外包同學，給他們用命令行，多難用！考慮到易用性，當然做一個客戶端界面（pyqt5），點點點就更方便啦！
我幾乎通宵做了兩個晚上，有一天代碼提交出了問題，又修改到了後半夜，那時候真的是感覺很“充實”，做出來成果之後，還發朋友圈自嗨！
結果，到演示的時候，可謂瞬間爆炸啊……
因爲客戶端做的太臃腫了，中間出了不少交互的bug，簡單的功能被我做得那麼複雜，而且距離交付的時間也越來越近，領導瞬間都氣炸了，會上直接就發飆了。
會後，我又得按領導的要求把功能砍到最精簡的樣子，當時感覺既挫敗又委屈。
後來，工具還是交付並且推廣了，但由於安裝運行環境很麻煩，很多同事都不愛用，非但不能幫助業務測試的同學，還給他們造成麻煩，最後工具就沒有推廣起來。
真的後悔自己因爲自大，浪費了自己和大家那麼多時間。
二、溝通
能羣聊就不要單聊，能文字就不要語音！
剛開始進入互聯網公司不久，我就接手了一個特別烏龍的需求。
這個項目，從活動運營，到開發，到測試，都是剛入職不久的新人。
一開始這個只是運營領導一句話的需求，沒有產品經理跟進，沒有經過需求評審，單純就是口頭溝通，就搞起來了。
我當時還是很負責任的，找當事運營也確認了很多遍需求，但是完全都沒有意識到這樣的溝通很低效。
沒有溝通羣，全靠口口相傳；需求改了很多遍，但是需求文檔一直是兩行字的需求，全靠猜。
最後我們終於品嚐到了因爲溝通問題滋生的惡果！
由於我對需求的理解存在偏差，我給開發提了一個錯誤的“bug”，這個“bug”改完之後，直接使功能的實現背道而馳！甚至影響到了用戶流量！
在提這個bug之前，我也找運營同學確認過bug的有效性，當時明明都確認這個“bug”是有效的。
但是出現線上問題之後，我卻成了衆矢之的，運營同事當場就“不承認”這個bug是找她確認過的，大家都一致認爲這個bug就是我自己給自己“加戲”！
我真的感覺跳到黃河都洗不清了，我甚至拿不出任何證據給自己洗白，比竇娥還冤！
測試背鍋真的很正常，但是我卻因爲溝通問題，背了我不該背的鍋！
從那時起，只要是未經過需求評審的一句話需求以及沒有詳細文字版prd的需求，我都不接；只要是需要我測試的需求，我都會主動拉羣，有事都在羣裏溝通，不再單聊。
後來，再也沒有出現過這類的問題。
三、責任心
責任心是測試工程師的底線！
我在找工作面試過程中，有一個問題被問到過很多次：“你印象最深刻的bug是哪一個？”
細細想來，我碰到過的bug，絕大部分都是顯而易見的bug。
我還經常抱怨：“開發的代碼怎麼寫得這麼爛，連主功能都沒走通！能寫出這些bug，都不是技術問題了，真的就是態度問題！”。
但就是這麼簡單的bug，在我們的團隊裏，還是會時不時流露到線上！線上的問題，你能怪開發麼？這就是測試工程師責任心的問題！
試想假如你負責的項目，線上出現這麼“沙包”的主流程都過不了的問題，你再怎麼辯解“測試環境中明明是好的啊”，都顯得好蒼白無力啊！最尷尬的是，線上出問題之後，你再在測試環境中嘗試復現，竟然還穩定復現～
嗨！兄弟，這就是漏測！
相信開發兄弟的水平就是對自己作爲測試工程師的責任心的侮辱！
自己寫過測試用例，一定要經得起用例評審；自己寫的測試用例，再怎麼噁心都要一條一條執行完畢！不要拿環境問題和測試時間緊迫當自己漏測的藉口！
你一年幹得再出色，出現一兩個線上bug之後，所有出彩的地方都會被掩蓋，責任心就是測試工程師的底線！我們要時刻堅守住自己的底線。
四、流程控制
要敢於對不合理的流程說不！
以前手工測試app埋點時，有一個不合理的流程是：測試完埋點之後，還要手寫一份測試報告，把抓包的數據填充到測試報告中，然後再寫一份郵件，抄送給BI部門。
維護這個測試報告的成本十分高，起碼佔用了50%的測試時間，完了這個測試報告發給BI部門，但根本沒人會看！
這個測試報告的作用，可能就僅僅是測試人員完成埋點測試的“打卡”操作，並不能給埋點質量的提升帶來任何幫助！
我當時按這個流程測了2個版本之後，再也忍受不住這種噁心的流程。
我當即找到了BI的負責人，溝通取消這個流程，因爲這個流程對於測試人員來說就是一種羈絆，我們只專注於寫這個測試報告，卻忽略了測試埋點的意義，總感覺時間不夠用，但是埋點測試的質量又得不到提高。
後來，經過妥善溝通，我們取消了這個測試報告，我們終於可以不用再忍受這個噁心的流程！
從此，埋點的測試不再只是爲了完成任務而完成任務，我們可以花費更多時間去驗證埋點的數據格式和埋點策略，埋點測試的質量和效率得到很大的提升。
五、風險意識
問題越早發現，風險越小！發現bug，一定要提交bug單留存並追蹤到底！
之前有一個項目需要和別的團隊進行合作，我在測試環境中發現了一個非本版本功能改動的bug，當時憑藉經驗，以爲是合作團隊的改動引發的問題，並且當時我自己的測試需求還忙得不可開交，就當了回甩手掌櫃，把問題丟給合作團隊的測試同事去跟進了，然後我就不管了，也沒有提bug單。
沒想到那個測試同事當時休假了，事情一直得不到妥善解決。
憑藉經驗，我也僅僅以爲是環境或者賬號的問題，也並沒有重視這個問題。
等這個同事回來的時候，時間已經接近發版了，這時才發現這個問題根本不是他們的問題，而是我們連接他們服務的時候，這個版本的傳參有問題，但是由於我並不知曉這個改動。
我發現這個問題，一沒告知我們的開發，二沒提交bug單，除了我和合作部門的測試之外，其他人對這個bug都不知情......導致這個bug差點就流露到線上去。
現在想想都還後怕！
任何bug，不管多小，都要bug單留存，並且要追蹤到底！
▼▼▼
分享的幾個我測試生涯中的案例，也是想強調軟實力（情商 + 溝通 + 責任心 + 流程控制 + 風險意識）的重要性，其實還有諸如管理能力、演說能力也都包含在軟實力裏面，具備這些軟實力能讓你在職場走得更遠！
延伸閱讀：寫給工程師的十條精進原則
https://tech.meituan.com/2018/08/16/10-principles-for-engineers.html
長按識別下方二維碼關注公衆號
關注我的微信公衆號【測試開發Guide】，
回覆「java」：即可獲得java經典學習資料（我花200元買的），帶你輕鬆入門java編程。
回覆「python」：免費獲取「python入門」高分好書，業餘時間偷偷變牛逼。
回覆「面試」：24個常見的測試面試題，你一定不想錯過。