Mai devreme sau mai târziu, multe organizații care folosesc acest sau acel software ajung la nevoia de a organiza un proces de testare. Există, de obicei, mai multe motive, fie că acesta este un startup care necesită imediat testarea software-ului său, fie conducerea începe să înțeleagă că, pe lângă testarea afacerii, întreținerea, dezvoltarea și toți ceilalți care pot fi implicați în companie, specialiștii profesioniști în testare sunt încă mai este nevoie de cine va scuti pe toți ceilalți oameni, neavând o înțelegere normală a testării.Și din acest moment începe deseori numirea tradițională a unuia dintre actualii angajați în funcția de șef al departamentului de testare, tradițională pentru munca noastră. De exemplu, iată un câmp pentru tine, seamănă-l... Nu contează ce faci, dar departamentul trebuie să existe și trebuie să aducă rezultate. Desigur, totul nu este întotdeauna atât de rău; cineva mai caută specialiști în testare competenți pentru această poziție, dar cu toate acestea, încă nu există un proces de testare în această etapă și trebuie creat.

Și foarte des, mulți manageri încep să creeze un proces de testare nu sistematic, ci selectiv. Dar, în același timp, dacă organizați procesul de testare prin simpla alegere a celor mai bune practici, fără a avea o abordare sistematică, atunci un astfel de proces nu va aduce rezultate pozitive nici într-o lună, nici într-un an.

Cred că mulți oameni știu că, dacă procesul de testare nu este organizat corect de la bun început, atunci va fi extrem de dificil să îl schimbi mai târziu. Prin urmare, trebuie să determinați cum să organizați corect procesul de testare?

De unde să începeți organizarea procesului de testare?

Identific 11 criterii principale în organizarea procesului de testare:

1. Obiectivele și domeniul de aplicare al testării
2. Echipă
3. Control
4. Comunicare și interacțiune
5. Metodologia de testare
6. Documentația procesului
7. Managementul riscurilor
8. Măsurarea procesului
9. Instrumente
10. Medii de testare
11. Îmbunătățirea procesului

Îndeplinirea tuturor acestor criterii este cea care permite procesului de testare să se dezvolte uniform, ceea ce în scurt timp vă permite să atingeți un nivel în care procesul de testare va aduce rezultate pozitive.

Prin urmare, orice manager care se confruntă cu sarcina de a organiza procesul de testare ar trebui să pună următoarele întrebări:

• De ce avem nevoie de testare?
• Ce trebuie să facem teste?
• Ce procese trebuie formalizate sau create?
• Cum și ce ar trebui să testăm?

Abia după ce primim răspunsuri la aceste întrebări putem începe să trecem la standarde.

Subliniez următoarele standarde pe care chiar trebuie să le studiați înainte de a începe să construiți un proces:

• ISO 29119
• IEEE 829\1008
• TPI Next&TMap
• ISTQB

Desigur, este imposibil să se utilizeze complet practicile stabilite în standarde. Orice standard ar trebui să fie personalizat pentru a se potrivi nevoilor procesului dumneavoastră de testare specific, deoarece implementarea fără grija a practicilor standardelor poate duce la consecințe negative, deoarece procesul dumneavoastră de testare nu va îndeplini cerințele de afaceri.

Orice proces IT trebuie să răspundă întotdeauna nevoilor afacerii!

Vom analiza principalele criterii pentru construirea unui proces de testare.

Obiectivele și domeniul de aplicare al testării

Scopul testării este de a detecta defecte, de a verifica dacă software-ul îndeplinește cerințele menționate și de a oferi feedback despre defecte tuturor părților interesate.

Acesta este un obiectiv standard al procesului de testare, dar pot exista și obiective care sunt determinate de nevoile de afaceri ale organizației. De exemplu, este tipic pentru bănci ca diverse cerințe ale Băncii Centrale să fie implementate în timp util, prin urmare, pe lângă obiectivul general de testare, se adaugă și executarea la timp a testării cu calitatea necesară pentru sarcinile critice.

Vorbind despre zona de testare, trebuie să înțelegem perfect ce anume avem de testat. Acestea pot fi sisteme, componente, procese de afaceri. Pentru a înțelege acest lucru, trebuie doar să răspundeți la două întrebări:

• Ce ar trebui testat?
• Ce vom testa?

Adesea, ceea ce trebuie testat și ceea ce vom testa pot diferi foarte mult. Depinde de capacitățile procesului dvs. de testare. „Ce este necesar” este adesea dictat de afaceri și management, așa că un bun manager ar trebui să înțeleagă întotdeauna „ce este necesar” pentru a testa. După cum se spune: „Dacă urmăriți doi iepuri de câmp, nici nu veți prinde”, așa că este aici. Este întotdeauna mai bine să testați calitativ ceea ce puteți testa de fapt împreună cu echipa dvs. decât să vă apucați de tot ceea ce afacerea cere și să nu realizați nimic la timp și chiar să ratați defecte critice.

Echipa si management

Echipa este cea mai importantă componentă a procesului de testare. Fără echipă, tu, ca lider, nu vei face nimic. Există adesea mai multe abordări pentru formarea unei echipe:

Instrumente și infrastructură

Care este procesul de testare fără instrumente? Aceasta se dovedește a fi muncă manuală de dragul muncii manuale :) Cred că mulți dintre voi ați auzit adesea despre scrierea cazurilor de testare în documente Word, despre construirea de grafice și diagrame în Excel. Dar de ce să pierdem efortul dacă piața ne oferă produse de management al testelor gata făcute, precum HP ALM, MS TFS, TestRail, TestLink, JIRA Zephyr și multe altele.
Prin urmare, dacă ați început să organizați procesul de testare, atunci faceți acest proces convenabil și eficient. Scrieți cazuri de testare în forme convenabile de produse finite, integrați instrumente cu un sistem de management al sarcinilor, personalizați etc.

Atunci când alegeți un instrument, trebuie să înțelegeți întotdeauna:

• Ce sarcini intenționați să efectuați?
• Care este bugetul dvs. pentru instrumente?

După ce ați primit răspunsuri la aceste întrebări, veți putea să determinați instrumentele de testare care sunt cele mai convenabile pentru dvs. și poate să le dezvoltați pe ale dvs.

Pe lângă instrumentele de management de testare, instrumentele de testare includ și:

• Sistem de management al defectelor și sarcinilor (poate fi inclus în sistemul de management al testelor)
• Instrumente auxiliare (pentru capturi de ecran, luarea jurnalelor, lucrul cu baze de date, SOUP UI pentru XML etc.)
• Instrumente de automatizare ( , Selenium etc.)
• Sisteme de management al cunoștințelor (pe motorul wiki)

Acum să vorbim despre infrastructură. În contextul actual al poveștii mele, mă refer la medii de testare.

În aproape orice organizație, mai ales dacă organizația este mare și nu dezvoltă aplicații mobile pentru piața jocurilor, veți avea nevoie de un mediu de testare pentru testare. Capacitatea și volumul integrării sistemului în mediile de testare pot varia în funcție de volumul de testare.

Ca standard, identific următoarele tipuri de medii de testare:

• Mediu de dezvoltare (poate fi clasificat ca mediu de testare?, dar totuși)
• Mediu de testare a sistemului (unul sau mai multe sisteme pot fi implementate, componentă, nu necesită alimentare serioasă)
• Mediu de integrare (un mediu de integrare complet pentru testarea funcționalității proceselor de afaceri end-to-end)
• Mediu (principala cerință este ca puterea să corespundă circuitului de luptă)
• Mediu ProdLike/PreProd (mediu pentru depanarea unei build testate gata făcute, efectuarea testelor de instalare)

Capacitatea de a organiza un număr atât de mare de medii de testare vă permite să efectuați lucrări de testare suprapunându-le unele peste altele, crescând astfel numărul de modificări (lansări, sprinturi) care pot apărea în paralel, dar în diferite etape de testare.

Îmbunătățirea procesului

Foarte des spun fraza că „Orice proces, indiferent de ce, ar trebui întotdeauna îmbunătățit în mod constant”, la care aud foarte des „De ce, procesul nostru funcționează deja bine”.

Dar asta nu este adevărat. De ce trebuie să îmbunătățim constant procesul de testare:

1. Obiectivele de testare nu pot fi aceleași, ele se schimbă constant în funcție de nevoile afacerii, care sunt dictate de piață.

2. Sectorul IT este în continuă evoluție. Apar tehnologii și abordări noi, care ne permit întotdeauna să îmbunătățim procesul de testare.

După cum se spune, nu există limită pentru perfecțiune!

Ei bine, modul de îmbunătățire este ciclul Demming standard.

Planificat - Realizat - Analizat - Ajustat

Ei bine, în concluzie, voi spune că cel potrivit vă permite să creați în cel mai scurt timp posibil un proces de testare cu adevărat eficient, care să rezolve scopurile și obiectivele stabilite pentru acesta.

Testare

Testarea (test de engleză - test, verificare) este o metodă experimentală de psihodiagnostic utilizată în cercetarea sociologică empirică, precum și o metodă de măsurare și evaluare a diferitelor calități și stări psihologice ale unui individ.

Apariţia procedeelor ​​testologice s-a datorat nevoii de comparare (comparare, diferenţiere şi ierarhizare) a indivizilor după nivelul de dezvoltare sau gradul de exprimare a diverselor calităţi psihologice.

Fondatorii testării sunt F. Galton, C. Spearman, J. Cattell, A. Binet, T. Simon. Însuși termenul „test mental” a fost inventat de Cattell în 1890. Începutul dezvoltării testologiei moderne pentru utilizarea în masă a testelor în practică este asociat cu numele medicului francez Binet, care, în colaborare cu Simon, a dezvoltat un scara metrică a dezvoltării mentale, cunoscută sub numele de „testul Binet-Simon”.

Diseminarea largă, dezvoltarea și îmbunătățirea testelor a fost facilitată de o serie de avantaje pe care le oferă această metodă. Testele vă permit să evaluați o persoană în conformitate cu scopul declarat al studiului; oferă posibilitatea obținerii unei evaluări cantitative bazate pe cuantificarea parametrilor calitativi de personalitate și comoditatea prelucrării matematice; reprezintă o modalitate relativ rapidă de a evalua un număr mare de indivizi necunoscuți; contribuie la obiectivitatea aprecierilor care nu depind de atitudinile subiective ale celui care efectuează cercetarea; asigurarea comparabilității informațiilor obținute de diferiți cercetători pe diferite subiecte.

Testele necesită:

Formalizarea strictă a tuturor etapelor de testare,

Standardizarea sarcinilor și condițiilor de implementare a acestora,

Cuantificarea rezultatelor obtinute si structurarea acestora dupa un program dat,

Interpretarea rezultatelor pe baza unei distribuții obținute anterior pentru caracteristica studiată.

Fiecare test care îndeplinește criteriile de fiabilitate, pe lângă un set de sarcini, include următoarele componente:

1) instrucțiuni standard pentru subiect despre scopul și regulile de îndeplinire a sarcinilor,

2) cheie de scalare - corelarea itemilor de sarcină cu scalele de calități măsurate, indicând ce element de sarcină aparține cărei scară,

4) cheia de interpretare a indicelui rezultat, care reprezintă datele normative cu care se corelează rezultatul obţinut.

În mod tradițional, norma în testare a fost datele statistice medii obținute ca urmare a testării preliminare pe un anumit grup de persoane. Aici este necesar să se țină cont de faptul că interpretarea rezultatelor obținute poate fi transferată doar acelor grupuri de subiecți care, în caracteristicile lor socioculturale și demografice de bază, sunt similare cu cea de bază.

Pentru a depăși principalul dezavantaj al majorității testelor, sunt utilizate diferite tehnici:

1) creșterea eșantionului de bază pentru a crește reprezentativitatea acestuia într-un număr mai mare de parametri,

2) introducerea unor factori de corecție ținând cont de caracteristicile eșantionului,

3) introducerea în practica de testare a unei metode non-verbale de prezentare a materialului.

Testul constă din două părți:

a) material stimulativ (sarcină, instrucțiune sau întrebare)

b) instrucțiuni privind înregistrarea sau integrarea răspunsurilor primite.

Standardizarea situației, tipică pentru teste, le oferă acestora, spre deosebire de observarea „liberă” a comportamentului, o mai mare obiectivitate a rezultatelor.

Testele sunt clasificate în funcție de diferite criterii.

Pe baza tipului de trăsături de personalitate, acestea sunt împărțite în teste de realizare și de personalitate. Primele includ teste de inteligență, teste de performanță școlară, teste de creativitate, teste de aptitudini, teste senzoriale și motorii. Al doilea include teste pentru atitudini, interese, temperament, teste caracterologice, teste motivaționale. Cu toate acestea, nu toate testele (de exemplu, teste de dezvoltare, teste grafice) pot fi sortate în funcție de acest criteriu. În funcție de tipul de instrucțiuni și de metoda de aplicare, testele individuale și de grup diferă. În testarea de grup, un grup de subiecți este examinat simultan. Deși nu există limite de timp în testele de nivel, acestea sunt necesare în testele de viteză. În funcție de măsura în care subiectivitatea cercetătorului se manifestă ca urmare a testării, se disting teste obiective și subiective.

Cele mai multe teste de realizare și teste psihofiziologice sunt obiective, în timp ce testele proiective sunt subiective. Această împărțire coincide într-o anumită măsură cu împărțirea în teste directe și indirecte, care diferă în funcție de faptul că subiecții cunosc sau nu sensul și scopul testului.

Pentru testele proiective, o situație tipică este atunci când subiectul nu este informat despre scopul real al studiului. Când efectuați sarcini de testare proiectivă, nu există răspunsuri „corecte”. În funcție de reprezentarea componentei vorbirii în test, se disting teste verbale și nonverbale. Verbal, de exemplu, este un test de vocabular, non-verbal este un test care necesită anumite acțiuni ca răspuns.

După structura lor formală, testele diferă de cele simple, adică. elementare, al căror rezultat poate fi un singur răspuns, și teste complexe, constând din subteste separate, pentru fiecare dintre acestea trebuie acordat un punctaj. În acest caz, se pot calcula și estimări generale. Un set de mai multe teste individuale se numește baterie de testare, o reprezentare grafică a rezultatelor pentru fiecare subtest se numește profil de test. Testele includ adesea chestionare care satisfac o serie de cerințe aplicate de obicei unei anumite metode de colectare a informațiilor psihologice sau sociologice.

Recent, testele bazate pe criterii au devenit din ce în ce mai răspândite, permițând evaluarea subiectului de testare nu în comparație cu datele populației medii, ci în raport cu o normă predeterminată. Criteriul de evaluare în astfel de teste este gradul în care rezultatul testului unui individ se apropie de așa-numita „normă ideală”.

Dezvoltarea testului constă în patru etape.

În prima etapă, conceptul inițial este dezvoltat cu formularea principalelor puncte de testare sau a principalelor întrebări cu caracter preliminar;

În a doua etapă, elementele de testare preliminare sunt selectate cu selecția ulterioară și reducerea la forma finală și, în același timp, evaluarea este efectuată în funcție de criterii calitative de fiabilitate și validitate;

În a treia etapă, testul este retestat pe aceeași populație;

La a patra etapă este calibrat în raport cu vârsta, nivelul de educație și alte caracteristici ale populației.

În toate etapele dezvoltării testului, este necesar să se ia în considerare:

a) o proprietate diagnosticabilă a personalității (mărime, poziție, indicator) sau numai manifestările ei observabile (de exemplu, abilități, nivel de cunoștințe, temperament, interese, atitudini);

b) validarea metodei asociate, i.e. determinarea cât de bine măsoară proprietatea necesară;

c) dimensiunea eșantionului din populația pe care trebuie evaluată metoda;

d) material stimulativ (tablete, imagini, jucării, filme);

e) influența cercetătorului în procesul de instruire, stabilire a sarcinilor, explicare, răspuns la întrebări;

f) condiţiile situaţiei;

g) asemenea forme de comportament ale subiectului care indică proprietatea care se măsoară;

h) scalarea formelor relevante de comportament;

i) însumarea rezultatelor pentru itemi individuali măsurați în valori generale (de exemplu, însumarea răspunsurilor ca „Da”);

j) formularea rezultatelor într-o scală de rating standardizată.

Una dintre opțiunile de testare poate fi un chestionar, dar cu condiția ca acesta să îndeplinească cerințele pentru teste. Un chestionar este o colecție de întrebări care sunt selectate și aranjate unele în relație cu altele, în conformitate cu conținutul cerut. Chestionarele sunt folosite, de exemplu, în scopuri de psihodiagnostic, atunci când subiectului i se cere să-și autoevalueze comportamentul, obiceiurile, opiniile etc. În acest caz, subiectul, răspunzând la întrebări, își exprimă preferințele pozitive și negative. Cu ajutorul chestionarelor, puteți măsura evaluările subiecților asupra altor persoane. Sarcina acționează de obicei ca un răspuns direct la întrebări la care trebuie să se răspundă prin regret sau respingere. Oportunitățile de răspuns sunt oferite în majoritatea cazurilor și necesită doar un semn sub formă de cruce, cerc etc. Dezavantajul chestionarului este că subiectul poate simula sau disimula anumite trăsături de personalitate. Cercetătorul poate depăși acest neajuns (deși nu complet) prin întrebări de control, scale de control și scale de „minciună”. Chestionarele sunt folosite în primul rând pentru a diagnostica caracterul, a diagnostica personalitatea (de exemplu, extroversiune - introversie, interese, atitudini, motive).

Diagnosticul personalității este un set de metode care fac posibilă recunoașterea proprietăților sale non-intelectuale, care sunt de natura unor dispoziții relativ stabile. Pentru trăsături de personalitate precum extraversia - introversia, motivul dominant, inhibiția, excitabilitatea, rigiditatea, au fost dezvoltate o serie de metode de diagnostic (chestionare și teste proiective) cu ajutorul cărora puteți determina severitatea acestor proprietăți. La construirea unor astfel de metode, de regulă, se utilizează analiza factorială (G. Eysenck, J. Cattell, J. Guilford) și validarea constructivă.

