INSTRUMENTE DE TESTARE

MANUAL
Testare:
 Procesul de identificare a erorilor dintr-un software (proiect / produs) este cunoscut sub
numele de "Testare".
 Inginerul de testare trebuie să verifice (valideze) dacă software-ul dezvoltat este
conform cerințelor clientului sau nu. El este responsabil pentru furnizarea de software
de calitate clientului.

**Notă: Principala responsabilitate a inginerului de testare este că trebuie să verifice

(valideze) dacă aplicația dezvoltată (software-ul) este utilă pentru utilizatorul final sau nu.

Gândac: Abaterea de la cerință este cunoscută sub numele de bug sau defect.

Calitate:Justificarea tuturor cerințelor clientului cu ușurință în utilizare și securitate este

cunoscută sub numele de calitate.
 Să luăm un exemplu: Livrat/Lansat

Analist de afaceri Document necesar Dezvoltatorcompanie Proiect/produs

Mă Arhitect Plan Constructo Constructor Domiciliu
r
Client

Plan
Supraveghetor

Inginer de testare

Proiect:
Acesta va fi dezvoltat pe baza cerințelor clientului; Odată ce este dezvoltat, acesta va fi livrat
clientului. În funcție de nevoile clienților, membrii echipei (utilizatorii finali) îl vor folosi.
Ex: Spicejet.com, selenium4testing.com, Construirea propriei case cu cerintele noastre.
Produs:
Acesta va fi dezvoltat pe baza cerințelor companiei. Odată ce este dezvoltat, acesta va fi lansat
pe piață în funcție de nevoile clienților, aceștia vor alege produsul.
Ex:Aplicatie mobila, Calculator, Facebook, yahoo, MS Office, sistem de operare Mac,
sistem de operare Windows, Gmail etc.

Tipuri de testare:
 Instrumente de testare

Testarea funcțională Testarea non-funcțională

Testarea sarcinii

Testare manuală Testarea automatizării Testarea performanței

Seleniu, alergător câștigător Testarea stresului

QTP, RFT, serigrafie, apă, Watin Soak Testare

Aplicatii bazate pe Internet:

Aceste aplicații pot fi accesate în întreaga lume cu un număr nelimitat de utilizatori.

Ex: Gmail, Facebook, seleniu 4testing

Aplicații bazate pe intranet:

Aceste aplicații pot fi accesate și în întreaga lume, dar cu un număr limitat de utilizatori.

Ex: Aplicații care sunt limitate la o anumită organizație.

Licitarea proiectului:
Roluri implicate:
1. Analist de afaceri de marketing (BA)
2. Manager de interacțiuni (EM)

 Marketing Business Analyst (BA):

Marketing BA se va întâlni cu clientul și îl va convinge cu propunerea. Odată ce clientul este

mulțumit de propunere, atunci clientul și compania vor semna proiectul.

Deconectare:

Acordul oficial dintre client și companie cu privire la livrarea proiectului este cunoscut
sub numele de "semnare".
 Întâlnirea de lansare:

Odată ce proiectul este semnat, compania va merge la o întâlnire "kickoff". Este o

intalnire rapida la care vor participa toti membrii managementului de nivel inalt si vor
anunta proiectul, clientul si vor alege managerul de proiect pentru proiect. Managerul
de proiect este responsabil pentru SDLC.

 Manager de interacțiuni (EM):

Managerul de angajamente este responsabil pentru menținerea relației dintre client și

companie. El acționează ca o punte între Client și Companie.

Licitarea proiectului
1 Cr
Client
Despre companie 1 an

Istorie

Estimări
Propunere Deconectare

Timp și cost

Întâlnirea inițială
C1 C2 C3

2cr 1.5 cr 1 cr Manager de proiect

2 ani 1,5 ani 1 an

Ierarhia proiectului sau Ierarhia de desemnare sau Ierarhia rolurilor

LLM: Management de nivel scăzut

MLM: Management de nivel mediu

HLM: Management la nivel înalt

CICLUL DE VIAȚĂ AL
DEZVOLTĂRII SOFTWARE-ULUI (SDLC):
Se compune din fazele de mai jos,

1. Faza de cerință
2. Faza de analiză
3. Faza de proiectare
4. Faza de codare
5. Faza de testare
6. Faza de livrare și întreținere.

PIN:Notă de inițiere/sesizare a proiectului:

Este un e-mail, va fi pregătit de managerul de proiect unde conține data de începere și data de
încheiere a proiectului. E-mailul va fi trimis clientului și conducerii la nivel înalt.
Codul PIN indică începutul proiectului.

1) Faza cerințelor:
Roluri:Analist de afaceri
Manager de interacțiuni
Manager de proiect

 BA este responsabil pentru colectarea tuturor cerințelor într-un document șablon de

cerință (RTD).
 Odată ce toate cerințele sunt colectate în șablonul de cerințe, atunci acestea vor semna
cerințele,
 Documentul semnat este cunoscut sub numele de SRS (specificație cerință
software/sistem) sau BRS (specificație cerință de afaceri) sau FRS (specificație cerință
funcțională) sau BDD (document de proiectare de afaceri) sauBD (document de afaceri).
 Odată ce documentul SRS este de referință, BA este responsabil pentruPOC (Validarea
conceptului).
 În timpul POC, BA este responsabil pentru dezvoltarea prototipului și acesta va fi
prezentat clientului.

Prototip: Este o aplicație de probă dură și rapid dezvoltată; Nu conține niciuna dintre
funcționalitățile reale. Pur și simplu descrie cum va fi proiectul și cum se va afișa. Scopul
principal al prototipului este de a colecta toate cerințele în mod corespunzător și de a
înțelege toate cerințele în mod corespunzător.

 Managerul de angajamente este responsabil pentru menținerea raportului sau relației

dintre client și companie. El se va concentra, de asemenea, pe cerințele suplimentare,
costurile suplimentare și timpul suplimentar al proiectului.
 Managerul de proiect este responsabil pentru monitorizarea fazelor și va ajuta atât BA,
cât și EM să-și finalizeze activitățile în mod corespunzător.
Notă: Rezultatul fazei de cerință este SRS și Prototype

2) Faza de analiză:Analiza cerințelor.

Roluri:Management la nivel înalt
Management de nivel mediu
Manager de proiect
BA
  Toate rolurile de mai sus se vor aduna pentru o întâlnire și vor efectua activitățile de mai
jos
a. Studiu de fezabilitate
b. Selectarea tehnologiei
c. Planul de resurse
d. Planul H& S
a. Studiu de fezabilitate: Fezabil înseamnă posibil sau nu. Rolurile de mai sus vor
lua fiecare cerință din documentul SRS. Cerințele vor fi analizate și vor identifica
dacă este posibil să se dezvolte sau nu, dacă este posibil să se dezvolte, atunci
vor identifica cât timp este necesar pentru dezvoltarea, testarea și livrarea către
client. Dacă orice cerință nu este fezabilă pentru a se dezvolta, atunci o vor
informa clientului.
b. Selectarea tehnologiei: Lista tehnologiilor precum Java, .net, MSSQL, Oracle,
seleniu etc. sunt necesare pentru dezvoltarea proiectului, testarea și livrarea
către client vor fi descrise aici. Pe baza tehnologiilor vor angaja resursele.
c. Planul de resurse:Numărul de resurse precum dezvoltatori, ingineri de testare,
ingineri de baze de date sunt necesare pentru dezvoltarea și testarea proiectului
va fi descris aici.
d. Plan hardware și software:Numărul de hardware-uri, cum ar fi desktop-uri,
laptop-uri, telefoane mobile, imprimante etc. Cu software-urile conexe sunt
necesare pentru proiect vor fi descrise aici.

 Toate cele de mai sus vor fi documentate într-un document numit plan de proiect.
Acesta va fi trimis clientului, pentru revizuire.

3) Faza de proiectare:
Roluri: Arhitect/arhitect șef
Analist de afaceri (BA)
Manager de proiect

 Arhitectul va revizui toate cerințele documentului SRS, examinând în același timp dacă
sunt necesare clarificări cu privire la cerințe, atunci BA este responsabil pentru a șterge
toate cerințele neclare.
 Odată ce arhitectul este clar cu privire la toate cerințele, atunci el va împărți cerințele în
mai multe module și submodule. Grupul de cerințe conexe este cunoscut sub numele de
"Module".
  Odată ce toate modulele sunt împărțite, el va furniza diagrama arhitecturală (diagrama
flux) a întregului proiect cu ajutorul UML (limbaj unificat de modelare)
 Toate cele de mai sus vor fi documentate într-un document numit Document de
proiectare sau SRS.

4) Faza de codificare:
Roluri: Echipa în curs de dezvoltare
Echipa de testare
BA
Manager de proiect

 Odată ce modulele sunt împărțite de arhitect, acestea vor fi atribuite dezvoltatorilor,

precum și echipei de testare.
 Dezvoltatorii sunt responsabili pentru dezvoltarea codului sursă pentru module. Odată
ce codul sursă este stabil, atunci vor verifica codul sursă în depozitul central.
 Liderul de dezvoltare va verifica codul sursă în sistemul său local, apoi liderul de
dezvoltare va construi codul sursă și compilarea va fi lansată echipei de testare pentru
testare.

Repertoriul central:
 Depozit înseamnă un folder de stocare. Repertoriul central înseamnă folderul care este
accesibil în mod obișnuit tuturor resurselor din organizație. Acesta conține toate fișierele
securizate.
Ex: SVN- Sub versiune
VSS - Sursă vizuală sigură
TFS - Team Foundation Server
CVS - Sistem de versiune concurentă
Perforce, Github
Check in:Procesul de încărcare a fișierelor din sistemul local în depozitul central este cunoscut
sub numele de Check in sau Comit.

Verifică:Procesul de descărcare a fișierelor din depozitul central în sistemul local este cunoscut
sub numele de Check out.

Build:Procesul de conversie a codului sursă în cod executabil este cunoscut sub numele de
Build.

5) Faza de testare:
Roluri:Ingineri de testare
Echipa de dezvoltare
Analist de afaceri (BA)
Manager de proiect

 Odată ce documentul SRS este aliniat la bază (finalizat), acesta va fi trimis atât echipei
de dezvoltare, cât și echipei de testare.
 Echipa de dezvoltare este responsabilă pentru revizuirea documentului SRS, înțelegerea
acestuia și dezvoltarea construcției.
 Echipa de testare este, de asemenea, responsabilă pentru revizuirea documentului SRS.
În timpul revizuirii, dacă sunt identificate cerințe neclare (îndoieli), acestea vor fi
actualizate în documentul numit "Raport de revizuire (RR)".
 Raportul de revizuire va fi trimis conducătorului de echipă unde acesta va consolida
(Face un singur document) toate rapoartele de revizuire într-un singur document numit
"Raport de revizuire consolidată (CRR)" și va fi trimis la BA.
 BA este responsabil să revizuiască toate cerințele neclare și va oferi clarificările, apoi
"Raportul de revizuire actualizat (URR)" va fi trimis echipei de testare
 Echipa de testare va revizui din nou documentul SRS cu clarificări.
 Odată ce echipa de testare este foarte clară cu privire la toate cerințele, atunci vor lua
