Training Perl: Difference between revisions
No edit summary |
No edit summary |
||
Line 1: | Line 1: | ||
The '''Perl''' training focuses on ''Test Points'' validation with limited | The '''Perl''' training focuses on ''Test Points'' validation with limited ''Remoting'' for controlling the software under test. | ||
''A few words of caution''. Using Perl for testing when applied to the right situation can be a very compelling. At the same time there are challenges to be considered. A script executed by Stride runs on the host .. '''not''' on the actual device. Because of this certain limits should be assessed. For example, although Stride supports remoting of global functions (i) ''how to qualify a function signature using pragmas (i.e. out pointers)'' and (ii) ''how to access these types of fields using Perl'' can be very challenging. | ''A few words of caution''. Using Perl for testing when applied to the right situation can be a very compelling. At the same time there are challenges to be considered. A script executed by Stride runs on the host .. '''not''' on the actual device. Because of this certain limits should be assessed. For example, although Stride supports remoting of global functions (i) ''how to qualify a function signature using pragmas (i.e. out pointers)'' and (ii) ''how to access these types of fields using Perl'' can be very challenging. |
Revision as of 00:33, 26 November 2014
The Perl training focuses on Test Points validation with limited Remoting for controlling the software under test.
A few words of caution. Using Perl for testing when applied to the right situation can be a very compelling. At the same time there are challenges to be considered. A script executed by Stride runs on the host .. not on the actual device. Because of this certain limits should be assessed. For example, although Stride supports remoting of global functions (i) how to qualify a function signature using pragmas (i.e. out pointers) and (ii) how to access these types of fields using Perl can be very challenging.
This sample demonstrates the advantages of host based scripting without the concerned mentioned above. The remoting used are for the following routines:
void sut_start_thread(void); void sut_stop_thread(void);
Some of the advantages that will be shown:
- test coverage can be expanded without any changes to the target build
- nominal test code space requirements for software under test
- seamless integration of test results from both target-based tests and script tests
Test Points
This test suite focuses on Test Points and how to validate them using a Perl script module.
The following articles are related to this example:
- Presentation of a validation technique based on code sequencing and state data
- Overview of source instrumentation
- Review of expectation tables and predicates using Perl
- Test Point Macro definition
The Test Suite is called testpoints.pm and is implemented in: testpoints.pm. The comments and descriptions are contained in the header blocks using POD. Three test cases (methods) are already implemented and one test method that can be used to make changes to is called TryStuff. Currently the TryStuff test method is set to not in use.
First thing to do is run the TestPoints Suite. Start the TestApp.exe and use the following command:
stride --options_file my.opt --run "..\training\testpoints.pm
You can take a look at the results in TestApp.xml.
Consider the following for TryStuff:
- Write a test to validate a subset of Test Points
- Write a test to wait on a trigger TRIGGER and then validate "A", "C", and "G"