Changes

Jump to: navigation, search

Bugzilla:QA

506 bytes removed, 02:04, 5 January 2009
m
no edit summary
Both HTML and Perl Selenium scripts can be downloaded using bzr:
bzr co bzr://bzr.bugzilla.org/selenium/
 
Members of the QA team can use CVS to get them and to commit changes:
cvs -d my_login@landfill.bugzilla.org:/cvsroot co selenium
 
where my_login is your user account name on landfill.
 
This will download Selenium scripts for all branches, including Bugzilla 2.20, 2.22, 3.0, and 3.2. Do not expect HTML scripts to work as is. They were based on a given test installation on landfill having some given user accounts, products, components and parameters, and so they won't run on a fresh test installation. They are only available so that you can see what we did till Bugzilla 3.0. Note that the 3.0 branch has a t/ directory with test scripts related to WebService. As those point to the same test installations as above, they also won't run as is on a fresh test installation.
=== Perl Selenium scripts ===
To avoid the problem mentioned above, we highly improved the QA process during the Bugzilla 3.2 cycle and decided to write a script which would populate your fresh new installation so that you could also run our Selenium and WebService tests. This script is located in <em>bugzilla32/config/generate_test_data.pl</em>, and requires that you first set parameters in <em>bugzilla32/config/selenium_test.conf </em> correctly. Note that generate_test_data.pl It must be run against an existing Bugzilla match your local configuration, especially the url to your installation, created by which must already exist (but should contain nothing more than what checksetup.pl! created, i.e. your admin account, the TestProduct and system groups), as well as the path to your browser (if possible Firefox 2 due to a problem with Firefox 3, the EULA license being displayed on startup with a new profile, preventing Selenium to work). If you set mail_delivery_method to 'Testfile', you can define fake user accounts in the config file. Once the DB is populated, you can start the Selenium server and run our scripts located in bugzilla32/t/.
The fastest way to write Selenium scripts is to use [http://openqa.org/selenium-ide/ selenium-IDE] ([https://addons.mozilla.org/extensions/moreinfo.php?application=firefox&category=Newest&numpg=10&id=2079 amo], formerly [http://seleniumrecorder.mozdev.org/ Selenium Recorder]). Selenium-IDE is a Firefox extension which writes scripts for you. It records your actions and converts them into a valid Selenium script. If you decide to install this extension, you don't need to install Selenium separately; everything is included in the XPI package (samples and docs are not included though). You can also write Selenium scripts with a text editor, but this is longer and can be pretty painful.
What you can read here are the descriptions given for each command of the script. This makes debugging much easier!
Existing Selenium scripts being under development/review can be found in open bugs depending on [http://landfill.bugzilla.org/bugzillaqa/show_bug.cgi?id=3065 bug 3065]. Members of the QA team can use Those shouldn't be considered as "safe" till they are available via CVS to get them all at once using:  cvs -d my_login@landfill.bugzilla.org:/cvsroot co selenium where my_login is your user account name on landfill. Once bzr (you have the repository on your local disk, all you have to do is to edit bugzilla32/config/selenium_test.conf to match your local configuration, especially the url to your installation, which must already exist (but should contain nothing more than what checksetup.pl created, i.e. your admin account, the TestProduct and system groups), as well as the path to your browser (if possible Firefox 2 due to a problem with Firefox 3, the EULA license being displayed on startup with a new profile, preventing Selenium to workbeen warned). If you set mail_delivery_method to 'Testfile', you can define fake user accounts in the config file. When the config file matches your local configuration, the last step is to run generate_test_data.pl, which will populate your DB. This last step is required as all Selenium and WebService scripts assume the DB to have some given data in it. If a test goes wrong and breaks your DB, all you have to do is to recreate an empty DB, run checksetup.pl for the initialization, and then generate_test_data.pl again to repopulate the DB.
Confirm
683
edits

Navigation menu