Embedded Systems

Module 14
Software Development and V&V

EE4673/5673

by
Dr. Maarten Uijt de Haag

SW V&V.1
 Embedded Systems
Input
Sensor Actuator Actuator Actuator
Device

E E
E E E
E E

Wire
Actuator Actuator
bundle

• Previous course notes:

– Nodes: sensor actuator (notes 2 & 3) E Actuator
– Safety-assessment (notes 6 & 7)
– Global and local time (notes 4 & 5) E Sensor
– Communications (notes 9, 10, 11, 12)
– Scheduling of tasks on processors (13) E: embedded processor SW V&V.2
Embedded Systems
Intended
Function
Safety Assessment Safety Assessment Process Notes 6 and 7
Process Guidelines & methods
(Fault tolerance)

Function, Failure,
System Design
and safety Information

Aircraft System System Development Functional System

Development Process Processes

Implementation
Hardware Life-Cycle Software Life-Cycle
Process Functions & Functions & Process
Implementation
Requirements Requirements

Hardware Software
Development Development
SW V&V.3
Software Standards
• There are many software-related standards
• Some standards that will be referred to in
this section of the course:
– IEC 61508-3,
– IEEE/EIA 12207,
– ISO/IEC 12207,
– ED-12B / DO-178B,
– IEEE 1012,
– IEC-62138,
– IEC-61226,
– IEC-60880.

SW V&V.4
Software Standards

• Definitions are used quite extensively in

standards, requirements, specifications, etc.
• Why?
– In standards, requirements, and specifications it
is often important to define specific
nomenclature (jargon), so that it is clear to all
users what is meant.

SW V&V.5
Development vs. Assurance

Development Standards Assurance Standards

Provide guidelines to ensure Provide a means to establish

an orderly and repeatable that certain attributes are
development process present in the development

How the development is accomplished is

Military standards: left to the development standards
DOD-STD-2167A
International Electrotechnical Commission standard
MIL-STD-498
IEC 61508
Non-Military standards: Part 1 Part 3
ISO/IEC 12207 Safety Software
IEEE 1012
882C ARP-4754 DO-178B
ARP-4761 IEEE Standards such as
IEEE/EIA 12207

SW V&V.6
 IEC 61508 Software Life-cycle

“V” life cycle model

SW V&V.7
Software Development Processes

SW V&V.8
Software V&V Processes

SW V&V.9
Software Safety Requirements
System Requirements

High-Level Requirements

Low-Level Requirements +
Software Architecture

Source Code

SW V&V.10
 Software Architecture
The software architecture defines
the major components and
subsystems of the software, how
they are interconnected, and how
the required attributes, particularly
safety integrity, will be achieved.
Examples of major software
components include operating
systems, databases, plant
input/output subsystems,
communication subsystems,
application program(s),
programming and diagnostic tools
etc.
Software architecture (in DO178B/C):
The structure of the software selected to implement the software requirements
(e.g. control and data flow, inter SW component communication) SW V&V.11
Software System Design
System Requirements

High-Level Requirements

Low-Level Requirements +
Software Architecture

Source Code

SW V&V.12
Low-Level Requirements
• Software requirements from which the Source
Code can be directly implemented without
further information.
– Pseudocode? Matlab code?
Low-level requirements:

Module thrustReverseEnable
IF( wow AND (air_speed < rollout_upper_limit) ) THEN
reverseThrust = REV_THRUST_ENABLE
ELSE
reverseThrust = REV_THRUST_DISABLE
ENDIF
EndThrustReverseEnable

Coding option:

float thrustReverseEnable(float weightOnWheels, airspeed, rolloutUpperLimit,)

{
float reverseThrust;
reverseThrust = REVERSE_THRUST_DISABLED;

if( weightOnWheels && (airspeed < rolloutUpperLimit) )

reverseThrust = REVERSE_THRUST_ENABLED;
return( reverseThrust);
} SW V&V.13
 Hierarchy of Requirements – Be Organized!!

System S1 S2 … … … Sn Derived High-level requirements

High-level H1 H2 … … … … … … Hm
Derived Low-level requirements

Low-level L1 L2 … … … … … … … … … … … … Lj

Derived Requirements
Additional requirements resulting from the software development processes, which
may not be directly traceable to higher level requirements
ARP4754
“At each phase of the development activity, decisions are made as to how particular requirements or
groups of requirements are to be met. The consequences of these design choices become
requirements for the next phase of the development. Since these requirements result from the design
process itself, they may not be uniquely related to a higher-level requirement and are referred to as
derived requirements.”
SW V&V.14
Standards

