性能測試開展指導(dǎo)

1、性能測試開展指導(dǎo)項(xiàng)目測試組<文檔編號>文檔信息修改歷史日期版本作者修改內(nèi)容評審號更改請求號摘要本摘要提出了各位team leader需要關(guān)注的問題：目錄關(guān)注問題相關(guān)人員確定性能需求的解決方法Leader、業(yè)務(wù)人員、DBA、系統(tǒng)部人員、性能測試工程師確立性能測試目標(biāo)的原則Leader2.3不同階段的性能測試目標(biāo)Leader3.1性能測試方案的確立性能測試工程師3.2用例和場景設(shè)計(jì)性能測試工程師3.3設(shè)定需要監(jiān)控的資源性能測試工程師4性能測試的應(yīng)用領(lǐng)域Leader、性能測試工程師5.1分析影響性能因素的步驟設(shè)計(jì)人員、DBA、性能測試工程師5.2開發(fā)角度性能問題的原因開發(fā)人員、設(shè)計(jì)人員、

2、DBA、leader 6產(chǎn)品部署階段leader7維護(hù)階段leader8性能測試的策略性能測試工程師9各階段所要進(jìn)行的性能測試設(shè)計(jì)人員、開發(fā)人員、Leader、性能測試工程師10系統(tǒng)的穩(wěn)定性度量Leader、性能測試工程師11性能測試的基本概念性能測試工程師12響應(yīng)時間的分解性能測試工程師13在性能測試中需要注意的問題性能測試工程師目錄1編寫目的72需求階段72.1性能測試需求的確立7性能測試需求的來源7確定性能測試需求的解決方法72.2確立性能測試目標(biāo)8確立性能測試目標(biāo)的原則8確定性能測試目標(biāo)的方法82.3不同階段的性能測試目標(biāo)9設(shè)計(jì)階段的性能測試目標(biāo)9開發(fā)階段的性能測試目標(biāo)9產(chǎn)品部署階段的

3、性能測試目標(biāo)9系統(tǒng)維護(hù)階段的性能測試目標(biāo)93設(shè)計(jì)階段93.1性能測試方案的確立93.2用例和場景設(shè)計(jì)103.3設(shè)定需要監(jiān)控的資源104性能測試的應(yīng)用領(lǐng)域105實(shí)施階段115.1分析影響性能因素的步驟115.2開發(fā)角度性能問題的原因116產(chǎn)品部署階段117維護(hù)階段128性能測試的策略129各階段所要進(jìn)行的性能測試129.1設(shè)計(jì)階段的性能測試129.2實(shí)施階段的性能測試129.3產(chǎn)品部署階段的性能測試129.4維護(hù)階段的性能測試1210系統(tǒng)穩(wěn)定性的度量1311性能測試的基本概念1312響應(yīng)時間的分解1313在性能測試中需要注意的問題1413.1環(huán)境設(shè)計(jì)的問題1413.2其他需要注意的地方1514確

4、定最小用戶負(fù)載1514.1確定最小用戶負(fù)載的目的1514.2確定最小用戶負(fù)載的方法1515性能測試的兩個基本類別1615.1預(yù)備測試1615.2正式測試1616性能測試生存周期1617后臺活動分析1617.1分析Web應(yīng)用程序的用戶活動1717.2分析Web應(yīng)用程序的后臺性能瓶頸1718關(guān)鍵性能尺度標(biāo)準(zhǔn)1719鏡像生產(chǎn)環(huán)境1720用戶思考時間的問題1821確定負(fù)載增加的標(biāo)準(zhǔn)1822性能參數(shù)介紹1822.1處理器性能參數(shù)1822.2處理器瓶頸的解決辦法1922.3內(nèi)存性能參數(shù)191 編寫目的本文檔從性能工程的角度提出開展性能測試工作的流程，和進(jìn)行性能測試工作的策略，下面我們討論性能工程的需求階段

5、、設(shè)計(jì)階段、實(shí)施階段、產(chǎn)品部署階段、維護(hù)階段所要開展的工作，和相應(yīng)要采取的策略。2 需求階段2.1 性能測試需求的確立2.1.1 性能測試需求的來源性能測試需求的來源有三個方面：1、 需求文檔2、 設(shè)計(jì)文檔3、 客戶備忘錄2.1.2 確定性能測試需求的解決方法在沒有需求文檔和設(shè)計(jì)文檔的情況下，我們需要對TSP系統(tǒng)上的客戶業(yè)務(wù)使用情況進(jìn)行分析，提出我們所關(guān)注的性能測試需求，并告知業(yè)務(wù)人員。讓業(yè)務(wù)人員來判斷我們的性能需求是否能滿足客戶的真實(shí)要求。在通過TSP系統(tǒng)分析業(yè)務(wù)使用狀況時，我們可以從以下方面來關(guān)注：1、確定當(dāng)前系統(tǒng)的業(yè)務(wù)使用狀況：通過TSP的日志記錄客戶端模塊使用情況了解在某個時間段內(nèi)，客

