Testați modelul și cum să lucrați cu structura. Proces de testare tehnologică

• 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!

Testarea software-ului- 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 sale 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 își arată numărul 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.

Matricea 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.

Gradul de prioritate a 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ă (împărtășită de aceștia).

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 acestora 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 actualizat. 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.

Model de testare este o structură logică care descrie funcționalitatea sistemului și/sau comportamentul utilizatorului, în funcție de care sunt generate cazurile de testare. Construcția unui model de testare începe cu construcția unei structuri, iar apoi structura aprobată este umplută cu cazuri de testare.

Modelele sunt de obicei construite pe baza cerințelor și/sau a comportamentului așteptat al sistemului. Construirea și gestionarea unui model de testare este potrivită pentru sisteme mari cu o logică complexă de afaceri și este dificil de aplicat proiectelor care lucrează folosind metodologii flexibile, deoarece costul menținerii procesului de management al modelului de testare și de asigurare a calității va fi prea mare.

Managementul modelului de testare se referă la procesul care controlează acoperirea modelului de testare, calitatea scripturilor care descriu modelul de testare și actualizarea acestuia.

Managementul modelului de testare este un proces continuu pe tot parcursul ciclului de viață al produsului.

Testați acoperirea modelului

Pentru a controla acoperirea tuturor cerințelor, puteți utiliza matrice de urmărire, care determină acoperirea cerințelor prin cazuri de testare (vezi exemplul).
Înainte ca cazurile de testare să fie descrise, structura modelului de testare trebuie să fie aprobată de client.

Calitatea scenariului

Pentru a gestiona calitatea scripturilor, este necesar să se controleze nu numai nivelul de descriere a cazurilor de testare, ci și calitatea acestora.

Înainte de a începe descrierea cazurilor de testare, este necesar să se determine cerințele pentru fiecare nivel de descriere și criteriile de calitate pentru descrierea cazurilor de testare.

Niveluri posibile de descriere a cazului de testare:

La nivelul 4, coordonarea cu clientul poate fi înlocuită cu aprobare.

Criteriile de calitate pentru descrierile cazurilor de testare pot fi următoarele:

• Cazurile de testare trebuie scrise conform cerințelor

Testarea este procesul prin care se verifică dacă un produs îndeplinește cerințele sale. Prin urmare, în parte din descrierea generală a cazului de testare (în sistemele de urmărire a testelor se utilizează de obicei termenul „Rezumat”), este necesar să se facă referire la o cerință specifică împreună cu fragmente din textul cerințelor. Astfel, va fi clar pentru toți participanții la proiect pe baza căruia a fost scris acest caz de testare.

• Utilizați condiții preliminare detaliate

Cum să economisești timp pe cazurile de testare?

Setați reguli de formatare pentru toate cazurile de testare. În acest fel, cazul de testare va fi ușor de înțeles și de citit pentru orice participant la proiect. De exemplu, într-un proiect puteți introduce următoarele reguli:

• Toți parametrii de intrare trebuie marcați cu roșu.
• Toate scripturile trebuie evidențiate cu albastru,
• Toate numele butoanelor, câmpurilor, blocurilor sunt evidențiate cu caractere cursive și aldine.
• Locurile importante sunt evidențiate cu subliniere.
• Fiecare pas efectuat trebuie să aibă un rezultat așteptat.
• Fiecare pas din cazurile de testare ar trebui să descrie o singură acțiune și rezultatul așteptat pentru aceasta. Acestea. Când primiți un caz de testare eșuat într-un anumit pas, ar trebui să fie clar clar la ce acțiune apare eroarea.
• Rezultatul așteptat ar trebui să fie clar.

Cazurile de testare trebuie să fie clare, de ex. trebuie să fie redactate și formulate astfel încât să nu permită o interpretare ambiguă, dar să fie înțelese clar de toți participanții.

Dacă scrierea cazurilor de testare durează mult, poate apărea o situație când un specialist încetează să-și vadă greșelile. Acest lucru necesită o perspectivă exterioară - aici va ajuta efectuarea de revizuiri încrucișate. Această etapă este recomandată a fi efectuată în cazurile în care dezvoltarea unui model de testare este extinsă și durează mult timp. De exemplu, când dezvoltarea scenariilor de testare durează mai mult de 1 lună.

