În primul rând, ar trebui să știm ce este linia de bază înainte de a înțelege ce este testarea liniei de bază.

Tehnic vorbind –

O linie de bază este un document formal care acționează ca un document de bază pentru munca viitoare. Vorbind într-un limbaj profan, pentru a face o clădire, aveți nevoie de o bază. Același lucru este valabil și pentru testare. Trebuie să creăm o linie de bază, de la care se fac testele ulterioare. În primul rând, este foarte important de știut că este vorba de o testare nefuncțională, ceea ce înseamnă că nu are nimic de-a face cu testarea funcționalității unei aplicații. Mai degrabă se face o testare a documentului care stabilește o bază solidă a muncii care urmează să fie făcută în viitor. Așadar, se poate spune că acționează ca o bază pentru dezvoltarea viitoare, oricare ar fi ea. Poate fi performanța, dezvoltarea de cazuri de testare.

Să vorbim în termeni de testare a performanței –

Dacă se observă că performanța aplicației unui anumit server cu o sarcină de 100 de utilizatori, dacă aceasta funcționează bine pe serverul cu o sarcină de 100 fără nicio întrerupere sau încetineală sau defecțiune și după aceea performanța serverului scade drastic după ce o sarcină mai mare de 100 de utilizatori este aplicată serverului care conține aplicația. Atunci putem spune că standardul pentru acest server este de 100 de utilizatori. Acum, acest standard poate fi comparat cu serverul standard și se poate defini domeniul de aplicare viitor al testelor de performanță.

Să înțelegem acest lucru cu un alt exemplu, să presupunem că versiunea 1 are un timp de răspuns de 2 secunde, iar versiunea 2 are un timp de răspuns de 3 secunde. Acum, pentru versiunea 3, timpul de răspuns de 2 secunde al versiunii 2 acționează ca bază sau linie de bază pentru performanța versiunii 3. Așadar, de aici putem deduce că Baseline este un document la care se face referire ca bază de comparație sau de referință pentru lucrările viitoare. Trebuie să existe un document la care se poate face referire ca un document finalizat stabil pentru munca viitoare.

Să vorbim în termeni de dezvoltare software –

Dacă vorbim în termeni de dezvoltare software, există un document numit document de proiectare. Acesta poate fi un document de nivel scăzut sau un document de nivel înalt pe baza căruia încep lucrările de dezvoltare. Dacă vorbim în termen de testare, un document pregătit de către analistul de afaceri care este în contact cu clientul și este responsabil pentru a obține cerința de la client acționează ca un punct de referință de contact pentru testeri pentru a începe procesul de dezvoltare și testare. Analistul de afaceri se deplasează la sediul clientului după ce a stabilit o întâlnire, preia cerința și o completează într-un șablon specific. Acum, el discută cerința cu managerul de angajament sau cu managerul de management de proiect pentru a testa cerința și a verifica fezabilitatea acesteia. În cazul în care nu le este clară cerința, aceștia îi cer dezvoltatorului să creeze un prototip și, dacă sunt mulțumiți, predau documentul privind cerința managerului de proiect care pregătește Specificația cerințelor software. Un document pregătit de analistul de afaceri se numește document de cerințe de afaceri sau specificație a cerințelor funcționale sau specificație a cerințelor utilizatorului sau document de proiectare a afacerii sau document de afaceri, în funcție de terminologia utilizată de organizație. Așadar, aici vedem că testarea cerințelor se face pentru a finaliza documentul privind cerințele, care acționează ca o bază pe care se pregătește documentul de proiectare sau planul de proiect și planul de testare și constituie baza pentru dezvoltarea și testarea software-ului. Acest tip de testare se numește testare de bază. În acest tip de testare verificăm dacă documentul pregătit este la înălțimea așteptărilor și dacă îndeplinește așteptările în mod corespunzător sau, cu alte cuvinte, validăm documentul și îl finalizăm.

După ce se face testarea de bază și se finalizează documentul de specificație a cerințelor software, suntem gata să mergem mai departe și să începem procesul de dezvoltare și testare. Pentru testare, putem începe să pregătim cazurile de testare pe baza documentelor de cerințe. Principalul avantaj al testării de bază este că putem elimina erorile din cerințe în faza timpurie a ciclului de viață al dezvoltării de software și eliminăm atât de multe probleme și efort într-o etapă ulterioară și ne ajută să livrăm proiectul cu un minim de retușuri și mai puțin efort.

