提到性能測(cè)試，相信大家可以在網(wǎng)上找到很多種不同的定義、解釋以及分類方法。不過(guò)歸根結(jié)底，在大多數(shù)情況下，我們所要做的性能測(cè)試的目的是“觀察系統(tǒng)在一個(gè)給定的環(huán)境和場(chǎng)景中的性能表現(xiàn)是否與預(yù)期目標(biāo)一致，評(píng)判系統(tǒng)是否存在性能缺陷，并根據(jù)測(cè)試結(jié)果識(shí)別性能瓶頸，改善系統(tǒng)性能”。

本文是《LoadRunner沒(méi)有告訴你的》系列的第五篇，在這篇文章中，我希望可以跟大家一起來(lái)探討“如何將性能測(cè)試應(yīng)用到軟件開發(fā)過(guò)程的各個(gè)階段中，如何通過(guò)盡早的開展性能測(cè)試來(lái)規(guī)避因?yàn)樾阅苋毕輰?dǎo)致的損失”。

因此，本文的結(jié)構(gòu)也將依據(jù)軟件開發(fā)過(guò)程的不同階段來(lái)組織。

另外，建議您在閱讀本文前先閱讀本系列文章的第三篇《理發(fā)店模型》和第四篇《理解性能》。

需求階段

我們不可能將一輛設(shè)計(jì)載重為0.75噸的皮卡改裝成載重15噸的大型卡車，如果你面對(duì)的正是這樣的問(wèn)題，那么恐怕你只能重做一輛，而且客戶不會(huì)為你之前那輛付錢。對(duì)于一個(gè)已經(jīng)完成的應(yīng)用系統(tǒng)來(lái)說(shuō)也是如此。

如果我們?cè)谙到y(tǒng)結(jié)構(gòu)確定之前就能夠了解到系統(tǒng)的將要面對(duì)的壓力，用戶的使用習(xí)慣和使用頻度，我們就可以更早也更有效的提前解決或預(yù)防可能發(fā)生的性能缺陷，也將會(huì)極大的減少后期返工和反復(fù)調(diào)優(yōu)所帶來(lái)的工作量。如果我們預(yù)期到系統(tǒng)的容量將會(huì)不斷的增長(zhǎng)，我們還可以給出相應(yīng)的解決方案來(lái)低成本的解決這類問(wèn)題，就像上面那輛皮卡，也許你可以有辦法把20輛皮卡捆在一起，或者把15噸的東西分由20輛來(lái)運(yùn)。

分析設(shè)計(jì)階段

系統(tǒng)性能的優(yōu)化并不是要等待整個(gè)系統(tǒng)全部集成后才能開始的，早在分析設(shè)計(jì)階段，我們就可以開始考慮系統(tǒng)的技術(shù)架構(gòu)和數(shù)據(jù)庫(kù)部分的優(yōu)化。

數(shù)據(jù)庫(kù)通常位于整個(gè)系統(tǒng)的最底層，如果直到系統(tǒng)上線前才發(fā)現(xiàn)因?yàn)閿?shù)據(jù)庫(kù)設(shè)計(jì)不合理而導(dǎo)致性能極差，通常使用任何一種方法來(lái)優(yōu)化都已經(jīng)于事無(wú)補(bǔ)了。要避免這類問(wèn)題，最常見(jiàn)的做法是在數(shù)據(jù)庫(kù)結(jié)構(gòu)確定后，通過(guò)工具或腳本向數(shù)據(jù)庫(kù)中注入大量的數(shù)據(jù)，并模擬各種業(yè)務(wù)的數(shù)據(jù)庫(kù)操作。根據(jù)對(duì)數(shù)據(jù)庫(kù)性能的觀察和分析，對(duì)數(shù)據(jù)庫(kù)表結(jié)構(gòu)和索引進(jìn)行調(diào)整以優(yōu)化數(shù)據(jù)庫(kù)性能。

在系統(tǒng)的技術(shù)架構(gòu)方面，要明白先進(jìn)的技術(shù)并不是解決問(wèn)題的唯一方法，過(guò)于強(qiáng)調(diào)技術(shù)的作用反而會(huì)將你帶入歧途。例如：某些業(yè)務(wù)雖然經(jīng)常面臨著巨大的壓力，并且業(yè)務(wù)本身的復(fù)雜性決定了通過(guò)算法的優(yōu)化來(lái)提高系統(tǒng)的性能收效甚微。但是我們知道用戶對(duì)于該業(yè)務(wù)的實(shí)時(shí)性要求并不高，并且返回結(jié)果對(duì)于不同用戶來(lái)說(shuō)是相同的。那么我們完全可以考慮將每次請(qǐng)求都動(dòng)態(tài)生成返回結(jié)果的方式改為每次用戶請(qǐng)求都返回一個(gè)定期更新的靜態(tài)頁(yè)面。

