性能測試藝術

來自： http://my.oschina.net/u/1433482/blog/634047

為什么要進行性能測試？

什么是好的與壞的性能？為什么性能測試在軟件開發生命周期(SDLC software development life cycle)中很重要？

性能不佳的應用通常無法實現企業預期利益，花費了大量時間和金錢，但是卻在用戶中失去了信譽。

相比功能測試和驗收測試(OAT operational acceptance testing)，性能測試容易被忽略，往往在發布之后碰到性能和擴展性問題才意識到重要性。

 

 

最終用戶眼中的性能

性能”是用戶最終的感受。性能優異的應用在最終用戶執行某項任務時不會產生過度的延遲而引起用戶的不滿。好的應用不會在登錄時顯示空屏，不會讓用戶走神。比如偶然的用戶在購物網站上尋找和購買他們所需要的東西時，客戶中心不會收到差性能的投訴。


多 數應用系統在峰值時性能表現不佳。從高層看，應用由客戶端軟件和基礎設施組成，后者包括了運行軟件所需的服務器硬件和網絡基礎設施。另外有些應用還有第3 方服務。任何一個組成部分中出現問題，整個系統的性能就將面臨災難。您可能會簡單地認為，為了保證應用性能，觀察應用每個部分在負載壓力下的運行狀況并且 解決所出現的問題即可。這種做法往往“太少”和“太遲”了，因此只能是治標不治本。

 

性能度量

 關鍵業績指標(KPIs key performance indicators)有服務和效率兩種。
 
基于服務的：衡量應用系統為用戶服務的好壞。

• 可用性(Availability): 終端用戶可以使用的應用的總時間。可用性很重要，小小的故障也會導致大量的商務上的花費。用戶無法有效地使用該應用系統，比如應用不響應或者響應慢到無法接受。)

• 響應時間(response time)：一般指系統響應時間。即用戶發起請求到收到結果的時間。響應有異步和同步兩種。

 

基于效率的：衡量應用對基礎設施的利用。

• 吞吐量(Throughput)：應用處理速度，比如一定時間內某個頁面的點擊數。

• 利用率(Utilization)：理論資源的使用率。當1000個用戶同時在線時，應用消耗了多少網絡帶寬及在服務器內存和cpu等使用情況。
  

 性能標準

沒有正式的行業標準，但是有許多非正式的標準，試圖對系統的性能好壞做出評價，尤其是B/S應用。比如“頁面最小刷新時間”從20秒到8秒，現在是2秒最佳。用戶和企業都希望系統能夠“即時響應”，但現在這樣的性能很難達到的。

(Martin et al.,1988)的研究表明：

• 超過15 秒：基本上不適合交互。某些特定的應用，一些用戶可能坐在終端等待超過15秒的時間去等待查詢結果的返回, 比如公安局的網上預約系統。然而繁忙的呼叫中心運營商或期貨交易商，超過15 秒無法容忍的。如果真的發系統就應該設計成可以讓用戶轉向其他的操作，后面異步響應。

• 超過4秒：對于要求用戶保存短暫記憶里的會話來說太長，當然交易完成之后，4-15秒的延遲是可以忍受的。

• 2-4 秒：超過2秒很難引起用戶的高度關注。買家在輸入了她的地址和信用卡號碼后等待2-4秒的時間可以接受。然而如果是在早先的階段，當她正在比較不同產品的差異時，卻又是不可容忍的。

• 低于2 秒: 用戶需要記住幾個響應信息時，響應時間必須很短，如果要記住更為詳細的信息，則要求就更高了。

• 亞秒: 思想密集型的工作來說（比如寫一本書），尤其是一個圖形應用程序，響應時間要非常短才能夠保持用戶的興趣和長時間的關注。當藝術家將圖片拖曳到另一個位置時，程序必須能夠立即響應。

• 馬上響應：按鍵并在屏幕上出現相應的字符，或者用鼠標點擊，這種響應必須幾乎是瞬時的。比如游戲。

• 由此可見，響應時間臨界點是2秒。

 

 

 糟糕的性能：為何如此普遍？ 
 
 

