Kavin

• Jul 9th, 2005

 

There are different methods for automating such tests. One is the record/playback method that leads to a very long script that can take days to run. It would systematically execute code to set the environment, and code to execute the test, alternating between these until finished with all test cases. This method requires a lot of maintenance and is lacking in error recovery and versatility. Breaking the script down into modular functions makes the code easier to maintain. The above test cases would require a unique function for each test: Test_1, Test_2, etc. There would also need to be a function to set the display resolution for the first set of tests and a function to set the baud rate for the second set. Each of these functions should return a value indicating whether the function was successful and leave the system in a known state. Rather than a long succession of executable lines of code, repeating lines are consolidated into a single function and our automated test becomes a set of function calls. The body of the test would look something like this: 
 
Call Function SetDisplay (800x600); 
 
Call Function RunDisplayTest_1(); 
 
Call Function SetDisplay (1024x768); 
 
Call Function RunDisplayTest_1(); 
 
And so on?. 
 
Call Function SetBaudRate (56K); 
 
Call Function RunComTest_1(); 
 
Call Function SetBaudRate (9600); 
 
Call Function RunComTest_1(); 
 
And so on?. 
 
This makes the script much shorter and more modular. If something must change in the code for running one of the tests, it only has to be changed in one place rather than multiple times throughout the script. Progressing further with this idea of minimizing the length of the script and reusing code, we can abstract out another layer of function calls. One more level of modularity will greatly increase the scripts versatility. 
 
In the above example, there is still a repeating pattern in the code. The functions SetDisplay and RunDisplayTest are called alternatively. This method is useful for running through every test, but not for running through a sample of tests. It is also not convenient for changing the order of the tests executed. These changes could be made by going into the script and changing code, but a user can more easily change the order of execution if the script is abstracted out one more layer.

balu

• Dec 5th, 2005

 

generaly in loadrunner

first v select sever if it is related to database application v select odbc server r if it is web application v select web server after that v choose vuser_init those this function v initialise apllication. after that action part in this v record application in this action part we can insert the functions we can change the script insert scdript after that we end recording by  chossing vuser_end