Un pla de proves és un document detallat que descriu àrees i activitats de prova de programari. Destaca l'estratègia de prova, els objectius, el calendari de proves, els recursos necessaris (recursos humans, programari i maquinari), l'estimació de la prova i els lliuraments de la prova.

linux mint canyella vs mate

El pla de proves és la base de les proves de cada programari. És l'activitat més crucial que garanteix la disponibilitat de totes les llistes d'activitats planificades en una seqüència adequada.

El pla de proves és una plantilla per dur a terme activitats de prova de programari com un procés definit que està totalment supervisat i controlat pel gestor de proves. El pla de proves el prepara el responsable de proves (60%), el responsable de proves (20%) i l'enginyer de proves (20%).

Tipus de pla de proves

Hi ha tres tipus de pla de prova

• Pla mestre de proves
• Pla de proves de fase
• Tipus d'assaig Plans de prova específics

Pla mestre de proves

El Pla de proves mestre és un tipus de pla de proves que té diversos nivells de proves. Inclou una estratègia de prova completa.

Pla de proves de fase

Un pla de prova de fase és un tipus de pla de prova que aborda qualsevol fase de l'estratègia de prova. Per exemple, una llista d'eines, una llista de casos de prova, etc.

Plans de proves específics

Pla de proves específic dissenyat per als principals tipus de proves, com ara proves de seguretat, proves de càrrega, proves de rendiment, etc. En altres paraules, un pla de proves específic dissenyat per a proves no funcionals.

Com escriure un pla de proves

Elaborar un pla de proves és la tasca més crucial del procés de gestió de proves. Segons IEEE 829, seguiu els set passos següents per preparar un pla de prova.

• En primer lloc, analitzeu l'estructura i l'arquitectura del producte.
• Ara dissenyeu l'estratègia de prova.
• Definiu tots els objectius de la prova.
• Definir l'àrea de prova.
• Definir tots els recursos utilitzables.
• Programar totes les activitats d'una manera adequada.
• Determineu tots els resultats de la prova.

Components o atributs del pla de proves

El pla de proves consta de diverses parts, que ens ajuden a derivar tota l'activitat de prova.

Objectius: Consisteix en informació sobre mòduls, característiques, dades de prova, etc., que indiquen l'objectiu de l'aplicació significa el comportament de l'aplicació, objectiu, etc.

Àmbit: Conté informació que s'ha de provar amb la corresponent aplicació. L'àmbit d'aplicació es pot dividir a més en dues parts:

• En abast
• Fora àmbit

En l'abast: Aquests són els mòduls que s'han de provar amb rigor (en detall).

Fora àmbit: Aquests són els mòduls, que no cal provar-los amb rigor.

Per exemple , Suposem que tenim una aplicació de Gmail per provar, on característiques a provar tal com Redacta correu, elements enviats, safata d'entrada, esborranys i la característiques que no es poden provar tal com Ajuda , i així successivament, el que significa que en l'etapa de planificació, decidirem quina funcionalitat s'ha de comprovar o no en funció del límit de temps indicat en el producte.

Ara com decidim quines funcions no s'han de provar?

Tenim els següents aspectes on podem decidir quina característica no es prova:

• Com veiem més amunt Ajuda Les característiques no es provaran, ja que està escrit i desenvolupat per l'escriptor tècnic i revisat per un altre escriptor professional.
• Suposem que tenim una aplicació que té P, Q, R i S característiques, que s'han de desenvolupar en funció dels requisits. Però aquí, la funció S ja ha estat dissenyada i utilitzada per una altra empresa. Així, l'equip de desenvolupament comprarà S d'aquesta empresa i s'integrarà amb funcions addicionals com ara P, Q i R.

Ara, no realitzarem proves funcionals a la funció S perquè ja s'ha utilitzat en temps real. Però farem les proves d'integració i les proves del sistema entre les funcions P, Q, R i S perquè és possible que les noves funcions no funcionin correctament amb la funció S com podem veure a la imatge següent:

• Suposem que en la primera versió del producte, els elements que s'han desenvolupat, com ara P, Q, R, S, T, U, V, W…..X, Y, Z . Ara el client proporcionarà els requisits per a les noves característiques que milloren el producte en la segona versió i les noves característiques A1, B2, C3, D4 i E5.

Després d'això, escriurem l'abast durant el pla de prova com

Àmbit

Característiques a provar

A1, B2, C3, D4, E5 (funcions noves)

P, Q, R, S, T

Característiques que no s'han de provar

W…..X, Y, Z

Per tant, primer comprovarem les noves característiques i després continuarem amb les antigues perquè això podria veure's afectat després d'afegir les noves característiques, el que significa que també afectarà les àrees d'impacte, de manera que farem una ronda de proves de regressió per a P, Q , R..., T característiques.

Metodologia de prova:

Conté informació sobre la realització d'un tipus de prova diferent, com ara proves funcionals, proves d'integració i proves del sistema, etc. a l'aplicació. En això, decidirem quin tipus de prova; realitzarem les diferents funcions en funció del requisit de l'aplicació. I aquí, també hauríem de definir quin tipus de proves utilitzarem en les metodologies de prova perquè tothom, com la direcció, l'equip de desenvolupament i l'equip de proves, puguin entendre fàcilment perquè els termes de prova no són estàndard.

cadena convertidora fins a la data

Per exemple, per a aplicacions autònomes com ara Adobe Photoshop , realitzarem els següents tipus de proves:

Proves de fum → Proves funcionals → Proves d'integració → Proves del sistema → Proves adhoc → Proves de compatibilitat → Proves de regressió → Proves de globalització → Proves d'accessibilitat → Proves d'usabilitat → Proves de fiabilitat → Proves de recuperació → Proves d'instal·lació o desinstal·lació

I suposem que hem de provar https://www.jeevansathi.com/ aplicació, de manera que realitzarem els següents tipus de proves:

Aproximació

Aquest atribut s'utilitza per descriure el flux de l'aplicació mentre es realitza la prova i per a la futura referència.

Podem entendre el flux de l'aplicació amb l'ajuda dels aspectes següents:

Escrivint els escenaris d'alt nivell Escrivint el gràfic de flux

Escrivint els escenaris d'alt nivell

Per exemple , suposem que estem provant el Gmail aplicació:

• Inicieu sessió a Gmail: envia un correu electrònic i comproveu si es troba a la pàgina Elements enviats
• Iniciar Sessió en …….
• ……
• …....

Estem escrivint això per descriure els enfocaments que s'han de seguir per provar el producte i només per a les característiques crítiques on escriurem els escenaris d'alt nivell. Aquí, no ens centrarem a cobrir tots els escenaris perquè l'enginyer de proves en particular pot decidir quines funcions s'han de provar o no.

Escrivint el gràfic de flux

El gràfic de flux s'escriu perquè escriure els escenaris d'alt nivell requereix un procés de bits de temps, com podem veure a la imatge següent:

Estem creant gràfics de flux per obtenir els següents beneficis, com ara:

• La cobertura és fàcil
• La fusió és fàcil

L'enfocament es pot classificar en dues parts que són les següents:

• Aproximació de dalt a baix
• Aproximació de baix a dalt

Assumpció

Conté informació sobre un problema o problema que es pot produir durant el procés de prova i quan estem escrivint els plans de prova, les hipòtesis assegurades es faran com a recursos i tecnologies, etc.

Risc

Aquests són els reptes als quals hem d'enfrontar-nos per provar l'aplicació en la versió actual i si les hipòtesis fracassaran, hi ha riscos.

Per exemple, l'efecte d'una aplicació, la data de llançament es posposa.

Pla de mitigació o Pla de contingència

És un pla de seguretat que està preparat per superar els riscos o problemes.

Vegem un exemple d'assumpció, risc i pla de contingència junts perquè estan correlacionats entre si.

En qualsevol producte, el suposició que farem és que els 3 enginyers de proves estaran allà fins a la finalització del producte i a cadascun d'ells se li assignen diferents mòduls com ara P, Q i R. En aquest escenari particular, el risc podria ser això si l'enginyer de proves deixés el projecte al mig.

