後臺性能測試總結—測試準備篇

在這半年以來，我陸續參加或者獨立承擔的項目組版本的部分性能測試，慢慢的有了一些認識，暫時作一個積累，和你們作一個交流

　　在這半年以來，我陸續參加或者獨立承擔的項目組版本的部分性能測試，慢慢的有了一些認識，暫時作一個積累，和你們作一個交流

　　性能測試的需求背景通常來自於如下三種狀況：

　　第一種是現網出現性能問題，項目組專門進行了性能改造。好比修改的某個接口，由原來的同步調用修改爲了異步，又或者是更換了新的api，由tcp協議修改成udp協議，爲了保證新替換的api的可靠性，都須要進行性能測試

　　第二種是一個新作的系統，運營人員須要全面的把脈，瞭解該系統的處理能力。

　　第三種是隨着請求量的快速增加，而該系統卻從未作過性能測試，項目組擔憂系統在可預見的短時間會扛不住，因此要求測試人員對該進行全面的性能測試，給出一份參考數據

　　根據背景的不一樣咱們每每有不一樣的準備方式，可是大體能夠從如下幾個方面入手準備。

　　一、全面瞭解該系統概況

　　(1)系統所指望的性能指標：

　　對於第一二兩種狀況，都會有很明確的現網性能指標，好比之前測試的acs，是一個新做的系統，需求說明書中就明確標註須要達到1wtps.而對於第三種狀況，每每咱們須要儘可能的模擬現網，得出數據供運營作參考。例如最近測試的查詢限制引擎，測試這邊給出了單臺svr的處理能力以及是否支持平行擴展等運維最關心的數據便可。

　　(2)組網以及網間各個系統之間的通訊形式：

　　有時咱們性能改造只是組網中一個小小的系統，這就須要咱們去弄清楚這個系統在整個邏輯處理中所處的位置。

　　圖1

　　瞭解被測系統在整個交易中的位置，對於測試用例的設計以及測試環境的搭建是相當重要的

　　其次，還須要瞭解組網中各個模塊之間的通訊方式，tcporudp，同步調用仍是異步調用，長鏈接仍是短鏈接。

　　(3)系統的各個邏輯分支：

　　瞭解系統的邏輯分支，主要是有利於設計測試用例。在咱們實際的工做過程當中，時間老是頗有限的，而咱們提升工做效率的一個很重要的方法就是重視用例的設計，瞭解了系統的各個邏輯分支，能夠很精準的準備用例，直擊問題的本質，減小摸索的時間。

　　舉一個例子，psc系統性能改造版本(如圖1)，幾乎全部的業務邏輯都要走ssp去查詢是否受限，可是咱們選擇其中的一條最簡單的受周邊系統最小的二級贈送分支進行測試，利用最短的成本驗證問題，很好的保證了測試的進度

　　(4)系統內部模塊的組合：

　　較爲複雜的系統，都會有本身的模塊組合方式。咱們須要瞭解系統由幾個模塊組成，各個模塊的耦合關係是怎樣的，不只對於功能測試中的異常測試用例的設計有很大幫助，對於性能測試的幫助也一樣不可小覷。

　　舉一個比較簡單的例子：aqc系統，這個系統是供外部查詢的，內部的模塊大體分爲：網絡通訊層，請求分發層，功能處理層。網絡通訊層主要是利用某網絡通訊組件，處理網絡通訊，請求分發層dispatch，主要將網絡通訊層隊列的包根據cmdcode的不一樣分發到後端的功能處理層，功能處理層則有一個個小svr組成，每一個svr處理不一樣的查詢請求。

　　假若有一個性能需求是發現現網有一個查詢分支性能不OK，那麼咱們就須要很快的鎖定關鍵的模塊，瓶頸極可能存在與處理這條分支的svr上。

　　其次瞭解了系統的各個模塊以及模塊之間的耦合關係，在理解性能曲線，調整測試方案時一樣很重要。

　　二、踩準關鍵點，進一步深挖系統

　　系統的性能指標，除了最典型指標即吞吐量或者響應時間，另外還有不少咱們須要關注的指標，好比cpu，內存，io，數據庫鏈接數操做等等，因而咱們在測試前還須要進一步深挖的系統，找出如下幾個關鍵點：

　　(1)內存分配和使用。消息隊列的使用，緩存的使用

　　(2)文件，網絡IO操做：大文件讀取到內存，或者將內存寫會文件，是否操做頻繁

　　(3)耗cpu的操做：好比一些大內存排序

　　(4)數據庫的操做：頻繁的進行數據庫的讀寫操做，頻繁的創建數據庫鏈接等等

　　(5)網絡調用：網絡時延以及鏈接的併發

