昨天下午大神把組內(nèi)幾十號人召集在一起開Online bug分析大會，主要是針對近期線上事故從事故原因和解決方案兩個(gè)維度來分析。

對金融軟件來說，每一次的線上事故都有可能給公司帶來重大的損失，少扣了用戶的錢，為公司帶來資金方面的虧損；多扣了用戶的錢，則為帶來不必要的合約或法律糾紛，故測試金融軟件不比其他行業(yè)的軟件，后者線上bug大多不會直接引起資金方面損失，最多就是用戶體驗(yàn)不好，功能沒有實(shí)現(xiàn)，導(dǎo)致用戶量的流失。

對金融軟件來說沒有小bug，一旦出現(xiàn)bug那就是重大的bug，必須引起高度重視。

俗話說”人非圣賢，孰能無過“，軟件是由人編寫的，所以再所難免都會有問題，而我們所要做就是盡量避免出現(xiàn)問題，或者是避免出現(xiàn)重復(fù)的問題。

對于軟件測試人員來說分析線上BUG是非常好的一個(gè)措施，這樣可以檢測到測試人員在測試過程中哪些地方考慮不周，或沒有考慮到，從而可以提醒測試人員下次思考的范圍擴(kuò)大，盡可能地完全覆蓋測試范圍。

從分析結(jié)果的角度出發(fā)，線上bug大多都是開發(fā)人員和測試人員麻痹大意所導(dǎo)致的，并不是不可避免的。

經(jīng)過分析得出線上的bug出現(xiàn)的原因基本有以下幾類：

1.開發(fā)人員使用java框架錯誤

2.開發(fā)人員上線時(shí)合并代碼不仔細(xì)，導(dǎo)致代碼有遺漏

3.測試人員回歸測試流程不全

4.多系統(tǒng)一起上線，缺少聯(lián)調(diào)或者聯(lián)調(diào)不全

01

開發(fā)人員使用java框架錯誤

這個(gè)問題已經(jīng)出現(xiàn)了兩次，在8月份就出現(xiàn)過一次，原因就是開發(fā)人在使用多線程時(shí)，將多例使用成單例，導(dǎo)致系統(tǒng)在高并發(fā)進(jìn)出現(xiàn)了串?dāng)?shù)據(jù)的現(xiàn)象，導(dǎo)致系統(tǒng)在處理時(shí)放錯款，將A的錢放到B的賬戶中去了。

雖然使用單例能節(jié)省資源，降低系統(tǒng)的占用率，但這種情況并不合適目前的系統(tǒng)。

而此中情況在測試過程中并不一定能測試出來，這種出現(xiàn)的機(jī)率不定，必須在數(shù)據(jù)高并發(fā)時(shí)才有可能出現(xiàn)。

解決方案：技術(shù)問題，將單例修改成多例。

02

開發(fā)人員上線時(shí)合并代碼有遺漏

開發(fā)人員上線時(shí)刪除了master中的某行代碼，引起有個(gè)變量沒有定義，導(dǎo)致上線之后某功能失效。

開發(fā)人員將git分支上的代碼合并到master時(shí)，master提示某一行代碼沒有，開發(fā)人員就將分支上的代碼刪除再合并到master，等將代碼上線之后，導(dǎo)致某個(gè)功能失效。

解決方案1：開發(fā)人員將代碼合并到master時(shí)，先將master上的代碼拉到一個(gè)新分支上，然后再將要合并的代碼合到新分支上，最終將新分支上的代碼合并到master上。

解決方案2：開發(fā)人員建立良好的習(xí)慣，在開發(fā)某個(gè)項(xiàng)目時(shí)，每天（固定頻率）都將master上的代碼合并到自己代碼的分支上

03

測試人員回歸測試不全==漏測

說是回歸測試不全，其實(shí)就是相當(dāng)于一定程度上的漏測，漏測應(yīng)該是軟件測試人員盡量避免，一般漏測是因?yàn)闇y試人員思考不全，導(dǎo)致某個(gè)方面沒有測試到。

這次線上bug分析有以下幾個(gè)問題：

回歸測試時(shí)，驗(yàn)證某個(gè)流程，但只驗(yàn)證到任務(wù)創(chuàng)建，就沒有執(zhí)行任務(wù)，上線后，該任務(wù)創(chuàng)建后執(zhí)行會報(bào)錯。

未測試冪等性，上線后，導(dǎo)致兩次返回的結(jié)果不一樣。

