性能測試工具的基本功能和可能出現的技術要點分析(4)

　　• 第二部分是界面部分，提供腳本編輯、調試和運行功能，這部分可以用 Visual C++/MFC 實現 Windows 平臺版本和 Java/AWT 實現 Unix 版本。

　　• 第三部分是以插件的形式提供的分析各種網絡協議的解析器。開發這類插件的強有力的開發工具為 lex 和 yacc 。

　　• Proxy 二次捕獲的問題

　　Vugen 的 Proxy 方式需要解決的一個問題是二次捕獲數據包的問題。

　　早期的網絡服務器程序對外提供一個固定端口，客戶端僅僅和這個端口通訊就可以了。這對于 proxy 錄制非常容易。但是現在很多服務器程序為了提高對客戶端并發量的支持，采用兩個端口通訊的方式。如下圖所示：

　　整個通訊的過程如下：

　　• 第一步：客戶端將請求發往 Proxy 錄制器。

　　• 第二步： Proxy 錄制器將請求發往真正的服務器的指定端口，即圖中的 3200 端口。

　　• 第三步：服務器機器的 3200 端口返回數據包給 Proxy 錄制器。該數據包中包含了下一次通訊的目的地址，形式為 IP:Port 。很顯然，這里的 IP 數據為真正服務器的 IP 地址。

　　• 第四步， Proxy 錄制器把請求返回給客戶端。

　　• 第五步，客戶端根據提供的 IP:Port 信息直接把請求發往真正的服務器，不再經過 Proxy 錄制器。

　　• 第六步：以后的通訊只是客戶端和服務器之間的通訊了， Proxy 錄制器是無法捕獲這些通訊包了。

　　因此一般的 Proxy 錄制器只能捕獲頭兩個收發的數據包。 這個問題更一般的情形的例子是 HTTP 的 redirection 功能。第二次通訊可能發往另外一臺機器了。 Proxy 錄制器必需解決這個問題。

　　• 關聯的問題

　　客戶端和服務器之間的通訊，有一部分是數據是動態的，每次通訊都不一樣。 Proxy 錄制器在錄制的時候是無法區分哪些是靜態的信息，哪些是動態的信息，所有的信息都以 hard-coded 的方式記錄下來。但是在回放的時候，如果有些信息不改變，那么腳本是不能執行成功的?？紤]如下情形：

　　如上圖所示，用戶 jojo 以 jojo/bean 的賬號 / 口令登錄某一 web 服務器，查詢某產品的信息，由 Vugen 錄制交易的全部通訊包。 web 服務器返回給 jojo 一個動態的會話 ID: SessionID@12345 ，作為這次登錄的會話標識。由于 Vugen 無法知道哪些信息是動態的，它會照單全收的方式，把所有的數據就記錄下來。接著 jojo 根據 Web 服務器告訴他的 SessionID 去查詢產品列表，交易可以正常執行下去。

我們會觀察到，當 Vugen 根據捕獲的通訊包生成 http 腳本的時候， SessionID 是 Hard-coded 的，即 “ 寫死 ” 在程序里面的。當我們不加修改的回放該腳本的時候，會出現什么問題呢?如下圖所示：

　　按照錄制時候的腳本， jojo 以 jojo/bean 登錄后， Web 服務器返回給 jojo 一個動態會話 ID: SessionID@23456 ，這個值已經不是錄制時候產生的 SessionID@12345 了，而是新的值： SessionID@23456 。那么腳本根據記錄的 SessionID 的值，仍然會使用 SessionID@12345 去執行下面的查詢交易。由于會話 ID 是有時效性的，用戶退出系統后，其 SessionID 會失效，那么，服務器會給出一個 “SessionID 失效 ” 的錯誤，從而導致腳本無法正常執行下去。

　　對于上面的問題的通用解決方法如下圖所示：

　　在第一次從服務器得到 SessionID 的時候把其放在一個變量 里面，在后面腳本訪問服務器的語句里面，把所有的 ”SessionID@12345” 替換為變量 就可以圓滿解決這個問題。

　　這種問題在任何系統都是非常常見對外問題。其通用的模式是： “服務器返回給客戶端一些動態變化的值，客戶端使用這些值去訪問服務器的時候，不能把這些值寫死在腳本里面，而應該存放在一個變量里面。” 這就是關聯的概念。

　　關聯的工作往往占據開發腳本的大部分時間，因為我們必需針對每一個具體的系統進行細致的分析，確定其需要關聯的動態信息。為了快速開發腳本， Vugen 必需提供幫助我們關聯的手段，最好做到自動關聯。自動關聯的方法有三種：

原文轉自：http://www.uml.org.cn/Test/200503183.htm