Assigning Multiple Tasks to Virtual User through Scripting

Hi Pawel,



Not sure if I got you right, but:

Only one task can be assigned to the virtual user at a time. If you need to execute several tasks during some time period, you may consider something like that:

while timespan < ExecutionPeriod

{

  VU.Task = <TaskObject1>

  VU.Task = <TaskObject2>

  
...

}



Note, that in this case (as opposed to Complex Task) TestComplete will not keep cookies between tasks - i.e. if task1 sets cookie that is then used by task2, then you must keep the cookie somewhere and modify task2's requests in the OnBeforeRequest event handler.

Hi Alexei,



Thanks for the quick reply. Looking above at your response, how would this fit into a load test of lets say 10 users? It is my understanding that when a load test is set up through script that the virtual users are run concurrently. Below I will provide a more defined example:



I wish to load test a manufacturing system. My load tests that I created visually are four separate tasks, Logging In, Creating Product Name, Adding Components to Product, and Logging Out. The tasks must be done in order, so a user must Login, Create a Product, Add Components, and Logout. The amount of components a user may add can vary (they can add at times one component or many components). I need to script these tests because the data in the requests must be unique each time and the amount of times I wish to run the Add Components script will vary. So, what I need is a Virtual User that will perform these four tasks in order. And then expand that into 10, 20, 30 users with each user performing their four tasks in order.



It is my understanding that I simply cannot assign a virtual user one task in my scenario since:



1) The tasks need to be completed in order

2) Calling the .Run method for a usergroup would execute all the users concurrently, thus the requests would not follow the flow of Login, Create Product, Add Component, Logout

3) The tasks need to share information such as viewstates, data selectors, etc.



From your example you assign a Task to a VU, (then I assume run the VU?), then assign another task to the VU, (then run the VU again?), How could this me expanded to 20 users and each starting concurrently while running your process in sequence?

Hello Pawel,





In general, the Complex Task feature is the best way to assign multiple tasks to a single VU. If you are going to implement the same behavior with a script, you will have to implement the Data Selectors, Load Testing Variables, and cookie handling in your script - this may be not an easy task.





From a general point of view, the task you have described in the last post sounds like a Functional Testing scenario - you are going to vary the actions the VUs are performing, the data they are sending to the server, etc. As a rule, it's not needed for a Load Test. Just think about it:





A Load Test must put some high load to the tested web server.

For the web server and the web application, in most cases, it does not matter what requests to handle (from the performance perspective).

Most probably, there are some pages that put high load to the server (CPU, or disk, or DB), and all other pages put almost the same load.

At that, the load does not depend on the user working with the system, does not greatly depend on the data the user sends to the server (not taking into account the exceptional cases when uploading a 2 GB file, for example - this needs to be tested separately).

So, when we have a very high number of VUs, it's not important (from the performance perspective) what requests they are sending to the server, it's important how many requests they are sending per second.





Of course, there are situations when the actual data matters. But what I want to tell is that you probably should not spend so much time and efforts trying to parameterize the VUs "actions". Most probably, the Load Testing results will not change much whatever actions the VUs will perform. That is, instead of trying to implement parameterization "on the fly", it is probably more efficient to create several real-world scenarios, and run them with the varying number of VUs. You can have several such scenarios to increase the server-side code coverage, or ensure that the load is put to all components involved (CPU, memory, network channel, DB, etc.) - it's based on your goals. I think you got the general idea.