優(yōu)質文章，第一時間送達！
各位好，我叫王捷豪，在測試行業(yè)已經有7年，曾從事過酒店、空氣質量、電網領域，目前是國內某互聯(lián)網醫(yī)療公司研發(fā)中心基礎平臺部一名測試開發(fā)工程師，多年的測試工作對測試知識有一些小認識，希望通過該篇文章與各位分享關于如何開展不同測試類型的性能測試，以及性能測試環(huán)節(jié)中遇到的一些問題與解決方案。本次性能測試是針對集成服務開展的一系列性能測試，其中性能測試范圍包括基準測試、配置&定容定量測試。
內有干貨，篇符較長，請耐心品完
集成服務（Integration Services）是用于生成高性能數(shù)據(jù)集成和工作流，包括針對數(shù)據(jù)源數(shù)據(jù)的提取、轉換和加載等操作的解決方案，主要解決眾多系統(tǒng)情況下，不同系統(tǒng)之間點對點通信需要開發(fā)新接口問題。因此，通過搭建統(tǒng)一規(guī)范、統(tǒng)一代碼、統(tǒng)一接口的信息集成平臺，以集成服務為中介，實現(xiàn)各系統(tǒng)間的信息共享和交互。
下圖是基于集成服務部署的一個數(shù)據(jù)同步集成方案，該集成方案通過獲取數(shù)據(jù)源數(shù)據(jù)，并按照映射關系轉化數(shù)據(jù)，同步至目標數(shù)據(jù)庫，集成方案具體操作有以下幾點：
通過日志輪詢JDBC連接數(shù)據(jù)庫，按照設定的時間間隔，定時查詢任務日志表多條日志數(shù)據(jù)，返回日志數(shù)據(jù)所關聯(lián)的業(yè)務數(shù)據(jù)
通過分支節(jié)點修改發(fā)送次數(shù)，記錄操作次數(shù)，當操作次數(shù)超出3次，日志仍處于同步失敗狀態(tài)，則不再同步該條日志的業(yè)務數(shù)據(jù)
通過映射處理器轉換數(shù)據(jù)，并保存數(shù)據(jù)至目標數(shù)據(jù)庫，同時修改日志表日志狀態(tài)為成功
在性能測試過程中，了解服務的系統(tǒng)架構圖能夠更清楚性能壓力在哪個環(huán)節(jié)上，如在集成服務同步數(shù)據(jù)過程中，可以對數(shù)據(jù)庫、集成服務、中間件、日志服務器等節(jié)點進行監(jiān)控。
在開展性能測試前，通常情況下需要選擇性能測試工具對接口進行多并發(fā)施壓，如主流的性能工具LoadRunner、JMeter，但實際上壓測對象不一定是可見的接口。對于本次分享的集成服務，其原理是通過設置的定時器按照最快秒級頻率觸發(fā)一次同步任務，其壓力不在接口并發(fā)數(shù)量上，而是在調度頻率、同步數(shù)據(jù)量大小上，因此無法借助性能工具進行壓測。
基準測試（benchmarking）是在某個時間點通過基準測試建立一個已知的性能水平線（稱為基準線），當系統(tǒng)的軟硬件環(huán)境發(fā)生變化之后，通過再次基準測試建立新基準線，對新舊基準線進行比較，以確定哪些變化對性能的影響。
在進行基準測試前，需制定相應測試計劃，確定測試目的、測試范圍、測試環(huán)境、集成方案、測試準備內容、測試用例等內容。
在測試范圍上，挑選了兩個業(yè)務場景（見下方表格），其中注冊場景，其視圖關聯(lián)表數(shù)據(jù)復雜程度低；而登記場景，其視圖關聯(lián)表數(shù)據(jù)復雜程度相對注冊場景高，且關聯(lián)表字段有BLOB類型字段，該字段可以存儲二進制文件。這兩個場景的區(qū)別在查詢一條數(shù)據(jù)時，數(shù)據(jù)大小和關聯(lián)復雜程度。
在部署測試集成方案時，通過和現(xiàn)場開發(fā)人員、產品經理多次確認生產實際部署方案，目的是為了盡可能貼近現(xiàn)場方案。由于性能測試開展在現(xiàn)場部署之前，最終測試集成方案（見下方第一張圖）和生產集成方案上存在一定區(qū)別（見下方第二張圖），這與前期評估不夠精準以及現(xiàn)場人員對業(yè)務需求進一步了解后發(fā)生的變更有關系。
在測試準備內容方面，除了部署集成方案，需按照場景分別制造測試數(shù)據(jù)，了解表與表之間的關聯(lián)關系，此次批量制造日志表1w條數(shù)據(jù)，視圖表數(shù)據(jù)10w至20w數(shù)據(jù)。
#批量制造數(shù)據(jù)SQL
BEGIN
for i in 1 .. 100000 loop
#插入SQL
INSERT INTO INSERT INTO "庫名"."表名" (字段名,關聯(lián)id字段名) VALUES ('字段值', i);
end loop;
commit;
END;
在基準測試用例方面，挑選了調度頻率、日志輪詢查詢條數(shù)、數(shù)據(jù)大小、日志表數(shù)據(jù)量、視圖表數(shù)據(jù)量五個變量進行測試，通過五個變量采集同步數(shù)據(jù)總耗時、每秒可同步條數(shù)、實際調度頻率結果，最終找出最佳方案設置下最佳基準線。同時，對每個變量設定中值線（下表調度頻率變量3秒每次），在中值線基礎上設置下限值（下表調度頻率變量1秒每次）和上限制（下表調度頻率變量5秒每次），其中中值線通過和現(xiàn)場開發(fā)人員、產品經理溝通確定，測試過程中會發(fā)現(xiàn)確定的中值線不一定準確，因此需要額外場景測試找到中值線。
問題1：制造10w數(shù)據(jù)的時候，插入數(shù)據(jù)失敗，提示unable to extend lob segment by 128 xxxx in tablespace xxxx
解決方案：找DBA增加表空間
問題2：基準測試開展前，由于集成方案保存數(shù)據(jù)接口通過其它產品線開發(fā)人員配置，因此需要產品線和產品線之間開發(fā)人員的配合，但實際還面臨其它產品線開發(fā)人員去了現(xiàn)場或是有其它緊急任務，導致基準測試進度無法推進
解決方案：創(chuàng)建一個性能測試專項群，把產品經理、開發(fā)人員、測試人員拉進去，通過產品經理推動性能測試進度，同時根據(jù)任務優(yōu)先級安排時間和工作，如開發(fā)人員現(xiàn)場任務緊急，測試人員可以準備測數(shù)據(jù)以及設計測試用例等其它工作
問題3：采集結果波動大，如上方表格場景編號1-1測試用例，1w條日志同步完總耗時可能偏差10多秒，是因為測試環(huán)境不只是一個用戶使用，而且部署了非當前性能測試其它服務
解決方案：最好的方式是部署獨立的測試環(huán)境，但實際上部署成本高以及設備資源少，只能協(xié)調或避開測試環(huán)境多用戶使用高峰期，或者對場景進行多次采集，剔除異常數(shù)據(jù)之后求均值
問題4：集成方案調度任務狀態(tài)出現(xiàn)長時間處于執(zhí)行中，或是集成服務出現(xiàn)崩潰，由于集成服務內存分配了512M，而JDBC節(jié)點查詢數(shù)據(jù)時主要消耗內存資源，導致JVM頻繁GC
解決方案：集成服務調整內存分配至1G，同時限制JDBC節(jié)點查詢數(shù)據(jù)量以及降低調度頻率
配置測試：通過對被測試軟件的軟硬件配置進行測試，找到系統(tǒng)各項資源的最優(yōu)分配原則。配置測試能充分利用有限的軟硬件資源，發(fā)揮系統(tǒng)的最佳處理能力，同時可以將其與其它性能測試類型聯(lián)合應用，從而為系統(tǒng)提供重要依據(jù)。
定容定量測試：在一定的軟硬件條件下，在數(shù)據(jù)庫中構造不同數(shù)量級的記錄數(shù)量，通過運行一種或多種業(yè)務場景在一定虛擬用戶數(shù)量的情況下，獲取不同數(shù)量級別的性能指標，從而得到在該數(shù)量級下系統(tǒng)能夠處理的最大會話能力、最大容量等。
與基準測試5.1工作開展過程不同的是，配置&定容定量測試調整了場景用例和增加了監(jiān)控。
在測試用例設計上，選擇了注冊場景、更新場景作為相同場景，用于測試多節(jié)點場景。另選擇登記場景作為定容定量場景，通過更改BLOB文件大小控制數(shù)據(jù)量級。
在選擇性能監(jiān)控平臺上，數(shù)據(jù)庫監(jiān)控通過Grafana平臺，主機監(jiān)控由于公司沒有統(tǒng)一的監(jiān)控平臺，因此主機監(jiān)控通過多個平臺配合監(jiān)控，包括Grafana、VMware vSphere、linux命令、Spring Boot Admin。
在開始配置測試前，由于需要更改CPU、內存、磁盤等資源，因此需要運維工程師協(xié)助驅散集成服務所在節(jié)點，禁止別的容器調度節(jié)點，同時需要系統(tǒng)工程師協(xié)助調整主機CPU和磁盤資源大小，再由測試工程師自行重啟集成服務，調整服務使用內存大小。由于啟動集成服務至少需要內存 500M、磁盤 100G、CPU 4核，否則較易出現(xiàn)服務崩潰或啟動服務失敗，因此以該配置做為最低配置。
在配置過程中，通過更改CPU核數(shù)發(fā)現(xiàn)，當CPU4核時，CPU使用率70%左右。同時，CPU核數(shù)對數(shù)據(jù)同步速度影響不大，每秒同步條數(shù)相差不大。
通過更改內存發(fā)現(xiàn)，當內存大小足以緩存低數(shù)量級數(shù)據(jù)時，內存大小對同步數(shù)據(jù)速度影響不大，每秒同步條數(shù)相差不大。
但當數(shù)據(jù)的數(shù)據(jù)量級發(fā)生變更，數(shù)據(jù)量級逐漸增大時，內存回收速度逐漸變快，一開始呈規(guī)律性回收（下方第一二張圖），最后呈非規(guī)律性回收（下方第三張圖）。
通過配置測試結果也可知，當數(shù)據(jù)量級增大時，內存消耗增大，集成服務同步速度下降。
問題1：在配置測試過程中，再次出現(xiàn)采集數(shù)據(jù)波動較大，后來發(fā)現(xiàn)是數(shù)據(jù)保存接口所在服務器磁盤問題等待時間過長導致
解決方案：更換主機磁盤
問題2：在測試過程中，出現(xiàn)磁盤不足，當前配置磁盤大小100G，而日志會記錄各個節(jié)點處理日志，包括打印出SQL查詢的數(shù)據(jù)，并且沒有定時清理日志
解決方案：日志只截取部分SQL查詢出來的數(shù)據(jù)，減少日志內容，同時只保留固定天數(shù)日志，備份日志到其它磁盤空間
問題3：在同步數(shù)據(jù)過程中，出現(xiàn)同步數(shù)據(jù)失敗，后來發(fā)現(xiàn)是數(shù)據(jù)庫緩存表不足導致，數(shù)據(jù)庫關聯(lián)查詢數(shù)據(jù)或者排序時會使用到臨時表
解決方案：增加臨時表空間或者降低數(shù)據(jù)庫操作頻率，讓緩存表數(shù)據(jù)能夠有時間釋放
看過性能測試相關文章或者是開展過性能測試的小伙伴應該有體會， 性能測試不只是某一個人的事，也不只是測試部門的事，而是一個需要多角色人員參與和積極配合的性能團隊。如果只有測試工程師一個角色人員或者其它角色人員不積極配合，性能測試工作都無法順利推進。在本次性能測試過程中，參與進性能測試工作的角色包含了DBA、運維開發(fā)工程師、系統(tǒng)工程師、測試工程師、開發(fā)工程師、產品經理、需求人員。同時，測試工程師在性能測試過程中，不只是對測試對象進行性能測試，更充當了協(xié)調配合和推進性能測試的角色。在專業(yè)技能上，測試工程師需要對系統(tǒng)架構、功能邏輯、性能知識、數(shù)據(jù)庫、中間件等都有一定深度的認知，否則當性能問題出現(xiàn)時，無從下手，不僅無法定位或排查性能問題，也不知道如何讓其它角色人員配合工作。
性能測試是一門很深的學問，需要不斷積累，擁有扎實的基礎知識，應當多學多問多實踐。性能之路漫漫其修遠兮，謹以此篇文章共勉在性能路上走得更遠。
