Vid4

Ce este testarea

Aplicațiile software sunt peste tot și au devenit o parte crucială a vieții noastre.

Fiecare dintre noi a folosit software într-un fel sau altul

puteți vedea software-ul sub forma numeroaselor aplicații de pe telefon

utilaje medicale în spitale, în mașina dvs. sau în avioane

în aplicații de afaceri precum bancar și bursă și chiar în divertisment

unde toate filmele tale preferate au fost făcute folosind un fel de software

De-a lungul istoriei computerului, este destul de comun pentru software și sisteme

urmând să fie livrate în exploatare și din cauza prezenței unor defecte sau bug-uri

așa cum o știm cei mai mulți dintre noi

multe aplicații software provoacă ulterior defecțiuni

sau altfel nu satisface nevoile părților interesate

Software-ul care nu funcționează sau chiar are probleme minore poate cauza probleme și frustrări uriașe

O mică greșeală de calcul într-o aplicație de afaceri poate cauza pierderi de bani

o operațiune de software îndelungată sau un raport lent ar putea pierde timp și poate provoca frustrare

dacă aștepți la coadă rândul tău la o casierie. Reputația dvs. de afaceri va fi în pericol

dacă software-ul dvs. nu este la standarde și poate provoca chiar vătămări sau deces.
Există multe exemple de probleme minore de software care cauzează o problemă uriașă

Vă voi arăta una dintre cele mai faimoase bug-uri din istorie

Aceasta a fost prima lansare a rachetei Agenției Spațiale Europene Ariane 5 în iunie 1996

a eșuat după 37½ secunde provoacă pierderi de milioane de dolari

După investigație, problema sa redus la un singur pas în software-ul care provoacă

software-ul să se prăbușească, hardware-ul să se prăbușească și apoi întreaga rachetă să se prăbușească

Ai putea spune că 1996 este cu mult timp în urmă

Ei bine, cu toții am auzit de prăbușirile avioanelor Boeing, a avut loc un accident de avion etiopian recent
în 2019

Boeing va lansa o actualizare de software pentru aeronava 737 Max la sol în săptămânile următoare

în urma accidentului Ethiopian Airlines care a ucis 157 de persoane

Producătorul de avioane american se așteaptă ca Administrația Federală a Aviației din SUA să aprobe
modificări de proiectare ale software-ului

„cel târziu în aprilie 2019”

Software-ul pe care Boeing intenționează să îl implementeze include actualizări ale Sistemului de creștere
a caracteristicilor de manevră.

Prin urmare, să avem grijă de crearea unui software funcțional stabil ar trebui să fie întotdeauna scopul
nostru

Și din experiența mea, nicio problemă în software nu este o problemă mică; Am văzut proiecte software
eșuate din cauza unui singur
greșeală de scriere pe unul dintre ecranele software-ului. Când clientul a văzut acea greșeală de scriere
după livrarea software-ului

și-a anulat viitoarea lucrare cu acea companie. A spus că dacă nu au prins o problemă evidentă ca aceasta

cum ar descoperi probleme ascunse în software

Acesta este motivul pentru care testarea ar trebui să înceapă cât mai devreme posibil

Despre acest curs

Fiți un tester certificat ISTQB® și aflați elementele de bază ale principiilor și tehnicilor de testare a
software-ului încă de la prima încercare
După cifre
Nivel de calificare: Toate nivelurile
Studenți: 86520
Limbi: engleza
Subtitrare: Da
Teste practice: 1
Întrebări: 40
Prelegeri: 97
Video: 9,5 ore în total

Vid5
Obiectivul testării Obiectivele tipice ale testării

Cel mai comun obiectiv binecunoscut al testării, este evaluarea calității software-ului și

pentru a reduce riscul defecțiunii software în funcționare. Dar uneori, puncte de vedere diferite

în testare luați în considerare diferite obiective.

Pentru orice proiect dat, obiectivele testării pot include:

provocând cât mai multe defecțiuni astfel încât să fie identificate defectele software-ului și

poate fi reparat. Acest lucru va reduce nivelul total de risc de calitate insuficientă a software-ului (în

cuvinte mai simple, asigurându-vă că defectele nedetectate nu vor fi dăunătoare în funcționare)

În timpul livrării software-ului pentru acceptare, obiectivul principal ar putea fi confirmarea acestui lucru

sistemul funcționează conform așteptărilor, pentru a câștiga încredere în nivelul de calitate și pe care l-a
îndeplinit

cerintele.

În unele cazuri, obiectivul principal al testării poate fi acela de a evalua calitatea software-ului

(fără intenția de a găsi sau remedia defecte), doar pentru a oferi informații părților interesate astfel

ei iau o decizie cu privire la aceste informații.

Testarea poate fi utilizată pentru a preveni defectele prin evaluarea produselor de lucru, cum ar fi
cerințele,

povești de utilizator, design și cod. Aceasta va ajuta

De asemenea, pentru a verifica dacă toate cerințele specificate au fost îndeplinite și implementate.

Dar doar pentru a vă anunța, implementarea cerințelor specificate, deoarece nu este suficientă

….da….M-ai auzit bine

puteți dezvolta software-ul exact ca cerințele specificate, dar clientul totuși

nu acceptă software-ul..poate pentru că software-ul așa cum este nu i-a rezolvat problema
inca.

De aceea, testarea implică și validare, care înseamnă verificarea dacă sistemul o va face

satisface nevoile utilizatorilor și ale altor părți interesate în mediul sau mediile operaționale.

Un ultim obiectiv posibil de testare ar fi Respectarea contractuale, legale sau de reglementare

