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.

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.

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.

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:

1. Make sure your application is in a state matching the action or step you want to run.
2. 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.
3. Select Automation > Run from Step or Run Current Action, or right-click and select Run from Step. The Run dialog box opens.
4. In the Run dialog box, choose where to save the run session results, and define any input parameters you want to use.
5. 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.

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

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.

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

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.

- 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.

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.

• 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.

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

• 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.

- 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