身為測試工程師，總有一道繞不過去的坎就是定位bug，這其實是非常花費時間的。

也許有很多人不以為然，覺得無非就是發現bug后提交bug管理系統，描述操作步驟，預期結果和實際結果哪里不一致，然后繼續測試。并不是說這樣做的不對，只是說這樣做的不夠好，看似節約了測試時間，實則對于項目的進度沒有起到應有的推動作用。

一、web前端

• Web前端就是通常說的網頁。互聯網公司的前端一般包含如下內容：JavaScript、ActionScript、CSS、HTML(..ML)、HTML5、Flash、交互式設計、視覺設計
• web前端測試可能發現的問題——版面設計、交互設計、文字、性能、功能
• bug定位通用思路：現象-->原因-->驗證手段-->結論-->現象

測試bug定位原因歸類：

測試環境相關

• 是否安裝了flash及flash的版本——可能導致部分頁面顯示出問題，目前常用的版本誒flash10
• 是否開啟了瀏覽器插件——插件可能導致瀏覽器行為的變化，除非測試要求，否則一律禁用插件
• 是否開啟了安全軟件——可能會截包、彈窗攔截、防釣魚等

瀏覽器相關

• 不同瀏覽器的支持標準——不同內核的瀏覽器對js及各種標準的支持不同，因此頁面解析出來的效果可能不同。Firefox：gecko；Chrome：webkit；IE：trident；Safari：webkit。
• 瀏覽器的設置——禁用js；禁用彈窗；禁用cookie等
• 瀏覽器cache策略——js，css，圖片等都有可能被cache住。ctrl+F5強制刷新請求
• cookie——跨域，過期

網絡相關

• 是否發出了正確的請求——請求url、參數變量。content數據
• 是否得到了正確的應答——http的返回值：200-正確；302-對象已移動；304-對象未修改；404-沒有找到頁面。返回的數據體
• 是否性能問題——異步請求的數量過多；網速過慢

字符編碼相關

• 頁面亂碼——百度后端存儲基本是使用的GBK編碼，前端提交可能是UTF-8編碼，后端對于非GBK編碼一般采用實體存儲。可能出現編碼沒有轉換。轉換的時候沒有判斷半個漢字（轉掉了半個漢字導致雪崩）。
• url錯誤——url路徑中漢字編碼使用的是utf-8編碼，參數中使用系統默認編碼，flash腳本中使用的都是uft-8編碼。

安全相關

• Xss漏洞——輸入一些特定字符頁面出現錯亂或有惡意代碼被執行，RD未對特殊字符轉義完整

性能相關

• 圖片數量——頁面中同一個域的圖片的數量控制在16個以下，IE會控制同一個域下圖片并行的下載數量
• 頁面抖動——異步請求的數量過多
• 加載失敗——限速情況下，超時

bug定位常用工具

• Firefox——firebug、web developer、live http headers、http fox
• IE插件——httpwatch
• 第三方工具——fiddler、charles
• 慢速網模擬工具——firefox throttle、fiddler、charles

二、web后端

• 后端包含運行在服務器上的程序，腳本和服務。比如：各種各樣的邏輯處理系統，數據存儲系統等。
• 后端可能發現的問題——邏輯的，數據的，策略的，接口的，性能的等

測試bug定位原因歸類：

數據流相關

• 上下游模塊是否連接正常——模塊的ip和端口的配置，白名單黑名單配置，session授權
• 模塊的數據發送接收是否正常——日志是否有滾動，是否顯示發送了數據或接收到數據，數據是否完整，跨機房，負載均衡算法（從哪些機器獲取到的數據）
• 非socket的數據傳輸——共享內存（是否分配，key的配置等），cache（是否創建，臟數據等），數據庫（配置，連接，表，觸發器，存儲過程），文件（大小，訪問權限）
• 模塊之間的接口——協議的一致性（mcpack1，mcpack2等），字段的一致性（一個按signed解析，一個按unsigned解析），字段復用

處理邏輯相關

• 程序的各種配置——功能是否開啟/關閉，詞表是否加載，各種閾值的配置，超時配置
• 程序日志——日志級別，交互的流程，處理的流程
• 各種邊界——數據邊界（int，long），文件邊界（空文件，分文件的邊界），時間邊界
• 各種資源并使用——Cache是否遺留臟數據，并發和死鎖

系統和環境相關

• 系統資源——Cpu，io，句柄，內存，網絡狀態，數據庫狀態，數據庫連接數
• 環境資源——程序版本，內核版本，網絡(外網)訪問權限，系統動態庫不一致

程序和代碼相關(常用驗證手段)

• 確認問題出現的位置——日志中的代碼行，gdb中的代碼行，拋出異常顯示的代碼行
• 獲取當時的運行時信息——Gdb core文件，gdb attach到進程，查看堆棧，查看寄存器，設置breakpoint，watchpoint，查看內部數據
• 獲取程序和系統信息——Strace查看系統調用，系統狀態獲取（ps，top，/proc/pid/*，vmstat，netstat）
• 更深入的手段——反匯編，查看寄存器，gdb高級應用

后端測試bug定位

日志查看命令

• ????????查看壓力——tail -f as.log | grep '^NOTICE' | awk '{print $3}' | uniq -c
• · 排除日志中的特定內容——grep -v 'pattern' as.log
• · 只輸出感興趣的內容——grep -o 'proctime:toal:\d+' as.log；grep -o 'proctime:toal:\d+' as.log | grep -o '\d+ '；grep -o 'proctime:toal:\d+' as.log | grep -o '\d+ ' | sort -n | uniq -c
• · 將wf日志歸類——grep -o '\w+\.(cpp|h):\d+' as.log.wf | sort | uniq -c

gdb常用命令

• bt——查看堆棧信息
• print——打印某變量值
• break——設置斷點
• x/i——翻譯當前指令為匯編
• info thread——查看所有線程，星號*標記的是當前線程
• thread num——切換到線程號為num的線程
• set scheduler -locking on——鎖定在線程：輸入continue命令以后，當前線程繼續執行，其它線程不執行
• set scheduler-locking off——這是默認設置，輸入continue命令以后，所有線程都繼續執行

三、性能測試

• 旨在獲取系統在特定一種或多種環境下，在不同的外部輸入壓力(包含極限)的條件下的系統各項指標的測試

常用命令

• 進程相關——ps，top，/proc/pid/*
• 系統相關——vmstat,top,iostat,sar,df,lsof
• 網絡相關——netstat

bug定位原因歸類

壓力工具相關

• 工具的功能和性能——能否達到預期壓力，啟動壓力的機器性能，壓力工具是否有異常連接關閉，壓力工具如何處理異常，長連接短連接，并發的個數
• 工具運行環境——壓力機器的帶寬，是否跨機房
• 被測系統相關
• 機器性能——系統所在機器性能，機器網絡帶寬，機器的內存，sd卡，硬盤
• 系統本身——系統的下游模塊的性能，系統的配置，系統的數據量，系統的特點狀態（充cache，dump，merge），系統的部署，程序的bug

環境相關

• 操作系統相關—— 是否和線上一致，內核版本，刷臟頁時間，有沒有調用directIO
• 查看系統狀態——Ps,top,/proc/pid/*, vmstat,netstat

正確的思路+豐富的業務知識+豐富的技術背景知識+較好的調試和開發能力= 強大的bug定位能力Bug定位的過程是能力提升的過程。