Hello Rasim,
| You mean by test actulay 0.3 seconds and all 3.5 seconds spend for initialization and log writing ? |
Yes, you are correct with the calculations. This is the way the Load Testing engine currently works - the initialization and finalization phases may take quite some time.
| can I show somebody those Avg.Process times as real times taken by users ? |
The times shown by TestComplete cannot be used to predict the real page loading time in a web browser (at least, with acceptable accuracy). The only thing you can tell about the page loading time in a web browser, is that it cannot be shorter than the total of the "Request Execution Summary" column in the Connections grid for all requests that are needed to load a page (when the server is under the same load).
When loading a web page, a web browser not only receives the server responses (like TestComplete does), it also parses the HTML code, renders the page, fires events, and executes client-side event handlers.
So, what you are getting from TestComplete as the "Time needed to simulate requests and receive responses" value, is a characteristics of the server-side part's performance, which may be different from the client-side UI performance. Measuring the client-side UI performance is a different type of testing, not directly related to Load Testing, and the results will greatly depend on the web browser you are using on the client.
So, in general, the numbers you are getting in the Load Testing logs, should be used for performance testing, but not as absolute values. They are relative to each other. You run a test several times with different scenarios (different VU number, different server settings, different web application versions, different web server hardware, etc.) and compare the times you got in the Test Logs with each other to understand how the server's performance depends on the usage scenario. For example, if the response time doubles when you increase the load by 50%, then, probably, it is not good, and you are approaching the server capacity limit in terms of simultaneously working users.
