Skip to content
QiTASC.com / intaQt Verification / intaQt Verification Rules /
Introduction
/ .. / .. /
Introduction










intaQt Verification Rules

Verification Rules files consist Selectors used to define which tickets to verify as well as the Verification Rules that will be applied to the tickets.

Selectors are written in variables blocks that define ticket types (such as MOC or SMS) and their characteristics. Next, creating Verification Rules enable checking that the selected ticket types match test case execution expected criteria. All Selectors and Rules files must be in files with the .rules extension.

Additional Verification Built-ins are available for defining Selectors.

Verification Rules Basics
Selectors
Defining Rules
Verify Any of Rules Blocks
Verify One of Rules Blocks
Including Other Rules Files
Replace Rules

Notes: Information required to set Selectors is included within project-specific documentation.

Selectors

Selectors define criteria that tell intaQt Verification which CDRS to use. For example, a Selector may specify that only voice call tickets should be used. Typically, a test project will have multiple Selectors. All Selectors are defined within a variables block. For example, a ticket with a certain ID, or where a certain activity type occurs. Additional Verification Built-ins are available for defining Selectors.

Syntax 

1
2
3
4
variables
    <selector Identifier> = Tickets(<criteria String>);
...
end

Parameters

  • selector - The Selector name.

  • criteria - The Boolean condition that selects matching tickets.

Example 

1
2
3
4
5
variables
    MOC1 = Tickets("Ticket_ID == '77'");
    MOC2 = Tickets("Ticket_ID == '88' && MOC1.CallingNumber != CallingNumber");
    SMS  = Tickets("Ticket_ID == '99'");
end

In the example above, the first Selector (MOC1) searches for tickets with 77 as their ID. The second Selector (MOC2) searches for tickets with 88 as their ID, and whose calling number is not the same as that for MOC2. The third ticket (SMS) searches for tickets with 99 as their ID. All other tickets generated will be excluded.

Rules Blocks

Rules define the type of check that intaQt Verification will perform against the selected CDRs. A Rules block specifies the Rules that are applied to the tickets found by the Selector of a same name. For example, the a Selector named MOC1 would have an associated Rules block named MOC1.

A Rules block is considered as passed whenever all its enclosed Rules pass. It can verify either any of the Rules match or one of the Rules matches against the tickets.

Defining Rules

All Rules start with check followed by parameters and values to match against tickets. The name of the Rule must match the name of the Selector it accesses. In additional to verifying parameters, the Test Case Structure Rule checks that a test case consists of a specified amount of tickets types. Additionally, adding the if present clause indicates that a property will only be checked if present. Omitting the if present clause indicates that if the property is not present the test case should fail.

Example 

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
MOC {
    check "RECORD_LENGTH" equals 32;
    check "RECORD_TON" equals 32;
    // if fieldA is not present, the following Rule will not be checked
    check "fieldA" matches "^.{0,2}$" if present;
}

SMS {
    check "Number_of_Messages" equals 1;
}
// Test case structure Rule
Testcase {
    check structure consists of 1 MOC;
}

The example above contains three Rules. The first two Rules, MOC and SMS refer to two Selectors also named MOC and SMS and verify that conditions including recording length and number of messages. The Testcase Rule checks that the test case consists of only one MOC.

Notes:

  • Expressions must not contain a closing bracket }, (e.g. ${ctx['var{1}']}) because they will be interpreted as the expression's closing bracket.

  • Each Rule must end with a semicolon (;) .

Including Other Rules Files

The include statement invokes external Rules files, such as those in other projects.

Syntax 

1
include <importedRule NameOrPath>
Parameters

  • importedRule - The name or path to the external Rules file.

Example 

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
include DATA;

variables
  MOC = Tickets("Ticket_ID == '77'");
  SMS = Tickets("Ticket_ID == '99'");
end

MOC {
    check "Balance_before_Event" equals 6;
    check "Ticket_ID" equals "77";
    check "Other_Costs" equals 0;
    check "FreeUnits" equals "";
    check "Call_Start_Time" and
    ${ctx.A.outgoingCalls.connectTime[0]} within 1500 milliseconds;
    check "A_Party" against
    ${ctx.nationalFormat} based on ${ctx.A.number};
    check "Call_Duration" within 1 from ${ctx.callDur};
}

The example above invokes the Rules file, DATA (DATA.rules), which contains additional Rules:

1
2
3
4
5
6
DATA {
    check "Balance_before_Event" equals 0;
    check "Ticket_ID" equals "88";
    check "Other_Costs" equals "";
    check "FreeUnits" equals "";
}

Replace Rules

The replace statement replace previously-defined Rules with new Rules.

Syntax 

1
2
3
4
5
6
7
<selector Identifier> {
    replace {
        <oldRule Rule>;
    } with {
        <newRule Rule>;
    }
}

Parameters

  • selector - The Selector name invoked by the Rule block.

  • oldRule - The Rule to replace.

  • newRule - The Rule replacing the oldRule.

Example 

1
2
3
4
5
6
7
R_MOC {
    replace {
        check "A_Party" against ${ctx.nationalFormat} based on ${ctx.A.number};
    } with {
        check "A_Party" against ${ctx.internationalFormat} based on ${ctx.A.number};
    }
}

In the example above, R_MOC expects a ticket with the same Ticket_ID as MOC, with an additional non-empty property called Roaming_Code.

Verify Any of Rule Blocks

The verify any of statement specifies that if all the Rules within any of the specified blocks pass, the block will pass -- whether or not Rules in other blocks fail.

Syntax 

1
2
3
4
5
6
<selector Identifier> {
    verify any of {
      <rules Block>
      ...
    }
}
Parameters

  • selector - The Selector name invoked by the Rule block.

  • rules - The block of Rules contained within the Selector.

Example Rules Block 

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
variables
    TICKET = Tickets("type == 'TICKET'");
end

TICKET {
    verify any of {
       check "A" equals "FAILURE";
    } or {
      check "B" equals "2";
      check "C" equals "3";
    }
}
Example Tickets 
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
TICKET Record='1' {
    A 1 [1]
    B 2 [2]
    C 3 [3]
}
TICKET Record='2' {
    A 3 [3]
    B 4 [4]
    C 5 [5]
}
In the example above, the TICKET Rules block TICKET refers to a Selector also be named TICKET. The test case with the TICKET Selector will fail, because neither blocks are fulfilled for all selected tickets:

  • None of the tickets match the first block (check "A" equals "FAILURE").

  • Only one of the two tickets matches the second block (check "B" equals "2"; and check "C" equals "3";).

If the Selector's condition are Record == '1' instead of type == 'TICKET', the test case will pass, because the second block of Rules was successfully applied. If the Selector's condition are Record == '2' instead of type == 'TICKET', the test case will fail because none of the Rule blocks were successfully applied.

Verify One of Rule Blocks

The verify one of statement specifies that when all Rules within one of the Rule blocks passes, the entire block will pass. However, if more than one block of Rules passes, the result will be failed.

Syntax 

1
2
3
4
5
<selector Identifier> {
    verify one of {
      <rules Block>
    } ...
}
Parameters

  • selector - The Selector name invoked by the Rule block.

  • rules - The block of Rules contained within the Selector.

Example Rules Block 

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
variables
    TICKET = Tickets("type == 'TICKET'");
end

TICKET {
    verify one of {
        check "A" equals "7";
    } or {
        check "B" equals "2";
        check "C" equals "3";
    }
}
Example Tickets 
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
TICKET Record='1' {
    A 1 [1]
    B 2 [2]
    C 3 [3]
}
TICKET Record='2' {
    A 7 [7]
    B 2 [2]
    C 3 [3]
}
TICKET Record='3' {
    A 0 [0]
    B 0 [0]
    C 0 [0]
}

In the example above, the TICKET Rules block TICKET refers to a Selector also be named TICKET. TTe test case with the TICKET Selector will fail, because no blocks are fulfilled for all selected tickets:

  • Only one of the tickets matches the first block (check "A" equals "7").

  • Only two of the three tickets matches the second block (check "B" equals "2"; and check "C" equals "3";).

If the Selector's condition is Record == '1' instead of type == 'TICKET', the test case will pass because the second block of Rules was successfully applied. If the Selector's condition is Record == '2' instead of type == 'TICKET', the test case will fail because more than one Rule blocks were successfully applied. If the Selector's condition is Record == '3' instead of type == 'TICKET', the test case will fail because none of the Rule blocks were successfully applied.