答案。

自动化负面测试场景是全面测试系统不可或缺的一部分。这是对系统在错误操作、不正确数据、服务故障和其他异常情况下的稳健性进行验证的测试。

问题历史：

以前，主要关注的是正面场景（happy paths），因为它们更容易自动化和维护。然而，对质量的要求提高，越来越多的缺陷出现在边界条件上，以及错误或明显不正确的条件上。这些手动测试很快会过时，而自动化可以跟踪退化。

问题：

• 确定和覆盖所有可能的负面测试场景
• 正确检查错误消息，在操作失败后系统状态的有效性
• 在业务逻辑变更时维护测试

解决方案：

• 提取和系统化负面场景（边界值分析，等价划分）
• 使用自定义断言和验证器来检查错误文本、HTTP代码、异常
• 在负面测试后自动“清理”系统状态

关键特性：

• 明确的 测试设定，用于错误、异常和非标准输入数据
• 检查 错误消息和系统内部状态
• 控制 副作用：负面测试后，系统应保持一致状态

具有挑战性的问题。

仅检查负面测试时返回的错误是否足够？

不够。重要的是不仅要检查错误的内容，还要检查错误后系统状态是否未发生变化（例如，未在数据库中添加不正确的记录）。

需要自动化所有可能的负面测试场景吗？

不需要。可能有无数个场景；应突出最可能和关键的（边界值、空值、不正确的类型、SQL注入等），其余的按需处理。

可以对所有负面案例使用相同的处理方式吗？

不可以。不同的负面场景需要不同的检查、异常处理和回滚，模板断言是不够的。

常见错误与反模式

• 忽视负面场景或仅仅“流于形式”覆盖它们
• 错误检查不够有说服力（例如，仅检查代码500，而不检查文本或副作用）
• 测试失败后未清理测试环境

生活中的例子

负面案例

系统只测试有效的注册场景。未对空邮箱的注册进行自动化测试。结果，出现用户可以使用空邮箱注册的问题，只在生产环境中被发现。

优点：

• 测试支持简单
• 自动化测试数量少，运行快速

缺点：

• 关键缺陷在生产中被发现
• 修复和回退成本增加

正面案例

每个负面场景（缺失邮箱、不正确格式、SQL注入）都有一个自动化测试，明确检查新账户的缺失和错误消息的内容。

优点：

• 早期发现漏洞和缺陷
• 减少生产中的缺陷

缺点：

• 测试数量增加，维护成本提高
• 可能增加清理环境的复杂性