cerințe sau standarde. De exemplu, puteți testa software-ul pentru a vă asigura că este conform

cu standardul ISO sau pentru a obține sigla certificată Windows pe cutia dvs. de software... deci aici

testați pentru a vă asigura că software-ul respectă unele reguli specifice furnizate de un

organizare.

Acestea sunt obiectivele de testare care au fost menționate în programă. Dar mi-ar plăcea

să adaug că toate aceste obiective servesc unui mare obiectiv care cred că este tatăl

a tuturor obiectivelor de testare care este reducerea nivelului de risc al software-ului insuficient

calitate (cu cuvinte mai simple, asigurându-vă că defectele nedetectate nu vor fi dăunătoare în

Operațiune)

Acestea erau obiective de testare pe care le puteai vedea în orice proiect software. Uneori,

obiectivele testării pot varia, în funcție de contextul componentei sau sistemului

în curs de testare, unde ne aflăm în ciclul de viață al dezvoltării software și care software

modelul ciclului de viață de dezvoltare pe care îl folosim. Deci diferite obiective pot fi aplicate în timpul
cursul dezvoltării proiectului software depinde de contextul testării. Aceste diferențe

poate include, de exemplu:

În timpul testării componentelor, un obiectiv poate fi acela de a găsi cât mai multe defecțiuni

ca defectele de bază să fie identificate și remediate din timp. Un alt obiectiv poate fi

pentru a crește acoperirea de cod a testelor componente. ne vom ocupa de acoperire mai mult în

videoclipuri viitoare... dar pentru moment creșterea acoperirii codului înseamnă să ne asigurăm că am
acoperit

cât mai multe linii de cod și logică prin rularea testelor noastre.

De asemenea, în timpul testării de acceptare, un obiectiv poate fi acela de a confirma că sistemul

funcționează ca

asteptat si satisface cerintele. Un alt obiectiv al acestei teste poate fi acela de a oferi informații

părților interesate despre riscul eliberării sistemului la un moment dat.

În practică, este esențial să înțelegem obiectivul real al activității de testare.

Testarea software-ului în scopul găsirii defectelor poate fi diferită de testarea software-ului

același software pentru a câștiga încredere cu privire la nivelul de calitate.

Orice activitate care va ajuta la atingerea obiectivului de testare este considerată activitate de testare

Vid6

De ce este necesară testarea

Deci, cred că este clar de ce este necesară testarea

testarea abundentă a componentelor și sistemelor și documentația asociată acestora;

poate ajuta la reducerea riscului de defecțiuni care apar în timpul funcționării.

Ai mai auzit termenul de risc într-un videoclip anterior și îl vei auzi mult mai mult în timpul acestui curs

și dacă intenționați să vă alăturați altor cursuri ISTQB, îl veți auzi și mai mult.

Pe scurt, noi, testerii, lucrăm pentru a reduce riscul apariției defecțiunilor în timpul funcționării.

Atunci când defectele sunt detectate și ulterior remediate, aceasta contribuie

la calitatea componentelor sau sistemelor.

În plus, așa cum am spus înainte... există multe alte obiective de testat,

aceste obiective sunt, desigur, alte motive pentru care este necesară testarea

De exemplu, testarea software-ului poate fi, de asemenea, necesară pentru a îndeplini contractul

sau cerințe legale sau standarde specifice industriei.

Contribuțiile testării la succes

Deci, cum pot testerii să reducă riscul apariției defecțiunilor în timpul funcționării.

Testerul ar trebui să folosească diferite tehnici pentru a evita această problemă majoră de software

Una dintre tehnici este de a găsi și remedia cât mai multe defecte posibil înainte de lansarea software-ului

Această tehnică presupune execuția componentei sau a sistemului testat cu unele date de testare;
o astfel de testare se numește testare dinamică.

Dar această formă de testare necesită ca codul software să fie implementat și rulat

corect, acest lucru nu este cât mai devreme posibil

Testarea dinamică înseamnă că erorile sunt de fapt acolo și că încercăm să le găsim.

O strategie mai bună ar fi să împiedicați apariția erorilor în software în primul rând.

o astfel de testare se numește testare statică

testarea statică nu implică execuția componentei sau a sistemului testat

se întâmplă mai devreme. Deci nu există cod de executat sau de rulat. De aceea se numește static.

