Training Perl: Difference between revisions

From STRIDE Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 10: Line 10:
Some of the advantages that will be shown:
Some of the advantages that will be shown:
* '''test coverage''' can be '''expanded''' without any changes to the target build
* '''test coverage''' can be '''expanded''' without any changes to the target build
* nominal '''code space''' requirements for software under test  
* nominal '''test code''' space requirements for software under test  
* seamless '''integration''' of test results from both '''target-based tests''' and '''script tests'''
* seamless '''integration''' of test results from both '''target-based tests''' and '''script tests'''



Revision as of 18:16, 25 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:

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"