接口測試:如何定位BUG的產生緣由

轉自公衆號《QA之道》

 

咱們從在平常功能測試過程當中對UI的每一次操做說白了就是對一個或者多個接口的一次調用，接口的返回的內容(移動端通常爲json)通過前端代碼的處理最終展現在頁面上。http接口是離咱們最近的一層接口，web端和移動端所展現的數據就來自於這層，那麼咱們如何知道在測試過成功UI上的每一次點擊都觸發調用了那些接口呢？請在下面的場景中找答案。

以下場景：

你負責測試某一個電商網站一個用戶的訂單列表功能，測試過程當中你發現頁面上展現的訂單數量與實際數據庫裏的數量不一致，請你們結合本身平時的工做方式回憶下如何快速的定位該問題是否是BUG或者BUG產生的緣由是什麼。

下面說下我認爲比較合適的定位方式：
一、 用chrome瀏覽器打開你正在測試的項目 F12打開開發者工具，切到network 標籤，訪問訂單列表頁面，以下圖

抓取到展現訂單列表的接口，能夠看出本次請求一共傳遞了9個參數，此時打開RD提供的接口文檔確認須要傳遞的參數是否傳遞的正確，或者參數個數一致，若是不正確，那能夠判斷是前端的Bug。
有人說若是沒有接口文檔怎麼辦？能看得懂代碼的直接去看這個接口的定義或者實現，看不懂的就只能找後端開發去確認了
二、 點擊Response標籤將標籤內的內容複製出來，問了更好的查看能夠將其粘貼到格式化json的工具上（若是返回類型是json）工具地址：http://json.parser.online.fr/，而後查看這裏面展現的記錄數是否是跟UI上展現的一致，若是不一致能夠判斷是前端的Bug

 

三、 若是上一步沒有問題，請打開系統的debug日誌，獲取訂單的操做說白了最後落到數據庫層面就是一條帶條件的select 查詢語句，咱們從日誌中能夠獲取到select 語句的參數，這個參數通常狀況下就是在調用接口時傳遞的那9個，此時抓取到本次接口調用產生的sql語句而後放到數據庫客戶端上執行，分析查詢條件和執行結果的關係，這個過程就是找出錯誤參數的過程。相似的debug日誌以下：

從截圖能夠看出有一些select 語句如：select * from model where id = ? 

總結：測試過程遇到問題時先別急着喊開發，先本身有個初步的判斷，或者直接定位到Bug產生的緣由，這樣既能夠減小一些沒必要要的溝通還可讓開發直奔Bug的產生緣由，提升問題的解決速度。