摘要：文章介紹了各類(lèi)軟件缺陷、故障、問(wèn)題、bug等（統(tǒng)稱(chēng)為軟件事故），并針對(duì)軟件事故的發(fā)生經(jīng)過(guò)、原因、后續(xù)解決方案等進(jìn)行研究，提出了軟件事故報(bào)告表編寫(xiě)方法。關(guān)鍵詞：軟件事故;軟件測(cè)試;BUG

中圖法分類(lèi)號(hào)：TP311文獻(xiàn)標(biāo)識(shí)碼：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

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

1? 軟件事故報(bào)告表

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

1.1? 項(xiàng)目信息

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

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

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

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

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

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

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

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

1.2? 事故原因

事故原因可能是多個(gè)因素造成的，需要將事故原因描述清楚，不能隨意夾雜個(gè)人判斷、揣測(cè)等。此外，事故原因可能涉及原來(lái)的系統(tǒng)設(shè)計(jì)、需求、操作不當(dāng)?shù)?，只有?zhǔn)確分析具體原因，才能解決事故。

1.3? 主要原因

描述事故的主要原因。

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

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

1.5? 客戶(hù)評(píng)估

事故解決之后，由客戶(hù)進(jìn)行評(píng)估驗(yàn)收，確認(rèn)是否修復(fù)以及評(píng)估意見(jiàn)。

1.6? 懲罰

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

2? 軟件事故提交流程

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

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

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

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

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

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

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

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

提交事故報(bào)告：提交事故報(bào)告給客戶(hù)，進(jìn)行評(píng)估確認(rèn)。

3? 案例分析

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

3.1? 編寫(xiě)事故報(bào)告表

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

3.1.1? 編號(hào)規(guī)則

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

3.1.2? 事故描述原則

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

準(zhǔn)確性原則：描述準(zhǔn)確、清晰，方便定位問(wèn)題，避免存在歧義。

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

言簡(jiǎn)意賅原則：杜絕長(zhǎng)篇大論，描述需要言簡(jiǎn)意賅。

3.1.3? 解決方案原則

快：在方案評(píng)估過(guò)程中，多個(gè)方案的修改時(shí)間不一致，建議采用時(shí)間最快的臨時(shí)方案，以減少損失。

?。涸诜桨冈u(píng)估過(guò)程中，多個(gè)方案存在不同的缺點(diǎn)，需要和客戶(hù)溝通，建議采用影響最小的方案。

3.2? 事故原因分析

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

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

3.2.2? 事故原因分析思路

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

3.2.3? 事故原因分析流程

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

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

4? 總結(jié)

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

參考文獻(xiàn)：

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

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

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

作者簡(jiǎn)介：

謝彭（1991— ），本科，工程師，研究方向：軟件測(cè)試技術(shù)。D4851783-F5FC-44B6-BE1B-C6BA3883C1D9