șablonul de caz de testare și vor scrie cazurile de testare pentru toate cerințele.
 Documentele cazurilor de testare vor fi trimise la BA. Unde îl va revizui și va furniza
comentarii dacă sunt necesare noi cazuri de testare.
 Pe baza comentariilor BA, echipa de testare va actualiza cazurile de testare.
 Odată ce cazurile de testare sunt aliniate de bază (finalizate), acestea vor fi trimise
clientului pentru revizuire finală.
 Odată ce compilarea este lansată echipei de testare, aceasta va executa toate cazurile
de testare pe Build.
 În timpul testării compilării, dacă sunt identificate erori, acestea vor fi raportate (trimise)
echipei de dezvoltare. Dezvoltatorul îl va remedia și îl va trimite înapoi echipei de
testare pentru testare.
 Inginerul de testare va testa dacă bug-ul este într-adevăr fixat sau nu și, în același timp,
va verifica alte erori.
 Dacă este identificat, acesta va fi raportat dezvoltatorului.
 Același proces va fi continuat până când compilarea este stabilă (fără erori sau fără
erori).
 Construcția stabilă va fi livrată clientului.
 6) Livrare și întreținere:
Roluri:Ingineri de testare
Echipa de dezvoltare
Analist de afaceri (BA)
Manager de proiect
Client

Livrare:Odată ce compilarea este stabilă în mediul de testare, echipa de testare (TL) va trimite
un e-mail managerului de proiect spunând că compilarea este stabilă, apoi managerul de
proiect va livra compilarea clientului.

 Clientul va implementa mediul de construire în scenă și va efectua teste.

 Mediul de etapăeste mediul comun în care atât echipa de testare, cât și echipa clientului
vor testa aplicația înainte de a intra în direct. Este, de asemenea, cunoscut sub numele
de mediu de pre-producție.
 Odată ce compilarea este stabilă în mediul etapei, atunci clientul va implementa
construirea în mediul live sau de producție.
 Odată ce construcția este implementată cu succes în mediul de producție / live, atunci
putem concluziona că proiectul este livrat cu succes clientului.
Întreținere:
"Live" înseamnă locul în care clientul sau utilizatorii finali utilizează aplicația. Întreținerea va fi
continuată atâta timp cât aplicația este activă.

Faza de întreținere TAT

Remedierea bug-
Client
Timp de răspuns urilor, CR-urilor
BA/PM/TL
3 Erori
(Îmbunătățire)
3 CR-uri Firmă

12/24 ore 3 Bug-uri – 3 zile

3 CRS – 4 zile

7 zile

 Odată ce proiectul este livrat cu succes clientului și este implementat cu succes în

mediul live / de producție, atunci va începe întreținerea proiectului.
 În timpul întreținerii, compania este responsabilă pentru două activități.
a) Remedierea erorilor.
b) Actualizarea CR-urilor pentru îmbunătățiri/solicitări de modificare.
 Atâta timp cât proiectul este live, întreținerea proiectului va fi continuată.
 Conform semnării (acordului), inițial, compania va oferi întreținere gratuită până la 3
până la 5 ani (depinde de aprobarea proiectului).
 Odată ce perioada de întreținere gratuită este finalizată, clientul va reînnoi contractul de
întreținere.
  Ori de câte ori clientul trimite bug-uri și CRS, atunci, de la companie, cineva (dezvoltator,
BA, tester) trebuie să trimită e-mailul de confirmare clientului în TAT (timpul de răspuns)
convenit conform acordului, ar putea fi de 12/24 de ore.
 E-mailul conține numărul de ore pe care le vom lua pentru a repara și livra noua
construcție clientului.
 Atâta timp cât proiectul este live, întreținerea proiectului va fi continuată

Q. Ce fel de aplicații ați testat?

TIPURI DE APLICAȚII:

Există trei tipuri de aplicații care pot fi testate;

1) Aplicatii Web
2) Aplicații desktop
3) Aplicații mobile

1) APLICAȚII WEB:

Aceste aplicații sunt accesate cu ajutorul unor browsere.

Este dedouă tipuri
a) Aplicații de arhitectură pe 3 niveluri.
b) Aplicații de arhitectură N-Tier.

Mediu/Sistem:

Toate aplicațiile sunt o combinație a mediului.

Mediul conține:
1. Stratul de prezentare.
2. Stratul de afaceri.
3. Stratul bazei de date.
MEDIU

APLICAȚIE
STRAT DE PREZENTARE/CLIENT

Solicitați răspuns
SERVER
STRATUL DE AFACERI

Solicitați răspuns
BAZA DE DATE
STRATUL BAZĂ DE DATE

1. Strat de prezentare:

Front-end-ul pe care utilizatorul final îl va accesa este cunoscut sub numele de

strat de prezentare / client.

2. Stratul de afaceri:

Serverul este responsabil pentru a servi cererea. Înseamnă că va prelua cererea

din aplicație, o va trimite în baza de date, va prelua răspunsul din baza de date și
îl va trimite înapoi în aplicație. Întregul proces este cunoscut sub numele de
servirea cererii.

Ex: Tomacat, JBoss, Weblogic, WebSphere, IIS

3. Stratul bazei de date:

Nivelul bazei de date este responsabil pentru stocarea datelor sub formă de
tabele.
Ex: MS SQL, My SQL, ORACLE

a) Aplicații de arhitectură pe 3 niveluri:

În aplicațiile de arhitectură pe 3 niveluri, cele 3 straturi de mai sus sunt disponibile în trei
mașini diferite (straturi) pe care le vom numi niveluri. Prin urmare, ele sunt numite aplicații
de arhitectură pe 3 niveluri.

Ex: PL - Browser
SErver - Tomacat
Baza de date - Oracle
b) Aplicații ale arhitecturii N-Tier:

Este la fel ca aplicațiile de arhitectură pe 3 niveluri bazate pe numărul de utilizatori

(încărcare), vom avea un număr mai mare de servere și baze de date.

Pe baza cererii de încărcare, logica de afaceri va fi distribuită între servere și DB. Prin urmare, îl
vom numi caAplicații de mediu distribuit.

.PL .PL .PL

Server Server Server

BL

.DB .DB .DB

DBL

2) APLICAȚII DESKTOP:

Aceste aplicații pot fi accesate fără niciun browser.

Ex: Skype, calculator, MS Office, player vlc etc.
Este de două tipuri:
 1-Nivelul
 2 niveluri

 1-nivel:

Aceste aplicații sunt limitate la un sistem specific (PC). Toate cele 3 straturi PL, BL și DBL vor
fi disponibile numai în acel sistem specific.
Ex: VLC player , Calc

 2 niveluri:
 Stratul de prezentare va fi disponibil într-un sistem, stratul de afaceri și stratul de bază de
date vor fi disponibile într-un alt sistem, cu ajutorul LAN / WANputem accesa aceste aplicații
din mai multe sisteme. Prin urmare, îl vom numi aplicații cu 2 niveluri, este cunoscut și sub
numele de aplicații de arhitectură client-server.
Ex: Skype

NOTĂ:Pentru aplicațiile desktop trebuie să instalăm aplicația pe partea utilizatorului / clientului,

apoi numai noi putem să o accesăm. Pentru a efectua testarea aplicațiilor desktop trebuie să o
efectuăm atât în client, cât și pe server.

Pentru aplicația Web, trebuie să o testăm numai în client.

(BL)

Server + DBL

App

LAN WAN LAN

M1 M2 M3
.PL

3) APLICAȚII MOBILE:
Aplicațiile care pot fi accesate pe platforma mobilă sunt cunoscute sub numele de
aplicații mobile.
Ex: Android, IOS, Blackberry, Windows etc.

Ele sunt de trei tipuri:

a. Aplicații native
b. Aplicatii Web
c. Aplicații hibride

a. Aplicații native:

Aceste aplicații pot fi accesate fără niciun browser.

Ex: Viber, funcționalitate apel, msg, ceas etc.

b. Aplicatii Web:

Aceste aplicații pot fi accesate cu ajutorul browserului de pe mobil.

Ex: selenium4testing.com

c. Aplicații hibride:

Aceste aplicații pot fi accesate atât fără browser, cât și cu browsere.

Ex: aplicația Gmail / Gmail, aplicația Facebook / Facebook, site-urile bancare / aplicația etc.

NOTĂ:Aplicațiile ForWeb nu sunt necesare pentru a instala aplicația din partea utilizatorului /
clientului, deoarece putem accesa cu ajutorul browserului. Pentru a efectua testarea aplicațiilor
web trebuie să o efectuăm numai în client.

METODOLOGII DE TESTARE:

Î:Cine este responsabil pentru testare. La ce nivel Test Engg.. se va implica în testare
Ele sunt de trei tipuri:

un. Testarea cutiei negre

b. Testarea cutiei albe
c. Testarea cutiei gri

a. Testarea cutiei negre:

Dacă resursa efectuează teste pe partea funcțională a aplicației, atunci el va fi tratat ca

"tester cutie neagră".

Partea funcțională înseamnă dacă aplicația dezvoltată este conform cerințelor clientului sau
nu. Testerele vor efectua testarea cutiei negre în mediul de testare și etapa env (Pre production
env)
b. Testarea cutiei albe:

Dacă resursa testează partea structurală (programarea) aplicației, atunci el va fi tratat ca

"tester cutie albă". Dezvoltatorii sunt responsabili pentru testarea cutiei albe în mediul de
dezvoltare.

c. Testarea cutiei gri:

Dacă resursa are experiență în ambele testări (testarea cutiei albe și testarea cutiei
negre). Apoi va fi tratat ca "Grey box tester".

NIVELURI DE TESTARE:
Dacă un proiect trebuie să treacă de la etapa de semnare la live (producție), acesta trebuie să
treacă prin nivelurile de testare de mai jos.

1) Nivelul unitar de testare

2) Testarea la nivel de modul
3) Nivelul de integrare al testării
4) UAT (Testarea acceptării utilizatorului)
5) Testarea sistemului

1) Nivelul unității de testare: Unitate înseamnă cel mai mic debit sau scenariu din
aplicație.
 Dezvoltatorul este responsabil pentru testarea la nivel de unitate.
 El va împărți modulul alocat în mai multe unități și va dezvolta codul pentru
toate unitățile.
 El este responsabil să verifice dacă fiecare unitate funcționează conform
așteptărilor sau nu.

2) Testarea la nivel de modul:

 De la testarea la nivel de modul, atât echipa de testare, cât și echipa de
dezvoltare sunt responsabile.
 Dezvoltatorul va combina toate unitățile aferente pentru a forma un modul.
 Odată ce modulul este dezvoltat, dezvoltatorul este responsabil pentru testarea
cutiei albe în mediul de dezvoltare.
 Odată ce modulul este eliberat echipei de testare, aceștia sunt responsabili
pentru testarea cutiei negre în mediul de testare.
 3) Testarea nivelului de integrare:
 Procesul de combinare a tuturor modulelor dezvoltate este cunoscut sub
numele de integrare.
 Verificați dacă fluxul de date navighează de la un modul la altul este cunoscut
