@import url(http://www.tkk7.com/CuteSoft_Client/CuteEditor/Load.ashx?type=style&file=SyntaxHighlighter.css);@import url(/css/cuteeditor.css);

《LoadRunner沒有告訴你的》 《轉(zhuǎn)載》

1.        LoadRunner之—Block

l  如何在一個(gè)腳本中實(shí)現(xiàn)不同事務(wù)不同次數(shù)的循環(huán)呢？

l  案例：假如你想在一個(gè)腳本中，實(shí)現(xiàn)登錄執(zhí)行1次，查詢執(zhí)行2次，插入執(zhí)行3次，怎么辦？錄3個(gè)腳本？每個(gè)事務(wù)分別在腳本中復(fù)制N次？

l  當(dāng)然不用，LR早就想到了你的需求，下面讓我們隆重推出Block。

l  位置：Run-time Settings--General--Run Logic

l  操作：

l  將你所要考察的事務(wù)設(shè)置在不同的Action內(nèi)。

l  在Run Logic中的Run中刪掉默認(rèn)的Action。

l  在Run中插入Block。

l  在插入的Block中再插入我們要考察的Action。

l  設(shè)置Block的properties。這里有兩種選擇，Sequential和Random。如果選擇Sequential，在下面的Iteration中直接填入數(shù)值，那么Block中的Action都會按輸入的次數(shù)執(zhí)行。如果選擇Random，下面的properties還可以設(shè)置Block內(nèi)各Action執(zhí)行的百分比。

l  按照我們前面的案例，我們只需要設(shè)置3個(gè)Block，每個(gè)Block中分別插入一個(gè)Action，設(shè)置執(zhí)行次數(shù)分別為1，2，3就可以了。

 

l  本人理解補(bǔ)充

1、  如果腳本中各個(gè)action沒有順序或邏輯關(guān)系，Block中action順序可以是任意的。如查詢。但是像登錄這樣必須在前面執(zhí)行的action，隨意放置將導(dǎo)致腳本失敗。

2、  在Number of Iterations中設(shè)置的循環(huán)次數(shù)，作用于Run(x)下的所有Action，而不作用于Block下的action。即Block下的action可以通過設(shè)置Block的Properties來指定循環(huán)的次數(shù)。

2.        《LoadRunner 沒有告訴你的》之一——描述性統(tǒng)計(jì)與性能結(jié)果分析

l  LoadRunner中的90％響應(yīng)時(shí)間是什么意思？這個(gè)值在進(jìn)行性能分析時(shí)有什么作用？本文爭取用最簡潔的文字來解答這個(gè)問題，并引申出“描述性統(tǒng)計(jì)”方法在性能測試結(jié)果分析中的應(yīng)用。

l  為什么要有90％用戶響應(yīng)時(shí)間？因?yàn)樵谠u估一次測試的結(jié)果時(shí)，僅僅有平均事務(wù)響應(yīng)時(shí)間是不夠的。為什么這么說？你可以試著想想，是否平均事務(wù)響應(yīng)時(shí)間滿足了性能需求就表示系統(tǒng)的性能已經(jīng)滿足了絕大多數(shù)用戶的要求？

l  假如有兩組測試結(jié)果，響應(yīng)時(shí)間分別是 {1，3，5，10，16} 和 {5，6，7，8，9}，它們的平均值都是7，你認(rèn)為哪次測試的結(jié)果更理想？

l  假如有一次測試，總共有100個(gè)請求被響應(yīng)，其中最小響應(yīng)時(shí)間為0.02秒，最大響應(yīng)時(shí)間為110秒，平均事務(wù)響應(yīng)時(shí)間為4.7秒，你會不會想到最小和最大響應(yīng)時(shí)間如此大的偏差是否會導(dǎo)致平均值本身并不可信？

l  為了解答上面的疑問，我們先來看一張表：

l  在上面這個(gè)表中包含了幾個(gè)不同的列，其含義如下：

l  CmdID   測試時(shí)被請求的頁面

l  NUM      響應(yīng)成功的請求數(shù)量

l  MEAN    所有成功的請求的響應(yīng)時(shí)間的平均值

l  STD DEV      標(biāo)準(zhǔn)差（這個(gè)值的作用將在下一篇文章中重點(diǎn)介紹）

l  MIN              響應(yīng)時(shí)間的最小值

l  50 th(60/70/80/90/95 th)          如果把響應(yīng)時(shí)間從小到大順序排序，那么50％的請求的響應(yīng)時(shí)間在這個(gè)范圍之內(nèi)。后面的60/70/80/90/95 th 也是同樣的含義

l  MAX      響應(yīng)時(shí)間的最大值

l  我想看完了上面的這個(gè)表和各列的解釋，不用多說大家也可以明白我的意思了。我把結(jié)論性的東西整理一下：

l  1.      90％用戶響應(yīng)時(shí)間在 LoadRunner中是可以設(shè)置的，你可以改為80％或95％；

l  2.      對于這個(gè)表，LoadRunner中是沒有直接提供的，你可以把LR中的原始數(shù)據(jù)導(dǎo)出到Excel中，并使用Excel中的PERCENTILE 函數(shù)很簡單的算出不同百分比用戶請求的響應(yīng)時(shí)間分布情況；

l  3.      從上面的表中來看，對于Home Page來說，平均事務(wù)響應(yīng)時(shí)間(MEAN)只同70％用戶響應(yīng)時(shí)間相一致。也就是說假如我們確定Home Page的響應(yīng)時(shí)間應(yīng)該在5秒內(nèi)，那么從平均事務(wù)響應(yīng)時(shí)間來看是滿足的，但是實(shí)際上有10-20％的用戶請求的響應(yīng)時(shí)間是大于這個(gè)值的；對于Page 1也是一樣，假如我們確定對于Page 1 的請求應(yīng)該在3秒內(nèi)得到響應(yīng)，雖然平均事務(wù)響應(yīng)時(shí)間是滿足要求的，但是實(shí)際上有20-30％的用戶請求的響應(yīng)時(shí)間是超過了我們的要求的；

l  4.      你可以在95 th之后繼續(xù)添加96/ 97/ 98/ 99/ 99.9/ 99.99 th，并利用Excel的圖表功能畫一條曲線，來更加清晰表現(xiàn)出系統(tǒng)響應(yīng)時(shí)間的分布情況。這時(shí)候你也許會發(fā)現(xiàn)，那個(gè)最大值的出現(xiàn)幾率只不過是千分之一甚至萬分之一，而且99％的用戶請求的響應(yīng)時(shí)間都是在性能需求所定義的范圍之內(nèi)的；

l  5.      如果你想使用這種方法來評估系統(tǒng)的性能，一個(gè)推薦的做法是盡可能讓你的測試場景運(yùn)行的時(shí)間長一些，因?yàn)楫?dāng)你獲得的測試數(shù)據(jù)越多，這個(gè)響應(yīng)時(shí)間的分布曲線就越接近真實(shí)情況；

