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

摘要：文章介紹了各類軟件缺陷、故障、問題、bug等（統(tǒng)稱為軟件事故），并針對軟件事故的發(fā)生經(jīng)過、原因、后續(xù)解決方案等進行研究，提出了軟件事故報告表編寫方法。關(guān)鍵詞：軟件事故;軟件測試;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

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

1? 軟件事故報告表

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

1.1? 項目信息

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

1.2? 事故發(fā)生經(jīng)過

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

（1）致命：造成系統(tǒng)或應(yīng)用程序崩潰、死機、系統(tǒng)掛起，或造成數(shù)據(jù)丟失、主要功能完全喪失、導(dǎo)致本模塊以及相關(guān)模塊異常等問題。比如，代碼錯誤、死循環(huán)、數(shù)據(jù)庫發(fā)生死鎖以及與數(shù)據(jù)庫連接錯誤或數(shù)據(jù)通信錯誤，未考慮異常操作、功能錯誤等。

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

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

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

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

1.2? 事故原因

事故原因可能是多個因素造成的，需要將事故原因描述清楚，不能隨意夾雜個人判斷、揣測等。此外，事故原因可能涉及原來的系統(tǒng)設(shè)計、需求、操作不當?shù)龋挥袦蚀_分析具體原因，才能解決事故。

1.3? 主要原因

描述事故的主要原因。

1.4? 解決方案或?qū)Σ?/p>

解決方案或?qū)Σ甙R時解決方案（記錄臨時解決方案，填寫解決對策、負責(zé)人、時間）和最終解決方案（記錄最終事故解決方案，填寫解決方案、負責(zé)人、時間）。

1.5? 客戶評估

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

1.6? 懲罰

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

2? 軟件事故提交流程

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

提交：客戶發(fā)現(xiàn)軟件缺陷，可以通過郵件、電話、微信等方式，通知客戶 IT 或項目經(jīng)理。

分析或轉(zhuǎn)發(fā)：客戶 IT 或項目經(jīng)理接收客戶問題并進行初步分析或解答，無法解決時將會聯(lián)系項目實施方的項目負責(zé)人。

接收問題：項目經(jīng)理或測試人員接收客戶問題，測試人員編寫事故報告表，以復(fù)現(xiàn)問題。

問題復(fù)現(xiàn)：將缺陷登記至內(nèi)部的缺陷管理系統(tǒng)，并提交給開發(fā)團隊。無法復(fù)現(xiàn)的問題需要與客戶溝通，詢問問題發(fā)生的操作等，并記錄在事故報告表中。

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

發(fā)布版本：內(nèi)部測試完成之后，發(fā)布版本。

問題總結(jié)與分析：內(nèi)部進行分析總結(jié)，最后根據(jù)具體情況做出獎懲決定。

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

3? 案例分析

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

3.1? 編寫事故報告表

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

3.1.1? 編號規(guī)則

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

3.1.2? 事故描述原則

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

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

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

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

3.1.3? 解決方案原則

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

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

3.2? 事故原因分析

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

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

3.2.2? 事故原因分析思路

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

3.2.3? 事故原因分析流程

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

在事故原因分析中，我們可能會遇到潛在缺陷，需要勇敢面對問題并解決問題。出現(xiàn)事故不可怕，可怕的是不知道什么原因?qū)е碌氖鹿?。在事故發(fā)生之后，必須排查出事故原因，提出最適合的解決方案，以解決事故、降低損失?？梢圆捎谩棒~骨圖”“帕累托圖”等進行分析，找出問題的原因。

4? 總結(jié)

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

參考文獻：

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

[2] 于慧媛.基于測試的軟件缺陷數(shù)據(jù)分析方法[ J].現(xiàn)代導(dǎo)航，2020，11（4）：308?312.

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

作者簡介：

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