- Introduction
- Manual testing
- Autoit
- Ant
- Agilitest
- Bat
- Bat With Params
- Beanshell
- Cerberus
- Cucumber
- Cucumber v2 (BDD & Gherkin support)
- eTASQ Motion (Ponant)
- Executable
- FitNesse
- Gatling
- Generic Version-Control
- Git, Gitlab, Github
- Gradle
- Java
- Jar
- JMeter
- JMeter SQL
- JMeter Web
- JUnit
- Katalon
- Katalon v2
- Marathon
- Maven
- Mocha
- NeoLoad
- NUnit
- Odin Axe
- Odin Axe Results
- Offline
- Perl
- PHPUnit
- Postman (Newman)
- Protractor
- Python
- PyUnit
- PyTest
- QF-Test
- Quick Test Pro/UFT
- Ranorex
- Rapise
- RobotFramework
- RobotFramework v2
- RobotFramework v3
- RobotFramework v4
- Sahi
- Sahi 3.5
- Sahi 4.0
- Sahi 6.0
- Selenese
- Selenium HTML
- Selenium 3
- Selenium Java
- Selenium .NET
- Selenium Python
- Shell
- Sikuli
- SikuliX
- SilkTest
- SoapUI
- SoapUI Load
- SoapUI Security
- SOATest
- SQL Compare
- SQL Select
- Squish
- SVN (Subversion)
- Tape
- Tcl
- TestComplete
- TestComplete v2
- TestExecute
- TestExecute v2
- TestNG
- TestOptimal
- TestOptimal Simple
- TestPartner
- TestStand
- VisualStudio
- VisualStudio Coded UI
- WAPT
- WebdriverIO
- WebUI
- XCI
- xUnit.net
- Success (skeleton)
- Random (skeleton)
- Proxy
XStudio can execute any kind of tests (scripts, native code, interpreted code, xml etc.). This means that your already existing test suites are usable as they are.
The only condition is to have a launcher available.
Most of the existing launchers are listed in the open-source's launchers section and in this documentation chapter.
Among these launchers, some are dedicated to manual testing: 5 different interfaces for manual testing are provided along with XStudio.
In addition, all the launchers for automated testing are provided with their source code. They are delivered as open-source and licensed under GNU General Public License v2 (GPLv2)
But that's not all... if you have developed your own proprietary test framework you can also develop (in Java) a custom launcher yourself! as XQual provides a complete and extremely simple SDK.
The launchers integrate very simply in XStudio's architecture:
The first thing you need is to let XStudio knows about your automated tests.
To do that, you just need to create some tests in the test tree in XStudio.
This is the logical definition phase:
The association of the test with a launcher is made through the category. To do this, create a category in the test tree that will host the tests and associate it with a launcher:
At run-time, XStudio (or XAgent) will be able to find the physical test using all the data associated to the logical test.
This can include the test name, its logical path, any meta-data associated with it (i.e. attributes) or even parameters included in the execution configuration (selected when the user starts the execution):
Then, the execution engine will connect to the automation framework and will execute the physical test exactely the same way as if it was executed normally (through a GUI, or using a command line, manually etc.):
Results, traces, logs and any other potential useful information is gathered by the launcher and reported to XStudio.
Every information is securely stored in XStudio database:
In practice, it consists in selecting one of the named configuration that you have built (once for all).
This configuration is built initially using a form that is defined by an XML and this XML is provided along with the launcher.
All the parameters in the configuration are passed to the launcher at run-time.
If you're developing your own launcher, you'll need to provide the jar and a configuration XML.
For instance:
When you create your own launcher, don't forget to reference it in /var/lib/tomcat8/webapps/xqual/xstudio/launchers/launchers.xml on the server.
To get more information on how to develop your own launcher, read the Developer�s guide.
XStudio is the only ALM providing ~90 launchers to run almost any type of automated tests in any language and for any type of technology.
Check the detailed list in the left menu.
Most of the existing launchers are listed in the open-source's launchers section and in this documentation chapter.
Among these launchers, some are dedicated to manual testing: 5 different interfaces for manual testing are provided along with XStudio.
In addition, all the launchers for automated testing are provided with their source code. They are delivered as open-source and licensed under GNU General Public License v2 (GPLv2)
But that's not all... if you have developed your own proprietary test framework you can also develop (in Java) a custom launcher yourself! as XQual provides a complete and extremely simple SDK.
List of the main test automation frameworks supported
Launcher | Keywords |
agilitest | Agilitest, ATS scripts, KDT |
ant | Ant, Build tool, Continuous Integration, DevOps |
autoit | AutoIT scripts, GUI, Windows |
bat | batch scripts, Windows |
bat_with_params | batch scripts, Windows |
beanshell | Beanshell scripts, Java, Shell |
cerberus | Web, iOS, Android and API (REST, SOAP and Kafka) |
cucumber | Cucumber, BDD, Gherkin, Ruby, Java, JavaScript, C#, PHP |
cucumber_v2 | Cucumber, BDD, Gherkin, Embedded Gherkin, Ruby, Java, JavaScript, C#, PHP |
etasq | Any physical device (non-intrusive robot) |
exe | Executable, Windows |
fitnesse | Fitnesse, Java |
gatling | Gatling, Load, Performances |
generic | Generic scripted tests |
generic_version_control | Generic version-control commands |
git | Git, VCS, Github, gitLab, Version control |
gradle | Gradle, Continuous Integration, DevOps |
jar | Java |
java | Java |
jmeter | JMeter, Load, Performances |
jmeter_sql | JMeter, Load, Performances, SQL, Database |
jmeter_web | JMeter, Load, Performances, HTTP, Web |
junit | JUnit, Unit, Java |
Katalon | Katalon, Web, GUI, C#, .NET, Java, Qt, Desktop, Web, Windows, Mobile |
Katalon_v2 | Katalon, Web, GUI, C#, .NET, Java, Qt, Desktop, Web, Windows, Mobile |
marathon | Marathon, Java |
maven | Maven, Build tool, Continuous Integration, DevOps |
mocha | Mocha, JavaScipt |
neoload | NeoLoad, Web, Load, Performances |
nunit | NUnit, .NET, Unit |
odin_axe | Odin, Selenium, Appium, TestStack |
odin_axe_results | Odin, Selenium, Appium, TestStack |
offline_generic | Any framework that generate parsable result files supporting JUnit, TestNg, Mockito, EasyMock or any of the manual output format |
perl | Perl |
phpunit | PHP |
postman | Postman, SOAP, Web, REST, Load, Performances, Security |
protractor | Javascript, Angular Js |
pytest | Python, Unit |
python | Python |
pyunit | Python, Unit |
qftest | QF-Test, GUI, Java, Swing, SWT, JavaFX, AJAX, JQuery, Windows, Linux |
qtp | QTP, UFT |
ranorex | Ranorex, Web, GUI, C#, .NET, Java, Qt, Desktop, Web, Windows, Mobile |
Rapise | Rapise, Web, GUI, C#, .NET, Java, Qt, Desktop, Web, Windows, Mobile |
robot_framework | Robot Framework, BDD, Python, Java, .NET, Keyword Testing |
robot_framework_v2 | Robot Framework, BDD, Gherkin, Embedded Gherkin, Python, Java, .NET, Keyword Testing |
robot_framework_v3 | Robot Framework, BDD, Gherkin, Embedded Gherkin, Python, Java, .NET, Keyword Testing |
robot_framework_v4 | Robot Framework, BDD, Gherkin, Embedded Gherkin, Python, Java, .NET, Keyword Testing |
sahi | Sahi, Web |
sahi35 | Sahi 3.5, Web |
sahi40 | Sahi 4.0, Web |
sahi60 | Sahi 6.0, Web |
selenese | Selenese, GUI, Web, Selenium, AJAX |
selenium_dotnet | Selenium, GUI, Web, Mobile, .NET |
selenium_html | Selenium, GUI, Web, Mobile |
selenium_java | Selenium, GUI, Web, Mobile, Java |
selenium_python | Selenium, GUI, Web, Mobile, Python |
selenium3_html | Selenium 2.0 WebDriver, GUI, Web, Mobile |
shell | Shell, Linux, Unix |
sikuli | Sikuli, GUI, Desktop, Record |
sikulix | Sikuli, GUI, Desktop, Record |
silktest | Silk, GUI, Desktop, .NET, Java, Swing, SWT, Web, Windows |
soapui | SoapUI, SOAP, Web |
soapui_load | SoapUI, SOAP, Web, Load, Performances |
soapui_security | SoapUI, SOAP, Web, Security |
soatest | SOAP, REST, APIs |
newman | Newman, Postman, SOAP, Web, Rest, Automated |
sql_compare | SQL, Database |
sql_select | SQL, Database |
squish | Squish, GUI, Mobile, Desktop, Qt, Java, Web |
svn | SVN, VCS, Version control |
tape | Tape, Web, TAP, JavaScript, NodeJs |
tcl | TCL |
testcomplete | TestComplete, GUI, Windows, Mobile, .NET, Java, Database |
testcomplete_v2 | TestComplete, GUI, Windows, Mobile, .NET, Java, Database |
testexecute | TestComplete, GUI, Windows, Mobile, .NET, Java, Database |
testexecute_v2 | TestComplete, GUI, Windows, Mobile, .NET, Java, Database |
testng | TestNg, Java, Unit |
testoptimal | TestOptimal, Web, Database, Load, Model-Based, Behavior-Driven, Data-Driven |
testoptimal_simple | TestOptimal, Web, Database, Load, Model-Based, Behavior-Driven, Data-Driven |
testpartner | TestPartner, GUI, VBA, Windows |
teststand | Sequence, Labview, CVI, .NET, C/C++, ActiveX, HTBasic, ATLAS, VEE, etc. |
visualstudio | VisualStudio, .NET, Windows |
visualstudio_codedui | VisualStudio, GUI, .NET, Windows |
wapt | WAPT, Web, Load, Performances |
webdriverio | Javascript, Node.js |
webui | WebUi, Web, GUI, AJAX |
xci | XCI, Continuous Integration build plans, DevOps, Release, Pipeline |
xunit_dotnet | XUnit.NET, Unit, .NET, C# |
success (skeleton) | Success (skeleton) |
random (skeleton) | Random (skeleton) |
proxy | Proxy |
How to use a launcher
A launcher is what makes the "link" between the logical test declared in XStudio and its physical implementation (the script).The launchers integrate very simply in XStudio's architecture:
The first thing you need is to let XStudio knows about your automated tests.
To do that, you just need to create some tests in the test tree in XStudio.
This is the logical definition phase:
The association of the test with a launcher is made through the category. To do this, create a category in the test tree that will host the tests and associate it with a launcher:
At run-time, XStudio (or XAgent) will be able to find the physical test using all the data associated to the logical test.
This can include the test name, its logical path, any meta-data associated with it (i.e. attributes) or even parameters included in the execution configuration (selected when the user starts the execution):
Then, the execution engine will connect to the automation framework and will execute the physical test exactely the same way as if it was executed normally (through a GUI, or using a command line, manually etc.):
Results, traces, logs and any other potential useful information is gathered by the launcher and reported to XStudio.
Every information is securely stored in XStudio database:
Execution Configuration
When you start executing some test, you'll need to select an execution configuration.In practice, it consists in selecting one of the named configuration that you have built (once for all).
This configuration is built initially using a form that is defined by an XML and this XML is provided along with the launcher.
All the parameters in the configuration are passed to the launcher at run-time.
If you're developing your own launcher, you'll need to provide the jar and a configuration XML.
For instance:
<form name="Timing"> <formItem type="slider" id="0" name="delay between testcases (ms)" value="0" min="0" max="10000" readOnly="false"/> </form>will be embedded in XStudio's GUI as:
Proprietary/Custom launchers
This mechanism is extremely powerful as it allows you to automate the execution of your proprietary tests very quickly. In most of the cases, only a few tenth of lines of java are sufficient to create your own proprietary launcher.When you create your own launcher, don't forget to reference it in /var/lib/tomcat8/webapps/xqual/xstudio/launchers/launchers.xml on the server.
Where are they?
All the launchers (as well as their configuration XML) can be found in <Install_folder>/bin/launchers folder.To get more information on how to develop your own launcher, read the Developer�s guide.