狂嗨之後的寂寞
相信每一個軟件測試工程師都有一個疑問：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中了。
考拉曰
產生bug的具體原因或許多種多樣，但在bug原因分析過程中，希望能抽絲剝繭，找出其產生的根本原因。之前寫過如何減少線上故障、典型故障分析、故障的坑，你踩了多少遍等等，如果能結合起來看線上、線下的bug，或許會對bug產生的原因有不一樣的認識。\r
一、前後端使用架構導致\r
前端使用es7+react+node使用，在開發方面增大了工作量：
封裝組件;\r
多個模塊公用組件，導致改動一個功能點，改壞其他模塊;對測試的影響就是，該一個模塊，需要回歸其他涉及的多個模塊哦。\r
後端屬於大數據基礎上做各種條件篩選，在具體實現上採用了“重內存”方案，即：\r
1、將數據定時更新到內存中;\r
2、在內存中做多條件的篩選;\r
帶來的問題就是：\r
1、 fullgc問題 導致需要大內存服務器;\r
2、定時數據更新機制，常常發現一個接口多次篩選返回的數據不一致;
二、開發人員經驗問題/思維嚴謹性導致\r
此類問題和經驗、或每個開發人員的合作、做事風格有很大的關係，具體問題包括：\r
1、前後端默認參數約定\r
2、前端傳參\r
3、需求點沒有實現\r
4、“顯而易見”的主功能沒有實現\r
三、業務特點導致\r
每一個業務除了公共的業務特點外，還有各自獨特的業務特徵。例如，前端業務與純後端業務側重點有很大不同，而APP端的前端業務與web的前端業務又有很大的不同。反應到具體產生的bug上，無論是bug的數量，還是bug本身的隱藏深度，都有很大的不同。\r
四、測試人員的經驗缺乏導致\r
這裡不必多說了，測試方案制定的完整性和深度，甚至測試執行層面的經驗，都決定了究竟有多少bug可以被暴露出來了。
無謂子
這個問題問的好，身為程序員，看到這個問題，完全忍不住想要站出來說兩句。就像之前看到一個問題:為什麼會有程序bug，程序員不能一次性寫好嗎？
首先，需要明白程序開發的整個過程（這裡說自己認為的，可能不精確，歡迎補充）。
1.公司商務大佬，通過調查或者自身產生想法，想要開發一款程序；或者接到其他公司，也就是客戶提出的想法，要開發一款程序。
2.公司產品大佬，通過與程序提議者溝通，確定具體細節，到底要做一個什麼樣的程序，整理成文檔，也就是所謂的需求調研。
3.開發大佬，產品確定需求後，將整理的需求文檔發給開發人員，開發參照文檔進行開發。
4.測試大佬，程序開發完成後，肯定不會直接提供給客戶或者拿出來用，而是先要經過公司測試進行完整的程序測試，確保沒有問題了再對外提供出來。
（所有的會議討論環節，這裡省略了）
綜上來看，一款程序從最初提出想法，到最終開發出來，是有一系列步驟的。就產品傳遞給開發這一步，就有可能發生很大變化。最終，客戶想的是這種，開發出來是那種，或者客戶在開發過程中又有了新的想法，就是所謂的需求變更，這就導致程序總是不能按照既定的路線發展。
當然，上線後也會有問題，有個很經典的比方:為什麼有人在使用高壓鍋的時候會發生爆炸？明明廠家已經多次按照說明測試過沒問題的，但，你沒想到的是，客戶不一定按照說明書來操作，所以……
霚裡看花最是迷人
需求設計，架構設計，代碼規範產生的，開始需求不完善，或需求高大上，做出來之後，又要修正維護，但有些程序設計耦合關聯大，不能隨意更改，需求變得越多，維護的越多，代碼越亂，bug越多，產品和架構師是主要的bug生產者，業務代碼僅是簡單的ifelse。所以有經驗的產品和架構師非常重要，底層的碼農到是可以隨便找
啊哈哈叫啊
Bug不是產生的，而是程序設計時，一些沒有考慮周到的地方。軟件和遊戲，尤其是遊戲，都是一些邏輯的組合。比如說遊戲，程序所做的就是模擬，但是模擬的真實度如何，就得看我們人考慮的是否周到了。當然，所有東西都考慮到不是不可能，但是確實沒有一個產品實現。
在軟件工程中，有個職位是軟件測試，它的目的是儘可能多的發現問題，而不是發現所有問題。因為我們都知道那是不可能的。
因此，目前幾乎所有的東西都存在設計的漏洞，也就是BUG。所以我們才要常常打補丁，修復這些BUG。
易為圖紙
Bug不是產生的，而是程序設計時，一些沒有考慮周到的地方。軟件和遊戲，尤其是遊戲，都是一些邏輯的組合。比如說遊戲，程序所做的就是模擬，但是模擬的真實度如何，就得看我們人考慮的是否周到了。當然，所有東西都考慮到不是不可能，但是確實沒有一個產品實現。
在軟件工程中，有個職位是軟件測試，它的目的是儘可能多的發現問題，而不是發現所有問題。因為我們都知道那是不可能的。
因此，目前幾乎所有的東西都存在設計的漏洞，也就是BUG。所以我們才要常常打補丁，修復這些BUG
