Bug到底是怎么產(chǎn)生的？為什么就是控制不了？

相信每一個軟件測試工程師都有一個疑問：Bug到底是怎么產(chǎn)生的?為什么就是控制不了?我們今天就來深入探討、分析下這個問題。

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

一、前后端使用架構(gòu)導(dǎo)致

前端使用es7+react+node使用，在開發(fā)方面增大了工作量：封裝組件;

多個模塊公用組件，導(dǎo)致改動一個功能點，改壞其他模塊;對測試的影響就是，該一個模塊，需要回歸其他涉及的多個模塊哦。

后端屬于大數(shù)據(jù)基礎(chǔ)上做各種條件篩選，在具體實現(xiàn)上采用了“重內(nèi)存”方案，即：

1、將數(shù)據(jù)定時更新到內(nèi)存中;

2、在內(nèi)存中做多條件的篩選;

帶來的問題就是：

1、 fullgc問題 導(dǎo)致需要大內(nèi)存服務(wù)器;

2、定時數(shù)據(jù)更新機制，常常發(fā)現(xiàn)一個接口多次篩選返回的數(shù)據(jù)不一致;

二、開發(fā)人員經(jīng)驗問題/思維嚴謹性導(dǎo)致

此類問題和經(jīng)驗、或每個開發(fā)人員的合作、做事風(fēng)格有很大的關(guān)系，具體問題包括：

1、前后端默認參數(shù)約定

2、前端傳參

3、需求點沒有實現(xiàn)

4、“顯而易見”的主功能沒有實現(xiàn)

三、業(yè)務(wù)特點導(dǎo)致

每一個業(yè)務(wù)除了公共的業(yè)務(wù)特點外，還有各自獨特的業(yè)務(wù)特征。例如，前端業(yè)務(wù)與純后端業(yè)務(wù)側(cè)重點有很大不同，而APP端的前端業(yè)務(wù)與web的前端業(yè)務(wù)又有很大的不同。反應(yīng)到具體產(chǎn)生的bug上，無論是bug的數(shù)量，還是bug本身的隱藏深度，都有很大的不同。

四、測試人員的經(jīng)驗缺乏導(dǎo)致

這里不必多說了，測試方案制定的完整性和深度，甚至測試執(zhí)行層面的經(jīng)驗，都決定了究竟有多少bug可以被暴露出來了。

五、迭代周期不合理導(dǎo)致

這里涉及團隊所有成員對迭代速度和規(guī)模的接受程度了。一個過度追求迭代速度的團隊，整體上會犧牲一些產(chǎn)品質(zhì)量了。

六、上下游業(yè)務(wù)嚴重耦合導(dǎo)致

這里舉一個實際的用戶實際使用場景先后涉及的業(yè)務(wù)方：

業(yè)務(wù)B--->業(yè)務(wù)A--->業(yè)務(wù)B

在這里業(yè)務(wù)A與業(yè)務(wù)B嚴重耦合起來了，導(dǎo)致在實際的項目中，測試業(yè)務(wù)A的同學(xué)常常非常被動：

需要業(yè)務(wù)B同學(xué)造若干場景，需要反反復(fù)復(fù)的溝通

數(shù)據(jù)來自業(yè)務(wù)B，而其測試環(huán)境非常不穩(wěn)定，又需要反反復(fù)復(fù)的溝通

業(yè)務(wù)B的改動，需要業(yè)務(wù)A來回歸，但業(yè)務(wù)A同學(xué)又沒有比較好的途徑了解其改動，只能“盲測”。

在若干次反反復(fù)復(fù)的迭代中，記憶猶新的一件事情：業(yè)務(wù)B修改了某個邏輯，結(jié)果出現(xiàn)了線上故障，卻反過來問業(yè)務(wù)A的同學(xué)，為什么沒有發(fā)現(xiàn)。這種哭笑不得的場景，或許是最為嚴重、切業(yè)務(wù)方不可控的因素了。經(jīng)過反反復(fù)復(fù)的“血淚史”后，終于在一次架構(gòu)調(diào)整中，把業(yè)務(wù)A歸并到了業(yè)務(wù)B中了。