Per tant, el Pla de contingència s'assignarà un propietari principal i un subordinat a cada característica. Per tant, si l'enginyer de prova únic marxa, el propietari subordinat es fa càrrec d'aquesta característica específica i també ajuda el nou enginyer de prova, perquè pugui entendre els seus mòduls assignats.

Els supòsits, el risc i el pla de mitigació o de contingència són sempre precisos en el propi producte. Els diferents tipus de riscos són els següents:

• Perspectiva del client
• Enfocament de recursos
• Opinió tècnica

Rol i responsabilitat

Defineix la tasca completa que ha de realitzar tot l'equip de proves. Quan arriba un gran projecte, aleshores Gestor de proves és una persona que redacta el pla de prova. Si hi ha 3-4 projectes petits, el responsable de proves assignarà cada projecte a cada líder de prova. A continuació, el responsable de la prova escriu el pla de prova del projecte, que se li assigna.

Vegem un exemple en què entendrem les funcions i la responsabilitat del gestor de proves, el responsable de proves i els enginyers de proves.

Funció: responsable de proves

Nom: Ryan

Responsabilitat:

• Preparar (escriure i revisar) el pla de prova
• Realitzar la reunió amb l'equip de desenvolupament
• Realitzar la reunió amb l'equip de proves
• Realitzar la reunió amb el client
• Realitzar una reunió dempeus mensual
• Tanqueu la nota de llançament
• Gestió d'escalades i problemes

Funció: cap de prova

Nom: Harvey

Responsabilitat:

• Preparar (escriure i revisar) el pla de prova
• Realitzar una reunió dempeus diària
• Revisar i aprovar el cas de prova
• Preparar el RTM i els informes
• Assignar mòduls
• Horari de gestió

Funció: Enginyer de proves 1, Enginyer de proves 2 i Enginyer de proves 3

diferència simètrica

Nom: Louis, Jessica, Donna

Assigna mòduls: M1, M2 i M3

Responsabilitat:

• Escriu, revisa i executa els documents de prova que consisteixen en casos de prova i escenaris de prova
• Llegir, revisar, comprendre i analitzar el requisit
• Escriu el flux de l'aplicació
• Executeu el cas de prova
• RTM per als mòduls respectius
• Seguiment de defectes
• Elaborar l'informe d'execució de la prova i comunicar-lo al responsable de la prova.

Horari

S'utilitza per explicar el temps per treballar, què s'ha de fer o aquest atribut cobreix quan exactament ha d'iniciar i acabar cada activitat de prova? I també s'esmenten les dades exactes per a cada activitat de prova per a la data concreta.

Per tant, com podem veure a la imatge de sota, per a l'activitat concreta, hi haurà una data d'inici i una data de finalització; per a cada prova d'una compilació específica, hi haurà la data especificada.

Per exemple

• Redacció de casos de prova
• Procés d'execució

Seguiment de defectes

Generalment es fa amb l'ajuda d'eines perquè no podem fer un seguiment manual de l'estat de cada error. I també comentem sobre com comuniquem els errors que s'identifiquen durant el procés de prova i els enviem de nou a l'equip de desenvolupament i com respondrà l'equip de desenvolupament. Aquí també esmentem la prioritat dels errors com ara alt, mitjà i baix.

A continuació es mostren diversos aspectes del seguiment de defectes:

Tècniques per rastrejar l'error
…..
……
……
……Eines de seguiment d'errors
Podem comentar el nom de l'eina, que utilitzarem per fer el seguiment dels errors. Algunes de les eines de seguiment d'errors més utilitzades són Jira, Bugzilla, Mantis i Trac, etc.<Severitat
La gravetat podria ser la següent:
Bloquejador o showstopper
…..
..... (Explica-ho amb un exemple al pla de prova)
Per exemple , hi haurà un defecte en el mòdul; no podem anar més enllà per provar altres mòduls perquè si l'error està bloquejat, podem procedir a comprovar altres mòduls.
Crític
……
..... (Explica-ho amb un exemple al pla de prova)
En aquesta situació, els defectes afectaran el negoci.
Major
….
…. (Explica-ho amb un exemple al pla de prova)
Menor
…..
..... (Explica-ho amb un exemple al pla de prova)
Aquests defectes són aquells que afecten l'aspecte i la sensació de l'aplicació.Prioritat
Alt-P1
…..
Mitjà-P2
…..
Baix-P3
…..
…..
P4

