01.對交易中涉及的所有步驟使用適當的檢查點/斷言
當頁面未完全正確下載時，沒有檢查點可能會導致更好的響應時間。
用于斷言的文本應該是靜態的，或者應該在所有運行/環境中保持一致。如果做得不好，腳本維護成為開銷。例如，如果最暢銷汽車的名稱被用作斷言，那么一旦暢銷汽車名稱發生變化后，該腳本可能會在幾天后開始失敗。
02.確認您的性能測試工具是否自動處理cookie
如果被測站點設置了cookie，這些cookie可能會出現在記錄的腳本中，并且需要由腳本設計者通過使用變量來顯式處理。該變量允許腳本在測試過程中接收不同的cookie值，而不是使用記錄的值。
如果站點使用來自應用程序服務器的HTTP會話cookie，Cookie替換是必須的。
03.確保該腳本不包含不正確或無關的URL。指定的網址應該按正確的順序排列
錄音時可能會有這種可能，劇本作者會去他/她的受歡迎的網站。
可以使用測試工具的“播放”功能來驗證腳本實際執行的操作。
04.識別腳本中存在的所有動態數據（作為服務器的響應）并將其關聯起來
通常可以通過記錄腳本兩次并在它們之間進行比較來找到它。
05.參數化腳本以支持動態數據集
在存在動態數據的情況下，每個模擬用戶都會執行完全相同的路徑，但避免緩存響應并正確執行數據庫交互。
06.檢查腳本中的思考時間和步調時間
不建議為每個步驟或每個用戶使用常量思考時間值。
請檢查您的工具是否支持在某個范圍內分配思考時間值。
思考時間值和起搏時間值應在性能需求收集階段進行規劃和確定。
07.用戶很少從網站注銷，因此不要假設相同并相應地設計腳本
每次注銷時，都可能比實際更快地清除緩存中的http會話信息。
08.在設計時驗證腳本
用一個迭代和一個用戶來驗證它
通過多次迭代和一個用戶來驗證它
用多個并發用戶進行多次迭代來驗證它
09.應該以某種方式編寫腳本，以便可以針對多個環境執行腳本而無需進行任何重大更改
不同的環境可以是測試，壓力，預生產等
10.考慮先為原始路徑構建腳本
它有助于輕松排除故障和優化
11.最終腳本應該代表實際的用戶活動
不應該太簡單，太專注，直到真正需要
12.在設計腳本時注意可重用性
開發簡單的腳本來構建更復雜的腳本和場景。
所有簡單的腳本應該是原子性的。
13.遵循標準的命名約定和文件夾結構
抵制使用工具提供的默認值（例如目錄路徑，日志文件位置）的誘惑。了解每個設置的結果，然后應用它。
有助于可讀性和審查腳本。
推薦閱讀：
sales@spasvo.com
