Diferència entre pla de prova, estratègia de prova, cas de prova, script de prova, escenari de prova i condició de prova

difference between test plan

Apreneu quina diferència hi ha entre el pla de prova, l'estratègia de prova, el cas de prova, el guió de prova, l'escenari de prova i l'estat de la prova amb exemples:

Les proves de programari inclouen diversos conceptes bàsics i importants que tots els provadors de programari haurien de tenir en compte.

En aquest article s’explicaran els diversos conceptes de les proves de programari juntament amb la seva comparació.

Pla de prova vs Estratègia de prova, Cas de prova vs Script de prova, Escenari de prova vs Estat de la prova i Procediment de prova vs Test Suite s’expliquen detalladament per facilitar la vostra comprensió.

=> Feu clic aquí per obtenir una sèrie completa de programes de proves

diferència entre pla de prova i cas de prova

La pregunta anterior feta per Sasi C. és la pregunta més freqüent de la nostra Classe de proves de programari i sempre dic als nostres participants que amb l'experiència gairebé no notem aquestes paraules i que es converteixen en una part del nostre vocabulari.

Però sovint la confusió els envolta i, en aquest article, intento definir pocs termes d’ús comú.

Diversos conceptes de proves de programari

A continuació es detallen els diversos conceptes de proves de programari juntament amb la seva comparació.

Comencem!!

Què aprendreu:

• Diferència entre pla de prova i estratègia de prova
  • Pla de proves
  • Document del pla de proves
    • Tipus de pla de proves
  • Prova d’Estratègia
  • Document d'estratègia de prova
    • # 1) Visió general del projecte
    • # 2) Abast dels requisits
    • # 3) Pla de proves d'alt nivell
    • # 4) Enfocament de la prova
    • # 5) Cobertura de la prova
    • # 6) Entorn de prova
    • # 7) Entregables i mètriques de control de qualitat
    • # 8) Gestió de defectes
    • # 9) Gestió de la comunicació
    • # 10) Supòsits, riscos i dependències
    • # 11) Apèndix
  • Prova del pla contra l'estratègia de prova
• Diferència entre cas de prova i guió de prova
• Diferència entre l'escenari de prova i l'estat de la prova
• Diferència entre el procediment de prova i el conjunt de proves
• Conclusió
  • Lectura recomanada

Diferència entre pla de prova i estratègia de prova

L'estratègia i el pla de proves són dos documents importants en el cicle de vida de les proves de qualsevol projecte. Aquí intentem oferir-vos un coneixement profund de l'estratègia de prova i els documents del pla de proves.

Pla de proves

Un pla de prova es pot definir com un document que defineix l'abast, l'objectiu i l'enfocament per provar l'aplicació de programari. El pla de proves és un terme i un lliurament.

El pla de proves és un document que llista totes les activitats d’un projecte de control de qualitat, les programa, defineix l’abast del projecte, les funcions i responsabilitats, els riscos, els criteris d’entrada i sortida, l’objectiu de la prova i qualsevol altra cosa que se us pugui imaginar.

El pla de proves és com m’agrada anomenar un 'súper document' que enumera tot el que cal saber i necessitar. Si us plau consulteu aquest enllaç per obtenir més informació i una mostra.

El pla de proves es dissenyarà en funció dels requisits. Mentre assigna feina als enginyers de proves, per alguns motius, un dels provadors és substituït per un altre. Aquí s’actualitza el pla de proves.

L'estratègia de prova descriu l'enfocament de la prova i tota la resta que l'envolta. És diferent del pla de prova, en el sentit que una estratègia de prova només és un subconjunt del pla de prova. És un document de prova molt dur que és fins a un punt genèric i estàtic. També hi ha un argument sobre quins nivells s’utilitza l’estratègia o pla de prova, però realment no veig cap diferència discernidora.

Exemple: El pla de proves proporciona informació sobre qui farà la prova en quin moment. Per exemple, El mòdul 1 serà provat per 'X tester'. Si el comprovador Y substitueix X per algun motiu, s’ha d’actualitzar el pla de prova.

