九色国产,午夜在线视频,新黄色网址,九九色综合,天天做夜夜做久久做狠狠,天天躁夜夜躁狠狠躁2021a,久久不卡一区二区三区

作為測試人員，和我們最常打交道的，莫屬bug。當你發(fā)現(xiàn)bug后，會采取什么樣的行動？是直接報出來，亦或找找問題原因？

不管是我們自己找到的，亦或是開發(fā)修復后告訴我們的，知道問題之所在總是好的。在本篇文章中，筆者試圖帶領大家一起梳理下，為什么測試人員定位問題很重要，以及我們可以使用什么樣的定位方法。

很多測試人員可能會說，我的職責就是找到bug，至于找原因并修復，那是開發(fā)的事情，關我什么事？

好，我的回答是，如果您只想做一個測試人員最基本最本分的事情，那么可以這么想。但是，如果您想要在測試甚至開發(fā)的道路上長足發(fā)展，就要知其所以然。那么，為什么定位問題如此重要？

1.可以明確一個問題是不是真的“bug”。很多時候，我們找到了問題的原因，也許發(fā)現(xiàn)這根本不是bug。原因明確，誤報就會降低。比如我們團隊的大梅同學，全年500個bug中沒有一個無效的。

2.找到bug原因后，可以明確地指個某個開發(fā)，防止他們打太極推來推去，提高缺陷的修復速度。

3.讓開發(fā)人員能夠佩服你，提升開發(fā)對測試的信任度。

4.自己在這個過程中能學到很多東西，有助于理解產品內部邏輯，對架構的理解，以及數(shù)據流是怎樣的走向。隨著對業(yè)務架構邏輯的理解，反過來又會促進對問題的定位。

5.可以降低缺陷率。這個可以說是最重要的。在bug系統(tǒng)中，我們會要求開發(fā)人員記錄bug產生的原因。只有我們自己對bug有一個較全面的認識，才會判別出開發(fā)寫的是不是真正的原因，也才能有助于我們后續(xù)對bug進行分析歸類，根據bug分析，有針對性地未雨綢繆，進而提升產品質量，降低缺陷。

所以，定位問題很重要。接下來我們就來探討下有哪些定位問題的方法和技巧。

首先，作為開發(fā)也好，測試也好，定位問題有一個總的思路，而這個思路是和數(shù)據的走向一致的。大致是這樣：

用戶層面問題 -> Web頁面/軟件界面 -> 中間件 -> 后端服務 -> 代碼 -> 數(shù)據庫

以下都以Web頁面舉例說明。

用戶層面問題指的是用戶自己的環(huán)境問題或者操作問題，比如環(huán)境不通，或者操作不正確。這種問題一般不是bug，當然，如果要考慮構建更加健壯的軟件，那么可以根據實際情況來決定要不要處理這類問題。

到第二步，用戶在Web頁面進行正常操作時，也可能會發(fā)現(xiàn)問題。這類問題一般通過觀察以及利用一些常識可以發(fā)現(xiàn)，比如樣式問題一般是css的問題，交互問題一般是js的問題，文本問題一般是html的問題（當然有可能是其他問題，例如js生成html）。

到第三步，Web頁面操作后，比如發(fā)出一個請求，可能會進入中間件這個層面。我這里說的中間件是廣義上的，比如LVS、CDN、各種緩存服務器等等。我們遇到過一個問題，發(fā)現(xiàn)剛剛上傳的圖片進行讀取展示時就讀不到，那么可以想到可能是負載均衡時將上傳照片和讀取照片兩個請求分配到了不同的服務器導致的，也就是我們常說的會話保持。當然，中間件問題有時候是和開發(fā)相關的，有時候是公司其他團隊負責的，比如360公司就是OPS在負責。當然，中間件也不僅僅會出現(xiàn)在這一步，實際的項目中可能還會用到更多的基礎設施，比如消息中間件、數(shù)據存取中間件等，如果發(fā)現(xiàn)了相應的問題也就需要有對應的思路去排查。

接著再往下到第四步，服務會轉發(fā)到我們真正的后端服務層，web服務器、應用服務器比如nginx、tomcat會收到請求。如果發(fā)現(xiàn)內存溢出，那么就可能會定位到是tomcat配置的問題；如果請求返回404，也可能是nginx配置不當。當然，這個時候可能會遇到一些環(huán)境問題，比如測試環(huán)境沒有的問題，到線上就有了，很可能是環(huán)境原因，比如jdk版本不同、tomcat版本不同、jar包版本不同等等。

最后一層是數(shù)據庫。代碼沒有問題，不代表軟件沒有問題。數(shù)據庫層面也可能會有各種各樣的問題，比如字段的約束問題等等。假如一個文本框的前端校驗和接口校驗的文本長度最大是50，但數(shù)據表字段設定的是varchar(30)，那么在存數(shù)據的時候肯定會報錯。再比如之前發(fā)現(xiàn)一個數(shù)據庫的問題，測試環(huán)境沒有，到線上卻有了，那么也可以看下是不是數(shù)據庫版本不同導致的。

