Studio:Using Scripts to Automate Software Testing - Revision history

Timd: Text replace - 'Category:Scripting' to 'Category:Studio:Scripting'

2009-08-20T23:46:12Z

Text replace - 'Category:Scripting' to 'Category:Studio:Scripting'

← Older revision		Revision as of 23:46, 20 August 2009
Line 136:		Line 136:
	</source>		</source>

	[[Category:Scripting]]		[[Category:Studio:Scripting]]

Timd: Using Scripts to Automate Software Testing moved to Studio:Using Scripts to Automate Software Testing

2009-08-18T22:10:27Z

Using Scripts to Automate Software Testing moved to Studio:Using Scripts to Automate Software Testing

← Older revision	Revision as of 22:10, 18 August 2009
(No difference)

Ivailop at 17:58, 12 February 2009

2009-02-12T17:58:43Z

← Older revision		Revision as of 17:58, 12 February 2009
Line 1:		Line 1:
	This entry shows how to use a script running in STRIDE Studio to test a function. The basic technique is also applicable to less-frequently-used messaging interfaces.		This entry shows how to use a script running in [[STRIDE Studio]] to test a function. The basic technique is also applicable to less-frequently-used messaging interfaces.

	In STRIDE terminology, the script is the ''User'' of the interface. (In contrast, [[Using Scripts to Simulate Missing Software Units]] involves a script that is the ''Owner'' of an interface.)		In STRIDE terminology, the script is the ''User'' of the interface. (In contrast, [[Using Scripts to Simulate Missing Software Units]] involves a script that is the ''Owner'' of an interface.)

Ivailop at 00:32, 15 October 2008

2008-10-15T00:32:29Z

← Older revision		Revision as of 00:32, 15 October 2008
Line 3:		Line 3:
	In STRIDE terminology, the script is the ''User'' of the interface. (In contrast, [[Using Scripts to Simulate Missing Software Units]] involves a script that is the ''Owner'' of an interface.)		In STRIDE terminology, the script is the ''User'' of the interface. (In contrast, [[Using Scripts to Simulate Missing Software Units]] involves a script that is the ''Owner'' of an interface.)

	The script's injected '''ascript''' object instance provides the bridge between the interfaces in your embedded application and your favorite scripting language. ~~For additional details, see the Online Help installed with STRIDE Studio.~~		The script's injected '''[[AutoScript\|ascript]]''' object instance provides the bridge between the interfaces in your embedded application and your favorite scripting language.

	=Example=		=Example=

Ivailop: /* Header File */

2008-10-02T16:33:57Z

Header File

← Older revision		Revision as of 16:33, 2 October 2008
Line 15:		Line 15:
	Notice that it is annotated with SCL <code>#pragma</code>s to provide needed metadata to the STRIDE compiler. When SCL <code>#pragma</code>s are inline with the source, we generally surround them with <code>#ifdef</code>s to prevent them from being seen by your code compiler.		Notice that it is annotated with SCL <code>#pragma</code>s to provide needed metadata to the STRIDE compiler. When SCL <code>#pragma</code>s are inline with the source, we generally surround them with <code>#ifdef</code>s to prevent them from being seen by your code compiler.

	<source lang="~~cpp~~">		<source lang="c">
	#ifndef _LEAPYEAR_H_		#ifndef _LEAPYEAR_H_
	#define _LEAPYEAR_H_		#define _LEAPYEAR_H_

Timd at 18:15, 6 March 2008

2008-03-06T18:15:01Z

← Older revision		Revision as of 18:15, 6 March 2008
Line 137:		Line 137:

	[[Category:Scripting]]		[[Category:Scripting]]

	~~[[Category:Code Samples]]~~

Timd at 18:13, 6 March 2008

2008-03-06T18:13:32Z

← Older revision		Revision as of 18:13, 6 March 2008
Line 137:		Line 137:

	[[Category:Scripting]]		[[Category:Scripting]]

			[[Category:Code Samples]]

Timd at 17:57, 5 March 2008

2008-03-05T17:57:12Z

@@ Line 1: / Line 1: @@
 This entry shows how to use a script running in STRIDE Studio to test a function. The basic technique is also applicable to less-frequently-used messaging interfaces.
@@ Line 66: / Line 65: @@
 Note that we use a single test case to test the entire set of input values, and we bail out of the test at the first failure. Another approach is to create a test case for each input value.
 ===Perl Test===
@@ Line 137: / Line 103: @@
 </source>
 [[Category:Scripting]]

Timd at 17:49, 5 March 2008

2008-03-05T17:49:49Z

← Older revision		Revision as of 17:49, 5 March 2008
Line 1:		Line 1:
	Much of what software developers generally dislike about testing can be overcome with better automation. Not only does automation reduce repetition, it will also help to ensure the accuracy and repeatability of tests. Because STRIDE makes your embedded application's interfaces accessible in the scripting language of your choice, using scripts is an ideal way to better automate testing.

	~~The subject of this topic defines~~ how to use ~~scripts to supply inputs~~ to a function~~, component, or application over one or more interfaces~~. ~~These interfaces can be messaging~~-~~based or function~~-based. In STRIDE terminology, the script tends to be the ''User'' of the interface or interfaces. (In contrast, [[Using Scripts to Simulate Missing Software Units]] tends to involve scripts that are the ''Owner'' of an interface or interfaces.)		This entry shows how to use a script running in STRIDE Studio to test a function. The basic technique is also applicable to less-frequently-used messaging interfaces.

	~~Via its objects, methods, and properties~~, '''~~ascript~~'~~'' is the bridge between the interfaces in your embedded application and your favorite scripting language. A complete list~~ of the ~~objects, methods, and properties for use in your scripts can be found in the Online Help installed with STRIDE Studio~~. ~~The objective of this topic is to focus on those objects, methods~~, ~~and properties you will need~~ to ~~automate~~ the ~~testing~~ of ~~your software~~.		In STRIDE terminology, the script is the ''User'' of the interface. (In contrast, [[Using Scripts to Simulate Missing Software Units]] involves a script that is the ''Owner'' of an interface.)

	~~Note: To test a function, component, or application using a~~ script, the ~~corresponding interface(s) must be [accessible to STRIDE]~~. ~~In addition~~, ~~you will need an [intercept module] if any of~~ the ~~interfaces cross platform boundaries~~.		The script's injected '''ascript''' object instance provides the bridge between the interfaces in your embedded application and your favorite scripting language. For additional details, see the Online Help installed with STRIDE Studio.

	=Example=		=Example=
			In this example, we will be testing a target-based function that takes an integer as an argument, and returns an enumeration indicating whether the passed-in number is a leap year.

	~~<source lang="cpp">~~		In an actual testing scenario, the function would be implemented on your target system. Also, the example header file would be added to your workspace and the script file would be created and added to your workspace.
	/*
	~~The Gregorian calendar has 97 leap years every 400 years:~~

	~~Every year divisible by 4~~ is ~~a leap year~~, ~~except:.~~		==Header File==
	~~- a year divisible by 100 is not a leap year except:~~		Below is the sample <code>.h</code> file that defines the interface we will be testing. Typically, this is a header file from the target codebase.
	~~- a year divisible by 400~~ is a ~~leap year after all~~.

	~~For simplicity, any year prior~~ to the ~~introduction of~~ the ~~Gregorian Calendar~~		Notice that it is annotated with SCL <code>#pragma</code>s to provide needed metadata to the STRIDE compiler. When SCL <code>#pragma</code>s are inline with the source, we generally surround them with <code>#ifdef</code>s to prevent them from being seen by your code compiler.
	~~(1582) is considered~~ to ~~be NOT a leap year~~.
	*/

			<source lang="cpp">
	#ifndef _LEAPYEAR_H_		#ifndef _LEAPYEAR_H_
	#define _LEAPYEAR_H_		#define _LEAPYEAR_H_
Line 47:		Line 43:

	#ifdef _SCL		#ifdef _SCL
	// ~~tell~~ the STRIDE compiler that the IsLeapYear should be captured (i.e. instrumented)		// Tell the STRIDE compiler that the IsLeapYear should be captured (i.e. instrumented).
			// Capturing the function allows it to be called from a script
	#pragma scl_function(IsLeapYear)		#pragma scl_function(IsLeapYear)
	// ~~tell~~ the STRIDE compiler that the return value of IsLeapYear is constrained to		// Tell the STRIDE compiler that the return value of IsLeapYear is constrained to
	// the enumeration eIsLeapYear		// the enumeration eIsLeapYear
	#pragma scl_values(IsLeapYear(), eIsLeapYear)		#pragma scl_values(IsLeapYear(), eIsLeapYear)
Line 57:		Line 54:
	</source>		</source>

			In a testing scenario, this header file is processed by the STRIDE compiler to produce a metadata database, and an Intercept Module (IM) is generated. The IM comprises a set of source files that provide proxy/stub functionality for the captured functions. The IM files become part of your target code build.

			Note that once built, STRIDE compilation and IM generation only needs to be done if the function signature changes.

			You can now use a script to interact with the captured function.

			==Test Scripts==
			The following example test scripts demonstrate how to set up and call a remote function. They also show rudimentary use of the '''testSuite''' object to report on test results.

			The scripts provide identical functionality: a common pattern of exercising the target function by calling it in a loop iterating through a set of inputs. The function's return value is validated and the test result set accordingly.

			Note that we use a single test case to test the entire set of input values, and we bail out of the test at the first failure. Another approach is to create a test case for each input value.

			===JScript Test===
	<source lang="javascript">		<source lang="javascript">
	// create a new test in the parent suite		// create a new test in the parent suite
Line 89:		Line 100:
	</source>		</source>

			===Perl Test===
	<source lang="perl">		<source lang="perl">
			# standard STRIDE preamble for Perl
	use strict;		use strict;
	use Win32::OLE;		use Win32::OLE;
	Win32::OLE->Option(Warn => 3);		Win32::OLE->Option(Warn => 3);

			# create a new test in the parent suite
	my $test = $main::testSuite->Tests->Add("Leap Year Positive Test");		my $test = $main::testSuite->Tests->Add("Leap Year Positive Test");

			# initialize the test input values
	my @input = (1600, 1604, 1996, 2000);		my @input = (1600, 1604, 1996, 2000);

			# get the function user instance
	my $f = $main::ascript->Functions->Item("IsLeapYear")->User;		my $f = $main::ascript->Functions->Item("IsLeapYear")->User;

			# iterate through the members of arInput
	for my $i (0..$#input)		for my $i (0..$#input)
	{		{
			# set the parameter value
	$f->ParameterList->{uYear} = $input[$i];		$f->ParameterList->{uYear} = $input[$i];

			# call the function synchronously; the STRIDE runtime will route the call to the
			# currently registered function owner
	$f->Call();		$f->Call();

			# test the return value; note that the value is returned as the name of the enumerator
	if ($f->ReturnValue eq "YES") {		if ($f->ReturnValue eq "YES") {
	$test->{Status} = "PASS";		$test->{Status} = "PASS";

Timd at 16:29, 5 March 2008

2008-03-05T16:29:04Z

← Older revision		Revision as of 16:29, 5 March 2008
Line 7:		Line 7:
	Note: To test a function, component, or application using a script, the corresponding interface(s) must be [accessible to STRIDE]. In addition, you will need an [intercept module] if any of the interfaces cross platform boundaries.		Note: To test a function, component, or application using a script, the corresponding interface(s) must be [accessible to STRIDE]. In addition, you will need an [intercept module] if any of the interfaces cross platform boundaries.

			=Example=

	<source lang="cpp">		<source lang="cpp">