BUG頻出的大環境下，如何最大程度避免線上事故？

 

一個產品的研發過程中， bug是不可避免的。bug很難徹底消除，只能避免，尤其避免那些線上影響範圍大的，涉及關鍵功能點的高階事故。今天說幾點我們日常工作中能有效避免線上事故的拙見。

 

1.上線流程規劃

不完整的釋出和迭代是隱患出現的一大原因。成熟而完整的產品線應該嚴格按照需求 ->開發-> ->運維釋出的持續整合過程，除此之外，還應該附帶有標準的hotfix流程&灰度流程，最大程度從根源預防風險。很多時候，臨時需求加塞，慌忙上線，線上直接修程式碼等一些過火操作是導致重大事故的直接原因，一定要避免。

除此之外，一些常用的事件追蹤管理工具比 jira/mantis，建立的相關sprint版本，hotfix版本，臨時上線版本，正式版本號等，這些釋出要走的必要流程，看起來比較偏行政化的工作，卻是必須要有人來管理和維護的；記錄清楚事件的流轉，這樣即使線上出現了事故也能快速回滾或及時止損。

 

2.前後端分離的重要性

公司一般都有明確的前端開發人員，後端開發人員；但 可能沒有前端測試人員和後端測試人員，這就要求測試同學在工作的時候分清楚前後端需求，對於出現的問題 ,能夠透過抓包等方式迅速定位到。怎麼做到前後端分離呢？一般認為：

-API自動化(first 後端自動化)

-UI自動化(second 前端自動化)

對於前端 bug，比如一些控制元件，元素，特效等，js報錯等相對比較容易定位。

對於後端，尤其是 service相關的bug,定位可從以下幾方面入手：

-關鍵日誌抓取/請求抓包

-API情況，關鍵error code&message

-資料庫資料情況

前後端分離是清晰化測試任務的有效方法，也是及時響應 bug/處理bug/分類bug的有效方法。

 

3.做好單元測試和整合測試

單元測試一般在工程程式碼裡同時存在，由開發同學來完誠。做好底層單元測試，提升分支覆蓋情況，提升程式碼質量，最大限度避免一些低階卻致命的錯誤。單元測試 -大指標可以說是覆蓋率，有些人認為覆蓋率太片面，但覆蓋率卻是最直觀，最容易做，收益比較高的一個工程。不過，如果不做覆蓋率的話，現在SonarQube比較火，它是一個程式碼質量管理的平臺，透過外掛機制，Sonar 可以整合不同的測試工具，進行程式碼質量分析工具和報告，像類似這種工具也可以聯絡起來。

那整合測試呢，就是系統級別的測試。這種測試可以發現，聯調時候的問題，前後端不一致，介面返回資料等系統性的問題，整合測試有時候和迴歸測試一起做，目的是保障之前的功能正常執行。

 

4.做好bug管控

有些公司內部， bug還是比較亂的。遺留的新建的去年的今年的，各種bug越積越多，沒有推進，會直接導致一系列的連鎖反應，所以測試同學聯合開發同學最好有對bug的把控或認知，分清重要級緊急級優先順序，哪些應該優先解決，哪些需要配合解決，哪些需要重構，哪些需要改表，都要十分清楚，把控把控，怎麼把控呢，就是一不要事故牽著鼻子走。

5.認真對待每一次需求

每個產品及產品線，只要正常運轉，都會不可避免的面臨持續迭代和發版。每次的需求，都需要正規走需求評審，用例設計，開發自測等環節，認真對待每次需求，再小的需求也要做到五臟俱全，指不定哪裡就會爆雷。有的時候說開發緊張或者排期緊張，只能說前期規劃並沒做好，導致整個團隊跟著一起緊張，這樣的事情儘量避免。但如果實在不行，那就要臨時更換上線方案，走一些 hotfix等等。

我們測試人員，是為了質量保障而存在。線上事故的數量直接衡量了這個產品的穩定性。 QA做的每個措施，下的每個決定，都可能在這個產品線起到影響。所以，認真對待上線，認真對待產品本身，Deadline is deadline，認真對待排期，才能做到持續且長久的質量保證。