软件问题解决过程程序+报告的参考模板

suxia20141

我是一个软件小白，现急需一份软件问题解决过程程序+报告的参考模板，大佬们帮帮忙了，谢谢！！！！

wang04021

缺陷管理制度？

suxia20141

wang04021 发表于 2023-4-6 15:22
缺陷管理制度？

嗯，可以提供一份参考吗？谢谢！

wang04021

1 目的
本程序详细描述了本公司标准的缺陷管理流程、缺陷属性定义、缺陷管理工具及其使用方法

2 适用范围
适用于本公司所有软件的缺陷管理工作，本公司使用的缺陷管理工具是GitLab。

3 职责
3.1项目经理负责缺陷管理工具的设置以及缺陷的维护，负责缺陷的确认、分派调整及处理。
3.2软件测试工程师负责提交缺陷、验证缺陷的修复、提交测试报告、测试文档缺陷的修复。
3.3软件开发工程师负责代码缺陷的修复和软件需求缺陷的修复。

4  程序
4.1 GitLab的设置
项目测试执行活动开始前，项目经理完成在GitLab上建立项目，并完成具体的Issue Type、Workflow、使用权限等相关设置。

4.2标准缺陷管理流程
缺陷管理的标准流程如下：









4.2.1测试工程师登录缺陷
测试工程师在执行测试过程中发现缺陷时，需记录于表单内汇总缺陷，详细和准确的描述所发现的缺陷，并将缺陷传达给项目负责人。记录内容包含测试软件版本号、测试时间、BUG（测试环境、步骤、缺陷的表现描述）、优先级、备注等。

4.2.2 项目经理确认缺陷
缺陷在由项目经理定期对Open的问题展开评审会议进行确认，评价问题和安全性的相关性，以确定其处理方案并执行，保持研究和评价记录。
4.2.2.1        若项目经理确认为有效缺陷，则将该缺陷在GitLab上登录并转给相关人员进行修复。
登录内容如下：
1）【Title】：简要介绍缺陷
2）【Description】：准确而详细地描述缺陷。准确而详细地描述一个缺陷是非常重要的，有利于问题的快速和准确定位；详细的缺陷描述格式如下：
        【Initial situation】：初始条件设置，包括环境等；
        【Operation】：再现步骤；描述发生缺陷时的操作步骤，若存在回避该缺陷的路径，也需描述；
        【Defects】：缺陷的表现描述；
        【Others】：其他需要补充的信息，如其他出现类似情况的信息等；
3）【Attach a file】：重现该缺陷的数据或在执行过程中错误界面的图片等文件（需要时上传）
4）【Assignee】：选择将该缺陷提交至何人
5）【Milestone】：选择该缺陷目前的状态
6）【Label】：选择该缺陷的分类
7）【Due date】：选择解决该缺陷的最后限定日期
此时缺陷状态自动设为Open。
4.2.2.2        若项目经理确认为无效缺陷，将该缺陷closed，并记录于评审会议。
4.2.2.3项目经理安排和执行处理方案及缺陷的跟踪，并定期整理相关缺陷传达给项目人员。

4.2.3开发工程师修复缺陷
缺陷被分派给开发人员后，开发人员对缺陷进行详细定位，需进行下列工作：
4.2.3.1当缺陷需要被修复时，若是文档错误，开发人员对最新版本文档进行修改，并在文档修改记录中作好相应记录，完成后保存。
4.2.3.2若是源代码，开发人员对代码文件进行修改后保存，并在下一次版本发布的发布日志中注明相关变更。
4.2.3.3若是测试用例的缺陷，由测试工程师对最新版本文档作相应修改，并保持修改记录，完成后保存。
4.2.3.4修改完毕后，并写明下列信息：
        【Resolve IM】：缺陷的解决方案，针对缺陷所做修改的具体内容，并具体写出被修改的文件名。
        【Resolve Version】：缺陷解决的版本。
        【Comment】：必要的备注信息。

