A compiled module,like a regular test you create in Test Script Language,can be opened,edited, and saved. you indicate that a test is a compiled moduleby clicking Compiled Module in the Test Type box in the Test Properties dialog box.
The content of a compiled module differs from that of an ordinary test,it cannot include checkpoints or any analog input such as mouse tracking.The purpose of a compiled module is not to perform a test,but to store functions you use most frequently so that they can be quickly and conveniently accessed from others tests.
Unlike an ordinary test,all data objects (variables,constants,arrays) in a compiled module must be declared before use. The structure of a compiled module is similar to a C Program file,in that it may contain the following elements:
a) Function definitions and declarations for variables,constants and arrays.
b) Prototypes of external functions.
c) Load statements to other modules.
Note that when user-defined functions appear in compiled modules:
a) A public function is available to all modules and test,while a static function is available only to the module within which it was defined.
b) The loaded module remains resident in memory even when test execution is aborted.However,all variables defined within the module (whether static or public) are initialized.
Saturday, January 31, 2009
Creating Compiled Modules
For example,you could create a function called open the application that loads a GUI map file,starts the application,and logs into the system, or resets the main window if the application is already open. A function can be called from anywhere in a test script. Since it is already compiled,execution time is accelerated. For instance, suppose you create a test that opens a number of files and checks their contents. Instead of recording or programming the sequence that opens the file several times, you can write a function and call it each time you want to open a file.
Function Syntax
A user-defined function has the following structure:
[class] function name([mode]parameter.....)
{
declarations;
statements;
}
Class: The class of a function can be either static or public. A static function is available only to the test or module within which the function was defined. Once you execute a public function,it is available to all tests,for as long as the test containing the function remains open.
This is convenient when you want the function to be accessible from called tests. However,if you want to create a function that will be available to many tests, you should place it in a compiled module. The functions in a compiled module are available for the duration of the testing session.If no class is explicitly declared, the function is assigned the default class,public.
Parameters: Parameters need not be explicitly declared. They can be of mode in,out,or inout. For all non-array parameters,the default mode is in. For array parameters,the default is inout. The significance of each of these parameters types is as follows:
in: A parameter that is assigned a value from outside the function.
out: A parameter that is assigned a value from inside the function.
inout: A parameter that can be assigned a value from outside or inside the function
A parameter designated as out or inout must be a variable name,not an expression. When you call a function containing an out or an inout parameter,the argument corresponding to that parameter must be a variable,and not an expression.For example,consider a user-defined function with the following syntax:
function get_date(out today_date) {....}
Proper usage of the function call would be
get_date(todays_date);
Illegal usage of the function call would be
get_date(date[i]);or get_date("Todays date is" & todays_date);
because both contains expressions.
Function Syntax
A user-defined function has the following structure:
[class] function name([mode]parameter.....)
{
declarations;
statements;
}
Class: The class of a function can be either static or public. A static function is available only to the test or module within which the function was defined. Once you execute a public function,it is available to all tests,for as long as the test containing the function remains open.
This is convenient when you want the function to be accessible from called tests. However,if you want to create a function that will be available to many tests, you should place it in a compiled module. The functions in a compiled module are available for the duration of the testing session.If no class is explicitly declared, the function is assigned the default class,public.
Parameters: Parameters need not be explicitly declared. They can be of mode in,out,or inout. For all non-array parameters,the default mode is in. For array parameters,the default is inout. The significance of each of these parameters types is as follows:
in: A parameter that is assigned a value from outside the function.
out: A parameter that is assigned a value from inside the function.
inout: A parameter that can be assigned a value from outside or inside the function
A parameter designated as out or inout must be a variable name,not an expression. When you call a function containing an out or an inout parameter,the argument corresponding to that parameter must be a variable,and not an expression.For example,consider a user-defined function with the following syntax:
function get_date(out today_date) {....}
Proper usage of the function call would be
get_date(todays_date);
Illegal usage of the function call would be
get_date(date[i]);or get_date("Todays date is" & todays_date);
because both contains expressions.
Creating User Defined Functions
To providing built-in functions,Test Script Language (TSL) allows you to design and implement your own functions.You can:
A) Create user-defined functions in a test-script.You define the function once,and then you call it from anywhere in the test (including called tests)
B) Create user-defined functions in a compiled module. Once you load the module, you can call the functions from any test.
A) Create user-defined functions in a test-script.You define the function once,and then you call it from anywhere in the test (including called tests)
B) Create user-defined functions in a compiled module. Once you load the module, you can call the functions from any test.
Monday, January 26, 2009
Implementing Performance Testing
Performance Testing is carried out in 3 phases.
1.Simulation: Creating the test environment
2.Execution: executing the performance testing and recording results
3.Analysis: Analyzing the results and identifying the bottlenecks
Performance Testing can be implemented in 3 approaches:
1.Manually: Performance Testing can be implemented using Manual Test approach.
2.Volume Testing:
a.Manually we can create lower data volumes but it will not be possible to create huge data volumes.
b.Manually,the performance of application can be identified but the results can't be precise.
c.Manually,the performance analysis can't be conducted that is analyzing the processor utilization,memory utilization...
3.Multi User Testing:
a.Manually can simulate less no of concurrent user environment and it will not be possible to create huge no of users environment.
b.Simulating environment will be a costly process because of resources and infrastructure.
c.Manually executing multi user testing will be possible but precise Test Results can't be identified.
d.When multi user test is scheduled manually.
Limitations: Less no of users can be created,costly infrastructure,tough synchronization between users.Can't find the precise test results. Performance Test Analysis is not possible Manually.
1.Simulation: Creating the test environment
2.Execution: executing the performance testing and recording results
3.Analysis: Analyzing the results and identifying the bottlenecks
Performance Testing can be implemented in 3 approaches:
1.Manually: Performance Testing can be implemented using Manual Test approach.
2.Volume Testing:
a.Manually we can create lower data volumes but it will not be possible to create huge data volumes.
b.Manually,the performance of application can be identified but the results can't be precise.
c.Manually,the performance analysis can't be conducted that is analyzing the processor utilization,memory utilization...
3.Multi User Testing:
a.Manually can simulate less no of concurrent user environment and it will not be possible to create huge no of users environment.
b.Simulating environment will be a costly process because of resources and infrastructure.
c.Manually executing multi user testing will be possible but precise Test Results can't be identified.
d.When multi user test is scheduled manually.
Limitations: Less no of users can be created,costly infrastructure,tough synchronization between users.Can't find the precise test results. Performance Test Analysis is not possible Manually.
Performance Test Parameters
The Performance Test Parameters to be considered
The following parameters are considered during performance testing:
1. Response Time: The time taken from request to the time when we get the first bit of response.
2. Execution Time: The time from the request to the time when complete response is received.
3. Throughput: Amount of work done/sec that is data processed per second or no of requests addressed per second.
4. Server Resource Utilization: How the memory and processor resources are used.
5. Network Performance: The display in the network are monitered.
Factors affecting Performance of the application
Performance of any application will be influenced by below factors:
1. Multi User (Concurrent Users....working at the same time)
2. Data Volume (No of Records in DB)
3. Functionality/Complexity of Activity.
Performance Test Process:
1.Collect Performance Requirements from client that is response time,execution time ...
2.Identify scope of performance testing that is what functionality to be considered for performance testing (functionality1,functionality2,functionality3)
3.Design performance test scenarios (combinations of functionality/scripts)
4.Generate Virtual User Scripts for each functionality.
5.Update and Debug the scripts.
6.Develop performance scenarios or control scenarios (grouping of scripts)
7.Run the scenarios (performance testing)
8.Record the Results
9.Analyze the Results
10.System Tuning (Only if we are looking for better performance)
11.Repeat from 6-8
The following parameters are considered during performance testing:
1. Response Time: The time taken from request to the time when we get the first bit of response.
2. Execution Time: The time from the request to the time when complete response is received.
3. Throughput: Amount of work done/sec that is data processed per second or no of requests addressed per second.
4. Server Resource Utilization: How the memory and processor resources are used.
5. Network Performance: The display in the network are monitered.
Factors affecting Performance of the application
Performance of any application will be influenced by below factors:
1. Multi User (Concurrent Users....working at the same time)
2. Data Volume (No of Records in DB)
3. Functionality/Complexity of Activity.
Performance Test Process:
1.Collect Performance Requirements from client that is response time,execution time ...
2.Identify scope of performance testing that is what functionality to be considered for performance testing (functionality1,functionality2,functionality3)
3.Design performance test scenarios (combinations of functionality/scripts)
4.Generate Virtual User Scripts for each functionality.
5.Update and Debug the scripts.
6.Develop performance scenarios or control scenarios (grouping of scripts)
7.Run the scenarios (performance testing)
8.Record the Results
9.Analyze the Results
10.System Tuning (Only if we are looking for better performance)
11.Repeat from 6-8
Performance Testing
Testing the performance/response behavior of the application under various working conditions is called as performance testing.
Automated Performance Testing:
Automated Performance Testing is a discipline that leverages products,people,and processes to reduce the risks of application,upgrade,or patch deployment.At its core,,automated performance testing is about applying production workloads to pre-deployement systems while simultaneously measuring system performance and end-user experience.
Performance test answers questions such as:
1. Does the application respond quickly enough for the intended users?
2. Will the application handle the expected user load and beyond?
3. Will the application handle the number of transactions required by the business?
4. Is the application stable under expected and unexpected user loads?
5. Are you sure that users will have a positive experience on go-live day?
By answering above questions,automated performance testing quantifies the impact of a change in business terms. This is turn makes clear the risks of deployment. An effective automated performance testing process helps you to make more informed release decisions,and prevents system downtime and availability problmes.
Automated Performance Testing:
Automated Performance Testing is a discipline that leverages products,people,and processes to reduce the risks of application,upgrade,or patch deployment.At its core,,automated performance testing is about applying production workloads to pre-deployement systems while simultaneously measuring system performance and end-user experience.
Performance test answers questions such as:
1. Does the application respond quickly enough for the intended users?
2. Will the application handle the expected user load and beyond?
3. Will the application handle the number of transactions required by the business?
4. Is the application stable under expected and unexpected user loads?
5. Are you sure that users will have a positive experience on go-live day?
By answering above questions,automated performance testing quantifies the impact of a change in business terms. This is turn makes clear the risks of deployment. An effective automated performance testing process helps you to make more informed release decisions,and prevents system downtime and availability problmes.
Subscribe to:
Posts (Atom)




