Testarea manuală este un proces de testare a software-ului în care cazurile de testare sunt executate manual fără a utiliza niciun instrument automat. Toate cazurile de testare sunt executate manual de către tester în funcție de perspectiva utilizatorului final. Acesta asigură dacă aplicația funcționează, așa cum este menționat în documentul de cerințe sau nu. Cazurile de testare sunt planificate și implementate pentru a finaliza aproape 100% din aplicația software. Rapoartele de cazuri de testare sunt, de asemenea, generate manual.

Testarea manuală este unul dintre cele mai fundamentale procese de testare, deoarece poate găsi atât defecte vizibile, cât și ascunse ale software-ului. Diferența dintre rezultatul așteptat și rezultatul, dată de software, este definită ca un defect. Dezvoltatorul a remediat defectele și l-a predat testerului pentru retestare.

Testarea manuală este obligatorie pentru fiecare software nou dezvoltat înainte de testarea automată. Această testare necesită eforturi mari și timp, dar oferă siguranța unui software fără erori. Testarea manuală necesită cunoștințe despre tehnicile de testare manuală, dar nu și despre orice instrument de testare automată.

Testarea manuală este esențială deoarece una dintre testarea software-ului Fundamentele este „Automatizarea 100% nu este posibilă”.

înlocuirea metodei java

De ce avem nevoie de testare manuală

Ori de câte ori o aplicație intră pe piață și este instabilă sau are o eroare sau probleme sau creează o problemă în timp ce utilizatorii finali o folosesc.

Dacă nu vrem să ne confruntăm cu acest tip de probleme, trebuie să efectuăm o rundă de testare pentru a face aplicația fără erori și stabilă și pentru a livra clientului un produs de calitate, deoarece dacă aplicația este fără erori, utilizatorul final va folosi aplicația mai convenabil.

Dacă inginerul de testare efectuează teste manuale, el/ea poate testa aplicația ca perspectivă a utilizatorului final și se poate familiariza mai bine cu produsul, ceea ce îi ajută să scrie cazurile de testare corecte ale aplicației și să ofere feedback rapid al aplicației.

Tipuri de testare manuală

Există diferite metode utilizate pentru testarea manuală. Fiecare tehnică este utilizată conform criteriilor sale de testare. Tipurile de testare manuală sunt prezentate mai jos:

• Testarea cutiei albe
• Testarea cutiei negre
• Testarea cutiei gri

Testarea cutiei albe

Testarea casetei albe este realizată de dezvoltator, unde verifică fiecare linie a unui cod înainte de a-l da inginerului de testare. Deoarece codul este vizibil pentru Dezvoltator în timpul testării, de aceea este cunoscut și sub numele de testare cutie albă.

Pentru mai multe informații despre testarea cutiei albe, consultați linkul de mai jos:

https://www.javatpoint.com/white-box-testing

Testarea cutiei negre

Testarea cutiei negre este realizată de Inginerul de Testare, unde poate verifica funcționalitatea unei aplicații sau a software-ului în funcție de nevoile clientului/clientului. În aceasta, codul nu este vizibil în timpul efectuării testării; de aceea este cunoscut sub numele de testare cutie neagră.

Pentru mai multe informații despre testarea cutie neagră, consultați linkul de mai jos:

https://www.javatpoint.com/black-box-testing

Testarea Grey Box

Testarea cutie gri este o combinație de testare cutie albă și cutie neagră. Poate fi efectuat de o persoană care știa atât codificare, cât și testare. Și dacă persoana singură realizează cutia albă, precum și testarea cutie neagră pentru aplicație, este cunoscută ca testare cutie gri.

Pentru a obține mai multe detalii despre testarea casetei gri, consultați linkul de mai jos:

https://www.javatpoint.com/grey-box-testing

Cum se efectuează testarea manuală

• În primul rând, testerul observă toate documentele legate de software, pentru a selecta zonele de testare.
• Testerul analizează documentele cerințelor pentru a acoperi toate cerințele declarate de client.
• Testerul dezvoltă cazurile de testare conform documentului de cerințe.
• Toate cazurile de testare sunt executate manual utilizând testarea cutiei negre și testarea cutiei albe.
• Dacă au apărut erori, atunci echipa de testare informează echipa de dezvoltare.
• Echipa de dezvoltare remediază erori și a predat software-ul echipei de testare pentru retestare.

