Tag Archives: automated

[Slide] Automated Web Testing with Selenium for beginners

6 Jun

You can find useful information for this presentation.

1. What is Selenium?

– Test tool for web applications
– Runs in any mainstream browser
– Supports tests in many languages
– Selenese (pure HTML, no backend required)
– Java, C#, Perl, Python, Ruby
– Record/playback (Selenium IDE)
– Open Source with corporate backing
– Lives at selenium.openqa.org

2. Demo

– Record a test in Selenium IDE
– Show same test written in Java

You can download in link

Source from Erik Doernenburg, ThoughtWorks

Why Your Selenium Tests Are So Dang Brittle

31 May

If you are writing automated through-the-GUI tests for a web application, you are in danger of creating software tests that are more expensive to maintain than they are worth. With well-factored Selenium RC tests running in Junit or TestNG, you can keep your abstraction layers or “Lingos” – small bounded bits of slang for discrete parts of the object model – separate, thereby reducing the maintenance costs of your tests, and improving your sanity.

In this webinar to learn:
– How and why automated web app code gets so dang brittle
– Why the expressiveness, readability, and fluency of your test code is so important to its maintenance cost
– Some basic, useful OOD patterns for writing very expressive web app tests using Selenium RC, in Java and in C#/.NET
– Some useful OOD principles to guide your design decisions, like keeping modules small, the SRP, DRY, “Lingos”, and “Lingual Design”
– Some OOD principles worth violating, frequently, when writing automated test code, because it’s just very different from application code
– How and why to prefer element locators like Id and Value attributes to xPath; how to keep xPath least brittle
– An introduction to Domain Specific Languages (DSLs) built on top of Selenium RC, using FitNesse
– An introduction to “fluent” Selenium RC testing using Scala

Source: http://pillartechnology.com/


31 May

The testing process has these 4 steps :
• Creating a testplan (if you are using the testplan editor)
• Recording a test frame.
• Creating testcases
• Running testcases and interpreting their results.
Creating a testplan
If the testplan editor is used, the automated testing process is started by creating a testplan. A basic testplan is structured as a hierarchical outline and contains:
• Descriptions of individual tests and groups of tests. As many levels of description can be used.
• Statements that link the test descriptions in the plan to the 4Test routines, called testcases, that accomplish the actual work of testing.
Recording a test frame
Next, record a test frame, which contains descriptions, called window declarations, of each of the GUI objects in your application. A window declaration specifies a logical, cross-platform name for a GUI object, called the identifier, and maps the identifier to the object’s actual name, called the tag. In addition, the declaration indicates the type of the object, called its class.
Creating testcases

The 4Test commands in a testcase collectively perform three distinct actions :
• Drive the application to the state to be tested.
• Verify the state (this is the heart of the testcase).
• Return the application to its original state.
The powerful object-oriented recorder can be used to automatically capture these 4Test commands to interact with the application, or to white the 4Test code manually if one is comfortable with programming languages. For maximum ease and power, these two approaches can be combined, recording the basic testcase and then extending it using 4Test’s flow of control features.
Running testcases and interpreting results
Next, run one or more testcases, either by running a collection of scripts, called a suite, or, if you are using the testplan editor, by running specific portions of the testplan. As each testcase runs, statistics are written to a results file. The results file and its associated comparison tools allow you to quickly pinpoint the problems in your application.
A Test Frame
The test frame is the backbone that supports the testcases and scripts. It is a file that contains all the information about the application’s GUI objects that Silk Test needs when you record testcases. This information minimally consists of a declaration for each GUI object, but can also include any data that you want to associate with each GUI object, as well as any new classes and methods that you want to define.
A window declaration specifies a cross-platform, logical name for a GUI object, called the identifier, and maps the identifier to the object’s actual name, called the tag. Because the testcases use logical names, if the object’s actual name changes on the current GUI, on another GUI, or in a localized version of the application, only the tag in the window declarations need to be changed; don’t need to change any of the scripts. Variables, functions, methods, properties can be added to the basic window declarations recorded by Silk Test.
To record declarations for the main window and menu hierarchy of your application.

1. Start up your application and Silktest.
2. Select File / New. The New dialog appears.
3. Select the Test Frame radio button and click OK. The New Test Frame dialog is displayed, allowing to create a test.
4. Frame file for an application displayed in the Application list box.
5. Select the application fro the Application list box. If a Web application is tested, different fields are seen.
6. Click OK. The new test frame file is created. The file contains the 4Test declarations for the main window and all its menus, as well as a generic declaration that is valid for each of the standard message boxes in the application.

A Test Plan
A Testplan is made up of a large amount of information, a structured, hierarchical outline provides an ideal model for organizing and developing the details of the plan. A testplan consists of two distinct parts
• An outline that describes the test requirements
• Statement that connect the outline to the 4Test scripts and testcases that implement the test requirements.
Using the testplan, we can create and run tests.

To start a new testplan :
• Select File / New
• Select Testplan and click OK.
An empty testplan window opens.

A Test Suite
A Test Suite is a collection of test scripts. Consider a case that we are having a set of script (.t) file. If we want to run these scripts against our application, we have to select the required testcase or we have to run the entire script file. But after the completion of that script file, the user has to manually change that to the next script file to run those testcases available in that script. Instead of that silktest provides a way to continuously select a set of script files and run those script files at-a-stretch. This can be done by creating a new Test Suite file and declare the needed script files in that suite file.
To start a new test suite:

1. Select File / New.
2. Select Test Suite and click OK.
3. In that suite file enter the script file names to run continuously.
4. Save that script file.
5. Compile the script file and run it.
6. Now the process of running the script will not stop after the completion of the first script file, instead of that it will automatically pass to the next script file and run the testcases available there.
Assume a case where there is a folder called silk scripts in c drive with five test script files. Here in the suite file, we are calling all the script files instead of running those script files separately. The suite file will look like as given below :
use c:\silkscripts.\script.t” use c:\silkscripts.\script2t” use “c:\silkscripts./script3.t” use “c:\silkscripts\script4.t” use “c:\silkscripts\5.”

A Test script

A testscript file contains various testcases for various test conditions.

A Testcase
In a script file, a testcase ideally addresses one test requirement. Specifically, a 4Test function that begins with the testcase keyword and contains a sequence of 4Test statements. It drives an application to the state to be tested, verifies that the application works as expected, and returns the application to its base state.
• In the silktest tool, select the File -> Now option the menu bar.
• In the resulting dialog box �New�, there will be options for selecting different kind of files.
• Select the file type 4� test script� option.
• It will open a new script file.
• Before start writing the testcase, declare the necessary file that is to be used in that script file.
• Start with the keyword �testcase� followed by the testcase name. The name of the testcase is whatever as selected by the user. But make sure that by looking at the name of the testcase, the objective of the testcase should be understandable.
• Start the tests from the scratch so that the silktest will start eh application and to the testing from the base state.
• Use necessary conditions / loops if necessary.
• At the end of each and every script, print a statement to know whether the test case has achieved its objective or not. The user can make sure that the particular part of the application is error free by looking at the message you print.
• Try to make the testcase effective and time consuming (say) by keeping the second tests continue from the place where the first test finishes.
• A sample testcase for registering into the yahoo mail.
Testcase registration ()
• Browser.LoadPage “mail.yoo.com”)
• Sign In YahooMail.SetActive ()
• SignIn Yahoo.Mail.objSingIn YahooMail.SignUp.Now.Click()
• Sleep (3)
• WelcomeTo Yahoo.Set Active
• Welcome To yahoo.objWelcomeToYahoo.LastName.SetText(“lastname”)
• Welcome To Yahoo.objWelcomeToYahoo.LanguageConten1.Select(5)
• WelcomeTo Yahoo.objWelcome ToYahoo.ContactMeOccassionally About.Click ()
• Welcome To Yahoo.objWelcome To Yahoo.Submit ThisForm.Click()
• If Registration Success.Exists ()
• Print (“Test Pass”)
• else
• logerror (“Test Fail”)