【背诵2025】测试
测试项目的一般流程
- 需求分析：理解项目需求和测试目标，确定测试范围，识别测试重点和难点；
- 测试计划：制定测试策略和资源安排，编写测试计划文档（目标、范围、资源、进度、风险）冒烟测试→全量测试→回归测试，选择测试方法，确定测试环境；
- 测试设计：设计测试用例（覆盖功能、边界值、异常场景），准备测试数据（正常数据、异常数据、大数据量），评审测试用例（确保覆盖率和有效性）；
- 测试环境搭建：准备测试所需的硬件、软件和网络环境；
- 测试执行：冒烟测试（核心功能优先）→全量测试（覆盖所有用例），执行测试用例并记录结果，提交bug并跟踪修复进度；
- 缺陷管理：确保bug被有效修复，报告bug、验证bug修复、跟踪bug直至关闭；
- 回归测试：确保新代码或修复未引入新问题；
- 测试报告与总结：评估测试结果并总结项目，编写测试报告（测试覆盖率、缺陷统计、风险分析），总结测试经验（优化流程、改进测试用例）；
- 测试收尾：归档测试用例、脚本、数据，并释放资源。
需求清理、用例全面、工具辅助、闭环思维
保证无遗漏无重测的方法
无遗漏：正向反向用例结合，正向验证确认功能按需求正常运作，反向验证检查异常处理能力，边界值分析测试极限情况。
无重测：每个用例分配ID并与需求关联，合并相似用例。
常用的测试方法
| 维度 | 黑盒测试（Black-Box Testing） | 白盒测试（White-Box Testing） |
|---|---|---|
| 测试对象 | 软件外部功能（输入/输出） | 软件内部结构（代码、逻辑、路径） |
| 视角 | 用户视角（不关心实现） | 开发者视角（需了解代码） |
| 目标 | 验证功能是否符合需求 | 确保代码逻辑正确性、覆盖率 |
| 是否需要代码 | 不需要 | 需要 |
| 功能 | 验证功能正确性（通过输入输出验证） 系统测试、验收测试阶段 | 检测代码缺陷，覆盖隐性需求 单元测试、集成测试阶段 |
| 典型场景 | 功能测试：验证需求文档中的功能（如登录、支付）。 兼容性测试：不同浏览器/设备的表现。 用户验收测试（UAT）：业务方确认系统是否符合预期。 安全测试（部分）：如渗透测试（模拟外部攻击）。 | 单元测试：开发阶段验证函数/方法逻辑。 代码审查：静态分析代码质量（如SonarQube）。 覆盖率测试：确保代码分支/语句被充分执行。 性能优化：分析代码瓶颈（如算法复杂度）。 |
白盒测试
| 方法 | 说明 | 示例 |
|---|---|---|
| 语句覆盖 | 确保每行代码至少执行一次 | 测试if-else的所有分支 |
| 分支覆盖 | 验证所有条件分支（如if/switch） | 覆盖if (x>0)和else |
| 路径覆盖 | 测试所有可能的代码路径 | 循环嵌套中的不同路径组合 |
| 条件覆盖 | 确保每个逻辑条件取True/False | 测试(A && B)的所有可能值 |
| 静态代码分析 | 工具检查代码缺陷（如内存泄漏） | 使用SonarQube扫描代码 |
黑盒测试的8种测试方法
1.等价类划分
等价类划分是将系统的输入域划分为若干等价类，然后从每个类选取少量代表性数据进行测试。等价类可以划分为有效等价类和无效等价类，设计测试用例的时候要考虑这两种等价类。
有效等价类：对于程序的需求规格说明来说是合理的，有意义的输入数据，利用有效等价类检验程序是否实现功能；
无效等价类：利用无效等价类可检验程序对于无效数据的异常处理能力。
示例：测试登录功能时，将密码分为“有效密码”（符合规则）和“无效密码”（过短/含特殊字符）。
2.边界值分析法
边界值分析法是对等价类划分的一种补充，因为大多数错误都在输入输出的边界上。边界值分析就是假定大多数错误出现在输入条件的边界上，如果边界附件取值不会导致程序出错，那么其他取值出错的可能性也就很小。
边界值分析法是通过优先选择不同等价类间的边界值覆盖有效等价类和无效等价类来更有效的进行测试，因此该方法要和等价类划分法结合使用。
示例：输入年龄范围是1~100岁，测试0、1、2、99、100、101等值。
3.正交试验法
用数学方法减少测试用例数量，覆盖多因素组合（适用于配置测试）。正交是基于正交表，将多个因素的不同水平进行组合，从大量的试验点中挑选出适量的、有代表性的点。保证各个因素之间相互独立，以避免因素间的干扰。正交试验设计是研究多因素多水平的一种设计方法，已确定各个因素之间的相互作用和最优的因素组合，是一种基于正交表的高效率、快速、经济的试验设计方法。
示例：测试跨浏览器兼容性时，选择代表性的OS+浏览器+分辨率组合。
4.状态迁移法
状态迁移法是对一个状态在给定的条件内能够产生需要的状态变化，有没有出现不可达的状态和非法的状态，状态迁移法是设计足够的用例达到对系统状态的覆盖、状态、条件组合、状态迁移路径的覆盖。状态迁移法不保证单个功能的正确性，只考虑状态之间的转化是否和需求一致。
示例：ATM机从“待机”→“输入密码”→“取款”→“结束”的状态流程测试。
5.场景测试
模拟真实用户场景（端到端流程）验证系统行为。
示例：测试在线购物流程：搜索商品→加入购物车→支付→订单生成。
6.判定表分析法
基于业务规则组合输入条件，生成测试用例表格。判定表是分析和表达多种输入条件下系统执行不同动作的工具，可以把复杂的逻辑关系和多种条件组合的情况表达的即具体又明确；
示例：电商优惠券规则（会员等级+订单金额）对应不同折扣，组合测试所有可能情况。
7.因果图法
因果图是用于描述系统输入输出之间的因果关系、约束关系。因果图的绘制过程是对被测系统的外部特征的建模过程，根据输入输出间的因果图可以得到判定表，从而规划出测试用例。
示例：提交表单时，必填字段（原因）与错误提示（结果）的关联测试。
8.错误推测法
错误猜测法主要是针对系统对于错误操作时对于操作的处理，从而设计测试用例。
示例：测试文件上传功能时，尝试上传超大文件或非允许格式。
| 方法 | 适用场景 | 优点 |
|---|---|---|
| 等价类划分 | 输入数据范围明确（如注册表单） | 减少冗余测试用例 |
| 边界值分析 | 数值型输入（如年龄、金额） | 高效发现边界错误 |
| 正交试验法 | 多参数组合测试（如配置兼容性） | 用最少用例覆盖最多组合 |
| 状态转换测试 | 状态驱动的系统（如登录流程） | 验证状态切换是否正常 |
| 场景测试 | 用户实际使用路径（如电商下单） | 贴近真实业务需求 |
| 判定表测试 | 多条件组合业务规则（如促销活动） | 覆盖所有逻辑分支 |
| 因果图测试 | 复杂输入输出逻辑 | 避免遗漏关键组合 |
| 错误推测法 | 经验丰富的测试场景 | 快速定位隐蔽缺陷 |
测试项总结
| 测试项 | 测试目的 | 常见bug | |
|---|---|---|---|
| 功能测试 | 表单测试 | 确保软件按预期运行，提升质量与用户体验。确保需求实现，发现隐藏缺陷，保障系统稳定性，满足合规要求。 | |
| 链接测试 | |||
| 业务流程测试 | 逻辑错误：条件判断错误、计算错误 | ||
| 数据验证 | 数据问题：数据未保存、数据一致性 | ||