6、戶執(zhí)行某個操作的具體情況。2、了解不同視角的用戶性能：）用戶視角：響應(yīng)時間：用戶所能感受到的響應(yīng)時間，也是用戶最重視的性能體驗(yàn)。 確立響應(yīng)時間的原則：2/5/10原則 2：2秒鐘用戶會覺得是一個很好的體驗(yàn)。 5：5秒鐘用戶可能會覺得差了一點(diǎn)，還行，比較好。 10：10秒鐘是用戶所能承受的最大極限。鑒于不同地區(qū)的網(wǎng)絡(luò)環(huán)境，將用戶所能承受的響應(yīng)時間極限定為1215秒。此部分需與業(yè)務(wù)人員討論。穩(wěn)定性：系統(tǒng)長時間運(yùn)行不會出現(xiàn)錯誤的能力。驗(yàn)證方法：系統(tǒng)在滿負(fù)載的運(yùn)行8小時，系統(tǒng)是否會出現(xiàn)服務(wù)不可用，Connection Refused HTTP 404,500錯誤。）系統(tǒng)視角：延遲，系統(tǒng)資源使用狀況 延

7、遲：包括數(shù)據(jù)庫延遲和網(wǎng)絡(luò)延遲此部分需與DBA及系統(tǒng)部人員討論。 系統(tǒng)資源使用狀況：服務(wù)器的CPU使用率是否長期高于80，達(dá)到90，100的程度，整個磁盤的I/O是否達(dá)到極限。內(nèi)存的使用數(shù)是否只剩下極少的幾兆，幾十兆。）開發(fā)者視角：從代碼實(shí)現(xiàn)和數(shù)據(jù)庫實(shí)現(xiàn)來考慮性能?？纯催@兩方面得到實(shí)現(xiàn)是否足夠好。3、了解真正的性能測試需求方法：）識別項(xiàng)目干系人：指的是和項(xiàng)目相關(guān)的人，開發(fā)人員，設(shè)計(jì)人員，需求人員，業(yè)務(wù)人員，上層領(lǐng)導(dǎo)，了解他們對性能測試的考慮。 ）隱藏在“性能測試”之后的實(shí)際想法，比如：是因?yàn)殚_發(fā)人員對所完成的代碼沒有信心，又不愿意做修改，要求我們對其所作的程序進(jìn)行性能測試，還是設(shè)計(jì)人員使用了一項(xiàng)

8、新技術(shù)，心里沒低，所要求作的性能測試，等等。2.2 確立性能測試目標(biāo)2.2.1 確立性能測試目標(biāo)的原則1、以“需求”為本考慮系統(tǒng)需不需要作性能測試，性能測試的內(nèi)容和范圍。2、測試目標(biāo)確定的經(jīng)濟(jì)性考慮）投入到性能測試的人員是多少？）具備可以確定性能測試需求，制定性能測試方案的人員是多少？可以執(zhí)行性能測試的人員是多少？）這些人員需要投入多長時間？）所要開發(fā)系統(tǒng)的運(yùn)行環(huán)境和設(shè)備，這些設(shè)備的配置對于性能測試的影響，比如說：tomcat4.1的應(yīng)用服務(wù)器，它的配置文件缺省的jvm的使用空間是64M，一個機(jī)器的內(nèi)存為1G，我們將jvm的使用空間設(shè)置為512M對性能測試的影響。 ）內(nèi)部的人員無法滿足性能測試

9、的要求，通過外聘，采用外聘的方式，公司所能承受的成本是多高。3、基于風(fēng)險的測試目標(biāo)確定）系統(tǒng)如果不做性能測試，會有多大的風(fēng)險，如果在性能指標(biāo)上達(dá)不到用戶的要求會有多大的風(fēng)險。需要進(jìn)行評估。）如果做性能測試會有多大的風(fēng)險，性能測試的投入會有多大，會有多大的風(fēng)險需要進(jìn)行評估。2.2.2 確定性能測試目標(biāo)的方法我們要確定系統(tǒng)的吞吐量和并發(fā)用戶數(shù)的設(shè)計(jì)目標(biāo)可以采用以下三種方式：l 確定在某個特定時間端內(nèi)，估計(jì)系統(tǒng)會有多少用戶同時訪問l 在某個特定的時間端內(nèi)，正在訪問系統(tǒng)的用戶的典型操作是什么？哪個頁面的訪問量最大？l 在某個特定的時間端內(nèi)，系統(tǒng)需要處理多少種用戶場景這些數(shù)據(jù)可以在系統(tǒng)服務(wù)器的日志文件、

10、TSP監(jiān)視數(shù)據(jù)種找到，也可以通過監(jiān)視數(shù)據(jù)庫的活動情況來獲得。2.3 不同階段的性能測試目標(biāo)2.3.1 設(shè)計(jì)階段的性能測試目標(biāo)設(shè)計(jì)階段的性能測試目標(biāo)為考察系統(tǒng)是否滿足預(yù)期的性能要求。2.3.2 開發(fā)階段的性能測試目標(biāo)）將開發(fā)階段的性能測試目標(biāo)作為對系統(tǒng)進(jìn)行調(diào)優(yōu)的參考：考慮在每個開發(fā)階段，性能是否能夠達(dá)到標(biāo)準(zhǔn)，考慮當(dāng)前階段的性能瓶頸，及其性能瓶頸出現(xiàn)的原因是在于數(shù)據(jù)庫訪問（SQL語句或者存儲過程寫的不夠好）還是其他的原因。 ）用性能測試手段發(fā)現(xiàn)系統(tǒng)存在的問題：通過模擬真實(shí)場景，發(fā)現(xiàn)在現(xiàn)場測試中可能存在的問題，比如說：用戶數(shù)的突然增加，導(dǎo)致的應(yīng)用程序崩潰，服務(wù)器崩潰的問題。2.3.3 產(chǎn)品部署階段的

11、性能測試目標(biāo)提供部署方案的參考，確定合適的硬件設(shè)備，雖然更高的設(shè)備可以獲取商業(yè)上的利益，但應(yīng)考慮客戶的具體情況。2.3.4 系統(tǒng)維護(hù)階段的性能測試目標(biāo)考察系統(tǒng)的可擴(kuò)展性：從系統(tǒng)的視角考慮,在用戶數(shù)擴(kuò)大，在業(yè)務(wù)量增大的情況下，是一個怎樣的表現(xiàn)。3 設(shè)計(jì)階段3.1 性能測試方案的確立在確立性能測試方案之前，需要作的工作1、確定測試目標(biāo)和需求這里的靈活性比較大，與性能測試成敗有很大的關(guān)系。2、了解現(xiàn)狀 ）業(yè)務(wù)使用狀況通過日志記錄，在某個時間段內(nèi)，用戶的操作。）了解環(huán)境：包括網(wǎng)絡(luò)條件，服務(wù)器條件，軟硬件條件，應(yīng)用服務(wù)器環(huán)境及各種配置信息。3、確定需要監(jiān)控的指標(biāo)：）CPU使用率 ）內(nèi)存使用情況 在此應(yīng)優(yōu)

12、先監(jiān)控應(yīng)用服務(wù)器的性能指標(biāo)。對于Tomcat或者Weblogic來說，監(jiān)控他的JVM使用狀況，連接池的連接數(shù)量，內(nèi)存使用狀況等信息。對于數(shù)據(jù)庫來說監(jiān)控cache的命中率，索引的使用狀況，數(shù)據(jù)庫的連接數(shù)。3.2 用例和場景設(shè)計(jì)用例和場景設(shè)計(jì)的步驟：1、對業(yè)務(wù)的分析和分解2、根據(jù)業(yè)務(wù)確定用例3、不同用例按照不同的發(fā)生比例組成場景 4、了解每個場景的實(shí)際意義 （對場景執(zhí)行測試，收集結(jié)果）了解業(yè)務(wù)的分布情況，根據(jù)業(yè)務(wù)確定用例，在設(shè)計(jì)用例的時候，根據(jù)前期收集的數(shù)據(jù)，設(shè)計(jì)不同的場景來組成用例，并了解每個場景的實(shí)際意義，執(zhí)行場景，收集結(jié)果數(shù)據(jù)。場景設(shè)計(jì)的例子（主要是根據(jù)業(yè)務(wù)的使用狀況）：l 場景1：10登錄

13、，10入庫，30訂單，20出庫，30查詢（1000用戶）日常l 場景2：10登錄，90查詢（400用戶）周末盤點(diǎn)3.3 設(shè)定需要監(jiān)控的資源設(shè)定需要監(jiān)控的資源主要有一下幾個方面：1、CPU利用率2、內(nèi)存使用情況3、數(shù)據(jù)庫監(jiān)控4、JVM使用狀況監(jiān)控應(yīng)優(yōu)先監(jiān)控應(yīng)用服務(wù)器的性能指標(biāo)。對于Tomcat或者Weblogic來說，監(jiān)控他的JVM使用狀況，連接池的連接數(shù)量，內(nèi)存使用狀況等信息。對于數(shù)據(jù)庫來說，cache的命中率，索引的使用狀況，數(shù)據(jù)庫的連接數(shù)，具體的監(jiān)控指標(biāo)請性能測試工程師，根據(jù)性能需求確定。4 性能測試的應(yīng)用領(lǐng)域40系統(tǒng)性能測試的主要應(yīng)用領(lǐng)域是驗(yàn)證能力、性能調(diào)優(yōu)。1、驗(yàn)證能力包括）驗(yàn)證新的系

14、統(tǒng)，新的架構(gòu)能否滿足用戶的需求。）向用戶提供性能測試報告，說明系統(tǒng)的性能達(dá)到了預(yù)期設(shè)計(jì)的標(biāo)準(zhǔn)。）確定新平臺的產(chǎn)品架構(gòu)，假設(shè)以前用ASP，現(xiàn)在用.net，或者換到j(luò)2ee平臺上，驗(yàn)證新系統(tǒng)架構(gòu)是否滿足性能要求，這個要求不是用戶提出來的，也不是直接用戶體驗(yàn)的，而是在架構(gòu)設(shè)計(jì)過程中要確定的指標(biāo)。2、性能調(diào)優(yōu)在系統(tǒng)開發(fā)過程中，通過性能測試，了解當(dāng)前系統(tǒng)瓶頸（比如說在于數(shù)據(jù)庫訪問，SQL語句或者存儲過程寫的不夠好，或者說數(shù)據(jù)庫設(shè)計(jì)的問題，索引做的不夠好），所選擇的應(yīng)用服務(wù)器有問題，或者說代碼這一層，業(yè)務(wù)邏輯實(shí)現(xiàn)的不夠好，導(dǎo)致它性能的缺陷。以確定問題出現(xiàn)在應(yīng)用層，數(shù)據(jù)庫層，代碼層。5 實(shí)施階段5.1 分析

15、影響性能因素的步驟將影響性能的因素按照以下順序進(jìn)行判斷：1、網(wǎng)絡(luò)狀況2、硬件設(shè)備3、系統(tǒng)/應(yīng)用服務(wù)器/數(shù)據(jù)庫配置4、數(shù)據(jù)庫設(shè)計(jì)和數(shù)據(jù)庫訪問實(shí)現(xiàn)（SQL和SP）5、業(yè)務(wù)的程序?qū)崿F(xiàn)但是在開發(fā)階段做性能調(diào)優(yōu)時關(guān)注的順序：請更多的關(guān)注SQL 一級和代碼一級。若是對于一個實(shí)際在線上運(yùn)行的系統(tǒng)，請直接按照以上5點(diǎn)的順序。注：很多的性能問題，是由于應(yīng)用服務(wù)器的配置完全不合理，比如：tomcat4.1的應(yīng)用服務(wù)器，沒有修改它的配置文件中缺省的jvm的使用空間。5.2 開發(fā)角度性能問題的原因1、對所使用的技術(shù)不熟悉這是影響最大的因素。對于.net平臺，j2ee平臺的架構(gòu)不熟悉，開發(fā)人員對于有哪些架構(gòu)和哪些模式對

16、于性能會有影響不了解，建議開發(fā)部門做一下調(diào)研。對于性能測試工程師來說，應(yīng)多了解一些平臺的知識，平臺的性能。J2ee的平臺和它的性能問題是怎么產(chǎn)生的，如何來調(diào)整它的性能。2、系統(tǒng)架構(gòu)設(shè)計(jì)的不合理3、程序員的實(shí)現(xiàn)錯誤6 產(chǎn)品部署階段產(chǎn)品部署階段的性能測試主要用來確立客戶需要什么樣的硬件配置。7 維護(hù)階段維護(hù)階段的性能測試主要在于考察系統(tǒng)的可擴(kuò)展性：從系統(tǒng)的視角考慮,在用戶數(shù)擴(kuò)大，在業(yè)務(wù)量增大的情況下，系統(tǒng)是一個怎樣的表現(xiàn)。8 性能測試的策略鑒于我們當(dāng)前的性能測試工作開展情況，先對3.0系統(tǒng)進(jìn)行一個容量測試，確定現(xiàn)有系統(tǒng)所能承受的最大用戶數(shù)及最大業(yè)務(wù)處理能力。并將這個結(jié)果告知用戶，讓用戶了解當(dāng)前系統(tǒng)

17、條件下的運(yùn)行水平，系統(tǒng)所能支撐的最大用戶數(shù)，每個用戶的響應(yīng)時間是多長。并將結(jié)果作為以后進(jìn)行4.0系統(tǒng)制定性能測試目標(biāo)的一個參照標(biāo)準(zhǔn)。9 各階段所要進(jìn)行的性能測試除了需求階段都需要進(jìn)行性能測試。其他階段的性能測試需要依據(jù)你的性能測試目標(biāo)：9.1 設(shè)計(jì)階段的性能測試在設(shè)計(jì)階段的性能測試主要的目的是驗(yàn)證你的架構(gòu)。驗(yàn)證的方式有兩種：1、在對于系統(tǒng)架構(gòu)有一個預(yù)期的性能目標(biāo)的情況下，去驗(yàn)證當(dāng)前架構(gòu)能否滿足預(yù)期的性能目標(biāo)。2、系統(tǒng)架構(gòu)是基于以前的架構(gòu)修改過來的，對于兩者進(jìn)行一個對比測試，了解兩種架構(gòu)各有什么優(yōu)勢。9.2 實(shí)施階段的性能測試在實(shí)施階段進(jìn)行性能測試的目的是為了階段性的驗(yàn)證系統(tǒng)性能，進(jìn)行性能調(diào)優(yōu)，

18、并通過系統(tǒng)調(diào)優(yōu)發(fā)現(xiàn)系統(tǒng)缺陷。9.3 產(chǎn)品部署階段的性能測試在產(chǎn)品部署階段，將性能測試作為驗(yàn)收測試的一部分。9.4 維護(hù)階段的性能測試在維護(hù)階段考察系統(tǒng)的可擴(kuò)充性/定位系統(tǒng)缺陷，考察系統(tǒng)的可擴(kuò)充性用來定位系統(tǒng)的缺陷。10 系統(tǒng)穩(wěn)定性的度量為了驗(yàn)證系統(tǒng)的穩(wěn)定性，我們需要對系統(tǒng)進(jìn)行一個可靠性度量，在目前沒有一個行業(yè)或者國際標(biāo)準(zhǔn)進(jìn)行可靠性度量的前提下，我們又無法獲得確切的用戶需求（用戶提不出系統(tǒng)穩(wěn)定性的量化標(biāo)準(zhǔn)），我們可以采用如下方式來驗(yàn)證系統(tǒng)的穩(wěn)定性。通過在做性能測試的過程中得到系統(tǒng)穩(wěn)定性數(shù)據(jù)的方式來驗(yàn)證系統(tǒng)的穩(wěn)定性手段：對一個系統(tǒng)進(jìn)行一個長時間的運(yùn)行，觀察它的可用內(nèi)存，cpu使用率有無顯著的變化，

19、如果在長時間使用的情況下，cpu，內(nèi)存無顯著變化，則可以認(rèn)為系統(tǒng)具有穩(wěn)定性。11 性能測試的基本概念1、響應(yīng)時間： 客戶端從發(fā)送請求的那一刻起到收到應(yīng)用程序響應(yīng)的最后一個字節(jié)時止而不 得不等待的時間長度。2、點(diǎn)擊數(shù)： 對每一個對象的請求，比如說：一個頁面有五個部分組成，一個框架，四張圖片，這樣算做5個點(diǎn)擊數(shù)。3、頁面請求： 請求了一個頁面，不管這個頁面包括了多少對象。4、吞吐量： i）按照流量來計(jì)算的吞吐量，用來衡量網(wǎng)絡(luò)狀況或者應(yīng)用服務(wù)器的處理能力，在指定的時間內(nèi)，每秒鐘字節(jié)的出入.ii）用點(diǎn)擊數(shù)來衡量吞吐量，每個固定的時間段內(nèi)有多少點(diǎn)擊數(shù)，用于銀行系統(tǒng)。5、并發(fā)用戶：從業(yè)務(wù)上的并發(fā)：200人

20、同時在線。 從服務(wù)器上的并發(fā)：200人同時向服務(wù)器發(fā)出請求。200人同時做一個提交的操作，服務(wù)器接受到多少請求。6、資源利用率：cpu利用率，內(nèi)存利用率，磁盤I/O狀況等12 響應(yīng)時間的分解響應(yīng)時間網(wǎng)絡(luò)響應(yīng)時間應(yīng)用程序響應(yīng)時間 網(wǎng)絡(luò)延遲N1（數(shù)據(jù)在網(wǎng)絡(luò)上傳輸?shù)臅r間）web服務(wù)器請求被處理的時間A1 web服務(wù)器到database服務(wù)器的傳輸時間N2（如果兩臺服務(wù)器在同一臺機(jī)器上傳輸時間就會很短）數(shù)據(jù)庫服務(wù)器處理數(shù)據(jù)庫請求所耗的時間A2database服務(wù)器返回請求到web服務(wù)器的傳輸時間N3web服務(wù)器請求被處理的時間A3網(wǎng)絡(luò)延遲N4因此，性能的相關(guān)性大概為三個部分：網(wǎng)絡(luò)的延遲、應(yīng)用服務(wù)器處理

21、的延遲、數(shù)據(jù)庫處理的延遲。所以，在開發(fā)階段做性能調(diào)優(yōu)的時候，針對這三個方面進(jìn)行。響應(yīng)時間的獲得：用lr可以獲得一個完整的響應(yīng)時間，有兩種辦法可以獲得各部分的數(shù)據(jù)，i)自己做一些日志，應(yīng)用服務(wù)器可以接受到的，應(yīng)用服務(wù)器可以接受到的，打開這個日志可以看到他什么時候接受到請求的，來判斷網(wǎng)絡(luò)的延遲是多少，數(shù)據(jù)庫的延遲也可以用同樣的方法來做。這種方法的資源消耗比較大，只用于驗(yàn)證已確定的系統(tǒng)中的問題在哪里。ii)通過各種工具慢慢來做：比如：做某個業(yè)務(wù)的時候響應(yīng)速度很慢，可以用排除法來做：第一，猜測是網(wǎng)絡(luò)的問題，在兩個網(wǎng)絡(luò)之間使用網(wǎng)絡(luò)測試工具sniffer測試網(wǎng)絡(luò)延遲，或者用windows操作系統(tǒng)，在win

22、dows2000，advanced server也有相應(yīng)的工具測點(diǎn)對點(diǎn)的延遲。數(shù)據(jù)庫的延遲可以采用將影響性能的SQL語句摘出來，直接在環(huán)境下實(shí)際運(yùn)行一下，看實(shí)際的處理時間是多少，對于應(yīng)用服務(wù)器的延遲，通過應(yīng)用服務(wù)器本身的日志，或者在應(yīng)用實(shí)現(xiàn)的代碼里加一些日志輸出來實(shí)現(xiàn)。13 在性能測試中需要注意的問題13.1 環(huán)境設(shè)計(jì)的問題1、網(wǎng)絡(luò)環(huán)境2、軟硬件環(huán)境3、環(huán)境的維護(hù)方案4、時間同步問題5、“鏡像”環(huán)境時間同步問題：各種服務(wù)器部署在不同的機(jī)器上，在進(jìn)行性能測試分析響應(yīng)時間的時候就需要進(jìn)行時間同步，通過日志來對比時間，但日志上記錄的是本地時間，讓日志記錄的時間有可比性，需要做時間同步。同步的方法：在

23、UNIX操作系統(tǒng)上用NTP協(xié)議可以做時間同步，在windows系統(tǒng)上可以通過加入域來時間同步，“鏡像”環(huán)境的問題：做能力驗(yàn)證的測試的時候，一般要求在現(xiàn)場做，因?yàn)檫@種測試結(jié)果和應(yīng)用服務(wù)器網(wǎng)絡(luò)環(huán)境本身會有很大的關(guān)系，如果不能做現(xiàn)場測試，采用的兩個解決辦法：i）盡可能的模擬出用戶環(huán)境：包括網(wǎng)絡(luò)狀況，服務(wù)器狀況，ii）和用戶去協(xié)商：去做現(xiàn)場測試。13.2 其他需要注意的地方1、應(yīng)用服務(wù)器的Warm up問題J2ee應(yīng)用或者.net應(yīng)用現(xiàn)在都會涉及本地編譯的過程，在第一次做運(yùn)行的時候，在第一次訪問的時候速度會很慢，第二次訪問才會快起來，因?yàn)閺谋镜谻ache中讀取信息，所以在應(yīng)用服務(wù)器重啟了以后，都必須多

