GO ON。。。


酒是一樣的，可是喝酒的人是不同的。
你越喝臉越紅，這叫頻繁分配釋放資源。
你越喝臉越白，這叫資源不釋放。
你已經醉了，卻說我還能喝，叫做資源額度不足。
你明明能喝，卻說我已經醉了，叫做資源保留。
你喝一段時間就上廁所，這叫cache。

酒過三巡，你也該活動活動了。
你一桌一桌的走，這叫輪巡。
你突然看到某一桌的漂亮mm，走了過去，這叫優先級。
你去了坐下來就不打算走了，這叫死循環。
你的老大舉杯邀你過去，你只好過去，這叫激活事件。
你向一桌敬酒，他們說不行不行我們都喝白的，于是你也喝白的，這叫本地化。
你向boss敬酒，可是boss被圍了起來，你只能站在外圈，這叫排隊。
你終于到了內圈，小心翼翼的向前一步，這叫訪問臨界區。
你拍著boss的肩膀說哥們咱們喝一杯，這叫越界。
你不知喝了幾圈了，只會說兩個字，干了，這叫udp。
可是還有人拿著酒瓶跑過來說，剛才都沒跟你喝，這叫丟包。

喝酒喝到最后的結果都一樣

你突然跑向廁所，這叫捕獲異常。
你在廁所吐了，反而覺得狀態不錯，這叫清空內存。
你在臺面上吐了，覺得很慚愧，這叫程序異常。
你在boss面前吐了，覺得很害怕，這叫系統崩潰。
你吐到了boss身上，只能索性暈倒了，這叫硬件休克 。

繼續：

菜過三巡，你就不跟他們客氣了。
你向對面的人敬酒，這叫p2p.
你向對面的人敬酒，他回敬你，你又再敬他……，這叫tcp.
你向一桌人挨個敬酒，這叫令牌環。
你說只要是兄弟就干了這杯，這叫廣播。
可是你的上司jj聽了不高興了，只有兄弟么，罰酒三杯。這叫炸彈。
可是你的下級mm聽了不高興了，我喝一口，你喝一杯，這叫惡意攻擊。
有一個人過來向這桌敬酒，你說不行你先過了我這關，這叫防火墻。
你的小弟們過來敬你酒，這叫一對多。
你是boss，所有人過來敬你酒，這叫服務器。

再補充一個：

自己吹瓶 叫 單交易負載測試
被別人敬酒 叫 壓力測試
喝了一個晚上 叫 穩定性壓力測試
喝得臉不改色：還有上升空間，繼續實施壓力
喝到暈：資源已經接近瓶頸點
喝到吐：資源已經出現瓶頸
喝到不省人事:機器被壓宕機
喝到隔屁:機器被壓死機

我的LR是8.0。
在錄制的過程中就同時生成腳本了，可以切換回腳本的窗口的。
8.1不知道是否還是同樣，我的8.0是這樣的。

@tester
能否更詳細說一下，如何通過檢查VUser來處理實際處理能力？

@cc
從你描述的情況看，我想很可能是JBOSS的連接數問題。
這里指的一個請求是指客戶端和服務器的一次交互（或者連接）。
服務器的響應是處理完請求的響應。

呵呵，我的文章被四處copy了嗎？
好早的時候寫的了。
現在好象HP已經放棄對winrunner的支持了，全力發展QTP。。
以后沒有必要對這二者再做比較了，嘿嘿。。。

thinktime是指在測試的過程中，每一步操作中間的思考時間（停頓）。
pacing是指在測試過程中，每兩次迭代（或稱循環）間的停頓。

取最大的訪問量的80%（根據“二八原則”）。

@ppent

我沒有用過你說的這個函數，所以不確定是不是可以在非http協議腳本使用，有機會可以在QQ或MSN上和我討論一下。

滾！
這個是因為本身比較簡單！
^_^

樓上的，“蒙事”是什么意思？

是啊，當時我也寫了一點，但是不夠詳細，那天又遇到這個問題，看了自己以前寫的，還是不懂，所以這次就寫得更詳細些。

