多次刷新是Web应用程序的测试用例吗？

#1 楼

是的，尽管这些测试用例虽然很粗糙，而且可能不是最合适的，但这些“滥用”的测试用例却是迈出“快乐之路”思考和测试的重要工具。


有效地，像这样的测试是原始负载/响应测试。

虽然理论上不应该在现实世界中发生这种错误，但实际上，即使最终没有任何资源用于修复，发现这样大量输入导致的错误也应该引起人们的注意。问题。 [“已知问题，无法解决”完全是解决某些问题的合法“解决方案”。我猜...]



为什么这种非标准的输入/交互会导致输入意外的状态/错误？
以上答案是否暴露出来？潜在的安全风险[例如系统为错误的用户获取了不正确的，可能是敏感的数据？]或性能急剧上升？ [例如，某些用户的瞬时超负荷破坏了会话，然后这些用户最终都运行了多次硬刷新来解决问题，这反过来又增加了服务器负载，并导致更多的用户会话破坏？*]

这样的测试可以正常进行，并且可以在两个屏幕/状态之间来回导航。该软件不应该能够在诸如此类的事情上失败，而底层的单元测试应该能够抓住它，但是最终，对于QA而言，应该做的事情并不像在实际情况中那样重要。在做。

“ ...时，某些地方出错了”是在软件中找到的重要点，尽管我们可能更愿意找到更优雅的方式来发现此类问题，但事实是，有时最简单的方式是用隐喻的锤子简单地“随机”击打东西，看看是否有东西破裂。

随着项目的成熟和测试方法的改进，这种情况可能会因支持更有针对性和更优美的解决方案而失效。记住思考“用户在现实世界中永远不会做类似的事情……”的危险也很重要，因为用户是神话中的生物，并且似乎会尽其所能来做开发团队中没有人能做的事情有没有想像过他们在做...


他们是否“激进不耐烦”，如果出现问题，会生气地敲打刷新按钮？
他们是否有行动不便的问题或出现故障的硬件导致大量意外或意外点击？
如果服务器处于负载状态，“快速刷新”错误是否会出现，并且用户实际上在一分钟左右就相当随意地刷新一次，以获取您的站点做出响应？


同时需要考虑资源管理的实际情况。像这样的测试用例可能不太适合于每天都运行的恒定的“前端和中心”操作。


也许将它们分组为一个池，然后针对给定的构建而不是整个池定期运行它们的一个子集。
作为士气事件的一部分可能很有用：拉动与他们选择的食物和饮料进行团队合作，并进行团队合作，“谁可以用最奇怪的方式破坏事物”。


*我已经看到一个客户将他们的服务器要求降低到解决此类问题背后的软件问题后，他们使用了将近八分之一的资源，而不是继续为此花费硬件资金。

#2 楼

可能不会。我想用一个简单的问题来挑战这样的缺陷：实际用户会执行这种行为吗？

在大多数情况下，我不希望用户连续刷新常规页面十次。某些页面可能仅在刷新时更新页面内容，从而迫使用户经常刷新以获取最新数据。我认为这更多的是UX问题。

所以请与用户交谈。他们经常刷新吗？


是的。这是您应该每次运行的测试用例。
否。忽略这个问题。为什么用大量用户永远不会遇到的缺陷淹没开发人员？

我喜欢在一组试探法中添加这样的测试。在探索性测试期间有时会混合使用列表。 10次​​。它是服务器上的负载吗？它是数据库锁定吗？同一时间有10个用户发生了什么。.Ohnoo我的大脑超速运转。也许您遇到了一个真正的问题。做研究吧。

#3 楼

刷新似乎不是一个简单的操作，所以这是一个很好的系统测试。

我已经说过，我会给它较低的优先级，并且只偶尔执行一次，因为它会显着降低其余测试的速度。

#4 楼

每个软件测试公司都会在测试任何功能时遵循测试用例的创建过程。

应针对实际用户在实际环境中将要使用的功能创建测试用例。

仅当在应用程序中应用更改后页面没有自动刷新并且用户必须刷新应用程序2-3次以加载应用程序中完成的所有更改时，才会出现这种情况。对于这种情况，必须创建测试用例来覆盖对应用程序更改的测试，并且它应该是回归的一部分。