軟件事故報告表編寫方法研究

摘要：文章介紹了各類軟件缺陷、故障、問題、bug等（統稱為軟件事故），并針對軟件事故的發生經過、原因、后續解決方案等進行研究，提出了軟件事故報告表編寫方法。關鍵詞：軟件事故;軟件測試;BUG

中圖法分類號：TP311文獻標識碼：A

Method for compiling software accident report andanalysising accident causes

XIE Peng

（Shanghai Landa Human Resources Co.，Ltd.，Shanghai 200000，China）

Abstract：This paper introduces various software defects， faults， problems，bugs， etc.（collectively referred to as software accidents）， studies the occurrence process，causes，and follow-up solutions of software accidents， and proposes a method for compiling software accident report forms.

Key words：software accident，software Testing，BUG

軟件缺陷是計算機系統以及程序中存在的任何一種破壞正常運行能力的問題、錯誤，或者隱藏的功能缺陷、瑕疵[1] ，一般在軟件測試階段被集中、大量發現 [2]。軟件上線后將會被來自各方的用戶所使用，在使用過程中就是對軟件進行一次次的測試。在不同的操作系統、不同的賬戶、不同的網絡中，用戶可能會發現一些在測試過程中沒有發現的問題，這些問題可能涉及功能、性能、安全等方面。針對發現的問題，作為軟件系統開發方或項目的實施方，需要解決問題和分析發生問題的根本原因。通過剖析問題的原因，排查系統的其他問題，列出和解決系統中的類似問題，避免造成二次損失。

1? 軟件事故報告表

如表1 所列，軟件事故報告表由項目信息、事故發生經過、事故原因、主要原因、解決方案與對策、系統截圖等組成。

1.1? 項目信息

項目信息包含項目名稱（某項目）、事故編號（具有唯一性，參考事故編碼規則）、項目經理（系統實施方的項目負責人）、填寫時間（事故報告填寫時間）、填寫人（填寫者一般為測試組長或測試工程師）、審核人（審核人一般為項目負責人、部門負責人或測試經理）、審核時間（事故報告表的審核確定時間）。

1.2? 事故發生經過

事故發生經過包括事故發生時間（記錄事故發生的時間，精確到分鐘）、事故發生模塊（記錄事故發生的系統模塊，以便后續按照模塊分析事故發生率等）、事故描述（填寫事故現象、步驟等信息）、事故嚴重性（參考軟件缺陷嚴重等級，即致命、嚴重、一般、輕微）

（1）致命：造成系統或應用程序崩潰、死機、系統掛起，或造成數據丟失、主要功能完全喪失、導致本模塊以及相關模塊異常等問題。比如，代碼錯誤、死循環、數據庫發生死鎖以及與數據庫連接錯誤或數據通信錯誤，未考慮異常操作、功能錯誤等。

（2）嚴重：系統的主要功能部分喪失、數據不能保存，系統的次要功能完全喪失。問題局限在本模塊，導致模塊功能失效或異常退出。比如，致命的錯誤聲明、程序接口錯誤以及數據庫的表、業務規則、缺省值未加完整性等約束條件。

（3）一般：次要功能沒有完全實現但不影響使用。比如，提示信息不太準確或用戶界面顯示效果差、操作時間長、模塊功能部分失效等，以及打印內容錯誤、格式錯誤、刪除操作未給出提示、數據庫表中有過多的空字段等。

（4）輕微：使用者操作不方便或遇到麻煩，但不影響功能的操作和執行，如錯別字、界面不規范（字體大小不統一，文字排列不整齊，可輸入區域和只讀區域沒有明顯的區分標志），輔助說明描述不清楚。

另外，事故發生經過還包括事故影響（事故一旦發生設法找出事故的影響，系統模塊之間存在耦合性，某個功能模塊出現故障，可能會影響引用的地方。需要準確地分析事故的影響點，并解決相關問題）、事故發生時（詳細記錄事故發生期間的動態，記錄發生了什么、做了什么、有什么影響，準確記錄事故發生動態，后期可以分析、解決事故）、事故發生后（一般描述事故發生后的狀態，如系統恢復正常、功能可以正常使用等）、事故截圖（系統的錯誤截圖、日志等截圖。截圖一定要清晰，錯誤提示或異常明顯。有些事故不易被重現，事故截圖可以給開發人員、IT 運維人員提供一定的問題判斷依據）。

1.2? 事故原因

事故原因可能是多個因素造成的，需要將事故原因描述清楚，不能隨意夾雜個人判斷、揣測等。此外，事故原因可能涉及原來的系統設計、需求、操作不當等，只有準確分析具體原因，才能解決事故。

1.3? 主要原因

描述事故的主要原因。

1.4? 解決方案或對策

解決方案或對策包含臨時解決方案（記錄臨時解決方案，填寫解決對策、負責人、時間）和最終解決方案（記錄最終事故解決方案，填寫解決方案、負責人、時間）。

1.5? 客戶評估

事故解決之后，由客戶進行評估驗收，確認是否修復以及評估意見。

1.6? 懲罰

懲罰包括內部獎懲（依據事故原因追究事故責任人的責任，根據企業內部信息系統事故相關的管理規定，進行獎懲）、外部獎懲（雙方進行溝通確認獎懲辦法，實施方可以主動拿出獎懲辦法，由甲方進行確認。內部獎懲根據實際情況考慮是否通報甲方）。

2? 軟件事故提交流程

軟件事故的提交流程根據企業的具體情況而定，圖 1為通用軟件事故中采用的流程。

提交：客戶發現軟件缺陷，可以通過郵件、電話、微信等方式，通知客戶 IT 或項目經理。

分析或轉發：客戶 IT 或項目經理接收客戶問題并進行初步分析或解答，無法解決時將會聯系項目實施方的項目負責人。

