Ip13testarea2 170518132914

Ingineria programării
13. Faza de testare (II)
Florin Leon
Universitatea Tehnică „Gheorghe Asachi” din Iași
Facultatea de Automatică și Calculatoare
http://florinleon.byethost24.com/curs_ip.htm
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Faza de testare (II)
1. Testarea de nivel înalt
2. Testarea sistemului
3. Înregistrarea și urmărirea defectelor
4. Analiza și prevenirea defectelor
5. Testarea extremă
6. Principii de testare
7. Concluzii

7. Concluzii

Testarea de nivel înalt
 Chiar dacă s-ar putea realiza
testarea perfectă a modulelor, tot nu
s-ar putea garanta lipsa defectelor
 Este nevoie de testarea de nivel
înalt
 Un defect se manifestă atunci când
programul nu face ceea ce se
așteaptă utilizatorul, în mod
rezonabil, să facă
4
Dezvoltarea
și testarea
1. Nevoile utilizatorilor sunt
transformate în cerințe
(scopuri)
2. Cerințele sunt
transformate în obiective
specifice (fezabilitate, cost,
compromisuri, priorități)
3. Obiectivele sunt
transformate în specificații
externe (sistemul e văzut ca
o cutie neagră, se iau în
calcul doar interfețele și
interacțiunile cu utilizatorul)
5
Dezvoltarea
și testarea
Fiecare fază a procesului de
testare se concentrează pe
un anumit pas al procesului
de dezvoltare și pe o anumită
clasă de defecte
La sfârșitul fiecărei faze

există un pas separat de
verificare pentru a detecta
cât mai multe defecte înainte
de a trece la faza următoare
(de exemplu inspecții ale
codului)
6
Corespondențe
 Scopul testării modulelor / unităților este de a
găsi discrepanțele dintre modulele programului
și specificațiile interfețelor acestora
 Scopul testării funcționale este de a arăta că
programul nu respectă specificațiile externe
 Scopul testării sistemului este de a arăta că
produsul nu respectă obiectivele stabilite inițial
7
Testarea funcțională
 Specificațiile externe reprezintă o descriere precisă a
comportamentului sistemului din perspectiva utilizatorului
 Descriu toate intrările și ieșirile posibile ale produsului
 Specifică toate caracteristicile și combinațiile de caracteristici
 Testarea funcțională este o activitate de tip cutie neagră
 Partiționarea în clase de echivalență
 Analiza valorilor limită
 Grafurile cauză-efect
 „Ghicirea erorilor”
 Se bazează pe diagramele cazurilor de utilizare,
diagramele de stări etc.
8
Tipuri de testare funcțională
 Testarea navigării utilizatorului
 Testarea ecranelor de tranzacții
 Testarea fluxurilor de tranzacții
 Testarea ecranelor de rapoarte
 Testarea fluxurilor de rapoarte
 Testarea operațiilor cu bazele de date
(Create/Retrieve/Update/Delete)
 Exemplu: dacă un raport arată pe ecran într-un anumit
mod, trebuie să arate la fel și în forma tipărită
9
Testarea sistemului
 Este de obicei cel mai dificil proces de testare
 Scopul este compararea comportamentului
sistemului cu obiectivele sale inițiale
 Încearcă să demonstreze în ce fel sistemul nu își
îndeplinește obiectivele
 Testarea sistemului este imposibilă dacă nu există
obiective scrise măsurabile ale produsului
 Nu se referă la testarea funcțiilor sistemului
complet (≠ testarea funcțională)
10
Proiectarea testelor
 Testarea sistemului se
proiectează analizând obiectivele
 Cazurile de test se formulează
prin analiza documentației
utilizatorului
 Pentru fiecare linie din enunțul
obiectivelor, ar trebui să
demonstreze că produsul nu se
comportă corect
 Nu există metodologii de
proiectare a acestor teste
 Necesită creativitate
 Specificațiile externe corespund
testării funcționale
11
Exemplu: enunț de obiective
pentru comanda “display”
12
7. Concluzii

Testarea sistemului
 Testarea sistemului testează aplicația ca întreg și este