@mxlly

我這篇文章沒有提高QTP，貶低Winrunner的意思。
這二者應該是各有優缺點，只要能熟練掌握其中的一種，是可以較好地實現自動化測試的。而且，這二者都是同一家公司的產品，在很多地方是相通的，并不互相排斥。

@water_jie
你可能沒有理解我說的。
我的意思是，設置多個組，第一個組為初始用戶數，如100，第二個組以50或100遞增，直至達到所需的200用戶，300用戶等，并不是說第一個組100，第二個組200，第三個組300……

對的。
不過我建議你找一個實際的測試結果，自己看看，會理解得更清楚些。

哦，不好意思，我上面說得不太準確。
其實我的意思是，響應時間長了，也就意味著TPS低。
不是說響應時間長會影響TPS，而是說響應時間長了會導致TPS低。
也就是你要衡量的這個事務性能有問題，詳細的要再跟蹤。

暈，這個問題比較汗。。。
當然會影響啊，你自己都知道TPS是事務數/時間，那么時間越大，當然TPS就越小啦。

怎么一下子提這么多問題。
一個一個來吧：
1、是的。但是TPS值這么小，你要檢查一下具體的原因。如，是不是把thinktime算進去了？你的事務定義得是否有問題？等等。
2、每秒事務數可以是每秒交易數，這要看你的事務和交易分別是怎么定義的。
3、平均TPS值是這樣算的沒有錯。

是的。Transactions per Second就是每秒事務數，也就是我們通常說的TPS

再次針對以上問題進行試驗，我在lrt_strcpy(sendBuf1, sendBuf);語句的前后各加了一句調試信息：lr_output_message("sendBuf:%s",sendBuf);
和lr_output_message("sendBuf1:%s",sendBuf1);
打印出來的結果截然不同，前者的輸出顯示沒有傳入參數值，而后者則成功傳入參數。這表明確實是lrt_strcpy這個函數在搞鬼。
至此，這個問題可以圓滿結束了！感謝Zee同學的熱情解答！^_^

昨天和Zee討論了一個下午，結論還是沒有明確。今天上午繼續試驗，試驗結果表明Zee說的是正確的，不能直接將C語言里的變量直接當作LR變量使用，而需要做一些轉換。事實上，執行strcpy(a,"{a}");后，并沒有真正將參數值傳給a。需要這樣寫：strcpy(a,lr_eval_string("{a}"));這樣就沒問題了。

不過，問題還沒有結束，在tuxedo協議中，用 lrt_strcpy函數則沒有這個問題存在，例如：lrt_strcpy(sendBuf1, sendBuf);則可以成功地將sendBuf中的參數值賦值給sendBuf1。目前懷疑是該函數在內部已經進行過轉換，但并不肯定，尚待證實。

@rickyzhu
呵呵，你太客氣了！
我從你的文章里知道你現在正在oracle任職吧？這些東西你應該比我清楚才對啊，以后多指教！

首先要安裝oracle客戶端，完成相關配置，再添加oracle計數器就可以了。
至于要監控哪些參數，完全看你的需要，這個需要參考下oracle的資料。

你沒看清楚吧？
我是回到項目組，不是回廈門。
這次回來比上次更忙了，天天加班到晚上9點以后，周末也不例外。
恐怕暫時還是沒有時間寫文章了。

另：你的blog搬家了，可是沒告訴我新地址啊，我怎么給你換??？

@rickzhu

呵呵，我寫這個已經有一段時間了，現在自己再看我寫的這幾句話，也挺費解，已經想不起來為什么當時會這么寫了。

現在想想其實我這樣的描述似乎并不是很合適，對于幫助里的這句話，僅僅從它字面上的意思就挺好理解了，沒有必要區分這里的前者和后者，我這樣描述反而可能對大家造成誤導了，不好意思。^o^

呵呵，謝謝樓上兩位的精彩評論，很高興看到這個貼子至今還有人頂，不要客氣，繼續繼續哈~^_^
最近忙于在外地出差，所以就不常來發貼了，不好意思！
我也來說說看法吧。
對于以上的第一個問題，我同意檻外人“如何確定是否要對一個功能進行性能測試，是根據其實現過程分析它給系統帶來的性能消耗來決定的?！钡恼f法。
至于第二個問題，Pacing設置的確是客戶端的設置，通過控制虛擬用戶發送的請求頻率來對服務器端造成壓力。Pacing究竟對服務器的性能結果是否有影響？以及如何影響的？在原文中已經說得很清楚，當發送的請求頻率在服務器處理能力范圍內（隊列處于收斂和穩定狀態）時，而當發送的請求達到一定的頻率，超過了服務器處理的能力（隊列處于發散狀態）時，是會對測試結果產生影響的。

@檻外人

關于你說的第一個問題，按照幫助文件中的說法，可能我在上文中表述的意思有些模糊，其實我的理解是這樣的：在場景運行的整個過程中，LR都會對每一個時間點采樣一次，取在這個時間點上通過的事務數，然后畫一個分析圖。而你說的“總的事務數/場景運行時間=每秒事務數。 ”我不清楚你說的這個“每秒事務數”是從哪里得到的，如果是TPS圖下方的平均值，我認為這個值應該是這些采樣值的平均，而不是這樣得到的。當然也有可能是我理解的錯誤，歡迎繼續討論，希望我們最終能得到一個正確的結論。

至于你的第二個問題，我不太理解你的意思，，虛擬用戶數和完成的事務數并沒有確實的對應關系，一個虛擬用戶執行的腳本中可能包含多個事務（有時還會包括init和end事務），所以你說的“虛擬用戶數/響應時間=每秒完成的事務數”，是沒有什么根據的。

@ppent
我在上文中說的是每秒事務數圖所表示的含義，LR在運行場景的過程中，會對每一個時間點采樣一次，記錄在這個時間點上所通過的事務數，將其繪制成分析圖，這就是我們所看到的“每秒事務數圖”，而我們通常所關注的TPS值，應該是由這些采樣值所取的平均值，這樣看來，事務響應時間和每秒事務數肯定不會是簡單的倒數關系。

我本來就沒有貼圖啊。
我只是在說這幾張圖所表示的含義，這幾張圖的名稱都比較容易看懂，用不著貼圖了吧？

呵呵，不客氣，一起學習，共同進步！^_^

二、關于TPS（Transactions per Second）：
每秒處理事務數。這個值可以說明系統在特定的負載情況下，每秒可以處理多少個客戶端請求，這是一個衡量服務器端性能的重要指標，相信各位在進行性能測試的時候經常會用到這個指標。但是一直以來我都有一個疑問，到底這個值是怎么算出來的。既然是每秒事務數，那算法自然是“事務數/時間”。事務數很好理解，執行了多少就是多少，關鍵是這個時間。是整個場景執行的時間，還是僅僅是在服務器端執行的時間？因為我們知道，這兩個時間肯定是有區別的，前者還包括thinktime的時間、pacing的時間以及在網絡上耗費的時間等等。
為了弄明白這個問題，我今天特地查了一下幫助文檔，看到上面是這么說的：“每秒事務數圖顯示在場景或會話步驟運行的每一秒中，每個事務通過、失敗以及停止的次數。”如果按照這句話去理解，那么上面那個問題的答案應該是后者，也就是說，在Transaactions per Second這張圖中，LoadRunner是針對場景運行過程中的每一個時間點取樣一次，顯示在這個時間點上每個事務的通過、失敗以及停止的個數。
另外，我還在Analysis里面找了一下，發現圖表的時間顯示粒度也是可以設置的。具體方法為：在圖表上點擊右鍵->選擇“Set Granularity”或者直接按Ctrl+G。我試著把時間粒度調成以毫秒為單位，結果LoadRunner提示當前不支持以毫秒為顯示粒度，由此我推斷LoadRunner對于Transactions per Second這張圖，最小的取樣粒度為1秒。
以上分析如果有不對的地方，希望各位提出批評。