SW Requirements Standard
Define structured methods, rules and tools that will be used
to develop the high-level requirements.

Addresses how you state your requirements

(in other words what form factor and notations are used)
Addresses the constraints on the use of the development tools

System High-level
Requirements Requirements
SW Requirements
Standards

SW V&V.15
 Standards
SW Design Standard
Define structured methods, rules and tools that will be used
to develop the low-level requirements and software architecture.

DO-178B addresses a variety of items that should be included

in this standard:
-Naming conventions
-Design tool constraints
-Complexity restrictions: maximum level of nested calls etc.
-Constraints on the design: exclusion of recursion and/or dynamic objects, etc.
-Etc.

High-level Low-level
Requirements Requirements
SW Design
Standards

SW V&V.16
 Standards
SW Code Standard
Define the programming languages, methods, rules and tools that
will be used to code the software.

DO-178B addresses a variety of items that should be included

in this standard:
-Programming language (may refer to a standard in your plan)
-Source code presentation: line length restriction, Source code
documentation standards, etc.
-Naming conventions for components, subprograms, variables, and constants (syntax)
-Constraints on the coding tools design
-Etc.
Low-level
Source Code
Requirements
SW Coding
Standards
SW V&V.17
SW Code Standard – MISRA C
• MISRA-C: 2004
– “Guidelines for the use of the C language in critical systems,”
October 2004.
• Includes 141 rules:
– 121 are mandatory
– 20 are advisory.
• All rules apply to the source code and not to the object code
generated by the compiler
• MathWorks products, including Simulink, Stateflow, and
Embedded Coder, are widely used to generate embedded
software for MISRA C.
• MathWorks Polyspace code verification products are used to
analyze handwritten or generated code for MISRA-C:2004
compliance.
SW V&V.18
SW Code Standard – MISRA C
• char_t plain 8-bit character
• uint8_t unsigned 8-bit integer
• uint16_t unsigned 16-bit integer
• uint32_t unsigned 32-bit integer
• int8_t signed 8-bit integer
• int16_t signed 16-bit integer
• int32_t signed 32-bit integer
• float32_t 32-bit floating-point
• float64_t 64-bit floating point

SW V&V.19
SW Code Standard – MISRA C
• Rule 1.1 (required):
– All code shall conform to ISO 9899:1990 “Programming languages –
C, amended and corrected by ISO/IEC 9899/COR1:1995, ISO/IEC
9899/AMD1:1995, ISO/IEC 9899/COR2:1996.
• Rule 13.3 (required):
– Floating-point expressions shall not be tested for equality or
inequality.
Why?
If(f32aux == 0) {
/* segment is parallel to y axis */
projected->x = one.x;
projected->y = gps.y;
}

IEEE 754 floating point: (-1)s2e-127(1.m)2

SW V&V.20
 SW Code Standard – MISRA C
Use a macro:
#define FloatEqual(x,v,epsilon) (((v -
epsilon) < x) && ((v + epsilon) > x))

