破坏性的测试环境
我们的 Web 应用程序非常复杂，很难准确模拟生产负载。
我们的应对机制之一是确保测试环境中的硬件始终比我们的生产硬件慢，因此负载和性能问题将更加明显。
其他人也在这样做吗？您还使用什么其他策略？
We have a web application that is sufficiently complicated that it's hard to accurately simulate production load.
One of our coping mechanisms has been to make sure that the hardware in the test environment is always slower that our production hardware, so load and performance problems will be more pronounced.
Are other folks out there doing this, what other strategies are you using?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我有一台已经用了 7 年、配备 256MB RAM 的 600mHz Celeron 笔记本电脑，我一直保留它用于性能分析。 为了测试网络延迟，您可以获取一个延迟代理（或者简单地编写一个）； 它收到一个数据包，等待 X 毫秒，然后将其传递。
I have a 7-year-old 600mHz Celeron laptop with 256MB RAM that I keep around for performance profiling. For testing network latency, you could get a delay proxy (or write one trivially); it gets a packet, waits X milliseconds, then passes it on.
Fiddler 可以帮助您测试低带宽——可以模拟较慢网络的延迟。
Fiddler can help you test low-bandwidth -- can simulate latency of slower networks.
连接测试人员。 进行一些手动测试，并让他们的代理通过记录您手动执行的操作来编写测试脚本。 使用脚本自动化。
http://www.pushtotest.com/
开源且免费。
Hook up testmaker. Do some manual tests and let their proxy write the test script by recording what you did manually. Automate using the script(s).
http://www.pushtotest.com/
Open source and free.