24、測幾次，等服務(wù)器Warm up后再測試，否則的話，前面的結(jié)果沒有有效性。整個的結(jié)果還會有誤差。2、應(yīng)用服務(wù)器的Cache在多次測試的過程中，把Cache功能給去掉，或者把cache給清空。3、瀏覽器或客戶端應(yīng)用的Cache客戶端和瀏覽器的cache在錄制腳本的時候都應(yīng)該去掉。14 確定最小用戶負(fù)載14.1 確定最小用戶負(fù)載的目的為了全面掌握應(yīng)用程序的性能不僅是重壓條件下，而且是在更為理想的條件下。這是很重要的，因?yàn)閼?yīng)用程序通常將大部分的時間花費(fèi)在這些低負(fù)載條件下。峰值操作通常很少發(fā)生。14.2 確定最小用戶負(fù)載的方法從需求上解決，了解業(yè)務(wù)分布情況，將業(yè)務(wù)分布情況劃分成不同的場景，確定一個負(fù)載使

25、用狀況最小的場景。執(zhí)行此場景，觀察系統(tǒng)在此場景下的運(yùn)行狀況。15 性能測試的兩個基本類別 15.1 預(yù)備測試預(yù)備測試：最初的試探性測試，讓我們能夠感受一下應(yīng)用程序的性能并優(yōu)化測試環(huán)境。15.2 正式測試有四個正式的性能測度，我們的分析就建立在這些測度上。可以將這些正式測試按照類型分成如下幾個子類：單實(shí)例壓力測試、持久測試、體系結(jié)構(gòu)測試一旦按照初步測試結(jié)果設(shè)置好了環(huán)境和測試參數(shù)（測試腳本、思考時間、采樣方法等等），這些因素就必須對任何特定的性能測試都保持不變。如果在某個特定的性能測試中修改任何參數(shù)，那么我們就破壞了結(jié)果的可比較性，將不得不重新執(zhí)行測試。16 性能測試生存周期l 規(guī)劃性能分析l 創(chuàng)

26、建有效的壓力腳本l 執(zhí)行壓力測試l 分析性能測試數(shù)據(jù)來確定和解決性能瓶頸規(guī)劃性能分析階段的工作包括收集重要的原始數(shù)據(jù)，然后根據(jù)這些信息制訂測試方案。規(guī)劃階段收集到的信息至少應(yīng)該描述兩個方面的內(nèi)容：l 用來復(fù)制一個接近生產(chǎn)環(huán)境的測試環(huán)境的細(xì)節(jié)。l 對該應(yīng)用程序的使用方式的理解，以及臨界性能表現(xiàn)的跡象等。這些信息可以來源于市場預(yù)測報告、站點(diǎn)的IIS日志、站點(diǎn)的性能日志和站點(diǎn)功能說明等。創(chuàng)建高效的壓力測試腳本 在收集了所需信息并搭建了測試環(huán)境后，下一步就是創(chuàng)建測試腳本，它應(yīng)該能夠準(zhǔn)確地模擬站點(diǎn)期望地流量。最有效地方式是根據(jù)實(shí)況網(wǎng)站中的歷史數(shù)據(jù)結(jié)合市場調(diào)查或商業(yè)分析而得到這些期望數(shù)據(jù)。執(zhí)行壓力測試 創(chuàng)

27、建可以模擬最大用戶負(fù)載的壓力測試腳本。分析性能測試結(jié)果 (i)確定性能瓶頸影響終端用戶響應(yīng)時間的瓶頸包括應(yīng)用程序和服務(wù)器的吞吐量、終端到終端的Internet連接速度以及網(wǎng)絡(luò)涌塞等。（ii）檢驗(yàn)性能優(yōu)化結(jié)果分析結(jié)果了解系統(tǒng)的性能狀況并能夠?qū)π阅苓M(jìn)行提高。17 后臺活動分析后臺活動分析可以用來分析再Web應(yīng)用程序數(shù)據(jù)庫層上的用戶活動情況和性能瓶頸。使用這些信息有助于獲得精確的性能測試結(jié)果。17.1 分析Web應(yīng)用程序的用戶活動用戶在Web應(yīng)用程序中的詳細(xì)活動信息是記錄在數(shù)據(jù)庫中的。我們可以根據(jù)自己的業(yè)務(wù)需求到數(shù)據(jù)庫中去查詢用戶活動的處理情況。比如：有多少訂單被處理、有多少登陸行為發(fā)生，以及用戶進(jìn)

