如果設計說明書中沒有給出明確的標准，那么可以參考國外的業內公認的一些標准：
主要對性能測試設計、測試執行以及數據分析。
量：包括業務量（業務類型），負荷量（系統處理的流量），配置量（軟件配置和硬件配置），用戶量（靜態用戶和動態用戶），時間量（測試的時間）。
全：主要是針對測試用例而言。測試用例理你包括預置條件，測試步驟和預期結果三部分，這個“全”重點針對預置條件和測試步驟的測試結果觀察和數據而言。
深：一是對系統的了解要深，二是對缺陷的分析要深。
快：一是測試經驗的固化，避免測試設計，觀察等遺漏。將經驗固化成模板或工具便於經驗的傳承，減少測試的重復和遺漏；二是性能測試的自動化，包括性能測試環境構建和測試執行以及測試分析的自動化，自動化對性能測試效率的提升價值更大。
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次/秒