l  6.      在確定性能需求時(shí)，你可以用平均事務(wù)響應(yīng)時(shí)間來衡量系統(tǒng)的性能，也可以用90％或95％用戶響應(yīng)時(shí)間來作為度量標(biāo)準(zhǔn)，它們并不沖突。實(shí)際上，在定義某些系統(tǒng)的性能需求時(shí)，一定范圍內(nèi)的請求失敗也是可以被接受的；

l  7.      上面提到的這些內(nèi)容其實(shí)是與工具無關(guān)的，只要你可以得到原始的響應(yīng)時(shí)間記錄，無論是使用LoadRunner還是JMeter或者OpenSTA，你都可以用這些方法和思路來評估你的系統(tǒng)的性能。

l  事實(shí)上，在性能測試領(lǐng)域中還有更多的東西是目前的商業(yè)測試工具或者開源測試工具都沒有專門講述的——換句話說，性能測試僅僅有工具是不夠的。我們還需要更多其他領(lǐng)域的知識，例如數(shù)學(xué)和統(tǒng)計(jì)學(xué)，來幫助我們更好的分析性能數(shù)據(jù)，找到隱藏在那些數(shù)據(jù)之下的真相。

3.        《LoadRunner 沒有告訴你的》之二——描述性統(tǒng)計(jì)與性能結(jié)果分析

l      數(shù)據(jù)統(tǒng)計(jì)分析的思路與分析結(jié)果的展示方式是同樣重要的，有了好的分析思路，但是卻不懂得如何更好的展示分析結(jié)果和數(shù)據(jù)來印證自己的分析，就像一個(gè)人滿腹經(jīng)綸卻不知該如何一展雄才 ^_^

l  一圖勝千言，所以這次我會用兩張圖表來說明“描述性統(tǒng)計(jì)”在性能測試結(jié)果分析中的其他應(yīng)用。

l 

l  在這張圖中，我們繼續(xù)使用了上一篇文章——《描述性統(tǒng)計(jì)與結(jié)果分析》一文中的方法，對響應(yīng)時(shí)間的分布情況來進(jìn)行分析。上面這張圖所使用的數(shù)據(jù)是通過對

l  Google.com 首頁進(jìn)行測試得來的，在測試中分別使用10/25/50/75/100 幾個(gè)不同級別的并發(fā)用戶數(shù)量。通過這張圖表，我們可以通過橫向比較和縱向比較，更清晰的了解到被測應(yīng)用在不同級別的負(fù)載下的響應(yīng)能力。

l 

l  這張圖所使用的數(shù)據(jù)與第一張圖一樣，但是我們使用了另外一個(gè)視角來對數(shù)據(jù)進(jìn)行展示。表中最左側(cè)的2000/5000/10000/50000的單位是毫秒，分別表示了在整個(gè)測試過程中，響應(yīng)時(shí)間在0-2000毫秒范圍內(nèi)的事務(wù)數(shù)量占成功的事務(wù)總數(shù)的百分比，響應(yīng)時(shí)間在2001-5000毫秒范圍內(nèi)的事務(wù)數(shù)量占成功的事務(wù)總數(shù)的百分比，響應(yīng)時(shí)間在5001-10000毫秒范圍內(nèi)的事務(wù)數(shù)量占成功的事務(wù)總數(shù)的百分比，以及響應(yīng)時(shí)間在10001-50000毫秒范圍內(nèi)的事務(wù)數(shù)量占成功的事務(wù)總數(shù)的百分比。

l  這幾個(gè)時(shí)間范圍的確定是參考了業(yè)內(nèi)比較通行的“2-5-10原則”——當(dāng)然你也可以為自己的測試制定其他標(biāo)準(zhǔn)，只要得到企業(yè)內(nèi)的承認(rèn)就可以。所謂的“2-5-10原則”，簡單說，就是當(dāng)用戶能夠在2秒以內(nèi)得到響應(yīng)時(shí)，會感覺系統(tǒng)的響應(yīng)很快；當(dāng)用戶在2-5秒之間得到響應(yīng)時(shí)，會感覺系統(tǒng)的響應(yīng)速度還可以；當(dāng)用戶在5-10秒以內(nèi)得到響應(yīng)時(shí)，會感覺系統(tǒng)的響應(yīng)速度很慢，但是還可以接受；而當(dāng)用戶在超過10秒后仍然無法得到響應(yīng)時(shí)，會感覺系統(tǒng)糟透了，或者認(rèn)為系統(tǒng)已經(jīng)失去響應(yīng)，而選擇離開這個(gè)Web站點(diǎn)，或者發(fā)起第二次請求。

l  那么從上面的圖表中可以看到，當(dāng)并發(fā)用戶數(shù)量為10時(shí)，超過95％的用戶都可以在5秒內(nèi)得到響應(yīng)；當(dāng)并發(fā)用戶數(shù)量達(dá)到25時(shí)，已經(jīng)有80％的事務(wù)的響應(yīng)時(shí)間處在危險(xiǎn)的臨界值，而且有相當(dāng)數(shù)量的事務(wù)的響應(yīng)時(shí)間超過了用戶可以容忍的限度；隨著并發(fā)用戶數(shù)量的進(jìn)一步增加，超過用戶容忍限度的事務(wù)越來越多，當(dāng)并發(fā)用戶數(shù)到達(dá)75時(shí)，系統(tǒng)幾乎已經(jīng)無法為任何用戶提供響應(yīng)了。

l  這張圖表也同樣可以用于對不同負(fù)載下事務(wù)的成功、失敗比例的比較分析。

l  Note：上面兩個(gè)圖表中的數(shù)據(jù)，主要通過Excel 中提供的FREQUENCY，AVERAGE，MAX，MIN和PERCENTILE幾個(gè)統(tǒng)計(jì)函數(shù)獲得，具體的使用方法請參考Excel幫助手冊。

4.        《LoadRunner 沒有告訴你的》之三——理發(fā)店模型

l  相信大家都進(jìn)過或見過理發(fā)店，一間或大或小的鋪面，1個(gè)或幾個(gè)理發(fā)師，幾張理發(fā)用的椅子和供顧客等待的長條板凳

l 

l  在我們的這個(gè)理發(fā)店中，我們事先做了如下的假設(shè)：

l  1.       理發(fā)店共有3名理發(fā)師；

l  2.      每位理發(fā)師剪一個(gè)發(fā)的時(shí)間都是1小時(shí)；

l  3.      我們顧客們都是很有時(shí)間觀念的人而且非常挑剔，他們對于每次光顧理發(fā)店時(shí)所能容忍的等待時(shí)間+剪發(fā)時(shí)間是3小時(shí)，而且等待時(shí)間越長，顧客的滿意度越低。如果3個(gè)小時(shí)還不能剪完頭發(fā)，我們的顧客會立馬生氣的走人。

l  通過上面的假設(shè)我們不難想象出下面的場景：

