软件事故报告表编写方法研究

摘要：文章介绍了各类软件缺陷、故障、问题、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— ），本科，工程师，研究方向：软件测试技术。