Software Testing Stuff

Test Management and Planning

2009-10-30T10:55:00.001-07:00

Software Testing Estimation Process – It covers some important factors which needs to be taken care while doing estimation.

Organizing the Test Team – One of the important tasks for the Test Manager.

Test Readiness Review Checklist – A sample checklist for Test Leads & Managers to evaluate the readiness of the application released for testing.

Identify Testing Types and Exit Criteria – Identifying various types of testing's required for the application and Exit Criteria, both are very critical for the success of testing effort.

Software Test Planning – The quality of the testing effort is directly proportional to the quality of the test planning.

Testing Bible - Software Test Plan Document – The document usually created after test planning or parallel with the Test Planning effort.

Test Specification - a detailed summary of what all scenarios shall be tested and how they will be tested. It is basically, a part of test planning process.

Test Strategy – Important activity to be done before starting the test planning.

When software is ready to ship or release – It is really difficult to decide whether the software is ready for release or not. Only, an experienced test manager or test lead can make decision of it.

Responsibilities of a Test Manager / Lead – Here is a list of roles and responsibilities of a Test Manager or Test Lead. It will help aspiring Test Managers and leads.

Testing Types, Methods and Strategies

2009-10-30T02:39:00.001-07:00

In my various posts in this web log, I wrote about common and important Testing Types, Methods and Strategies. Below are these topics. Although this is not a complete list, but soon it will increase in size as well as in quality.

Here is the list:

License Errors in LoadRunner

2009-10-21T22:50:00.001-07:00

License – Expired: Your LoadRunner license has expired. Please contact customer support to renew it. You have a time-limited license for your LoadRunner application. Some or all of your license features have expired.

Troubleshooting:

Check your license information to verify whether your license has expired.
Contact customer support to renew your license

License – Renewal: Your LoadRunner licenses are no longer valid. Contact customer support to renew your licenses.
Troubleshooting: Contact customer support to renew your license.

License - Time limit Expired: LoadRunner out of licenses. You have a time-limited license for your LoadRunner application. Some or all of your license features have expired.
Troubleshooting:

Check your LoadRunner license to verify which features have expired.
Contact customer support to renew your license.

License - Vuser Type Not Licensed: You do not have a license for this Vuser type. Please contact customer support to renew your license.
Troubleshooting:

Check your license information to verify whether the license currently installed includes the Vuser types that you are trying to use.
Contact customer support to obtain a license for this Vuser type, or to inform them that you have a problem trying to run a licensed Vuser type.

License - WAN Emulation: You need a license to use the WAN Emulation feature. Please contact customer support for licensing information.
Troubleshooting: Contact customer support for WAN Emulation licensing information.

Also See: Important LoadRunner Tutorials

Replay Tips for Citrix protocol in LoadRunner

2009-10-08T05:55:00.001-07:00

Today, I’m going add one more tutorial in the LoadRunner section. Below are some useful tips to replay a LoadRunner script for citrix protocol:

Set initialization quota: To prevent overloading by multiple Vusers while connecting, set an initialization quota of 4 to 10 Vusers (depending on the capacity of the server) or apply ramp-up initialization using the Scheduler.

Enable think time: For best results, do not disable think time in the Run-Time settings. Think time is especially relevant before the ctrx_sync_on_window and ctrx_sync_on_bitmap functions, which require time to stabilize.

Set consistency between machines: If you intend to replay the script on another machine, make sure that the following items are consistent between the record and replay machines: Window Size (resolution), Window Colors, System Font and the other Default Options settings for the Citrix client. These settings affect the hash value of bitmaps, and inconsistencies may cause replay to fail. To view the Citrix Client settings, select an item from the Citrix program group and choose Application Set Settings or Custom Connection Settings from the right-click menu. Select the Default Options tab.

Increase the numbers of Vusers per machine: Machines running Citrix Vusers may be limited in the number of Vusers that can run, due to the graphic resources available to that machine. To increase the number of Vusers per machine, open a Terminal Server session on the machine. You relate to this Terminal Server as a new injector machine. To refer to the virtual injector machine from the LoadRunner Controller, use the following format: machine_name:1, machine_name:2, ... using either the machine name or its IP address. Note that sessions on a Terminal server use, by default, a 256-color set. If you intend to use a terminal session for load testing, make sure to record on machines with a 256-color set.

Changing window names: In some Citrix sessions, the active window name changes while you are recording. If you try to replay the script as is, the Vuser uses the original window name and the replay may fail. Using the recording options, you can specify a naming convention for the windows in which VuGen uses a common prefix or common suffix to identify the window.

For example, if the original window's name is "Application 1" where the name changes during application's run to "Application 1", you can instruct VuGen to use the common prefix only, "Application".

Alternatively, you can modify the window names in the actual script after recording. In the Script view (View > Script view), locate the window name and replace the end of the window name with the wildcard notation, *. For example, ctrx_sync_on_window ("Application*", ACTIVATE, ...);.

How to correlate a Winsock script in LoadRunner

2009-10-06T05:38:00.001-07:00

For LoadRunner 7.51 and later, users can correlate the dynamic value for a Winsock script from VuGen's Tree View. Below is further information on how it can be accomplished.

To use the Tree View for correlation:

Open the script in VuGen.
Choose View > Tree View.
The Tree View will open with the following structure:
- Function call in the LoadRunner script listed on the left panel.
- Snapshot of the page in the right panel which can be viewed in either Text View or Binary View

To correlate:

Select the lrs_recieve function on the left panel of the Tree View. The contents of the received buffer are displayed in the right panel.
Select either Text View or Binary View. If you work in Text View, you need to clear the Read-only checkbox in the upper right corner.
Search for the dynamic value that you want to capture.
Highlight that value, right-click, and select Create Parameter. There are two ways to create a parameter:
- If the offset of the dynamic value is fixed, highlighting that value will set the correct values for Data Range in the Create Parameter window. This creates the function lrs_save_param.
- If the offset values are not fixed (when the send buffer is parameterized and the response of the server changes in length), look for fixed left and right boundaries to capture the value. Then check Extract Parameter data using boundaries and set the left and right boundaries correctly. This creates function lrs_save_search_string.
VuGen will pop-up with an option for applying the correlation to all occurrences of the value in the script.
- If you select Yes, VuGen will automatically search for this value in all the lrs_send buffers and replace the values with the parameter name.
- If you select No, the correlation will be applied to the current location only.

Also See: Other LoadRunner Tutorials

Important LoadRunner Tutorials

2009-10-05T09:17:00.001-07:00

Below are some the links of eXcellent loadrunner tutorials:

Recording Tips in Load Runner

Recording Problems in LoadRunner

HP Diagnostics and LoadRunner Integration

LoadRunner Automation API

Analysis API in LoadRunner

Vusers in LoadRunner

C Vuser Functions in LoadRunner

LoadRunner VuGen Environment Options

Silent Test Runner

Measuring Transactions

Inserting and Running Tests in LoadRunner or Business Process Monitor

Mercury Performance Testing and Business Availability Center Products

Mercury LoadRunner and Citrix

Citrix ICA Client Integration with LoadRunner

Citrix Load Testing Challenges

How to correlate a Winsock script in LoadRunner

Replay tips for Citrix protocol in LoadRunner

License Errors in LoadRunner

Load Runner - Interview Questions

Note: For further stuff on LoadRunner, please visit our other website: LoadRunnerStuff.com

Recording Tips in Load Runner

2009-10-05T08:56:00.001-07:00

In continuation to my previous post “Recording Problems in Load Runner”, here, I’m going to give you some good and useful tips for doing recording in Load Runner.

Use the mouse and not the keyboard: In LoadRunner, it is preferable to click on an object with the mouse rather then using the keyboard. During recording, use only GUI objects that are within the browser's pane. Do not use any browser icons, controls, the Stop button, or menu items, such as View > Refresh. You may, however, use the Refresh, Home, Back and Forward buttons and the address bar.
Do not record over an existing script : It is best to record into a newly created script—not an existing one.
Avoid context menus: Avoid using context menus during recording. Context menus are menus which pop up when clicking an item in a graphical user interface, such as right-click menus.
Avoid working in a browser while recording: During recording, do not work in any browser window other than the browser windows opened by VuGen.
Wait for downloads: Wait for all downloads to complete before doing any action, such as clicking on a button or filling in a text field.
Wait for pages to load: During recording, it is best to wait for the page to load completely before doing the next step. If you did not wait for all of the pages to load, record the script again.
Navigate to start page: If the last page in an action does not contain the links and buttons that were available at the start of the iteration, then the next iteration will fail. For example, if the first page has a text link Book A Flight, make sure to navigate to the appropriate page at the end of your recording, so that the same link will be visible at the end of the business process.
Use a higher event configuration level: Record the business process again the High Event Configuration level.
Disable socket level recording: In certain cases, the capturing of the socket level messages disrupts the application. For most recordings, socket level data is not required. To prevent the recording of socket level data, disable the option in the recording options. For more information, see the section about recording with Click and Script.
Enable the record rendering-related property values: If the client-side scripts of the application use a lot of styling activities, enable the Record rendering-related property values option before recording the script. For example, enable this option to record additional DOM objects such as offsetTop. Note that enabling this option may decrease the replay speed. To enable record rendering-related property values in Load Runner:

Open the Recording Options. Select Tools > Recording Options and select the GUI Properties:Advanced node

Also See: Other LoadRunner Tutorials

Recording Problems in LoadRunner

2009-10-05T04:49:00.001-07:00

Here, I’m going to describe some common recording problems / issues of Load Runner and how to resolve them. Normally, these problems are faced by everyone. I would request you all that leave your comments for the problems you face and how you tackle them.

Firefox is not supported: Only Internet Explorer is supported for Web (Click and Script). To record browser activity on Firefox, use the Web (HTTP/HTML) protocol.

Application behaves differently while being recorded: If your application behaves differently during recording, than it does without recording, you should determine if the recording problem is unique to Web (Click and Script). The effect may be that a Web page will not load, part of the content is missing, a popup window does not open, and so forth. Create a new Web (HTTP/HTML) script and repeat the recording. In the event that the recording is OK in Web (HTTP/HTML), we recommend that you disable socket level recording. The problem may be the result of an event listener. Use trial and error to disable event listeners in the Web Event Configuration Recording Options, and then re-record your session as a Web (Click and Script) user. To disable an event listener:

Open the Recording Options. Select Tools > Recording Options and select the GUI Properties:Web Event Configuration node.
Click Custom Settings and expand the Web Objects node. Select an object.
Select Disabled from the list in the Record column for the relevant Web object. If the recording still does not work, enable the listener you previously disabled, and try disabling another one. Repeat these steps until your recording succeeds.

Dynamic menu navigation was not recorded: A dynamic menu is a menu that dynamically changes depending on where you select it. If the dynamic menu navigation was not recorded, record again using "high" event configuration mode. To set the configuration level to high:

Open the Recording Options. Select Tools > Recording Options and select the GUI Properties:Web Event Configuration node.
Move the slider to High.

Certain user actions were not recorded: Check if there is a Java applet running inside the browser. If not, record the script with the Web (HTTP/HTML) protocol.

Also See: Other LoadRunner Tutorials

Latest QTP Training Material and Tutorials

2009-10-02T03:15:00.000-07:00

Here are the links of some good QTP tutorials. Beginners can use these tutorials as a training material. Read these and give your feedback for improvement.

Selenium - Overview

2009-08-30T05:26:00.001-07:00

Selenium is a portable software testing framework for web applications. The tests can be written as HTML tables or coded in a number of popular programming languages and can be run directly in most modern web browsers. Selenium can be deployed on Windows, Linux, and Macintosh. Selenium is used for UAT (User Acceptance Test).

Selenium consists of

- Selenium Core
- Selenium RC
- Selenium Grid
- Selenium on Rails
- Selenium IDE

Selenium IDE:

Selenium IDE is a complete Integrated Development Environment (IDE) for Selenium tests (previously known as Selenium Recorder). Firefox extension that allows recording and editing of tests. It allows easier development of tests. It can output Ruby for it’s Ruby based (Application Programming Interface) API.

Selenium IDE Features:

- Record and playback
- Intelligent field selection will use IDs, names, or XPath as needed
- Auto complete for all common Selenium commands
- Walk through test cases and test suites.
- Debug and set breakpoints
- Save tests as HTML, Ruby scripts, or other formats
- Support for Selenium user-extensions.js file
- Option to automatically assert the title of every page
- Rollup common commands

Selenium IDE License:

Selenium was developed by a team of programmers and testers at Thought Works. Selenium is open source software, released under the Apache 2.0 license and can be downloaded and used without charge. The Selenium Grid provides a hub allowing the running of multiple Selenium tests concurrently on any number of local or remote systems, thus minimizing test execution time.

Selenium Interview Questions - 1

2009-08-30T05:09:00.001-07:00

Q1. What is Selenium?

Ans. Selenium is a set of tools that supports rapid development of test automation scripts for web

based applications. Selenium testing tools provides a rich set of testing functions specifically

designed to fulfil needs of testing of a web based application.

Q2. What are the main components of Selenium testing tools?
Ans. Selenium IDE, Selenium RC and Selenium Grid

Q3. What is Selenium IDE?
Ans. Selenium IDE is for building Selenium test cases. It operates as a Mozilla Firefox add on and

provides an easy to use interface for developing and running individual test cases or entire test

suites. Selenium-IDE has a recording feature, which will keep account of user actions as they are

performed and store them as a reusable script to play back.

Q4. What is the use of context menu in Selenium IDE?
Ans. It allows the user to pick from a list of assertions and verifications for the selected location.

Q5. Can tests recorded using Selenium IDE be run in other browsers?
Ans. Yes. Although Selenium IDE is a Firefox add on, however, tests created in it can also be run in

other browsers by using Selenium RC (Selenium Remote Control) and specifying the name of the test

suite in command line.

Q6. What are the advantage and features of Selenium IDE?

Ans. 1. Intelligent field selection will use IDs, names, or XPath as needed
2. It is a record & playback tool and the script format can be written in various languages including

C#, Java, PERL, Python, PHP, HTML
3. Auto complete for all common Selenium commands
4. Debug and set breakpoints
5. Option to automatically assert the title of every page
6. Support for Selenium user-extensions.js file

Q7. What are the disadvantage of Selenium IDE tool?
Ans. 1. Selenium IDE tool can only be used in Mozilla Firefox browser.
2. It is not playing multiple windows when we record it.

Q8. What is Selenium RC (Remote Control)?
Ans. Selenium RC allows the test automation expert to use a programming language for maximum

flexibility and extensibility in developing test logic. For example, if the application under test returns

a result set and the automated test program needs to run tests on each element in the result set, the

iteration / loop support of programming language’s can be used to iterate through the result set,

calling Selenium commands to run tests on each item.

Selenium RC provides an API and library for each of its supported languages. This ability to use

Selenium RC with a high level programming language to develop test cases also allows the automated

testing to be integrated with the project’s automated build environment.

Q9. What is Selenium Grid?

Ans. Selenium Grid in the selenium testing suit allows the Selenium RC solution to scale for test suites

that must be run in multiple environments. Selenium Grid can be used to run multiple instances of

Selenium RC on various operating system and browser configurations.

Q10. How Selenium Grid works?

Ans. Selenium Grid sent the tests to the hub. Then tests are redirected to an available Selenium RC,

which launch the browser and run the test. Thus, it allows for running tests in parallel with the entire

test suite.

Q 11. What you say about the flexibility of Selenium test suite?
Ans. Selenium testing suite is highly flexible. There are multiple ways to add functionality to Selenium

framework to customize test automation. As compared to other test automation tools, it is

Selenium’s strongest characteristic. Selenium Remote Control support for multiple programming and

scripting languages allows the test automation engineer to build any logic they need into their

automated testing and to use a preferred programming or scripting language of one’s choice.

Also, the Selenium testing suite is an open source project where code can be modified and

enhancements can be submitted for contribution.

Q12. What test can Selenium do?
Ans. Selenium is basically used for the functional testing of web based applications. It can be used for

testing in the continuous integration environment. It is also useful for agile testing

Q13. What is the cost of Selenium test suite?
Ans. Selenium test suite a set of open source software tool, it is free of cost.

Q14. What browsers are supported by Selenium Remote Control?
Ans. The test automation expert can use Firefox, IE 7/8, Safari and Opera browsers to run tests in

Selenium Remote Control.

Q15. What programming languages can you use in Selenium RC?
Ans. C#, Java, Perl, PHP, Python, Ruby

Q16. What are the advantages and disadvantages of using Selenium as testing tool?
Ans. Advantages: Free, Simple and powerful DOM (document object model) level testing, can be used

for continuous integration; great fit with Agile projects.

Disadvantages: Tricky setup; dreary errors diagnosis; can not test client server applications.

Q17. What is difference between QTP and Selenium?
Ans. Only web applications can be testing using Selenium testing suite. However, QTP can be used for

testing client server applications. Selenium supports following web browsers: Internet Explorer,

Firefox, Safari, Opera or Konqueror on Windows, Mac OS X and Linux. However, QTP is limited to

Internet Explorer on Windows.

QTP uses scripting language implemented on top of VB Script. However, Selenium test suite has the

flexibility to use many languages like Java, .Net, Perl, PHP, Python, and Ruby.

Q18. What is difference between Borland Silk test and Selenium?
Ans. Selenium is completely free test automation tool, while Silk Test is not. Only web applications

can be testing using Selenium testing suite. However, Silk Test can be used for testing client server

applications. Selenium supports following web browsers: Internet Explorer, Firefox, Safari, Opera or

Konqueror on Windows, Mac OS X and Linux. However, Silk Test is limited to Internet Explorer and

Firefox.

Silk Test uses 4Test scripting language. However, Selenium test suite has the flexibility to use many

languages like Java, .Net, Perl, PHP, Python, and Ruby.

Object Repository Types in QTP

2009-08-29T08:06:00.001-07:00

Test objects can be stored in two types of object repositories—a shared object repository and a local object repository. A shared object repository stores test objects in a file that can be accessed by multiple components (via their application areas) in read-only mode. A local object repository stores objects in a file that is associated with one specific component, so that only that component can access the stored objects.

When you plan and create components, you must consider how you want to store the objects in your components. You can store the objects for each component in its corresponding local object repository, or you can store the objects in your components in one or more shared object repositories. By storing objects in shared object repositories and associating these repositories with your components’ application areas, you enable multiple components to use the objects. For each component, you can use a combination of objects from your local and shared object repositories, according to your needs. You can also transfer local objects to a shared object repository, if required. This reduces maintenance and enhances the reusability of your components because it enables you to maintain the objects in a single, shared location instead of multiple locations.

If you are new to using QTP, you may want to use local object repositories. In this way, you can record and run components without creating, choosing, or modifying shared object repositories because all objects are automatically saved in a local object repository that can be accessed by its corresponding component. If you modify an object in the local object repository, your changes do not have any effect on any other component.

If you are familiar with testing, it is probably most efficient to save objects in a shared object repository. In this way, you can use the same shared object repository for multiple components—if the components include the same objects. Test object information that applies to many components is kept in one central location. When the objects in your application change, you can update them in one location for all the components that use this shared object repository.

If an object with the same name and description is located in both the local object repository and in a shared object repository associated with the same component, the component uses the local object definition. If an object with the same name and description is located in more than one shared object repository associated with the same component, the object definition is used from the first occurrence of the object, according to the order in which the shared object repositories are associated with the component.

Local objects are saved locally with the component, and can be accessed only from that component. When using a shared object repository, you can use the same object repository for multiple components. You can also use multiple object repositories for each component.

When you open and work with an existing component, it always uses the object repositories that are specified in the application area with which the component is associated. Shared object repositories are read-only when accessed from components; you edit them using the Object Repository Manager.

Testing Business Components using QTP and Quality Center

2009-08-29T08:01:00.001-07:00

Generally, business components are created and modified in Quality Centre by Subject Matter Experts. However, you can use the Business Component Keyword View to create, view, modify, and debug a business component in QTP, if required.

In the Keyword View, business components are divided into steps in a modular, keyword-driven, table format. Each step is a row that comprises individual parts that you can easily modify. You create and modify steps by selecting items and operations and entering additional information, as required.

Each step in a business component is automatically documented as you complete it. This enables you to view a description of the step in understandable sentences. In addition, if you added a function library to the application area associated with the business component, when you define a step by selecting a user-defined operation (function), the documentation that you added in the function library will be displayed for the step.

Before you create or open a business component, you connect QTP to a Quality Centre project, which is where business components and application area resources and settings are stored. Connecting to your Quality Centre project enables QTP to create or open the business component. This also enables the business component to access all of the resources defined in the application area on which the component is based.

Important Note: Make sure you have the required Quality Centre permissions before working with business components and application areas.

If the application area you select does not yet contain all of the required resources and settings, you can still add steps using the ManualStep function or the Comment option. This enables you to type in manual steps as you would in Quality Centre or in another application, such as Microsoft Excel or Microsoft Word. You can also use comments to add information about a step or to separate sections of your business component. Each manual step and comment appears as a separate row in the Keyword View.

If you want to delete a component, you can do so only in Quality Centre, regardless of whether it was created in QTP or in Quality Centre.

Also, if needed, you can convert a business component to a scripted component.

Running Part of Test Script in QTP

2009-08-08T00:36:00.001-07:00

You can use the Run from Step option to run a selected part of your test. This enables you to check a specific section of your application or to confirm that a certain part of your test runs smoothly.

In the Expert View, you can use the Run from Step option to run your test from the selected step until the end of the action. Using Run from Step in this mode ignores any iterations. However, if the action contains nested actions, QTP runs the nested actions for the defined number of iterations of the nested action.

In the Keyword View, you can use the Run from Step option to run your test from the selected step until the end of the test (if the selected step is not part of a reusable action, because a reusable action needs to be called from a test, in order for the test to know from where to continue). Using Run from Step in this mode includes all iterations. The first iteration will run from the step you selected until the end of the test; all other iterations will run from the beginning of the test.

You can use the Run Current Action option to run a single action in your test. Using Run Current Action ignores any iterations. However, if the action contains nested actions, QTP runs the nested actions for the defined number of iterations.

Please note, if you only want to run one iteration of your test, select Run one iteration only from the Run pane in the Test Settings dialog box.

If you want to run your test until a specific point within the test (and not to the end of the action or test), you can insert a breakpoint. The test will then run from the selected step or action until the breakpoint.

To run an entire action, or run a test or action from a selected step:

Make sure your application is in a state matching the action or step you want to run.
Select the action or step where you want to start running the test. Make sure that the step or action you choose is not dependent on previous steps, such as a retrieved value or a parameter defined in a previous step.
Select Automation > Run from Step or Run Current Action, or right-click and select Run from Step. The Run dialog box opens.
In the Run dialog box, choose where to save the run session results, and define any input parameters you want to use.
Click OK. The Run dialog box closes and the run session starts

By default, when the run session ends, the Test Results window opens. The Test Results summary displays a note indicating that the test was run using the Run from Step or Run Current Action option.

If you cleared the View results when run session ends check box in the Run pane of the Options dialog box, the Test Results window does not open at the end of the run session.

Debugging an Action or a Function in QTP

2009-08-08T00:33:00.001-07:00

Suppose you create an action or a function that defines variables that will be used in other parts of your test or function library. You can add breakpoints to the action or function to see how the value of the variables changes as the test or function library runs. To see how the test or function library handles the new value, you can also change the value of one of the variables during a breakpoint.

This can be done by following below simple steps:

Step 1: Create a New Action or Function: Open a test and insert a new action, or open a new function library and create a new function called SetVariables.

If you are working in the Expert View, then follow Step 4 directly. If you are working in a function library, continue with Step 2 and Step 3.

Step 2: (For Function Libraries Only) Associate the Function Library with a Test: Make sure the function library is in focus. Select File > Associate Library ‘<Function Library Name>’ with ‘<Test Name>’. QuickTest associates the function library with your test.

Step 3: (For Function Libraries Only) Add a Call to the Function in Your Test: Add a call to the function by inserting a new step and typing the following in the Expert View: SetVariables.

Step 4: Add Breakpoints: Add breakpoints at the appropriate lines.

Step 5: Begin Running the Test: Run the test. The test or function library stops at the first breakpoint, before executing that step (line of script).

Step 6: Check the Value of the Variables in the Debug Viewer Pane:

Step 7: Check the Value of the Variables at the Next Breakpoint: Click the Run button to continue running the test. The test stops at the next breakpoint.

Step 8: Modify the Value of a Variable Using the Variables Tab

Step 9: Modify the Value of a Variable Using the Command Tab

Step 10: Repeat a Command from the Command History

Handling Run Errors in QTP

2009-08-08T00:30:00.001-07:00

There are two types of Run Error message boxes that can be displayed during a run session in QTP. One is displayed if the problem is a pure VBScript syntax error. When a syntax run error message box is displayed, click OK in the message box and address the error in your step.

The other message box can be displayed in a number of situations. It offers information about the error and a number of buttons for dealing with errors encountered:

Stop: Stops the run session. The run results are displayed if QTP is configured to show run results after the run.

Retry: QTP attempts to perform the step again. If the step succeeds, the run continues.

Skip: QTP skips the step that caused the error, and continues the run from the next step.

Debug: QTP suspends the run, enabling you to debug the test and any associated function library that contains a function called by the test. You can perform any of the debugging operations described in this section. After debugging, you can continue the run session from the step where the test or function library stopped, or you can use the step commands to control the remainder of the run session.

Help: Opens the QTP troubleshooting Help for the displayed error message. After you review the Help topic, you can select another button in the error message box.

The message box also recommends that you consider using Maintenance Mode if you think the error is due to intentional changes in your application and requires that you update multiple steps in your test or objects in your repository.

HP Diagnostics and LoadRunner Integration

2009-08-08T00:28:00.001-07:00

The HP Diagnostics integration with LoadRunner allows you to monitor and analyze the performance of Java 2 Enterprise Edition (J2EE), .NET-connected, SAP, Oracle, and other complex environments.

Specifying the Diagnostics Server Details: The first time you use LoadRunner to capture J2EE or .NET diagnostics data, you need to identify the machine on which the Diagnostics Server in Commander mode is running, and the port that it is using for communication with LoadRunner. You must update this information if you want to integrate with a different Diagnostics Server in Commander mode, or if you change the port it is using. To update the LoadRunner configuration settings for HP Diagnostics:

1. Select Start > Programs > HP LoadRunner > LoadRunner to open the LoadRunner launcher window.

2. From the LoadRunner launcher window menu, select Configuration > Diagnostics for J2EE/.NET Setup to open the Diagnostics for J2EE/.NET Setup dialog box. Enter the details for the Diagnostics Server in Commander mode.

3. Click Test to verify that you entered the correct information for the Diagnostics Server in Commander mode and that there is connectivity between the Diagnostics Server in Commander mode and LoadRunner. Click OK to complete the configuration process.

Configure LoadRunner Scenarios to use HP Diagnostics

1. Before configuring your scenario for Diagnostics, ensure that the application server that you are monitoring has been started.

2. In the Controller, open the relevant load test scenario (FIle > Open) or create a new scenario (File > New).

3. Select Diagnostics > Configuration to open the Diagnostics Distribution dialog box.

4. Set the percentage of Vusers to participate in the HP Diagnostics (J2EE/.NET Diagnostics) monitoring. The maximum percentage of Vusers for which HP Diagnostics (J2EE/.NET Diagnostics) data can be collected is 100%, unless you have enabled other types of diagnostics. In this case, the percentage of Vuser participation in HP Diagnostics (J2EE/.NET Diagnostics) cannot exceed the maximum of any of the other types of diagnostics that you enabled.

5. In the Online & Offline Diagnostics section of the Diagnostics Distribution dialog box, next to J2EE/.NET Diagnostics, click Configure. The J2EE/.NET Diagnostics Configuration dialog box opens.

6. Select Enable J2EE/.NET Diagnostics

7. In the Select probes list, select the probes to be included in your load test scenario.

8. If the Diagnostics Server (or a Diagnostics Server in Mediator mode in a distributed environment) is located behind a firewall, select There is a firewall between the mediator and the Controller, and enter the name of the MI listener server in the MI listener server box. If there is a firewall between the LoadRunner Controller and the Diagnostics Server involved in a load test, you must configure the Controller and the Diagnostics Server to use the MI Listener to enable the transfer of the offline analysis file.

9. To capture a percentage of server requests which occur outside the context of any Vuser transaction select Monitor server requests.

10. To investigate any issues that you have with the connections between the Diagnostics components, click the Troubleshoot Diagnostics for J2EE/.NET connectivity link. This will open the HP Diagnostics System Health Monitor in a new browser window.

During a LoadRunner load test scenario, you can view HP Diagnostics data for the whole scenario or you can drill down to HP Diagnostics data from a particular transaction. After you have run your scenario, you can use HP LoadRunner Analysis to analyze offline Diagnostics data generated during the scenario.

Also See: Other LoadRunner Tutorials

Debugging Components and Function Libraries in QTP

2009-08-07T09:46:00.001-07:00

In QTP, after you create a component or function library including registered user functions, you should check that they run smoothly, without errors in syntax or logic. To debug a function library, you must first associate it with a component via its application area and then debug it from that component.

To detect and isolate defects in a component or function library, you can control the run session using the Pause command as well as various step commands that enable you to step into, over, and out of a specific step.

You can use the Start from Step command to begin your debug session at a specific point in your component. You can also use the Run to Step command to pause the run at a specific point in your component. You can set breakpoints, and then enable and disable them as you debug different parts of your component or function library.

When the component or function library run stops at a breakpoint, you can use the Debug Viewer to check and modify the values of VBScript objects and variables. Also, if QTP displays a run error message during a run session, you can click the Debug button on the error message to suspend the run and debug the component or function library.

You can also use the Run from Step command to run your component or function library from a selected step to the end. This enables you to check a specific section of your application or to confirm that a certain part of your component or function library runs smoothly.

Important things to remember:

While the component and function libraries are running in debug mode, they are read-only. You can modify the content after you stop the debug session. If needed, you can enable the function library for editing (File > Enable Editing) after you stop the session. After you implement your changes, you can continue debugging your component and function libraries.
If you perform a file operation, the debug session is stopped.
In QTP, when you open a component, QTP creates a local copy of the external resources that are saved to your Quality Center project. So, any changes you apply to any external resource that is saved in your Quality Center project, such as a function library, will not be implemented in the component until the component is closed and reopened.

Please note, an external resource is any resource that was not created using QTP, such as, a function library created in an external editor.

LoadRunner Automation API

2009-08-07T09:38:00.000-07:00

The LoadRunner Automation API allows execution of LoadRunner scenarios without using the LoadRunner Controller Graphic User Interface. Using the LoadRunner Automation API, you create programs that define and run scenarios. You might use the API, for example, to run tests at night or to run tests as part of another program.

The central object of the LoadRunner automation API is LrEngine object. When LrEngine is created, it will connect to an existing instance of the LoadRunner Controller or launch a new one.

Use LrEngine to access and program the scenario object that determines the properties of the test to be run, and to access Events related to groups, hosts, scenarios and rendezvous.

Exceptions: LoadRunner Automation handles most errors by generating an exception rather than a return code. In general, the return codes only indicate that the function ran successfully. A return code of zero does not indicate that the action was performed successfully.

You can catch the exceptions by writing your own exception handlers or using standard error classes. Errors in creating objects can be detected by checking if the object is Nothing.

Glossary of terms used in LoadRunner Automation Library:

Controller: The LoadRunner Controller provides a graphic user interface for controlling and managing load test scenarios.

Group: A logical collection of virtual users, usually running the same script.

Host: A machine that executes one or many virtual user scripts, enabling the virtual user to emulate the actions of a human user. When you execute a scenario, the Controller distributes each virtual user in the scenario to a host.

Rendezvous: Emulates heavy user load on the application. You insert rendezvous points into virtual user scripts to ensure that multiple virtual users act simultaneously. For example, to emulate peak load on a bank application, you can insert a rendezvous point instructing 100 virtual users to transfer funds within their accounts at the same time.

Rendezvous Group: A collection of rendezvous.

Scenario: A class that includes a number of scripts to be run, and specifies the hosts that will run the scripts and the virtual user groups associated with each one.

Script: Describes the acts that a virtual user performs during scenario execution. When you run a scenario, each virtual user executes a script. The virtual user scripts include functions that measure and record the performance of your application.

Vuser: A virtual user. When you run a scenario, Vusers emulate the actions of human users, operating your application. A scenario can contain tens or thousands of Vusers. To emulate conditions of heavy user load, you create a large number of Vusers that perform a series of tasks.

Also See: Other LoadRunner Tutorials

Some Facts in Software Testing

2009-08-07T06:44:00.001-07:00

- Software Testing can not show the absence of errors

- There is no last bug in the software / application

- Maximum coverage through minimum test cases is a big challenge of testing.

- Even for simple program of loops, there can be over million paths – testable manually in million years. Domain of possible inputs is too large to test. Also, there are too many possible paths to test the program. Even if, theoretically speaking, one could design excellent test cases to detect all defects, does one have the luxury of time and resources to do so in practice?

- Preventive testing is very important. Verify documents, design, code at each stage of development to prevent errors from getting in. Use a variety of techniques for this. Code review itself throughs up many defects that may be too difficult to detect by execution of tests. On the other hand, test execution can detect errors that can not be easily detected by code reviews. Therefore, various techniques are complimentary in nature and it is only through their combined use that one can hope to detect most errors.

- Even though development tends to be given more importance than testing. A good test design is perhaps intellectually more challenging than the software design and development. Given reasonable practical limits to the quality of test design in practice, it is easy to understand that why it is difficult to uncover all defects through testing.

Analysis API in LoadRunner

2009-08-06T07:20:00.001-07:00

This API set can be used for the following purposes:

Unattended creation of an Analysis session that can then be opened in the HP LoadRunner Analysis.
Custom extraction of data from the results of a test run under the HP LoadRunner Controller

An application that creates an Analysis session can be run automatically at completion of a test run. In the LoadRunner Controller, open Tools > Options and select the Execution tab. Enter the command to run your application in the Post Execution Command box.

The API set provides the following functionality:

Convert Controller Run results to an Analysis data base file
Create, modify, and apply a global filter and Graph filters
Set graph parameters
Calculate metrics and statistics per Graph in a Run
Notifications from the API infrastructure to the API application
Logging at different severity levels
Ability to run concurrent, independent instances of API-based applications

Limitations: This version of the API set does not support:

Graph auto-correlation
Graph merging
Importing data from external monitors
XML export of data
Support Level Agreements functionality
Use of filters, graphs, and other configurations created in the Analysis user interface
J2EE Graphs are only partially supported

Prerequisites: To use this API set, you must:

Be a .NET programmer
Be familiar with the Controller and Analysis programs

The development environment requires:

Visual Studio 2005 or any other compiler that supports .NET 2.0
LoadRunner Analysis

The runtime environment requires:

LoadRunner Analysis
A .NET configuration file. A command-line utility to build the configuration file is provided in the <Analysis installation>\Additional Components\AssemblyCrawler folder.

Also See: Other LoadRunner Tutorials

Oracle Add-in for QTP

2009-08-06T07:13:00.000-07:00

After installing the Oracle Add-in, your applications will always open with Java support active. You can confirm that your Oracle environment has opened properly by checking the Java console for the confirmation message similar to: Loading Oracle Support (version x.x build xxx) (Oracle Corporation x.x.x.xx)

The QTP Oracle Add-in supports only Oracle clients that are Java-based. Oracle Developer/2000 is not supported.

Before using the Oracle Add-in to test Oracle Applications, you must first enable the Name attribute supplied by the Oracle Applications server.

