答案1
首先，从业务代表开始。他们（应该）最了解应用程序。确定关键事务和端到端响应时间。理想情况下，他们将能够向您提供一份文档，其中包含他们的非功能性需求。如果您的应用程序正在替换旧版应用程序，那就更好了 - 从该应用程序获取尽可能多的适用使用指标。这是性能测试最关键的成功因素。了解潜在用户群的规模、可能同时使用它的用户数量、每个关键事务同时执行的百分比、每个 [时间范围] 的增长率。
构建一个自动化脚本来模拟关键事务。在这个脚本中包含思考时间。很少有用户会在不花几秒钟时间查看应用程序对他们的输入做出响应的情况下浏览您的应用程序/网站。如果不能充分模拟思考时间，您的应用程序将承受不切实际的负载，从而导致各方的不满。话虽如此，企业可能会发现 10% 的用户群是高级用户，您可能希望以“正常”思考时间向 90% 的普通用户提供负载，以更快、更积极的思考时间向 10% 的高级用户提供负载。
在一段时间内（加速时间）添加虚拟用户 - 不要在 1 秒内从 0 增加到 500，除非您确实有这种负载（销售从上午 9:00 开始！）。了解您的应用程序在负载峰值下的表现是很好的，但有些应用程序可能会在这些情况下失败，这只有在您预计会有这种负载时才会成为问题。否则，您可能会发现自己花费了比支持可能永远不会到来的负载所需的多得多的钱。
考虑延迟和网络速度。对于压力测试，最好有一个千兆以太网连接，应用程序的延迟小于 1 毫秒，您可以使用它来推动应用程序确定它何时会失败。但实际上，您的用户通常不会离您的应用程序那么近 - 他们会遇到各种不同类型的网络条件。
耐久性测试 - 建议至少进行 24 小时，如果负担得起，可以进行更长时间。您需要捕获在定期运行批处理时应用程序发生的情况，例如备份、防病毒定义更新，甚至 IIS 应用程序池回收（默认每 29 小时一次）。
了解性能测试和负载测试之间的区别。负载测试通常会显示服务器的视角。这并不完全正确 - 许多工具会以 TTLB 的形式显示事务所花费的时间 - 但当今大多数工具并不反映客户端渲染时间，而客户端渲染时间在 JS 密集型应用程序或使用 XSLT 的应用程序中很重要。
不要仅仅依赖自动化测试数据 - 至少不要从第一天开始。定期手动验证您得到的数字。随着时间的推移，随着您对模拟越来越有信心，这种情况就会逐渐消退。
性能计数器 - 每个应用程序都不同，但从四个基本类别开始 - CPU、内存、磁盘 i/o、网络 i/o 不会出错。我首选的计数器列表位于 ht tp://www.oneredlight.com/perf.config.txt。您可以使用以下命令行设置应用程序以将这些计数器记录到 300 MB 循环文件中：logman create counter PERF -f bincirc -max 300 -si 2 --v -o "c:\perflogs\perf" -cf "perf.config"。我只在 Windows 2008/IIS 7/SQL 2008 上尝试过这些，因此您的里程可能会有所不同。如果您的应用程序在 ms 堆栈上，我还建议您阅读 ht tp://msdn.microsoft.com/en-us/library/ms998530.aspx。
（抱歉网址已损坏；新用户无法发布超链接）