Testare Software

Curs 1 - Introduction
1. Ce reprezinta Testarea?
R: O investigatie tehnica a unui produs bazata pe teste ce au ca rol sa ofere persoanelor
interesate in cauza informatii legate de calitatea soft-ului. [Kaner]
2. Enumerati 5 obiective ale testarii.
R: gasirea de bug-uri importante, pentru a fi inlaturate; evaluarea calitatii produsului;
ajuta managerii in luarea deciziilor; blocarea lansarii de produse incomplete; verificarea
interoperabilitatii cu alte produse.
Curs 2 Engineering process
1. Prezentati etapele tipice din ciclul de viata al unui produs software. Detaliati.
R:
a) Analizarea cerintelor si specificatiilor
Reprezinta procesul de stabilire a serviciilor cerute si a constrangerilor legate de
operatiile sistemului si dezvoltare.
Cerintele procesului ingineresc: studiu fezabilitate; elucitarea cerintelor si analiza,
specificarea cerintelor, validarea cerintelor.
b) Design
Proiectarea structurii software ce corespunde specificatiilor.
c) Implementarea
Translatarea structurii(de mai sus) intr-un program executabil.
Design si implementare
=> procesul de convertire a specificatiilor sistemului intr-un sistem executabil.
=> aceste activitati sunt strans legate.
d) Testare
V&V are rolul de a arata ca un sistem este conform cu specificatiile si intruneste
cerintele clientului sistemului.
Presupune cautare si revederea proceselor si testarea sistemului
Testarea Sistemului
=>presupune executarea sistemului folosind cazuri de testare ce sunt derivate din
specificatiile datei reale, ce trebuie procesata de sistem.
e) Mentenanta
Pe masura ce cerintele din cauza diferitelor circumstante de activitate, soft-ul ce suporta
aceasta activitate trebuie sa evolueza si sa se schimbe.
f) Ciclu de viata
Reprezinta un mod particular de a realiza activitati in legatura cu diferite faze ale

procesului de proiectie a softului.

IDEEA: indeplinirea obiectivului. Exemplu: Cresterea calitatii, etc.
2. Fazele Modelului Waterfall(Cascada).
R:
- Concepere Soft
- Cerinte
- Analiza
- Design
- Codare si Debug
- Testare Sistem
- Deployment(Desfasurare(ro)) & Mentenanta
3. Descrieri modelul Waterfall.(Avantaje)
R:
- Primul model soft aplicat;
- sta la baza altor modele;
- progresare ordonata de la conceptul initial catre testarea sistemului si mentenanta
- revizuire la fiecare sfarsit de etapa. Intoarcerea la faza anterioara daca nu este
acceptata.
- Document driven
- Faze discontinue:nu se suprapun
- Potrivit pentru definirea de produse stabile si tehnologii
- Gasirea erorilor in etape timpurii
- Minimizarea planificarii overhead
- Potrivit chiar si pentru echipe nexperimentate.
4. Descrieri modelul Waterfall.(Dezvantaje)
R:
- Riscurile slab adresate;
- Produsul nu e vizibil pana la stagiile finale
- Stabilitatea cerintelor nu este o presupunere valida in dezvoltarea de software
- Descoperirea functiilor lipsa la sfarsitul unui ciclu e foarte scumpa
- Lipsa flexibilitatii
- Costisitoare
- Longer schedules.
5. Descrieti testarea in cazul Waterfall
R:
- Testarea la sfarsitul ciclului de viata
- Nici o interactiune intre testare si dezvoltare
- Consecinta: pastrarea depart testarii si dezvoltarii separat
- Procesul de testare soft este considerat a fi unul destructiv
- Programatorii nu ar tb sa isi testeze propriile programe
- Organizatiile de programatori(firmele) nu ar tb sa isi testeze propriile programe.

6. Fazele Modelului V (Waterfall modificat)

