Training Perl - Revision history

Marku at 21:52, 6 July 2015

2015-07-06T21:52:06Z

← Older revision		Revision as of 21:52, 6 July 2015
Line 23:		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''
	* ~~Overview of~~ [[~~Source_Instrumentation_Overview#Instrumentation \| source instrumentation~~]]		* [[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
	* [[Test Point]] 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''.		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'' ~~Suite~~. Start the '''TestApp.exe''' and use the following command:		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''

Marku at 18:45, 27 November 2014

2014-11-27T18:45:05Z

← Older revision		Revision as of 18:45, 27 November 2014
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 ~~concerned~~ mentioned above. The remoting used are for the following routines:		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);

Marku at 16:17, 27 November 2014

2014-11-27T16:17:44Z

← Older revision		Revision as of 16:17, 27 November 2014
Line 7:		Line 7:
	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:

Ivailop: /* Test Points */

2014-11-26T23:37:23Z

Test Points

← Older revision		Revision as of 23:37, 26 November 2014
Line 20:		Line 20:
	* Overview of [[Source_Instrumentation_Overview#Instrumentation \| source instrumentation]]		* Overview of [[Source_Instrumentation_Overview#Instrumentation \| source instrumentation]]
	* 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
	* [[Test Point]] ~~Macro~~ definition		* [[Test Point]] 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''.		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''.
Line 28:		Line 28:
	stride --options_file my.opt --run "..\training\testpoints.pm''		stride --options_file my.opt --run "..\training\testpoints.pm''

	You can take a look at the results in '''~~TestApp~~.~~xml~~'''.		You can take a look at the results by opening the generated '''stride.html''' in your browser.

	Consider the following for '''TryStuff''':		Consider the following for '''TryStuff''':
	* Write a test to validate a subset of Test Points		* 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"		* Write a test to wait on a trigger '''TRIGGER''' and then validate "A", "C", and "G"

Marku at 00:33, 26 November 2014

2014-11-26T00:33:54Z

← Older revision		Revision as of 00:33, 26 November 2014
Line 1:		Line 1:
	The '''Perl''' training focuses on ''Test Points'' validation with limited ~~remoting~~ for controlling the software under test.		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.

Marku at 18:16, 25 November 2014

2014-11-25T18:16:43Z

← Older revision		Revision as of 18:16, 25 November 2014
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'''

Marku at 17:13, 24 November 2014

2014-11-24T17:13:45Z

← Older revision		Revision as of 17:13, 24 November 2014
Line 1:		Line 1:
	The '''Perl''' training focuses on ''Test Points'' validation with limited remoting for controlling the software under test.		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. ~~If the software under test is executing on the device~~ 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 ~~at times~~ 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 concerned mentioned above. The remoting used are for the following routines:		This sample demonstrates the advantages of host based scripting ''without'' the concerned mentioned above. The remoting used are for the following routines:
Line 9:		Line 9:

	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 ~~device.~~		* '''test coverage''' can be '''expanded''' without any changes to the target build
	* ~~no additional~~ '''code space''' requirements ~~on the device once the~~ software under test ~~is [[Source Instrumentation~~		* nominal '''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'''

	== Test Points ==		== Test Points ==
Line 22:		Line 22:
	* [[Test Point]] Macro definition		* [[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 called '''TryStuff'''. Currently ~~this~~ test method is set to ''not in use''.		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:		First thing to do is run the ''TestPoints'' Suite. Start the '''TestApp.exe''' and use the following command:
Line 30:		Line 30:
	You can take a look at the results in '''TestApp.xml'''.		You can take a look at the results in '''TestApp.xml'''.

	Consider ~~trying~~ the following:		Consider the following for '''TryStuff''':
	* Write a test to validate a subset of Test Points		* Write a test to validate a subset of Test Points
	* Write a test to wait on a trigger '''TRIGGER''' and ~~than~~ validate "A", "C", and "G"		* Write a test to wait on a trigger '''TRIGGER''' and then validate "A", "C", and "G"

Marku: Created page with "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 testin..."

2014-11-22T18:31:48Z

Created page with "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 testin..."

New page

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. If the software under test is executing on the device 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 at times 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 device.
* no additional '''code space''' requirements on the device once the software under test is [[Source Instrumentation
* 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 [[Expectations | validation]] technique based on ''code sequencing'' and ''state data''
* Overview of [[Source_Instrumentation_Overview#Instrumentation | source instrumentation]]
* Review of [[ Perl_Script_APIs#STRIDE::TestPoint | 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 called '''TryStuff'''. Currently this 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 trying the following:
* Write a test to validate a subset of Test Points
* Write a test to wait on a trigger '''TRIGGER''' and than validate "A", "C", and "G"