MAT - Marc d’Automatització de Testing

El MAT és un framework d'automatització de proves dissenyat per garantir la qualitat de les aplicacions del Centre de Telecomunicacions i Tecnologies de la Informació. Funciona mitjançant diferents desencadenants, com la realització d'un pull request o l'execució sota demanda, assegurant un control de qualitat durant tot el cicle de vida del programari.

Aquest marc permet implementar un procés de proves estructurat i escalable, ajudant a millorar la qualitat de les aplicacions mitjançant tècniques avançades de validació. L’objectiu principal del MAT és assegurar que les interfícies siguin intuïtives, estables, segures i compatibles amb diversos dispositius, garantint així una experiència d’usuari òptima.

El MAT proporciona plantilles de treball que estableixen estàndards mínims de qualitat, assegurant una execució de proves homogènia i eficient. Aquest enfocament permet als equips de desenvolupament realitzar proves en un entorn flexible i adaptable a les seves necessitats, eliminant limitacions tècniques i promovent la millora contínua.

Un dels elements clau del MAT és la seva capacitat d’Integració Contínua, que facilita l'execució de proves automàtiques mitjançant eines com Jenkins o Jira, proporcionant feedback constant durant tot el procés. A més, incorpora un sistema de monitoratge per detectar i gestionar incidències en temps real, millorant així la resposta i la qualitat global del programari.

La Integració Contínua del MAT és fonamental per al desenvolupament del producte. Permet la realització de proves automàtiques mitjançant diferents eines de gestió de projecte com Jira, per tal de rebre un feedback continu en el moment de l'execució.

Propòsits i Objectius

El principal objectiu del MAT és millorar la qualitat de les aplicacions, garantint que:

• Les interfícies siguin intuïtives, estables i segures.
• Hi hagi compatibilitat amb diversos dispositius.
• Es proporcioni un suport adequat als usuaris.

Per assolir aquest objectiu, el MAT defineix diferents tipus de proves en el cicle de vida del producte mitjançant plantilles de treball estandarditzades.

2. Alta a les eines

Per integrar-se correctament amb el MAT, cal disposar d'accés a les eines necessàries i complir alguns requisits bàsics per garantir un procés fluid i sense errors. Aquest procés permet una configuració òptima per a l'execució de proves automatitzades i la gestió del cicle de vida del programari.

Requisits previs

• Accés als repositoris de codi: L’usuari ha de tenir els permisos necessaris per treballar amb el codi font i les proves.
• Eines de gestió de projectes: Es recomana utilitzar plataformes com Jira per gestionar proves.

En cas de no disposar d’accés, les heu de tramitar des de:

Eina	Sol·licitud a
Repositoris de Codi	Via ticket ACOCLDSIC
Projecte a Jira	Podeu trobar informació per la creació i configuració de projectes Jira al web Alta i accés

Presentem el cas d'ús end-to-end, en cas de no disposar de Jira, i sí estar integrats al SIC+ podeu passar directament a l’execució als Workflows de Github Enterprise.

3. Detall Prova en Jira

El nom del projecte de Jira i el nombre d'Issue creat per al Pla de Proves s'utilitzaran més endavant per a l'execució del Workflow a GitHub.

Jira és una eina clau per a la gestió i traçabilitat de les proves automatitzades dins del MAT. Permet gestionar i documentar els casos de prova, planificar-ne l'execució i integrar els resultats amb altres eines de desenvolupament.

Configuració d’un projecte de proves en Jira

• Creació del projecte Jira: Si el projecte encara no està configurat, cal crear un espai dedicat a la gestió de proves.
• Definició d’un Pla de Proves: Crear un Issue per a cada conjunt de proves que es vol executar.
• Utilització de XRay: Aquest complement de Jira permet gestionar casos de prova, executar-los i emmagatzemar els resultats.
• Integració amb GitHub o CI/CD: Els resultats de les proves poden ser sincronitzats amb GitHub Actions o Jenkins per automatitzar-ne l'execució.

Execució i seguiment de les proves

• Cada prova es documenta dins de Jira, permetent una traçabilitat completa.
• Els casos de prova es poden agrupar en plans de proves per facilitar la seva execució ordenada.
• Els resultats de les proves són accessibles directament a Jira, amb la possibilitat d'afegir captures de pantalla i logs.
• En cas de fallada, Jira permet obrir històries d’usuari automàticament per al seu seguiment i resolució.

Beneficis d'usar Jira per a la gestió de proves

• Centralització de la informació: Tots els casos de prova i resultats es troben en una única plataforma.
• Traçabilitat completa: Integració amb altres eines per relacionar proves amb desenvolupament i desplegaments.
• Automatització i monitoratge: Possibilitat d’integrar-se amb GitHub Actions, Jenkins o altres eines per a l'execució automatitzada de proves.
• Generació d'informes: Els informes de proves es poden generar automàticament per facilitar l'anàlisi i la presa de decisions.

