總結一下此次測試的不足之處：
1、測試計劃中，對真實用戶場景模擬不全面。
這次測試目的是調優，使上班登記功能滿足客戶的需求。我在設計場景時，只考慮到使用集合點，通過最大并發數來模擬用戶。
前輩分析：上班登記這一業務為多用戶集中在短時間內完成，還應增加場景，使多用戶在一定時間內完成此業務，才能更好的模擬真實場景�？磥磉�是想的不夠全面。
2、場景設計中，對用戶并發數，沒有進行準確的壓力評估。
開始時，我總是想著測出系統支持的最大并發數就好了。一直往上加用戶，直到寫測試報告，才發現我的測試過程完全沒有按照計劃來做，最后變成了根據測試結果來寫測試計劃。哎...還是思路不夠清晰。尤其是對于最大并發數的預計。不過后來從前輩那兒學了一個公式不知道準確不準確，拿來跟大家分享一下：
計算平均的并發用戶數：C = nL/T
并發用戶數峰值：C’≈C+3√C
公式(1)中，C是平均的并發用戶數;n是login session的用戶數量;L是login session的平均長度;T指考察的時間段長度。
例如：系統最大用戶在線數為900，系統在現有配置下應支持并發用戶數為900×2/10=180;
最后總結，性能測試是一項完整的工程，一定要有一個詳細的計劃來指引工作的進行。測試計劃必不可少，測試計劃越詳細越好!
朋友建議我把詳細的測試過程也放上來，下面就再簡單描述下，希望大家能多提意見：
測試目的：系統上下班登記業務能夠滿足當前用戶的需求。
測試策略:根據用戶實際業務情況，上班登記業務多集中在上班前后10分鐘內，并發操作較多，在測試過程中設置了兩種場景。
場景一：并發測試，180用戶到齊后同時簽到。
場景二：用戶在線測試，300用戶在10分鐘內完成上班簽到。
LoadRunner中場景設置：
場景一：設置集合點，每10秒上2個用戶(上用戶速度較慢，保證所有用戶都能正常登錄系統)所有用戶跑完停止。
場景二：不設置集合點，每2秒上一個用戶，所有用戶跑完停止。
注：在測試過程中，可以按照50、100.....依次遞增上用戶。
每次結束后，注意分析數據庫服務器、應用服務器windows資源情況是否正常，以及應用服務器后臺是否報錯
文章來源于領測軟件測試網 http://www.kjueaiud.com/