Procesul de control al calității scenariului poate fi efectuat folosind Test Model Control– un șablon special pregătit.

Testează actualizarea modelului

Este necesar să se actualizeze în mod regulat modelul de testare și cazurile de testare în sine pentru conformitatea cu cerințele, precum și revizuirea priorităților cazurilor de testare.

A updata puteți menține o „Matrice de cerințe”(Matricea de urmărire a cerințelor): după fiecare modificare a unei cerințe specifice, toate cazurile de testare asociate cu această cerință sunt selectate din sistemul de urmărire a testelor și actualizate.

Testarea controalelor modelului:

• TestRail
• TestLink
• Jira+Zephyr
• Microsoft Test Manager (MTM)
• excela

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 scurgerile 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 de creștere a 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.

De ce este necesară testarea?

În această secțiune, ne vom uita la cele mai de bază concepte și principii care sunt utilizate în procesul de testare. Vom afla ce este de fapt testarea, de ce este nevoie și cine o face. Să luăm în considerare obiectivele, principiile și etapele principale ale testării. Să simțim care ar trebui să fie atitudinea psihologică a unui tester adevărat și, în sfârșit, să dezmințim câteva mituri despre testare. Suntem siguri că veți fi interesați.
Să începem cu ce este „testarea”. Pentru început, să facem abstracție de la definițiile academice seci și să privim acest concept din punctul de vedere al utilizării de zi cu zi.
Când testăm ceva, ne punem o întrebare simplă: „funcționează așa cum ne așteptăm?” sau, cu alte cuvinte: comportamentul real al obiectului de testare se potrivește așteptărilor noastre? Dacă răspunsul este pozitiv, grozav, dacă nu, am fost înșelați în așteptările noastre, ceea ce înseamnă că ceva trebuie corectat.
Testarea este necesară pentru că toți facem greșeli. Unele dintre ele pot fi minore, în timp ce altele pot avea cele mai devastatoare consecințe. Tot ceea ce este produs de om poate conține erori (așa suntem proiectați noi, oamenii). Acesta este motivul pentru care orice produs trebuie verificat - testat înainte de a putea fi utilizat eficient și în siguranță.
Același lucru este valabil și pentru software.
Software – programe de calculator, funcții, precum și documentația și datele însoțitoare legate de funcționarea unui sistem informatic.
Tehnologiile informatice pătrund din ce în ce mai adânc în viața noastră de zi cu zi. Software-ul controlează funcționarea multor lucruri din jurul nostru - de la telefoane mobile și computere până la mașini de spălat și carduri de credit. În orice caz, cu toții am întâlnit una sau alta eroare în program: un editor de text care se blochează în timp ce lucrează la un proiect de teză, un bancomat care „mâncă” un card sau pur și simplu un site web care nu se va încărca - toate acestea nu ne ușurează viața.
Cu toate acestea, nu toate erorile sunt la fel de periculoase – nivelurile de risc pot diferi pentru diferite sisteme software.
Risc:
– un factor care poate duce la consecințe negative în viitor; de regulă, se exprimă în termeni de probabilitate de apariție a unor astfel de consecințe și impactul acestora asupra sistemului.
– ceva ce nu s-a întâmplat încă și s-ar putea să nu se întâmple deloc; potenţială problemă.
În plus, nivelul de risc va depinde de probabilitatea apariției unor consecințe negative.
De exemplu, aceeași eroare minoră, să zicem o greșeală de scriere, poate avea niveluri de risc complet diferite pentru diferite programe:
– o greșeală de tipar în descrierea intereselor pe o pagină personală de pe o rețea de socializare este puțin probabil să aibă consecințe semnificative, cu excepția faptului că îți va face prietenii să zâmbească;
– aceeași greșeală simplă făcută în descrierea activităților unei mari companii postată pe site-ul său este deja periculoasă, deoarece indică indirect neprofesionalismul angajaților săi;
- o greșeală de tipar în codul programului care calculează nivelurile de radiații atunci când se utilizează un aparat cu raze X (de exemplu, 100 în loc de 10) poate avea cele mai grave consecințe - prejudiciul cauzat sănătății și siguranței oamenilor va duce la o pierdere de încredere în companie și procese cu multe zerouri.