Si no es disposa de Jira, es pot executar directament a través de GitHub Workflows.

Descripció gràfica:

Després s'obre la finestra per emplenar les dades del pla de proves

Primer crearem el pla de proves (Test Plan).

Després crearem les diferents proves i les descriurem, per tal de que es connectin directament amb el MAT, el tipus de prova ha de ser Generic

4.- Creació de proves automatitzades

Per començar amb l’automatització de proves, és imprescindible que els testers disposin dels repositoris adequats amb les plantilles preconfigurades. Per això, han de sol·licitar l’aprovisionament dels repositoris de proves, els quals contenen els recursos necessaris, incloent-hi exemples pràctics i documentació detallada sobre l’ús de les plantilles. Aquest pas és fonamental per garantir la coherència i l’eficiència en la creació i execució de les proves automatitzades.

Un cop obtingut l’accés als repositoris, les proves es desenvolupen a l’entorn local del tester, utilitzant la plantilla proporcionada pel MAT (Marc d’Automatització de Testing). Aquesta plantilla proporciona una estructura estàndard per a les proves, assegurant que cada cas de prova inclogui:

• El propòsit de la prova, descrivint què es vol validar.
• Els passos a seguir per executar la prova de manera sistemàtica.
• Les dades d’entrada necessàries, com inputs de formularis o paràmetres d’API.
• Els resultats esperats, per verificar que el sistema respon correctament.
• Altres detalls rellevants, com precondicions o dependències.

Tipus de proves automatitzades

Les proves automatitzades poden abordar diferents aspectes del sistema, com ara:

• Proves de Frontend: Validen la interfície d’usuari, assegurant que funcioni correctament en diferents navegadors i dispositius.
• Proves d’APIs: Comproven la comunicació entre serveis, verificant que les peticions i respostes siguin correctes.
• Proves de Rendiment: Avaluen la capacitat de resposta del sistema en diferents condicions de càrrega per detectar possibles colls d’ampolla.

És fonamental seguir les instruccions de la documentació per configurar l’entorn correctament i assegurar que les proves es desenvolupin segons els requisits establerts.

Integració i validació de proves

Un cop desenvolupades les proves a l’entorn local, cal validar-les abans de la seva integració. Això es fa mitjançant un pull request al repositori de proves, que desencadena automàticament un flux de verificació. Aquest procés és essencial per assegurar que:

• Les proves compleixen els estàndards de qualitat definits.
• No introdueixen errors en el sistema.
• Totes les modificacions són revisades i validades abans de fusionar-se a la branca principal.

Quan es fa el pull request al repositori de proves, s’executa un conjunt de validacions automàtiques. Els resultats d’aquestes validacions es poden consultar directament al pull request, facilitant la detecció de possibles errors abans que el codi es fusioni. Aquesta pràctica és fonamental per garantir un codi estable i fiable abans de desplegar-lo a producció.

Bones pràctiques per a una integració eficient

Per mantenir un flux de treball ordenat i eficient, és recomanable seguir aquestes bones pràctiques:

• Crear branques específiques per a cada funcionalitat o correcció de bugs.
• Utilitzar noms descriptius per a les branques, facilitant la seva identificació.
• Fer commits freqüents i ben documentats, explicant els canvis realitzats.
• Revisar els resultats de les proves automàtiques abans de fusionar el codi.

Aquest enfocament permet identificar i corregir problemes de manera primerenca, reduint el risc d’introduir errors en la branca principal.

Contribució a la qualitat del programari

Amb aquest procés, els testers tenen un paper clau en la garantia de qualitat del programari. Seguint un enfocament estructurat en la creació i execució de proves automatitzades, es minimitzen errors i es millora la fiabilitat del sistema. Això assegura que el producte final compleixi els estàndards esperats abans d’arribar als usuaris finals.

5. Repositori

El MAT està dissenyat específicament per integrar-se amb el SIC+ i el SIC3, aprofitant les seves característiques per garantir una automatització de proves eficient i alineada amb l'entorn tecnològic. Això permet validar el funcionament del programari de manera contínua, seguint les millors pràctiques d'integració i execució de proves.
A més de la integració automàtica en els fluxos de treball establerts, el MAT també permet l'execució sota demanda mitjançant Jira. Això ofereix als equips de desenvolupament i qualitat la flexibilitat de llançar proves quan sigui necessari, facilitant la validació de canvis abans del seu desplegament.

6. Execució de proves a GitHub Actions

Aquest pas és opcional, podrà executar el seu flux de treball manualment omplint els camps requerits per dur a terme les verificacions que consideri necessàries.