Per tant, en funció de la prioritat d'errors com alt, mitjà i baix, el classificarem com a P1, P2, P3 i P4.

Entorns de prova

Aquests són els entorns on provarem l'aplicació, i aquí tenim dos tipus d'entorns, que són de programari i maquinari configuració.

El configuració del programari significa els detalls sobre diferents Sistemes operatius tal com Windows, Linux, UNIX i Mac i diversos Navegadors M'agrada Google Chrome, Firefox, Opera, Internet Explorer , etcètera.

I la configuració de maquinari significa la informació sobre diferents mides de RAM, ROM i processadors .

Per exemple

• El Programari inclou el següent:

Servidor

Nota: els servidors anteriors són els serveis que l'equip de proves utilitza per provar l'aplicació.

Client

Nota: els detalls anteriors proporcionen els diferents sistemes operatius i navegadors en què l'equip de proves provarà l'aplicació.

• El Maquinari inclou el següent:

Servidor : Sun StarCat 1500

Aquest servidor en particular pot ser utilitzat per l'equip de proves per provar la seva aplicació.

Client:

Té la configuració següent, que és la següent:

Nota: proporcionarà la configuració dels sistemes dels enginyers de proves que són l'equip de proves.

Procés per instal·lar el programari
……
…..
…..

L'equip de desenvolupament proporcionarà la configuració de com instal·lar el programari. Si l'equip de desenvolupament encara no proporciona el procés, l'escriurem com a Desenvolupament basat en tasques (TBD) al pla de prova.

Criteris d'entrada i sortida

És una condició necessària, que s'ha de complir abans d'iniciar i aturar el procés de prova.

Criteris d'entrada

Els criteris d'entrada inclouen les condicions següents:

• Les proves de caixa blanca s'han d'acabar.
• Comprendre i analitzar el requisit i preparar els documents de prova o quan els documents de prova estiguin preparats.
• Les dades de la prova haurien d'estar a punt.
• La compilació o l'aplicació s'ha de preparar
• Els mòduls o característiques s'han d'assignar als diferents enginyers de prova.
• El recurs necessari ha d'estar preparat.

Criteris de sortida

Els criteris de sortida inclouen les condicions següents:

nombre sencer doble java

• Quan s'executen tots els casos de prova.
• La majoria dels casos de prova ho han de ser passat .
• Depèn de la gravetat dels errors, la qual cosa significa que no hi ha d'haver cap bloquejador o error important, mentre que existeixen alguns errors menors.

Abans de començar a realitzar proves funcionals, tot l'anterior Criteris d'entrada s'ha de seguir. Després de realitzar proves funcionals i abans de fer proves d'integració, llavors el Criteris de sortida de les proves funcionals s'han de seguir perquè el percentatge de criteris de sortida els decideix la reunió tant amb el responsable de desenvolupament com amb el responsable de proves perquè la seva col·laboració pot aconseguir el percentatge. Però si no es segueixen els criteris de sortida de les proves funcionals, no podem continuar amb les proves d'integració.

Aquí en funció de la gravetat de l'error significa que l'equip de proves ho hauria decidit per continuar més endavant per a les següents fases.

Automatització de proves

En això, decidirem el següent:

• Quina funció s'ha d'automatitzar i no?
• Quina eina d'automatització de proves utilitzarem en quin marc d'automatització?

Automatitzem el cas de prova només després del primer llançament.

Aquí sorgeix la pregunta sobre quina base nosaltres voluntat decidir quines característiques s'han de provar?