determinată de scenariile de analiză
 Aplicația trebuie să execute cu succes toate scenariile
pentru a putea fi pusă la dispoziția clientului
 Spre deosebire de testarea internă și a componentelor,
care se face prin program, testarea aplicației se face de
obicei cu scripturi care rulează sistemul cu o serie de
parametri și colectează rezultatele
 Testarea aplicației trebuie să fie realizată de o echipă
independentă de echipa de implementare
14
Testarea performanțelor
 O parte din testare se concentrează pe
evaluarea proprietăților emergente ale
sistemului, cum ar fi:
 Fiabilitatea: menținerea unui nivel specificat de
performanță
 Securitatea: persoanele neautorizate să nu aibă
acces iar celor autorizate să nu le fie refuzat accesul
 Utilizabilitatea: capacitatea de a fi înțeles, învățat și
utilizat
15
Tipuri de testare a sistemului
 Testarea caracteristicilor  Testarea configurației
 Testarea încărcării  Testarea compatibilității
 Testarea la stress  Testarea instalabilității
 Testarea volumului  Testarea fiabilității
 Testarea utilizabilității  Testarea recuperării
 Testarea securității  Testarea documentației
 Testarea stocării  Testarea procedurilor
16
Testarea caracteristicilor
 engl. “facility testing”
 Parcurgerea obiectivelor și testarea dacă
produsul îndeplinește fiecare obiectiv
 Compararea mentală a obiectivelor cu
documentația utilizatorului este deseori
suficientă
17
Testarea încărcării
 engl. “load testing”
 Presupune operarea sistemului în condiții normale sau cu
vârfuri anticipate de sarcină și observarea comportamentului
acestuia
 Ajută la identificarea capacității operaționale maxime a
sistemului
 Mediul de test este asemănător cu mediul în care va rula
sistemul în producție
 Relevantă în special pentru sisteme multi-user, client-server
sau pentru servicii cu SLA (“service level agreement”)
 Utilă și pentru alte tipuri de produse software: procesoare de
text sau grafice, aplicații cu generatoare de rapoarte etc.
18
Testarea încărcării
 Poate ajuta la depistarea cauzelor care scad
performanțele, de exemplu:
 Servere de aplicații sau alte componente software
 Servere de baze de date
 Latența sau congestia rețelei
 Prelucrările în partea clientului
 Echilibrarea încărcării între mai multe servere
19
Testarea la stress
 Solicită sistemul dincolo de încărcarea maximă proiectată
 Supraîncărcarea testează modul în care „cade” sistemul
 Sistemele nu trebuie să eșueze catastrofal
 Testarea la stress verifică pierderile inacceptabile de date sau funcționalități
 Deseori apar aici conflicte între teste. Fiecare test funcționează
corect atunci când este făcut separat. Când două teste sunt rulate în
paralel, unul sau ambele teste pot eșua
 Cauza este de obicei managementul incorect al accesului la resurse critice
(de exemplu memoria)
 O altă variantă, “soak testing”, presupune rularea sistemului pentru
o perioadă lungă de timp (zile, săptămâni, luni)
 În acest caz, de exemplu scurgerile nesemnificative de memorie se pot
acumula și pot provoca căderea sistemului
20
Testarea la stress
 Ajută la estimarea robusteții, disponibilității și modului de
tratare a erorilor printr-o încărcare dincolo de limitele
normale de operare
 Foarte importantă mai ales pentru sistemele critice, a
căror defectare poate avea consecințe dezastruoase
 Chiar dacă testele simulează condiții care nu vor apărea
niciodată, comportamentul sistemului poate da informații
importante despre erorile care ar putea apărea în situații
reale de funcționare
21
Testarea la stress
 Nu se pot determina toate modurile în care va fi folosit sistemul,
de exemplu un sistem de operare va rula aplicații care nici nu
există în momentul testării
 Utilizatorii vor putea rula sistemul pe calculatoare cu mai puține
resurse decât cele folosite pentru testare
 Concurența este dificil de testat cu metode tradiționale, de
exemplu “race conditions”, “deadlocks”
 Serverele web pot fi supuse atacurilor de tip “denial of service”
 Testarea la stress pentru un timp scurt poate simula operarea
