在這半年以來，我陸續參加或者獨立承擔的項目組版本的部分性能測試，慢慢的有了一些認識，暫時做一個積累，和大家做一個交流
性能測試的需求背景一般來自於以下三種情況：
第一種是現網出現性能問題，項目組專門進行了性能改造。比如修改的某個接口，由原來的同步調用修改成了異步，又或者是更換了新的api，由tcp協議修改爲udp協議，爲了保證新替換的api的可靠性，都需要進行性能測試
第二種是一個新做的系統，運營人員需要全面的把脈，瞭解該系統的處理能力。
第三種是隨着請求量的快速增長，而該系統卻從未做過性能測試，項目組擔心繫統在可預見的短期會扛不住，所以要求測試人員對該進行全面的性能測試，給出一份參考數據
根據背景的不同我們往往有不同的準備方式，但是大致可以從以下幾個方面入手準備。
1. 全面瞭解該系統概況。
（1） 系統所期望的性能指標：
對於第一二兩種情況，都會有很明確的現網性能指標，比如以前測試的acs，是一個新作的系統，需求說明書中就明確標註需要達到1w tps.而對於第三種情況，往往我們需要儘量的模擬現網，得出數據供運營做參考。例如最近測試的查詢限制引擎，測試這邊給出了單臺svr的處理能力以及是否支持平行擴展等運維最關心的數據即可。
（2） 組網以及網間各個系統之間的通信形式：
有時我們性能改造只是組網中一個小小的系統，這就需要我們去弄清楚這個系統在整個邏輯處理中所處的位置。
圖1
瞭解被測系統在整個交易中的位置，對於測試用例的設計以及測試環境的搭建是至關重要的
其次，還需要了解組網中各個模塊之間的通信方式，tcp or udp,同步調用還是異步調用，長連接還是短連接。
（3） 系統的各個邏輯分支：
瞭解系統的邏輯分支，主要是有利於設計測試用例。在我們實際的工作過程中，時間總是很有限的，而我們提高工作效率的一個很重要的方法就是重視用例的設計，瞭解了系統的各個邏輯分支，可以很精準的準備用例，直擊問題的本質，減少摸索的時間。
舉一個例子，psc系統性能改造版本（如圖1），幾乎所有的業務邏輯都要走ssp去查詢是否受限，但是我們選擇其中的一條最簡單的受周邊系統最小的二級贈送分支進行測試，利用最短的成本驗證問題，很好的保證了測試的進度
（4） 系統內部模塊的組合：
較爲複雜的系統，都會有自己的模塊組合方式。我們需要了解系統由幾個模塊組成，各個模塊的耦合關係是怎樣的，不僅對於功能測試中的異常測試用例的設計有很大幫助，對於性能測試的幫助也同樣不可小覷。
舉一個比較簡單的例子：aqc系統，這個系統是供外部查詢的，內部的模塊大致分爲：網絡通信層，請求分發層，功能處理層。網絡通信層主要是利用某網絡通信組件，處理網絡通信，請求分發層dispatch，主要將網絡通信層隊列的包根據cmdcode的不同分發到後端的功能處理層，功能處理層則有一個個小svr組成，每個svr處理不同的查詢請求。
圖2
倘若有一個性能需求是發現現網有一個查詢分支性能不OK，那麼我們就需要很快的鎖定關鍵的模塊，瓶頸很可能存在與處理這條分支的svr上。
其次瞭解了系統的各個模塊以及模塊之間的耦合關係，在理解性能曲線，調整測試方案時同樣很重要。
2. 踩準關鍵點，進一步深挖系統。
系統的性能指標，除了最典型指標即吞吐量或者響應時間，另外還有很多我們需要關注的指標，比如cpu，內存，io，數據庫連接數操作等等，於是我們在測試前還需要進一步深挖的系統，找出以下幾個關鍵點：
（1） 內存分配和使用。消息隊列的使用，緩存的使用
（2） 文件，網絡IO操作：大文件讀取到內存，或者將內存寫會文件，是否操作頻繁
（3） 耗cpu的操作：比如一些大內存排序
（4） 數據庫的操作：頻繁的進行數據庫的讀寫操作，頻繁的建立數據庫連接等等
（5） 網絡調用：網絡時延以及連接的併發
（6） 臨界資源：多進程處理模式中是否有加鎖不恰當的行爲
（7） ……
3. 設計測試用例
瞭解了以上的基本情況，其實都是爲這一步作準備的。在解決第一個情況的性能需求時顯得尤其省力，有經驗的性能測試人員在瞭解了以上的情況甚至可以不用設計測試就可以確定問題出在了哪裏！（lisa大膽揣測一下，儘管還沒有達到那個水平）
性能測試的測試用例不比功能測試，可以考慮很多的異常測試，因爲成本很小，而一次性能測試用例的執行常常需要消耗較大的資源和時間，所以精準的性能測試用例顯得尤爲重要。
性能測試用例的設計，根據Lisa這段時間的積累與總結，感覺可以從以下幾個方面着手。
（1） 選定最合適的邏輯分支進行測試。
往往會有很多分支可以滿足你的測試要求，選擇的時候，可以從以下兩點入手：A.受周邊影響最小，B，消耗的資源最少。
A點可以幫助我們很快的定位出問題，也許整條邏輯分支設計的系統會有很多，我們可以選擇涉及周邊系統最小但是卻可以包含被測系統在內的分支進行，當然最簡單的做法就是可以直接壓測被測系統，但這樣做有些問題是暴露不出來的。
B點可以幫助我們節省資源，比如已經有現成的環境了，總之我所需要準備的東西減少了，自然就速度快效率高了，而對於新系統或者從未進行過性能測試的老系統，在時間有限的情況下，我們還需要結合實際情況，選擇用戶請求量最多的最重要的分支進行測試。
（2） 根據前面的分析，設計最有針對性，最有效的測試用例。
比如說我懷疑導致aqc系統性能下降的原因是本次迭代新增了大內存的排序。例如aqc系統有一條分支將用戶所有的cdkey查詢出來然後按照時間排序，並全部返回給用戶。那麼我們怎麼讓這個問題得到驗證呢？在設計的時候可以選擇兩種極端的情況極其組合進行測試，一種是所有用戶均沒有cdkey，另一種是所有用戶均含有500個cdkey，最後一種則是兩者的組合，比較一下則可以驗證出是否是因爲偶爾的某些用戶的cdkey太多，導致整體的性能下降。
當然在測試的過程中，我們還需要根據現有的數據調整測試用例，幫助我們驗證猜想，更清晰的定位問題
（3） 請教有經驗的性能測試人員往往會有驚喜
在經驗有限的情況下，着手處理前和前輩請教下，不僅可以提高工作效率，更可以增長見聞。但是這點恐怕也是很多人忽略的。任務來了，不要急着入手，先問問往往可以拓展思路。
4. 測試環境的準備
測試環境的搭建往往要根據測試用例的設計而確定。對於初次進行性能測試的系統，我們的目標是儘可能的和現網一致。可以主要從以下幾個方面入手。
（1） 數據：大數據量以及數據的多樣性往往是模擬的難點。大數據量需要自己寫腳本將數據庫填充到一定的程度，如果要求高的話，甚至可以採用從現網導數據的方法。多樣性往往比較難以實現，需要了解現網的數據多樣性以及比例，達到模擬的效果
（2） 網絡時延：這個和公司的IDC機器管理很相關.我之前一直以爲所有的測試機器都在一個IDC,後來發現其實不然，我們的測試機器也和運營機器一樣，分佈在不同的IDC，而我們在挑選機器部署時，需要先了解一下現網運營機器之間的網絡時延。這在測試整個一條邏輯分支的性能時尤爲重要。
（3） 配置：日誌級別的配置，線程或進程的個數，如果條件允許，配置可以升級到機器的硬件的配置，如果可以一致自然是最理想的效果。
這裏有一個誤區，我之前一直以爲最好每次測試的環境都儘量的去和現網靠攏，但是在聽了yuetangdeng的一堂課之後，發現IBM並不是這麼做的，對於以前曾經做過性能測試的系統，往往那套環境還是存在的（不管這套環境是否之前和現網一致），而測試我們更多的是想驗證系統是否存在性能問題，想想與上一次測試周邊環境都相同的情況下，新的迭代版本替換後系統性能明顯下降了，難道還不能說明問題麼？
在一切都準備好了，接下來我們就可以開始準備測試工具來執行我們的測試用例啦~~~~
