一、前后端使用架構導致

　　前端使用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中了。

總結

以上是生活随笔為你收集整理的Bug产生原因的深入分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。