int main() { int main() {

float x; float x;

for(x = 0; x < 1000; x = x + 0.0001); for(x = 0; x < 1000; x = x + 0.0001);

if (x == 1000) { if (FloatEqual(x,1000,0.001)) {
printf("equals\n"); printf("equals\n");
} else { } else {
printf("not equals (x = printf("not equals (x = %f)\n",x);
%f)\n",x); }
} return 0;
return 0; }
}
> not > equals
Output: Output:
not equals (x = 1000.000061) equals

SW V&V.21
 SW Code Standard – MISRA C
• Rule 20.3 (Required):
– The validity of values passed to library functions shall be checked.
• man sqrt: sqrt(x) returns a NaN and generates a domain error for x < 0.

• Rule 20.4 (Required):

– Dynamic heap memory allocation shall not be used. This precludes the use of
the functions calloc, malloc, realloc and free.
• Rule 14.7 (Required):
– A function shall have a single point of exit at the end of the function This is
required by IEC 61508, under good programming style.
• Rule 6.3 (Advisory):
– typedefs that indicate size and sign should be used in place of the basic types:
• typedef signed int int32_t;
• typedef unsigned int uint32_t;

SW V&V.22
Why Planning, Verification, Validation?
Relative cost of error solving:
Time detected
Time
introduced Requiremen Architecture/
Coding Test Port-release
ts Design
Requirements 1 3 5-10 10 10-100
Architecture/
Design - 1 10 15 25-100

Coding - - 1 10 10-25

Based on: McConnell, Steve, “Code Complete,” Microsoft Press, 2004.

SW V&V.23
 Verification versus Validation (V&V)
Validation:
The process of determining that the requirements are the
correct (they satisfy the customer’s needs, wants, and desires) requirements
and that they are complete.

Verification:
The evaluation of the results of a process to ensure correctness and consistency
with respect to the inputs and standards provided to that process.

• Verification (IEC-61508 & IEEE1012-2004):

– “confirmation by examination and provision of objective evidence that the
requirements have been fulfilled”
• Verification (DO178-B):
– “evaluation of the results of a process to ensure correctness and consistency with
respect to the inputs and standards provided to that process.”
SW V&V.24
Software Verification
Technical assessment of the results of
both the SW development processes and the verification process itself
Purpose:

Detect and report errors that may have been introduced

during the software development processes and the verification process itself.
Make sure that the software implement its intended function completely and
correctly while avoiding its unintended function

Verification ≠ Testing

but

Testing is a part of the

verification process

SW V&V.25
 Software Verification Activities
Reviews Analysis Testing

Qualitative assessment of Detailed examination of the see a couple of

the correctness of a functionality, performance, slides from now ……
process or component traceability, and safety
applications of a SW component

Requirements reviews
Timing and stack analysis
Design reviews
Data flow
Code reviews
Control flow
Test procedure reviews
Note an analysis tool can be used
Checklists can be used to make
but more on that topic later …
the reviews effective and consistent:
• Objective evidence of the review activity
• Focus on the areas most prone to error
• Provide mechanism for using “lesson-learned”
• Provide a simple means for ensuring corrective action
is taken
SW V&V.26
SW Verification – Review and Analysis

Compliance
Traceability
Consistency
Accuracy
Verifiability
Conformance
Compatibility

SW V&V.27
 SW Verification – Review and Analysis

Verifiable
Can the requirement or code be verified without change?

Applies to: high-level requirements, low-level requirements,

software architecture, source code

Example:

1.2 A red indicator light shall come on if the electrical power falls below
3000W.

This can be verified by tests

Number of requirement in requirements document

SW V&V.28
 SW Verification – Review and Analysis

Accuracy
The requirement or code is accurate, unambiguous, and sufficiently
detailed.

Applies to: high-level requirements, low-level requirements,

software architecture, source code
Example:

1.2 The hybrid engine controller shall turn off the engine when car stands still.

Ambiguous requirement:
Need to define how long you stand still otherwise it should turn off after
after an arbitrary short time

SW V&V.29
 SW Verification – Review and Analysis

Consistency
No internal conflicts within a collection of items*.

Applies to: high-level requirements, low-level requirements,

software architecture, source code
Example:

1.2.1 The number of transmitted synchronization bytes shall be greater

than 140 bytes per second.

3.4.2 The synchronization bytes output by the transmitter shall not

exceed 7000 per minute

> 140 bytes/second Þ >1120bits/second

8
Contradictory
£ 7000bytes/minute Þ£ 7000 bits/second=933bits/second
60

*here: software requirements SW V&V.30

 SW Verification – Review and Analysis

Compatibility
No conflicts between two or more specified items* or collections.

Applies to: high-level requirements, low-level requirements,

software architecture

Example:

Compatibility with the target computer in terms of systems response times,

input/output hardware, and other resources.

*here: software requirements, hardware resources etc. SW V&V.31

Remember: Requirements Hierarchy

Higher level requirement … Parent

Lower level requirements … … … Children

Note: requirements should be low enough detail to ensure compliance,

but a high enough abstraction to prevent redundancies and confusion.

SW V&V.32
SW Verification – Review and Analysis
Traceability
All components at one stage of the lifecycle have been addressed
at the next (higher or lower) level of the life cycle.
Question yourself: Did I loose any functionality going to a lower level of requirements?

Traceability:
-Accounting function (bookkeeping)
-Downward (higher to lower level): No childless parents
-Upward (lower to higher level): No children without parents (orphans)
unless assigned to derived requirements

Compliance
Establish that there is technical agreement between products
from different stages of a life-cycle.

Compliance:
-Technical agreement between parent and child

Note that traceability is often seen as overhead imposed by the certification authorities
and as a result neglected especially during changes made to the product: DO NOT MAKE THIS MISTAKE
SW V&V.33
 Traceability – Compliance Example
High-level requirement:

3.1 Test statistic = Absolute Disparity (previous time epoch) – Absolute Disparity (51 time epochs ago)
+ Absolute Disparity (current time epoch)

Low-level requirement: Oops

5.1.3 T = AD(time-delta_time) – AD(time – 51 *delta_time) + AD(time) + Lever_arm

Traceability:

High-level requirement 3.1 and low-level requirement 5.1.3 can be traced to one another.
There are no orphans (upward) nor childless parents (downward).

Compliance:

The problem is that there is no technical agreement between 3.1 and 5.1.3.

SW V&V.34
 SW Verification – Testing
Two purposes:
-Demonstrate that the software product performs its intended function completely
and correctly
-Demonstrate, with a high degree of confidence, that the SW is free of errors that
could lead to unacceptable failure conditions

Relates it directly to the System Safety Assessment Process

and the required level of safety for this SW component.

SW Testing

Low-level testing Software integration testing HW/SW integration testing

Verify the implementation
of the low-level requirements
Verify the interrelationships between SW
requirements and components &
Verify implementation of the SW
requirements and architecture
Verify the correct operation
of the SW in the target embedded
computer environment
SW V&V.35
Software Engineering
Inputs Outputs

White Box Testing Black Box Testing

Select Test Cases based Do not consider the code

on the Software Code while designing the Test Cases

Specification-based Testing &

Requirements-based Testing
SW V&V.36
Software Engineering
White Box Testing
A SW test methodology at the module level in which test cases are derived from
the internal structure. It may execute all statements or branches in the
program to check on how the system is implemented. Some methods of white-box testing
are statement coverage, branch coverage, and path coverage.

Black Box Testing

A SW/HW test methodology that is derived from external specifications
and requirements of the system. Methods for black-box testing include random-testing,
testing at boundary values, and a possible error list. It verifies the end results
at the system level but does not check how the system is implemented.
Nor does it assume that all statements in the program are executed.

Both definitions from: “Software Requirements Engineering”,

Edited by R. H. Thayer, and M.Dorfman, IEEE Computer Society, 2000

SW V&V.37
 Requirements-based Testing

• Given a low-level requirement:

Low-level requirements:

Module thrustReverseEnable
IF( wow AND (air_speed < rollout_upper_limit) ) THEN
reverseThrust = REV_THRUST_ENABLE
ELSE
reverseThrust = REV_THRUST_DISABLE
ENDIF
EndThrustReverseEnable

wow: weight on wheels is “1” when the aircraft is on the ground and all the
aircraft’s weight is on the wheels.
airspeed: speed of the aircraft wit respect to the air.
rollout_upper_limit: speed above which a reverse thrust would be disastrous.

SW V&V.38
Requirements-based Testing

• Given a low-level requirement:

Low-level requirements:

Module thrustReverseEnable
IF( wow AND (air_speed < rollout_upper_limit) ) THEN
reverseThrust = REV_THRUST_ENABLE
ELSE
reverseThrust = REV_THRUST_DISABLE
ENDIF
EndThrustReverseEnable

Weight on Wheels sensor

Black
Box Air Speed
(Target)

SW V&V.39
 Example Tests
Test 1:
Connect the weight-on-wheels input to a low-level voltage (= 0V) and the airspeed to 220 knots.
Expected result: the reverse thrust will be disabled.

Low-level requirements: Requirement based on requirement

Module thrustReverseEnable
IF( wow AND (air_speed < rollout_upper_limit) ) THEN
reverseThrust = REV_THRUST_ENABLE
ELSE
reverseThrust = REV_THRUST_DISABLE
ENDIF
EndThrustReverseEnable

wow = 0 (false)
(airspeed < rollout_upper_limit) = (220 < 95) = false = 0

Assume: rollout_upper_limit = 95
0V => logic “0”
1V => logic “1” SW V&V.40
Example Tests
Test 1:
Connect the weight-on-wheels input to a low-level voltage (= 0V) and the airspeed to 220 knots.
Expected result: the reverse thrust will be disabled.
Test 2:
Connect the weight-on-wheels input to a high-level voltage (= 5V) and choose the airspeed to be
equal to 10 knots.
Expected result: the reverse thrust will be enabled
Test 3:
Connect the weight-on-wheels input to a high-level voltage (= 5V) and choose the airspeed to be
equal to 220 knots.
Expected result: the reverse thrust will be disabled

Assume: rollout_upper_limit = 95
0V => logic “0”
1V => logic “1”
SW V&V.41
 Perform Tests on Code
Coding option in “C”:

float thrustReverseEnable(float weightOnWheels, airspeed, rolloutUpperLimit,)

{
float reverseThrust;

if( weightOnWheels && (airspeed < rolloutUpperLimit) )

reverseThrust = REVERSE_THRUST_ENABLED;
else
reverseThrust = REVERSE_THRUST_DISABLED;

return( reverseThrust);
}

Weight on Wheels (wow) sensor

Black
Box Air Speed
(Target)

SW V&V.42
 Requirements-based Test Case Selection
• Normal range test cases
– Exercise real & integer value
variables
– Equivalence classes
– Boundary values
– Time dependencies
– Include the time domain in the
equivalence classes
– Filters, integrators, etc.
– State transitions
– Examine every transitions
– Logic equations
• Robustness (abnormal range)
range test cases
– Exercise real & integer value
variables
– Invalid Equivalence classes
– Invalid Boundary values
– Abnormal system initialization
– Failure modes of external data
– Loop robustness
– If the loop counter is a
computed value try out-of-
range loop values.
– Frame times State transitions
– Examine every transitions
– Arithmetic over- and
underflow
– Disallowed state transitions
SW V&V.43
 SW Testing - Equivalence classes

Equivalence class:
is a set of input, state, or output values for which an object is supposed to behave
similarly. Or DO178B: The partition of the input domain of a program such that a test of
a representative value of the class is equivalent to a test of other values of the class.

Y = 1 + K x + 0.3 Kx2 and 0 < K < 2, 0 < x < 255

From analysis it can be seen that K=1 is as representative of the 0 < K < 2 as K=1.4
Thus K=1 can be used as an equivalence class.

Boundaries: K = 0+ and K = 2-,

x = 0+ and x = 255-
Robustness test case example:
K=0, X=0
K=2, X=255 Note that the use of fixed-point versus
Etc. Floating-point becomes an issue
SW V&V.44
SW Testing - Example

0 1
Normal range tests would include:
0  1, 1  2, 2  , etc.

Robustness tests would include:

2  3, 3  1, etc.
2 3

SW V&V.45
Errors Revealed in SW Testing
Low-level Testing
Failure of an algorithm to satisfy a SW requirement.
Incorrect loop operations
Incorrect logic decisions
Failure to process correctly legitimate combinations of input conditions
Incorrect responses to missing or corrupted data
Incorrect handling of exception (arithmetic faults, array limit violations)
Incorrect computation sequence
Inadequate algorithm precision, accuracy, and performance

SW V&V.46
Errors Revealed in SW Testing
SW Integration Testing
Incorrect initialization of variables and constants
Parameter passing errors
Data corruption (global data especially)
Inadequate end-to-end numerical resolution
Incorrect sequencing of events and operations

SW V&V.47
Errors Revealed in SW Testing
HW/SW Integration Testing
Incorrect interrupt handling
Failure to satisfy execution time requirements
Incorrect SW response to HW transients and failures
Resource contention problems (like data bus)
Inability of built-in test to detect failures
Errors in HW/SW interfaces
Incorrect behavior of feedback loops
Incorrect control of memory management HW or other HW devices under SW
control
Stack overflow
Field-loadable SW problems
Violations of SW partitioning
SW V&V.48
 Verification of the Verification
Coverage Analysis

Coverage refers to the extend to which a given verification

activity satisfies its objectives.

Coverage is most often applied to the testing activities.

Coverage

Requirement coverage analysis Structural coverage analysis

Determine what SW requirements were not tested: Determine what SW structures

Prove that
-Test cases exist for each SW requirement
-Test cases satisfy the criteria of normal and robustness
were not exercised by the
requirements-based test procedures.
May be performed on the Source Code unless it is level A
and the compiler generates object code that is not directly
traceable to the source code statements
SW V&V.49
 SW Testing – Structural Coverage

May uncover code that was not exercised during the tests.

This code may be the result of:

Inadequacies in SW
requirements Short-coming/problems Dead code Deactivated code
with the requirements-based
test cases or procedures

Activated by operational scenario.

Develop test cases and procedures.

SW V&V.50
Software Testing Summary
Software
Requirements-based
Test Generation

Hardware/SW
Low-level SW Integration
Integration
Tests Tests
Tests

Software Requirements
Coverage Analysis

Software Structure
Coverage Analysis
Direct Path Additional
Conditional Path End of Testing Verification
SW V&V.51
 Designing Tests
A
Z For an n –input AND gate:
(1) All inputs are set true (1 test),
B (2) Each and every input is set exclusively false (n tests)

Example:
Test Case # A B Z
3-input AND gate, FTT, TFT, TTF, TTT

1 F F F

2 F T F

3 T F F

4 T T T

Decision coverage: (FF,TT) or (FT,TT) or (TF,TT)

Condition coverage: (FF,TT) or (FT,TF) Don’t worry about this for now!
MC/DC: FT, TF, TT
See: Hayhurst, K. et al. “A Practical Tutorial on Modified
Condition/ Decision Coverage,” NASA TM, 2001. SW V&V.52
Designing Tests - Example
Low-level requirements:

Module thrustReverseEnable
IF( wow AND (air_speed < rollout_upper_limit) ) THEN
reverseThrust = REV_THRUST_ENABLE
ELSE
reverseThrust = REV_THRUST_DISABLE
ENDIF
EndThrustReverseEnable

If(A and B) use there tests: A: wow

B: (air_speed < rollout_upper_limit)
Test case 1: A = T , B = T
Test case 2: A = T , B = F
Test case 3: A = F , B = T

SW V&V.53
Designing Tests - Example
Test 1:
Connect the weight-on-wheels input to a low-level voltage (= 0V) and the airspeed to 10 knots.
Expected result: the reverse thrust will be disabled.
FT
Test 2:
Connect the weight-on-wheels input to a high-level voltage (= 5V) and choose the airspeed to be
equal to 10 knots.
Expected result: the reverse thrust will be enabled TT
Test 3:
Connect the weight-on-wheels input to a high-level voltage (= 5V) and choose the airspeed to be
equal to 220 knots.
Expected result: the reverse thrust will be disabled TF

SW V&V.54
Designing Tests
Z
A
For an n –input OR gate:
B (1) All inputs are set false (1 test),
(2) Each and every input is set exclusively true (n tests)

Test case Example:

A B Z
# 3-input OR gate, TFF, FTF, FFT, FFF
1 F F F

2 F T T

3 T F T

4 T T T

Decision coverage: (FF,TT) or (FT,FF) or (TF,FF)

Condition coverage: (FF,TT) or (FT,TF)
Don’t worry about this for now!
MC/DC: FT, TF, FF
SW V&V.55
Designing Tests
A
Test case A B Z Z

1 F F F B
2 F T T

3 T F T
Multiple test sets possible. See the truth table:
4 T T F
Test sets: (1,2,3), (1,2,4), (1,2,4), (2,3,4)

A Z
A Z

F T
For an NOT gate:
T F (1) Input set false,
(2) Input set true.
SW V&V.56
Designing Tests
x A
• Criteria:
x x > comparison point
– Less than
– Greater than
– Less than or equal to Or
– Greater than or equal to x
– Equal to A
– No equal to x
x>y
y y

Two test cases will confirm MC/DC, one test case with a TRUE outcome and one with a FALSE outcome.

However, minimum good requirements-based testing for a comparator requires:

(1) Input set at a value slightly above the comparison point

(2) Input set at a value slightly below the comparison point
(3) Input set at a value equal to the comparison point

SW V&V.57
Designing Tests
Engine RPMs(x)
A
x x > 2500

Test Case # Input altitude x Output A

1 25 F These 2 cases give MC/DC but do

not confirm that the comparison point
2 32,000 T is at 2500, not elsewhere.

3 2,500 F

4 2,499 F Better choices

5 2,501 T

SW V&V.58
Designing Tests - Example
Low-level requirements:

Module thrustReverseEnable
IF( wow AND (air_speed < rollout_upper_limit) ) THEN
reverseThrust = REV_THRUST_ENABLE
ELSE
reverseThrust = REV_THRUST_DISABLE
ENDIF
EndThrustReverseEnable

Include: air_speed = rollout_upper_limit s a test case

SW V&V.59
Designing Tests
Example: if C then z := x else z:=y;

Schematic representations:
C

x
z
z := x z := y
y

Minimum testing for the “if … then … else” statement:

(1) Inputs that force the execution to the “then” path (decision outcome = TRUE)
(2) Inputs that force the execution to the “else” path (decision outcome = FALSE)
(3) Inputs needed to exercise any logical gates in decision “C”

SW V&V.60