what is regression testing
Què és la prova de regressió?
La prova de regressió és un tipus de prova que es fa per verificar que un canvi de codi al programari no afecta la funcionalitat existent del producte. Això és per assegurar-se que el producte funcioni bé amb noves funcionalitats, solucions d'errors o qualsevol canvi en la funció existent. Els casos de prova executats prèviament es tornen a executar per verificar l'impacte del canvi.
=> Feu clic aquí per obtenir una sèrie completa de programes de proves
La prova de regressió és un tipus de prova de programari en què els casos de prova es tornen a executar per comprovar si la funcionalitat anterior de l'aplicació funciona bé i els nous canvis no han introduït cap error nou.
Aquesta prova es pot realitzar en una nova versió quan hi ha un canvi significatiu en la funcionalitat original, fins i tot en una sola correcció d'errors.
La regressió significa tornar a provar les parts de l'aplicació sense canvis.
Què aprendreu:
- Tutorials coberts en aquesta sèrie
- Visió general de la prova de regressió
- Quan es realitza aquesta prova?
- Es poden realitzar proves de regressió manualment?
- Eines de proves de regressió automatitzades
- Per què la prova de regressió?
- Tipus de proves de regressió
- Quina regressió es requereix?
- Què fem en comprovació de regressió?
- Tècniques de proves de regressió
- Com es pot seleccionar una suite de proves de regressió?
- Com es realitzen proves de regressió?
- Regressió Agile
- Avantatges
- Desavantatges
- Regressió de l'aplicació GUI
- Diferència entre la regressió i la revisió
- Regression Test Pla Template (TOC)
- Conclusió
- Lectura recomanada
Tutorials coberts en aquesta sèrie
Tutorial # 1: Què és la prova de regressió (Aquest tutorial)
Tutorial # 2: Eines de prova de regressió
Tutorial # 3: Torneu a provar la prova de regressió
Tutorial # 4: Proves de regressió automàtiques en Agile
Visió general de la prova de regressió
La prova de regressió és com un mètode de verificació. Els casos de prova generalment s’automatitzen, ja que cal que els casos de prova s’executin una i altra vegada i executar els mateixos casos de prova una i altra vegada manualment també requereix molt de temps i és tediós.
Per exemple, Penseu en un producte X, en què una de les funcions és activar correus electrònics de confirmació, acceptació i enviament quan es fa clic als botons Confirma, Accepta i Envia.
Es produeix algun problema al correu electrònic de confirmació i, per solucionar-ho, es fan alguns canvis de codi. En aquest cas, no només cal provar els correus electrònics de confirmació, sinó que també s’han de comprovar els correus electrònics d’acceptació i d’enviament per garantir que el canvi de codi no els hagi afectat.
Les proves de regressió no depenen de cap llenguatge de programació com Java, C ++, C #, etc. És un mètode de prova que s’utilitza per provar les modificacions o actualitzacions del producte. Verifica que qualsevol modificació en un producte no afecti els mòduls existents del producte.
Verificar que els errors s'han corregit i que les funcions afegides recentment no han creat cap problema a la versió anterior de treball del programari.
Els verificadors realitzen proves funcionals quan hi ha disponible una nova versió per verificar-la. La intenció d'aquesta prova és verificar també els canvis realitzats a la funcionalitat existent i a la nova funcionalitat.
Quan es faci aquesta prova, el comprovador hauria de verificar si la funcionalitat existent funciona com s'esperava i si els nous canvis no han introduït cap defecte en la funcionalitat que funcionava abans d'aquest canvi.
La prova de regressió ha de formar part del cicle de llançament i s’ha de tenir en compte en l’estimació de la prova.
Quan es realitza aquesta prova?
Les proves de regressió es realitzen generalment després de verificar els canvis o la nova funcionalitat. Però no sempre és així. Per a la versió que triga mesos a completar-se, les proves de regressió s’han d’incorporar al cicle de proves diàries. Per a les versions setmanals, es poden realitzar proves de regressió quan finalitzin les proves funcionals dels canvis.
La comprovació de regressió és una variació de la nova prova (que és simplement repetir una prova). Quan es torna a provar, el motiu pot ser qualsevol cosa. Per exemple, provàveu una característica concreta i era el final del dia; no podíeu acabar la prova i havíeu d’aturar el procés sense decidir si la prova va passar o no.
L’endemà, quan torneu, torneu a fer la prova; això vol dir que repetiu una prova que heu fet abans. El simple fet de repetir una prova és una prova nova.
La prova de regressió en el seu nucli és una mena de prova. Només per a l'ocasió especial ha canviat alguna cosa de l'aplicació / codi. Pot ser un codi, un disseny o qualsevol cosa que dicti el marc general del sistema.
Una prova nova que es realitza en aquesta situació per assegurar-se que l'esmentat canvi no ha tingut cap impacte en res que ja funcionava abans s'anomena Prova de regressió. Les raons més habituals per les quals es pot dur a terme són perquè s’han creat noves versions del codi (augment de l’abast / requisit) o s’han corregit els errors.
Es poden realitzar proves de regressió manualment?
Acabo d'ensenyar un d'aquests dies a la meva classe i em va venir la pregunta: 'Es pot fer la regressió manualment?'
Vaig contestar la pregunta i vam continuar a la classe. Tot semblava correcte, però d'alguna manera aquesta pregunta em va molestar durant força temps després.
Al llarg dels nombrosos lots, aquesta pregunta es repeteix diverses vegades de maneres diferents. Alguns d’ells són:
- Per realitzar l'execució de la prova, necessitem una eina?
- Com es realitzen les proves de regressió?
- Fins i tot després de tota una ronda de proves, als nouvinguts els costa discernir què és exactament la prova de regressió?
I, per descomptat, la pregunta original:
- Es pot realitzar aquesta prova manualment?
Començar amb, Execució de la prova és un acte senzill d’utilitzar els casos de prova i realitzar aquests passos a l’AUT, subministrar les dades de la prova i comparar el resultat obtingut a l’AUT amb el resultat esperat esmentat als casos de prova.
En funció del resultat de la comparació, establim l’estat del cas de prova aprovat / suspès. L’execució de les proves és tan senzilla, no hi ha eines especials necessàries per a aquest procés.
Eines de proves de regressió automatitzades
La prova de regressió automatitzada és l'àrea de proves on podem automatitzar la majoria dels esforços de prova. Executem tots els casos de prova executats anteriorment en una nova versió.
Això vol dir que tenim un conjunt de casos de prova disponible i que executar manualment aquests casos de prova requereix molt de temps. Coneixem els resultats esperats, de manera que automatitzar aquests casos de prova suposa un estalvi de temps i és un mètode de prova de regressió eficient. L'abast de l'automatització depèn del nombre de casos de prova que continuaran sent aplicables hores extres.
Si els casos de prova varien de tant en tant, l’abast de l’aplicació augmenta i l’automatització del procediment de regressió serà la pèrdua de temps.
La majoria de les eines de prova de regressió són de tipus de gravació i reproducció. Podeu enregistrar els casos de prova navegant per l’automàtica (aplicació en prova) i verificar si els resultats esperats arribaran o no.
Eines
- Seleni
- Catalog Studio
- AdventNet QEngine
- Provador de regressió
- vTest
- aigua
- actiWate
- Provador funcional racional
- SilkTest
- TimeShiftX
La majoria d’aquestes són eines de proves funcionals i de regressió.
Lectura recomanada => Consulteu aquí la llista de les principals eines de regressió
Afegir i actualitzar casos de proves de regressió en un conjunt de proves d’automatització és una tasca feixuga. Mentre seleccioneu una eina d'automatització per a proves de regressió, heu de comprovar si l'eina us permet afegir o actualitzar els casos de prova fàcilment.
retornar una matriu d'un mètode a Java
En la majoria dels casos, hem d’actualitzar els casos de proves de regressió automàtiques amb freqüència a causa de canvis freqüents al sistema.
MIRA EL VÍDEO
Per obtenir una explicació més detallada de la definició amb un exemple, consulteu el següentVídeo de prova de regressió:
Per què la prova de regressió?
La regressió s'inicia quan un programador corregeix qualsevol error o afegeix un nou codi per a una nova funcionalitat al sistema.
Hi pot haver moltes dependències a la nova funcionalitat afegida i existent.
És una mesura de qualitat per comprovar si el nou codi compleix amb el codi antic de manera que el codi no modificat no es vegi afectat. La majoria de les vegades l’equip de proves té la tasca de comprovar els canvis d’última hora del sistema.
En aquesta situació, només cal provar l'àrea d'aplicació afectada per completar el procés de prova a temps, cobrint tots els aspectes principals del sistema.
Aquesta prova és molt important quan s’afegeix un canvi / millora contínua a l’aplicació. La nova funcionalitat no hauria d’afectar negativament el codi de prova existent.
Es requereix una regressió per trobar els errors que s'han produït a causa d'un canvi en el codi. Si no es fa aquesta prova, és possible que el producte tingui problemes crítics en l'entorn actiu i que, de fet, pot portar problemes al client.
En provar qualsevol lloc web en línia, un provador informa d’un problema que indica que el preu del producte no es mostra correctament, és a dir, mostra un preu inferior al preu real del producte i que s’ha de solucionar aviat.
Un cop el desenvolupador solucioni el problema, s’ha de tornar a provar i també cal fer proves de regressió, ja que s’hauria de corregir la comprovació del preu a la pàgina informada, però es pot mostrar un preu incorrecte a la pàgina de resum on es mostra el total amb els altres càrrecs o el correu enviat al client encara té el preu incorrecte.
Ara, en aquest cas, el client haurà de suportar la pèrdua si aquesta prova no es realitza, ja que el lloc calcula el cost total amb un preu incorrecte i el mateix preu es fa per correu electrònic a un client. Un cop el client accepta, el producte es ven en línia a un preu inferior, suposarà una pèrdua per al client.
Per tant, aquesta prova té un paper important i també és molt necessària i important.
Tipus de proves de regressió
A continuació es detallen els diferents tipus de regressió:
- Regressió de la unitat
- Regressió parcial
- Regressió completa
# 1) Regressió de la unitat
La regressió de la unitat es fa durant el Proves unitàries la fase i el codi es posen a prova de manera aïllada, és a dir, es bloquegen les dependències de la unitat que es vulgui provar de manera que es pugui provar individualment sense discrepàncies.
# 2) Regressió parcial
La regressió parcial es fa per verificar que el codi funciona bé fins i tot quan els canvis s’han fet al codi i que la unitat s’integra amb el codi sense canvis o ja existent.
# 3) Regressió completa
La regressió completa es fa quan es fa un canvi en el codi en diversos mòduls i també si l'impacte del canvi d'un canvi en qualsevol altre mòdul és incert. El producte en conjunt es regressa per comprovar qualsevol canvi a causa del codi canviat.
Quina regressió es requereix?
Això depèn de l'abast de les noves funcions afegides.
Si l’abast d’una correcció o característica és massa gran, l’àrea de l’aplicació afectada també és bastant gran i les proves s’han de realitzar a fons incloent tots els casos de prova de l’aplicació. Però això es pot decidir de manera efectiva quan el provador obté informació d'un desenvolupador sobre l'abast, la naturalesa i la quantitat de canvis.
Com que es tracta de proves repetitives, els casos de prova es poden automatitzar de manera que es pugui executar fàcilment un conjunt de casos de prova en una nova versió.
Els casos de proves de regressió s’han de seleccionar amb molta cura per tal de cobrir la màxima funcionalitat en un conjunt mínim de casos de prova. Aquest conjunt de casos de prova necessita millores contínues per a la nova funcionalitat afegida.
Es fa molt difícil quan l'abast de l'aplicació és molt gran i hi ha increments o pegats continus al sistema. En aquests casos, cal realitzar proves selectives per estalviar costos i temps de les proves. Aquests casos de proves selectives es trien en funció de les millores realitzades al sistema i de les parts on pot afectar més.
Què fem en comprovació de regressió?
- Torneu a executar les proves realitzades prèviament
- Compareu els resultats actuals amb els resultats de les proves prèviament executats
Es tracta d’un procés continu realitzat en diverses etapes al llarg del cicle de vida de les proves de programari.
Una bona pràctica és dur a terme una prova de regressió després de Proves de seny o fum i al final de les proves funcionals per a una versió curta.
Per realitzar proves efectives, la regressió Pla de proves s’hauria de crear. Aquest pla hauria d’esbossar l’estratègia de proves de regressió i els criteris de sortida. Les proves de rendiment també formen part d'aquesta prova per assegurar-se que el rendiment del sistema no es vegi afectat pels canvis realitzats als components del sistema.
Millors pràctiques : Executeu casos de proves automatitzats cada dia al vespre perquè es puguin solucionar els efectes secundaris de la regressió a la compilació del dia següent. D’aquesta manera redueix el risc d’alliberament cobrint gairebé tots els defectes de regressió en una etapa primerenca en lloc de trobar-los i solucionar-los al final del cicle d’alliberament.
Tècniques de proves de regressió
A continuació es detallen les diverses tècniques.
- Torneu a provar-ho tot
- Selecció de proves de regressió
- Priorització de casos de prova
- Híbrid
# 1) Torneu a provar-ho tot
Com el seu propi nom indica, tots els casos de prova del conjunt de proves es tornen a executar per assegurar-se que no hi hagi errors a causa d'un canvi en el codi. Aquest és un mètode car, ja que requereix més temps i recursos en comparació amb les altres tècniques.
# 2) Selecció de la prova de regressió
En aquest mètode, es seleccionen casos de prova del conjunt de proves per tornar a executar-se. No es torna a executar tota la suite. La selecció dels casos de prova es fa sobre la base del canvi de codi al mòdul.
Els casos de prova es divideixen en dues categories, una és casos de prova reutilitzables i una altra és casos de prova obsolets. Els casos de prova reutilitzables es poden utilitzar en futurs cicles de regressió, mentre que els obsolets no s’utilitzen en els propers cicles de regressió.
# 3) Priorització de casos de prova
Els casos de prova amb prioritat alta s’executen primer que els de prioritat mitjana i baixa. La prioritat del cas de prova depèn de la seva criticitat i del seu impacte sobre el producte i també de la funcionalitat del producte que s’utilitza amb més freqüència.
# 4) Híbrid
La tècnica híbrida és una combinació de selecció de proves de regressió i priorització de casos de prova. En lloc de seleccionar tot el conjunt de proves, seleccioneu només els casos de prova que es tornin a executar en funció de la seva prioritat.
Com es pot seleccionar una suite de proves de regressió?
La majoria dels errors trobats a l’entorn de producció es produeixen a causa dels canvis realitzats o bé solucionats a l’onzena hora, és a dir, els canvis realitzats en una etapa posterior. La correcció d'errors en l'última etapa podria crear altres problemes / errors al producte. Per això, la comprovació de regressió és molt important abans de llançar un producte.
A continuació es mostra una llista de casos de prova que es poden utilitzar mentre es realitza aquesta prova:
- Funcionalitats que s’utilitzen amb freqüència.
- Prova de casos que cobreixen el mòdul on s'han fet els canvis.
- Casos complexos de proves.
- Casos de proves d’integració que inclouen tots els components principals.
- Comproveu els casos de la funcionalitat o característica bàsica del producte.
- S'han d'incloure casos de prova de prioritat 1 i prioritat 2.
- S'han trobat casos de prova que fallen sovint o defectes de proves recents.
Com es realitzen proves de regressió?
Ara que hem establert el que significa regressió, és evident que també està provant, simplement repetint en una situació específica per una raó específica. Per tant, podem derivar amb seguretat que el mateix mètode que s’aplica per a les proves, en primer lloc també es pot aplicar a això.
Per tant, si les proves es poden fer manualment, també les proves de regressió. L’ús d’una eina no és necessari. No obstant això, a mesura que passa el temps, les aplicacions s’amunteguen amb més i més funcionalitats que augmenten l’abast de la regressió. Per treure el màxim profit del temps, aquesta prova és més sovint Automatitzat .
A continuació, es detallen els diversos passos per dur a terme aquesta prova
- Prepareu un conjunt de proves per a la regressió tenint en compte els punts esmentats a 'Com seleccionar el conjunt de proves de regressió'?
- Automatitzeu tots els casos de prova del conjunt de proves.
- Actualitzeu el conjunt de regressió sempre que sigui necessari, com si es detectés algun defecte nou que no es cobreixi en el cas de prova, i s'hauria d'actualitzar un cas de prova al mateix, de manera que no es perdi la prova la propera vegada . El conjunt de proves de regressió s’hauria de gestionar correctament actualitzant contínuament els casos de prova.
- Executeu els casos de prova de regressió sempre que hi hagi algun canvi en el codi, es solucioni l'error, s'afegeixi una nova funcionalitat, es faci una millora de la funcionalitat existent, etc.
- Creeu un informe d'execució de la prova que inclogui l'estat Passa / Falla dels casos de prova executats.
Per exemple:
Deixeu-me explicar-ho amb un exemple. Examineu la situació següent:
Versió 1 Estadístiques | |
---|---|
Nombre de provadors | 3 |
Nom de l'aplicació | XYZ |
Número de versió / versió | 1 |
Nombre de requisits (abast) | 10 |
Nombre de casos / proves | 100 |
Nombre de dies que triga a desenvolupar-se | 5 |
Nombre de dies que triga a provar-se | 5 |
Versió 2 Estadístiques | |
---|---|
Nombre de provadors | 3 |
Nom de l'aplicació | XYZ |
Número de versió / versió | 2 |
Nombre de requisits (abast) | 10+ 5 nous requisits |
Nombre de casos / proves | 100+ 50 nous |
Nombre de dies que triga a desenvolupar-se | 2,5 (ja que aquesta meitat de la quantitat de treball que abans) |
Nombre de dies que triga a provar-se | 5 (per als 100 TC existents) + 2,5 (per als nous requisits) |
Versió 3 Estadístiques | |
---|---|
Nombre de provadors | 3 |
Nom de l'aplicació | XYZ |
Número de versió / versió | 3 |
Nombre de requisits (abast) | 10+ 5 + 5 nous requisits |
Nombre de casos / proves | 100+ 50+ 50 nous |
Nombre de dies que triga a desenvolupar-se | 2,5 (ja que aquesta meitat de la quantitat de treball que abans) |
Nombre de dies que triga a provar-se | 7,5 (per als 150 TC existents) + 2,5 (per als nous requisits) |
Les següents són les observacions que podem fer a partir de la situació anterior:
- A mesura que les versions creixen, la funcionalitat creix.
- El temps de desenvolupament no necessàriament creix amb les versions, però sí el temps de prova
- Cap empresa o la seva direcció estarà disposada a invertir més temps en proves i menys per al desenvolupament
- Ni tan sols podem reduir el temps que es necessita per provar augmentant la mida de l’equip de proves, perquè més gent significa més diners i la gent nova també significa molta formació i potser també un compromís de qualitat, ja que és possible que la gent nova no estigui a l’alçada dels coneixements necessaris. nivells immediats.
- L’altra alternativa és clarament reduir la quantitat de regressió. Però això podria ser arriscat per al producte de programari.
Per tots aquests motius, les proves de regressió són un bon candidat per a les proves d’automatització, però no s’ha de fer només d’aquesta manera.
Passos bàsics per realitzar proves de regressió
Cada vegada que el programari experimenta un canvi i apareix una nova versió / versió, els passos que podeu seguir per dur a terme aquest tipus de proves són els següents:
- Comprendre quin tipus de canvis s’han fet al programari
- Analitzar i determinar quins mòduls / parts del programari es poden veure afectats: els equips de desenvolupament i BA poden ser fonamentals per proporcionar aquesta informació.
- Mireu els casos de prova i determineu si haureu de fer una regressió total, parcial o unitària. Identifiqueu els que s’adaptaran a la vostra situació
- Programa el temps i prova de distància.
Regressió Agile
Àgil és un enfocament adaptatiu que segueix un mètode iteratiu i incremental. El producte es desenvolupa en breus iteracions anomenades sprint que dura de 2 a 4 setmanes. En l'àgil, hi ha diverses iteracions, per tant, aquesta prova juga un paper important ja que la nova funcionalitat o canvi de codi es fa a les iteracions.
El conjunt de proves de regressió s’hauria de preparar des de la fase inicial i s’hauria d’actualitzar amb cada sprint.
A Àgil, la comprovació de regressió es cobreix en dues categories:
- Regressió de nivell Sprint
- Regressió de punta a punta
# 1) Regressió de nivell Sprint
Sprint Level Regression es fa principalment per a la nova funcionalitat o la millora que es fa a l'últim sprint. Els casos de prova del conjunt de proves es seleccionen segons la nova funcionalitat afegida o la millora que es faci.
# 2) Regressió d'extrem a extrem
La regressió d’extrem a extrem inclou tots els casos de prova que s’han de tornar a executar per provar el producte complet de punta a punta cobrint totes les funcionalitats bàsiques del producte.
Com Agile té sprints curts i continua, és molt necessari automatitzar el conjunt de proves, els casos de prova es tornen a executar i això també s’ha de completar en un curt període de temps. L’automatització dels casos de prova redueix el temps d’execució i el lliscament dels defectes.
Avantatges
A continuació es detallen els diversos avantatges de la prova de regressió
- Millora la qualitat del producte.
- Assegura que qualsevol correcció d'errors o millores que es facin no afecti la funcionalitat existent del producte.
- Es poden utilitzar eines d'automatització per a aquesta prova.
- Assegura que els problemes ja solucionats no es tornin a produir.
Desavantatges
Tot i que hi ha diversos avantatges, també hi ha alguns desavantatges. Ells són:
- També s’ha de fer per fer un petit canvi en el codi, ja que fins i tot un petit canvi en el codi pot crear problemes en la funcionalitat existent.
- Si en cas que no s’utilitzi l’automatització al Projecte per a aquesta prova, serà una tasca tediós i llarga executar els casos de prova una i altra vegada.
Regressió de l'aplicació GUI
És difícil realitzar una prova de regressió GUI (interfície gràfica d'usuari) quan l’estructura GUI es modifica. Els casos de prova escrits a la GUI antiga ja estan obsolets o cal modificar-los.
La reutilització dels casos de prova de regressió significa que els casos de prova de la GUI es modifiquen segons la nova GUI. Però aquesta tasca esdevé feixuga si teniu un gran nombre de casos de prova de la GUI.
Diferència entre la regressió i la revisió
La prova de nou es fa per als casos de prova que fallen durant l'execució i l'error plantejat per a la mateixa s'ha solucionat, mentre que la comprovació de regressió no es limita a la correcció d'errors, ja que també cobreix altres casos de prova per garantir que la correcció d'errors no s'hagi ha afectat qualsevol altra funcionalitat del producte.
Regression Test Pla Template (TOC)
1. Història del document
2. Referències
3. Pla de proves de regressió
3.1. Introducció
3.2. Propòsit
3.3. Prova d’Estratègia
3.4. Funció a provar
3.5. Requisit de recursos
3.5.1. Requisit de maquinari
3.5.2. Requisit de programari
3.6. Calendari de proves
3.7. Sol · licitud de canvi
3,8. Criteris d’entrada / sortida
3.8.1. Criteris d'entrada per a aquesta prova
3.8.2. Criteris de sortida per a aquesta prova
3.9. Assumpció / Restriccions
3.10. Casos de prova
3.11. Risc / Supòsits
3.12. Eines
4. Aprovació / Acceptació
Fem una ullada a cadascun d’ells amb detall.
# 1) Història del document
La història del document consisteix en un registre del primer esborrany i de tots els actualitzats en el format que es mostra a continuació.
Versió | Data | Autor | Comenta |
---|---|---|---|
1 | DD / MM / AA | ABC | Aprovat |
2 | DD / MM / AA | ABC | S'ha actualitzat per a la funció afegida |
# 2) Referències
La columna Referències fa un seguiment de tots els documents de referència utilitzats o necessaris per al projecte mentre es crea un pla de prova.
no | Document | Ubicació |
---|---|---|
1 | Document SRS | Unitat compartida |
# 3) Pla de proves de regressió
3.1. Introducció
Aquest document descriu el canvi / actualització / millora del producte a provar i l'enfocament utilitzat per a aquesta prova. Tots els canvis de codi, millores, actualitzacions i funcions afegides es detallen per ser provats. Els casos de prova que s’utilitzen per a la prova d’unitat i la prova d’integració es poden utilitzar per crear un conjunt de proves per a la regressió.
3.2. Propòsit
El propòsit del pla de proves de regressió és descriure què i exactament es realitzarien les proves per aconseguir els resultats. Es fa una comprovació de regressió per assegurar-se que cap altra funcionalitat del producte es veu dificultada a causa del canvi de codi.
3.3. Prova d’Estratègia
Test Strategy descriu l'enfocament que s'utilitzarà per realitzar aquesta prova i que inclou la tècnica que s'utilitzarà, quins seran els criteris de finalització, qui realitzarà quina activitat, qui escriurà els scripts de prova, quina eina de regressió s'utilitzarà , passos per cobrir els riscos com la reducció de recursos, el retard en la producció, etc.
3.4. Funcions a provar
Les funcions / components del producte a provar es detallen aquí. En regressió, es reexecuten tots els casos de prova o es trien els que afecten la funcionalitat existent en funció de la correcció / actualització o millora realitzada.
3.5. Requisit de recursos
3.5.1. Requisit de maquinari:
Els requisits de maquinari s’identifiquen aquí com ordinadors, ordinadors portàtils, mòdems, llibres Mac, telèfons intel·ligents, etc.
3.5.2. Requisits de programari:
El requisit de programari s’identifica com el sistema operatiu i els navegadors necessaris.
3.6. Calendari de proves
El calendari de proves defineix el temps estimat per realitzar les activitats de prova.
Per exemple Quants recursos realitzaran una activitat de prova i també en quant de temps?
3.7. Sol · licitud de canvi
S'esmenten detalls de CR per a la qual es realitzaria la regressió.
S.No | CR Descripció | Suite de proves de regressió |
---|---|---|
1 | ||
2 |
3,8. Criteris d’entrada / sortida
3.8.1. Criteris d'entrada per a aquesta prova:
Es defineixen els criteris d’entrada del producte per iniciar la comprovació de regressió.
Per exemple:
- S'haurien de completar els canvis de codificació / millora / addició de noves funcions.
- S'ha d'aprovar el pla de prova de regressió.
3.8.2. Criteris de sortida per a aquesta prova:
Aquí es defineixen els criteris de sortida per a la regressió.
Per exemple:
- S'haurien de completar les proves de regressió.
- Cal tancar qualsevol error crític nou trobat durant aquesta prova.
- L'informe de prova hauria d'estar llest.
3.9. Casos de prova
Aquí es defineixen els casos de proves de regressió.
3.10. Risc / Supòsits
S'identifica qualsevol risc i supòsit i es prepara un pla de contingència per al mateix.
3.11. Eines
S’identifiquen les eines que s’utilitzaran en el projecte. Tal com:
- Eina d'automatització
- Eina d'informes d'errors
# 4) Aprovació / acceptació
Aquí es detallen els noms i la designació de les persones:
Nom | Aprovat / rebutjat | Signatura | Data |
---|---|---|---|
Conclusió
La prova de regressió és un dels aspectes importants, ja que ajuda a oferir un producte de qualitat assegurant-se que qualsevol canvi del codi, ja sigui petit o gran, no afecta la funcionalitat existent o antiga.
Hi ha moltes eines d’automatització disponibles per automatitzar els casos de proves de regressió, però s’hauria de seleccionar una eina segons el requisit del projecte. Una eina hauria de tenir la possibilitat d’actualitzar el conjunt de proves, ja que el conjunt de proves de regressió s’ha d’actualitzar amb freqüència.
Amb això, acabem aquest tema i esperem que a partir d’ara hi hagi molta més claredat sobre el tema.
Feu-nos saber les vostres preguntes i comentaris relacionats amb la regressió. Com heu abordat les tasques de proves de regressió?
=> Visiteu aquí per obtenir la sèrie completa de programes de proves
Lectura recomanada
- Les millors eines de prova de programari 2021 (Eines d'automatització de proves de control de qualitat)
- Top 10 d'eines de proves de regressió més populars el 2021
- Què són les proves de fiabilitat: definició, mètode i eines
- 11 millors eines d'automatització per provar aplicacions d'Android (eines de prova d'aplicacions d'Android)
- Proves de regressió automatitzades: reptes, processos i passos
- Prova de descàrrega de llibres electrònics
- Diferència entre la prova de repetició i la prova de regressió amb un exemple
- Top 10+ millors eines de prova de SAP (eines d'automatització de SAP)