?做測試一年多來，雖然平時的工作都能很好的完成，但最近突然發(fā)現(xiàn)自己在關(guān)于測試的整體知識體系上面的了解很是欠缺，所以，在工作之余也做了一些測試方面的知識的補(bǔ)充。不足之處，還請大家多多交流，互相學(xué)習(xí)。

現(xiàn)在看來，雖然平時工作中，所涉及雖然的是自動化測試，但更多的是功能測試，今天了解了一下性能測試。

同時，我也清楚的意識到，對于測試工具而言，會不會或者熟悉不熟悉是遲早的事，只要你經(jīng)常用，但掌握測試的基礎(chǔ)知識，了解一些測試思想和觀念，更能讓我們受益無窮。

下面總結(jié)一下我所學(xué)習(xí)到的性能測試：

性能測試（Performance?Testing）：是通過自動化的測試工具模擬多種正常、峰值以及異常負(fù)載條件來對系統(tǒng)的各項性能指標(biāo)進(jìn)行測試。負(fù)載測試和壓力測試都屬于性能測試。通過負(fù)載測試，確定在各種工作負(fù)載下的系統(tǒng)的性能，目標(biāo)是測試當(dāng)負(fù)載逐漸增加時，系統(tǒng)各項性能指標(biāo)的變化情況。壓力測試是通過確定一個系統(tǒng)的瓶頸或者不能接受的性能點，來獲得系統(tǒng)能提供的最大服務(wù)級別的測試。

負(fù)載測試（Load?Testing）：是模擬實際軟件所承受的負(fù)載條件的系統(tǒng)負(fù)荷，通過不斷加載（如逐漸增加模擬用戶的數(shù)量）或其他加載方式來觀察不同負(fù)載下系統(tǒng)的響應(yīng)時間和數(shù)據(jù)吞吐量、系統(tǒng)占用的資源（CPU、內(nèi)存等），以檢驗系統(tǒng)的行為和特性，以發(fā)現(xiàn)系統(tǒng)可能存在的性能瓶頸，內(nèi)存泄漏，不能實時同步等問題，負(fù)載測試更多的體現(xiàn)了一種方法或一種技術(shù)。

壓力測試（stress?testing）：在強(qiáng)負(fù)載（大數(shù)據(jù)量、大量并發(fā)用戶等）下的測試，查看應(yīng)用系統(tǒng)在峰值使用情況下的操作行為，從而有效地發(fā)現(xiàn)系統(tǒng)的某項功能隱患，系統(tǒng)是否具有良好的容錯能力和可恢復(fù)能力。壓力測試可分為高負(fù)載下的長時間（如24小時以上）的穩(wěn)定性壓力測試和極限負(fù)載情況下導(dǎo)致系統(tǒng)奔潰的破壞性壓力測試。

三者的區(qū)別：?從測試的目的出發(fā)，從用戶的需求出發(fā)，就比較容易區(qū)分性能測試、負(fù)載測試和壓力測試了。性能測試是為了獲得系統(tǒng)在某種特定的條件下（包括特定的負(fù)載條件下）的性能指標(biāo)數(shù)據(jù)，而負(fù)載測試、壓力測試是為了發(fā)現(xiàn)軟件系統(tǒng)中所存在的問題，包括性能瓶頸、內(nèi)存泄漏等。通過負(fù)載測試，也是為了獲得系統(tǒng)正常工作時所能承受的最大負(fù)載，這時的負(fù)載測試就成為了容量測試。通過壓力測試，可以知道在什么極限情況下系統(tǒng)會奔潰、系統(tǒng)是否具有自我恢復(fù)性等，但更多的是為了確定系統(tǒng)的穩(wěn)定性。

性能測試工具（目前只是知道有這些工具，后期在使用過程中在總結(jié)它們的使用方法）：

(1) Apache?Jmeter:?用戶手冊?Apache JMeter - User's Manual

(2) Load Runner

(3) QTP(Quick Test)

(4) Web Polygraph

性能測試不單單是熟悉測試工具，更要注意的是其中的測試思想，下面可以了解一下關(guān)于性能測試的三個觀念：

• 精確和模糊

i.e.?一輛汽車開100公里需要多少汽油？

做假設(shè)（assumption），下面有3個階段的假設(shè)：

a.?做了假設(shè)卻不知道自己做了假設(shè)