În stadiul actual, sociologia aplicată utilizează cel mai adesea metode de testare împrumutate din psihologia socială legate de studiul trăsăturilor de personalitate. Apar teste special elaborate de sociologi. Aceste teste sunt adesea folosite în chestionarele sociologice.

Referinte:

1. Director social, Kiev, 1990.

2. Dicționar social, Minsk, 1991.

3.Fund of time and events in the social sfera, M: Nauka, 1989.

• Tutorial

O zi buna!

Vreau să adun toată cea mai necesară teorie despre testare, care este cerută în timpul interviurilor cu stagiarii, juniorii și puțin mijlocii. De fapt, am adunat deja destul de mult. Scopul acestei postări este de a adăuga în mod colectiv ceea ce a ratat și de a corecta/parafraza/adăugați/face Altceva cu ceea ce este deja acolo, astfel încât să devină bun și să puteți lua totul și să îl repetați înainte de următorul interviu, pentru orice eventualitate. . În general, colegi, întreb sub tăietură cine ar trebui să învețe ceva nou, cine să sistematizeze vechiul și cine să contribuie.

Rezultatul ar trebui să fie o fișă cuprinzătoare pe care trebuie să o recitiți în drum spre interviu.

Tot ce este enumerat mai jos nu a fost inventat de mine personal, ci a fost preluat din diverse surse, unde personal mi-a plăcut mai mult formularea și definiția. La sfârșit este o listă de surse.

Subiect: definirea testării, calitatea, verificarea/validarea, obiectivele, etapele, planul de testare, punctele planului de testare, designul testului, tehnicile de proiectare a testelor, matricea de trasabilitate, cazul testelor, lista de verificare, defect, eroare/defect/eșec, raport de eroare, gravitate vs prioritate, niveluri de testare, tipuri/tipuri, abordări ale testării de integrare, principii de testare, testare statică și dinamică, testare exploratorie/ad-hoc, cerințe, ciclu de viață al erorilor, etape de dezvoltare a software-ului, tabel de decizie, inginer qa/qc/test, schema de conectare.

Merge!

Testare software- verificarea corespondenței dintre comportamentul real și cel așteptat al programului, efectuată pe un set finit de teste selectate într-un anumit mod. Într-un sens mai larg, testarea este una dintre tehnicile de control al calității care include activitățile de planificare a muncii (Test Management), proiectare a testelor (Test Design), execuție a testelor (Test Execution) și analiza rezultatelor (Test Analysis).

Calitate software este un set de caracteristici ale software-ului legate de capacitatea acestuia de a satisface nevoile declarate și anticipate.

Verificare este procesul de evaluare a unui sistem sau a componentelor acestuia pentru a determina dacă rezultatele actualei etape de dezvoltare satisfac condițiile formate la începutul acestei etape. Acestea. dacă obiectivele, termenele limită și sarcinile noastre de dezvoltare a proiectelor definite la începutul fazei curente sunt îndeplinite.
Validare- aceasta este o determinare a dacă software-ul dezvoltat îndeplinește așteptările și nevoile utilizatorului și cerințele de sistem.
Puteți găsi și o altă interpretare:
Procesul de evaluare a conformității unui produs cu cerințele (specificațiile) explicite este verificarea, în timp ce, în același timp, evaluarea conformității produsului cu așteptările și cerințele utilizatorilor este validare. De asemenea, puteți găsi adesea următoarea definiție a acestor concepte:
Validare - „este aceasta specificația corectă?”.
Verificare - „este sistemul corect conform specificațiilor?”.

Obiectivele de testare
Creșteți probabilitatea ca aplicația destinată testării să funcționeze corect în toate circumstanțele.
Creșteți probabilitatea ca aplicația testată să îndeplinească toate cerințele descrise.
Furnizarea de informații actualizate despre starea curentă a produsului.

Etape de testare:
1. Analiză
2. Dezvoltarea unei strategii de testare
și planificarea procedurilor de control al calității
3. Lucrul cu cerințe
4. Crearea documentației de testare
5. Testarea prototipului
6. Testare de bază
7. Stabilizare
8. Funcționare

Planul de testare- acesta este un document care descrie întreaga sferă a muncii de testare, pornind de la o descriere a obiectului, strategiei, programului, criteriilor de începere și încheiere a testării, până la echipamentul necesar procesului, cunoștințe speciale, precum și evaluarea riscurilor cu opțiuni pentru rezolvarea acestora.
Răspunde la întrebare:
Ce ar trebui testat?
Ce vei testa?
Cum vei testa?
Cand vei testa?
Criterii pentru începerea testării.
Criterii de finalizare a testului.

Principalele puncte ale planului de testare
Standardul IEEE 829 enumeră punctele pe care un plan de testare ar trebui (poate) să includă:
a) identificatorul planului de testare;
b) Introducere;
c) itemi de testare;
d) Caracteristici de testat;
e) Caracteristici care nu trebuie testate;
f) Abordare;
g) Criterii de promovare/refuzare a articolului;
h) Criteriile de suspendare și cerințele de reluare;
i) livrabile de testare;
j) Sarcini de testare;
k) Nevoile de mediu;
l) Responsabilitati;
m) Nevoile de personal și formare;
n) Program;
o) Riscuri și neprevăzute;
p) Aprobari.

Design de testare- aceasta este etapa a procesului de testare a software-ului în care cazurile de testare (cazurile de testare) sunt proiectate și create în conformitate cu criteriile de calitate și obiectivele de testare definite anterior.
Roluri responsabile pentru proiectarea testelor:
Analist de testare - determină „CE să testeze?”
Designer de testare - determină „CUM se testează?”

Testarea tehnicilor de proiectare

Partiționare echivalentă (EP). De exemplu, dacă aveți un interval de valori valide de la 1 la 10, trebuie să alegeți o valoare corectă în interiorul intervalului, să spunem 5, și o valoare incorectă în afara intervalului, 0.

Analiza valorii limită (BVA). Dacă luăm exemplul de mai sus, vom selecta limitele minime și maxime (1 și 10) ca valori pentru testarea pozitivă și valori mai mari și mai mici decât limitele (0 și 11). Analiza valorii limită poate fi aplicată câmpurilor, înregistrărilor, fișierelor sau oricărui tip de entitate constrânsă.

Cauză/Efect - CE. Aceasta înseamnă, de regulă, introducerea de combinații de condiții (motive) pentru a obține un răspuns din partea sistemului (Efect). De exemplu, testați capacitatea de a adăuga un client utilizând un anumit afișaj. Pentru a face acest lucru, va trebui să introduceți mai multe câmpuri, cum ar fi „Nume”, „Adresă”, „Număr de telefon”, apoi faceți clic pe butonul „Adăugați” - acesta este „Motivul”. După ce faceți clic pe butonul „Adăugați”, sistemul adaugă clientul la baza de date și arată numărul său pe ecran - aceasta este „Investigație”.

Testare exhaustivă (ET)- acesta este un caz extrem. În cadrul acestei tehnici, ar trebui să testați toate combinațiile posibile de valori de intrare și, în principiu, aceasta ar trebui să găsească toate problemele. În practică, utilizarea acestei metode nu este posibilă din cauza numărului mare de valori de intrare.

Matrice de trasabilitate- Matricea de conformitate a cerințelor este un tabel bidimensional care conține corespondența dintre cerințele funcționale ale produsului și cazurile de testare pregătite. Titlurile coloanelor din tabel conțin cerințe, iar titlurile rândurilor conțin scenarii de testare. La intersecție există un semn care indică faptul că cerințele coloanei curente sunt acoperite de cazul de testare al rândului curent.
Matricea de conformitate cu cerințele este utilizată de inginerii QA pentru a valida acoperirea testelor de produs. MCT este o parte integrantă a planului de testare.

Caz de testare este un artefact care descrie un set de pași, condiții specifice și parametri necesari pentru a verifica implementarea funcției testate sau a părții sale.
Exemplu:
Acțiune Rezultat așteptat Rezultat test
(procesat/eșuat/blocat)
Deschideți pagina „login” Pagina de autentificare este deschisă

Fiecare caz de testare trebuie să aibă 3 părți:
Precondiții O listă de acțiuni care aduc sistemul într-o stare adecvată pentru testarea de bază. Sau o listă de condiții, a căror îndeplinire indică faptul că sistemul se află într-o stare adecvată pentru efectuarea testului principal.
Descrierea cazului de testare O listă de acțiuni care transferă sistemul dintr-o stare în alta pentru a obține un rezultat pe baza căruia se poate concluziona că implementarea îndeplinește cerințele
PostConditions Lista acțiunilor care transferă sistemul în starea inițială (starea înainte de testare - starea inițială)
Tipuri de cazuri de testare:
Cazurile de testare sunt împărțite în funcție de rezultatul așteptat în pozitive și negative:
Un caz de testare pozitiv folosește numai date corecte și verifică dacă aplicația a executat corect funcția apelată.
Un caz de testare negativ operează atât cu date corecte, cât și cu date incorecte (cel puțin 1 parametru incorect) și are ca scop verificarea situațiilor excepționale (validatori sunt declanșate), precum și verificarea faptului că funcția apelată de aplicație nu este executată atunci când validatorul este declanșat.