Procesul de construire a software-ului

• Odată ce cerința este colectată, aceasta va oferi celor două echipe diferite de dezvoltare și testare.
• După obținerea cerinței, dezvoltatorul în cauză va începe să scrie codul.
• Și, între timp, inginerul de testare înțelege cerința și pregătește documentele necesare, până acum dezvoltatorul poate completa codul și poate stoca în Instrumentul Versiune de control .
• După aceea, codul se modifică în interfața de utilizare, iar aceste modificări sunt gestionate de o echipă separată, care este cunoscută sub numele de construi echipa .
• Această echipă de compilare va prelua codul și va începe să compilați și să comprima codul cu ajutorul unui instrument de compilare. Odată ce obținem o ieșire, rezultatul merge în fișierul zip, care este cunoscut ca Construi (aplicație sau software). Fiecare Build va avea un număr unic, cum ar fi (B001, B002).
• Apoi, această versiune specială va fi instalată pe serverul de testare. După aceea, inginerul de testare va accesa acest server de testare cu ajutorul URL-ului de testare și va începe testarea aplicației.
• Dacă inginerul de testare a găsit vreo eroare, el/ea va fi raportat dezvoltatorului în cauză.
• Apoi, dezvoltatorul va reproduce eroarea în serverul de testare și va repara eroarea și va stoca din nou codul în instrumentul Versiune de control și va instala noul fișier actualizat și va elimina fișierul vechi; acest proces este continuat până când obținem Build-ul stabil.
• Odată ce obținem Build-ul stabil, acesta va fi predat clientului.

Nota 1

• Odată ce colectăm fișierul din instrumentul Control version, vom folosi instrumentul de compilare pentru a compila codul din limbajul de nivel înalt în limbajul la nivel de mașină. După compilare, dacă dimensiunea fișierului va crește, vom comprima acel fișier și îl vom arunca în serverul de testare.
• Acest proces este realizat de Construiește echipa , dezvoltator (dacă echipa de construcție nu este acolo, un dezvoltator o poate face) sau cablu de testare (dacă echipa de construcție se ocupă direct de zip și instalează aplicația pe serverul de testare și informează inginerul de testare).
• În general, nu putem obține o nouă versiune pentru fiecare eroare; altfel, de cele mai multe ori va fi pierdut doar în crearea construcțiilor.

Nota 2

Construiește echipa

Principala sarcină a echipei de compilare este să creeze aplicația sau Build-ul și să convertească limbajul de nivel înalt în limbaj de nivel scăzut.

Construi

Este un software, care este folosit pentru a converti codul în format de aplicație. Și constă dintr-un set de caracteristici și remedieri de erori care sunt predate inginerului de testare în scopuri de testare până când devine stabil.

Instrumentul pentru versiunea de control

Este un software sau o aplicație, care este utilizată în următorul scop:

• În acest instrument, putem salva diferite tipuri de fișiere.
• Este întotdeauna securizat deoarece accesăm fișierul din instrumente folosind aceleași date de conectare.
• Obiectivul principal al instrumentelor este de a urmări modificările efectuate pentru fișierele existente.

Exemplu de proces de construire

Să vedem un exemplu pentru a înțelege cum să construiți procesul de lucru pe scenariile reale:

De îndată ce inginerul de testare primește bug-ul, îl va trimite dezvoltatorilor și au nevoie de ceva timp pentru a analiza; după aceea, el/ea remediază doar eroarea (Inginerul de testare nu poate oferi colecția de erori).

Dezvoltatorul este hotărât câte erori poate remedia în funcție de timpul lor. Și inginerul de testare este hotărât, care bug ar trebui remediat mai întâi în funcție de nevoile lor, deoarece inginerii de testare nu își pot permite să oprească testarea.

Și inginerul de testare care primește e-mailul, ei pot ști doar care eroare este remediată de lista cu remedieri de erori .

Timpul va crește, deoarece la prima versiune, dezvoltatorii ar trebui să scrie codul în diferitele caracteristici. Și la sfârșit, el/ea poate face doar remedierea erorilor și numărul de zile va fi scăzut.