sub numele de testare la nivel de integrare.
 Atât echipa de dezvoltare, cât și echipa de testare sunt responsabile pentru
testarea nivelului de integrare.
Ex: Creați un cont în Gmail, verificați dacă vă puteți conecta la aplicație cu contul
creat. Apoi compuneți e-mail și trimiteți-l, verificați dacă este livrat corect sau
nu.
 În timp ce integrarea, dacă lipsește vreun modul obligatoriu, atunci plumbul de
dezvoltare va înlocui modulul obligatoriu cu un cod fals cunoscut sub numele de
ciot sau driver.

D1 D2 D3 D4 D5
+ + + + +
Autentificare acreditări Compune Expedia
Deconectare

Ciot/Șofer:Ambele nu sunt altceva decât un cod fals, nu conține funcționalități.

 Dacă liderul de dezvoltare folosește abordarea de sus în jos pentru a integra
modulele, în timp ce integrarea dacă lipsește vreun modul obligatoriu, atunci
acesta va fi înlocuit cu Stub.
 Dacă liderul de dezvoltare folosește abordarea de jos în sus pentru a integra
modulele, în timp ce integrarea dacă lipsește vreun modul obligatoriu, atunci el
va înlocui cu Driver.
 4) Testarea acceptării de către utilizatori:
 Este cunoscut sub numele de testare de acceptare a utilizatorului / clientului.
Odată ce construcția este stabilă în mediul de testare, atunci vom planifica
livrarea construcției către client. Înainte de a livra compilarea clientului, clientul
va trimite cazurile de testare a acceptării utilizatorului echipei de testare pentru
execuție.
 Echipa de testare va executa toate cazurile de testare UA în mediul de testare;
Dacă toate sunt trecute, atunci managerul de proiect va livra compilarea
clientului.
 Clientul va executa din nou toate cazurile de testare UA în mediul clientului
(mediul etapei). Dacă toate sunt transmise, atunci clientul va implementa
compilarea în mediul Live sau Production.
 UAT este de două tipuri:

un.Testarea alfa
b. Testarea beta UAT

Testarea alfa Testarea beta (UATCS)

(UATC-uri) Mediu de testareMediu de scenă

un. Testarea alfa:Executarea tuturor cazurilor de testare UA într-un mediu de testare de

către echipa de testare este cunoscută sub numele de "testare alfa".
 b. Testare beta:Executarea tuturor cazurilor de testare UA în mediul de etapă al
clienților de către echipa clientului sau echipa de testare este cunoscută sub numele de
"testare beta".

Odată ce testarea beta este trecută, clientul va merge în mediul live.

Mediul de testare Client

Trecere Build (UATCS)

Construirea echipei de Porni
testare Livra

UATCS

5) Testarea sistemului:
 Este, de asemenea, cunoscut sub numele de testare non-funcțională. Odată ce
aplicația este stabilă, atunci putem merge la testarea nefuncțională.
 În testarea non-funcțională va fi identificată performanța (timpul de răspuns) a
aplicației.
 Timpul dintre solicitare și răspuns este cunoscut sub numele de timp de răspuns.
Acesta va fi identificat cu ajutorul mai multor tipuri de testare non-funcționale,
cum ar fi testarea sarcinii, testarea performanței, testarea stresului, testarea
punctului de rupere.
MODELE DE DEZVOLTARE SOFTWARE:
Q. Ce proces ați folosit pentru a vă dezvolta proiectul

Modelele sunt după cum urmează.

1) Model cascadă
2) Model spiralat
3) Modelul V
4) Modelul de pește
5) Proces agil

1) Model cascadă:
A fost procesul sau modelul inițial introdus pentru dezvoltarea de software (proces
vechi). Execuția secvențială a tuturor fazelor din SDLC este cunoscută sub numele de
model de cădere de apă. Odată ce faza este finalizată, managementul la nivel înalt va
analiza această fază.

NOTĂ: Cum cascadele de la un nivel la altul,în același mod vor fi implementate

fazele SDLC.

Avantaje:

 Este foarte ușor să implementați proiectul, deoarece este o execuție secvențială.

Dezavantajele:

 Riscul nu poate fi identificat în stadiul incipient al ciclului de viață, deci nu poate

fi prevenit.
 Este un proces consumator de timp, precum și un proces costisitor.
 Nu putem accepta schimbarea cerințelor în mijlocul proiectului. Dacă mai
trebuie acceptată, atunci vom accepta modificarea cerinței sub forma cererilor
de modificare a CR-urilor. Cererile de modificare se fac la sfârșitul proiectului și
CR-urile percepute de companie.
lună

2) Model spiralat:

 Modelul spiralat este o combinație de model cascadă și prototip.

  În loc să colecteze toate cerințele o singură dată, BA colectează puține cerințe;
Acesta va fi analizat și proiectat cu ajutorul prototipului. Apoi va fi dat dezvoltării.
 Odată ce dezvoltatorul dezvoltă compilația, aceasta va fi lansată echipei de testare.
Același proces va fi continuat pentru toate cerințele.
 Odată ce toate cerințele sunt finalizate și construcția este stabilă, atunci construirea
va fi livrată clientului.

Avantaje:

 Putem economisi timp și costuri, deoarece executăm toate fazele în paralel.

 Riscul poate fi identificat în stadiul incipient al SDLC și poate fi prevenit în stadiul
incipient al ciclului de viață.
 Modificarea cerinței poate fi acceptată la mijlocul procesului.

Dezavantajele:

 Are un risc imens de livrare, din cauza liniilor de timp agresive (mai puțin timp).
 Nu pot accepta modificarea cerințelor în etapa finală a proiectului pentru a evita
riscul de livrare.

3) Model V (model de verificare și validare):

Validare:
 Este, de asemenea, cunoscut sub numele de "QC" (controlul calității). Echipa de testare
este responsabilă pentru validare. Echipa de testare va verifica dacă software-ul
dezvoltat este conform cerințelor clientului sau nu.

Inginerii de testare sunt validatori.

Verificare:

Def1: Verificați dacă fiecare document de rezultat al fazei este conform instrucțiunilor
companiei și clientului sau nu.

Def2: Verificați dacă fiecare rol din organizație funcționează conform

Companiile și clienții ghidează liniile directoare sau nu. Verificarea este, de asemenea,
cunoscută sub numele de QA (asigurarea calității).

Grupul de management al proiectului/procesului (PMG) sau grupul de audit sunt responsabile

pentru verificare.

 Începând cu modelul V, chiar și echipa de testare va participa la colectarea

cerințelor.
 BA este responsabil pentru colectarea cerințelor, în paralel echipa de testare va
analiza toate cerințele pentru a verifica dacă este posibil să se testeze sau nu.
 Odată ce SRS este de bază, echipa de validare este responsabilă pentru planul de
testare
 Pe baza fazelor de analiză și proiectare, echipa de validare pregătește planul de
testare a sistemului și planul de proiectare.
 Odată ce codul este dezvoltat, aceștia vor elibera construcția echipei de testare,
unde vor efectua toate nivelurile de testare. Odată ce construcția este stabilă,
aceasta va fi livrată clientului.

Avantaje:

 Activitățile de testare sunt începute începând cu faza de cerințe, astfel încât să

putem asigura calitatea.
  Pentru fiecare fază, echipa de verificare și echipa de validare vor verifica fazele,
astfel încât să putem asigura calitatea.
 Riscul poate fi identificat în stadiu incipient pentru că avem o activitate paralelă de
testare, deci poate fi prevenit.
 Putem accepta schimbarea cerinței la mijlocul fazei.

Dezavantajele:

 Este un proces consumator de timp și costisitor, dar putem asigura calitatea.

4) Model de pește:

 Este la fel ca modelul v.

 În modelul de pește vom avea mai multe echipe de verificare de la client și companie
pentru a verifica procesul și pentru a oferi mai multă calitate și securitate.
 Este mai scump decât modelul v.
 Oferă mai multă securitate și se aplică în proiecte de securitate la nivel înalt, cum ar
fi NASA, Forțele Aeriene, Marina, Armata etc.
Notă: Echipa de validare va examina rezultatele testelor unitare atunci când
compilarea este în curs de dezvoltare
5) Proces agil:

 Are mai multe submodele, cum ar fi adaptive, Scrum, model iterativ etc. Modelul pe
care îl vom folosi este modelul scrum.
 Este un model iterativ și incremental. Modelul Scrum are activitățile de mai jos.
a. Scrum maestru
b. Poveștile utilizatorilor
c. Întâlnire Scrum / apeluri scrum / DSM
d. Planul Sprint
e. Întâlnire Sprint
f. Rămâneri

a. Scrum maestru:

Scrum masterul este cel care va conduce proiectul. Managerul de proiect sau clientul va
acționa ca un scrum master. Scrum master este responsabil pentru întâlnirile scrum și
întâlnirile de sprint.

b. Relatări ale utilizatorilor:

Cerințele vor fi înregistrate sub formă de fluxuri utilizate de utilizatorul final (moduri
utilizate de utilizatorul final). Prin urmare, o vom numi povești ale utilizatorilor. BA este
responsabil pentru colectarea
c. Întâlnire Scrum:

 În fiecare zi, toți membrii echipei vor participa la o întâlnire rapidă în care vor
descrie ce activități au fost efectuate ieri și ce sarcini sunt planificate să
îndeplinească astăzi și există provocări.
 Toți membrii echipei, inclusiv scrum masterul și clientul, trebuie să descrie.
 Scopul principal al întâlnirii scrum este de a urmări resursele și, de asemenea, de
a menține transparența.

d. Planul Sprint:

 Sprintul este fix, perioada de timp poate fio săptămână / două săptămâni / trei
săptămâni etc. Acesta va fi decis de maestrul scrum.
 Planul Sprint este, de a colectapovești utilizator, analiza, dezvolta, testa și livra
clientului.
 În timpul sprintului, dacă nu putem îndeplini niciuna dintre cerințe, sprintul nu va
fi prelungit. Iar cerințele în așteptare ar trebui să fie duse la următorul sprint.
Sprintul este o perioadă fixă de timp

e. Întâlnire Sprint:

Odată ce sprintul este finalizat, următorul plan de sprint va fi decis în cadrul întâlnirii de
sprint. Ei vor discuta, dacă sprintul actual este livrat cu succes sau nu, există provocări cu
care se confruntă.

f. Rămâneri:

În timpul planului de sprint, dacă poveștile utilizatorilor nu pot fi realizate, acestea vor fi
luate ca Backlogs. Aceste restanțe trebuie finalizate în următorul sprint.

Este de două tipuri,

(i) Restanțe de produse

(ii) Restanțe Sprint

Restanțe de produs: Cerințele (poveștile utilizatorilor) pe care le vom colecta,

dezvolta, testa și livra clientului ca parte a planului de sprint sunt cunoscute sub
numele de restanțe de produs.
Sprint Backlog: Cerințele care nu sunt finalizate ca parte a planului de sprint vor
fi tratate ca restanțe de sprint.
avantaje:

 Fiecare sprint va fi testat de mai multe ori de către echipa de testare și client, astfel încât