Lista de verificare este un document care descrie ceea ce trebuie testat. În același timp, lista de verificare poate avea niveluri complet diferite de detaliu. Cât de detaliată va fi lista de verificare depinde de cerințele de raportare, de nivelul de cunoaștere a angajaților despre produs și de complexitatea produsului.
De regulă, o listă de verificare conține doar acțiuni (pași), fără rezultatul așteptat. Lista de verificare este mai puțin formalizată decât scenariul de testare. Este adecvat să îl utilizați atunci când scripturile de testare sunt redundante. Listele de verificare sunt, de asemenea, asociate cu abordări flexibile ale testării.

Defect (aka bug)- aceasta este o discrepanță între rezultatul real al execuției programului și rezultatul așteptat. Defectele sunt descoperite în timpul etapei de testare a software-ului, când testerul compară rezultatele programului (componentă sau design) cu rezultatul așteptat descris în specificația cerințelor.

Eroare- eroare utilizator, adică încearcă să folosească programul într-un mod diferit.
Exemplu - introduce litere în câmpurile în care trebuie să introduceți numere (vârstă, cantitate de mărfuri etc.).
Un program de înaltă calitate asigură astfel de situații și afișează un mesaj de eroare cu o cruce roșie.
Bug (defect)- o eroare a programatorului (sau a designerului sau a oricui altcineva care ia parte la dezvoltare), adică atunci când ceva din program nu merge conform planului și programul scapă de sub control. De exemplu, atunci când intrarea utilizatorului nu este controlată în niciun fel, ca rezultat, datele incorecte provoacă blocări sau alte „bucurii” în funcționarea programului. Sau programul este construit intern în așa fel încât inițial să nu corespundă cu ceea ce se așteaptă de la el.
Eșec- o defecțiune (și nu neapărat hardware) în funcționarea unei componente, a unui întreg program sau a unui sistem. Adică există defecte care duc la defecțiuni (Un defect a provocat defecțiunea) și sunt cele care nu. Defecte ale UI, de exemplu. Dar o defecțiune hardware care nu are nimic de-a face cu software-ul este, de asemenea, un eșec.

Raport de eroare este un document care descrie situația sau succesiunea de acțiuni care au condus la funcționarea incorectă a obiectului de testare, indicând motivele și rezultatul așteptat.
Un capac
Scurtă descriere (Rezumat) O scurtă descriere a problemei, indicând în mod clar cauza și tipul situației de eroare.
Numele proiectului al proiectului testat
Componentă aplicație (componentă) Numele părții sau funcției produsului testat
Număr versiune Versiunea pe care a fost găsită eroarea
Severitatea Cel mai comun sistem cu cinci niveluri pentru gradarea severității unui defect este:
Blocant S1
S2 Critic
S3 major
S4 Minor
S5 Trivial
Prioritate Prioritatea defectului:
P1 ridicat
P2 Mediu
P3 scăzut
Stare Starea erorii. Depinde de procedura utilizată și de ciclul de viață al erorilor (flux de lucru și ciclu de viață al erorilor)

Autor (Autor) Creator de rapoarte de eroare
Assigned To Numele persoanei atribuite problemei.
Mediu inconjurator
OS / Service Pack etc. / Browser + versiune /... Informații despre mediul în care a fost găsit bug-ul: sistem de operare, service pack, pentru testare WEB - numele și versiunea browserului etc.
…
Descriere
Pași pentru a reproduce Pași prin care puteți reproduce cu ușurință situația care a dus la eroare.
Rezultat Actual Rezultatul obținut după parcurgerea pașilor de reproducere
Rezultat așteptat Rezultat corect așteptat
Suplimente
Atașament Un fișier jurnal, o captură de ecran sau orice alt document care poate ajuta la clarificarea cauzei erorii sau poate indica o modalitate de a rezolva problema.

Severitate vs Prioritate
Severitatea este un atribut care caracterizează impactul unui defect asupra performanței unei aplicații.
Prioritatea este un atribut care indică prioritatea îndeplinirii unei sarcini sau eliminării unui defect. Putem spune că acesta este un instrument de planificare a muncii managerului. Cu cât prioritatea este mai mare, cu atât defectul trebuie remediat mai rapid.
Severitatea este expusă de către tester
Prioritate - manager, lider de echipă sau client

Gradul de severitate a defectului (severitate)

Blocant S1
O eroare de blocare care face ca aplicația să fie inoperabilă, făcând imposibilă munca ulterioară cu sistemul testat sau cu funcțiile sale cheie. Rezolvarea problemei este necesară pentru funcționarea ulterioară a sistemului.

S2 Critic
O eroare critică, o defecțiune a logicii de afaceri cheie, o gaură în sistemul de securitate, o problemă care a dus la o blocare temporară a serverului sau a făcut ca o parte a sistemului să fie inoperabilă, fără posibilitatea de a rezolva problema folosind alte puncte de intrare. Rezolvarea problemei este necesară pentru continuarea lucrărilor cu funcțiile cheie ale sistemului testat.

S3 major
O eroare semnificativă, o parte a logicii principale de afaceri nu funcționează corect. Eroarea nu este critică sau este posibil să lucrați cu funcția testată folosind alte puncte de intrare.

S4 Minor
O eroare minoră care nu încalcă logica de afaceri a părții aplicației testate, o problemă evidentă a interfeței cu utilizatorul.

S5 Trivial
O eroare banala care nu afecteaza logica de afaceri a aplicatiei, o problema prost reproductibila care este greu de observat prin interfata cu utilizatorul, o problema cu biblioteci sau servicii terte, o problema care nu are nici un impact asupra calitatii generale a produsul.

Gradarea priorității defectelor (Prioritate)
P1 ridicat
Eroarea trebuie corectată cât mai repede posibil, deoarece... prezența sa este critică pentru proiect.
P2 Mediu
Eroarea trebuie corectată; prezența ei nu este critică, dar necesită o soluție obligatorie.
P3 scăzut
Eroarea trebuie corectată; prezența ei nu este critică și nu necesită o soluție urgentă.

Niveluri de testare

1. Testarea unitară
Testarea componentelor (unității) verifică funcționalitatea și caută defecte în părți ale aplicației care sunt accesibile și pot fi testate separat (module de program, obiecte, clase, funcții etc.).

2. Testarea integrării
Interacțiunea dintre componentele sistemului este verificată după testarea componentelor.

3. Testarea sistemului
Obiectivul principal al testării sistemului este de a verifica atât cerințele funcționale, cât și cele nefuncționale ale sistemului în ansamblu. Aceasta identifică defecte precum utilizarea incorectă a resurselor sistemului, combinații neintenționate de date la nivel de utilizator, incompatibilitate cu mediul, cazuri de utilizare neintenționată, funcționalitate lipsă sau incorectă, inconveniente de utilizare etc.

4. Testare operațională (Release Testing).
Chiar dacă un sistem îndeplinește toate cerințele, este important să se asigure că îndeplinește nevoile utilizatorului și își îndeplinește rolul în mediul său de operare, așa cum este definit în modelul de afaceri al sistemului. Trebuie avut în vedere faptul că modelul de afaceri poate conține erori. Acesta este motivul pentru care este atât de important să se efectueze teste operaționale ca pas final de validare. În plus, testarea în mediul de operare ne permite să identificăm probleme nefuncționale, precum: conflicte cu alte sisteme legate de zona de business sau în medii software și electronice; performanță insuficientă a sistemului în mediul de operare etc. Evident, găsirea unor astfel de lucruri în etapa de implementare este o problemă critică și costisitoare. De aceea este atât de important să se efectueze nu numai verificarea, ci și validarea, încă din primele etape de dezvoltare a software-ului.

5. Testarea de acceptare
Un proces formal de testare care verifică dacă un sistem îndeplinește cerințele și este realizat pentru:
determinarea dacă sistemul îndeplinește criteriile de acceptare;
luarea unei decizii de către client sau altă persoană autorizată dacă cererea este acceptată sau nu.

Tipuri/tipuri de testare

Tipuri funcționale de testare
Testare funcțională
Testarea securității și controlului accesului
Testare de interoperabilitate

Tipuri nefuncționale de testare
Toate tipurile de teste de performanță:
o testare de sarcină (testare de performanță și de încărcare)
o Testarea de stres
o Testare de stabilitate/fiabilitate
o Testarea volumului
Testarea instalării
Testare de utilizare
Testare de failover și recuperare
Testarea configurației

Tipuri de testare legate de schimbare
Testarea fumului
Testarea regresiei
Re-testare
Test de verificare a construcției
Testare de sănătate

Testare funcțională ia în considerare comportamentul prestabilit și se bazează pe o analiză a specificațiilor funcționalității componentei sau a sistemului în ansamblu.

Testare de securitate este o strategie de testare folosită pentru a verifica securitatea sistemului, precum și pentru a analiza riscurile asociate cu oferirea unei abordări holistice pentru protejarea aplicației, atacuri ale hackerilor, viruși, acces neautorizat la date confidențiale.

Testare de interoperabilitate este testarea funcțională care testează capacitatea unei aplicații de a interacționa cu una sau mai multe componente sau sisteme și include testarea de compatibilitate și testarea integrării

