La prova manual és un procés de prova de programari en què els casos de prova s'executen manualment sense utilitzar cap eina automatitzada. Tots els casos de prova executats pel provador manualment segons la perspectiva de l'usuari final. Assegura si l'aplicació funciona, tal com s'esmenta al document de requisits o no. Els casos de prova es planifiquen i s'implementen per completar gairebé el 100 per cent de l'aplicació de programari. Els informes de casos de prova també es generen manualment.

Les proves manuals són un dels processos de prova més fonamentals, ja que poden trobar defectes visibles i ocults del programari. La diferència entre la sortida esperada i la sortida, donada pel programari, es defineix com un defecte. El desenvolupador va solucionar els defectes i els va lliurar al provador per tornar a provar.

Les proves manuals són obligatòries per a cada programari desenvolupat recentment abans de les proves automatitzades. Aquesta prova requereix grans esforços i temps, però ofereix la garantia d'un programari lliure d'errors. Les proves manuals requereixen coneixements de tècniques de prova manuals, però no de cap eina de prova automatitzada.

Les proves manuals són essencials perquè una de les proves de programari els fonaments és 'l'automatització al 100% no és possible'.

Per què necessitem proves manuals

Sempre que una aplicació surt al mercat i és inestable o té un error o problemes o crea un problema mentre els usuaris finals l'utilitzen.

Si no volem enfrontar-nos a aquest tipus de problemes, hem de realitzar una ronda de proves per fer que l'aplicació estigui lliure d'errors i estable i lliurar un producte de qualitat al client, perquè si l'aplicació està lliure d'errors, l'usuari final utilitzarà l'aplicació de manera més còmoda.

Si l'enginyer de proves fa proves manuals, pot provar l'aplicació com a perspectiva de l'usuari final i familiaritzar-se més amb el producte, cosa que l'ajuda a escriure els casos de prova correctes de l'aplicació i donar-li una resposta ràpida.

fmovies Índia

Tipus de proves manuals

Hi ha diversos mètodes utilitzats per a les proves manuals. Cada tècnica s'utilitza segons els seus criteris de prova. A continuació s'indiquen els tipus de proves manuals:

• Prova de caixa blanca
• Prova de la caixa negra
• Prova de caixa grisa

Prova de caixa blanca

La prova de caixa blanca la fa el desenvolupador, on comproven cada línia d'un codi abans de lliurar-lo a l'enginyer de prova. Com que el codi és visible per al desenvolupador durant la prova, és per això que també es coneix com a prova de caixa blanca.

Per obtenir més informació sobre les proves de la caixa blanca, consulteu l'enllaç següent:

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

Prova de caixa negra

Les proves de la caixa negra les fa l'Enginyer de Tests, on poden comprovar la funcionalitat d'una aplicació o del programari segons les necessitats del client/client. En això, el codi no és visible mentre es realitza la prova; per això es coneix com a prova de caixa negra.

Per obtenir més informació sobre les proves de caixa negra, consulteu l'enllaç següent:

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

Prova de la caixa grisa

Les proves de caixa grisa són una combinació de proves de caixa blanca i caixa negra. Pot ser realitzat per una persona que coneixia tant la codificació com la prova. I si la persona soltera realitza la prova de caixa blanca, així com les proves de caixa negra per a l'aplicació, es coneix com a prova de caixa gris.

Per obtenir més detalls sobre les proves de la caixa grisa, consulteu l'enllaç següent:

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

Com realitzar les proves manuals

• En primer lloc, el provador observa tots els documents relacionats amb el programari per seleccionar les àrees de prova.
• El verificador analitza els documents de requisits per cobrir tots els requisits indicats pel client.
• Tester desenvolupa els casos de prova segons el document de requisits.
• Tots els casos de prova s'executen manualment mitjançant proves de caixa negra i proves de caixa blanca.
• Si es van produir errors, l'equip de proves ho informarà a l'equip de desenvolupament.
• L'equip de desenvolupament corregeix errors i va lliurar el programari a l'equip de proves per tornar a provar.

