你是否經(jīng)常碰到如下的問題：

如果你對一個(gè)程序員說：

“你的代碼有bug,你的代碼有蟲”

那么他第一反應(yīng)肯定是：

1.你的環(huán)境有問題吧

2.你會(huì)用嗎？

但如果你換個(gè)委婉的說法：

“你這個(gè)程序和預(yù)期的有點(diǎn)不一致，你看看是不是我的使用方法有問題。”

他本能的就會(huì)想：

呀，是不是出bug了!

上述大家看到的其實(shí)還算“溫柔”的，其實(shí)有些情況下，某些測試人員或者開發(fā)人員脾氣大的可能撕逼或者快干架。所以如何和開發(fā)有效溝通，并高效勸說開發(fā)改掉bug是一門學(xué)問，以下是我總結(jié)八年測試經(jīng)驗(yàn)給測試新人的一些建議：

01、和開發(fā)人員保持友好的團(tuán)隊(duì)關(guān)系

和開發(fā)人員保持友好的團(tuán)隊(duì)關(guān)系。這是最重要的一點(diǎn)！~

我以前遇到一個(gè)開發(fā)，剛開始給他提bug時(shí)，他是各種抵觸情緒加敷衍。后來我就私底下和他多接觸，了解他的脾氣，久而久之他也和我熟絡(luò)起來，結(jié)果不僅不再有抵觸情緒，甚至還幫我主動(dòng)定位bug。

其實(shí)人心都是肉長的，我們做事既要講理，也要適當(dāng)打打“感情牌”。注意跟開發(fā)溝通的語氣，要有換位思考的意識(shí)，做事情對事不對人，對待開發(fā)要確保在解決bug的前提下盡量不傷和氣。

也只有這樣，才能夠很好的說服開發(fā)去修改Bug。當(dāng)然有時(shí)候我們也會(huì)遇到強(qiáng)勢的開發(fā)，油鹽不進(jìn)的那種，對我們的測試工作帶來層層阻力，我也親身經(jīng)歷過，但是這種開發(fā)畢竟是少數(shù)，如果真遇到了那就具體問題具體分析吧！

02、要確定這是一個(gè)真正的bug

不要出現(xiàn)因?yàn)榕渲迷蚧蛘呤遣僮麇e(cuò)誤引起的“bug”，這樣是會(huì)被開發(fā)“鄙視”的。最搞笑的是自己測錯(cuò)了版本，然后測出了老版本的問題，那就尷尬了。

或者自己電腦網(wǎng)絡(luò)問題，結(jié)果以為是服務(wù)器響應(yīng)問題，這樣的失誤多了肯定降低自己在開發(fā)心中的地位。作為一名測試人員，我們應(yīng)該樹立在開發(fā)心中專業(yè)的形象。

這樣說話才有分量。遇到問題先別頭腦一發(fā)熱就去找開發(fā)詢問，哪怕有些自己不確定了也盡可能自己想辦法確認(rèn)問題，確定是bug了再去找開發(fā)。

一定要記住，我們可是專業(yè)的“蟲師” ！

03、盡可能寫好bug描述

盡可能寫好bug描述，方便他人就是方便自己。

以前我工作中遇到過一個(gè)現(xiàn)象，就是同組的女測試每次提的bug都能比我解決的快，我當(dāng)時(shí)很納悶，就去詢問開發(fā)人員，這是性別歧視還是憐香惜玉呢？

結(jié)果開發(fā)只回了一句：“她解釋的更清楚，你的需要反復(fù)核對才能確定！”從那以后我痛定思痛，在缺陷管理工具中會(huì)將bug的詳情描述的特別清晰。而且咱們測試描述地越清晰，越具體，開發(fā)才會(huì)更加佩服你的“專業(yè)”。

Bug的描述盡量詳細(xì)且淺顯易懂，確保沒有歧義，復(fù)現(xiàn)的步驟一定要條理清晰，你的預(yù)期結(jié)果和現(xiàn)有的結(jié)果，截圖也要盡量標(biāo)注信息且清晰。如果是特殊的測試數(shù)據(jù)，我們還需要附帶這些數(shù)據(jù)。

對于復(fù)現(xiàn)率很低的問題，需要注明復(fù)現(xiàn)率，詳細(xì)記錄當(dāng)時(shí)的測試環(huán)境信息。如操作系統(tǒng)、產(chǎn)品名稱、版本、操作步驟、是否機(jī)器相關(guān)、是否產(chǎn)品相關(guān)等。

04、提升自己的專業(yè)技能

我剛?cè)胄袝r(shí)遇到一次特別囧的經(jīng)歷，有一次給團(tuán)隊(duì)的開發(fā)提Bug,結(jié)果新來的女前端跑來質(zhì)問我，一個(gè)后臺(tái)問題怎么提給了她前端。

當(dāng)時(shí)我才明白，我們測試打鐵必須自身硬，必須具備對bug的基本定位能力，就比如剛說的Bug，如果我當(dāng)時(shí)會(huì)F12看下報(bào)的是502問題，肯定就不會(huì)提交到前端開發(fā)人員那去了。