IT 商業價值曲線 

 
 性能問題通常會比較晚才發現，而且越晚發現，解決成本就越高。
 
 
 實線(計劃)表示預期結果。方塊表示部署。虛線(實際)表示實際結果，延遲上線，上線后因為性能問題產生負面效果。

 

性能測試成熟度

Forrester在 2006年對典型應用系統上線后發現的性能缺陷進行了調查：

圖中定義了三種性能測試。

 

• 第一種是救火(Firefighting)，發布前很少或從來沒有性能測試。所有性能缺陷在生產環境上發現解決。這是最不可取的，卻依然比較普遍。

• 第二種是性能驗證(performance validation)。公司為性能測試在產品的后期安排了時間，生產環境會發現30%左右的性能bug。這個當前絕大多數公司的做法。

• 第三種是性能驅動(performance driven),生命周期中的每一階段都考慮了性能, 生產環境會發現5%左右的性能bug。

 

系統設計階段缺少性能方面的考慮

設計的時候考慮性能有望產出好性能的應用，至少也能使應用在出現意想不到的性能問題時靈活地能進行修改或重新配置。設計相關的性能問題后期才發現就很難解決，有時候甚至需要重新開發。

多數的應用基于可獨立測試的組件進行開發的，組件在單獨執行的時候性能可能都不錯，切記必須從整體來考慮。這些組件之間的交互必須高效且擴展性好，集成后才會有好的性能。

直到最后一刻才進行性能測試

性能驗證模式下，性能測試直到系統發布前才會進行，并且很少考慮到性能測試所需的時間及失敗后所造成的后果。可能無法發現一些嚴重的性能缺陷或發現了性能問題但卻沒有時間解決。

擴展性

可能忽略了用戶的地理分布和規模等。需要考慮如下問題：

• 有多少終端用戶會實際使用？

• 用戶位于何處？

• 多少用戶會同時使用？

• 用戶如何連接到應用？

• 后期有多少額外的用戶需要訪問應用？

• 應用的服務器數量及網絡拓撲？

• 將應用對網絡容量產生什么影響？

了解流行度

很多公司低估其應用的人氣，人是好奇的，系統發布的第一天，你估計1萬次點擊，結果卻是100萬次點擊，您的應用系統就這樣崩潰了！需要考慮高峰訪問。

令人震驚的失敗：一個真實的例子

在很多年以前，英國政府決定在互聯網上公布1901年人口普查的結果。這涉及到大量的將舊文檔轉換成現代的數字格式文檔的工作，并且還需要創建一個應用以供公眾訪問。

很多希望了解家族歷史,24小時之后網站崩潰了。在之后的幾個星期里始終無法訪問，直到最后重新發布。

性能測試還不規范

目前性能調優的書籍很多，但是對醫生而言，最重要的是識別病情，識別性能瓶頸比解決問題有時更難。

不使用自動化的測試工具

不使用自動化的測試工具和自動化：單單使用手工是很難完成性能測試的。

 應用程序使用技術的影響

 應用程序使用技術的影響：某些新技術不太方便進行測試。

 

 

 

如何選擇性能測試工具？

web方面的測試工具比較多。但是非web的，尤其是涉及到加密和壓縮的，就很少了，甚至是https，很多工具都處理不好。

性能測試工具架構

 

常見的性能測試工具架構：

 

• 腳本：描述用戶的活動，支持不同協議。

• 測試管理模塊: 創建并執行性能測試會話或場景。

• 負載生成器: 生成負載。

• 分析模塊: 分析數據，有些還有自動分析的專家模式。

• 其他模塊: 監控服務器和網絡性能的同時，與其他軟件集成。

 

 

選擇性能測試工具

選擇性能測試工具：
除了HTTP/S支持比較廣泛，JavaScript, JSON和 Microsoft Silverlight就不一樣了。

• 協議支持

• 授權：比如最大虛擬用戶數；能支持的額外協議；附加插件集成和特定的技術棧監控，比如Oracle, Python等，)可以與APM(application performance monitoring)與CI(continuous integration)集成。

• 腳本支持：稍微復雜一點的測試就需要深入腳本。考慮腳本修改的難度；考慮測試團隊的技術水平，比如團隊如果有python高手，直接用python功能會比具體的工具要強大得多。