să putem asigura calitatea.
 Toate fazele din SDLC sunt efectuate în paralel y, astfel încât să putem economisi timp și
costuri.
 Modificarea cerinței poate fi acceptată în orice etapă a proiectului (chiar și după livrarea
sprintului).
 Riscul poate fi identificat în stadiul incipient și poate fi prevenit
 Putem menține transparența proiectului.
 Clientul va participa, de asemenea, la întâlniri scrum, astfel încât să putem obține
informațiile foarte repede.
 Fiecare sprint este livrat clientului, astfel încât să nu avem risc de livrare.
 Putem câștiga satisfacția clientului livrând toate sprinturile clientului.
 Sprint este, de asemenea, cunoscut sub numele de iterativ. Modelul său și iterativ și
incremental

Dezavantajele:
Menținerea tuturor informațiilor legate de sprint este o sarcină foarte dificilă, dar putem depăși
cu ajutorul instrumentelor de gestionare a testelor precum Scrum wise, Centrul de calitate, JIRA
și linkul de testare etc.

Tipuri de testare funcțională (sau) Tipuri de testare cutie neagră :

1) Testarea fumului:

 Odată ce construcția este dezvoltată și implementată în orice mediu, atunci se va

efectua testarea inițială, cunoscută sub numele de testare a fumului. Inițial, echipa de
dezvoltare va implementa construcția în mediul de dezvoltare și va efectua teste de
fum. Ei vor verifica dacă fiecare câmp legat de modul navighează corect sau nu pe
paginile lor și verifică funcționalitatea principală a aplicației. Obiectivul testului de fum
este de a verifica dacă construcția este pregătită pentru teste suplimentare sau nu.
Dezvoltatorul se va concentra pe testarea cutiei albe
 Dacă toate aceste câmpuri navighează corect către paginile aferente, atunci vor
concluziona că testul de fum este trecut.

2) Testarea sanității:
 Odată ce construcția este implementată în mediul de testare, echipa de testare va
efectua testul de fum în mediul de testare. Este cunoscut sub numele de testare a
sanității.
 În testul de sănătate, echipa de testare va efectua cel puțin o rundă a funcționalității
principale a fluxului și va verifica dacă funcționează corect sau nu.
 Dacă testul de sănătate este trecut, atunci echipa de testare va executa toate cazurile
de testare, dacă nu reușește, vor respinge construirea echipei de dezvoltare.

Ex pentru fluxul principal: Creați un cont în Gmail și conectați-vă la acel cont și

compuneți e-mail și trimiteți-l la un e-mail valid și verificați dacă este livrat corect sau
nu.

Notă:Odată ce testul de sănătate este efectuat, echipa de testare (liderul testului) trebuie să
trimită un e-mail cu rezultatele testului de sănătate echipei de dezvoltare.

3) Testare pre SRN:SRN - Note de lansare software

  Acesta conține starea de construire, cum ar fi, numărul de module disponibile în
compilare pentru testare.
 Numărul de module care sunt în curs de dezvoltare.
 Numărul de cioturi și drivere sunt disponibile în construcție.
 Numărul de bug-uri care sunt fixate și disponibile în construcție.
 Numărul de bug-uri care sunt în curs de dezvoltare
 Instrucțiuni de implementare etc.

 Înainte de a elibera documentul SRN împreună cu construcția către echipa de

testare, echipa de testare va efectua testul de fum în mediul de dezvoltare, cunoscut
sub numele de Pre-SRN Testing
 Este, de asemenea, cunoscut sub numele de Testarea acceptării construcției (BAT)
sau testarea verificării construcției (BVT).

Notă: Odată ce compilarea este lansată echipei de testare, engg-ul de testare va revizui
documentul SRN pentru a cunoaște starea compilării (ce conține compilarea). Apoi, testarea va
efectua testul de sănătate.

2. Comanda este inițial echipa Dev va efectua testarea fumului, apoi echipa de testare va
efectua testarea Pre-SRN în Dev Env. Dacă ambele sunt trecute, atunci echipa Dev va elibera
construirea echipei de testare, apoi testarea va efectua testarea sănătății

4) Testare GUI/UI:
Testarea interfeței grafice cu utilizatorul / interfața cu utilizatorul. Cele cinci activități de mai
jos vor fi testate în GUI.
  Verificați ortografiile tuturor câmpurilor.
 Verificați fontul tuturor câmpurilor în care ar trebui să mențină consistența.
 Verificați culoarea și aliniamentele tuturor câmpurilor, ar trebui să mențină consistența.
 Verificați aspectul general al paginii

5) Testarea de regresie:

Efectuarea testării funcționalităților deja testate pe compilările iterative și incrementale este

cunoscută sub numele de "testare de regresie".

Se va efectua în două moduri:

 Ori de câte ori este identificat un bug, acesta va fi raportat dezvoltatorului, dezvoltatorul îl
va remedia, apoi va elibera bug-ul fix sub formă de nou build (Build2) echipei de testare.
Inginerul de testare va testa din nou, pentru a verifica dacă eroarea este într-adevăr fixată
sau nu.
 Cazurile de testare care sunt transmise pe vechea construcție vor fi executate din nou
pe noua construcție și vor verifica dacă acestea funcționează la fel ca anterioare sau nu.

Testarea funcționalităților deja testate este testarea de regresie. Testarea noilor

funcționalități nu este testarea de regresie. Se află sub executarea cazului de testare.

Notă:Dacă există vreo actualizare de cod, atunci acel cod nou poate afecta codul
existent, așa că efectuăm testarea de regresie.
 6) Retestare:

 Efectuarea testării pe aceleași funcționalități din nou și din nou cu mai multe seturi de
date de testare diferite pe aceeași compilare este cunoscută sub numele de "Retestare".
 Executarea cazurilor de testare eșuate pe compilările iterative și incrementale este, de
asemenea, cunoscută sub numele de "Re testing".

Date de testare:Datele pe care echipa de testare le utilizează pentru testare sunt cunoscute
sub numele de "date de testare".

Ex: 1. Testați funcționalitatea de conectare a Gmail cu mai multe seturi de seturi

diferite acreditări.

2. Testați căutarea spicejet într-un singur sens cu mai multe seturi de origini
diferite și pasageri diferiți.

Î: Care este diferența dintre testarea de regresie și retestare

Î: Care este diferența dintre testarea de regresie și testarea nivelului de integrare

7) Testare end-to-end:
Inginerul de testare trebuie să identifice toate scenariile utilizate de utilizatorul final ale
aplicației și să verifice dacă scenariile end-to-end funcționează corect sau nu

Prin efectuarea testării End To End putem realiza testarea nivelului de integrare

De exemplu: scenariul de la un capăt la altul pentru Gmail.

 8) Testarea compatibilității:

 Testarea dacă aplicația funcționează la fel ca cea așteptată în toate mediile vizate sau nu
este cunoscută sub numele de "testare compatibilitate". Mediul este o combinație de
sistem de operare, browser, server, DB etc.
 Testarea compatibilității este de două tipuri: "testare cross-browser" și "cross-platform
testing".
 Testați dacă aplicația web funcționează așa cum era de așteptat în toate browserele
vizate, cum ar fi firefox, safari, google chrome, IE etc. este cunoscută sub numele de
"testare încrucișată a browserului".
 Testați dacă aplicația desktop funcționează conform așteptărilor pe diferite platforme
sau sisteme de operare, cum ar fi Windows, LINUX, MAC, Solaris etc. este cunoscută sub
denumirea de "testare multiplatformă".

Ex pentru testarea încrucișată a browserului: Testați dacă spicejetul funcționează în mediile de

mai jos sau nu.

Windows – Internet explorer, Firefox, Google chrome, Safari, Opera

Linux - Internet explorer, Firefox, Google chrome, Safari, Opera

MAC - Firefox, Google chrome, Safari, Opera

Ex pentru testarea pe mai multe platforme:Testați dacă skype funcționează în platformele sau
mediile de mai jos
 Windows
Linux
MAC și Mobile

Notă: Ori de câte ori efectuăm teste de compatibilitate, trebuie să ne concentrăm mai
mult pe GUI-ul aplicației

9) Testarea utilizabilității:

 Utilitatea înseamnă ușurință în utilizare. Inginerul de testare trebuie să asigure utilitatea

aplicației pentru satisfacția utilizatorului final.
 Depinde de aplicația pe care o avem pentru a oferi utilitatea.

Ex: Pentru aplicația bancară (securizată) trebuie să oferim mai multă securitate, în timp ce
pentru site-urile sociale (Face book, twitter), trebuie să oferim mai multă ușurință în utilizare.

10) Testare adhoc:

 Adhoc înseamnă în felul nostru.

 Testarea adhoc înseamnă testați aplicația în felul dvs., După înțelegerea tuturor
cerințelor și cel puțin o rundă de testare manuală este finalizată pe aplicație
 Scopul principal al testării ad-hoc este de a oferi utilitate aplicației.
 11) Testare exploratorie:

 Exploratoriu înseamnă identificarea noii cerințe / a noii caracteristici. Odată ce

construirea este stabilă, experții în domeniu vor testa aplicația conform cunoștințelor lor
de domeniu, în timp ce testează vor explora dacă cerințele existente sunt suficiente,
dacă nu, vor furniza noile cerințe.
 Scopul principal al testării exploratorii este de a oferi utilitate și securitate aplicației.

12) Testarea maimuțelor/testarea gorilelor:

 Odată ce aplicația este stabilă, atunci putem merge la testarea maimuțelor.

 Efectuarea testării aplicației prin efectuarea unor acțiuni anormale este cunoscută sub
numele de testare maimuță / gorilă.
 Acțiuni anormale înseamnă să faceți clic continuu pe un câmp pentru o perioadă lungă
de timp și să verificați dacă aplicația se blochează sau nu.
 Testați aplicația cu date nevalide, cum ar fi etichetele HTML (<html>) și verificați dacă
aplicația se blochează sau nu.
Notă: Obiectivul testării maimuțelor este de a verifica dacă aplicația se prăbușește sau
nu (Mijloacele vor primi serverul nu a fost găsit excepție)

13) Testare statică:

 Testarea aplicației fără a efectua nicio acțiune este cunoscută sub numele de testare
statică.

Ex:1. Testarea interfeței grafice

2. Validări:- verificarea disponibilității câmpurilor din pagină intră sub testare
statică.

14) Testare dinamică:

 Testarea aplicației prin efectuarea unei acțiuni este cunoscută sub numele de
testare dinamică.

Ex: Testarea de regresie, retestarea, testarea adhoc etc.

 15) Testarea autentificării:

 Autentificarea înseamnă verificarea dacă acreditările/datele securizate sunt

disponibile în baza de date sau nu.
 Testarea autentificării înseamnă testarea aplicației cu mai multe seturi de date
valide și nevalide, pentru date valide ar trebui să afișeze pagina principală, în timp ce
pentru datele nevalide, ar trebui să afișeze mesajul de autentificare corespunzător
(mesaj de eroare).

Ex: Testați funcționalitatea de conectare a HMS cu mai multe seturi de acreditări valide și
nevalide. Trebuie să autentifice corect aplicația.