l  1.  當(dāng)理發(fā)店內(nèi)只有1位顧客時(shí)，只需要有1名理發(fā)師為他提供服務(wù)，其他兩名理發(fā)師可能繼續(xù)等著，也可能會幫忙打打雜。1小時(shí)后，這位顧客剪完頭發(fā)出門走了。那么在這1個(gè)小時(shí)里，整個(gè)理發(fā)店只服務(wù)了1位顧客，這位顧客花費(fèi)在這次剪發(fā)的時(shí)間是1小時(shí)；

l  2.  當(dāng)理發(fā)店內(nèi)同時(shí)有兩位顧客時(shí)，就會同時(shí)有兩名理發(fā)師在為顧客服務(wù)，另外1位發(fā)呆或者打雜幫忙。仍然是1小時(shí)后，兩位顧客剪完頭發(fā)出門。在這1小時(shí)里，理發(fā)店服務(wù)了兩位顧客，這兩位顧客花費(fèi)在剪發(fā)的時(shí)間均為1小時(shí)；

l  3.  很容易理解，當(dāng)理發(fā)店內(nèi)同時(shí)有三位顧客時(shí)，理發(fā)店可以在1小時(shí)內(nèi)同時(shí)服務(wù)三位顧客，每位顧客花費(fèi)在這次剪發(fā)的時(shí)間仍然是均為1小時(shí)；

l  從上面幾個(gè)場景中我們可以發(fā)現(xiàn)，在理發(fā)店同時(shí)服務(wù)的顧客數(shù)量從1位增加到3位的過程中，隨著顧客數(shù)量的增多，理發(fā)店的整體工作效率在提高，但是每位顧客在理發(fā)店內(nèi)所呆的時(shí)間并未延長。

l  當(dāng)然，我們可以假設(shè)當(dāng)只有1位顧客和2位顧客時(shí)，空閑的理發(fā)師可以幫忙打雜，使得其他理發(fā)師的工作效率提高，并使每位顧客的剪發(fā)時(shí)間小于1小時(shí)。不過即使根據(jù)這個(gè)假設(shè)，雖然隨著顧客數(shù)量的增多，每位顧客的服務(wù)時(shí)間有所延長，但是這個(gè)時(shí)間始終還被控制在顧客可接受的范圍之內(nèi)，并且顧客是不需要等待的。

l  不過隨著理發(fā)店的生意越來越好，顧客也越來越多，新的場景出現(xiàn)了。假設(shè)有一次顧客A、B、C剛進(jìn)理發(fā)店準(zhǔn)備剪發(fā)，外面一推門又進(jìn)來了顧客D、E、F。因?yàn)?/span>A、B、C三位顧客先到，所以D、E、F三位只好坐在長板凳上等著。1小時(shí)后，A、B、C三位剪完頭發(fā)走了，他們每個(gè)人這次剪發(fā)所花費(fèi)的時(shí)間均為1小時(shí)。可是D、E、F三位就沒有這么好運(yùn)，因?yàn)樗麄円鹊?/span>A、B、C三位剪完才能剪，所以他們每個(gè)人這次剪發(fā)所花費(fèi)的時(shí)間均為2小時(shí)——包括等待1小時(shí)和剪發(fā)1小時(shí)。

l  通過上面這個(gè)場景我們可以發(fā)現(xiàn)，對于理發(fā)店來說，都是每小時(shí)服務(wù)三位顧客——第1個(gè)小時(shí)是A、B、C，第二個(gè)小時(shí)是D、E、F；但是對于顧客D、E、F來說，“響應(yīng)時(shí)間”延長了。如果你可以理解上面的這些場景，就可以繼續(xù)往下看了。

l  在新的場景中，我們假設(shè)這次理發(fā)店里一次來了9位顧客，根據(jù)我們上面的場景，相信你不難推斷，這9位顧客中有3位的“響應(yīng)時(shí)間”為1小時(shí)，有3位的“響應(yīng)時(shí)間”為2小時(shí)（等待1小時(shí)+剪發(fā)1小時(shí)），還有3位的“響應(yīng)時(shí)間”為3小時(shí)（等待2小時(shí)+剪發(fā)1小時(shí)）——已經(jīng)到達(dá)用戶所能忍受的極限。假如在把這個(gè)場景中的顧客數(shù)量改為10，那么我們已經(jīng)可以斷定，一定會有1位顧客因?yàn)?#8220;響應(yīng)時(shí)間”過長而無法忍受，最終離開理發(fā)店走了。

l  我想并不需要特別說明，大家也一定可以把上面的這些場景跟性能測試掛上鉤了。如果你還是覺得比較抽象，繼續(xù)看下面的這張圖 ^_^

l 

l  這張圖中展示的是1個(gè)標(biāo)準(zhǔn)的軟件性能模型。在圖中有三條曲線，分別表示資源的利用情況（Utilization，包括硬件資源和軟件資源）、吞吐量（Throughput，這里是指每秒事務(wù)數(shù)）以及響應(yīng)時(shí)間（Response Time）。圖中坐標(biāo)軸的橫軸從左到右表現(xiàn)了并發(fā)用戶數(shù)（Number of Concurrent Users）的不斷增長。

l  在這張圖中我們可以看到，最開始，隨著并發(fā)用戶數(shù)的增長，資源占用率和吞吐量會相應(yīng)的增長，但是響應(yīng)時(shí)間的變化不大；不過當(dāng)并發(fā)用戶數(shù)增長到一定程度后，資源占用達(dá)到飽和，吞吐量增長明顯放緩甚至停止增長，而響應(yīng)時(shí)間卻進(jìn)一步延長。如果并發(fā)用戶數(shù)繼續(xù)增長，你會發(fā)現(xiàn)軟硬件資源占用繼續(xù)維持在飽和狀態(tài)，但是吞吐量開始下降，響應(yīng)時(shí)間明顯的超出了用戶可接受的范圍，并且最終導(dǎo)致用戶放棄了這次請求甚至離開。

l  根據(jù)這種性能表現(xiàn)，圖中劃分了三個(gè)區(qū)域，分別是Light Load（較輕的壓力）、Heavy Load（較重的壓力）和Buckle Zone（用戶無法忍受并放棄請求）。在Light Load和Heavy Load 兩個(gè)區(qū)域交界處的并發(fā)用戶數(shù)，我們稱為“最佳并發(fā)用戶數(shù)（The Optimum Number of Concurrent Users）”，而Heavy Load和Buckle Zone兩個(gè)區(qū)域交界處的并發(fā)用戶數(shù)則稱為“最大并發(fā)用戶數(shù)（The Maximum Number of Concurrent Users）”。

