我是一名開發
在咱們開發的時間中,其實coding的時間所佔比例大概為30%,大部分時間都在自測和改bug
但是許多新人覺得coding才是最重要的,而且把大部分精力花在coding上,其他的(自測,改bug,重構)不太重視
自測和改bug,歸根結底就是解決問題.
解決問題的第一步,就是了解問題的現象,這是前提.
所以我們解決bug時,經常提到的乙個詞就是"重現bug",不能重現的bug,我們是沒法改的.
那麼重現bug之後,我們應該做些什麼呢?
有的人一上來不管三七二十一就去看**!這太衝動了!
因為有可能根本不是**的問題!
比如可能是url位址不對,或者傳入的引數不對,或者伺服器壓根沒有啟動,或者斷網了,等等
所以看**只是最後沒辦法的行為.看**是最後一步.
那麼不馬上看**,我們要做什麼呢?
首先,我們要排除最基本的錯誤:
(a)url 位址是否正確
(b)引數是否正確,是否缺少引數
(c)埠號是否正確
(d)使用的協議是http還是https
(e)伺服器是否已啟動(伺服器狀態對不對)
(f)執行的git分支是否正確(本來是在develop上修改的,結果執行的是master分支)
(g)網路環境是否正確,是集測,**,還是線上
然後,猜測可能的原因,把最有可能的原因列出來,然後按照優先順序驗證
再次,採用單一項原則,保證只有乙個因素是變數,其他因素都排除掉或者定死.
還有乙個原則:能細粒度測試的就細粒度測試
什麼意思呢?
比如在乙個專案裡面有個bug,然後你也定位了bug相關的**
那你怎麼解決呢?
一般的新人,就會執行整個專案,搭建環境,啟動tomcat,從註冊開始,一步步執行下去....
其實就為了驗證其中乙個很小很小的環節.
所以這種方法可行,但是成本非常高.
如果是我,會怎麼做呢?
我絕對不會執行整個專案,而是把bug相關的**摘出來,然後建乙個非常簡單的頁面或非常簡單的工程來研究.
這樣有3個好處:
(1)避免了不相關模組的影響
(2)速度快,因為我只是乙個頁面或者乙個非常簡單的專案(隨手建立的)
(3)符合單一項原則
單一項原則,請參看:
下面列舉幾個實際經歷的案例
(a)前幾天,測試同學說在ie9中下單頁顯示有問題,服務項單位沒有顯示云云.
於是我讓靜態頁面同學去看,我並沒有馬上去.
過了一會兒,我去了測試同學那裡,靜態頁面同學說,有個樣式得改.
我讓她起來,我來看下.
我開啟ie 的開發者介面(按f12),看瀏覽器,發現瀏覽器的文件模式是ie7.
問題解決:咱們壓根不支援ie7
(b)做t+**時,為了改個東西,給乙個dto增加了有參的構造方法,但是沒有加上 無參構造方法,當時覺得沒有必要.
然後測試同學就給我報了bug,訂單列表報錯
後來,我一步步排查,發現是我增加了有引數的構造方法導致的.
因為dto 反序列化時需要無參構造方法
參考:
Android APP開發自測點
功能完成後，自測時的檢查點 1.思考某些情況下，某個變數是否會造成空指標問題 2.把手機橫屏，檢查布局是否有bug 3.在不同解析度的機型上，檢查布局是否有bug 4.切換到英文等外文本型下，檢查外文是否能完整顯示 5.從低版本公升級上來，會不會有問題，比如可能會出現資料庫不相容的問題 6.按下ho...
開發自測模式實踐
背景 長期以來業務線測試有這種困擾 業務線傳統的專案流程把開發 測試兩個階段分得比較明顯，導致開發趕時間寫 提測階段測出一些低階bug 重新返工不僅測試時間延長，也導致開發 測試同學都累。在天彤的支援下，本人今年3月份來到c2b市場團隊輪崗開發，實踐了開發自測的專案模式。這是乙個新產品團隊，新模式比...
開發自測？開發與測試的戰爭
做測試的都會遇到過 開發提交的版本質量太差！開發人員提交測試後發現大部分主要功能都不通，後續告知修復完成，測試人員又去驗證，結果還是大部分功能不通，這樣的效率實在讓人無法忍受。開發自測自然在測試人員心 現！質量的提公升不只是測試團隊的事情，這句話貌似都在說，跟在喊口號一樣，並不能帶來實際的效果。開發...