Procés de creació de programari

• Un cop recollit el requisit, es proporcionarà als dos equips de desenvolupament i proves diferents.
• Després d'obtenir el requisit, el desenvolupador interessat començarà a escriure el codi.
• I mentrestant, l'enginyer de proves entén el requisit i prepara els documents requerits, fins ara el desenvolupador pot completar el codi i emmagatzemar-lo al Eina de control de la versió .
• Després d'això, el codi canvia a la interfície d'usuari i aquests canvis els gestiona un equip independent, que es coneix com a construir equip .
• Aquest equip de compilació agafarà el codi i començarà a compilar i comprimir el codi amb l'ajuda d'una eina de compilació. Un cop tenim una sortida, la sortida passa al fitxer zip, que es coneix com Construir (aplicació o programari). Cada compilació tindrà un número únic com (B001, B002).
• Aleshores, aquesta compilació concreta s'instal·larà al servidor de prova. Després d'això, l'enginyer de proves accedirà a aquest servidor de proves amb l'ajuda de l'URL de prova i començarà a provar l'aplicació.
• Si l'enginyer de prova troba algun error, s'informarà al desenvolupador corresponent.
• Aleshores, el desenvolupador reproduirà l'error al servidor de prova i arreglarà l'error i tornarà a emmagatzemar el codi a l'eina de versió de control, i instal·larà el nou fitxer actualitzat i eliminarà el fitxer antic; aquest procés es continua fins que aconseguim la compilació estable.
• Un cop aconseguim el Build estable, es lliurarà al client.

Note1

• Un cop recollit el fitxer de l'eina de versió de control, utilitzarem l'eina de compilació per compilar el codi des d'un llenguatge d'alt nivell fins a un llenguatge de màquina. Després de la compilació, si la mida del fitxer augmentarà, comprimirem aquest fitxer en particular i el llançarem al servidor de prova.
• Aquest procés el realitza Construir equip , desenvolupador (si l'equip de creació no hi és, un desenvolupador pot fer-ho) o el cable de prova (si l'equip de creació gestiona directament el zip i instal·la l'aplicació al servidor de proves i informa l'enginyer de proves).
• En general, no podem obtenir una versió nova per a cada error; en cas contrari, la majoria del temps només es perdrà en crear les compilacions.

Nota 2

Construir equip

La feina principal de l'equip de compilació és crear l'aplicació o la compilació i convertir el llenguatge d'alt nivell en llenguatge de baix nivell.

Construir

És un programari, que s'utilitza per convertir el codi en format d'aplicació. I consta d'un conjunt de funcions i correccions d'errors que es lliuren a l'enginyer de proves amb finalitats de prova fins que es torni estable.

Eina de control de la versió

És un programari o aplicació, que s'utilitza amb les finalitats següents:

• En aquesta eina, podem desar diferents tipus de fitxers.
• Sempre està assegurat perquè accedim al fitxer des de les eines utilitzant les mateixes credencials d'inici de sessió.
• L'objectiu principal de les eines és fer un seguiment dels canvis fets per als fitxers existents.

Exemple de procés de construcció

Vegem un exemple per entendre com construir el treball del procés en els escenaris reals:

Tan bon punt l'enginyer de proves rebi l'error, l'enviarà als desenvolupadors i necessiten una mica de temps per analitzar; després d'això, només corregeix l'error (l'enginyer de proves no pot donar la col·lecció d'errors).

El desenvolupador decideix quants errors pot solucionar segons el seu temps. I es decideix l'enginyer de proves, quin error s'ha de solucionar primer segons les seves necessitats perquè els enginyers de proves no es poden permetre el luxe d'aturar les proves.

I l'enginyer de proves que rep el correu, només poden saber quin error ha corregit llista de les correccions d'errors .

El temps augmentarà perquè a la primera compilació, i els desenvolupadors haurien d'escriure el codi en les diferents funcions. I al final, només pot corregir els errors i el nombre de dies es reduirà.

