软件测试BUG相关知识点总结
一、软件测试生命周期
软件测试贯穿软件整个生命周期，是按特定顺序执行的、保障产品质量符合需求的测试流程，各阶段有明确目标与交付产物，具体如下：
| 阶段 | 核心内容 |
|---|---|
| 需求分析 | 用户角度：判断软件需求合理性；技术角度：评估技术可行性与优化空间；测试角度：排查业务逻辑错误、冗余、冲突等问题 |
| 测试计划 | 明确测试时间、结束节点、耗时、测试形式等 |
| 测试设计与开发 | 参考需求文档、技术文档等，编写测试用例、测试文档，明确测试方法、工具等 |
| 测试执行 | 测试人员充分利用测试用例和工具，全面覆盖测试，实施测试工作 |
| 测试评估 | 判断测试是否通过，确认是否有遗留BUG，产出测试报告 |
| 上线 | 将项目发布到线上环境 |
| 运行维护 | 跟踪上线情况，测试线上环境软件运行正确性，收集试运行问题并反馈 |
| 项目测试结束 | 测试人员可参与用户培训 |
二、BUG相关核心知识
（一）bug的概念
计算机程序中存在的错误、缺陷、疏忽或故障，会导致程序无法正确运行，其产生源于源代码或程序设计阶段的问题。判定标准如下：
- 若规格说明存在且正确，程序与规格说明不匹配则为bug；
- 若需求规格说明书未提及相关功能，以最终用户合理预期为准，程序未实现该预期功能则为bug。
（二）描述bug的要素
为保障沟通效率与工作质量，bug描述需包含5个基本要素：
- 问题出现的版本；
- 问题出现的环境；
- 问题出现的步骤；
- 预期结果；
- 实际结果。
（三）bug级别
通过级别明确问题严重程度，指导开发人员分配处理优先级，同时反映开发质量，具体分类如下：
| 级别 | 定义与示例 |
|---|---|
| 崩溃 | 阻碍开发/测试工作；造成系统崩溃、死机、死循环，数据库数据丢失/连接错误，主要功能丧失、基本模块缺失等（如代码错误、死锁、一级菜单功能不可用），出现后需立即中止当前版本测试 |
| 严重 | 系统主要功能部分丧失，数据库保存/调用错误，用户数据丢失，一级功能菜单不可用但不影响其他功能测试；功能与需求严重不符，模块无法启动/调用，程序重启/自动退出，关联程序调用冲突，存在安全或稳定性问题（如数据保存后显示错误、功能缺失、接口错误），不影响其他功能测试时可继续当前版本测试 |
| 一般 | 功能未完全实现但不影响使用，功能菜单有缺陷但不影响系统稳定性（如操作/查询时间长、格式错误、边界条件错误、删除无确认框），实际测试中占比最高 |
| 次要 | 界面、性能缺陷或建议类问题，不影响功能执行（如错别字、界面格式不规范、显示重叠、提示语丢失、用户体验差），测试初期较多、优先级低，后期需及时处理 |
（四）bug的生命周期
- 核心状态流转：New（新发现，未评审是否指派开发）→ Open（确认是bug，指派开发修改）→ Fixed（开发修改后待回归测试）→ Closed（回归测试通过，关闭bug）；
- 特殊状态处理 ：
- Rejected（判定不是bug，拒绝修改）→ Closed；
- Delay（暂时无需/不能修改，延后处理）；
- Reopen（回归测试验证bug仍存在，重新打开让开发修改）；
- 无效bug流转：Open→Closed 或 Open→Rejected→Closed。
三、与开发产生争执的处理方法
（一）检查自身bug描述
确保bug描述准确、全面，若书面表达不足，提交后主动与开发沟通，明确bug信息。
（二）站在用户角度沟通
向开发说明bug对用户的潜在困扰，通过"若你是用户，是否能接受"等提问促使开发重视。
（三）bug定级有理有据
参考bug级别标准，结合是否影响业务流程，站在用户角度合理定级。
（四）提升自身能力
提高技术与业务水平，不仅能发现问题，还能提供合理解决方案（不命令开发按自身想法修改），建立权威性。
（五）召开bug评审
友好沟通无果时，组织评审会议，需测试代表、开发代表、产品代表参加，解决两个核心问题：
- 确定bug处理方案；
- 分析bug产生原因，制定预防对策。