答案。

编写测试用例是手动测试的基础和验证应用程序功能的关键步骤。

问题背景： 很长一段时间，测试用例一直是质量控制的中心方法：它们使要求验证结构化，并确保测试的可重复性，与测试人员的更换无关。

问题： 主要的困难在于细节过多和准备不足之间的平衡。过于详细的用例会使测试变得单调且缓慢，而过于简洁的用例可能会遗漏重要场景。常见的问题有：

• 与需求的联系不足。
• 漏掉边界情况。
• 场景重复。
• 由于产品变化而过时。

解决方案： 为了有效的测试用例，需要：

• 将每个测试与需求建立联系（可追溯性矩阵）。
• 使用测试设计技术（等价划分、边界值分析）。
• 定期审核和更新测试用例。
• 涉及开发团队和分析师，以澄清复杂问题。

关键特点：

• 结构化原则为“一个测试—一个预期结果”。
• 在需求变更时进行更新。
• 覆盖所有路径，包括负面情况。

带陷阱的问题。

测试用例是否总是在开发之前编写？

不。虽然最好在实施开始之前编写它们（shift-left），但在实践中，测试用例通常会根据新信息的到来或测试环境的出现而不断完善。

一个测试用例是否应仅检查一个场景？

是的，经典原则是：“一个测试—一个结果”使得错误分析和测试内容理解变得更容易。对于端到端场景，可能会有例外，但在这种情况下明确区分预期结果也是很重要的。

是否可以完全信任从需求中自动生成的测试用例？

不。这样的用例通常太过表面，可能会遗漏重要的业务逻辑、边界值或操作组合——需要人工分析。

常见错误和反模式

• 没有根据新要求调整而直接复制旧的用例。
• 漏掉负面场景。
• 使用模糊的措辞（例如，“系统运行正常”）。

生活实例

负面案例

团队使用了未经审查的旧测试文档，并开始使用未根据已更改功能调整的测试用例。

优点：

• 创建新文档节省时间。

缺点：

• 新的业务规则被遗漏，错误只在上线后被发现。

正面案例

测试人员审核了测试用例，与分析师讨论了困难点，找出了过时的用例并进行了新团队的审查。

优点：

• 针对所有场景的有效检查。
• 考虑新的需求，这使得能够在发布前发现错误。

缺点：

• 初期需要更多时间，与团队之间需要沟通。