有效地规划和构建手动测试工作，以实现最大的覆盖范围和效率规划新功能的测试方法在 API 和浏览器测试之间做出决定组织回归测试确定测试场景的优先级了解不同测试级别的平衡 UI 中的端到端用户流程关键用户路径、快乐路径、关键工作流程缓慢、脆弱，但最接近用户体验登录流程、结账流程、注册 <目的>直接使用curl测试API端点 API 契约、错误处理、集成点比浏览器测试更快，专注于数据和响应 <示例>CRUD 操作、身份验证、错误响应 <目的>无需详细脚本即可探索和发现问题新功能、查找边缘情况、理解行为 <特点>灵活、有创意、发现意想不到的问题尝试不寻常的输入，以新颖的方式组合功能 <目的>对记录的场景进行结构化、可重复的测试回归测试、功能覆盖率、文档一致、可追踪、涵盖已知场景冒烟测试、健全性测试、功能检查表何时通过 API 与浏览器进行测试 API 测试明显快于浏览器测试更喜欢 API 来提高速度，更喜欢浏览器来进行 UX 验证 <因素名称=“复杂性”> 浏览器测试可以测试复杂的 UI 交互用于多步骤流程的浏览器，用于单个操作的 API <因素名称=“焦点”> API测试注重数据，浏览器测试注重用户体验用于数据验证的 API、用于 UI 行为的浏览器 <因素名称=“稳定性”> API 测试比浏览器测试更脆弱用于回归的 API、用于关键用户路径的浏览器 <因素名称=“覆盖范围”> 浏览器测试涵盖前端+后端用于端到端流程的浏览器，用于后端逻辑的 API CRUD 操作（创建、读取、更新、删除）身份验证和授权错误处理和状态代码数据验证和清理端点性能测试测试与外部服务的集成批量操作和批量操作直接测试业务逻辑用户流程和工作流程 UI 交互（点击、表单、导航）视觉回归和布局问题响应式设计和移动测试前端状态管理用户体验和可用性复杂交互（拖放、模式）辅助功能测试基于好奇心和经验的非结构化测试没有详细的测试计划或脚本测试人员动态设计测试专注于学习和发现发现边缘案例和意外问题在开发早期，当功能发生变化时为了了解新功能的行为当时间有限但需要广泛覆盖时结构化测试未发现问题后对于难以编写脚本的复杂功能章程 - 会议的任务和重点时间范围 - 会议持续时间（通常为 60-90 分钟）要探索的领域 - 要调查的特定模块或功能注释 - 观察、错误、问题发现的问题 - 发现的错误和缺陷后续 - 向开发人员提出的问题或进一步的测试需求根据经验，猜测可能出现错误的地方边界值、异常输入、快速操作 <技术名称=“数据流测试”> 通过系统跟踪数据检查数据如何存储、检索、转换 <技术名称=“状态测试”> 测试不同的系统状态和转换 <示例>登录与注销、空数据库与完整数据库 <技术名称=“场景测试”> 测试真实的用户场景 <示例>用户在流程中取消，使用后退按钮快速验证主要功能是否有效确定系统是否足够稳定以进行详细测试仅测试关键路径执行速度非常快仅测试快乐路径无深度边缘情况测试新部署之后开始全面回归之前系统出现严重问题时每天或会话首次测试代码合并之前 <典型_smoke_test_scenarios> 应用程序加载并可访问用户可以登录主导航正常运行核心 CRUD 操作正常运行数据库连接稳定外部服务可访问如果冒烟测试失败，请勿继续进行详细测试立即报告关键问题如果冒烟测试失败则阻止部署全面测试，确保现有功能仍然有效查找新更改引入的回归涵盖所有主要功能测试以前工作的功能包括边缘情况和负面场景耗时但全面在主要版本之前在重大代码更改之后定期捕获细微的回归在重构之后在修复关键错误时测试所有特性和功能在主要版本或重大更改之前高时间投入最大覆盖范围 <策略名称=“部分回归”> 仅测试受影响的功能和依赖项有针对性的更改或错误修复后 <成本>降低时间投入 <覆盖>目标覆盖 <策略名称=“基于风险的回归”> 优先考虑高风险和常用功能时间有限时优化时间投入 <覆盖>专注于关键领域核心业务逻辑常用功能以前有缺陷的区域复杂功能模块之间的集成点高风险区域（支付、身份验证）重点测试最近更改或修复的功能验证特定更改是否按预期工作范围狭窄，专注于更改以错误修复和新功能为目标比完全回归更快可能包括受更改影响的相关领域错误修复后功能实现后合并到主分支之前测试特定模块时确定更改的内容（代码、配置、数据）确定受影响的功能为更改区域创建重点测试场景测试快乐路径和边缘情况验证相关功能没有损坏记录发现的任何问题在时间有限的情况下根据重要性进行测试有多少业务会受到影响严重：阻碍业务运营高：对用户产生重大影响中：中等影响低：轻微或罕见影响该功能的使用频率每日：非常频繁使用每周：定期使用每月：偶尔使用稀有：不常用受影响的用户数量所有用户：适合所有人的核心功能许多用户：受欢迎的功能部分用户：利基功能用户很少：很少使用失败风险和后果严重：安全、数据丢失、付款高：主要功能损坏中：次要功能损坏低：小问题或边缘情况高业务影响 + 高频率 = 关键优先级高业务影响 + 低频率 = 高优先级低业务影响 + 高频率 = 中优先级低业务影响 + 低频率 = 低优先级在测试用例和检查表之间进行选择详细的、脚本化的测试场景用于需要可重复的回归测试当记录确切的步骤和期望时对于新测试人员或培训当测试合规性或受监管的场景时对于复杂或关键功能详细、可重现、可跟踪创建耗时，可能会错过探索性问题评估和管理测试覆盖率测试功能的百分比测试功能计数/功能总数核心功能：100%，次要功能：80-90% <维度名称=“场景覆盖范围”> 覆盖的测试场景百分比执行场景计数/记录场景总数关键场景：100%，正常场景：80-90% <维度名称=“路径覆盖范围”> 测试的代码路径的百分比对测试路径进行计数/可能路径总数幸福路径：100%，边缘情况：70-80% 跟踪每个模块或功能的覆盖率轻松识别未经测试的模块 <策略名称=“风险覆盖范围”> 优先考虑高风险区域，实现全覆盖专注于最关键的功能将覆盖范围映射到用户工作流程 <好处>确保关键用户路径经过充分测试 <时间管理> 有效管理测试时间为测试活动分配固定时间探索性测试60分钟，冒烟测试30分钟防止过度测试，保证多区域覆盖 <策略名称=“基于会话的测试”> 将测试组织到有针对性的会议中上午会议：API 测试，下午会议：UI 测试 <好处>结构化方法，每次会议的明确目标 <策略名称=“MVP 测试”> 首先测试最小可行集 <示例>测试快乐路径，然后测试边缘情况，然后测试负面情况 <好处>在详细测试之前确保核心功能正常工作 <策略名称=“基于风险的优先级”> 先测试高风险项目 <示例>严重错误 > 主要错误 > 小错误 <好处>首先发现并解决最重要的问题如何构建测试会话了解目标需要测试什么以及为什么新功能、错误修复验证、回归测试 <步骤编号=“2”> <名称>收集信息需求、设计文档、以前的错误阅读票证、检查 PR 描述、审查问题 <步骤编号=“3”> <名称>选择方法决定测试方法 <示例>API 与浏览器、结构化与探索性 <步骤编号=“4”> <名称>创建或选择工件测试用例、清单或探索性章程使用现有的测试用例，创建新的清单，定义章程 <步骤编号=“5”> <名称>设置环境准备测试环境和数据获取测试账号、准备测试数据、配置环境 <步骤编号=“6”> <名称>执行测试运行测试并记录结果遵循测试用例，完成检查表，探索 <步骤编号=“7”> <名称>报告结果记录发现和错误创建错误报告，更新测试用例状态，编写摘要

测试策略

包含技能