寫在前面
對於每一個測試人員來說，軟體測試過程中有一個四字成語，真的是如噩夢一般的存在，會在你不注意的時候，就突然蹦出來，勞你筋骨、空乏你身、亂你心神、行拂亂你所為，那就是——線上故障。
線上故障顧名思義，就是專案上線後出現的故障。誘發線上故障的因素有很多，每一個團隊，大大小小，都會受到各種各樣的線上故障，我們有時候會侷限於故障的本身，但是如何應對、避免線上故障的發生，是每個技術研發團隊都要面對的事情。並且，由於線上故障的解決跟蹤過程，能直接體現一個團隊的應急反應能力，所以，線上故障的解決並不是測試一個人的問題，而是整個團隊協同一致，共同面對的一個問題。因此在這個基礎上，我們的測試團隊在部門長的指導下，制定出了我們團隊的線上故障等級和處理規範，供大家參考學習
《故障等級定義》
由於無法配置表格，只能以拙劣的截圖奉上了
線上故障規範及模板
文件背景
為保障線上功能正常使用，並在遇到問題時及時反饋並快速解決，現編寫規範如下
問題分類
線上BUG:
① 運營同事的錯誤操作導致的體驗型別問題，如：文案錯誤；
② 運營後臺使用異常，如：無法修改商品狀態，不能正常開啟使用後臺管理；
③ 產品設計缺陷，不合理需求，等
線上故障：
① 由技術原因導致的線上使用異常，如：無法正常支付、無法正常跳轉配置的連結地址、訂單異常等；
② 運營同事的錯誤操作導致的問題，如：錯配優惠券為無限量無門檻；
非故障型別
產品設計未實現的需求問題，如：需要新增某種功能，或者產品未覆蓋的功能點等
問題錄入
錄入問題必須寫明：專案（線上故障NOF）、模組（android、ios、公眾號、小程式、後臺）、環境（手機配置、瀏覽器及版本）、描述（故障產生場景及操作）、影響版本（故障對應版本號）、嚴重性、優先順序（緊急故障會立即啟動故障流機制）、經辦人、附件（非必填）；問題發生（收到反饋）的時間等，儘可能的詳細
等級評判
評級標準可參考《故障等級參考》
問題修復
1、 定位問題原因，和影響範圍
2、 修改問題耗時，和修改方案
3、 確認後續跟蹤方案
故障Review
故障責任人：故障問題的負責人
問題修復：開發and 開發組長，測試and測試組長
定責內容：確認故障級別、故障原因、故障導致的影響以及最終的解決方案，後續跟蹤
為方便理解以上規範內容，現取一條線上問題作為模板供閱讀此規範的同事參考：
[NOF-32] 全平臺所有業務下單後支付異常，無法調起支付建立: XX年/XX月/XX日 更新: XX年/XX月/XX日 解決: XX年/XX月/XX日 |
|
|
專案: |
線上故障 |
|
模組: |
無 |
|
影響版本: |
4.X |
|
解決版本: |
無 |
|
型別: |
技術方故障 |
優先順序: |
高 |
|
報告人: |
雪姨 |
經辦人: |
陳獨秀 |
|
解決結果: |
完成 |
責任人: |
陳獨秀 |
|
標籤: |
無 |
||
|
剩餘時間: |
XX天XX時XX分 |
||
|
耗費時間: |
XX天XX時XX分鐘 |
||
|
原預估時間: |
尚未登記 |
|
嚴重程度: |
嚴重 |
|
描述 |
|
|
全平臺所有業務下單後支付異常，無法調起支付。 持續時間：XX小時XX分鐘，重啟服務後恢復正常 |
|
|
|
|
|
|
測試-克萊瑞斯覆盤 [ XX/XX月/XX ] |
|
問題解決： 1．臨時通過重啟伺服器解決無法支付的問題 2．最終通過程式碼修復，釋出版本解決問題， 原因分析： 1. 因為沒有.......（問題原因），導致........（問題） 2. 問題出現時，沒有能夠及時聯絡到相關值班人，導致時間延誤 解決方案： 1、陳獨秀通過修正........，新增...........，並在XX時，經小組長抖音帝驗證後釋出到線上環境， 2、萬能鋼新增...........機制，通過.........實現.......，與經小組長抖音帝驗證後釋出到線上環境 3、互留手機號，避免由於溝通不暢影響故障修復速度，部門長已驗證通過 影響範圍： 通過日誌確定XX日XX時XX分出現問題，XX日XX時XX分開始解決， XX日XX時XX分問題解決併發布上線，影響時長 XX天XX小時XX分 全平臺不能調起支付，經核算，問題時間段內影響客戶影響交易量為XXXX元 參與修復人：陳獨秀、萬能鋼 問題責任人：陳獨秀 故障評級： 經過以上影響範圍評估，此判定等級為P-1級故障 |
後續Action：
此次支付故障後，由於該問題具有普遍性，所以阿爾法小組夥伴排查了線上所有的任務並做了危險等級評估
1、業務一......危險評估高，計劃某月某號某人優化修改
2、業務二......危險評估中，計劃某月某號某人優化修改
3、業務三......危險評估低，計劃某月某號某人優化修改
貝塔小組也做出了同樣的預防措施如下：
1、 實現A功能優化，執行人Eason，計劃完成日期XX
2、 通過B方法檢查來review程式碼，
3、 通過C方案避免.......問題。
由於此次問題具有代表性，需要引起各位同事的重視和品質意識，所以有了此規範文件。又因為是首次覆盤線上故障，過程和步驟生疏，導致耗時比較長。所以為了更高效的解決線上故障，以後每週由每條業務線的測試人員驅動，進行故障Review，若本週內未錄入線上故障，則不走此流程。
所有的流程和步驟，都是為了高效、優質、有意義的工作，祝大家工作順利
寫在最後
因為是第一次執筆寫故障定級和規範，所以有很多不足之處，也請大家多多指正出來，我們共同討論，更高效，高質量的管控故障，共同保證我們的專案，安全平穩的執行