负向测试用例—10 个真实示例

在软件测试中，负向测试用例评估系统在用户执行“错误”或意外操作时的行为。此外，负向测试还关注系统在发生这些操作时的响应。这些测试是评估任何软件产品的关键部分，但开发人员有时会在满足初始需求时忽视它们。负向用例偶尔也会包含在需求中，但通常只会遵循“正向路径”。“正向路径”是一个术语，意思是在通用有序的场景中，用户按计划进行并因此而发生预期的行为。

如果用户无视指示或正常使用情况，故意或无意地偏离标准路径，测试人员就会发现负向测试用例。在设计负向测试用例时，我们需要像用户一样思考，试图破坏某些东西。如果我这样做会怎样？如果我尝试那样会怎样？无论多么天马行空，对于每个场景，用户有哪些选择？只要你能想到的，都可以试一试。

这篇文章详细介绍了现实世界中的一些负向测试，并提供了示例以便更容易理解。

负向测试示例

让我们来看看负向测试的一些真实案例。

1. 在输入字段中输入不允许的字符

在输入字段中输入不允许的字符可能是最常用的负向测试。当用户输入不允许的字符时，应显示错误信息。例如，用户名字段可能不允许输入 @ 符号。

当用户尝试使用无效字符提交注册时，会显示一条错误信息，通知用户该要求。通过测试这个场景，我们验证：

1. 显示有关字段要求的消息。
2. 不处理注册。
3. 不显示任何其他错误。
4. 应用程序不会崩溃。

2. 在必填字段中没有任何文本的情况下尝试提交

另一个简单的例子是在必填字段中不输入任何文本。只需将必填字段留空并尝试提交，即可进行负向测试。在这种情况下，我们要验证同样的三件事：

1. 显示有关字段要求的信息。
2. 不处理注册。
3. 不显示其他意外的错误。

3. 对带超链接的按钮使用无效的 URL

假设你正在测试一项新功能，其中包括一个用于将用户带到另一个网站或页面的按钮。当你在 CMS（内容管理系统）中为指定按钮输入一个有效的 URL 时，用户点击该按钮就会打开预定的页面。如果 URL 中有错误怎么办？这显然是一个负向测试案例。要进行测试，可以在 CMS 中为该按钮输入一个无效的URL，然后保存。这样我们就能发现一些问题：

1. CMS 是否保存了包含错误 URL 的更新？
2. 假设 CMS 保存了错误的 URL，点击按钮后会发生什么？
3. 应用程序会崩溃吗？

在这种情况下，我们有可能会在几个地方看到错误。比如，在点击按钮时，我们可能会在CMS中看到一个错误或 404 错误信息。

4. 尝试在不登录的情况下提交评论

为了验证评论字段的功能，我们将在登录后测试大量正向用例。一个负向测试为：尝试在登录之前提交评论。如果用户输入评论，然后在身份验证之前点击提交，他们应该会收到一条错误信息，告知他们这种情况。在测试时，我们必须通过确认以下内容来验证评论是否丢失：

1. 关于身份验证的错误信息显示正确
2. 评论的文字可以保留
3. 不显示任何其他意外错误
4. 应用程序不会崩溃

5. 验证过期后尝试提交

这种情况是上一个测试用例的变体。在某些情况下，出于安全目的，身份验证会在设定的期限后自动过期。在这种情况下，我们会开始填写表单或进行评论/回复，并等到认证过期后再完成提交。尝试提交后，我们将验证以下内容：

1. 正确的认证错误显示
2. 输入的文本没有丢失
3. 未显示其他意外错误
4. 登录后，用户可成功提交之前输入的数据
5. 应用程序不会崩溃

6. 永久过期后尝试提交

在某些情况下，提交是有截止日期的。例如，参加比赛的作品需要在某天午夜前提交。另一个例子是体育赛事，用户必须在比赛前确定获胜者。在这种情况下，我们可以在测试环境中更改截止日期，以验证这种情况。对这种负向用例的验证包括：

1. 向用户显示正确的错误信息，告知其情况
2. 不处理提交
3. 反复尝试提交，不断产生同样的错误
4. 应用程序没有崩溃，也没有出现其他意外错误

7. 验证页面删除后是否出现 404 消息

在有意删除网页后，当用户尝试访问该网页时，应出现定义好的行为。在某些情况下，重定向可以管理用户对丢失页面的期望。或者，预期行为可能是在网站导航栏下方显示一个 404 错误消息。我们必须让用户知道该页面已被特意删除，同时也希望他们点击导航栏来访问网站的其他页面。用户可能是通过社交媒体上的旧链接或者因为他们将该链接加为书签而访问到了这个缺失的页面。无论哪种情况，我们都必须验证预期行为：

1. 未显示意外错误
2. 应该出现预期的404错误消息，包括标准页面布局和站点导航菜单

8. 尝试访问没有权限的页面

当尝试访问受限页面时，应显示标准的403 身份验证错误。这可能出现在用户不再拥有访问权限或有人恶意尝试试图访问时。除了标准 403 错误信息外，还应该显示站点的菜单，为用户提供访问其他内容的方法。对于这种情况，我们将验证：

1. 未显示意外错误
2. 应该出现预期的403错误消息，包括标准页面布局和站点导航菜单
3. 最重要的是，用户无法访问该页面

在用户提交表单、购买或进行银行转账的场景中，我们可以测试一些异常行为，例如用户提交请求后快速刷新。我们可以测试快速刷新一次或多次，看看会发生什么。在这种情况下，我们可以验证：

9. 等待确认信息时手动刷新

在用户提交表单、购物或进行银行转账的场景中，我们可以测试一些异常行为，例如在用户提交请求后快速刷新。我们可以测试快速刷新一次或多次，看看会发生什么。在这种情况下，我们可以验证：

1. 多次提交不会导致重复购买、转账、评论等
2. 不会出现意外错误
3. 确认信息按预期显示

10. 提交后迅速按返回键或退出键

调整用户交互的时机是进行负向测试的另一种绝佳方式。在移动设备上，当工作流向前移动后，快速点击返回（或按下Escape键）有时会导致问题。你还可以尝试快速多次点击返回键，看看会发生什么。这是一个用于简单浏览应用程序或提交评论或审核表单的良好测试。在快速点击或按下返回键后，我们将验证：

1. 最终显示正确的页面
2. 初始请求成功（如果是提交表单）
3. 未出现意外错误
4. 应用程序（尤其是手机应用程序）不会崩溃

结论

在制定测试计划时，没有必要区分正向和负向测试用例。负向测试用例与正向测试用例同样重要，甚至更为重要，因为开发人员在将代码交给质量保证部门之前，通常只会关注正向的“顺利路径”场景。在负向测试场景中发现错误，是质量保证部门真正可以大显身手并体现巨大价值的地方。