28、行了多少次搜索。通過這些簡單的查詢就可以將這些信息從數(shù)據(jù)庫里提取出來，這些信息將用來幫助制定用戶場景（user scenarios）、用戶場景比率或其他營銷方面的情報。17.2 分析Web應(yīng)用程序的后臺性能瓶頸對于現(xiàn)有系統(tǒng)的Web應(yīng)用程序進(jìn)行性能測試，可以檢查數(shù)據(jù)庫服務(wù)器，找出那些花費(fèi)長時間運(yùn)行、引起死鎖或占用了大量系統(tǒng)資源的SQL語句，從而判斷出當(dāng)前性能的瓶頸在哪里。方法為使用包括SQL分析器工具跟蹤SQL語句的執(zhí)行情況以及對Web應(yīng)用程序中的Windows和SQL Server等對象進(jìn)行監(jiān)視產(chǎn)生性能監(jiān)視日志。由SQL語句造成對性能的影響，主要的原因包括：阻塞、索、死鎖、有問題的查詢以及需要

29、花費(fèi)大量時間執(zhí)行的存儲過程等。18 關(guān)鍵性能尺度標(biāo)準(zhǔn)性能測試的關(guān)鍵尺度包括以下幾點(diǎn)：l 服務(wù)器錯誤的可接受性 壓力測試過程中經(jīng)常會發(fā)生服務(wù)器錯誤，在壓力測試剛剛開始或正在結(jié)束時，錯誤往往會產(chǎn)生，這是因?yàn)榘l(fā)生了大量的突發(fā)負(fù)荷和未完成的頁面請求。這些錯誤時由于壓力測試而造成的，不大可能在生產(chǎn)環(huán)境中發(fā)生，因此可以忽略這些錯誤。l 服務(wù)器利用的可接受性 確定服務(wù)器所能承受的最大負(fù)荷程度。制定出度量標(biāo)準(zhǔn)，并將這些度量標(biāo)準(zhǔn)形成文檔，發(fā)布給開發(fā)組，支持組，管理組的人員，以后可以根據(jù)這個度量標(biāo)準(zhǔn)監(jiān)視生產(chǎn)環(huán)境中的Web服務(wù)器，看哪些需求超過了Web服務(wù)器的性能要求，然后就可以想辦法提高Web應(yīng)用程序的性能來處理

30、更高的流量。l 內(nèi)存泄漏和其他穩(wěn)定性問題 這種問題往往出現(xiàn)在長時間高負(fù)荷的運(yùn)行情況下。19 鏡像生產(chǎn)環(huán)境性能測試的環(huán)境應(yīng)該盡可能地接近實(shí)際生產(chǎn)中的環(huán)境，包括服務(wù)器的性能和配置、網(wǎng)絡(luò)環(huán)境、系統(tǒng)的負(fù)載均衡方案和后臺數(shù)據(jù)庫等。通過鏡像生產(chǎn)環(huán)境，可以確保測試結(jié)果的準(zhǔn)確性。注：即使無法模擬出生產(chǎn)環(huán)境的硬件情況，依然可以發(fā)現(xiàn)許多存在于代碼和系統(tǒng)架構(gòu)中的瓶頸。雖然理想狀態(tài)下測試環(huán)境應(yīng)盡可能地接近生產(chǎn)環(huán)境，實(shí)際上在能搭建地任何測試環(huán)境中測試都是有意義的。20 用戶思考時間的問題創(chuàng)建測試腳本的時候，可以選擇使用用戶思考時間，主要考慮到用戶在訪問系統(tǒng)過程中的思考時間，因此能幫助我們更好地模擬實(shí)際情況下的應(yīng)用程序使

31、用情況，但在對新框架的測試中，因?yàn)橹恍栩?yàn)證框架的穩(wěn)定性和框架所能承受的并發(fā)用戶數(shù)及頁面響應(yīng)時間就不需考慮用戶的業(yè)務(wù)使用情況。另外，使用用戶思考時間會降低客戶端能夠產(chǎn)生的最大負(fù)載量，會影響到對最大負(fù)荷下系統(tǒng)的性能表現(xiàn)的計(jì)算結(jié)果。而且，如果客戶端發(fā)送請求的能力本身就存在不足的話，將更加難以發(fā)現(xiàn)性能瓶頸，因?yàn)槠款i往往是在系統(tǒng)承擔(dān)最大負(fù)載時表現(xiàn)出來的。21 確定負(fù)載增加的標(biāo)準(zhǔn)確定壓力測試需要進(jìn)行的程度，首先需要指定一個標(biāo)準(zhǔn)，確定何時達(dá)到適當(dāng)?shù)膲毫墑e。我在這里舉一些可能的測試標(biāo)準(zhǔn)的例子：l 當(dāng)一定數(shù)量的錯誤出現(xiàn)在事件或Web服務(wù)器的日志中時，停止繼續(xù)增加負(fù)載。l 不斷增加負(fù)載，直到吞吐量開始下降。l 給CPU利用率設(shè)置一個極限值