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

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

　　性能測試的需求背景一般來自于以下三種情況：

　　第一種是現網出現性能問題，項目組專門進行了性能改造。比如修改的某個接口，由原來的同步調用修改成了異步，又或者是更換了新的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)網絡調用：網絡時延以及連接的并發

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