Archive | May, 2012

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/

Advertisements

Experiences of Test Automation – Case studies of Software Test Automation

31 May

Software test automation has moved beyond a luxury to become a necessity. Applications and systems have grown ever larger and more complex, and manual testing simply cannot keep up. As technology changes, and more organizations move into agile development, testing must adapt—and quickly. Test automation is essential, but poor automation is wasteful—how do you know where your efforts will take you?

Authors Dorothy Graham and Mark Fewster wrote the field’s seminal text, Software Test Automation, which has guided many organizations toward success. Now, in Experiences of Test Automation, they reveal test automation at work in a wide spectrum of organizations and projects, from complex government systems to medical devices, SAP business process development to Android mobile apps and cloud migrations. This book addresses both management and technical issues, describing failures and successes, brilliant ideas and disastrous decisions and, above all, offers specific lessons you can use.

Coverage includes
Test automation in agile development
How management support can make or break successful automation
The importance of a good testware architecture and abstraction levels
Measuring benefits and Return on Investment (ROI)
Management issues, including skills, planning, scope, and expectations
Model-Based Testing (MBT), monkey testing, and exploratory test automation
The importance of standards, communication, documentation, and flexibility in enterprise-wide automation
Automating support activities
Which tests to automate, and what not to automate
Hidden costs of automation: maintenance and failure analysis
The right objectives for test automation: why “finding bugs” may not be a good objective
Highlights, consisting of lessons learned, good points, and helpful tips

Experiences of Test Automation will be invaluable to everyone considering, implementing, using, or managing test automation. Testers, analysts, developers, automators and automation architects, test managers, project managers, QA professionals, and technical directors will all benefit from reading this book.

You can get this book with sample (only chapter 29. Test Automat ion Anecdote s is available )  in here

http://ptgmedia.pearsoncmg.com/images/9780321754066/samplepages/0321754069.pdf

Silktest – THE AUTOMATED TESTING PROCESS

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”)

Silk Test – Introduction

31 May

Silk Test is a tool specifically designed for doing REGRESSION AND FUNCTIONALITY testing. It is developed by Segue Software Inc. Silk Test is the industry’s leading functional testing product for e-business applications, whether Window based, Web, Java, or traditional client/server-based. Silk Test also offers test planning, management, direct database access and validation, the flexible and robust 4Test scripting language, a built in recovery system for unattended testing, and the ability to test across multiple platforms, browsers and technologies.
You have two ways to create automated tests using silktest:

1. Use the Record Testcase command to record actions and verification steps as you navigate through the application.
2. Write the testcase manually using the Visual 4Test scripting language.

1. Record Testcase
The Record / Testcase command is used to record actions and verification steps as you navigate through the application. Tests are recorded in an object-oriented language called Visual 4Test. The recorded testreads like a logical trace of all of the steps that were completed by the user. The Silk Test point and click verification system allows you to record the verification step by selecting from a list of properties that are appropriate for the type of object being tested. For example, you can verify the text is stored in a text field.

2. Write the Testcase manually
We can write tests that are capable of accomplishing many variations on a test. The key here is re-use. A test case can be designed to take parameters including input data and expected results. This “data-driven” testcase is really an instance of a class of test cases that performs certain steps to drive and verify the application-under-test. Each instance varies by the data that it carries. Since far fewer tests are written with this approach, changes in the GUI will result in reduced effort in updating tests. A data-driven test design also allows for the externalization of testcase data and makes it possible to divide the responsibilities for developing testing requirements and for developing test automation. For example, it may be that a group of domain experts create the Testplan Detail while another group of test engineers develop tests to satisfy those requirements.
In a script file, an automated testcase ideally addresses one test requirement. Specifically, a 4Test function that begins with the test case 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.
A script file is a file that contains one or more related testcases. A script file has a .t extension, such as find .t
Other Segue products

The Silk products include

Sit Test for functional and regression testing
Silk Performer for load and performance simulation
Silk Pilot for functional and regression testing CORBA and EJB servers
Silk Radar for automated defet tracking
Silk Vision for enterprise application health monitoring
Silk Express for a scalability and load testing consulting solution.

Silk Test Features :

Some of the feature of silk test are given below.
• Easy to use interface
• Built in recovery system
• The object oriented concept
• Record & Play
• Multi-kind application testing
• Automatic generation of results
• Browser & Platform independent
• 24 x 365 unattended testing
• Distributed Access to Test Results
• Cross Platform Java Testing
• Testing Across Multiple Browsers and Windows Versions
• Support for HTML, XML, JavaScript, Java, Active X, Windows controls, and Visual Basic.
• Single-recording testing for cross-platform Java testing with the Silk Bean.
• Against Over 35 Databases.
• Link Tester
• Validation of Advanced Database Structure and Techniques
• Creation of
Test Plan
Test Frame
Test Suite
• Integration with other silk products.
Silk Test Architecture
Normal use of an application consists of a person manipulating a keyboard and mouse to initiate application operations. The person is said to be interacting with the GUI (Graphical User Interface). During Silk Test testing, Silk Test interacts with the GUI to submit operations to the application automatically. Thus Silk Test can simulate the actions of a person who is exercising all the capabilities of an application and verifying the results of each operation. The simulated user (Silk test) is said to be driving the application. The application under test reacts to the simulated user exactly as it would react to a human rest. Silk Test consists of two distinct software components that execute in separate processes :
Silk Test host software
The Silk Test host software is the program you use to develop, edit, compile, run and debug your 4Test scripts and test plans. This manual refers to the system that runs this program as the host machine or the Silk Test machine.
The Agent
The 4Test Agent is the software process that translates the commands in your 4Test scripts into GUI-specific commands. In order words, it is the Agent that actually drives and monitors the application you are testing. One Agent can run locally on the host machine. In a networked environment, any number of Agents can run on remote machines. This manual refers to the systems that run remote Agents as target machines. This manual refers to the systems that run remote Agents as target machines. In a client/server environment, Silk Test drives the client application by means of an Agent process running on each application’s machine. The application then drives the server just as it always does. Silk Test is also capable of driving the GUI belonging to a server or of directly driving a server database by running scripts that submit SQL statements to the database. These methods o directly manipulating the server application are intended to support testing in which the client application drives the server.
Limitations of Silk Test:

Some of the limitations of Silk Test are given below:
• SilkTest may not recognize some objects in a window / page due to some technical reasons.
• Silk Test may not recognize some window frames.
• The ‘tag’ value may get changed frequently.
• Sometimes it will be difficult to activate some window.
• It may be necessary to make some modifications if testing should be shifted to other browser / operating system.
• In web based applications, sometimes, silktest will take the links as simple text.
System Requirements :

The minimum requirement, a system needs to run the silk test is given below :

Windows NT, Windows 95, 98 or 2000
Pentium 466 Mhz or better processor (application dependent)
32 MB RAM
60MB Hard Disk

Supported Environments:

Netscape Navigator 4.x
Internet Explorer 4 and 5
Active X, Visual Basic 5 and 6
Java JDK 1.3
Swing 1.1
Microsoft Web browser control

SilkTest Introduction to Automation

31 May

[docstoc docId=”86121734″ mId=”-10″ width=”630″ height=”550″ slideMode=”true” showRelatedDocs=”true” showOtherDocs=”true” allowdownload=”true” url=”http://embed.docstoc.com/docs/86121734/SilkTest-–-Introduction-to-Automation”%5DSilkTest – Introduction to Automation[/docstoc]

Giới thiệu về công cụ kiểm thử tự động QUICKTEST PROFESSIONAL

31 May

Trong lĩnh vực KTTĐ hiện có khá nhiều TT thương mại nổi tiếng, phổ biến như QuickTest Professional, WinRunner, Rational Robot, SilkTest, JTest,… Trong số đó, QuickTest Professional (QTP) phiên bản 8.2 của hãng Mercury khá tốt và mạnh, bao gồm nhiều chức năng điển hình của một công cụ kiểm tra tự động. Lưu ý là QTP 8.2 đã có một cái tên mới hơn là Mercury Functional Testing 8.2.

QTP là TT dùng để kiểm tra chức năng (functional test) và cho phép thực hiện kiểm tra hồi qui (regression test) một cách tự động. Đây cũng là công cụ áp dụng phương pháp Keyword-Driven, một kỹ thuật scripting (lập trình trong KTTĐ) hiện đại, cho phép KTV bổ sung test case bằng cách tạo file mô tả cho nó mà không cần phải chỉnh sửa hay bổ sung bất cứ script nào cả. Nó cũng phù hợp trong tình huống chuyển giao công việc mà người mới tiếp nhận chưa có thời gian hoặc không hiểu script vẫn có thể thực hiện kiểm tra PM theo đúng yêu cầu.

1. Loại phần mềm hỗ trợ

QTP giúp chúng ta KTPM theo hướng chức năng trên rất nhiều loại chương trình phần mềm khác nhau. Tuy nhiên Mercury chỉ hỗ trợ sẵn một số loại chương trình thông dụng như:

• Ứng dụng Windows chuẩn/Win32.

• Ứng dụng web theo chuẩn HTML, XML chạy trong trình duyệt Internet Explorer, Netscape hoặc AOL.

• Visual Basic.

• ActiveX.

• QTP hỗ trợ Unicode (UTF-8, UTF-16).

Một số loại chương trình khác đòi hỏi chúng ta phải cài đặt thêm thành phần bổ sung của QTP thì mới thực hiện kiểm tra được. Các loại chương trình đó là:

.NET • NET Framework 1.0, 1.1, 2.0 beta
• Các đối tượng chuẩn của .NET và các đối tượng khác thừa kế từ các đối tượng chuẩn.
Java • Sun JDK 1.1 – 1.4.2
• IBM JDK 1.2 – 1.4
Oracle • Oracle Applications 11.5.7, 11.5.8, 11.5.9
People Soft • PeopleSoft Enterprise 8.0 – 8.8
SAP • SAP GUI HMTL 4.6D, 6.10, 6.20
• SAP Workplace 2.11
• SAP Enterprise Portal 5.0
Siebel • Siebel 7.0, 7.5, 7.7
Terminal Emulators • Attachmate EXTRA! 6.7, 7.1
• Attachmate EXTRA! Terminal Viewer 3.1 Java sessions
• IBM Personal Communications
•…

2. Đặc điểm

• Dễ sử dụng, bảo trì, tạo test script nhanh. Cung cấp dữ liệu kiểm tra rõ ràng và dễ hiểu.

• Kiểm tra phiên bản mới của ứng dụng với rất ít sự thay đổi. Ví dụ khi ứng dụng thay đổi nút tên “Login” thành “Đăng nhập”, thì chỉ cần cập nhật lại Object Repository (OR – được giải thích ở phần sau) để QTP nhận ra sự thay đổi đó mà không cần thay đổi bất cứ test script nào.

• Hỗ trợ làm việc theo nhóm thông qua sự chia sẻ thư viện, thống nhất quản lý Object Repository.

• Thực tế cho thấy, QTP thực hiện KTTĐ trên nhiều trình duyệt cùng lúc tốt hơn những TT khác.

• Với chức năng Recovery Scenarios, QTP cho phép xử lý những sự kiện hoặc lỗi không thể đoán trước có thể làm script bị dừng trong khi đang chạy.

• QTP có khả năng hiểu test script của Mercury Winrunner (một công cụ kiểm tra khác của Mercury).

Đặc biệt phiên bản v.8.2 có một số tính năng mới nổi bật:

Quản trị Object Repository

• Phối hợp giữa các KTV qua việc đồng bộ hóa dữ liệu, khả năng trộn, nhập/xuất ra file XML

Thư viện hàm mới

• Chia sẻ các thư viện hàm giữa các nhóm KTV

Kiểm tra tài nguyên

• Kiểm tra tài nguyên cần thiết trước khi thực thi lệnh kiểm tra tự động.

Nâng cấp khả năng kéo thả

• Kéo thả các bước kiểm tra trong môi trườn
g ngôn ngữ tự nhiên.

Hỗ trợ XML cho báo cáo

• Lưu trữ kết quả kiểm tra dưới dạng XML, HTML, từ đó cho phép tùy biến báo cáo.

Trình phát triển mới (IDE)

• Môi trường soạn thảo mới, mềm dẻo cho tùy biến và sử dụng.

Trình dò lỗi mới

• Cho phép KTV kiểm soát lỗi khi viết test case.

Quản trị từ khóa

• Quản lý từ khóa trong quá trình sử dụng

Hỗ trợ đa giao tiếp

• Cho phép người dùng mở và soạn thảo đồng thời nhiều hàm thư viện và Object Repository.

Hỗ trợ Unicode

• Hỗ trợ Unicode với các ứng dụng đa ngôn ngữ (multi-language).

Hỗ trợ các môi trường mới

Khu vực Chức năng
Menu bar Cấu hình thao tác với QTP và script
File toolbar Hỗ trợ quản lý script
Debug toolbar Hỗ trợ kiểm tra lỗi trong test script (debug)
Testing toolbar Hỗ trợ quá trình tạo test script hoặc thực hiện KTTĐ
Action toolbar Xem một Action (thủ tục, hàm) hoặc toàn bộ chu trình của test script
Test pane Soạn thảo script ở một trong 2 chế độ Keyword View hoặc Expert View
Data Table Nơi lưu trữ dữ liệu cho test script
Active Screen Xem lại giao diện PM được kiểm tra

3. Các thành phần quan trọng trong QTP

a. Action:

Giống như thủ tục hay hàm trong các ngôn ngữ lập trình khác, Action ghi lại các bước thực hiện KTTĐ và nó có thể được sử dụng lại nhiều lần. Trong một test script có thể có nhiều Action.

b. DataTable:

Nơi lưu dữ liệu phục vụ cho KTTĐ. Một test script sẽ có một DataTable được dùng chung cho tất cả các Action. Bên cạnh đó mỗi Action cũng có một DataTable cho riêng mình.

c. Object Repository (OR):

Cấu trúc theo dạng cây, mô tả các đối tượng trong PM được kiểm tra. Đây được xem là cầu nối để test script tương tác với PM được kiểm tra.

Khi ra lệnh cho QTP ghi lại thao tác người dùng lên PM thì trong OR sẽ tự động phát sinh thành phần đại diện cho những đối tượng trên PM vừa được thao tác.

OR có thể tổ chức thành 2 loại, một loại dùng chung trong nhiều test script, loại khác dùng theo từng Action.

Để xem OR, chọn menu Tools > Object Repository.

d. Checkpoint:

Có thể hiểu là nơi kiểm tra trong test
script, khi chạy nó sẽ thực hiện so sánh kết quả thực tế khi kiểm tra PM với kết quả mong đợi. Sau khi tiến hành so sánh QTP sẽ tự động ghi lại kết quả vào Test Results (nơi lưu kết quả khi chạy test script).

4. Ngôn ngữ sử dụng viết script

QTP sử dụng ngôn ngữ VBScript để viết test script. Đây là ngôn ngữ dễ học; rất giống ngôn ngữ VBA. Chế độ Expert View của QTP là chế độ soạn thảo dành cho VBScript. Ngoài việc dùng VBScript để tương tác với PM được kiểm tra, QTP còn có khả năng cấu hình hệ thống bằng ngôn ngữ Windows Script.

Chi tiết về ngôn ngữ VBScript, người đọc có thể dễ dàng tìm trong các sách hiện có trên thị trường, thậm chí ngay chính trong phần help của QTP.

5. Sử Dụng QTP

a. Yêu cầu cấu hình hệ thống:

b. Bản quyền sử dụng:

CPU PIII trở lên
Hệ điều hành Windows 2000 SP3, SP4; Windows XP SP1, SP2 hoặc Windows 2003 Server
RAM 256 MB trở lên
Dung lượng đĩa Tối thiểu 250MB cho ứng dụng, 120MB trên ổ đĩa hệ điều hành. Sau khi cài QTP, dung lượng cần thiết thêm trên ổ đĩa cài hệ điều hành là 150 MB
Trình duyệt IE 5.5 SP 2 trở lên

• Bạn có thể vào http://www.mercury.com để đăng ký và tải về bản dùng thử trong 14 ngày. Các bước cài đặt theo sự hướng dẫn của chương trình. Sau thời gian dùng thử, để có thể tiếp tục sử dụng QTP chúng ta cần phải mua bản quyền, giá tham khảo từ nhà cung cấp như sau: cho một máy 9.000 USD; cho nhiều máy dùng cùng lúc 12.000 USD.

Tại Việt Nam, nếu có nhu cầu, bạn có thể liên hệ để mua bản quyền của QTP tại công ty Tân Đức (TD&T, 103 Pasteur, Q.1, TP.HCM).

(Sưu tầm)

[Tester] Becoming a Software Testing Expert

29 May

[Test tool] [Selenium] Learn how to use Selenium with Maven/Ant to automate testing of web apps

29 May

San Francisco Java User Group presents Chris Bedford who talks about:
– How to write functional tests with Selenium (including explaining its IDE, architecture, RC, and alternatives like Canoo WebTest)
– How to set up Selenium testing for web apps in continuous integration using Maven, Ant, Cargo, etc.
– How to use Hudson for build server (brief overview)

January 12, 2010 in San Francisco, CA
http://www.sfjava.org/calendar/11982857/

[Test tool] [Selenium] More Top Tips For Writing Better Selenium Tests

29 May

[Test tool] [Selenium] Selenium Regression Testing Part II – Tips and Tricks

29 May

In my last post, I talked about how you can use Selenium to do real regressions tests for web applications. It’s a great way to automate testing the real user experience, and not just the backend stuff.

(see Luke’s last post here: Web Application Functional Regression Testing Using Selenium)

That said, Selenium is a relatively new technology, and it’s not without its issues. When building your first test you might find a lot of times where it’s a trial and error process. There are so many different ways to do the same test, it can be overwhelming. Often times, one or more of the ways you try won’t work. I’m going to try to list some of the common problems I ran into and tips I found below.
Selenium Commands
waitForElementPresent
this is will block your test proceeding until it finds the identified element. It checks once a second for 30 seconds.
this was the most common way I dealt with ‘ajax’ type interactions where it takes an unknown period of time for something to show up
I also use it generally instead of verifyElementPresent – it does basically the same thing with a little wiggle room
mouseDown/mouseUp/mousePressed/click
mostly equivalent, but sometimes you need to match the desired event to a javascript handler
try click first. If it doesn’t work the way you want, move on to mouseDown and so on.
waitForFrameToLoad/selectFrame
important if you use iFrames (modal dialog, etc.)
the selenium selectors only hit the current frame, otherwise you have to select the correct frame
an easy way to get back to the root window is to do selectFrame null
type vs. typeKeys
type fills out an input in code – if it works, use this. You can use this,and then fire a single typeKeys for the last character if you need an event to be triggered.
typeKeys fires the key events on the element
has some idiosyncracies – certain letters (I’m looking at you,‘y’) are reserved to do other special keypresses
necessary if you are using a wysiwyg ‘designmode’ type box instead of a standard input
verifyX vs. assertX
if verify fails, the test continues (and is marked as errored). If assert fails, the test aborts.
Usually verify is better, unless one task blocks a future one from functioning correctly
runScript vs. Eval vs. Expression
runScript inserts the javascript you provide into the current frame/window. Useful for those things selenium doesn’t support – like moving a cursor around and selecting text in a wysiwyg
Eval runs javascript in the context of selenium. Handy for complex checks – use waitForEval (for instance, checking the css background image property of a particular element)
Use this.browserbot.findeElement(“selenium selector”) to find elements the way selenium would
Use window.X To access the current frame/window context objects
Expression is similar to Eval, but uses Selenium’s custom expression format instead of javascript (but you can combine with javascript by using javascript{}
storedVars[‘key’] allows you to get to a variable you created with a Selenium ‘store’ expression
selectPopUp
useful for checking stuff in a popup that was initiated
Easiest to get by the html title of the popup, but do a ‘pause’ first to let it load
Selenium Selectors and XPath
In general, be as abstract as possible.
Don’t select individual server generated ids (hand crafted html ids are ok if you don’t expect them to change)
Don’t select on complicated relationships ( /div[0]/div[2]/a[4] ) – your html structure will change and you’ll have to maintain it
Select links by the simple link=text when possible – easy to read/maintain, unlikely to change
Use //that (any decendant) instead of /this/that where possible
. references ‘this’ element. Helps to select something with a particular text: //div[@id=’publish-private-shares’]//p[.=’This is pretty cool.’]
Contains() is useful if you don’t know the exact text (for instance, when an element has multiple css classes): //div[@id=’pageContent’ and contains(@class,’contenteditable’) and h2=’Goals’]/p[1]
Selenium RC
While you can use Selenium IDE to create a c# version of your tests – if you do so, you have two tests to maintain. You can run your ‘selenese’ tests directly with RC, too.
JAVAPATHjava.exe –jar SELENIUMPATHselenium-server.jar –htmlSuite “*BROWSER” “BASESITEURL” “SUITEFILEPATH” “RESULTSFILEPATH”
I’ve written a simple csharp console project that automatically finds the correct javapath and fires up the test when you run it. If people ask in the comments, I’ll post it.
Last I checked, Chrome and Safari-Windows don’t work. Chrome is supposed to be fixed in Selenium RC 1.0.4
Sauce RC
This is a great UI to help test multiple browsers, but there are a couple of issues
Firefox works, but only in dual window mode
IE works, but only in single window mode.
The ‘timeout’ setting implies a default timeout per action in your test, but it is actually the timeout for your entire test run. Since it defaults to 30 seconds, you’ll probably want to change it, or else your tests will suddenly die for no reason with no explanation/log.

I’m sure there is probably more I’ve forgotten, so leave a comment if you get stuck and I’ll try to help out if I can.

For some helper classes for Selenium 2 with ASP.NET Forms, see the following post: Simplifying C# Selenium 2 Tests for ASP.NET WebForms

http://www.foliotek.com/devblog/selenium-tips-and-tricks/