Ciclul in V

8/18/2019 Ciclul in V

1/50

CICLUL IN V

NOTIUNI DE TESTARE STRUCTURALA


2/50

CUPRINS

01 Generalitati Ciclul in V

02 Specificitati Auto

03 Notiuni de testare structurala


3/50

2

Cmd 2

1

Cmd 1

Commands

Measures

Estimated states

Observer (gain K)

L1

LQ Int

L2

LQ Gain

1

s

Integrator

1

s

Integrator

4

Meas 2

3

Meas 1

2

Stp 2

1

Stp 1

SOFT CONTROL GMP

Ecuatii fizice Model Matlab Simulink Cod C

Ex. : gestiune injectie, OCS, regenerare FAP, Stop & Start, diagnostic …

3


4/50

Ciclul in V

Proiectare

sistem/arhitectura(HLR)

Analizacerintelor

Specificatii de

nivel jos – SW -

(LLR)

CODARE

Teste Unitare

Teste de

integrare/ Testepe tinta

Teste deacceptanta


5/50

Ciclul in V

Analiza

cerintelor

• Cerintele sistemului (requirements) sunt adunate prin analiza

nevoilor clientului.

• Nu specifica cum SW va fi proiectat si codat.

• In mod uzual, clientii sunt intervievati si se construieste « User

requirements document »

• Se pot stabili « use cases » : modul in care clientul final utilizeaza

produsul final


6/50

Ciclul in V

• Inginerii analizeaza sistemul studiind « User requirement

document »

• Se gasesc tehnici prin care Cerintele client pot fi implementate

• Se proiecteaza arhitectura sistemului (high level requirements) :

• Lista modulelor

• Scurta descriere a functionalitatii fiecarui modul

• Descriere a interactiunii dintre module

Proiectare

sistem/arhitectura(HLR)


7/50

Ciclul in V

• Sistemul este subimpartit in module

• Fiecare modul este explicat a.i. sa fie codabil

• Elemente specificate :

• Algoritmi in pseudocod/simul ink/SCADE

• Descriere completa a interfetelor

• Descriere completa a variabilelor si tipurilor

• Mesaje de eroare

Specificatii de

nivel jos – SW -

(LLR)


8/50

Ciclul in V

• O unitate este cea mai mica parte testabila a unei aplicatii

• In mod uzual : o functie

• Se verifica logica interna a codului trecand prin toate ramurile

posibile

• Testare WHITE BOX

Teste Unitare


9/50

Ciclul in V

• Teste de integrare

• Teste pe ansamblu de module integrate

• Se cauta erori la interfete si erori de interactiune intre module

• Testare de tip BLACK BOX

Teste de

integrare/ Teste

sistem / pe tinta

• Teste sistem / pe tinta

• Teste pe ansamblul sistemului

• Se verif ica implementarea corecta a cerintelor sistem (punct de

vedere client)

• Testare pe microcontrolerul tinta


10/50

Ciclul in V

• Se verifica ca cerintele client sunt corect implementate

• Documentul de sinteza a testelor de acceptanta este bazat pe User

Requirements Document / Use cases

• In urma acestor teste clientul decide daca accepta sistemul sau nu

• Test in conditii reale de catre clientii reali sau reprezentantii clientilor

Teste de

acceptanta


11/50

Ciclul in V exemplu

• Proiectarea unui sistem cu ventilator

• care sa mentina temperatura lichidului de racire a motorului la

o temperatura mai mica de 100 °C

• Care sa optimizeze durata de viata a ventilatorului :

ventilatorul se declanseaza doar daca viteza vehiculului este

mai mica de 70 km/h

Analiza

cerintelor


12/50

Ciclul in V exemplu

• Sistemul va f i compus din 3 « module » :

• CitesteTemperatura

• CitesteViteza

• ActiveazaReleu

Proiectare

sistem/arhitectura

(HLR)


13/50

Ciclul in V - exemplu

• CitesteTemperatura :

• Primeste octetul ce codeaza temperatura de la senzor

• Converteste in valoare fizica ([0..255] [-40..110] °C)

• Intoarce valoare fizica

• CitesteViteza

• Primeste octetul ce codeaza viteza de la ABS

• Converteste in valoare fizica ([0..255]

[0..200 km/h]

• Intoarce valoarea fizica

• Act iveazaReleu

• Daca (Temperatura > 100°C) si (Viteza < 70 km/h)

ActiveazaReleu

• Daca (Temperatura < 98°C)

DezactiveazaReleu

Specificatii de

nivel jos – SW -

(LLR)


14/50


CODARE

1/4

// citeste temperatura de la senzor si o intoarce

double ReadTemperature() {

unsigned int sensor_readout;double temperature_value;

Read_Sensor(& sensor_readout);

// 0 = -40 °C, 255 = 110 °C

temperature_value = -40 + sensor_readout * 150 / 255;

return temperature_value;}

ECHIPA 1


15/50


CODARE

2/4

ECHIPA 2

// citeste viteza de pe CAN si o intoarce

double ReadSpeed() {

unsigned int can_readout;double speed_value;

Read_Speed_CAN(& can_readout);

// 0 = 0 mph, 255 = 200 mph

speed_value = can_readout * 200 / 255;

return speed_value;}


16/50


CODARE

3/4

ECHIPA 3

// activeaza releul cand viteza depaseste 100 °C// si viteza e mai mica de 70 km/h

void ActivateRelais(double Tmax, double Tmin, double Speed_th, double

current_temperature, double current_speed) {

if (current_temperature > Tmax) && (current_speed < Speed_th)

ON_Relais_Command();

if (current_temperature < Tmin)OFF_Relais_Command();

}


17/50


CODARE

4/4

ECHIPA 4

#define TMAX 100

#define TMIN 98

//prag pentru viteza : 70 km/h#define SPEED_TH 70

main () {

double temperature_value;

double speed_value;

while (temperature_value = ReadTemperature()) {speed_value = ReadSpeed();

ActivateRelais(TMAX, TMIN, SPEED_TH,

temperature_value, speed_value);

}

}

Fiecare functie e

codata cf. cerintelor

Dar functia globala

este gresita

deoarece…

Unitatile de masura

sunt diferite.


18/50

Ciclul in V - dezavantaje

• Este rigid si nu permite tratarea cu usurinta a schimbarilor

• Daca timpul de dezvoltare este depasit, testarea este comprimata in

ferestre stranse de timp pentru a respecta termenele

• Daca anumite cerinte sunt abandonate pe parcurs (dupa faza de

analiza), timpul petrecut cu analiza acestora este pierdut


19/50

Alte metode – Agile

• Task-urile sunt sparte in mici incremente cu planing minimal

• Fiecare iteratie urmeaza toti pasii de dezvoltare : analiza cerintelor,

proiectare, codare, teste, acceptanta

• Astfel, procesul se adapteaza schimbarilor foarte rapid

• Teste unitare scrise in acelasi timp sau chiar inainte de cod

• Echipe relativ mici

USER REQ

DOC.

Cerinta 1

Cerinta 2

Cerinta 3

Analiza Proiect Codare Teste Productie Cerinta 1 Cerinta 2 Cerinta 3

Analiza

Proiect

Codare

Teste

Productie

Ciclu in V traditional Metode Agile


20/50

Sistem de control calibrat grup motopropulsor

20

Logiciel calibré

Soft de baza(OS + pilotaj senzori si actuatori)

SW Aplicativ Algoritmi control comanda

Electronica calculator “ P l a t f o r m a ”

Strat de interfata “ S W A

p l i c a t i c ”

C a l i b r a t i o n s ( p a r a m è

t r e s d e

r é g l a g e d e s f o n c t i o n

s d e

c o n t r ô l e )

Electronica senzori

si actuatori

Specificatii Aplicative

Furnizor Specificatii Furnizor

Module SW

C O M

D I A G

C O M B U S T

C C / S L

S

P E E D

M G T

C O O L A N T

Strat de interfata

Soft de baza


21/50

MIL (Model In the Loop)

SIL (Software In the Loop)

21

Intrarile modululuiGalben: Rezultat spec

Violet : Rezultat cod

Iesirile Modulului

Mediul de test

Modulul testat

MIL perminte validarea specificatiilor unui modul

inainte de codare.

SIL permite validarea codului asociat.

Pentru validare trebuie aplicati stimuli la intrare siverificata iesirea


22/50

HIL (Hardware In the Loop)

Simularea in timp real a sistemelor fizice

Permite testarea noilor SW intr-un mediu virtual fara vehcul real sau prototip.

22

Control

scripts

Real-Time Model


23/50

Cerintele SW contin o lista finita de comportamente

Fiecare cerinta trebuie sa fie scrisa a.i sa fie verificabila

Testarea bazata pe cerinte este tentanta pentru ca este din perspectiva utilizatorului

Avand o lista finita de cerinte, testele sunt fezabile (spre deosebire de testeleexhaustive)

Insa, o multime de teste ce acopera toate cerintele nu este necesar suficienta din mai multe motive :

E posibil ca cerintele SW si LLR sa nu reprezinte o specificatie completa atuturor comportamentelor codului executabil

Cerintele pot sa nu fie scrise cu suficienta granularitate ca sa se asigure ca catoate comportamentele codului sunt testate

Testele pe baza de cerinte nu pot confirma singure ca nu exista functionalitatenedorita in cod

CUM TESTAM ?

REQUIREMENT COVERAGE


24/50

STRUCTURAL COVERAGE

Analiza structurala (structural coverage) furnizeaza un mijloc de aconfirma ca testele executa toata structura codului

In procesul de testare, testele pe baza de cerinte vor fi facuteinaintea analizei structurale

Tipuri de analiza structurala : Statement coverage

Decision coverage

Condition coverage

Condition/Decision coverage

Modified Condition/Decision Coverage

Multiple condition coverage


25/50

1) Statement Coverage

