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