　　(6)臨界資源：多進程處理模式中是否有加鎖不恰當的行爲 (7) 三、設計測試用例 瞭解了以上的基本狀況，其實都是爲這一步做準備的。在解決第一個狀況的

　　(6)臨界資源：多進程處理模式中是否有加鎖不恰當的行爲

　　(7)……

　　三、設計測試用例

　　瞭解了以上的基本狀況，其實都是爲這一步做準備的。在解決第一個狀況的性能需求時顯得尤爲省力，有經驗的性能測試人員在瞭解了以上的狀況甚至能夠不用設計測試就能夠肯定問題出在了哪裏!(lisa大膽揣測一下，儘管尚未達到那個水平)

　　性能測試的測試用例不比功能測試，能夠考慮不少的異常測試，由於成本很小，而一次性能測試用例的執行經常須要消耗較大的資源和時間，因此精準的性能測試用例顯得尤其重要。

　　性能測試用例的設計，根據Lisa這段時間的積累與總結，感受能夠從如下幾個方面着手。

　　(1)選定最合適的邏輯分支進行測試

　　每每會有不少分支能夠知足你的測試要求，選擇的時候，能夠從如下兩點入手：A.受周邊影響最小，B，消耗的資源最少。

　　A點能夠幫助咱們很快的定位出問題，也許整條邏輯分支設計的系統會有不少，咱們能夠選擇涉及周邊系統最小可是卻能夠包含被測系統在內的分支進行，固然最簡單的作法就是能夠直接壓測被測系統，但這樣作有些問題是暴露不出來的。

　　B點能夠幫助咱們節省資源，好比已經有現成的環境了，總之我所須要準備的東西減小了，天然就速度快效率高了，而對於新系統或者從未進行過性能測試的老系統，在時間有限的狀況下，咱們還須要結合實際狀況，選擇用戶請求量最多的最重要的分支進行測試。

　　(2)根據前面的分析，設計最有針對性，最有效的測試用例

　　好比說我懷疑致使aqc系統性能降低的緣由是本次迭代新增了大內存的排序。例如aqc系統有一條分支將用戶全部的cdkey查詢出來而後按照時間排序，並所有返回給用戶。那麼咱們怎麼讓這個問題獲得驗證呢?在設計的時候能夠選擇兩種極端的狀況極其組合進行測試，一種是全部用戶均沒有cdkey，另外一種是全部用戶均含有500個cdkey，最後一種則是二者的組合，比較一下則能夠驗證出是不是由於偶爾的某些用戶的cdkey太多，致使總體的性能降低。

　　固然在測試的過程當中，咱們還須要根據現有的數據調整測試用例，幫助咱們驗證猜測，更清晰的定位問題

　　(3)請教有經驗的性能測試人員每每會有驚喜

　　在經驗有限的狀況下，着手處理前和前輩請教下，不只能夠提升工做效率，更能夠增加見聞。可是這點恐怕也是不少人忽略的。任務來了，不要急着入手，先問問每每能夠拓展思路。

　　四、測試環境的準備

　　測試環境的搭建每每要根據測試用例的設計而肯定。對於初次進行性能測試的系統，咱們的目標是儘量的和現網一致。能夠主要從如下幾個方面入手。

　　(1)數據：大數據量以及數據的多樣性每每是模擬的難點。大數據量須要本身寫腳本將數據庫填充到必定的程度，若是要求高的話，甚至能夠採用從現網導數據的方法。多樣性每每比較難以實現，須要瞭解現網的數據多樣性以及比例，達到模擬的效果

　　(2)網絡時延：這個和公司的IDC機器管理很相關.我以前一直覺得全部的測試機器都在一個IDC，後來發現其實否則，咱們的測試機器也和運營機器同樣，分佈在不一樣的IDC，而咱們在挑選機器部署時，須要先了解一下現網運營機器之間的網絡時延。這在測試整個一條邏輯分支的性能時尤其重要。

　　(3)配置：日誌級別的配置，線程或進程的個數，若是條件容許，配置能夠升級到機器的硬件的配置，若是能夠一致天然是最理想的效果。

　　這裏有一個誤區，我以前一直覺得最好每次測試的環境都儘可能的去和現網靠攏，可是在聽了yuetangdeng的一堂課以後，發現IBM並非這麼作的，對於之前曾經作過性能測試的系統，每每那套環境仍是存在的(無論這套環境是否以前和現網一致)，而測試咱們更多的是想驗證系統是否存在性能問題，想一想與上一次測試周邊環境都相同的狀況下，新的迭代版本替換後系統性能明顯降低了，難道還不能說明問題麼?

　　在一切都準備好了，接下來咱們就能夠開始準備測試工具來執行咱們的測試用例啦~~~~

 

　　轉自：http://www.uml.org.cn/Test/201308025.asp