Home Random Page


CATEGORIES:

BiologyChemistryConstructionCultureEcologyEconomyElectronicsFinanceGeographyHistoryInformaticsLawMathematicsMechanicsMedicineOtherPedagogyPhilosophyPhysicsPolicyPsychologySociologySportTourism






TEST SPECIFICATIONS

The purpose of testing is to prove empirically that the system or component under test meets specified requirements. Normally it is not possible to prove by testing that a component contains no errors.

According to Myers, an important aspect of testing is to execute a program with the intention of finding errors [Ref. 14]. Testers should adopt this 'falsificationisf approach because it encourages testers to devise tests that the software fails, not passes. Myers's recommendations originate from Karl Popper, the influential philosopher who first proposed the 'falsificationisf approach as a scientific method.

Testers must be critical and objective for testing to be effective. On large projects, system and acceptance test specifications should not be written by the analysts, designers and programmers responsible for the SRD, ADD, DDD and code. On small and medium-size projects, it is acceptable for the developer to write the test specifications and for the user or product assurance representatives to review them. Users should run the acceptance tests, not the developers.

Unit test planning

Unit test plans must be generated in the DD phase and documented in the Unit Test section of the Software Verification and Validation Plan (SVVP/UT). The Unit Test Plan should describe the scope, approach and resources required for the unit tests, and take account of the verification requirements in the SRD (see Section 2.5.3 below and Chapter 7).

Test designs, test cases and test procedures

The developer must write specifications for the:

• acceptance tests,

• system tests,

• integration tests,

• unit tests

in the DD phase and document them in the SWP. The specifications should be based on the test plans, and comply with the verification and acceptance testing requirements in the SRD. The specifications should define the:

• test designs (SVV19);

 

14 ESA PSS-05-05 Issue 1 (May 1992) THE DETAILED DESIGN AND PRODUCTION PHASE

• test cases (SW20);

• test procedures (SW21); see Section 2.6 below and Chapter 7.

When individual modules have been coded and unit tested, developers have to integrate them into larger components, test the larger components, integrate the larger components and so on. Integration is therefore inextricably linked with testing.

The Software Project Management Plan for the DD phase (SPMP/DD) should contain a delivery plan for the software based on the life cycle approach adopted. The delivery plan influences the integration tests defined in the Software Verification and Validation Plan (SVVP/IT). For a given delivery plan, the SWP/IT should make integration testing efficient by minimising the number of test aids (e.g. drivers and stubs) and test data files required.

CODING AND UNIT TESTING

Coding is both the final stage of the design process and also the first stage of production. Coding produces modules, which must be unit tested. Unit testing is the second stage of the production process.



Coding

The transition from the detailed design stage to the coding stage comes when the developer begins to write modules that compile in the programming language. This transition is obvious when detailed design has been performed with flowcharts, but is less so when the developer has used a PDL or pseudo-code.

Coding must be based on the principles of:

• structured programming (DD03):

• concurrent production and documentation (DD04).

Every module should be understandable to a reviewer or maintenance programmer, moderately familiar with the programming language and unfamiliar with the program, the compiler and operating system. Understandability can be achieved in a variety of ways:

• including an introductory header for each module;

• declaring all variables:

• documenting all variables;

 

ESA PSS-05-05 Issue 1 (May 1992) 15 THE DETAILED DESIGN AND PRODUCTION PHASE

• using meaningful, unambiguous names:

• avoiding mixing data types:

• avoiding temporary variables:

• using parentheses in expressions;

• laying out code legibly:

• adding helpful comments;

• avoiding obscuring the module logic with diagnostic code:

• adhering to structured programming rules:

• being consistent in the use of the programming language:

• keeping module short:

• keeping the code simple.

2.5.1.1 Module headers

Each module should have a header that introduces the module. This should include:

title:

• configuration item identifier (SCM15);

• original author (SCM16):

• creation date (SCM 17);

• change history (SCM18).

If tools to support consistency between source code and DDD are available, the introduction should be followed by explanatory comments from the component description in the DDD part 2.

The header usually comes after the module title statement (e.g. SUBROUTINE) and before the variable declarations.

2.5.1.2 Declarations of variables

Programmers should declare the type of all variables, whatever the programming language. The possible values of variables should either be stated in the variable declaration (as in Ada), or documented. Some languages, such as FORTRAN and Prolog, allow variables to be used without explicit declaration of their type. Programmers using weakly typed languages should declare all variables. Where strong typing is a compiler option, it should always be used (e.g. IMPLICIT NONE in some

 

16 ESAPSS-05-05 Issue 1 (May 1992) THE DETAILED DESIGN AND PRODUCTION PHASE

FORTRAN compilers). Declarations should be grouped, with argument list variables, global variables and local variable declarations clearly separated.


Date: 2016-01-03; view: 683


<== previous page | next page ==>
Definition of module processing | Documentation of variables
doclecture.net - lectures - 2014-2024 year. Copyright infringement or personal data (0.007 sec.)