1. 性能測試必要性評估
1.1 必要性評估的意義
任何項目在開展性能測試活動前都需要進行必要性評估。通過必要性評估活動，確認被測對象是否有必要實施性能測試活動，千萬不可爲了性能而性能。
通常情況下，必要性評估可以通過設定不同條件、不同權重進行分析，將評估項分爲關鍵評估項和一般評估項兩種。關鍵評傳項，只要有一項符合，則必須開展性能測試，而一般評估項，可通過加權計算，超過60分，則需開展性能測試。
1.2 關鍵評估項
1. 被測對象需經過主管部門或監管單位審查、認可，需提供性能測試報告。目前，很多企業的軟件產品在正式上市對外銷售、應用時，政府機關、主管部門或監管單位，可能需要其出具功能測試報告、性能測試報告，甚至是第三方測試報告，這種情況下，必須進行性能測試；
2. 涉及財產生命安全的系統。通常情況，電商系統、金融業務系統、醫療健康評估，涉及用戶或行方資金交易，生命安全類的，需要進行性能測試；
3.首次投產的大型系統，具有大量用戶使用的核心業務；
4.系統核心數據庫、業務邏輯、軟硬件升級。與歷史系統對比，系統核心數據庫、業務邏輯調整、軟件硬件設備升級，同樣需要實施性能測試:
5.歷史版本存在重大非功能缺陷或風險較大的未評估項:
6.業務量、用戶量、節點增長30％以上。系統升級後，業務量、用戶量、應用節點，増長量在30％以上的，具體數值可根據實際情況調整。應用節點增長一般指甲方因業務需求，増加應用節點，銀行拓展分行、分中心、分公司、營業網點等
7.系統架構發生重大變化。不同的系統架構可能存在較大的性能差異，因此在系統架構發生變化後，必須實施性能測試，並且在此過程中，無法通過類推的思路推斷架構變化後的系統性能;
8.生產環境非功能嚴重缺陷修復後。生產環境在使用過程中產生重大非功能性缺陷成功修復後需重新開展性能測試活動，以驗證修復活動是否對生產環境造成不良影響
對於不同行業，不同測試對象可能存在的不同的關鍵評估項，可自行增減。如果上述關鍵評估項，有一項達標，則需進行性能測試。
1.3 一般評估項
常見的性能測試一般評估項，主要從單次版本考慮，如果是平臺性的，則爲關鍵評估項，如果是單次版本，單個組件或業務，則從以下幾個一般評估項評估權重:
1.是否在平臺中處於核心位置(15分):
2.是否有升級，且升級內容中包含了外部系統對接接口、支付接口、 Web Servicei調用接口等與其他系統關聯接口(20分)
3.是否存在部署方式調整或優化(15分
4.是否增加了性能風險較高的調整(20分)
5.是否存在客戶要求必須測試的組件或業務流程(20分
6.是否涉及多個功能缺陷的修復，且流程發生較大變化(10分)
如果上述一般評估項，總計分值超過60分，則需進行性能測試。
2. 性能測試需求分析
2.1 需求分析
性能測試需求分析與傳統的功能測試需求有所不同，功能測試需求分析重點在於從用戶層面分析被測對象的功能性、易用性等質量特性，性能測試則需要從終端用戶應用、系統架構設計、硬件配置等多個緯度分析系統可能存在性能瓶頸的業務。
一般而言，用戶或產品團隊設定性能測試需求時，僅會表述字面意義上需求，如“系統TPS需達到300以上，單筆交易時間不超過3秒“等。需要性能測試工程師結合用戶需求及性能測試活動本身需求進行顯性與隱性性能測試需求的分解與提取。
隨着互聯網技術的飛速發展，互聯網應用架構越來越複雜，運營系統涉及的利益相關方越來越多，因此，在性能測試工作實施過程中，需從不同的用戶層面分析待測需求，確定性能測試的必要性後，性能測試工程師主要從以下兩個用戶方確定性能測試需求
+ 業務用戶
1.用戶頻繁使用，且存在大量用戶使用的業務流程
2.交易佔比較高，日常佔比在80％以上甚至更高的業務流程:
3.特殊交易日或峯值交易佔比80％以上甚至更高的業務流程
4.性能較差且有過調整的業務流程
5.特殊業務場景
6.核心業務發生重大程調整的業務流程
以上從業務用戶層面，考慮的可能需要進行性能測試的點。實際實施過程中，如果可能，可向終端用戶調研。
+ 項目團隊
1.曾經測過性能後調整了架構設計的業務;
2.邏輯複雜，關鍵的業務
3.可能消耗大量資源的業務
4.與外部系統存在接口調用，且有大量數據交互的業務
5.調用第三方業務組件，邏輯複雜的業務。1
以上從項目開發角度考慮可能需要進行性能測試業務流程，性能測試工程師需對被測對象深入瞭解，並且需要研發團隊配合。
除上述兩種用戶，還可能包括運營團隊，調研未來業務發展規劃，系統需滿足未來業務需求的可能性。
2.2 需求評審
確定性能測試需求後，如有必要，需進行某種程度的測試需求評審活動。性能測試需求評審與功能測試需求評審類似，都需關注需求本身的可測性、一致性及正確性。
+ 可測性
軟件可測性，通常理解爲軟件本身是否具備實施測試的條件，是否便於發現缺陷及定位缺陷。
在一定的時間及成本範圍內，構建測試環境，設計及執行測試用例，測試工程師能夠相對便捷的發現、定位缺陷，從而協助研發人員解決對應的缺陷，無論是功能測試，還是性能測試，都需要被測對象具備上述的可測試特性。
性能測試活動與功能測試活動有個顯著的特點是被測對象運行環境要求不同。實施功能測試時，只要被測對象能夠在合理的運行環境中正常運行即可，即使測試環境與生產環境可能存在較大的差異，性能測試則不同，一定需模擬儘可能真實的運行環境。當測試環境與實際生產環境差異較大時，性能測試結果往往不被接受，如果在性能測試實施過程中，無法搭建相對真實的測試環境，即可認爲被測對象不具備性能的可測性。
+ 一致性
性能測試需求一致性，主要關注用戶需求、生產需求、運營需求幾個方面。通過對性能測試需求的分析，判斷本次測試需求是否滿足用戶需求規格說明書中明確列出的性能求項。生產需求，則是關注被測對象運行的真實性，從而在測試結東後能夠提供相對準確的數據依據。
運營需求，需以歷史數據或者現今運營數據爲基礎，規劃未來業務發展的可能性，從而使得被測對象性能指標具有一定的冗餘度。
通過性能測試需求評審活動，確定本次性能需求與上述的關注點一致
+ 正確性
在可測性與一致性得到保證的基礎上，需針對性能測試指標進行驗證，從而保證後實施活動中所關注的各個項目需求、場景及指標的正確性，從而儘量減少返工、重新設計的風險。
通過可測性、一致性及正確性的評估，最終確定本輪性能測試需求，並以此作爲後續測試實施活動的輸入。
2.3 常見的需求指標
響應時間
頁面：<3s
數據庫：<500ms
接口：<1000ms
併發數
略
成功率
100%
內存/cpu
<=80%
2.4 系統架構分析
+ 常用的系統架構
Linux + Apache + PHP + MySQL
Linux + Nginx + Redis + PHP + MySQL
Linux + Apache + Tomcat + Java+ Oracle
Windows Server 2003/2008 + IIS + C#/ASP.NET + 數據庫
Window Server 2003/2008 + tomcat + MySql/Oracle/ + Java
Linux + Python + uwsgi + Nginx + MySQL
3. 性能測試策略確定
3.1 場景確定
1. 測試場景
+ 發生頻率非常高的（例如：某郵箱核心業務系統中的登錄、收發郵件等業務，它們在每天的業務總量中佔到90%以上）
+ 關鍵程度非常高的（產品經理認爲絕對不能出現問題的，如登錄等）
+ 資源佔用非常嚴重的（導致磁盤I/O非常大的，例如某個業務進行結果提交時需要向數十個表存取數據，或者一個查詢提交請求時會檢索出大量的數據記錄）
2. 根據項目性能需求場景和實際的業務場景，確定性能壓測場景：
+ 單業務基準測試
+ 單業務壓力測試
+ 單業務負載測試
+ 綜合業務基準測試(組合場景)
與單業務基準測試類似，但綜合業務需考慮業務與業務間的聯繫，如果相互之間存在資源爭用，則需單獨組合測試、。假設系統需測試的業務有三個:A、B、C綜合業務基準測試是將ABC一起運行，那麼加上A、B、C三個基準測試，共計4個基準測試場景，分別寔ABC、A、B、C，但A與C存在資源爭用，則需單獨將A與C組合，構成一個單獨的測試場景，則一共爲ABC、A、B、C、AC等5個基準測試場景。
綜合業務測試中的數據分配，根據實際業務、用戶需求、運行日誌、運營規劃等分析確定
+ 綜合業務基準測試(組合場景)
+ 綜合業務壓力測試(組合場景)
+ 綜合業務穩定性測試(組合場景)
3.2 工具選型
通過測試必要性評估，確定了需要對被測對象實施性能測試後，則需要考慮採用哪種性能測試方式。根據被測對象的業務特性和架構設計，可以採用以下兩種方式開展有效的性能測試活動。
如果被測對象爲批處理方式實現，並且在數據庫中設立起始與終止標識字段，則可以利用存儲過程或發起批處理的方式進行，資源監控可以利用監控腳本如 python腳本、shel1腳本或其他監控工具，最終統計時間，以結東時間減去開始時間，則可獲得交易時間，並可根據每筆交易獲得平均交易時間，相對來說較爲方便。
如果被測對象不是批處理模式，且可能存在大量數據交互，則可能需要採用專業的性能測試工具來實現。一般而言，業內常用的性能測試工具主要有開源的 Jmeter和商用的HP公司的 Loadrunner,以及其他的開源工具和自研工具。
+ Jmeter/是個開源的性能測試工具，目前在市場中的熱度很高，不依賴於界畫，功能測試的腳本同樣可以作爲性能測試腳本運行，對測試工程師技術技能要求不高，而且提供了參數化、函數、關聯等功能便於腳本的優化與擴展。
+ Loadrunner在商用領域一枝獨秀，很多年保持排前的市場佔有率，與 Jmeter相比， Loadrunner具有強大的腳本開發功能、完善的函數庫及結果分析功能。對測試工程師技術要求相對較高，但因其在業內流行很多年， Loadrunnerl應用的資料相對於Jete較多，便於學習與應用
+ python3調用locust，使用協程產生併發的方式也是一種可選方法，但此方案需要有一定的代碼基礎
+ 企業在選拝性能測試工具時，如有條件可以自己根據實際測試需求自定義開發測試工具，也可以選擇市場上常用的測試工具，通常選擇時需考慮以下幾個問題:
1.能否自定義開發，更符合實際測試需求;
2.商用的測試工具所需的成本，企業能否承受
3.採購的測試工具是否提供了完善的服務、細緻的培訓
4.團隊人員能否掌握測試活動所需的工具技能。
開源是行業趨勢，本書案例項目用開源性能工具 Jmeter實施性能測試。
4. 性能測試準備
4.1 腳本編寫
進行代碼編寫或錄製，並根據產場景進行組合調試。
4.2 數據準備
參數化、關聯數據處理等
生產環境數據複製/備份
python代碼生成
數據庫語言構造
4.3 測試環境準備
服務器搭建配置
數據備份或隔離
保證功能穩定
千兆寬帶
4.4 性能監控準備
+ linux服務
命令：free -m、vmstat、top、uptime
工具：nmon(https://www.cnblogs.com/jsondai/p/10021731.html)）
+ jemeter + linux服務監控
1、jemeter安裝PerfMon(Service Performance Monitoring)插件
2、下載ServerAgent上傳至服務端，linux下啓動“startAgent.sh”,windows下啓動“startAgent.sh”，ServerAgent默認開啓4444端口
3、jemeter添加監聽器---PerfMon
+ 本地監控
使用java監視器，在cmd中輸入“jconsole”
+ Mysql數據庫監控
Spotlight
5. 性能測試執行
5.1 測試執行
按照測試腳本進行執行並調試服務參數配置。一般第一次運行和調試的時間回比較長
5.2 參數收集
收集性能參數及曲線
6、結果結果分析及調優
6.1 結果分析
根據曲線變化分析所需參數
6.2 常見性能問題
響應時間越來越長，系統越來越慢：
1、物理內存資源不足
2、內存泄漏
3、外部資源交互
4、業務失敗是頻繁重試
5、資源爭用
6、中間件配置不合理
7、數據庫連接設置不合理
8、進程/線程設計錯誤
6.3 性能調優
7、性能跟蹤
7.1 性能跟蹤
7.2 性能報告
可參考https://wenku.baidu.com/view/975df1fb763231126fdb1182.html