Nota 3

Ciclu de testare

Ciclul de testare este durata de timp acordată inginerului de testare pentru a testa fiecare Build.

Se formează diferențe între cele două

Bug-urile găsite într-o versiune și pot fi remediate în oricare din viitoarea versiune, care depinde de cerințele inginerului de testare. Fiecare versiune nouă este versiunea modificată a celei vechi, iar aceste modificări ar putea fi remedieri de erori sau adăugarea unor funcții noi.

Cât de des primim noua versiune

La început, obișnuiam să obținem build-uri săptămânale, dar în ultima etapă de testare, când aplicația devenea stabilă, obișnuiam să obținem noua Build o dată la 3 zile, două zile sau, de asemenea, zilnic.

Câte build-uri avem

Dacă luăm în considerare un an din durata oricărui proiect, avem 22-26 de versiuni.

Când primim remedierea erorilor

În general, înțelegem remedierea erorilor numai după ce ciclul de testare este finalizat sau colecția de erori este remediată într-o versiune și transferul în următoarele versiuni.

manipularea șirurilor de caractere în c++

Avantajele testării manuale

• Nu necesită cunoștințe de programare în timpul utilizării metodei cutie neagră.
• Este folosit pentru a testa design-uri GUI care se schimbă dinamic.
• Testerul interacționează cu software-ul ca un utilizator real, astfel încât acesta să poată descoperi problemele de utilizare și interfața cu utilizatorul.
• Se asigură că software-ul este sută la sută fără erori.
• Este rentabil.
• Ușor de învățat pentru noii testeri.

Dezavantajele testării manuale

• Este nevoie de un număr mare de resurse umane.
• Este foarte consumator de timp.
• Tester dezvoltă cazuri de testare pe baza abilităților și experienței lor. Nu există dovezi că au acoperit sau nu toate funcțiile.
• Cazurile de testare nu pot fi folosite din nou. Este necesar să se dezvolte cazuri de testare separate pentru fiecare software nou.
• Nu oferă testare pentru toate aspectele testării.
• Deoarece două echipe lucrează împreună, uneori este dificil să se înțeleagă motivele celuilalt, poate induce în eroare procesul.

Instrumente manuale de testare

În testarea manuală, diferite tipuri de testare, cum ar fi unitatea, integrarea, securitatea, performanța și urmărirea erorilor, avem diverse instrumente, cum ar fi Jira , Bugzilla , Mantis, Zap, NUnit, Tessy, LoadRunner, Citrus, SonarQube etc. disponibile în piaţă. Unele dintre instrumente sunt open-source, iar altele sunt comerciale.

Pentru mai multe informații despre instrumentele de testare, consultați linkul de mai jos:

https://www.javatpoint.com/software-testing-tools

Să le înțelegem unul câte unul:

LoadRunner

Este cel mai frecvent utilizate instrumente de testare a performanței. LoadRunner este utilizat în principal pentru a susține testarea performanței pentru o gamă largă de proceduri, număr de abordări și medii de aplicație.

Scopul principal al executării instrumentului LoadRunner este de a clasifica rapid cele mai comune surse de probleme de performanță.

Caracteristicile LoadRunner

• Instrumentul LoadRunner conține n numere de aplicații, ceea ce reduce timpul de înțelegere și descriere a rapoartelor.
• Putem obține rapoarte amănunțite de testare a performanței utilizând instrumentul LoadRunner.
• Va reduce costul testării de încărcare distribuită și va oferi, de asemenea, instrumentul operațional pentru urmărirea implementării.

Citrice

Citrus este un instrument de testare a integrării, care este cel mai des folosit cadru de testare. Este scris în Programare Java limba. Este folosit mai ales pentru a solicita și a răspunde la partea serverului și a clientului și pentru a valida fișierele XML JSON.

Pentru a realiza testele de utilizare end-to-end, citrus acceptă mai multe protocoale HTTP, JMS și SOAP.

Caracteristicile citricelor

Iată câteva dintre caracteristicile importante ale instrumentului Citrus:

• Este folosit pentru a trimite și primi mesaje.
• Citrus este disponibil atât ca sursă deschisă, cât și ca licență pe piață.
• Oferă o soluție cu costuri reduse.
• Putem autentifica baza de date folosind instrumentul de citrice.
• Acesta va descrie secvența de mesaje, va oferi planul de testare și va documenta acoperirea testului.
• Acesta creează mesajul și verifică răspunsurile.

ZAP

ZAP este un scaner de securitate pentru aplicații web open-source. Este standuri pentru Zed Attack Proxy . La fel ca și alte instrumente, este scris și în limbaj de programare JAVA . Este cel mai eficient Deschideți Proiecte de securitate pentru aplicații web [OWASP].

Caracteristicile ZAP

• Suportă multe sisteme de operare precum Windows, Linux, OS X.
• Are o arhitectură bazată pe pluginuri.
• Conține o piață online care ne permite să adăugăm funcții noi sau actualizate.
• Panoul de control GUI al ZAP este ușor de utilizat.

Călugăriţă

NUnit este unul dintre cele mai frecvent utilizate instrumente de testare unitară. Este un instrument open-source și derivat în principal din JUnit .

A fost complet scris în Limbajul de programare C# si potrivit pentru toti .Limbi nete .

Cu alte cuvinte, putem spune că instrumentul NUnit este complet reproiectat pentru a deveni avantajul multor calități ale limbajului .Net. De exemplu:

Capacități legate de reflecție. Alte atribute personalizate.

Caracteristicile NUnit

• Permite aserțiunile ca metodă statică a clasei de avantaj.
• Susține testele bazate pe date.
• Acceptă mai multe platforme, cum ar fi .NET core Xamarin mobile, Silverlight și framework eficient.
• Abilitatea NUnit ne ajută să executăm testele simultan.
• Folosește un runner de consolă pentru a încărca și a executa testele.

JIRA

Cel mai des folosit instrument de urmărire a erorilor este JIRA , care este un instrument open-source. Este folosit pentru urmărirea erorilor, managementul proiectelor și urmărirea problemelor.

rând și coloană

În acest instrument, putem urmări cu ușurință tot felul de erori sau defecte legate de software și produse de inginerii de testare.

Caracteristicile JIRA

• Este un instrument care economisește timp.
• Jira este folosit pentru a urmări defectele și problemele.
• Este folosit pentru stabilirea sarcinilor de documentare.
• Jira este un instrument foarte util în urmărirea îmbunătățirii documentației noastre.

Pentru a obține informații complete despre instrumentul Jira, consultați linkul de mai jos: https://www.javatpoint.com/jira-tutorial .

SonarQube

Un alt instrument de testare de testare manuală este SonarQube, care ne îmbunătățește fluxul de lucru cu calitate continuă a codului și securitatea codului. Este flexibil cu utilizarea plug-in-urilor.

Este complet scris în limbajul de programare JAVA. Oferă evaluare și integrare complet automatizate cu Ant, Maven, Gradle, MSBuild și instrumente de integrare constantă. SonarQube are capacitatea de a înregistra un istoric al valorilor și oferă graficul de evoluție.

Caracteristicile Sonarqube

Mai jos sunt câteva dintre caracteristicile semnificative ale instrumentului SonarQube:

• Suportă mai multe limbaje de programare precum C, C++, Python, JAVA, HTML, CSS, VB.NET, PHP, COBOL, PL/SQL etc.
• Conform licenței publice generale minore GNU, Sonarqube este disponibil gratuit.
• SonarQube este afiliat cu unele instrumente externe importante, cum ar fi GitHub, Active Directory, LDAP și altele.
• SonarQube a fuzionat cu mediile de dezvoltare Visual Studio, Eclipse și IntelliJ IDEA datorită SonarLint plug-in-uri.

JMeter

JMeter este un instrument open-source care este folosit pentru a testa performanța resurselor statice și dinamice și a aplicațiilor web dinamice.

Este complet proiectat pe aplicația JAVA pentru a încărca comportamentul de testare funcțional și pentru a măsura performanța aplicației.

Facilitează utilizatorilor sau dezvoltatorilor să utilizeze codul sursă pentru dezvoltarea altor aplicații.

Caracteristicile JMeter

Mai jos sunt câteva dintre caracteristicile esențiale ale JMeter:

• Este independent de platformă, care acceptă un JVM similar Windows, Mac și Linux etc.
• Acesta acceptă o interfață grafică ușor de utilizat, care este interactivă și simplă.
• Este incredibil de extensibil să încărcați testul de performanță în mai multe tipuri de servere.

Pentru mai multe informații despre JMeter, consultați linkul de mai jos:

https://www.javatpoint.com/jmeter-tutorial.

Cu Bugz

Un alt instrument de urmărire a erorilor folosit în testarea manuală este Cu Bugz .

Este cel mai utilizat de multe organizații pentru a urmări diferitele erori ale aplicației.

Bugzilla este un instrument open-source care ajută clientul și clientul să țină evidența defectelor. Bugzilla este, de asemenea, considerat un instrument de gestionare a testelor, deoarece, în acest sens, putem conecta cu ușurință alte instrumente de gestionare a cazurilor de testare, cum ar fi ALM, Centrul de calitate etc.

Caracteristicile Bugzilla

Bugzilla are câteva caracteristici suplimentare care ne ajută să raportăm cu ușurință eroarea:

• Acceptă diverse sisteme de operare, cum ar fi Windows, Linux și Mac.
• Cu ajutorul lui Bugzilla, putem enumera un bug în mai multe formate.
• Preferințele utilizatorului pot măsura notificarea prin e-mail.
• Bugzilla are capabilități avansate de căutare.

Mantis

Mantis este un sistem de urmărire a erorilor bazat pe web. ManitsBT înseamnă Mantis Bug Tracker . Este folosit pentru a urmări defectele software și este realizat în limbajul de programare PHP. Este, de asemenea, un instrument open-source.

Caracteristicile lui Mantis

Unele dintre caracteristicile standard ale instrumentului special sunt următoarele:

• Cu ajutorul acestui instrument, avem accesibilitate pentru căutarea în text integral.
• Traseele de audit ale modificărilor aduse problemelor.
• Oferă integrarea sistemului de control al revizuirii.
• Controlul revizuirii câmpurilor de text și notelor

Pentru a obține mai multe detalii despre instrumentele de urmărire a erorilor, consultați următorul link: https://www.javatpoint.com/defect-or-bug-tracking-tool .

Tessy

Un alt instrument de testare a integrării este Tessy , care este utilizat pentru a efectua integrarea și testarea unitară pentru software-ul încorporat. De asemenea, ne ajută să descoperim acoperirea de cod a software-ului sau a unei aplicații.

dimensiunea linguritei

Poate gestiona cu ușurință întreaga organizație de testare, inclusiv nevoile afacerii, managementul testelor, cantitatea de acoperire și trasabilitatea.

Tessy conține trei funcții principale, care sunt după cum urmează:

• Editor de interfață de testare (TIE)
• Editor de date de testare (TDE)
• Spațiul de lucru.

Caracteristicile lui TESSY

Caracteristicile standard ale TESSY sunt următoarele:

• Produce raportul de testare pentru rezultatele executării testului.
• Acceptă diverse limbaje de programare, cum ar fi C și C++.
• Tessy este folosit pentru a evalua interfața funcției și descrie variabila utilizată de acea funcție.

Pentru mai multe informații despre instrumentele de testare a integrării, consultați următorul link: https://www.javatpoint.com/integration-testing-tools .

Prezentare generală

În acest articol, am văzut informații detaliate despre Testarea manuală, care include definiția testării manuale, necesitatea testării manuale, tipul de testare manuală, instrumente de testare manuală, procesul de testare manuală și câteva avantaje și dezavantaje importante ale acesteia.

În cele din urmă, putem spune că este un proces în care inginerul de testare trebuie să fie foarte persistent, inovator și receptiv.

În testarea manuală, inginerul de testare trebuie să gândească și să efectueze ca interpretarea utilizatorului final.

Pentru a implementa testarea manuală, un inginer de testare are nevoie de abilități productive și imaginație. Și trebuie să se gândească la mai multe situații sau scenarii pentru a testa o anumită aplicație.

Chiar dacă în prezent putem testa aproape toate aplicațiile cu ajutorul testării automate, totuși testarea manuală este necesară, deoarece este baza testării software.