Testare stresanta- aceasta este o testare automată care simulează munca unui anumit număr de utilizatori de afaceri pe o resursă comună (partajată).

Testare stresanta vă permite să verificați cât de eficiente sunt solicitate aplicația și sistemul în ansamblu și, de asemenea, să evaluați capacitatea sistemului de a se regenera, de ex. pentru a reveni la normal după încetarea stresului. Stresul în acest context poate fi o creștere a intensității operațiunilor la valori foarte mari sau o schimbare de urgență a configurației serverului. De asemenea, una dintre sarcinile testării de stres poate fi evaluarea degradării performanței, astfel încât obiectivele testării de stres se pot suprapune cu obiectivele testării performanței.

Testarea volumului. Scopul testării volumului este de a obține o evaluare a performanței pe măsură ce volumul de date din baza de date a aplicației crește

Testare de stabilitate / fiabilitate. Sarcina testării stabilității (fiabilității) este de a verifica funcționalitatea aplicației în timpul testării pe termen lung (multe ore) cu un nivel mediu de încărcare.

Testarea instalației menită să verifice instalarea și configurarea reușite, precum și actualizarea sau dezinstalarea software-ului.

Testare de utilizare este o metodă de testare care vizează stabilirea gradului de utilizare, învățare, înțelegere și atractivitate pentru utilizatori a produsului care se dezvoltă în contextul unor condiții date. Aceasta include, de asemenea:
Testarea UI este un tip de testare de cercetare efectuată pentru a determina dacă un obiect artificial (cum ar fi o pagină web, o interfață de utilizator sau un dispozitiv) este potrivit pentru utilizarea prevăzută.
User eXperience (UX) este sentimentul experimentat de utilizator în timpul utilizării unui produs digital, în timp ce interfața utilizator este un instrument care permite interacțiunea utilizator-resurse web.

Testare de failover și recuperare testează produsul supus testării în ceea ce privește capacitatea sa de a rezista și de a se recupera cu succes în urma posibilelor defecțiuni rezultate din erori software, defecțiuni hardware sau probleme de comunicații (de exemplu, defecțiunea rețelei). Scopul acestui tip de testare este testarea sistemelor de recuperare (sau a sistemelor care dublează funcționalitatea principală), care, în cazul unor defecțiuni, vor asigura siguranța și integritatea datelor produsului testat.

Testarea configurației- un tip special de testare care vizează verificarea funcționării software-ului în diferite configurații de sistem (platforme declarate, drivere acceptate, diferite configurații de computer etc.)

Fum testarea este considerată ca un scurt ciclu de teste efectuate pentru a confirma că după construirea codului (nou sau fix), aplicația instalată pornește și îndeplinește funcțiile de bază.

Testare de regresie este un tip de testare care vizează verificarea modificărilor aduse unei aplicații sau unui mediu (remedierea unui defect, fuzionarea unui cod, migrarea către alt sistem de operare, bază de date, server web sau server de aplicații), pentru a confirma faptul că funcționalitatea preexistentă funcționează conform intenției inainte de. Testele de regresie pot fi atât teste funcționale, cât și nefuncționale.

Retestare- testarea, în timpul căreia sunt executate scripturi de testare care au identificat erori în timpul ultimei rulări pentru a confirma succesul corectării acestor erori.
Care este diferența dintre testarea de regresie și re-testarea?
Re-testare - remedierea erorilor este verificată
Testare de regresie - verifică dacă remedierea erorilor nu a afectat alte module software și nu a cauzat erori noi.

Testare de asamblare sau Test de verificare a construcției- testare care vizează determinarea conformității versiunii lansate cu criteriile de calitate pentru a începe testarea. În ceea ce privește obiectivele sale, este analog cu Smoke Testing, care vizează acceptarea unei noi versiuni pentru testare sau operare ulterioară. Poate pătrunde mai adânc, în funcție de cerințele de calitate ale versiunii lansate.

Teste sanitare- aceasta este o testare limitată suficientă pentru a demonstra că o anumită funcție funcționează conform cerințelor menționate în caietul de sarcini. Este un subset al testelor de regresie. Folosit pentru a determina performanța unei anumite părți a aplicației după modificările aduse acesteia sau mediului. De obicei, se face manual.

Error Guessing - EG. Acesta este momentul în care analistul de testare își folosește cunoștințele despre sistem și capacitatea de a interpreta specificația pentru a „preva” în ce condiții de intrare ar putea eșua sistemul. De exemplu, specificația spune „utilizatorul trebuie să introducă un cod”. Analistul de testare se va gândi: „Dacă nu introduc codul?”, „Dacă introduc codul greșit? ", și așa mai departe. Aceasta este predicția erorii.

Abordări de testare a integrării:

Integrare de jos în sus
Toate modulele, procedurile sau funcțiile de nivel inferior sunt colectate împreună și apoi testate. După care următorul nivel de module este asamblat pentru testarea integrării. Această abordare este considerată utilă dacă toate sau aproape toate modulele nivelului în curs de dezvoltare sunt pregătite. Această abordare ajută, de asemenea, la determinarea nivelului de pregătire a aplicației pe baza rezultatelor testării.

Integrare de sus în jos
În primul rând, toate modulele de nivel înalt sunt testate și, treptat, cele de nivel scăzut sunt adăugate unul câte unul. Toate modulele de nivel inferior sunt simulate ca stub-uri cu funcționalitate similară, apoi, când sunt gata, sunt înlocuite cu componente active reale. În acest fel testăm de sus în jos.

Big Bang (integrarea „Big Bang”)
Toate sau aproape toate modulele dezvoltate sunt asamblate împreună ca un sistem complet sau parte principală, apoi se efectuează testarea de integrare. Această abordare este foarte bună pentru a economisi timp. Cu toate acestea, dacă cazurile de testare și rezultatele lor nu sunt înregistrate corect, atunci procesul de integrare în sine va fi foarte complicat, ceea ce va deveni un obstacol pentru echipa de testare în atingerea obiectivului principal de testare a integrării.

Principii de testare

Principiul 1- Testarea arată prezența defectelor
Testarea poate arăta că există defecte, dar nu poate dovedi că acestea nu sunt prezente. Testarea reduce probabilitatea apariției defectelor în software, dar chiar dacă nu sunt găsite defecte, acest lucru nu dovedește corectitudinea acestuia.

Principiul 2- Testarea exhaustivă este imposibilă
Testarea completă folosind toate combinațiile de intrări și condiții preliminare este imposibil din punct de vedere fizic, cu excepția cazurilor triviale. În loc de testare exhaustivă, analiza riscurilor și prioritizarea ar trebui utilizate pentru a concentra mai bine eforturile de testare.

Principiul 3- Testare timpurie
Pentru a găsi defectele cât mai devreme posibil, activitățile de testare ar trebui să înceapă cât mai devreme posibil în ciclul de viață al dezvoltării software sau a sistemului și ar trebui să se concentreze pe obiective specifice.

Principiul 4- Gruparea defectelor
Eforturile de testare ar trebui concentrate proporțional cu densitatea defectelor de modul așteptată și mai târziu cu cea reală. De regulă, majoritatea defectelor descoperite în timpul testării sau care au cauzat majoritatea defecțiunilor sistemului sunt conținute într-un număr mic de module.

Principiul 5- Paradoxul pesticidelor
Dacă aceleași teste sunt executate din nou și din nou, în cele din urmă acest set de cazuri de testare nu va mai găsi noi defecte. Pentru a depăși acest „paradox al pesticidelor”, cazurile de testare trebuie să fie revizuite și revizuite în mod regulat, iar noile teste trebuie să fie cuprinzătoare pentru a acoperi toate componentele software-ului sau a sistemului și pentru a găsi cât mai multe defecte posibil.

Principiul 6- Testarea depinde de concept
Testarea se face diferit în funcție de context. De exemplu, software-ul critic pentru securitate este testat diferit de un site de comerț electronic.

Principiul 7- Eșecul absenței erorilor
Găsirea și remedierea defectelor nu va ajuta dacă sistemul creat nu se potrivește utilizatorului și nu corespunde așteptărilor și nevoilor acestuia.

Testare statică și dinamică
Testarea statică diferă de testarea dinamică prin faptul că este efectuată fără a rula codul produsului. Testarea se realizează prin analiza codului programului (revizuirea codului) sau codul compilat. Analiza se poate face fie manual, fie folosind instrumente speciale. Scopul analizei este de a identifica din timp erorile și potențialele probleme ale produsului. Testarea statică include, de asemenea, specificațiile de testare și altă documentație.

Testare exploratorie/ad-hoc
Cea mai simplă definiție a testării exploratorii este proiectarea și executarea testelor în același timp. Care este opusul abordării scenariului (cu procedurile sale de testare predefinite, fie că sunt manuale sau automate). Testele exploratorii, spre deosebire de testele de scenariu, nu sunt predeterminate și nu sunt executate exact așa cum a fost planificat.

Diferența dintre testarea ad-hoc și cea exploratorie este că, teoretic, testarea ad-hoc poate fi efectuată de oricine, în timp ce testarea exploratorie necesită abilități și cunoaștere a anumitor tehnici. Vă rugăm să rețineți că anumite tehnici nu sunt doar tehnici de testare.

Cerințe este o specificație (descriere) a ceea ce ar trebui implementat.
Cerințele descriu ceea ce trebuie implementat, fără a detalia partea tehnică a soluției. Ce, nu cum.

Cerințe Cerințe:
Corectitudine
Neambiguitate
Completitudinea setului de cerințe
Consecvența unui set de cerințe
Verificabilitate (testabilitate)
Trasabilitate
Intelegere

Ciclul de viață al bug-ului

Etape de dezvoltare software- acestea sunt etapele prin care parcurg echipele de dezvoltare software înainte ca programul să devină disponibil pentru o gamă largă de utilizatori. Dezvoltarea software începe cu etapa inițială de dezvoltare (etapa pre-alfa) și continuă cu etape în care produsul este rafinat și modernizat. Etapa finală a acestui proces este lansarea pe piață a versiunii finale a software-ului („versiunea generală disponibilă”).

Produsul software parcurge următoarele etape:
analiza cerințelor proiectului;
proiecta;
implementare;
testarea produselor;
implementare și sprijin.

Fiecărei etape de dezvoltare software i se atribuie un număr de serie specific. De asemenea, fiecare etapă are propriul nume, care caracterizează gradul de pregătire a produsului în această etapă.

Ciclul de viață al dezvoltării software:
Pre-alfa
Alfa
Beta
Eliberarea candidatului
Eliberare
Post lansare

Tabel de decizie- un instrument excelent pentru organizarea cerințelor complexe de afaceri care trebuie implementate într-un produs. Tabelele de decizie prezintă un set de condiții, a căror îndeplinire simultană ar trebui să conducă la o anumită acțiune.

QA/QC/Inginer de testare


Astfel, putem construi un model al ierarhiei proceselor de asigurare a calității: Testarea face parte din QC. QC face parte din QA.

Schema de conectare este un instrument de management al calității bazat pe identificarea relațiilor logice dintre diverse date. Acest instrument este folosit pentru a compara cauzele și efectele problemei studiate.

Testarea software-ului identifică defecte, defecte și erori ale codului care trebuie eliminate. Poate fi definit și ca procesul de evaluare a funcționalității și corectitudinii software-ului prin analiză. Principalele metode de integrare și testare a produselor software asigură calitatea aplicațiilor și constau în verificarea specificației, proiectării și codului, aprecierea fiabilității, validarea și verificarea.

Metode

Scopul principal al testării software este de a confirma calitatea unui pachet software prin depanarea sistematică a aplicațiilor în condiții atent controlate, determinând caracterul complet și corectitudinea acestora, precum și detectarea erorilor ascunse.

Metodele pot fi împărțite în statice și dinamice.

Primele includ revizuirea informală, de control și tehnică, inspecție, detaliu, audit și analiza statică a fluxului și controlului de date.

Tehnicile dinamice sunt după cum urmează:

1. Testarea cutiei albe. Acesta este un studiu detaliat al logicii interne și al structurii unui program. Acest lucru necesită cunoașterea codului sursă.
2. Testarea cutiei negre. Această tehnică nu necesită cunoștințe despre funcționarea internă a aplicației. Sunt luate în considerare doar principalele aspecte ale sistemului care nu sunt legate sau au puțină legătură cu structura sa logică internă.
3. Metoda casetei gri. Combină cele două abordări anterioare. Depanarea cu cunoștințe limitate despre funcționarea internă a aplicației este combinată cu cunoașterea aspectelor de bază ale sistemului.

Testare transparentă

Metoda casetei albe folosește scripturi de testare pentru a controla structura unui design procedural. Această tehnică vă permite să identificați erorile de implementare, cum ar fi gestionarea defectuoasă a codului, prin analizarea funcționării interne a unei piese de software. Aceste metode de testare sunt aplicabile la nivel de integrare, modul și sistem. Testerul trebuie să aibă acces la codul sursă și, folosindu-l, să descopere care bloc se comportă inadecvat.

Testarea cutie albă a programelor are următoarele avantaje:

• vă permite să identificați erorile în codul ascuns atunci când eliminați linii suplimentare;
• posibilitatea de efecte secundare;
• acoperirea maximă se realizează prin scrierea unui script de testare.

Defecte:

• un proces extrem de costisitor care necesită un depanator calificat;
• multe căi vor rămâne neexplorate, deoarece o verificare amănunțită a tuturor erorilor posibile ascunse este foarte dificilă;
• o parte din codurile lipsă vor trece neobservate.

Testarea cutie albă este uneori numită și testare transparentă sau deschisă, testare structurală, testare logică, testare sursă, testare arhitectură și testare logică.

Principalele soiuri:

1) testarea controlului fluxului - o strategie structurată care utilizează ca model fluxul de control al programului și favorizează un număr mai mare de căi simple față de un număr mai mic de căi mai complexe;

2) depanarea de ramuri are ca scop examinarea fiecărei opțiuni (adevărată sau falsă) a fiecărei declarații de control, care include și decizia combinată;

3) testarea căilor de bază, care permite testatorului să stabilească o măsură a complexității logice a unui proiect procedural pentru a identifica un set de bază de căi de execuție;

4) verificarea fluxului de date - o strategie de examinare a fluxului de control prin adnotarea graficului cu informații despre declararea și utilizarea variabilelor programului;

5) testarea ciclului - complet concentrată pe executarea corectă a procedurilor ciclice.

Depanare comportamentală

Testarea cutiei negre tratează software-ul ca pe o „cutie neagră” - informațiile despre funcționarea internă a programului nu sunt luate în considerare și sunt testate doar aspectele principale ale sistemului. În acest caz, testerul trebuie să cunoască arhitectura sistemului fără acces la codul sursă.

Avantajele acestei abordări:

• eficienta pentru un segment mare de cod;
• ușurința de percepție de către testator;
• Perspectiva utilizatorului este clar separată de perspectiva dezvoltatorului (programatorul și testerul sunt independente unul de celălalt);
• crearea mai rapidă a testelor.

Testarea programelor folosind metode cutie neagră are următoarele dezavantaje:

• în realitate, se execută un număr selectat de cazuri de testare, rezultând o acoperire limitată;
• lipsa unei specificații clare face dificilă dezvoltarea cazurilor de testare;
• eficienta scazuta.

Alte nume pentru această tehnică sunt testarea comportamentală, testarea opace, testarea funcțională și depanarea cu casete închise.

1) partiționare echivalentă, care poate reduce setul de date de testare, deoarece datele de intrare ale modulului software sunt împărțite în părți separate;

2) analiza marginilor se concentrează pe testarea limitelor sau a valorilor limită extreme - minime, maxime, erori și valori tipice;

3) fuzzing - folosit pentru a căuta erori de implementare prin introducerea datelor distorsionate sau semidistorsionate în mod automat sau semi-automat;

4) grafice ale relațiilor cauză-efect - tehnică bazată pe crearea de grafice și stabilirea unei legături între o acțiune și cauzele acesteia: identitate, negație, SAU logic și ȘI logic - patru simboluri de bază care exprimă interdependența dintre cauză și efect;

5) testarea rețelelor ortogonale, aplicată la probleme cu o zonă de intrare relativ mică, care depășește capacitățile unui studiu exhaustiv;

6) testarea tuturor perechilor - o tehnică al cărei set de valori de testare include toate combinațiile discrete posibile ale fiecărei perechi de parametri de intrare;

Testarea cutiei negre: exemple

Tehnica se bazează pe specificații, documentație și descrieri ale interfeței software sau a sistemului. În plus, este posibil să se utilizeze modele (formale sau informale) care reprezintă comportamentul așteptat al software-ului.

Această metodă de depanare este utilizată de obicei pentru interfețele utilizator și necesită interacțiunea cu aplicația prin introducerea datelor și colectarea rezultatelor - de pe ecran, din rapoarte sau printuri.

Testerul interacționează astfel cu software-ul prin intrare, comutatoare de operare, butoane sau alte interfețe. Alegerea datelor de intrare, ordinea în care sunt introduse sau succesiunea acțiunilor pot duce la un număr total gigantic de combinații, așa cum se poate observa în exemplul următor.

Câte teste trebuie efectuate pentru a verifica toate valorile posibile pentru 4 casete de selectare și un câmp cu două poziții care specifică timpul în secunde? La prima vedere, calculul este simplu: 4 câmpuri cu două stări posibile - 24 = 16, care trebuie înmulțite cu numărul de poziții posibile de la 00 la 99, adică 1600 de teste posibile.

Totuși, acest calcul este greșit: putem defini că un câmp cu două poziții poate conține și un spațiu, adică este format din două poziții alfanumerice și poate include caractere alfabetice, caractere speciale, spații etc. Astfel, dacă sistemul este un 16 -biți, există 216 = 65.536 opțiuni pentru fiecare poziție, rezultând 4.294.967.296 cazuri de testare, care trebuie înmulțite cu 16 combinații pentru steaguri, dând un total de 68.719.476.736.la o rată de 1 test pe secundă, durata totală a testării va fi de 2.177,5 ani. Pentru sistemele pe 32 sau 64 de biți, durata este și mai mare.

Prin urmare, este necesar să se reducă această perioadă la o valoare acceptabilă. Astfel, trebuie aplicate tehnici pentru a reduce numărul de cazuri de testare fără a reduce acoperirea testării.