R:
7. Descrieti testarea in cazul Modelului in V
R:
- inceperea activitatilor de testare in fazele incipiente ale ciclului de viata
- definirea clara a celor patru tipuri de activitati de testare:
o testarea unitatii
o testarea integritatii (de integrare)
o testarea sistem
o testarea acceptanta
- planul de testare afecteaza planul de dezvoltare
8. Fazele Modelului in Spirala.
R:
9. Descrieti testarea in cazul Modelului in spirala
R:
- Primul model iterativ major: planificarea distribuita de-alungul iteratiilor
- Mai bun ca waterfall: identifica riscul din timp
- Procesul este reprezentat in forma de spirala, la waterfall este o inlantuire de
secvente de activitati cu backtracking.
- Fiecare bucla din spirala reprezinta o faza din proces
- Fiecare iteratie a spiralei consta in eliminarea unui risc major
- Nu este specificata fix faza de specificare sau design buclele in spirala sunt alese
depinzand de cerinte.
- Ultima spirala poate fi un ciclu waterfall
- Rezultatul fiecarei iteratii reprezinta prototipuri tot mai rafinate pana la eliberarea
versiunii finale.
10. Prezentati avantajele si dezavantajele Modelului in Spirala
R:
Avantaje:
- Adresarea timpurie a riscurilor: pe masura ce cresc costurile , scad riscurile
- Controlul managementului este cel putin ca in cazul waterfall, imbunatatit de
existenta (so called: checkpoints) punctelor de verificare la sfarsitul fiecarei iteratii a
spiralei.
Dezavantaje:
- Uneori complicat de gestionat
- Poate fi dificil de definit milestone ce indica daca esti pregatit sa treci la urmatoarea
iteratie.
11. Fazele modelului RUP
R:

12. Descrieti RUP

R:
- Incipienta(de inceput) : definirea scopului proiectului, obtinerea intelegerii pe
obiectivele proiectului.
- Elaborarea: adress key technical risks, producerea unui prototip evolutionar.
- Construirea: Dezvoltarea Iterativ si incremental a unui produs complet operational
- Tranzitie: Trimiterea produsului in mediul utilizator-final.
13. Descrieti Agile Development
R:
- XP
- SCRUM
- Iterativ ridicat
- Se adapteaza la modificarile cerintelor
- Bazat pe comunicarea echipelor
- Bun pentru mici/experimentate echipe
- Programarea in echipe
- Refactorizare
- Implicarea activa a clientilor
- Posibil sa nu scaleze pe proiecte mari
14. Descrieti XP Testing
R:
Testare Timpurie
- Nu trebuie asteptat sa se testeze pana la sfarsit asamblarii sistemului.
- Rulare cazuri de testare pe masura ce o unitate e implementata.
Testare la inceput
- Scriere cazuri de testare inainte de implementare unitatii. Acesta e folositor
deoarece cazurile de testare pot servi ca specificatii.
Testare des
- Rulare teste cu fiecare lansare de sistem. Rulare dupa fiecare modificare.
Alte teste
- Sa testeze altcineva testele
Realizare doar UNIT testing si ACCEPTANCE testing.
Curs 3 Quality Assurance
1. Definiti termenul de Calitate Soft
R:
Gradul in care un sistem, componenta sau proces respecta cerintele specificate.
2. Definiti termenul Software Quality Assurance
R:
Un sablon planificat & sistematic a tuturor actiunilor necesare pentru a oferi incredere
adecvata ca un produs este conform cu cerintele tehnice stabilite.
Un set de activitati gandite sa evalueze procesul prin care produsele sunt dezvoltate sau

fabricate
3. Calitatea proiectelor IT
R:
Functionalitate este gradul n care un sistem si ndeplineste functia destinata.
Caracteristici sunt caracteristicile sistemului special care apeleaza la utilizatori
Iesiri de sistem sunt ecrane si rapoartele pe care sistemul le genereaza
Fiabilitatea este capacitatea unui produs sau serviciu pentru a efectua cum era de asteptat,
n conditii normale
Disponibilitatea este caracteristic pentru un produs sau serviciu pentru a fi accesibila
atunci cnd este necesar sa fie
Aderese de Mentenabilitate- usurinta de efectuare de ntretinere pe un produs
Adese de Performanta - ct de bine un client doreste sa foloseasca performantele unui
produs sau unui serviciu
Scalabilitate este abilitatea a sistemelor de a se adapta si de a realiza asa cum ne asteptam
conform cerintelor folosite crescande.
4. V & V
Verification vs. Validation
Verification:
Software-ul ar trebui sa fie in conformitate cu specificatiile lui.
Validation:
Software-ul ar trebui sa faca ce ii zice utilizatorul.
The V & V process
Este un intreg process de ciclare-V&V trebuie aplicat la fiecare pas in procesul
software.
Are 2 obiective principale
-descoperirea defectelor(erorilor) in system
-evaluarea dc sistemul este sau nu util si usor de utilizat intr-o situatie de
exploatare.
V& V goals
V&V ar trebui sa stabileasca increderea ca software-ul este adaptat scopului.
Aceasta nu inseamna ca e complet lipsit de defecte(erori).
Mai degraba, aceasta trebuie sa fie suficient de bun pentru ce a fost creat sa fie utilizat si
tipul
de utilizare va determina gradul de incredere de care are nevoie.
V & V confidence
Depinde de cerintele sistemului,asteptarile utilizatorului si mediul marketingului
V & V planning
Planificarea atenta este necesara pentru a obtine cel mai mult de la testarea si
inspectarea
proceselor.
Planificarea ar trebui sa inceapa devreme in procesul de development.
Planul ar trebui sa identifice balanta intre verificarea statica si testare.
Test planning se refera la definirea standardelor pentru procesul de testare,mai degraba
decat descrierea product testelor.

5. Static and dynamic verification

Inspectii software.
=>Preocupat de analiza a sistem de reprezentare statica pentru a descoperi probleme
(static
verification)
Testare software.
=>Preocupat cu exercitarea si observarea comportamentului produsului(dynamic
verification)
????Software inspections
These involve people examining the source representation with the aim of discovering
anomalies and defects.
Inspections not require execution of a system so may be used before implementation.
They may be applied to any representation of the system (requirements, design,
configuration data, test data, etc.).
They have been shown to be an effective technique for discovering program errors.
Inspection success
Many different defects may be discovered in a single inspection. In testing, one defect
,may mask another so several executions are required.
The reuse of domain and programming knowledge so reviewers are likely to have seen
the types of error that commonly arise.
6. Inspections and testing
Inspectiile si testarile sunt complementare si nu opuse tehnicilor de verificare.
Ambele ar trebui folosite pe durata procesului V&V.
Inspectiile pot verifica conformatii cu o specificatiile dar nu pot verifica conformatii cu
cererile reale ale clientului.
Inspectiile nu pot verifica corect carac non-functionale ca de exemplu performanta,grad
de utilizare,etc.
The inspection process
- Planificarea, privire ansamblu, pregatire individuala, inspectia, revizie, urmarire.
7. Types of testing
Defect(verification) testing
Test conceput sa descopere defectele sistemului.
Un defect test este correct(de succes) daca indica prezenta defectelor in system.
Teste de validare
Destinat sa arate ca software-ul intruneste cerintele sale.
Un test corect este acela care arata ca cerintele au fost implementate
corespunzator.
Inspection
meeting
Indi vidual
pr epar ation
Overvie w
Planning

Rework
Follo w-up
The software testing process
Testing and debugging
Defect testing si debugging sunt procese disticnte.
V&V are grija sa stabileasca existenta unor defecte in program.(in cazul in care acestea
exita)
Debugging are grija sa localizeze si sa repare aceste erori.
Debugging implica formularea de ipoteze legate de comportamentul programului decat
sa testeze aceste ipoteze pt a gasi eroarea.
JUNIT
? Este un framework simplu pt creare automata de teste unit.
? JUNIT test cases sunt clase Java care contin una sau mai multe metode unit
test,si aceste teste sunt grupate in test suites.
? Poti rula testele individual sau poti rula toate test suites.
? Fiecare JUnit test ar trebui sa se execute rapid.
Design test cases
Prepar e test data
Run program with test data Compare results to test cases
Test
cases
Test
data
Test
results
Test
repor ts
CURS 4 Testing Types
Black box testing
- Este bazat pe observarea caracteristicilor externe ale programului ce il testam.
Testele sunt gandite fara a tine cont de cum functioneaza programul intern.
- Testele sunt realizate pe prototipuri dezvoltate si versiuni
- Tehnici simple: tabele de decizie, testare integritate bd, testare exceptii, testare
random
- Testele sunt conduse de cerintele produsului si specificatii des utilizate in testarea
sistemului si testarea acceptantei
- Nu vor arata efectele laterale ale actiunii. Exemplu: trimitere de mail nedorit.
White box testing
- Este numita si testare glass box, bazata pe observarea caracteristicilor interne ale
programului
- Testele sunt gandite sa exerseze diferite parti sigure ale codului utilizand
cunostiintele pe caile logicii si datelor interne
- Cerintele si specificatiile nu sunt considerate
- Tehnici simple: analiza caii de baza, acoperire expresie, acoperire margini/conditii,
etc.