Nota 3

Cicle de prova

El cicle de prova és el temps que es dóna a l'enginyer de prova per provar cada compilació.

Les diferències entre les dues construccions

Els errors es troben en una compilació i es poden solucionar qualsevol de les futures compilacions, que depèn del requisit de l'enginyer de prova. Cada nova compilació és la versió modificada de l'antiga, i aquestes modificacions podrien ser la correcció d'errors o l'addició d'algunes funcions noves.

Amb quina freqüència teníem la nova versió

Al principi, solíem obtenir compilacions setmanals, però en l'última etapa de proves, quan l'aplicació s'estava fent estable, solíem obtenir la nova compilació un cop cada 3 dies, dos dies o també cada dia.

Quantes construccions tenim

Si tenim en compte un any de durada del projecte, tenim entre 22 i 26 versions.

Quan rebem les correccions d'errors

En general, entenem que les correccions d'errors només s'han completat el cicle de prova, o la col·lecció d'errors s'ha solucionat en una compilació i la transferència a les següents compilacions.

Avantatges de les proves manuals

• No requereix coneixements de programació mentre s'utilitza el mètode de la caixa negra.
• S'utilitza per provar dissenys de GUI que canvien dinàmicament.
• El provador interactua amb el programari com a usuari real perquè pugui descobrir problemes d'usabilitat i interfície d'usuari.
• Assegura que el programari està cent per cent lliure d'errors.
• És rendible.
• Fàcil d'aprendre per als nous provadors.

Inconvenients de les proves manuals

• Requereix un gran nombre de recursos humans.
• És molt llarg.
• Tester desenvolupa casos de prova basats en les seves habilitats i experiència. No hi ha proves que hagin cobert totes les funcions o no.
• Els casos de prova no es poden tornar a utilitzar. Cal desenvolupar casos de prova separats per a cada programari nou.
• No ofereix proves en tots els aspectes de les proves.
• Com que dos equips treballen junts, de vegades és difícil entendre els motius dels altres, pot enganyar el procés.

Eines manuals de prova

En proves manuals, diferents tipus de proves com ara unitat, integració, seguretat, rendiment i seguiment d'errors, disposem de diverses eines com Jira, Bugzilla, Mantis, Zap, NUnit, Tessy, LoadRunner, Citrus, SonarQube, etc. mercat. Algunes de les eines són de codi obert i altres comercials.

Per obtenir més informació sobre les eines de prova, consulteu l'enllaç següent:

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

Anem a entendre-los un per un:

LoadRunner

Són les eines de prova de rendiment més utilitzades. LoadRunner s'utilitza principalment per donar suport a les proves de rendiment per a una àmplia gamma de procediments, nombre d'enfocaments i entorns d'aplicació.

L'objectiu principal d'executar l'eina LoadRunner és classificar ràpidament les fonts més habituals de problemes de rendiment.

Característiques de LoadRunner

• L'eina LoadRunner conté n-nombres d'aplicacions, cosa que redueix el temps per comprendre i descriure els informes.
• Podem obtenir informes exhaustius de proves de rendiment mitjançant l'eina LoadRunner.
• Reduirà el cost de les proves de càrrega distribuïda i també oferirà l'eina operativa per al seguiment del desplegament.

Cítrics

Citrus és una eina de prova d'integració, que és el marc de prova més utilitzat. Està escrit en Programació Java llenguatge. S'utilitza principalment per sol·licitar i respondre al costat del servidor i al costat del client i validar els fitxers XML JSON.

Per dur a terme les proves de casos d'ús d'extrem a extrem, Citrus admet diversos protocols HTTP, JMS i SOAP.

Característiques dels cítrics

A continuació es mostren algunes de les característiques importants de l'eina Citrus:

• S'utilitza per enviar i rebre missatges.
• Citrus està disponible com a codi obert i amb llicència al mercat.
• Ofereix una solució de baix cost.
• Podem autenticar la base de dades mitjançant l'eina de cítrics.
• Descriurà la seqüència de missatges, oferirà el pla de prova i documentarà la cobertura de la prova.
• Crea el missatge i verifica les respostes.

ZAP

ZAP és un escàner de seguretat d'aplicacions web de codi obert. És significa Proxy d'atac Zed . Igual que altres eines, també està escrit en el Llenguatge de programació JAVA . És el més efectiu Obriu els projectes de seguretat d'aplicacions web [OWASP].

Característiques de ZAP

• Admet molts sistemes operatius com Windows, Linux, OS X.
• Té una arquitectura basada en complements.
• Conté un mercat en línia que ens permet afegir funcions noves o actualitzades.
• El tauler de control de la GUI de ZAP és fàcil d'utilitzar.

Monja

NUnit és una de les eines de prova d'unitats més utilitzades. És una eina de codi obert i derivada principalment del JUnit .

Estava completament escrit al Llenguatge de programació C# i apte per a tothom Idiomes .Net .

En altres paraules, podem dir que l'eina NUnit està totalment redissenyada per convertir-se en l'avantatge de moltes qualitats del llenguatge .Net. Per exemple:

Capacitats relacionades amb la reflexió. Altres atributs personalitzats.

Característiques de NUnit

• Permet les afirmacions com a mètode estàtic de la classe d'avantatge.
• Sosté les proves basades en dades.
• Admet diverses plataformes, com ara .NET core Xamarin mobile, Silverlight i un marc eficient.
• La capacitat de NUnit ens ajuda a executar les proves simultàniament.
• Utilitza un corredor de consola per carregar i executar les proves.

JIRA

L'eina de seguiment d'errors més utilitzada és JIRA , que és una eina de codi obert. S'utilitza per al seguiment d'errors, la gestió de projectes i el seguiment de problemes.

proves de programari

En aquesta eina, podem rastrejar fàcilment tot tipus d'errors o defectes relacionats amb el programari i produïts pels enginyers de prova.

Característiques de JIRA

• És una eina que estalvia temps.
• Jira s'utilitza per fer un seguiment dels defectes i problemes.
• S'utilitza per establir les tasques de documentació.
• Jira és una eina molt útil per fer el seguiment de la millora de la nostra documentació.

Per obtenir la informació completa sobre l'eina Jira, consulteu l'enllaç següent: https://www.javatpoint.com/jira-tutorial .

SonarQube

Una altra eina de prova de proves manuals és SonarQube, que millora el nostre flux de treball amb una qualitat de codi contínua i seguretat de codi. És flexible amb l'ús de connectors.

Està completament escrit en el llenguatge de programació JAVA. Ofereix una avaluació i integració totalment automatitzada amb Ant, Maven, Gradle, MSBuild i eines d'integració constant. SonarQube té la capacitat d'enregistrar un historial de mètriques i proporciona el gràfic d'evolució.

Característiques de Sonarqube

A continuació es mostren algunes de les característiques significatives de l'eina SonarQube:

• Admet diversos llenguatges de programació com C, C++, Python, JAVA, HTML, CSS, VB.NET, PHP, COBOL, PL/SQL, etc.
• Sota la llicència pública general menor de GNU, Sonarqube està disponible gratuïtament.
• SonarQube està afiliat a algunes eines externes importants com GitHub, Active Directory, LDAP i altres.
• SonarQube es va fusionar amb els entorns de desenvolupament Visual Studio, Eclipse i IntelliJ IDEA a causa del SonarLint connectors.

JMeter

JMeter és una eina de codi obert que s'utilitza per provar el rendiment dels recursos estàtics i dinàmics i les aplicacions web dinàmiques.

Està completament dissenyat a l'aplicació JAVA per carregar el comportament de la prova funcional i mesurar el rendiment de l'aplicació.

Facilita als usuaris o desenvolupadors utilitzar el codi font per al desenvolupament d'altres aplicacions.