Amb les proves llestes i validades, les podrem executar sota demanda a través de GitHub omplint els paràmetres requerits en el Flux de GitHub Actions, que es proporciona amb la plantilla de repositori.

Cicle de vida de les proves a través de Pull Request

Haurà de tenir en consideració la política de branques aplicable al seu repositori.

Per garantir una integració correcta i la verificació del codi de les proves, abans de posar-les en producció, el flux de treball s'activarà automàticament després de fer un pull request al repositori de proves. Aquesta pràctica assegura que totes les modificacions proposades siguin revisades i validades abans de fusionar-les a la branca principal, evitant així la introducció d'errors al sistema.

Procés per arribar al pull request

1. Desenvolupament local: Primer, el tester ha de dissenyar la prova en el seu entorn local.
2. Verificació inicial: Un cop comprovat que la prova retorna el resultat esperat, es puja al repositori de proves.
3. Validació en branques de desenvolupament: Abans d'incorporar la prova a la branca principal, es recomana pujar-la a una branca de desenvolupament específica per fer una primera revisió interna.
4. Pull request al repositori de proves: Quan la prova està llesta, es fa un pull request al repositori de proves, activant automàticament el flux de verificació.

Execució i validació de proves

Abans de fusionar el codi a la branca principal, també és possible executar manualment les proves des de les accions del repositori, referenciant la branca corresponent. Això permet als testers assegurar que la integració amb el MAT, SIC+ i SIC3 és correcta i que les proves es comporten segons els requeriments establerts.

Bones pràctiques per garantir la qualitat

Per mantenir una integració controlada i evitar problemes en la branca principal, es recomana seguir aquestes bones pràctiques:

• Utilitzar una política de branques clara, creant branques específiques per cada funcionalitat o correcció de bugs.
• Fer commits freqüents i ben documentats, explicant cada canvi realitzat.
• Executar les proves manualment abans del pull request, si és necessari, per detectar errors abans que passin a la validació automàtica.

Quan es realitza el pull request al repositori de proves, s'executa automàticament un flux de verificació que comprova que el codi compleix els estàndards de qualitat i no introdueix errors. Aquesta validació permet detectar i corregir problemes de manera precoç, abans que puguin afectar altres parts del sistema.

Abans de fer el merge, aquest flux de verificació s'executa immediatament i el seu resultat es pot consultar dins del mateix pull request per verificar l’estat de les proves. Això proporciona un control addicional i permet assegurar que només es fusiona codi fiable a la branca principal.

Una vegada validada i acceptada la petició de Pull Request i executat el Merge, ja tindrem les proves llestes per executar-les.

7. Visualització de resultats

Un cop executat el flux de treball, podrà visualitzar als registres de GitHub tota la informació respecte de la prova en curs. Aquests registres proporcionen detalls exhaustius sobre l'execució de les proves, incloent-hi els resultats, els errors trobats i qualsevol altra informació rellevant. A més, una de les grans avantatges de la generació d'informes de proves amb Selenium en format HTML és la seva claredat i facilitat de lectura. Aquests informes són visuals i interactius, permetent una ràpida identificació de problemes i una millor comprensió dels resultats de les proves.

Després d'executar el flux de treball a través d'un pull request, els informes generats es poden trobar fàcilment a Jira gràcies a la integració entre GitHub i Jira. Aquesta integració permet que els resultats de les proves i els informes HTML es sincronitzin automàticament amb les tasques corresponents a Jira, facilitant així el seguiment i la gestió de les proves. Verificar l'estatus de la prova realitzada a Jira és senzill, ja que tota la informació es troba centralitzada i accessible des d'una única plataforma.

A més, l'informe .HTML generat proporciona una visió completa i detallada de les proves realitzades, incloent-hi captures de pantalla, logs d'execució i altres dades importants que ajuden a diagnosticar i solucionar problemes de manera eficient. Aquesta documentació detallada és essencial per assegurar que totes les parts interessades tinguin una comprensió clara de l'estat de les proves i dels resultats obtinguts. La visualització de resultats a través dels registres de GitHub i els informes HTML a Jira ofereix una solució completa i eficient per al seguiment i la gestió de les proves automatitzades.

Guia per a l'Estructuració de Proves Automatitzades

Per dur a terme el que s'ha vist anteriorment, el Tester haurà d'estructurar les seves proves automatitzades, per a la qual cosa hem facilitat una plantilla que resumeix funcionalitats rellevants de manera que li sigui més pràctic la construcció i execució de les seves proves.

Proves Funcionals:

Aquestes proves es centren en validar la funcionalitat de l'aplicació des de la perspectiva de l'usuari, simulant interaccions reals de l'usuari, com fer clic en botons, omplir formularis i navegar per diferents pàgines.