| Planificarea lecțiilor pentru anul școlar | Etapele principale ale modelării

Lectia 2
Etapele principale ale modelării

După ce ați studiat acest subiect, veți învăța:

Ce este modelarea;
- ce poate servi drept prototip pentru modelare;
- ce loc ocupă modelajul în activitatea umană;
- care sunt principalele etape ale modelării;
- ce este un model de calculator;
- Ce este un experiment pe calculator?

Experiment pe calculator

Pentru a da viață noilor dezvoltări de design, pentru a introduce noi soluții tehnice în producție sau pentru a testa idei noi, este nevoie de un experiment. Un experiment este o experiență care se realizează cu un obiect sau model. Constă în efectuarea anumitor acțiuni și determinarea modului în care eșantionul experimental reacționează la aceste acțiuni.

La școală faci experimente în lecții de biologie, chimie, fizică și geografie.

Experimentele sunt efectuate atunci când se testează mostre de produse noi la întreprinderi. De obicei, pentru aceasta se folosește o instalație special creată, care permite efectuarea unui experiment în condiții de laborator, sau produsul real în sine este supus la tot felul de teste (experiment la scară completă). Pentru a studia, de exemplu, proprietățile de funcționare ale oricărei unități sau componente, acesta este plasat într-un termostat, înghețat în camere speciale, testat pe suporturi de vibrații, scăpat etc. Este bine dacă este un ceas nou sau un aspirator - pierderea este nu grozav când este distrus. Dacă este un avion sau o rachetă?

Experimentele de laborator și de teren necesită costuri mari de materiale și timp, dar semnificația lor este totuși foarte mare.

Odată cu dezvoltarea tehnologiei informatice, a apărut o nouă metodă unică de cercetare - un experiment pe computer. În multe cazuri, studiile computerizate ale modelelor au venit în ajutor și uneori chiar înlocuiesc mostrele experimentale și bancurile de testare. Etapa de realizare a unui experiment pe calculator include două etape: elaborarea unui plan de experiment și efectuarea cercetării.

Plan experimental

Planul experimental trebuie să reflecte în mod clar succesiunea de lucru cu modelul. Primul punct al unui astfel de plan este întotdeauna testarea modelului.

Testarea este procesul de verificare a corectitudinii modelului construit.

Un test este un set de date inițiale care permit să se determine corectitudinea construcției modelului.

Pentru a fi sigur de corectitudinea rezultatelor modelării obţinute, trebuie să: ♦ să verificaţi algoritmul dezvoltat pentru construirea modelului; ♦ asigurați-vă că modelul construit reflectă corect proprietățile originalului care au fost luate în considerare în timpul modelării.

Pentru a verifica corectitudinea algoritmului de construcție a modelului, se folosește un set de test de date inițiale, pentru care rezultatul final este cunoscut în prealabil sau predeterminat în alte moduri.

De exemplu, dacă utilizați formule de calcul în modelare, atunci trebuie să selectați mai multe opțiuni pentru datele inițiale și să le calculați „manual”. Acestea sunt sarcini de testare. Odată construit modelul, testați cu aceleași variații ale datelor de intrare și comparați rezultatele simulării cu concluziile obținute prin calcul. Dacă rezultatele coincid, atunci algoritmul este dezvoltat corect; dacă nu, trebuie să căutăm și să eliminăm motivul discrepanței lor. Este posibil ca datele de testare să nu reflecte deloc situația reală și să nu aibă niciun conținut semantic. Cu toate acestea, rezultatele obținute în timpul procesului de testare vă pot determina să vă gândiți la schimbarea informațiilor originale sau a modelului simbolic, în primul rând în partea în care este încorporat conținutul semantic.

Pentru a vă asigura că modelul construit reflectă proprietățile originalului care au fost luate în considerare în timpul modelării, este necesar să selectați un exemplu de testare cu date sursă reale.