normală pentru un timp îndelungat, de exemplu poate pune în
evidență scurgerile de memorie sau folosirea incorectă a
resurselor
22
Discuție
 Testarea la încărcare variază condițiile de operare,
de exemplu numărul de utilizatori, de tranzacții etc.,
menținând constantă configurația
 Numărul de tranzacții cu 2000, 3000, 4000 de utilizatori
concurenți
 Testarea la stress presupune condiții extreme sau
anormale, de exemplu resurse diminuate sau prelucrări
intense
 Numărul de tranzacții cu 2000, 3000, 4000 de utilizatori
concurenți, cu memorie foarte puțină pe server, viteză mică a
rețelei etc.
23
Testarea volumului
 Presupune expunerea produsului la un volum mare
de date
 Exemple:
 Un compilator care primește un fișier sursă de 1 MB
 Un simulator de circuite electronice care primește un circuit
cu 1000 de componente
 Un procesor de text care primește un document cu 2000
de pagini
 Scopul este să arate că programul nu poate
gestiona volumul de date specificat în obiective
24
Accepțiuni alternative
 Testarea la stress implică un element de timp: supunerea
sistemului la o încărcare foarte mare pentru o perioadă scurtă
de timp
 Aplicabilă mai ales pentru programele care operează la încărcări
variabile, interactive, în timp real: aplicații web, programe de control etc.
 Exemple:
 Dacă un sistem poate gestiona maximum 15 task-uri simultan, testarea
la stress implică rularea a 15 task-uri
 Dacă un sistem de control al traficului aerian poate gestiona 200 de
avioane simultan, se testează cu 200 sau 201 avioane sau se simulează
intrarea simultană a unui număr mare de avioane în raza sa de acțiune
 Pentru un sistem de control al proceselor, toate procesele monitorizate
generează semnale simultan
25
Accepțiuni alternative
 Analogie: evaluarea unei dactilografe
 Testarea volumului: dacă poate face față unui
raport de 100 de pagini
 Testarea la stress: dacă poate scrie la o rată de
50 de cuvinte pe minut
26
Testarea utilizabilității
 engl. “usability testing”
 Testează cât de ușor de folosit este sistemul
 Se poate face în laboratoare sau „pe teren” cu utilizatori
din lumea reală
 Recomandări:
 Interfețele cu utilizatorul trebuie să fie potrivite pentru profilul
acestuia
 Ieșirile trebuie să fie ușor de înțeles
 Mesajele de eroare nu trebuie să reflecte detalii interne de
programare
 Interfețele trebuie să aibă integritate conceptuală, coerență
27
Testarea utilizabilității
 Recomandări:
 Când acuratețea este vitală, intrările trebuie să aibă suficient de
multe elemente redundante, de exemplu număr cont, nume
titular, PIN etc.
 Sistemul nu trebuie să conțină un număr excesiv de opțiuni.
Accesarea lor trebuie să fie logică și intuitivă. Se pot prezenta
doar opțiunile folosite frecvent
 Sistemul trebuie să prezinte notificări pentru primirea intrărilor.
Dacă o operațiune este de durată, utilizatorul trebuie informat
 Sistemul trebuie să fie ușor de folosit. De exemplu, dacă intrările
sunt “case-sensitive”, utilizatorul trebuie să cunoască acest lucru,
sau într-o succesiune de meniuri sau ferestre, utilizatorul trebuie
să știe cum să se întoarcă la meniul principal
28
Testarea securității
 engl. “security testing”
 Trebuie imaginate cazuri de test care să corupă
sistemul de securitate
 Se pot studia probleme de securitate cunoscute
ale altor sisteme și se încearcă demonstrarea
existenței lor în sistemul testat
 Aplicațiile web necesită în general un nivel
superior de securitate, mai ales site-urile de
comerț electronic
29
Testarea stocării
 engl. “storage testing”
 Unele programe au obiective de stocare,
referitoare de exemplu la volumul de memorie
folosit sau la dimensiunea fișierelor temporare
 Trebuie imaginate cazuri de test care arată că
programul nu îndeplinește aceste obiective
30
Testarea configurației
 engl. “configuration testing”
 Sistemele de operare, sistemele de management al bazelor
de date, aplicațiile de transmitere de mesaje/pachete trebuie
să suporte o mulțime de configurații hardware
 Dispozitive de intrare-ieșire
 Linii de comunicație
 Dimensiuni diferite ale memoriei
 De multe ori, numărul configurațiilor posibile este prea mare
pentru a fi testată fiecare combinație în parte
 Trebuie testat sistemul cu fiecare tip de dispozitiv hardware și
cu configurațiile minime și maxime
31
Testarea compatibilității
 engl. “compatibility testing”
 Multe sisteme nu sunt complet noi, ci trebuie să
înlocuiască sisteme mai vechi sau cu probleme
 Pot exista obiective specifice privind
compatibilitatea cu sistemele existente, sau
procedurile de conversie a datelor
 De exemplu, actualizarea unui sistem de
management al bazelor de date
32
Testarea instalabilității
 engl. “installability testing”
 Unele sisteme software au proceduri complicate
de instalare
 Instalarea este primul contact al utilizatorului cu
sistemul
 O instalare defectuoasă îl poate împiedica să
folosească în mod adecvat produsul software,
să aibă încredere în el, sau îl poate determina
să aleagă un alt produs
33
Testarea fiabilității
 engl. “reliabiliy testing”
 În general, scopul tuturor tipurilor de testare este creșterea
fiabilității
 Testarea fiabilității poate fi dificilă
 Un WAN sau un ISP pot avea ca obiectiv un timp de funcționare de
99,97% (engl. “uptime”)
 Este greu de imaginat cum s-ar putea testa sistemul timp de câteva
luni sau ani
 Se poate calcula timpul mediu între defectări
 Există metode formale de demonstrare a corectitudinii unui
program. Trebuie demonstrat și că programul se va termina.
În cazul general demonstrarea este imposibilă, dar se poate
realiza pentru anumite cazuri particulare
34
Testarea recuperării
 engl. “recovery testing”
 Sistemele de operare, sistemele de management al
bazelor de date, programele de teleprocesare au de
obicei obiective de recuperare, care arată cum trebuie să
repornească sistemul după defecțiuni legate de
programare, de hardware sau de date
 Testarea presupune crearea (simularea) unor condiții de
eroare în mediul extern de execuție
 Testarea își propune să arate că:
 Funcțiile de recuperare nu lucrează corect
 Sistemul nu respectă timpul mediu pentru recuperare asumat
35
Testarea documentației
 engl. “documentation testing”
 Documentația este folosită ca un ghid pentru
scrierea cazurilor de test la testarea sistemului
 Documentația utilizatorului trebuie să fie
inspectată (ca și codul), analizându-i-se
acuratețea și claritatea
36
Testarea procedurilor
 engl. “procedure testing”
 Multe produse software sunt parte a unor
sisteme mai mare, incomplet automatizate, care
implică proceduri urmate de oameni
 Toate procedurile trebuie testate, de exemplu
cele pentru operatorii de sistem, administratorul
de baze de date sau utilizatorii finali
37
Executarea testării sistemului
 Cine trebuie să testeze sistemul
 Pe cât posibil, nu programatorii
 O echipă formată din: experți în testare, inginer de factori
umani (“human factors engineer”), 1 sau 2 utilizatori
reprezentativi, analistul sau proiectantul aplicației
 Pe cât posibil, nu organizația dezvoltatoare
 Aceasta nu are de fapt motivația să demonstreze că produsul
nu îndeplinește obiectivele
 Cel mai economic mod de a realiza testarea sistemului
(găsirea numărului maxim de defecte cu un anumit cost sau
un cost mai mic pentru descoperirea aceluiași număr de
defecte) este subcontractarea către o altă organizație
 vezi și principiile 2 și 3 spre sfârșitul cursului
38
7. Concluzii

Ciclul de viață al unui defect
 De cele mai multe ori, persoana care raportează
un defect este diferită de cea care îl repară
 Un proiect mare poate include mii de defecte
 În astfel de situații, raportarea și repararea
nu pot fi făcute informal: un defect ar putea
fi uitat și/sau redescoperit ulterior cu un efort
suplimentar
40
 Formal, când un defect este descoperit – de către oricine – este
înregistrat (“logged”) într-un sistem de control al defectelor
 Defectul este în starea trimis (“submitted”)
 Repararea defectului este atribuită unei persoane, de obicei
programatorul inițial, care realizează depanarea (“debugging”)
 Defectul este în starea reparat (“fixed”)
 Se verifică dacă defectul a fost reparat cu succes
 Defectul este în starea închis (“closed”)
41
 Ciclul de viață poate fi mărit sau micșorat în funcție de
natura proiectului
 Pentru proiecte mici, un defect poate fi doar „deschis”
sau „închis”
 Pentru proiecte critice, un defect poate trece prin mai
multe faze de urmărire
 Defectele sunt deseori clasificate, pentru a le înțelege
mai bine natura
 De exemplu: logică, standarde, interfața cu utilizatorul,
interfațarea componentelor, performanțe, documentație
42
Clasificarea după severitate
 În multe organizații se folosește o clasificare a
defectelor pe 4 niveluri:
 Defecte critice: afectează mulți utilizatori, pot întârzia
proiectul
 Defecte majore: au un impact puternic, necesită un volum
mare de lucru pentru a le repara, dar nu afectează
substanțial graficul de lucru al proiectului
 Defecte minore: izolate, care se manifestă rar și au un
impact minor asupra proiectului
 Defecte cosmetice: mici greșeli care nu afectează
funcționarea corectă a produsului software
43
Exemplu: descoperirea și
închiderea defectelor
 În figură, distanța dintre numărul
total de defecte și numărul
defectelor închise crește
 Activitatea de dezvoltare trebuie
încetinită și trebuie alocate mai
multe resurse reparării defectelor
 Pentru un proiect gestionat
corespunzător, numărul de
defecte deschise ar trebui să se
reducă spre sfârșitul proiectului,
chiar dacă nu este obligatoriu ca
variația să fie monoton
descrescătoare
44
7. Concluzii

Analiza și prevenirea defectelor
 La nivel organizațional, analiza defectelor poate
îmbunătăți listele de verificare, procesele sau
instruirea personalului
 La nivelul proiectului, se învață din defectele
descoperite până la un moment dat pentru a preveni
pe cât posibil defectele din restul proiectului
 Prevenirea defectelor
 Crește calitatea: sistemul final va avea mai puține defecte
 Crește productivitatea: se consumă mai puțin efort pentru
repararea defectelor
46
Analiza Pareto
 Se bazează pe așa-numita „regulă 80-20”:
 80% din probleme vin din 20% din sursele posibile
 80% din efecte sunt determinate de 20% din cauze
 Pentru un produs software: 80% din defecte apar din
20% din cauzele esențiale sau 80% din defecte se
găsesc în 20% din cod
 Se realizează o diagramă Pareto cu numărul de defecte
de diferite tipuri
 Diagrama identifică tipurile principale de defecte
descoperite, care au o mare probabilitate de a se regăsi
și în restul proiectului, dacă nu se iau unele măsuri
47
Exemplu: diagramă Pareto
 Primele 3 categorii de defecte reprezintă mai mult de 88% din total
 Aceste categorii ar trebui să fie ținta prevenirii defectelor ulterioare
48
Analiza cauzală
 Diagrama Pareto identifică tipurile principale de defecte
(pot fi considerate efecte)
 Analiza cauzală are scopul de a identifica principalele cauze
ale acestor efecte
 Înțelegerea cauzelor ajută la identificarea soluțiilor pentru
eliminarea lor
 Cauze majore tipice: procese, oameni, tehnologie, instruire
 Cauzele și sub-cauzele se determină prin brainstorming;
dacă se identifică mai multe, acestea se prioritizează
 Această metodă de analiză se bazează pe diagrama Ishikawa
(diagrama cauză-efect)
49
Exemplu: diagramă Ishikawa
sub-cauze
efectul
cauze
50
Dezvoltarea și implementarea
soluțiilor
 În această fază, se găsesc soluții pentru
atenuarea cauzelor descoperite, tot prin
brainstorming
 Soluțiile găsite trebuie apoi implementate
 Trebuie tratate ca activități ale proiectului
 Este importantă verificarea efectelor soluțiilor,
pentru a vedea dacă sunt eficiente
 Oamenii sunt convinși dacă văd rezultate
 De exemplu, analiza defectelor după implementarea
soluțiilor
51
Exemplu
52
Intensitatea defectărilor în timp
λ0 = intensitatea inițială a defectărilor

ν0 = numărul total de defectări
Aceste valori trebuie cunoscute pentru a

estima fiabilitatea produsului software
53
7. Concluzii

Testarea extremă
 eXtreme Programming (XP), Kent Beck, 1996, Daimler-Chrysler
 Metodologie agilă de dezvoltare software
 A facilitat adoptarea noilor limbaje de programare, precum
Java și C#, pentru dezvoltarea rapidă de aplicații
 Aplicațiile se creează mai ușor și mai rapid, însă nu este
garantată calitatea
 Scopul XP: programe de calitate într-un timp scurt
 Se bazează pe testarea unităților și pe testarea de recepție
(“acceptance”): cazurile de test se realizează înaintea codului
propriu-zis
55
Caracteristicile XP
 Arhitecturi simple, comunicare între dezvoltatori și clienți,
testare permanentă, refactorizare
 XP funcționează bine pentru proiecte mici și medii,
cu schimbări frecvente ale specificațiilor și unde
comunicarea rapidă este posibilă
 Evită stabilirea tuturor detaliilor de la început, permite
schimbările cerințelor
 Se evită funcționalitățile care nu sunt absolut necesare
la un moment dat
 Accentul cade pe funcționalitatea care are o valoare
mare pentru client
56
Testarea extremă
 Reguli:
 Toate modulele trebuie să aibă teste înainte de scrierea codului
 Toate modulele trebuie să treacă toate testele înainte de a fi lansat
sistemul
 Dificultăți:
 Cum poate fi scris un test pentru un cod inexistent
 Cum afectează scrierea acestor teste termenul limită
 Beneficii:
 Încrederea că programul va respecta specificațiile
 Exprimarea rezultatului final înainte de implementare
 Înțelegerea mai bună a cerințelor și specificațiilor
 Se poate începe cu o arhitectură mai simplă și apoi codul se poate
refactoriza fără teama nerespectării specificațiilor
 Automatizarea testării (de exemplu cu NUnit, JUnit etc.)
57
Exemplu
58
Cazuri de test
59
[TestClass]
public class UnitTestCheckPrime
{
[TestMethod]
public void TestCheckPrime_True() //Test case 1
{
Assert.IsTrue(CheckPrime.PrimeCheck(3));
}
[TestMethod]
public void TestCheckPrime_False() //Test cases 2,3
{
Assert.IsFalse(CheckPrime.PrimeCheck(0));
Assert.IsFalse(CheckPrime.PrimeCheck(1000));
}
[TestMethod]
[ExpectedException(typeof(Exception))]
public void TestCheck4Prime_CheckArgs_Neg_Input() //Test case 4
{
string[] args = new string[1];
args[0] = "-1";
CheckPrime.CheckArgs(args);
}
[TestMethod]
public void TestCheck4Prime_CheckArgs_Above_Upper_Bound() //Test case 5
{
args[0] = "10001";
}
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm 60

[TestMethod]
public void TestCheck4Prime_CheckArgs_2_Inputs() //Test case 6
{
args[0] = "5";
args[1] = "99";
}
[TestMethod]
[ExpectedException(typeof(FormatException))]
public void TestCheck4Prime_CheckArgs_Char_Input() //Test case 7
{
args[0] = "r";
}
[TestMethod]
public void TestCheck4Prime_CheckArgs_0_Inputs() //Test case 8
{
}
}

public class CheckPrime
{
private const int Max = 1000; // Set upper bounds.
private const int Min = 0; // Set lower bounds.
private static int _input = 0; // Initialize input variable.
private static void Main(string[] args)

{
try
{
//Check arguments and assign value to input variable
//Check for Exception and display help
}
catch
{
Console.WriteLine("Usage: CheckPrime x");
Console.WriteLine(" -- where 0<=x<=1000");
Environment.Exit(1);
}
//Check if input is a prime number

if (CheckPrime.PrimeCheck(_input))
Console.WriteLine("{0} is a prime number", _input);
else
Console.WriteLine("{0} is not a prime number", _input);
}

/// <summary>
/// Calculates prime numbers and compares it to the input
/// </summary>
/// <param name="num"></param>
/// <returns></returns>
public static bool PrimeCheck(int num)
{
double sqroot = Math.Sqrt(Max); // Find square root of n
//Initialize array to hold prime numbers

bool[] primeBucket = new bool[Max + 1];
//Initialize all elements to true, then set non-primes to false

for (int i = 2; i <= Max; i++)
primeBucket[i] = true;
//Do all multiples of 2 first

int j = 2;
for (int i = j + j; i <= Max; i = i + j)
{
//start with 2j as 2 is prime
primeBucket[i] = false; //set all multiples to false
}
// cont. ->

for (j = 3; j <= sqroot; j = j + 2)
{
// do up to sqrt of n
if (primeBucket[j] == true)
{
// only do if j is a prime
for (int i = j + j; i <= Max; i = i + j)
{
// start with 2j as j is prime
primeBucket[i] = false; // set all multiples to false
}
}
}
//Check input against prime array

if (primeBucket[num] == true)
return true;
else
return false;
} // PrimeCheck

/// <summary>
/// Method to validate input
/// </summary>
/// <param name="args"></param>
public static void CheckArgs(string[] args)
{
//Check arguments for correct number of parameters
if (args.Length != 1)
{
throw new Exception();
}
else
{
//Get integer from string
_input = Convert.ToInt32(args[0]);
//If less than zero

if (_input < 0) //If less than lower bound
throw new Exception("Less than lower bound");
else if (_input > Max) //If greater than upper bound
throw new Exception("Greater than upper bound");
}
}
}

Rezultatele testării
66
7. Concluzii

Principii de testare
1. O parte necesară a unui caz de test este
definirea ieșirii sau rezultatului așteptat
 Dacă nu este definit rezultatul așteptat, un rezultat
plauzibil, dar greșit, poate fi interpretat drept corect
 „Ochiul vede ce vrea să vadă” – dorință subconștientă
de a vedea un rezultat corect
 Un caz de test trebuie să aibă:
 O descriere a datelor de intrare
 O descriere precisă a rezultatului corect corespunzător datelor
de intrare respective
68
2. Programatorii nu ar trebui să-și testeze
propriile programe
 Programatorul știe ce ar trebui să facă o secvență de cod și nu își dă
seama când face altceva
 Programatorul are o perspectivă constructivă (proiectare/implementare);
testarea necesită o perspectivă destructivă
 Programatorul poate evita în mod subconștient găsirea defectelor, de
frica șefului/colegilor/clientului etc.
 Programul poate conține defecte deoarece programatorul nu a înțeles
specificațiile – și testele vor suferi de pe urma acestor neînțelegeri
 Principiul nu spune că un programator nu își poate testa propriul cod,
ci că testarea este făcută mai eficient de altcineva
 Depanarea (“debugging”) este făcută mai eficient de programatorul inițial
69
3. Organizațiile nu ar trebui să-și testeze
propriile programe
 Performanțele organizației și ale managerului de proiect sunt
deseori măsurate drept capacitatea de a termina proiectul la o
dată limită și cu o limită de cost
 Timpul și costul sunt ușor cuantificabile, însă fiabilitatea
programului – nu
 Testarea corectă scade probabilitatea atingerii obiectivelor de
cost și de timp
 Nu este imposibil ca organizațiile să-și testeze propriile
programe, însă o testare obiectivă, independentă, poate crește
calitatea programului
70
4. Rezultatele fiecărui test trebuie inspectate
amănunțit
 Numeroase experimente au arătat că unele defecte
nu sunt detectate, deși simptomele lor puteau fi clar
observate în testele anterioare
 Multe defecte descoperite la un moment dat ar fi putut