Fiecare instructiune executabila este chemata cel putin o data in timpul

testarii

Statement coverage este asa de slaba incat in general este consideratainutila (Myers). In cel mai bun caz, statement coverage trebuie considerataca un test minimal.

Se considera urmatorul cod

if (x > 1) and (y = 0) then z := z / x; end if;

if (z = 2) or (y > 1) then z := z + 1; end if;

Alegand x = 2, y = 0, si z = 4 ca intrari, fiecare instructiune este executata celputin o data.

Cu toate acestea, daca un or este codat in loc de and din greseala in primainstructiune, testul nu va detecta o problema

STATEMENT COVERAGE


26/50

2)Decision Coverage

Decision coverage cere 2 cazuri : unul pentru iesirea true si unul pentru iesirea

false

Pentru decizia (A or B), cazurile de test (TF) si (FF) vor face ca decizia sa seschimbe din true in false.

Cu toate acestea, efectul lui B nu este testat. Acest test nu poate distinge intredecizia (A or B) si decizia A.

DECISION COVERAGE


27/50

3)Condition Coverage

Condition coverage cere ca fiecare conditie dintr-o decizie sa ia toate valorileposibile cel putin o data (pentru a evita problema din exemplul precedent)dar nu cere ca decizia sa ia toate valorile posibile cel putin o data.

In acest caz, pentru decizia (A or B) cazurile (TF) si (FT) indeplinesc conditia

dar nu fac ca iesirea sa ia toate valorile.

Aceste teste nu pot distinge intre or si xor in acest exemplu particular.

CONDITION COVERAGE


28/50

4)Condition/Decision Coverage

Condition/decision coverage imbina cerintele din decision coverage cu cele

din condition coverage.

Trebuie sa fie suficiente teste pentru a schimba iesirea deciziei din true infalse si pentru a face ca fiecare intrare sa ia si valoarea true si valoareafalse.

In exemplul (A or B), cazurile de test (TT) and (FF) indeplinesc criteriul.

Cu toate acestea, aceste doua teste nu disting expresia corecta (A or B) de

