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

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

Chiar dacă sunteți atât de tolerant încât puteți reporni programul de 18 ori după un accident în decurs de o jumătate de oră și abia apoi aruncați monitorul direct în fereastră, veți fi de acord că lucrul cu acest program ar fi mai confortabil dacă nu s-ar bloca. ” .

Cum vă puteți asigura că cazurile de blocare, înghețare sau eșec în efectuarea acțiunilor necesare programului pe care l-ați dezvoltat devin foarte rare?

Răspunsul exact la această întrebare Nu. Dar de-a lungul secolelor, cei mai înțelepți oameni de știință s-au gândit la acest subiect de ani de zile și au reușit să găsească un remediu care, dacă nu elimină toate erorile de program, atunci măcar creează iluzia acțiunii pentru a le elimina.

Și acest remediu se numește TESTARE produs software .

Potrivit oamenilor înțelepți, testarea este una dintre cele mai stabilite modalități de a asigura calitatea dezvoltării software si este inclusa in set mijloace eficiente sistem modern asigurarea calitatii produsului 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, inginerii suport, marketingul. , instruire și personal de 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, stabilirea problemei asigurării calității produsului are ca rezultat sarcina de a identifica părțile interesate, criteriile lor de calitate și apoi de a găsi soluția optimă care să satisfacă 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 chestiune regală. Produsul software trebuie testat de angajați special instruiți numiți testeri, 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 din punctul de vedere al clasificării după scop ar trebui împărțită în două clase:

Testare funcțională
Testare nefuncțională

Testare funcțională

Testarea funcțională înseamnă verificarea conformității unui produs software cu cerințele funcționale specificate în specificațiile tehnice pentru realizarea acestui produs. Pentru a spune simplu, testarea funcțională verifică dacă produsul software îndeplinește toate funcțiile necesare.

Deci, ați decis în sfârșit să efectuați teste funcționale. Te uiți la specificațiile tehnice, citești cerințele funcționale și realizezi că cel puțin acestea nu sunt în ordinea în care se poate face testarea. Veți fi surprinși că cu destul de mult timp în urmă, alții au observat deja această discrepanță și și-au dat seama cum să o depășească.

Pentru a efectua teste funcționale, personalul departamentului de control tehnic elaborează un program de documente și o metodologie pentru testarea 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 de testare și metodologia trebuie să simuleze funcționarea produsului software în mod real. Aceasta înseamnă că scenariul 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, î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ă calitățile unui produs software, cum ar fi 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 în masă.

După cum sugerează și numele, testarea nefuncțională verifică dacă un produs software îndeplinește cerințele nefuncționale ale termeni de referinta pentru crearea lui. Și, ca și în cazul testării funcționale, un program de testare și o metodologie sunt dezvoltate 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 (software) încorporat. 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 este vitală pentru a aduce un produs pe piață. În mod tradițional, testarea a jucat un rol important în dezvoltarea sistemelor încorporate pentru industriile reglementate de standarde. Cu toate acestea, în ultimii ani, practicile și procesele de testare consacrate, locul și rolul lor în astfel de proiecte, s-au schimbat semnificativ. A fost o schimbare a jocului, iar când regulile jocului se schimbă, trebuie să te schimbi cu ele pentru a câștiga.

Odată cu dezvoltarea constantă a tehnologiilor noi, de ultimă oră, companiile trebuie să ofere rapid pe piață produse fiabile, sigure, ușor de utilizat și compatibile cu alte sisteme - doar pentru a evita pierderea în lumea tehnologică în schimbare rapidă. Într-o astfel de situație, modelul tradițional în cascadă, în care procesul de dezvoltare a software-ului este strict secvențial, iar testarea este efectuată chiar la sfârșit, devine un lucru din trecut. Metodele DevOps și Agile devin din ce în ce mai populare, deoarece le permit inginerilor să finalizeze sarcini care anterior se succedau simultan.

Test de performanta

În timpul fazei de testare a performanței, primul pas este testarea sarcinii, 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 funcționarea reală.

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 volumetrică.

Există un alt tip de testare: testarea de stabilitate și fiabilitate, care include nu numai testarea 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 sarcini stresante.

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 a efectua testarea, este dezvoltat un caz de testare, care trebuie să conțină date suficiente 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, ceea ce permite mod automat creați 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, care conține informații despre finalizarea tuturor etapelor și etapelor testării și comentariile primite în timpul testării.

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

Testare exploratorie

Testarea exploratorie (testarea ad-hoc este un subtip de testare funcțională. Este utilizată în proiecte cu creștere rapidă, cu metode de dezvoltare flexibile, unde nu există documentație și cerințe clare. Testarea exploratorie este cea mai înaltă acrobație în testarea software-ului. Testarea calitativă este disponibilă pentru specialiști cu înaltă calificare și depinde aproape în totalitate de executant, de experiența sa, de cunoștințele (atât în materie, cât și în metodele de testare) și de capacitatea de a ajunge rapid la esență.

Testare stresanta

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

1. Generarea de scripturi de testare

Pentru o analiză eficientă, scenariile trebuie 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ă identificarea criteriilor de evaluare a performanței (viteza de răspuns, timpul de procesare a cererii etc.).

3. Efectuarea unui test de testare

Atunci când se efectuează teste, este important să se monitorizeze în timp util execuția scenariilor și răspunsul sistemului testat. Emularea sarcinilor mari necesită 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 reduse sunt luate ca bază și sunt 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.

Testează automatizarea

Principala caracteristică a testării automate este capacitatea de a efectua rapid teste de regresie. Principalele avantaje ale automatizării (conform unui raport de la 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: cost ridicat - din cauza costului ridicat de implementare și suport pentru automatizarea testelor, aproximativ 50% dintre companii folosesc în continuare testarea manuală în principal.

Testare de utilizare

Orice aplicație este creată pentru a fi utilizată. Ușurința de utilizare este un indicator important al calității unui program. 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 și, prin urmare, pentru numărul maxim de utilizatori. Pentru aplicațiile WEB, de obicei se alege testarea încrucișată. Pentru aplicații Windows - testare pe diverse sisteme de operareși dimensiunile biților (x86, x64). O componentă importantă a testării configurației este infrastructura de testare: pentru a efectua teste, 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 părților programului. Testarea se realizează prin dezvoltarea și desfășurarea cazurilor „end-to-end”. 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ă comportamentul semnificativ. Testarea la stres testează funcționarea unei aplicații în condiții care depășesc limitele normale de funcționare. Acest lucru este deosebit de important pentru programele „critice”: software bancar, programe din industria aviației, medicină. Testele de stres se efectuează nu numai în etapa de dezvoltare a software-ului, ci și pe parcursul întregului ciclu de operare pentru a obține și procesa datele de comportament ale 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 de utilizator care a transmis. Acum această funcție folosește 3 funcții sursă-a, sursă-b și sursă-c pentru a produce 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-dataar trebui să verific disponibilitatea 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 de a uni date ș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 căruia i-a fost transmis.

Grozav. Atunci ar trebui să verifici. Pentru un anumit ID, returnați datele corecte?

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

Ce detaliu de implementare ar trebui să ignorați în 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, beneficiul cheie al acestui test unitar este că puteți refactoriza implementarea metodei și testul va verifica dacă ați făcut-o 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 batjocură de date), în timp ce testul se concentrează pe cerințe și pragmatism.

La urma urmei, acesta este un cod important. Există teste pentru a susține codul real, petrecând 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 batjocorești (ar trebui să fie testate unitar în clasele lor).

În testarea integrării, testați comportamentul mai multor clase care interacționează între ele, aceasta î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 și datele sunt conectate corect) .

Testele unitare sunt mai simple și mai concentrate și ar trebui scrise de dezvoltatori. Testele de integrare devin de obicei învechite relativ repede (dacă există componentă internă a fost schimbat), făcându-le mai dificil de executat. Trebuie să fie creat de un profil QA.

Cum vă puteți asigura că cazurile de blocare, înghețare sau eșec în efectuarea acțiunilor necesare programului pe care l-ați dezvoltat devin foarte rare?

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

Și acest remediu se numește TESTAREA produsului 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 produselor software.

Când și cine?

Cu toate acestea, toți dezvoltatorii sunt de acord că testarea unui produs software din punctul de vedere al clasificării după scop ar trebui împărțită în două clase:

Testare funcțională
Testare nefuncțională

Testare funcțională

Pentru a efectua teste funcționale, personalul departamentului de control tehnic elaborează un program de documente și o metodologie pentru testarea 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 de testare și metodologia trebuie să simuleze funcționarea produsului software în mod real. Aceasta înseamnă că scenariul 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, î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ă calitățile unui produs software, cum ar fi ergonomia sau performanța.

După cum sugerează și numele, testarea nefuncțională verifică conformitatea unui produs software cu cerințele nefuncționale din specificațiile tehnice pentru crearea acestuia. Și, ca și în cazul testării funcționale, un program de testare și o metodologie sunt dezvoltate 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 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, care conține informații despre finalizarea tuturor etapelor și etapelor testării și comentariile primite în timpul testării.

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

Testare exploratorie

Testare stresanta

1. Generarea de scripturi de testare

