Acasă › Instalare și configurare › Testarea produselor software. Cum se verifică funcționalitatea unei funcții care utilizează alte funcții în ea? Schimbați testele legate

Testarea produselor software. Cum se verifică funcționalitatea unei funcții care utilizează alte funcții în ea? Schimbați testele legate

Chiar dacă sunteți atât de tolerant încât puteți reporni programul de 18 ori după o defecțiune în decurs de o jumătate de oră și abia după aceea aruncați monitorul exact în fereastră, veți fi de acord că lucrul cu acest program ar fi mai confortabil dacă nu ar fi " cad” .

Cum să faci astfel încât cazurile de cădere, îngheț, neefectuarea acțiunilor necesare din programul dezvoltat de tine să devină foarte rare?

Nu există un răspuns exact la această întrebare. Dar de secole, cei mai înțelepți oameni de știință s-au gândit la asta de ani de zile și, cu toate acestea, au reușit să găsească un remediu care, dacă nu elimină toate erorile de program, atunci măcar creează iluzia activității pentru a le elimina.

Și acest instrument se numește Testarea produselor software.

Potrivit oamenilor înțelepți, testarea este una dintre cele mai stabilite modalități de a asigura calitatea dezvoltării. softwareși este inclus într-un set de instrumente eficiente sistem modern asigurarea calității produselor software.

Calitatea unui produs software este caracterizată printr-un set de proprietăți care determină cât de „bun” este produsul din punctul de vedere al părților interesate, cum ar fi clientul produsului, sponsorul, utilizatorul final, dezvoltatorii și testerii de produse, suport ingineri, oameni de marketing, instruire și vânzări. Fiecare dintre participanți poate avea o idee diferită despre produs și cât de bun sau rău este acesta, adică cât de înaltă este calitatea produsului. Astfel, formularea problemei asigurării calității produsului are ca rezultat sarcina de a identifica părțile interesate, criteriile lor de calitate și apoi găsirea soluției optime care să îndeplinească aceste criterii.

Când și cine?

Potrivit dezvoltatorilor experimentați, testarea unui produs software ar trebui să fie efectuată chiar de la începutul creării sale. Dar, în același timp, dezvoltatorii experimentați nu ar trebui să ia parte la testare, deoarece aceasta nu este o afacere regală. Angajații special instruiți, numiți testeri, ar trebui să testeze produsul software, pentru că nici cel mai experimentat dezvoltator nu își va putea vedea greșeala, nici măcar folosind cele mai noi instrumente optice.

Cu toate acestea, toți dezvoltatorii sunt de acord că testarea unui produs software în ceea ce privește clasificarea în funcție de obiective ar trebui împărțită în două clase:

Testare funcțională
Testare nefuncțională

Testare funcțională

Testarea funcțională este înțeleasă ca verificarea conformității unui produs software cu cerințele funcționale specificate în termenii de referință pentru crearea acestui produs. Pentru a spune simplu, testarea funcțională verifică dacă produsul software îndeplinește toate funcțiile pe care ar trebui.

Deci, ați decis să efectuați teste funcționale. Te uiți la termenii de referință, citești cerințele funcționale și înțelegi că cel puțin nu sunt în ordinea în care poți testa. Veți fi surprinși că cu mult timp în urmă, alții au observat deja această discrepanță și și-au dat seama cum să o depășească.

Pentru a efectua testarea funcțională, personalul departamentului de control tehnic elaborează un program de documente și o metodă de testare a funcționalității aplicației (API). Documentul PMI conține o listă de scenarii de testare a produselor software (cazuri de testare) cu descriere detaliata trepte. Fiecare pas al scenariului de testare este caracterizat de acțiunile utilizatorului (specialist în testare) și de rezultatele așteptate - răspunsul programului la aceste acțiuni. Programul și metodologia de testare trebuie să simuleze funcționarea produsului software în mod real. Aceasta înseamnă că scriptul de testare ar trebui să fie construit pe baza unei analize a operațiunilor pe care viitorii utilizatori ai sistemului le vor efectua și nu trebuie să fie o secvență de manipulări compilată artificial, care să fie înțeles doar de dezvoltator.

De obicei, testarea funcțională este efectuată la două niveluri:

Testarea componentelor (unității). Testarea componentelor individuale ale unui produs software, axată pe specificul, scopul și caracteristicile funcționale ale acestora.
Testarea integrării. Acest tip testarea se efectuează după testarea componentelor și are ca scop identificarea defectelor în interacțiunea diferitelor subsisteme la nivelul fluxurilor de control și schimbului de date.

Testare nefuncțională

Testarea nefuncțională evaluează astfel de calități ale unui produs software, cum ar fi, de exemplu, ergonomia sau performanța.

Cred că importanța acestui tip de testare este clară și nu necesită justificare. La urma urmei, toată lumea înțelege că, dacă, de exemplu, performanța sistemului nu este suficientă, atunci utilizatorii vor trebui să aștepte o jumătate de zi pentru un răspuns la acțiunile lor, ceea ce poate duce la hibernarea lor masivă.

După cum sugerează și numele, testarea nefuncțională verifică dacă produsul software îndeplinește cerințele nefuncționale ale termeni de referinta la crearea lui. Și, ca și în cazul testării funcționale, sunt dezvoltate un program și o metodologie de testare pentru testarea nefuncțională.

Testarea și conformitatea software-ului încorporat în era Agile

Respectarea standardelor din industrie nu este ceva pe care îl puteți neglija sau face mai târziu; este o parte integrantă a procesului de dezvoltare a software-ului încorporat (SW). Pentru unele industrii - cum ar fi avionica, auto și asistența medicală - respectarea strictă a standardelor de calitate în dezvoltarea de sisteme integrate complexe și fără probleme devine o condiție vitală pentru introducerea pe piață a unui produs. În mod tradițional, testarea a jucat un rol important în dezvoltarea sistemelor încorporate pentru industriile bazate pe standarde. Cu toate acestea, în ultimii ani, practicile consacrate și procesele de testare, locul și rolul lor în astfel de proiecte s-au schimbat semnificativ. A schimbat dramatic toate regulile jocului, iar atunci când regulile jocului se schimbă, trebuie să le schimbi cu ele pentru a câștiga.

Cu noile tehnologii de ultimă generație în continuă evoluție, companiile trebuie să aducă rapid pe piață produse fiabile, sigure, ușor de utilizat și interoperabile - doar pentru a nu se pierde în ritmul rapid. lumea tehnologiei. Într-o astfel de situație, modelul tradițional în cascadă, în care procesul de dezvoltare a software-ului este strict secvențial și testarea este efectuată chiar la sfârșitul acestuia, devine un lucru din trecut. Metodele DevOps și Agile câștigă popularitate, deoarece le permit inginerilor să efectueze sarcini care se urmau în același timp.

Test de performanta

În faza de testare a performanței, în primul rând, se efectuează testarea la sarcină, al cărei scop este de a verifica dacă sistemul va răspunde în mod adecvat la influențele externe într-un mod apropiat de modul real de funcționare.

Pe lângă testarea la sarcină, testele sunt efectuate în condiții de hardware minim și test de sarcină maximă - stres, precum și teste în condiții de volume maxime de informații prelucrate - testare de volum.

Există un alt tip de testare: testarea de stabilitate și fiabilitate, care include nu numai o testare pe termen lung a unui produs software în condiții normale, ci și capacitatea acestuia de a reveni la funcționarea normală după perioade scurte de solicitări.

Documentatie pentru testare

După cum sa menționat mai sus, testarea este efectuată în conformitate cu programul și metodologia de testare, care este dezvoltată în conformitate cu GOST 34.603-92.

Dezvoltat pentru testare caz de testare, care ar trebui să conțină suficiente date pentru a verifica toate modurile de funcționare ale produsului software. De obicei, un caz de testare este creat în comun de către client și antreprenor pe baza datelor reale.

Pentru a efectua toate tipurile de teste de performanță, cel mai adesea este creat un așa-numit generator de date, care vă permite mod automat creați suficiente date pentru a obține un rezultat obiectiv la evaluarea performanței.

În timpul testării, se întocmește un protocol de testare, în care se introduc informații privind parcurgerea tuturor etapelor și etapelor testării și comentariile primite în timpul testelor.

Dacă rezultatul testului este negativ, deficiențele sunt corectate și retestate.

Testare exploratorie

Testarea exploratorie (testarea ad-hoc este o subspecie a testării funcționale. Este folosită în proiecte cu creștere rapidă, cu metode de dezvoltare flexibile, unde nu există documentație și cerințe clare. Testarea exploratorie este punctul culminant al testării software. Sunt disponibile teste de înaltă calitate. la specialiști cu înaltă calificare și depinde aproape în totalitate de performer, experiența lui, cunoștințele (atât în domeniu, cât și în metodele de testare), capacitatea de a pătrunde rapid în esență.

Testare stresanta

Testarea la sarcină este procesul de analiză a performanței sistemului testat sub influența sarcinilor. Scopul testării sarcinii este de a determina capacitatea unei aplicații de a rezista la sarcini externe. De obicei, testele sunt efectuate în mai multe etape.

1. Generarea scenariilor de testare

Pentru o analiză eficientă, scenariile ar trebui să fie cât mai apropiate de cazurile reale de utilizare. Este important să înțelegeți că excepții sunt întotdeauna posibile și chiar și cel mai detaliat plan de testare poate să nu acopere un singur caz.

2. Dezvoltarea unei configurații de testare

Având scenarii de testare, este important să se distribuie ordinea creșterii sarcinii. Pentru o analiză de succes este necesară evidențierea criteriilor de evaluare a performanței (viteza de răspuns, timpul de procesare a cererii etc.).

3. Efectuarea unui test de testare

Când efectuați teste, este important să monitorizați în timp util execuția scripturilor și răspunsul sistemului testat. Pentru a emula sarcini mari, este necesară o infrastructură hardware și software serioasă. În unele cazuri, metodele de modelare matematică sunt folosite pentru a reduce costul muncii. Datele obținute la sarcini mici sunt luate ca bază și aproximative. Cu cât este mai mare nivelul de sarcină simulată, cu atât este mai mică acuratețea estimării. Cu toate acestea, această metodă reduce semnificativ costurile.

Test de automatizare

Principala caracteristică a testării automate este capacitatea de a efectua rapid teste de regresie. Principalele avantaje ale automatizării (conform raportului Worksoft) sunt eficiența sporită a personalului, detectarea mai devreme a defectelor și multe altele calitate superioară procesele de afaceri. Aceste avantaje sunt compensate de un dezavantaj semnificativ: costul ridicat - din cauza costului ridicat de implementare și întreținere a automatizării testelor, aproximativ 50% dintre companii folosesc încă mai ales testarea manuală.

Testare de utilizare

Fiecare aplicație este creată pentru a fi utilizată. Ușurința de utilizare este un indicator important al calității programului. Industria IT cunoaște multe exemple de proiecte care au decolat după o soluție de succes a utilizării. Cu cât audiența este mai largă, cu atât este mai important factorul de utilizare. Testarea de utilizare implică o analiză detaliată a comportamentului utilizatorului. Pentru a evalua ergonomia, este important să aveți date nu numai despre viteza de finalizare a unei sarcini de afaceri, ci și despre emoțiile utilizatorului, expresiile faciale și timbrul vocii.

Testarea configurației

Testarea configurației oferă încredere că aplicația va funcționa pe diferite platforme, ceea ce înseamnă pentru numărul maxim de utilizatori. Pentru aplicațiile WEB, se alege de obicei testarea compatibilității între browsere. Pentru aplicații Windows - testare pe diverse sisteme de operareși bitness (x86, x64). O componentă importantă a testării configurației este infrastructura de testare: pentru testare, trebuie să mențineți în mod constant o flotă de mașini de testare. Numărul lor variază de la 5 la câteva zeci.

Testarea integrării

Dacă proiectul dvs. are mai multe componente, are nevoie de testare de integrare. Cu o arhitectură de aplicație complexă, o condiție necesară pentru asigurarea calității este verificarea interacțiunii dintre părțile programului. Testarea se realizează prin dezvoltarea și desfășurarea „prin” cazuri. Testarea integrării este efectuată după testarea componentelor. Prin urmare, este foarte important să se țină cont de experiența de testare a componentelor, respectând în același timp orientarea către business a cazurilor de testare.

testare stresanta

Fiecare sistem are o limită functionare normala. Când limita este depășită, sistemul intră într-o stare de stres și își schimbă semnificativ comportamentul. Testarea la stres verifică performanța aplicației în condiții de depășire a limitelor de funcționare normală. Acest lucru este deosebit de important pentru programele „critice”: software bancar, programe din industria aviației și medicină. Testele de stres se desfășoară nu numai în etapa de dezvoltare a software-ului, ci și pe parcursul întregului ciclu de funcționare pentru a obține și prelucra date despre comportamentul sistemului pe o perioadă lungă de timp.

Să presupunem că există o funcție get-data, care returnează o hartă a informațiilor despre id-ul utilizatorului care a transmis. Acum această funcție folosește cele 3 funcții sursă-a, sursă-b și sursă-c pentru a obține trei tipuri diferite de hărți. Acum vom combina toate aceste hărți într-o singură hartă și vom reveni de la get-data.

Când testez get-data, ar trebui să verific existența datelor pentru chei? Are sens ca această funcție să eșueze testele unitare dacă unul dintre sursa-a, sursa-b și sursa-c eșuează? Dacă sarcina acestei funcții este să se alăture datelor și o face, ar trebui să fie suficient, nu?

2 raspunsuri

Să presupunem că există o funcție get-data care returnează o hartă a informațiilor despre id-ul utilizatorului transmis.

Grozav. Atunci ar trebui să verifici. Pentru id-ul dat, returnați datele corecte?

acum această funcție folosește 3 funcții sursă-a, sursă-b și sursă-c pentru a obține 3 tipuri diferite de hărți.

Ce detaliu de implementare ar trebui să ignorați într-un test. Tot ce testați este că unitatea dvs. de lucru (această metodă) face ceea ce trebuie să facă (luați un ID și returnați datele XYZ pentru acel ID). Cum această metodă nu contează cu adevărat - la urma urmei, avantajul cheie al acestui test unitar este că puteți refactoriza implementarea metodei, iar testul va verifica dacă ați procedat corect.

Cu toate acestea, probabil că va trebui să bate joc de sursele de date, așa că la un moment dat testul va trebui probabil să știe cum funcționează acest cod. Aici trebuie să echilibrați trei obiective concurente: să faceți testul izolat (prin batjocorirea datelor), să faceți testul concentrat pe cerințe și pragmatism.

La urma urmei, acesta este un cod important. Există teste pentru a face copii de rezervă ale codului real, a petrece mult timp și necazul de a verifica lustruirea nu este la fel de util ca testele realizarea .

În testarea unitară, ar trebui să testați doar funcționalitatea unei clase, dacă metodele sursă-a, sursă-b și sursă-c apelează alte clase, ar trebui să le batjocoriți (ar trebui să fie testate unitar în clasele lor).

În testarea integrării, testați comportamentul mai multor clase care interacționează între ele, ceea ce înseamnă că funcția dvs. de obținere a datelor trebuie să verifice dacă datele care sunt preluate sunt corecte (sursa-a, sursa-b și sursa-c sunt corecte , iar datele sunt îmbinate corect) .

Testele unitare sunt mai simple și mai concentrate și ar trebui create de dezvoltatori. Testele de integrare devin de obicei învechite relativ repede (dacă există componenta interioara a fost schimbat), deci sunt mai dificil de executat. Trebuie să fie creat de un profil QA.

Cum să faci astfel încât cazurile de cădere, îngheț, neefectuarea acțiunilor necesare din programul dezvoltat de tine să devină foarte rare?

Și acest instrument se numește Testarea produselor software.

Potrivit oamenilor înțelepți, Testarea este una dintre cele mai stabilite modalități de a asigura calitatea dezvoltării software și este inclusă în setul de instrumente eficiente ale unui sistem modern de asigurare a calității software.

Când și cine?

Cu toate acestea, toți dezvoltatorii sunt de acord că testarea unui produs software în ceea ce privește clasificarea în funcție de obiective ar trebui împărțită în două clase:

Testare funcțională
Testare nefuncțională

Testare funcțională

Pentru a efectua testarea funcțională, personalul departamentului de control tehnic elaborează un program de documente și o metodă de testare a funcționalității aplicației (API). Documentul PMI conține o listă de scenarii de testare a produselor software (cazuri de testare) cu o descriere detaliată a pașilor. Fiecare pas al scenariului de testare este caracterizat de acțiunile utilizatorului (specialist în testare) și de rezultatele așteptate - răspunsul programului la aceste acțiuni. Programul și metodologia de testare trebuie să simuleze funcționarea produsului software în mod real. Aceasta înseamnă că scriptul de testare ar trebui să fie construit pe baza unei analize a operațiunilor pe care viitorii utilizatori ai sistemului le vor efectua și nu trebuie să fie o secvență de manipulări compilată artificial, care să fie înțeles doar de dezvoltator.

De obicei, testarea funcțională este efectuată la două niveluri:

Testarea componentelor (unității). Testarea componentelor individuale ale unui produs software, axată pe specificul, scopul și caracteristicile funcționale ale acestora.
Testarea integrării. Acest tip de testare se efectuează după testarea componentelor și are ca scop identificarea defectelor în interacțiunea diferitelor subsisteme la nivelul fluxurilor de control și schimbului de date.

Testare nefuncțională

Testarea nefuncțională evaluează astfel de calități ale unui produs software, cum ar fi, de exemplu, ergonomia sau performanța.

După cum sugerează și numele, testarea nefuncțională verifică conformitatea unui produs software cu cerințele nefuncționale din termenii de referință pentru crearea acestuia. Și, ca și în cazul testării funcționale, sunt dezvoltate un program și o metodologie de testare pentru testarea nefuncțională.

Testarea și conformitatea software-ului încorporat în era Agile

Test de performanta

Documentatie pentru testare

După cum sa menționat mai sus, testarea este efectuată în conformitate cu programul și metodologia de testare, care este dezvoltată în conformitate cu GOST 34.603-92.

Pentru testare, este dezvoltat un caz de testare, care ar trebui să conțină suficiente date pentru a testa toate modurile de funcționare ale produsului software. De obicei, un caz de testare este creat în comun de către client și antreprenor pe baza datelor reale.

Pentru a efectua toate tipurile de testare a performanței, cel mai adesea este creat un așa-numit generator de date, care vă permite să creați automat o cantitate suficientă de date pentru a obține un rezultat obiectiv la evaluarea performanței.

În timpul testării, se întocmește un protocol de testare, în care se introduc informații privind parcurgerea tuturor etapelor și etapelor testării și comentariile primite în timpul testelor.

Dacă rezultatul testului este negativ, deficiențele sunt corectate și retestate.

Testare exploratorie

Testare stresanta

1. Generarea scenariilor de testare

2. Dezvoltarea unei configurații de testare

3. Efectuarea unui test de testare

Test de automatizare

Principala caracteristică a testării automate este capacitatea de a efectua rapid teste de regresie. Principalele avantaje ale automatizării (conform raportului companiei Worksoft) sunt eficiența sporită a personalului, detectarea mai devreme a defectelor și calitatea mai ridicată a proceselor de afaceri. Aceste avantaje sunt compensate de un dezavantaj semnificativ: costul ridicat - din cauza costului ridicat de implementare și întreținere a automatizării testelor, aproximativ 50% dintre companii folosesc încă mai ales testarea manuală.

Testare de utilizare

Testarea configurației

Testarea configurației oferă încredere că aplicația va funcționa pe diferite platforme, ceea ce înseamnă pentru numărul maxim de utilizatori. Pentru aplicațiile WEB, se alege de obicei testarea compatibilității între browsere. Pentru aplicații Windows - testare pe diverse sisteme de operare și bitness (x86, x64). O componentă importantă a testării configurației este infrastructura de testare: pentru testare, trebuie să mențineți în mod constant o flotă de mașini de testare. Numărul lor variază de la 5 la câteva zeci.

Testarea integrării

testare stresanta

Orice sistem are o limită de funcționare normală. Când limita este depășită, sistemul intră într-o stare de stres și își schimbă semnificativ comportamentul. Testarea la stres verifică performanța aplicației în condiții de depășire a limitelor de funcționare normală. Acest lucru este deosebit de important pentru programele „critice”: software bancar, programe din industria aviației și medicină. Testele de stres se desfășoară nu numai în etapa de dezvoltare a software-ului, ci și pe parcursul întregului ciclu de funcționare pentru a obține și prelucra date despre comportamentul sistemului pe o perioadă lungă de timp.

Printre toate tipurile de testare funcțională, acesta ocupă pe bună dreptate o poziție de lider, deoarece programul trebuie să funcționeze corect în primul rând, altfel nu va exista absolut niciun sens de la ușurința în utilizare, securitatea și viteza suficientă. Pe lângă stăpânirea diferitelor tehnici de testare, fiecare specialist trebuie să înțeleagă cum să testeze corect pentru a obține cel mai eficient rezultat.

Testarea funcțională: unde să direcționăm principalele eforturi?

Pentru testarea unității și a sistemului;

Pentru a bifa caseta „albă” sau „neagră”;

Pentru testare manuală și automatizare;

Pentru a testa o nouă funcționalitate sau ;

La teste „negative” sau „pozitive”.

Între toate aceste domenii de activitate este important să găsim calea potrivită, care va fi „mijlocul”, pentru a echilibra eforturile, folosind la maximum avantajele fiecăreia dintre zone.

Se efectuează verificarea software-ului căi diferite, dintre care unul este cutia neagră sau testarea bazată pe date.

Programul în acest caz este prezentat din punctul de vedere al „cutiei negre”, iar testul este efectuat pentru a afla circumstanțele în care comportamentul programului nu va respecta specificația. Toate erorile sunt determinate de managementul datelor, care se realizează cu ajutorul unor teste exhaustive, adică folosind toate posibilele

Dacă pentru un program execuția unei comenzi depinde de evenimentele care o preced, atunci va fi necesară o verificare a tuturor secvențelor posibile. Este destul de evident că, în majoritatea cazurilor, este pur și simplu imposibil să se efectueze teste exhaustive, așa că mai des aleg o opțiune acceptabilă sau rezonabilă, care se limitează la rularea programului pe un mic subset al tuturor datelor de intrare. Această opțiune garantează pe deplin absența abaterilor de la specificații.

Testarea funcțională implică alegerea corectă a testului. În același timp, se obișnuiește să se facă distincția între astfel de metode de formare a seturilor pentru ele:

Analiza valorii limită;

Partiție echivalentă;

Estimarea erorii;

Analiza relațiilor dintre cauze și efecte.

Puteți lua în considerare fiecare dintre ele separat.

Analiza valorilor la limită. Valorile limită sunt de obicei înțelese ca cele situate la granițele claselor de echivalență. În astfel de locuri, este cel mai probabil să găsiți o eroare. Utilizarea unei astfel de metode necesită o anumită creativitate din partea specialistului, precum și specializarea în această problemă specială luată în considerare.

Partiție echivalentă. Toate seturile posibile de parametri de intrare sunt împărțite în mai multe clase de echivalență. Datele sunt combinate conform principiului detectării erorilor similare. Este în general acceptat că, dacă un set dintr-o clasă detectează o eroare, atunci și echivalente o vor indica. Testare funcțională de către aceasta metoda se desfășoară în două etape: la prima, sunt selectate clase de echivalență, iar la a doua, sunt deja formate teste speciale.

Analiza relațiilor dintre cauză și efect. Sistemul poate selecta teste cu performanță ridicată datorită unor astfel de verificări. În acest caz, o condiție de intrare separată este luată drept cauză, iar o condiție de ieșire este văzută ca o consecință. Metoda se bazează pe ideea de a atribui toate tipurile de cauze anumitor consecințe, adică pe clarificarea acelorași relații cauză-efect. Testarea unui produs software se realizează în mai multe etape, rezultând o listă de cauze și consecințe.

abaterea accidentală a dezvoltatorilor de la standardele de lucru sau planurile de implementare;
specificațiile de cerințe funcționale și de interfață sunt executate fără respectarea standardelor de dezvoltare, ceea ce duce la o întrerupere a funcționării programelor;
organizarea procesului de dezvoltare - management imperfect sau insuficient de către managerul de proiect a resurselor (umane, tehnice, software etc.) și probleme de testare și integrare a elementelor proiectului.

Să luăm în considerare procesul de testare pe baza recomandărilor standardului ISO/IEC 12207 și să enumerăm tipurile de erori care se găsesc pe fiecare proces de ciclu de viață.

Procesul de dezvoltare a cerințelor. Atunci când se determină conceptul inițial al sistemului și cerințele inițiale pentru sistem, apar erori de analist în timpul specificației nivel superior sisteme și construirea unui model conceptual al domeniului de studiu.

Erorile tipice ale acestui proces sunt:

inadecvarea specificației cerințelor pentru utilizatorii finali - specificarea incorectă a interacțiunii software cu mediul de operare sau cu utilizatorii;
discrepanța între cerințele clienților pentru proprietățile software individuale și generale;
descrierea incorectă a caracteristicilor funcționale;
lipsa instrumentelor pentru toate aspectele implementării cerințelor clienților etc.

Proces de design.Pot apărea greșeli în proiectarea componentelor la descrierea algoritmilor, logicii de control, structurile de date, interfețele, logica de modelare a fluxurilor de date, formate de intrare-ieșire etc. Aceste erori se bazează pe defecte în specificațiile analiștilor și defectele proiectanților. Acestea includ erori legate de:

cu definirea interfeței utilizator cu mediul;
cu o descriere a funcțiilor (inadecvarea scopurilor și obiectivelor componentelor care sunt detectate la verificarea complexului de componente);
cu definirea procesului de prelucrare a informaţiei şi a interacţiunii dintre procese (rezultatul unei definiri incorecte a relaţiilor dintre componente şi procese);
cu atribuirea incorectă a datelor și a structurilor acestora în descrierea componentelor individuale și a PS în ansamblu;
cu descrierea incorectă a algoritmilor modulelor;
cu definirea condițiilor pentru apariția unor posibile erori în program;
cu încălcarea standardelor și tehnologiilor adoptate pentru proiect.

Etapa de codificare.In aceasta etapa apar erori care sunt rezultatul defectelor de proiectare, erori ale programatorilor si managerilor in procesul de dezvoltare si depanare a sistemului. Cauzele erorilor sunt:

lipsa controlului asupra valorilor parametrilor de intrare, indicilor matricei, parametrilor buclei, rezultatelor de ieșire, împărțirea cu 0 etc.;
tratarea incorectă a situațiilor neregulate la analizarea codurilor returnate din subrutine, funcții, etc.
încălcarea standardelor de codificare (comentarii proaste, iraționale alocarea modulelorși componentă etc.);
utilizarea aceluiași nume pentru a desemna obiecte diferite sau nume diferite ale aceluiași obiect, mnemonice de nume slabă; - modificări inconsecvente ale programului de către diferiți dezvoltatori etc.

Proces de testare.În acest proces, erorile sunt făcute de programatori și testeri la realizarea tehnologiei de asamblare și testare, selectarea suitelor de testare și a scenariilor de testare etc. Eșecurile software cauzate de astfel de erori ar trebui detectate, eliminate și nu reflectate în statisticile de eroare ale componentelor și software-ului. în general.

Proces de întreținere.Pe parcursul procesului de întreținere se constată erori care sunt cauzate de neajunsuri și defecte ale documentației operaționale, indicatori insuficienti de modificare și lizibilitate, precum și incompetență a persoanelor responsabile cu întreținerea și/sau îmbunătățirea software-ului. În funcție de natura modificărilor efectuate, în această etapă pot apărea aproape orice erori similare erorilor enumerate anterior în etapele anterioare.

Toate erorile care apar în programe sunt de obicei împărțite în următoarele clase [7.12]:

erori logice și funcționale;
erori de calcul și de rulare;
I/O și erori de manipulare a datelor;
erori de interfață;
erori de volum de date etc.

Erori de logica sunt cauza încălcării logicii algoritmului, inconsecvența internă a variabilelor și operatorilor, precum și a regulilor de programare. Erorile funcționale sunt rezultatul unor funcții definite incorect, încălcarea ordinii de aplicare a acestora sau lipsa completității implementării lor etc.

Erori de calcul apar din cauza inexactităților în datele sursă și a formulelor implementate, erori de metodă, aplicare incorectă a operațiilor de calcul sau operanzilor. Erorile de rulare sunt legate de eșecul de a furniza viteza necesară de procesare a interogărilor sau timpul de recuperare a programului.

Erori I/Oși manipularea datelor sunt rezultatul pregătirii de proastă calitate a datelor pentru execuția programului, eșecurile la introducerea lor în baza de date sau la preluarea din aceasta.

Erori de interfață se referă la erori în interconectarea elementelor individuale între ele, care se manifestă la transferul de date între ele, precum și la interacțiunea cu mediul de funcționare.

Erori de volum se referă la date și sunt o consecință a faptului că metodele de acces implementate și dimensiunile bazelor de date nu satisfac volumele reale de informații de sistem sau intensitatea prelucrării acestora.

Clasele principale de erori date sunt caracteristice diferitelor tipuri de componente software și se manifestă în programe în moduri diferite. Deci, atunci când lucrați cu o bază de date, există erori în prezentarea și manipularea datelor, erori logiceîn sarcina procedurilor aplicate de prelucrare a datelor etc. Erorile de calcul predomină în programele de natură computaţională, iar erorile logice şi funcţionale în programele de control şi procesare. Software-ul, care constă din multe programe diverse care implementează diferite funcții, poate conține erori. tipuri diferite. Erorile de interfață și încălcările domeniului de aplicare sunt comune oricărui tip de sistem.

Analiza tipurilor de erori din programe este o condiție prealabilă pentru crearea planurilor de testare și a metodelor de testare pentru a asigura corectitudinea software-ului.

În stadiul actual de dezvoltare a instrumentelor de suport pentru dezvoltarea software (CASE-tehnologii, metode orientate pe obiecte și instrumente de proiectare pentru modele și programe), se realizează o astfel de proiectare în care software-ul este protejat de cele mai frecvente erori și astfel previne apariția defectelor software.

Conectarea unei erori cu o eroare.Prezența unei erori în program, de regulă, duce la defecțiunea software-ului în timpul funcționării acestuia. Pentru a analiza relațiile cauză-efect „eroare-eșec”, se efectuează următoarele acțiuni:

identificarea defectelor în tehnologiile de proiectare și programare;
relația dintre defecte în procesul de proiectare și erori umane;
clasificarea defecțiunilor, defectelor și erorilor posibile, precum și a defectelor la fiecare etapă de dezvoltare; - compararea erorilor umane făcute într-un anumit proces de dezvoltare, și a defectelor obiectului, ca urmare a erorilor din specificația proiectului, modele de program;
verificarea și protecția împotriva erorilor în toate etapele ciclului de viață, precum și detectarea defectelor la fiecare etapă de dezvoltare;
compararea defectelor și defecțiunilor în software pentru a dezvolta un sistem de interconexiuni și metode de localizare, colectare și analiza informațiilor despre defecțiuni și defecte;
dezvoltarea de abordări ale proceselor de documentare și testare software.

Scopul final al cauzalității erorilor-eșecuri este de a defini metode și instrumente pentru testarea și detectarea erorilor anumitor clase, precum și criteriile pentru testarea finalizării pe un set de seturi de date; în determinarea modalităților de îmbunătățire a organizării procesului de dezvoltare, testare și întreținere a software-ului.

Oferim următoarea clasificare a tipurilor de defecțiuni:

hardware, în care software-ul la nivelul întregului sistem nu este operațional;
informațional, cauzat de erori în datele de intrare și transmisia datelor prin canale de comunicație, precum și atunci când dispozitivele de intrare se defectează (o consecință a defecțiunilor hardware);
ergonomic, cauzat de erorile operatorului la interacțiunea cu mașina (această defecțiune este o defecțiune secundară care poate duce la defecțiuni informaționale sau funcționale);
software, dacă există erori în componente etc.

Unele erori pot fi cauzate de defecte în definirea cerințelor, design, generarea codului de ieșire sau documentație. Pe de altă parte, acestea sunt generate în timpul dezvoltării programului sau în timpul dezvoltării interfețelor pentru elemente individuale ale programului (încălcarea ordinii parametrilor, mai puțini sau mai mulți parametri etc.).

Surse de erori.Erorile pot fi generate în timpul dezvoltării proiectului, componentelor, codului și documentației. De regulă, acestea sunt descoperite în timpul execuției sau întreținerii software-ului în cele mai neașteptate și diverse puncte ale acestuia.

Unele erori din program pot fi rezultatul unor defecte în definirea cerințelor, design, generare de cod sau documentare. Pe de altă parte, erorile sunt generate în timpul dezvoltării unui program sau a interfețelor elementelor acestuia (de exemplu, atunci când ordinea de setare a parametrilor de comunicare este încălcată - mai puțin sau mai mult decât este necesar etc.).

Motivul apariției erorilor este o înțelegere greșită a cerințelor clientului; specificarea incorectă a cerințelor în documentele de proiect etc. Acest lucru duce la faptul că sunt implementate unele funcții de sistem care nu vor funcționa așa cum sugerează clientul. În acest sens, se poartă o discuție comună între client și dezvoltator a unor detalii ale cerințelor pentru clarificarea acestora.

Echipa de proiectare a sistemului poate modifica, de asemenea, sintaxa și semantica descrierii sistemului. Cu toate acestea, este posibil ca unele erori să nu fie detectate (de exemplu, indecșii sau valorile variabile ale acestor operatori sunt setate incorect).

Popular în categorie: