Testare cutie alba

Testare de utilizare

A) Testarea sarcinii

Test de performanta

Testare funcțională

Testare software

Testarea este procesul de executare a unui program (sau a unei părți a unui program) cu intenția (sau scopul) de a găsi erori.

Există mai multe criterii după care se obișnuiește să se clasifice tipurile de testare. De obicei, se disting următoarele semne:

I) După obiectul încercării:

(determinarea sau colectarea indicatorilor de performanță și timp de răspuns a unui sistem software și hardware sau dispozitiv ca răspuns la o solicitare externă pentru a stabili conformitatea cu cerințele pentru acest sistem)

b) Testarea de stres

(evaluează fiabilitatea și stabilitatea sistemului în condiții de depășire a limitelor de funcționare normală.)

c) Testarea de stabilitate

4) Testarea interfeței cu utilizatorul

5) Testare de securitate

6) Testare de localizare

7) Testare de compatibilitate

II) Prin cunoaşterea sistemului:

1) Testarea cutiei negre

(este testat un obiect, a cărui structură internă este necunoscută)

(se verifică structura internă a programului, datele de testare se obțin prin analiza logicii programului)

III) După gradul de automatizare:

1) Testare manuală

2) Testare automată

3) Testare semi-automatizată

IV) După gradul de izolare a componentelor:

1) Testarea componentelor (unității).

2) Testarea integrării

3) Testarea sistemului

V) Până la momentul testării:

1) Testarea alfa- un proces închis de testare a programului de către dezvoltatori sau testeri cu normă întreagă. Un produs alfa este cel mai adesea complet doar 50%, există un cod de program, dar lipsește o parte semnificativă a designului.

2) Testare beta- utilizare intensă versiunea terminată programe pentru a identifica numărul maxim de erori în activitatea sa pentru eliminarea ulterioară a acestora înainte de intrarea definitivă pe piață, către consumatorul de masă. Voluntari din rândul viitorilor utilizatori obișnuiți sunt implicați în testare.

Verificarea software-ului este un concept mai general decât testarea. Scopul verificării este de a obține asigurarea că obiectul care este verificat (cerințe sau cod de program) îndeplinește cerințele, este implementat fără funcții nedorite și îndeplinește specificațiile și standardele de proiectare ( ISO 9000-2000). Procesul de verificare include inspecții, testarea codurilor, analiza rezultatelor testelor, generarea și analiza rapoartelor de probleme. Astfel, este în general acceptat că procesul de testare este parte integrantă procesul de verificare.

Saint Petersburg

Universitatea Electrotehnică de Stat

Departamentul MOEM

prin disciplina

„Procesul de dezvoltare software”

„Verificare software”

St.Petersburg

Scopul verificării………………………………………………………………… pagina 3

Observații introductive……………………………………………………………………….. pagina 3

Ținte speciale și generale………………………………………….. pagina 4

Practică așteptată pe ținte……………………………………… pagina 4

SG1 Pregătirea pentru verificare……………………………………………………………. pagina 4

SG2 Efectuarea examinărilor (evaluarea de la egal la egal)………………………… pagina 7

SG3 Implementarea verificării…………………………………………………………. pagina 9

Anexa 1. Prezentare generală a instrumentelor de automatizare pentru procesul de verificare……….. pagina 11

Anexa 2. Principala abordări moderne la verificare…………….. pagina 12

Lista literaturii utilizate……………………………………………………….. pagina 14

Un model integrat de excelență și maturitate

Verificare (Nivelul de maturitate 3)

Ţintă

Scopul verificării este oferind asigurarea că middleware-ul sau produsul final selectat îndeplinește cerințele specificate.

1. note de apă

Verificarea produselor software este verificarea produsului finit sau a versiunilor sale intermediare pentru a îndeplini cerințele inițiale. Aceasta presupune nu numai testarea programului în sine, ci și auditarea proiectului, a documentației utilizator și tehnică etc.

Scopul verificării sistemului software este de a identifica și raporta erorile care pot fi făcute în timpul etapelor ciclului de viață. Principalele sarcini de verificare:

determinarea conformității cerințelor de nivel înalt cu cerințele de sistem;

luarea în considerare a cerințelor de nivel înalt în arhitectura sistemului;

conformitatea cu arhitectura și cerințele pentru aceasta în codul sursă;

determinarea conformității codului executabil cu cerințele pentru sistem;

determinarea mijloacelor folosite pentru rezolvarea sarcinilor de mai sus, care sunt corecte din punct de vedere tehnic și suficient de complete.

Verificarea include verificarea produselor finite și verificarea produselor intermediare în raport cu toate cerințele selectate, inclusiv cerințele clienților, cerințele pentru produsele finite și cerințele pentru componentele sale individuale.

Verificarea este în mod inerent un proces incremental (incremental) din momentul începerii sale, pe parcursul dezvoltării produselor și a întregii lucrări asupra produselor. Verificarea începe cu verificarea cerințelor, apoi urmează verificarea tuturor produselor intermediare în diferite etape ale dezvoltării și fabricării acestora și se termină cu verificarea produsului final.

Verificarea produselor intermediare în fiecare etapă a dezvoltării și fabricării lor crește semnificativ probabilitatea ca produsul final să îndeplinească cerințele clientului, cerințele pentru produsul finit și cerințele pentru componentele sale individuale.

Verificarea și Validarea proceselor sunt procese în mod esențial conexe, având ca scop, totuși, obținerea de rezultate diferite. Scopul validării este de a demonstra că produsul finit își îndeplinește de fapt scopul inițial. Verificarea are ca scop să se asigure că produsul îndeplinește exact anumite cerințe. Cu alte cuvinte, Verificarea asigură că „ o faci corect”, iar validarea este că „ faci ceea ce trebuie”.

Verificarea ar trebui implementată cât mai devreme posibil în procesele relevante (cum ar fi livrarea, dezvoltarea, operarea sau întreținerea) pentru a evalua rentabilitatea și performanța. Acest proces poate include analiză, verificare și testare (testare).

Acest proces poate fi realizat cu diferite grade de independență a interpreților. Gradul de independență al artiștilor interpreți poate fi distribuit atât între diferite entități din organizația propriu-zisă, cât și entități din altă organizație, cu grade diferite de repartizare a responsabilităților. Acest proces se numește proces verificare independentă dacă organizația de implementare este independentă de vânzător, dezvoltator, operator sau întreținător.

Evaluări ale experților (expertiză) reprezintă o parte importantă a verificării ca instrument bine stabilit pentru eliminarea eficientă a defectelor. O concluzie importantă din aceasta este necesitatea de a dezvolta o înțelegere și o înțelegere mai profundă a versiunilor de lucru ale produsului, precum și a fluxurilor de lucru utilizate pentru a identifica posibilele defecte și pentru a crea o oportunitate pentru îmbunătățiri, dacă este necesar.

Examinările includ un studiu metodic al muncii efectuate de experți pentru a identifica defectele și alte modificări necesare.

Principalele metode de evaluare a experților sunt:

inspecţie

control structural de la capăt la capăt

Cele două concepte de validare și verificare sunt adesea confundate. În plus, validarea cerințelor de sistem este adesea confundată cu validarea sistemului. Vă sugerez să analizați această problemă.

În articol, am luat în considerare două abordări ale modelării obiectelor: ca întreg și ca structură. În articolul actual, vom avea nevoie de această diviziune.

Să presupunem că avem un obiect funcțional proiectat. Fie ca acest obiect să fie considerat de noi ca o parte a construcției unui alt Obiect funcțional. Să existe o descriere a construcției Obiectului, astfel încât să conțină o descriere a obiectului. Într-o astfel de descriere, obiectul are o descriere ca un întreg, adică interfețele sale de interacțiune cu alte obiecte sunt descrise în cadrul construcției Obiectului. Să fie dată descrierea obiectului ca structură. Să existe un obiect informațional care să conțină cerințe pentru proiectarea descrierii obiectului ca structură. Să existe un corp de cunoștințe care conține reguli de inferență, pe baza cărora se obține o descriere a obiectului ca structură din descrierea obiectului ca întreg. Corpul de cunoștințe este ceea ce designerii sunt predați în institute - multe, multe cunoștințe. Ele permit, pe baza cunoștințelor despre obiect, proiectarea structurii acestuia.

Deci, puteți începe. Putem afirma că dacă obiectul în ansamblu este corect descris, dacă corpul de cunoștințe este corect și dacă regulile de inferență au fost respectate, atunci descrierea rezultată a construcției obiectului va fi corectă. Adică, pe baza acestei descrieri, un obiect funcțional corespunzător conditii reale Operațiune. Ce riscuri pot apărea:

1. Utilizarea cunoștințelor incorecte despre Obiect. Modelul Obiectului din mintea oamenilor poate să nu corespundă realității. Ei nu cunoșteau pericolul real al cutremurelor, de exemplu. În consecință, cerințele pentru obiect pot fi formulate incorect.

2. Înregistrare incompletă a cunoștințelor despre Obiect - ceva este omis, se fac greșeli. De exemplu, știau despre vânturi, dar au uitat să menționeze. Acest lucru poate duce la o descriere insuficient de completă a cerințelor pentru obiect.

3. Corp greșit de cunoștințe. Ni s-a învățat prioritatea masei față de alți parametri, dar s-a dovedit că trebuie să creștem viteza.

4. Aplicarea incorectă a regulilor de inferență la descrierea obiectului. Erori logice, ceva lipsește în cerințele pentru proiectarea obiectului, urma cerințelor este ruptă.

5. Înregistrare incompletă a concluziilor obținute despre proiectarea sistemului. Totul a fost luat în calcul, totul a fost calculat, dar au uitat să scrie.

6. Sistemul creat nu corespunde descrierii.

Este clar că toate artefactele proiectului apar, de regulă, în forma lor completată numai până la sfârșitul proiectului și chiar și atunci nu întotdeauna. Dar, dacă presupunem că dezvoltarea este în cascadă, atunci riscurile sunt așa cum am descris. Verificarea fiecărui risc este o operațiune specifică căreia i se poate da un nume. Dacă cineva este interesat, puteți încerca să veniți cu și să exprimați acești termeni.

Ce este verificarea? În rusă, verificarea este o verificare a conformității cu regulile. Regulile sunt sub forma unui document. Adică ar trebui să existe un document cu cerințe de documentare. Dacă documentația îndeplinește cerințele acestui document, atunci a trecut verificarea.

Ce este validarea? În limba rusă, validarea este verificarea corectitudinii concluziilor. Adică, ar trebui să existe un corp de cunoștințe care să descrie cum să obțineți o descriere a unui design bazat pe datele obiectului. Verificarea corectitudinii aplicării acestor concluzii este validare. Validarea înseamnă, printre altele, verificarea consecvenței, completitudinii și inteligibilității descrierii.

Validarea cerințelor este adesea confundată cu validarea unui produs construit pe acele cerințe. Nu merită să faci asta.

echipa include mai mult de două persoane ridică inevitabil problema repartizării rolurilor, drepturilor și responsabilităților în echipă. Un set specific de roluri este determinat de mulți factori - numărul de participanți la dezvoltare și preferințele lor personale, metodologia de dezvoltare adoptată, caracteristicile proiectului și alți factori. În aproape orice echipă de dezvoltare, se pot distinge următoarele roluri. Unele dintre ele pot fi complet absente, în timp ce persoanele individuale pot îndeplini mai multe roluri simultan, dar compoziția generală se schimbă puțin.

Client (solicitant). Acest rol revine unui reprezentant al organizației care a ordonat dezvoltarea sistemului. De obicei, solicitantul este limitat în interacțiunea lor și comunică numai cu managerii de proiect și cu un specialist în certificare sau implementare. De obicei, clientul are dreptul de a modifica cerințele pentru produs (numai în cooperare cu managerii), de a citi documentația de proiectare și certificare care afectează caracteristicile non-tehnice ale sistemului în curs de dezvoltare.

Manager de proiect. Acest rol oferă un canal de comunicare între client și echipa de proiect. Managerul de produs gestionează așteptările clientului și dezvoltă și menține contextul de afaceri pentru proiect. Munca lui nu este direct legată de vânzare, el este concentrat pe produs, sarcina lui este să definească și să furnizeze cerintele clientului. Managerul de proiect are dreptul de a modifica cerințele pentru produs și documentația finală pentru produs.

Manager de program. Acest rol gestionează comunicațiile și relațiile în cadrul echipei de proiect, acționează ca coordonator într-un fel, dezvoltă și gestionează specificațiile funcționale, menține programul proiectului și raportează starea proiectului și inițiază decizii critice pentru proiect.

Testare- procesul de executare a unui program pentru a detecta o eroare.

date de testare- intrări care sunt folosite pentru a testa sistemul.

Situație de testare (caz de testare)- intrări pentru testarea sistemului și ieșirile așteptate în funcție de intrări, dacă sistemul funcționează în conformitate cu specificația cerințelor.

Caz de testare bun- o situație care are o probabilitate mare de a detecta o eroare încă nedetectată.

test norocos- un test care detectează o eroare încă nedetectată.

Eroare- acțiunea unui programator în stadiul de dezvoltare, ducând la faptul că software-ul conține un defect intern, care, în timpul funcționării programului, poate duce la un rezultat incorect.

Refuz- comportament imprevizibil al sistemului, care duce la un rezultat neașteptat, care ar putea fi cauzat de defectele conținute în acesta.

Astfel, în procesul de testare a software-ului, de regulă, sunt verificate următoarele.

Verificare si validare ( verificare si validare-V& v) sunt concepute pentru a analiza, verifica executarea corectă și conformitatea software-ului cu specificațiile și cerințele clientului. Aceste metode de verificare a corectitudinii programelor și respectiv sistemelor înseamnă:

• verificarea este verificarea corectitudinii creării sistemului în conformitate cu specificațiile acestuia;
• Validarea este o verificare a corectitudinii îndeplinirii cerințelor specificate pentru sistem.

Verificarea ajută la tragerea unei concluzii despre corectitudinea sistemului creat după finalizarea proiectării și dezvoltării acestuia. Validarea vă permite să stabiliți fezabilitatea cerințelor specificate și include o serie de acțiuni pentru obținerea programelor și sistemelor corecte, și anume:

• planificarea procedurilor de inspecție și control decizii de proiectareși cerințe;
• asigurarea nivelului de automatizare a proiectării programelor prin intermediul CASE;
• verificarea functionarii corecte a programelor prin testarea metodelor pe seturi de teste tinta;
• adaptarea produsului la mediul de operare etc.

Validarea realizează aceste activități prin revizuirea și inspectarea specificațiilor și a rezultatelor proiectării în etapele ciclului de viață pentru a confirma că există o implementare corectă a cerințelor inițiale și că sunt îndeplinite condițiile și constrângerile specificate. Sarcinile de verificare și validare includ verificarea completității, consecvenței și lipsei de ambiguitate a specificației cerințelor și a corectitudinii performanței funcțiilor sistemului.

Verificarea și validarea sunt supuse:

• principalele componente ale sistemului;
• interfețe de componente (software, tehnice și informaționale) și interacțiuni ale obiectelor (protocoale și mesaje) care asigură implementarea sistemului în medii distribuite;
• mijloace de acces la baza de date și fișiere (tranzacții și mesaje) și verificarea mijloacelor de protecție împotriva accesului neautorizat la datele diferiților utilizatori;
• documentație pentru software și pentru sistem în ansamblu;
• teste, proceduri de testare și date de intrare.

Cu alte cuvinte, principalele metode sistematice de corectitudine a programelor sunt:

• verificare validarea specificațiilor componentelor și cerințelor PS;
• inspectie PS să stabilească conformitatea programului cu specificațiile date;
• testarea codul de ieșire al PS pe datele de testare într-un mediu de operare specific pentru a identifica erorile și defecte cauzate de diverse defecte, anomalii, defecțiuni ale echipamentelor sau blocări ale sistemului (vezi Capitolul 9).

ISO/IEC 3918-99 și 12207 includ procese de verificare și validare. Pentru ei, obiectivele, sarcinile și acțiunile sunt definite pentru a verifica corectitudinea produsului creat (inclusiv produse de lucru, intermediare) în etapele ciclului de viață și conformitatea cu cerințele acestuia.

Sarcina principală a proceselor de verificare și validare este de a verifica si confirma că software-ul final este adecvat scopului și satisface cerințele clientului. Aceste procese vă permit să identificați erorile în produsele de lucru ale etapelor ciclului de viață, fără a afla motivele apariției acestora, precum și să stabiliți corectitudinea software-ului în raport cu specificația acestuia.

Aceste procese sunt interconectate și sunt definite printr-un singur termen - „verificare și validare” (V&V 7).

Verificarea se efectuează:

• verificarea corectitudinii traducerii componentelor individuale în codul de ieșire, precum și descrierilor interfeței prin urmărirea relațiilor dintre componente în conformitate cu cerințele specificate ale clientului;
• analiza corectitudinii accesului la fișiere sau la o bază de date, ținând cont de procedurile adoptate în instrumentele de sistem utilizate pentru manipularea datelor și transmiterea rezultatelor;
• verificarea mijloacelor de protecție a componentelor pentru conformitatea cu cerințele clienților și urmărirea acestora.

După verificarea componentelor individuale ale sistemului, se realizează integrarea acestora, precum și verificarea și validarea sistemului integrat. Sistemul este testat pe o multitudine de suite de testare pentru a determina dacă suitele de testare sunt adecvate și suficiente pentru a finaliza testul și a stabili corectitudinea sistemului.

Ideea creării unui proiect internațional de verificare formală a fost propusă de T. Hoare, a fost discutată la un simpozion despre software verificat în februarie 2005 în California. Apoi, în octombrie același an, la conferința IFIP de la Zurich, a fost adoptat un proiect internațional pentru o perioadă de 15 ani pentru a dezvolta un „set holistic automatizat de instrumente pentru verificarea corectitudinii PS”.

Acesta a formulat următoarele sarcini principale:

• dezvoltarea unei teorii unificate a construcției și analizei programelor;
• construirea unui set cuprinzător integrat de instrumente de verificare pentru toate etapele de producție, inclusiv dezvoltarea specificațiilor și verificarea acestora, generarea de cazuri de testare, rafinarea, analiza și verificarea programelor;
• crearea unui depozit de specificații formale și obiecte software verificate tipuri diferiteși tipuri.

Acest proiect presupune că verificarea va acoperi toate aspectele creării și verificării corectitudinii software-ului și va deveni un panaceu pentru toate problemele asociate cu apariția constantă a erorilor în programele create.

Multe metode formale de demonstrare și verificare a programelor specificate au fost testate în practică. Terminat mare treabă comitetul internațional ISO/IEC în cadrul Standardul ISO/ IEC 12207:2002 privind standardizarea proceselor de verificare și validare a software-ului. Verificarea corectitudinii prin metode formale a diferitelor obiecte de programare este promițătoare.

Depozitul este un depozit de programe, specificații și instrumente utilizate în dezvoltarea și testarea, evaluarea componentelor finite, unelte și semifabricate de metodă. Are următoarele sarcini generale:

• acumularea de specificații verificate, metode de probă, obiecte de program și implementări de cod pentru aplicații complexe;
• acumularea diferitelor metode de verificare, proiectarea lor într-o formă adecvată pentru căutarea și selectarea unei idei teoretice realizate pentru aplicare ulterioară;
• dezvoltarea de formulare standard pentru stabilirea și schimbul de specificații formale ale diferitelor obiecte de programare, precum și instrumente și sisteme gata făcute;
• dezvoltarea de mecanisme de interoperabilitate și interacțiune pentru transferul produselor finite verificate din depozit în noi medii distribuite și de rețea pentru a crea noi PS-uri.

Acest proiect ar trebui să fie dezvoltat în 50 de ani. Proiectele anterioare și-au propus obiective similare: îmbunătățirea calității software-ului, formalizarea modelelor de servicii, reducerea complexității prin utilizarea PIC-urilor, crearea de instrumente de depanare pentru diagnosticarea vizuală a erorilor și eliminarea acestora etc. Cu toate acestea, o schimbare fundamentală în programare nu a avut loc nici în sensul de depanare vizuală sau în realizarea Calitate superioară PE. Procesul de dezvoltare continuă.

Un nou proiect internațional de verificare a software-ului necesită de la participanții săi nu numai cunoștințe aspecte teoretice specificațiile programului, dar și programatori cu înaltă calificare pentru implementarea acestuia în următorii ani.