ContacteMarc d’Automatització de Testing (MAT)
El Marc d’Automatització de Testing (MAT) és un framework especialitzat en l’automatització de proves, dissenyat per a integrar-se fàcilment amb els fluxos de desenvolupament i desplegament tant del SIC+ com del SIC 3.0. El seu objectiu és garantir la qualitat del programari mitjançant l’execució automatitzada de proves en entorns preproductius, facilitant així la detecció precoç d’errors i la validació contínua de les aplicacions abans d’arribar a l’entorn productiu.
El MAT es basa en un enfocament modular i flexible, permetent als equips de desenvolupament definir i executar proves específiques per a les seves aplicacions. Cada tipus de prova, funcional, regressió, rendiment o api, tindrà associat un repositori específic que allotjarà el codi dels tests, així com els recursos necessaris per a la seva execució.
La documentació oficial del MAT pot trobar-se al Portal de Qualitat, en concret a la **Documentació Marc d’Automatització de Testing (MAT), on s’explica detalladament aquest framework desenvolupat per l’equip de Qualitat del CTTI.
Per a trobar informació sobre el desenvolupament de tests de Selenium, JMeter o Postman ha de consultar-se la documentació publicada per l’equip de qualitat. Qualsevol dubte referent al desenvolupament d’aquests tests, o la funcionalitat del propi framework MAT, ha de ser consultada a aquest equip. L’equip del SIC únicament és responsable de la integració amb el MAT, no del seu desenvolupament ni dubtes d’ús per part dels lots de manteniment d’aplicacions.
Per a la gestió i el control d’integració amb el MAT, s’ha implementat un orquestador al SIC+ que s’encarrega de coordinar l’execució de les proves en funció dels desplegaments realitzats dels components d’una aplicació. Aquest orquestador processa un arxiu de configuració (release.yml) que defineix quines proves s’han d’executar, en quin ordre i amb quins paràmetres.
Tipus de proves del MAT
El SIC+ s’integra amb el MAT per l’execució de 4 tipus de proves diferents: funcionals, regressió, rendiment i API. Cadascun d’aquests tipus de proves té el seu propi repositori i estructura de codi.
Proves funcionals
El repositori de proves funcionals s’utilitza per a validar el comportament esperat de l’aplicació en escenaris específics Functional Tests Template. Aquestes proves se centren en verificar que les funcionalitats implementades compleixen amb els requisits definits i s’executen correctament. L’eina utilitzada per a les proves és Selenium, la qual permet simular interaccions d’usuari amb l’aplicació web i verificar que els resultats són els esperats.
Aquest repositori conté el fitxer “release.yml” en l’arrel del repositori, que és l’encarregat de definir les proves que s’executaran per una release concreta de l’aplicació. Aquest fitxer segueix una estructura específica que permet orquestrar les proves de manera adequada.
El repositori, a més, compta amb tres branques principals, igual que la resta de repositoris del SIC+: develop, release i master. També inclou un conjunt de workflows de CI/CD que s’hauran d’usar seguint el GitFlow comú del SIC+ per al desenvolupament de les proves de Selenium.
Proves de regressió
El repositori de proves de regressió s’utilitza per a validar que els canvis realitzats en l’aplicació no introdueixen nous errors o afecten negativament les funcionalitats existents Regression Tests Template. Igual que les proves funcionals, s’utilitzen eines com Selenium per a simular interaccions d’usuari i verificar els resultats.
El repositori té les mateixes característiques que el de proves funcionals.
Proves de rendiment
El repositori de proves de rendiment s’utilitza per a avaluar el comportament de l’aplicació sota diferents càrregues i condicions Performance Tests Template. Aquestes proves permeten identificar colls d’ampolla, mesurar temps de resposta i garantir que l’aplicació pot assumir un determinat volum d’usuaris.
Aquestes proves s’executen amb l’eina JMeter, la qual permet simular múltiples usuaris i mesurar el rendiment de l’aplicació en diferents escenaris.
Aquest repositori, a diferència dels anteriors, només compta amb la branca master.
Proves d’API
El repositori de proves d’API s’utilitza per a validar el correcte funcionament de les interfícies de programació d’aplicacions (API) del sistema Api Tests Template. Aquestes proves es centren en verificar que les API responen correctament a les peticions i compleixen amb els contractes definits.
Aquestes proves s’executen amb l’eina Postman, que permet definir i executar proves sobre les API de manera senzilla i efectiva.
El repositori de proves de API, igual que el de proves de rendiment, només compta amb la branca master.
Estructura del orquestador (fitxer “release.yml”)
S’ha creat un fitxer d’orquestració anomenat “release.yml” que es troba en l’arrel del repositori de proves funcionals de cada aplicatiu. Aquest fitxer defineix les proves que s’executaran en una release concreta i segueix una estructura específica que permet orquestrar les proves de manera adequada.
En el següent codi es pot trobar el template del fitxer “release.yml” Test Funcionals release.yml template que s’ha creat per l’orquestador del MAT:
release-file:
version: 1.0.0
parameters:
global:
env_to_test: Preproduccio
jira_project_key: ''
jira_issue_key: ''
functional:
url_app: <myurlapp>
regression:
url_app: <myurlapp>
api:
app_name: <myappname>
elements:
- name: Infra
version: 1.0.0
repository: https://github.com/ctti-dev/<repository_name>
- name: Frontend
version: 1.0.0
repository: https://github.com/ctti-dev/<repository_name>
- name: Backend
version: 1.0.0
repository: https://github.com/ctti-dev/<repository_name>
tests:
- name: FunctionalTests
type: functional
url: https://github.com/ctti-dev/<app_code>.<comp_code>-<acronim>-functional-tests
branch: master
# - name: RegressionTests
# type: regression
# url: https://github.com/ctti-dev/<app_code>.<comp_code>-<acronim>-regression-tests
# branch: master
# - name: PerformanceTests
# type: performance
# url: https://github.com/ctti-dev/<app_code>.<comp_code>-<acronim>-performance-tests
# branch: master
# - name: ApiTests
# type: api
# url: https://github.com/ctti-dev/<app_code>.<comp_code>-<acronim>-api-tests
# branch: master
Aquest fitxer conté els següents blocs principals, que es detallaran en l’esquema de validació més endavant:
release-file: El bloc principal que engloba tota la configuració del orquestador.version: La versió del la release de l’aplicatiu.parameters: Un bloc que defineix els paràmetres globals i específics per a les proves funcionals, de regressió i de API.global: Paràmetres globals com l’entorn a provar i les claus de Jira.functional: Paràmetres específics per a les proves funcionals, com la URL de l’aplicació.regression: Paràmetres específics per a les proves de regressió, com la URL de l’aplicació.api: Paràmetres específics per a les proves de API, com el nom de l’aplicació.
elements: Un bloc que defineix els components de la release de l’aplicatiu en una llista.name: El nom del component.version: La versió del component en format semàntic.repository: La URL del repositori del component.
tests: Un bloc que defineix els tests que s’executaran en la release en una llista.name: El nom del test.type: El tipus de test (functional, regression, performance, api).url: La URL del repositori on es troben els tests.branch: La branca del repositori de tests on es defineixen els tests a executar.
A continuació, es mostra un exemple d’un fitxer “release.yml” que podria usar-se per a un aplicatiu amb codi 9999, codi de component 99 i acrònim “myapp”:
release-file:
version: 1.0.0
parameters:
global:
env_to_test: Preproduccio
jira_project_key: ''
jira_issue_key: ''
functional:
url_app: https://preproduccio.myapp.intranet.gencat.cat/
regression:
url_app: https://preproduccio.myapp.intranet.gencat.cat/
# api:
# app_name: myapp
elements:
- name: Infra
version: 1.0.32
repository: https://github.com/ctti-dev/9999.99-myapp-infra
- name: Frontend
version: 2.2.15
repository: https://github.com/ctti-dev/9999.99-myapp-example-frontend
- name: Backend
version: 1.10.0
repository: https://github.com/ctti-dev/9999.99-myapp-example-backend
tests:
- name: FunctionalTests
type: functional
url: https://github.com/ctti-dev/9999.99-myapp-functional-tests
branch: master
- name: RegressionTests
type: regression
url: https://github.com/ctti-dev/9999.99-myapp-regression-tests
branch: master
# - name: PerformanceTests
# type: performance
# url: https://github.com/ctti-dev/9999.99-myapp-performance-tests
# branch: master
# - name: ApiTests
# type: api
# url: https://github.com/ctti-dev/9999.99-myapp-api-tests
# branch: master
En el cas que algun test o element estigui comentat, o no vingui informat, s’ometrà l’execució d’aquest tipus de prova o no es comprovarà el desplegament d’aquest component a l’entorn de preproducció. Això permet una gran flexibilitat en la configuració de les proves a executar, adaptant-se a les necessitats específiques de cada release.
Integració amb el MAT en els workflows de CD
S’han afegit diversos steps als workflows de CD de contenidors, funcions, contingut estàtic i infra per a poder executar les proves del MAT:
- Obtain test repository names: obté els noms dels repositoris de proves.
- Checkout auxiliary repository: clona el repositori de tests funcionals per a obtenir l’arxiu
release.yml. - MAT Orquestrator Proccessing: crida l’action del orquestrador.
- MAT Functional Tests - Selenium: crida a l’action del MAT passant-li els paràmetres necessaris per als tests funcionals construïts a l’action del orquestrador.
- MAT Regression Tests - Selenium: crida a l’action del MAT passant-li els paràmetres necessaris per als tests de regressió construïts a l’action del orquestrador.
- MAT API Tests - Postman: crida a l’action del MAT passant-li els paràmetres necessaris per als tests de api construïts a l’action del orquestrador.
- MAT Performance Tests - JMeter: crida a l’action del MAT passant-li els paràmetres necessaris per als tests de performance construïts a l’action del orquestrador.
Esquema de validació
{
"type": "object",
"properties": {
"release-file": {
"type": "object",
"properties": {
"version": {
"type": "string",
"pattern": "^\\d+\\.\\d+\\.\\d+$"
},
"parameters": {
"type": "object",
"properties": {
"global": {
"type": "object",
"properties": {
"env_to_test": {
"type": "string",
"enum": ["Desenvolupament", "Preproduccio", "Produccio"]
},
"jira_project_key": {"type": "string"},
"jira_issue_key": {"type": "string"}
},
"required": ["env_to_test"]
},
"functional": {
"type": "object",
"properties": {
"url_app": {"type": "string", "format": "uri"}
},
"required": ["url_app"]
},
"regression": {
"type": "object",
"properties": {
"url_app": {"type": "string", "format": "uri"}
},
"required": ["url_app"]
},
"api": {
"type": "object",
"properties": {
"app_name": {"type": "string"}
},
"required": ["app_name"]
}
},
"required": ["global", "functional"]
},
"elements": {
"type": "array",
"items": {
"type": "object",
"properties": {
"name": {"type": "string"},
"version": {
"type": "string",
"pattern": "^\\d+\\.\\d+\\.\\d+$"
},
"repository": {"type": "string", "format": "uri"}
},
"required": ["name", "version", "repository"]
},
"minItems": 1
},
"tests": {
"type": "array",
"items": {
"type": "object",
"properties": {
"name": {"type": "string"},
"type": {
"type": "string",
"enum": ["functional", "regression", "performance", "api"]
},
"url": {"type": "string", "format": "uri"},
"branch": {"type": "string"}
},
"required": ["name", "type", "url"]
},
"minItems": 1,
"contains": {
"type": "object",
"properties": {
"type": {"const": "functional"}
},
"required": ["type"]
}
}
},
"required": ["version", "parameters", "elements", "tests"]
}
},
"required": ["release-file"]
}
Estructura del schema.json
-
Objecte arrel:
- Propietat principal: “release-file” (tipus object), que engloba tota la configuració.
-
Dins de release-file:
-
version: Tipus: string Patró: SemVer (^\d+\.\d+\.\d+$)
-
parameters: Tipus: object Propietats:
- global:
Tipus: object
Propietats:
- env_to_test: string, valors permesos(s’especifiquen amb la propietat enum): Desenvolupament, Preproduccio, Produccio
- jira_project_key: string
- jira_issue_key: string
Requerit: env_to_test
- functional, regression, api: Cadascun és un objecte amb els seus propis paràmetres requerits (per exemple, url_app per a functional i regression, app_name per a api)
- global:
Tipus: object
Propietats:
Requerit: global, functional
-
elements: Tipus: array Cada element:
- name: string
- version: string (SemVer)
- repository: string (format URI)
Mínim 1 element
-
tests: Tipus: array Cada test:
- name: string
- type: string, valors permesos(s’especifiquen amb la propietat enum): functional, regression, performance, api
- url: string (format URI)
- branch: string
Ha de contenir almenys un test de tipus functional
-
Requerit en release-file:
- version, parameters, elements, tests
Requerit en arrel:
- release-file
Processament del fitxer d’orquestració (“release.yml”)
L’action processa l’arxiu release.yml per a obtenir els paràmetres necessaris de cada test. Es realitza una validació per a comprovar que tots els components definits en el bloc elements han estat desplegats prèviament abans d’executar qualsevol de les tipologies de tests especificades en el fitxer.
Es valida l’existència de tags en els repositoris dels components definits en el bloc elements del release.yml. L’existència d’aquests tags significa que els components han estat desplegats correctament en els entorns corresponents en cada procés individual de CD del component. Si algun tag requerit no existeix, fet que significa que el component en concret no ha estat desplegat en PREPRODUCCIÓ, i no està sent desplegat en el workflow en curs, es deshabilita la integració amb el MAT per al workflow, per la qual cosa s’ometen tots els passos relacionats amb el MAT encara que estiguin definits en el orquestrador.
També es defineixen els paràmetres necessaris per a cada test com a variables d’entorn en format JSON, recol·lectant la informació dels tests definits en el fitxer del orquestrador en conjunció als paràmetres específics de cada test, amb noms com FUNCTIONAL_TESTS_PARAMS, REGRESSION_TESTS_PARAMS, etc., perquè puguin ser usats en els següents steps del workflow.