常見bug分類

作為測試新人，很多學員在工作中不知道從哪裡進行下手進行測試，即使發現了問題也不確定是不是bug，從而導致非問題、重複bug等現象，現根據測試過程中比較常的問題進行分類，並針對這些問題怎樣進行驗證提出了相關的參考辦法，相信能幫到剛入職不久的你開啟思路：

一、功能性問題

當需求進行分析與評審後，系統都具備什麼樣的功能，測試人員都一清二楚，不管有沒有進行冒煙測試，功能問題都是我們最容易發現且最沒有疑問的問題。具體的問題體現要依具體的需求文件而定。

參考辦法：《需求設計文件》

二、相容性問題

不管是B/S構架還是C/S架構，在測試過程中都會做大量的相容性測試，雖然進行相容性測試的時間不一樣（有專門留時間段進行相容性測試，也有在功能測試的過程中同步進行），但相容性測試始終是測試內容中的一大塊，比如：按鈕位置不對、文字顯示不全、提示彈框出錯等都是比較常見的相容性問題。

參考辦法：用多種不同的瀏覽器版本進行驗證

三、易用性問題

所有的測試問題中，最有爭議的莫過於易用性問題，易用性本身就是從方便與合理兩個角度測試的，因此會因個人習慣與專案整體風格而產生的不同的意見，加上不涉及功能，往往這類問題也是走評審最多的。比如，導航按鈕位置不合理、進行某步操作後沒有給出明確的提示資訊等。

參考辦法：走評審、做競品分析

四、資料庫問題

資料庫問題最直觀的體現就是介面給出的類似”資料庫異常”的提示，或是寫資料寫不過去，這種問題，要考慮資料庫所在的機器是否正常，配置是否正確，連線程式是否正常執行等。

參考辦法 ：日誌

五、儲存過程問題

都說在測試行業做手工測試太久的話，很容易被人取代，也找不到測試的樂趣，這是事實，因為不光技術的層面上不去，就連發現的問題也不太讓人信服了，比如儲存過程的問題，跟以往透過bug的出現再去檢視日誌協助定位不同，一般都是建議透過日誌檢視呼叫是否正常再去驗證前臺資料，當然，不是說不能透過前臺現象確認儲存過程的問題，只是反過來更簡單一些。從日誌可以看到呼叫的儲存過程，傳遞的引數個數、位置、範圍，因此，對業務與說明文件足夠熟悉的話，可以脫離介面從而測試呼叫下發這個環節。比如：透過動態日誌監控某個介面呼叫的儲存過程中，下發的引數跟介面選擇不符。

參考辦法：資料庫欄位說明

六、效能問題

效能測試比功能測試介入的晚，一方面是由於功能不穩定不適合進行效能測試，一方面也是因為效能問題往往改動比較大。由於效能測出現的問題大多都是比較大的問題，且涉及的面比較廣，因此對於專項做效能的測試人員與開發人員都有比較廣的技術面的要求，往淺了說，簡單的穩定性測試（保持長時間向伺服器傳送請求）也是每個專案都必須進行的。比如，往伺服器加壓的過程中，某核心元件異常斷掉，或是因為請求未合理排隊而導致伺服器掛死等。

參考辦法：檢視日誌、減壓定位

七、設計錯誤問題

雖然需求分析時針對很多特定的場景有評審過，但還是避免不了在週期中，很多因為設計錯誤而產生的bug，這些問題要看具體的業務的設計與應用場景。往往認為最沒有疑問的，但是由於應用場景不一樣視為缺陷的場景並不少見。比如，專案中只要涉及許可權就會有角色，但是有些專案中的管理許可權是透過角色來限制，而有些則還是透過使用者來管理。

參考辦法：參考專案背景與適用場景、評審

八、外部條件問題

為什麼需要進行測試，通俗來講只是讓產品能適應不同的人在不同的環境做不同的操作。作為測試人員，只是在上線前充當這過程中需要的人而已。

測試過程中，為了看部件或系統的容錯能力，除了正常的功能測試外，也會做相關的“暴力測試”，比如，斷網，斷電。

參考辦法：測試前後的資料對比、測試後的資料驗證

九、資料同步問題

這類測試往往在做手工測試時不易察覺，需要接觸介面測試或是效能測試後才能想到更深的同步問題。隨著現在對伺服器的釋壓，分散式是我們比較常見的一個詞，不管是對伺服器還是部件，甚至是業務層面，都會涉及到同步的問題。比如，在已知資料的基礎上驗證相關業務，發現資料對不上，排查了功能問題及誤操作外，就要透過其它方式，比如時間，去驗證是否是同步的問題

參考辦法：檢視日誌、透過介面測試驗證

十、需求理解問題

雖然這種問題不常見，但現實告訴我們，儘管有對需求進行評審，但是在測試過程中還是避免不了會存在需求理解錯誤的問題，當然這種問題不佔大多數。

參考辦法：需求文件、評審

不管是哪類bug，需求熟悉、業務熟練是根本，再就是流程與配置，只有熟悉了這些，遇到問題時，才能有辦法去進行驗證與定位，從而累積經驗，在測試的道路上越好越順！