如何發現更深層次的bug? bug管理
看到有位冤家說測試人員應當發明更深檔次的bug，沒有指出如何做，我這里彌補下，不對之處見諒。
在咱們日常的測試運動中，單純的功用界面測試(黑盒測試)發明的缺點質量不高，即便發明了，也很少能從基本上去定位，這樣的bug提交上去，給咱們的研發共事修復帶來了艱難，同時也不利于進步咱們本身的才能。這里我介紹一下個人的經歷。
2、在發明問題后，不要馬上就想著提交bug，應當做下記載，而后本人嘗試著去剖析這個問題發生的起因，比方看一下源代碼，有些問題測試人員是能夠本人定位的，只有本人確認了，提交上去的bug質量會更高。比方，履行搜尋的時分，輸出某個字段值，沒有搜進去，檢討代碼后，發明sql語句并未履行，這時，咱們再提交bug，描寫里能夠詳細到那個頁面文件，那個源代碼，研發共事定位也不便，共事也對咱們的技巧才能熟悉上有轉變。
3、假如測試環境帶有控制平臺，比方tomcat，jboss，weblogic等等，都有控制平臺，那么咱們測試的時分，不只僅須要關注前臺的頁面體現，還要看監控平臺上的信息日志。有些體系對同伴頁面做了解決，咱們在發明這類問題的時分，頂多將解決過的同伴頁面寫到bug中，基本的起因能夠無法得悉，其實咱們能夠應用控制平臺獲取真正的同伴起因，寫到bug中。 軟件測試
4、聯合數據庫進行測試，個別流程性的測試，最主要的就是數據在數據庫中的狀況變更。比方挪動的名目，很多是異步的，光從頁面是看不到后果的，所以咱們能夠聯合數據庫進行測試，弄清晰數據在數據庫中的流轉流程，這樣才能發明更深層的bug，當然須要咱們控制數據庫的運用，尤為主要要的是sql語句。舉個例子，進行增加操作的時分，增加實現后沒有反映，能夠有兩種狀況，第一，增加基本未勝利，第二，增加勝利了，沒回顯進去，那么咱們能夠通過sql查一下增加的數據，假如數據庫中有了，就解釋回顯出了問題，假如沒有，就解釋insert 出了問題。
5、能夠檢討體系的日志檢討測試歷程中的問題。所有異樣都須要關注。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
