靚湯：性能測試策略實戰解析

2017年3月7日周二晚8點30分，具有十余年自動化性能測試以及六年測試管理及測試過程優化的經驗的產品測試架構師靚湯帶來了主題為“圖解性能測試之二：如何做性能測試”的交流。以下是主持人赫陽整理的實錄，記錄下了本場Chat的精彩片段。

問：訂單交易類的如何做全鏈路壓測？

答：這是一個大問題，有很多要聊的。首先解釋一下全鏈路壓測：全鏈路壓力測試是2013年阿里提出來的。之前壓力測試主要是：線下模擬單一集群測試；牛叉一點的團隊會線上引流壓測。但傳統的壓力測試暴露出的基本上是一些單點問題，最主要是測試情況與真實情況有偏差。

全鏈路壓測特點：在生產環境壓力，驗證全流程，模擬用戶交易全流程或模擬某產品大促或某個平臺大促等，需要的大量技術支持和架構支持。

全鏈路壓力測試一般是一些大公司在玩，最成熟的應該是阿里：主要特點是線上壓測、影子數據庫、全面容器化、全面監控、性能測試平臺化、大量微服務化，所以一般的公司沒有難做起來。那么對于小公司開展全鏈路壓力測試，是比較困難的。

對于用能力有資源的團隊來講那么可以做些什么呢？

全面監控

性能測試平臺化

推動公司開展微服務，進行服務治理

以上是前期可以開展的工作，特別是微服務，對于服務治理有很大幫助。以前接口調用情況是黑盒，現在可以變成白盒。

服務治理方面，可以建立統一平臺、統一監控、統一調度，統一集成等。

中期可以做全面容器化，這主要是為了應對壓力而要做的事情，微服務和全面容器化給灰度發布帶來了機會，影子數據庫則是實現線上壓測的必經之路。

不同階段可以用不同的方法實現。主要看公司的技術儲備等。其實看有沒有資源。

對于沒有能力和資源的小團隊：確定壓力測試的目的最重要。我們做全流程的壓力測試就是保證流程中沒有瓶頸。我建議把事情簡化，能才就拆，整個鏈路一定是有瓶頸的，找到瓶頸，找到最需要測試的地方是現在需要做的。

我們的目標是避免瓶頸。我們就分析哪些需要做壓力測試，文章中描述需求和調研中有很多方法確認關鍵業務和關鍵場景。

找的瓶頸后就各個突破。

如果是多系統，建議先分段進行各系統的壓力測試【此時可以有擋板】。

在整合所有資源做一次拉通的壓力測試，如果系統多，就涉及協調溝通等問題。

以上是我的思路。

問：很多時候團隊中沒有如此優秀的人才負責性能測試，很多時候從設計時都沒花心思考慮性能問題，這種怎么在實際工作中推進？

答：這是一個好問題很多團隊是不重視性能測試的，分到的資源就特別少。性能測試是測試的一個分支，所有很多方法可以通用。

總結起來主要策略是：讓干系人緊張、讓流程順暢、讓設計可驗收、讓風險提前發現。

在需求評審時，引入非功能需求評審，問用戶問業務要，用戶量、要業務量。不行就自己參加調研，如果用戶說不用考慮，就需要你去說服用戶了，要么就做不了了。

在設計時團隊使用驗收測試驅動開發的辦法，外部要求研發的設計需要測試驗證。測試內部要求測試人員增加性能測試驗收標準。

研發時，先測試前置，驗收測試驅動開發，然后可以試試測試驅動開發，在測試里就設計高并發的壓力測試，迫使研發人員對于高并發下的同步鎖、響應時間等做錯整改和設計。

在上線后，提出當前性能風險分析，如果做了微服務的就能看到服務的調用情況等。可以把用戶的調用情況作為下個版本的輸入，給到研發人員，產品架構師等。

另外要通知到你的運營和銷售人員，有大促和活動時，通知到測試進行一些專項性能測試。

其實測試人員要明白，最關心系統性能的不是測試人員，應該是產品負責人；我們為何看到產品負責人一點不緊張，其實是因為他不了解。測試人員就要讓相應人員了解情況，并督促驗證相應問題。

問：同時在線用戶數還是不太了解是要測什么？

答：用戶數業務量是影響系統的主要因素，因此我們要細分用戶。同時在線用戶數主要用戶組合場景的情況，比如12306有的用戶在查詢，有的用戶在登錄，有的用戶在支付。我們掌握同時在線用戶數主要是用來分為真實業務系統中，我們如何來進行虛擬用戶的分配。主要考察固定時間段內用戶的占比等。

另外對于同時在線用戶數可以結合實際業務進行分析，看看有多少用戶存在業務場景轉換。比如一個大數據平臺，A類用戶可能一直關注商業人群的分析，但突然有一天這類用戶可能突然轉到分析商圈商業。有些業務之間存在引流的情況。這也是壓力測試是設計人員需要考慮的。引流的用戶比例大概是多少。

另外需要結合僵尸用戶進行分析，看看有多少用戶是短周期的僵尸用戶。這些僵尸用戶是在什么時候出現。比如以下場景：我們分析用戶時拿了去年的雙11的歷史數據。而我們性能測試目的是系統能在一般大促中承受壓力。那么大家可以在去年雙11的用戶中移除，全年就雙十一有需求的用戶。以此來保證系統不浪費資源又能承受壓力。

用戶不做操作，也要保證你數據庫的連接數能滿足用戶的臨時性請求。

問：2016年除夕夜支付寶收集福卡搶紅包，對于這種即時性業務，支付寶測試團隊如何去調研用戶量，怎樣最大限度去保證調研的用戶量和當天實際的用戶量相近，如果出現調研的用戶量遠遠大于實際用戶量，這樣是不是浪費公司資源？

答：這個問題有提到兩塊，一是用戶量，二是資源如何更合理。

首先我不知道他們怎么做的用戶調研，但如果是我，我可能這樣做：

第一，這樣理解吧，除夕夜通常都是以最大業務量進行計算的，相信雙十一也沒有這樣的高峰期。 對于支付寶系統，本身有他的優勢：1）有歷史數據可以參考；2）有用戶增長比率可以參考。

當然最牛的就是用戶預測。我們現在公司就在進行業務量的預測，當然這用了大數據建模。這個可能就需要專業人才了。我們現在的產品銷量預測就能做到98%的準確。當然是指特定業務。如果對于普通公司第一次遇到大促的時候，有沒有競品和歷史數據可以參考的時候，通常可以認為你的80%用戶會參加活動。置于那個功能會有最大用戶數和高峰用戶數是多少，文中有詳細介紹。

第二，對于我來講保證業務的穩定性，此時高于用戶的體驗，架構上優化。另外我認為他們的紅包永遠不會出錢系統崩盤的情況。原因在于在真正服務器產生壓力前，所有的壓力都在隊列里。發紅包不同于秒殺，秒殺可能在前端就當掉了很多請求，然后在把請求放在隊列，最后才會對服務器造成真正的壓力。其實業內的同學都知道，很多公司的秒殺都是假的，很多用戶都被提前擋在了外面，這也是提高體驗的方法之一。

第三，使用云、微服務、使用容器保證，資源的收縮。好處在于實時可以看到資源的情況。有的公司也在產品包的目錄下放置了監控包。用于全面的性能監控。根據監控情況實時調整資源。

調整的方法可以給大家說一下：使用動態服務注冊，和動態服務通知的方法實現。當發現服務需要擴容的情況時。增加服務的容器，通知服務注冊，然后消費方收到服務通知后就知道去訪問相應的服務器，而減輕之前服務器的壓力。

問：在性能測試時，模擬用戶需要追求越真實越好嗎？如果需要，有哪些模擬的方法，包括分析方法。如果不需要，如何來選擇性能測試時的用戶行為呢？性能測試一般需要持續多長時間？性能測試和穩定性測試還有壓力測試的區別和聯系？

答：第一個問題：當然越真實越好。分析主要兩個方向，第一個是真實業務操作。主要看那些業務操作會對系統帶來壓力。

比如查詢和查詢條件的組合。另外就是要考慮用戶群體，如果是不懂電腦的群體，如果出現卡頓，可能他會一直點下去。那么這就需要考慮是否前端就把這種無用請求給擋回去。用戶有哪些關鍵行為，需要關聯，我們性能需求分析中的關鍵業務分析。通過關鍵業務找到關鍵用戶場景，去分析用戶行為，準備相應數據和測試場景，測試步驟等。另外壓力測試時間，一般業務15-30分鐘就可以了。穩定性測試需要27小時以上，但如果已經性能問題了，可以隨時中斷。壓力測試是穩定性測試的基礎。壓力都有問題就不要進行穩定性了。當然不是所有的壓力測試都要做穩定性測試。原因要跟著性能測試目的來。以目的為出發點。

問：性能測試自動化怎么做？

答：有的同學可能覺得這是一個不怎么樣的問題。但這是一個好問題，特別是使用不同工具進行性能測試的人來講。所有需要一個平臺，或一個串聯的程序。這個時候一下CI程序就有用處了。我們可以使用粘盒機的python語言。也可以使用jenkins這樣的工具，把不同的性能測試工具連起來。如果單一場景可能使用lr/jmeter/soapui等性能測試工具就可以實現自動化。自動化需要根據業務情況來看。

我之前在華為做一系統的測試時調度，就用的windows系統的定時任務來跑的。soapui是一個接口自動化、性能、安全測試的一個工具。所有根據實際情況來做。有資源就做平臺。所有代碼、調度、監控都讓平臺幫忙做。沒有資源就用工具，工具多了就組合。

問：性能測試結束的準則是怎樣的？系統性能不穩定了就可終止測試還是系統崩潰？一般系統的資源運行到極限的狀態的參考值是多少呢？

答：工具之間可以氈合在一起跑。比如我調完lr在調SoapUI、在調自己寫的代碼。準則在測試策略里體現、具體結果以評審通過的性能指標為準則。具體指標在文章中有提到。壓力測試壓出問題就可以停下來了。因為優化后又要重新測試？一般系統的資源運行到極限的狀態的參考值是多少呢？這篇文章里也有具體的數字，可以看看文章。

答：這有是要聊很久的話題。由于時間關系我題一下關鍵字，大家看看那些要展開我們就展開。首先我認為系統性能是設計出來的。如果真要談到測試，那么就在研發設計的時候干預。通常我們性能設計會做這些事，大家看看自己項目可以選取什么。

一、動靜分離

靜態資源拿出來講一下。所有靜態資源放一個服務器。記得前面加一個網管。不然所有請求還是會通過動態服務器。

二、讀寫分離

第二個主要是對數據庫的請求，進行讀寫分離。這些優化第4場細聊。

三、分工明確

是指代碼的職責劃分嗎？是的，簡單例子對于給別人掉的接口放到一個包，對于自己調別人的接口放另外一個包。

也可以根據業務功能來分，目前最好的架構狀態就是微服務。

四、熱數據無論大小都進緩存

五、慢SQL分析、索引

六、業務數據轉歷史

一般快到業務高峰期的時候可以對不參與業務高峰的數據進行轉歷史操作，減少表的數據量。當然有的公司進行了分表、分庫出來，就更好操作了。當然業務高峰前還可以把系統里的慢SQL查詢出來，進行SQL優化。慢SQL需要進行一些配置，所有要提前進行。慢SQL的具體如何優化，我們第4場CHAT會具體分析。

七、分區、分表、分庫

目的通常就是減少基礎數據量來的。后面我會找到相應的PPT補充這次回答的。大家可以在關注后面整理的文檔，一下沒有找到。一般按業務場景分、按hash值分。或者引入外部的中間件來分如mycat

問：進行性能測試的環境和數據，會對測試結果有影響，導致測試結論數據不準確，如何避免？

答：

一定要在每個事物進行數據斷言。

使用生產數據（不脫敏最好、非要脫敏就越少越好）。

測試人員對業務場景和研發代碼要深挖。

準備數據的存儲過程、方法、策略要通過“干系人”評審。

本文轉載自異步社區。

云性能測試服務 CPTS 壓力測試

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。