expresia A sau de expresia B sau de expresia (A and B).

CONDITION/DECISION COVERAGE


29/50

5) Modified Condition/Decision Coverage

Criteriul MC/DC imbunatateste criteriul condition/decision coverage princerinta ca sa fie demonstrat ca fiecare conditie afecteaza in modindependent iesirea deciziei.

Insa, pentru a obtine MC/DC se cere o atentie mai mare in selectia cazurilor de test si, in general, un minim n+1 cazuri de test pentru o decizie cu nintrari.

Pentru decizii cu multe intrari, MC/DC cere in mod semnificativ mai multecazuri de test ca orice alt criteriu discutat aici.

MODIFIED CONDITION/DECISION COVERAGE


30/50

MULTIPLE CONDITION COVERAGE

(236 teste)*(1 sec/100 teste)*(1 min/60 sec)*(1h/60 min)*(1 zi/24 h)*(1 an/365 zile) = Aproximativ 21.79 ani !!!

(236 teste)*(1 pagina/64 linii)*(5 cm/500 pagini)*(1 m/100 cm)*(1 km/1000 m) =

Aproximativ 107 km !!!

6) Multiple Condition Coverage

Acest criteriu cere atatea cazuri de test cat sunt necesare pentru a asigura toate

combinatiile de intrari posibile intr-o decizie (testare exhaustiva a combinatiilor de

intrari)

Ce ar insemna testarea tuturor combinatiilor posibile de intrari ?

[Cat timp ar lua testarea unei expresii cu 36 de conditii ? => presupunand 100 de teste/ s ]

[Ce inaltime ar avea raportul de test ? => presupunand o singura linie pentru un

rezultat caz de test, 64 linii / pagina, 500 pagini / 5 cm]

Rezultat


31/50

Mai multe detalii despre Modified Condition/Decision Coverage

Pentru o decizie cu n intrari, sunt necesare 2n teste. In cazul in care n este mic, aface 2n teste poate fi rezonabil; a executa 2n teste pentru n mare, nu este fezabil.

In sisteme complexe, expresii Binare complexe sunt comune. In tabelul 2 se aratanumarul de expresii Binare cu n conditii intr-un soft aeronautic scris in ADA.

MCDC


32/50

Recap : MCDC

Fiecare decizie din program trebuie sa ia toate valorile posibile cel

putin o data

Fiecare conditie dintr-o decizie din program trebuie sa ia toate

valorile posibile cel putin o data

Se demonstreaza ca fiecare conditie dintr-o decizie influenteaza in

mod independent iesirea deciziei


33/50

MCDC in aeronautica

Classification des conditions de panne selon la sévérité de leurs effets

• Catastrophiques : morts multiples, habituellement avec perte de l'avion

• Dangereuses : réduction de la capacité de l'avion ou de l'aptitude de l'équipage àfaire face à des conditions opérationnelles défavorables risquant d'entraîner :

une réduction important des marges de sécurité ou des capacités fonctionnelles

des détresses physiques ou une charge de travail telle qu'on ne pourrait plus

compter sur l'équipage pour accomplir ses tâches

ou des blessures sérieuses ou des morts concernant un nombre relativementfaible d'occupants

• Majeures : réduction de la capacité de l'avion ou de l'aptitude de l'équipage à faire

face à des conditions opérationnelles défavorables risquant d'entraîner :

une réduction significative des marges de sécurité

ou une réduction significative des capacités fonctionnellesou une augmentation significative de la charge de travail de l'équipage ou des

conditions réduisant son efficacité

ou un inconfort pour les passagers et équipages, pouvant inclure des blessures

• Mineures : pas de réduction significative de la sûreté de l'avion

• Sans effet sur la sécurité


34/50

Testare MCDC a unei porti AND


35/50

Testare MCDC a unei porti OR


36/50

Testare MCDC a unei porti XOR

• Cazul 1 : obligatoriu pentru a diferentia OR de XOR

• Cazurile 1, 2, 3 suficiente pentru a testa XOR


37/50

