1. 软件测试的⽣命周期
软件测试贯穿于软件的整个⽣命周期，针对这句话我们⼀起来看⼀下软件测试是如何贯穿软件的整个⽣命周期。
软件测试的⽣命周期是指测试流程，这个流程是按照⼀定顺序执⾏的⼀系列特定的步骤，去保证产品质量符合需求。在软件测试⽣命周期流程中，每个活动都按照计划的系统的执⾏。每个阶段有不同的⽬标和交付产物
| 阶段 | 用户角度思考 | 测试目标/任务 | 主要活动与输出 |
|---|---|---|---|
| 需求分析 | - 是否合理- 技术可行性- 有无逻辑冲突 | 从用户/技术角度识别潜在问题 | 参与评审需求文档，识别业务逻辑错误、冗余与冲突 |
| 测试计划 | 无 | 制定测试策略与整体安排 | 明确测试时间表、范围、资源分配、目标与形式；输出测试计划 |
| 测试设计与开发 | 无 | 准备具体测试方案 | 编写测试用例、测试点；明确测试方法、使用工具等 |
| 测试执行 | 无 | 实际测试系统，发现和记录缺陷 | 执行测试用例，记录缺陷，使用测试工具提高覆盖率 |
| 测试评估 | 无 | 确定是否达到测试标准，有无遗留问题 | 整理测试报告，说明通过情况与BUG状态，评估上线风险 |
| 上线 | 是否能在真实环境中正常运行 | 确认部署正确，功能稳定 | 上线后环境验证测试；确保部署版本功能一致性 |
| 运行维护 | 用户是否能顺利使用软件，有无问题反馈 | 参与支持工作，辅助用户培训 | 测试人员参与用户培训、现场支持，收集问题并及时反馈 |
2.BUG
1.什么是bug?
1. 当且仅当规格说明是存在的并且正确，程序与规格说明之间的不匹配才是错误。
2. 当需求规格说明书没有提到的功能，判断标准以最终⽤⼾为准：当程序没有实现其最终⽤⼾合理预期的功能要求时，就是软件错误。
2.描述bug的要素
描述bug的基本要素：问题出现的版本、问题出现的环境、问题出现的步骤、预期结果、实际结果
eg.
问题出现的版本：⾕歌浏览器版本 123.0.6312.123（正式版本） （64 位）
问题出现的环境：Windows家庭版
问题出现的步骤：
1、打开⾕歌浏览器，输⼊⽹址https://www.101eduyun.com/
2、等待⾸⻚⻚⾯渲染完成
预期结果：⼆维码与登陆模块不会出现遮挡，⼆维码可以正常扫描
实际结果：⼆维码被登陆模块遮挡，⼆维码扫描失败
3.bug级别
通过定义bug的级别，能够明确看出问题的严重程度。⼯作中开发⼈员通常需要按照bug的级别来分配优先级来处理bug，除此之外，通过bug级别也能够体现出开发⼈员的开发质量。
bug级别⼀般分为：崩溃、严重、⼀般、次要
| 等级 | 定义简述 | 示例（简化） | 是否阻断测试 |
|---|---|---|---|
| 崩溃 | 系统崩溃、死机、死锁、数据丢失等 | 死循环、数据库连接错误、主功能丢失、一级菜单不可用 | ✅ 是 |
| 严重 | 主功能受损但不阻止测试 | 数据保存错误、程序重启、自动退出、接口冲突、安全漏洞 | ⚠️ 部分阻断 |
| 一般 | 功能不全但基本可用 | 查询慢、边界错误、无确认框、格式问题、字段设计不合理 | ❌ 否 |
| 次要 | 界面、体验、建议类问题 | 错别字、提示缺失、页面错位、按钮不对齐、光标位置不正确 | ❌ 否 |
4.bug的⽣命周期
试⼈员在执⾏测试的过程中如有发现bug，需要在对应的bug管理平台来创建bug（bug⽣命起源），创建好的bug需要被开发⼈员修复，以及测试⼈员的持续跟踪和测试。
1.创建一个bug 开发承认->open 2.严重bug||时间宽松->Fixed 进行修改 直到改对->closed。3.一般bug&&时间紧->Delay 暂时不修改 改完->closed
情况 Bug状态流转路径 说明 开发确认是 Bug New → Open进入处理流程 严重 Bug / 时间充裕 Open → Fixed → Closed及时修复并验证关闭 一般 Bug 且时间紧张 Open → Delay → Fixed → Closed延期处理后再修复关闭
3.与开发产⽣争执怎么办
1.先检查⾃⾝，是否bug描述不清楚
2.站在⽤⼾⻆度考虑并抛出问题
3.BUG定级要有理有据
4.提⾼⾃⾝技术和业务⽔平，做到不仅能提出问题，最好也能给出解决⽅案
5.若仍无法达成一致，会推动组织 Bug 评审，由项目组多方共同决策，确保质量与进度的平衡
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
