在應用程序的生命週期中，應儘早建立性能測試意識。
確保應用一切就緒
需要考慮的問題：
- 應用程序部署後需要支持多少最終用戶？6個月後？1年後？3年後呢？
- 這些用戶分佈在哪裏？他們是如何與系統建立連接的？
- 部署後有多少在線用戶、併發用戶？6個月後？1年後？3年後呢？
引申出的問題： - 對於每個應用程序，需要多少臺服務器？這些服務器的配置是怎麼樣？是否需要集羣？
- 我需要提供什麼類型的網絡基礎設施？
性能測試重點關注的方面：
- 選擇合適的性能測試工具；
- 設計一個合適的性能測試環境；
- 設置切合實際的性能測試目標；
- 確保被測應用程序足夠穩定；
- 安排有足夠的時間進行有效的性能測試；
- 做到代碼凍結；
- 確定和編寫關鍵業務腳本；
- 提供高質量、足夠的測試數據；
- 確保準確的性能測試設計；
- 確定監控服務器和網絡的關鍵性指標（KPI）；
- 安排有足夠的時間進行有效的性能測試。
性能測試工具
性能測試工具要求：
- 協議支持（通信協議）；
- 認證模式（License）；
- 概念驗證（Proof of concept，簡稱POC，證明其可行性，示範其原理）；
- 腳本效果（生成腳本的編輯程度）；
- 解決方案與負載測試工具（提供解決方案）；
- 外包性能測試or內部執行。
注意：制定替代方案。
預留足夠時間
安排足夠的時間確保有效的性能測試。
需要考慮的幾個方面：
- 準備測試環境的時間
- 準備負載生成器環境
- 確定及描述業務事務的時間
- 識別和創建足夠的測試數據的時間
- 部署測試環境的時間
- 準備和執行性能測試運行的時間
- 解決問題的時間
設計性能測試環境
理論上要與生產環境完全一致，但是很多原因導致不太可能，可能的原因：
- 服務器的數量和規模：真實環境難以複製，儘量保持規格一致或接近，以便提供基準；
- 帶寬和網絡基礎設施：地理位置難以複製；
- 應用層數量：建議完全一致；
- 應用程序數據庫規模：建議完全一致。
搭建性能測試環境，需要進行計劃和規劃，必要時候需要定期做評審。
性能測試環境的三個層次：
- 完全真實或者接近真實的環境；
- 生產環境的子集。使用少數的服務器，但部署的規模和應用層都與生產環境一致；
- 生產環境的子集。使用較少的和小規模的服務器（所有部署模式與生產一致，只是縮小規模）。
施壓能力
負載生成器能力：確保負載生成器有足夠的硬件資源（儘量保證硬件資源處於非飽和狀態）。
針對虛擬用戶需要注意以下幾點：
- 負載均衡：應用程序根據傳入的IP地址不同進行負載分配；
- 需要實施“IP欺騙”技術（選擇測試工具時，需要注意）；
- 用戶會話限制：每一個物理機器只能發起一個用戶會話，如：mac驗證等；
- 應用程序技術的中間件可能無法錄製；
- 使用功能測試工具從表現層產生負載；
- 使用某種瘦客戶端的部署形式，以使性能測試工具能夠錄製；
- 從應用層角度去衡量性能（通常性能測試是從中間層發起的，客戶端沒有進行性能測試選擇測試工具時，可以選擇負載測試腳本和功能測試腳本任意組合的性能測試工具）。
網絡部署模式
不同的部署模式（網絡環境）考慮如下幾點：
- 可用帶寬：局域網和廣域網的帶寬，需要作爲性能測試模型的考慮因素；
- 網絡反應時間：局域網和廣域網的延遲，廣域網的延遲高，會影響性能。
針對廣域網的性能測試方法：
- 修改事務回放：性能測試工具通過修改事務的執行頻率達到；
- 廣域網的負載生成器：需要符合實際；
- 網絡模擬：網絡角度模擬廣域網的網絡環境。
環境檢查信息
- 服務器數量；
- 負載均衡策略；
- 硬件信息；
- 軟件清單；
- 應用程序組件（中間件）清單；
- 外部連接（其他內部或者第三方系統的情況）。
軟件安裝衝突
測試環境中安裝的第三方軟件是否會互相沖突，比如：安全軟件。
設定合理的性能目標
制定切合實際的性能指標：制定明確清晰的性能指標，否則性能測試沒有任何意義。
一致性
- 性能指標制定需要提早制定（項目的早期階段）；
- 制定一致性的性能指標需要相關所有部門都參與進來，使所有成員對項目進程和交付等問題都有清楚的瞭解（促進專家評審和參與）；
- 商務人員：首席信息官（CIO）、首席技術官（CTO）、首席財務官（CFO）、部門負責人；
- IT：架構團隊、開發人員、測試人員、運維人員、基礎設施組（內部和外部）、終端用戶。
關鍵性能指標
主要包含可用性、響應時間、吞吐量、併發、網絡利用率和服務器利用率。
- 可用性或者正常運行時間：應用程序任何時候處於可用狀態；
- 併發性和擴展性：根據80/20原則確定，考慮高峯時期，經驗法則在併發數和吞吐量指標基礎上增加10%；
- 吞吐量：考慮區分專家級和初級用戶，專家級用戶在單位時間內，創建的事務更多；
- 響應時間：確定基線值（無任何影響情況下，一個用戶單獨運行此事務的響應時間），根據差額確定響應時間變化當用戶增加時，響應時間會增加，但是隨着負載的增加不應該出現阻塞的情況；
- 網絡容量：數據量（低帶寬廣域網下，帶寬限制和網絡延遲的影響）、數據吞吐量（是否能達到“節流”的情況）、數據錯誤率；
- 服務器容量：CPU、內存、I/O（磁盤和網絡等）、磁盤空間等。
梳理關鍵業務用例和編寫腳本
識別並確認關鍵業務的事務，確定性能測試業務範圍。
確保在性能測試過程中應用程序足夠穩定，系統穩定性是對於應用程序能夠正確提供服務的信心，性能測試之前，代碼的質量對於性能的好壞是至關重要的。
影響應用程序穩定性，可能出現的隱藏問題：
- 大數據量展現；
- 執行效率不佳的SQl語句；
- 大量的網絡數據交互；
- 應用程序的未知錯誤。
做到代碼凍結（保證測試版本穩定），對不斷變化的對象進行性能測試是毫無意義的，保證代碼版本的一致性，對於性能測試至關重要。
事務檢查列表
- 定義每個執行步驟並形成文檔，保證不出現具有歧義的路徑；
- 確定所有輸入數據的要求和預期結果；
- 定義事務涉及的用戶類型：多用戶操作同一事務，使用量各有不同；
- 事務的鏈接模式是什麼：局域網、廣域網、互聯網；
- 主動型事務還是被動型事務。
事務回放驗證
- 驗證單用戶回放；
- 驗證多用戶回放。
度量目標
要測量什麼：關注事務的響應時間，及LR裏面事務的概率。
登錄還是不登錄
用戶是否反覆登錄（腳本中，是否重複登錄）。
共存系統問題
資源共享（與其他應用共享服務器、網絡帶寬等）。
準備測試數據
提供高質量的足夠的測試數據
- 輸入數據：用戶認證；搜索條件：不同的數據組成搜索條件；文檔關聯：上傳下載測試，文檔類型和大小多種；
- 目標數據：大小：確定數據庫基礎數據量；數據回滾：保證每次測試時，數據庫的數據量一致，減少性能測試差異，考慮數據庫恢復時間，並在性能測試計劃中體現；
- 運行時返回數據：確認執行結果正確；
- 數據安全性：保證數據脫敏。
精確的設計性能測試
性能測試的基本類型
- 基準測試：基準測試是指建立一個可與進一步測試比較的點，通常用於衡量事務響應時間；通常是單用戶在一段時間或一定的循環次數內執行單個事務，提供在“最好情況下”的測量；基準測試得到的值可用於評估，隨着用戶數或吞吐量的增長而導致系統響應性能的衰減；
- 負載測試：爲達到性能目標而做的性能測試；最接近真實的使用場景；
- 壓力測試：導致應用程序或部分支撐硬件的崩潰，這樣做的目的是確定硬件的支撐大小和上限；壓力測試的結果不僅可以衡量系統的性能，還可以衡量功能；重要的是瞭解到了應用程序的上限，爲未來的做決策；
- 滲透或穩定性或可靠性測試：長時間下的負載測試；
- 冒煙測試：只關注發生改變的部分；
- 隔離測試：性能問題確定測試。
負載模型
負載生成策略：
- 爆炸式（同一時間加壓）
- 遞增式
- 逐步遞增式
- 逐步遞增式，逐步遞減式
- 延遲啓動
爲每個事務設置虛擬用戶數（混合場景性能測試）。
性能測試負載方式：
- 每個事務的基準測試：爲每個事務建立一套性能數據基準；
- 每個事務的負載測試：確定每個事務需要的最大併發用戶數或吞吐量；
- 單個事務的隔離測試：出現問題時，啓動，直到問題解決；
- 混合事務負載測試：單事務達標，啓動混合事務負載測試目的爲了發現硬件能力或可能的衝突，比如數據庫鎖等資源的競爭負載生成策略：遞增或遞減；
- 混合事務隔離測試：混合負載不達標時，啓動，確認診斷結果和解決方案，指導解決；
- 混合事務滲透測試：疲勞或穩定性測試單事務或者混合事務，發現在長時間運行情況下，才能出現的問題；
- 混合事務壓力測試：峯值測試單事務或者混合事務，通過減少暫停時間和步進時間，創建比負載測試中更大的吞吐量查明應用程序容量的上限，並且確定在突然的業務高峯期系統的響應如何；
- 其他性能方面的測試：配置測試不同方式的負載均衡停掉應用程序的一個或多個服務來測試系統的容錯行爲爲今後異常處理或者應急方案做決策，而做的非性能方面的測試。
用戶負載仿真：創建的負載必須和真實的環境一致，考慮帶寬的制約、資源的制約等。
思考時間&步進時間
思考時間和步進時間可以儘量讓性能測試更真實。
思考時間：影響的是事務執行的頻率（事務內部的等待時間）。
步進時間：影響的是事務的吞吐量（事務迭代之間的間隔時間）。
確定關鍵性能指標
服務器指標
- 通用指標
- CPU
- 內存
- I/O（磁盤和網絡）
- 磁盤空間
- Web和應用服務層：OC4J、Weblogic、WebSphere、Jboss等；
- 數據庫服務層：MSSQL、Oracle、DB2、MySQL、Sybase、Informix等；
- 主機層：Strobe（Compuware）、Candle（IBM）。
網絡指標
- 數據包的響應時間；
- 數據展現；
- 大數據量引起的任何可能出現的錯誤。
參考文檔
- 《應用程序性能測試的藝術》