• 解決方案與負載測試工具: 有些廠商只提供個負載測試工具，而有些提供性能測試解決方案。解決方案產花費更多，但通常功能更強大，可能包括自動需求管理，自動數據創建和管理，預性能 測試的應用程序調試和優化，響應時間預測和容量建模，APM提供類和方法層面的分析，集成用戶體驗（EYE）監控，管理測試結果和測試資產等。

• 外包：可以免去工具選型等。但是次數太多的成本太高。

• 其他：基于云平臺的測試。節約硬件成本。缺點：次數太多的成本太高，性能指標監控未必方便。程序不穩定時代價很高。

 

性能測試工具集：概念驗證(POC Proof of Concept)

POC至少要有兩個用例：讀數據和寫數據。目的如下：

• 對性能測試工具是否適合目標應用進行技術評估。

• 識別腳本數據要求

• 評估腳本需要的編寫和修改時間

• 展示測試工具的容量。

 

 

POC檢查表

一般不建議超過2天。

• 準備：

• 成功或退出標準，客戶已經簽字。

• 工具的軟硬件準備ok。

• 安裝任何需要監控軟件的權限。

• 理想情況下保證環境專有性

• 應用技術支持：產品專家。

• 應用技術支持：技術專家(比如開發)可以咨詢或者應用中間件級別的架構宣講。

• 用戶帳戶：可以安裝訪問

• 至少兩套憑據登錄目標應用程序。因為需要并發執行等。

• 兩個用例，簡單的讀和復雜的寫。

• 過程

• 錄制用例并比較異同，注意運行時和會話數據等。

• 修改腳本，確認用戶和多用戶模式都可以執行，結果正確。確保腳本無內存泄露等不良行為。

• 交付： 

• 通過或者不通過

• 生成了數據需求。

• 腳本開發時間

• 如果是售前，要能說服客戶

 

有效應用性能測試的基礎

需要考慮的問題：

• 發布時要支持多少用戶？6個月，12個月，2年后呢？

• 用戶分布及如何將它們連接到應用？

• 發布時用戶的并發？ 6個月后，12個月，2年后呢？

   

回答會引出一些問題, 比如：

• 每個應用層需要的服務器規格及數量是什么？

• 服務器的位置？

• 網絡基礎設施的類型？

回答不出來沒有關系，但是你已經開始考慮容量和擴展性了。從廣義上講，功能需求定義系統是應該做什么，非功能需求定義系統是什么樣子(來自維基百科)。在軟件測試中，性能測試基于基準衡量系統對性能和容量質量，包括以下內容：

• 項目計劃

• 應用夠穩定

• 足夠的時間

• 代碼凍結

• 基本的非功能需求

• 設計合適的性能測試環境

• 設置現實合適的性能目標

• 確定并腳本化的關鍵use case

•  測試數據

• 負荷模型

• 精確的性能測試設計

• KPI(Key Performance Indicator)

應用準備OK

功能要運行穩定，不能10次運行，2次失敗。避免性能測試成為頻繁的bug修改實踐。功能等問題會掩蓋性能問題。要有嚴格的單元和功能測試保證。衡量標準如下：

• 大量數據(High data presentation)：比如大量圖片和冗余會話。

• 低效SQL(Poorly performing SQL): 比如下圖：

• 大量應用的網絡來回：容易導致延遲、帶寬限制和網絡擁塞等。

• 應用錯誤：比如HTTP 404，500等。

 

足夠的時間

以下工作需要時間：

• 準備測試環境

• 配置負載注射器

• 識別user case(數天到數周)和腳本化

• 確定和創建測試數據(數天到數周)

• 測試環境安裝配置

• 問題解決

代碼凍結

    不凍結可能會導致腳本失效或不能代表用戶行為等。

設計性能測試環境

理論上要與生產環境完全一致，但是很多原因導致不太可能，下面列出部分原因：

• 服務器的數量和規格: 服務器內容和架構難以復制，盡量保持規格一致，以方便提供基準。

• 帶寬和網絡基礎設施：地理位置難以復制。

• 部署層次：建議完全一致。

