|
|
Does LoadRunner transaction response time include the rendering time of the browser?
The answer is “No”! The reason is very simple, LoadRunner is not designed for client-side activities (remember, it’s all about network traffic!). We will illustrate using Web (HTTP/HTML) protocol.
Keep in mind that when we mention rendering time, it means the time taken for the display of the web components, Javascript or applet to load in the browser (or anything that is considered client-activity, loading in the browser) that is being activated after the HTML page is being received.
When we replay the scripts in LoadRunner, network traffic are being generated by the APIs (functions) and are expected to receive before the subsequent step can be executed. All this are taken place in memory and what LoadRunner does is to generate the traffic and receive the responses in memory. No user interface (UI) is launched in the process of replay for the purpose of rendering the pages received. Having no UI launched, rendering is omitted.
In a real user environment, the entire time for response in user perspective includes the request sending time, request processed time, response time and the browser loading (rendering time). However, in the context of LoadRunner, UI is not part of this entire request and response cycle.
Keep in mind that the transmission of the data is still pure text (or binary) and that needs to be rendered by the browser to be displayed properly. That’s considering the Javascript and any applets that needs to be loaded which is greatly dependent on the browser (eg. IE, Modzilla)and your machine specifications.
Even for Web Page Diagnostics, rendering time is not included as part of the transaction response time. It only allows the drill-down of time taken to download web components and not the time taken to render the component for display. In summary, it’s still at the network level.
If you are looking for an end-to-end response time testing that includes the rendering of the UI, you should consider using the GUI vuser protocol. The protocol utilizes another (famous) HP testing product, Quick Test Professional (QTP) as the recording mechanism, and replays the QTP scripts in the Load Generators as GUI vusers. For official information on the GUI vuser protocol, you can refer to the HP LoadRunner (v9.0) Controller User Guide, Chapter 14, “Using Functional Testing Scripts in LoadRunner”.
|
一个佐见，至于作者的依据有何根据，可以发邮件去问问。
|
|
|
/1 
关于我们
发表于 2009-5-19 09:56:38