4.2.4验证修复
在相关责任人解决缺陷后，该缺陷的提交人对缺陷进行验证。
4.2.4.1        验证结束后，在评价区写明下列信息：
        【Verify IM】：相关验证信息，验证结果。
        【Verified Version】：验证的软件版本。
        【Comment】：必要的备注信息。
4.2.4.2        若验证未通过，在评论区写明下列信息：
        【Verify IM】：相关验证信息。
        【Verified Version】：验证的软件版本。
        【Comment】：必要的备注信息。
此时缺陷退回给上一处理者，继续过程4.2.1。
注：如果缺陷通过了验证，但是在以后版本中又重新发现，则不需修改该缺陷的状态，而是在重新发现这个缺陷的时候，作为新缺陷再次提交。

4.3软件版本正式发布后的缺陷管理
4.3.1软件版本正式发布后，项目经理需按照计划或定期收集用户发现的缺陷，并安排相关人员将缺陷记录到缺陷管理工具中。
4.3.2在临床试验期间，项目经理及时安排相关人员将用户反馈的缺陷信息完整记录到缺陷管理工具中，并安排开发人员对应。
4.3.3项目进入维护期后，项目经理需安排定期主动向用户询问是否有发现产品的缺陷，并获取用户的明确答复。若用户反馈缺陷，项目经理应及时安排相关人员将缺陷信息完整记录到缺陷管理工具中，并安排开发人员对应。

4.5缺陷属性定义
4.5.1缺陷严重度定义
缺陷的严重度是指假如缺陷没有修改，由这个缺陷引发的问题对用户的影响程度。测试工程师在发现软件缺陷时，需为每个缺陷定义其严重度。缺陷的严重度从高到低分为1～3级。
a）        critical：导致系统崩溃、挂起、死机或数据被破坏，数据不能保存，或者系统任何一个主要功能完全丧失的缺陷，没有其他的工作方式来补救。例如：
        由于程序所引起的死机，非法退出
        数据通讯错误
        与数据库连接错误
b）        major：导致功能错误执行的缺陷，系统的主要功能部分丧失，系统的次要功能完全丧失，有其他的工作方式来缓解这种影响。例如：
        数值计算错误
        界面错误
        打印内容错误
c）        minor：影响功能使用的缺陷。使操作者不方便或遇到麻烦，但它不影响功能的操作和执行，例如：
        辅助说明描述不清楚
        显示格式不规范
        长时间操作未给用户进度提示

4.5.2缺陷来源
缺陷来源一般有两种途径：
        软件测试：软件测试人员在测试过程中提出缺陷
        用户反馈：在临床过程中或产品上市后，用户反馈的信息（可能是缺陷，也可能是新的需求）

4.6分析问题的趋势
项目经理需定期对所有软件问题进行分析，以找出问题的趋势。此分析也可包含在测试报告中。

4.7测试报告
当完成相关更改的测试后，软件测试工程师负责完成测试报告。

5 相关文件
5.1 YY/T 0664医疗器械软件 软件生存周期过程
5.2《软件配置管理制度》

6 质量记录
《测试用例及记录表》
《BUG及QA记录汇总》
《测试报告》

栗子7

wang04021 发表于 2023-4-6 16:28
1 目的
本程序详细描述了本公司标准的缺陷管理流程、缺陷属性定义、缺陷管理工具及其使用方法

感谢分享...............

wang04021

流程图。。。。。。

suxia20141

wang04021 发表于 2023-4-6 16:28
1 目的
本程序详细描述了本公司标准的缺陷管理流程、缺陷属性定义、缺陷管理工具及其使用方法

谢谢分享，可以发我邮箱吗（360416625@qq.com）

suxia20141

wang04021 发表于 2023-4-6 16:28
1 目的
本程序详细描述了本公司标准的缺陷管理流程、缺陷属性定义、缺陷管理工具及其使用方法

谢谢分享，可以发我邮箱吗（360416625@qq.com）

ten1

程凌祥

谢谢分享，学习了

123456789h

感谢分享