1. 程式人生 > >bug產生原因分析

bug產生原因分析

目錄

一、前後端使用架構導致

二、開發人員經驗問題/思維嚴謹性導致

三、業務特點導致

四、測試人員的經驗缺乏導致

五、迭代週期不合理導致

六、上下游業務嚴重耦合導致


前言

          產生bug的具體原因或許多種多樣,但在bug原因分析過程中,希望能抽絲剝繭,找出其產生的根本原因。之前寫過如何減少線上故障典型故障分析故障的坑,你踩了多少遍等等,如果能結合起來看線上、線下的bug,或許會對bug產生的原因有不一樣的認識。

一、前後端使用架構導致

前端使用es7+react+node使用,在開發方面增大了工作量:

封裝元件;

多個模組公用元件,導致改動一個功能點,改壞其他模組;對測試的影響就是,該一個模組,需要回歸其他涉及的多個模組哦

後端屬於大資料基礎上做各種條件篩選,在具體實現上採用了“重記憶體”方案,即:

1、將資料定時更新到記憶體中;

2、在記憶體中做多條件的篩選;

帶來的問題就是:

1、 fullgc問題 導致需要大記憶體伺服器;

2、定時資料更新機制,常常發現一個介面多次篩選返回的資料不一致;

二、開發人員經驗問題/思維嚴謹性導致

此類問題和經驗、或每個開發人員的合作、做事風格有很大的關係,具體問題包括:

1、前後端預設引數約定

2、前端傳參

3、需求點沒有實現

4、“顯而易見”的主功能沒有實現

三、業務特點導致

         每一個業務除了公共的業務特點外,還有各自獨特的業務特徵。例如,前端業務與純後端業務側重點有很大不同,而APP端的前端業務與web的前端業務又有很大的不同。反應到具體產生的bug上,無論是bug的數量,還是bug本身的隱藏深度,都有很大的不同。

四、測試人員的經驗缺乏導致

         這裡不必多說了,測試方案制定的完整性和深度,甚至測試執行層面的經驗,都決定了究竟有多少bug可以被暴露出來了。

五、迭代週期不合理導致

         這裡涉及團隊所有成員對迭代速度和規模的接受程度了。一個過度追求迭代速度的團隊,整體上會犧牲一些產品質量了。

六、上下游業務嚴重耦合導致

         這裡舉一個實際的使用者實際使用場景先後涉及的業務方: 

                                    業務B--->業務A--->業務B

        在這裡業務A與業務B嚴重耦合起來了,導致在實際的專案中,測試業務A的同學常常非常被動:

  • 需要業務B同學造若干場景,需要反反覆覆的溝通
  • 資料來自業務B,而其測試環境非常不穩定,又需要反反覆覆的溝通
  • 業務B的改動,需要業務A來回歸,但業務A同學又沒有比較好的途徑瞭解其改動,只能“盲測”

         在若干次反反覆覆的迭代中,記憶猶新的一件事情: 業務B修改了某個邏輯,結果出現了線上故障,卻反過來問業務A的同學,為什麼沒有發現。這種哭笑不得的場景,或許是最為嚴重、切業務方不可控的因素了。經過反反覆覆的“血淚史”後,終於在一次架構調整中,把業務A歸併到了業務B中了。