Forum Discussion

hnguyen_1's avatar
hnguyen_1
Occasional Contributor
15 years ago

Clarifications needed

http://www.automatedqa.com/support/viewarticle/?aid=6830#StartDelay



Documentation: "The “ramp up” feature is ignored if the Run Concurrently check box of the Load Test Editor is clear. When this check box is clear, TestComplete runs virtual users in a series, so the “ramp up” functionality becomes meaningless."



1: The doc only mentions the ramp up feature. is the start delay feature also ignored when Run Concurrently is unchecked? Or would the users run in a series, with added delay? So for the example, VUser1 and VUser 4 will run, then after all of these are ran + delay of 500ms, users in VUser5 then will start running?



2: How do I verify the run concurrently feature via the load testing log? 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. If it was a thread-like execution, I would expect to see requests overlap for users (row 1 might have request from user 1, but row 2 might have it from user 2). I don't know if this is due to my test being too short? Can you give me an example to tell the difference (preferably via images/videos)?



I think this question might be similar to this one: http://www.automatedqa.com/forums/forum/post/?mode=singleThread&thread=07c628a1-1344-4007-8542-b9f17162c15f, but I don't understand the answer, so not sure.



3: http://www.automatedqa.com/forums/forum/post/?mode=singleThread&thread=73b87711-3099-4292-a71b-202a5d9f86a1

I don't really understand the difference between the connection numbering, vs. request numbering. It doesn't seem to run the test in the request numbering, rather, by the connection and request numbering. Why? Why are there multiple connections?



4: I see these files *.tcLTK.tcLTCnctns that has the HTTP request/response. I want to edit the files directly, but couldn't because there are binary information in them. Is there no way to edit these manually? Whenever something changes, I have to always re-record? I have a task recorded that has been working fine for a few weeks, then recently, it stopped working and I don't know what caused the errors. I really do not like to re-record tasks. Are load tests this brittle? Btw, how can debug it? A demo would really help (I'm a very visual person - reading text makes it harder to understand). 



5 Replies

  • hnguyen_1's avatar
    hnguyen_1
    Occasional Contributor
    If you can answer question 4 first, that would help me a lot. I need to know this to estimate the effort that I will have to spend to find a workaround for this problem.

  • Hello Huong,





    Here is the answer to question #4:

    You should not edit the files manually to avoid problems with the files' format. If you want to edit the requests' data, you can do this in the Load Testing Task Editor - it is possible to edit header and body values.





    As for the other questions, I will answer them a bit later.
  • hnguyen_1's avatar
    hnguyen_1
    Occasional Contributor
    Thank you for your last response, we've decided on a workaround implementation for this problem now.

  • 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.









    3: http://www.automatedqa.com/forums/forum/post/?mode=singleThread&thread=73b87711-3099-4292-a71b-202a5d9f86a1

    I don't really understand the difference between the connection numbering, vs. request numbering. It doesn't seem to run the test in the request numbering, rather, by the connection and request numbering. Why? Why are there multiple connections?





    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.
  • hnguyen_1's avatar
    hnguyen_1
    Occasional Contributor
    Your answers were very helpful, thank you. I'm still learning load testing, so I'm sorry for all of the basics that I need explaining. Thank you for being patient and for answering my questions.