• 數據庫大小：建議完全一致。

    也有公司直接在生產環境同時部署測試環境或者直接拿生產環境做性能測試，后者注意不要影響用戶，包含數據和服務等。

    性能測試的環境類型有：

• 生產環境非常接近的副本：通常不太現實。

• 生產環境的子集，層次一致，服務器規格一致，但是數量有所減少：建議達到的方案。

• 生產環境的子集，層次有縮減，服務器規格一致，但是數量有所減少：最常見的方案。

 

虛擬化

虛擬化的概念請參考：https://en.wikipedia.org/wiki/Virtualization 和 https://en.wikipedia.org/wiki/Docker_(software) 等。 注意：

• 虛擬機管理程序層有管理開銷

• 總線和網絡的通信方式不同。前者沒有帶寬和延遲限制。在網絡跨地理位置的情況尤其需要注意。建議虛擬化與生產環境一致。特別注意不要跨層虛擬化在同一機器。

• 物理與虛擬NIC：后者的開銷更大。

云計算

可以簡單理解云計算為商品化的虛擬主機，它便宜，容易部署。相關概念介紹參見：https://en.wikipedia.org/wiki/Cloud_computing 。

優點：

• 可以生成大量負載注射器。

• 便宜

• 快速

• 可擴展

• 易部署

缺點

•     不及時關閉很貴

• 有時不可靠，比如配置的機器無法啟動，IP被墻等。

負載注入容量

單機能模擬的虛擬用戶是有限的，特別注意測試機的CPU和內存等使用率不要過載，盡量使用多的機器機進行測試。注意以下幾點：

• 負載均衡：一些基于IP分配服務器。所以必要的時候需要使用IP欺騙。

• 用戶會話限制：比如一個IP只能一個會話。

 

其他問題：

• 有些中間件不能用腳本表示。解決辦法，從表示層入手；改用瘦客戶端；自行開發工具。

• 衡量表示層性能：性能測試通常工作在中間件層。比如想計算用戶點擊復選框的時間，建議使用前端測試工具。

 

網絡部署模式

廣域網的速度通常只有256 Kb左右，網絡延遲也比較大。延遲的產生基于光速：1ms/130公里以及交換機、路由器等網絡設備和服務器的時延。

如果有必要，可以：1，從WAN進行性能測試；2，測試工具模擬；3，網絡模擬。

 

環境檢查表

• 服務器數：物理或虛擬服務器的數量。

• 負載均衡策略：負載均衡機制的類型。

• 硬件清單：CPU的類型和數目，內存，網卡的類型和數量。

• 軟件清單：標準版本的軟件清單(不包括中間件)。

• 中間件清單。

• 內部和外部鏈接

軟件安裝約束

比如安全考慮。

 

務實的性能目標

目標部分來自服務級別協議(SLA service-level agreement)。無論如何目標必須明確。

一致

一致且盡早介入。

 

業務

C級管理負責預算和策略決定：
?首席信息官（CIO Chief information officer）
?首席技術官（CTO Chief technology officer）
?首席財務官（CFO Chief financial officer (CFO)）
?部門負責人

IT

?開發人員
?測試
?架構團隊
?服務提供者（內部和外部）
?終端用戶

?IT或運維

性能目標定義

主要包含可用性、響應時間、吞吐量、并發、網絡利用率和服務器利用率。

在性能測試中并發是同時在線的用戶。要注意并發虛擬用戶和并發實際用戶不一定是同一回事。估算時需要基于二八原理和峰值等。

吞吐量通常更適合衡量無狀態的行為。比如瀏覽購物時通常不會登錄，看中之后才會登錄，瀏覽購物可以認為是無狀態的。

響應時間不要隨著并發的增加而大幅度增加，可以基于單個用戶做基準測試。

網絡利用率需要關注數據量、數據吞吐量(可能會導致吞吐量突然下降是容量問題)和數據錯誤率。

服務器利用率主要關注CPU、內存和I/O(磁盤和網絡等)

確定和腳本化關鍵業務user case

關鍵的user case一般不會超過10個。

Use-Case檢查表

• 記錄每個步驟

• 輸入數據和期望的響應

• 用戶類型：新的或老用戶，超級用戶，客戶，客服等類型。

• 網絡：LAN或WAN

• 主動還是被動

腳本驗證

基于抓包工具或錄制工具書寫腳本，然后單用戶到多用戶調通。注意腳本不要影響到并發的執行，盡量使用不同的用戶等。

檢查點

業務較復雜時尤其重要。

是否需要登入登出

盡量符合實際情況。

共存

注意共存的應用和網絡共享

 

測試數據

輸入數據

• 用戶憑據：比如用戶名和密碼。

• 查找規則：通過客戶的姓名和詳細地址，發票號和產品碼甚至是通配符進行查詢。

• 相關文件：比如圖片。

 

目標數據

需要考慮數據容量是否符合規格的大小，數據回滾等。

會話數據

比如token。

數據安全

數據要保密，同時性能測試工具要實現與服務器端通信的加密方式。

 

性能測試設計

性能測試的類型

1.pipe-clean測試。
2.容量測試。盡量接近用戶實際使用。
3.隔離測試。
4.壓力測試。退出標準：沒有更多的用戶可以登錄，響應時間難以接受，或應用程序變得不可用。

5.浸泡測試，又叫穩定測試。發現內存泄漏等問題。

6.冒煙測試，只測試修改的部分。注意和其他地方的概念不一樣。

 

pipe-clean, volume, stress和soak test通常都需要進行。

 

負載模型

負載模型定義了user case的負載分布及并發和吞吐量的目標。通常先基于容量測試，再擴展到其他類型。注意測試數據、思考時間和步長的影響。比如搜索數據分類：

• 小數據模型：具體的產品名稱或ID。

• 中數據模型：局部產品名稱。

• 大數據模型: 通配符或最小的產品名稱的內容。

 

需要模擬真實情況下各種user case的分布:

 

吞吐量模型對于已有一個用需要參考Google Analytics或WebTrends，新應用的需要估計。

思考時間代表著延遲和暫停。
步長是循環之間的間隔。

負載注入方式有：Big Bang、Ramp-up、Ramp-up (with step)、Ramp up (with step), ramp down (with step)、Delayed start。注意"with step"主要是為了方便觀察。

KPI

服務器KPI

Windows 性能工具。Linux有monitor、top,、vmstat、sar等工具。監控分為業務層、中間件層和系統層等。

通用模板如下：

? Total processor utilization %
? Processor queue length
? Context switches/second
? Available memory in bytes
? Memory pages faults/second
? Memory cache faults/second
? Memory page reads/second
? Page file usage %
? Top 10 processes in terms of the previous counters
? Free disk space %

? Physical disk: average disk queue length
? Physical disk: % disk time
? Network interface: Packets Received errors
? Network interface: Packets Outbound errors

Web和應用服務器層：比如nginx、WebLogic、WebSphere、Apache、JBOSS等。
數據庫層：比如MYSQL、Oracle等。MongoDB, Cassandra和DynamoDB可以視為應用設計的一部分。
大型主機層：比如Strobe、Candle
主機層：比如亞馬遜的CloudWatch。
網絡層：網絡錯誤、延遲、帶寬。

應用監控

性能測試過程

性能測試的方法

• 范圍和非功能需求捕捉：通常需要幾天。

• 性能測試環境準備

• user case腳本化：一個user case通常需要半天。

• 創建和驗證性能測試場景。1-2天。前提是創建了精確的負載模型，定義每個性能測試的結構和內容。

• 執行性能測試。通常需要5天左右。如果頻繁重測，耗時更多。

• 收集數據和卸載軟件。通常需要1天左右。

• 最后分析和報告。通常需要2-3天左右。

 

非功能需求分析

先決條件如下：

• 性能測試的截止期限

• 內部或外部資源OK。

• 測試環境的設計。盡量接近真實環境。

• 代碼凍結。

• 專有的測試環境，

• 目標。

• 關鍵用例。識別、記錄并準備腳本。

• 用例中的檢查點。

• 選擇的use case的輸入、目標和會話數據。同時還需要考慮數據安全。

• 負載模型OK。

• 性能測試場景的數量、類型、use-case內容和虛擬用戶的部署已經確定。還可能需要考慮時間，步長，注入細節等。