fi detectate din rezultatele testelor anterioare
71
5. Trebuie scrise cazuri de test atât pentru
condiții de intrare invalide și neașteptate, cât și
pentru condiții de intrare valide și așteptate
 Există o tendință naturală ca testerii să se
concentreze pe condițiile de intrare valide și așteptate
(scenariile normale de funcționare ale programului)
 Multe defecțiuni apar după livrare din cauza utilizării
programului într-un mod neașteptat
 Testarea condițiilor neașteptate detectează mai multe
defecte decât testarea condițiilor așteptate
72
6. Programul trebuie examinat pentru a vedea
dacă nu face ce trebuie; de asemenea, trebuie
examinat pentru a vedea dacă face ce nu
trebuie
 Programele trebuie examinate și pentru detectarea
efectelor secundare
 De exemplu, un program de salarii care produce rapoarte
pentru salariați inexistenți sau șterge prima înregistrare din
baza de date a personalului
73
7. Cazurile de test abandonabile trebuie evitate
dacă programul nu este abandonabil
 Test abandonabil (engl. “throwaway”): o persoană
rulează programul manual, cu diferite date de intrare
 Testele dispar după ce testarea a fost terminată
 Cazurile de test trebuie salvate și re-executate după
efectuarea unor schimbări în program: testarea de
regresiune
74
8. Efortul de testare nu trebuie planificat cu
presupunerea tacită că nu se vor descoperi
defecte
 Presupunerea greșită că testarea arată că programul
funcționează corect
75
9. Probabilitatea să existe defecte suplimentare într-o
secțiune a programului este proporțională cu numărul de
defecte deja descoperite în acea secțiune
 Defectele tind să apară în grupuri
 Unele secțiuni ale programului sunt mai predispuse la defecte
decât altele – pot fi secțiuni mai dificile sau secțiuni unde a lucrat
o persoană mai puțin pregătită
 De exemplu, un program are 2 module, A și B. În modulul A s-au
descoperit 5 defecte, iar în B doar 1 defect. Dacă A nu a fost
supus unei testări mai riguroase, atunci probabilitatea de a găsi
mai multe defecte în A este mai mare decât probabilitatea de a
găsi mai multe defecte în B
76
9. Probabilitatea să existe defecte suplimentare într-o
secțiune a programului este proporțională cu numărul de
defecte deja descoperite în acea secțiune
Relația surprinzătoare
dintre numărul de
defecte rămase și
numărul de defecte
descoperite 77
10. Testarea este un proces definit de
creativitate și provocări intelectuale
 Creativitatea necesară pentru testare probabil
depășește creativitatea necesară pentru proiectare
78
Concluzii
 Testarea detectează nu numai erorile de implementare,
ci și pe acelea de analiză și proiectare
 Testarea este o metodă dinamică de verificare și
validare, unde un element (un modul sau sistemul întreg)
este executat și i se observă comportamentul
 Testarea se bazează pe un plan, care ghidează întregul
proces:
 Specifică nivelurile testării și elementele testate
 Cazurile de test specificate sunt inspectate și apoi executate
 Rezultă raportul de testare (cazurile executate) și raportul
defectelor descoperite
79
Concluzii
 Niciodată nu putem fi siguri că specificațiile sunt 100%
corecte
 Niciodată nu putem fi siguri că un instrument de testare
este corect
 Niciun instrument de testare nu poate fi folosit pentru
toate produsele software
 Testerii nu pot fi niciodată siguri că înțeleg complet un
produs software
 Niciodată nu putem fi siguri că testarea unui produs
software este completă
80

Ip13testarea2 170518132914

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Ip13testarea2 170518132914

Încărcat de

Drepturi de autor:

Formate disponibile

Ingineria programării

13. Faza de testare (II)

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

La sfârșitul fiecărei faze

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

λ0 = intensitatea inițială a defectărilor

Aceste valori trebuie cunoscute pentru a

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm 60

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm 61

private static void Main(string[] args)

//Check if input is a prime number

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm 62

//Initialize array to hold prime numbers

//Initialize all elements to true, then set non-primes to false

//Do all multiples of 2 first

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm 63

//Check input against prime array

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm 64

//If less than zero

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm 65

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

S-ar putea să vă placă și