- Folosit pentru testarea unitara si testarea integritatii

- Nu detecteaza caile lipsa si erorile de data sensibile
- Este f greu de verificat toate caile logice posibile
Gray Box Testing
- Combinare intre black si white testing
- Testorul comunica cu dezvoltatorul despre calea in care specifiicatile au fost
implementate
- Util cand specificatiile sunt ambiguee
- Poate reduce numarul de teste cerute
Acceptance testing
- Testarea bazata pe cerintele clientului: valideaza produsul
- Realizata la sfarsitul fiecarui ciclu de viata
- Acopera doar testele esentiale ale programului
- Deseori realizata de o organizatie externa, alta decat cea ce a construit produsele
sau utilizatorii finali.
- Black box testing type
- Poate include testarea non-functional
- Realizata fara a tine cont de ciclu de viata al prod
System testing
- Testarea bazata pe specificatiile produsului
- Nu valideza cerintele
- Testare Black Box
- Acopera aspectele functionale si non-functionale
- Realizarea pe un produs complet
- Unele metodologii nu o includ(XP)
Integration testing
- Testarea a putine parti din cod impreuna
- Descopera erori de interfata si erori de protocol
- Incepe cu module putine si eventual acopera toata aplicatia
- Combinata cu diferite module ofera o abordare (en. Divide and Impera) in evaluarea
sistemului deseori numita testare incrementala
- Deseori realizata de dezvoltatori
- Abordare Bottom-up
Unit testing
- Testarea modulelor individuale de cod inainte de a fi integrate in produs
- Realizat de developeri
- Presupune scrierea unui cod ce apeleaza si realizarea asertiuni pe cod testat
- Foarte bun suport pt testarea regresiva
- XP combina cu test acceptanta pt acoperirea tuturor efectelor testarii
Individual techniques
1) Testarea Functionala
Cazuri reprezentative:
- Foaie de calcul, testare fiecare element in izolare
- Baza de date, testare fiecare report in izolare
Puncte Forte
- Analiza aprofundata a fiecarui element testat

- Foarte usor de facut pe masura ce fiecare functie e implementata

Unghiuri moarte
- Lipseste interactiunea
- Lipseste explorarea beneficiilor oferite de program
2) Equivalence analysis
Cazuri reprezentative:
- Analiza echivalentei unui camp numeric simplu
- Testarea compatibilitatii Printer
Puncte Forte
- Gasirea celor mai probabile erori (la nivel inalt) folosind un set redus de teste
- Intuitiv o abordare curata, generalizare buna
Unghiuri moarte
- Erorile ce nu se gasesc la margini sau in cazuri evidente
- Seturi real de valori posibile e de multe ori imposibil de cunoscut.
3) Testarea bazata pe specificatii
Cazuri reprezentative:
- Matricea de Trasabilitate *, urmareste cazurile de testare asociate cu fiecare
element al specif
- Testare documentatie utilizator
Puncte Forte
- Aparare critica impotriva clauzelor de garantie, tarife fraude, lipsa credibilitatii in rel
cu clientii
- Util pentru gestionarea scopului/ asteptarilor unei testari conduse obisnuit.
- Reduce cost pentru suport sau plangerile clientilor prin asigurarea ca nu este
reprezentat fals sau induc in eroare consumatorii.
Unghiuri moarte
- Orice probleme ce nu sunt in specificatii sau au fost tratate gresit in
specificatii/documentatii.
*, Este un tabel pentru a arata ce variabile(functii/ item de specificare) sunt acoperati
de ce teste. Randurile sunt cazuri de testare. Celula arata ce caz de testare e aplicat pe
itemi.
4) Testarea bazata pe risc
Trei mari intelesuri:
- Gasire erori (risk-based approach to the technical tasks of testing)
- Gestiune process gasire erori (risk-based test management)
- Gestionarea proiectului de testare si de riscul prezentat de (si) testarea, n relatia sa cu
proiectul de ansamblu (bazate pe risc, management de proiect)
Cazuri reprezentative:
- Analiza clase de echivalenta , reformulata
- Testare in fct de frecventa utilizarii
- Testare stresat,testare de lucru cu erori, testare securitate
- Precizire lista bug
Puncte Forte

- Priotizare optimala
- Teste la putere maxima(de nivel inalt)
Unghiuri moarte
- Riscuri ne-identificate
- Anumiti testeri bazat pe risc(Categ) se pare ca opereaza subiectiv.
5)Testarea bazata pe stres
Cazuri reprezentative:
- Volum mare de date, conectare dispozitive, lant de tranzactii lungi
- Conditii de memorie mici, esec dispozitive, virusi, alte crize
- Incarcari extreme
Puncte Forte
- Expune punctele slabe ce vor aparea in domeniu
- Expune risc de securitate
Unghiuri moarte
- Slabiciuni ce nu rezulta (nu sunt vizibile) in urma testarii.
6) Testarea regresiva
Cazuri reprezentative:
- Regresie bug, regresie veci stabilite
- Regresie a GUI automata a suitelor de teste
Puncte Forte
- Ieftin de executat
- Testare config
Unghiuri moarte
- curba de imunizare
- Orice nu e acoperit in suita de regresie
- Costul de gestiune a suitei regresive
7) Testarea exploratorie
Cazuri reprezentative:
- Testare exploratorie cu indemanare a produsului final
- Testare rapida & testare de urgenta
- Troubleshooting/ urmarire testare defecte
Puncte Forte
- Bazata pe client, bazata pe risc
- In concordanta cu modficarile circumstantelor
- Gasire bug ce altfel sunt pierdute
Unghiuri moarte
- Cu cat stim mai putin, cu atat riscam sa pierdem
- Limitat de slabiciunile testorilor
- E pt avansati.
8) User Testing
Cazuri reprezentative
Beta testing

 Laborator intern folosind un exemplu stratificat de piata tinta

In-house lab using a stratified sample of target market
Usability testing
Strengths
Expune problema de proiectare
Gaseste zone cu rate mari de eroare
Pot fi monitorizate cu nregistratoare de zbor
pot fi folosite in testarile interne vazute pe zone
Blind spots
nu asigura acoperire
cazuri de testare slabe
La Beta test rezultatele tehnice sunt amestecate
Trebuie sa se distinga marketing betas de tehnical batas.
9) Scenario Testing
Representative cases
Utilizarea de cazuri, sau secvente cu asocieri de cazuri de utilizare.
Lauda produsul mpotriva regulilor de afaceri, date client
Hans Buwaldas soap opera testing.
Strengths
Evenimente complexe,realiste.Pot stapani(ajuta cu)situatiile care sunt prea
complexe pt model.
Expune esecurile care apar in timp
Blind spots
Esecurile functiilor simple pot face acest test ineficient
Trebuie gandit atent pt a realize o buna acoperire
10) Stochastic or Random Testing
The essence of this technique is that, while the strategy is designed by a
human; the individual test cases are generated by machine.
Curs 5 TDD
Test Driven Development
- Alerting a programmer about mistakes as soon as possible
- A programmer taking a TDD approach refuses to write a new function until there is
first a test that fails because that function isnt present
- If it's worth building, it's worth testing.
- If it's not worth testing, why are you wasting your time working on it?
- You communicate your intentions twice, stating the same idea in different ways: first
with a test, then with production code. When they match, its likely they were both
coded correctly. If they dont, theres a mistake somewhere.
- is a rapid cycle of testing, coding, and refactoring
Etape in TDD:
Step 1: Think of tests
Step 2: Write failing tests (Red stage)
Step 3: Writing production code (Green stage)

Step 4: Refactor
Step 5: Repeat the process