1.软件测试的生命周期
软件测试贯穿于软件的整个生命周期：软件测试的生命周期（Software Testing Life Cycle, STLC）,是指测试流程，这个流程是按照一定顺序执行的一系列特定的步骤，去包正产品质量符合需求。
分为：需求分析 —> 测试计划 —> 测试设计&测试开发 —> 测试执行 —> 测试评估 —> 上线 &运行维护
**需求分析：**理解并验证软件需求是否完整、明确、可测试；要求测试团队深入理解产品的功能和性能要求
- 关键活动：
- 参与需求评审会议
- 确定测试范围
- 分析哪些功能可以自动化测试
- 制定初步的风险评估
- 交付：需求可测性报告、测试需求清单
- 关键活动：
**测试计划：**制定详细的测试策略和计划，确保资源、时间和人力合理安排；制定出一个全面的测试策略，包括资源分配、时间线安排和测试环境搭建
- 关键活动：
- 确定测试类型
- 规划测试环境、工具和框架
- 安排人员分工和时间表
- 风险识别与应对方案
- 交付：测试计划文档（Test Plan）
- 关键活动：
**测试设计 & 测试开发：**基于需求和测试计划，创建具体的测试用例和脚本；每个测试用例都应覆盖特定的功能或应用场景，并且明确预期和结果和成功标准
- 关键活动：
- 编写测试用例
- 准备测试数据
- 开发自动化测试搅拌
- 评审测试用例
- 交付：测试用例文档、测试脚本、测试数据集
- 关键活动：
**测试执行：**按照测试用例执行测试，发现记录缺陷；测试人员将执行事先设计号的测试用例，并对软件的行为进行观察和记录
- 关键活动：
- 执行测试用例
- 记录测试结果
- 提交缺陷报告
- 回归测试
- 交付：测试执行日志、缺陷跟踪报告、测试进度报告
- 关键活动：
**测试评估：**评估测试完成情况和产品质量状态；测试团队会汇总测试结果，分析数据，评估软件的整体质量，并提出是否发布产品的建议
- 关键活动：
- 分析测试覆盖率
- 汇总缺陷分布及严重程度
- 评估是否达到测试出口标准
- 输出测试总结报告
- 交付：测试总结报告（Test Summary Report）、质量评估报告
- 关键活动：
**上线 & 运行维护：**保障系统上线后的稳定运行，并持续优化产品质量；包括报告和修复发现的缺陷，并涉及对缺陷解决过程的跟踪和验证
- 关键活动：
- 上线前的最终回归测试或冒烟测试
- 支持上线部署
- 监控生产环境中的问题
- 对用户反馈进行分析并协助修复问题
- 交付：上线检查清单、运维支持文档、版本发布说明
- 关键活动：
软件测试生命周期（SDLC）与 软件开发生命周期（SDLC）的关系
| SDLC阶段 | STLC对应阶段 |
|---|---|
| 需求分析 | 需求分析 |
| 设计阶段 | 测试计划、测试设计 |
| 编码阶段 | 测试开发、单元测试 |
| 测试阶段 | 测试执行 |
| 部署阶段 | 上线测试、验收测试 |
| 维护阶段 | 回归测试、缺陷修复验证 |
2. BUG
BUG(缺陷/错误)：一个计算机bug指在计算机中存在的一个错误（error）、缺陷（flaw）、疏忽（mistake）或者故障（fault），导致程序不能按照预期工作。BUG产生于代码中的逻辑错误、设计疏漏、数据处理不当，或与需求文档不符的功能表出现。
BUG 是软件中不符合预期的行为或状态，是影响软件质量的重要因素。
准确来说：
- 当且仅当规格说明是存在并且正确，程序与规格说明之间的不匹配才是错误
- 当需求文档中没有提到的功能，判断标注以用户为标准；当程序中没有实现其最终用户合理预期的功能请求是，就是软件有错误
2.1 表述BUG的要素
BUG的要素：是指在提交一个缺陷（bug）报告时，必须包含的基本信息，用于帮助开发人员快速理解问题、定位原因并进行修复。
Bug的六大核心要素
| 要素名称 | 说明 |
|---|---|
| 1. Bug标题（Summary / Title） | 简明扼要地描述问题的核心，便于识别和搜索。 |
| 2. Bug描述（Description） | 清晰描述Bug出现的场景、影响范围及具体现象。 |
| 3. 重现步骤（Steps to Reproduce） | 明确的操作流程，使他人可以复现该Bug。 |
| 4. 实际结果 vs 预期结果 | 对比程序实际行为与预期行为，明确偏差。 |
| 5. 环境信息（Environment） | 提供软硬件环境、系统版本、浏览器等关键信息。 |
| 6. 附件/截图/日志（Attachments） | 提供截图、录屏或日志文件作为证据支持。 |
2.2 BUG级别
Bug级别（也称为缺陷严重性或Severity）是指根据软件缺陷对系统功能、性能或安全性的影响程度来分类。不同级别的Bug反应了它们对用户体验、系统稳定性以及业务目标的影响大小，从而帮助团队决定修复这些Bug的优先级。
通过Bug级别也能体现出开发人员的开发质量。
bug级别一般分为：崩溃、严重、一般、次要
- 崩溃（Critical/Blocker）：导致系统无法运行或核心功能完全失效
- 阻碍开发或测试工作的问题
- 造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失
- 严重（Major/High）：核心业务流程受阻，但系统仍可部分运行
- 系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级菜单不能使用但是不影响其他功能的测试。
- 功能设计与需求严重不符，模块无法启动或调用，系统重启、自动退出，关联程序间调用冲突，安全性、稳定性等。
- 一般（Moderate/Medium）：功能有缺陷，但不影响主流程
- 功能没有完全实现但不影响使用，功能菜单存在缺陷但不会影响系统稳定性
- 次要（Minor/Low）：外观问题或轻微逻错误，不影响使用
- 界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等
2.3 BUG的声命周期
Bug的生命周期（Defect Life Cycle）：也称为缺陷生命周期，是指一个Bug从被发现开发直到最终关闭所经历的一系列状态。