Vorbind în termeni de fază a ciclului de viață al dezvoltării de software –

Cum știm că mai multă muncă în faza timpurie a ciclului de viață al dezvoltării de software reduce prea mult efort într-o etapă ulterioară. Pentru a înțelege cât de importantă este testarea de bază, trebuie să avem o mică înțelegere a ciclului de viață al dezvoltării software. Prima fază este o fază a cerințelor, în care analistul de afaceri culege informații de la client și pregătește documentele de cerințe, care se numesc document de cerințe de afaceri sau specificație a cerințelor funcționale sau specificație a cerințelor utilizatorului sau document de proiectare a afacerii sau document de afaceri, în funcție de terminologia utilizată de organizație. Pe baza documentului de cerințe, se efectuează testarea documentului de cerințe, ceea ce se numește testare de bază, iar cerința este finalizată sau putem spune că cerința este înghețată. Odată ce aceasta este la înălțimea așteptărilor și poate fi luată în considerare pentru a pregăti specificația cerințelor software în faza de analiză. În acest document, managerul de proiect sau managerul tehnic sau analistul de sistem pregătește planul de proiect cu privire la modul în care va fi dezvoltat proiectul. Pe baza documentului SRS, se pregătește Documentul de proiectare, cum ar fi Documentul de proiectare la nivel înalt și Documentul de proiectare la nivel scăzut, pe baza căruia se realizează o altă fază a ciclului de viață al dezvoltării de software, cum ar fi codificarea, testarea și livrarea.

Să presupunem că testarea de bază nu este efectuată în mod corespunzător și că documentul privind cerințele de afaceri nu este finalizat în mod corespunzător, atunci SRS pregătit pe baza documentului privind cerințele de afaceri nu va fi corect, iar documentul de proiectare nu va fi, de asemenea, corect și, prin urmare, toate activitățile de dezvoltare și testare nu vor fi conforme cu așteptările clientului, deoarece poate exista o mică greșeală în timpul preluării cerințelor sau cerințele nu au fost stabilite în mod corespunzător. Din aceasta, putem înțelege cât de importantă este testarea bazei de referință.

Un lucru important este că există un termen de bază care este utilizat în managementul configurației, deși sensul este mai mult sau mai puțin același și acolo. Acesta este legat de versiunea documentului în care versiunea de bază a documentului este finalizată, iar noua versiune a documentului este lansată pentru fiecare versiune a aplicației software. Dar și în managementul configurației există un mic concept de testare de bază, deoarece versiunea de bază a tuturor documentelor, indiferent dacă este legată de dezvoltare, testare, proiectare web sau orice alt document pregătit în legătură cu dezvoltarea de software, trebuie să fie revizuită în mod corespunzător din punct de vedere al formatelor și al conținutului, astfel încât următoarea versiune a documentului să fie pregătită cu mai puțin efort într-un document deja formatat corespunzător.

Concluzie:

Atunci vedem că testarea de bază este foarte importantă și dacă și până când documentul privind cerințele nu este validat în mod corespunzător sau, cu alte cuvinte, dacă testarea de bază nu se face, vor exista multe probleme în etapa ulterioară, iar utilizarea efortului va fi mult mai mare în rezolvarea problemelor, ceea ce va fi doar o pierdere de efort și de timp, iar o nouă cerință va fi luată și va trebui să treacă prin toate fazele ciclului de viață al dezvoltării de software, pentru a rezolva complet problema. Așadar, putem spune că testarea de bază rezolvă multe probleme într-o etapă anterioară, reduce costurile, efortul și timpul organizației în etapa ulterioară a ciclului de viață al dezvoltării de software.

⇓ Abonează-te la noi ⇓

Dacă nu ești un cititor obișnuit al acestui site, atunci îți recomandăm să te abonezi la buletinul nostru informativ gratuit prin e-mail!!! Înscrieți-vă doar furnizând adresa dvs. de e-mail de mai jos:

Testări fericite!!!