Selenium permet crear scripts que emulen accions humanes, la qual cosa garanteix que l'aplicació compleixi amb els requisits funcionals i que es mantingui estable davant possibles canvis o actualitzacions.

En el següent manual, podeu executar proves funcionals de Selenium, a través de Selenium Grid, una eina que permet orquestrar i escalar els navegadors.

Per tal de desenvolupar les proves, hem preparat un manual que podeu trobar aquí:

Execució de la prova des de Jira:

Els proveïdors podran executar les proves directament des del pla de proves de Jira.

Dades necessàries per a l'execució

• Repositori de codi font: URL on estan allotjades les proves funcionals.
• Entorn: Entorns per a fer les proves.
• Branca: Branca del repositori de proves.
• URL de l'aplicació: URL de l'aplicació.
• Llindar de QG: Límit de fallades de les proves.
• JIRA_PROJECT_KEY: Project Key de Jira.
• JIRA_ISSUE_KEY: Test Plan Key de Jira.

Accedir al pla de proves en Jira:

En Jira es poden veure els resultats dins del:

• Pla de proves: dins del Pla de proves, es poden veure els adjunts de l'execució.

El report de les proves funcionals és un document .HTML que prové de la llibreria Extent Report.


• Test: dins del test, es poden veure les execucions associades a aquest Tests.

En aquestes execucions es pot veure l'estat del test.



També es pot veure l'estat general del projecte en els taulers:

Proves d’API

Les proves de REST API consisteixen a enviar peticions a un conjunt d’APIs, per tal d'observar-les i monitorar les respostes per a assegurar-se que funcionen de la forma que s'espera. Les API (Interfícies de Programació d'Aplicacions) són una col·lecció de mètodes i funcions que permeten desenvolupar aplicacions. Funcionen com a missatgers entre les persones i el proveïdor de serveis, rebent les peticions i responent amb un resultat. Per tant, les proves d’API es concentren principalment en la funcionalitat d'una aplicació més que en cadascuna de les seves parts o com es mostren a un usuari.

Eines per a les proves

En el següent manual, podeu executar proves d’API a través de Postman i Newman (CLI per a Postman).

Resultats de les proves

Els resultats de les proves seran bolcats al quadre de comandament de Grafana, per mitjà de InfluxDB. A més, els resultats seran també bolcats a Jira (amb el plugin de XRay).

Desenvolupament

Podeu trobar el procés de creació de les proves d’API aquí.

Instal·lació:

És possible usar Postman en la seva versió web o en aplicació d'escriptori.

Per a més informació acudir a la guia oficial: Install and update Postman | Postman Docs

Haurem d’instalar Newman per tal d’executar les proves de Postman via consola

• Instal·lar Node.js.
• Instal·lar Newman.
npm install -g newman
• Instal·lar paquet per a reportar els resultats a Influxdb.
npm install -g newman-reporter-influxdb
• Instal·lar paquet per a reportar els resultats a Jira amb XRay.
npm install -g newman-reporter-junitxray

Creació de proves:

1. Utilitzar la plantilla de proves proporcionada al repositori de proves d’api.
2. Crear les proves en el següent fitxer: backend-test-java/<app_name>-backend-postman.json
3. Exportar des de Postman el fitxer de les variables d'entorn en: environment.json

Els fitxers de <app_name>-backend-postman.json i de environment.json seran creats i exportats des de Postman directament.

Execució de proves:

Per a executar les proves, s'utilitzarà Newman, una extensió de Postman que permet executar per línia de comandos.

                    newman run -backend-postman.json -e environment.json 
                      -r 'cli,junitxray,htmlextra'  
                      --reporter-htmlextra-export 'newman/report.html' 
                      --reporter-junitxray-export postman_echo_junitxray.xml 
                      -n 1
                  

-n 1: defineix el nombre de vegades que s'executarà la col·lecció.

MAT:

Execució del job des de Jira:

Els proveïdors podran executar les proves directament des del pla de proves de Jira, ja que està connectat amb el Job de Jenkins.

Aquests són les dades necessàries per a aquesta execució:

• Job de Jenkins: MAT-PROVES-API-POSTMAN
• Paràmetres:
• repositori = ... URL on estan allotjades les proves funcionals.
• branca = ... Branca del repositori de proves.
• app_name= ... nom de l'aplicació.
• entorn = ... Entorns per a fer les proves.

Accedir al pla de proves en Jira

Resultats:

En Jira es poden veure els resultats dins del:

• Pla de proves: dins del Pla de proves, es poden veure els adjunts de l'execució.

El report de les proves de API és un document .html que prové de Newman Reporter.


• Test:

Proves de Rendiment

Accedir al pla de proves en Jira: