我一直在自己开发一个应用程序，我正处于一个一切都很好的阶段——只要用户做了他或她应该做的一切。:-) 这个软件需要更多的测试来看看它有多健壮，当人们重复点击同一个按钮、尝试打开错误类型的文件、将数据放在错误的位置等时它的工作情况如何。
我对此有点麻烦，因为我很难考虑错误地使用该应用程序。这些对我来说都是边缘情况。不过，在开始将应用程序提供给 beta 测试人员之前，我希望应用程序尽可能稳定且经过良好测试。假设我现在不是在谈论聘请专业测试人员，我很好奇你们是否有任何提示或系统地思考这项任务。
谢谢，一如既往。
好吧，听起来您在谈论“测试应用程序的功能”和“压力测试”（这是您的问题的标题）这两个不同的东西
压力测试是当你有一个网站，并想检查它是否可以同时为 100,000 人提供服务。查看您的应用程序在压力下的表现。您可以通过多种方式做到这一点，例如通过记录一些操作，然后让多个代理机器同时访问您的应用程序。
这个问题听起来更像是一个质量保证问题。这就是测试人员/ Beta 测试人员的用途。但是您可以自己做一些事情来验证您的应用程序是否能发挥最大作用。
对您的代码进行单元测试将是一个好的开始，它可以帮助您尝试找到那些边缘情况。如果您的方法接受 int 之类的内容，请尝试传入 int.max、int.min 并查看发生了什么问题。将空值传递给所有内容。如果您使用的是 .Net，您可能想查看 PEX，它将通过您的应用程序拥有的所有分支/代码路径。这可能会帮助您进一步完善您的单元测试，以尽可能地测试您的应用程序。
集成测试，看看你的一些常见事情端到端发生了什么。这将帮助您在以后开发时“发现错误”。
这些是一些关于您可以自己尝试并找到您可能错过的边缘情况的快速提示。但是，是的，最终您需要将您的应用程序交给其他人进行测试。只要确保在它击中他们之前你已经尽可能多地掩盖了:-)
确保在单元测试和集成测试中有足够的代码覆盖率。
使用适当的 UI 验证，并测试可能破坏它的组合。
我发现一个架构良好的应用程序可以减少 UI 中可能的排列数量（用户可以打破它的方式）有很大帮助。像 MVC 这样的设计模式在这方面特别有用，因为它们使你的 UI 面板尽可能薄。
自动化。
（重新）分解您的代码，以便另一个程序可以向它抛出用户事件。创建用户事件的简单脚本并将它们回放到您的程序中。捕获来自 beta 用户的事件并将其保存为测试脚本（对于重现问题和检查回归很有用）。编写一个模糊测试器，对脚本应用小的随机更改，并针对您的程序尝试它们。
通过这种自动化，您可以强调应用程序并发现缓存和内存泄漏等明显问题。它不会测试实际功能。对于功能，单元测试可能会有所帮助。有大量的单元测试框架可供尝试。选择一些有用的东西，学习编写好的测试，并将它们集成到你的构建过程中。