回答。

确定测试范围（scope）是手动测试的基础任务，可以集中精力于应用程序中最相关和关键的部分。

问题背景

随着项目的发展，待测试功能的数量不断增加，手动覆盖所有场景变得不可能。随着敏捷/增量开发的出现，确定范围的角色变得更加重要。

问题

如果测试范围模糊，将面临风险：

• 进行无效的测试，浪费资源在不重要的功能上
• 忽略重要场景中的关键缺陷
• 与其他测试人员的工作重叠，造成重复

解决方案

测试范围应基于以下内容确定：

• 业务优先级、用户场景和风险
• 需求分析、用户故事和规格说明
• 与团队（分析师、产品经理、开发人员）的咨询

关键特点：

• 聚焦于主要功能和风险区域
• 在测试计划中明确记录/文档化覆盖范围，以避免误解
• 在需求变化时能够快速重新审视范围

难题。

是否总是需要测试实现的所有内容，包括最小的细节？

不是，测试原则是关注优先和关键部分，尤其是在错误最有可能发生的地方，这些错误会对业务产生重大影响。

测试人员能否在没有沟通的情况下自行扩展或缩小范围，特别是当出现新需求时？

不能，任何范围的变更都必须与产品经理或团队负责人协商，以避免漏洞或重复工作。

仅依赖技术文档来确定范围是否足够？

不是，还需考虑业务背景、实际用户任务和客户反馈。

常见错误和反模式

• 范围未固定且不断变化
• 忽视业务优先级而偏向次要功能
• 在改变测试范围时缺乏团队成员之间的沟通

生活中的例子

负面案例

测试人员自行决定覆盖所有功能和用例，最终没有时间测试关键路径，主要缺陷被忽略。

优点：

• 在形式上测试了许多场景

缺点：

• 由于注意力分散，关键阻塞缺陷未被发现
• 由于不必要的测试量而导致截止日期延误

正面案例

在冲刺开始时，测试人员参与规划，和整个团队一起记录范围，强调最重要的用户场景，商定工作量并在Confluence中记录。

优点：

• 提高找到关键缺陷的可能性
• 明确理解“我们在做什么”和“我们不做什么”
• 最小化重复努力和产品风险

缺点：

• 需要时间进行沟通和准备