Hello Huong,
sounds like it's saying that when the test is running, I should not use scripting to modify the traffic because concurrency will then be lost.
|
Yes, you understand this correctly.
| The application keeps on getting update status from the server until the PDF is completely exported. |
TestComplete can't automate this scenario. It can simulate the recorded requests, but it cannot repeat a request based on the server response.
So, you can't make the Load Testing engine send a request in a loop until some condition is met.
However, you can still use TestComplete to simulate the needed server load - executing the recorded request for N users will start N parallel exporting tasks on your server. The question here is how to measure the time it takes for the server to complete the export. You cannot measure this time with TestComplete, so you will need to add some server-side logging to see how much time it takes the server to export a document.
| Another question is variable parameterization, using this does not remove concurrency, correct? |
You are right - using the
Data Selectors functionality will allow TestComplete to run the VUs in parallel because there is no dependency on the scripting engine in this case.
