Page History
| UI Expand | ||
|---|---|---|
| ||
|
Introduction
In certain Scenarios, Test Case Designer allows you to define which parameter values should never be tested together. This is achieved by applying Constraints.
To guide the model, you can define Invalid Constraints (values that should
| Table of Contents | ||
|---|---|---|
|
Overview
In specific scenarios, system allows user to define what parameter values can never be tested together or in the other hand, scenarios where parameter values can only be tested together.
For that, user can apply constraints to support these cases.
So that the model can understand the requirements, you have the option to define invalid constraints (values that can never be tested together) , and/or bound constraints Bound Constraints (values that can only must be tested together) to train the model.
Invalid constraints
Invalid constraints restrict parameter values that can never be tested together.
. Important - regardless of the constraint type, the only function of this feature is exclusion of certain combinations from the Scenarios screen.
Invalid Constraints
Invalid Constraints prevent parameter values that should never be combined in a Test case.
For example (Figure 1), assume that the browser In this example, let's assume Internet Explorer (IE) is not supported on Apple computers so . In this case, it would be impossible for a tester to execute a test case that instructed them to launch IE from to Test a scenario where IE is launched on a Mac running on its native operating systemOS. AccordinglyTherefore, we do not want any tests generated to include combinations such as “OS X” and “IE8” in the same test case.
On the Rules ->Constraints screen, you will need to click on two red X’s. Hover over the first Value of the Invalid Pair and click on the red X that appears
...
As you enter your Constraints, you will see them listed to the left:
...
After you enter these two Invalid Pairs, clicking on the “Scenarios” button will create a completely new set of test cases that excludes those two pairs of Values (and only those two pairs of Values). Each test with ‘OS X’ as the operating system will have a browser other than IE.
As you use the Invalid Pair feature and the related Bound Pair one, keep in mind these usage tips:
...
Do you need to add a lot of Invalid Constraints?
...
Watch out for “Not Applicable” Values.
- Do you need to add some of them to your plan? Do you need to invalidate the combination of “Not Applicable” with other specific Values?
- Especially watch out for situations where you have multiple related “Not Applicable” values in a plan. Would it make sense to create a “Bound Constraint” between ‘Hotel Chain Preference = Not Applicable’ and ‘Type of Room’ = Not Applicable’?
you want to prevent the generation of Test cases that combine Mac OS and IE10 or IE11.
Figure 1 - OS and Browser
Creating Invalid Constraints
| UI Steps | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
As you use the Invalid Pair feature and the related Bound Pair, keep in mind these usage tips:
|
Bound Constraints
Bound constraints restrict parameter values that can only be tested together.
| UI Steps | ||||||
|---|---|---|---|---|---|---|
|
Bound constraints
Bound constraints restrict parameter values that can only be tested together.
Consider these parameters & values:
You will have the following issue when you click on the “Scenarios” button:
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
Creating Bound Constraints
| UI Steps | size | small|||||
|---|---|---|---|---|---|---|
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
One-way Bound Pair
The underlying relationship type : is many-to-one, represented by WHEN-THEN statements in the left column.
We would like to exclude combinations like ‘Breed Breed of Animal = Shiba Inu’ Inu and ‘Type Type of Animal = Cat’ Cat from the generated scenarios.
We have 2 two breeds for each of the first 2 two types of animals. Therefore, we can set up 4 four one-way bound pairs from "from Breed of Animal" to "Type of Animal" (Figure 16):
Figure 16 - Breed
You You can check your the logic by reading the statement at the bottom of the dialog (Figure 16 - 1).
The order in which you set the pair matters!.
In this case, we wouldn't be able to say WHEN ‘Type WHEN Type of Animal = Cat’ THEN ‘Breed Cat THEN Breed of Animal = Siamese’ Siamese because that would prevent 'Cat + Persian' from appearing, and would leave 'Persian" without any possible pairing (Figure 18).
Figure 17 - Type
| Note |
|---|
| You may argue that the statement at the bottom (Figure 17 - 1) still looks correct in this direction. However, however you need to keep in mind how the word "must" is interpreted by the algorithmalgorithm must interpret the word. Since the evaluation is done at the " pair of values " level, "must have Breed of Animal as Siamese" = "must NOT have Breed as Persian, Shiba Inu, Golden Retriever, Arabian" - of which "Persian" is incorrectly excluded. Therefore, therefore this direction wouldn't work for this example. We could use such direction if we had multiple types that can be with only 1 one breed. |
Mutually Bound Pair
The underlying relationship type : is one-to-one, represented by ALWAYS-ALWAYS statements in the left column.
With Mutually Bound Constraints, the values are exclusive to each other. In this example (Figure 18), there is only one horse breed in the second parameter. So, with 1 one constraint, we can specify that "Horse" should not be paired with "Siamese, Persian, Shiba Inu, Golden Retriever" AND ", and Arabian" should not be paired with "Cat, Dog" - i.e., "Horse" and "Arabian" must only be tested together.
Figure 18 - Breed
The final set of rules for this model (in the verbal form) would look like this (Figure 19):
Figure 19 - Final
In essence, Bound Constraints and Invalid Constraints perform similar tasks: they ensure that certain values only or never appear together - making all generated scenarios valid within the model scope. From a different point of view, Bound Constraints and Mutually Bound Constraints actually invalidate many values and Invalid Constraints bind many values, behind the scenes.
...
Skip
...
Constraints
| Info |
|---|
...
Skip |
...
constraints are only available under the Advanced Mode |
...
(toggle in the top left of the Constraints screen). |
"Skip " constraints allow for certain parameters to be excluded from test Test cases when it is not appropriate for them to appear. It is a faster alternative to the "Not applicable" + Bound Pairs approach. However, as the feature is in the beta stage, please note that there are a couple open defects, specifically around the interaction of "Skip" constraints with the regular ones. So if you encounter any issues, feel free to reach out to Support or avoid skips for the time being.
How to Use Skip Constraints
For example, let’s use this plan below for a flight booking system:
Creating Skip Constraints
For example, let’s use the model below for a flight booking system (Figure 20):
Figure 20 - Flight
In this model (Figure 20)In this model, only customers who are in First Class get in-flight dining. Coach and Business class customers do not get in-flight dining. Therefore, test Test cases with Coach and Business class customers should have no value for “Food Choice”.First, navigate to Rules→ Constraints. Next, click the toggle Food Choice. Additionally, Coach customers do not even get Drink Choice.
| UI Steps | ||||
|---|---|---|---|---|
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
You can also skip multiple parameters that are listed next to each other in the Parameters screen. For example, let’s say that Coach customers now get no food, drink, or checked bag. Thus, they should have blanks for each of those parameters. Since we have those 3 sequentially in the table of parameters (refer to the model screenshot at the start of this article), we can use the following syntax:
...
|
...
|
|
...
|
...
|
...
Now, when we generate our test suite by navigating to Scenarios, any rows with “Coach” for “Ticket Type” have no value for “Food Choice”, “Drink Choice”, or “Checked Bag”:
The final component of "Skip" constraints is the ‘skip to end’ capability. In this case, we can tell Xray Test Case Designer that for some parameters values, skip all parameters listed later (below) on the “Parameters” page.
So, for our example, we could return to our Parameters page and reorder the elements so that “Food Choice”, “Drink Choice”, and “Checked Bag” are the last three parameters:
...
Parameter[Parameter Value] >> First Parameter to be skipped::!!
For our example, that looks like this:
Lastly, you can do a quick review of available options & syntax by clicking the “Usage” button in top-right section of the Advanced Mode:
View a Constraint
| UI Steps | ||||
|---|---|---|---|---|
| ||||
|
Edit a Constraint
...
|
Viewing a Constraint
| UI Steps | ||||||
|---|---|---|---|---|---|---|
|
Editing a Constraint
| Info |
|---|
It is not possible to edit a Constraint in the Standard View. In the Standard View, you are only allowed to delete and create a new Constraint. |
| UI Steps | ||||||||
|---|---|---|---|---|---|---|---|---|
|
Deleting a Constraint
| UI Steps | ||||||
|---|---|---|---|---|---|---|
|
| Expand | ||
|---|---|---|
| ||
If you have questions or technical issues, please contact the Support team via the Customer Portal (Jira service management) or send us a message using the in-app chat. |
It is not possible to edit a constrain at the Standard View. In the Standard View you are only allowed to delete and create a new constrain.
Delete a Constraint
To delete a constraint, hover the constraint and select the delete option:
...