在這半年以來，我陸續參加或者獨立承擔的專案組版本的部分效能測試，慢慢的有了一些認識，暫時做乙個積累，和大家做乙個交流
在這半年以來，我陸續參加或者獨立承擔的專案組版本的部分效能
測試，慢慢的有了一些認識，暫時做乙個積累，和大家做乙個交流
效能測試
的需求背景一般來自於以下三種情況：
第一種是現網出現效能問題，專案組專門進行了效能改造。比如修改的某個介面，由原來的同步呼叫修改成了非同步，又或者是更換了新的api，由tcp協議修改為udp協議，為了保證新替換的api的可靠性，都需要進行效能測試
第二種是乙個新做的系統，運營人員需要全面的把脈，了解該系統的處理能力。
第三種是隨著請求量的快速增長，而該系統卻從未做過效能測試，專案組擔心系統在可預見的短期會扛不住，所以要求測試人員
對該進行全面的效能測試，給出乙份參考資料
根據背景的不同我們往往有不同的準備方式，但是大致可以從以下幾個方面入手準備。
1、全面了解該系統概況
(1)系統所期望的效能指標：
對於第一二兩種情況，都會有很明確的現網效能指標，比如以前測試的acs，是乙個新作的系統，需求說明書中就明確標註需要達到1wtps.而對於第三種情況，往往我們需要盡量的模擬現網，得出資料供運營做參考。例如最近測試的查詢限制引擎，測試這邊給出了單台svr的處理能力以及是否支援平行擴充套件等運維最關心的資料即可。
(2)組網以及網間各個系統之間的通訊形式：
有時我們效能改造只是組網中乙個小小的系統，這就需要我們去弄清楚這個系統在整個邏輯處理中所處的位置。
圖1了解被測系統在整個交易中的位置，對於測試
用例的設計以及測試環境的搭建是至關重要的
其次，還需要了解組網中各個模組之間的通訊方式，tcporudp，同步呼叫還是非同步呼叫，長連線還是短連線。
(3)系統的各個邏輯分支：
了解系統的邏輯分支，主要是有利於設計測試用例。在我們實際的工作過程中，時間總是很有限的，而我們提高工作效率的乙個很重要的方法就是重視用例的設計，了解了系統的各個邏輯分支，可以很精準的準備用例，直擊問題的本質，減少摸索的時間。
舉乙個例子，psc系統效能改造版本(如圖1)，幾乎所有的業務邏輯都要走ssp去查詢是否受限，但是我們選擇其中的一條最簡單的受周邊系統最小的二級贈送分支進行測試，利用最短的成本驗證問題，很好的保證了測試的進度
(4)系統內部模組的組合：
較為複雜的系統，都會有自己的模組組合方式。我們需要了解系統由幾個模組組成，各個模組的耦合關係是怎樣的，不僅對於功能測試
中的異常測試用例的設計有很大幫助，對於效能測試的幫助也同樣不可小覷。
舉乙個比較簡單的例子：aqc系統，這個系統是供外部查詢的，內部的模組大致分為：網路通訊層，請求分發層，功能處理層。網路通訊層主要是利用某網路通訊元件，處理網路通訊，請求分發層dispatch，主要將網路通訊層佇列的包根據cmdcode的不同分發到後端的功能處理層，功能處理層則有乙個個小svr組成，每個svr處理不同的查詢請求。
倘若有乙個效能需求是發現現網有乙個查詢分支效能不ok，那麼我們就需要很快的鎖定關鍵的模組，瓶頸很可能存在與處理這條分支的svr上。
其次了解了系統的各個模組以及模組之間的耦合關係，在理解效能曲線，調整測試方案時同樣很重要。
2、踩準關鍵點，進一步深挖系統
系統的效能指標，除了最典型指標即吞吐量或者響應時間，另外還有很多我們需要關注的指標，比如cpu，記憶體，io，資料庫
連線數操作等等，於是我們在測試前還需要進一步深挖的系統，找出以下幾個關鍵點：
(1)記憶體分配和使用。訊息佇列的使用，快取的使用
(2)檔案，網路io操作：大檔案讀取到記憶體，或者將記憶體寫會檔案，是否操作頻繁
(3)耗cpu的操作：比如一些大記憶體排序
(4)資料庫的操作：頻繁的進行資料庫的讀寫操作，頻繁的建立資料庫連線等等
(5)網路呼叫：網路時延以及連線的併發
(6)臨界資源：多程序處理模式中是否有加鎖不恰當的行為 (7) 3、設計測試用例 了解了以上的基本情況，其實都是為這一步作準備的。在解決第乙個情況的
(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並不是這麼做的，對於以前曾經做過效能測試的系統，往往那套環境還是存在的(不管這套環境是否之前和現網一致)，而測試我們更多的是想驗證系統是否存在效能問題，想想與上一次測試周邊環境都相同的情況下，新的迭代版本替換後系統效能明顯下降了，難道還不能說明問題麼?
在一切都準備好了，接下來我們就可以開始準備測試工具
來執行我們的測試用例啦~~~~
**：
效能測試準備
效能需求評估 系統特殊要求 從實時性角度來分析，某些系統對響應時間要求比較，比如餐飲系統，系統的快慢直接影響客戶的感受，這種情況就有作併發測試的必要，在大併發量的場景下，檢視這個功能的響應時間 確定效能測試點 日請求量 確定被測專案各功能點的日請求量 可以統計不同時間粒度下的請求量如 小時，日，周，...
效能測試總結 二 測試流程篇
glen.he 出處 本文主要介紹下效能測試的基本流程，效能測試從實際執行層面來看，測試的過程一般分為這麼幾個階段，如下圖 下面分別介紹下每個階段具體需要做什麼 一 效能需求分析 效能需求分析是整個效能測試工作開展的基礎，如果連效能的需求都沒弄清楚，後面的效能測試執行其實是沒有任何意義的，而且效能需...
效能測試總結 二 測試流程篇
本文主要介紹下效能測試的基本流程，效能測試從實際執行層面來看，測試的過程一般分為這麼幾個階段，如下圖 下面分別介紹下每個階段具體需要做什麼 一 效能需求分析 效能需求分析是整個效能測試工作開展的基礎，如果連效能的需求都沒弄清楚，後面的效能測試執行其實是沒有任何意義的，而且效能需求分析做的好不好直接影...