Vuser – V-user, virtual user, the script will emulate the actions of one particular user. Able to what we had taught him during the recording, parameterization, and other patient preparation. For example: Login, causes of action against the server, receives the result of (wait for it or not) and otloginivaetsya. From the perspective of the whole system of testing – it is a party that receives at the start of the script where to go and what to do, receives instructions from the controller about the run as in the rest-users (one of the crowd, or more nimble escape forward, listened attentively to what he do if somewhere you can not run and on what ground he has that Having reported. Then after the whistle controller, he runs around the well-known scenario (sequence of actions) and "calls back for confirmation on the typewriter, which he launched on the outcome of the race. From a technical standpoint, each -user can be a single instance of software-engine, which performs the script, the user (so is faster, but also the resources to it) – that is, scripts are executed in multredovom mode (the documentation is a reservation that the system must support such a mode of program) and perhaps one of the processes of the program-engine, then he will share memory with others, users who steers the engine – to eat more memory and speed is lower.
Multithreading is not supported for all protocols! But if it is available, it is recommended to use it, rather than processes. It is precisely because the consumption of resources load generator machine (mainly memory) while significantly smaller, which allows a single load generator to run more VUsers.
Vugen – generator-users (pisalka scripts), so smart Toole, who sits between the client, which pulls the application / server and the application itself or server, which is under test. During the user experience, Vugen «catches" all API calls that the user throws the server (to make it then that play) and all responses that the server itself (that was later to compare with).
Scenario – A list of B-users (with names and surnames), which is defined as in-users, we will get to run, with no cars, and some scripts, we’ll get them to do.
Controller – machine, which is the command to start / stop control / coordination (Rendezvous – a beautiful French word) in-users on a typewriter, with which our in-users and Teasing the system under test. The same controller collects the data / reports from users, then to build the beautiful graphics or reports that we have something to fall. This may be a machine of the tester. On this machine robbed data on work-in users (how long they worked, what they are doing now, etc.)
Beautiful graphics controller is not built, and a third module LoadRunner’a, called Analysis. He gets the input file with the results of running the script (. Lrr-file) and creates an analysis session. This session could be maintained if there is a need (. Lra-file).
Load generator / load injector – real cars which is an engine that can run scripts in-users. Subject to the controller, the command which starts in-user, listens to their "complaints" and giving reports to the controller.
Known for some protocols communicate with the user and the server.
The most painful often determine how much traffic we’ll catch and transform into a script.
Known sequence of action, it is a business scenario, the sequence of actions with the end result.
Run Tool to record and click on our consistency.
Login and logoff is often written in vuser_init and vuser_end part (when running with different parameters, the operation described in the init and the End of not playing). Actions of the user record in the action part, or create a few actions, if the logic holds more than one action with tangible results.
Look what happened, and we lose: we play action on behalf of one user (until a load is not).
If necessary, We arrange a rendezvous point (again, a beautiful French word) – it is such a point, Running up that in-user "looks" at kotroler (waiting for instructions), who tells him to run farther or wait for the others (as in clear-users in mean load will run at different speeds). He will wait until all the visual signal controller will gather at the rendezvous point (if we load this piece of the simultaneous load of all users), or run away before (load is obtained fuzzy, but more real – someone else the first steps is finished, but someone had already on the second circle ran).
If necessary, define a transaction – say where it starts / ends posledovatelnost action that we are interested to compete.
If necessary / possible parametriziruem script. That is, we speak not just to perform sampling on such a field with a constant value terms, and learn the script substitute for constant variables that tell him where he can take these variables.
Define the data that-users can use as parameters. We can say here’s a sign / I’ve found, and take away everything in order, randomly, only those who have no one took it, and that’s in that range.
Here is a good moment: the intersection of the load and functional testing. Have unloaded at the plate I’ve found – our test data (such as id-shki kastomerov are to be used at the input sample). The plate is big. But we and the user can be many. Talking to each take a piece, do you want from 1 to 100, do you want from 101 to 200 and so on – it turns out that in one iteration, we will go to as many options as users, and the number of iterations, we define the block size (intervals).
In order to determine a suitable protocol was not painful, is necessary to understand what actually VuGen writes.
Sometimes the question "A what protocol is using your application?" can be heard in response to "TCP / IP", that generally speaking, too, will be correct, but absolutely useless in terms of load testing. We are not interested in the transport layer data, we are interested in application level protocol. For example, if there are two client / server systems, working with databases Oracle, but one of them works with the database directly, and the second through the middle tier, such as Tuxedo, then the protocols used for writing scripts for such systems will be different. In the first case we need Oracle 2-tier protocol, and the script we will see the SQL requests going from client to server. In the second case, we need a Tuxedo protocol and we will see in the script function VUGen’a who pulled a Tuxedo API.
Record login / logout respectively vuser_init / vuser_end is part of best practices, but not necessarily. Depends on whether you want to emulate the login / logout for each iteration or only once. Create several parts of actions can not be taken for all protocols (for HTTP can).
Determine the transaction will almost always (but otherwise we’re going to measure?). Parametrization – at our request. If it is not done, then we must remember that chasing a bunch of users with the same data can be (if the application under test will allow), but the same queries are cached and you risk not getting a real load on your system. If the test is more or less a real system, it is likely no correlation (dynamic parameterization), we can not do. The classic example – generate a unique ID when inserting new record into the database table. Recorded script, you can not drive a second time unless you do the correlation. Static parameterization does not help here, because we do not know in advance what kind of ID will be generated as it is generated only in run-time.
Rendezvous point does not necessarily imply the expectation of all who should assemble there. The control logic allows us to be more flexible in this regard. For example, the wait will bring together all, but if not met for 2 minutes, then released all of those who gathered. Rendezvous point helps us to simulate stress load on the server to see how he will lead in this situation.
These scripts define the stage of creating and debugging VUser’ov, ie VuGen’e, but not in the controller. You can upload data directly from the database (there is a special Wizard, which helps to do this), if you know the necessary SELECT.