Característiques de JMeter

A continuació es mostren algunes de les característiques essencials de JMeter:

• És independent de la plataforma, que accepta una JVM similar Windows, Mac i Linux, etc.
• Admet una GUI fàcil d'utilitzar, que és interactiva i senzilla.
• És increïblement extensible per carregar la prova de rendiment en diversos tipus de servidors.

Per obtenir més informació sobre JMeter, consulteu l'enllaç següent:

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

Amb Bugz

Una altra eina de seguiment d'errors utilitzada a les proves manuals és Amb Bugz .

És el més utilitzat per moltes organitzacions per fer un seguiment dels diversos errors de l'aplicació.

Bugzilla és una eina de codi obert que ajuda el client i el client a fer un seguiment dels defectes. Bugzilla també es considera una eina de gestió de proves perquè en aquesta, podem enllaçar fàcilment altres eines de gestió de casos de prova com ALM, Quality Center, etc.

Característiques de Bugzilla

Bugzilla té algunes funcions addicionals que ens ajuden a informar de l'error fàcilment:

• És compatible amb diversos sistemes operatius com Windows, Linux i Mac.
• Amb l'ajuda de Bugzilla, podem enumerar un error en diversos formats.
• Les preferències de l'usuari poden mesurar la notificació per correu electrònic.
• Bugzilla té capacitats de cerca avançades.

Mantis

Mantis és un sistema de seguiment d'errors basat en web. ManitsBT significa Mantis Bug Tracker . S'utilitza per seguir els defectes del programari i es realitza en el llenguatge de programació PHP. També és una eina de codi obert.

Característiques de Mantis

Algunes de les característiques estàndard de l'eina en particular són les següents:

• Amb l'ajuda d'aquesta eina, tenim accessibilitat a la cerca de text complet.
• Pistes d'auditoria dels canvis fets als problemes.
• Proporciona la integració del sistema de control de revisions.
• Control de revisió de camps de text i notes

Per obtenir més detalls sobre les eines de seguiment d'errors, consulteu l'enllaç següent: https://www.javatpoint.com/defect-or-bug-tracking-tool .

Tessy

Una altra eina de prova d'integració és Tessy , que s'utilitza per realitzar la integració i les proves d'unitat per al programari incrustat. També ens ajuda a descobrir la cobertura de codi del programari o d'una aplicació.

Pot gestionar fàcilment tota l'organització de proves, incloses les necessitats empresarials, la gestió de proves, la quantitat de cobertura i la traçabilitat.

Tessy conté tres funcions principals, que són les següents:

• Editor d'interfície de prova (TIE)
• Editor de dades de prova (TDE)
• Espai de treball.

Característiques de TESSY

Les característiques estàndard del TESSY són les següents:

• Produeix l'informe de prova per als resultats d'execució de la prova.
• Admet diversos llenguatges de programació com C i C++.
• Tessy s'utilitza per avaluar la interfície de la funció i descriu la variable utilitzada per aquesta funció.

Per obtenir més informació sobre les eines de prova d'integració, consulteu l'enllaç següent: https://www.javatpoint.com/integration-testing-tools .

Visió general

En aquest article, hem vist informació detallada sobre Proves manuals, que inclouen la definició de proves manuals, la necessitat de proves manuals, tipus de proves manuals, eines de proves manuals, el procés de proves manuals i alguns avantatges i inconvenients importants d'aquesta.

Finalment, podem dir que, és un procés on l'enginyer de proves ha de ser molt persistent, innovador i sensible.

En les proves manuals, l'enginyer de proves ha de pensar i actuar com la interpretació de l'usuari final.

Per implementar les proves manuals, un enginyer de proves necessita habilitats productives i imaginació. I han de pensar en múltiples situacions o escenaris per provar una aplicació específica.

Tot i que actualment podem provar gairebé totes les aplicacions amb l'ajuda de proves d'automatització, les proves manuals són necessàries, ja que són la base de les proves de programari.