有些人根據(jù)自己的切身體驗來做測試，然后寫測試報告給別人看，關(guān)鍵是你覺得自己的測試是正確的，但并不是所有人都是處于你所處的環(huán)境，做和你測試時做完全一樣的事情，所以測試出來的結(jié)果只會誤導(dǎo)到別人。比如前面提到的那個耗油的問題，有人的做法是我開100公里看看，得出來多少就是多少。

b.?做了過多的假設(shè)

”當(dāng)路面平坦，一路綠燈，風(fēng)速5km/h,只有一名70kg的乘客，時速穩(wěn)定在70km/h,良好駕駛習(xí)慣，… ,?的情況下，油耗是7.1L/100km.“這樣可能很嚴(yán)謹(jǐn)，但對于讀你報告的讀者，這樣的數(shù)據(jù)沒有多大的意義。

c.?做必要和合理的假設(shè)

生活中有些時候是需要一些妥協(xié)和折衷的，如果這些折衷是必要的和合理的。因為跳出來看，我們的測試需要提供有價值的信息，所以為了這樣有價值的信息，做出必要的合理的假設(shè)是可以接受的。

• 宏觀與微觀

這也是一個有趣的對立。在做性能測試，特別是整個產(chǎn)品的性能測試的時候，我們看到的是產(chǎn)品的核心功能和主要的大的功能模塊，比如數(shù)據(jù)庫、web服務(wù)器、核心的daemon等等。在腦海里，我們有一個架構(gòu)圖，哪怕你沒有把它畫出來。所以有時候，我們會想，性能測試對于產(chǎn)品的視角是宏觀的，看大的組件，而不是具體的細(xì)節(jié)的東西。

果真是如此嗎？看看下面的例子：

1.?把daemon的log級別改為debug?（log_level從2改到5）之后，性能下降了差不多一半。

2.?關(guān)掉一個cache選項

3.?打開keepalive選項

4.?打開DNS反向查詢

......

上面都是些細(xì)枝末節(jié)的設(shè)置，一個配置項而已，藏在DB的某張表或者某個ini里面。但是改變之后，得到的性能結(jié)果可能大不相同。

這時候，其實要不要考慮細(xì)枝末節(jié)，主要是看他到底是否Critical。至于怎樣的才是至關(guān)重要的，這還需要在以后的工作中思考和總結(jié)。

• 項目和任務(wù)

性能測試本身肯定是一個任務(wù)，無論對于被安排去做這個的人，或者安排的人。但是它有時候也像一個項目，對于去做這件事情的人。為什么呢？

首先你需要和很多的人打交道。

產(chǎn)品經(jīng)理或者客戶：獲取需求，設(shè)定目標(biāo)。

QA manager/lead：討論resource和schedule。包括需要的機(jī)器，環(huán)境，軟件，還有整個計劃。

開發(fā)人員：查找問題和調(diào)優(yōu)等。

功能測試的owner：?性能測試人員可能不是什么功能都很懂。

Admin：Lab，網(wǎng)絡(luò)，DB等等

其次，它是一個周期很長，跨度很大的工作。特別是對于一個比較大的產(chǎn)品而言。你需要準(zhǔn)備詳細(xì)的測試設(shè)計，包括目標(biāo)、范圍、可能的方法，以及上面提到的資源和時間計劃；然后邀請很多人來評審這個計劃；接下來要準(zhǔn)備工具、環(huán)境和測試數(shù)據(jù)。然后是執(zhí)行，記錄分析結(jié)果。如果有問題還要反復(fù)的調(diào)整和regression。最后要整理報告，回答疑問。

說它是一個項目一來是因為上面的原因?qū)е鹿ぷ鞯膹?fù)雜性，還有一些原因是因為性能測試帶有評測的性質(zhì)，因為你是在試圖去度量、衡量或者評價一個東西，而且?guī)в斜容^絕對的結(jié)果。這樣導(dǎo)致性能測試不可避免的要引入一些權(quán)威性的問題，盡管你并不一定期望這樣。這使得很多的東西就像一個其他項目一樣，有期望管理和良好的外部溝通和協(xié)調(diào)的需要。所以有時候，更愿意把它作為一個小的項目來看待，這樣或許可以做得更全面。

到了這里，關(guān)于性能測試/負(fù)載測試/壓力測試之間的區(qū)別的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！