ciclul in v
Post on 06-Jul-2018
219 Views
Preview:
TRANSCRIPT
-
8/18/2019 Ciclul in V
1/50
CICLUL IN V
NOTIUNI DE TESTARE STRUCTURALA
-
8/18/2019 Ciclul in V
2/50
CUPRINS
01 Generalitati Ciclul in V
02 Specificitati Auto
03 Notiuni de testare structurala
-
8/18/2019 Ciclul in V
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
-
8/18/2019 Ciclul in V
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
-
8/18/2019 Ciclul in V
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
-
8/18/2019 Ciclul in V
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)
-
8/18/2019 Ciclul in V
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/18/2019 Ciclul in V
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
-
8/18/2019 Ciclul in V
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
-
8/18/2019 Ciclul in V
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
-
8/18/2019 Ciclul in V
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
-
8/18/2019 Ciclul in V
12/50
Ciclul in V exemplu
• Sistemul va f i compus din 3 « module » :
• CitesteTemperatura
• CitesteViteza
• ActiveazaReleu
Proiectare
sistem/arhitectura
(HLR)
-
8/18/2019 Ciclul in V
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)
-
8/18/2019 Ciclul in V
14/50
Ciclul in V - exemplu
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
-
8/18/2019 Ciclul in V
15/50
Ciclul in V - exemplu
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;}
-
8/18/2019 Ciclul in V
16/50
Ciclul in V - exemplu
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();
}
-
8/18/2019 Ciclul in V
17/50
Ciclul in V - exemplu
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.
-
8/18/2019 Ciclul in V
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
-
8/18/2019 Ciclul in V
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
-
8/18/2019 Ciclul in V
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
-
8/18/2019 Ciclul in V
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
-
8/18/2019 Ciclul in V
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
-
8/18/2019 Ciclul in V
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
-
8/18/2019 Ciclul in V
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
-
8/18/2019 Ciclul in V
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
-
8/18/2019 Ciclul in V
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
-
8/18/2019 Ciclul in V
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
-
8/18/2019 Ciclul in V
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
-
8/18/2019 Ciclul in V
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
-
8/18/2019 Ciclul in V
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
-
8/18/2019 Ciclul in V
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
-
8/18/2019 Ciclul in V
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
-
8/18/2019 Ciclul in V
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é
-
8/18/2019 Ciclul in V
34/50
Testare MCDC a unei porti AND
-
8/18/2019 Ciclul in V
35/50
Testare MCDC a unei porti OR
-
8/18/2019 Ciclul in V
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
-
8/18/2019 Ciclul in V
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.
-
8/18/2019 Ciclul in V
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
-
8/18/2019 Ciclul in V
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)
-
8/18/2019 Ciclul in V
40/50
Exemplul 1 (cont’d)
Etapa 1 : Se realizeaza schema codului sursa
Etapa 2 : Maparea cazurilor de test pe schema
-
8/18/2019 Ciclul in V
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
-
8/18/2019 Ciclul in V
42/50
Example 1 (cont’d)
Etapa 4 : Se verifica MC/DC.
Etapa 5 : Se confirma ca nu exista cazuri de test care lipsesc
-
8/18/2019 Ciclul in V
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
-
8/18/2019 Ciclul in V
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.
-
8/18/2019 Ciclul in V
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
-
8/18/2019 Ciclul in V
46/50
Exemplul 2 (cont’d)
Etapa 1 : Se construieste schema expresiei
-
8/18/2019 Ciclul in V
47/50
Exemplul 2 (cont’d)
Etapa 2 : Se pun cazurile de test pe schema
-
8/18/2019 Ciclul in V
48/50
Exemplul 2 (cont’d)
Etapa 3 : Se elimina cazurile de test mascate
-
8/18/2019 Ciclul in V
49/50
Exemplul 2 (cont’d)
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).
-
8/18/2019 Ciclul in V
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
top related