相信每一個軟體測試工程師都有一個疑問：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中了。

這個問題問的好，身為程式設計師，看到這個問題，完全忍不住想要站出來說兩句。就像之前看到一個問題:為什麼會有程式bug，程式設計師不能一次性寫好嗎？

1.公司商務大佬，透過調查或者自身產生想法，想要開發一款程式；或者接到其他公司，也就是客戶提出的想法，要開發一款程式。

2.公司產品大佬，透過與程式提議者溝通，確定具體細節，到底要做一個什麼樣的程式，整理成文件，也就是所謂的需求調研。

3.開發大佬，產品確定需求後，將整理的需求文件發給開發人員，開發參照文件進行開發。

4.測試大佬，程式開發完成後，肯定不會直接提供給客戶或者拿出來用，而是先要經過公司測試進行完整的程式測試，確保沒有問題了再對外提供出來。

綜上來看，一款程式從最初提出想法，到最終開發出來，是有一系列步驟的。就產品傳遞給開發這一步，就有可能發生很大變化。最終，客戶想的是這種，開發出來是那種，或者客戶在開發過程中又有了新的想法，就是所謂的需求變更，這就導致程式總是不能按照既定的路線發展。

當然，上線後也會有問題，有個很經典的比方:為什麼有人在使用高壓鍋的時候會發生爆炸？明明廠家已經多次按照說明測試過沒問題的，但，你沒想到的是，客戶不一定按照說明書來操作，所以……

需求設計，架構設計，程式碼規範產生的，開始需求不完善，或需求高大上，做出來之後，又要修正維護，但有些程式設計耦合關聯大，不能隨意更改，需求變得越多，維護的越多，程式碼越亂，bug越多，產品和架構師是主要的bug生產者，業務程式碼僅是簡單的ifelse。所以有經驗的產品和架構師非常重要，底層的碼農到是可以隨便找

Bug不是產生的，而是程式設計時，一些沒有考慮周到的地方。軟體和遊戲，尤其是遊戲，都是一些邏輯的組合。比如說遊戲，程式所做的就是模擬，但是模擬的真實度如何，就得看我們人考慮的是否周到了。當然，所有東西都考慮到不是不可能，但是確實沒有一個產品實現。

在軟體工程中，有個職位是軟體測試，它的目的是儘可能多的發現問題，而不是發現所有問題。因為我們都知道那是不可能的。

因此，目前幾乎所有的東西都存在設計的漏洞，也就是BUG。所以我們才要常常打補丁，修復這些BUG。

任何一個「問題」的產生，本身是沒有好壞之分的，但是為什麼會有的就不被care，甚至還會很喜歡，而有的會被吐槽呢？根本原因是因為產生了利益損失。

比如年前拼多多出問題送了很多無門檻券。

作為一個使用者，自然很喜歡，誇你誇到飛起，怎麼會吐槽你呢。但是作為利益損失方，必然破口大罵，害我傾家蕩產！

所以，如果沒有產生利益損失，我想其他人也不會來找你吐槽。

但是「問題」就等於「bug」嗎？我認為並不是，「問題」不等於「 bug」。

因為程式設計師的職責是什麼？拿造房子來比喻的話，我認為最核心的工作真的和“搬磚”（非貶義詞）無異，就是根據設計師（產品經理）設計好的設計圖砌磚（編碼），建成和設計圖紙上一模一樣的建築。

所以，如果一個東西造出來與設計不符，那麼它可以說是bug或者缺陷（缺斤少兩不完整）。否則，並不是bug，但可以被稱之為「漏洞」（完全沒考慮到的），表示不在預料之內的情況。

之前看到過一個形象的比喻：你家裡的窗可以從外面開啟，那叫漏洞。你家裡的窗打不開，那叫bug。