Forum Discussion

hnguyen_1's avatar
hnguyen_1
Occasional Contributor
14 years ago

How to modifying traffic through script but retain concurrency

http://www.automatedqa.com/support/viewarticle/17275/ 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. I need to write load test for export PDF. The application keeps on getting update status from the server until the PDF is completely exported. I don't know how many updates it needs until this process is done, so I can't really modify the test before hand. Do you have any recommendations on how to approach this problem?



Another question is variable parameterization, using this does not remove concurrency, correct?

1 Reply

Sort By
  • AlexanderM's avatar
    AlexanderM
    Staff
    14 years ago

    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.