任職百度八年“測試工程師”，親自闡述軟體效能測試的藝術

為什麼要進行效能測試？

什麼是好的與壞的效能？為什麼效能測試在軟體開發生命週期(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）監控，管理測試結果和測試資產等。

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

●其他：基於雲平臺的測試。節約硬體成本。缺點：次數太多的成本太高，效能指標監控未必方便。程式不穩定時代價很高。

備註：Loadrunner之類的效能測試工具，中文化和文件都做得不錯，對於通用的http協議效果也可以。但是擴充套件性差、效率低下、價格極其昂貴。所以一般認為一談效能就談Loadrunner的人沒有真正入門效能測試。功能測試的QTP也和Loadrunner類似。

　效能測試工具集：概念驗證(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(數天到數週)和指令碼化

●確定和建立測試資料(數天到數週)

●測試環境安裝配置

●問題解決

　程式碼凍結

不凍結可能會導致指令碼失效或不能代表使用者行為等。

設計效能測試環境

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

●伺服器的數量和規格: 伺服器內容和架構難以複製，儘量保持規格一致，以方便提供基準。

●頻寬和網路基礎設施：地理位置難以複製。

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

●資料庫大小：建議完全一致。

也有公司直接在生產環境同時部署測試環境或者直接拿生產環境做效能測試，後者注意不要影響使用者，包含資料和服務等。

效能測試的環境型別有：

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

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

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

　虛擬化

●虛擬機器管理程式層有管理開銷

●匯流排和網路的通訊方式不同。前者沒有頻寬和延遲限制。在網路跨地理位置的情況尤其需要注意。建議虛擬化與生產環境一致。特別注意不要跨層虛擬化在同一機器。

●物理與虛擬NIC：後者的開銷更大。

雲端計算

可以簡單理解雲端計算為商品化的虛擬主機，它便宜，容易部署。

優點：

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

●便宜

●快速

●可擴充套件

●易部署

　缺點

●不及時關閉很貴

●有時不可靠，比如配置的機器無法啟動，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提交方式。涉及測試團隊成員和報告結構。工具、資源、技術和授權。另外還有培訓，在外包的時候尤其重要。常見的架構如下：

在這裡給大家提供一個學習交流的平臺，測試工程師群：672899761

1. 具有1-5工作經驗的，面對目前流行的技術不知從何下手，需要突破技術瓶頸的可以加群。
   

2. 在公司待久了，過得很安逸，但跳槽時面試碰壁。需要在短時間內進修、跳槽拿高薪的可以加群。
   

3. 如果沒有工作經驗，但基礎非常紮實，對功能測試，效能測試，Java，Python掌握熟練的可以加群。

基於上述資訊，可以輸出：

1.制定包括資源，時間線和里程碑的高層計劃

2.包括所有的依賴、相關時間線、詳細的場景和use case，負荷模型和環境資訊的效能測試計劃。

3.風險評估。

另外還需要注意迭代。