Training Perl: Difference between revisions
No edit summary |
|||
| (2 intermediate revisions by the same user not shown) | |||
| Line 3: | Line 3: | ||
''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. | ||
This sample demonstrates the advantages of host based scripting ''without'' the | This sample demonstrates the advantages of host based scripting ''without'' the concerns mentioned above. The remoting used are for the following routines: | ||
void sut_start_thread(void); | void sut_start_thread(void); | ||
void sut_stop_thread(void); | void sut_stop_thread(void); | ||
Example option file ''my.opt'' used below for running | |||
--database "%STRIDE_DIR%\SDK\Windows\out\TestApp.sidb" | |||
--device TCP:localhost:8000 | |||
Some of the advantages that will be shown: | Some of the advantages that will be shown: | ||
| Line 18: | Line 23: | ||
The following articles are related to this example: | The following articles are related to this example: | ||
* Presentation of a [[Expectations | validation]] technique based on ''code sequencing'' and ''state data'' | * Presentation of a [[Expectations | validation]] technique based on ''code sequencing'' and ''state data'' | ||
* | * [[Test Point]] definition | ||
* Review of [[ Perl_Script_APIs#STRIDE::TestPoint | expectation tables and predicates]] using Perl | * Review of [[ Perl_Script_APIs#STRIDE::TestPoint | expectation tables and predicates]] using Perl | ||
The Test | The Test Script 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'' | First thing to do is run the ''TestPoints'' Test Script. Start the '''TestApp.exe''' and use the following command: | ||
stride --options_file my.opt --run "..\training\testpoints.pm'' | stride --options_file my.opt --run "..\training\testpoints.pm'' | ||
Latest revision as of 21:52, 6 July 2015
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 concerns mentioned above. The remoting used are for the following routines:
void sut_start_thread(void); void sut_stop_thread(void);
Example option file my.opt used below for running
--database "%STRIDE_DIR%\SDK\Windows\out\TestApp.sidb" --device TCP:localhost:8000
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
- Test Point definition
- Review of expectation tables and predicates using Perl
The Test Script 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 Test Script. 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 by opening the generated stride.html in your browser.
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"