本章思维导图：
1. 软件测试的生命周期
软件测试贯穿于整个软件的生命周期
| 流程阶段 | 需求分析 | 测试计划 | 测试设计/开发 | 测试执行 | 测试评估 | 上线 | 运行维护 |
|---|---|---|---|---|---|---|---|
| 具体工作内容 | 1. 阅读需求文档 2. 标记可测试需求 3. 确定测试类型 | 1. 制定测试范围 2. 选择测试工具 3. 分配资源 | 1. 编写测试用例 2. 准备测试数据 3. 开发自动化脚本 | 1. 执行测试用例 2. 记录结果 3. 提交缺陷 | 1. 统计缺陷 2. 计算覆盖率 3. 编写报告 | 1. 部署软件 2. 验证功能 3. 监控运行 | 1. 收集反馈 2. 修复缺陷 3. 性能优化 |
其中，上线流程并不是一步就完成的，而是分为多步进行， 环境分为线上环境 和线下环境
- 线下环境：开发和测试人员测试使用
- 线上环境：用户使用
线下环境测试完成后，就需要进行上线，上线又分为 沙盒测试、小流量、全流量、全线上
- 沙盒测试：企业内部的员工使用
- 小流量：只有一部分的用户能够使用
- 全流量：大部分用户能够使用
- 全线上：所有线上的用户都能够使用
| 测试/发布类型 | 沙盒测试 (Sandbox Testing) | 小流量 (Canary Release) | 全流量 (Full Release) | 全线上 (Production) |
|---|---|---|---|---|
| 定义 | 在隔离的测试环境中模拟生产环境进行测试 | 将新版本先发布给少量真实用户进行验证 | 新版本对所有用户开放，但尚未完全取代旧版本 | 新版本已完全取代旧版本，成为线上唯一版本 |
| 具体工作内容 | 1. 搭建与生产隔离的测试环境 2. 模拟用户请求和数据 3. 验证核心功能与异常场景 | 1. 选择小部分用户或流量（如1%-5%） 2. 监控用户行为和数据指标 3. 快速回滚发现问题 | 1. 逐步扩大用户覆盖范围（如50%-100%） 2. 持续监控系统稳定性 3. 与旧版本并行运行验证 | 1. 完全下线旧版本 2. 全量用户使用新版本 3. 长期监控和优化 |
| 目的 | 提前发现功能或性能问题，避免影响真实用户 | 降低风险，通过真实用户反馈验证版本稳定性 | 确保新版本在大规模流量下的稳定性 | 完成版本迭代，进入稳定运维阶段 |
| 风险等级 | 无用户影响 | 低风险（影响范围可控） | 中风险（需快速响应问题） | 高风险（需确保100%稳定性） |
| 适用场景 | 新功能开发完成后内部验证 | 重大更新或架构改动前的验证 | 确认小流量无问题后的全面推广 | 最终稳定版本的长期运行 |
2. Bug
2.1 bug 的概念
「Debug」的由来
计算机史上第一个著名的"Bug"诞生于1947年9月9日，哈佛大学的Grace Hopper团队在调试马克II计算机时，发现一只飞蛾卡死在继电器中导致机器故障。他们幽默地将这只蛾子贴在日志本上，标注"First actual case of bug being found"，从此"bug"成为程序缺陷的代名词，"debug"则指排除故障的过程。这个真实的小故事不仅创造了计算机领域的经典术语，更生动展现了工程师们解决问题的智慧------再复杂的技术问题，往往源于最意想不到的细节。如今保存在史密森尼博物馆的那只飞蛾，成为了计算机发展史上最有趣的文物之一。
定义：在软件测试中，Bug（缺陷） 是指软件系统中存在的任何不符合预期行为或需求的问题。Bug 可能导致功能失效、性能下降、安全漏洞或用户体验不佳。
简单理解：任何与需求文档、设计规范或用户期望不一致的问题，均可称为 Bug。
就比如说当需要一个列表功能，其中有几千上万个选项
但是需要用户一个一个往下翻才能找到想要的，而不能直接检索关键字来确定范围
此时该功能和用过需求有了冲突 ，此时就可以提一个 bug
当我们进行测试的时候，我们不需要过分关注程序里的代码是如何写的，重点关注的是该程序的输入输出是否符合我们的预期
例如一个排序程序，里面的实现方式可能是冒泡排序，快速排序，归并排序........
不用管，只需要看无序数组经过程序运行后是否变得有序就行
2.2 描述 bug 的要素
为什么描述 bug 还要有要求？
在心理学上说，在编写文档是，人们想要表达的和实际书写的文档往往会南辕北辙。而不清楚，不确定的描述更是可能误导开发人员，倒是沟通低效，工作质量低。因此，一个清晰、完整的 Bug 描述能帮助开发人员快速定位 和修复问题。
描述 bug 的基本要素：
问题标题、问题出现的版本、问题出现的环境、问题出现的步骤、预期结果、实际结果
拿浏览器打开同一个网址来举例：
同一个网址，某些浏览器打开会出现页面显示错误，会出现图片错位的情况，以这个 bug 来描述
问题标题：浏览器兼容性问题导致页面图片错位
问题出现的版本：网站版本 v2.1.0（举例）
问题出现的环境：Safari 16.6 / Edge 117（异常环境） Chrome 118 / Firefox 118 （正常环境）
问题出现的步骤：
使用 Safari 16.6 或 Edge 117 浏览器。
访问网址：
https://example.com/product/123。滚动页面至「产品详情」模块。
预期结果：图片应与文字描述对齐，布局符合设计稿
实际结果 ：图片向右偏移 50px，与文字重叠
2.3 bug 级别
| 级别 | 类型 | 描述 | 示例 |
|---|---|---|---|
| Critical | 严重程度 (Severity) | 导致系统崩溃、数据丢失或核心功能完全不可用 | 支付失败但扣款成功、数据库数据损坏 |
| Major | 严重程度 (Severity) | 重要功能异常，但系统可降级运行 | 商品搜索返回错误结果、图片错位影响操作 |
| Minor | 严重程度 (Severity) | 非核心功能问题，用户体验受损 | 字体颜色不符设计稿、次要按钮无响应 |
| Trivial | 严重程度 (Severity) | 微小瑕疵，不影响功能 | 控制台无关警告、拼写错误 |
| P1 | 优先级 (Priority) | 必须立即修复（阻塞开发/上线） | 所有用户无法登录、关键业务流程中断 |
| P2 | 优先级 (Priority) | 高优先级，需在当前版本修复 | 部分用户遭遇数据展示错误（如浏览器兼容性问题） |
| P3 | 优先级 (Priority) | 可延期至后续版本修复 | 低频率UI错位，不影响核心功能 |
| P4 | 优先级 (Priority) | 修复成本高于收益，可能永不修复 | IE11浏览器下的边缘样式问题 |
2.4 bug 的生命周期
| 状态 | 描述 | 常见操作 |
|---|---|---|
| New | 测试人员新发现的缺陷，尚未分配 | 提交Bug报告 |
| Assigned | 缺陷已分配给开发人员，等待修复 | 开发认领任务 |
| In Progress | 开发人员正在修复中 | 代码修改、本地测试 |
| Fixed | 开发完成并部署到测试环境，等待验证 | 标记为"已修复" |
| Verified | 测试人员确认缺陷已解决 | 回归测试通过 |
| Closed | 缺陷完全关闭，流程结束 | 归档至历史记录 |
| Rejected | 开发认为不是缺陷（如需求理解错误） | 需产品经理仲裁 |
| Deferred | 暂不修复（如低优先级、下个版本处理） | 记录延期原因 |
| Reopened | 验证时问题复现，重新激活（从Verified/Fixed回到Assigned） | 重新分配开发 |
流程图：
2.5 与开发发生争执应该怎么做
1)先检查自己，是否 bug 描述不清楚
2)站在用户的角度考虑并抛出问题 ---- 功能正常只是测试的一部分，还要考虑用户的感受
-
bug 定级需要有理有据---- bug 级别描述文档
-
提高业务水平，做到不仅能够提出问题，最好也能够提出解决方案
举例：双十一活动
测试新手：双十一活动时间边界值不符合预期
测试大牛: 双十一活动时间边界值不符合预期 修改建议：.......
注意，不要以命令式的口吻去告诉开发人员，术业有专攻，建议只是建议
- bug 评审
如果确实是 bug ，但不能友好沟通，就召开 bug 评审
Bug评审是软件开发过程中由跨职能团队共同评估、分类和处理缺陷的关键环节，其核心目标是高效分配资源并确保产品质量。
bug 评审需要三个代表参加：测试代表、开发代表、产品代表
bug 评审主要解决两个问题：
- 决定如何处理 bug
- 分析缺陷产生的原因，并找出预防的对策