在日常項目開發中，異常拋出和捕獲是再平常不過的事情。通過try-catch我們可以方便的捕獲異常，同時通過查看異常堆棧我們能發現拋出異常代碼的位置。 例如下面這段代碼： 這段代碼非常簡單，運行后他拋出了如下異常： 沒有問題，堆棧信息明確指出了拋出異常的位置 ...

一、monkey事件類型 數字 對應量 解釋0 ...

如何去區分一個功能測試工程師的水平高和低？ 可以從很多個方面去檢查，比如測試的思路， 比如測試用例的覆蓋度？，比如測試出bug是否能夠定位到根因？ 上面說的各個方面都很合理，那我們平常如何如更深的定位問題的根因呢？ 1、通過我們的測試的經驗 這個有點不容易掌握，也不容易 ...

問題：工作生活中常見的現象 　　 調試和排查步驟 1、確認一下域名解析的問題?是否可以解析成對應的IP--- DNS -- 重點 2、Ping或者telnet這個IP確實連接是否可達? 3、tracert跟蹤，確定哪個節點出現問題。 4、不可達，服務器是否開機?服務是否開啟 ...

【問題描述】 數據庫連接異常是很難排查的一類問題。因為它牽涉到應用端，網絡層和服務器端。任何一個組件異常，都會導致數據庫連接失敗。開發遇到數據庫連接不上的問題，都會第一時間找DBA來協助查看，DBA除了需要懂得數據庫以外，還需要對應用，對網絡有所了解，知道在哪里看應用程序的日志，以及看網絡交換機 ...

一、引子 這要從線上的一個接口偶發異常耗時說起，事情往往不是你想象的樣子，尤其是在排查問題的時候，切忌有先入為主的的某些判斷。 二、問題： 接口監控圖：顯示每天總會有那么幾次耗時特別長的請求。 三、排查： 1、直觀的認識是“偶發”，每天零星的幾個，不規律。 對於這種情況，第一感覺 ...

日常Bug排查-拋異常不回滾 前言 日常Bug排查系列都是一些簡單Bug排查，筆者將在這里介紹一些排查Bug的簡單技巧，同時順便積累素材_。 Bug現場 最近有人反映java應用操作數據庫的時候，拋異常不回滾。這還了得，不過筆者篤定肯定是用法的鍋，不然就全亂套了。所以筆者去Review ...

一般來說bug大多數存在於3個模塊： 1、前台界面，包括界面的顯示，兼容性，數據提交的判斷，頁面的跳轉等等，這些bug基本都是一眼可見的，不太需要定位，當然也不排除一些特殊情況，本身數據傳過來的時候就有問題，所以顯示會出問題的情況（這個后面會說到）。 2、后台程序，包括前台調用的接口 ...