作爲測試人員，和我們最常打交道的，莫屬bug。當你發現bug後，會採取什麼樣的行動？是直接報出來，亦或找找問題原因？
不管是我們自己找到的，亦或是開發修復後告訴我們的，知道問題之所在總是好的。在本篇文章中，筆者試圖帶領大家一起梳理下，爲什麼測試人員定位問題很重要，以及我們可以使用什麼樣的定位方法。
一、定位問題的重要性
很多測試人員可能會說，我的職責就是找到bug，至於找原因並修復，那是開發的事情，關我什麼事？
好，我的回答是，如果您只想做一個測試人員最基本最本分的事情，那麼可以這麼想。但是，如果您想要在測試甚至開發的道路上長足發展，就要知其所以然。那麼，爲什麼定位問題如此重要？
1.可以明確一個問題是不是真的“bug”。很多時候，我們找到了問題的原因，也許發現這根本不是bug。原因明確，誤報就會降低。比如我們團隊的大梅同學，全年500個bug中沒有一個無效的。
2.找到bug原因後，可以明確地指個某個開發，防止他們打太極推來推去，提高缺陷的修復速度。
3.讓開發人員能夠佩服你，提升開發對測試的信任度。
4.自己在這個過程中能學到很多東西，有助於理解產品內部邏輯，對架構的理解，以及數據流是怎樣的走向。隨着對業務架構邏輯的理解，反過來又會促進對問題的定位。
5.可以降低缺陷率。這個可以說是最重要的。在bug系統中，我們會要求開發人員記錄bug產生的原因。只有我們自己對bug有一個較全面的認識，纔會判別出開發寫的是不是真正的原因，也纔能有助於我們後續對bug進行分析歸類，根據bug分析，有針對性地未雨綢繆，進而提升產品質量，降低缺陷。
所以，定位問題很重要。接下來我們就來探討下有哪些定位問題的方法和技巧。
二、問題定位技巧
首先，作爲開發也好，測試也好，定位問題有一個總的思路，而這個思路是和數據的走向一致的。大致是這樣：
用戶層面問題 -> Web頁面/軟件界面 -> 中間件 -> 後端服務 -> 代碼 -> 數據庫
以下都以Web頁面舉例說明。
用戶層面問題指的是用戶自己的環境問題或者操作問題，比如環境不通，或者操作不正確。這種問題一般不是bug，當然，如果要考慮構建更加健壯的軟件，那麼可以根據實際情況來決定要不要處理這類問題。
到第二步，用戶在Web頁面進行正常操作時，也可能會發現問題。這類問題一般通過觀察以及利用一些常識可以發現，比如樣式問題一般是css的問題，交互問題一般是js的問題，文本問題一般是html的問題（當然有可能是其他問題，例如js生成html）。
到第三步，Web頁面操作後，比如發出一個請求，可能會進入中間件這個層面。我這裏說的中間件是廣義上的，比如LVS、CDN、各種緩存服務器等等。我們遇到過一個問題，發現剛剛上傳的圖片進行讀取展示時就讀不到，那麼可以想到可能是負載均衡時將上傳照片和讀取照片兩個請求分配到了不同的服務器導致的，也就是我們常說的會話保持。當然，中間件問題有時候是和開發相關的，有時候是公司其他團隊負責的，比如360公司就是OPS在負責。當然，中間件也不僅僅會出現在這一步，實際的項目中可能還會用到更多的基礎設施，比如消息中間件、數據存取中間件等，如果發現了相應的問題也就需要有對應的思路去排查。
接着再往下到第四步，服務會轉發到我們真正的後端服務層，web服務器、應用服務器比如nginx、tomcat會收到請求。如果發現內存溢出，那麼就可能會定位到是tomcat配置的問題；如果請求返回404，也可能是nginx配置不當。當然，這個時候可能會遇到一些環境問題，比如測試環境沒有的問題，到線上就有了，很可能是環境原因，比如jdk版本不同、tomcat版本不同、jar包版本不同等等。
最後一層是數據庫。代碼沒有問題，不代表軟件沒有問題。數據庫層面也可能會有各種各樣的問題，比如字段的約束問題等等。假如一個文本框的前端校驗和接口校驗的文本長度最大是50，但數據表字段設定的是varchar(30)，那麼在存數據的時候肯定會報錯。再比如之前發現一個數據庫的問題，測試環境沒有，到線上卻有了，那麼也可以看下是不是數據庫版本不同導致的。
上面我們說的是問題定位的一個大致思路。每一個環節都有可能出現bug，既可能是response的問題，也可能是前端回調處理的問題。有的問題可能會直接暴漏在用戶面前，有些則可能需要我們去分析日誌。
當然，很多時候我們不需要這樣一層一層去定位，經驗豐富的開發或者測試根據現象可能馬上能定位到究竟哪裏出了問題。
下面我們就來說說測試人員定位問題的N板斧。
1
讓子彈飛一會兒
碰到問題先別忙定位，首先請保存犯罪現場，並且確認能復現。然後排除QA的低級問題 。爲什麼要保存現場？如果以後復現不了，就證明不了問題的存在。有哪些QA的低級問題？常見的就是hosts不對，網絡不通，以及操作姿勢不正確等等。這個其實就是上文提到的用戶層面問題，這裏的用戶就是QA人員。經常有QA人員發現問題後就趕緊叫開發過來看，開發這時候幽幽地說句“host對嗎”，一看不對豈不是很尷尬。
還有一類問題就是髒數據，我們有時候會遇到服務端報500錯誤，查看日誌後，報空指針，那麼很有可能就是數據庫中關聯表的數據被人爲刪掉導致的。還有的問題是由於工具的影響導致的，例如fiddler。所以發現問題您別慌，讓子彈飛一會，確認不是自己的問題再說。
2
直觀查看頁面表現
這個就是上文提到的對Web頁面的觀察。不再贅述。
3
看狀態碼
4xx狀態碼一般表示是客戶端問題（當然也有可能是服務器端配置問題），比如發生了401，那麼要看下是否帶了正確的身份驗證信息；發生了403則要看下是否有權限訪問；404則要看下對應的URL是否真實存在。
而5xx一般表示服務端問題。比如發生了500錯誤，則表明是服務器內部錯誤，這個時候要配合服務器log進行定位；發生了502則可能是服務器掛了導致的；發生503可能是由於網絡過載導致的；發生504則可能是程序執行時間過長導致超時。
4
看服務器日誌
如果發生5xx問題，或者檢查後端接口執行的sql是否正確，我們最常見的排查方法就是去看服務器日誌比如tomcat日誌，開發人員一般會打出關鍵信息和報錯信息，從而找到問題所在。測試人員要養成看日誌的習慣。並且，如果將來進行開發，也要養成打日誌的習慣，否則發現問題真不知道到哪哭去。
5
接口的請求和返回以及js執行是否有報錯
在第3點中我們說了狀態碼的問題，明確了4xx和5xx的問題所在。那麼，如果接口返回了200，就一定正常嗎？
假設有這麼一種情況，要測試一個翻頁控件，翻到第二頁的時候，發現內容和第一頁完全一樣，接口請求返回的是200。這個時候你會怎麼排查？
這個時候就要看前端發送的參數正不正常，後端返回的內容正不正常，即接口的請求和返回。
我們來看翻頁控件的問題。我們看接口的請求（F12控制檯查看網絡請求或者抓包工具），一般根據開發的習慣，會有pn、ps參數，看看傳值是否正確。如果請求參數不正確，那麼就是前端的問題。如果正確，那麼就看response，看看返回的內容對不對，以此就知道到底是前端問題還是服務端問題。如果發現js執行報錯了，那就是前端有問題，比如跨域問題。
請求URL不正確，是前端bug，傳參不正確，是前端bug，響應內容不正確，則是後端bug。如果是響應內容不正確的後端問題，那就要繼續深挖，是接口吐數據的時候出錯了，還是數據庫中的數據就錯了，還是緩存中的數據錯了（如果用到了緩存的話）。經常見到後端開發人員有的負責接口，有的負責寫入數據庫，有的負責維護緩存，所以如果發現是後端的問題，可以更進一步確認下是哪塊的問題。
6
看需求文檔
有時候，前端和服務端的交互都正確，但是從測試的角度看不合理。這個時候，我們應該翻翻需求文檔（如果沒有的話，就直接拋出這個問題）。如果和需求文檔不符，那麼就要看下誰改合理，是前端改，還是服務端改，或者兩者都得改。這裏有一個原則，就是前端儘可能少地去承擔邏輯，只負責渲染展現。當然，不要以爲需求文檔就全部正確，它也可能會有錯誤，我們也應該去發現需求文檔的bug，然後再去協調PM，敦促FE或者RD進行修改。在這點上，不得不說，有的開發做的比較好，他會有自己的思想，在開發的時候就能發現需求文檔的錯誤，而有的開發則是無條件無腦執行。
7
後端生成頁面問題
後端生成頁面，最常見的就是類似於jsp、php、python的某些前後端不分離的框架，這種比較特殊，常見於單人開發的項目，這種項目的問題排查和其他項目總的思路也一樣，只不過前後端bug的修改可能都是同一個人而已。
8
開發提供可測性支持
有時候，涉及到多方面合作，不太好測試的情況下，需要開發提供可測性支持。比如，要查看接口給另一個接口發的請求是否正確，可以讓開發打印出完整的請求log。還有一些邏輯開關、修改頁面數據條數等，都屬於可測性支持的範疇。
9
配置的問題
很多時候，bug不是代碼問題，而是tomcat配置、nginx配置、jdbc配置等的問題。在這個層面上，測試人員最好能夠了解下它們的各項配置，在發現問題後可能就會想到這方面的問題。
10
經驗法則
太陽底下沒有新鮮事，有經驗的人早就遇到過相同的問題。高手往往能夠一眼看穿表面現象內部的問題，然後直奔主題，迅速報告或者解決，留下別人在風中凌亂……
11
其他
常見的可能還有構建的問題，比如代碼本身都沒錯，但是合併代碼到主幹後出問題了，常見的就是代碼存在衝突時手動解決的時候。所以我之前有一段時間喜歡問開發在合併代碼時有沒有衝突，如果有衝突，那是什麼地方有衝突，就得重點對待了。
另外，定位到問題後，還要考慮下具體情況，根據開發人員的心態來決定要不要告訴他具體原因。有的開發不夠open，會覺得你搶了他的飯碗。而對於open的開發，你們會因此配合的更加默契。
當然，我們在發現問題或者定位到問題原因後，一定要進行一步，就是再次確認問題。所謂確認問題，就是弄清楚問題是否每次都發生，還是概率事件，或者是工具相關的問題（比如換個瀏覽器是否依然出現？如果換個瀏覽器不出現的話，很可能就是前端的兼容性問題）。比如翻頁控件，我們待測的系統有很多頁面都有翻頁控件，那麼就要看下是否每個頁面都會出現這個問題，進而報bug時進行統一說明，也更加方便開發人員批量處理，防止漏改。
以上是對問題的初步定位。對問題的進一步分析可能是更加體現測試人員素質的，比如你發現了一個問題，通過白盒測試看他的代碼，發現某一個分支的判斷條件寫錯了，並且把這些告訴了開發，那麼他一定會給你一個大大的贊，然後說上一句，小夥子靠譜，和你合作很愉快！
三、案例
下面介紹幾個常見的問題並逐一分析下。
1、點擊頁面的某個“修改”按鈕，頁面彈窗提示“unforbidden”，但需求文檔中顯示應該提示“沒有權限”，如何定位？
這個問題要看彈窗中的錯誤信息是誰發出的。如果點擊修改按鈕，前端發出了一個接口請求，而該接口的response中有“unforbidden”，那麼說明前端的提示是後端返回的，那麼就需要後端去修改。否則就是前端寫的提示。所以，有時候不能想當然地認爲前端彈窗提示文案一定是前端的問題。具體問題具體分析。
2.修改某個表單中文本框內的文字並提交，跳轉到結果列表頁後發現該文本內容顯示不全，該如何排查？
這個問題的可能性有很多，我們可能需要這樣排查：首先查看下錶單提交時，前端發送的請求中該文本內容是否正確，如果正確就再去數據庫中查看記錄，然後去看後端響應內容是否正確，然後去看前端渲染是否正確，以此來判斷是前後端交互的哪個環節出了問題。
四、總結
可以發現，上面兩個案例都沒有定論，都是得具體問題具體分析。我們只要掌握了分析方法和思路，就能夠找出來到底是哪裏出了問題。前端頁面所看到的所有元素以及所有數據，要麼是前端返回，要麼是後端返回，有問題了，就看是誰生成的返回，前端返回的就去找前端，後端返回的就去找後端，誰的孩子惹麻煩了就去找誰，前後端就靠http來通信，所以要多F12，多觀察前後端接口交互。
這只是經驗總結，並非標準。bug千差萬別，有時候需要一個一個分析。多修煉內功：對業務系統的掌握，測試方法以及開發技術。建設自己的bug知識庫，多思考、多積累、多總結。
最後，請謹記：對於無法確定的問題或者目前功力難以定位的問題，要交給開發，不要死磕，浪費時間。如果冒煙測試都不通過，就不要浪費時間定位了，直接打回。優先解決項目進度問題，其次纔是測試深度。