"如何快速定位bug"
  01
  定位問題的重要性
  很多測試人員可能會說，我的職責就是找到bug，至于找原因并修復，那是開發的事情，關我什么事？
  好，我的回答是，如果您只想做一個測試人員最基本最本分的事情，那么可以這么想。但是，如果您想要在測試甚至開發的道路上長足發展，就要知其所以然。
  那么，為什么定位問題如此重要？
  可以明確一個問題是不是真的“bug”。很多時候，我們找到了問題的原因，也許發現這根本不是bug。原因明確，誤報就會降低。
  找到bug原因后，可以明確地指給某個開發，防止他們打太極推來推去，提高缺陷的修復速度。
  讓開發人員能夠佩服你，提升開發對測試的信任度。
  自己在這個過程中能學到很多東西，有助于理解產品內部邏輯，對架構的理解，以及數據流是怎樣的走向。隨著對業務架構邏輯的理解，反過來又會促進對問題的定位。
  可以降低缺陷率。這個可以說是最重要的。在bug系統中，我們會要求開發人員記錄bug產生的原因。只有我們自己對bug有一個較全面的認識，才會判別出開發寫的是不是真正的原因，也才能有助于我們后續對bug進行分析歸類，根據bug分析，有針對性地未雨綢繆，進而提升產品質量，降低缺陷。
  Soo，定位問題很重要。
  接下來我們就來探討下有哪些定位問題的方法和技巧。
  02
  問題定位技巧
  首先，定位問題有一個總的思路，而這個思路是和數據的走向一致的。大致是這樣：
  首先當系統出現bug時，一定要將bug現象進行錄制保留，保留現象是為了證明這個bug出現過，如果bug是固定重現還好說，如果該bug無法重現，那么保存的截圖都是你直接證據，要養成良好的保存現場的習慣
  提BUG這塊，還是要體現出測試的專業性，標題簡潔、問題環境標識清楚、問題詳細描述清楚、系統錯誤表象貼圖、接口傳參返參貼圖、必要時貼服務器日志，總結來說不該少的bug標簽一個不要少；
  一.小型產品，前后端一人統籌
  一些小型程序，例如前后端都用node、php語言開發的，整個系統前后端是同一個開發的時候，那么小編可以自信的給你說，系統出現問題時，bug大膽的提，往猝死的提，責任人錯不了！
  二.常規系統，多人開發協同
  前置：測試之前該測試人員對系統、業務、環境部署、開發人員等較為熟悉；
  在測試之前打開對應瀏覽器的F12直接開個新頁簽，或者使用抓包工具等，系統呈現出問題時，查看對應的請求、日志信息等我們才能去全面的定位是前端還是后端人員的問題，具體給大家介紹以下幾個常用方法；
  01
  分析問題場景進行預判
  先查看頁面表象，根據問題表像判斷問題可能出現的原因，進行縮小范圍，并且準備好錄制工具，錄制問題
  系統頁面無法正常訪問的提示5開頭的找后端，4開頭的先檢查請求地址或者對應的權限，進入系統頁面正常打開，提示異常代碼錯誤的直接找后端
  進入系統頁面展示異常視頻相關提示Flash等相關信息進行安裝Flash如若還不行找前端，界面UI展示兼容性錯誤找前端
  如若系統訪問正常，進入操作頁面，功能性報錯信息，就進入下面環節，抓包查看對應請求體，看日志等
  02
  關注請求體的狀態碼
  4**開頭的狀態碼一般都是客戶端（前端）的問題；例如常見的404確認下是否是請求的地址有錯，403確認是否有權限訪問，具體可百度；
  5**開頭的狀態碼一般都是服務端（后端）問題，例如常見的500，則表示是服務器內部錯誤，503網絡過載導致服務端延時，502服務器崩潰等，具體可百度；
  03
  關注請求的入參與響應數據
  通過訪問報錯的頁面，加載錯誤請求時我們通過F12進行分析請求包，查看對應的入參以及響應數據
  例如：請求入參錯誤，那么該bug屬于前端的錯誤；入參標準可以根據前端頁面的輸入的內容或者選擇的內容，進行核驗，入參格式以及是否必填等可以對應接口文檔去進行分析或跟開發確認；
  例如：請求未響應或者響應數據錯誤，那么該bug就屬于后端的錯誤；一般是數據庫查看報錯，例如刪了某個表查詢報錯誤空指針等；
  如果請求的入參或者響應數據都沒問題，可以跟開發反饋是不是瀏覽器解析的問題，可以換個瀏覽器測試；
  04
  查看日志
  針對服務端類型的報錯，我們可以進行登錄日志平臺或者服務器對應Log目錄下查看打印出的日志；
  常用查看日志命令tail,/error進行快速檢索關鍵詞接口名等相關內容
  拿到對應的日志,將日志文件貼進bug單，指派給后端，提高專業性，測試人員也要養成看日志的習慣，看著看著就懂了；
  05
  經驗法則
  在系統前端頁面當碰見服務器配置相關報錯的信息例如Nginx***或者代碼以及SQL相關的提示報錯信息直接找后端處理，例如JAVA****、.PHP、SQL等異常報錯。
  前端字符校驗、格式校驗、等，瀏覽器界面UI兼容性以及插件，或者APP、小程序類調用手機相關功能拍照、語音無法正常調用直接找前端。
  測試人員定位問題的N+1板斧。
  1、讓BUG飛一會兒...
  碰到問題先別忙定位，首先請保存犯罪現場，并且確認能復現。然后排除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，就一定正常嗎？
  假設有這么一種情況，要測試一個翻頁控件，翻到第二頁的時候，發現內容和第1頁完全一樣，接口請求返回的是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次寫的時候有哪些困惑，并針對這些困惑，后來采取了怎樣的解決方案）
  1、編寫用例的第1步我該做什么？
  理解系統，首先站在測試的角度深入理解系統的每個功能與系統業務邏輯，畫出業務邏輯圖（即：系統能做什么）。
  其次站在用戶的角度，列出用戶使用系統的目的（即：用戶使用這個系統，想干什么？）
  2、怎樣確定用戶目標？
  不能確定用戶目標，可能由2方面原因造成:a>對系統不夠熟悉，b>不了解用戶背景。對于第1點原因，那是你自己的原因，只有回過去頭看文檔了，對于第二點原因，可以從‘系統能做什么’推算出‘用戶可以做什么’然后再總結出‘用戶可能想做什么’，當然這樣做的前提是你對系統已非常熟悉。
  3.這個月我將做什么？
  剛進入測試行業是怎樣總結的（利用測試管理工具進行總結）：
  把測試管理工具中的缺陷全部分類導出，總結一下哪些模塊容易產生哪些缺陷，重點看一下自己是否有未發現或沒考慮到的缺陷。
  如果說測試新人的第1層次是從執行用例開始，那么第二層次就是編寫測試用例了。把測試管理工具中的用例詳細看幾遍，學習別人的用例編寫方法和思想，空閑時間可以自己試著編寫，看自己編寫的與別人編寫的用例差距在哪，從而不斷完善。重要說明；著重用例編寫方法和思想的學習，而不要死搬硬套。
  多進入一些測試討論群，將自己的困惑和經驗和大家一起分享交流，在學習中，不斷進步。當然了有疑惑的地方也可以來咨詢小編和我們親愛的樂哥！
  總結：
  正所謂功夫在詩外，測試理論知識就是那么多，理論知識掌握之后就要不斷的參與到項目中來，一個一個項目的練習，鍛煉自己的發現Bug的能力，就算隨機測試，一個好的測試和一個壞的測試，他們發現問題的能力也是完全不同的。以上完全是個人的一點體悟，各位看官，看的時候也請多多指教。