不好意思，最近這幾天比較忙，沒有時間來回復。
@檻外人
我個人的看法，如果按照你所說的，場景是基于目標的，那么Pacing的設置確實沒有太多關系，不過在我的實際工作中，通過并發用戶去設置場景的情況還是比較多，所以Pacing的設置還是會對測試結果產生一些影響的。
謝謝你的回復，歡迎繼續探討！

* 在Analysis中，可以很方便地將各個分析圖表拷貝出來。方法是：先切換到某個圖表頁(Graph)，再使用Edit?Copy to Clipboard功能，便可將該圖表的圖、數據等復制到剪貼板，然后就可以粘貼到需要的地方（如測試報告）去。
* 將參數設置為Unique時，要特別注意提供的參數列表是否足夠，在Controller中分配值的選項(Allocate Vuser values in the Controller)默認設置為自動分配數據塊(Automatically allocate block size)，這樣的設置在場景的執行過程中往往會出問題，報出“參數不夠”的錯誤，可以修改為由人工分配(Allocate__values for each Vuser)，為每個虛擬用戶分配指定數目的參數，以便于控制。
* LR在錄制腳本時有時常會出現一些亂七八糟的字符，例如：
"Name=save_path", "Value=D:"
"\\x5C"
"resin-2.1.12"
"\\x5C"
"doc"
以上腳本片斷中用紅色標出的“x5C”部分就是錄制下來的亂字符，該腳本原本是為了將附件上傳到服務器端保存，可錄制下來的保存路徑卻多了以上的亂字符，導致本應的保存路徑D:\resin-2.1.12\doc\...，變為D:\x5Cresin-2.1.12\x5Cdoc\...。要特別注意，以避免產生不必要的錯誤。

Q：性能測試有哪些測試類型？有何異同？
A：性能測試是一個涵義很廣的概念，它包括負載測試、壓力測試、強度測試、可伸縮性/擴展性測試等。
1.負載測試：通過逐步增加系統負載，最終確定在滿足性能指標的情況下，系統能承受的最大負載量的測試。 2.壓力測試：通過逐步增加系統負載，最終確定在什么負載條件下系統性能將處于崩潰狀態，以此獲得系統能提供的最大服務級別的測試。 3.強度測試：又稱疲勞強度測試，在系統穩定運行的情況下能夠支持的最大并發用戶數，持續執行一段時間業務，通過綜合分析，確定系統處理最大工作量強度性能的過程。4.可伸縮性（Scalability）是衡量一個系統處理能力或容量的屬性，舉個例子說，就是當為一個系統增加了資源——特別是硬件資源后，系統可以承受更大的負載，并獲得更大的 吞吐量，這個系統可以被稱為 Scalable System （可伸縮的系統）。例如測試一個使用了負載均衡和集群技術的系統，測試當增加新的 Cluster 之后是否可以承受更大的負載，并獲得相應的吞吐量提升。


Q：“并發用戶數”在英文中是如何表示的？
A：并發用戶數量：the number of concurrent users
最佳并發用戶數量：the optimum number of concurrent users
最大并發用戶數量：the maximum number of concurrent users
峰值并發用戶數量：the peak number of concurrent users
平均并發用戶數量：the average number of concurrent users

Q：“注冊用戶數”和“最大并發用戶數”有聯系嗎？
A: 注冊用戶數和最大并發用戶數之間本身沒有必然聯系。一般根據特定時間段的峰值來進行計算。如注冊用戶數為2000，按照行業標準一般峰值使用人數為5％－10％，也可以通過前期項目進行統計后，得到較為準確的百分數。

網友 大漠飛鷹：

并發中有兩個概念，一個是業務并發數，指的是客戶端的訪問用戶量；
還有一個是服務器端的并發數，指的是服務器端的處理數量；

實際操作中，我們比較方便控制客戶端的并發數，而服務器端的則幾乎無法控制和操作，因此我們平時說的并發數指的都是業務并發數。

以下是在51testing論壇上的討論貼：