Testarea statică implică tehnici precum revizuirea documentelor (de exemplu, cerințe, povești ale
utilizatorilor,

documentele de proiectare și codul sursă care pot fi eficiente în prevenirea defectelor

de a fi introduse în cod prin eliminarea ambiguităților și erorilor din documentele de specificații

Testarea statică este tratată în detaliu într-o altă secțiune.

Atât testarea dinamică, cât și testarea statică pot fi utilizate ca mijloace pentru atingerea unor obiective
similare

și va oferi informații care pot fi folosite pentru a îmbunătăți atât sistemul testat

și procesele de dezvoltare și testare.

O întrebare frecventă care mi s-a adresat aici este cine efectuează testarea statică și dinamică?
Fii atent la raspunsul meu

atât testarea statică, cât și testarea dinamică pot fi efectuate de oricine din ciclul de viață al software-ului

dezvoltatori, clienți și/sau testeri de sistem

Această programă nu vorbește despre testatorul de software de locuri de muncă,

vorbim despre testare în general, despre rolul testării, care poate fi făcută de oricine

Așa că ține cont de asta atunci când răspunzi la orice întrebare

nu este vorba doar despre tine. Dacă vreau să vorbesc despre testare ca pe un loc de muncă,

Voi spune testarea sistemului în loc de doar testare

Disciplina de testare software implică atât testarea statică, cât și cea dinamică.

Deci, amintiți-vă că atunci când menționăm testarea în general, atunci ne referim atât la testarea statică,
cât și la cea dinamică

Deci, există diferite moduri în care testarea contribuie la succesul software-ului

Exemple de tehnici diferite utilizate de testator pentru a dezvolta software de mai bună calitate includ

Dacă testerii sunt implicați în revizuirea cerințelor sau în rafinarea poveștii utilizatorului, ar putea detecta
defecte ale acestor produse de lucru

Identificarea și înlăturarea defectelor cerințelor

reduce riscul dezvoltării unei funcționalități incorecte sau netestabile

Testerii lucrează îndeaproape cu proiectanții de sistem în timp ce sistemul este proiectat

poate crește înțelegerea fiecărei părți asupra designului și a modului de testare

Această înțelegere sporită poate reduce riscul unor defecte semnificative de proiectare și poate permite
identificarea testelor într-un stadiu incipient

și să permită identificarea testelor într-un stadiu incipient

Testerii lucrează îndeaproape cu dezvoltatorii în timp ce codul este în curs de dezvoltare

poate crește înțelegerea fiecărei părți a codului și a modului de testare

Această înțelegere sporită poate reduce riscul de defecte în cod și teste

și, în cele din urmă, să solicite testerilor să verifice și să valideze software-ul înainte de lansare

poate detecta defecțiuni care altfel ar fi putut fi ratate

și sprijină procesul de eliminare a defectelor care au cauzat eșecurile, care este un alt nume de depanare

Aceasta este ceea ce am numit testare dinamică înainte. Acest lucru crește probabilitatea ca software-ul să
se întâlnească

nevoile părților interesate și satisface cerințele.

Permiteți-mi să vorbesc puțin despre testarea dinamică aici

Provocarea este să ne asigurăm că testarea pe care o facem este o testare eficientă.

Un test bun este cel care găsește un defect dacă există unul prezent

Un test care descoperă niciun defect a consumat resurse, dar aproape că nu a adăugat valoare

Am spus aproape pentru că poate a crescut încrederea în software

dar un test care descoperă un defect a creat o oportunitate de a îmbunătăți qua

vid7

Asigurarea calității și testare

În timp ce oamenii folosesc adesea expresia asigurare a calității (sau doar QA) pentru a se referi la testare

Asigurarea calității și testarea nu sunt aceleași, dar sunt legate

Când auziți asigurarea calității, amintiți-vă întotdeauna procesul

asigurarea calității se concentrează de obicei pe ameliorarea proceselor adecvate

pentru a oferi încredere că vor fi atinse niveluri adecvate de calitate

Permiteți-mi să vă dau un exemplu ușor de reținut

Dacă ți-aș cere să faci pizza

si nu stii sa faci pizza, atunci Probabilitatea ca vei face ceva de mancare este foarte mica

chiar dacă ai cele mai bune ingrediente

Dar dacă vă dau o rețetă de pizza care s-a dovedit până acum a fi o pizza bună

atunci probabilitatea de a face o pizza bună va fi mult mai mare.

produsul software este pizza noastră, iar rețeta este procesul.

Cine a scris această rețetă cu siguranță a avut mai multe încercări pentru a veni cu acea rețetă bună

din când în când, autorul rețetei ar putea adăuga ceva ici și colo
până când clienții pizza sunt de acord că aceasta este o pizza bună

în software, acele îmbunătățiri se numesc îmbunătățiri de proces

Cu cât procesul este mai bun, cu atât software-ul este mai bun

simplu ca buna ziua

O pizza de bună calitate înseamnă că totul despre pizza este bun

aluatul, sosul pe care îl numim în produsele software de lucru

Când procesele sunt efectuate corect

produsele de lucru sau rezultatele create de acele procese sunt, în general, de o calitate superioară

care contribuie la prevenirea defectelor

În plus, utilizarea analizei cauzei principale pentru a detecta și înlătura cauzele defectelor este importantă
pentru asigurarea eficientă a calității.

împreună cu aplicarea corespunzătoare a constatărilor de - - - - pentru a îmbunătăţi procesele

este important pentru asigurarea eficientă a calității

Pe de altă parte, controlul calității implică diverse activități

Inclusiv activități de testare, care sprijină atingerea nivelurilor adecvate de calitate

Activitățile de testare fac parte din procesul general de dezvoltare sau întreținere a software-ului

întrucât asigurarea calității se preocupă de buna desfășurare a întregului proces

prin urmare, asigurarea calității sprijină testarea adecvată.

astfel încât testarea contribuie la atingerea calității într-o varietate de moduri

În aceeași notă, un concept mai larg de management al calității

leagă asigurarea calității și controlul calității împreună

managementul calității include atât asigurarea calității, cât și controlul calității Printre alte activități

Managementul calității include toate activitățile care direcționează și controlează o organizație în ceea ce
privește calitatea

Vid8
Erori, defecte și eșecuri

Să ne uităm acum la câteva definiții importante

O ființă umană poate face o eroare (greșeală), această persoană ar putea fi analistul de sistem

proiectantul sau codificatorul sistemului, sau chiar clientul sau utilizatorii.

Unele dintre aceste erori vor ADĂUGA un defect (defecțiune, eroare) la codul programului sau la un
document

Am spus unele dintre aceste erori pentru că nu toate greșelile vor produce o eroare.

O greșeală a analistului ar adăuga un bug la software. Dar o greșeală de utilizator nu va ADĂUGA un bug
la software

Dacă se execută un defect în cod, sistemul poate să nu facă ceea ce ar trebui să facă

(sau faceți ceva ce nu ar trebui), provocând un eșec

Observați din nou că am spus „poate eșua”, deoarece nu toate defectele ar eșua software-ul
De fapt, unele erori ar face ca software-ul să eșueze doar în circumstanțe foarte specifice.

Dacă aceste circumstanțe nu s-ar întâmpla niciodată, atunci defectul nu va cauza un eșec

Există o vorbă „A greși este uman; pentru a găsi erorile necesită un tester”

Vă voi da un exemplu pentru a fi clar

cineva are febră care este un eșec un simptom pe care îl vedeți

se duce la doctor si doctorul decide ceva in neregula cu stomacul care este defectul

ceva în neregulă cu stomacul

motivul durerii de stomac este că pacientul a mâncat prea mult cu o seară înainte

aceasta este eroarea pe care pacientul a facut-o care a cauzat defectul

În plus, în calitate de tester, vreau să știi ceva

Software-ul este creat de om și omul face greșeli

Nu trebuie să fie pentru că sunt leneși sau ignoranți.

Oamenii greșesc pentru că sunt imperfecți

și există și multe presiuni care fac greșelile mai probabile

Dacă un document conține o eroare, se utilizează pentru a construi o componentă sau un software

atunci componenta va fi defectă și probabil va prezenta un comportament incorect

Eroarea din document ar putea fi greșeala analistului de sistem pentru că nu a înțeles clientul
sau greșeala clientului în primul rând pentru că clientul nu a putut explica exact ce vrea

Erorile pot apărea din mai multe motive, cum ar fi

Presat de timp

Falibilitatea umană

Participanți la proiect fără experiență sau insuficient calificați

Comunicarea greșită între participanții la proiect, inclusiv comunicarea greșită cu privire la cerințe și
design

Complexitatea codului, a designului, a arhitecturii, a problemei de bază care trebuie rezolvată și/sau a
tehnologiilor utilizate

De asemenea, neînțelegeri despre interfețele intra-sistem și inter-sistem,

mai ales atunci când astfel de interacțiuni intrasistem și intersistem sunt mari ca număr

și ultimele tehnologii noi, necunoscute

Toți acești factori vor adăuga presiuni asupra proiectanților de sisteme și vor crește probabilitatea erorilor
în specificații,

proiecte și în codul software

De asemenea, pot apărea erori din cauza nerespectării standardelor cerute

de exemplu. standarde de compilare, critice pentru siguranță sau legate de siguranță, cum ar fi comutarea
căilor ferate, controlul traficului aerian și așa mai departe

Am vorbit despre erori, să vorbim puțin despre defecte

Dacă un sistem financiar are o greșeală de calcul în una dintre caracteristicile sale, numim că un defect
funcțional, ceea ce este desigur, este inacceptabil

numim asta un defect funcțional, care este desigur, este inacceptabil

Este posibil ca unele sisteme să nu aibă probleme evidente de funcționalitate, dar încă inutilizabile

Luați în considerare un sistem care este lent sau un sistem care nu poate accepta mai mult de 1000 de
utilizatori la un moment dat

Acest lucru este încă inacceptabil. Numim acest tip de probleme defecte nefuncționale

Un rol al testării este de a se asigura că cerințele funcționale și nefuncționale cheie

sunt examinate înainte ca sistemul să fie pus în funcțiune

iar orice defecte sunt raportate echipei de dezvoltare pentru a le remedia.

Utilizăm testarea pentru a ne ajuta să măsurăm calitatea software-ului în ceea ce privește numărul de
defecte găsite,

testele rulează și sistemul acoperit de teste.

Spunând asta, crezi că testarea crește calitatea software-ului?

Raspunsul este nu

Testarea nu poate elimina direct defectele, ci doar le raportează. Prin urmare, testarea nu poate îmbunătăți
direct calitatea

Testarea poate da încredere în calitatea software-ului dacă găsește puține defecte sau deloc

Un test proiectat corespunzător care trece reduce nivelul general de risc din sistem

Prin raportarea defectelor, face posibilă eliminarea acestora

iar calitatea sistemului software crește doar atunci când acele defecte sunt remediate.

bine, am vorbit despre erori și defecte, este timpul să vorbim despre eșecuri

Acum vreau să te gândești la următoarele

Pe lângă defecțiunile cauzate de defecte ale codului, eșecurile pot fi cauzate și de condițiile de mediu

De exemplu, radiațiile, câmpurile electromagnetice și poluarea pot cauza defecte ale firmware-ului sau
pot influența execuția

software-ul prin schimbarea condițiilor hardware..

Știți ce înseamnă asta, înseamnă că nu toate rezultatele testelor neașteptate

sunt eșecuri reale din cauza unei erori în software

ceea ce vrem să spunem aici este că ar putea exista ceva care nu funcționează corect

dar nu se datorează unei erori în software. Aceasta ar putea fi o surpriză pentru unii.

când software-ul funcționează bine, dar ne imaginăm că ceva nu este în regulă și raportăm un defect

aici avem (rezultat fals-pozitiv) fals înseamnă ceva greșit și pozitiv înseamnă că am găsit ceva, dar a fost

constatare greșită. fals pozitive sunt raportate ca defecte, dar nu sunt de fapt defecte. Este un raport de
eroare prost.

După cum am spus, fals pozitive pot apărea din cauza erorilor în modul în care au fost executate testele,

sau din cauza defectelor datelor de testare, a mediului de testare sau a altor programe de testare sau din
alte motive.

Pe de altă parte
Când software-ul are defecte, dar nu le-am putut găsi nici după testare

apoi spunem că avem (rezultat fals-negativ) fals înseamnă ceva greșit și negativ înseamnă că nu l-am
găsit

Fals negative sunt teste care nu detectează defecte pe care ar fi trebuit să le detecteze.

Deci care crezi că este mai periculos, fals negativ sau fals pozitiv?

Dacă te gândești bine, falsele negative sunt mai periculoase decât falsele pozitive

deoarece poate duce la o problemă gravă după lansarea software-ului.

Vid10

Defecte, cauze fundamentale și efecte

După cum am spus, eșecurile sunt cauzate de defecte, iar defectele sunt cauzate de erori sau greșeli făcute
de oameni.

Deci, a ști de ce oamenii fac greșeli și a le opri ar fi prima linie de apărare.

De aceea încercăm întotdeauna să găsim cauzele fundamentale ale defectelor.

Cauzele fundamentale ale defectelor sunt primele acțiuni sau condiții care au contribuit la crearea
defectelor.

Deci analizăm defectele pentru a le identifica cauzele fundamentale,

astfel încât să putem reduce apariția unor defecte similare în viitor. Concentrându-se pe cele mai
importante cauze fundamentale,

Analiza cauzei principale poate duce la îmbunătățiri ale procesului

care împiedică introducerea unui număr semnificativ de defecte viitoare.

De exemplu, să presupunem că plățile incorecte ale dobânzii, din cauza unui singur rând de cod incorect,

duce la reclamații ale clienților. Codul defect a fost scris pentru o cerință ambiguă,

din cauza neînțelegerii de către analist cu privire la modul de calcul al dobânzii.

Dacă un procent mare de defecte există în calculele dobânzii, iar aceste defecte au cauza principală în
similară

neînțelegeri, analiștii ar putea fi instruiți în tema de interes

calcule pentru a reduce astfel de defecte în viitor.

În acest exemplu, plângerile clienților sunt efecte. Plățile incorecte ale dobânzii sunt eșecuri.

Calculul incorect din cod este un defect și a rezultat din defectul inițial,

ambiguitatea în cerință. Cauza principală a defectului inițial a fost

o lipsă de cunoștințe din partea analistului, ceea ce a dus la greșeala analistului

în timp ce scrieți cerința. Procesul de analiză a cauzei principale este discutat în ISTQB-ETM Expert
Level

Programul de management al testelor și ISTQB-EITP Nivelul de experți Îmbunătățirea programului de

testare.

Testare și depanare

Testarea și depanarea sunt diferite. Executarea testelor poate arăta defecțiuni cauzate de defecte ale
software-ului.

Depanarea este activitatea de dezvoltare care găsește, analizează și remediază astfel de defecte.
Retestarea ulterioară sau testarea de confirmare verifică dacă remediile au rezolvat defectele.

În unele cazuri, testerii sunt responsabili pentru testul inițial și testul final de confirmare,

în timp ce dezvoltatorii fac depanarea și testarea componentelor asociate. Cu toate acestea, în dezvoltarea
Agile

și în alte cicluri de viață, testerii pot fi implicați în depanare și testarea componentelor.

Standardul ISO (ISO/IEC/IEEE 29119-1) conține informații suplimentare despre conceptele de testare a
software-ului.

acesta este primul nostru număr sau număr standard de reținut

Înainte să plec, vreau să vă gândiți, ce găsesc testerii de sistem? Erori, defecte sau defecțiuni?

Testerii de sistem găsesc eșecuri... apoi scriu un raport despre acea eșec pentru dezvoltator

într-un mod care ar ajuta dezvoltatorul să dubleze eșecul.

Apoi, dezvoltatorul va folosi tehnicile sale de depanare pentru a găsi defectul care a cauzat acea
defecțiune și pentru a încerca să-l remedieze.

Vid10
Conceptul de acoperire în testarea software-ului

Acoperirea testului este o parte esențială a testării software-ului.

este definită ca o măsură în Testarea software-ului care -măsoară cantitatea de testare efectuată de un set
de teste.

Prin cantitatea de teste ne referim la ce părți ale programului aplicației sunt exercitate atunci când rulăm
un grup de teste
În termeni simpli, acoperirea testului măsoară eficacitatea testării noastre

Deci, când putem conta pe anumite lucruri dintr-o aplicație și, de asemenea, putem spune dacă cazurile de
testare acoperă

acele lucruri ale aplicației, atunci putem spune că cât de mult au acoperit cazurile noastre de testare.

Deci, de exemplu, dacă avem 4 caracteristici și am testat doar 3 dintre ele, atunci acoperirea noastră de
testare este de 75% din caracteristici

Sau dacă avem 1000 de linii de cod și testele noastre au vizitat sau au exercitat 600 de linii din acele linii

Atunci acoperirea noastră de testare este de 60%.

Deci eficacitatea testării nu este măsurată prin numărul de cazuri de testare

ci mai degrabă cât de mult pot acoperi acele cazuri de testare.

Puteți avea 100 de cazuri de testare care spun că acoperă 50% din software-ul dvs

puteți adăuga încă 100 de cazuri de testare, dar acoperirea testului ar fi în continuare aceeași 50%

și puteți adăuga doar un caz de testare care va crește acoperirea testului la 100%

deci nu este vorba de cantitate, ci de calitatea testelor.

Măsurați testarea software-ului

Deci, care sunt părțile software-ului pe care le putem măsura pentru acoperire

Acoperirea cerințelor: Software-ul a fost testat conform tuturor cerințelor

Acoperire structurală: Fiecare element de proiectare al software-ului a fost exercitat în timpul orelor de
testare, funcții
implementare Acoperire: Fiecare linie de cod a software-ului a fost sau nu exercitată în timpul testării

Dar cum putem ști ce cerință a fost testată

Ei bine, avem nevoie de un fel de hartă care să arate urme între fiecare cerință și fiecare test

o astfel de trasabilitate va ajuta să știți ce cerință a fost testată în ce caz de testare

și care cerință nu a fost testată deloc

un astfel de concept de trasabilitate poate fi aplicat între cerințe, elemente de proiectare, linii de cod,
cazuri de testare și așa mai departe.

Deci, de ce facem Acoperire de testare

Efectuăm analiza acoperirii testului din următoarele motive

Pentru a găsi zonele în cerințele specificate care nu sunt acoperite de testele noastre

pentru a ști unde trebuie să creăm mai multe cazuri de testare pentru a ne crește acoperirea testelor

de asemenea, putem măsura modul în care o solicitare de modificare va afecta software-ul

Identificarea unei măsuri cantitative a acoperirii testului, care este o metodă indirectă de verificare a
calității

și ultima identificarea cazurilor de testare fără sens care nu măresc acoperirea

vid11
Cele șapte principii de testare

O serie de principii de testare au fost sugerate în ultimii 40 de ani și oferă linii directoare generale pentru
toate testele.

Testarea arată prezența defectelor, nu absența acestora

Când testați software-ul, este posibil să găsiți sau nu defecte. Dacă găsiți defecte, aceasta este o dovadă a
prezenței erorilor

Dar, pe de altă parte, dacă testul dvs. nu a găsit defecte, aceasta nu este o dovadă că software-ul nu are
defecte.

Există o mare probabilitate să nu fi găsit defecte, deoarece testul dvs. nu acoperă

lățimea și lățimea software-ului

Poate că nu ați selectat datele de testare potrivite pentru a utiliza software-ul

Poate că defectul așteaptă ca o circumstanță excepțională să eșueze software-ul

Amintiți-vă de problema Y2K, în care multe soluții software eșuează, deoarece consideră anul doar ca
fiind de 2 cifre,

presupunând că se va adăuga întotdeauna automat la 1900

Dacă te gândești la acele soluții software, ele funcționau perfect în anii 70, 80 și 90.

dar nu au putut funcționa începând cu 1 ianuarie 2000

Prin urmare, acele soluții conțin defecte care așteptau să apară o dată cu totul specială

Așa că nu putem numi aceste soluții fără erori, chiar dacă au funcționat perfect de mulți ani

Deci nu există nimic numit software fără erori. Nu avem cum să dovedim asta

Trebuie doar să proiectăm cât mai multe teste pentru a găsi cât mai multe defecte.

Testarea reduce probabilitatea ca defectele nedescoperite să rămână în software

dar, chiar dacă nu sunt găsite defecte, testarea nu este o dovadă a corectitudinii
Testarea exhaustivă este imposibilă

Imaginați-vă dacă avem o pagină web în care trebuie să introduceți vârsta angajatului, care ar trebui să se
încadreze între 20 și 50 de ani.

Pentru a testa acest câmp în detaliu, trebuie să introduceți toate valorile posibile în acel câmp (atât
valorile valide, cât și cele nevalide).

Deci, dacă acest câmp acceptă un număr întreg, care variază de la -32.767 la 32.767, atunci avem 65535
de valori posibile

Adăugați la el o grămadă de combinații de valori de text și caractere speciale (ei bine, utilizatorul poate
introduce text din greșeală

și doriți ca software-ul dvs. să se comporte decent în toate cazurile, fără să se blocheze).

De asemenea, s-ar putea să avem cazuri de testare în care lipim numerele nu doar tastându-le,

trageți și plasați valorile și poate încercați niște circumstanțe excepționale

când introduceți valori precum spații, ștergeți caractere... etc

apoi spunem că avem un total de 70000 de valori.

Dacă fiecare valoare durează un minut pentru a fi testată, atunci am avea nevoie de 70000 de minute
pentru a testa numai acest câmp

70000 de minute înseamnă 1167 de ore, adică 49 de zile, testând acest câmp zi și noapte?

Testarea tuturor combinațiilor posibile de intrări și condiții prealabile se numește testare exhaustivă.

Prin urmare, testarea exhaustivă este imposibilă.

Cu excepția cazului în care aplicația testată are cazuri simple, banale

atunci este posibil să se testeze toate combinațiile posibile de date de intrare și precondiții

dar, după cum știți, majoritatea aplicațiilor reale nu sunt banale

deci principiul general este testarea exhaustivă este imposibilă.

Din acest motiv, analiza riscului, tehnicile de testare și prioritățile sunt folosite pentru a se concentra

cele mai importante aspecte de testat

Utilizarea lor este esențială pentru a se asigura că piesele esențiale sunt testate

Testarea timpurie economisește timp și bani

Multe probleme din sistemele software pot fi urmărite până la cerințe lipsă sau incorecte

În testele timpurii, încercăm să găsim erori și defecte cât mai curând posibil

înainte de a trece la următoarea etapă a procesului de dezvoltare

Din graficul afișat, când se descoperă o eroare în cerință în timpul fazei de cerință

costul remedierii acestui bug este foarte ieftin

Cu cât așteptăm mai mult să remediem acest bug, cu atât este mai costisitor să fie remediat. De ce?

Pentru că acum este posibil să fi construit o parte din designul nostru pe baza acestor cerințe defectuoase

Același lucru când este introdus un bug în faza de proiectare,

este mai ieftin să-l repari în faza de proiectare decât să așteptați până la etapele ulterioare. Și așa mai
departe
O eroare în cerință ar crea un design greșit, care, la rândul său, ar crea un cod de erori,

iar rezultatul final ar fi un software cu erori.

Din graficul afișat, vedem că dacă clientul nostru a descoperit o eroare după livrarea software-ului

acest lucru ar costa de 1000 de ori mai mult decât dacă am fi descoperit și remediat eroarea în faza de
cerințe

În plus, timpul și efortul necesar pentru a remedia o eroare de cerințe în timpul fazei de testare a
sistemului

ar putea fi de 500 de ori mai mare decât dacă am fi descoperit și remediat bug-ul în faza de cerințe

pentru a găsi defectele din timp, activitățile de testare ar trebui să înceapă cât mai devreme posibil în
software

sau ciclul de viață al dezvoltării sistemului, testerii ar trebui să se alăture ciclului de viață al software-ului
de îndată ce documentele sunt în modul schiță
De exemplu, cerințele individuale sunt testabile? Putem găsi cerințe ambigue sau lipsă? și așa mai departe

Ceea ce încercăm să realizăm aici este să întrerupem ciclul „eroare-cod-eșec” pe care l-am menționat
anterior.

Aplicarea unui proces reduce erorile făcute de oameni, testarea statică identifică defecte cât mai devreme
posibil

testarea dinamică găsește eșecuri pe care le-am putea găsi încă și trimite acele eșecuri înapoi

pentru dezvoltatori în rapoartele de erori sau defecțiuni pentru a remedia

Dacă așteptăm până în ultimul minut pentru a introduce testere, presiunea timpului poate crește dramatic.

Prin urmare, există un pericol real ca testarea să fie strânsă.

Cu cât activitatea de testare este începută mai devreme, cu atât timpul scurs disponibil este mai lung
Testerii nu trebuie să aștepte până când software-ul este disponibil pentru testare

Programa menționa că testarea timpurie este uneori denumită „schift left”

ceea ce înseamnă că testarea s-a mutat la stânga pe cronologia proiectului.

Unele întrebări din examen ar putea fi legate de cele mai scumpe defecte de remediat

Bine

Ei bine, de obicei nu vă spun în ce fază vă aflați în prezent

așa că luați în considerare timpul de după lansarea software-ului

deci care defecte sunt cele mai costisitoare pentru a remedia cerinţele defecte.

Dacă au menționat că sunteți încă în faza de cerințe, de exemplu,

atunci defectele cerințelor sunt cel mai ieftin de reparat

Dacă ați fost în faza de proiectare, atunci defectele cerințelor sunt cel mai scump de remediat atunci

iar defectele de proiectare sunt cele mai ieftine și așa mai departe

Defectele se grupează împreună

Dacă avem software de 10 module sau componente. Imaginați-vă că primul nostru ciclu de testare a expus
100 de erori.

Nu veți descoperi că fiecare modul are exact 10 erori, ci, mai degrabă, este adesea un număr mic de
module

care prezintă majoritatea problemelor

un anumit modul ar putea conține majoritatea erorilor dintr-o varietate de motive, dintre care:

Complexitatea sistemului

Cod volatil

Efectele schimbării

Experiența personalului de dezvoltare

Neexperienta personalului de dezvoltare

Deci, acest principiu spune că Un număr mic de module conține de obicei

majoritatea defectelor descoperite în timpul testării pre-lansare

sau este responsabil pentru majoritatea defecțiunilor operaționale

Clusterele de defecte previzionate și grupurile de defecte observate efectiv în testare sau operare,

sunt o contribuție esențială într-o analiză de risc utilizată pentru a concentra efortul de testare

Acest fenomen este strâns legat de principiul Pareto, care se numește regula 80/20.

Regulile spun că 80% dintre efecte se datorează a 20% dintre probleme

De exemplu, 80% dintre accidentele de mașină se datorează a 20% dintre șoferi

Dreapta
În software, se spune că aproximativ 80 la sută din probleme se găsesc în aproximativ 20 la sută din
module
Deci, dacă doriți să descoperiți un număr mai mare de defecte, este util să folosiți acest principiu și să
vizați zonele

a aplicaţiei unde se pot constata o proporţie mare de defecte

Cu toate acestea, trebuie amintit că testarea nu ar trebui să se concentreze exclusiv pe acele părți

Este posibil să existe mai puține defecte în codul rămas, dar ar putea fi mai grave

așa că testerii trebuie încă să le caute din greu

Atenție la paradoxul pesticidelor

Dacă aceleași teste sunt repetate iar și iar, în cele din urmă același set de teste nu va mai găsi niciun defect
nou

Testele nu mai sunt eficiente în găsirea defectelor, la fel cum pesticidele nu mai sunt eficiente în uciderea
insectelor după un timp.

Pentru a detecta noi defecte, testele existente și datele de testare ar putea trebui modificate

și poate fi necesar să fie scrise noi teste pentru a exercita diferite părți ale software-ului sau sistemului

pentru a găsi eventual mai multe defecte

În unele cazuri, cum ar fi testarea de regresie automată, paradoxul pesticidelor are un rezultat benefic

care este numărul relativ scăzut de defecte de regresie

Testarea depinde de context

Sunt necesare teste diferite pentru diferite circumstanțe

Un software de joc care folosește mult grafica va fi testat diferit de un editor de grafică
software care utilizează, de asemenea, grafica intens

Un site web static simplu va fi testat diferit de un site de comerț electronic dinamic,

unde produsele pot fi achiziționate folosind carduri de credit/debit

Un software folosit într-un avion va fi testat diferit de un simulator de zbor

Software-ul de control industrial critic pentru siguranță este testat diferit de o aplicație mobilă de comerț
electronic

Conectarea pentru un sistem bancar se va face diferit de autentificarea pentru un joc online

chiar dacă interfața cu utilizatorul ar putea arăta exact la fel în ambele aplicații.

Ca un alt exemplu, testarea într-un proiect Agile se face diferit decât testarea într-un proiect de ciclu de
viață secvenţial

Ultimul principiu Absența erorilor este o eroare

Unele organizații se așteaptă ca testerii să poată rula toate testele posibile și să găsească toate defectele
posibile

dar principiile 2 și, respectiv, 1, ne spun că acest lucru este imposibil

În plus, este o eroare (adică o credință greșită) să te aștepți că doar găsirea și remedierea unui număr mare
de defectec

va asigura succesul unui sistem.

De exemplu, testarea amănunțită a tuturor cerințelor specificate și remedierea tuturor defectelor găsite

ar putea încă produce un sistem greu de utilizat

care nu satisface nevoile și așteptările utilizatorilor.

Software-ul fără erori cunoscute nu este neapărat pregătit pentru a fi livrat. Ar trebui să pui și întrebarea

Aplicația testată îndeplinește sau nu nevoile utilizatorilor?

Faptul că nu găsim niciun defect sau că am remediat toate defectele

pe care le-am găsit nu sunt suficiente motive pentru care software-ul va avea succes

Gandeste-te la asta

Înainte de a începe testarea dinamică, nu au fost raportate defecte în raport cu codul livrat până acum

Înseamnă asta că software-ul care nu a fost testat și, prin urmare, nu există defecte restante împotriva
acestuia

poate fi expediat? Eu nu cred acest lucru!

Amintește-ți mereu asta și am învățat asta pe calea grea

S-ar putea să mergi la un medic cu simptome pe care acesta îți administrează medicamente conform
analizei sale asupra problemei

încercați medicamentul pentru o perioadă fără îmbunătățiri, așa că se dovedește că analiza inițială a
medicului a fost greșită

și ar putea recomanda un alt medicament.

Primul medicament nu a fost unul rău, dar a fost un medicament greșit în funcție de situația actuală.

Vă puteți gândi la aceeași analogie atunci când vă gândiți la software

de obicei construim „software care să ne ajute să rezolvăm o problemă

Punem caracteristicile software-ului gândindu-ne că va rezolva problema

Și apoi construim software-ul exact în funcție de caracteristicile pe care ni le punem.

Ei bine, uneori, soluția noastră se dovedește a fi una proastă

Deci, absența erorilor este o eroare că software-ul va avea succes oricum

Acum, ce fel de întrebări puteți primi în această parte

Ei bine, pentru unul, ei pot enumera 4 opțiuni, 3 dintre ele sunt principii și a patra nu este un principiu

și apoi ei vă pot cere să alegeți cel care nu este de principiu.

Desigur, ei vor face din cel non-principal unul confuz

Ceva de genul „testarea ajută la câștigarea încrederii în software”, este adevărat, dar nu este un principiu.

În plus, ei vă pot oferi o situație și vă pot întreba ce principiu descrie situația

sau care principiu lipsește situația

De exemplu, un client primește software-ul, dar este supărat pentru că software-ul nu îi satisface nevoia

Care principiu nu l-am urmat. Eșecul absenței erorilor.

O echipă vrea să descopere cât mai multe defecte, ce principiu ar trebui să urmeze.

Gruparea defectelor Și așa mai departe.

Acum este ceva ce aș dori să subliniez aici

așa cum am menționat mai înainte, „riscul” este un aspect important atunci când vorbim despre testare

deci haideți să vorbim câteva minute despre risc doar pentru a evidenția conceptul de risc.
Acum, dacă testarea arată doar prezența defectelor și testarea exhaustivă este imposibilă plus paradoxul
pesticidelor

O întrebare bună ar putea apărea acum. Câte teste sunt suficiente?

Răspunsul este că depinde de RISC

Riscul de a pierde erori importante

Riscul de eșec costuri

Riscul de a lansa software netestat sau insuficient testat

Riscul de a pierde credibilitatea și cota de piață

Riscul de a rata o fereastră de piață

Riscul de supratestare, testare ineficientă

De fiecare dată ar trebui să evaluăm riscul situației actuale a software-ului și să decidem

indiferent dacă riscul este ridicat sau scăzut

Dacă riscul este scăzut și acceptabil, atunci putem opri testarea și livrăm software-ul. În caz contrar, ar
trebui să continuăm testarea

Testarea ar trebui să ofere părților interesate suficiente informații pentru a lua decizii informate cu privire
la eliberarea

software-ul fiind testat pentru următorul pas de dezvoltare sau predarea către clienți.

Apoi folosim aceste informații despre RISC pentru a determina

ce să testezi mai întâi

ce să testeze cel mai mult

alocați timpul disponibil pentru testare prin prioritizarea testării

ce să nu testezi (de data asta)

cât de bine să testați fiecare articol

vom vorbi mai multe despre risc și testare într-o secțiune ulterioară

Testarea software-ului nu este un joc aleatoriu cu software-ul până când găsim o eroare

ci mai degrabă este un proces pentru a asigura realizarea celor mai eficiente și mai eficiente teste.