另外，所謂“先進(jìn)技術(shù)”通常都會(huì)在帶來(lái)某一方面改進(jìn)的同時(shí)帶來(lái)另一方面的問(wèn)題，未經(jīng)試驗(yàn)就盲目的在系統(tǒng)中加入各種流行元素未必是最好的選擇。例如ORM可以提供一些方便，但是它生成的SQL是未經(jīng)優(yōu)化的，有時(shí)甚至比人工編寫的SQL效率更低。

最后，要知道不同廠家的設(shè)備性能是不同的，而且不同的硬件設(shè)備搭載不同的操作系統(tǒng)、數(shù)據(jù)庫(kù)、中間件以及應(yīng)用服務(wù)器，表現(xiàn)出來(lái)的性能也是不同的。如果有足夠的資源，應(yīng)當(dāng)考慮提前進(jìn)行軟硬件平臺(tái)的對(duì)比選型；如果沒(méi)有足夠的資源，可以考慮通過(guò)一些專業(yè)的組織或網(wǎng)站來(lái)獲取或購(gòu)買相關(guān)的評(píng)估報(bào)告。

編碼階段

一片樹葉在哪里最難被發(fā)現(xiàn)？——當(dāng)這片樹葉落在一堆樹葉里面的時(shí)候。

如果你只是在系統(tǒng)測(cè)試完成后才開始性能測(cè)試，那么即使發(fā)現(xiàn)系統(tǒng)存在性能缺陷，并且已經(jīng)有了幾個(gè)可供懷疑的對(duì)象，但是當(dāng)一段因?yàn)槭褂昧瞬划?dāng)?shù)乃惴ǘ鴮?dǎo)致執(zhí)行效率很低的代碼藏身于一個(gè)龐大的系統(tǒng)中時(shí)，找出它是非常困難的。避免這種情況出現(xiàn)的方法是盡早開始核心業(yè)務(wù)代碼的性能測(cè)試，重點(diǎn)集中在對(duì)算法和實(shí)現(xiàn)方法的優(yōu)化上。

另外，及早開始的測(cè)試也可以幫你更容易找到內(nèi)存泄漏的問(wèn)題。

測(cè)試階段

產(chǎn)品終于交到我們手上了，搭建測(cè)試環(huán)境，設(shè)計(jì)測(cè)試場(chǎng)景，執(zhí)行測(cè)試，找到系統(tǒng)的最佳并發(fā)用戶數(shù)和最大并發(fā)用戶數(shù)，將系統(tǒng)進(jìn)行分類，評(píng)判系統(tǒng)的性能表現(xiàn)是否滿足需求中定義的目標(biāo)——如果有需求的話 ^_^

如果發(fā)現(xiàn)系統(tǒng)的性能表現(xiàn)與預(yù)期目標(biāo)相去甚遠(yuǎn)，則需要根據(jù)執(zhí)行測(cè)試過(guò)程中收集到的數(shù)據(jù)來(lái)分析和識(shí)別性能瓶頸，優(yōu)化系統(tǒng)性能。

在這個(gè)階段還有很多值得我們深入思考和討論的東西，在本系列后續(xù)的文章中，我們將會(huì)更多的關(guān)注這一部分的內(nèi)容。

維護(hù)階段

維護(hù)階段通常遇到的問(wèn)題是需要在實(shí)驗(yàn)室中模擬客戶環(huán)境，重現(xiàn)在客戶那里發(fā)現(xiàn)的缺陷并修復(fù)缺陷。相比功能缺陷，性能缺陷與某一具體環(huán)境和場(chǎng)景的關(guān)聯(lián)更加密切，所以在測(cè)試前需要檢查生產(chǎn)環(huán)境中各服務(wù)器的資源利用率、系統(tǒng)訪問(wèn)日志、應(yīng)用服務(wù)器的日志、數(shù)據(jù)庫(kù)的日志。如果客戶使用了專門的系統(tǒng)來(lái)監(jiān)測(cè)各個(gè)服務(wù)器的軟硬件資源使用情況的話，檢查該系統(tǒng)是否記錄下了軟硬件資源的異常或者警告。

與性能測(cè)試相關(guān)的其他測(cè)試

可靠性測(cè)試（Reliability Testing）    對(duì)于一個(gè)運(yùn)營(yíng)商級(jí)的系統(tǒng)來(lái)說(shuō)，能夠保證提供7×24的連續(xù)穩(wěn)定的服務(wù)是非常重要的。當(dāng)然，你可以通過(guò)一些“高可用性（High Availability）”技術(shù)方案來(lái)增強(qiáng)系統(tǒng)的可靠性，但是對(duì)于系統(tǒng)本身的可靠性測(cè)試是不能被忽略的。

常用的測(cè)試方法是使用一定的負(fù)載長(zhǎng)時(shí)間向服務(wù)器加壓，并觀察隨著加壓時(shí)間的延長(zhǎng)，響應(yīng)時(shí)間、吞吐量以及資源利用率的變化。要注意的是，所使用的負(fù)載應(yīng)當(dāng)是系統(tǒng)的最佳并并發(fā)用戶數(shù)，而不是最大并發(fā)用戶數(shù)。

可伸縮性測(cè)試（Scalability Testing） 對(duì)于一個(gè)系統(tǒng)來(lái)說(shuō)，在一個(gè)給定的環(huán)境下，它的最佳并發(fā)用戶數(shù)和最大并發(fā)用戶數(shù)是客觀存在的，但是系統(tǒng)所面臨的壓力卻有可能隨上線時(shí)間的延長(zhǎng)而增大。例如，一個(gè)在線購(gòu)物站點(diǎn)，注冊(cè)用戶數(shù)量不斷增多，訪問(wèn)站點(diǎn)查詢商品信息和購(gòu)買商品的人也不斷的增多，我們應(yīng)該用一種什么樣的方案，在不影響系統(tǒng)繼續(xù)為用戶提供服務(wù)的前提下來(lái)實(shí)現(xiàn)系統(tǒng)的擴(kuò)容？

一種常用的方案是使用負(fù)載均衡（Load Balance）和集群（Cluster）技術(shù)。但是在我們?yōu)榭蛻籼峁┻@種方案之前，需要先自己進(jìn)行測(cè)試，保證該技術(shù)的有效性——我們是否真的可以通過(guò)簡(jiǎn)單的增加服務(wù)器數(shù)據(jù)和修改某些參數(shù)配置，就能夠使得系統(tǒng)的容量得到線性的增長(zhǎng)？

可恢復(fù)性測(cè)試（Recoverability Testing）      雖然我們已經(jīng)可以準(zhǔn)確的估算出系統(tǒng)上線后將要面對(duì)的壓力，并且可以保證系統(tǒng)的最佳并發(fā)用戶數(shù)和最大并發(fā)用戶數(shù)是足以應(yīng)對(duì)這些壓力的，但是這個(gè)世界上總是有些事情上我們所無(wú)法預(yù)料到的——例如9.11事件發(fā)生后，AOL的網(wǎng)站訪問(wèn)量在短時(shí)間內(nèi)增長(zhǎng)到了平時(shí)的數(shù)十倍。

我們無(wú)法保證系統(tǒng)可以在任何情況下都能為用戶正確無(wú)誤的提供服務(wù)，但是我們需要確保當(dāng)意外過(guò)去后，系統(tǒng)可以恢復(fù)到正常的狀態(tài)，并繼續(xù)后來(lái)的用戶提供服務(wù)——就像從未發(fā)生過(guò)任何事情一樣。

如果要實(shí)現(xiàn)“可恢復(fù)性測(cè)試”，我們可以借助于測(cè)試工具或腳本來(lái)逐漸的增大并發(fā)用戶數(shù)，直至并發(fā)用戶數(shù)已經(jīng)超過(guò)了系統(tǒng)所能承受的最大并發(fā)用戶數(shù)，并導(dǎo)致軟硬件資源利用率飽和，響應(yīng)時(shí)間無(wú)限延長(zhǎng)，大量的請(qǐng)求因?yàn)槌^(guò)響應(yīng)時(shí)間要求或無(wú)法獲得響應(yīng)而失?。恢?，我們逐漸的減少并發(fā)用戶數(shù)，并觀察資源利用率、響應(yīng)時(shí)間、吞吐量以及交易成功率的變化是否與預(yù)期目標(biāo)一致。