16) Testarea directă a adreselor URL:

 Conectați-vă la o pagină securizată și luați adresa URL a paginii securizate și accesați

acea adresă URL într-un browser nou. În cazul în care nu ar trebui să fie accesibilă,
dacă este accesibilă, atunci aplicația nu este securizată.

Ex: Conectați-vă la Gmail.com, copiați adresa URL a paginii de pornire. Deschideți într-un
browser nou și accesați direct adresa URL, unde nu ar trebui să fie accesibilă.

17) Testarea scurgerilor de firewall:

 Conectați-vă la aplicație ca un nivel de utilizator și încercați să accesați datele dincolo

de limitarea rolului dvs. Dacă este accesibil, atunci concluzionăm că aplicația nu
funcționează conform rolului (are scurgerea firewall-ului).

Ex: Conectați-vă la aplicația HMS ca Jr. Doctor și încercați să accesați datele lui
Sr. Doctor, în cazul în care nu ar trebui să fie accesibil

18) Testarea bazei de date:

  Testarea dacă datele sunt inserate corect în baza de date a tuturor tabelelor sau nu
este cunoscută sub numele de testare a bazei de date. Cu ajutorul interogărilor SQL
putem efectua testarea DB.

Ex: Ori de câte ori creăm înregistrarea permanentă în HMS, toate detaliile
pacientului vor fi stocate în baza de date HMS, ca inginer de testare trebuie să ne
conectăm la baza de date și să verificăm dacă datele sunt introduse corect în toate
tabelele sau nu.

Testarea implementării / testarea instalării: Echipa de implementare sau

liderul de testare va implementa compilarea în mai multe medii, cum ar fi dev,
testare, etapă1, etapă2, producție etc. și va verifica dacă este implementată corect
sau nu

Î: Odată ce compilarea este lansată, cum veți testa compilarea

R: Inițial vom efectua testarea sanității, dacă este trecută, atunci vom executa toate cazurile
de testare, apoi vom efectua toate tipurile de testare funcțională ca mai jos. Prin efectuarea
tuturor testelor de mai jos, atunci putem asigura calitatea aplicației
Tipuri de testare funcțională - Fluxul de execuție al testării funcțiilor pe Build, odată ce este
lansat echipei de testare

Notă: Pentru orice aplicatie se vor efectua toate testarile de mai sus pentru a se asigura,
daca aplicatia indeplineste cerintele clientilor, calitatea si utilitatea acesteia pentru
utilizatorul final sau nu.

2. Dacă este o aplicație desktop de top, testarea directă a adreselor URL și testarea
cross-browser nu este posibilă pentru a efectua.

Model de raport de revizuire:

Examinați documentul SRS al spice jet și furnizați raportul de revizuire în șablonul de mai jos.

ID cerință Cerințe Comentarii de TE Comentarii

Descriere
7. Picătură pentru adulți, copii și sugari 1. Care este diferența dintre

Down-urile ar trebui să fie disponibile. Copil, adult și sugar

2. Ce valori au domeniile adult, copil, infantil?

19) Testarea globalizării:

Este de două tipuri

un. Testarea localizării.

b. Testarea internaționalizării.

un. Testarea localizării:

 Testați aplicația în toate limbile locale care sunt selective pentru țara
noastră, cum ar fi hindi, bengaleză, telugu etc. este cunoscută sub
numele de testare de localizare.
 Acceptă maximum 10 limbi pentru o singură integrare. Prin urmare, o
vom numi testare "L10N".

Ex:1. Testați Google.co.in în toate limbile locale, cum ar fi hindi, bengaleză,

telugu etc.

2. Testați bancomatul în limbile locale, cum ar fi hindi, telugu și engleză.

b. Testarea internaționalizării:

 Testați aplicația în toate limbile internaționale, cum ar fi japoneza,

chineza și spaniola, etc.is cunoscută sub numele de testare de
internaționalizare. Acceptă maximum 18 limbi pentru o singură integrare.
Prin urmare, o vom numi testarea "I18N".

Ex: Test Gmail.com în toate limbile de circulație internațională, cum ar fi,

japoneză, spaniolă și chineză etc.

CICLUL DE VIAȚĂ AL TESTĂRII SOFTWARE:

Acesta conține fazele de mai jos:

1) Plan de testare software.

2) Proiectarea testelor software.
 3) Executarea testului.
4) Analiza rezultatelor.
5) Raportare și BLC.
6) Livrare și întreținere.
7) Raport sumar al testului / Construiți raportul postmortem.

1. Plan de testare software:

 Planul este un document strategic care descrie modul de îndeplinire a unei sarcini într-
un mod eficace și eficient.
 Planul de testare software este, de asemenea, un document strategic care descrie
modul de efectuare a testării într-un mod eficace și eficient. Planul de testare va fi
pregătit de plumbul de testare; Odată ce este pregătit, acesta va fi trimis echipei de
testare pentru revizuire.
 Pe baza planului de testare, suntem responsabili pentru efectuarea testelor.
 Acesta conține mai jos activități sau Index.

Indicele planului de testare

1. Obiectiv

1.1 Domeniul de aplicare al testării

2. Documente de referință

3. Elemente de testare

3.1 Caracteristici care trebuie testate

3.2 Caracteristici care nu trebuie testate

4. Strategia de testare

4.1 Tipuri de testare

4.1.1. Tipuri de încercări funcționale

5. Mediul de testare

6. Criterii de acceptare/respingere a testului

7. Analiza și închiderea defectelor

8. Rezultate de testare

9. Testarea automatizării

10. Riscuri și situații neprevăzute

11. Cerințe hardware și software

12. Planul de resurse

13. Raport sumar de testare / Construiți raportul postmortem.

1. Obiectiv:

Scopul principal al planului de testare va fi descris aici. Acesta conține domeniul de testare.

1.1 Domeniul de aplicare al testării:

Ce tipuri de teste este responsabilă echipa de testare pentru a testa aplicația este
cunoscut sub numele de domeniul de testare.

Ex: Echipa de testare este responsabilă pentru testarea manuală și automatizarea

proiectului.

2. Documente de referință:

Lista documentelor utilizate de conducătorul testului pentru pregătirea planului de testare va fi

descrisă aici.

Plumbul de testare va utiliza documente SRS pentru a pregăti planul de testare.

3. Elemente de testare:

3.1 Caracteristici care trebuie testate:

Lista funcționalităților sau modulelor pentru care echipa este responsabilă va fi descrisă
aici și, de asemenea, lista testelor pe care echipa de testare le efectuează asupra
modulelor va fi descrisă aici.

Ex: Echipa de testare este responsabilă pentru rezervarea unui zbor, rezervarea unui
hotel și gestionarea rezervării.

Pentru modulele de mai sus, aceștia sunt responsabili pentru testarea manuală și
automatizare.

3.2 Caracteristici care nu trebuie testate:

 Lista modulelor și testelor pentru care echipa de testare nu este responsabilă va fi
descrisă aici.

Ex: Echipa de testare nu este responsabilă pentru modulele de plată și, de asemenea, nu
este responsabilă pentru testarea performanței, testarea sarcinii, testarea stresului.

4. Strategia de testare:

Strategia înseamnă lista pașilor pe care îi vom face pentru a realiza planul.

 Strategia de testare înseamnă lista tipurilor de testare funcțională. Ceea ce echipa de

testare va lua pentru a efectua testarea este cunoscut sub numele de strategie de
testare.
 Vom efectua toate tipurile de testare funcțională, cum ar fi regresie, retestare etc.
privind cererea
 Pe scurt, planul înseamnă ce să faci. Strategia înseamnă modul de realizare a planului.

5. Mediul de testare:

Mediu înseamnă că sistemul pe care îl vom folosi pentru a implementa construirea și

pentru a testa aplicația este cunoscut sub numele de mediu de testare.

Ex:Tipul mașinii : Windows server enterprise

Sistem de operare : Windows
Procesor: Intel Xeon CPU
Memorie: 4GB/2.13 GHZ
Hard disk : 150GB
Baza de date : Microsoft SQL server 2008 standard edition
Server web : IIS 7.0
Client : Microsoft Internet Explorer, Firefox, Google Chrome

6. Test de respingere / criterii:

Dacă un caz de testare se abate de la rezultatul așteptat, atunci acesta va fi tratat ca

eșec sau eroare.

Fiecare bug are criteriile sau tipul de bug.

Este de cinci tipuri:

un. Blocker
b. Foarte ridicat
c. Înalt
d. Medie
 e. Jos

7. Închiderea analizei defectelor:

La momentul livrării compilării, dacă sunt disponibile bug-uri / defecte, acestea vor fi analizate
de echipa de testare cu managerul de proiect. Dacă nu este necesar să se remedieze vreo
eroare, atunci aceasta va fi închisă.

8. Rezultatele testului:

Lista modulelor pe care le vom livra clientului cunoscute sub numele de livrabiles.

Toate modulele vor fi împărțite în mai multe faze și, de asemenea, clientul va furniza termenul
țintă (data livrării).

Dead Lines (data

Faza nr. Module livrării)

1. Zborul
2. ManageMy Booking
1 3. Statutul PNR 30 iunie

2 4. Orarele de zbor 31 iulie

5. Beneficii corporative

3 6. Conectare condimente 30 septembrie

9. Testarea automatizării:

Numărul de module pe care echipa de testare le va automatiza va fi descris aici, iar

instrumentul și strategia de automatizare pe care inginerii de testare le vor urma vor fi descrise
aici.

10. Riscuri și situații neprevăzute:

Lista riscurilor cu care se va confrunta echipa în timpul executării proiectului și, de asemenea,
cu soluția aferentă va fi descrisă aici.

Riscurile Neprevăzute
Deficitul de resurse Mențineți resursele tampon

Modificări continue ale cerințelor Analizați cerințele

Monitorizați evaluările
Lipsa evaluărilor inter pares inter pares

11. Cerințe hardware și software:

Numărul de mașini precum laptopuri, telefoane mobile, imprimante etc. Necesare pentru
testarea cu software-ul aferent vor fi descrise aici.

12. Planul de resurse:

Numărul de resurse necesare pentru testarea manuală, testarea automatizării, testarea bazei
de date vor fi descrise aici.

13. Raport sumar de testare/Raport postmortem de construire:

Odată ce testarea este finalizată, plumbul testului trebuie să pregătească raportul de sinteză al
testului, acesta conține rezumatul testării.
 2) Proiectarea testului software:
Procesul de scriere a cazurilor de testare pe șablonul cazului de testare după înțelegerea
tuturor cerințelor este cunoscut sub numele de "proiectare test software".

 Fiecare organizație va avea propriul șablon bazat pe acel șablon; Inginerul de testare
este responsabil pentru scrierea cazurilor de testare.
 Avem șabloanele de mai jos pentru a scrie cazurile de testare. Acesta conține
CoverSheet, Test cases, Testdata, Trasabilitate matrice și Test Report

Necesită- Test prioritate TC Testa Pre- Testa Adevăr Așteptat Rezulta Comentari
Tipuri ment ID scenariu producție Tipuri at Rezultat t i
Rezulta
ID t

Foaie de copertă:

Numele modulului :

Nr. total de cazuri de testare:

Nr. de cazuri de testare P1:

Nr. de cazuri de testare P2:

Nr. de cazuri de testare P3:

Nr. de cazuri de testare P4:

ID cerință: Numărul cerinței pentru care scriem cazurile de testare va fi descris aici.

Tipuri de teste: Tipul cazului de testare este cunoscut sub numele de tip de testare. Este de
cinci tipuri.

 GUI
 Validare
 Caz de test pozitiv (sau) Caz de test pozitiv funcțional.
 Caz de test negativ (sau) Caz de test negativ funcțional
 Caz de testare a bazei de date

Caz de test pozitiv: Testarea aplicației cu toate datele valide este cunoscută sub numele
de caz de test pozitiv.
 Caz de test negativ: Testarea aplicației cu cel puțin o dată nevalidă este cunoscută sub
numele de caz de test negativ.

Prioritate: Acesta descrie cât de important este cazul de testare. Este sub tipurile: P1, P2, P3 și
P4.

P1: Dacă cazul de testare descrie funcționalitatea principală a aplicației / modulului,

atunci acesta va fi tratat ca P1.

Funcționalitatea principală înseamnă că, dacă cazul de testare a eșuat, nu putem

continua testarea, astfel încât prioritatea este "P1".

P2: Dacă cazul de testare descrie funcționalitatea la nivel de câmp, atunci prioritatea
este "p2".

Cazul de testare la nivel de câmp înseamnă, dacă nu reușește, putem continua

testarea, dar este important să fim acolo în aplicație conform cerințelor clientului.

P3: Toate cazurile de testare GUI sunt intră sub prioritatea P3.

P4:Inginerul de testare are opțiunea de a da sugestia aplicației. Aceste sugestii vor fi

capturate sub formă de cazuri de testare, iar apoi prioritatea este "P4".

ID-ul cazului de testare: Numărul de serie al cazului de testare va fi descris aici.

Scenariu de testare:Scenariu înseamnă un flux sau modul utilizat de utilizatorul final. Cerința va
fi împărțită în toate fluxurile sau scenariile utilizate de utilizatorul final, iar acestea vor fi
descrise aici. Testul engg trebuie să identifice debitele maxime posibile (Scenrios) pentru
cerința sau povestea utilizatorului

Pre-condiție:Condiția necesară pentru testarea scenariului va fi descrisă aici.

Etapele testului:Lista pașilor necesari pentru executarea scenariului va fi descrisă aici. Pe baza
pașilor de testare, engg de testare va executa pe aplicație sau pe compilare

Rezultatul scontat:La momentul redactării cazurilor de testare, nu vom avea aplicația cu noi.
Deci, vom aștepta rezultatul scenariului. Rezultatul așteptat va fi actualizat în coloana cu
rezultatele așteptate.

Rezultatul real:Acesta va fi actualizat la momentul executării cazurilor de testare. Inginerul de

testare va observa comportamentul real al aplicației pentru scenariu și va fi actualizat aici.
Rezultat: Odată ce executarea testului este finalizată, inginerul de testare va compara rezultatul
real cu rezultatul așteptat, dacă ambele se potrivesc, atunci va actualiza rezultatul ca admis,
dacă nu, îl va actualiza ca eșuat.

Comentarii:BA sau clientul va furniza comentariile aici.

Consultați documentul TCs de conectare Gmail

Tehnici de proiectare a testului:

Pentru a efectua testarea într-un mod eficace și eficient, trebuie să urmăm tehnicile de
proiectare a testelor de mai jos.

1. Analiza valorii limită (BVA)

2. Partiția clasei de echivalență (ECP)

3. Ghicirea erorilor

1. Analiza valorii limită (BVA):

Ori de câte ori avem cerința de a testa intervalul precum 1 la 100 sau 1 la 1000 sau 1 la
1 lipsă sau 1 lipsă la 2 lipsuri, atunci nu este posibil să efectuăm testarea exhaustivă
(testare completă). Deci trebuie să aplicăm tehnica BVA.

 Împărțiți intervalul la mai multe limite, cum ar fi min-1, min, min+1, mijloc, max-
1, max și max+1.
 Pentru a efectua testarea pozitivă, testați câmpul cu min, min + 1, mijloc, max-1
și max. Unde ar trebui să accepte. (Cazul său de testare +ve)
 Pentru a efectua teste negative, testați câmpul cu min-1 și max+1. În cazul în
care nu ar trebui să accepte. (Cazul său -ve Test)
 Dacă funcționează conform celor de mai sus, atunci putem concluziona că
acceptă doar intervalul.
+Scenariu de testare +V: Verificați câmpul cu limite precum min, min + 1, mijloc, max-1 și max

-Scenariul testului ve: Verificați câmpul cu limite precum min-1 și max+1

2. Partiția clasei de echivalență (ECP):

Ori de câte ori avem cerința specială, cum ar fi verificarea dacă câmpul (numele de
utilizator sau parola) acceptă caractere precum a la z, de la A la Z, de la 0 la 9 și #
%@$&*. În același timp, câmpul nu trebuie să accepte caractere speciale precum <>-+/\.

 În acest scenariu, nu este posibil să efectuați testarea exhaustivă cu toate

caracterele. Deci trebuie să urmăm tehnica ECP.
 Împărțiți în mod egal datele de testare în două clase.
un. Date de încercare valide clasa b. Clasă de date de testare nevalidă
 Pregătiți datele de testare cu toate modurile posibile.
 Pentru a efectua teste pozitive, testează câmpul cu date de testare valide. Unde
trebuie să accepte. (Cazul său de testare +ve)
 Pentru a efectua teste negative, testați câmpul cu date de testare nevalide. În
cazul în care nu ar trebui să accepte. (Cazul său -Ve Test)
 Dacă funcționează așa cum era de așteptat în cele de mai sus, putem concluziona
că funcționează conform cerinței.
 3) Eroare la ghicire:

Ori de câte ori un bug este identificat de inginerul de testare, atunci ar trebui să fie raportat
dezvoltatorului unde îl va remedia și îl va trimite înapoi echipei de testare. Inginerul de testare
va verifica dacă eroarea este într-adevăr rezolvată sau nu. În același timp, el trebuie să
ghicească erorile sau erorile din funcționalitățile aferente. El trebuie să efectueze testarea și în
funcționalitățile aferente. Este cunoscut sub numele de "Ghicirea erorilor".

Ex: În alerta paginii PR msg nu se afișează, a fost remediată de dezvoltator și testată de tester.
În cazul în care alerta msg funcționează corect în pagina PR. Acum testul engg.. trebuie să
meargă funcționalitățile conexe, cum ar fi avizul de admitere și admiterea, apoi să caute (ghici)
tipul similar de eroare.

Matricea de trasabilitate:

Este de a urmări dacă inginerul de testare a acoperit toate cazurile de testare pentru întreaga
cerință sau nu.
 Pe baza matricei de trasabilitate, clientul sau clientul va urmări dacă inginerul de testare a
acoperit toate cazurile de testare sau nu.

ID-ul
ID-ul Numărul cazului de
REQ de TC testare Comentarii
1 1 1
2 1 2
3 1 3
4 1 4
5 1 5
6 1 6
7 1 7
8&9 5 8 până la 12
Cerința nu este clară.
Nu a fost încă În așteptarea
10 implementat comentariilor BA

4) Executarea testului:

 Procesul de executare a cazurilor de testare pe mediul de testare încorporat este

cunoscut sub numele de execuție de testare. Ori de câte ori compilarea este lansată
echipei de testare, inginerul de testare trebuie să revizuiască documentul SRN pentru a
cunoaște starea construirii.
 Pe baza documentului SRN, liderul testului va implementa compilarea, iar echipa de
testare va efectua testul de sănătate.
 Odată ce testul de sănătate este finalizat, rezultatele testului de sănătate sunt trimise
dezvoltatorului.
 Dacă testul de sănătate este trecut, echipa de testare va continua să execute cazurile de
testare, dacă testul de sănătate nu reușește, echipa de testare va respinge construirea
înapoi la echipa de dezvoltare.
 În timp ce execută cazurile de testare, inginerul de testare va observa comportamentul
real al aplicației pentru scenariu și va fi actualizat în câmpul de rezultate reale. Același
lucru va fi continuat pentru toate cazurile de testare.

5) Analiza rezultatelor:

 În timp ce execută cazurile de testare, inginerul de testare va actualiza câmpul de

rezultat real, apoi va compara rezultatul real cu rezultatul așteptat, dacă ambele se
potrivesc, atunci va furniza rezultatul ca trecere, altfel va actualiza ca eșec.
  Pentru trecere vom da culoarea verde, în timp ce pentru eșec vom oferi culoarea roșie.
Executarea testului și analiza rezultatelor, ambele sunt procese paralele.

Notă: Odată ce executarea cazurilor de testare este finalizată, suntem responsabili să executăm
toate tipurile de teste funcționale pe aplicație pentru a identifica erorile.

* Câte cazuri de testare putem scrie într-o zi?

Totul depinde de toate cerințele și de inginerul de testare, dar în medie putem scrie în jur de
40-50 de cazuri de testare într-o zi. Aceasta înseamnă că durează aproximativ 8-10 minute
pentru un caz de testare pentru a analiza cerința și pentru a pregăti cazul de testare pe șablonul
cazului de testare cu datele testului.

* Câte cazuri de testare putem executa într-o zi?

Depinde și de cazurile de testare și de aplicație, dar în medie putem executa 50-60 de cazuri
de testare într-o zi, deoarece să revizuim cazul de testare și să îl executăm pe aplicație.

Avem nevoie de aproximativ 5-8 minute pentru a executa un caz de testare în medie.

6) Raportare:

 Procesul de raportare / trimitere a erorilor (cazuri de testare eșuate) către dezvoltator

este cunoscut sub numele de raportare.
 Sunt două tipuri.

1. Raportarea erorilor prin utilizarea fișierelor XL.

2. Raportarea erorilor prin utilizarea instrumentelor de raportare.

1. Raportați erorile utilizând fișierul XL:

A fost vechiul proces pe care l-am folosit pentru a avea șablonul de mai jos pentru a actualiza
eroarea și a o trimite dezvoltatorului.

Gâ Titlul bug- Stare Severitat Prior Descrie Captură Zidi Raport Comentarii atribuite
nda ului/ e itate rea de ecran Versiu ate
c Rezumat erorii ne Lângă spre
ID
1.

ID eroare:

Numărul de serie al bug-ului va fi descris aici.

Titlul bug-ului / Rezumat:

Rezultatul real al bug-ului va fi descris aici.

Stare:

Pe baza bug-ului, inginerii de testare, precum și dezvoltatorul sunt responsabili pentru a da

statutul. Este mai jos de tipuri.

 Nou:
Ori de câte ori inginerul de testare identifică orice eroare. Inițial, starea bug-ului este
nouă. Noua eroare va fi raportată dezvoltatorului.
 Deschide:
Dezvoltatorul va verifica dacă noul bug este într-adevăr un bug sau nu. Dacă da, atunci
vom actualiza starea de la nou la deschis.
 Fix/Verificat:
Dezvoltatorul va dura ceva timp pentru a remedia eroarea deschisă, odată ce este
remediată, va actualiza starea de la deschis la fix. Bug-ul fix va fi trimis inginerului de
testare.
 Închis:
Inginerul de testare va verifica dacă eroarea fixă funcționează într-adevăr așa cum se
așteaptă sau nu. Dacă funcționează, atunci vom actualiza starea de la fix la închis. Starea
închisă este sfârșitul Bug-ului.
 Redeschide:
Bug-ul fix va fi testat de inginerul de testare; Dacă nu funcționează așa cum era de
așteptat, atunci va actualiza starea de la fix la redeschidere, iar eroarea de redeschidere
va fi trimisă înapoi dezvoltatorului.
 Dezvoltatorul va verifica dacă este într-adevăr un bug sau nu, dacă da, îl deschide,
remediază bug-ul și îl trimite înapoi echipei de testare.
 Respins/Nu este un bug/hold/differed:
Când inginerul de testare a identificat orice eroare, aceasta va fi raportată
dezvoltatorului cu o nouă stare. Dacă dezvoltatorul nu acceptă un bug, atunci va
actualiza o stare de la nou la Respins / Nu este un bug și va fi trimis înapoi echipei de
testare.

Severitate:

Acesta descrie cât de grav a afectat bug-ul aplicația la testare. Severitatea înseamnă gravitatea
bug-ului. Este sub tipuri.

 Blocker:
Dacă eroarea blochează întreaga testare a modulului, atunci severitatea sau tipul unui
bug este Blocker.
 Foarte mare:
Dacă bug-ul blochează parțial testarea modulului, atunci severitatea bug-ului este foarte
mare.
 Înalt:
Dacă eroarea blochează numai scenariul specific al modulului, atunci severitatea este
ridicată.
 Medie:
Severitatea tuturor erorilor GUI este medie.
 Jos:
Inginerul de testare are opțiunea de a da și sugestia. Deci, sugestia va fi raportată sub
formă de bug, unde severitatea este scăzută.

Prioritate:

Prioritatea descrie ordinea în care eroarea trebuie remediată de dezvoltator. Pe baza

gravității, inginerul de testare va acorda prioritate bug-ului, după cum urmează:

Severitate Prioritate
 Blocator/Urgent/Critic P1

Foarte ridicat P2

Înalt P3

Medie P4

Jos P5

Descriere:

Pașii detaliați pentru a produce / obține bug-ul vor fi descriși aici. Pe baza pașilor, dezvoltatorul
va verifica dacă este într-adevăr un bug sau nu.

Captură:

Inginerul de testare va captura de ecran a bug-ului și va fi încărcat în șablonul de eroare. Este

pentru a dovedi că bug-ul raportat este valid și, de asemenea, pentru a înțelege despre bug.

Versiunea de compilare:

Numărul de construcție pe care inginerul de testare a identificat bug-ul va fi descris aici.

Raportat de:

Inginerul de testare care a identificat eroarea va descrie aici.

Atribuiți către:Numele dezvoltatorului sau numele clientului potențial al dezvoltatorului, care

va remedia eroarea, vor fi descrise aici.

Comentarii:

Ambii ingineri de testare, dezvoltator pot pune întrebări sub formă de comentarii.

Notă:Raportarea fișierelor XL va consuma mult timp, astfel încât planul nostru este să folosim
instrumentele de raportare.

Ex:

Faze BUG Titlul / Stare Severita Priorit Descrierea erorii Captură de ecran
 rezumatul
ID erorii te ate

Aplicația nu
afișează 1. Deschideți Spicejet.com
ambele 2. Faceți clic pe butonul
selectoare radio dus-întors 3. Aplicația nu
Eu 1 de dată Nou Blocker P1 afișează ambele selectoare de date D:\Nagesh\SPicejet_Lo

Numele
Spicejet se 1. Deschideți Spicejet.com
afișează ca 2. Observați logo-ul
II 2 spacejet Nou Medie P4 Spicejet 3. Se afișează ca jetul spațial D:\Nagesh\SPicejet_Lo
Butonul
radio
unidirecțion 1. Deschideți Spicejet.com
al nu se Foarte 2. Butonul radio Oneway nu este
III 3 afișează Nou înalt P2 disponibil Drum
Caseta de
selectare
Student nu 1. Deschideți Spicejet.com
este 2. Caseta de selectare Student nu
Eu 4 disponibilă Nou Înalt P3 este disponibilă Drum
Cheange
culoarea
paginii de
pornire
spicejet la
II 5 albastru Nou Jos P5 1. Deschideți Spicejet.com Drum
Link-ul
clubului
Spicejet nu 1. Deschideți Spicejet.com
navighează 2. Faceți clic pe linkul
la pagina Spiceje Connect 3. Spiceje Connect
clubului link-ul nu navighează la pagina
III 6 Spicejet Nou Blocker P1 MySpicetrip Drum

1. Deschideți
Aplicația nu http://selenium4testing.com/hms
este 2. Conectați-vă la aplicație
menținută 3. Faceți clic pe Înregistrare căutare
Eu 7 GUI Nou Medie P4 4. Aplicația nu menține GUI Spicejet_GUI.png
 1. Deschideți
Interfața http://selenium4testing.com/hms
grafică a 2. Conectați-vă la hms cu
listei de user1/user1
lucru pentru 3. Faceți clic pe ADT
admitere nu 4. Faceți clic pe Lista
se menține de lucru pentru admitere 5.
II 8 corect Nou Medie p4 Observați GUI, nu se menține corect D:\Nagesh\hms_ADW

Câmpul 1. Deschideți http://spicejet.com

Adult nu se 2. Respectați toate câmpurile
afișează pe 3. meniul drop-down pentru adulți
III 9 pagină Nou Blocker P1 nu este disponibil D:\Nagesh\Spicejet\Sp

Aplicația nu 1. Deschideți http://spicejet.com

afișează 2. Faceți clic pe câmpul
Hyderabad și Foarte LeavingFrom 3. Aplicația nu afișează
Eu 1 Bangalore Nou înalt P2 Hyderabad și Bangalore D:\Nagesh\Spicejet\Sp
Î: care este diferența dintre severitate și prioritate

Î: care estediferența dintre Prioritate în cazurile de testare și Prioritate în șablonul de eroare

Î.Dacă dezvoltatorul nu acceptă bug-ul dvs., atunci cum veți dovedi că al dvs. este un bug
valid?

Un: Pe baza descrierii bug-ului, a documentului SRS, a capturii de ecran, vom încerca să
dovedim că bug-ul este valid, dacă nu îl acceptăm, atunci voi lua jurnalul sever pentru a
dovedi că bug-ul este valid, dacă încă nu îl accept și apoi îl voi trimite unui BA, manager de
proiect și, în final, clientului.

Î. Explicați scenariul în care eroarea are o severitate ridicată cu prioritate scăzută și

securitate scăzută cu prioritate ridicată?

A:Prioritate de severitate

Blocant - P1

Securitate ridicată Foarte ridicat - P2 Prioritate ridicată

Mare - P3

Mediu - P4
 Securitate scăzută Scăzut - P5 Prioritate scăzută

Avem două bug-uri, unul este Blocker, altul este mediu. Blocantul va avea prioritate
ridicată, iar cel mediu va avea prioritate scăzută.

Pe baza severității testului engg.. va oferi prioritate. Pe baza priorității pe care echipa de
dezvoltare este responsabilă să o remedieze

Dar liderul de dezvoltare are opțiunea de a schimba prioritatea, depinde de situație.

 Bug-urile care sunt legate de livrarea fazei curente vor fi convertite la prioritate
ridicată, indiferent de gravitate.
 Bug-urile care nu fac parte din livrarea curentă vor fi convertite la prioritate scăzută,
indiferent de gravitate.

ID eroare fază Titlu eroare / rezumat Stare Severitate Prioritate

I. 1. Spice jetname afișează noul mediu P4---P1

Ca jet spațial

2. 2. Spice jet connect link nu este New Blocker P1----P4

Navigarea în pagina de conectare cu jet de condimente

Raport de testare/Raport de stare a compilării:

Odată ce execuția cazului de testare este finalizată pe construcție, inginerul de

testare este responsabil să trimită un raport de testare atât clientului, cât și clientului.
Este formatul de mai jos
Raport de stare a construcției/raport de testare

Raport de stare a construirii / Raport de testare

Test Engg Nume:
Construirea nr. 1
Acreditări de conectare
Browser FF, IE GoogleChrome

Matrica de testare
 Numărul total de cazuri de
testare 200
Numărul de cazuri de încercare
executate 150
Numărul de cazuri-pilot pendinte 50
Numărul de cazuri de testare
Treceți 100
Numărul de cazuri de testare nu
reușește 50
Numărul de cazuri de testare
omise 10
Nr. de bug-uri raportate 3

Valori de testare:

Metrics înseamnă măsurarea sarcinii. Valorile de testare înseamnă măsurarea testării.

Până:

Dacă dezvoltatorul nu a oferit deloc funcționalitate, atunci acele cazuri de testare nu pot fi
executate. Este în așteptare.

Ignorate:

Dezvoltatorul a dat funcționalitatea, dar nu putem testa funcționalitățile, din cauza

funcționalităților dependente eșuate.

Ex: dacă conectarea a eșuat, nu putem executa compunerea.

Compuneți cazuri de testare este omis.

 Raportarea va fi continuată până când compilarea este stabilă, stabilă înseamnă că

majoritatea cazurilor de testare sunt trecute și nu sunt disponibile erori de blocare în
instrumentul de raportare.
 Construcția stabilă va fi livrată clientului.

Î: Explicați-mi structura de raportare din organizația dvs.

Raportați erorile utilizând instrumente de raportare:

 Orice instrument de raportare care are două tipuri de utilizatori: unul este utilizator
administrator și altul este utilizator final.
 Utilizator administrator: Utilizatorul administrator este responsabil pentru crearea
proiectului, crearea utilizatorilor precum ingineri de testare, dezvoltatori ... etc. El va
atribui utilizatorul proiectului
  Utilizator final: El este responsabil să utilizeze (raporteze) sau să primească bug-urile ex:
ingineri de testare, dezvoltatori ... etc.

Ex: QC, JIRA, Bugzilla, Redmine, Manager de testare etc.

BugZilla:

 Accesați Bugzilla utilizând selenium4testing.com

 Apoi faceți clic pe Bugzilla.
 Conectați-vă la Bugzilla ca inginer de testare (jan30selenium@gmail.com și parola :
seleniu)
 Folosind Bugzilla putem efectua activitățile de mai jos.
un. Raportarea unei erori.
b. Căutați bug-urile.
c. Putem lua raportul.
d. Preferință.

Introducere în Bugzilla
Ce este Bugzilla?
Bugzilla este un sistem open-source de urmărire a problemelor / erorilor care
permite dezvoltatorilor să urmărească în mod eficient problemele restante cu produsul
lor. Este scris în Perl și folosește baza de date MYSQL.

Bugzilla este un instrument de urmărire a defectelor, însă poate fi folosit ca

instrument de gestionare a testelor, astfel încât poate fi ușor legat de alte instrumente de
gestionare a cazurilor de testare, cum ar fi Centrul de calitate, Testlink etc.

