Changes between Version 1 and Version 2 of Developer/Projects/Open/TestSpecification


Ignore:
Timestamp:
Feb 14, 2015, 7:44:27 PM (5 years ago)
Author:
Gedare Bloom
Comment:

Improve intro.

Legend:

Unmodified
Added
Removed
Modified
  • Developer/Projects/Open/TestSpecification

    v1 v2  
    1010'''Status:''' Current status of project. For starting, it should be: Uninitiated.
    1111
    12 '''Introduction:''' The purpose of formalizing the testing process is to reduce the expense involved in getting systems using the RTEMS kernel to be safety certified.  Although different countries (or groups of countries) have different safety certification standards, meeting the safety certification standards for one country (or one group of countries) will aid in meeting the safety standards of another country (or group of countries).  Towards this end, the test specification shall be written.
     12'''Introduction:'''  Need a formal test specification.  Ideally, inspired by http://softwaretestingstandard.org/ some notes about existing test specifications can be found http://www.rtems.org/wiki/index.php/GoogleCodeInProjects#Test_Documentation_Files_update
     13
     14The purpose of formalizing the testing process is to reduce the expense involved in getting systems using the RTEMS kernel to be safety certified.  Although different countries (or groups of countries) have different safety certification standards, meeting the safety certification standards for one country (or one group of countries) will aid in meeting the safety standards of another country (or group of countries).  Towards this end, the test specification shall be written.
    1315
    1416Although RTEMS has already been designed, a common theme that seems to be appearing in safety certification standards is testing at different development stages, such as, testing requirements, and testing software.  Testing at different levels may indicate a need for different test specifications at different levels.  For example: the test specification indicating that RTEID met the Army's need in the 1980's and 1990's may be different than the test specification for illustrating that RTEMS is POSIX 2004 compliant.  That being said, further research is needed to identify the test scope of each phase, and identify specifications that will work for each of the phases.  There are also different types of tests for each of the phases, and specifications could be drawn up for each of the types of tests.  On the other hand, we want to avoid "analysis paralysis" so the tests need to be automated as much as possible, and the specifications need to lend themselves to automated test writing, where feasible, and test case reduction, where not.