Document del pla de proves

Test Plan és un document que proporciona informació completa sobre tasques de prova relacionades amb un projecte de programari. Proporciona detalls com l'abast de les proves, els tipus de proves, els objectius, la metodologia de prova, l'esforç de prova, els riscos i les contingències, els criteris de publicació, els lliuraments de proves, etc. Realitza un seguiment de les possibles proves que s'executaran al sistema després de codificar-les.

Evidentment, el pla de proves està canviat. Inicialment, es desenvoluparà un esborrany de pla de proves basat en la claredat del projecte en aquell moment. Aquest pla inicial es modificarà a mesura que avanci el projecte. El gerent de l’equip de prova o el cap de prova pot preparar el document del pla de proves. Descriu les especificacions i està subjecte a canvis en funció de les mateixes.

Què provar, quan provar, qui provarà i com provar es definirà al pla de prova. Test Plan ordenarà una llista de problemes, dependències i riscos subjacents.

Tipus de pla de proves

Els plans de prova poden ser de diferents tipus segons la fase de prova. Inicialment, hi haurà un pla mestre de proves per a l’execució completa del projecte. Es poden crear plans de prova separats per a tipus de proves específics, com ara proves de sistema, proves d’integració de sistemes, proves d’acceptació d’usuaris, etc.

Un altre enfocament és tenir plans de proves separats per a proves funcionals i no funcionals. En aquest rendiment, les proves tindran un pla de proves diferent.

Contingut del document del pla de proves ( Estructura del pla de proves IEEE-829 )

És difícil dibuixar un format clar per al pla de proves. El format del pla de prova pot variar en funció del projecte en qüestió. IEEE ha definit un estàndard per als plans de prova que es descriuen com l'estructura del pla de prova IEEE-829.

A continuació, trobareu recomanacions IEEE per a un contingut de pla de prova estàndard:

1. Identificador de pla de prova
2. Introducció
3. Elements de prova
4. Problemes de risc de programari
5. Funcions a provar
6. Funcions que no s’han de provar
7. Aproximació
8. Criteris d'aprovació / suspensió de l'element (o) Criteris d'acceptació
9. Criteris de suspensió i requisits de represa
10. Prova de lliuraments
11. Tasques de prova
12. Requisits ambientals
13. Necessitats de personal i formació
14. Responsabilitats
15. Horari
16. Aprovacions

Lectura suggerida => Tutorial del pla de proves: una guia perfecta

Prova d’Estratègia

Test Strategy és un conjunt de pautes que expliquen el disseny de la prova i determinen com s’ha de fer la prova.

Exemple: Una estratègia de prova inclou detalls com 'Els membres de l'equip de prova han de provar mòduls individuals'. En aquest cas, qui ho prova no té importància; per tant, és genèric i el canvi del membre de l’equip no s’ha d’actualitzar, mantenint-lo estàtic.

Document d'estratègia de prova

L’objectiu de l’estratègia de prova és definir l’enfocament de les proves, els tipus de proves, els entorns de prova i les eines que s’utilitzaran per provar i els detalls d’alt nivell sobre com s’alinearà l’estratègia de prova amb altres processos. Es pretén que el document d’estratègia de prova sigui un document actiu i s’actualitzarà ** quan obtinguem més claredat sobre els requisits, els paràmetres SLA, l’entorn de prova i l’enfocament de gestió de compilació, etc.

L’estratègia de prova està pensada per a l’equip complet del projecte que comprèn patrocinadors de projectes, pimes empresarials, desenvolupament d’aplicacions / integració, socis d’integració de sistemes, equips de conversió de dades, equips de gestió de compilacions / llançaments, com ara responsables tècnics, responsables d’arquitectura i equips de desplegament i infraestructura.

** Alguns argumenten que l'estratègia de prova un cop definida no s'hauria d'actualitzar mai. En la majoria de projectes de proves, normalment s’actualitza a mesura que avança el projecte.

A continuació es mostren les seccions importants que hauria de tenir un document d’estratègia de prova:

# 1) Visió general del projecte

Aquesta secció pot començar donant una visió general de l’organització seguida d’una breu descripció del projecte en curs. Pot incloure detalls a continuació

• Quina necessitat tenia el projecte?
• Quins objectius assolirà el projecte?

Taula d’acrònims: És millor incloure una taula amb acrònims que pugui arribar al lector de documents mentre es refereix al document.

# 2) Abast dels requisits

L'abast del requisit pot incloure l'abast de l'aplicació i l'abast funcional

Àmbit d'aplicació defineix el sistema que s’està provant i l’impacte sobre el sistema a causa de la funcionalitat nova o modificada. També es poden definir sistemes relacionats.

Abast funcional defineix l’impacte en diferents mòduls del sistema. Aquí s'explicarà cada sistema relacionat amb la funcionalitat.

# 3) Pla de proves d'alt nivell

Test Plan és un document independent. A l'estratègia de prova, es pot incloure un pla de proves d'alt nivell. Un pla de proves d’alt nivell pot incloure objectius i abast de la prova. L'abast de la prova hauria de definir tant les activitats d'abast com fora de l'abast.

# 4) Enfocament de la prova

En aquesta secció es descriu l'enfocament de les proves que es seguiran durant el cicle de vida de les proves.

c ++ char * a int

Segons el diagrama anterior, les proves es realitzaran en dues fases, és a dir, Estratègia i planificació de proves i Execució de proves. La fase d’estratègia i planificació de les proves serà única per a un programa global, mentre que les fases d’execució de les proves es repetiran per a cada cicle del programa general. El diagrama anterior mostra diferents etapes i lliuraments (resultat) en cada fase de l'enfocament d'execució.

L'enfocament de la prova hauria d'incloure a continuació sub-seccions

a) Calendari de proves: Expliqueu la cronologia del projecte proposada en aquesta subsecció

b) Enfocament de les proves funcionals: L’ús d’aquesta subsecció proporciona una visió general de cada fase i dels respectius criteris d’entrada i sortida. Les diferents fases de proves són les proves d’unitat, les proves del sistema, les proves d’integració del sistema, les proves d’acceptació d’usuaris i les proves d’extrem a extrem.

c) Prova d’indicadors clau de rendiment:

• Priorització de casos de prova: Definiu l'enfocament de priorització de casos de prova de manera que en cas de restriccions de temps, l'equip de prova pugui executar escenaris d'alta prioritat. Hi hauria d’haver un acord entre els grups d'interès del projecte sobre els possibles riscos que comporta no executar tots els escenaris previstos.
• Priorització de defectes: L’estratègia de priorització de defectes és el següent tema a tractar aquí. Definiu el nivell de prioritat i doneu la descripció a cada nivell, com ara crític, alt, mitjà, etc.
• Temps de resposta dels defectes: El temps de resposta dels defectes es defineix com el temps transcorregut entre el moment en què el defecte es va elevar per primera vegada i quan el defecte es va solucionar i es presenta per tornar a provar-lo. La resposta ràpida garanteix proves ràpides i adherència a la cronologia del projecte. Per a cada nivell de prioritat de defecte, definiu el temps de resposta.

# 5) Cobertura de la prova

En aquesta secció es descriuen els processos que seguirà l'equip de control de qualitat per tal d'optimitzar la cobertura dels requisits empresarials / funcionals en els escenaris i casos de prova. Matriu de traçabilitat del requisit: (RTM) es pot utilitzar per rastrejar tots els requisits amb els respectius escenaris de prova i casos de prova.

# 6) Entorn de prova

Definiu els diferents entorns de control de qualitat disponibles. Esmenta quines proves es faran en quin entorn i per qui. Creeu un pla de còpia de seguretat de l’entorn per atendre les emergències. L’accés a cada entorn s’ha de regular i convocar amb claredat.

Les eines de prova que s’utilitzaran també es poden esmentar en aquesta secció.

# 7) Entregables i mètriques de control de qualitat

Enumereu tots els lliuraments de control de qualitat

Enumereu totes les mètriques de control de qualitat

# 8) Gestió de defectes

Definiu clarament una estratègia de gestió de defectes creant un flux de treball de defectes, una metodologia de seguiment de defectes i un procés de triatge de defectes. Esmenta la responsabilitat dels defectes per a les funcions de cada provador. L’anàlisi periòdica de defectes i l’anàlisi de la causa arrel milloraran la qualitat general de les proves

# 9) Gestió de la comunicació

Definiu directrius per als informes d’estat, les reunions d’estat i la comunicació in situ-offshore.

# 10) Supòsits, riscos i dependències

Descriviu els supòsits en què es basa el projecte. Aquests poden incloure el temps, els recursos i les capacitats del sistema. Descriviu les dependències com ara altres projectes, la disponibilitat de recursos temporals i altres terminis que poden afectar el projecte

# 11) Apèndix

Incloeu elements com ara Funcions i responsabilitats, Zona horària de treball i Referències en aquesta secció

Per llegir més=> Guia per escriure un document de bona estratègia de prova .

Prova del pla contra l'estratègia de prova

La diferència entre aquests dos documents és subtil. Una estratègia de prova és un document estàtic d’alt nivell sobre el projecte. D'altra banda, el pla de prova especifica què cal provar, quan provar i com provar.

Diferència entre cas de prova i guió de prova

Al meu entendre, aquests dos termes es poden utilitzar indistintament. Sí, dic que no hi ha diferència. El cas de prova és una seqüència de passos que ens ajuden a realitzar una determinada prova a l'aplicació. El guió de prova també és el mateix.

Ara, hi ha un pensament que un cas de prova és un terme que s’utilitza a l’entorn de proves manuals i que el script de prova s’utilitza en un entorn d’automatització. Això és en part cert, a causa del nivell de confort dels verificadors en els camps respectius i també de com les eines fan referència a les proves (alguns criden scripts de prova i alguns els criden per provar casos).

En efecte, ambdós, el guió de prova i el cas de prova són passos a realitzar en una aplicació per validar la seva funcionalitat, ja sigui manualment o mitjançant automatització.

Per llegir més=> Com escriure casos de proves efectius? i Plantilla d'exemple de cas de prova .

Diferència entre l'escenari de prova i l'estat de la prova

Escenari de prova: És una manera de definir totes les maneres possibles de provar una aplicació. És una declaració única que cobreix totes les maneres possibles de provar una aplicació.

Estat de la prova: La condició de prova és l’especificació que un verificador ha de seguir per provar una aplicació.

Es tracta d'un punter d'una línia que els provadors creen com a pas inicial i de transició a la fase de disseny de la prova. Aquesta és principalment una definició d'una línia de 'Què' anem a provar respecte a una determinada característica. Normalment, els escenaris de prova s’introdueixen per a la creació de casos de prova.

En els projectes àgils, els escenaris de prova són els únics resultats de disseny de proves i no s’escriuen casos de prova després d’aquests. Un escenari de prova pot provocar diverses proves.

Exemples d'escenaris de prova:

què és el control de qualitat i la garantia de qualitat

• Valideu si l'administrador pot afegir un país nou
• Valideu si l'administrador pot suprimir un país existent
• Valideu si es pot actualitzar un país existent

Les condicions de les proves, en canvi, són més específiques. Es pot definir aproximadament com l'objectiu / objectiu d'una determinada prova.

Exemple de condició de prova: A l'exemple anterior, si provéssim l'escenari 1, podem provar les condicions següents:

• Introduïu el nom del país com a 'Índia' (vàlid) i comproveu si s'afegeix el país
• Introduïu un espai en blanc i comproveu si s'afegeix el país.
• En cada cas, es descriuen les dades específiques i l'objectiu de la prova és molt més precís.

Per llegir més=> Més de 180 exemples d'escenaris de prova per provar aplicacions web i d'escriptori.

Diferència entre el procediment de prova i el conjunt de proves