Partiție echivalentă

Partiționarea echivalentă este o tehnică simplă aplicabilă oricărei variabile prezente în software, fie că este vorba de valori de intrare sau de ieșire, simbolice, numerice etc. Se bazează pe principiul că toate datele din aceeași partiție echivalentă vor fi procesate în același mod și prin aceleași instrucțiuni.

În timpul testării, un reprezentant este selectat din fiecare partiție echivalentă definită. Acest lucru vă permite să reduceți în mod sistematic numărul de cazuri de testare posibile fără a pierde acoperirea comenzii și a caracteristicilor.

O altă consecință a acestei partiționări este reducerea exploziei combinatorii între diferite variabile și reducerea asociată a cazurilor de testare.

De exemplu, în (1/x)1/2 sunt utilizate trei secvențe de date, trei partiții echivalente:

1. Toate numerele pozitive vor fi procesate în același mod și ar trebui să producă rezultate corecte.

2. Toate numerele negative vor fi procesate în același mod, cu același rezultat. Acest lucru este incorect deoarece rădăcina unui număr negativ este imaginară.

3. Zero va fi procesat separat și va da o eroare de împărțire la zero. Aceasta este o secțiune cu un singur sens.

Deci vedem trei secțiuni diferite, dintre care una se rezumă la un singur sens. Există o secțiune „corectă”, care oferă rezultate fiabile, și două „greșite”, cu rezultate incorecte.

Analiza regională

Procesarea datelor la granițele partițiilor echivalente poate fi efectuată diferit decât era de așteptat. Studiile de valoare limită sunt o modalitate binecunoscută de a analiza comportamentul software-ului în astfel de domenii. Această tehnică vă permite să identificați următoarele erori:

• utilizarea incorectă a operatorilor relaționali (<,>, =, ≠, ≥, ≤);
• erori singulare;
• probleme cu bucle și iterații,
• tipuri sau dimensiuni incorecte ale variabilelor utilizate pentru stocarea informațiilor;
• restricții artificiale asociate cu tipuri de date și variabile.

Testare translucide

Metoda casetei gri mărește acoperirea auditului, permițându-vă să vă concentrați pe toate nivelurile unui sistem complex prin combinarea metodelor casetei albe și negre.

Atunci când folosește această tehnică, testerul trebuie să cunoască structurile interne de date și algoritmii pentru a dezvolta valorile de testare. Exemple de tehnici de testare a casetei gri sunt:

• model arhitectural;
• Limbajul de modelare unificat (UML);
• model de stare (mașină cu stări finite).

În metoda casetei gri, codurile modulelor sunt studiate folosind tehnica albă pentru a dezvolta cazuri de testare, iar testarea propriu-zisă se realizează pe interfețele programului folosind tehnica neagră.

Astfel de metode de testare au următoarele avantaje:

• combinarea avantajelor tehnicilor cutiei albe și negre;
• testerul se bazează mai degrabă pe interfață și pe specificațiile funcționale decât pe codul sursă;
• depanatorul poate crea scripturi de testare excelente;
• verificarea se realizează din punctul de vedere al utilizatorului, nu al designerului de program;
• crearea de teste personalizate;
• obiectivitate.

Defecte:

• acoperirea testului este limitată din cauza lipsei de acces la codul sursă;
• dificultate la detectarea defectelor în aplicațiile distribuite;
• multe căi rămân neexplorate;
• dacă dezvoltatorul de software a rulat deja testul, atunci investigațiile suplimentare pot fi redundante.

Un alt nume pentru tehnica cutiei gri este depanarea translucidă.

1) matrice ortogonală - folosind un submult al tuturor combinațiilor posibile;

2) depanarea matricei folosind datele de stare a programului;

3) efectuate atunci când se fac noi modificări la software;

4) un test șablon care analizează designul și arhitectura unei aplicații bune.

testarea software-ului

Utilizarea tuturor metodelor dinamice duce la o explozie combinatorie a numărului de teste care trebuie proiectate, implementate și efectuate. Fiecare tehnică trebuie utilizată pragmatic, ținând cont de limitările sale.

Nu există o singură metodă corectă, ci doar cele care se potrivesc mai bine unui anumit context. Tehnicile structurale pot găsi cod inutil sau rău intenționat, dar sunt complexe și nu se aplică programelor mari. Metodele bazate pe specificații sunt singurele care sunt capabile să identifice codul lipsă, dar nu pot identifica valori aberante. Unele tehnici sunt mai potrivite pentru un anumit nivel de testare, tip de eroare sau context decât altele.

Mai jos sunt principalele diferențe dintre cele trei tehnici de testare dinamică - este dat un tabel de comparație între cele trei forme de depanare software.

Automatizare

Metodele automate de testare a software-ului simplifică foarte mult procesul de verificare, indiferent de mediul tehnic sau contextul software. Sunt utilizate în două cazuri:

1) să automatizeze sarcini plictisitoare, repetitive sau meticuloase, cum ar fi compararea fișierelor de câteva mii de linii, pentru a elibera timpul testerului pentru a se concentra pe puncte mai importante;

2) pentru a efectua sau urmări sarcini care nu pot fi îndeplinite cu ușurință de către oameni, cum ar fi testarea performanței sau analiza timpului de răspuns, care poate fi măsurată în sutimi de secundă.

Instrumentele de testare pot fi clasificate în diferite moduri. Următoarea diviziune se bazează pe sarcinile pe care le suportă:

• managementul testelor, care include suport pentru managementul proiectelor, managementul versiunilor, managementul configurației, analiza riscurilor, urmărirea testelor, erori, defecte și instrumente de raportare;
• managementul cerințelor, care include stocarea cerințelor și specificațiilor, verificarea completității și ambiguității acestora, prioritatea lor și trasabilitatea fiecărui test;
• revizuire critică și analiză statică, inclusiv monitorizarea fluxului și sarcinilor, înregistrarea și stocarea comentariilor, detectarea defectelor și corecțiile planificate, gestionarea referințelor la liste de verificare și reguli, urmărirea relației dintre documentele sursă și codul, analiza statică cu detectarea defectelor, asigurarea conformității cu standardele de codare , analiza structurilor și dependențele acestora, calculul parametrilor metrici ai codului și arhitecturii. În plus, se folosesc compilatoare, analizoare de legături și generatoare de referințe încrucișate;
• modelare, care include instrumente pentru modelarea comportamentului de afaceri și testarea modelelor create;
• dezvoltarea testelor asigură generarea datelor așteptate pe baza condițiilor și interfeței cu utilizatorul, modelelor și codului, gestionarea acestora pentru a crea sau modifica fișiere și baze de date, mesaje, verificarea datelor pe baza regulilor de management, analiza statisticilor condițiilor și riscurilor;
• revizuire critică prin introducerea datelor prin GUI, API, linii de comandă folosind comparatoare pentru a ajuta la identificarea testelor reușite și nereușite;
• suport pentru medii de depanare care vă permit să înlocuiți hardware-ul sau software-ul lipsă, inclusiv simulatoare hardware bazate pe un subset de ieșiri deterministe, emulatori de terminale, telefoane mobile sau echipamente de rețea, medii pentru testarea limbilor, a sistemului de operare și a hardware-ului prin înlocuirea componentelor lipsă cu module de drivere false , etc., precum și instrumente pentru interceptarea și modificarea solicitărilor OS, simularea limitărilor CPU, RAM, ROM sau rețelei;
• compararea fișierelor de date, baze de date, verificarea rezultatelor așteptate în timpul și după testare, inclusiv compararea dinamică și pe lot, „oracole” automate;
• măsurarea acoperirii pentru a localiza pierderile de memorie și gestionarea incorectă a memoriei, a evalua comportamentul sistemului în condiții de încărcare simulată, a genera încărcări de aplicații, baze de date, rețea sau server în scenarii realiste ale creșterii acesteia, pentru a măsura, analiza, verifica și raporta resursele sistemului;
• Securitate;
• testarea performanței, testarea sarcinii și analiza dinamică;
• alte instrumente, inclusiv pentru verificarea ortografiei și a sintaxei, securitatea rețelei, disponibilitatea tuturor paginilor site-ului etc.

Perspectivă

Pe măsură ce tendințele din industria software-ului se schimbă, procesul de depanare este, de asemenea, supus schimbării. Noile metode existente de testare a software-ului, cum ar fi arhitectura orientată pe servicii (SOA), tehnologiile fără fir, serviciile mobile etc. au deschis noi căi de testare a software-ului. Unele dintre schimbările așteptate în această industrie în următorii câțiva ani sunt enumerate mai jos:

• testerii vor oferi modele ușoare cu care dezvoltatorii își pot verifica codul;
• dezvoltarea unor metode de testare care includ vizualizarea și simularea programelor într-un stadiu incipient va elimina multe inconsecvențe;
• prezența multor interceptări de testare va reduce timpul de detectare a erorilor;
• analizatorul static și instrumentele de detectare vor fi utilizate mai pe scară largă;
• aplicarea de matrice utile, cum ar fi acoperirea specificațiilor, acoperirea modelului și acoperirea codului va ghida dezvoltarea proiectului;
• instrumentele combinatorii vor permite testerilor să determine zonele prioritare pentru depanare;
• testerii vor oferi servicii mai vizibile și mai valoroase pe tot parcursul procesului de dezvoltare a software-ului;
• Depanatorii vor putea crea instrumente și metode de testare software scrise și interoperabile cu diverse limbaje de programare;
• Specialiștii în depanare vor deveni mai pregătiți profesional.