Efectuarea de cercetări

După testare, când aveți încredere în corectitudinea modelului construit, puteți trece direct la efectuarea cercetării.

Planul trebuie să includă un experiment sau o serie de experimente care să satisfacă obiectivele modelării. Fiecare experiment trebuie să fie însoțit de o înțelegere a rezultatelor, care servește drept bază pentru analizarea rezultatelor modelării și luarea deciziilor.

Schema de pregătire și desfășurare a unui experiment pe calculator este prezentată în Figura 11.7.

Orez. 11.7. Schema de experimente pe calculator

Analiza rezultatelor simulării

Scopul final al modelării este luarea unei decizii, care ar trebui luată pe baza unei analize cuprinzătoare a rezultatelor modelării. Această etapă este decisivă – fie continui cercetarea, fie o termini. Figura 11.2 arată că etapa de analiză a rezultatelor nu poate exista independent. Descoperirile contribuie adesea la realizarea unei serii suplimentare de experimente și, uneori, la schimbarea problemei.

Baza pentru dezvoltarea unei soluții sunt rezultatele testelor și experimentelor. Dacă rezultatele nu corespund obiectivelor sarcinii, înseamnă că au fost făcute greșeli în etapele anterioare. Aceasta poate fi fie o formulare incorectă a problemei, fie o construcție prea simplificată a unui model de informații, fie o alegere nereușită a unei metode sau a unui mediu de modelare, fie o încălcare a tehnicilor tehnologice la construirea unui model. Dacă sunt identificate astfel de erori, atunci modelul trebuie ajustat, adică revenirea la una dintre etapele anterioare. Procesul se repetă până când rezultatele experimentale ating obiectivele modelării.

Principalul lucru este să vă amintiți întotdeauna: o eroare identificată este și un rezultat. După cum spune înțelepciunea populară, înveți din greșeli. Marele poet rus A. S. Pușkin a mai scris despre asta:

O, câte descoperiri minunate ne sunt pregătite de spiritul iluminării Și experienței, fiul greșelilor grele, Și geniul, prieten al paradoxurilor, Și întâmplării, Dumnezeule inventatorul...

Testați întrebări și sarcini

1. Numiți cele două tipuri principale de probleme de modelare.

2. În celebra „Cartea problemelor” de G. Oster există următoarea problemă:

Vrăjitoarea rea, lucrând neobosit, transformă 30 de prințese pe zi în omizi. Câte zile îi vor lua pentru a transforma 810 de prințese în omizi? Câte prințese vor trebui transformate în omizi pe zi pentru a finaliza treaba în 15 zile?
Care întrebare poate fi clasificată ca tipul „ce se va întâmpla dacă...” și care întrebare poate fi clasificată ca „cum se poate face asta...”?

3. Enumerați cele mai cunoscute scopuri ale modelării.

4. Formalizați problema umoristică din „Cartea problemelor” a lui G. Oster:

Din două cabine situate la o distanță de 27 km unul de celălalt, doi câini luptători au sărit unul spre celălalt în același timp. Primul rulează cu o viteză de 4 km/h, iar al doilea cu 5 km/h.
Cât va dura până să înceapă lupta?

5. Numiți cât mai multe caracteristici ale obiectului „pereche de pantofi”. Creați un model de informații al unui obiect în diferite scopuri:

■ alegerea pantofilor pentru drumeții; ■ alegerea unei cutii de pantofi potrivite; ■ achiziționarea cremei de îngrijire a pantofilor.

6. Ce caracteristici ale unui adolescent sunt importante pentru recomandări privind alegerea unei profesii?

7. Din ce motive este computerul utilizat pe scară largă în modelare?

8. Numiți instrumentele de modelare pe computer pe care le cunoașteți.

9. Ce este un experiment pe calculator? Dă un exemplu.

10. Ce este testarea modelului?

11. Ce erori apar în timpul procesului de modelare? Ce ar trebui să faceți când se descoperă o eroare?

12. Ce este analiza rezultatelor simulării? Ce concluzii se trag de obicei?