Changes between Initial Version and Version 1 of TBR/UserManual/RTEMS_Coverage_Analysis


Ignore:
Timestamp:
Aug 5, 2009, 9:10:41 PM (10 years ago)
Author:
JoelSherrill
Comment:

First content cut and pasted from Open Projects

Legend:

Unmodified
Added
Removed
Modified
  • TBR/UserManual/RTEMS_Coverage_Analysis

    v1 v1  
     1= RTEMS Coverage Analysis =
     2
     3
     4This task consists of performing automated coverage testing using an open
     5source simulator.  The [wiki:Developer/Simulators/SkyEye SkyEye] project is currently adding coverage
     6analysis capabilities per our specifications.  When those are available,
     7the person(s) undertaking this project could analysis the binary object
     8level coverage provided by the RTEMS Test Suites on any target BSP
     9supported by the [wiki:Developer/Simulators/SkyEye SkyEye]/RTEMS combination.
     10
     11The analysis will identify a subset of RTEMS such as the SuperCore and
     12a single API implementation and use that as the basis for analysis. RTEMS
     13includes a lot of source code and the coverage analysis should only focus
     14on improving the test coverage of that code subset.
     15
     16The resulting analysis is expected to provide a report on individual
     17assembly instructions within RTEMS subsystems which are not currently
     18exercised by existing tests. Each case has to be individually analyzed
     19and addressed.  Historically, we have identified multiple categories
     20for code being uncovered:
     21
     22 *  Needs a new test case
     23
     24 *  Unreachable in current RTEMS configuration.  For example, the SuperCore could have a feature only exercised by a POSIX API object.  It could be disabled when POSIX is not configured.
     25
     26 *  Debug or sanity checking code which can be placed inside an RTEMS_DEBUG conditional.
     27
     28 *  Unreachable paths generated by gcc for switches.  Sometimes you have to restructure switches to avoid unreachable object code.
     29
     30 *  Critical sections which are synchronizing actions with ISRs.  Most of these are very hard to hit and may require very specific support from a simulator environment.  OAR has used tsim to exercise these paths but this is not reproducible in a BSP independent manner.  Worse, there is often no external way to know the case in question has been hit and no way to do it in a one shot test.
     31
     32There are multiple ways to measure progress on this task. In the past, we have used two metrics.  The first is the reduction in the number of uncovered binary code ranges from that identified initially.  The second is the percent of untested binary object code as a percentage of the total code size under analysis.  Together the metrics provide useful information.  Some uncovered ranges may be a single instruction so eliminating that case improves the first metric more than the second.