想学程序员去哪里学安卓优化大师官方版本下载
本章思维导图：
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) 站在用户的角度考虑并抛出问题 ---- 功能正常只是测试的一部分，还要考虑用户的感受
3) bug 定级需要有理有据 ---- bug 级别描述文档
4) 提高业务水平，做到不仅能够提出问题，最好也能够提出解决方案
举例：双十一活动
测试新手：双十一活动时间边界值不符合预期
测试大牛: 双十一活动时间边界值不符合预期 修改建议：.......
注意，不要以命令式的口吻去告诉开发人员，术业有专攻，建议只是建议
5) bug 评审
如果确实是 bug ，但不能友好沟通，就召开 bug 评审
Bug评审是软件开发过程中由跨职能团队共同评估、分类和处理缺陷的关键环节，其核心目标是高效分配资源并确保产品质量。
bug 评审需要三个代表参加：测试代表、开发代表、产品代表
bug 评审主要解决两个问题：
- 决定如何处理 bug
- 分析缺陷产生的原因，并找出预防的对策