Noi metode de testare a programelor orientate spre afaceri vor veni să le înlocuiască, schimbând modul în care interacționăm cu sistemele și informațiile pe care acestea le furnizează, reducând în același timp riscurile și sporind beneficiile schimbărilor în afaceri.

Testarea software-ului este evaluarea software-ului/produsului dezvoltat pentru a verifica capacitățile, capacitățile și conformitatea cu rezultatele așteptate. Există diferite tipuri de metode utilizate în domeniul testării și asigurării calității, despre care vor fi discutate în acest articol.

Testarea software-ului este o parte integrantă a ciclului de dezvoltare a software-ului.

Ce este testarea software-ului?

Testarea software-ului nu este altceva decât testarea unei bucăți de cod în condiții de funcționare controlate și necontrolate, observarea rezultatelor și apoi examinarea dacă îndeplinește condiții predefinite.

Diverse seturi de cazuri de testare și strategii de testare au ca scop atingerea unui obiectiv comun - eliminarea erorilor și erorilor din cod și asigurarea performanței software precise și optime.

Metodologia de testare

Metodele de testare utilizate pe scară largă sunt testarea unitară, testarea integrării, testarea de acceptare și testarea sistemului. Software-ul este supus acestor teste într-o anumită ordine.

3) Testarea sistemului

4) Teste de acceptare

În primul rând, se efectuează un test unitar. După cum sugerează și numele, aceasta este o metodă de testare la nivel de obiect. Componentele software individuale sunt testate pentru erori. Acest test necesită cunoștințe precise ale programului și ale fiecărui modul instalat. Astfel, această verificare este efectuată de programatori, nu de testeri. Pentru a face acest lucru, sunt create coduri de testare care verifică dacă software-ul se comportă conform intenției.

Modulele individuale care au fost deja testate unitar sunt integrate între ele și verificate pentru defecțiuni. Acest tip de testare identifică în primul rând erorile de interfață. Testarea integrării se poate face folosind o abordare de sus în jos, urmând proiectarea arhitecturală a sistemului. O altă abordare este abordarea de jos în sus, care este implementată din partea de jos a fluxului de control.

Testarea sistemului

În această testare, întregul sistem este verificat pentru erori și bug-uri. Acest test este efectuat prin împerecherea componentelor hardware și software ale întregului sistem și apoi testarea acestuia. Această testare este clasificată ca o metodă de testare „cutie neagră”, în care sunt testate condițiile de funcționare așteptate de utilizator pentru software.

Teste de acceptare

Acesta este ultimul test care se efectuează înainte ca software-ul să fie lansat către client. Este realizat pentru a se asigura că software-ul care a fost dezvoltat îndeplinește toate cerințele clienților. Există două tipuri de testare de acceptare - una care este efectuată de membrii echipei de dezvoltare este cunoscută sub denumirea de testare de acceptare internă (testare Alpha) și cealaltă care este efectuată de client este cunoscută ca testare de acceptare externă.

Când testarea se face cu clienți potențiali, se numește testare de acceptare a clienților. Când testarea este efectuată de utilizatorul final al software-ului, este cunoscută sub numele de testare de acceptare (testare beta).

Există mai multe tehnici de testare de bază care fac parte din regimul de testare software. Aceste teste sunt de obicei considerate autosuficiente în găsirea erorilor și bug-urilor în întregul sistem.

Testarea cutiei negre

Testarea cutiei negre se efectuează fără cunoștințe despre funcționarea internă a sistemului. Testerul va conduce software-ul către mediul utilizatorului, oferind diverse intrări și testând ieșirile generate. Acest test este cunoscut și sub denumirea de testare în cutie neagră, testare în cutie închisă sau testare funcțională.

Testarea cutiei albe

Testarea cutiei albe, spre deosebire de testarea cutiei negre, ia în considerare funcționarea internă și logica codului. Pentru a efectua acest test, testerul trebuie să cunoască codul pentru a ști exact partea de cod care are erori. Acest test este cunoscut și sub denumirea de testare White-box, Open-Box sau Glass Box.

Testarea cutiei gri

Testarea cutie gri sau testarea cutie gri este ceva între testarea White Box și Black Box, unde testerul are doar cunoștințele generale despre produs necesare pentru a efectua testul. Această verificare se realizează prin documentație și diagrame de flux informațional. Testarea este efectuată de utilizatorul final sau de utilizatorii care par a fi utilizatori finali.

Teste nefuncționale

Securitatea aplicației este una dintre sarcinile principale ale dezvoltatorului. Testarea de securitate testează software-ul pentru confidențialitate, integritate, autentificare, disponibilitate și non-repudiere. Testarea individuală este efectuată pentru a preveni accesul neautorizat la codul programului.

Testarea la stres este o tehnică în care software-ul este expus la condiții care sunt în afara condițiilor normale de funcționare ale software-ului. După atingerea punctului critic se înregistrează rezultatele obţinute. Acest test determină stabilitatea întregului sistem.

Software-ul este testat pentru compatibilitatea cu interfețe externe precum sisteme de operare, platforme hardware, browsere web etc. Un test de compatibilitate verifică dacă un produs este compatibil cu orice platformă software.

După cum sugerează și numele, această tehnică de testare testează cantitatea de cod sau resurse pe care le folosește un program atunci când efectuează o singură operație.

Această testare verifică utilizarea și aspectul practic al software-ului pentru utilizatori. Ușurința cu care utilizatorul poate accesa dispozitivul formează punctul principal de testare. Testarea de utilizare acoperă cele cinci aspecte ale testării - învățare, eficiență, satisfacție, memorabilitate și erori.

Teste în timpul dezvoltării software

Modelul cascadă folosește o abordare de sus în jos, indiferent dacă este utilizat pentru dezvoltarea de software sau testare.

Principalii pași implicați în această metodologie de testare a software-ului sunt:

• Analiza Nevoilor
• Test de proiectare
• Test de implementare
• Testarea, depanarea și revizuirea codului sau a produsului
• Implementare si intretinere

În această tehnică, treci la următorul pas numai după ce l-ai finalizat pe cel precedent. Modelul folosește o abordare non-iterativă. Principalul avantaj al acestei tehnici este abordarea sa simplificată, sistematică și ortodoxă. Cu toate acestea, are multe dezavantaje, deoarece erorile și erorile din cod nu vor fi detectate până în etapa de testare. Acest lucru poate duce adesea la pierdere de timp, bani și alte resurse valoroase.

Model Agil

Această metodologie se bazează pe o combinație selectivă de abordări secvențiale și iterative, pe lângă o varietate destul de mare de noi metode de dezvoltare. Dezvoltarea rapidă și progresivă este unul dintre principiile cheie ale acestei metodologii. Accentul se pune pe obținerea de rezultate rapide, practice și vizibile. Interacțiunea și participarea continuă cu clienții este o parte integrantă a întregului proces de dezvoltare.

Dezvoltare rapidă a aplicațiilor (RAD). Metodologia de dezvoltare rapidă a aplicațiilor

Numele vorbește de la sine. În acest caz, metodologia adoptă o abordare evolutivă rapidă folosind principiul proiectării componentelor. După înțelegerea diferitelor cerințe ale unui proiect dat, un prototip rapid este pregătit și apoi comparat cu setul așteptat de condiții și standarde de ieșire. Schimbările și modificările necesare sunt făcute după o discuție comună cu clientul sau echipa de dezvoltare (în contextul testării software-ului).

Deși această abordare are partea ei de avantaje, poate să nu fie adecvată dacă proiectul este mare, complex sau are o natură extrem de dinamică, în care cerințele sunt în continuă schimbare.

Model în spirală

După cum sugerează și numele, modelul în spirală se bazează pe o abordare în care există un număr de cicluri (sau spirale) din toate etapele succesive dintr-un model în cascadă. Odată ce ciclul inițial este încheiat, se efectuează o analiză și o revizuire amănunțită a produsului sau a rezultatelor obținute. Dacă ieșirea nu îndeplinește cerințele specificate sau standardele așteptate, se efectuează un al doilea ciclu și așa mai departe.

Procesul rațional unificat (RUP). Proces rațional unificat

Tehnica RUP este, de asemenea, similară cu modelul în spirală, în sensul că întreaga procedură de testare este defalcată în mai multe cicluri. Fiecare ciclu constă din patru etape - creare, dezvoltare, construcție și tranziție. La sfârșitul fiecărui ciclu, produsul/ieșirea este revizuit și ciclul (constând din aceleași patru faze) este urmat după cum este necesar.

Utilizarea tehnologiei informației crește în fiecare zi, iar importanța testării adecvate a software-ului a crescut, de asemenea, în mod semnificativ. Multe companii mențin echipe speciale în acest scop, ale căror capacități sunt la nivelul dezvoltatorilor.