測試分析

測試分析

一．定位bug的重要性：

1. 能夠確認發現的問題是否是真的問題。不少時候，咱們找到了問題的緣由，也許發現這根本不是bug。緣由明確，誤報就會下降。

2. 找到bug產生緣由後，能夠明確地指個某個開發，提升缺陷的修復速度。

3. 下降缺陷率。會讓咱們本身對bug有一個較全面的認識，也有助於咱們後續對bug進行分析歸類，根據bug分析，有針對性地未雨綢繆，進而提高產品質量，下降缺陷。

二. 問題定位技巧：

用戶層面問題 -> Web頁面/軟件界面 -> 中間件 -> 後端服務  -> 數據庫

1. 用戶層面問題：指的是用戶本身的環境問題或者操做問題，好比環境不通，或者操做不正確。

2. 在Web頁面進行正常操做時，也可能會發現問題。這類問題通常經過觀察以及利用一些常識能夠發現，好比樣式問題。Web頁面操做後，好比發出一個請求，可能會進入中間件這個層面。我這裏說的中間件是廣義上的，好比LVS、CDN、各類緩存服務器等等。

3. 服務會轉發到咱們真正的後端服務層，web服務器、應用服務器好比nginx、tomcat會收到請求。若是發現內存溢出，那麼就可能會定位到是tomcat配置的問題；若是請求返回404，也多是nginx配置不當。

4. 數據庫層面的：可能少某個字段，或者字段值爲空等等，這些可能在設計數據庫時就埋下了錯誤的種子，致使程序調用數據庫錯誤的數據產生bug，這一類問題不算廣泛，但也是最容易忽視的一種狀況，有時候從數據庫入手定位bug說不定還能發現數據庫的設計缺陷呢。

5.網絡層面的：一般這種都是網絡狀況較差的時候產生的，好比手機的移動網絡信號很差，又或是公司網絡不穩定，致使js/css未加載徹底或者請求超時等等，這種問題其實非程序bug形成的，能夠不用提交bug，也不用讓開發毫無頭緒的去查代碼的問題。固然若是能夠的話也能夠當優化建議提給開發，讓他優化代碼，好比壓縮js/css，增長超時時間，超時後的重試機制。

三．關於測試人員定位問題：

1. 碰到問題先別忙定位，首先記錄操做步驟，而且確認能復現。而後排除是，網絡不通，以及操做姿式不正確等等。還有一類問題就是髒數據，咱們有時候會遇到服務端報錯誤，查看日誌後，報空指針，那麼頗有可能就是數據庫中關聯表的數據被人爲刪掉致使的。還有的問題是因爲工具的影響致使的，因此發現問題別慌，確認不是本身的問題再說。

 

2. 4xx狀態碼通常表示是客戶端問題（固然也有多是服務器端配置問題），好比發生了401，那麼要看下是否帶了正確的身份驗證信息；發生了403則要看下是否有權限訪問；404則要看下對應的URL是否真實存在。而5xx通常表示服務端問題。好比發生了500錯誤，則代表是服務器內部錯誤，這個時候要配合服務器log進行定位；發生了502則多是服務器掛了致使的；發生503多是因爲網絡過載致使的；發生504則多是程序執行時間過長致使超時。

 

3. 看服務器日誌，若是發生5xx問題，或者檢查後端接口執行的sql是否正確，咱們最多見的排查方法就是去看服務器日誌好比tomcat日誌，開發人員通常會打出關鍵信息和報錯信息，從而找到問題所在。測試人員要養成看日誌的習慣。

 

4. 有時候，前端和服務端的交互都正確，可是從測試的角度看不合理。這個時候，咱們應該翻翻需求文檔（若是沒有的話，就直接拋出這個問題）。若是和需求文檔不符，那麼就要看下誰改合理，是前端改，仍是服務端改，或者二者都得改。這裏有一個原則，就是前端儘量少地去承擔邏輯，只負責渲染展示。固然，不要覺得需求文檔就所有正確，它也可能會有錯誤，咱們也應該去發現需求文檔的bug，而後再去協調PM，敦促FE或者RD進行修改。

 

5. 固然，咱們在發現問題或者定位到問題緣由後，必定要進行一步，就是再次確認問題。所謂確認問題，就是弄清楚問題是否每次都發生，仍是機率事件，或者是工具相關的問題（好比換個瀏覽器是否依然出現？若是換個瀏覽器不出現的話，極可能就是前端的兼容性問題）。好比翻頁控件，咱們待測的系統有不少頁面都有翻頁控件，那麼就要看下是否每一個頁面都會出現這個問題，進而報bug時進行統一說明，也更加方便開發人員批量處理，防止漏改。