滥用案例和安全滥用案例是否相同？

是的，差不多。

我认为“滥用”比“滥用”意味着更多的恶意，但它们都意味着人们用你的软件做他们不应该被允许的事情。

虽然我主要同意 Tom77 的回答。从安全角度来看，滥用/误用会导致相同的后果。

但是，我还建议将误用案例用作正在进行的设计和实施审查的输入。尽量减少误用的可能性。如果用户可能不小心误用系统，那么他们的用户满意度也会降低。

词之间还是有歧义的。在 Google 上快速搜索“滥用案例测试”会显示以下内容：

滥用案例可以描述应用程序可能被滥用的情况

我同意滥用案例是滥用案例的一个子集。我也同意 Tom77 建议的虐待案件包含更多的恶意。

但是如果必须画一条线并给出定义：

1. 误用案例将不顾要求地测试应用程序。这些情况有助于确保正确清理字段并优雅地处理错误。“滥用”这个词本身就让我们记住了一些事情：

   • 它应该与用例相反。
   • 它应该填补用例之间留下的空白/漏洞。
   • 它不仅应该包含功能测试，还应该包含可用性测试（因此误用）。
   • 从测试的角度来看：我们正在探索，去我们没有被告知的地方，遵循我们的直觉，试图提高应用程序的质量。

2. 滥用案例还将测试用例之间的差距，但其方式将尽可能对应用程序和环境造成最大的损害。目标是导致错误、损坏数据、破坏稳定性并引发崩溃。

   • 从测试的角度来看：我们尝试使用任何可能的工具来制造尽可能多的破坏。我们讨厌该应用程序，并希望看到它及其用户/用户的数据都被破坏。
   • 如果我们有一个根据“喜欢”的数量对事物进行排名的网站，如果我们能够编辑页面上的 javascript 以允许我们多次喜欢，那么数据就不再具有完整性。
   • 如果我们正在使用带有滑动键盘的手机测试移动应用程序，并且当应用程序的打开或关闭方向发生变化时，我们应该反复打开和关闭键盘以查看应用程序如何处理这种滥用。

滥用案例具有破坏性，只有极少数用户会有这种心态，所以很多时候我发现经理决定最后修复它们，如果有的话。

另一方面，误用案例实际上有助于提高系统质量，我发现在此过程中发现的问题会相对较快地得到修复，或者标记为更改请求/增强功能，以便在不久的将来修复（除了史蒂夫之前提到的内容之外）。

误用案例将不顾要求地测试应用程序。这些情况有助于确保正确清理字段并优雅地处理错误。“滥用”这个词本身就让我们记住了一些事情：

它应该与用例相反。它应该填补用例之间留下的空白/漏洞。它不仅应该包含功能测试，还应该包含可用性测试（因此误用）。从测试的角度来看：我们正在探索，去我们没有被告知的地方，遵循我们的直觉，试图提高应用程序的质量。滥用案例还将测试用例之间的差距，但其方式将尽可能对应用程序和环境造成最大的损害。目标是导致错误、损坏数据、破坏稳定性并引发崩溃。

从测试的角度来看：我们尝试使用任何可能的工具来造成尽可能多的破坏。我们讨厌该应用程序，并希望看到它及其用户/用户的数据都被破坏。如果我们有一个根据“喜欢”数量对事物进行排名的网站，如果我们能够编辑页面上的 javascript 以允许我们多次喜欢它，那么数据就不再具有完整性。如果我们正在使用带有滑动键盘的手机测试移动应用程序，并且当应用程序的打开或关闭方向发生变化时，我们应该反复打开和关闭键盘以查看应用程序如何处理这种滥用。滥用案例具有破坏性，只有极少数用户会有这种心态，所以很多时候我发现经理决定最后修复它们，如果有的话。

另一方面，误用案例实际上有助于提高系统质量，我发现在此过程中发现的问题会相对较快地得到修复，或者标记为在不久的将来修复的变更请求/增强功能（除了史蒂夫之前提到的内容之外）。