為什么要進(jìn)行性能測(cè)試？
什么是好的與壞的性能？為什么性能測(cè)試在軟件開(kāi)發(fā)生命周期(SDLC software development life cycle)中很重要？
性能不佳的應(yīng)用通常無(wú)法實(shí)現(xiàn)企業(yè)預(yù)期利益，花費(fèi)了大量時(shí)間和金錢，但是卻在用戶中失去了信譽(yù)。
相比功能測(cè)試和驗(yàn)收測(cè)試(OAT operational acceptance testing)，性能測(cè)試容易被忽略，往往在發(fā)布之后碰到性能和擴(kuò)展性問(wèn)題才意識(shí)到重要性。
最終用戶眼中的性能
性能”是用戶最終的感受。性能優(yōu)異的應(yīng)用在最終用戶執(zhí)行某項(xiàng)任務(wù)時(shí)不會(huì)產(chǎn)生過(guò)度的延遲而引起用戶的不滿。好的應(yīng)用不會(huì)在登錄時(shí)顯示空屏，不會(huì)讓用戶走神。比如偶然的用戶在購(gòu)物網(wǎng)站上尋找和購(gòu)買他們所需要的東西時(shí)，客戶中心不會(huì)收到差性能的投訴。
多 數(shù)應(yīng)用系統(tǒng)在峰值時(shí)性能表現(xiàn)不佳。從高層看，應(yīng)用由客戶端軟件和基礎(chǔ)設(shè)施組成，后者包括了運(yùn)行軟件所需的服務(wù)器硬件和網(wǎng)絡(luò)基礎(chǔ)設(shè)施。另外有些應(yīng)用還有第3 方服務(wù)。任何一個(gè)組成部分中出現(xiàn)問(wèn)題，整個(gè)系統(tǒng)的性能就將面臨災(zāi)難。您可能會(huì)簡(jiǎn)單地認(rèn)為，為了保證應(yīng)用性能，觀察應(yīng)用每個(gè)部分在負(fù)載壓力下的運(yùn)行狀況并且 解決所出現(xiàn)的問(wèn)題即可。這種做法往往“太少”和“太遲”了，因此只能是治標(biāo)不治本。
性能度量
關(guān)鍵業(yè)績(jī)指標(biāo)(KPIs key performance indicators)有服務(wù)和效率兩種。
基于服務(wù)的：衡量應(yīng)用系統(tǒng)為用戶服務(wù)的好壞。
可用性(Availability): 終端用戶可以使用的應(yīng)用的總時(shí)間?？捎眯院苤匾⌒〉墓收弦矔?huì)導(dǎo)致大量的商務(wù)上的花費(fèi)。用戶無(wú)法有效地使用該應(yīng)用系統(tǒng)，比如應(yīng)用不響應(yīng)或者響應(yīng)慢到無(wú)法接受。)
響應(yīng)時(shí)間(response time)：一般指系統(tǒng)響應(yīng)時(shí)間。即用戶發(fā)起請(qǐng)求到收到結(jié)果的時(shí)間。響應(yīng)有異步和同步兩種。
基于效率的：衡量應(yīng)用對(duì)基礎(chǔ)設(shè)施的利用。
吞吐量(Throughput)：應(yīng)用處理速度，比如一定時(shí)間內(nèi)某個(gè)頁(yè)面的點(diǎn)擊數(shù)。
利用率(Utilization)：理論資源的使用率。當(dāng)1000個(gè)用戶同時(shí)在線時(shí)，應(yīng)用消耗了多少網(wǎng)絡(luò)帶寬及在服務(wù)器內(nèi)存和cpu等使用情況。
性能標(biāo)準(zhǔn)
沒(méi)有正式的行業(yè)標(biāo)準(zhǔn)，但是有許多非正式的標(biāo)準(zhǔn)，試圖對(duì)系統(tǒng)的性能好壞做出評(píng)價(jià)，尤其是B/S應(yīng)用。比如“頁(yè)面最小刷新時(shí)間”從20秒到8秒，現(xiàn)在是2秒最佳。用戶和企業(yè)都希望系統(tǒng)能夠“即時(shí)響應(yīng)”，但現(xiàn)在這樣的性能很難達(dá)到的。
(Martin et al.,1988)的研究表明：
超過(guò)15 秒：基本上不適合交互。某些特定的應(yīng)用，一些用戶可能坐在終端等待超過(guò)15秒的時(shí)間去等待查詢結(jié)果的返回, 比如公安局的網(wǎng)上預(yù)約系統(tǒng)。然而繁忙的呼叫中心運(yùn)營(yíng)商或期貨交易商，超過(guò)15 秒無(wú)法容忍的。如果真的發(fā)系統(tǒng)就應(yīng)該設(shè)計(jì)成可以讓用戶轉(zhuǎn)向其他的操作，后面異步響應(yīng)。
超過(guò)4秒：對(duì)于要求用戶保存短暫記憶里的會(huì)話來(lái)說(shuō)太長(zhǎng)，當(dāng)然交易完成之后，4-15秒的延遲是可以忍受的。
2-4 秒：超過(guò)2秒很難引起用戶的高度關(guān)注。買家在輸入了她的地址和信用卡號(hào)碼后等待2-4秒的時(shí)間可以接受。然而如果是在早先的階段，當(dāng)她正在比較不同產(chǎn)品的差異時(shí)，卻又是不可容忍的。
低于2 秒: 用戶需要記住幾個(gè)響應(yīng)信息時(shí)，響應(yīng)時(shí)間必須很短，如果要記住更為詳細(xì)的信息，則要求就更高了。
亞秒: 思想密集型的工作來(lái)說(shuō)（比如寫(xiě)一本書(shū)），尤其是一個(gè)圖形應(yīng)用程序，響應(yīng)時(shí)間要非常短才能夠保持用戶的興趣和長(zhǎng)時(shí)間的關(guān)注。當(dāng)藝術(shù)家將圖片拖曳到另一個(gè)位置時(shí)，程序必須能夠立即響應(yīng)。
馬上響應(yīng)：按鍵并在屏幕上出現(xiàn)相應(yīng)的字符，或者用鼠標(biāo)點(diǎn)擊，這種響應(yīng)必須幾乎是瞬時(shí)的。比如游戲。
由此可見(jiàn)，響應(yīng)時(shí)間臨界點(diǎn)是2秒。
參考資料
- 緊張整理更新中，討論 釘釘免費(fèi)群21745728 qq群144081101 567351477
- 本文涉及的python測(cè)試開(kāi)發(fā)庫(kù) 謝謝點(diǎn)贊！
- 本文相關(guān)書(shū)籍下載
- 更多python性能測(cè)試工具參考
- 2018最佳12個(gè)開(kāi)源或免費(fèi)web服務(wù)器和客戶端性能測(cè)試工具
糟糕的性能：為何如此普遍？
IT 商業(yè)價(jià)值曲線
性能問(wèn)題通常會(huì)比較晚才發(fā)現(xiàn)，而且越晚發(fā)現(xiàn)，解決成本就越高。
實(shí)線(計(jì)劃)表示預(yù)期結(jié)果。方塊表示部署。虛線(實(shí)際)表示實(shí)際結(jié)果，延遲上線，上線后因?yàn)樾阅軉?wèn)題產(chǎn)生負(fù)面效果。
性能測(cè)試成熟度
Forrester在 2006年對(duì)典型應(yīng)用系統(tǒng)上線后發(fā)現(xiàn)的性能缺陷進(jìn)行了調(diào)查：
圖中定義了三種性能測(cè)試。
第一種是救火(Firefighting)，發(fā)布前很少或從來(lái)沒(méi)有性能測(cè)試。所有性能缺陷在生產(chǎn)環(huán)境上發(fā)現(xiàn)解決。這是最不可取的，卻依然比較普遍。
第二種是性能驗(yàn)證(performance validation)。公司為性能測(cè)試在產(chǎn)品的后期安排了時(shí)間，生產(chǎn)環(huán)境會(huì)發(fā)現(xiàn)30%左右的性能bug。這個(gè)當(dāng)前絕大多數(shù)公司的做法。
第三種是性能驅(qū)動(dòng)(performance driven),生命周期中的每一階段都考慮了性能, 生產(chǎn)環(huán)境會(huì)發(fā)現(xiàn)5%左右的性能bug。
系統(tǒng)設(shè)計(jì)階段缺少性能方面的考慮
設(shè)計(jì)的時(shí)候考慮性能有望產(chǎn)出好性能的應(yīng)用，至少也能使應(yīng)用在出現(xiàn)意想不到的性能問(wèn)題時(shí)靈活地能進(jìn)行修改或重新配置。設(shè)計(jì)相關(guān)的性能問(wèn)題后期才發(fā)現(xiàn)就很難解決，有時(shí)候甚至需要重新開(kāi)發(fā)。
多數(shù)的應(yīng)用基于可獨(dú)立測(cè)試的組件進(jìn)行開(kāi)發(fā)的，組件在單獨(dú)執(zhí)行的時(shí)候性能可能都不錯(cuò)，切記必須從整體來(lái)考慮。這些組件之間的交互必須高效且擴(kuò)展性好，集成后才會(huì)有好的性能。
直到最后一刻才進(jìn)行性能測(cè)試
性能驗(yàn)證模式下，性能測(cè)試直到系統(tǒng)發(fā)布前才會(huì)進(jìn)行，并且很少考慮到性能測(cè)試所需的時(shí)間及失敗后所造成的后果?？赡軣o(wú)法發(fā)現(xiàn)一些嚴(yán)重的性能缺陷或發(fā)現(xiàn)了性能問(wèn)題但卻沒(méi)有時(shí)間解決。
擴(kuò)展性
可能忽略了用戶的地理分布和規(guī)模等。需要考慮如下問(wèn)題：
有多少終端用戶會(huì)實(shí)際使用？
用戶位于何處？
多少用戶會(huì)同時(shí)使用？
用戶如何連接到應(yīng)用？
后期有多少額外的用戶需要訪問(wèn)應(yīng)用？
應(yīng)用的服務(wù)器數(shù)量及網(wǎng)絡(luò)拓?fù)洌?/p>
將應(yīng)用對(duì)網(wǎng)絡(luò)容量產(chǎn)生什么影響？
了解流行度
很多公司低估其應(yīng)用的人氣，人是好奇的，系統(tǒng)發(fā)布的第一天，你估計(jì)1萬(wàn)次點(diǎn)擊，結(jié)果卻是100萬(wàn)次點(diǎn)擊，您的應(yīng)用系統(tǒng)就這樣崩潰了！需要考慮高峰訪問(wèn)。
令人震驚的失敗：一個(gè)真實(shí)的例子
在很多年以前，英國(guó)政府決定在互聯(lián)網(wǎng)上公布1901年人口普查的結(jié)果。這涉及到大量的將舊文檔轉(zhuǎn)換成現(xiàn)代的數(shù)字格式文檔的工作，并且還需要?jiǎng)?chuàng)建一個(gè)應(yīng)用以供公眾訪問(wèn)。
很多希望了解家族歷史,24小時(shí)之后網(wǎng)站崩潰了。在之后的幾個(gè)星期里始終無(wú)法訪問(wèn)，直到最后重新發(fā)布。
性能測(cè)試還不規(guī)范
目前性能調(diào)優(yōu)的書(shū)籍很多，但是對(duì)醫(yī)生而言，最重要的是識(shí)別病情，識(shí)別性能瓶頸比解決問(wèn)題有時(shí)更難。
不使用自動(dòng)化的測(cè)試工具
不使用自動(dòng)化的測(cè)試工具和自動(dòng)化：?jiǎn)螁问褂檬止な呛茈y完成性能測(cè)試的。
應(yīng)用程序使用技術(shù)的影響
應(yīng)用程序使用技術(shù)的影響：某些新技術(shù)不太方便進(jìn)行測(cè)試。
如何選擇性能測(cè)試工具？
web方面的測(cè)試工具比較多。但是非web的，尤其是涉及到加密和壓縮的，就很少了，甚至是https，很多工具都處理不好。
性能測(cè)試工具架構(gòu)
常見(jiàn)的性能測(cè)試工具架構(gòu)：
腳本：描述用戶的活動(dòng)，支持不同協(xié)議。
測(cè)試管理模塊: 創(chuàng)建并執(zhí)行性能測(cè)試會(huì)話或場(chǎng)景。
負(fù)載生成器: 生成負(fù)載。
分析模塊: 分析數(shù)據(jù)，有些還有自動(dòng)分析的專家模式。
其他模塊: 監(jiān)控服務(wù)器和網(wǎng)絡(luò)性能的同時(shí)，與其他軟件集成。
選擇性能測(cè)試工具
選擇性能測(cè)試工具：
除了HTTP/S支持比較廣泛，JavaScript, JSON和 Microsoft Silverlight就不一樣了。
協(xié)議支持
授權(quán)：比如最大虛擬用戶數(shù)；能支持的額外協(xié)議；附加插件集成和特定的技術(shù)棧監(jiān)控，比如Oracle, Python等，)可以與APM(application performance monitoring)與CI(continuous integration)集成。
腳本支持：稍微復(fù)雜一點(diǎn)的測(cè)試就需要深入腳本?？紤]腳本修改的難度；考慮測(cè)試團(tuán)隊(duì)的技術(shù)水平，比如團(tuán)隊(duì)如果有python高手，直接用python功能會(huì)比具體的工具要強(qiáng)大得多。
解決方案與負(fù)載測(cè)試工具: 有些廠商只提供個(gè)負(fù)載測(cè)試工具，而有些提供性能測(cè)試解決方案。解決方案產(chǎn)花費(fèi)更多，但通常功能更強(qiáng)大，可能包括自動(dòng)需求管理，自動(dòng)數(shù)據(jù)創(chuàng)建和管理，預(yù)性能 測(cè)試的應(yīng)用程序調(diào)試和優(yōu)化，響應(yīng)時(shí)間預(yù)測(cè)和容量建模，APM提供類和方法層面的分析，集成用戶體驗(yàn)（EYE）監(jiān)控，管理測(cè)試結(jié)果和測(cè)試資產(chǎn)等。
外包：可以免去工具選型等。但是次數(shù)太多的成本太高。
其他：基于云平臺(tái)的測(cè)試。節(jié)約硬件成本。缺點(diǎn)：次數(shù)太多的成本太高，性能指標(biāo)監(jiān)控未必方便。程序不穩(wěn)定時(shí)代價(jià)很高。
備注：Loadrunner之類的性能測(cè)試工具，中文化和文檔都做得不錯(cuò)，對(duì)于通用的http協(xié)議效果也可以。但是擴(kuò)展性差、效率低下、價(jià)格極其昂貴。所以一般認(rèn)為一談性能就談Loadrunner的人沒(méi)有真正入門性能測(cè)試。功能測(cè)試的QTP也和Loadrunner類似。
性能測(cè)試工具集：概念驗(yàn)證(POC Proof of Concept)
POC至少要有兩個(gè)用例：讀數(shù)據(jù)和寫(xiě)數(shù)據(jù)。目的如下：
對(duì)性能測(cè)試工具是否適合目標(biāo)應(yīng)用進(jìn)行技術(shù)評(píng)估。
識(shí)別腳本數(shù)據(jù)要求
評(píng)估腳本需要的編寫(xiě)和修改時(shí)間
展示測(cè)試工具的容量。
POC檢查表
一般不建議超過(guò)2天。
準(zhǔn)備：
成功或退出標(biāo)準(zhǔn)，客戶已經(jīng)簽字。
工具的軟硬件準(zhǔn)備ok。
安裝任何需要監(jiān)控軟件的權(quán)限。
理想情況下保證環(huán)境專有性
應(yīng)用技術(shù)支持：產(chǎn)品專家。
應(yīng)用技術(shù)支持：技術(shù)專家(比如開(kāi)發(fā))可以咨詢或者應(yīng)用中間件級(jí)別的架構(gòu)宣講。
用戶帳戶：可以安裝訪問(wèn)
至少兩套憑據(jù)登錄目標(biāo)應(yīng)用程序。因?yàn)樾枰l(fā)執(zhí)行等。
兩個(gè)用例，簡(jiǎn)單的讀和復(fù)雜的寫(xiě)。
過(guò)程
錄制用例并比較異同，注意運(yùn)行時(shí)和會(huì)話數(shù)據(jù)等。
修改腳本，確認(rèn)用戶和多用戶模式都可以執(zhí)行，結(jié)果正確。確保腳本無(wú)內(nèi)存泄露等不良行為。
交付：
通過(guò)或者不通過(guò)
生成了數(shù)據(jù)需求。
腳本開(kāi)發(fā)時(shí)間
如果是售前，要能說(shuō)服客戶
有效應(yīng)用性能測(cè)試的基礎(chǔ)
需要考慮的問(wèn)題：
發(fā)布時(shí)要支持多少用戶？6個(gè)月，12個(gè)月，2年后呢？
用戶分布及如何將它們連接到應(yīng)用？
發(fā)布時(shí)用戶的并發(fā)？ 6個(gè)月后，12個(gè)月，2年后呢？
回答會(huì)引出一些問(wèn)題, 比如：
每個(gè)應(yīng)用層需要的服務(wù)器規(guī)格及數(shù)量是什么？
服務(wù)器的位置？
網(wǎng)絡(luò)基礎(chǔ)設(shè)施的類型？
回答不出來(lái)沒(méi)有關(guān)系，但是你已經(jīng)開(kāi)始考慮容量和擴(kuò)展性了。從廣義上講，功能需求定義系統(tǒng)是應(yīng)該做什么，非功能需求定義系統(tǒng)是什么樣子(來(lái)自維基百科)。在軟件測(cè)試中，性能測(cè)試基于基準(zhǔn)衡量系統(tǒng)對(duì)性能和容量質(zhì)量，包括以下內(nèi)容：
項(xiàng)目計(jì)劃
應(yīng)用夠穩(wěn)定
足夠的時(shí)間
代碼凍結(jié)
基本的非功能需求
設(shè)計(jì)合適的性能測(cè)試環(huán)境
設(shè)置現(xiàn)實(shí)合適的性能目標(biāo)
確定并腳本化的關(guān)鍵use case
測(cè)試數(shù)據(jù)
負(fù)荷模型
精確的性能測(cè)試設(shè)計(jì)
KPI(Key Performance Indicator)
應(yīng)用準(zhǔn)備OK
功能要運(yùn)行穩(wěn)定，不能10次運(yùn)行，2次失敗。避免性能測(cè)試成為頻繁的bug修改實(shí)踐。功能等問(wèn)題會(huì)掩蓋性能問(wèn)題。要有嚴(yán)格的單元和功能測(cè)試保證。衡量標(biāo)準(zhǔn)如下：
大量數(shù)據(jù)(High data presentation)：比如大量圖片和冗余會(huì)話。
低效SQL(Poorly performing SQL): 比如下圖：
大量應(yīng)用的網(wǎng)絡(luò)來(lái)回：容易導(dǎo)致延遲、帶寬限制和網(wǎng)絡(luò)擁塞等。
應(yīng)用錯(cuò)誤：比如HTTP 404，500等。
足夠的時(shí)間
以下工作需要時(shí)間：
準(zhǔn)備測(cè)試環(huán)境
配置負(fù)載注射器
識(shí)別user case(數(shù)天到數(shù)周)和腳本化
確定和創(chuàng)建測(cè)試數(shù)據(jù)(數(shù)天到數(shù)周)
測(cè)試環(huán)境安裝配置
問(wèn)題解決
代碼凍結(jié)
不凍結(jié)可能會(huì)導(dǎo)致腳本失效或不能代表用戶行為等。
設(shè)計(jì)性能測(cè)試環(huán)境
理論上要與生產(chǎn)環(huán)境完全一致，但是很多原因?qū)е虏惶赡埽旅媪谐霾糠衷颍?/p>
服務(wù)器的數(shù)量和規(guī)格: 服務(wù)器內(nèi)容和架構(gòu)難以復(fù)制，盡量保持規(guī)格一致，以方便提供基準(zhǔn)。
帶寬和網(wǎng)絡(luò)基礎(chǔ)設(shè)施：地理位置難以復(fù)制。
部署層次：建議完全一致。
-
數(shù)據(jù)庫(kù)大?。航ㄗh完全一致。
也有公司直接在生產(chǎn)環(huán)境同時(shí)部署測(cè)試環(huán)境或者直接拿生產(chǎn)環(huán)境做性能測(cè)試，后者注意不要影響用戶，包含數(shù)據(jù)和服務(wù)等。
性能測(cè)試的環(huán)境類型有：
生產(chǎn)環(huán)境非常接近的副本：通常不太現(xiàn)實(shí)。
生產(chǎn)環(huán)境的子集，層次一致，服務(wù)器規(guī)格一致，但是數(shù)量有所減少：建議達(dá)到的方案。
生產(chǎn)環(huán)境的子集，層次有縮減，服務(wù)器規(guī)格一致，但是數(shù)量有所減少：最常見(jiàn)的方案。
虛擬化
虛擬化的概念請(qǐng)參考：https://en.wikipedia.org/wiki/Virtualization 和 https://en.wikipedia.org/wiki/Docker_(software) 等。 注意：
虛擬機(jī)管理程序?qū)佑泄芾黹_(kāi)銷
總線和網(wǎng)絡(luò)的通信方式不同。前者沒(méi)有帶寬和延遲限制。在網(wǎng)絡(luò)跨地理位置的情況尤其需要注意。建議虛擬化與生產(chǎn)環(huán)境一致。特別注意不要跨層虛擬化在同一機(jī)器。
物理與虛擬NIC：后者的開(kāi)銷更大。
云計(jì)算
可以簡(jiǎn)單理解云計(jì)算為商品化的虛擬主機(jī)，它便宜，容易部署。相關(guān)概念介紹參見(jiàn)：https://en.wikipedia.org/wiki/Cloud_computing 。
優(yōu)點(diǎn)：
可以生成大量負(fù)載注射器。
便宜
快速
可擴(kuò)展
易部署
缺點(diǎn)
不及時(shí)關(guān)閉很貴
有時(shí)不可靠，比如配置的機(jī)器無(wú)法啟動(dòng)，IP被墻等。
負(fù)載注入容量
單機(jī)能模擬的虛擬用戶是有限的，特別注意測(cè)試機(jī)的CPU和內(nèi)存等使用率不要過(guò)載，盡量使用多的機(jī)器機(jī)進(jìn)行測(cè)試。注意以下幾點(diǎn)：
負(fù)載均衡：一些基于IP分配服務(wù)器。所以必要的時(shí)候需要使用IP欺騙。
用戶會(huì)話限制：比如一個(gè)IP只能一個(gè)會(huì)話。
其他問(wèn)題：
有些中間件不能用腳本表示。解決辦法，從表示層入手；改用瘦客戶端；自行開(kāi)發(fā)工具。
衡量表示層性能：性能測(cè)試通常工作在中間件層。比如想計(jì)算用戶點(diǎn)擊復(fù)選框的時(shí)間，建議使用前端測(cè)試工具。
網(wǎng)絡(luò)部署模式
廣域網(wǎng)的速度通常只有256 Kb左右，網(wǎng)絡(luò)延遲也比較大。延遲的產(chǎn)生基于光速：1ms/130公里以及交換機(jī)、路由器等網(wǎng)絡(luò)設(shè)備和服務(wù)器的時(shí)延。
如果有必要，可以：1，從WAN進(jìn)行性能測(cè)試；2，測(cè)試工具模擬；3，網(wǎng)絡(luò)模擬。
環(huán)境檢查表
服務(wù)器數(shù)：物理或虛擬服務(wù)器的數(shù)量。
負(fù)載均衡策略：負(fù)載均衡機(jī)制的類型。
硬件清單：CPU的類型和數(shù)目，內(nèi)存，網(wǎng)卡的類型和數(shù)量。
軟件清單：標(biāo)準(zhǔn)版本的軟件清單(不包括中間件)。
中間件清單。
內(nèi)部和外部鏈接
軟件安裝約束
比如安全考慮。
務(wù)實(shí)的性能目標(biāo)
目標(biāo)部分來(lái)自服務(wù)級(jí)別協(xié)議(SLA service-level agreement)。無(wú)論如何目標(biāo)必須明確。
一致
一致且盡早介入。
業(yè)務(wù)
C級(jí)管理負(fù)責(zé)預(yù)算和策略決定：
?首席信息官（CIO Chief information officer）
?首席技術(shù)官（CTO Chief technology officer）
?首席財(cái)務(wù)官（CFO Chief financial officer (CFO)）
?部門負(fù)責(zé)人
IT
?開(kāi)發(fā)人員
?測(cè)試
?架構(gòu)團(tuán)隊(duì)
?服務(wù)提供者（內(nèi)部和外部）
?終端用戶
?IT或運(yùn)維
性能目標(biāo)定義
主要包含可用性、響應(yīng)時(shí)間、吞吐量、并發(fā)、網(wǎng)絡(luò)利用率和服務(wù)器利用率。
在性能測(cè)試中并發(fā)是同時(shí)在線的用戶。要注意并發(fā)虛擬用戶和并發(fā)實(shí)際用戶不一定是同一回事。估算時(shí)需要基于二八原理和峰值等。
吞吐量通常更適合衡量無(wú)狀態(tài)的行為。比如瀏覽購(gòu)物時(shí)通常不會(huì)登錄，看中之后才會(huì)登錄，瀏覽購(gòu)物可以認(rèn)為是無(wú)狀態(tài)的。
響應(yīng)時(shí)間不要隨著并發(fā)的增加而大幅度增加，可以基于單個(gè)用戶做基準(zhǔn)測(cè)試。
網(wǎng)絡(luò)利用率需要關(guān)注數(shù)據(jù)量、數(shù)據(jù)吞吐量(可能會(huì)導(dǎo)致吞吐量突然下降是容量問(wèn)題)和數(shù)據(jù)錯(cuò)誤率。
服務(wù)器利用率主要關(guān)注CPU、內(nèi)存和I/O(磁盤(pán)和網(wǎng)絡(luò)等)
確定和腳本化關(guān)鍵業(yè)務(wù)user case
關(guān)鍵的user case一般不會(huì)超過(guò)10個(gè)。
Use-Case檢查表
記錄每個(gè)步驟
輸入數(shù)據(jù)和期望的響應(yīng)
用戶類型：新的或老用戶，超級(jí)用戶，客戶，客服等類型。
網(wǎng)絡(luò)：LAN或WAN
主動(dòng)還是被動(dòng)
腳本驗(yàn)證
基于抓包工具或錄制工具書(shū)寫(xiě)腳本，然后單用戶到多用戶調(diào)通。注意腳本不要影響到并發(fā)的執(zhí)行，盡量使用不同的用戶等。
檢查點(diǎn)
業(yè)務(wù)較復(fù)雜時(shí)尤其重要。
是否需要登入登出
盡量符合實(shí)際情況。
共存
注意共存的應(yīng)用和網(wǎng)絡(luò)共享
測(cè)試數(shù)據(jù)
輸入數(shù)據(jù)
用戶憑據(jù)：比如用戶名和密碼。
查找規(guī)則：通過(guò)客戶的姓名和詳細(xì)地址，發(fā)票號(hào)和產(chǎn)品碼甚至是通配符進(jìn)行查詢。
相關(guān)文件：比如圖片。
目標(biāo)數(shù)據(jù)
需要考慮數(shù)據(jù)容量是否符合規(guī)格的大小，數(shù)據(jù)回滾等。
會(huì)話數(shù)據(jù)
比如token。
數(shù)據(jù)安全
數(shù)據(jù)要保密，同時(shí)性能測(cè)試工具要實(shí)現(xiàn)與服務(wù)器端通信的加密方式。
性能測(cè)試設(shè)計(jì)
性能測(cè)試的類型
1.pipe-clean測(cè)試。
2.容量測(cè)試。盡量接近用戶實(shí)際使用。
3.隔離測(cè)試。
4.壓力測(cè)試。退出標(biāo)準(zhǔn)：沒(méi)有更多的用戶可以登錄，響應(yīng)時(shí)間難以接受，或應(yīng)用程序變得不可用。
5.浸泡測(cè)試，又叫穩(wěn)定測(cè)試。發(fā)現(xiàn)內(nèi)存泄漏等問(wèn)題。
6.冒煙測(cè)試，只測(cè)試修改的部分。注意和其他地方的概念不一樣。
pipe-clean, volume, stress和soak test通常都需要進(jìn)行。
負(fù)載模型
負(fù)載模型定義了user case的負(fù)載分布及并發(fā)和吞吐量的目標(biāo)。通常先基于容量測(cè)試，再擴(kuò)展到其他類型。注意測(cè)試數(shù)據(jù)、思考時(shí)間和步長(zhǎng)的影響。比如搜索數(shù)據(jù)分類：
小數(shù)據(jù)模型：具體的產(chǎn)品名稱或ID。
中數(shù)據(jù)模型：局部產(chǎn)品名稱。
大數(shù)據(jù)模型: 通配符或最小的產(chǎn)品名稱的內(nèi)容。
需要模擬真實(shí)情況下各種user case的分布:
吞吐量模型對(duì)于已有一個(gè)用需要參考Google Analytics或WebTrends，新應(yīng)用的需要估計(jì)。
思考時(shí)間代表著延遲和暫停。
步長(zhǎng)是循環(huán)之間的間隔。
負(fù)載注入方式有：Big Bang、Ramp-up、Ramp-up (with step)、Ramp up (with step), ramp down (with step)、Delayed start。注意"with step"主要是為了方便觀察。
KPI
服務(wù)器KPI
Windows 性能工具。Linux有monitor、top,、vmstat、sar等工具。監(jiān)控分為業(yè)務(wù)層、中間件層和系統(tǒng)層等。
通用模板如下：
? 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和應(yīng)用服務(wù)器層：比如nginx、WebLogic、WebSphere、Apache、JBOSS等。
數(shù)據(jù)庫(kù)層：比如MYSQL、Oracle等。MongoDB, Cassandra和DynamoDB可以視為應(yīng)用設(shè)計(jì)的一部分。
大型主機(jī)層：比如Strobe、Candle
主機(jī)層：比如亞馬遜的CloudWatch。
網(wǎng)絡(luò)層：網(wǎng)絡(luò)錯(cuò)誤、延遲、帶寬。
應(yīng)用監(jiān)控
性能測(cè)試過(guò)程
性能測(cè)試的方法
范圍和非功能需求捕捉：通常需要幾天。
性能測(cè)試環(huán)境準(zhǔn)備
user case腳本化：一個(gè)user case通常需要半天。
創(chuàng)建和驗(yàn)證性能測(cè)試場(chǎng)景。1-2天。前提是創(chuàng)建了精確的負(fù)載模型，定義每個(gè)性能測(cè)試的結(jié)構(gòu)和內(nèi)容。
執(zhí)行性能測(cè)試。通常需要5天左右。如果頻繁重測(cè)，耗時(shí)更多。
收集數(shù)據(jù)和卸載軟件。通常需要1天左右。
最后分析和報(bào)告。通常需要2-3天左右。
非功能需求分析
先決條件如下：
性能測(cè)試的截止期限
內(nèi)部或外部資源OK。
測(cè)試環(huán)境的設(shè)計(jì)。盡量接近真實(shí)環(huán)境。
代碼凍結(jié)。
專有的測(cè)試環(huán)境，
目標(biāo)。
關(guān)鍵用例。識(shí)別、記錄并準(zhǔn)備腳本。
用例中的檢查點(diǎn)。
選擇的use case的輸入、目標(biāo)和會(huì)話數(shù)據(jù)。同時(shí)還需要考慮數(shù)據(jù)安全。
負(fù)載模型OK。
性能測(cè)試場(chǎng)景的數(shù)量、類型、use-case內(nèi)容和虛擬用戶的部署已經(jīng)確定。還可能需要考慮時(shí)間，步長(zhǎng)，注入細(xì)節(jié)等。
識(shí)別和記錄應(yīng)用、服務(wù)器和網(wǎng)絡(luò)的KPI。注意需要關(guān)注基礎(chǔ)設(shè)施。
性能測(cè)試的輸出。
bug提交方式。涉及測(cè)試團(tuán)隊(duì)成員和報(bào)告結(jié)構(gòu)。工具、資源、技術(shù)和授權(quán)。另外還有培訓(xùn)，在外包的時(shí)候尤其重要。常見(jiàn)的架構(gòu)如下：
基于上述信息，可以輸出：
1.制定包括資源，時(shí)間線和里程碑的高層計(jì)劃
2.包括所有的依賴、相關(guān)時(shí)間線、詳細(xì)的場(chǎng)景和use case，負(fù)荷模型和環(huán)境信息的性能測(cè)試計(jì)劃。
3.風(fēng)險(xiǎn)評(píng)估。
另外還需要注意迭代。
性能測(cè)試環(huán)境準(zhǔn)備
步驟如下：
1.足夠的時(shí)間來(lái)采購(gòu)設(shè)備，配置和構(gòu)建環(huán)境。
2.考所有部署模型要在LAN和WAN環(huán)境實(shí)驗(yàn)。
3.考慮外部鏈接。
4.提供足夠的負(fù)荷注入容量。比如云主機(jī)。
5.確保應(yīng)用正確部署到測(cè)試環(huán)境。
6.軟件授權(quán)。
7.部署和配置性能測(cè)試工具。
8.部署和配置KPI監(jiān)控。
Use-Case腳本
針對(duì)每個(gè)user case：
?確定會(huì)話數(shù)據(jù)的要求。其中一些可能來(lái)自概念驗(yàn)證(POC)。
?確認(rèn)并應(yīng)用輸入數(shù)據(jù)的要求。
?檢查點(diǎn)。
?修改腳本
?腳本單用戶和多用戶都可以執(zhí)行。
性能測(cè)試場(chǎng)景構(gòu)建
? 測(cè)試類型是什么(pipe-clean, volume, soak, or stress？)，通常是針對(duì)user case進(jìn)行單個(gè)用戶(pipe-clean)測(cè)試，產(chǎn)生基線數(shù)據(jù)。然后加大并發(fā)和吞吐量。之后進(jìn)行混合user case的容量測(cè)試。然后可能有soak和stress測(cè)試，最后還可能結(jié)合負(fù)載均衡和容災(zāi)等測(cè)試。
?思考時(shí)間和步長(zhǎng)(尤其是壓力測(cè)試)。
?負(fù)載注射器和虛擬用戶的數(shù)量。
?注入方式：Big Bang, ramp-up, ramp-up/ramp-down with step, or delayed start。注意這幾種方式可能是連接的。比如下圖：
?測(cè)試執(zhí)行控制：執(zhí)行一段時(shí)間段、到達(dá)一定界限或測(cè)試數(shù)據(jù)耗盡停止或是用戶介入。
?是否需要IP欺騙?
?您是否需要模擬不同的波特率？
?監(jiān)控需求。
?Web的性能測(cè)試需要考慮瀏覽器緩存。還需要考慮新用戶，活躍用戶，回歸用戶等。
?技術(shù)影響，比如SAP比較消耗資源。
性能測(cè)試執(zhí)行
1.pipe-clean測(cè)試。
2.容量測(cè)試。
3.隔離測(cè)試
4.壓力測(cè)試。
5.浸泡測(cè)試，發(fā)現(xiàn)內(nèi)存泄漏等問(wèn)題
6.其他測(cè)試，比如負(fù)載均衡，容災(zāi)等。
性能測(cè)試分析和報(bào)告
?進(jìn)行最后的數(shù)據(jù)收集(可能有軟件卸載)。數(shù)據(jù)要有備份。
?比較試驗(yàn)結(jié)果與目標(biāo)，決定是否通過(guò)。
?測(cè)試報(bào)告。
性能測(cè)試分析
相關(guān)術(shù)語(yǔ)
平均值和中值
標(biāo)準(zhǔn)偏差和正態(tài)分布: 高標(biāo)準(zhǔn)偏差表示用戶體驗(yàn)不好。
百分比
響應(yīng)時(shí)間分布
吞吐量不能增加，一般有瓶頸存在：
遠(yuǎn) 程監(jiān)控：Windows注冊(cè)表、Web-Based Enterprise Management (WBEM)、Simple Network Monitoring Protocol (SNMP)、Java Monitoring Interface (JMX)、Rstatd（傳統(tǒng)的基于RPC的監(jiān)控工具）
客戶端需要關(guān)注：CPU百分比、內(nèi)存使用、頁(yè)利用率、磁盤(pán)時(shí)間、磁盤(pán)空間。
好的擴(kuò)展性與響應(yīng)時(shí)間：
差的擴(kuò)展性與響應(yīng)時(shí)間：
特別注意值的突然跳躍，一般是有瓶頸存在。另外服務(wù)器的基線數(shù)據(jù)也可供參考。
檢查表
性能測(cè)試與移動(dòng)端
移動(dòng)端的類型
移動(dòng)網(wǎng)站
移動(dòng)應(yīng)用
混合移動(dòng)應(yīng)用
m. site: 很少用，IOS中用來(lái)避免Apple App Store，像移動(dòng)應(yīng)用，但是實(shí)質(zhì)是移動(dòng)網(wǎng)站。
設(shè)計(jì)考慮
耗電量：
運(yùn)行一定時(shí)間，觀察耗電量；
與其他應(yīng)用同時(shí)使用，觀察耗電量排行。
網(wǎng)絡(luò)：
異步：
測(cè)試考慮
兼容性：系統(tǒng)、瀏覽器等組合。
API測(cè)試。
移動(dòng)測(cè)試設(shè)計(jì)
移動(dòng)網(wǎng)站：考慮瀏覽器?？梢詤⒖糋oogle Analytics。
移動(dòng)應(yīng)用：考慮API。
混合移動(dòng)應(yīng)用
m. site: 很少用，IOS中用來(lái)避免Apple App Store，像移動(dòng)應(yīng)用，但是實(shí)質(zhì)是移動(dòng)網(wǎng)站。
終端用戶體驗(yàn)監(jiān)控與性能
主動(dòng)監(jiān)控
測(cè)試需要考慮：
參考網(wǎng)絡(luò)圖如下：
主動(dòng)監(jiān)控主要關(guān)注：可用性和響應(yīng)時(shí)間。