l  當(dāng)系統(tǒng)的負(fù)載等于最佳并發(fā)用戶數(shù)時(shí)，系統(tǒng)的整體效率最高，沒有資源被浪費(fèi)，用戶也不需要等待；當(dāng)系統(tǒng)負(fù)載處于最佳并發(fā)用戶數(shù)和最大并發(fā)用戶數(shù)之間時(shí)，系統(tǒng)可以繼續(xù)工作，但是用戶的等待時(shí)間延長，滿意度開始降低，并且如果負(fù)載一直持續(xù)，將最終會導(dǎo)致有些用戶無法忍受而放棄；而當(dāng)系統(tǒng)負(fù)載大于最大并發(fā)用戶數(shù)時(shí)，將注定會導(dǎo)致某些用戶無法忍受超長的響應(yīng)時(shí)間而放棄。

l  對應(yīng)到我們上面理發(fā)店的例子，每小時(shí)3個(gè)顧客就是這個(gè)理發(fā)店的最佳并發(fā)用戶數(shù)，而每小時(shí)9個(gè)顧客則是它的最大并發(fā)用戶數(shù)。當(dāng)每小時(shí)都有3個(gè)顧客到來時(shí)，理發(fā)店的整體工作效率最高；而當(dāng)每小時(shí)都有9個(gè)顧客到來時(shí)，前幾個(gè)小時(shí)來的顧客還可以忍受，但是隨著等待的顧客人數(shù)越來越多，等待時(shí)間越來越長，最終還是會有顧客無法忍受而離開。同時(shí)，隨著理發(fā)店里顧客人數(shù)的增多和理發(fā)師工作時(shí)間的延長，理發(fā)師會逐漸產(chǎn)生疲勞，還要多花一些時(shí)間來清理環(huán)境和維持秩序，這些因素將最終導(dǎo)致理發(fā)師的工作效率隨著顧客人數(shù)的增多和工作的延長而逐漸的下降，到最后可能要1.5小時(shí)甚至2個(gè)小時(shí)才能剪完1個(gè)發(fā)了。

l  當(dāng)然，如果一開始就有10個(gè)顧客到來，則注定有1位顧客剪不到頭發(fā)了。

 

l  進(jìn)一步理解“最佳并發(fā)用戶數(shù)”和“最大并發(fā)用戶數(shù)”

l  在上一節(jié)中，我們詳細(xì)的描述了并發(fā)用戶數(shù)同資源占用情況、吞吐量以及響應(yīng)時(shí)間的關(guān)系，并且提到了兩個(gè)新的概念——“最佳并發(fā)用戶數(shù)（The Optimum Number of Concurrent Users）”和“最大并發(fā)用戶數(shù)（The Maximum Number of Concurrent Users）”。在這一節(jié)中，我們將對“最佳并發(fā)用戶數(shù)”和“最大并發(fā)用戶數(shù)”的定義做更加清晰和明確的說明。

l  對于一個(gè)確定的被測系統(tǒng)來說，在某個(gè)具體的軟硬件環(huán)境下，它的“最佳并發(fā)用戶數(shù)”和“最大并發(fā)用戶數(shù)”都是客觀存在。以“最佳并發(fā)用戶數(shù)”為例，假如一個(gè)系統(tǒng)的最佳并發(fā)用戶數(shù)是50，那么一旦并發(fā)量超過這個(gè)值，系統(tǒng)的吞吐量和響應(yīng)時(shí)間必然會 “此消彼長”；如果系統(tǒng)負(fù)載長期大于這個(gè)數(shù)，必然會導(dǎo)致用戶的滿意度降低并最終達(dá)到一種無法忍受的地步。所以我們應(yīng)該 保證最佳并發(fā)用戶數(shù)要大于系統(tǒng)的平均負(fù)載。

l  要補(bǔ)充的一點(diǎn)是，當(dāng)我們需要對一個(gè)系統(tǒng)長時(shí)間施加壓力——例如連續(xù)加壓3-5天，來驗(yàn)證系統(tǒng)的可靠性或者說穩(wěn)定性時(shí)，我們所使用的并發(fā)用戶數(shù)應(yīng)該等于或小于“最佳并發(fā)用戶數(shù)”——大家也可以結(jié)合上面的討論想想這是為什么 ^_^

l  而對于最大并發(fā)用戶數(shù)的識別，需要考慮和鑒別一下以下兩種情況：

l  1.              當(dāng)系統(tǒng)的負(fù)載達(dá)到最大并發(fā)用戶數(shù)后，響應(yīng)時(shí)間超過了用戶可以忍受的最大限度——這個(gè)限度應(yīng)該來源于性能需求，例如：在某個(gè)級別的負(fù)載下，系統(tǒng)的響應(yīng)時(shí)間應(yīng)該小于5秒。這里容易疏忽的一點(diǎn)是，不要把顧客因?yàn)闊o法忍受而離開時(shí)店內(nèi)的顧客數(shù)量作為理發(fā)店的“最大并發(fā)用戶數(shù)”，因?yàn)檫@位顧客是在3小時(shí)前到達(dá)的，也就是說3小時(shí)前理發(fā)店內(nèi)的顧客數(shù)量才是我們要找的“最大并發(fā)用戶數(shù)”。而且，這位顧客的離開只是一個(gè)開始，可能有會更多的顧客隨后也因?yàn)闊o法忍受超長的等待時(shí)間而離開；

l  2.             在響應(yīng)時(shí)間還沒有到達(dá)用戶可忍受的最大限度前，有可能已經(jīng)出現(xiàn)了用戶請求的失敗。以理發(fā)店模型為例，如果理發(fā)店只能容納6位顧客，那么當(dāng)7位顧客同時(shí)來到理發(fā)店時(shí)，雖然我們可以知道所有顧客都能在可容忍的時(shí)間內(nèi)剪完頭發(fā)，但是因?yàn)槔戆l(fā)店容量有限，最終只好有一位顧客打道回府，改天再來。

l  對于一個(gè)系統(tǒng)來說，我們應(yīng)該 確保系統(tǒng)的最大并發(fā)用戶數(shù)要大于系統(tǒng)需要承受的峰值負(fù)載。

l  如果你已經(jīng)理解了上面提到的全部的概念，我想你可以展開進(jìn)一步的思考，回頭看一下自己以往做過的性能測試，看看是否可以對以往的工作產(chǎn)生新的理解。也歡迎大家在這里提出自己的心得或疑惑，繼續(xù)討論下去。

l  理發(fā)店模型的進(jìn)一步擴(kuò)展

l  這一節(jié)中我會提到一些對理發(fā)店模型的擴(kuò)展，當(dāng)然，我依然是只講述現(xiàn)實(shí)中的理發(fā)店的故事，至于如何將這些擴(kuò)展同性能測試以及性能解決方案等方面關(guān)聯(lián)起來，就留給大家繼續(xù)思考了 ^_^

l  擴(kuò)展場景1：有些顧客已經(jīng)是理發(fā)店的老顧客，他們和理發(fā)師已經(jīng)非常熟悉，理發(fā)師可以不用花費(fèi)太多時(shí)間溝通就知道這位顧客的想法。并且理發(fā)師對這位顧客的腦袋的形狀也很熟悉，所以可以更快的完成一次理發(fā)的工作。

l  擴(kuò)展場景2：理發(fā)店并不是只有剪發(fā)一種業(yè)務(wù)，還提供了燙發(fā)染發(fā)之類的業(yè)務(wù)，那么當(dāng)顧客提出新的要求時(shí)，理發(fā)師服務(wù)一位顧客的時(shí)間可能會超過標(biāo)準(zhǔn)的1小時(shí)。而且這時(shí)如果要計(jì)算每位顧客的等待時(shí)間就變得復(fù)雜了很多，有些顧客的排隊(duì)時(shí)間會比原來預(yù)計(jì)的延長，并最終導(dǎo)致他們因?yàn)闊o法忍受而離開。

l  擴(kuò)展場景3：隨著燙發(fā)和染發(fā)業(yè)務(wù)的增加，理發(fā)師們決定分工，兩位專門剪發(fā)，一位專門負(fù)責(zé)燙發(fā)和染發(fā)。

l  擴(kuò)展場景4：理發(fā)店的生意越來越好，理發(fā)師的數(shù)量和理發(fā)店的門面已經(jīng)無法滿足顧客的要求，于是理發(fā)店的老板決定在旁邊再開一家店，并招聘一些工作能力更強(qiáng)的理發(fā)師。

l  擴(kuò)展場景5：理發(fā)店的生意變得極為火爆了，兩家店都無法滿足顧客數(shù)量增長的需求，并且有些顧客開始反映到理發(fā)店的路途太遠(yuǎn)，到了以后又因?yàn)闋C發(fā)和染發(fā)的人太多而等太久。可是理發(fā)店的老板也明白燙發(fā)和染發(fā)的收入要遠(yuǎn)遠(yuǎn)高于剪發(fā)阿，于是他腦筋一轉(zhuǎn)，決定繼續(xù)改變策略，在附近的幾個(gè)大型小區(qū)租用小的鋪面開設(shè)分店，專職剪發(fā)業(yè)務(wù)；再在市區(qū)的繁華路段開設(shè)旗艦店，專門為燙發(fā)、染發(fā)的顧客，以及VIP顧客服務(wù)。并增設(shè)800電話，當(dāng)顧客想要剪發(fā)時(shí)，可以撥打這個(gè)電話，并由服務(wù)人員根據(jù)顧客的居住地點(diǎn)，將其指引到距離最近的一家分店去。

l  這篇文章就先寫到這里了，希望大家在看完之后可以繼續(xù)思考一下，也寫出自己的心得體會或者新的想法，記下自己的不解和疑惑，讓我們在不斷的交流和討論中走的更遠(yuǎn) ^_^

5.        《LoadRunner 沒有告訴你的》之四——理解性能

l     如何評價(jià)性能的優(yōu)劣: 用戶視角 vs. 系統(tǒng)視角

l  對于最終用戶(End-User)來說，評價(jià)系統(tǒng)的性能好壞只有一個(gè)字——“快”。最終用戶并不需要關(guān)心系統(tǒng)當(dāng)前的狀態(tài)——即使系統(tǒng)這時(shí)正在處理著成千上萬的請求，對于用戶來說，由他所發(fā)出的這個(gè)請求是他唯一需要關(guān)心的，系統(tǒng)對用戶請求的響應(yīng)速度決定了用戶對系統(tǒng)性能的評價(jià)。

l  而對于系統(tǒng)的運(yùn)營商和開發(fā)商來說，期望的是能夠讓盡可能多的用戶在任意時(shí)刻都擁有最好的體驗(yàn)，這就要確保系統(tǒng)能夠在同一時(shí)間內(nèi)處理更多的用戶請求。正如在《理發(fā)店模型》一文中所描述的：系統(tǒng)的負(fù)載（并發(fā)用戶數(shù)）與吞吐量（每秒事務(wù)數(shù)）、響應(yīng)時(shí)間以及資源利用率（包括軟硬件資源）之間存在著一個(gè)“此消彼長”的關(guān)系。因此，從系統(tǒng)的運(yùn)營商和開發(fā)商的角度來看，所謂的“性能”是一個(gè)整體的概念，是系統(tǒng)的負(fù)載與吞吐量、可接受的響應(yīng)時(shí)間以及資源利用率之間的平衡。

l  換句話說，“好的性能”意味著更大的最佳并發(fā)用戶數(shù)（The Optimum Number of Concurrent Users）和 最大并發(fā)用戶數(shù)（The Maximum Number of Concurrent Users）。有關(guān)“最佳/最大并發(fā)用戶數(shù)”的概念請參見《理發(fā)店模型》一文。

l  另外，從系統(tǒng)的視角來看，所需要關(guān)注的還包括三個(gè)與“性能”有關(guān)的屬性：可靠性（Reliability），可伸縮性（Scalability）和 可恢復(fù)性（Recoverability）——我將會在本系列文章的第五篇“無處不在的性能測試”中專門討論這三個(gè)屬性的含義和相關(guān)的實(shí)踐經(jīng)驗(yàn)。

l  響應(yīng)時(shí)間

l 

l  上面這張圖引自段念兄的一份講義，不過我略作了些修改。從圖中我們可以清楚的看到一個(gè)請求的響應(yīng)時(shí)間是由幾部分時(shí)間組成的，包括

l  C1：用戶請求發(fā)出前在客戶端需要完成的預(yù)處理所需要的時(shí)間；

l  C2：客戶端收到服務(wù)器返回的響應(yīng)后，對數(shù)據(jù)進(jìn)行處理并呈現(xiàn)所需要的時(shí)間；

l  A1：Web/App Server 對請求進(jìn)行處理所需要的時(shí)間；

l  A2：DB Server 對請求進(jìn)行處理所需的時(shí)間；

l  A3：Web/App Server 對 DB Server 返回的結(jié)果進(jìn)行處理所需的時(shí)間；

l  N1：請求由客戶端發(fā)出并達(dá)到Web/App Server 所需要的時(shí)間；

l  N2：如果需要進(jìn)行數(shù)據(jù)庫相關(guān)的操作，由Web/App Server 將請求發(fā)送至DB Server 所需要的時(shí)間；

l  N3：DB Server 完成處理并將結(jié)果返回Web/App Server 所需的時(shí)間；

l  N4：Web/App Server 完成處理并將結(jié)果返回給客戶端所需的時(shí)間；

l  從用戶的角度來看，響應(yīng)時(shí)間＝(C1+C2)+(A1+A2+A3)+(N1+N2+N3+N4)；但是從系統(tǒng)的角度來看，響應(yīng)時(shí)間只包括(A1+A2+A3)+(N1+N2+N3+N4)。

l  在理解了響應(yīng)時(shí)間的組成之后，可以幫助我們通過對響應(yīng)時(shí)間的分析來更好的識別和定位系統(tǒng)的性能瓶頸。

l   

l  吞吐量 vs. 吞吐量