上面我們說的是問題定位的一個大致思路。每一個環(huán)節(jié)都有可能出現(xiàn)bug，既可能是response的問題，也可能是前端回調處理的問題。有的問題可能會直接暴漏在用戶面前，有些則可能需要我們去分析日志。

當然，很多時候我們不需要這樣一層一層去定位，經驗豐富的開發(fā)或者測試根據現(xiàn)象可能馬上能定位到究竟哪里出了問題。

下面我們就來說說測試人員定位問題的N板斧。

碰到問題先別忙定位，首先請保存犯罪現(xiàn)場，并且確認能復現(xiàn)。然后排除QA的低級問題 。為什么要保存現(xiàn)場？如果以后復現(xiàn)不了，就證明不了問題的存在。有哪些QA的低級問題？常見的就是hosts不對，網絡不通，以及操作姿勢不正確等等。這個其實就是上文提到的用戶層面問題，這里的用戶就是QA人員。經常有QA人員發(fā)現(xiàn)問題后就趕緊叫開發(fā)過來看，開發(fā)這時候幽幽地說句“host對嗎”，一看不對豈不是很尷尬。

還有一類問題就是臟數(shù)據，我們有時候會遇到服務端報500錯誤，查看日志后，報空指針，那么很有可能就是數(shù)據庫中關聯(lián)表的數(shù)據被人為刪掉導致的。還有的問題是由于工具的影響導致的，例如fiddler。所以發(fā)現(xiàn)問題您別慌，讓子彈飛一會，確認不是自己的問題再說。

這個就是上文提到的對Web頁面的觀察。不再贅述。

4xx狀態(tài)碼一般表示是客戶端問題（當然也有可能是服務器端配置問題），比如發(fā)生了401，那么要看下是否帶了正確的身份驗證信息；發(fā)生了403則要看下是否有權限訪問；404則要看下對應的URL是否真實存在。

而5xx一般表示服務端問題。比如發(fā)生了500錯誤，則表明是服務器內部錯誤，這個時候要配合服務器log進行定位；發(fā)生了502則可能是服務器掛了導致的；發(fā)生503可能是由于網絡過載導致的；發(fā)生504則可能是程序執(zhí)行時間過長導致超時。

如果發(fā)生5xx問題，或者檢查后端接口執(zhí)行的sql是否正確，我們最常見的排查方法就是去看服務器日志比如tomcat日志，開發(fā)人員一般會打出關鍵信息和報錯信息，從而找到問題所在。測試人員要養(yǎng)成看日志的習慣。并且，如果將來進行開發(fā)，也要養(yǎng)成打日志的習慣，否則發(fā)現(xiàn)問題真不知道到哪哭去。

在第3點中我們說了狀態(tài)碼的問題，明確了4xx和5xx的問題所在。那么，如果接口返回了200，就一定正常嗎？

假設有這么一種情況，要測試一個翻頁控件，翻到第二頁的時候，發(fā)現(xiàn)內容和第一頁完全一樣，接口請求返回的是200。這個時候你會怎么排查？

這個時候就要看前端發(fā)送的參數(shù)正不正常，后端返回的內容正不正常，即接口的請求和返回。

我們來看翻頁控件的問題。我們看接口的請求（F12控制臺查看網絡請求或者抓包工具），一般根據開發(fā)的習慣，會有pn、ps參數(shù)，看看傳值是否正確。如果請求參數(shù)不正確，那么就是前端的問題。如果正確，那么就看response，看看返回的內容對不對，以此就知道到底是前端問題還是服務端問題。如果發(fā)現(xiàn)js執(zhí)行報錯了，那就是前端有問題，比如跨域問題。

請求URL不正確，是前端bug，傳參不正確，是前端bug，響應內容不正確，則是后端bug。如果是響應內容不正確的后端問題，那就要繼續(xù)深挖，是接口吐數(shù)據的時候出錯了，還是數(shù)據庫中的數(shù)據就錯了，還是緩存中的數(shù)據錯了（如果用到了緩存的話）。經常見到后端開發(fā)人員有的負責接口，有的負責寫入數(shù)據庫，有的負責維護緩存，所以如果發(fā)現(xiàn)是后端的問題，可以更進一步確認下是哪塊的問題。

有時候，前端和服務端的交互都正確，但是從測試的角度看不合理。這個時候，我們應該翻翻需求文檔（如果沒有的話，就直接拋出這個問題）。如果和需求文檔不符，那么就要看下誰改合理，是前端改，還是服務端改，或者兩者都得改。這里有一個原則，就是前端盡可能少地去承擔邏輯，只負責渲染展現(xiàn)。當然，不要以為需求文檔就全部正確，它也可能會有錯誤，我們也應該去發(fā)現(xiàn)需求文檔的bug，然后再去協(xié)調PM，敦促FE或者RD進行修改。在這點上，不得不說，有的開發(fā)做的比較好，他會有自己的思想，在開發(fā)的時候就能發(fā)現(xiàn)需求文檔的錯誤，而有的開發(fā)則是無條件無腦執(zhí)行。

