1.缺陷的属性
| 属性 | 描述 |
| 缺陷的类型 | 根据缺陷的自然属性划分缺陷的种类 |
| 缺陷的严重程度 | 对软件产品的影响程度 |
| 缺陷优先级 | 被修复的紧急程度 |
| 缺陷的状态 | 跟踪修复过程的进展 |
| 缺陷的起源 | 第一次被检测到的阶段 |
| 缺陷的来源 | 缺陷的起因 |
| 缺陷的根源 | 发生错误的根本因素 |
| 缺陷类型 | 描述 |
| 功能 | 影响了系统的功能、逻辑缺陷 |
| 用户界面 | 影响了用户的界面、人机交互特性，包括屏幕格式 |
| 文档 | 影响发布和维护，包括注释、用户手册、设计文档 |
| 软件包 | 软件配置库、变更管理、版本控制引起的错误 |
| 性能 | 不满足系统可测量的属性值，如事物的处理速率、执行时间 |
| 系统/模块接口 | 与其他组件、模块过驱动设备、调用函数、控制块或参数列表等不匹配、冲突。 |
| 缺陷严重程度 | 描述 |
| 致命 | 主要功能完全丧失 |
| 严重 | 主要功能部分丧失，次要功能完全丧失 |
| 一般 | 次要功能没有实现，不影响用户的正常使用 |
| 较小 | 不影响功能操作和执行 |
2.缺陷的生命周期 （bug处理的过程）：
1.发现缺陷：测试人员
2.提交缺陷：测试人员
3.确认缺陷：质量保证：产品经理
4.分配缺陷：开发或者产品经理
5.修复缺陷：开发、产品经理
6.验证缺陷：测试人员
7.关闭缺陷：测试人员
3.缺陷的识别
(1)客观依据：需求文档、设计文档、产品用例、测试用例
(2)主观依据：同行业类似的成熟软件、开发人员、有经验的测试人员
4.缺陷的报告
1.缺陷编号：Bug_项目名称_模块名称_功能名称_001
2.所属模块：一级、二级、三级
3.优先级：缺陷修复的紧急程度P1>P2>P3
4.严重程度:S1>S2>S3
5.缺陷的概述：缺陷基本情况，实际结果与预期的不同
6.缺陷的描述：复现步骤、实际结果、预期结果
7.提交人
8.备注。该缺陷产生的特殊情况，bug的截图作为附件
5.缺陷报告编写的目的：
(1) 易于搜索软件测试报告的缺陷；
(2)报告的缺陷信息更只准确、具体；
(3)软件开发希望获得却显得本质特征和复现步骤；
(4)市场和技术不希望获得缺陷的分布以及对市场和用户的影响程度；
版权声明：本文为qq_40319094原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。