Hello Huong,
1: The doc only mentions the ramp up feature. is the start delay feature also ignored when Run Concurrently is unchecked? |
No, the Start Delay setting is not ignored when the "Run Concurrently" option is disabled.
2: How do I verify the run concurrently feature via the load testing log? |
Users are run in parallel threads, so, they actually work in parallel. The Load Testing log does not show the results in a way that would make you see exactly how the requests overlapped or that they did not overlap - you do not see the timeline with the executed requests, you see only the list of users and their measured parameters.
From what I see via the Default log (I sorted it by time), it seems like the users are running in a series rather than concurrently, just in random order. |
The Default Log is generated when the execution is over, not during the test execution. So, the Time column does not reflect the actual execution order, the time stamps show the log record creating time, but not the event occurrence time.
I think this question might be similar to this one: |
No, the situations are different. As far as I understand, you are not using event handlers in your test.
When you load a page in a web browser, the browser opens several HTTP connections to the server to load different parts of the page independently (images, styles, scripts, etc.). TestComplete records the requests and connections exactly like they were created/sent by the browser. So, requests in parallel connections are sent independently. However, depending on the tested application implementation, the request order across connections may be important. TestComplete "does not know" when the requests order across connections is important and when it is not, and that is why, TestComplete assigns IDs to requests sequentially to preserve the requests order across connections.