接收問題：項目經理或測試人員接收客戶問題，測試人員編寫事故報告表，以復現問題。

問題復現：將缺陷登記至內部的缺陷管理系統，并提交給開發團隊。無法復現的問題需要與客戶溝通，詢問問題發生的操作等，并記錄在事故報告表中。

解決問題：根據內部的缺陷處理流程進行排查和解決問題，開發人員定位問題、解決問題以及記錄涉及的影響功能。

發布版本：內部測試完成之后，發布版本。

問題總結與分析：內部進行分析總結，最后根據具體情況做出獎懲決定。

提交事故報告：提交事故報告給客戶，進行評估確認。

3? 案例分析

A 公司因業務發展的需要，定制開發了一套信息化管理系統。該系統從開發階段至上線階段一直平穩運行，在驗收過程中，其順利通過了 A 公司的 UAT 等測試，符合公司要求，同意驗收。經過一段時間的正常使用，恰逢節假日復工上班，用戶部門反饋該系統無法正常使用。客戶將問題通過郵件發送給項目負責人，項目負責人將問題反饋到測試部門。

3.1? 編寫事故報告表

根據客戶的郵件反饋以及電話溝通等，記錄和描述故障的詳細信息，包含事件的經過、問題分析等（圖2）。

3.1.1? 編號規則

每個公司的編號規則不同，如可以根據項目進行編碼，也可以由公司進行統一編碼。公司事故編號規則為“SG+年+4位+流水編號”（ SG：“Shi Gu”）。系統的事故編號規則為“系統編號+年+4位流水編號”，如 ERP?2022?0001或 SAP202204100001等。

3.1.2? 事故描述原則

實事求是原則：根據實際的軟件事故進行描述。

準確性原則：描述準確、清晰，方便定位問題，避免存在歧義。

可重現原則：事故的描述具備詳細的操作步驟，便于開發者及客戶理解。

言簡意賅原則：杜絕長篇大論，描述需要言簡意賅。

3.1.3? 解決方案原則

快：在方案評估過程中，多個方案的修改時間不一致，建議采用時間最快的臨時方案，以減少損失。

小：在方案評估過程中，多個方案存在不同的缺點，需要和客戶溝通，建議采用影響最小的方案。

3.2? 事故原因分析

事故報告表的原因分析可以讓雙方了解事故發生的根本原因，避免存在歧義。在軟件測試過程中，測試人員不僅要做問題的提出者，也要做問題原因的分析者及解決方案的建議者。事故發生之后，一名優秀的測試人員首先思考的是可能出現的功能點，進行分析和排查。而不是想到找什么樣的借口來逃避問題。? 3.2.1? 軟件錯誤特征

軟件錯誤特征較多，作為測試人員在分析問題時可以進行參考[3]：錯誤的外部征兆遠離引起錯誤的內部原因，對于高度耦合的程序結構而言，此類現象更為嚴重;糾正一個錯誤造成了另一錯誤（暫時）消失，相關錯誤一般會具有這種特征;某些錯誤征兆只是假象;因操作人員一時疏忽造成的某些錯誤征兆不易追蹤，如輸入操作等;錯誤是由于分時而不是程序引起的;輸入條件難以精確地再構造（例如，某些實時應用的輸入次序不確定）;錯誤征兆時有時無，此現象在嵌入式系統中尤其普遍;錯誤是由于把任務分布在若干臺不同處理機上運行而造成的。

3.2.2? 事故原因分析思路

是否是人為操作的原因？查看客戶采取了哪些操作步驟;是否是操作系統的兼容性原因？查看客戶的操作系統、瀏覽器等是否兼容;是否是數據異常的原因？查看客戶是否輸入特殊了字符;是否是硬件原因（如網絡、設備故障等）？查看客戶網絡是否正常;是否是原有的系統需求未得到滿足？查看說明書或操作手冊等。

3.2.3? 事故原因分析流程

測試人員根據客戶的反饋，排查項目日志及數據;查看數據庫中的最后一條數據出現的時間點，從而判斷服務器的最后一次數據交互的時間;查看日志，解讀日志中雙向推送的報文狀態。若無法判斷原因，召開項目組臨時會議，通報問題，尋找開發團隊的支持，排查問題;排查問題或解決問題時，必須提供問題的根本原因及解決方案。測試人員進行確認驗證，關閉內部的缺陷系統 BUG。編寫事故報告表，提交項目組審核。

在事故原因分析中，我們可能會遇到潛在缺陷，需要勇敢面對問題并解決問題。出現事故不可怕，可怕的是不知道什么原因導致的事故。在事故發生之后，必須排查出事故原因，提出最適合的解決方案，以解決事故、降低損失。可以采用“魚骨圖”“帕累托圖”等進行分析，找出問題的原因。

4? 總結

在軟件開發過程中，軟件事故不可避免。本文介紹了一種軟件事故報告表的編寫與原因的分析方法，測試人員在處理軟件事故時，也要掌握事故報告編寫方法，從而更好地幫助客戶解決問題，提升自己的專業水平。單系統或多系統的事故原因可以進行整合分析，找出事故原因的共性，從開發、實施、環境等各個方面提高軟件開發質量，降低軟件事故率。

參考文獻：

[1 ] 朱少民.軟件測試方法和技術[ M].北京：清華大學出版社，2005.

[2] 于慧媛.基于測試的軟件缺陷數據分析方法[ J].現代導航，2020，11（4）：308?312.

[3] 戴蒙.高建華.軟件錯誤的分類、原因及特征[ J].福建電腦，2003（5）：1?2.

作者簡介：

謝彭（1991— ），本科，工程師，研究方向：軟件測試技術。