l  在不同的測試工具中，對于吞吐量(Throughput)會有不同的解釋。例如，在LoadRunner中，這個(gè)指標(biāo)是以字節(jié)數(shù)為單位來衡量網(wǎng)絡(luò)吞吐量的，而在JMeter中則是以事務(wù)數(shù)/秒為單位來衡量系統(tǒng)的響應(yīng)能力的。不過在大多數(shù)英文的性能測試方面的書籍或資料中，吞吐量的定義使用的是后者。

l   

l  并發(fā)用戶數(shù) ≠ 每秒請求數(shù)

l  這是兩個(gè)容易讓初學(xué)者混淆的概念。

l  簡單說，當(dāng)你在性能測試工具或者腳本中設(shè)置了100并發(fā)用戶數(shù)后，并不能期望著一定會有每秒100個(gè)請求發(fā)給服務(wù)器。事實(shí)上，對于一個(gè)虛擬用戶來說，每秒發(fā)出多少請求只跟服務(wù)器返回響應(yīng)的速度有關(guān)。如果虛擬用戶在0.5秒內(nèi)就收到了響應(yīng)，那么它會立即發(fā)出第二個(gè)請求；而如果要一直等待3秒才能得到響應(yīng)，它將會一直等到收到響應(yīng)后才發(fā)出第二個(gè)請求。也就是說，并發(fā)用戶數(shù)的設(shè)置只是保證服務(wù)器在任一時(shí)刻都有100個(gè)請求需要處理，而并不一定是保證每秒中發(fā)送100個(gè)請求給服務(wù)器。

l  所以，只有當(dāng)響應(yīng)時(shí)間恰好是1秒時(shí)，并發(fā)用戶數(shù)才會等于每秒請求數(shù)；否則，每秒請求數(shù)可能大于并發(fā)用戶數(shù)或小于并發(fā)用戶數(shù)。

l   

6.        《LoadRunner 沒有告訴你的》之五——無所不在的性能測試

l  需求階段

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

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

l   

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

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

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

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

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

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

l   

l  編碼階段

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

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

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

l   

l  測試階段

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

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

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

l   

l  維護(hù)階段

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

l   

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

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

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

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

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

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

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

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

l   

l  當(dāng)然，這一切的前提是在系統(tǒng)負(fù)載達(dá)到峰值前，Server一直在頑強(qiáng)的掙扎著而沒有down掉 ^_^

l 

l  性能測試，并非網(wǎng)絡(luò)應(yīng)用專屬

l  軟件的性能和性能測試都是伴隨著網(wǎng)絡(luò)應(yīng)用的興起而逐漸被重視起來的，但是軟件性能和性能測試卻并非網(wǎng)絡(luò)應(yīng)用的專屬名詞，因?yàn)閱螜C(jī)版的應(yīng)用同樣需要考慮性能問題。下面舉幾個(gè)簡單的例子來方便大家的理解：

l  1.               當(dāng)使用Word來編輯一個(gè)500多頁，并包含了豐富圖表、圖片和各種格式、樣式信息的文檔時(shí)，是否每次對大段的文字或表格的修改、刪除或重新排版，都要等待系統(tǒng)花幾秒鐘的時(shí)間進(jìn)行處理？

l  2.              當(dāng)在Excel中使用嵌套的統(tǒng)計(jì)和數(shù)學(xué)函數(shù)對幾萬行記錄進(jìn)行統(tǒng)計(jì)分析時(shí)，是否每次都要兩三分鐘才能看到結(jié)果？

l  3.              殺毒軟件是否每次都要花費(fèi)兩個(gè)小時(shí)才能完成一次對所有的分區(qū)的掃描？

l  4.              是否每次在手機(jī)的通訊簿中根據(jù)姓名搜索某個(gè)人的聯(lián)系方式都要三四秒鐘才有響應(yīng)？

l  如果大家有興趣，也可以通過Google搜索到更多的有關(guān)單機(jī)應(yīng)用性能測試的資料。

7.        《LoadRunner沒有告訴你的》之六——獲取有效的性能需求

l         一個(gè)實(shí)際的例子

l  為了便于大家的理解，我們先來看一個(gè)性能需求的例子，讓大家有一個(gè)感性的認(rèn)識，本文后面的討論也會再次提到這個(gè)例子。

l  這是一個(gè)證券行業(yè)系統(tǒng)中某個(gè)業(yè)務(wù)的“實(shí)際需求”——實(shí)際上是我根據(jù)通過網(wǎng)絡(luò)搜集到的數(shù)據(jù)杜撰出來的，不過看起來像是真實(shí)的 ^_^

l  l         系統(tǒng)總?cè)萘窟_(dá)到日委托6000萬筆，成交9000萬筆

l  l         系統(tǒng)處理速度每秒7300筆，峰值處理能力達(dá)到每秒10000筆

l  l         實(shí)際股東帳號數(shù)3000萬

l  這個(gè)例子中已經(jīng)包括幾個(gè)明確的需求：

l  l         最佳并發(fā)用戶數(shù)需求：每秒7300筆

l  l         最大并發(fā)用戶數(shù)需求：峰值處理能力達(dá)到每秒10000筆

l  l         基礎(chǔ)數(shù)據(jù)容量：實(shí)際股東帳號數(shù)3000萬

l  l         業(yè)務(wù)數(shù)據(jù)容量：日委托6000萬筆，成交9000萬筆——可以根據(jù)這個(gè)推算出每周、每月、每年系統(tǒng)容量的增長模型

l  什么是“有效的”性能需求？

l  要想獲得有效的性能需求，就要先了解什么樣的需求是“有效的”。有效的性能需求應(yīng)該符合以下三個(gè)條件。

l  1.     明確的數(shù)字，而不是模糊的語句。

l  結(jié)合上面的例子來看，相信這個(gè)應(yīng)該不難理解。但是有的時(shí)候有了數(shù)字未必就不模糊。例如常見的一種需求是“系統(tǒng)需要支持5000用戶”，或者“最大在線用戶數(shù)為8000”。這些有數(shù)字的需求仍然不夠明確，因?yàn)檫€需要考慮區(qū)分系統(tǒng)中不同業(yè)務(wù)模塊的負(fù)載，以及區(qū)分在線用戶和并發(fā)用戶的區(qū)別。關(guān)于這方面的內(nèi)容，在下面兩篇文章中的留言內(nèi)容中有精彩的討論：

l  http://www.cnblogs.com/jackei/archive/2006/11/15/560578.html

l  http://www.cnblogs.com/jackei/archive/2006/11/16/561846.html

l  2.     有憑有據(jù)，合理，有實(shí)際意義。

l  通常來說，性能需求要么由客戶提出，要么由開發(fā)方提出。對于第一種情況，要保證需求是合理的，有現(xiàn)實(shí)意義的，不能由著客戶使勁往高處說，要讓客戶明白性能是有成本的。對于第二種情況，性能需求不能簡單的來源于項(xiàng)目組成員、PM或者測試工程師的估計(jì)或者猜測，要保證性能需求的提出是有根據(jù)的，所使用的數(shù)據(jù)和計(jì)算公式是有出處的——本文后面的部分會介紹獲得可用的數(shù)據(jù)和計(jì)算公式的方法。

l  3.     相關(guān)人員達(dá)成一致。

l  這一點(diǎn)非常關(guān)鍵。如果相關(guān)人不能對性能需求達(dá)成一致，可能測了也白測——特別是在客戶沒有提出明確的性能需求而由開發(fā)方提出時(shí)。這里要注意“相關(guān)人員”的識別，通常項(xiàng)目型的項(xiàng)目的需要與客戶方的項(xiàng)目經(jīng)理或負(fù)責(zé)人進(jìn)行確認(rèn)，產(chǎn)品型的項(xiàng)目需要與直屬領(lǐng)導(dǎo)或者市場部進(jìn)行確認(rèn)。如果實(shí)在不知道該找誰確認(rèn)，那就把這個(gè)責(zé)任交給你的直屬領(lǐng)導(dǎo)；如果你就是領(lǐng)導(dǎo)了，那這領(lǐng)導(dǎo)也白當(dāng)了 ^_^

l   

l  如何獲得有效的性能需求

l  上面提到了“有效的”性能需求的一個(gè)例子和三個(gè)條件，下面來我們將看到有哪些途徑可以幫助我們獲得相關(guān)的數(shù)據(jù)——這些方法我在實(shí)際的工作中都用過，并且已經(jīng)被證實(shí)是可行的。這幾種方法由易到難排列如下：

l  1.       客戶方提出

l  這是最理想的一種方式，通常電信、金融、保險(xiǎn)、證券以及一些其他運(yùn)營商級系統(tǒng)的客戶——特別是國外的客戶都會提出比較明確的性能需求。

l  2.       根據(jù)歷史數(shù)據(jù)來分析

l  根據(jù)客戶以往的業(yè)務(wù)情況來分析客戶的業(yè)務(wù)量以及每年、每月、每周、每天的峰值業(yè)務(wù)量。如果客戶有舊的系統(tǒng)，可以根據(jù)已有系統(tǒng)的訪問日志，數(shù)據(jù)庫記錄，業(yè)務(wù)報(bào)表來分析。要特別注意的是，不同行業(yè)、不同應(yīng)用、不同的業(yè)務(wù)是有各自的特點(diǎn)的。例如，購物網(wǎng)站在平時(shí)的負(fù)載主要集中在晚上，但是節(jié)假日時(shí)訪問量和交易量會是平時(shí)的數(shù)倍；而地鐵的售票系統(tǒng)面臨的高峰除了周末，還有周一到周五的一早一晚上下班時(shí)間。

l  3.       參考?xì)v史項(xiàng)目的數(shù)據(jù)

l  如果該產(chǎn)品已有其他客戶使用，并且規(guī)模類似的，可以參考其他客戶的需求。例如在線購物網(wǎng)站，或者超市管理系統(tǒng)，各行業(yè)的進(jìn)銷存系統(tǒng)。

l  4.       參考其他同行類似項(xiàng)目的數(shù)據(jù)

l  如果本企業(yè)沒有做過類似的項(xiàng)目，那么可以參考其他同行企業(yè)的公布出來的數(shù)據(jù)——通常在企業(yè)公布的新聞或者成功解決方案中會提到，包括系統(tǒng)容量，系統(tǒng)所能承受的負(fù)載以及系統(tǒng)響應(yīng)能力等。

l  5.       參考其他類似行業(yè)應(yīng)用的數(shù)據(jù)

l  如果無法找打其他同行的數(shù)據(jù)，也可以參考類似的應(yīng)用的需求。例如做IPTV或者DVB計(jì)費(fèi)系統(tǒng)的測試，可以參考電信計(jì)費(fèi)系統(tǒng)的需求——雖然不能完全照搬數(shù)據(jù)，但是可以通過其他行業(yè)成熟的需求來了解需要測試的項(xiàng)目有哪些，應(yīng)該考慮到的情況有哪些種。

l  6.       參考新聞或其他資料中的數(shù)據(jù)

l  最后的一招，特別是對于一些當(dāng)前比較引人關(guān)注的行業(yè)，涉及到所謂的“政績”的行業(yè)，通常可以通過各種新聞媒體找到一些可供參考的數(shù)據(jù)，但是需要耐心的尋找。例如我們在IPTV和DVB系統(tǒng)的測試中，可以根據(jù)新聞中公布的各省、各市，以及國外各大運(yùn)營商的用戶發(fā)展情況和用戶使用習(xí)慣來估算系統(tǒng)容量和系統(tǒng)各個(gè)模塊的并發(fā)量。

l  又一塊磚拋出來了，希望大家在看完之后也有更多的玉丟過來 ^_^

8.        《LoadRunner沒有告訴你的》之七——使用 LoadRunner 連續(xù)長時(shí)間執(zhí)行測試，如何保證參數(shù)化的數(shù)據(jù)足夠又不會重復(fù)？

l  有朋友開始投訴了，說我已經(jīng)好長一段時(shí)間沒有寫技術(shù)類文章了。汗顏，積極改進(jìn)。剛好今天在群里有同行遇到一個(gè)關(guān)于 LR 參數(shù)化的問題，其實(shí)這個(gè)問題以前也遇到過，所以就順便把我的想法整理一下發(fā)上來。

l  當(dāng)時(shí)我們要做的是使用性能測試工具模擬大量用戶在線點(diǎn)播 Movie 的業(yè)務(wù)，這個(gè)點(diǎn)播 Movie 的業(yè)務(wù)在第一次點(diǎn)播成功后，如果同一用戶再次點(diǎn)播同一 Movie，系統(tǒng)的處理流程與第一次點(diǎn)播是不同的。另外，我們在執(zhí)行測試時(shí)，通常都會連續(xù)執(zhí)行幾個(gè)小時(shí)以獲得盡可能多的樣本數(shù)據(jù)。

l  那么問題就在于，一方面我們不能在一次測試中重復(fù)的讀取同樣的數(shù)據(jù)，另一方面準(zhǔn)備幾十萬甚至上百萬的數(shù)據(jù)工作量也太大，而且還涉及到相關(guān)的基礎(chǔ)數(shù)據(jù)的準(zhǔn)備。那么，我們該如何在使用 LoadRunner 連續(xù)長時(shí)間執(zhí)行測試，保證參數(shù)化的數(shù)據(jù)充足而又不會重復(fù)呢？

l  其實(shí)方法很簡單。無論上 LR 還是 JMeter，都提供了將多個(gè)參數(shù)的取值存放在同一個(gè)文件中，或者每個(gè)參數(shù)單獨(dú)指定一個(gè)文件的功能，針對上面這個(gè)例子，我們只是簡單的創(chuàng)建了兩個(gè)文件和三個(gè)參數(shù)，第一個(gè)參數(shù)和第二個(gè)參數(shù)（用戶賬號和密碼）存放在第一個(gè)文件中，有1000條記錄；第三個(gè)參數(shù)（Movie 的 ID）存放在第二個(gè)文件中，有999條記錄。然后在測試工具中設(shè)置參數(shù)取值的讀取為順序讀取并且循環(huán)讀取。通過這種簡單的方法組合出了大量的數(shù)據(jù)。

l  問題被解決了。

9.        LoadRunner之--Think Time

l  “Think Time”顧名思義－思考時(shí)間。它效仿真實(shí)用戶在實(shí)際操作過程中的等待時(shí)間。也就是說，實(shí)際用戶在瀏覽網(wǎng)頁，操作B/S系統(tǒng)的時(shí)候，不可能像機(jī)器一樣不停的點(diǎn)啊點(diǎn)，在操作和操作之間會有一定的間隔。如：你瀏覽網(wǎng)頁，打開一個(gè)或幾個(gè)網(wǎng)頁后，你會閱讀，讀過之后才會繼續(xù)打開新網(wǎng)頁。你閱讀時(shí)所消耗的時(shí)間就是Think Time。對于服務(wù)器來說，這段時(shí)間是沒有壓力的。

l  我們做性能測試，很多時(shí)候就要模擬這種狀態(tài)。例如：某系統(tǒng)，要求滿足100用戶同時(shí)在線操作，響應(yīng)時(shí)間在5秒。如果不設(shè)置Think Time，我覺得，你的測試是失敗的。大家想想為什么？答案將在文章的結(jié)尾揭曉。

l  下面我來講解一下LR中Think Time的設(shè)置。

l  設(shè)置Think Time有兩種方式，一種是使用Record think time在錄制過程中根據(jù)實(shí)際等待時(shí)間自動的寫入腳本。另一種是在腳本錄制結(jié)束后手動加入到腳本中。接下來我們詳細(xì)介紹。

l  自動：

l  位置及操作：Recording　Option－Advanced：勾上Record think time，這樣在你錄制的時(shí)候，Think Time就會自動添加入你的腳本。需要注意的是，后面還有一項(xiàng)Think time threshold，它的作用是定義你所要錄制的Think Time的最小時(shí)間。舉個(gè)例子，如果你把這個(gè)值設(shè)置為5秒，那么如果錄制過程中等待的時(shí)間小于５秒，那么就不會在腳本中記錄這個(gè)Think Time。

l  手動：

l  位置及操作：腳本中任何你想要插入的地方。注意，不要將Think Time插入到你定義的事務(wù)當(dāng)中，否則，測出的事務(wù)時(shí)間需要減去Think Time的時(shí)間呦。操作：在你想要插入Think Time的地方，右鍵，Insert－New Step在Time To Think （） second在空中填寫你為想要設(shè)置的時(shí)間。也可以在腳本中直接寫函數(shù)lr_think_time();

l  添加好后，我們在Run-time Settings中設(shè)置執(zhí)行的策略。

l  位置：Run-time Settings－Think Time。進(jìn)入后，我們會看到兩個(gè)選項(xiàng)。Ignore think time：忽略think time，也就是即使你添加了think time，腳本執(zhí)行的時(shí)候也不會理睬，忽略不執(zhí)行。Replay the think time：下面還有３個(gè)子項(xiàng)。As recorded：按照錄制的執(zhí)行。不用多說。Multiply recorded think time by：這就是我錄制的think time乘一個(gè)系數(shù)。如，你錄制的think time是4秒，在這里設(shè)置2，最后執(zhí)行時(shí)就會按4秒×2＝８秒來執(zhí)行。如果你想要執(zhí)行２秒，就在這里填0.5。Use random percentage of the recorded think time：這里隨機(jī)設(shè)置一個(gè)百分比，并規(guī)定上下限。如，錄制的think time為4秒。Min為50％，Max為200％。那么執(zhí)行的時(shí)候它就會從2秒到8秒內(nèi)隨機(jī)取一個(gè)數(shù)來執(zhí)行。Limit think time to：為think time設(shè)置一個(gè)上限，不管上面的如何設(shè)置，執(zhí)行的時(shí)候，取值都不會操過這個(gè)上限。

l  講到這里，think time的設(shè)置大家應(yīng)該很明白了。不知道讓大家思考的問題是否想通了。需求說的是100用戶同時(shí)在線操作，注意，是在線！大家想想，100人在線肯定有人在操作，也有人只是在線，沒有對服務(wù)器發(fā)出任何請求。如果不設(shè)置think time，相當(dāng)于100人并發(fā)操作，每個(gè)人都不停的向服務(wù)器發(fā)送請求，這比需求的壓力可是大很多的呦～

10.    LoadRunner之--關(guān)聯(lián)（correlation）

l  所謂的關(guān)聯(lián)（correlation）就是把腳本中某些寫死的（hard-coded）資料，轉(zhuǎn)變成是摘取自服務(wù)器所送的、動態(tài)的、每次都不一樣的資料。舉一個(gè)常見的例子，剛剛提到有些比較聰明的服務(wù)器，這些服務(wù)器在每個(gè)瀏覽器第一次跟它要資料時(shí)，都會在資料中夾帶一個(gè)唯一的辨識碼，接下來就會利用這個(gè)辨識碼來辨識跟它要資料的是不是同一個(gè)瀏覽器。一般稱這個(gè)辨識碼為Session ID。對于每個(gè)新的交易，服務(wù)器都會產(chǎn)生新的Session ID給瀏覽器。這也就是為什么執(zhí)行腳本會失敗的原因，因?yàn)?/span>VuGen還是用舊的Session ID向服務(wù)器要資料，服務(wù)器會發(fā)現(xiàn)這個(gè)Session ID是失效的或是它根本不認(rèn)識這個(gè)Session ID，當(dāng)然就不會傳送正確的網(wǎng)頁資料給VuGen了。

l  當(dāng)錄制腳本時(shí)，瀏覽器送出網(wǎng)頁A的請求，服務(wù)器將網(wǎng)頁A的內(nèi)容傳送給瀏覽器，并且夾帶了一個(gè)ID=123的資料，當(dāng)瀏覽器再送出網(wǎng)頁B的情求時(shí)，這時(shí)就要用到ID=123的資料，服務(wù)器才會認(rèn)為這是合法的請求，并且把網(wǎng)頁B的內(nèi)容送回給瀏覽器。

l  在執(zhí)行腳本時(shí)會發(fā)生什么狀況？瀏覽器再送出網(wǎng)頁B的請求時(shí)，用的還是當(dāng)初錄制的ID=123的資料，而不是用服務(wù)器新給的ID=456，整個(gè)腳本的執(zhí)行就會失敗。要對付這種服務(wù)器，我們必須想辦法找出這個(gè)Session ID到底是什么、位于何處，然后把它摘取下來，放到某個(gè)參數(shù)中，并且取代掉腳本中有用到Session ID的部份，這樣就可以成功騙過服務(wù)器，正確地完成整個(gè)交易了。

天貓 軟件自動化測試開發(fā)