chapter 3

04/13/23 Copyright, Testing Embedded Systems, Slides by P. Bobbie, 2007

1

LIFECYCLETESTING EMBEDDED SOFTWARE: MULTIPLE V-Model

(3)

PART II INTRODUCTION Process of developing and testing embedded software The lifecycle structures: the phases, activities within each, and the order The Multiple-V Model:

Which test process issues need to be addressed at each stage of development: first a design model (simulator), then build a prototype (via a series of iterations/refinements), and test final product


2


(3)

3.0 INTRO The model: a simulated version of the embedded software on a conventional PC

(e.g., using Rational Rose UML or Matlab) – tested

The prototype: code generation from corrected model is then ported into a prototype (experimental hardware or environment for the embedded software)

The final product: code is refined as experimental hardware is systematically/incrementally replaced by actual hardware, and mass produced

A V-Model: a developmental model, which takes into account different physical versions of the same system (the model, the prototype, and the product)

The Multiple-V Model: Where each physical version is tested completely, using the full testing cycle or process (except where specific functionalities can’t be tested until later stages), some versions requiring specific techniques or environments


3


(3)


4


(3)

Iterative and Parallel Development The Multiple-V Model has three stages:

design/model, build/prototype, test/product The middle ‘V’, is iterative (systematic refinements),

and may use such environments as Rationale Unified Process, eXtreme Programming (XP)

Each stages requires: hardware, software experts (working in parallel), project managers, unit/integration/regression testers (iterating with the hardware/software experts as experimental hardware is gradually replaced by the target hardware


5


(3)

Iterative and Parallel Development The ES requires initial system decomposition for

parallel design, development, etc. and stepwise integration

The multiple-V model is applied to each component, and during the integration at each stage – an evolutionary process

The process becomes tailored toward each unique ES

What are the activities within each stage of the Multiple-V Model, and what issues need to be tested?


6


(3)

What activities and issues requires a mapping into the multiple V’s:

Focus: What activity? When can it be done? Against what issue(s)? Which stage?

Activities vs Issues – a structured approach to embedded software testing:

A. Test techniques B. Test levels and types C. Other Test issues Map issues classified under A, B, and C onto one or more stages of

the V-Model


7


(3)


8


(3)


9


(3)


10


(3)


11


(3)

The nested V Model The seemingly sequential 3-V-Model ignores functional

decomposition of a system (into components) Each stage of a simple V-Model can be applied/used to

guide functional decomposition The left (design): decomposition The middle (build): parallel development The right (test): integration of components

With decomposition, each component is separately subjected to the Multiple-V Model, and repeated for subcomponents, etc., giving rise to a ‘nested’ V-Model


12


(3)

Nested Multiple V-Model Usually a simple V-Model is applied at the component level For most systems, not the full system is initially designed,

but a component (following the software architectural levels)

The simple V-Model (for components), when combined with multiple V-model (for the system/integration level), a “Nested Multiple V-model” results


13


(3)


14


(3)


15


(3)

• Nested, Multiple V-Model allows, e.g., higher-level issues to be correctly placed within higher-level test issues, etc.

chapter 3

Documents

multiplev model

nested v model

nested vmodel

simple vmodel

embedded software testing

corrected model

developmental model

middle v