2、負載目標計算
與項目管理中的SMART原則類似，業務場景需轉換成可量化、可衡量、可實現的負載目標才能進行性能測試，而負載目標要根據不同場景分別計算。根據上階段收集到“原始”數據，本階段可計算或指定出各種間接和直接的負載目標值，一般負載目標多從兩種角度考慮：
2.1 前端角度
在線用戶數量：間接負載目標值，可理解為所有能操作被測交易的用戶（柜員）數量。
平均操作時間（思考時間）：間接負載目標值，與在線用戶數量一同計算業務并發數量。
業務并發數量：典型場景中集中操作（不是絕對并發）交易的用戶（柜員）數量。
2.2 后端角度
每秒交易數量（TPS）：根據日志計算出的被測系統應承受的每秒交易數量。
交易響應時間（TRT）：與TPS對應，負載場景下交易應達到的響應時間。
吞度量（Throughout）：LoadRunner中吞度量是以每秒收到的字節數計算，其實TPS也是吞吐量的一種，根據不同被測系統計算對應的吞吐量。
系統并發數量：區別于業務并發數量，系統并發數量更趨近于絕對并發。對長連接系統來說系統并發就等于允許的連接數，對短連接系統來說更多取決于架構。
被測系統CPU、Mem、Disk等指標值：多為指定值，如CPU利用率不高于80%等。
前端負載目標需要通過大量、廣泛的業務和日志統計才能得出，如需記錄下高峰時段操作交易的用戶數量、估算用戶狀態比例、統計操作習慣等，由于考慮到人的因素，因此前端負載很難計算精確。前端負載目標適合交易關聯不大、操作用戶分散、無具體業務量要求的系統，如內控管理、培訓考核、網銀主頁等（以B/S架構為主）。
后端負載目標則比較容易計算，如當前某省對公匯兌類交易日均8萬筆，則TPS=80000/（6*60*60）=3.7筆/秒（對公按6小時計算）；核心系統聯機交易平均響應時間在3秒以下等。后端負載目標適合交易關聯度大、操作用戶相對集中、有具體業務量要求的系統，以銀行核心業務系統為主。
負責目標需要針對不同類型的被測系統計算合理的目標值，同時還需考慮2/8原則，未來業務量、用戶量擴展等因素，這里不做贅述。 一、性能測試的四個方面
在一般的性能測試討論中大家通常只圍繞三個方面進行提問和總結：測試腳本如何編寫，被測系統如何監控，性能瓶頸如何調優。大部分剛剛接觸性能測試的人會糾結于腳本的編寫，如何設置參數化、如何設置關聯、何時插入檢查點，各種論壇和討論群里不斷有人提出也不斷有人解答。經過一段時間的經驗積累后就會遇到如何監控被測系統，如何確定瓶頸并調優等問題，各種操作系統、中間件、數據庫的監控和調整方法也被口耳相傳。但我認為在性能測試的討論中我們卻忽略了另一個重要的方面：如何制定性能測試策略。
我認為完整的性能測試可以分為四個方面：1、測試策略制定；2、性能腳本編寫；3、被測系統監控4、性能瓶頸調優。從流程來看這四個方面有先后順序的關系，從領域來看這四個方面都有可深入研究的內容。
1、測試策略決定了性能測試如何開展，負載目標是否正確，場景模擬是否合理，好比戰場上的指揮部，從全局設計戰爭的方向。
2、測試腳本編寫決定了性能測試能否順利執行，壓力發起是否正確，好比戰場上直面敵人的作戰單位，需要真刀真槍的去拼殺。
3、測試監控決定了關注范圍是否合理，能否發現瓶頸所在，好比潛入敵后的地下組織，要設置在關鍵的脈絡上實時收集情況。
4、性能調優并不是所有項目都需要的，但一旦發現問題，調優就決定了測試能否完美收官，如戰場上的特種兵，用專業的技能解決各種難題，非一時所能練成，所以我們大部分人都執著于此。
本文以筆者實際項目經驗為基礎，嘗試探討并總結銀行系統性能測試策略制定過程中必經的步驟和所需考慮的內容。
二、測試需求分析
1、業務場景分析
測試銀行核心系統時將柜員簽到、簽退、業務操作、批量等眾多交易放在同一場景中執行，這樣的場景在現實中是否存在？測試POS、ATM等渠道時將查詢、動賬類交易各按50%的比例分配，這樣的比例是否正確？所有的性能測試都是以復現實際業務場景為目標。因此業務場景分析和選取務必嚴謹。業務場景應該從時間和空間兩個角度考慮：
1.1 時間角度
分別以一年、一月、一天的角度觀察，被測系統是否存在業務高峰時段。各高峰時段的重點交易是什么，交易比例如何。
1.2 空間角度
根據各分行業務特點不同，被測系統是否存在不同的高峰場景和交易，操作交易的柜員數量及一般操作時間是多少。
業務場景分析階段應向業務、研發、運維等多部門了解被測系統需求，但就數據準確度而言，應多參考生產日志。對升級改造類系統，場景分析的數據可從老系統的生產日志中獲取；對新開發的系統，分析數據可從業務上有關聯的其他系統中獲取，同時參考業務部門意見。典型業務場景可以不止一個，但一定要明確各場景中的交易和比例，不要模擬一個不存在的大混合！
三、測試環境設計
1、硬件環境設計
大部分性能測試的硬件環境與生產相去甚遠，受品牌、型號、部署方式（集群個數減少，軟負載均衡代替硬負載均衡）等多種因素限制，無法直接將測試環境下的性能結果向生產環境做比例放大，因此硬件環境設計主要關注應用架構與生產環境一致（如應用、數據庫服務器必須為集群方式），盡量減少性能測試中的硬件資源瓶頸（如數據庫存儲必須為SAN，發壓與被測系統間網絡帶寬必須為1000M）。
2、軟件環境設計
軟件測試環境可從兩個方面考慮：
2.1 基礎配置
確認操作系統、中間件、數據庫和被測系統的版本與補丁與生產環境一致，但操作系統、中間件、數據庫的內部參數應根據測試硬件環境做適當調整，可參考生產中的設置比例。
數據庫分區、索引等必須與生產或預計投產時一致。
2.2 外聯系統
盡量減少外聯系統，因為外聯系統越多，測試鏈條越長，環境越難維護，問題越難定位。可適當在被測系統中做擋板程序，模擬與外聯系統的應答，但必須保證被測系統中的邏輯分支沒有被屏蔽。
3、鋪底數據策略
性能鋪底數據量的大小和分布情況會對測試結果產生極大影響，是場景設計階段的重中之重！測試前對鋪底數據的構造可從以下四個方面考慮：
3.1 表分區情況
確認測試環境與生產環境（或預計投產后）的表分區和索引分區規劃一致，結合表清理策略確認典型場景中各分區、各表中的數據存量大小和分布情況。
3.2 表清理策略
確認生產環境（或預計投產后）的數據庫表（尤其業務熱表）清理和備份策略，與表分區情況配合，預鋪數據并確保測試數據庫表中數據存量與生產保持同一量級。
3.3 表維護策略
確認當前生產數據庫表（尤其熱表）和索引統計值更新、rebuild和reorg等操作的頻度，在數據預鋪中適當更新統計值，切勿在測試環境中頻繁執行統計值更新等操作，造成虛假的性能表現。
如下圖，更新統計值后表和索引的相關信息會統計正確，性能將得到一定程度的提升。
3.4 合理的業務數據
確認鋪底數據中的柜員、行部、角色、權限、待處理任務等業務數據是否符合實際情況，切勿為圖省事而創建超級行部、全能柜員和過量的待處理任務。
四、測試場景設計
1、發壓數據策略
測試發壓數據應在數據鋪底時一同考慮，但發壓數據需要和壓力工具配合使用，可從以下四個方面考慮：
1.1 表分區情況
確認發壓數據覆蓋各表分區，且在分區中也需盡量離散，不要集中操作（主要是查詢）同一范圍內的數據。
1.2 表維護策略
通常生產環境中數據庫表在日終結束后執行統計值更新，對應第二天營業時的數據狀態，除柜員簽到外，其余典型場景均發生在更靠后的營業時段，因此不要在剛剛執行完統計值更新的環境中執行正式的性能測試，建議再執行一段時間的數據預鋪，模擬行部營業一段時間后的業務，這時再執行正式的性能測試，并記錄結果。
1.3 被測交易分支
在能力允許的情況下應盡量多的閱讀被測交易源碼，或向開發人員了解程序邏輯和交易分支，確認發壓數據可覆蓋程序中所有重點路徑。避免造成該復現的問題沒有復現，該出現的瓶頸沒有出現。
1.4 合理的業務數據
與發壓工具配合，確認在測試過程中沒有同一柜員并發操作交易，沒有超出合理范圍的待處理任務，以日峰TPS為負載目標時不要同時執行疲勞測試，這樣會導致交易量遠遠大于實際。
2、測試并發設計
并發設計與負載目標緊密關聯，同樣可分為前端、后端兩種方式：
2.1 前端角度
使用工具模擬的并發數量代表業務并發用戶數量，一個并發進程或線程即模擬一個操作交易的柜員，腳本中設置thinktime模擬平均操作時間，維持典型場景中各交易的用戶比例，并做等比例遞增，關注此時被測系統的處理能力。但需注意的是，受thinktime和響應時間等影響，業務并發數量≠系統并發數量，所以不能在結論中說“被測系統只能承受XX并發”。且業務并發數量與在線用戶數量的換算不可能完全精確，所以也不能用類似10個業務并發即代表100個在線用戶的粗略換算為結論。
2.2 后端角度
使用工具模擬的并發數量不代表用戶數量，也不完全等價于系統并發數量，它僅通過并發的形式對被測系統產生壓力。由于后端角度更關注TPS，因此并發遞增時各交易之間的并發比例可能會變化，響應時間變慢的交易會增加更多并發以維持預期TPS。
后端角度重點關注并發增加時的TPS和響應時間變化趨勢，確定被測系統的處理能力。
五、測試策略維護
測試策略應在測試執行前確定，執行過程中不做大的變更，但仍需根據測試結果不斷反思和維護策略，確保性能測試能夠真實復現生產場景。
六、總結
工欲善其事必先利其器，在性能測試中我們的武器不僅僅是發壓和調優工具，還有測試的思想！性能測試不是一個流水化作業的過程，它必須深入被測領域，對業務和技術進行全面了解才能正確執行。本文探討并總結了銀行系統性能測試策略的制定，由于經驗有限，難免會有偏頗和遺漏，請批判閱讀，同時對其他領域的策略制定也是拋磚引玉。
版權聲明：本文出自 dionysus 的51Testing軟件測試博客：http://www.51testing.com/?5939
原創作品，轉載時請務必以超鏈接形式標明本文原始出處、作者信息和本聲明，否則將追究法律責任。