讓開發改bug全靠催？分享6個實用技巧

 

測試小夥伴們，你們有遇到下圖的情況嗎？

這張圖其實還算“溫柔”的，其實有些情況下，某些測試人員或者開發人員脾氣大的可能撕逼或者快乾架。所以如何和開發有效溝通，並高效勸說開發改掉bug是一門學問，以下是我總結八年測試經驗給測試新人的一些建議：

1、和開發人員保持友好的團隊關係。這是最重要的一點！

我以前遇到一個開發，剛開始給他提bug時，他是各種牴觸情緒加敷衍。後來我就私底下和他多接觸，瞭解他的脾氣，久而久之他也和我熟絡起來，結果不僅不再有牴觸情緒，甚至還幫我主動定位bug。其實人心都是肉長的，我們做事既要講理，也要適當打打“感情牌”。注意跟開發溝通的語氣，要有換位思考的意識，做事情對事不對人，對待開發要確保在解決bug的前提下儘量不傷和氣。也只有這樣，才能夠很好的說服開發去修改Bug。當然有時候我們也會遇到強勢的開發，油鹽不進的那種，對我們的測試工作帶來層層阻力，我也親身經歷過，但是這種開發畢竟是少數，如果真遇到了那就具體問題具體分析吧！

2、要確定這是一個真正的bug

不要出現因為配置原因或者是操作錯誤引起的“bug”，這樣是會被開發“鄙視”的。最搞笑的是自己測錯了版本，然後測出了老版本的問題，那就尷尬了。或者自己電腦網路問題，結果以為是伺服器響應問題，這樣的失誤多了肯定降低自己在開發心中的地位。作為一名測試人員，我們應該樹立在開發心中專業的形象。這樣說話才有分量。遇到問題先別頭腦一發熱就去找開發詢問，哪怕有些自己不確定了也儘可能自己想辦法確認問題，確定是bug了再去找開發。一定要記住，我們可是專業的“蟲師”?！

3、儘可能寫好bug描述，方便他人就是方便自己

以前我工作中遇到過一個現象，就是同組的女測試每次提的bug都能比我解決的快，我當時很納悶，就去詢問開發人員，這是性別歧視還是憐香惜玉呢？結果開發只回了一句：“她解釋的更清楚，你的需要反覆核對才能確定！”從那以後我痛定思痛，在缺陷管理工具中會將bug的詳情描述的特別清晰。而且我們們測試描述地越清晰，越具體，開發才會更加佩服你的“專業”。

Bug的描述儘量詳細且淺顯易懂，確保沒有歧義，復現的步驟一定要條理清晰，你的預期結果和現有的結果，截圖也要儘量標註資訊且清晰。如果是特殊的測試資料，我們還需要附帶這些資料。

對於復現率很低的問題，需要註明復現率，詳細記錄當時的測試環境資訊。如作業系統、產品名稱、版本、操作步驟、是否機器相關、是否產品相關等。

4、提升自己的專業技能

我剛入行時遇到一次特別囧的經歷，有一次給團隊的開發提Bug,結果新來的女前端跑來質問我，一個後臺問題怎麼提給了她前端。當時我才明白，我們測試打鐵必須自身硬，必須具備對bug的基本定位能力，就比如剛說的Bug，如果我當時會F12看下報的是502問題，肯定就不會提交到前端開發人員那去了。

其實我們測試人員，首先是對業務分析的能力。要充分熟悉我們軟體產品各個層面的業務，包括功能業務，程式碼實現邏輯，環境配置部署等。特別是做功能測試時，我們必須對所測模組的需求很熟悉，要比開發人員更熟悉。或者說一名專業的測試人員，可能比客戶和PM更懂這塊的規範。其次我們必須具備市面上常見的軟體測試技巧，掌握主流的測試工具。比如為了更高效測試而採取的自動化測試！說到這，你應該很自然地想到也應該具備基本的程式碼閱讀能力吧，要想成為一名優秀的測試工程師，我們應該知己知彼，知道開發是怎麼個程式碼邏輯實現需求，從而能夠更精準的定位深層次的問題。

5、測試應把握重點，切勿鬍子眉毛一把抓

這點當然也是測試界特別需要注意的一點，那就是在有限的測試時間內我們應該有舍有得。我曾經在這塊有過一次爭的面紅耳赤的經歷，之前我們做過一個交通方面的OA系統，我當時為了全面保障專案質量，在產品需求之外進行了一次效能測試，結果Jmeter測出來併發100使用者時系統就崩了，要知道我之前測的再小的OA系統也能承受500以上的併發。所以我當即就找PM和主要開發人員反應該問題，本來以為他們在驚訝之餘會立馬解決該效能問題，結果得到的答覆卻是：“我們這邊對效能沒要求，你只要保證主要的功能沒問題就行”。當時初生牛犢不怕虎的我，自然不肯放過這樣的低階效能問題，所以又去找總監拿主意，結果開發知道後很是生氣，最後也還是按照產品需求的基本功能實現就交付了，理由是小專案時間緊，任務重，人員少，只需要保證需求的實現即可，其它效能可以放到後期版本再去考慮。

其實現在市面上很多公司都是初創，很多專案都是人員少時間緊，所以要求我們測試應把握重點，不要在無關緊要的地方測試過多。切勿為了無關緊要的“bug”浪費溝通成本。什麼是重點，就是產品的主要功能和市面上該產品的主流要求，使用者經常會用到的操作。

如果是需求明確的嚴重問題，相信只要是開發，他都會想法設法去修復它。但比如說，一些非常規操作導致的嚴重問題，開發人員會說，實際場景中，使用者是不會這樣操作的。

對於這些問題，溝通是很浪費成本的，可以把問題記錄在日報中，反饋給測試老大或專案負責人，由他們來評估。再比如說一些個人介面建議，我們可以提交bug，但是開發不改，也不影響使用者使用的，我們不用過多糾結，只需做好記錄備案即可。

6、集中火力開炮，將遇到的問題一起問開發

軟體開發行業每個人都很忙，特別是忙著敲程式碼的開發更是極少有耐心，問的多了甚至對你口吐芬芳，所以不要一發現跟預期不清楚的就去詢問，因為在忙的情況下，很大程度上你拋過去的問題都會被無視。聰明的做法是把你需要問的問題做一下整理，集中起來問開發。如果這種方法還是不行，我教授你一個訣竅，那就是搬把椅子坐他身後，你看他能無視你到多久，哈哈！?

所以測試這門學問，不僅是要具備測試的“智商”，更要講究點“情商”。將心比心地去換位思考，揣摩開發的內心世界，我們才能驅動開發去做他們本不願意的事情，才能夠高效地解決掉bug！