A la imatge de dalt, com podem veure que les funcions més utilitzades s'han de provar una i altra vegada. Suposem que hem de comprovar l'aplicació de Gmail on es troben les funcions essencials Redacta el correu, els elements enviats i la safata d'entrada . Per tant, provarem aquestes característiques perquè mentre es realitza una prova manual, es necessita més temps i també es converteix en una feina monòtona.

Ara, com decidim quines funcions no es provaran?

Suposem l'ajuda La funció de l'aplicació Gmail no es prova una vegada i una altra perquè aquestes funcions no s'utilitzen regularment, de manera que no cal que la revisem amb freqüència.

Però si algunes funcions són inestables i tenen molts errors , el que significa que no provarem aquestes funcions perquè s'han de provar una i altra vegada mentre fem proves manuals.

Si hi ha una característica que s'ha de provar amb freqüència , però esperem el canvi de requisits per a aquesta funció, de manera que no ho comprovem perquè canviar els casos de prova manuals és més còmode en comparació amb el canvi a l'script de prova d'automatització.

Estimació de l'esforç

En això, planificarem l'esforç que ha d'aplicar cada membre de l'equip.

Prova lliurable

Aquests són els documents que són la sortida de l'equip de proves, que vam lliurar al client juntament amb el producte. Inclou el següent:

Pla de prova Casos de prova Scripts de prova RTM (Matriu de traçabilitat de requisits) Informe de defecte Informe d'execució de la prova Gràfics i mètriques Notes de la versió

Gràfics i mètriques

Gràfic

En això, parlarem sobre els tipus de gràfics enviarem, i també proporcionarem una mostra de cada gràfic.

Com podem veure, disposem de cinc gràfics diferents que mostren els diferents aspectes del procés de prova.

Gràfic 1: En això, mostrarem quants defectes s'han identificat i quants defectes s'han corregit en cada mòdul.

Gràfic 2: La figura 1 mostra quants defectes crítics, majors i menors s'han identificat per a cada mòdul i quants s'han corregit per als seus mòduls respectius.

Gràfic 3: En aquest gràfic en concret, representem el construir un gràfic intel·ligent , el que significa que en cada compilació quants defectes s'han identificat i corregit per a cada mòdul. A partir del mòdul, hem determinat els errors. Hi afegirem R per mostrar el nombre de defectes en P i Q, i també sumem S per mostrar els defectes en P, Q i R.

Gràfic 4: El plom de prova dissenyarà el Anàlisi de tendències d'errors gràfic que es crea cada mes i enviar-lo també a la Direcció. I és com una predicció que es fa al final del producte. I aquí, també podem valorar les correccions d'errors com ho podem observar arc té un tendència a l'alça a la imatge de sota.

Gràfic 5: El Gestor de proves ha dissenyat aquest tipus de gràfics. Aquest gràfic pretén comprendre el buit en l'avaluació dels errors i els errors reals que s'han produït, i aquest gràfic també ajuda a millorar l'avaluació d'errors en el futur.

Mètriques

Com anteriorment, creem el gràfic de distribució d'errors, que es troba a la figura 1, i amb l'ajuda de les dades esmentades anteriorment, també dissenyarem les mètriques.

Per exemple

A la figura anterior, conservem els registres de tots els enginyers de proves d'un projecte concret i quants defectes s'han identificat i corregit. També podem utilitzar aquestes dades per a anàlisis futures. Quan arriba un nou requisit, podem decidir a qui proporcionar la funció desafiant per a la prova en funció del nombre de defectes que han trobat anteriorment d'acord amb les mètriques anteriors. I estarem en una millor situació per saber qui pot gestionar molt bé les característiques problemàtiques i trobar el màxim nombre de defectes.

Nota de llançament: És un document que es prepara durant el llançament del producte i que està signat pel Test Manager.

A la imatge següent, podem veure que el producte final està desenvolupat i desplegat al client, i el nom de la versió més recent és Beta .

El Nota de llançament consta del següent:

• Manual d'usuari.
• Llistat de defectes pendents i oberts.
• Llista de funcions afegides, modificades i suprimides.
• Llista de la plataforma (Sistema Operatiu, Maquinari, Navegadors) en què es prova el producte.
• Plataforma en la qual no es prova el producte.
• Llista d'errors corregits a la versió actual i la llista d'errors corregits a la versió anterior.
• Procés d'instal·lació
• Versions del programari

Per exemple

Suposem que Beta és la segona versió de l'aplicació després de la primera Alfa s'allibera. Alguns dels defectes identificats en el primer llançat i que s'han corregit en el llançat posterior. I aquí, també assenyalarem la llista de funcions recentment afegides, modificades i suprimides des de la versió alfa fins a la versió beta.

Plantilla

Aquesta part conté totes les plantilles dels documents que s'utilitzaran al producte, i tots els enginyers de proves utilitzaran només aquestes plantilles al projecte per mantenir la coherència del producte. Aquí, tenim diferents tipus de plantilla que s'utilitzen durant tot el procés de prova, com ara:

• Plantilla de cas de prova
• Plantilla de revisió de casos de prova
• Plantilla RTM
• Plantilla d'informe d'errors
• Informe d'execució de la prova

Vegem una mostra del document del pla de prova

Pàgina 1

Pàgina3-pàgina18

Pàgina-20

A la pàgina 1, principalment omplim només el Versions, autor, comentaris i ressenyats per camps, i després que el gestor ho aprovi, n'esmentarem els detalls al Data d'aprovació i data d'aprovació camps.

Majoritàriament, el pla de proves està aprovat pel Gestor de proves i els enginyers de proves només el revisen. I quan arribin les noves característiques, modificarem el pla de proves i farem la modificació necessària Versió camp i, a continuació, s'enviarà de nou per a una posterior revisió, actualització i aprovació del gestor. El pla de proves s'ha d'actualitzar sempre que hi hagi canvis. A la pàgina 20, el Referències especifiqueu els detalls de tots els documents que farem servir per redactar el document del pla de proves.

Nota:

Qui escriu el pla de prova?

• Prova de plom → 60%
• Gestor de proves→20%
• Enginyer de proves → 20%

Per tant, com podem veure des de dalt, en el 60% del producte, el pla de prova està redactat pel Test Lead.

Qui revisa el pla de proves?

• Cap de prova
• Gestor de proves
• Enginyer de proves
• Client
• Equip de desenvolupament

L'enginyer de proves revisa el pla de proves per la seva perspectiva de mòdul i el responsable de proves revisa el pla de proves en funció de l'opinió del client.

Qui aprova el Pla de proves?

• Client
• Gestor de proves

Qui escriu el cas de prova?

• Cap de prova
• Enginyer de proves

Qui revisa el cas de prova?

estampat d'estrelles

• Enginyer de proves
• Cap de prova
• Client
• Equip de desenvolupament

Qui aprova els casos de prova?

• Gestor de proves
• Cap de prova
• Client

Directrius del pla de proves

• Reduïu el vostre pla de proves.
• Eviteu la superposició i la redundància.
• Si creieu que no necessiteu una secció que ja s'ha esmentat anteriorment, elimineu-la i continueu endavant.
• Sigues específic. Per exemple, quan especifiqueu un sistema de programari com a part de l'entorn de prova, esmenteu la versió del programari en lloc de només el nom.
• Eviteu els paràgrafs llargs.
• Utilitzeu llistes i taules sempre que sigui possible.
• Actualitzar el pla quan sigui necessari.
• No utilitzeu un document obsolet i no utilitzat.

Importància del pla de proves

• El pla de proves dóna direcció al nostre pensament. Això és com un llibre de regles, que cal seguir.
• El pla de prova ajuda a determinar els esforços necessaris per validar la qualitat de l'aplicació de programari sota la prova.
• El pla de proves ajuda a aquestes persones a entendre els detalls de la prova que estan relacionats amb l'exterior, com ara desenvolupadors, gestors empresarials, clients, etc.
• Aspectes importants com el calendari de proves, l'estratègia de proves, l'abast de la prova, etc. es documenten al pla de proves perquè l'equip directiu pugui revisar-los i reutilitzar-los per a altres projectes similars.