• 識別和記錄應用、服務器和網絡的KPI。注意需要關注基礎設施。

• 性能測試的輸出。

• bug提交方式。涉及測試團隊成員和報告結構。工具、資源、技術和授權。另外還有培訓，在外包的時候尤其重要。常見的架構如下：

 

基于上述信息，可以輸出：
1.制定包括資源，時間線和里程碑的高層計劃
2.包括所有的依賴、相關時間線、詳細的場景和use case，負荷模型和環境信息的性能測試計劃。
3.風險評估。

另外還需要注意迭代。

性能測試環境準備

步驟如下：

1.足夠的時間來采購設備，配置和構建環境。
2.考所有部署模型要在LAN和WAN環境實驗。
3.考慮外部鏈接。
4.提供足夠的負荷注入容量。比如云主機。
5.確保應用正確部署到測試環境。
6.軟件授權。
7.部署和配置性能測試工具。
8.部署和配置KPI監控。

 

Use-Case腳本

針對每個user case：

?確定會話數據的要求。其中一些可能來自概念驗證(POC)。
?確認并應用輸入數據的要求。
?檢查點。
?修改腳本
?腳本單用戶和多用戶都可以執行。

 

性能測試場景構建

? 測試類型是什么(pipe-clean, volume, soak, or stress？)，通常是針對user case進行單個用戶(pipe-clean)測試，產生基線數據。然后加大并發和吞吐量。之后進行混合user case的容量測試。然后可能有soak和stress測試，最后還可能結合負載均衡和容災等測試。
?思考時間和步長(尤其是壓力測試)。
?負載注射器和虛擬用戶的數量。
?注入方式：Big Bang, ramp-up, ramp-up/ramp-down with step, or delayed start。注意這幾種方式可能是連接的。比如下圖：

?測試執行控制：執行一段時間段、到達一定界限或測試數據耗盡停止或是用戶介入。
?是否需要IP欺騙?
?您是否需要模擬不同的波特率？
?監控需求。
?Web的性能測試需要考慮瀏覽器緩存。還需要考慮新用戶，活躍用戶，回歸用戶等。
?技術影響，比如SAP比較消耗資源。

 

性能測試執行

1.pipe-clean測試。
2.容量測試。
3.隔離測試
4.壓力測試。
5.浸泡測試，發現內存泄漏等問題
6.其他測試，比如負載均衡，容災等。

性能測試分析和報告

?進行最后的數據收集(可能有軟件卸載)。數據要有備份。
?比較試驗結果與目標，決定是否通過。
?測試報告。

性能測試分析

相關術語

平均值和中值

標準偏差和正態分布: 高標準偏差表示用戶體驗不好。

百分比

響應時間分布

吞吐量不能增加，一般有瓶頸存在：

遠 程監控：Windows注冊表、Web-Based Enterprise Management (WBEM)、Simple Network Monitoring Protocol (SNMP)、Java Monitoring Interface (JMX)、Rstatd（傳統的基于RPC的監控工具）

 

客戶端需要關注：CPU百分比、內存使用、頁利用率、磁盤時間、磁盤空間。

查找原因

好的擴展性與響應時間：

差的擴展性與響應時間：

 

特別注意值的突然跳躍，一般是有瓶頸存在。另外服務器的基線數據也可供參考。

檢查表

性能測試與移動端

移動端的類型

• 移動網站

• 移動應用

• 混合移動應用

• m. site: 很少用，IOS中用來避免Apple App Store，像移動應用，但是實質是移動網站。

 

設計考慮

耗電量：

    運行一定時間，觀察耗電量；

    與其他應用同時使用，觀察耗電量排行。

網絡：

異步：

 

測試考慮

兼容性：系統、瀏覽器等組合。

API測試。

移動測試設計

• 移動網站：考慮瀏覽器。可以參考Google Analytics。

• 移動應用：考慮API。

  

• 混合移動應用

• m. site: 很少用，IOS中用來避免Apple App Store，像移動應用，但是實質是移動網站。

 

終端用戶體驗監控與性能

主動監控

 

測試需要考慮：

參考網絡圖如下：

主動監控主要關注：可用性和響應時間。