Zee：
關于集合點，我一直覺得沒有什么可爭議的，這兩天看到幾個帖子在說這個東西。有一點我想大家都是認同的：集合是相對的集合。
集合是在產生負載的機器上的集合。如果考慮網絡，中間件等等的因素。到服務器肯定不會是同一時間點，那于是就有人希望能更接近在服務器端實現并發的操作。認為這才是真正的并發。
我覺得首先要做的是分析應用系統，到底你想做的是什么。
比如說，你想讓某個URL能達到1000個同時請求的目的。這樣的目標就比較明確了。
而在討論集合點的時候，大家很少拿具體的東西來舉個例子。這樣有點說不清楚。要想達到并發。我覺得應該更具體的分析應用。再來定下目標來做。而不是一直在討論LR如何能實現。

xingcyx：
因為在實踐中，我經常會碰到這樣的情況：
測試需求說，該系統應支持200個并發用戶。

那么我們就開始測，錄制好腳本，下一步就是在場景中執行了，在控制臺中設置某腳本并發用戶數為200，測試結果為通過或未通過。此時爭議就來了：這200個用戶的腳本如果執行通過，測試結果可以接受，是否可以說這個系統支持了200個并發呢？

Zee：
你說的是不是太過泛泛？如果用戶說這系統要支持200個并發。那做性能測試的人知道這句話有很大的出入。

大漠飛鷹：
測試前肯定要了解需求，或者說是測試目的。
就說明“該系統應支持200個并發用戶?！?， 這種需求嚴格意義上來說是不合格的需求，因為描述不夠清晰，過于模糊等。
當然，在實際中，這類需求到了我們測試人的手里也是常有的，一般就當普遍的情況來出來。
比如，web系統，就按2/5/8，或者2/5/10來處理，如果能通過就pass，否則就讓開發人員調優。

xingcyx：
那么樓上的兩位就請說說，你們實際的工作中，需求是怎么提出來的，或者你們是怎么去確定出來的，到了最后確定了的測試需求是個什么樣子？給出來大家參考一下。

Zee：
從集合點到并發數的確定。我覺得這其中的轉換最主要的地方在于分析業務。

比如用戶說了：要求200個用戶并發。
那要問清楚的就是，200個用戶是個什么樣的比例，有多少人在干這個，有多人在干那個，按百分比，用不同的腳本來跑。
那再來想一下客戶。他關心的是200個用戶在服務器上同時點同一個URL或者某一個相同的資源？這個客戶我想大多不會關心。而他想要的就是我有200個用戶在線的時候。響應時間不至于讓人不可接受。至于多少才不可接受。按平常人的心理承受能力來衡量就可以了。再或者有其他的說法，就是200人同時點同一 URL或者請求同一資源，我想可以通過計算來增加vuser的數量或者集合呀，或者其他的方法來努力的向這個目標靠近。

如果說非要在服務器上這個時間并發這么多的用戶。我覺得只能盡量把它縮小到一個時間段內。而這樣做我覺得并不是從分析業務出發的

xingcyx：
樓上說的是最常見的一種情況，在這種測試需求下，我會設置一個混合場景來測試，也就是按照做不同事情的用戶的百分比去設置。
但會有另外一些時候，并不是一個實際的應用系統，可能是一個開發平臺，或者工作引擎等，它涉及的性能的概念會更偏向底層一些，這個時候可能就不是像一般的應用系統那樣，設置一個混合場景來測試那么簡單了。

大漠飛鷹：
一般說的并發數指的是業務并發，而不是服務器端得并發數。

cc_lion：
一個業務并發，一個服務端最大并發數，針對測試目標不一樣選擇其中

測最大并發數可能有意外收獲哦??！資源爭用，DEADLOCK，等

6. 設置Internet首選項的其它選項
幾個比較常用的：
由資源引起的步驟超時是警告（Step timeout caused by resources is a warning）：如果由于資源未在超時間隔內加載而引起超時，將發出警告而不是錯誤。對于非資源，VuGen 總是發出錯誤。（默認情況下為 NO）
HTTP 請求連接超時（秒）（HTTP-request connect timeout(sec)）：Vuser 終止之前在步驟內等待特定 HTTP 請求連接的時間（秒）。超時為服務器保持穩定并響應用戶提供了機會。默認值為 120 秒。
HTTP 請求接收超時（秒）（HTTP-request receive timeout(sec)）：Vuser 終止之前在步驟內等待接收特定 HTTP 請求的響應時間（秒）。超時為服務器保持穩定并響應用戶提供了機會。默認值為 120 秒。
超時設置主要用于以下高級用戶：這些用戶已確定可接受的超時值應該隨環境而異。大多數情況下，默認設置應該足夠長。如果服務器在合理的時間內并未做出響應，請檢查其他與連接相關的問題，不要設置太長的超時，否則可能會導致腳本不必要地等待。
網絡緩沖區大?。∟etwork buffer size）：設置用于接收 HTTP 響應的緩沖區的最大大小。如果該數據的大小超過了指定的大小，則服務器將按塊發送數據，從而增加了系統開銷。從 Controller 中運行多個 Vuser 時，每個 Vuser 都使用自己的網絡緩沖區。該設置主要用于以下高級用戶：這些用戶已確定網路緩沖區的大小可能影響其腳本的性能。默認值為 12K 字節。

* 在啟動錄制腳本操作的Start Recording對話框，去掉Record the application startup前的選擇，可以不錄制應用程序啟動時的操作，而僅錄制所需的特定操作。

* 添加windows性能計數器時，必須先用管理員身份登錄該臺服務器，然后添加才可生效（注意先后順序）。

* 設置DB2數據庫監視：在Monitored Server Machines中配置Machine Information機器信息，Name中要填寫“主機名@實例名”，如“168.31.6.47@DB2”，其中實例名要填完整，包括節點名稱。Platform選“N/A”。

* 添加windows性能計數器時，必須先用管理員身份登錄該臺服務器，然后添加才可生效（注意先后順序）。

* web_reg_save_param是在web腳本中用于關聯HTML語句的函數。只有在錄制中的關聯有效時（在錄制選項中設置），web_reg_save_param才會被自動錄制。

以下是我的回復，想法不一定正確，希望拋磚引玉：

我看完郵件的描述，發現這正好和我前不久做過的一個系統比較像，但我不敢保證我的做法就是對的，只能把他提出的問題，結合我的實際經驗，提出來和大家討論一下。
1、關于在線用戶數和并發用戶數的之間的換算關系，其實很難有一個確定的說法，這個問題我一直在考慮，也很希望能夠有一個更好的方法來實現這個換算，但10%是一個普遍為大家所接受的比例，我個人覺得沒有什么問題。至于“背景用戶”，我覺得也是需要的，因為對于這樣的性能需求來說，很重要的一點就是要盡量地接近于真實的業務場景，只要你所模擬的是現實中的業務操作，那么測試出來的結果就是可信的。
2、對于第二個問題，我沒大看明白他的意思，如果他的場景是混合場景，那無疑應該是按照模型中的比例去設置虛擬用戶，但我猜測他之所以會提出這個問題，可能是想對單個業務交易去做測試，不知道我猜的對不對。
3、所謂突發性的大并發加壓策略，模擬的是一種業務處于高峰期時的，以及一些突發的、意外的情況，要看各個系統的具體業務情況來定，如果業務上存在這樣一種高峰時段（比如到了月底，會有大量的報表生成、導出等工作），我個人認為還是非常有必要考慮的，尤其是要關注一下當這樣的壓力過去后，系統是否可以恢復正常。

另外這邊我也提幾個問題：
1、“網站的每日訪問量10萬人次”，不知應如何去實現測試？
2、所謂的“頁面訪問量”是LR中好象是給不出來的，那么我們是否可以將其換算成點擊率的指標，然后再去進行測試？我在之前做的那個系統就是類似于網站性質的，我對于網站的測試也沒有什么經驗，僅僅做過那一次，因此也想聽聽兩位的意見。