如果设计说明书中没有给出明确的标准，那么可以参考国外的业内公认的一些标准：
主要对性能测试设计、测试执行以及数据分析。
量：包括业务量（业务类型），负荷量（系统处理的流量），配置量（软件配置和硬件配置），用户量（静态用户和动态用户），时间量（测试的时间）。
全：主要是针对测试用例而言。测试用例理你包括预置条件，测试步骤和预期结果三部分，这个“全”重点针对预置条件和测试步骤的测试结果观察和数据而言。
深：一是对系统的了解要深，二是对缺陷的分析要深。
快：一是测试经验的固化，避免测试设计，观察等遗漏。将经验固化成模板或工具便于经验的传承，减少测试的重复和遗漏；二是性能测试的自动化，包括性能测试环境构建和测试执行以及测试分析的自动化，自动化对性能测试效率的提升价值更大。
2-5-10原则
主要针对响应时间。简单说，就是当用户能够在2秒以内得到响应时，会感觉系统的响应很快；当用户在2-5秒之间得到响应时，会感觉系统的响应速度还可以；当用户在5-10秒以内得到响应时，会感觉系统的响应速度很慢，但是还可以接受；而当用户在超过10秒后仍然无法得到响应时，会感觉系统糟透了，或者认为系统已经失去响应，而选择离开这个Web站点，或者发起第二次请求。
80/20原则
用于减少风险，抓住重点进行更多的测试：80/20原则即帕累托法则（Pareto Principle），用户80％的时间在使用软件产品中20％的功能。“重点测试”就是测试这20％的功能，而其他80％的功能属于优先级低的测试范围，占测试20%的资源。
实例：对测试强度估算
基本概念：每个工作日80％的业务在20％的时间内完成。
例如：每天工作8个小时，那么每天80％的业务在8*20％＝1.6小时内完成。
例1：去年全年处理业务约100万笔，其中，15％的业务处理中，每笔务需对 应用服务器提交7次请求；70％的业务处理中，每笔业务需对应用服务器提交5次请求；其余15％的业务处理中，每笔业务对应用服务器提交3次请求。根据以 往的统计结果，每年的业务增量为15％，考虑到今后3年业务发展的需要，测试需按现有业务量的两倍进行。
强度估算如下：
每年的总请求数为：
（100*15％*7+100*70％*5+100*15％*3）*2＝1000万次/年
每天的请求数为：
1000/160=6.25万/天<备注：每个月为20个工作日，所以1年为160天>
每秒请求数：（62500×80％）/（8*20％*3600）＝8.68次/秒