后端生成頁面，最常見的就是類似于jsp、php、python的某些前后端不分離的框架，這種比較特殊，常見于單人開發(fā)的項目，這種項目的問題排查和其他項目總的思路也一樣，只不過前后端bug的修改可能都是同一個人而已。

有時候，涉及到多方面合作，不太好測試的情況下，需要開發(fā)提供可測性支持。比如，要查看接口給另一個接口發(fā)的請求是否正確，可以讓開發(fā)打印出完整的請求log。還有一些邏輯開關、修改頁面數(shù)據條數(shù)等，都屬于可測性支持的范疇。

很多時候，bug不是代碼問題，而是tomcat配置、nginx配置、jdbc配置等的問題。在這個層面上，測試人員最好能夠了解下它們的各項配置，在發(fā)現(xiàn)問題后可能就會想到這方面的問題。

太陽底下沒有新鮮事，有經驗的人早就遇到過相同的問題。高手往往能夠一眼看穿表面現(xiàn)象內部的問題，然后直奔主題，迅速報告或者解決，留下別人在風中凌亂……

常見的可能還有構建的問題，比如代碼本身都沒錯，但是合并代碼到主干后出問題了，常見的就是代碼存在沖突時手動解決的時候。所以我之前有一段時間喜歡問開發(fā)在合并代碼時有沒有沖突，如果有沖突，那是什么地方有沖突，就得重點對待了。

另外，定位到問題后，還要考慮下具體情況，根據開發(fā)人員的心態(tài)來決定要不要告訴他具體原因。有的開發(fā)不夠open，會覺得你搶了他的飯碗。而對于open的開發(fā)，你們會因此配合的更加默契。

當然，我們在發(fā)現(xiàn)問題或者定位到問題原因后，一定要進行一步，就是再次確認問題。所謂確認問題，就是弄清楚問題是否每次都發(fā)生，還是概率事件，或者是工具相關的問題（比如換個瀏覽器是否依然出現(xiàn)？如果換個瀏覽器不出現(xiàn)的話，很可能就是前端的兼容性問題）。比如翻頁控件，我們待測的系統(tǒng)有很多頁面都有翻頁控件，那么就要看下是否每個頁面都會出現(xiàn)這個問題，進而報bug時進行統(tǒng)一說明，也更加方便開發(fā)人員批量處理，防止漏改。

以上是對問題的初步定位。對問題的進一步分析可能是更加體現(xiàn)測試人員素質的，比如你發(fā)現(xiàn)了一個問題，通過白盒測試看他的代碼，發(fā)現(xiàn)某一個分支的判斷條件寫錯了，并且把這些告訴了開發(fā)，那么他一定會給你一個大大的贊，然后說上一句，小伙子靠譜，和你合作很愉快！

下面介紹幾個常見的問題并逐一分析下。

1、點擊頁面的某個“修改”按鈕，頁面彈窗提示“unforbidden”，但需求文檔中顯示應該提示“沒有權限”，如何定位？

這個問題要看彈窗中的錯誤信息是誰發(fā)出的。如果點擊修改按鈕，前端發(fā)出了一個接口請求，而該接口的response中有“unforbidden”，那么說明前端的提示是后端返回的，那么就需要后端去修改。否則就是前端寫的提示。所以，有時候不能想當然地認為前端彈窗提示文案一定是前端的問題。具體問題具體分析。

2.修改某個表單中文本框內的文字并提交，跳轉到結果列表頁后發(fā)現(xiàn)該文本內容顯示不全，該如何排查？

這個問題的可能性有很多，我們可能需要這樣排查：首先查看下表單提交時，前端發(fā)送的請求中該文本內容是否正確，如果正確就再去數(shù)據庫中查看記錄，然后去看后端響應內容是否正確，然后去看前端渲染是否正確，以此來判斷是前后端交互的哪個環(huán)節(jié)出了問題。

可以發(fā)現(xiàn)，上面兩個案例都沒有定論，都是得具體問題具體分析。我們只要掌握了分析方法和思路，就能夠找出來到底是哪里出了問題。前端頁面所看到的所有元素以及所有數(shù)據，要么是前端返回，要么是后端返回，有問題了，就看是誰生成的返回，前端返回的就去找前端，后端返回的就去找后端，誰的孩子惹麻煩了就去找誰，前后端就靠http來通信，所以要多F12，多觀察前后端接口交互。

這只是經驗總結，并非標準。bug千差萬別，有時候需要一個一個分析。多修煉內功：對業(yè)務系統(tǒng)的掌握，測試方法以及開發(fā)技術。建設自己的bug知識庫，多思考、多積累、多總結。

最后，請謹記：對于無法確定的問題或者目前功力難以定位的問題，要交給開發(fā)，不要死磕，浪費時間。如果冒煙測試都不通過，就不要浪費時間定位了，直接打回。優(yōu)先解決項目進度問題，其次才是測試深度。