Changes between Version 29 and Version 30 of TBR/UserManual/RTEMS_Coverage_Analysis

Timestamp:

09/09/09 20:24:57 (15 years ago)

Author:

GlennHumphrey

Comment:

More work on intro

TBR/UserManual/RTEMS_Coverage_Analysis

@@ -18 +18 @@
 In order to achieve the 100% tested goal, it is important to define what constitutes 100% tested.  A lot of information exists about how to completely test a software application.  In general, the term [http://en.wikipedia.org/wiki/Code_coverage Code Coverage] is used to refer to the analysis that is performed to determine what portions of the software are tested by the test suite and what portions are not tested.  For some background information on Code Coverage Analysis, see [wiki:Developer/Coverage/CoverageAnalysisTheory Coverage Analysis Theory].
 
-Traditionally, Code Coverage Analysis has been performed by instrumenting the source code or object code or by using special hardware to monitor the instructions executed.  The objectives of the RTEMS code coverage effort are to use existing tools and to avoid altering the code to be analyzed.  This can be accomplished by using a processor simulator that provides coverage analysis information.  The information can be processed to determine which instructions are executed.  We call this object code coverage.  Initially, we set out to achieve 100% object code coverage of the RTEMS executive.
+Traditionally, Code Coverage Analysis has been performed by instrumenting the source code or object code or by using special hardware to monitor the instructions executed.  The guidelines for the RTEMS code coverage effort were to use existing tools and to avoid altering the code to be analyzed.  This was accomplished by using a processor simulator that provides coverage analysis information.  The information was processed to determine which instructions are executed.  We called this object code coverage and we defined 100% tested to be 100% object code coverage.
 
-In addition to defining the method for determining 100% tested, it is also important to define what is actually being tested.  The RTEMS executive is a large body of code.  In order to contain the testing effort, the concept of profiles was introduced to provide boundaries for what is actually tested.
+In addition to defining the method for determining 100% tested, it is also important to define what is actually being tested.  We accomplished this by defining a set of Coverage Profiles that allowed us to specify the feature set, configuration options and compiler options used when performing the analysis.  This was important for two reasons.  First, it allowed to simplify the problem space (uncovered code) so that the goal was attainable and second, we wanted to recognize that not all RTEMS users configure RTEMS in the same manner.  The first profile that we defined encompassed the RTEMS executive and was called the POSIX Enabled Profile.  The RTEMS executive is a large body of code that is generally defined to contain the score, sapi, rtems, and posix directories in the cpukit directory.  This represents the full tasking and synchronization feature set.  More details about Coverage Profiles is discussed below.  Initially, we set out to achieve 100% object code coverage of the POSIX Enabled Profile.
 = How it was Done =