Les proves de regressió són tècniques de prova de caixa negra. S'utilitza per autenticar un canvi de codi al programari que no afecta la funcionalitat existent del producte. Les proves de regressió són assegurar-se que el producte funcioni bé amb noves funcionalitats, correccions d'errors o qualsevol canvi a la funció existent.
Les proves de regressió són un tipus de proves de programari . Els casos de prova es tornen a executar per comprovar que la funcionalitat anterior de l'aplicació funciona bé i els nous canvis no han produït cap error.
Les proves de regressió es poden realitzar en una nova compilació quan hi ha un canvi significatiu en la funcionalitat original. Assegura que el codi encara funciona fins i tot quan es produeixen els canvis. La regressió significa tornar a provar aquelles parts de l'aplicació, que no s'han modificat.
Les proves de regressió també es coneixen com a mètode de verificació. Els casos de prova solen ser automatitzats. Els casos de prova s'han d'executar moltes vegades i executar el mateix cas de prova una i altra vegada manualment, també requereix temps i tediós.
Exemple de prova de regressió
Aquí anem a prendre un cas per definir la prova de regressió de manera eficient:
Penseu en un producte Y, en el qual una de les funcionalitats és activar la confirmació, l'acceptació i els correus electrònics enviats. També s'ha de provar per assegurar-se que el canvi en el codi no els afecta. Les proves regressives no depenen de cap llenguatge de programació com Java , C++ , C# , etc. Aquest mètode s'utilitza per provar el producte per detectar modificacions o actualitzacions realitzades. Assegura que qualsevol canvi en un producte no afecta el mòdul existent del producte. Verifiqueu que els errors s'han corregit i les funcions afegides recentment no han creat cap problema a la versió de treball anterior del programari.
Quan podem fer proves de regressió?
Fem proves de regressió sempre que es modifiqui el codi de producció.
Podem realitzar proves de regressió en el següent escenari, aquests són:
1. Quan s'afegeix una nova funcionalitat a l'aplicació.
Exemple:
q3 mesos
Un lloc web té una funcionalitat d'inici de sessió que permet als usuaris iniciar sessió només amb correu electrònic. Ara s'ofereix una nova funció per iniciar sessió amb Facebook.
2. Quan hi hagi un requisit de canvi.
Exemple:
Recordeu la contrasenya eliminada de la pàgina d'inici de sessió que s'aplicava anteriorment.
3. Quan s'ha solucionat el defecte
Exemple:
Suposem que el botó d'inici de sessió no funciona en una pàgina d'inici de sessió i un verificador informa d'un error que indica que el botó d'inici de sessió està trencat. Un cop solucionat l'error pels desenvolupadors, el provador el prova per assegurar-se que el botó d'inici de sessió funciona segons el resultat esperat. Simultàniament, el provador prova altres funcionalitats relacionades amb el botó d'inici de sessió.
4. Quan hi ha una solució de problemes de rendiment
Exemple:
La càrrega d'una pàgina d'inici triga 5 segons, reduint el temps de càrrega a 2 segons.
5. Quan hi ha un canvi d'entorn
Exemple:
Quan actualitzem la base de dades de MySql a Oracle.
Com realitzar proves de regressió?
La necessitat de proves de regressió arriba quan el manteniment del programari inclou millores, correccions d'errors, optimització i supressió de funcions existents. Aquestes modificacions poden afectar la funcionalitat del sistema. La prova de regressió es fa necessària en aquest cas.
Les proves de regressió es poden realitzar mitjançant les tècniques següents:
1. Torneu a provar-ho tot:
Re-Test és un dels enfocaments per fer proves de regressió. En aquest enfocament, s'han de tornar a executar tots els casos de prova. Aquí podem definir una nova prova com quan una prova falla, i determinem que la causa de la fallada és una fallada del programari. S'informa de l'error, podem esperar una nova versió del programari en la qual s'ha solucionat el defecte. En aquest cas, haurem de tornar a executar la prova per confirmar que l'error s'ha solucionat. Això es coneix com a reprovació. Alguns es referiran a això com a prova de confirmació.
La reprovació és molt cara, ja que requereix molt temps i recursos.
2. Selecció de la prova de regressió:
- En aquesta tècnica, s'executarà un vestit de cas de prova seleccionat en lloc d'un vestit de cas de prova sencer.
- El cas de prova seleccionat s'adapta dividit en dos casos
- Cases de prova reutilitzables.
- Casos de prova obsolets.
- Els casos de prova reutilitzables es poden utilitzar en el cicle de regressió posterior.
- Els casos de prova obsolets no es poden utilitzar en el cicle de regressió posterior.
3. Priorització dels casos de prova:
Prioritzeu el cas de prova en funció de l'impacte empresarial, la funcionalitat crítica i utilitzada amb freqüència. La selecció de casos de prova reduirà el conjunt de proves de regressió.
Quines són les eines de prova de regressió?
Les proves de regressió són una part vital del procés de control de qualitat; mentre realitzem la regressió ens podem trobar amb els següents reptes:
Les proves de regressió consumeixen molt de temps. Les proves de regressió tornen a incloure proves existents, de manera que els provadors no estan entusiasmats de tornar a executar la prova.
Les proves de regressió també són complexes quan cal actualitzar qualsevol producte; les llistes de la prova també augmenten.
Les proves de regressió garanteixen que les característiques existents del producte encara funcionin. La comunicació sobre les proves de regressió amb un líder no tècnic pot ser una tasca difícil. L'executiu vol veure el producte avançar i fer una inversió de temps considerable en proves de regressió per garantir que la funcionalitat existent sigui difícil.
Procés de prova de regressió
El procés de prova de regressió es pot realitzar a través de construeix i la llançaments .
Proves de regressió a les compilacions
Sempre que s'arregla l'error, tornem a provar l'error i, si hi ha algun mòdul dependent, fem una prova de regressió.
Per exemple , Com realitzem les proves de regressió si tenim diferents compilacions com Build 1, Build 2 i Build 3 , que té diferents escenaris.
Construcció 1
- En primer lloc, el client proporcionarà les necessitats del negoci.
- A continuació, l'equip de desenvolupament comença a desenvolupar les funcions.
- Després d'això, l'equip de proves començarà a escriure els casos de prova; per exemple, escriuen 900 casos de prova per a la versió núm. 1 del producte.
- I després, començaran a implementar els casos de prova.
- Un cop llançat el producte, el client realitza una ronda de proves d'acceptació.
- I al final, el producte es trasllada al servidor de producció.
Construcció 2
- Ara, el client demana que s'afegeixin de 3 a 4 funcions addicionals (noves) i també proporciona els requisits per a les noves funcions.
- L'equip de desenvolupament comença a desenvolupar noves funcions.
- Després d'això, l'equip de proves començarà a escriure el cas de prova de les noves funcions i escriurà uns 150 casos de prova nous. Per tant, el nombre total de casos de prova escrits és de 1050 per a ambdues versions.
- Ara l'equip de proves comença a provar les noves funcions utilitzant 150 casos de prova nous.
- Un cop fet això, començaran a provar les funcions antigues amb l'ajuda de 900 casos de prova per verificar que afegir la nova funció ha danyat les funcions antigues o no.
- Aquí, provar les funcions antigues es coneix com Prova de regressió .
- Un cop provades totes les característiques (nous i antigues), el producte es lliura al client i, a continuació, el client farà la prova d'acceptació.
- Un cop fetes les proves d'acceptació, el producte es trasllada al servidor de producció.
Construeix 3
- Després de la segona versió, el client vol eliminar una de les funcions com ara Vendes.
- A continuació, esborrarà tots els casos de prova que pertanyen al mòdul de vendes (uns 120 casos de prova).
- A continuació, proveu l'altra característica per verificar que si totes les altres funcions funcionen bé després d'eliminar els casos de prova del mòdul de vendes, i aquest procés es fa amb les proves de regressió.
Nota:
- Prova les característiques estables per assegurar-se que es trenca a causa dels canvis. Aquí els canvis impliquen que el modificació, addició, correcció d'errors o supressió .
- La reexecució dels mateixos casos de prova en les diferents compilacions o versions és per garantir que els canvis (modificació, addició, correcció d'errors o supressió) no introdueixin errors en funcions estables.
Proves de regressió al llarg de la versió
El procés de prova de regressió s'inicia sempre que hi hagi una versió nova per al mateix projecte perquè la nova característica pot afectar els elements antics de les versions anteriors.
Per entendre el procés de prova de regressió, seguirem els passos següents:
Pas 1
No hi ha cap prova de regressió Alliberament #1 perquè no hi ha cap modificació a la versió #1, ja que la versió és nova.
Pas 2
El concepte de prova de regressió parteix de Alliberament #2 quan el client en dóna nous requisits .
Pas 3
Després d'aconseguir primer els nous requisits (modificar les funcions), ells (els desenvolupadors i els enginyers de proves) entendran les necessitats abans d'anar al anàlisi d'impacte .
Pas 4
Després d'entendre els nous requisits, realitzarem una ronda de anàlisi d'impacte per evitar el risc major, però aquí sorgeix la pregunta qui farà l'anàlisi d'impacte?
Pas 5
L'anàlisi d'impacte la realitza el client en funció dels seus coneixements empresarials , el desenvolupador en funció dels seus coneixements de codificació , i el més important, ho fa el enginyer de proves perquè tenen el coneixement del producte .
Nota: si una sola persona ho fa, és possible que no cobreixi totes les àrees d'impacte, per la qual cosa incloem totes les persones perquè puguem cobrir una àrea d'impacte màxima, i l'anàlisi d'impacte s'hauria de fer en les primeres etapes dels llançaments.
Pas 6
Un cop acabem amb el zona d'impacte , llavors el desenvolupador prepararà el àrea d'impacte (document) , i la client també prepararà el document de l'àrea d'impacte perquè puguem aconseguir el màxima cobertura de l'anàlisi d'impacte .
Pas 7
fórmula de paleta
Després de completar l'anàlisi d'impacte, el desenvolupador, el client i l'enginyer de proves enviaran el Informes# dels documents de l'àrea d'impacte al Cap de prova . I mentrestant, l'enginyer de proves i el desenvolupador estan ocupats treballant en el nou cas de prova.
Pas 8
Un cop el responsable de la prova obtingui els informes #, ho farà consolidar els informes i emmagatzemats al Repositori de requisits de casos de prova per al llançament #1.
Nota: Repositori de casos de prova: aquí desarem tots els casos de prova de les versions.
Pas 9
Després d'això, el responsable de prova agafarà l'ajuda de RTM i escollirà el necessari cas de prova de regressió des del dipòsit de casos de prova , i aquests fitxers es col·locaran al fitxer Suite de proves de regressió .
Nota:
- El cable de prova emmagatzemarà el cas de prova de regressió a la suite de proves de regressió perquè no hi hagi més confusió.
Pas 10
Després d'això, quan l'enginyer de proves hagi acabat de treballar en els nous casos de prova, el cable de prova ho farà assignar el cas de prova de regressió a l'enginyer de proves.
Pas 11
Quan tots els casos de prova de regressió i les noves característiques són estable i passar , després comproveu zona d'impacte utilitzant el cas de prova fins que sigui durador per a les funcions antigues més les noves, i després es lliurarà al client.
Tipus de proves de regressió
Els diferents tipus de proves de regressió són els següents:
- Prova de regressió unitària [URT]
- Prova de regressió regional[RRT]
- Prova de regressió completa o completa [FRT]
1) Prova de regressió unitària [URT]
En això, provarem només la unitat canviada, no l'àrea d'impacte, perquè pot afectar els components del mateix mòdul.
Exemple 1
A l'aplicació següent i a la primera compilació, el desenvolupador desenvolupa el Cerca botó que accepta 1-15 caràcters . A continuació, l'enginyer de proves prova el botó Cerca amb l'ajuda de la tècnica de disseny de casos de prova .
Ara, el client fa alguna modificació en el requisit i també demana que el Botó de cerca pot acceptar el 1-35 caràcters . L'enginyer de proves provarà només el botó Cerca per verificar que triga entre 1 i 35 caràcters i no comprova cap altra característica de la primera compilació.
Exemple 2
Aquí, tenim Construcció B001 , i s'identifica un defecte i l'informe es lliura al desenvolupador. El desenvolupador solucionarà l'error i enviarà juntament amb algunes funcions noves que es desenvolupen en el segon Construcció B002 . Després d'això, l'enginyer de proves provarà només un cop solucionat el defecte.
- L'enginyer de prova ho identificarà fent clic a Presentar botó va a la pàgina en blanc.
- I és un defecte, i s'envia al desenvolupador perquè el solucioni.
- Quan la nova compilació arriba amb les correccions d'errors, l'enginyer de proves només provarà el botó Envia.
- I aquí, no comprovarem altres funcions de la primera compilació i passarem a provar les noves funcions i les enviarem a la segona compilació.
- Estem segurs que arreglant el Presentar El botó no afectarà les altres funcions, de manera que només provem l'error corregit.
Per tant, podem dir que provant només la característica canviada s'anomena Prova de regressió unitat .
2) Prova de regressió regional [RRT]
En això, anem a provar la modificació juntament amb l'àrea o regions d'impacte, s'anomenen Prova de regressió regional . Aquí, estem provant l'àrea d'impacte perquè si hi ha mòduls fiables, també afectarà els altres mòduls.
Per exemple:
A la imatge de sota com podem veure que tenim quatre mòduls diferents, com ara Mòdul A, Mòdul B, Mòdul C i Mòdul D , que proporcionen els desenvolupadors per a les proves durant la primera construcció. Ara, l'enginyer de proves identificarà els errors Mòdul D . L'informe d'error s'envia als desenvolupadors i l'equip de desenvolupament corregeix aquests defectes i envia la segona compilació.
A la segona construcció, es corregeixen els defectes anteriors. Ara l'enginyer de proves entén que la correcció d'errors del mòdul D ha afectat algunes funcions Mòdul A i Mòdul C . Per tant, l'enginyer de proves primer prova el mòdul D on s'ha corregit l'error i després comprova les àrees d'impacte a Mòdul A i Mòdul C . Per tant, aquesta prova es coneix com Prova de regressió regional.
Mentre realitzem les proves de regressió regional, és possible que ens enfrontem al problema següent:
Problema:
A la primera compilació, el client envia alguna modificació en el requisit i també vol afegir noves funcions al producte. Les necessitats s'envien als dos equips, és a dir, desenvolupament i prova.
lectura d'un fitxer csv en java
Després d'obtenir els requisits, l'equip de desenvolupament comença a fer la modificació i també desenvolupa les noves funcions en funció de les necessitats.
Ara, el responsable de prova envia correu als clients i els demana que totes són les zones d'impacte que es veuran afectades després de fer la modificació necessària. Per tant, el client tindrà una idea de les característiques necessàries per tornar a provar. I també enviarà un correu a l'equip de desenvolupament per saber quines àrees de l'aplicació es veuran afectades com a conseqüència dels canvis i incorporacions de noves funcionalitats.
I de la mateixa manera, el client envia un correu a l'equip de proves per obtenir una llista de les àrees d'impacte. Per tant, el responsable de prova recopilarà la llista d'impacte del client, l'equip de desenvolupament i també l'equip de prova.
Això Llista d'impacte s'envia a tots els enginyers de proves que miren la llista i comproven si les seves característiques estan modificades i, en cas afirmatiu, ho fan proves de regressió regional . Les àrees d'impacte i les àrees modificades són provades pels respectius enginyers. Cada enginyer de proves prova només les seves característiques que podrien haver-se vist afectades com a resultat de la modificació.
El problema amb aquest enfocament anterior és que és possible que el líder de prova no tingui la idea completa de les àrees d'impacte perquè l'equip de desenvolupament i el client poden no tenir tant de temps per revertir els seus correus.
Solució
Per resoldre el problema anterior, seguirem el procés següent:
Quan s'adjunta una nova compilació amb les últimes funcions i correccions d'errors, l'equip de proves organitzarà la reunió on parlarà sobre si les seves funcions estan afectant a causa de la modificació anterior. Per tant, faran una ronda de Anàlisi d'impacte i generar el Llista d'impacte . En aquesta llista particular, l'enginyer de proves intenta tancar les àrees d'impacte màximes probables, la qual cosa també disminueix la possibilitat d'obtenir els defectes.
Quan arribi una nova construcció, l'equip de proves seguirà el procediment següent:
- Faran proves de fum per comprovar la funcionalitat bàsica d'una aplicació.
- A continuació, provaran noves funcions.
- Després d'això, comprovaran les funcions modificades.
- Un cop hagin acabat de comprovar les característiques modificades, l'enginyer de proves tornarà a provar els errors.
- I després comprovaran l'àrea d'impacte realitzant les proves de regressió regional.
Desavantatge d'utilitzar proves de regressió unitària i regional
A continuació es mostren alguns dels inconvenients de l'ús de proves de regressió unitària i regional:
- Potser ens perdem alguna zona d'impacte.
- És possible que identifiquem la zona d'impacte equivocada.
Nota: podem dir que el treball important que fem en les proves de regressió regional ens portarà a obtenir més nombre de defectes. Però, si realitzem la mateixa dedicació per treballar en la prova de regressió completa, obtindrem menys defectes. Per tant, aquí podem determinar que la millora en l'esforç de prova no ens ajudarà a obtenir més defectes.
3) Prova de regressió completa [FRT]
Durant la segona i la tercera versió del producte, el client demana afegir de 3 a 4 funcions noves, i també s'han de solucionar alguns defectes de la versió anterior. A continuació, l'equip de proves farà l'anàlisi d'impacte i identificarà que la modificació anterior ens portarà a provar tot el producte.
Per tant, podem dir que provant el característiques modificades i totes les característiques restants (antigues). s'anomena el Prova de regressió completa .
Quan fem proves de regressió completa?
Realitzarem el FRT quan tinguem les condicions següents:
- Quan es produeix la modificació al fitxer font del producte. Per exemple , JVM és el fitxer arrel de l'aplicació JAVA i, si es produeix algun canvi a la JVM, es provarà tot el programa JAVA.
- Quan hem de realitzar n-nombre de canvis.
Nota:
Les proves de regressió regional són l'enfocament ideal de les proves de regressió, però el problema és que podem perdre molts defectes mentre realitzem les proves de regressió regional.
I aquí resoldrem aquest problema amb l'ajuda del següent enfocament:
- Quan es doni l'aplicació per a les proves, l'enginyer de proves provarà el primer cicle 10-14 i farà el RRT .
- Després per al 15è cicle, fem FRT. I de nou, per al proper cicle 10-15, ho fem Prova de regressió regional , i pel 31è cicle, fem el prova de regressió completa , i seguirem així.
- Però durant els darrers deu cicles del llançament, només actuarem prova de regressió completa .
Per tant, si seguim l'enfocament anterior, podem obtenir més defectes.
L'inconvenient de fer proves de regressió manualment repetidament:
- La productivitat disminuirà.
- És una feina difícil de fer.
- No hi ha coherència en l'execució de la prova.
- I també augmenta el temps d'execució de la prova.
Per tant, buscarem que l'automatització superi aquests problemes; quan tinguem n-número del cicle de prova de regressió, anem a buscar el procés de prova de regressió d'automatització .
Procés de regressió automatitzat
Generalment anem per l'automatització sempre que hi ha múltiples llançaments o cicles de regressió múltiple o hi ha la tasca repetitiva.
El procés de prova de regressió d'automatització es pot fer en els passos següents:
Note1:
El procés de prova de l'aplicació mitjançant algunes eines es coneix com a prova d'automatització.
Suposem que si agafem un exemple d'a Mòdul d'inici de sessió , llavors com podem realitzar la prova de regressió.
Aquí, l'inici de sessió es pot fer de dues maneres, que són les següents:
Manualment: En això, realitzarem la regressió només una i dues vegades.
Automatització: En això, farem l'automatització diverses vegades, ja que hem d'escriure els scripts de prova i fer l'execució.
Nota 2: En temps real, si ens hem enfrontat a alguns problemes com ara:
| Problemes | Manejar per |
|---|---|
| Noves característiques | Enginyer d'assaig manual |
| Funcions de prova en regressió | Enginyer de proves d'automatització |
| Restant (funció 110 + versió núm. 1) | Enginyer d'assaig manual |
Pas 1
Quan s'inicia la nova versió, no optem per l'automatització perquè no hi ha cap concepte de prova de regressió i cas de prova de regressió tal com ho vam entendre en el procés anterior.
Pas 2
Quan comença la nova versió i la millora, tenim dos equips, és a dir, l'equip manual i l'equip d'automatització.
Pas 3
L'equip manual revisarà els requisits i també identificarà l'àrea d'impacte i lliurarà el conjunt de proves de requisits a l'equip d'automatització.
Pas 4
Ara, l'equip manual comença a treballar en les noves funcions i l'equip d'automatització començarà a desenvolupar l'script de prova i també començarà a automatitzar el cas de prova , el que significa que els casos de prova de regressió es convertiran en l'script de prova.
Pas 5
Abans que ells (l'equip d'automatització) comencin a automatitzar el cas de prova, també analitzaran quins casos es poden automatitzar o no.
Pas 6
A partir de l'anàlisi, iniciaran l'automatització, és a dir, convertiran tots els casos de prova de regressió en l'script de prova.
Pas 7
Durant aquest procés, rebran l'ajuda del Casos de regressió perquè no tenen el coneixement del producte tan bé com el eina i la aplicació .
Pas 8
Un cop l'script de prova estigui llest, iniciaran l'execució d'aquests scripts a la nova aplicació [funció antiga]. Atès que, l'script de prova s'escriu amb l'ajuda de la característica de regressió o la característica antiga.
Pas 9
cobertura de declaracions
Un cop finalitzada l'execució, obtenim un estat diferent com Aprovat/fallat .
Pas 10
Si l'estat falla, el que significa que s'ha de tornar a confirmar manualment, i si existeix l'error, s'informarà al desenvolupador interessat. Quan el desenvolupador soluciona aquest error, l'enginyer de prova manual ha de tornar a provar l'error juntament amb l'àrea d'impacte, i també l'enginyer de proves d'automatització ha de tornar a executar l'script.
Pas 11
Aquest procés continua fins que totes les funcions noves i la funció de regressió s'aprovaran.
Beneficis de fer proves de regressió mitjançant les proves d'automatització:
- L'script de prova es pot reutilitzar en diverses versions.
- Tot i que el nombre de casos de prova de regressió augmenta per llançament, i no hem d'augmentar el recurs d'automatització, ja que alguns casos de regressió ja estan automatitzats des de la versió anterior.
- És un procés d'estalvi de temps perquè l'execució és sempre més ràpida que el mètode manual.
Com seleccionar els casos de prova per a les proves de regressió?
Es va trobar a partir d'una inspecció de la indústria. Els diversos defectes reportats pel client es deuen a correccions d'errors d'última hora. Crear efectes secundaris i, per tant, seleccionar el cas de prova per a les proves de regressió és un art, no una tasca fàcil.
La prova de regressió es pot fer mitjançant:
- Un cas de prova que té defectes freqüents
- Funcionalitats més visibles per als usuaris.
- Els casos de prova verifiquen les característiques bàsiques del producte.
- Tots els casos de prova d'integració
- Tots els casos de prova complexos
- Casos de prova de valor límit
- Una mostra de casos de prova reeixits
- Fracàs dels casos de prova
Eines de prova de regressió
Si el programari experimenta canvis freqüents, els costos de les proves de regressió també augmenten. En aquests casos, l'execució manual de casos de prova augmenta el temps d'execució de la prova i els costos. En aquest cas, les proves d'automatització són la millor opció. La durada de l'automatització depèn del nombre de casos de prova que romanen reutilitzables per a cicles de regressió successius.
A continuació es mostren les eines essencials utilitzades per a les proves de regressió:
Seleni
Selenium és una eina de codi obert. Aquesta eina s'utilitza per a proves automatitzades d'una aplicació web. Per a les proves de regressió basades en navegador, s'utilitza seleni. Seleni utilitzat per a la prova de regressió del nivell d'IU per a aplicacions basades en web.
Estudi Ranorex
Automatització de proves de regressió tot en un per a aplicacions d'escriptori, web i mòbils amb Selenium Web Driver integrat. Ranorex Studio inclou IDE complet i eines per a l'automatització sense codi.
Professional de prova ràpida (QTP)
QTP és una eina de prova automatitzada que s'utilitza per a proves de regressió i funcionals. És una eina basada en paraules clau basada en dades. Va utilitzar el llenguatge VBScript per a l'automatització. Si obrim l'eina QTP, veurem els tres botons que són Grava, reprodueix i atura . Aquests botons ajuden a registrar cada clic i acció realitzada al sistema informàtic. Enregistra les accions i les reprodueix.
Provador funcional racional (RTF)
El provador funcional racional és una eina Java utilitzada per automatitzar els casos de prova d'aplicacions de programari. RTF s'utilitza per automatitzar casos de prova de regressió i també s'integra amb el provador funcional racional.
Per obtenir més informació sobre les eines de prova de regressió i automatització, consulteu l'enllaç següent:
https://www.javatpoint.com/automation-testing-tool
Proves de regressió i gestió de la configuració
La gestió de la configuració en les proves de regressió esdevé imprescindible en entorns àgils, on un codi es modifica contínuament. Per garantir una prova de regressió vàlida, hem de seguir els passos següents:
- No es permeten canvis al codi durant la fase de prova de regressió.
- Un cas de prova de regressió no ha de ser afectat pels canvis del desenvolupador.
- La base de dades utilitzada per a les proves de regressió ha d'estar aïllada; no es permeten canvis a la base de dades.
Diferències entre proves de reprovació i proves de regressió
Tornar a provar les proves significa tornar a provar la funcionalitat o l'error per assegurar-se que el codi s'ha corregit. Si no s'estableix, no caldrà tornar a obrir els defectes. Si s'arregla, el defecte es tanca.
La reprovació és un tipus de prova que es realitza per comprovar que els casos de prova que no van tenir èxit en l'execució final s'han superat amb èxit després de reparar els defectes.
Prova de regressió significa provar l'aplicació de programari quan se sotmet a un canvi de codi per assegurar-se que el codi nou no ha afectat altres parts del programari.
La prova de regressió és un tipus de prova executada per comprovar si un codi no ha canviat la funcionalitat existent de l'aplicació.
Les diferències entre la prova de repetició i la prova de regressió són les següents:
| Tornar a provar | Prova de regressió |
|---|---|
| Es tornen a provar per assegurar-se que els casos de prova que han fallat en l'execució final passen després que els defectes es solucionin. | Es fan proves de regressió per confirmar si el canvi de codi no ha afectat les funcions existents. |
| La reprovació funciona amb solucions de defectes. | L'objectiu de les proves de regressió és garantir que els canvis de codi no afectin negativament la funcionalitat existent. |
| La verificació de defecte és part de la nova prova. | Les proves de regressió no inclouen la verificació de defectes |
| La prioritat de la nova prova és superior a la prova de regressió, de manera que es fa abans de la prova de regressió. | Segons el tipus de projecte i la disponibilitat de recursos, les proves de regressió poden ser paral·leles a les proves de nou. |
| Re-Test és una prova planificada. | La prova de regressió és una prova genèrica. |
| No podem automatitzar els casos de prova per tornar a provar. | Podem fer l'automatització per a proves de regressió; les proves manuals poden ser costoses i requereixen temps. |
| La nova prova és per a casos de prova fallits. | Les proves de regressió són per a casos de prova aprovats. |
| Torneu a provar per assegurar-vos que s'ha corregit l'error original. | Les proves de regressió comprovan efectes secundaris inesperats. |
| La nova prova executa defectes amb les mateixes dades i el mateix entorn amb diferents entrades amb una nova compilació. | Les proves de regressió són quan hi ha una modificació o canvis esdevenen obligatoris en un projecte existent. |
| No es pot tornar a provar abans de començar la prova. | Les proves de regressió poden obtenir casos de prova de l'especificació funcional, tutorials i manuals d'usuari i informes de defectes pel que fa al problema corregit. |
Avantatges de les proves de regressió
Els avantatges de les proves de regressió són:
- Les proves de regressió augmenten la qualitat del producte.
- Assegura que qualsevol correcció d'errors o canvis no afecti la funcionalitat existent del producte.
- Les eines d'automatització es poden utilitzar per a proves de regressió.
- S'assegura que els problemes solucionats no es tornin a produir.
Inconvenients de les proves de regressió
Hi ha diversos avantatges de les proves de regressió, tot i que també hi ha desavantatges.
- Les proves de regressió s'han de fer per a petits canvis en el codi perquè fins i tot un petit canvi en el codi pot crear problemes en la funcionalitat existent.
- Si en el cas que l'automatització no s'utilitzi al projecte per a les proves, serà una tasca tediosa i llarga executar la prova una i altra vegada.
Conclusió
Les proves de regressió són un dels aspectes essencials, ja que ajuda a oferir un producte de qualitat que estalvia temps i diners a les organitzacions. Ajuda a proporcionar un producte de qualitat assegurant-se que qualsevol canvi en el codi no afecti la funcionalitat existent.
Per automatitzar els casos de prova de regressió, hi ha diverses eines d'automatització disponibles. Una eina hauria de tenir la capacitat d'actualitzar suite de proves ja que el vestit de prova de regressió s'ha d'actualitzar amb freqüència.