Running and Publishing the TestIntro Sample: Difference between revisions

From STRIDE Wiki
Jump to navigation Jump to search
 
(36 intermediate revisions by 4 users not shown)
Line 1: Line 1:
== Building the TargetApp to Include Test Intro Sample ==
== Building Instrumented Source Under Test ==
In this step, will will add a set of sample tests that provide an overview of STRIDE testing techniques. The [[Test Intro Sample]] tests are described in the linked article.
In this step, will will add a set of sample tests that provide an overview of STRIDE testing techniques. The [[Test Intro Sample]] tests are described in the linked article.


This step requires an installation of the STRIDE Samples package. If not installed, please see [[Package_Installation#Samples|Package Installation]] for more information.
To begin, be sure that TestApp is not running, then copy the <tt>.c</tt> and <tt>.h</tt> files found in <tt>Samples/test_in_c_cpp/TestIntro</tt> to <tt>SDK/Windows/sample_src</tt> (or <tt>SDK/Posix/sample_src</tt> for Linux).  


The SDK Makefile is set up so that all .c .cpp and .h files found in the directory <tt>SDK/Linux/sample_src</tt> (or, alternatively <tt>SDK\Windows\sample_src</tt>) are included in the compile and link of the '''testapp''' target.
Once the files have been copied to <tt>sample_src</tt>, simply build TestApp as described in [[Building_an_Off-Target_Test_App | here]].


Further--as a pre-compilation step--any .h files found in <tt>sample_src</tt> are submitted to the [[s2scompile|S2 compiler]] and subsequent [[Build Tools]]. This will result in
== Running Test Intro Samples and Publishing Results to Test Space ==
* the detection of [[SCL Pragmas#Test_Units| SCL Pragmas]] which declare Test Units in these .h files
Note: To successfully publish results you are required to create a test space called '''TestIntro'''. Refer to [[Test Space Setup]] for more information.
* the inclusion of metadata into the sidb file to describe these Test Units
* the generation of test harnessing code to run the indicated Test Units and collect results


To begin, be sure that TestApp is not running, then copy the .c and .h files found in <tt>Samples/TestIntro</tt> to <tt>SDK/Linux/sample_src</tt> (or Windows equivalent). Then [[Building_the_Basic_TargetApp_and_Running_Diagnostics#Building_the_TestApp|build the TestApp]] as described in previous evaluation steps.
Here we will run all tests in the <tt>TestApp.sidb</tt> database.<ref>Note that the S2 diagnostic tests are treated separately, and are not run unless the <tt>--diagnostics</tt> option is specified to <tt>stride</tt>.</ref>


== Listing Test Units in the Database File ==
# Run the build above TestApp in a console window.
In this step, we will use stride to list the Test Units in the <tt>TestApp.sidb</tt> database.
# Invoke <tt>stride</tt> in a separate console window (different from the running TestApp) -- as shown below and verify Summary results.


Run stride as follows (or Windows equivalent):
Here are the command line parameters that we will submit to <tt>stride</tt>
<source lang="bash">
stride --list --database=~/stride/SDK/Linux/out/TestApp.sidb
</source>
 
You should see output like this:


<pre>
<pre>
s2_testintro_cclass
--database ./out/TestApp.sidb
s2_testintro_flist
--device TCP:localhost:8000
s2_testintro_testdoubles
--upload
s2_testintro_testpoints
--testspace USER:PASS@mycompany.stridetestspace.com
--project Training
--space TestIntro
</pre>
</pre>


Note that the S2 diagnostic tests (which are also present in this TestApp) are not shown in the list of Test Units.
A couple of things to note:
* You will have to replace ''USER:PASS'' with your S2-assigned TestSpace user name and password
* You will have to replace ''mycompany'' with your S2-assigned subdomain name
* The project "Training" and TestSpace "TestIntro" have been pre-created within your company STRIDE TestSpace
* If you setup [[STRIDE_Runner#Environment_Variables | environment variables]] for the '''project''' and / or '''space''' they are not required in the option file. Note: Command line options override environment variables.


== Running Test Intro Samples and Publishing Results to Test Space ==
The command line is very long, so we'll want to create a text file named ''RunTestIntro.txt'' in the <tt>SDK\Windows</tt> (or <tt>SDK/Posix</tt> for Linux) directory as an option file to submit to <tt>stride</tt>.


=== Running All Tests ===
If you haven't done so already, start <tt>TestApp</tt> running in a separate console window.
Here we will run all tests in the <tt>TestApp.sidb</tt> database.<ref>Note that the S2 diagnostic tests are treated separately, and are not run unless the <tt>--diagnostics</tt> option is specified to <tt>stride</tt>.</ref>


# Invoke TestApp in a target console as in earlier steps.
Now run stride as follows (starting from the <tt>SDK\Windows</tt> or <tt>SDK/Posix</tt> directory):
# Invoke <tt>stride</tt> as shown below and verify Summary results.


<source lang="bash">
<source lang="bash">
stride --database=~/stride/SDK/Linux/out/TestApp.sidb --device=TCP:localhost:8000
stride -O RunTestIntro.txt --run="*"
</source>
</source>
The output should look like this:
<pre>
<pre>
Loading database...
Loading database...
Connecting to device...
Connecting to device...
  runtime version: 4.1.01
Executing...
Executing test units...
  test unit "s2_testintro_flist"
   s2_testintro_cclass
    > 2 passed, 1 failed, 0 in progress, 0 not in use.
   test unit "s2_testintro_cclass"
     > 1 passed, 1 failed, 0 in progress, 0 not in use.
     > 1 passed, 1 failed, 0 in progress, 0 not in use.
   s2_testintro_flist
   test unit "s2_testintro_testdoubles"
    > 2 passed, 1 failed, 0 in progress, 0 not in use.
  s2_testintro_testdoubles
     > 3 passed, 0 failed, 0 in progress, 0 not in use.
     > 3 passed, 0 failed, 0 in progress, 0 not in use.
   s2_testintro_testpoints
   test unit "s2_testintro_testpoints"
     > 3 passed, 0 failed, 0 in progress, 0 not in use.
     > 3 passed, 0 failed, 0 in progress, 0 not in use.
   ---------------------------------------------------------------------
  test unit "s2_testintro_parameters"
   Summary: 9 passed, 2 failed, 0 in progress, 0 not in use.
    > 2 passed, 0 failed, 0 in progress, 0 not in use.
   ---------------------------------------------------------------------  
   Summary: 11 passed, 2 failed, 0 in progress, 0 not in use.


Disconnecting from device...
Disconnecting from device...
Saving result file...
Saving result file...
Uploading to test space...
</pre>
</pre>


=== Running a Subset of Tests ===
=== Viewing Results in Test Space ===
Here we will run only the Test Units named <tt>s2_testintro_cclass</tt> and <tt>s2_testintro_flist</tt> against TestApp.
First navigate to the S2-provided TestSpace with your browser. The URL has the form: <nowiki>https://companyname.stridetestspace.com</nowiki>. On the page that is presented, enter your login credentials.
 
At the top of the next page, click on the All Projects link to view the status of existing projects. Here you should see the Training project listed, with its contained TestSpace ''TestIntro'' shown.
 
Clicking the ''TestIntro'' link will present you with the ''TestIntro'' TestSpace page. From the top-line results at the bottom of the page you can drill down into the Sequence_1 results to see the test details.
 
=== Analyzing the Results ===
At this point, we recommend that you take some time to review the techniques used in the TestIntro sample tests and correlate the results shown in Test Space with the various STRIDE constructs in the sample source. The article [[Test Intro Sample]] describes the tests in detail.
 
The following articles will be helpful in your analysis:
 
*[[Test Units]]
*[[Test Macros]]
*[[Test Log]]
*[[Test Point]]
*[[Test Double]]


<source lang="bash">
stride -r "s2_testintro_cclass, s2_testintro_flist" --database=~/stride/SDK/Linux/out/TestApp.sidb --device=TCP:localhost:8000
</source>
<pre>
Loading database...
Connecting to device...
  runtime version: 4.1.01
Executing test units...
  s2_testintro_cclass
    > 1 passed, 1 failed, 0 in progress, 0 not in use.
  s2_testintro_flist
    > 2 passed, 1 failed, 0 in progress, 0 not in use.
  ---------------------------------------------------------------------
  Summary: 3 passed, 2 failed, 0 in progress, 0 not in use.


Disconnecting from device...
<hr/>
Saving result file...
<references/>
</pre>


[[Category:For Evaluators...]]
[[Category:Installation]]

Latest revision as of 20:52, 20 February 2013

Building Instrumented Source Under Test

In this step, will will add a set of sample tests that provide an overview of STRIDE testing techniques. The Test Intro Sample tests are described in the linked article.

To begin, be sure that TestApp is not running, then copy the .c and .h files found in Samples/test_in_c_cpp/TestIntro to SDK/Windows/sample_src (or SDK/Posix/sample_src for Linux).

Once the files have been copied to sample_src, simply build TestApp as described in here.

Running Test Intro Samples and Publishing Results to Test Space

Note: To successfully publish results you are required to create a test space called TestIntro. Refer to Test Space Setup for more information.

Here we will run all tests in the TestApp.sidb database.[1]

  1. Run the build above TestApp in a console window.
  2. Invoke stride in a separate console window (different from the running TestApp) -- as shown below and verify Summary results.

Here are the command line parameters that we will submit to stride

--database ./out/TestApp.sidb 
--device TCP:localhost:8000
--upload
--testspace USER:PASS@mycompany.stridetestspace.com
--project Training
--space TestIntro

A couple of things to note:

  • You will have to replace USER:PASS with your S2-assigned TestSpace user name and password
  • You will have to replace mycompany with your S2-assigned subdomain name
  • The project "Training" and TestSpace "TestIntro" have been pre-created within your company STRIDE TestSpace
  • If you setup environment variables for the project and / or space they are not required in the option file. Note: Command line options override environment variables.

The command line is very long, so we'll want to create a text file named RunTestIntro.txt in the SDK\Windows (or SDK/Posix for Linux) directory as an option file to submit to stride.

If you haven't done so already, start TestApp running in a separate console window.

Now run stride as follows (starting from the SDK\Windows or SDK/Posix directory):

stride -O RunTestIntro.txt --run="*"

The output should look like this:

Loading database...
Connecting to device...
Executing...
  test unit "s2_testintro_flist"
    > 2 passed, 1 failed, 0 in progress, 0 not in use.
  test unit "s2_testintro_cclass"
    > 1 passed, 1 failed, 0 in progress, 0 not in use.
  test unit "s2_testintro_testdoubles"
    > 3 passed, 0 failed, 0 in progress, 0 not in use.
  test unit "s2_testintro_testpoints"
    > 3 passed, 0 failed, 0 in progress, 0 not in use.
  test unit "s2_testintro_parameters"
    > 2 passed, 0 failed, 0 in progress, 0 not in use.
  --------------------------------------------------------------------- 
  Summary: 11 passed, 2 failed, 0 in progress, 0 not in use.

Disconnecting from device...
Saving result file...

Viewing Results in Test Space

First navigate to the S2-provided TestSpace with your browser. The URL has the form: https://companyname.stridetestspace.com. On the page that is presented, enter your login credentials.

At the top of the next page, click on the All Projects link to view the status of existing projects. Here you should see the Training project listed, with its contained TestSpace TestIntro shown.

Clicking the TestIntro link will present you with the TestIntro TestSpace page. From the top-line results at the bottom of the page you can drill down into the Sequence_1 results to see the test details.

Analyzing the Results

At this point, we recommend that you take some time to review the techniques used in the TestIntro sample tests and correlate the results shown in Test Space with the various STRIDE constructs in the sample source. The article Test Intro Sample describes the tests in detail.

The following articles will be helpful in your analysis:



  1. Note that the S2 diagnostic tests are treated separately, and are not run unless the --diagnostics option is specified to stride.