性能測試流程介紹性能測試什么時候開始：一般在系統(tǒng)功能穩(wěn)定沒有大的缺陷之后開始執(zhí)行。但前期準備工作可以從系統(tǒng)需求分近時就開始：性能目標制定、場景獲取、環(huán)境申請等。一、制定性能測試目標在特定的并發(fā)用戶數(shù)下測試特定場景的響應(yīng)時間在一定的響應(yīng)時間的要求下來測試特定場景的最大并發(fā)用戶數(shù)測試特定場景的TPS1、線上系統(tǒng)對線上系統(tǒng)的日志進行分析以獲取到這個系統(tǒng)每個功能的訪問情況、最大的并發(fā)用戶量、平均/最大/最小響應(yīng)時間。然后通過每日的增長趨勢來確定最大的并發(fā)用戶數(shù)、響應(yīng)時間參考日志分析的結(jié)果，即與平均響應(yīng)時間相當。2、全新項目開發(fā)過程相關(guān)文檔項目開發(fā)計劃書、需求規(guī)格說明書、設(shè)計說明書等文檔都可能涉及性能測試的要求。通過收集這些材料，可以找到初步的性能需求。但這些性能測試需求往往不夠準確，需要性能測試人員進行專業(yè)的引導。類似項目公司的其他產(chǎn)品或以往項目會累積出一些數(shù)據(jù)，可以作為參考。用戶使用模型分析用戶使用模型是獲取性能測試需求的有效手段，考慮哪些用戶使用系統(tǒng)的哪些典型的業(yè)務(wù)，在什么時段有多少用戶進行了什么功能的操作。例如：某OA系統(tǒng)每天早上8:00會有200個用戶在10分鐘內(nèi)登錄系統(tǒng)；每天查詢交易的高峰是在9:00~11:00和下午的14:00~16:00等，然后根據(jù)這個用戶使用模型并結(jié)合80/20原則計算OA系統(tǒng)的登錄以及交易查詢業(yè)務(wù)的并發(fā)量。80/20原則80/20原理就是系統(tǒng)在每個工作日有80%的業(yè)務(wù)是在20%的時間內(nèi)集中完成，或者系統(tǒng)80%的用戶會在20%的時間內(nèi)集中進行應(yīng)用操作。下面我們來舉兩個例子說明：某網(wǎng)站每日的總訪問人數(shù)為10萬，其中瀏覽單品頁占30%，搜索業(yè)務(wù)占20%，登錄+購買業(yè)務(wù)占50%。采用80~20原則，8小時的20%作為基準時間，計算各個業(yè)務(wù)的并發(fā)數(shù)。搜索業(yè)務(wù)：(100000*20%*80%)/(8*3600*20%)=2.78取整為3瀏覽單品頁：(100000*30%*80%)/(8*3600*20%)=4.17取整為5登錄+購買：(100000*50%*80%)/(8*3600*20%)=6.94取整為7系統(tǒng)每年的業(yè)務(wù)集中在8個月完成，每個月平均有20個工作日，每個工作日8小時，按照80/20原則，即每天80%的業(yè)務(wù)在1.6小時完成。去年全年處理業(yè)務(wù)約100萬筆，其中15%的業(yè)務(wù)處理中每筆業(yè)務(wù)需對應(yīng)用服務(wù)器提交7次請求，其中70%的業(yè)務(wù)處理中每筆業(yè)務(wù)需對應(yīng)用服務(wù)器提交5次請求，剩余15%的業(yè)務(wù)處理中每筆業(yè)務(wù)需對應(yīng)用服務(wù)器提交3次請求。根據(jù)以往的統(tǒng)計結(jié)果，每年的業(yè)務(wù)增長量為15%，考慮到今后3年的業(yè)務(wù)發(fā)展需要，測試需按現(xiàn)有業(yè)務(wù)量的兩倍進行請求數(shù)來計算系統(tǒng)應(yīng)該達到的TPS。每年的總請求數(shù)二(100萬*15%*7+100萬*70%*5+100萬*15%*3)*2=1000萬TPS=(10000000*80%)/(8*20*8*3600*20%)=8.68,取整即TPS=9響應(yīng)時間標準2秒以內(nèi)，用戶感受良好2~5秒，用戶覺得可以接受5~10秒，用戶會覺得很煩躁，無法接收，會頻繁刷新頁面10秒以上，用戶完全無法接收，直接離開二、性能測試場景獲取1、線上系統(tǒng)單場景：根據(jù)對線上系統(tǒng)的日志分析結(jié)果，訪問量排在前面的功能、本次改動的以及可能會影響到的功能、和錢有關(guān)的功能。為保險起見最好再和開發(fā)確認一下會影響到的功能?；旌蠄鼍埃哼€是根據(jù)線上系統(tǒng)的日志分析結(jié)果，得到系統(tǒng)級別的最大并發(fā)數(shù)，再根據(jù)每日的增長趨勢做一個增量從而得到最終的最大并發(fā)數(shù)。然后根據(jù)日志分析結(jié)果中的各個重要功能的占比數(shù)來進行用戶分配。穩(wěn)定性場景：確定好單場景和混合場景后，還應(yīng)該考慮穩(wěn)定性場景。其目的是測試系統(tǒng)是否有內(nèi)存泄漏現(xiàn)象發(fā)生，同時也可以測試系統(tǒng)的平均無故障時間。所以，可以用混合場景做長時間的穩(wěn)定性測試。2、全新項目單場景：重要、核心的功能常用功能業(yè)務(wù)流程復(fù)雜的功能資源占用嚴重的功能（比如多表查詢或向多張表中插入數(shù)據(jù)）混合場景：根據(jù)一定的比例把所有重要的功能都加入混合場景穩(wěn)定性場景：可以考慮用混合場景做長時間的穩(wěn)定性測試。三、性能測試數(shù)據(jù)確定性能測試中很重要的一點就是場景數(shù)據(jù)的設(shè)計。比如一個數(shù)據(jù)查詢場景，如果該場景對應(yīng)的數(shù)據(jù)庫表只有10條數(shù)據(jù)，那么查詢結(jié)果肯定相對較快。但是，如果這個查詢場景對應(yīng)的數(shù)據(jù)庫表有1000萬條數(shù)據(jù)，那么查詢結(jié)果肯定會比只有10條數(shù)據(jù)的查詢結(jié)果要慢一些。如果性能測試不考慮數(shù)據(jù)量，那么性能測試的結(jié)果是不準確的，上線后由于未考慮數(shù)據(jù)量的因素而引發(fā)的性能問題幾率會很大。對于線上系統(tǒng)來說，各表的數(shù)據(jù)量可以根據(jù)線上系統(tǒng)的各表數(shù)據(jù)量以及增量來確定。而新系統(tǒng)需要根據(jù)開發(fā)文檔以及和相關(guān)項目干系人（如：客戶代表、項目經(jīng)理、需求分析員、系統(tǒng)架構(gòu)師以及產(chǎn)品經(jīng)理一起調(diào)研和討論來決定）四、性能測試用例設(shè)計1、單場景場景描述：模擬用戶進行登錄操作并發(fā)量：分別模擬并發(fā)用戶數(shù)為1、10、50三種情況進行測試壓測時間：每次15分鐘數(shù)據(jù)量：MySQL的user表中有70萬賬戶集合點：不使用集合點重點關(guān)注指標：響應(yīng)時間、事物成功率、應(yīng)用服務(wù)器資源使用情況（CPU、內(nèi)存、IO）、MySQL數(shù)據(jù)庫資源使用情況（CPU、內(nèi)存、IO）、應(yīng)用日志是否有死鎖等錯誤、數(shù)據(jù)庫日志是否有死鎖等錯誤、JVM內(nèi)存使用情況和GC情況預(yù)期指標：響應(yīng)時間在2秒內(nèi)、事物成功率為100%、應(yīng)用服務(wù)器和數(shù)據(jù)庫服務(wù)器CPU使用率＜60%、沒有內(nèi)存泄漏、數(shù)據(jù)庫死鎖、線程死鎖等現(xiàn)象2、混合場景混合場景不是把所有的測試場景糅合在一起形成一個大的場景，而應(yīng)該先考慮不同的混合場景組合，如數(shù)據(jù)庫查詢操作的混合場景、數(shù)據(jù)庫寫操作的混合場景、數(shù)據(jù)庫查詢與寫操作都包含的大混合場景。如下：場景描述：模擬系統(tǒng)不用用戶進行數(shù)據(jù)庫讀寫操作的混合場景，場景包括用戶登錄、廣告詞默認查詢、新建廣告組、廣告詞默認創(chuàng)建、廣告審核、廣告生效、廣告詞按價格排序。并發(fā)量：總共模擬300個用戶同時操作，其中登錄操作占比20%、廣告詞默認查詢占比25%、新建廣告組占比15%、廣告詞默認創(chuàng)建8%、廣告審核10%、廣告生效15%、廣告詞按價格排序7%壓測時間：每次15分鐘數(shù)據(jù)量：MySQL的cpc表有150萬條數(shù)據(jù)、plan表有10萬條數(shù)據(jù)、group表有50萬條數(shù)據(jù)、audit表有100萬條數(shù)據(jù)，MongoDB的report表有1TB數(shù)據(jù)、user表有90萬條數(shù)據(jù)。集合點：不使用集合點重點關(guān)注指標：響應(yīng)時間、事物成功率、應(yīng)用服務(wù)器資源使用情況（CPU、內(nèi)存、IO）、MySQL數(shù)據(jù)庫資源使用情況（CPU、內(nèi)存、IO）、應(yīng)用日志是否有死鎖等錯誤、數(shù)據(jù)庫日志是否有死鎖等錯誤、JVM內(nèi)存使用情況和GC情況預(yù)期指標：登錄、廣告詞默認查詢、新建廣告組等操作響應(yīng)時間在2秒內(nèi)，廣告詞默認創(chuàng)建、廣告審核、廣告生效、廣告詞按價格排序等操作響應(yīng)時間在3秒內(nèi)，事物成功率為100%、應(yīng)用服務(wù)器和數(shù)據(jù)庫服務(wù)器CPU使用率《60%、沒有內(nèi)存泄漏、數(shù)據(jù)庫死鎖、線程死鎖等現(xiàn)象3、穩(wěn)定性場景場景描述：模擬系統(tǒng)不用用戶進行數(shù)據(jù)庫讀寫操作的混合場景，場景包括用戶登錄、廣告詞默認查詢、新建廣告組、廣告詞默認創(chuàng)建、廣告審核、廣告生效、廣告詞按價格排序。并發(fā)量：總共模擬300個用戶同時操作，其中登錄操作占比20%、廣告詞默認查詢占比25%、新建廣告組占比15%、廣告詞默認創(chuàng)建8%、廣告審核10%、廣告生效15%、廣告詞按價格排序7%壓測時間：持續(xù)2*24小時數(shù)據(jù)量：MySQL的cpc表有150萬條數(shù)據(jù)、plan表有10萬條數(shù)據(jù)、group表有50萬條數(shù)據(jù)、audit表有100萬條數(shù)據(jù)，MongoDB的report表有1TB數(shù)據(jù)、user表有90萬條數(shù)據(jù)。集合點：不使用集合點重點關(guān)注指標：JVM內(nèi)存使用情況和GC情況預(yù)期指標：無內(nèi)存泄漏現(xiàn)象或跡象發(fā)生五、性能測試環(huán)境準備與搭建性能測試環(huán)境包括軟件環(huán)境、硬件環(huán)境和網(wǎng)絡(luò)環(huán)境。這三大環(huán)境不僅是指應(yīng)用服務(wù)器環(huán)境，還包括數(shù)據(jù)庫服務(wù)器、緩存服務(wù)器、文件服務(wù)器以及其他中間應(yīng)用服務(wù)器環(huán)境。硬件環(huán)境包括：CPU、內(nèi)存、磁盤等基本因素。軟件環(huán)境包括：操作系統(tǒng)版本號、配置，Linux磁盤分區(qū)、JDK版本、位數(shù)、廠商，中間件版本號、位數(shù)，數(shù)據(jù)庫版本號、位數(shù)，以及這些軟件的安裝路徑也最好與線上環(huán)境一致。配置文件包括JVM配置、中間件配置、數(shù)據(jù)庫配置文件等。網(wǎng)絡(luò)環(huán)境包括：網(wǎng)絡(luò)協(xié)議及網(wǎng)絡(luò)帶寬。集群環(huán)境包括：應(yīng)用相關(guān)服務(wù)器的負載均衡環(huán)境、數(shù)據(jù)庫的熱備或主從環(huán)境、集群環(huán)境等。申請線下仿真測試環(huán)境的時候，應(yīng)遵循以下原則：（1）硬件環(huán)境盡可能地保持與生產(chǎn)環(huán)境一致（2）如果是集群環(huán)境，測試環(huán)境就不可能申請到那么多臺服務(wù)器，那么可以考慮申請3臺與線上生產(chǎn)環(huán)境一致的機器來作為線下的性能測試機器。在性能測試的過程中，可以分別測試單機、雙機和三機負載均衡時候的性能表現(xiàn)，然后根據(jù)3種情況下性能表現(xiàn)計算出線上生產(chǎn)環(huán)境（比如說100臺）進行負載均衡時的性能損耗率，從而較為真實的計算出線上100臺機器進行負載均衡時候的性能指標。（3）如果數(shù)據(jù)庫集群環(huán)境太龐大，比如數(shù)據(jù)庫是8組32臺，那么線下測試不會申請32臺機器進行性能測試。一般這種情況只會申請一組數(shù)據(jù)庫（一主三從）作為性能測試的數(shù)據(jù)庫即可。因為大型數(shù)據(jù)庫的集群基本都是采用拆庫分表策略，所以會導致數(shù)據(jù)庫集群龐大。申請一組數(shù)據(jù)庫機器就可以開展性能測試，只需要保證性能測試所用的用戶數(shù)據(jù)都落在申請的這組數(shù)據(jù)庫即可。（4）如果實在無法保證硬件環(huán)境與線上一致，那么只能按照低配置環(huán)境進行測試，如果低配置環(huán)境測出的結(jié)果能滿足線上要求，那么線上高配置環(huán)境肯定也能滿足既定的性能要求。如果無法滿足，則不建議做建模估算，因為如果CPU顆粒數(shù)、高速緩存、物理內(nèi)存大小、磁盤轉(zhuǎn)速不同，性能建模得出的性能結(jié)果也不夠準確。如果在低配置的機器測試達不到要求，則要在測試報告中寫明測試環(huán)境，并說明不能保證因為測試環(huán)境的提升而達到要求。MockServer準備：在互聯(lián)網(wǎng)行業(yè)叫MockServer，在銀行等金融行業(yè)叫做性能測試擋板。有時候系統(tǒng)的業(yè)務(wù)聯(lián)調(diào)需要調(diào)用到其他系統(tǒng)的接口，但是其他系統(tǒng)的開發(fā)并未完成。對于這種情況，常見的解決方案是搭建一個臨時的server，模擬那些服務(wù)，提供數(shù)據(jù)進行聯(lián)調(diào)和測試。MockServer的使用通常會帶來以下好處：（1）隔絕由其他模塊或系統(tǒng)出錯引起的本模塊的測試錯誤。（2）隔絕其他模塊的開發(fā)狀態(tài)，只要定義好接口，不用管開發(fā)有沒有完成。（3）一些速度較慢的操作，可以用MockObject代替，快速返回。六、做腳本這里就不做詳細描述。七、跑場景根據(jù)測試用例來跑測試場景。做監(jiān)控在性能測試的過程中，先用命令來監(jiān)控，發(fā)現(xiàn)有問題再連上工具進