The Oracle Applications server supplies a unique Name attribute for many application objects. You can also find the Oracle Applications server Name attribute in the Oracle Add-in developer name identification property. The developer name identification property is used by QTP in most test object descriptions to identify Oracle objects.

In QTP, table data is always loaded from the application itself, even if the Active Screen contains an image of the table. For this reason, you must first open the table in the application before creating a table checkpoint in a test
In some cases you may have to scroll to the last row of the table to make sure that all the data is loaded

If the table object is not open in your application when you create the checkpoint, the Table Checkpoint Properties dialog box contains only the Properties tab, and the option to select which type of information to check (content or properties) is disabled

It is not necessary to open the table in your application to edit an existing table checkpoint.

Vusers in LoadRunner

2009-08-01T21:17:00.001-07:00

Vusers emulate the actions of human users by performing typical business processes in your application. The actions that a Vuser performs during the recording session are described in a Vuser script.

HP’s tool for creating Vuser scripts is the Virtual User Generator, VuGen. You use VuGen to develop a Vuser script by recording a user performing typical business processes on a client application. VuGen records the actions that you perform during the recording session, recording only the activity between the client and the server. Instead of having to manually program the application’s API function calls to the server, VuGen automatically generates functions that accurately model and emulate real world situations.

During recording VuGen monitors the client end of the database and traces all the requests sent by the user and received from the user, to the server.

During playback, Vuser scripts communicate directly with the server by executing calls to the server API. When a Vuser communicates directly with a server, system resources are not required for the client interface. This lets you run a large number of Vusers simultaneously on a single workstation, and enables you to use only a few testing machines to emulate large server loads.

In addition, since Vuser scripts do not rely on client software, you can use Vusers to check server performance even before the user interface of the client software has been fully developed.

Using VuGen, you can run scripts as standalone tests. Running scripts from VuGen is useful for debugging as it enables you to see how a Vuser will behave and which enhancements need to be made.

VuGen enables you to record a variety of Vuser types, each suited to a particular load testing environment or topology. When you open a new test, VuGen displays a complete list of the supported protocols.

While running the Vusers, you gather information about the system’s response. Afterwards, you can view this information with the Analysis tool. For example, you can observe how a server behaved when one hundred Vusers simultaneously withdrew cash from a bank’s ATM.

Also See: Other LoadRunner Tutorials

Working with the Java Add-in in QTP

2009-08-01T10:29:00.001-07:00

When learning objects and running steps on Java applications in QTP, consider the following:

After installing the Java Add-in, Java applets and applications will always open with Java support active. You can confirm that your Java environment has opened properly by checking the Java console for a message similar to the following confirmation message: “Loading QTP Java Support (version x.x.x.x) (<App> version x.x.x.x).” (where <App> is IE, IBM, or SUN).

You can use the Object test object property to activate only public methods and to retrieve only public properties. A recommended alternative to using the Object property is to extend QTP support for the required Java object using QTP Java Add-in Extensibility.

You cannot add SWT-based JavaMenu objects directly to an object repository using the Add Objects to Local button in the Object Repository window or the Add Objects button in the Object Repository Manager. If you want to add an SWT-based JavaMenu object to the object repository, you can use the Add Objects or Add Objects to Local button to add its parent object and then select to add the parent object together with its descendants. Alternatively, you can add a JavaMenu object using the Navigate and Learn option in the Object Repository Manager.

In QTP, table data is always loaded from the application itself, even if the Active Screen contains an image of the table. For this reason, you must first open the table in the application before creating a table checkpoint in a test. In some cases you may have to scroll to the last row of the table to make sure that all the data is loaded. It is not necessary to open the table in your application to edit an existing table checkpoint.

If you load or unload an add-in that is displayed as a child of the Java add-in in the Add-in Manager, only applications that are opened after loading or unloading the add-in are affected.

Why does software have bugs

2009-08-01T10:27:00.001-07:00

- Errors of Requirements: Gap between “what an application should do” and “what it actually does”. Thanks to one or more of the many possible reasons – deficiency in the specifications or the communication or understanding.

- Errors of Design: Not a well-engineered application. Deficient / defective design.

- Programming / coding errors

- Software Complexity: A non-trivial application has an inherent complexity

- Errors are difficult to detect

- The domain of possible inputs is too large to test. There are too many possible paths through the program to test. Test design is not a simple affair. Minimal tests with maximum coverage is not an easier task.

- Insufficient time to test

- Deficiency in Documentation: Incomplete, incorrect, inadequate, vague, missing documentation – leading to differing interpretations and messing up of construction or maintenance. It is tough to maintain and modify code that is badly written or poorly documented and risky too. Lack of resources, time pressures and bad practices may mean poor documentation

- Changing Requirements: The customer may not understand the effect of changes. Improperly controlled changes may play havoc with the application

- Time Pressures: Software time estimates are after all just that estimates which involves a lot of guess work and assumptions. When deadlines loom and the crunch comes, mistakes will be made

- Software helps automate. But, software to automate software construction does not exist – there are tools to only partially assist

- Software construction is predominantly a manual process. Software is written by people. People make mistakes. Software reflects those mistakes

- Defect Masking: A defect may have remained hidden/masked on account of another defect. Only when the defect, masking the defect, is removed, the masked defect get exposed