滥用案例和滥用案例

#1 楼

为安全起见，滥用案例和滥用案例是否相同？


是的，非常。

我认为“滥用”比“滥用”，但它们都等于有人在使用您的软件做事，不允许他们这样做。

#2 楼

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

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

#3 楼

词之间仍然存在歧义。 Google快速搜索“滥用案例测试”，结果表明：


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



但是如果必须划清界限并给出定义，则为：



一个滥用案例将在不考虑要求的情况下测试应用程序。这些情况对于确保正确清理字段并妥善处理错误很有用。 “滥用”一词本身使我们记住以下几点：


它应该与用例相反。
它应该填补空白。 /用例之间还留有漏洞。
它不仅应该包含功能测试，还应该包含可用性测试（因此会导致误用）。

从测试的角度来看：我们正在探索，探索过去的地方按照我们的直觉，并没有试图提高应用程序的质量。



滥用案例也将测试用例之间的差距，但以一种方式这将尝试对应用程序和环境造成最大的伤害。目的是造成错误，损坏数据，破坏稳定性并引起崩溃。



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


滥用案例具有破坏性，只有极少数的用户会有这种想法，所以很多时候我发现经理决定最后解决它们，另一方面，

滥用案例实际上可以解决并帮助提高系统质量，而且我发现在此过程中发现的问题可以相对较快地解决或标记出来。作为更改请求/增强功能，将在不久的将来得到解决（这是Steve前面提到的内容的补充）。