開發(fā)修改某一個(gè)bug，回歸測試未回歸以前的流程，導(dǎo)致上線后，原來正常的流程執(zhí)行不通過。

解決方案：

1.回歸測試時(shí)，主流程必須回歸，并且有完整的回歸步驟。

2.一個(gè)業(yè)務(wù)流程測試必須跑完一個(gè)完整流程。

3.測試過程中一定要細(xì)致，不能遺漏重要的點(diǎn)。

軟件中的bug不可能完全測試出來，但最不應(yīng)該出現(xiàn)的就是原本是正確的流程或功能，經(jīng)過版本改動，在后期又出現(xiàn)，但測試人員再次測試時(shí)竟然沒有發(fā)現(xiàn)，像這種情況是軟件測試人員最應(yīng)該避免的，所以回歸測試很重要，不僅要回歸主要流程，還需要回歸修改bug相關(guān)的代碼部分。

解決回歸測試流程測試不全最好的解決方案就是引入自動化，就目前我們的系統(tǒng)不夠成熟，改動太多，業(yè)務(wù)流程或需求都不穩(wěn)定，所以自動化測試還未正式引入。

04

多系統(tǒng)一起上線，缺少聯(lián)調(diào)或聯(lián)調(diào)不全

因?yàn)槁?lián)調(diào)出現(xiàn)問題也不再是一次二次了，為什么聯(lián)調(diào)會出現(xiàn)問題呢？

公司業(yè)務(wù)是由有多個(gè)系統(tǒng)組成的，同時(shí)還需要調(diào)用其他公司業(yè)務(wù)接口，測試人員在測試時(shí)調(diào)用相關(guān)系統(tǒng)接口時(shí)模擬返回或回調(diào)，基本都是使用的mock，mock返回的值并不是真的從相應(yīng)系統(tǒng)的返回值，所以如果聯(lián)調(diào)測試時(shí)沒有把握好，就非常容易出現(xiàn)問題。

在測試過程中聯(lián)調(diào)就非常重要，但由于聯(lián)調(diào)測試人員的放松，對聯(lián)調(diào)內(nèi)容的遺漏，導(dǎo)致業(yè)務(wù)上線之后：

1.調(diào)用某查詢?nèi)蝿?wù)，對方會一直返回處理中，導(dǎo)致流程卡住。

2.A系統(tǒng)回調(diào)B系統(tǒng)失敗，原因是編碼方式不一樣。

3.某系統(tǒng)功能失敗后，調(diào)用查詢接口報(bào)錯。

4.調(diào)用某系統(tǒng)，應(yīng)返回code=1，結(jié)果返回code=0，導(dǎo)致業(yè)務(wù)處理錯誤。

以上問題都是由于系統(tǒng)之間的調(diào)用或回調(diào)導(dǎo)致的線上bug。

解決方案：

1.在聯(lián)調(diào)之前先將自己系統(tǒng)中本次項(xiàng)目所有用例測試完全。

2.編寫聯(lián)調(diào)用例，并且與多方測試人員溝通，確保聯(lián)調(diào)用例能全面覆蓋業(yè)務(wù)流程和任務(wù)。

3.在聯(lián)調(diào)時(shí)，確保所有業(yè)務(wù)流程是全部走通，且返回的值正確。

聯(lián)調(diào)測試與平時(shí)的功能測試重點(diǎn)和關(guān)注點(diǎn)都不同：

1.聯(lián)調(diào)測試保證業(yè)務(wù)流程是通的。

2.聯(lián)調(diào)測試時(shí)要檢查其他系統(tǒng)返回來的數(shù)據(jù)是否正確?檢查相同數(shù)據(jù)在各個(gè)系統(tǒng)存的值是否相同？

3.檢查推送的報(bào)文mapping與其他系統(tǒng)接口文檔中的mapping是否一致（映射）。

此次線上BUG分析再次驗(yàn)證程序中的bug就是人為的，避免這些情況就需要開發(fā)人員在開發(fā)過程中多注意，培養(yǎng)良好的編程習(xí)慣，而測試人員在測試過程中需要將測試范圍考慮完全，盡量避免遺漏測試點(diǎn)，對于不清楚的點(diǎn)，不管是開發(fā)還是測試人員，都應(yīng)該拿出來討論，切忌閉門造車，不懂裝懂。

大家可以一起來說說你們線上發(fā)生了哪些重大事故？讓你開始引以為戒了。

轉(zhuǎn)載于:https://www.cnblogs.com/lifangzhen/p/10044800.html

總結(jié)

以上是生活随笔為你收集整理的线上bug分析的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。