Testare MCDC al unui COMPARATOR

Best : tests 3, 4 and 5

• Din punct de vedere MCDC :

• un test punand X = 0 si• un test punand X = 30 000

sunt suficiente pentru a asigura coverage

• Insa aceste teste nu verifica ca pragul comparatiei este la 2500 si nu

la 4000 de exemplu.

• In practica, se propun testele de mai jos.


38/50

Testare minima if – then – else presupun urmatoarele :

• Input care forteaza executia caii « then »

• Input care forteaza executia caii « else ». Chiar daca calea « else » nu exista

trebuie verificat ca calea « then » nu s-a executat• Inputuri pentru a verifica orice porti logice din decizie (cf. cazuri precedente)

De exemplu :

• If Z then …. else…. cere numai 2 cazuri de test pentru MCDC

• If X or Y or Z then…else…cere 4 cazuri de test pentru MCDC

Testare minima pentru if Z then a = x else a = y

Testare MCDC a unei instructiuni IF – THEN – ELSE


39/50

Exemplul 1

Fie tabelul de mai jos si sa presupunem ca sunt adecvate pentru testarea pe

baza de cerinte. Sa se determine daca aceste test case-uri asigura MC/DC

pentru codul sursa.

Codul sursa :

Z = ( A or B) and (C or D)


40/50

Exemplul 1 (cont’d)

Etapa 1 : Se realizeaza schema codului sursa

Etapa 2 : Maparea cazurilor de test pe schema


41/50

Example 1 (cont’d)

Etapa 3 : Se elimina cazurile de test mascate

In acest caz, orice intrare false in poarta and va masca cealalta intrare :

• Iesirea false a primului or va masca cazul de test 1 a celui de al doilea or

• Iesirea false a celui de al doilea or va masca cazul de test 3 al primului or


42/50

Example 1 (cont’d)

Etapa 4 : Se verifica MC/DC.

Etapa 5 : Se confirma ca nu exista cazuri de test care lipsesc


43/50

Eliminarea cazurilor de test mascate

• Principiile de observabilitate pentru o intrare sunt urmatoarele :

Principiul 1 = W AND TRUE = W

Principiul 2 = W OR FALSE = WPrincipiul 3 = W XOR FALSE = W

Principiul 4 = W XOR TRUE = NOT W

• In figura de mai sus Intrarea de interes este vizibila la iesire daca intrarile

de control sunt configurate ca in figura.

• Orice schimbare in intrarile de control 1 si 2 face ca intrarea de interes sa

nu mai fie vizibila

• O schimbare a intrarii de control 3 neaga la iesire intrarea de interes


44/50

Eliminarea cazurilor de test mascate

• Contrariul principiilor de mai sus este utilizat pentru a identifica daca o intrare este

mascata sau nu• Iata inca un exemplu ce arata cum se poate testa intrarea de interes.


45/50

Exemplul 2

• Sa presupunem ca vrem sa testam urmatoarea expresie ( A and not B) or (C xor D)

• Sa presupunem ca in tabelul de mai jos au fost identificate cazurile de test

necesare pentru testarea pe baze de cerinte

• Sa se determine daca cazurile de test asigura MC/DC


46/50


Etapa 1 : Se construieste schema expresiei


47/50


Etapa 2 : Se pun cazurile de test pe schema


48/50


Etapa 3 : Se elimina cazurile de test mascate


49/50


Etapa 4 Se verifica MCDC

Etapa 5 : Se adauga un caz de test. Pentru a asigura vizibilitatea prin poarta or

iesirea xor-ului trebuie sa fie falsa. Un posibil caz de test pentr ( ABCD) este deci

(FFTT).


50/50

Bibliografie

A Practical Tutorial on Modified Condition/ Decision Coverage, Kelly J.

Hayhurst, Dan S. Veerhusen, John J. Chilenski, Leanna K. Rierson, Mai2001

http://shemesh.larc.nasa.gov/fm/papers/Hayhurst-2001-tm210876-

MCDC.pdf

Documents

Ciclul in V