其實(shí)我們測試人員，首先是對業(yè)務(wù)分析的能力。要充分熟悉我們軟件產(chǎn)品各個(gè)層面的業(yè)務(wù)，包括功能業(yè)務(wù)，代碼實(shí)現(xiàn)邏輯，環(huán)境配置部署等。

特別是做功能測試時(shí)，我們必須對所測模塊的需求很熟悉，要比開發(fā)人員更熟悉?；蛘哒f一名專業(yè)的測試人員，可能比客戶和PM更懂這塊的規(guī)范。其次我們必須具備市面上常見的軟件測試技巧，掌握主流的測試工具。

比如為了更高效測試而采取的自動(dòng)化測試！說到這，你應(yīng)該很自然地想到也應(yīng)該具備基本的代碼閱讀能力吧，要想成為一名優(yōu)秀的測試工程師，我們應(yīng)該知己知彼，知道開發(fā)是怎么個(gè)代碼邏輯實(shí)現(xiàn)需求，從而能夠更精準(zhǔn)的定位深層次的問題。

05、測試應(yīng)把握重點(diǎn)

測試應(yīng)把握重點(diǎn)，切勿胡子眉毛一把抓。

這點(diǎn)當(dāng)然也是測試界特別需要注意的一點(diǎn)，那就是在有限的測試時(shí)間內(nèi)我們應(yīng)該有舍有得。

我曾經(jīng)在這塊有過一次爭的面紅耳赤的經(jīng)歷，之前我們做過一個(gè)交通方面的OA系統(tǒng)，我當(dāng)時(shí)為了全面保障項(xiàng)目質(zhì)量，在產(chǎn)品需求之外進(jìn)行了一次性能測試，結(jié)果Jmeter測出來并發(fā)100用戶時(shí)系統(tǒng)就崩了，要知道我之前測的再小的OA系統(tǒng)也能承受500以上的并發(fā)。

所以我當(dāng)即就找PM和主要開發(fā)人員反應(yīng)該問題，本來以為他們在驚訝之余會(huì)立馬解決該性能問題，結(jié)果得到的答復(fù)卻是：“我們這邊對性能沒要求，你只要保證主要的功能沒問題就行”。

當(dāng)時(shí)初生牛犢不怕虎的我，自然不肯放過這樣的低級(jí)性能問題，所以又去找總監(jiān)拿主意，結(jié)果開發(fā)知道后很是生氣，最后也還是按照產(chǎn)品需求的基本功能實(shí)現(xiàn)就交付了，理由是小項(xiàng)目時(shí)間緊，任務(wù)重，人員少，只需要保證需求的實(shí)現(xiàn)即可，其它性能可以放到后期版本再去考慮。

其實(shí)現(xiàn)在市面上很多公司都是初創(chuàng)，很多項(xiàng)目都是人員少時(shí)間緊，所以要求我們測試應(yīng)把握重點(diǎn)，不要在無關(guān)緊要的地方測試過多。

切勿為了無關(guān)緊要的“bug”浪費(fèi)溝通成本。什么是重點(diǎn)，就是產(chǎn)品的主要功能和市面上該產(chǎn)品的主流要求，用戶經(jīng)常會(huì)用到的操作。

如果是需求明確的嚴(yán)重問題，相信只要是開發(fā)，他都會(huì)想法設(shè)法去修復(fù)它。但比如說，一些非常規(guī)操作導(dǎo)致的嚴(yán)重問題，開發(fā)人員會(huì)說，實(shí)際場景中，用戶是不會(huì)這樣操作的。

對于這些問題，溝通是很浪費(fèi)成本的，可以把問題記錄在日報(bào)中，反饋給測試?yán)洗蠡蝽?xiàng)目負(fù)責(zé)人，由他們來評估。再比如說一些個(gè)人界面建議，我們可以提交bug，但是開發(fā)不改，也不影響用戶使用的，我們不用過多糾結(jié)，只需做好記錄備案即可。

06、集中火力開炮，將遇到的問題一起問開發(fā)

軟件開發(fā)行業(yè)每個(gè)人都很忙，特別是忙著敲代碼的開發(fā)更是極少有耐心，問的多了甚至對你口吐芬芳，所以不要一發(fā)現(xiàn)跟預(yù)期不清楚的就去詢問，因?yàn)樵诿Φ那闆r下，很大程度上你拋過去的問題都會(huì)被無視。

聰明的做法是把你需要問的問題做一下整理，集中起來問開發(fā)。如果這種方法還是不行，我教授你一個(gè)訣竅，那就是搬把椅子坐他身后，你看他能無視你到多久，哈哈！

所以測試這門學(xué)問，不僅是要具備測試的“智商”，更要講究點(diǎn)“情商”。將心比心地去換位思考，揣摩開發(fā)的內(nèi)心世界，我們才能驅(qū)動(dòng)開發(fā)去做他們本不愿意的事情，才能夠高效地解決掉bug！

??想了解更多漲薪技能提升方法

??可以到我的個(gè)人號(hào)：atstudy-js

即可加入領(lǐng)取 ??????

轉(zhuǎn)行、入門、提升、需要的各種干貨資料

內(nèi)含AI測試、 車載測試、AI大模型開發(fā)、BI數(shù)據(jù)分析、銀行測試、游戲測試、AIGC