Rational Test Real Time (RTRT) :-

RTRT uses ATTOL test description language that allows test scenarios to be defined in a simple way.

RTRT Contains :-

Test plan generator : Analyzes the test file(source code under test) and generates an initial test plan template, in the ATTOL language.

Test generator. This converts test specifications written in the ATTOL language to a programming language syntax and to be compiled and linked to all or part of the application.

A run time (ATTOL run time) which takes into account the nature of the execution target, will also be linked to the test program. This is part of Target Deployment Port (TDP).

A “trace” file is created when the test program is executed. This file will be analyzed by the Report generator, which generates the test report.

Target Deployment Port (TDP):-

What is TDP?

• A low-overhead technology enabling both limitless embedded target support and target-independent testing and run time analysis capabilities
• Built to accommodate the compiler, linker, debugger, and target architecture. The TDP acts as a buffer between your target architecture and all test and runtime analysis assets, ensuring full product independence
• The product assets don’t have to change when the environment does. Test script deployment, execution and reporting remain unaffected by a changing environment
• Compiler dialect-aware and linker-aware, for transparent test building.
• Simplified upload of the test harness onto your target via your own IDE, debugger, simulator or emulator.
• Painless test and runtime analysis results download from the target environment using JTAG probes, emulators or any available communication link, such as serial, Ethernet or file system.
• Powerful test execution monitoring to distribute, start, synchronize and stop test harness components, as well as to implement communication and exception handling.
• Versatile communication protocol adaptation to send and receive test messages.
• XML-based TDP editor enabling simple, in-house TDP creation and customization.

Testing Process in RTRT :-

• Generation of the basic skeleton (test plan template)
• SDD analysis and writing comments
  • functionality to cover
  • input & output data to be tested
  • CSU to stub
• Pre-calculate expected value for each test data
• Stub definitions
• Execute the test
• Check the test result and test coverage

What is STUB :-

Stubs are simulated implementations of functions that cannot be run in the testing environment, or functions for which the user wishes to give an alternative implementation for testing purposes

Supported by ATTOL, using the key word DEFINE STUB. It is mandatory that test should validate the parameter values, passed during the stub call.

If the interface to stub is internal to the CSC, this feature is not directly supported by ATTOL. The tester must develop some code in the PTU to check the call to those interfaces (For ada testing, internal procedures can be simulated in SIMUL block )

ATTOL Keywords:-

ATTOL provides a minimal set of 20 keywords. Some basic keywords are

• HEADER
• BEGIN
• SIMUL .. ELSE_SIMUL .. END SIMUL
• SERVICE … END SERVICE
• FAMILY
• FORMAT
• TEST… END TEST
• ELEMENT… END ELEMENT
• DEFINE STUB… END DEFINE
• ENVIRONMENT… END ENVIRONMENT… USE
• COMMENT
• CONST,VAR, STRUCTURE, ARRAY, STUB

Test Script Model :-

Syntax : –

HEADER [module_name], [module_version], [test_plan_version]

BEGIN [ parent unit [ , separate procedure ] ]

DEFINE STUB stub_name [ stub_dim ]
END DEFINE ( Explanation about in, out, inout and no types of parameters )

ENVIRONMENT name

END ENVIRONMENT

USE name

SERVICE service_name

END SERVICE

TEST test_name

END TEST

ELEMENT

END ELEMENT

VAR     <var.name>,             init = <initial_value>, ev = <expected_value>

STRUCTURE <str.name>,   init = <initial_value>, ev = <expected_value>

ARRAY <arr.name>,             init = <initial_value>, ev = <expected_value>

STR is also an alternative short notation for STRUCTURE keyword.

STUB keyword is used to test the external function/procedure call in the CSU.

STUB <stubname> <no. of call(optional) > (parameters) return value

COMMENT keyword is followed by statements that shall appear in the test report.

— keyword is followed by test script comments which shall not appear in the report, but an additional information.

# keyword is followed by native language statements. If C code is tested, then # should be followed by valid C syntax statement.

There are some more keywords and is beyond the scope of this presentation. Beginners are advised to explore the tool manuals to know more about the keywords.