Acest tracker deschis de bug-uri permite utilizatorilor să rămână conectați cu

clienții sau angajații lor, să comunice eficient despre probleme de-a lungul lanțului de
gestionare a datelor.

Caracteristicile cheie ale Bugzilla includ

 Capacități de căutare avansată

 Notificări prin e-mail
 Modificați/înregistrați erori prin e-mail
 Urmărirea timpului
 Securitate puternică
 Personalizare

Cum să vă conectați la Bugzilla?

Pasul 1)Pentru a crea un cont în Bugzilla sau pentru a vă conecta la contul existent,
accesați opțiunea Cont nou sau Conectare din meniul principal.

Pasul 2)Acum, introduceți detaliile personale pentru a vă conecta la Bugzilla

1. ID utilizator: jan30selenium@gmail.com
2. Parola: selenium
3. Apoi faceți clic pe "Conectați-vă"
Pasul 3)Sunteți conectat cu succes la sistemul Bugzilla

Crearea unui raport de erori în Bugzilla

Pasul 1)Pentru a crea un nou bug în Bugzilla, vizitați pagina de pornire a Bugzilla și
faceți clic pe fila NEW din meniul principal
Faceți clic pe link-ul Nou, apoi aplicația deschide fereastra următoare ca mai jos.

Pasul 2)În fereastra următoare

Faceți clic pe numele proiectului, cum ar fi HMS, apoi aplicația deschide o fereastră nouă
cu următoarele opțiuni:

1. Introduceți produsul
2. Introduceți componenta
3. Descrierea componentei Give
4. Selectați versiunea,
5. Selectați severitatea
6. Selectați Hardware
7. Selectați sistemul de operare
8. Introduceți rezumatul
9. Introduceți descrierea
10. Atașare atașament
11. Prezinte

NOTĂ: Câmpurile de mai sus vor varia în funcție de personalizarea Bugzilla

Introduceți toate câmpurile necesare cu privire la bug-ul dvs., după cum urmează,
Dacă aveți atașamente referitoare la eroarea de raportare, le puteți atașa făcând clic pe butonul "Adăugați un
atașament" și faceți clic pe butonul Commit de la sfârșitul paginii pentru a raporta eroarea.

Pasul 4) Bug-ul este creat ID-ul # 208 este atribuit bug-ului nostru. De asemenea, puteți adăuga informații
suplimentare la eroarea atribuită, cum ar fi adresa URL, cuvintele cheie, tabla albă, etichetele etc. Aceste
informații suplimentare sunt utile pentru a oferi mai multe detalii despre eroarea pe care ați creat-o.

1. Casetă text mare

2. Adresa URL
3. Tablă albă
4. Cuvinte cheie
5. Tags
6. Depinde
7. Blocuri
8. Ataşări
Pasul 5)În aceeași fereastră dacă derulați mai jos. Puteți selecta data limită și, de asemenea, starea erorii.
Termenul limită în Bugzilla oferă, de obicei, termenul limită pentru rezolvarea erorii într-un anumit
interval de timp.
Crearea rapoartelor grafice

Rapoartele grafice sunt o modalitate de a vizualiza starea curentă a bazei de date cu erori. Puteți rula rapoarte
fie printr-un tabel HTML, fie printr-unul grafic bazat pe linie/plăcintă/diagramă cu bare. Ideea din spatele
raportului grafic în Bugzilla este de a defini un set de bug-uri folosind interfața standard de căutare și apoi de a
alege un aspect al acelui set pentru a trasa pe axele orizontale și verticale. De asemenea, puteți obține un raport
3-dimensional alegând opțiunea "Pagini multiple".

Rapoartele sunt utile în multe feluri, de exemplu dacă doriți să știți care componentă are cel mai mare număr
de erori rău raportate împotriva acesteia. Pentru a reprezenta acest lucru în grafic, puteți selecta severitatea pe
axa X și componenta pe axa Y, apoi faceți clic pe generare raport. Acesta va genera un raport cu informații
cruciale.

1. Dați clic pe rapoartele din partea de sus a ferestrei, după cum urmează:

2. Faceți clic pe Rapoarte grafice

Pagina de rapoarte grafice va fi afișată ca mai jos,

Selectați axa verticală ca severitate și axa orizontală ca prioritate sau orice doriți, o puteți selecta și veți
obține raportul grafic corespunzător.

 Generați un raport cu funcții avansate introducând mai multe detalii cu privire la eroare, după cum
urmează:
Graficul de mai jos arată reprezentarea graficului cu bare pentru severitatea erorilor în componenta "Widget
Gears". În graficul de mai jos, cele mai severe bug-uri sau blocante din componente sunt 88, în timp ce bug-
urile cu severitate normală sunt în partea de sus cu numărul 667.

Funcția Browse

Pasul 1)Pentru a localiza bug-ul dvs. folosim funcția de navigare, faceți clic pe butonul Căutare din meniul
principal.
Raportarea va fi continuată până când compilarea este stabilă. Odată ce este stabil, acesta va
fi livrat clientului, apoi Consultați faza de livrare și întreținere

Odată ce compilarea este livrată cu succes clientului, liderul testului va pregăti

raportul sumar al testului și acesta va fi actualizat în planul de testare și planul de testare trimis
clientului în momentul livrării compilării.

TEST RAPORT SUMAR / RAPORT BUILD POST MARTUM

 Nr. de compilări lansate de Dev Team - 50

 Nr. de compilări acceptate de echipa de testare - 25
 Nr. de compilări respinse de echipa de testare - 25
 Nr. de cazuri de testare pregătite de echipa de testare - 1000
 P1 - 500, P2- 350, P3-100, P4-50

 Numărul de bug-uri identificate - 400

o Blocant - 100
o Foarte mare - 150
o Mare - 100
o Mediu - 40
o Scăzut - 10
 Nr. de bug-uri identificate de client- 100
 o Blocant - 10
o Foarte mare - 50
o Mare - 10
o Mediu - 10
o Scăzut - 20
 Povești de succes
 Provocări

Î: Care sunt criteriile de intrare (început) de testare și criteriile de ieșire (sfârșit) de testare

R: Planul de testare și documentul SRS sunt criteriile de intrare ale testării.

Nu există sfârșit pentru testare. Acesta va fi continuat atâta timp cât construcția este live. Dar
activitățile de testare se vor schimba după ce construcția este livrată clientului. În timpul
întreținerii nu vom efectua toate tipurile de testare funcțională. Vom efectua testarea de
regresie.

Terminologie
Peer înseamnă coechipierul cu desemnare egală.
Toți colegii vor participa la o întâlnire și vor discuta
despre proiect pentru a obține claritate cu privire la
toate modulele. Obiectivul evaluării inter pares este
de a obține cunoștințe funcționale despre toate
Colegială modulele de către fiecare engg de testare.
În timp ce evaluarea inter pares, inter paresul senior
va pregăti documentul privind evaluarea inter pares
Raport de evaluare inter este cunoscut sub numele de raport de evaluare
pares inter pares
Dacă aceeași evaluare inter pares este efectuată în
fața liderului sau a managerului de proiect, atunci
este cunoscută sub numele de Walk through.
Liderul sau PM va observa dacă membrii echipei
Plimbați-vă înțeleg proiectul în mod corespunzător sau nu
În timp ce Walk through the lead va pregăti
documentul pe Walk through este cunoscut sub
Parcurgeți raportul numele de raport Walk through
Combinația de mai multe cazuri de testare este
Suită de testare cunoscută sub numele de suită de testare
Combinația dintre suita de testare și mediul de
testare este cunoscută sub numele de banc de
Banc de testare testare
Raport zilnic de stare.
În fiecare zi, trebuie să trimitem starea noastră de
DSR lucru către clientul potențial într-un șablon
 Procesul-verbal al reuniunii.
Când participăm vreodată la o întâlnire, discuția
întâlnirii va fi luată într-o notă brută. Mai târziu va fi
actualizat într-un e-mail și e-mailul va fi trimis tuturor
membrilor echipei. Scopul MOM este de a menține
MĂMICĂ transparența întâlnirii în rândul membrilor echipei
Procesul de verificare dacă compania respectă
liniile directoare sau nu. Inspectia se va face fara
Inspectare sesizare
Este, de asemenea, procesul de verificare dacă
compania respectă liniile directoare sau nu. Auditul
Audit va fi efectuat cu notificare prealabila
Stabil înseamnă că nu sunt necesare actualizări
suplimentare.
Construirea stabilă înseamnă că majoritatea
cazurilor de testare sunt trecute și nu există erori de
Grajd blocare identificate în compilare
AUT Aplicarea în curs de testare
Când vreodată construcția este respinsă,
dezvoltatorul va analiza eșecul. Dacă lansează din
nou aceeași versiune echipei de testare, fără a
adăuga noi funcționalități, este cunoscut sub
numele de PatchBuild.
Dacă dezvoltatorul lansează compilarea cu unele
funcționalități noi este cunoscută sub numele de
Construirea patch-urilor compilare nouă
Faceți-l disponibil pentru utilizatorii vizați. Odată ce
Testcase-urile sau documentul SRS este aliniat la
bază, acesta va fi înregistrat în depozitul central
pentru utilizatorii vizați. Este cunoscut sub numele
Anunța de publicare
Defectele legate de proiectare sunt cunoscute sub
numele de defecte. Ex: Defecte GUI Defectele
legate de funcționalitate sunt bug-uri (greșeală
programator).
Ex: Toate erorile
funcționale Eroare: Excepțiile din script sunt
Eroare / Defect / Eroare cunoscute sub numele de eroare
Cazul de utilizare este o listă de pași, definind de
obicei interacțiunile dintre un rol (cunoscut sub
numele de "actor") și un sistem, pentru a atinge un
obiectiv. Actorul poate fi inginer de testare sau
utilizator
final Cerințele vor fi convertite în listă de pași de
Cazuri de utilizare către BA
Rapoarte de neconformitate sau Cerere de
modificare a neconformității. Cu privire la cerința
NCR aflată în discuție
Acțiunile corective sunt implementate ca răspuns la
reclamațiile
clienților Acțiunile preventive sunt implementate ca
COCA răspuns la identificarea surselor potențiale

CSM În ingineria software, managementul configurației

 software (SCM sau SWCM) este sarcina de a
urmări și controla modificările software-ului.
Practicile CSM includ controlul revizuirii și stabilirea
valorilor de referință.
SDN Notă de livrare software
Subțierea. Îndepărtarea de sarcină Numărul de zile
în care ați alunecat de la sarcină
Alunecarea
Produs defect Produsul cu defecte
Vârsta defectului (în timp) este diferența de timp
dintre data la care este raportat un defect și data
curentă (dacă defectul este încă deschis) sau data
la care defectul a fost remediat (dacă defectul este
Vârsta defectului deja remediat).
Latent Defect Defecțiune ascunsă
Product Portfolio Management este gestionarea
centralizată a proceselor, metodelor și tehnologiilor
PPM utilizate de managerii de proiect
PPR Rapoarte de evaluare a performanței programului
MRM Managementul resurselor de marketing