2. Dezvoltarea unei configurații de testare

3. Efectuarea unui test de testare

Testează automatizarea

Principala caracteristică a testării automate este capacitatea de a efectua rapid teste de regresie. Principalele avantaje ale automatizării (conform unui raport de la 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: cost ridicat - din cauza costului ridicat de implementare și suport pentru automatizarea testelor, aproximativ 50% dintre companii folosesc în continuare testarea manuală în principal.

Testare de utilizare

Testarea configurației

Testarea configurației oferă încredere că aplicația va funcționa pe diferite platforme și, prin urmare, pentru numărul maxim de utilizatori. Pentru aplicațiile WEB, de obicei se alege testarea încrucișată. Pentru aplicații Windows - testare pe diverse sisteme de operare și rate de biți (x86, x64). O componentă importantă a testării configurației este infrastructura de testare: pentru a efectua teste, 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ă la funcționarea sa normală. Când limita este depășită, sistemul intră într-o stare de stres și își schimbă comportamentul semnificativ. Testarea la stres testează funcționarea unei aplicații în condiții care depășesc limitele normale de funcționare. Acest lucru este deosebit de important pentru programele „critice”: software bancar, programe din industria aviației, medicină. Testele de stres se efectuează nu numai în etapa de dezvoltare a software-ului, ci și pe parcursul întregului ciclu de operare pentru a obține și procesa datele de comportament ale sistemului pe o perioadă lungă de timp.

Dintre toate tipurile, testarea funcțională ocupă pe bună dreptate o poziție de lider, deoarece programul trebuie în primul rând să funcționeze corect, altfel ușurința de utilizare, securitatea și viteza suficientă nu vor fi absolut de niciun folos. Pe lângă stăpânirea diferitelor tehnici de testare, fiecare specialist trebuie să înțeleagă cum să efectueze corect un test 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;

Pentru 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, valorificând 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 unei „cutii negre”, iar testul este efectuat pentru a determina circumstanțele în care comportamentul programului nu va respecta specificația. Toate erorile sunt identificate prin gestionarea datelor, care se realizează prin testare exhaustivă, adică folosind tot posibilul

Dacă pentru un program execuția unei comenzi depinde de evenimentele care o preced, atunci va fi necesară verificarea 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 nicio abatere de la specificații.

Testarea funcțională presupune alegerea testului potrivit. În același timp, se obișnuiește să se facă distincția între următoarele metode pentru a genera seturi generatoare pentru acestea:

Analiza valorii limită;

Partiție echivalentă;

Presupunerea erorii;

Analiza legăturilor dintre cauze și efecte.

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

Analiza valorii 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ă specifică 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 pe baza principiului detectării erorilor similare. Este în general acceptat că dacă un set dintr-o clasă arată o eroare, atunci și echivalentele o vor indica. Testare funcțională de către aceasta metoda se desfășoară în două etape: la prima, sunt identificate clase de echivalență, iar la a doua, sunt deja formate teste speciale.

Analiza relațiilor cauză-efect. Sistemul poate selecta teste cu performanță ridicată prin efectuarea unor astfel de verificări. În acest caz, o condiție de intrare separată este luată drept cauză, iar condiția de ieșire este văzută ca efect. 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.

abateri neintenționate ale dezvoltatorilor de la standardele de lucru sau planurile de implementare;
specificațiile cerințelor funcționale și de interfață sunt realizate fără respectarea standardelor de dezvoltare, ceea ce duce la întreruperea funcționării programelor;
organizarea procesului de dezvoltare - management imperfect sau insuficient al resurselor managerului de proiect (umane, tehnice, software etc.) si probleme de testare si integrare a elementelor proiectului.

Să ne uităm la procesul de testare bazat pe recomandările standardului ISO/IEC 12207 și să dăm tipurile de erori care sunt detectate în fiecare proces de ciclu de viață.

Procesul de dezvoltare a cerințelor. Atunci când determină conceptul inițial al sistemului și cerințele inițiale pentru sistem, analiștii comit erori de specificație nivel superior sisteme și construirea unui model conceptual al domeniului de studiu.

Erorile tipice în acest proces sunt:

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

Proces de design.Erorile în proiectarea componentelor pot apărea la descrierea algoritmilor, logicii de control, structurile de date, interfețele, logica de modelare a fluxului de date, formatele de intrare/ieșire, etc. Aceste erori se bazează pe defecte în specificațiile analistului și defectele de proiectare. Acestea includ erori legate de:

cu definirea interfeței utilizator cu mediul;
cu o descriere a funcțiilor (inadecvarea scopurilor și obiectivelor componentelor care se descoperă la verificarea unui set de componente);
cu definirea procesului de prelucrare a informațiilor și a interacțiunii dintre procese (rezultat al determinării incorecte a relațiilor dintre componente și procese);
cu specificarea incorectă a datelor și a structurilor acestora la descrierea componentelor individuale și a software-ului în ansamblu;
cu descrierea incorectă a algoritmilor modulelor;
cu determinarea condiţiilor de apariţie posibile eroriîntr-un 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 timpul dezvoltarii si depanarii 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 de returnare din subrutinele numite, funcții etc.;
încălcarea standardelor de codificare (comentarii proaste, iraționale alocarea modulelorși componentă etc.);
utilizarea unui singur nume pentru a desemna diferite obiecte sau nume diferite ale unui obiect, mnemonici de nume slabe; - 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 efectuarea tehnologiei de asamblare și testare, selectarea seturilor de testare și a scenariilor de testare etc. Eșecurile software-ului cauzate de acest tip de erori trebuie identificate, eliminate și să nu afecteze statisticile componentelor și erorile software în general.

Proces de întreținere.Pe parcursul procesului de întreținere se descoperă 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;
erori de intrare/ieșire și de manipulare a datelor;
erori de interfață;
erori de volum de date etc.

Erori logice sunt cauza încălcării logicii algoritmului, inconsecvența internă a variabilelor și operatorilor, precum și a regulilor de programare. Erorile funcționale sunt o consecință a funcțiilor definite incorect, a încălcării ordinii de aplicare a acestora sau a lipsei de completare a implementării lor etc.

Erori de calcul apar din cauza inexactității datelor sursă și a formulelor implementate, erori de metodă, aplicare incorectă a operațiilor de calcul sau operanzilor. Erorile de rulare sunt asociate cu eșecul de a furniza viteza necesară de procesare a cererilor sau timpul de recuperare a programului.

Erori I/O iar manipularea datelor sunt o consecință a pregătirii de proastă calitate a datelor pentru execuția programului, a eșecurilor la introducerea lor în baze de date sau la preluarea lor din acesta.

Erori de interfață se referă la erori în relația dintre elementele individuale între ele, care se manifestă în timpul transferului de date între ele, precum și în timpul interacțiunii cu mediul de operare.

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. Astfel, atunci când lucrați cu o bază de date, apar erori în prezentarea și manipularea datelor, erori logiceîn specificarea procedurilor aplicate de prelucrare a datelor etc. În programele de calcul predomină erorile de calcul, iar în programele de control și procesare predomină erorile logice și funcționale. 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 de volum sunt tipice pentru orice 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 (tehnologii CASE, metode orientate pe obiecte și instrumente de proiectare a modelelor și programelor), se realizează o proiectare în care software-ul este protejat de cele mai frecvente erori și astfel previne apariția defecte software.

Relația dintre eroare și eșec.Prezența unei erori într-un program, de regulă, duce la o defecțiune a 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 posibilelor erori, precum și a defectelor la fiecare etapă de dezvoltare;- compararea erorilor umane comise î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 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 analizare a informațiilor despre defecțiuni și defecte;
dezvoltarea de abordări ale proceselor de documentare și testare a software-ului.

Scopul final al cauzei erorilor-eșecuri este de a defini metode și mijloace pentru testarea și detectarea erorilor anumitor clase, precum și criteriile pentru finalizarea testării pe mai multe seturi de date; în identificarea modalităților de îmbunătățire a organizării procesului de dezvoltare, testare și întreținere a software-ului.

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

hardware, în care software-ul la nivelul întregului sistem este inoperabil;
informațional, cauzat de erori în datele de intrare și transmiterea datelor prin canale de comunicație, precum și defecțiunea dispozitivelor de intrare (o consecință a defecțiunilor hardware);
ergonomic, cauzat de erorile operatorului în timpul interacțiunii sale cu mașina (această defecțiune este o defecțiune secundară și poate duce la defecțiuni de informare sau funcționale);
software, dacă există erori în componente etc.

Unele erori pot fi rezultatul unor deficiențe în definirea cerințelor, proiectare, generare de cod de ieșire sau documentare. Pe de altă parte, acestea sunt generate în timpul dezvoltării unui program sau în timpul dezvoltării interfețelor elementelor 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 diferite puncte.

Unele erori dintr-un program pot fi rezultatul unor deficiențe în definirea cerințelor, proiectare, 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 erorilor este lipsa de înțelegere a cerințelor clienților; 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 este propus de client. În acest sens, se poartă o discuție comună între client și dezvoltator a unor detalii ale cerințelor pentru a le clarifica.

Echipa de dezvoltare 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 instrucțiuni sunt setate incorect).

Popular în categoria: