You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

Overview

Ranorex can be seen as a keyword-driven framework for implementing GUI test automation across a broad set of technologies, including desktop, web, and mobile. It's a codeless test automation solutiion. Ranorex provides comprehensive support for test automation as detailed in its core features. Data-driven testing is supported.

Ranorex provides Ranorex Studio, the main application to implement and organize automated test scripts. Ranorex Studio has multiple components, including a recorder (Ranorex Recorder) and a object/element identifier (Ranorex Spy).



Ranorex conceptDescription
Solution

In Ranorex Studio, a solution is the top-level container that contains all other test files. Solutions are organized into one or more projects.

Whenever creating a solution, we may identify the type of application we aim to test (e.g. desktop, web, mobile).

A solution has always a "test suite" project.


Project

A tailored place to organize test files.

A project can be of one of several types, including "test suite", which offer different capabilities.


Test suiteThe test suite is where you build, organize, and run your tests in Ranorex Studio. A test suite consists primarily of test cases.
Test caseA test, composed of Modules, which in turn are composed of Actions.
Module

Modules can be reused between Test cases.


ActionA step, inside a Module. Can be an action or a validation.
ValidationAn assertion, a validation.
Repository

A Repository contains Repository Items (i.e. UI elements) organized in a tree-like structure.

UI elements that contain other UI elements are represented as folders in the repository, with app folders acting as top-level elements and rooted folders as children.


Repository item

A representation of a user interface (UI) element used in a test.

Each repository item has a name and is defined by its RanoreXPath (i.e. path).





Overall test statusyes

Actions

no
Videosnoperhaps
Data-driven




How to


We will implement some automated tests for a dummy web site, providing an authentication mechanism that we aim to check.

Our tests, part of a test suite, include:

  • valid login
  • invalid login
  • valid logout
  • invalid login (data-driven scenario)


Solution and project setup

We start by creating a solution, web-based one as we aim to test a web site.

Under "Additional options" we can customize the language of the underlying code that Ranorex will use to support the test automation.

A project of type "test suite" will be created.

It contains one Test Suite, where we can create and manage our test cases. We may rename this Test Suite to have a more meaningful name (e.g. "Authentication").



Implementing automated tests

To add some Test cases to the Test Suite, we can use "Add" button.

We can rename the Test case (i.e. from TestCase to whatever describes it). We then add a Setup and a Teardown section and add the OpenBrowser and CloseBrowser modules, to each section respectively. Opening the OpenBrowser module, by double-clicking on it, will allow us to set the URL to be usused.

We can then use Ranorex Recorder to create a "module" (i.e. a set of sequential actions and/or validations on UI elements).

This will be used to implement interactions with our web site, without having to code.



Integrating with Xray to have visibility of testing results in Jira

In order to have visibility of our test automation results, we need to generate a JUnit XML that can then be submitted ot Xray.

Enabling the JUnit XML report can be done right from Ranorex Studio or from the command-line.


If we run the tests from within the Ranorex Studio UI, we can go to the properties of our test suite to customize the report file name, the reports directory, and enable the JUnit XML report.



If we run the tests from the command-line, by calling the executable built by Ranorex, we can enable the JUnit XML report, customize the report file base file name, among other options.

example of a shell script to run the tests
MyTest1.exe /junit /reportfile:results

In this case, the report will be stored in the current directory and wil be named results.rxlog.junit.xml.


To submit the report to Xray, we can use our favourite CI/CD tool or a simple shell script for that. 

example of a shell script to import results to Xray
curl -H "Content-Type: multipart/form-data" -u jira_username:jira_password -F "file=@results.rxlog.junit.xml" jiraserver_base_url.example.com/rest/raven/1.0/import/execution/junit?projectKey=DEMO


After submiting the test automation report, a Test Execution will be created in Jira, containing the results for each Test case.

A Test issue will be auto-provisioned, unless it already exists, per each Test Case. The Test Suite name along with the Test Case name will be used as unique identifier for the Generic Test that will be created.


Tips

Seeing the impacts of test automation results on user stories or requirements

After uploading the test automation results, users can link the Test issues to existing user stories or requirements. That will enable users to track coverage and thus assess if user stories are covered by automated test scripts and if based on that, the corresponding user story can be considered to OK or NOK.

Please remember that coverage is an heuristic but that can still be quite helpful to assess the readiness of user stories, individually or at the release level.


References

  • No labels