面試必問:如何快速定位BUG?BUG定位技巧及N板斧!
上課通知 ： 重磅消息 | 2022年最新全棧測(cè)試開發(fā)技能實(shí)戰(zhàn)指南（第3期）
PS: 全棧測(cè)開訓(xùn)練營(yíng)，本周六開始Python編程版塊（零基礎(chǔ)，有基礎(chǔ)皆適合）！
0 1 定位問題的重要性
很多測(cè)試人員可能會(huì)說，我的職責(zé)就是找到bug，至于找原因并修復(fù)，那是開發(fā)的事情，關(guān)我什么事？
好，我的回答是，如果您只想做一個(gè)測(cè)試人員最基本最本分的事情，那么可以這么想。但是，如果您想要在測(cè)試甚至開發(fā)的道路上長(zhǎng)足發(fā)展，就要知其所以然。
那么，為什么定位問題如此重要？
1、可以明確一個(gè)問題是不是真的“bug”。很多時(shí)候，我們找到了問題的原因，發(fā)現(xiàn)這根本不是bug。原因明確，誤報(bào)就會(huì)降低。比如我們團(tuán)隊(duì)的大梅同學(xué)，全年500個(gè)bug中沒有一個(gè)無效的。
2、找到bug原因后，可以明確地指給某個(gè)開發(fā)，防止他們打太極推來推去，提高缺陷的修復(fù)速度。
3、讓開發(fā)人員能夠佩服你，提升開發(fā)對(duì)測(cè)試的信任度。
4.自己在這個(gè)過程中能學(xué)到很多東西，有助于理解產(chǎn)品內(nèi)部邏輯，對(duì)架構(gòu)的理解，以及數(shù)據(jù)流是怎樣的走向。隨著對(duì)業(yè)務(wù)架構(gòu)邏輯的理解，反過來又會(huì)促進(jìn)對(duì)問題的定位。
5.可以降低缺陷率。這個(gè)可以說是最重要的。在bug系統(tǒng)中，我們會(huì)要求開發(fā)人員記錄bug產(chǎn)生的原因。只有我們自己對(duì)bug有一個(gè)較全面的認(rèn)識(shí)，才會(huì)判別出開發(fā)寫的是不是真正的原因，也才能有助于我們后續(xù)對(duì)bug進(jìn)行分析歸類，根據(jù)bug分析，有針對(duì)性地未雨綢繆，進(jìn)而提升產(chǎn)品質(zhì)量，降低缺陷。
所以，定位問題很重要。
接下來我們就來探討下有哪些定位問題的方法和技巧。
0 2 問題定位技巧
首先，定位問題有一個(gè)總的思路，而這個(gè)思路是和數(shù)據(jù)的走向一致的。大致是這樣：
首先當(dāng)系統(tǒng)出現(xiàn)bug時(shí)，一定要將bug現(xiàn)象進(jìn)行錄制保留，保留現(xiàn)象是為了證明這個(gè)bug出現(xiàn)過，如果bug是固定重現(xiàn)還好說，如果該bug無法重現(xiàn)，那么保存的截圖都是你直接證據(jù)，要養(yǎng)成良好的保存現(xiàn)場(chǎng)的習(xí)慣提BUG這塊，還是要體現(xiàn)出測(cè)試的專業(yè)性，標(biāo)題簡(jiǎn)潔、問題環(huán)境標(biāo)識(shí)清楚、問題詳細(xì)描述清楚、系統(tǒng)錯(cuò)誤表象貼圖、接口傳參返參貼圖、必要時(shí)貼服務(wù)器日志，總結(jié)來說不該少的bug標(biāo)簽一個(gè)不要少
一.?小型產(chǎn)品，前后端一人統(tǒng)籌 一些小型程序，例如前后端都用node、php語言開發(fā)的，整個(gè)系統(tǒng)前后端是同一個(gè)開發(fā)的時(shí)候，那么小編可以自信的給你說，系統(tǒng)出現(xiàn)問題時(shí)，bug大膽的提，往猝死的提，責(zé)任人錯(cuò)不了！
二.?常規(guī)系統(tǒng)，多人開發(fā)協(xié)同
前置：測(cè)試之前該測(cè)試人員對(duì)系統(tǒng)、業(yè)務(wù)、環(huán)境部署、開發(fā)人員等較為熟悉
在測(cè)試之前打開對(duì)應(yīng)瀏覽器的F12直接開個(gè)新頁(yè)簽，或者使用抓包工具等，系統(tǒng)呈現(xiàn)出問題時(shí)，查看對(duì)應(yīng)的請(qǐng)求、日志信息等我們才能去全面的定位是前端還是后端人員的問題，具體給大家介紹以下幾個(gè)常用方法
1.?分析問題場(chǎng)景進(jìn)行預(yù)判 先查看頁(yè)面表象，根據(jù)問題表像判斷問題可能出現(xiàn)的原因，進(jìn)行縮小范圍，并且準(zhǔn)備好錄制工具，錄制問題
系統(tǒng)頁(yè)面無法正常訪問的提示5開頭的找后端，4開頭的先檢查請(qǐng)求地址或者對(duì)應(yīng)的權(quán)限，進(jìn)入系統(tǒng)頁(yè)面正常打開，提示異常代碼錯(cuò)誤的直接找后端
進(jìn)入系統(tǒng)頁(yè)面展示異常圖片視頻相關(guān)提示Flash等相關(guān)信息進(jìn)行安裝Flash如若還不行找前端，界面UI展示兼容性錯(cuò)誤找前端
如若系統(tǒng)訪問正常，進(jìn)入操作頁(yè)面，功能性報(bào)錯(cuò)信息，就進(jìn)入下面環(huán)節(jié)，抓包查看對(duì)應(yīng)請(qǐng)求體，看日志等
2. 關(guān)注請(qǐng)求體的狀態(tài)碼
4**開頭的狀態(tài)碼一般都是客戶端（前端）的問題；例如常見的404確認(rèn)下是否是請(qǐng)求的地址有錯(cuò)，403確認(rèn)是否有權(quán)限訪問，具體可百度5**開頭的狀態(tài)碼一般都是服務(wù)端（后端）問題，例如常見的500，則表示是服務(wù)器內(nèi)部錯(cuò)誤，503網(wǎng)絡(luò)過載導(dǎo)致服務(wù)端延時(shí)，502服務(wù)器崩潰等，具體可百度
3.關(guān)注請(qǐng)求的入?yún)⑴c響應(yīng)數(shù)據(jù)
通過訪問報(bào)錯(cuò)的頁(yè)面，加載錯(cuò)誤請(qǐng)求時(shí)我們通過F12進(jìn)行分析請(qǐng)求包，查看對(duì)應(yīng)的入?yún)⒁约绊憫?yīng)數(shù)據(jù)
例如：請(qǐng)求入?yún)㈠e(cuò)誤，那么該bug屬于前端的錯(cuò)誤；入?yún)?biāo)準(zhǔn)可以根據(jù)前端頁(yè)面的輸入的內(nèi)容或者選擇的內(nèi)容，進(jìn)行核驗(yàn)， 入?yún)⒏袷揭约笆欠癖靥畹瓤梢詫?duì)應(yīng)接口文檔去進(jìn)行分析或跟開發(fā)確認(rèn)
例如：請(qǐng)求未響應(yīng)或者響應(yīng)數(shù)據(jù)錯(cuò)誤，那么該bug就屬于后端的錯(cuò)誤；一般是數(shù)據(jù)庫(kù)查看報(bào)錯(cuò)，例如刪了某個(gè)表查詢報(bào)錯(cuò)誤空指針等
如果請(qǐng)求的入?yún)⒒蛘唔憫?yīng)數(shù)據(jù)都沒問題，可以跟開發(fā)反饋是不是瀏覽器解析的問題，可以換個(gè)瀏覽器測(cè)試
4. 查看日志 針對(duì)服務(wù)端類型的報(bào)錯(cuò)，我們可以進(jìn)行登錄日志平臺(tái)或者服務(wù)器對(duì)應(yīng)Log目錄下查看打印出的日志
常用查看日志命令tail ,/error進(jìn)行快速檢索關(guān)鍵詞接口名等相關(guān)內(nèi)容
拿到對(duì)應(yīng)的日志,將日志文件貼進(jìn)bug單，指派給后端，提高專業(yè)性，測(cè)試人員也要養(yǎng)成看日志的習(xí)慣，看著看著就懂了
5. 經(jīng)驗(yàn)法則 在系統(tǒng)前端頁(yè)面當(dāng)碰見服務(wù)器配置相關(guān)報(bào)錯(cuò)的信息例如Nginx***或者代碼以及SQL相關(guān)的提示報(bào)錯(cuò)信息直接找后端處理，例如JAVA**** 、.PHP、SQL等異常報(bào)錯(cuò)
前端字符校驗(yàn)、格式校驗(yàn)、等，瀏覽器界面UI兼容性以及插件，或者APP、小程序類調(diào)用手機(jī)相關(guān)功能拍照、語音無法正常調(diào)用直接找前端
下面我們就來說說 測(cè)試人員定位問題的N板斧 。
1、讓子彈飛一會(huì)兒
碰到問題先別忙定位，首先請(qǐng)保存犯罪現(xiàn)場(chǎng)，并且確認(rèn)能復(fù)現(xiàn)。然后排除QA的低級(jí)問題 。為什么要保存現(xiàn)場(chǎng)？如果以后復(fù)現(xiàn)不了，就證明不了問題的存在。有哪些QA的低級(jí)問題？常見的就是hosts不對(duì)，網(wǎng)絡(luò)不通，以及操作姿勢(shì)不正確等等。這個(gè)其實(shí)就是上文提到的用戶層面問題，這里的用戶就是QA人員。經(jīng)常有QA人員發(fā)現(xiàn)問題后就趕緊叫開發(fā)過來看，開發(fā)這時(shí)候幽幽地說句“host對(duì)嗎”，一看不對(duì)豈不是很尷尬。
還有一類問題就是臟數(shù)據(jù)，我們有時(shí)候會(huì)遇到服務(wù)端報(bào)500錯(cuò)誤，查看日志后，報(bào)空指針，那么很有可能就是數(shù)據(jù)庫(kù)中關(guān)聯(lián)表的數(shù)據(jù)被人為刪掉導(dǎo)致的。還有的問題是由于工具的影響導(dǎo)致的，例如fiddler。所以發(fā)現(xiàn)問題您別慌，讓子彈飛一會(huì)，確認(rèn)不是自己的問題再說。
2、直觀查看頁(yè)面表現(xiàn)
這個(gè)就是上文提到的對(duì)Web頁(yè)面的觀察。不再贅述。
3、看狀態(tài)碼
4xx狀態(tài)碼一般表示是客戶端問題（當(dāng)然也有可能是服務(wù)器端配置問題），比如發(fā)生了401，那么要看下是否帶了正確的身份驗(yàn)證信息；發(fā)生了403則要看下是否有權(quán)限訪問；404則要看下對(duì)應(yīng)的URL是否真實(shí)存在。
而5xx一般表示服務(wù)端問題。比如發(fā)生了500錯(cuò)誤，則表明是服務(wù)器內(nèi)部錯(cuò)誤，這個(gè)時(shí)候要配合服務(wù)器log進(jìn)行定位；發(fā)生了502則可能是服務(wù)器掛了導(dǎo)致的；發(fā)生503可能是由于網(wǎng)絡(luò)過載導(dǎo)致的；發(fā)生504則可能是程序執(zhí)行時(shí)間過長(zhǎng)導(dǎo)致超時(shí)。
4、看服務(wù)器日志
如果發(fā)生5xx問題，或者檢查后端接口執(zhí)行的sql是否正確，我們最常見的排查方法就是去看服務(wù)器日志比如tomcat日志，開發(fā)人員一般會(huì)打出關(guān)鍵信息和報(bào)錯(cuò)信息，從而找到問題所在。測(cè)試人員要養(yǎng)成看日志的習(xí)慣。并且，如果將來進(jìn)行開發(fā)，也要養(yǎng)成打日志的習(xí)慣，否則發(fā)現(xiàn)問題真不知道到哪哭去。
5、接口的請(qǐng)求和返回以及js執(zhí)行是否有報(bào)錯(cuò)
在第3點(diǎn)中我們說了狀態(tài)碼的問題，明確了4xx和5xx的問題所在。那么，如果接口返回了200，就一定正常嗎？
假設(shè)有這么一種情況，要測(cè)試一個(gè)翻頁(yè)控件，翻到第二頁(yè)的時(shí)候，發(fā)現(xiàn)內(nèi)容和第一頁(yè)完全一樣，接口請(qǐng)求返回的是200。這個(gè)時(shí)候你會(huì)怎么排查？
這個(gè)時(shí)候就要看前端發(fā)送的參數(shù)正不正常，后端返回的內(nèi)容正不正常，即接口的請(qǐng)求和返回。
我們來看翻頁(yè)控件的問題。我們看接口的請(qǐng)求（F12控制臺(tái)查看網(wǎng)絡(luò)請(qǐng)求或者抓包工具），一般根據(jù)開發(fā)的習(xí)慣，會(huì)有pn、ps參數(shù)，看看傳值是否正確。如果請(qǐng)求參數(shù)不正確，那么就是前端的問題。如果正確，那么就看response，看看返回的內(nèi)容對(duì)不對(duì)，以此就知道到底是前端問題還是服務(wù)端問題。如果發(fā)現(xiàn)js執(zhí)行報(bào)錯(cuò)了，那就是前端有問題，比如跨域問題。
請(qǐng)求URL不正確，是前端bug，傳參不正確，是前端bug，響應(yīng)內(nèi)容不正確，則是后端bug。如果是響應(yīng)內(nèi)容不正確的后端問題，那就要繼續(xù)深挖，是接口吐數(shù)據(jù)的時(shí)候出錯(cuò)了，還是數(shù)據(jù)庫(kù)中的數(shù)據(jù)就錯(cuò)了，還是緩存中的數(shù)據(jù)錯(cuò)了（如果用到了緩存的話）。經(jīng)常見到后端開發(fā)人員有的負(fù)責(zé)接口，有的負(fù)責(zé)寫入數(shù)據(jù)庫(kù)，有的負(fù)責(zé)維護(hù)緩存，所以如果發(fā)現(xiàn)是后端的問題，可以更進(jìn)一步確認(rèn)下是哪塊的問題。
6、看需求文檔
有時(shí)候，前端和服務(wù)端的交互都正確，但是從測(cè)試的角度看不合理。這個(gè)時(shí)候，我們應(yīng)該翻翻需求文檔（如果沒有的話，就直接拋出這個(gè)問題）。如果和需求文檔不符，那么就要看下誰改合理，是前端改，還是服務(wù)端改，或者兩者都得改。這里有一個(gè)原則，就是前端盡可能少地去承擔(dān)邏輯，只負(fù)責(zé)渲染展現(xiàn)。當(dāng)然，不要以為需求文檔就全部正確，它也可能會(huì)有錯(cuò)誤，我們也應(yīng)該去發(fā)現(xiàn)需求文檔的bug，然后再去協(xié)調(diào)PM，敦促FE或者RD進(jìn)行修改。在這點(diǎn)上，不得不說，有的開發(fā)做的比較好，他會(huì)有自己的思想，在開發(fā)的時(shí)候就能發(fā)現(xiàn)需求文檔的錯(cuò)誤，而有的開發(fā)則是無條件無腦執(zhí)行。
7、后端生成頁(yè)面問題
后端生成頁(yè)面，最常見的就是類似于jsp、php、python的某些前后端不分離的框架，這種比較特殊，常見于單人開發(fā)的項(xiàng)目，這種項(xiàng)目的問題排查和其他項(xiàng)目總的思路也一樣，只不過前后端bug的修改可能都是同一個(gè)人而已。
8、開發(fā)提供可測(cè)性支持
有時(shí)候，涉及到多方面合作，不太好測(cè)試的情況下，需要開發(fā)提供可測(cè)性支持。比如，要查看接口給另一個(gè)接口發(fā)的請(qǐng)求是否正確，可以讓開發(fā)打印出完整的請(qǐng)求log。還有一些邏輯開關(guān)、修改頁(yè)面數(shù)據(jù)條數(shù)等，都屬于可測(cè)性支持的范疇。
9、配置的問題
很多時(shí)候，bug不是代碼問題，而是tomcat配置、nginx配置、jdbc配置等的問題。在這個(gè)層面上，測(cè)試人員最好能夠了解下它們的各項(xiàng)配置，在發(fā)現(xiàn)問題后可能就會(huì)想到這方面的問題。
10、經(jīng)驗(yàn)法則
太陽底下沒有新鮮事，有經(jīng)驗(yàn)的人早就遇到過相同的問題。高手往往能夠一眼看穿表面現(xiàn)象內(nèi)部的問題，然后直奔主題，迅速報(bào)告或者解決，留下別人在風(fēng)中凌亂……
11、其他
常見的可能還有構(gòu)建的問題，比如代碼本身都沒錯(cuò)，但是合并代碼到主干后出問題了，常見的就是代碼存在沖突時(shí)手動(dòng)解決的時(shí)候。所以我之前有一段時(shí)間喜歡問開發(fā)在合并代碼時(shí)有沒有沖突，如果有沖突，那是什么地方有沖突，就得重點(diǎn)對(duì)待了。
另外，定位到問題后，還要考慮下具體情況，根據(jù)開發(fā)人員的心態(tài)來決定要不要告訴他具體原因。有的開發(fā)不夠open，會(huì)覺得你搶了他的飯碗。而對(duì)于open的開發(fā)，你們會(huì)因此配合的更加默契。
當(dāng)然，我們在發(fā)現(xiàn)問題或者定位到問題原因后，一定要進(jìn)行一步，就是再次確認(rèn)問題。所謂確認(rèn)問題，就是弄清楚問題是否每次都發(fā)生，還是概率事件，或者是工具相關(guān)的問題（比如換個(gè)瀏覽器是否依然出現(xiàn)？如果換個(gè)瀏覽器不出現(xiàn)的話，很可能就是前端的兼容性問題）。比如翻頁(yè)控件，我們待測(cè)的系統(tǒng)有很多頁(yè)面都有翻頁(yè)控件，那么就要看下是否每個(gè)頁(yè)面都會(huì)出現(xiàn)這個(gè)問題，進(jìn)而報(bào)bug時(shí)進(jìn)行統(tǒng)一說明，也更加方便開發(fā)人員批量處理，防止漏改。
如果這篇文章對(duì)你有所幫助，或者有所啟發(fā)的話，幫忙 點(diǎn)贊 、 在看 、 轉(zhuǎn)發(fā) 、 收藏 ，你的支持就是我堅(jiān)持下去的最大動(dòng)力！
推薦閱讀：
END
所有原創(chuàng)文章
第一時(shí)間發(fā)布至此公眾號(hào)「測(cè)試開發(fā)技術(shù)」
長(zhǎng)按二維碼/微信掃碼? 添加作者