El procediment de prova és una combinació de casos de prova basats en una determinada raó lògica, com ara executar una situació de extrem a extrem o alguna cosa en aquest sentit. L'ordre en què s'han d'executar els casos de prova està fixat.

Procediment de prova: No és res més que el cicle de vida de la prova. Hi ha deu passos al cicle de vida de proves.

Ells són:

1. Estimació de l’esforç
2. Iniciació del projecte
3. Estudi del sistema
4. Pla de proves
5. Cas de prova de disseny
6. Automatització de proves
7. Executeu casos de prova
8. Notificar defectes
9. Proves de regressió
10. Anàlisi i informe resum

Per exemple , si provés l'enviament d'un correu electrònic des de Gmail.com, l'ordre dels casos de prova que combinaria per formar un procediment de prova seria:

1. La prova per comprovar l’inici de sessió
2. La prova per redactar un correu electrònic
3. La prova per adjuntar un o més fitxers adjunts
4. Formatant el correu electrònic de la manera requerida mitjançant diverses opcions
5. Afegir contactes o adreces de correu electrònic als camps Per a, BCC, CC
6. Enviar un correu electrònic i assegurar-se que es mostri a la secció 'Correu enviat'

Tots els casos de prova anteriors s’agrupen per assolir un objectiu determinat al final. A més, els procediments de prova tenen alguns casos de prova combinats en qualsevol moment.

El conjunt de proves, d'altra banda, és la llista de tots els casos de prova que s'han d'executar com a part d'un cicle de prova o d'una fase de regressió, etc. No hi ha cap agrupació lògica basada en la funcionalitat. L'ordre en què s'executen els casos de prova constitutius pot ser important o no.

Suite de proves: Test Suite és un contenidor que inclou un conjunt de proves que ajuden els verificadors a executar i informar de l'estat d'execució de la prova. Pot prendre qualsevol dels tres estats, és a dir, Actiu, en curs i completat.

Exemple del Test Suite : Si la versió actual d’una aplicació és 2.0. És possible que la versió 1.0 anterior tingués 1000 casos de prova per provar-la completament. Per a la versió 2 hi ha 500 casos de prova per provar la nova funcionalitat que s’afegeix a la nova versió.

Per tant, el conjunt de proves actual seria de 1000 + 500 casos de prova que inclouen tant la regressió com la nova funcionalitat. La suite també és una combinació, però no intentem assolir una funció objectiu.

Les suites de proves poden contenir 100 o fins i tot 1000 casos de proves.

Conclusió

Els conceptes de proves de programari tenen un paper important en el cicle de vida de les proves de programari.

Una comprensió clara dels conceptes comentats anteriorment, juntament amb la seva comparació, és molt important per a tots els programes de proves de programari per dur a terme el procés de prova amb eficàcia.

Normalment, articles com aquests són excel·lents punts de partida per a discussions més profundes. Per tant, aporteu els vostres pensaments, acords, desacords i qualsevol altra cosa en els comentaris següents. Esperem els vostres comentaris.

També donem la benvinguda a les vostres preguntes sobre proves de programari en general o qualsevol cosa relacionada amb la vostra carrera professional. Els tractarem amb més detall a les nostres properes publicacions de la mateixa sèrie.

Bona lectura !!

=> Visiteu aquí per obtenir la sèrie completa de programes de proves

PREV Tutorial | NEXT Tutorial

Lectura recomanada

• Tutorial de pla de prova: una guia per escriure un document de pla de prova de programari des de zero
• Com escriure un document d'estratègia de prova (amb una plantilla d'estratègia de prova de mostra)
• Com preparar-se per escriure casos de proves (Consells sobre productivitat)
• Què és l'escenari de prova: plantilla d'escenari de prova amb exemples
• Diferència entre el pla de prova de rendiment i l'estratègia de prova de rendiment
• Com escriure casos de prova: la guia definitiva amb exemples
• Exemple de plantilla de pla de prova de programari amb format i contingut
• Test Scenario Vs Case Test: Quina diferència hi ha entre aquests?