Embed Size (px)
Citation preview
Equation Chapter 1 Section 1
Departamento de Ingenieriacutea Electroacutenica
Escuela Teacutecnica Superior de Ingenieriacutea
Universidad de Sevilla
Sevilla 2020
Autor Francisco Joseacute Diacuteaz Romero
Tutores Pablo Aguilera Bonet
Daniel Gutieacuterrez Reina
Trabajo de Fin de Maacutester
Master en Ingenieriacutea de Telecomunicacion
Testeo automatizado de una plataforma Web de
gestioacuten Galgus CHT Manager
2
3
Trabajo de Fin de Maacutester
Maacutester en Ingenieriacutea de Telecomunicacioacuten
Testeo automatizado de una plataforma Web de
gestioacuten Galgus CHT Manager
Autor
Francisco Joseacute Diacuteaz Romero
Tutores
Pablo Aguilera Bonet
Daniel Gutieacuterrez Reina
Doctor Ingeniero en Electroacutenica
Escuela Teacutecnica Superior de Ingenieriacutea
Universidad de Sevilla
Sevilla 2020
4
5
Trabajo de Fin de Maacutester Testeo automatizado de una plataforma Web de gestioacuten
Galgus CHT Manager
Autor Francisco Joseacute Diacuteaz Romero
Tutor Pablo Aguilera Bonet
Daniel Gutieacuterrez Reina
El tribunal nombrado para juzgar el Proyecto arriba indicado compuesto por los siguientes miembros
Presidente
Vocales
Secretario
Acuerdan otorgarle la calificacioacuten de
Sevilla 2020
El Secretario del Tribunal
6
7
A mi familia
A mis maestros
A mis amigos
8
9
Agradecimientos
10
11
Resumen
La revolucioacuten tecnoloacutegica que vivimos hoy diacutea enfocada principalmente en el mundo de Internet y aplicaciones
Web estaacute permitiendo que todas las herramientas que tenemos a nuestro alrededor se encuentren en un proceso
de tremenda evolucioacuten y cambio continuo
En este proyecto se ha realizado un estudio del arte sobre una teacutecnica que permite mejorar el proceso de
automatizacioacuten de pruebas sobre una aplicacioacuten Web basaacutendose en el modelado de la aplicacioacuten para
proporcionar una abstraccioacuten en la implementacioacuten de las pruebas Tambiacuteeacuten se ha realizado una revisioacuten de los
diferentes modelos de calidad normativas y tipos de prueba de Software Finalmente se ha desarrollado una
herramienta de test comprendida por un conjunto de pruebas de aceptacioacuten automaacuteticas que permiten la
verificacioacuten y validacioacuten de la funcionalidad de la plataforma Web Galgus CHT Cloud Manager
Galgus CHT Cloud Manager es la plataforma Web distribuida ofrecida por Galgus para la gestioacuten de redes
compuestas por puntos de acceso Wifi Estas redes se encuentran instaladas en los diferentes clientes que hacen
uso de los servicios que ofrece Galgus los cuales se basan en la optimizacioacuten del rendimiento y las prestaciones
de las redes Wifi en entornos de alta densidad de usuarios Esto se consigue mediante un software embebido
patentado por Galgus conocido bajo el nombre de Cognitive Hostpot Technology (CHT) el cual es instalado
en los puntos de acceso Dicho software implementa un conjunto de algoritmos y caracteriacutescas colaborativas
para conseguir los objetivos planteados en redes Wifi
Como resultado del trabjo podemos proporcionar a los ingenieros de pruebas una herramienta con la que poder
automatizar el testeo de una plataforma Web De esta forma se consigue agilizar el proceso de pruebas y reducir
costes y esfuerzos en tareas repetitivas que anteriormente se haciacutean de forma manual
12
13
Abstract
The technological revolution we are living today focused mainly on the Internet world and therewith the Web
applications is allowing all the tools we have around us to be in a process of continuous evolution and change
In this project we have made a study of the art on a technique that allows to improve the process of automation
of testing on a Web application based on the modelling of the application to provide an abstraction in the
implementation of testing A review of the different quality models standards and types of software testing has
also been carried out Finally a tool comprised of a set of automated acceptance tests has been developed to
allow verification and validation of the functionality of the Galgus CHT Cloud Manager Web platform
Galgus CHT Cloud Manager is the distributed web platform offered by Galgus for the management of
networks composed by Wifi access points These networks are installed in the different clients that make
use of the services offered by Galgus which are based on the optimization of the performance and features
of Wifi networks in high user density environments This is achieved through an embedded software
patented by Galgus known as Cognitive Hostpot Technology (CHT) which is installed in the access points
This software implements a set of algorithms and collaborative features to achieve the objectives set in Wifi
networks
This allows us to provide quality assurance engineers with a tool to automate the testing of a Web platform In
this way the testing process is streamlined and costs and efforts are reduced in repetitive tasks that previously
used to be done manually
14
15
Iacutendice
Agradecimientos 9
Resumen 11
Abstract 13
Iacutendice 15
Iacutendice de Figuras 19
Glosario 24
1 Introduccioacuten 27 11 Motivacioacuten 28 12 Alcance y Objetivos 29 13 Estructura de la memoria 30
2 Estudio del Arte y Revisioacuten 32 21 Model Based Testing (MBT) 32
211 Introduccioacuten 32 212 iquestQueacute es Model Based Testing 33 213 iquestCoacutemo funciona Model Based Testing 33 214 Consideraciones para la aplicacioacuten de Model Based Testing (MBT) 36 215 Beneficios de Model Based Testing (MBT) 37 216 Problemas y Limitaciones de Model Based Testing (MBT) 38 217 Cuando elegir Model Based Testing (MBT) 38
22 Gestioacuten de Calidad Software 39 221 Introduccioacuten 39 222 Concepto de Calidad 39 223 Modelos de Calidad de Software 40 224 Principales Ventajas e Inconvenientes de Modelos de Calidad anteriores 44 225 Conclusiones 44
3 Marco Teoacuterico Pruebas de Software 46 31 Testing y Pruebas de Software 46 32 Principios de las Pruebas de Software 47 33 Proceso de Pruebas de Software Anaacutelisis disentildeo e implementacioacuten 48
331 Terminologiacutea 48 332 Proceso de Pruebas de Software 49
34 Clasificacioacuten de Pruebas de Software 51 341 Pruebas Funcionales 51 342 Pruebas No Funcionales 52 343 Pruebas Estructurales 54 344 Pruebas debidas a Cambios 54
35 Niveles de Prueba 54 351 Pruebas a Nivel de Componente 55 352 Pruebas a Nivel de Integracioacuten 55 353 Pruebas a Nivel de Aceptacioacuten 55
16
36 Dificultades de pruebas en aplicaciones Web e impacto 56
4 Sistema Galgus CHT Cloud Manager 58 41 Arquitectura y Descripcioacuten del Sistema 58
411 Puntos de Acceso (OpenWRT + CHT) 60 412 Broacuteker de Eventos AMQP (RabbitMQ) 61 413 Frontend 62 414 Zone Manager 62 415 MoMap 63 416 Servidor de Licencias 64
42 Alcance y Objetivos de las pruebas sobre el sistema planteado 65 43 Arquitectura de la Solucioacuten Entorno de UAT para el proceso de pruebas (User Acceptance Test) 67
5 Tecnologiacuteas y Herramientas Usadas 69 51 Selenium 69 52 Selenium WebDriver 70
521 Elementos del Navegador 70 53 Robot Framework (RF) 72
531 Estilo de representacioacuten Given-When-Then 72 532 Reportes 75 533 Libreriacuteas 76 534 Documentacioacuten 77
54 Pycharm (IDE) 78 55 GitGitlab 78
551 Git 78 552 Gitlab 78
56 Redmine 78 561 Uso en el Proyecto Galgus CHT Cloud Manager (Metodologiacutea Scrum) 79
6 Experimentos 82 61 Estructura del Proyecto 83 62 Vista de Gestioacuten Principal (Cloud Tab) 87
621 Administration 87 622 List 89 623 Manufacturer 90 624 MAP 92
63 Vista de Configuracioacuten (Configuration Tab) 95 631 Groups 95 632 CHT Zones 98 633 BackupRestore 100 634 Firmware 101
64 Vista de Red (Network Tab) 104 641 VLANS amp Bridges 104 642 SSIDs 106 643 CHT 108 644 Radius 110 645 Captive Portal 112 646 General 115 647 AP Network 117
7 Lineas de Mejora y Conclusiones 122 71 Liacuteneas de Mejora Futuras 122 72 Conclusiones Finales 123
Referencias 126
17
Anexo A Preparacioacuten del Entorno de Trabajo y Ejecucioacuten de Pruebas 128 A1 Preparacioacuten del entorno de trabajo 128
A11 Pip 128 A12 Virtualenv Entorno Virtual 128 A13 Selenium y Chromedriver 129 A14 Robot Framework y SeleniumLibrary 129 A15 Otras dependencias 130
A2 Ejecucioacuten de Pruebas 130 A3 Script de Prueba U007 (MAP) 132
Anexo B Docker de Robot Framework y Entorno de UAT Dockerizado 136 B1 Docker de Robot Framework 136 B2 Entorno de UAT Dockerizado 137
Anexo C Revisioacuten de Reportes y Logs 140 C1 Reporte de Logs ofrecido por Robot Framework 140 C2 Cloud Tab 140
C21 Administration 140 C22 List 142 C23 Manufacturers 143 C24 MAP 144
C3 Configuration Tab 145 C31 BackupRestore 145 C32 CHT Zones 146 C33 Firmware 147 C34 Groups 148
C4 Network Tab 150 C41 General 150 C42 SSID 151 C43 CHT 151 C44 VLAN 152 C45 Radius 153 C46 Captive Portal 154 C47 AP Network 155
Anexo D Diagrama de Gantt 157
18
19
IacuteNDICE DE FIGURAS
Figura 1 Fuente de datos Morgan Stanley 27
Figura 2 Manual Testing vs Automated Testing [20] 28
Figura 3 Fase de Pruebas y Validacioacuten 32
Figura 4 Esquema baacutesico de Model Based Testing 33
Figura 5 Proceso detallado de Model Based Testing (MBT) 34
Figura 6 Construccioacuten del Modelo 34
Figura 7 Concepto de Calidad 39
Figura 8 Liacutenea de tiempo de modelos a nivel de proceso 40
Figura 9 Logo de ITIL 40
Figura 10 ISOIEC 20000 41
Figura 11 Logo de WebQEM 41
Figura 12 Liacutenea de tiempo de modelos a nivel de producto 42
Figura 13 Esquema de ISO 9126 42
Figura 14 Esquema de ISOIEC 25000 43
Figura 15 Principios de las Pruebas de Software 47
Figura 16 Terminologiacutea para el proceso de pruebas 48
Figura 17 Proceso de Pruebas de Software 49
Figura 18 Clasificacioacuten de Pruebas de Software 51
Figura 19 Pruebas de Caja Negra 51
Figura 20 Pruebas de Rendimiento 52
Figura 21 Pruebas de Carga 52
Figura 22 Pruebas de Estreacutes 52
Figura 23 Pruebas de Usabilidad 53
Figura 24 Pruebas de Portabilidad 53
Figura 25 Pruebas de Caja Blanca 54
Figura 26 Modelo de desarrollo en V 55
Figura 27 Dificultades de pruebas en aplicaciones Web e impacto 56
Figura 28 Logo de Galgus 58
Figura 29 Arquitectura de CHT Cloud Manager 59
Figura 30 CHT_CLI 60
Figura 31 Plataforma de Gestioacuten de RabbitMQ 61
Figura 32 Patroacuten PublicadorSuscriptor 61
Figura 33 Ejemplo de Interfaz Graacutefica de un Zone Manager 62
Figura 34 Ejemplo de Interfaz Graacutefica de MoMap 63
20
Figura 35 Interfaz Graacutefica del Servidor de Licencias 64
Figura 36 Zero-Touch Provisioning (ZTP) 64
Figura 37 Test Plan de CHT Cloud Manager 65
Figura 38 Leyenda del Test Plan 66
Figura 39 Control de Versiones del Test Plan 66
Figura 40 Entorno de UAT con Docker (Anexo B) 67
Figura 41 Implementaciones disponibles de Selenium y Navegadores Web Compatibles 70
Figura 42 Coacutedigo de ejemplo con Python y Selenium 71
Figura 43 Estilo de representacioacuten Given-When-Then 72
Figura 44 Implementacioacuten de Pruebas en para el inicio de sesioacuten de CHT Cloud Manager 74
Figura 45 Ejemplo de reporte de pruebas automatizadas con Robot Framework 75
Figura 46 Ejemplo de documentacioacuten generada con Libdoc 77
Figura 47 Ejemplo de documentacioacuten generada con Testdoc 77
Figura 48 Ejemplo de Flujo de Trabajo en Redmine para Galgus CHT Cloud Manager 79
Figura 49 Esquema Graacutefico de Metodologiacutea Scrum 79
Figura 50 Logo de Galgus CHT Cloud Manager 82
Figura 51 Estructura del Proyecto 83
Figura 52 Fragmento del fichero ldquoSelectorpyrdquo 83
Figura 53 Fragmento del fichero ldquoCommon_Keywordsrobotrdquo 84
Figura 54 Fragmento del fichero de Configuracioacuten de pruebas ldquoConfigurationrobotrdquo 84
Figura 55 Diagrama de paquetes del proyecto de pruebas 85
Figura 56 Estructura de una Suite de Pruebas 85
Figura 57 Ejemplo de ldquoTest Setuprdquo personalizado para un caso de prueba 86
Figura 58 Vista de Gestioacuten Principal (Cloud Tab) 87
Figura 59 Pestantildea ldquoAdministrationrdquo 87
Figura 60 Diagramas de Flujo de Casos de Prueba U0025 y U0027 88
Figura 61 Script de Pruebas U0025 88
Figura 62 Keyword ldquoEdit Fieldsrdquo 88
Figura 63 Pestantildea ldquoList of Zone Managersrdquo 89
Figura 64 Diagrama de flujo de Caso de Prueba U0023 89
Figura 65 Script de Prueba U0023 90
Figura 66 Keyword ldquoZone Manager is registered successfullyrdquo 90
Figura 67 Seccioacuten de Fabricantes 90
Figura 68 Diagrama de flujo de Caso de Prueba U0009 91
Figura 69 Script de Prueba U0009 91
Figura 70 Toast Success 92
Figura 71 Keyword ldquoCorrectly Createrdquo 92
Figura 72 Setup amp Teardown de U0008 92
21
Figura 73 Mapa de Zone Managers 92
Figura 74 Funcioacuten que dibuja los ZM en el Mapa y obtiene los piacutexeles en pantalla 93
Figura 75 Diagrama de Flujo de Caso de Prueba U0007 94
Figura 76 Pestantildea ldquoGroupsrdquo 95
Figura 77 Diagrama de flujo de Caso de Prueba U0119 96
Figura 78 Script de Prueba U0119 97
Figura 79 Keyword ldquoVerify if AP is registered Succesfully on grouprdquo 97
Figura 80 Keywords Input Into Text Field y Clear Field Of Characters 97
Figura 81 Pestantildea ldquoCHT Zonesrdquo 98
Figura 82 Diagrama de Flujo de Caso de Prueba U0204 99
Figura 83 Scripts de Prueba U0204 99
Figura 84 Keyword Add Zone CHT to AP 99
Figura 85 Pestantildea BackupRestore 100
Figura 86 Diagrama de Flujo de Caso de Prueba U0401 101
Figura 87 Script de Prueba U0401 101
Figura 88 Keyword Restore For AP hace done successfully 101
Figura 89 Pestantildea ldquoFirmwarerdquo 102
Figura 90 Diagrama de Flujo de Caso de Prueba U0303 103
Figura 91 Script de Prueba U0303 103
Figura 92 Keyword Flash AP 103
Figura 93 Pestantildea ldquoVLAN amp Bridgesrdquo 104
Figura 94 Diagrama de Flujo de Caso de Prueba U0527 105
Figura 95 Script de Prueba U0527 105
Figura 96 Keyword Go And Create VLAN 105
Figura 97 Pestantildea SSIDs 106
Figura 98 Diagrama de Flujo de Caso de Prueba U0530 106
Figura 99 Script de Prueba U0530 107
Figura 100 Keyword Go And Create SSID 107
Figura 101 Pestantildea ldquoCHTrdquo 108
Figura 102 Diagrama de Flujo de Caso de Prueba U0539 109
Figura 103 Script de Prueba U0539 109
Figura 104 Keyword ACA Is Working 109
Figura 105 Keyword Changes On CLI 110
Figura 106 Comando CHT para obtener el estado del moacutedulo ACA en el punto de acceso 110
Figura 107 Pestantildea ldquoRadiusrdquo 110
Figura 108 Escenario de Funcionamiento de Servidor Radius 110
Figura 109 Diagrama de Flujo de Caso de Prueba U0601 111
Figura 110 Script de Prueba U0601 111
Figura 111 Keyword Create Radius Profile 112
22
Figura 112 Pestantildea Captive Portals 112
Figura 113 Escenario de Funcionamiento de un Portal Cautivo 112
Figura 114 Diagrama de Flujo de Caso de Prueba U0701 113
Figura 115 Script de Prueba U0701 113
Figura 116 Keyword Edit or Delete Captive Portal Profile 114
Figura 117 Pestantildea General 115
Figura 118 Diagrama de Flujo de Caso de Prueba U0522 116
Figura 119 Script de Prueba U0522 116
Figura 120 Keyword Check Number of Clients Increases 116
Figura 121 Pestantildea AP Network 117
Figura 122 Libreriacutea SSH para Robot Framework 117
Figura 123 Ventana de Configuracioacuten de TC Rules 118
Figura 124 Diagrama de Flujo de Caso de Prueba U0511 119
Figura 125 Script de Prueba U0511 120
Figura 126 Keyword Wait Timer 120
Figura 127 Keyword Check On CLI 120
23
24
GLOSARIO
CHT Cognitive Hostpot Technology
BDD Behaviour-Driven Development
MBT Model Based Testing
API Application Programing Interface
UAT User Acceptance Testing
SUT System Under Test
UML Unified Modeling Language
FSM Finite State Machine
RAE Real Academia Espantildeola
IEEE Institute of Electronical and Electronics Engineers
ITIL Information Technology Infrastructure Library
ISO International Organization for Standardization
WebQEM Web-site Quality Evaluation method
ISTQB International Software Testing Qualifications Board
TDD Test-Driven Development
SOA Service Oriented Architecture
WiFi Wireless Fidelity
MGR Manager Module
SB Smart Band Steering Module
TCM Traffic Congestion Management Module
LOC Localization Module
POWER Power Control Module
SR Smart Roaming Module
LB Load Balancing Module
AMQP Advance Message Queuing Protocol
HTML HyperText Markup Language
CSS Cascading Style Sheets
HTTPS HyperText Transfer Protocol Secure
TLS Transport Layer Security
REST REpresentational State Transfer
JSON JavaScript Object Notation
DOM Document Object Model
SQL Structure Query Language
ZMB Zone Manager Backend
ZTP Zero-Touch Provisioning
25
RF Robot Framework
CICD Continuous IntegrationContinuous Delivery
SSH Secure SHell
SCP Secure Copy ProtocolSimple Communication Protocol
26
27
1 INTRODUCCIOacuteN
ctualmente el desarrollo software se encuentra en un proceso revolucionario cuyo principal objetivo y
tendencia es la implantacioacuten y desarrollo de software distribuido donde se marcan como principales
objetivos la disponibilidad usabilidad y funcionalidad de cualquier aplicacioacuten a traveacutes de internet Es
aquiacute donde entran en juego entre otros el desarrollo de aplicaciones o servicios Web sustituyendo en gran
medida al desarrollo de aplicaciones y servicios de escritorio
Figura 1 Fuente de datos Morgan Stanley
Muchos son los aspectos a tener en cuenta entre los que cabe destacar la eficiencia la velocidad de respuesta y
de navegacioacuten los cuales para algunos servicios Web son excelentes pero para otros auacuten se encuentran en un
proceso de mejora Esto es debido a que gran cantidad de aplicaciones requieren de un buen disentildeo donde se
optimicen el uso de los recursos disponibles como el ancho de banda memoria carga del servidor respaldo
seguridad etc
A
Hemos establecido la civilizacioacuten de manera que los
maacutes cruciales elementos dependen de la ciencia y la
tecnologiacutea
Carl Sagan
28
11 Motivacioacuten
La gran demanda de servicios y aplicaciones Web distribuidas que permitan gestionar agilizar y simplificar
cualquier aacutembito de negocio hace que cada vez maacutes que dichas aplicaciones contemplen un mayor
conjunto de requisitos solicitados por los clientes lo cual se traduce en un mayor nuacutemero de funcionalidades
y casos de uso contemplados en dichas aplicaciones
Ademaacutes dichas aplicaciones se necesitan cada vez en un menor tiempo lo cual conlleva a reducir los
periodos en las diversas fases por las que pasa un proyecto software desde la fase de disentildeo hasta la de
pruebas Es en esta uacuteltima donde antes de ser entregada al cliente como un producto se detectan los
posibles errores e incluso se puede evaluar si la funcionalidad ofrecida por la aplicacioacuten esta alineada con
los requisitos demandados por el cliente
Los fallos o errores en las aplicaciones Web mal probadas bien por falta de asignacioacuten de tiempo o recursos
a la fase de pruebas tienen una mayor repercusioacuten teniendo el potencial de generar una gran cantidad de
quejas e insatisfaccioacuten por parte de los clientes casi inmediatamente En el caso de las aplicaciones Web
no soacutelo se trata de peacuterdidas econoacutemicas sino tambieacuten de peacuterdida de prestigio fiabilidad y credibilidad por
parte de nuestros usuarios o clientes Los consumidores de hoy demandan una tecnologiacutea intuitiva y de
confianza en un mercado en continuo crecimiento donde un pequentildeo error puede acarrear falta de
satisfaccioacuten en un usuario peacuterdidas millonarias a una empresa o incluso dantildeos humanos Y es en este tipo
de ciclos iterativos y raacutepidamente cambiantes donde la automatizacioacuten de pruebas juega un papel decisivo
iquestY cuaacutel es la causa de estos problemas Para ello debemos tener en cuenta que estos sistemas son disentildeados
por el ser humano el cual comete fallos ya sea por presioacuten en los plazos de trabajo por la complejidad del
coacutedigo o de la infraestructura por cambios de tecnologiacuteas o por cualquier otra interaccioacuten con el sistema
Como ha quedado reflejado un proceso riguroso de control de sistemas y documentacioacuten permiten
bull Ayudar a reducir el riesgo de los posibles fallos y Mejora la calidad de los sistemas a la hora de ser
usados
bull Un correcto mantenimiento del producto a lo largo del ciclo de desarrollo
bull Un cumplimiento de requisitos legales (normas nacionales e internacionales ordenanzas
municipales etc)
bull Una adecuacioacuten de un sistema a los requisitos contractuales
bull Una adaptacioacuten de estaacutendars especiacuteficos de la industria
La forma en la que se logre y las herramientas empleadas variaraacuten en funcioacuten de factores como la
envergadura y tipo de proyecto den cuanto a los riesgos tecnoloacutegicos de seguridad o de negocio asiacute como
del presupuesto y tiempo disponible
Figura 2 Manual Testing vs Automated Testing [20]
29
12 Alcance y Objetivos
Las pruebas de software o software testing pueden llevarse a la praacutectica de muacuteltiples maneras pero el
presente proyecto se centra en el componente funcional del producto enfocado en lo que hace el sistema y
no coacutemo primando la aceptacioacuten por parte de los usuarios en base a los requisitos de disentildeo originales Es
decir el punto de mira estaacute en cumplir los requisitos establecidos por el cliente dejando fuera del alcance
del proyecto la estructura del coacutedigo fuente implementado
Bajo este contexto se plantea la automatizacioacuten de la fase de pruebas de una aplicacioacuten Web distribuida
centrando el enfoque de este proyecto en la automatizacioacuten de pruebas funcionales maacutes concretamente
pruebas de humo or smoke tests y aceptacioacuten Hasta ahora dichas pruebas se realizaban manualmente por
un ingeniero de pruebas lo cual permitiacutea evaluar la calidad del producto que seriacutea entregado al cliente
Ademaacutes se realizaraacute un marco teoacuterico donde se resumiraacuten una clasificacioacuten de los diferentes tipos de
pruebas software que pueden realizarse sobre una aplicacioacuten
Concretamente la solucioacuten abordada en esta memoria se cintildee al mantenimiento de un producto Web como
es la plataforma Galgus CHT Cloud Manager Para ello se cubriraacuten un gran conjunto de funcionalidades
ofrecidas por dicha aplicacioacuten Web como por ejemplo inicio y cierre de sesioacuten flujos de navegacioacuten
comprobacioacuten de los elementos mostrados y uso de la caja de buacutesquedas Sin llegar a ser exhaustivos este
tipo de pruebas conocidas como smoke tests son faacutecilmente automatizables y permiten detectar las primeras
sentildeales de que un sistema no funciona de manera correcta Por tanto es necesario traducir los requisitos
funcionales a instrucciones de alto nivel faacutecilmente entendibles por personas con poca formacioacuten teacutecnica
dado que seraacute el el resultado mostrado de las pruebas realizadas (informes de pruebas) Estas instrucciones
usaraacuten Behaviour-Driven Development (BDD) para describir interacciones entre el usuario y el sistema
definiendo actor accioacuten y comportamiento esperado del sistema Robot Framework es la herramienta que
se usa para este punto
Una vez tenemos dichas instrucciones se deben traducir de nuevo a un lenguaje de menor nivel como es
Python para implementar los test scripts Estos scripts seraacuten los que Selenium Webdriver procese y traduzca
para comunicarse con el controlador del navegador Web Chrome en nuestro caso a traveacutes de una API
Posteriormente el navegador se encargaraacute de ejecutar los comandos de accioacuten y de devolver la informacioacuten
de estado de vuelta Finalmente Robot Framework elaboraraacute un informe en formato html detallando las
pruebas realizadas resultados de las interacciones tiempos de ejecucioacuten y espera errores producidos etc
Tambieacuten se realizaraacute un estudio del arte sobre una teacutecnica conocida como Model Based Testing (MBT)
Dicha teacutecnica permite la generacioacuten automaacutetica de las pruebas a realizar sobre un sistema partiendo del
modelado del comportamiento de dicho sistema Ademaacutes esta teacutecnica tambieacuten abarca la traduccioacuten de las
pruebas generadas en scripts ejecutables para aplicar dichas pruebas sobre el sistema dando tambiacuteeacuten la
posibilidad de evaluar los resultados Esto proporciona muchas ventajas sobre la fase de pruebas pero a la
vez tambieacuten requiere un mayor esfuerzo en la fase de disentildeo y una presencia continua de la fase de pruebas
en otras etapas del ciclo de vida del proyecto Tambieacuten se presentaraacute un conjunto de normativas que regula
y normaliza la gestioacuten de calidad software
Posteriormente se describiraacute el sistema sobre el cual se basa la aplicacioacuten bajo pruebas llamada CHT
Cloud Manager Se presentaraacute la arquitectura de la aplicacioacuten y posteriormente se destacaraacuten los objetivos
de automatizacioacuten de testeo sobre la misma proponiendo el entorno de UAT planteado para someter la
aplicacioacuten a las pruebas automaacuteticas desarrolladas Se dedicaraacute una seccioacuten a analizar las tecnologiacuteas y
herramientas usadas donde se centraraacute la atencioacuten en Robot Framework Selenium y Python como las
tecnologiacuteas usadas para automatizar el testeo Ademaacutes se destacaraacute la integracioacuten del entorno de UAT
como fase de la integracioacuten continua de la aplicacioacuten ademaacutes de la metodologiacutea de trabajo llevada a cabo
Finalmente se presentaraacuten algunos experimentos y demostraciones de uso de la herramienta desarrollada
se describiraacuten algunas liacuteneas de mejora y conclusiones y se incluiraacuten algunos posibles anexos para la puesta
en marcha de la aplicacioacuten y reportes de algunas pruebas entre otros
30
13 Estructura de la memoria
El siguiente esquema resume de forma geneacuterica los puntos tratados en esta memoria para que el lector pueda
tener una idea orientativa de la organizacioacuten de este documento
1 Introduccioacuten En este punto se abordan temas geneacutericos como los objetivos motivacioacuten y alcance de
forma que pueda adquirirse una breve aproximacioacuten a los detalles del proyecto
2 Estudio del Arte y Revisioacuten A lo largo de esta seccioacuten se presentaraacute un estudio sobre la teacutecnica
conocida como Model Based Testing la cual permitiriacutea mejorar el proceso de automatizacioacuten de
pruebas Ademaacutes se realiza una revisioacuten sobre la gestioacuten de Calidad Software presentado algunos
modelos existentes en la actualidad
3 Marco Teoacuterico Consta de un estudio sobre el proceso de pruebas en un proyecto Software y los
principales tipos de pruebas Software existentes
4 Sistema En este punto se presenta la arquitectura del sistema sobre el que se van a automatizar las
pruebas de aceptacioacuten o Smoke Tests Ademaacutes se describe el alcance y objetivos de dichas pruebas y
se presenta la arquitectura de la solucioacuten planteada como escenario de pruebas haciendo uso de Docker
como tecnologiacutea de automatizacioacuten en el despliegue de aplicaciones software alojadas en contenedores
de software
5 Tecnologiacuteas y Herramientas usadas Consta del conjunto de tecnologiacuteas usadas para la
implementacioacuten de las pruebas de aceptacioacuten automatizadas y las herramientas para utilizar dichas
pruebas y para gestionar el trabajo del equipo de desarrollo y calidad responsable de este proyecto
6 Experimentos Consta de un detalle sobre la funcionalidad de un conjunto de pruebas que han sido
implementadas para verificar y validar el funcionamiento esperado del sistema Para cada prueba se
definen criterios de aceptacioacuten diagramas de flujo y scripts de implementacioacuten detallando algunas de
las implementaciones clave
7 Liacuteneas de Mejora y Conclusiones Se incluye una seccioacuten conclusiones finales tras la realizacioacuten del
proyecto y una valoracioacuten del mismo a nivel general y personal Ademaacutes se destacaraacuten algunas liacuteneas
de mejora futuras relacionadas principalmente con la aplicacioacuten de Model Based Testing (MBT) y otros
aspectos sobre la implementacioacuten actual de la herramienta de automatizacioacuten
Ademaacutes se realizaraacute una seccioacuten de anexos en el que se trataraacuten puntos adicionales sobre el proyecto
bull Anexo A Preparacioacuten del Entorno de Trabajo y Ejecucioacuten de Pruebas
bull Anexo B Docker de Robot Framework y Entorno de UAT Dockerizado
bull Anexo C Revisioacuten de Reportes y Logs
31
32
2 ESTUDIO DEL ARTE Y REVISIOacuteN
n este punto se realizaraacute un estudio sobre el marco teoacuterico de una de las teacutecnicas existentes que permite
la generacioacuten y ejecucioacuten automaacutetica de casos de test a partir del modelado de un sistema para la fase
de pruebas de una aplicacioacuten Esta teacutecnica es conocida como Model Based Testing (MBT) Ademaacutes
se realizaraacute una revisioacuten de la normativa relacionada con la gestioacuten de calidad software analizando la familia de
normas ISOIEC 25000
21 Model Based Testing (MBT)
211 Introduccioacuten
Dada la rapidez con la que se demandan los servicios contratados por los clientes en muchas ocasiones la
mayoriacutea del tiempo y esfuerzo asignado para la realizacioacuten de proyectos de software van destinados a la
labor de desarrollo dedicando menos esfuerzos en otras fases del ciclo de vida de un proyecto como las
fases de disentildeo o de pruebas Esto puede conllevar a que el proyecto no se desarrolle de acuerdo con los
requisitos demandados por los clientes y que el nuacutemero de puntos de fallo del producto software aumente
La fase de testeo o prueba de un producto software durante su ciclo de vida es una etapa fundamental para
validar la calidad del producto desarrollado y ofrecido a un cliente para conseguir un grado de satisfaccioacuten
aceptable de forma que se cumpla con los requisitos demandados y con el menor grado de error posible
Figura 3 Fase de Pruebas y Validacioacuten
Uno de los factores por los que en ocasiones no se emplean suficientes recursos a la fase de pruebas es la
gran cantidad de casos de pruebas que se deben realizar para validar un sistema Por cada caso de prueba
se deben asignar recursos relacionados con la planificacioacuten disentildeo y ejecucioacuten del mismo
Por tanto en este punto cabe plantearse la idea de automatizar no solo los casos de pruebas que validan un
sistema sino la generacioacuten de los casos de prueba Esto puede permitir reducir de forma considerable el
coste y esfuerzos en la fase de pruebas En este contexto surge el concepto de Model Based Testing (MBT)
E
La tecnologiacutea no es en siacute el fin sino el medio entre la
sociedad del conocimiento y el desarrollo mundial
Anoacutenimo
33
212 iquestQueacute es Model Based Testing
Este se trata de un meacutetodo capaz de controlar la calidad del software durante su ciclo de vida permitiendo
la generacioacuten automaacutetica de los casos de prueba e incluso la ejecucioacuten y evaluacioacuten automaacutetica de
resultados Para ello se requiere de un modelado y disentildeo correcto del sistema bajo pruebas como base
para la aplicacioacuten de esta teacutecnica
Figura 4 Esquema baacutesico de Model Based Testing
MBT permite crear un modelo del comportamiento esperado por el sistema a traveacutes del cual permite la
aplicacioacuten de diferentes teacutecnicas para la generacioacuten de casos de prueba [1]
bull Generacioacuten de casos de pruebas con datos de entrada sobre un modelo de dominio del sistema bull Generacioacuten de casos de pruebas de un modelo de entorno bull Generacioacuten de casos de prueba con predicciones del comportamiento del modelo bull Generacioacuten de scripts de prueba a partir de pruebas abstractas
213 iquestCoacutemo funciona Model Based Testing
En primer lugar se requiere del disentildeo de un modelo del sistema bajo test el cual debe tener al menos dos
caracteriacutesticas principales debe ser pequentildeo en relacioacuten al tamantildeo del sistema de forma que no requiera
un coste elevado pero debe ser lo suficientemente detallado para describir completamente las
caracteriacutesticas que se quieran probar sobre el sistema
Una vez implementado el modelo del sistema a probar se procederiacutea a la utilizacioacuten de herramientas
basadas en la teacutecnica MBT para generar automaacuteticamente el banco de pruebas a partir del modelo del
sistema bajo test (SUT) Estos bancos de pruebas generados seraacuten un conjunto de pruebas abstractas cada
una de las cuales define la secuencia de operaciones a realizar para probar una funcionalidad determinada
con sus respectivos valores o datos de entrada necesarios y las salidas o respuestas del sistema que se
esperan
A partir del banco de pruebas abstractas se deben transformar en scripts de pruebas ejecutables lo cual
puede realizarse con herramientas basadas en la teacutecnica MBT Estos scripts podriacutean ser ejecutados para la
deteccioacuten de errores sobre el sistema bajo test y esta ejecucioacuten podriacutea ser controlada y monitorizada por
alguna herramienta de ejecucioacuten de pruebas
En el siguiente diagrama se muestra el proceso de aplicacioacuten de este meacutetodo donde se propone dividir el
proceso en cinco fases principales [1]
1 Modelado Modelar el sistema bajo test y su entorno 2 Generacioacuten Generar las pruebas abstractas a partir del modelo planteado en la fase anterior 3 Concretizado Concretizar o adaptar las pruebas abstractas para transformarlas en ejecutables 4 Ejecucioacuten Ejecutar las pruebas sobre el sistema bajo test y definir decisiones o veredictos para las
mismas de forma que se pueda determinar el correcto funcionamiento del sistema bajo test 5 Anaacutelisis Analizar los resultados obtenidos a partir de la ejecucioacuten de los casos de prueba
34
Destacar que para el generador de casos de prueba y el script de pruebas se suelen usar herramientas de pruebas
especiales Por este motivo se encuentran resaltados en negrita
Figura 5 Proceso detallado de Model Based Testing (MBT)
Una vez presentado el proceso o metodologiacutea para llevar a cabo dicha teacutecnica se describiraacuten las principales
fases
2131 Construccioacuten del Modelo
Dicha fase consiste en la construccioacuten de un modelo que represente el comportamiento detallado del sistema
bajo pruebas yo su entorno a partir de los requisitos de disentildeo del mismo y el plan de pruebas desarrollado para
cumplir con estos requisitos
Este es el paso maacutes importante en la aplicacioacuten de la teacutecnica Model Based Testing ya que el resto de fases
dependeraacute siempre del modelo del sistema bajo pruebas Cuanto maacutes completo sea el modelo maacutes efectivos
seraacuten los casos de prueba generados a partir de este
Figura 6 Construccioacuten del Modelo
35
Para llevar a cabo el modelo del comportamiento de la aplicacioacuten se requiere conocer exactamente el
comportamiento esperado de la misma lo cual lleva a estudiar y analizar en profundidad el sistema y su entorno
previamente
Existen diversas especificaciones formales para el modelado a partir de los requisitos como por ejemplo los
diagramas UML Estos ayudan a que el modelado sea una tarea algo maacutes sencilla de realizar que si se llevara a
cabo a partir de los requisitos escritos en lenguaje natural Por otro lado para modelar el comportamiento existen
diversas teacutecnicas como las maacutequinas de estados finitos (FSM) Cadenas de Maacuterkov Tablas de decisiones
Diagramas de estados etc
En conclusioacuten modelar un sistema no es una tarea sencilla ya que requiere de habilidades teacutecnicas experiencia
e imaginacioacuten para construir un modelo que se comporte de la forma deseada Dicho modelo debe cumplir con
las siguientes propiedades [2]
bull Debe ser lo maacutes abstracto posible sin perder la informacioacuten importante
bull No debe contener informacioacuten que sea redundante o que no esteacute relacionada con el alcance de las
pruebas
bull Debe ser entendible para los ingenieros de pruebas incluso a expensas de la brevedad y abstraccioacuten del
mismo
bull Debe ser flexible y abierto para permitir cambios y antildeadir o eliminar nuevas funcionalidades
bull Debe considerar todos los detalles de implementacioacuten de las pruebas
2132 Generacioacuten de Casos de Prueba
Los casos de prueba seraacuten generados tras la construccioacuten previa del modelo del sistema Antes de la creacioacuten de
los casos de prueba los ingenieros de pruebas deben especificar o proveer informacioacuten sobre el criterio o
propoacutesito de los casos de prueba las entradas y en algunos casos las salidas esperadas del sistema
Destacar que generar las salidas esperadas correspondientes a unas determinadas entradas es maacutes complejo que
generar soacutelo las entradas Para ello se necesita un oraacuteculo que cree salidas vaacutelidas y las mapee a los casos de
prueba Crear el oraacuteculo es la tarea maacutes compleja
Las dificultades presentadas en esta fase dependeraacuten de si el modelo es complejo o simple y la efectividad de
los casos de prueba generados dependeraacute de lo completo y preciso que sea dicho modelo para poder generar
automaacuteticamente los casos de prueba
Cuando el sistema es complejo la cantidad de casos de test es muy grande e incluso infinita Por tanto evaluar
todos los casos de test resulta inviable y costoso En este caso para mejorar la calidad del sistema se necesita
seleccionar los casos de test que realmente puedan ayudar a localizar tantos fallos como sea posible con un coste
aceptable
Existen diferentes criterios de cobertura que permiten ayudar a controlar el proceso de generacioacuten de casos de
prueba Sin embargo se recomienda seleccionar maacutes de uno de estos criterios para lograr un mayor resultado en
la cobertura de pruebas
2133 Ejecucioacuten de Casos de Prueba
La ejecucioacuten de los casos de pruebas requiere la transformacioacuten de los mismos en una forma ejecutable Debido
a que los los scripts de pruebas ejecutables pueden ser reutilizados durante todo el tiempo empleado en la
validacioacuten del sistema estos deben ser escritos de una forma maacutes eficiente que permita que sean reutilizables e
incluso que frente a una modificacioacuten sean maacutes faacuteciles generarlos y ejecutarlos Por ello se crean scripts
ejecutables para los casos de prueba abstractos
El proceso de transformacioacuten en pruebas ejecutables seriacutea maacutes eficiente si es hecha de forma automaacutetica
Despueacutes de aplicar los casos de prueba ejecutables al sistema bajo pruebas se obtienen las salidas actuales del
sistema las cuales deberaacuten ser contrastadas con las salidas esperadas
36
2134 Anaacutelisis de los Resultados
Una vez ejecutados los casos de pruebas y obtenidas las salidas actuales del sistema se deben evaluar y analizar
los resultados obtenidos Para ello se debe comparar las salidas actuales obtenidas con las salidas esperadas
especificadas en los casos de prueba Esta tarea de comparacioacuten podriacutea realizarse idealmente de forma
automaacutetica lo cual dariacutea como resultados posibles
1 Pasa Cuando las salidas actuales se encuentran acordes con las salidas esperadas
2 Falla Cuando las salidas actuales no se encuentran acordes con las salidas esperadas
3 Inconcluso Cuando no se puede tomar una decisioacuten en el momento
Hay que destacar que puede darse el caso en el que si las salidas esperadas no estaacuten bien determinadas los
resultados obtenidos al contrastar dichas salidas con las actuales sean falsos dando lugar a resultados sin utilidad
y que pueden dar lugar a confusioacuten
Por este motivo la generacioacuten automaacutetica de las salidas esperadas es una tarea compleja e importante en todo el
proceso especialmente en sistemas complejos Por tanto el nivel de dificultad para encontrar un oraacuteculo de
pruebas depende del tamantildeo y complejidad del sistema Sin embargo la necesidad e importancia del oraacuteculo de
pruebas tambieacuten aumenta cuando el sistema es maacutes complejo
Tras obtener los resultados se debe determinar si se decide generar maacutes casos de prueba si se debe modificar el
modelo o si la fase de pruebas debe ser detenida y debe ponerse en marcha el software del sistema que se estaacute
probando
214 Consideraciones para la aplicacioacuten de Model Based Testing (MBT)
Son muchos los artiacuteculos que describen aspectos importantes a tener en cuenta durante el desarrollo o la
aplicacioacuten de esta teacutecnica Algunas de estas consideraciones a destacar seriacutean las siguientes [3]
1 El modelo que describe el comportamiento del sistema es el punto clave
El comportamiento del modelo debe ser desarrollado cuidadosamente Sus limitaciones y restricciones deben
ser respetadas durante el modelado del sistema bajo pruebas De esta forma si el modelo estaacute mal las pruebas
generadas tambieacuten lo estaraacuten Por tanto la exactitud del modelo es fundamental para pasar a la fase de
generacioacuten de casos de prueba
2 Las pruebas deben cubrir los criterios de control de flujo y datos
Los criterios de cobertura de las pruebas definen un conjunto de casos de prueba seleccionados para la misma
Estos casos de pruebas pueden ser generados a partir de dos fuentes criterios de flujo de control o de flujo
de datos En el caso de pruebas aplicadas a grandes sistemas es importante combinar ambos criterios para
incrementar la cobertura de las pruebas
3 El nivel de automatizacioacuten debe ser elevado
El nivel de automatizacioacuten es un factor importante para definir la factibilidad de uso de MBT Normalmente
suele haber un uacutenico paso no automatizado el modelado del comportamiento del sistema el cual es utilizado
como entrada para el proceso de generacioacuten de los casos de prueba Si hubiese otros pasos no automatizados
se incrementariacutea el esfuerzo los costes y la complejidad de su uso
4 Son fundamentales las herramientas que soportan la automatizacioacuten de las fases de MBT
Las herramientas usadas deben soportar la ejecucioacuten de los pasos automatizados Si no hay una herramienta
que soporte un determinado paso esta tarea podriacutea ser difiacutecil e inviable Por tanto una herramienta debe
soportar la integracioacuten entre los diferentes pasos no automatizados y automatizados
5 Los liacutederes del proyecto deben entender las habilidades requeridas y la complejidad para usar
MBT
Las personas encargadas de la fase de pruebas necesitan conocer ademaacutes de las teacutecnicas de pruebas los
lenguajes de modelado y algunos lenguajes de programacioacuten
37
6 El orden de los pasos a seguir mientras se usa un enfoque MBT
Es necesario respetar los pasos seguidos para la generacioacuten de los casos de prueba de forma que sean
respetados en la fase de ejecucioacuten de las pruebas siendo ejecutados en la misma secuencia en que fueron
definidos En caso contrario se podriacutean generar salidas erroacuteneas de dichas pruebas
7 Transferencia de la Tecnologiacutea
Las tecnologiacuteas usadas para la aplicacioacuten de la teacutecnica MBT se transfieren desde entornos acadeacutemicos o de
investigacioacuten para ser implementados en proyectos industriales Por este motivo necesitan ser analizados
cuidadosamente antes de ser usadas
215 Beneficios de Model Based Testing (MBT)
A continuacioacuten se definen diversos beneficios que proporciona la aplicacioacuten de Model Based Testing para la
fase de pruebas [1] [4]
1 Deteccioacuten de Fallos del Sistema Bajo Pruebas
El modelado del comportamiento del sistema bajo pruebas permite detectar errores ambiguumledades o lagunas
que pueden presenciarse en la toma de requisitos especificacioacuten y disentildeo del software Por tanto permite
una deteccioacuten temprana de errores
2 Reduccioacuten de costes y tiempo en la fase de pruebas
La aplicacioacuten de esta teacutecnica contribuye a que el tiempo coste y recursos empleados a la fase de pruebas
disminuya Sin embargo se requiere una mayor asignacioacuten de recursos para el modelado y mantenimiento
del sistema
3 Mejora de la calidad de las pruebas
Cuando las pruebas se desarrollan manualmente la calidad de las mismas es muy dependiente de los
desarrolladores que la implementan Ademaacutes el proceso de disentildeo no puede ser reproducido el criterio
racional aplicado para cada prueba normalmente no es recordado y el resultado de los casos de prueba no es
faacutecilmente interpretado ni contrastado con los requisitos originales del sistema
Model Based Testing es una teacutecnica capaz de mejorar mucho estos inconvenientes que se presentan sobre el
desarrollo de pruebas manuales gracias al generador automatizado de casos de prueba
4 Trazabilidad
Puede definirse como la habilidad para relacionar cada caso de prueba al modelo criterio de seleccioacuten e
incluso a los requisitos informales del sistema Esto ayuda a explicar los casos de prueba asiacute como justificar
por queacute fueron creados Los algoritmos aplicados para la generacioacuten de pruebas deben saber queacute partes del
modelo seraacuten empleadas en cada caso de prueba y las salidas esperadas
5 Evolucioacuten de los requisitos
Si los requisitos del sistema cambian con la aplicacioacuten de Model Based Testing bastariacutea con actualizar el
modelo y las pruebas seraacuten generadas de nuevo de forma automaacutetica Debido a que el modelo es usualmente
maacutes pequentildeo que el conjunto de pruebas del sistema requiere menos tiempo actualizar el modelo que
actualizar todos los casos de prueba Por tanto puede concluirse que se obtiene una respuesta maacutes raacutepida
frente a un cambio en los requisitos
6 Reusabilidad del modelo
El modelo contiene informacioacuten sobre el comportamiento del sistema bajo pruebas Por tanto este puede ser
reutilizado en futuras pruebas incluso cuando los requisitos cambian
38
216 Problemas y Limitaciones de Model Based Testing (MBT)
Una vez destacados los beneficios que aporta dicha teacutecnica tambieacuten es importante detallar algunos problemas
y limitaciones sobre su uso [1] [5]
2161 Problemas
bull Para abordar dicha teacutecnica es necesario que los ingenieros de pruebas tengan habilidades teacutecnicas sobre
la notacioacuten usada para el modelado del sistema Ademaacutes deberiacutean tener experiencia con herramientas
scripts y lenguajes de programacioacuten usados para ejecutar las tareas de Model Based Testing
bull Cuando dicha teacutecnica se pretende aplicar a sistemas complejos el modelado del sistema es maacutes
complejo y existe riesgo de producirse un desbordamiento de la cantidad de casos de prueba generados
a partir del modelo Por esta razoacuten es muy importante definir bien el conjunto de criterios para la
generacioacuten de las pruebas lo cual permite acotar la cobertura de pruebas de forma razonable
bull La automatizacioacuten de la generacioacuten del oraacuteculo de pruebas a partir del modelo es compleja
especialmente en sistemas complejos Cuando el tamantildeo del sistema aumenta la necesidad de
automatizacioacuten tambieacuten aumenta
bull Es necesario desarrollar un modelo de software especiacutefico para un dominio en concreto de aplicacioacuten
ya que existen diversas notaciones de modelado del sistema
bull Es necesario la especificacioacuten formal de los requisitos para obtener el modelo del sistema a partir de
estos La especificacioacuten informal o en lenguaje natural de los requisitos puede dar lugar a ambiguumledades
que dificultan la exactitud en el modelado
2162 Limitaciones
bull No es posible modelar todos los aspectos del comportamiento del sistema bajo pruebas Por tanto es
necesario el uso de otras notaciones de modelado que cubran dichos aspectos
bull Los proyectos software evolucionan continuamente surgiendo nuevos requisitos los cuales algunos
pueden quedar fuera de la fecha de planificacioacuten Si se ha comenzado con el modelado a partir de
requisitos antiguos se construiraacute un modelo erroacuteneo que no reflejaraacute los nuevos requisitos
contemplados lo cual daraacute lugar a errores en el sistema bajo pruebas o resultados no fiables
bull Cuando se produce un fallo en una prueba generada podriacutea resultar maacutes complejo determinar la causa
del fallo ya que la secuencia de pruebas generadas en Model Based Testing podriacutea ser maacutes compleja y
menos intuitiva que las disentildeadas manualmente
217 Cuando elegir Model Based Testing (MBT)
Finamente tras detallar los beneficios problemas y limitaciones sobre la teacutecnica bajo estudio se destacan
algunos puntos principales a tener en cuenta para la aplicacioacuten de dicha teacutecnica
bull Debe existir documentacioacuten lo suficientemente buena sobre el sistema para poder aplicarla
bull Si ya existe un modelo del sistema seriacutea un primer paso que facilitariacutea su aplicacioacuten
bull El manager del proyecto debe ser consciente que la fase de pruebas con Model Based Testing comienza
desde la toma de requisitos ya que se debe modelar el comportamiento del sistema bajo pruebas a partir
de estos Por tanto no se puede esperar que la fase de pruebas comience despueacutes del desarrollo Hacerlo
tras el desarrollo podriacutea significar la modificacioacuten de los requisitos y en consecuencia el desarrollo
39
22 Gestioacuten de Calidad Software
221 Introduccioacuten
En los uacuteltimos antildeos la creciente demanda de productos software principalmente de aplicaciones distribuidas
como los servicios Web provoca que diferentes empresas busquen soluciones software para satisfacer las
necesidades de los clientes Este conjunto de empresas forma un entorno competitivo en el que se intenta buscar
algunos factores para destacar sobre los demaacutes competidores respondiendo a las nuevas exigencias del mercado
Bajo este contexto se plantea la implantacioacuten de una direccioacuten basada en la calidad como la propuesta que
mejores resultados ha ofrecido No solo basta con desarrollar software acorde a los requisitos de los clientes y
las exigencias de los mismos sino que se trata de crear un producto que garantice su correcto funcionamiento
bajo el sustento de una garantiacutea de calidad razonable
El concepto de ldquocalidadrdquo siempre se ha relacionado con la inspeccioacuten de productos fiacutesicos Pero dicho teacutermino
ha ido expandiendo su contexto de una forma maacutes global y aplicable a cualquier tipo de servicio o producto
ofrecido a un cliente
222 Concepto de Calidad
Acorde a la definicioacuten ofrecida por la Real Academia Espantildeola (RAE) la calidad se define como ldquouna propiedad
o conjunto de propiedades inherente a algordquo ldquoAdecuacioacuten de un producto o servicio a las caracteriacutesticas
especificadasrdquo o ldquocondicioacuten o requisito que se pone en un contratordquo [6]
Por otro lado el instituto de Ingenieros Eleacutectricos y Electroacutenicos (IEEE) define la calidad como ldquoel grado con
el que un sistema componente o proceso cumple con los requisitos especificados y las necesidades o
expectativas del cliente o usuariordquo destacando que el eacutenfasis radica en los requisitos especiacuteficos del sistema y
en la buacutesqueda de la satisfaccioacuten del cliente [7]
Roger Pressmann define la Calidad del Software como ldquoConcordancia del software producido con los requisitos
expliacutecitamente establecidos con los estaacutendares de desarrollo prefijados y con los requisitos impliacutecitos no
establecidos formalmente que desea el cliente y en uacuteltima instancia el usuariordquo [8]
Una vez presentado el concepto de calidad su definicioacuten orientada al software se refiere al grado de desempentildeo
de las principales caracteriacutesticas con las que debe cumplir un sistema durante su ciclo de vida Estas
caracteriacutesticas son las que garantizan que el cliente cuente con un sistema confiable lo que permite un aumento
de la satisfaccioacuten frente a la funcionalidad y eficiencia del sistema construido
Figura 7 Concepto de Calidad
40
223 Modelos de Calidad de Software
Los modelos de calidad son aquellos documentos que integran la mayor parte de las mejores praacutecticas proponen
temas de administracioacuten en los que cada organizacioacuten debe hacer eacutenfasis integran diferentes praacutecticas dirigidas
a los procesos clave y permiten medir los avances en calidad
Bajo este contexto los modelos de calidad deben permitir la evaluacioacuten del sistema de forma cualitativa o
cuantitativa y de acuerdo con esta evaluacioacuten la organizacioacuten podraacute proponer implementar estrategias que
permitan la mejora continua en el resto de etapas del ciclo de vida como son las etapas de anaacutelisis disentildeo
desarrollo y pruebas software [7] Desde finales de los antildeos 70 se han ido desarrollando diversos modelos de
calidad del producto software con el fin de fijar una terminologiacutea y entender queacute concepto de calidad se estaacute
usando Asiacute mismo dichos modelos de calidad se clasifican de acuerdo con el enfoque de evaluacioacuten
contemplado ya sea a nivel de proceso producto o calidad de uso
2231 Calidad a Nivel de Proceso
Este enfoque de calidad de software describe que la calidad de un sistema software debe ser implementada desde
el inicio del proyecto y en cada etapa de su ciclo de vida debiendo permitir el control y seguimiento de los
aspectos de calidad para minimizar los riesgos y ofrecer un soporte continuo De esta forma se consigue
garantizar un nivel oacuteptimo de cumplimiento de los factores de calidad definidos teniendo en cuenta que si en
alguna etapa no se verifican dichos factores posiblemente disminuya el nivel de calidad no solo del proceso si
no tambieacuten del producto en desarrollo [7]
A continuacioacuten se muestra una liacutenea de tiempo de algunos modelos a nivel de proceso y se describen dos de los
que maacutes intereacutes presentan dentro del aacutembito de este proyecto
Figura 8 Liacutenea de tiempo de modelos a nivel de proceso
ITIL (Information Technology Infrastructure Library)
Desarrollado en el Reino Unido con el fin de fortalecer la gestioacuten gubernamental a partir de cinco elementos
fundamentales la perspectiva del negocio entrega del servicio soporte del servicio manejo de la infraestructura
y manejo de aplicaciones con el propoacutesito de ofrecer una estructura integral para prestar a la organizacioacuten un
servicio completo cubriendo necesidades de apoyo de instalacioacuten adecuacioacuten de redes comunicaciones
hardware servidores sistema operativo y software necesarios
Figura 9 Logo de ITIL
41
ISOIEC 20000
El objetivo principal de esta norma es avalar que la prestacioacuten de servicios de TI en una empresa cuenta con la
calidad necesaria para brindar dichos servicios a los clientes Esta norma engloba diferentes secciones dedicadas
a las especificaciones de dicha norma y a los coacutedigos de buenas praacutecticas
Figura 10 ISOIEC 20000
WebQEM
Web-site Quality Evaluation Method se trata de una metodologiacutea de evaluacioacuten de calidad de sitios Web en seis fases planificacioacuten y programacioacuten de la evaluacioacuten de la calidad definicioacuten y especificacioacuten de los requisitos de calidad establecidos definicioacuten e implementacioacuten de la evaluacioacuten elemental definicioacuten e implementacioacuten de la evaluacioacuten global anaacutelisis de resultados y evaluacioacuten de meacutetricas y finalmente conclusiones y documentacioacuten
Figura 11 Logo de WebQEM
42
2232 Calidad a Nivel de Producto
El enfoque de la calidad de software a nivel de producto tiene como objetivo especificar y evaluar el
cumplimiento de los criterios del producto Para ello se suelen definir y aplicar medidas o meacutetricas internas o
externas Por esta razoacuten muchas normas definen la calidad a nivel de producto de tipo interna externa y en uso
Esta uacuteltima se define como el conjunto de atributos relacionados con la aceptacioacuten por parte del usuario final y
seguridad
A continuacioacuten se muestra una liacutenea de tiempo de algunos modelos a nivel de proceso y se describen tres de los
que maacutes intereacutes presentan dentro del aacutembito de este proyecto
Figura 12 Liacutenea de tiempo de modelos a nivel de producto
ISO 9126
Este se basa en el modelo McCall el cual es uno de los modelos pioneros en la evaluacioacuten de la calidad de
software Desarrollado en 1991 es un marco normativo dirigido a desarrolladores aseguradores de calidad
evaluadores analistas y cualquier otro involucrado en el proceso de construccioacuten de software y la gestioacuten de
calidad del mismo Estaacute dividido en cuatro partes Modelo de Calidad Meacutetricas Externas Meacutetricas Internas y
Calidad de Meacutetricas en Uso
Esta norma busca la fiabilidad funcionalidad usabilidad eficiencia mantenibilidad y portabilidad en la
construccioacuten de productos software A continuacioacuten se muestra un esquema que resume dichas caracteriacutesticas
y subcaracteriacutesticas [8]
Figura 13 Esquema de ISO 9126
43
ISOIEC 25000
Basada en la norma ISO 9126 y adaptando parte del marco normativo a las necesidades del mercado actual Esta
norma tambieacuten conocida como SQuaRE (Software Product Quality Requirements and Evaluation) establece
un marco de trabajo comuacuten para evaluar la calidad de productos de Software
En dicha norma se definen los modelos teacuterminos y definiciones comunes para el resto de normas que componen
la serie 25000 La ISOIEC 25000 presenta diversas secciones entre las que se puede destacar [9]
ISOIEC 25010 Describe las caracteriacutesticas y subcaracteriacutesiticas de calidad que pueden ser evaluadas
en un producto software diferenciando entre calidad interna externa y de uso En la siguiente figura se
presenta un desglose de dichas caracteriacutesticas
ISOIEC 25040 Define el proceso de evaluacioacuten perioacutedico de la calidad del producto software
Figura 14 Esquema de ISOIEC 25000
44
224 Principales Ventajas e Inconvenientes de Modelos de Calidad anteriores
2241 A nivel de Proceso
Modelo Ventajas Inconvenientes
ITIL bull Mejor estructuracioacuten organizacioacuten y
claridad de los proyectos
bull Mayor control administrativo
bull Mayor eficacia y rapidez ante cambios
bull Incrementa la productividad del negocio y la
fiabilidad de los clientes
bull Tiempo y esfuerzo necesarios
bull Falta de conocimiento para apreciar la mejora
proporcionada
bull Involucracioacuten y compromiso de todo el
personal de la organizacioacuten
bull Frustracioacuten generada por expectativas a corto
plazo
bull No hay mejoriacutea si la inversioacuten asignada para
implantar el modelo es insuficiente
ISOIEC
20000 bull Reconocimiento internacional
bull Muy usado por las organizaciones
WebQUEM bull Calidad medida en fases y actividades de
forma cuantitativa con indicadores
bull Aplicaciones de Software centradas en la Web
son cada vez maacutes complejas provocan mayor
complejidad en su implantacioacuten
2242 A nivel de Producto
Modelo Ventajas Inconvenientes
ISO 9126 bull Determina queacute caracteriacutesticas y
subcaracteriacutesticas son importantes para el
producto
bull Define meacutetricas especiacuteficas para los
componentes Software
bull Define indicadores para las caracteriacutesticas de
calidad
bull Usabilidad tratada desde la perspectiva del
proceso no del producto
bull No tiene en cuenta la caracteriacutestica de ldquofacilidad
de aprendizajerdquo siendo esta recomendada por
otros estaacutendares
bull Meacutetricas complejas difiacutecilmente medibles
Requieren descomposicioacuten
ISOIEC
25000 bull Detecta objetivos del producto alineados con
necesidades reales de clientes finales
bull Evita ineficiencias y maximiza rentabilidad
y calidad del producto
bull El proceso de evaluacioacuten perioacutedica permite
la mejora continua
bull No establece niveles de calidad para cada
proyecto
bull No hace uso de meacutetricas o umbrales de calidad
225 Conclusiones
Una vez presentado el concepto de gestioacuten de calidad de software y los principales modelos y normas es
interesante destacar la diferencia entre calidad interna y externa La calidad interna se centra en las caracteriacutesticas
propias del producto software (disentildeo especificacioneshellip) mientras que la calidad externa lo hace con las
caracteriacutesticas dinaacutemicas del mismo es decir con el comportamiento Es por ello que el proceso de calidad
interna se inicia en las fases tempranas del ciclo de vida de un proyecto mientras la calidad externa se aplica
una vez se tiene un primer prototipo funcional del producto software desarrollado Por tanto se trataraacute de
automatizar el proceso de evaluacioacuten de la calidad externa del proyecto CHT Cloud Manager analizando
verificando y validando automaacuteticamente la aceptacioacuten de dicho producto
45
46
3 MARCO TEOacuteRICO PRUEBAS DE SOFTWARE
ras presentar el concepto de calidad y algunas de las normas y estaacutendares maacutes conocidos que describen
la aplicacioacuten de dicho concepto en el aacutembito del desarrollo de software se centraraacute el enfoque en el
papel del testeo y las pruebas de software Con ello se destacaraacuten algunos puntos principales para
llevar a cabo las pruebas de software el anaacutelisis disentildeo e implementacioacuten de dichas pruebas los diferentes tipos
y niveles de pruebas y las dificultades de la aplicacioacuten de pruebas de software sobre aplicaciones Web
31 Testing y Pruebas de Software
Habitualmente se tiene una percepcioacuten del testing de un producto como una tarea basada en la ejecucioacuten de
pruebas de forma repetitiva para la buacutesqueda de errores o problemas que puedan repercutir sobre la calidad del
mismo Pero el testing no solo se basa en la realizacioacuten de pruebas
Se deben identificar otras tareas que estaacuten relacionadas con el testing las cuales se llevan a cabo antes y despueacutes
de la ejecucioacuten de pruebas Estas tareas estaacuten relacionadas principalmente con la planificacioacuten y control del
proceso de pruebas el disentildeo de los diferentes casos de prueba o test cases y la posterior comprobacioacuten de los
resultados obtenidos tras llevar a cabo las pruebas Otras tareas podriacutean ser la propia evaluacioacuten de los diferentes
criterios de finalizacioacuten del proceso de pruebas el anaacutelisis de informes de resultados o la revisioacuten de la
documentacioacuten generada en la fase de pruebas
A continuacioacuten se citan algunas definiciones para explicar el concepto de pruebas de software
ldquoUna prueba es una actividad ejecutada para evaluar la calidad del producto software y mejorarlo mediante
la identificacioacuten de problemas errores o defectos en su funcionamiento [9]rdquo
ldquoLas pruebas de Software consisten en verificaciones dinaacutemicas del comportamiento del software bajo
pruebas mediante un conjunto finito de casos de prueba seleccionadas adecuadamente sobre un dominio
infinito de casos posibles [1]rdquo
Atendiendo a las definiciones presentadas las pruebas de software son dinaacutemicas porque se puede ejecutar el
software bajo pruebas con un conjunto de valores de entrada especiacuteficos para encontrar fallos en su
comportamiento Por otro lado la realizacioacuten de pruebas exhaustivas no es posible para la mayoriacutea de los
productos software reales debido a la gran cantidad de entradas posibles para cada operacioacuten entradas invaacutelidas
o no esperadas y las infinitas secuencias de operaciones posibles
Por estas razones para aplicar un proceso de pruebas de software razonable en cuanto a recursos y tiempo de un
proyecto es necesario seleccionar un conjunto abarcable de pruebas Debido a esto la clave estaacute en el criterio
de seleccioacuten de dichas pruebas Una vez ejecutadas las pruebas seleccionadas se debe decidir si el
comportamiento esperado del sistema falla o no Este es el llamado problema del oraacuteculo el cual es resuelto en
la mayoriacutea de los casos de forma manual mediante la inspeccioacuten de los resultados de la prueba
T
La tecnologiacutea no es nada Lo importante es que tengas feacute
en la gente que sean baacutesicamente buenas e inteligentes
y si les das herramientas haraacuten cosas maravillosas con
ellas
Steve Jobs
47
32 Principios de las Pruebas de Software
Una vez presentada la definicioacuten de pruebas de Software se han obtenido algunos detalles que encajan
perfectamente con una serie de principios que han sido establecidos para el testing de productos software seguacuten
ISTQB (International Software Testing Qualifications Board) [10]
Figura 15 Principios de las Pruebas de Software
1 Las pruebas demuestran la presencia de defectos no su ausencia Las pruebas pueden mostrar que
los defectos estaacuten presentes en el producto pero no pueden probar que no haya defectos Por tanto las
pruebas pueden reducir la probabilidad de existencia de defectos en el software pero incluso si no se
encuentran defectos las pruebas no son una garantiacutea total para afirmar la ausencia de defectos en el
producto final
2 Las pruebas exhaustivas son imposibles Probar todas las posibles combinaciones de entradas y
condiciones previas sobre una aplicacioacuten no es factible excepto en casos muy triviales En lugar de
intentar realizar pruebas exhaustivas se debe usar el anaacutelisis de riesgos las teacutecnicas de prueba y las
prioridades ademaacutes de la automatizacioacuten para enfocar los esfuerzos en la fase de pruebas
3 Las pruebas tempranas ahorran tiempo y dinero Para una deteccioacuten temprana de errores y defectos
las actividades de pruebas deben iniciarse lo antes posible en el ciclo de vida del desarrollo del software
De esta forma se consigue una reduccioacuten de costes ya que cuanto maacutes tarde se detecte un defecto maacutes
costoso y difiacutecil seraacute corregirlo
4 Los defectos se agrupan Generalmente una pequentildea parte del software desarrollado concentra la
mayor complejidad del mismo por lo que la mayoriacutea de los defectos detectados tienen una mayor
probabilidad de encontrarse en esos elementos maacutes complejos Por tanto la realizacioacuten de un buen
anaacutelisis de riesgos permite enfocar el esfuerzo de pruebas en las aacutereas del producto con mayor
probabilidad de presentar defectos
Aplicando el Principio de Pareto al control de calidad [11] el 80 de los errores y defectos estaacute causado
por un 20 del total del producto software desarrollado lo cual podriacutea ser un buen principio sobre el
que basar el anaacutelisis de riesgos
5 Cuidado con la paradoja del pesticida Si las mismas pruebas se repiten una y otra vez con el tiempo
los mismos casos de pruebas ya no encontraraacuten nuevos defectos lo cual no quiere decir que la aplicacioacuten
presente una ausencia completa de los mismos (Las pruebas ya no son eficaces para detectar defectos
al igual que los pesticidas ya no son eficaces para matar insectos despueacutes de un tiempo) Para detectar
nuevos defectos es necesario que las pruebas existentes y los datos de las pruebas deban cambiar
ademaacutes de surgir la necesidad de disentildear nuevas pruebas
48
6 Las pruebas dependen del contexto Cada empresa organizacioacuten o proyecto adaptaraacute el proceso de
pruebas a sus necesidades recursos disponibles o aacutereas de riesgo existentes
7 La ausencia de errores es una falacia Un producto software puede tener un 100 de casos de eacutexito
en su fase de pruebas pero esto solo indica que hay defectos que auacuten no han sido localizados e
identificados
33 Proceso de Pruebas de Software Anaacutelisis disentildeo e implementacioacuten
Partiendo de los principios detallados en la seccioacuten anterior se presentan las diferentes etapas del proceso de
pruebas de software asiacute como la documentacioacuten generada en cada etapa
331 Terminologiacutea
Previamente se presentaraacuten algunos teacuterminos y definiciones que convienen describir para una mejor
comprensioacuten de todo el proceso de pruebas [3]
Figura 16 Terminologiacutea para el proceso de pruebas
1 Condicioacuten de prueba Elemento o evento de un componente o sistema que puede ser verificado por
uno o maacutes casos de prueba Los diferentes requisitos que definen la funcionalidad de un sistema pueden
ser descompuestos en diferentes condiciones de prueba
2 Caso de prueba conjunto de valores de entrada precondiciones de ejecucioacuten y valores esperados
Estos son desarrollados para perseguir un objetivo particular por ejemplo una condicioacuten de prueba
3 Precondicioacuten Condiciones de entorno y estado que deben ser satisfechas antes de que un componente
o sistema pueda ser sometido a un caso de prueba o conjunto de estos
4 Abstraccioacuten de casos de prueba Consiste en la generalizacioacuten de los casos de prueba especiacuteficos sin
valores concretos para sus entradas condiciones de prueba o valores esperados En resumen no es maacutes
que llevar las condiciones de prueba a un caso general para cualquier valor de entrada
5 Script de pruebas Una vez disentildeados los casos de prueba estos pueden ser implementados y
ejecutados por una herramienta de automatizacioacuten Un script de pruebas puede contener varios casos
de prueba
6 Paquete de pruebas Consiste en la agrupacioacuten de casos de prueba relacionados en cuanto a la
funcionalidad que automatizan sobre el sistema
7 Programacioacuten de la ejecucioacuten de pruebas Describen el flujo de ejecucioacuten de los diferentes paquetes
de pruebas
49
332 Proceso de Pruebas de Software
No existe un proceso de pruebas universal pero existen conjuntos comunes de actividades de prueba sin las
cuales las pruebas disentildeadas e implementadas tendriacutean menos probabilidad de alcanzar sus objetivos
establecidos Estos conjuntos de actividades de prueba constituyen un proceso de pruebas
Como se ha mencionado en secciones anteriores el proceso de pruebas se debe iniciar en las fases maacutes iniciales
del ciclo de vida de un proyecto Por tanto las actividades del proceso de pruebas la manera en que se
implementan dichas actividades y cuaacutendo ocurren pueden ser discutidas en la estrategia de pruebas de una
organizacioacuten
A continuacioacuten se exponen las etapas fundamentales del proceso de pruebas detallando en cada una de ellas la
documentacioacuten generada y coacutemo contribuyen a la mejora de la calidad del producto con su aplicacioacuten en el ciclo
de vida de un proyecto [13]
Figura 17 Proceso de Pruebas de Software
3321 Planificacioacuten y Control de Pruebas
La planificacioacuten consiste en determinar los diferentes objetivos de las pruebas realizadas sobre el Sistema bajo
test las especificaciones y los recursos que se necesitaraacuten para llevar a cabo la fase de pruebas y cumplir con los
objetivos planteados
Es en este punto donde se define el alcance de las pruebas a realizar de forma que se selecciona lo que seraacute y
no seraacute testeado ademaacutes de indicar quieacuten haraacute cada prueba y como la llevaraacute a cabo Mediante los objetivos de
las pruebas se puede establecer un punto de finalizacioacuten del proceso
Como salida de la actividad de planificacioacuten se obtendriacutea el ldquoPlan de Pruebasrdquo el cual documenta la estrategia
y el alcance de las pruebas la prioridad en cuanto a su realizacioacuten y las estimaciones temporales para su
evaluacioacuten ademaacutes de los recursos materiales y humanos para llevarlas a cabo
Es crucial que dicho documento sea validado por el personal correspondiente del proyecto antes de continuar
con las siguientes etapas del proceso de pruebas
Por otro lado el control de pruebas es una actividad desarrollada durante todo el ciclo de vida del proceso de
pruebas el cual permite contrastar el progreso actual con el plan original trazado para la aplicacioacuten de dicho
proceso incluyendo informes y desviaciones
Cuando se produce una desviacioacuten del plan original que introduce cierto riesgo adicional puede hacerse
necesario modificar los objetivos fijados para asegurar la calidad del producto De ahiacute que sea sumamente
importante tener en consideracioacuten la documentacioacuten generada en antiguos proyectos
50
3322 Anaacutelisis y Disentildeo de Pruebas
Una vez planificado el alcance y objetivos de las pruebas se realiza una actividad de anaacutelisis donde se traducen
a condiciones de prueba y posteriormente se disentildean los casos de prueba de alto nivel a partir de la abstraccioacuten
de los casos de prueba
Por otro lado cabe destacar la necesidad de un mecanismo que garantice la trazabilidad con la finalidad de
mantener alineados en todo momento los casos de prueba con los objetivos de la misma incluso contemplando
la posibilidad de que los objetivos puedan cambiar en alguacuten momento del proceso de pruebas
El documento generado en esta actividad es conocido como ldquoespecificaciones de disentildeo de pruebasrdquo
3323 Implementacioacuten y Ejecucioacuten de Pruebas
Dicha etapa consiste en la implementacioacuten de los casos de prueba de alto nivel que cumplen con las
especificaciones de disentildeo de la etapa anterior Es en esta fase donde se haraacute uso de herramientas para la
implementacioacuten y ejecucioacuten de las pruebas
Cabe destacar que para llevar a cabo dicha etapa en cuanto a la verificacioacuten y validacioacuten funcional de un
proyecto es necesario que durante la etapa de desarrollo se haya creado un producto funcional sobre el cual
puedan ejecutarse las pruebas
Durante la ejecucioacuten de las pruebas los resultados obtenidos quedaraacuten documentados en un documento
denominado ldquoRegistro de Pruebasrdquo el cual contiene todas las pruebas realizadas y un ldquoReporte de Incidenterdquo
por cada resultado no esperado que se haya detectado
Una vez sean corregidos los incidentes se debe volver a ejecutar las pruebas con la finalidad de asegurar que
dicho incidente haya sido corregido ademaacutes de asegurar que la correccioacuten realizada no haya introducido otros
defectos o errores Esto es lo que se denomina ldquoPruebas de Regresioacutenrdquo
3324 Evaluacioacuten de los criterios de eacutexito y Elaboracioacuten de reportes e informes
Tras la ejecucioacuten de las pruebas se deben evaluar los criterios de eacutexito los cuales han sido definidos en la etapa
de planificacioacuten
El personal responsable e involucrado en el proyecto se reuniraacute y revisaraacute el cumplimiento de dichos criterios
el registro de pruebas obtenido y los reportes de incidentes que hayan podido ser abiertos en la etapa anterior
Finalmente como resultado de dicha actividad se elabora un ldquoSumario final de Pruebasrdquo
3325 Cierre de la fase de pruebas
Las actividades de cierre de la fase de pruebas se centran mayormente en asegurar que todo el ciclo de vida del
proceso de pruebas se ha cumplido ademaacutes de analizar las posibles mejoras y defectos en las fases llevadas a
cabo
Ademaacutes se lleva a cabo el cierre de los incidentes corregidos y la liberacioacuten de los entornos y recursos asignados
a la fase de pruebas
51
34 Clasificacioacuten de Pruebas de Software
Existen diversos tipos de pruebas las cuales pueden ser clasificadas en funcioacuten del objetivo de prueba para lo
cual hayan sido establecidos Cada tipo de prueba persigue unos objetivos especiacuteficos sobre el producto pero
todas ellas persiguen como objetivo comuacuten ofrecer un producto con garantiacutea de calidad al cliente o usuario final
Dichas pruebas pueden ser clasificadas en cuatro tipos
Figura 18 Clasificacioacuten de Pruebas de Software
341 Pruebas Funcionales
Tambieacuten conocidas como ldquoPruebas de caja Negrardquo En [14] la IEEE define este tipo de pruebas como
ldquoPruebas que ignoran los mecanismos internos de un sistema o componente y se enfocan
solamente en las salidas generadas como respuesta a las entradas seleccionadas y a las
condiciones de ejecucioacutenrdquo
Figura 19 Pruebas de Caja Negra
Atendiendo a la definicioacuten anterior el sistema o componente sujeto a pruebas debe realizar una funcioacuten
determinada Estaraacute descrita en las especificaciones funcionales y se pueden llevar a cabo a cualquier nivel
Dichas especificaciones funcionales describen el comportamiento del sistema sin revelar informacioacuten acerca de
su implementacioacuten interna
Un tipo especial de prueba funcional son las ldquoPruebas de Humordquo o ldquoSmoke Testsrdquo Este tipo de pruebas suele
realizarse en fases tardiacuteas del desarrollo y permiten asegurar que las funcionalidades baacutesicas del software
responden adecuadamente
Por tanto dichas pruebas pueden quedar lejos de ser pruebas exhaustivas aunque siacute permiten asegurar que el
producto entregado al cliente cumple con los requisitos de funcionamiento establecidos Este tipo de pruebas
son las que se han implementado y automatizado en el proyecto presente lo cual se detallaraacute en capiacutetulos
posteriores
52
342 Pruebas No Funcionales
Este tipo de pruebas estaacuten orientadas a verificar coacutemo de bien funciona el sistema bajo pruebas en lugar de la
funcionalidad que ofrece Por ello pueden ser agrupadas tambieacuten dentro de la categoriacutea de pruebas de caja negra
Atendiendo al estaacutendar de evaluacioacuten del producto software ldquoISO 25000rdquo todas las caracteriacutesticas excepto la de
funcionalidad definen caracteriacutesticas de calidad no funcionales de un producto software Estas caracteriacutesticas de
calidad tienen su correspondiente tipo de prueba
3421 Pruebas de Rendimiento
Las pruebas de rendimiento son usadas para determinar la rapidez con la que se realiza una tarea en el sistema
bajo unas condiciones particulares de trabajo Estas pruebas tambieacuten pueden ser usadas para validar y verificar
otros atributos de calidad del sistema tales como la escalabilidad fiabilidad y uso de recursos
Figura 20 Pruebas de Rendimiento
3422 Pruebas de Carga
Este tipo de pruebas miden el rendimiento del sistema con una carga de trabajo manejable y conocida Se trata
de someter al sistema a cargas de trabajo controladas por el ingeniero de pruebas para validar prestaciones de
rendimiento sobre el sistema
Figura 21 Pruebas de Carga
3423 Pruebas de Estreacutes
Las pruebas de estreacutes ponen a prueba la robustez y confiabilidad del sistema sometieacutendolo a condiciones de uso
extremas Entre estas condiciones se incluyen el enviacuteo masivo de peticiones y la ejecucioacuten en condiciones de
hardware limitadas Dichas condiciones van maacutes allaacute de los liacutemites de operacioacuten considerados en el disentildeo
Figura 22 Pruebas de Estreacutes
53
3424 Pruebas de Usabilidad
Estas pruebas se centran en encontrar problemas de la interfaz de usuario que podriacutean hacer que el software sea
difiacutecil de utilizar o podriacutean causar que los usuarios mal interpreten las salidas Por tanto permiten medir coacutemo
de atractivo resulta un producto software basaacutendose en la facilidad de adaptacioacuten y uso por parte de los clientes
Figura 23 Pruebas de Usabilidad
3425 Pruebas de Fiabilidad
Prueban el rendimiento del sistema ante un determinado nuacutemero de operaciones o tras cierto periodo de
tiempo
3426 Pruebas de Instalacioacuten
Las pruebas de instalacioacuten tienen dos propoacutesitos El primero es asegurar que el sistema puede ser instalado
en todas las configuraciones posibles tales como nuevas instalaciones actualizaciones instalaciones
completas o personalizadas y bajo condiciones normales o anormales estas uacuteltimas incluyen insuficiente
espacio en disco falta de privilegios para algunas tareas etc
El segundo propoacutesito es verificar que una vez instalado el sistema opera correctamente Esto usualmente
implica ejecutar un nuacutemero significativo de pruebas de Funcionalidad
Por tanto miden coacutemo de sencillo resulta instalar la aplicacioacuten en distintas plataformas o entornos
3427 Pruebas de Portabilidad
Miden coacutemo de sencillo resulta migrar una aplicacioacuten de una plataforma a otra
Figura 24 Pruebas de Portabilidad
54
343 Pruebas Estructurales
Este tipo de pruebas son tambieacuten conocidas como ldquoPruebas de Caja Blancardquo En [14] la IEEE define este tipo
de pruebas como
ldquoPruebas que tienen en cuenta los mecanismos internos de un sistema o componenterdquo
Figura 25 Pruebas de Caja Blanca
Atendiendo a dicha definicioacuten estas pruebas tienen en cuenta la estructura del coacutedigo fuente del software a partir
del cual se seleccionan los diferentes casos de prueba guiaacutendose por la existencia de sentencias condicionales
bucles etc
Por tanto los casos de prueba son desarrollados usando criterios de cobertura para el coacutedigo del programa De
esta forma el sistema bajo pruebas se trata como una caja de cristal que permite ver su estructura
El criterio de cobertura hace referencia a cada miacutenima unidad de coacutedigo que puede ser probada de forma
independiente Es frecuente usar este tipo de pruebas en los niveles de prueba maacutes bajos como por ejemplo en
las ldquoPruebas Unitariasrdquo o las ldquoPruebas de Componenterdquo
344 Pruebas debidas a Cambios
Finalmente en el proceso de pruebas tras ejecutar las pruebas y encontrar un defecto o error en el sistema bajo
pruebas este se corrige pero es necesario validar la correccioacuten realizada para confirmar que el fallo no se
reproduce A este proceso se le denomina ldquoPrueba de confirmacioacuten o re-testingrdquo
Ademaacutes las correcciones pueden ser validadas pero tambieacuten es necesario asegurar que los cambios introducidos
para corregir dicho fallo no han provocado maacutes defectos Por tanto puede concluirse que es necesario volver a
realizar pruebas sobre el resto del sistema Estas son las ldquoPruebas de Regresioacutenrdquo
35 Niveles de Prueba
El proceso de pruebas es una etapa del ciclo de vida de un proyecto cuyas actividades estaacuten completamente
relacionadas con las actividades del proceso de desarrollo Existen diversos modelos que describen las fases y
actividades del proceso de desarrollo de software En esta seccioacuten se detallaraacute el uso del ldquoModelo de desarrollo
en Vrdquo
Este modelo describe las diferentes fases del proceso de desarrollo y sugiere la realizacioacuten de pruebas en cada
una de ellas Estas pruebas seraacuten ejecutadas posteriormente en orden ascendente Por tanto para cada fase existen
unos objetivos a cumplir los cuales deben ser probados para medir la integridad del trabajo realizado
55
A continuacioacuten se detallaraacuten los diferentes niveles de prueba para cada etapa del desarrollo software atendiendo
al modelo de desarrollo en V
Figura 26 Modelo de desarrollo en V
351 Pruebas a Nivel de Componente
Tambieacuten llamadas ldquoPruebas Unitariasrdquo El objetivo de estas pruebas es el de cubrir la unidad miacutenima funcional
que compone el software Estos componentes suelen tener una uacutenica funcioacuten especiacutefica la cual seraacute usada por
el resto del Sistema A menudo son realizadas por los propios desarrolladores haciendo uso de la metodologiacutea
de desarrollo guiado por prueba o Test-Driven-Development (TDD)
352 Pruebas a Nivel de Integracioacuten
Son aquellas pruebas realizadas en el aacutembito del desarrollo software una vez validadas las pruebas unitarias
Estas pruebas verifican que todos los elementos unitarios que componen el software funcionan en conjunto de
forma correcta Se centran principalmente en probar la comunicacioacuten entre los diferentes componentes del
sistema
353 Pruebas a Nivel de Aceptacioacuten
Este uacuteltimo nivel se centra en las necesidades del usuario requisitos y procesos de negocio con el fin de
determinar si el sistema satisface los criterios de aceptacioacuten acordados con el cliente en un contrato o acuerdo
de nivel de servicio en caso de ser un software de uso interno dentro de una compantildeiacutea
Ejemplos de este tipo de pruebas pueden ser las ldquoPruebas Alfa y Betardquo
Como se ha detallado anteriormente las pruebas desarrolladas y automatizadas en este Proyecto son ldquoPruebas
de humordquo o Smoke Tests Estas pruebas se centran en la verificacioacuten y validacioacuten de las especificaciones de uso
de un Sistema en este caso de la plataforma Web de gestioacuten Galgus CHT Manager
56
36 Dificultades de pruebas en aplicaciones Web e impacto
La complejidad antildeadida de las aplicaciones y servicios Web frente a otros tipos de aplicaciones recae sobre el
uso de muacuteltiples tecnologiacuteas de vanguardia que permiten la construccioacuten de sistemas distribuidos con un amplio
grado de escalabilidad accesibilidad disponibilidad interoperabilidad e independencia del hardware
Como consecuencia del incremento de la complejidad de las aplicaciones surgen nuevos paradigmas como la
Arquitectura Orientada a Servicios (SOA) la cual permite interoperabilidad y flexibilidad de las aplicaciones
distribuidas
Todo ello conlleva a plantearse queacute se deberiacutea hacer para garantizar que una aplicacioacuten Web puesta en marcha
funciona de acuerdo a los requisitos definidos y acordados con el cliente Podriacutean optimizarse y mejorarse los
diferentes procesos dentro del ciclo de vida de un proyecto pero siempre la fase de pruebas termina siendo la
fase previa a la puesta en marcha de la aplicacioacuten con lo que resulta siendo la uacuteltima oportunidad para detectar
posibles fallos que puedan terminar en ocasiones en peacuterdidas econoacutemicas de prestigio de fiabilidad y de
credibilidad por parte de los clientes
Realizar pruebas en una aplicacioacuten Web no es tarea faacutecil ya que son muchos los factores que influyen en el
testeo del sistema para abarcar y contemplar el maacuteximo de flujos posibles que se pueden llevar a cabo durante
el uso de la aplicacioacuten
Hoy en diacutea las aplicaciones Web pueden ser construidas con componentes implementados en diferentes
lenguajes y arquitecturas basaacutendose en diferentes modelos de programacioacuten y pudiendo ejecutarse en diferentes
plataformas de hardware y software
Esto incrementa la complejidad de las pruebas a realizar sobre un sistema de este tipo por lo que seriacutea interesante
plantearse la posibilidad de usar herramientas que permitan una abstraccioacuten de dicha complejidad ademaacutes de la
automatizacioacuten de la fase de pruebas En el caso de las pruebas a nivel de aceptacioacuten en este proyecto se
propondraacute el uso de herramientas que persiguen dichos fines
Figura 27 Dificultades de pruebas en aplicaciones Web e impacto
57
58
4 SISTEMA GALGUS CHT CLOUD MANAGER
ras realizar un estudio del arte sobre una teacutecnica que puede ser de gran utilidad para optimizar y
perfeccionar las teacutecnicas de automatizacioacuten para el proceso de pruebas sobre un sistema se han puesto
en contexto los diferentes tipos de pruebas que pueden realizarse sobre un sistema ademaacutes de definir
el proceso de pruebas Una vez llegados a este punto en primer lugar se realizaraacute una descripcioacuten del sistema
bajo pruebas sobre el cual se plantearaacute una solucioacuten para la fase de pruebas y su automatizacioacuten Maacutes
concretamente para la realizacioacuten de las pruebas a nivel de aceptacioacuten
41 Arquitectura y Descripcioacuten del Sistema
CHT Cloud Manager es un proyecto de la empresa Galgus el cual ofrece una plataforma Web de gestioacuten
configuracioacuten y monitorizacioacuten de redes WiFi Maacutes concretamente dicha plataforma permite gestionar un
conjunto de puntos de acceso desplegados con un conjunto de algoritmos definidos por software los cuales
permiten la optimizacioacuten de los recursos de red inalaacutembricos ofreciendo mayores prestaciones y una mayor
calidad de servicio al usuario Ademaacutes dicho software embebido ofrece otros servicios al cliente como la
localizacioacuten de estaciones dentro de la zona de alcance de la red WiFi o la deteccioacuten de intrusos y ataques de
suplantacioacuten de identidad
A este conjunto de algoritmos se le conoce bajo el nombre Cognitive Hostpot Technology (CHT) Este software
implementado en lenguaje C y preparado para sistemas embebidos como los puntos de acceso presenta una
estructura modular donde cada moacutedulo se encarga de una tarea determinada o de ejecutar un algoritmo
determinado
Figura 28 Logo de Galgus
Para permitir la comunicacioacuten con la plataforma Web CHT implementa un moacutedulo denominado MGR el cual
permite la conexioacuten con un broacuteker de eventos o intermediario para permitir el enviacuteo y la recepcioacuten de eventos
desde dicha plataforma
T
La simplicidad llevada al extremo se convierte en
elegancia
Jon Franklin
59
En la siguiente figura se muestra la arquitectura orientada a servicios para CHT Cloud Manager
Figura 29 Arquitectura de CHT Cloud Manager
Puede observarse que dicha plataforma estaacute formada por diferentes microservicios desplegados en la nube Cada
uno de ellos realiza una serie de tareas bien definidas e interactuacutean entre ellos enviando y recibiendo mensajes
haciendo uso de diferentes protocolos y modelos de comunicacioacuten
De esta forma se consigue mantener actualizado el estado de la informacioacuten de los diferentes elementos en
tiempo real sobre los diferentes eventos que puedan ocurrir en el sistema Dichos eventos proceden en su gran
mayoriacutea del conjunto de puntos de acceso que conforma una red de Galgus la cual pretende ser gestionada desde
la plataforma en cuestioacuten
A continuacioacuten se detallaraacuten los diferentes microservicios que conforman dicha plataforma ademaacutes de describir
a los puntos de acceso con la tecnologiacutea CHT como elementos a gestionar desde dicha plataforma
60
411 Puntos de Acceso (OpenWRT + CHT)
4111 OpenWRT
Los puntos de acceso WiFi de Galgus son sistemas embebidos de diferentes modelos en funcioacuten de las
especificaciones hardware que ofrezcan (nuacutemero de streams espaciales nuacutemero de antenas de exterior de
interior etc)
Todos ellos tienen en comuacuten el uso de OpenWRT como sistema operativo Este se trata de un sistema operativo
open source basado en Linux y usado para sistemas de red embebidos Todos los componentes de dicho sistema
han sido optimizados para dispositivos con limitaciones de hardware y este permite configurarlos mediante
interfaz de liacutenea de comandos o mediante una interfaz Web (LuCI) [15]
Partiendo de dicho sistema operativo Galgus desarrolla CHT como producto software que dota a los puntos de
acceso de una serie de prestaciones en una serie de moacutedulos Dicho producto es ofrecido al cliente mediante
licencias las cuales son gestionadas desde un servidor de licencias y obtenidas por los puntos de acceso de
forma automaacutetica Todo ello se detallaraacute maacutes adelante
4112 CHT
CHT tambieacuten ofrece su propia interfaz de liacutenea de comandos denominada CHT_CLI Esta herramienta permite
configurar los distintos moacutedulos de los que se compone CHT y obtener informacioacuten tanto de la configuracioacuten
como del funcionamiento de los algoritmos CHT
A continuacioacuten se presenta la interfaz y algunos de los comandos que se pueden utilizar
Figura 30 CHT_CLI
CHT_CLI es fundamental tanto en el desarrollo como en el testeo de CHT y CHT Cloud Manager ya que nos
permite acceder a paraacutemetros de configuracioacuten que no estaacuten accesibles desde la interfaz graacutefica LuCI Desde
CHT_CLI se controlan todos los moacutedulos de CHT entre los que se pueden destacar los siguientes Load Balance
(LB) Smart Roaming (SR) Power Control (POWER) Localization (LOC) Traffic Congestion Management
(TCM) Smart Band Steering (SB) y el moacutedulo Manager (MGR)
En este caso es de intereacutes resaltar el moacutedulo que permite la comunicacioacuten con la plataforma de gestioacuten CHT
Cloud Manager Dicho moacutedulo conocido bajo el nombre de MGR implementa un cliente AMQP para
establecer la comunicacioacuten con el broacuteker de eventos usado como intermediario para permitir la comunicacioacuten
entre los puntos de acceso y la plataforma de gestioacuten CHT Cloud Manager
Ademaacutes implementa una serie de estructuras de datos que son enviados a traveacutes de dicho intermediario basadas
en FlatBuffers como plataforma eficiente de serializacioacuten cruzada de datos ofrecida por Google Esta
herramienta permite crear un modelo de datos bajo la sintaxis ofrecida por FlatBuffers para posteriormente
generar dichas estructuras de datos en diferentes lenguajes de programacioacuten como por ejemplo C++ C C
Go Java JavaScript etc
Con esto se consigue generar estructuras de datos con una compatibilidad absoluta que se intercambiaraacuten entre
la plataforma de gestioacuten en lenguaje Java y los puntos de acceso en lenguaje C
61
412 Broacuteker de Eventos AMQP (RabbitMQ)
Este microservicio implementa un broacuteker de eventos que actuacutea como intermediario entre los puntos de acceso
WiFi y algunos microservicios que componen la plataforma Web de gestioacuten Se basa en el protocolo AMQP el
cual sigue el patroacuten publicadorsuscriptor como paradigma de comunicacioacuten indirecta
Estaacute involucrado en la entrega de mensajes entre los diferentes dispositivos embebidos con CHT y sus
respectivos servicios de gestioacuten en la plataforma Web de forma que los agentes que publican y consumen
eventos en el broacuteker no necesitan conocer al destinatario si no que el broacuteker es el que se encarga de publicar los
eventos para los destinatarios suscritos a eacutel En la siguiente figura se muestra la interfaz graacutefica de gestioacuten de
RabbitMQ [16]
Figura 31 Plataforma de Gestioacuten de RabbitMQ
Un broacuteker de eventos es un elemento del patroacuten PublicadorSuscriptor que recibe y mensajes de un conjunto de
elementos de red que quieren comunicarse ejecutan mecanismos de filtrado y permite la entrega correcta de los
diferentes mensajes a los consumidores correspondientes Por tanto el broacuteker de eventos permite ofrecer un
desacoplamiento entre emisores y receptores de la informacioacuten siendo este responsable de las tareas de
encaminamiento y reenvioacute de mensajes En conclusioacuten es responsable de coordinar la comunicacioacuten
proporcionando transparencia de acceso y localizacioacuten permitiendo la localizacioacuten de emisores y receptores
mediante un sistema de identificadores uacutenicos
Figura 32 Patroacuten PublicadorSuscriptor
62
413 Frontend
El Frontend de la plataforma Web estaacute implementado con Angular 6 HTML5 y CSS3 Su finalidad es ofrecer
una interfaz graacutefica al usuario final la cual permite mostrar el estado de los diferentes Zone Managers ademaacutes
de permitir el acceso a estos y gestionar el conjunto de puntos de acceso registrados en ellos de forma raacutepida e
intuitiva
Este microservicio recibe informacioacuten proporcionada por MoMap y los diferentes Zone Managers La
aplicacioacuten se sirve mediante un servidor Apache el cual proporciona una comunicacioacuten fiable con HTTPS
implementando una capa de transporte segura mediante el protocolo TLS
414 Zone Manager
Microservicio responsable de gestionar un conjunto de puntos de acceso CHT los cuales forman un despliegue
de red WiFi de Galgus para un cliente determinado Este microservicio estaacute formado por un servicio Web REST
implementado con Java Spring Framework desplegado en un servidor Jetty embebido y cuya persistencia se ha
implementado a traveacutes de Hybernate con el uso de Postgress SQL como gestor de bases de datos relacional
Un Zone Manager ofrece todas las tareas y acciones necesarias para configurar un conjunto de puntos de acceso
y consultar datos estadiacutesticos de usuarios conectados a dichos puntos de acceso entre otras Cabe destacar en
este punto la importancia que tiene el uso de FlatBuffers para garantizar la compatibilidad de datos enviados y
recibidos entre los puntos de acceso y el Zone Manager ambos implementados en tecnologiacuteas totalmente
diferentes
Figura 33 Ejemplo de Interfaz Graacutefica de un Zone Manager
63
415 MoMap
Dicho microservicio implementado en NodeJS gestiona y administra toda la infraestructura que conforma la
plataforma Web Establece y mantiene todas las conexiones y relaciones entre los diferentes puntos de acceso
con CHT y los Zone Managers (ZMB) que los gestiona
Ademaacutes este microservicio implementa una serie de maacutequinas de estado que permiten controlar el estado de
todos los Zone Managers y puntos de acceso CHT alertando sobre los eventos de error conexioacuten o desconexioacuten
en tiempo real a los usuarios finales a traveacutes del Frontend El soporte a la persistencia para dicho microservicio
se proporciona mediante MongoDB
Por tanto el microservicio MoMap actuacutea como proxy inverso HTTP2 Cuando un usuario intenta acceder a
traveacutes del Frontend de la plataforma Web puede gestionar y administrar un conjunto de Zone Managers o
administrar usuarios y asignar roles y permisos Tambieacuten se permite la creacioacuten eliminacioacuten y conexioacuten con un
Zone Manager redirigiendo las peticiones hacia el mismo
Cuando ocurre un evento de conexioacuten con un Zone Manager desde el microservicio MoMap se recupera y
enviacutea la informacioacuten necesaria para mostrar toda la informacioacuten correspondiente a ese Zone Manager en el
Frontend para el usuario final En la siguiente figura se muestra la interfaz graacutefica ofrecida por el servicio
MoMap a traveacutes del Frontend
Figura 34 Ejemplo de Interfaz Graacutefica de MoMap
64
416 Servidor de Licencias
El objetivo principal de este servicio es proporcionar una aplicacioacuten con una gestioacuten y control centralizado de
las licencias de todos los Puntos de Acceso desplegados con CHT Este servidor desplegado con Jetty de forma
embebida almacena el registro de un conjunto de Puntos de Acceso CHT para un conjunto de Clientes y
proyectos determinados Proporciona una API REST implementada con Java Spring Framework que permite
el registro de dichos dispositivos y la asignacioacuten de licencias CHT para habilitar los diferentes moacutedulos de dicha
aplicacioacuten embebida sobre los Puntos de Acceso Ademaacutes proporciona una interfaz Web de usuario
implementada con Angular 6 HTML5 y CSS3
En la siguiente figura se muestra un ejemplo de dicha interfaz graacutefica
Figura 35 Interfaz Graacutefica del Servidor de Licencias
4161 Zero-Touch Provisioning (ZTP)
En el contexto de la automatizacioacuten de redes WiFi el aprovisionamiento sin contacto es una caracteriacutestica
que permite que los puntos de acceso de una red se configuren automaacuteticamente evitando la intervencioacuten
humana para su configuracioacuten La configuracioacuten manual de dispositivos y conmutadores es costosa y
requiere lo que a menudo puede ser una gran cantidad de tiempo y esfuerzo dependiendo del tamantildeo de la
red [17]
Con el uso de sistemas automaacuteticos de aprovisionamiento y configuracioacuten se consigue reducir la carga de
trabajo y el esfuerzo que normalmente se requiere cuando se instalan y configuran nuevos dispositivos
Figura 36 Zero-Touch Provisioning (ZTP)
65
Haciendo uso de esta caracteriacutestica Galgus implementa en su infraestructura orientada a microservicios
un acceso directo de los Puntos de Acceso al servidor para que soliciten su licencia de CHT
automaacuteticamente de forma que cuando el usuario final vaya a instalar un Punto de Acceso CHT dicho
dispositivo obtendraacute su licencia de forma segura a traveacutes de la API REST del servidor de licencias siempre
y cuando esteacute registrado en el mismo y disponga de licencia sin necesidad de que el usuario intervenga en
dicho proceso
La comunicacioacuten entre los puntos de acceso y el resto de la infraestructura se realiza a traveacutes de un broacuteker
de eventos AMQP con su implementacioacuten en RabbitMQ Debido a esto cuando se crea y asigna licencia
a un dispositivo en el servidor de licencias dicho servidor crea un usuario en RabbitMQ de forma que el
punto de acceso en el momento que obtiene su licencia intentaraacute establecer conexioacuten con el broacuteker para
permitir el intercambio de eventos con los microservicios que lo gestionaraacuten mediante la plataforma CHT
Cloud Manager
Una vez el punto de acceso establece conexioacuten con el broacuteker de eventos este podraacute ser descubierto por el
Zone Manager que lo gestionaraacute El microservicio MoMap se encarga de establecer el descubrimiento de
los puntos de acceso comprobando si el punto de acceso estaacute registrado en el servidor de licencias con
licencia asignada y verificando que el punto de acceso estaacute operativo con conexioacuten a internet
42 Alcance y Objetivos de las pruebas sobre el sistema planteado
Una vez presentada y descrita toda la arquitectura de la plataforma Web ofrecida por Galgus se procederaacute a
detallar los principales objetivos del proceso de pruebas que se pretenderaacute conseguir sobre dicha aplicacioacuten Para
ello inicialmente se presentaraacute en queacute punto se encontraba el proceso de pruebas inicialmente
En este proyecto se ha centrado la atencioacuten en el conjunto de pruebas funcionales realizadas a la aplicacioacuten maacutes
concretamente las pruebas a nivel de aceptacioacuten
Dentro de las pruebas a nivel de aceptacioacuten los ingenieros de prueba hasta ahora habiacutean disentildeado un plan de
pruebas de aceptacioacuten o tests End-to-End los cuales se ejecutaban verificaban y validaban manualmente por
los ingenieros de QA Dicho plan de pruebas estaacute formado por una bateriacutea de casos de prueba a realizar sobre
las diferentes funcionalidades del sistema A continuacioacuten se muestra un fragmento de dicho plan de pruebas
Figura 37 Test Plan de CHT Cloud Manager
Como puede observarse en la figura anterior dicho plan de pruebas contiene un conjunto de casos de prueba
cada uno de ellos con un identificador uacutenico una descripcioacuten algunas especificaciones o detalles necesarios un
indicador de eacutexito o fallo y finalmente la descripcioacuten de los resultados obtenidos
Ademaacutes en dicho test plan se incluye una cabecera y una leyenda para clasificar los distintos resultados
obtenidos en la ejecucioacuten de las pruebas registrar algunos datos de relevancia y tener archivado dicho plan de
pruebas con las versiones de los diferentes microservicios que componen la plataforma Web
66
Figura 38 Leyenda del Test Plan
Figura 39 Control de Versiones del Test Plan
Una vez presentado el estado actual del proceso de pruebas a nivel de aceptacioacuten el nuevo equipo encargado de
evaluar la calidad de la plataforma Web planteoacute la oportunidad de automatizar dicho plan de pruebas Por tanto
el principal objetivo de este proyecto ha sido el de automatizar las actividades de ejecucioacuten y generacioacuten de
reportes de las pruebas de aceptacioacuten automatizadas sobre la aplicacioacuten
Sin embargo las actividades de planificacioacuten disentildeo e implementacioacuten de los diferentes casos de prueba se
realizaraacuten de forma manual haciendo uso de un conjunto de tecnologiacuteas que se usaraacuten para desarrollar la
automatizacioacuten de dichas pruebas Dichas tecnologiacuteas principalmente son Robot Framework Selenium y
Python las cuales se detallaraacuten maacutes adelante
En este punto es donde podriacutea entrar en juego la aplicacioacuten de Model-Based-Testing (MBT) detallado en la
seccioacuten 2 de este proyecto como teacutecnica que permite la abstraccioacuten de la actividad de implementacioacuten del plan
de pruebas mejorando el proceso de pruebas e independizando este de las actividades de desarrollo
En este proyecto queda fuera del alcance la aplicacioacuten de dicha teacutecnica debido a la necesidad de disponer de un
disentildeo completo y detallado de la plataforma Web para permitir la generacioacuten de los casos de prueba abstractos
y su posterior generacioacuten automaacutetica de los casos de prueba ejecutables Es de intereacutes destacar que a lo largo
del desarrollo del proyecto han ido surgiendo otros objetivos de intereacutes para mejorar el proceso de pruebas los
cuales permiten agilizar dicho proceso y ampliar su alcance
Entre estos objetivos se encuentran la generacioacuten automaacutetica de documentacioacuten del plan de pruebas la
implementacioacuten de un entorno de UAT (User Acceptance Testing) con Docker la integracioacuten de las pruebas a
nivel de aceptacioacuten en el proceso de integracioacuten continua del proyecto o la creacioacuten de un Docker que permita
ejecutar todo el plan de pruebas Todos estos objetivos se iraacuten detallando maacutes adelante
67
43 Arquitectura de la Solucioacuten Entorno de UAT para el proceso de pruebas (User Acceptance Test)
Hasta ahora dentro del proceso de desarrollo de la plataforma Web existiacutean las siguientes fases etapas o
entornos Desarrollo Preproduccioacuten y Produccioacuten
Bajo este contexto las actividades del proceso de pruebas eran realizadas sobre la fase de Preproduccioacuten Esto
provocaba una dependencia directa del cierre de la mayoriacutea de actividades de desarrollo para el despliegue en la
fase de Preproduccioacuten Como consecuencia la fase de pruebas a nivel de aceptacioacuten se podriacutea ver perjudicada
por esta metodologiacutea provocando en muchas ocasiones el retraso en el feedback necesario por los ingenieros de
desarrollo de los reportes e informes generados al ejecutar las pruebas de aceptacioacuten Para mejorar este proceso
se ha disentildeado un nuevo entorno de UAT en el proceso de desarrollo que permita disminuir la dependencia del
proceso de pruebas y desarrollo La inclusioacuten de este nuevo entorno ha sido posible gracias a la mejora del
proceso de integracioacuten continuacutea implementado en el desarrollo de la plataforma
Dentro de este proceso de integracioacuten continua se realiza la generacioacuten automaacutetica de los Docker que contienen
los diferentes microservicios de la plataforma Web en cualquier etapa del proceso de desarrollo Ademaacutes dentro
del proceso de integracioacuten continua se ha automatizado por parte de los ingenieros de desarrollo la ejecucioacuten
de pruebas unitarias y de integracioacuten que garantizan una miacutenima garantiacutea de estabilidad funcional de la
plataforma necesaria para el proceso de pruebas Partiendo de este punto el equipo de calidad ha disentildeado un
entorno de UAT con Docker el cual se muestra de forma graacutefica en la siguiente figura
Figura 40 Entorno de UAT con Docker (Anexo B)
68
69
5 TECNOLOGIacuteAS Y HERRAMIENTAS USADAS
na vez descrito el sistema bajo pruebas y presentada la arquitectura de la solucioacuten para el escenario de
pruebas con Docker se expondraacute a continuacioacuten el conjunto de tecnologiacuteas y herramientas usadas para
llevar a cabo el desarrollo de las pruebas automatizadas de aceptacioacuten o pruebas End-to-End Con este
conjunto de herramientas se pretende conseguir la implementacioacuten de los diferentes scripts de pruebas que
automaticen las acciones e interacciones necesarias con la plataforma Web CHT Cloud Manager como si de
una persona se tratase
51 Selenium
Selenium es una herramienta de coacutedigo abierto utilizada para la automatizacioacuten de pruebas en navegadores web
Dicha herramienta posee una enorme popularidad en el mundo de las pruebas de software debido a que
Presenta compatibilidad con diferentes lenguajes de programacioacuten para la implementacioacuten de scripts de
pruebas ofreciendo libreriacuteas en Java Python C PHP Ruby Perl y Net
Es multiplataforma permitiendo el lanzamiento de los scripts de pruebas en diversos sistemas
operativos como Windows Mac o Linux y en diferentes navegadores como Mozilla Firefox Internet
Explorer Google Chrome Safari y Opera
Soporta la integracioacuten con otras herramientas como TestNG o JUnit
Permite la integracioacuten continua con Maven Jenkins gitlab CICD y Docker
Sin embargo presenta una serie de inconvenientes que se deben mencionar
bull Solo permite probar aplicaciones Web
bull No hay soporte garantizado desde Selenium Muchas de las soluciones a problemas de la herramienta
han sido generadas por la comunidad
bull No es posible realizar pruebas en imaacutegenes Para ello es necesaria la integracioacuten con otras herramientas
bull No tiene capacidad nativa para generar informes o reportes de los resultados de las pruebas Para ello
se requiere el uso de un framework como puede ser el Robot Framework
Centrando la atencioacuten en el enfoque de dicho proyecto se haraacute uso de la libreriacutea Selenium para Python y la
facilidad de Robot Framework tanto para abstraer la posible complejidad antildeadida del lenguaje de programacioacuten
usado para la implementacioacuten de los scripts de prueba como para permitir la generacioacuten automaacutetica de informes
y reportes de resultados
Realmente Selenium estaacute formado por un conjunto de herramientas las cuales son Selenium RC Selenium
IDE Selenium Grid y Selenium Webdriver Dichas herramientas permiten desde la realizacioacuten de pruebas en
maacutequinas remotas a la ejecucioacuten de pruebas en diferentes maacutequinas con diferentes navegadores cada una
Con el lanzamiento de Selenium 2 en 2008 se antildeadieron nuevas funcionalidades de Selenium RC y Webdriver
en una misma herramienta aunque es frecuente mantener la nomenclatura de WebDriver a la hora de referirse
a la misma En este proyecto se centraraacute la atencioacuten en la herramienta WebDriver de Selenium
U
El disentildeo es el alma de todo lo creado por el hombre
Steve Jobs
70
52 Selenium WebDriver
Esta herramienta de Selenium ofrece una interfaz para ejecutar los casos de prueba descritos en los scripts
de prueba A traveacutes de esta API WebDriver se comunica directamente con el controlador del navegador
donde corre la aplicacioacuten Para ello seraacute necesario el uso de controladores para los diferentes navegadores
Web desde los que se validan las pruebas automaacuteticas
Todas las implementaciones de WebDriver que se comunican con el navegador usan un protocolo punto a
punto comuacuten Este protocolo define un servicio RESTfull usando JSON sobre HTTP Cada operacioacuten
realizada por WebDriver se mapea en un meacutetodo HTTP que se comunica con el navegador Las respuestas
a dichas operaciones seraacuten devueltas en mensajes HTTP de respuesta
Existen diversas implementaciones de Selenium para diferentes entornos tal y como se muestra en la
siguiente figura
Figura 41 Implementaciones disponibles de Selenium y Navegadores Web Compatibles
Para la ejecucioacuten de las pruebas implementadas en este proyecto se ha hecho uso de los controladores Gecko
Driver y Chromedriver para los navegadores Web Firefox y Google Chrome
521 Elementos del Navegador
Una vez tenemos una viacutea de comunicacioacuten con el navegador planteamos la pregunta iquesty coacutemo le indico al
navegador con queacute componente quiero interactuar
La cantidad de componentes que existen es muy amplia cajas de texto botones imaacutegenes hiperviacutenculos
botones de radio check boxes aacutereas de texto mensajes de error desplegables tablas frames etc Todos
estos elementos tienen una serie de propiedades que pueden ser uacutenicas o no en toda la paacutegina Por ejemplo
un identificador (ID) debe distinguir de manera uniacutevoca a un elemento Este identificador es lo que se
denomina un localizador Existen 8 tipos distintos de localizadores diferentes
bull Id Name Class Name Tag Name Link Text Partial Link Text CSS Xpath
71
Se podraacuten implementar las interacciones con el navegador mediante la llamada a un meacutetodo (accioacuten) que
se aplicaraacute sobre el elemento que nosotros indiquemos A continuacioacuten se muestra el diagrama de bloques
y la implementacioacuten de un ejemplo simple del inicio de sesioacuten usando Python y la libreriacutea de Selenium
Figura 42 Coacutedigo de ejemplo con Python y Selenium
La implementacioacuten anterior permite abrir un navegador Web Chrome en pantalla completa y acceder a la
plataforma Web Galgus CHT Cloud Manager Una vez ha sido posible el acceso y la paacutegina Web estaacute
disponible se realiza el inicio de sesioacuten en la plataforma con las credenciales correspondientes esperando que
dicho inicio de sesioacuten se haya realizado con eacutexito Finalmente se cierran todas las instancias de navegadores
Web abiertas por Selenium en la automatizacioacuten de dicha prueba de concepto
72
53 Robot Framework (RF)
Para la automatizacioacuten del testeo de la aplicacioacuten se ha hecho uso de este framework como herramienta
para dicha finalidad Robot Framework es un framework geneacuterico de automatizacioacuten de pruebas de coacutedigo
abierto desarrolla do por Pekka Klaumlrck en el antildeo 2005
Este framework sigue el enfoque Keyword-Driven Testing y es un candidato idoacuteneo debido a su alto nivel
de abstraccioacuten para pruebas de aceptacioacuten y desarrollo guiado por pruebas de aceptacioacuten o Acceptance
Test-Driven Development (ATDD) Las capacidades de pruebas pueden ser ampliadas con nuevas libreriacuteas
implementadas tanto en Python como en Java y los usuarios pueden crear nuevas keywords a partir de las
existentes usando la misma sintaxis que para los casos de prueba [18]
Robot Framework es independiente del sistema operativo y de la aplicacioacuten El nuacutecleo del framework estaacute
implementado en Python soportando tanto Python 2 como Python 3
Se ha decidido utilizar este framework por la disponibilidad de un amplio conjunto de libreriacuteas de propoacutesito
general y la integracioacuten con libreriacuteas externas como Selenium2Library Entre otras prestaciones permite el
uso de variables que aportan mayor flexibilidad a la hora de disentildear y controlar los scripts de prueba
permite el etiquetado para poder identificar y ejecutar los casos de prueba por separado proporciona una
faacutecil integracioacuten con Jenkins y Maven y proporciona un sistema de reporte de informes de resultados
detallados y de faacutecil lectura Ademaacutes hay que destacar la faacutecil abstraccioacuten que ofrece al poder utlizar
keywords de alto nivel permitiendo el uso del estilo de representacioacuten Given-When-Then para los casos
de prueba A continuacioacuten se describe dicho estilo de representacioacuten
531 Estilo de representacioacuten Given-When-Then
Dicho estilo ofrecido por Robot Framework es uno de los puntos fuertes de este framework Esta caracteriacutestica
permite el uso del siguiente estilo de representacioacuten para los casos de prueba
Figura 43 Estilo de representacioacuten Given-When-Then
bull Given Define las precondiciones necesarias para llevar a cabo la accioacuten asiacute como el actor de la
misma
bull When Accioacuten llevada a cabo por el actor definido en la claacuteusula Given
bull Then Es el comportamiento esperado o la salida del sistema esperada ante una entrada
determinada
bull And Claacuteusula auxiliar que se usa de forma combinada con las anteriores
73
Como ejemplo de aplicacioacuten de este estilo de representacioacuten supongamos que tenemos unos requisitos de
aceptacioacuten establecidos en un documento entre los que se encuentran el inicio y cierre de sesioacuten mediante
usuario y contrasentildea a la plataforma Galgus CHT Cloud Manager En la siguiente tabla se muestran los
criterios de aceptacioacuten definidos en el documento de requisitos para dicha funcionalidad
1 Un usuario no identificado puede iniciar sesioacuten desde la vista principal de la plataforma Web
2 Un usuario no identificado debe insertar un usuario y contrasentildea vaacutelidos para el inicio de sesioacuten
A continuacioacuten se muestra coacutemo se llevariacutea a cabo la implementacioacuten de los scripts de pruebas abstractos
asociados a las especificaciones anteriores haciendo uso del estilo de representacioacuten Given-When-Then
Es complicado implementar todos los casos de prueba posibles principalmente cuando el requisito de
aceptacioacuten requiere de una funcionalidad compleja En este caso se muestran tres casos de prueba
abstractos los cuales han sido implementados en el proyecto para validar el inicio y cierre de sesioacuten
Caso de Prueba 1 Inicio de Sesioacuten en Galgus CHT Cloud Manager
Claacuteusula Keyword
Given Navegacioacuten a la paacutegina principal de Galgus CHT Cloud Manager
When Insertar nombre de usuario vaacutelido
And Insertar contrasentildea vaacutelida
Then Iniciar sesioacuten con eacutexito
Caso de Prueba 2 Intento de Inicio de sesioacuten con usuario no vaacutelido
Claacuteusula Keyword
Given Navegacioacuten a la paacutegina principal de Galgus CHT Cloud Manager
When Insertar nombre de usuario invaacutelido
And Insertar contrasentildea vaacutelida
Then No es posible el inicio de sesioacuten Se muestra mensaje de error
Caso de Prueba 3 Intento de Inicio de sesioacuten con contrasentildea no vaacutelida
Claacuteusula Keyword
Given Navegacioacuten a la paacutegina principal de Galgus CHT Cloud Manager
When Insertar nombre de usuario vaacutelido
And Insertar contrasentildea invaacutelida
Then No es posible el inicio de sesioacuten Se muestra mensaje de error
74
En la siguiente figura se muestra la implementacioacuten de dichas pruebas con Robot Framework donde cada
Keyword implementada permite la abstraccioacuten de toda la funcionalidad necesaria para realizar las pruebas
Figura 44 Implementacioacuten de Pruebas en para el inicio de sesioacuten de CHT Cloud Manager
75
532 Reportes
A continuacioacuten se muestra un ejemplo de los reportes obtenidos tras la ejecucioacuten del primer caso de prueba de
los anteriores donde pueden identificarse las diversas keywords necesarias para implementar cada caso de
prueba asiacute como otras adicionales que ayudan a crear el contexto (precondiciones) Tambieacuten se incluyen
estadiacutesticas sobre el tiempo de ejecucioacuten nuacutemero de tests total nuacutemero de tests que han fallado o que han pasado
con eacutexito [18]
Figura 45 Ejemplo de reporte de pruebas automatizadas con Robot Framework
76
533 Libreriacuteas
Robot Framework permite el uso de Selenium mediante la libreriacutea de pruebas Web SeleniumLibrary Dicha
libreriacutea es compatible con las versiones de Selenium 2536 y sucesivas y con Python 27 y Python 3 Ademaacutes
del inteacuterprete por defecto de Python esta libreriacutea funciona tambieacuten con PyPy y Jython [18]
Esta libreriacutea estaacute compuesta entre otras muchas por una serie de archivos de Python (py) que implementan
las clases que contienen las diversas keywords que pueden ser usadas en nuestro framework La estructura de
estos archivos se presenta en la siguiente tabla
Archivo de Clase Funcioacuten
Alertpy Interacciones con mensajes de alerta
Browsermanagementpy Apertura cierre y cambio de navegadores
Cookiepy Manipulacioacuten de cookies del navegador
Elementpy Interaccioacuten con elementos y sus atributos
Formelementpy Interaccioacuten con elementos en formularios
Framespy Manejo de frames y su contenido
Javascriptpy Facilidades para inyectar coacutedigo javascript
Runonfailurepy Uso de funcionalidades en caso de fallo
Screenshotpy Manejo de capturas de pantalla
Selectelementpy Manejo de elementos en listas
Tableelementpy Manejo de elementos en tablas
Waitingpy Manejo de temporizadores de espera para
transiciones en una paacutegina
Webdrivertoolspy Interaccioacuten directa con el controlador del navegador
Windowpy Manejo de ventanas del navegador
Estas libreriacuteas fueron desarrolladas en sus oriacutegenes por el ingeniero finlandeacutes Tatu Aalto y posteriormente
mejoradas por toda la comunidad de expertos en automatizacioacuten de pruebas Sin embargo Robot Framework
mediante el uso de Python con Selenium permite la implementacioacuten de libreriacuteas propias o funcionalidades
desarrolladas en Python que pueden ser integradas en Robot Framework En este proyecto se hace uso de Python
con Selenium para desarrollar algunas funcionalidades avanzadas que permiten probar ciertos criterios de la
aplicacioacuten muy especiacuteficos y avanzados de la plataforma Web para los cuales las libreriacuteas ofrecidas por Robot
Framework no proporcionan la funcionalidad requerida
Ademaacutes se ha hecho uso de otras libreriacuteas como BuiltIn para el uso de bucles condicionales y otras keywords
String y Collections para el tratamiento de cadenas de caracteres y colecciones de datos SSHLibrary para usar
un cliente ssh Process para la ejecucioacuten de subprocesos haciendo uso la libreriacutea subprocess de python y
OperatingSystem para realizar algunas tareas sobre el sistema operativo
77
534 Documentacioacuten
La documentacioacuten de los diferentes casos de pruebas implementados con Robot Framework es muy redundante
y una tarea la cual seriacutea deseable de poder automatizar Dicho framework ofrece esta posibilidad a traveacutes de dos
herramientas para crear documentacioacuten basada en las pruebas y libreriacuteas implementadas para dichas pruebas
Libdoc y Testdoc [18]
5341 Libdoc
Libdoc es una herramienta ofrecida por Robot Framework para construir documentacioacuten sobre las keywords
implementadas para los casos de prueba Dicha documentacioacuten es generada en formato HTML y XML
Se puede crear documentacioacuten para bibliotecas implementadas con Python o Java y para las propias libreriacuteas
implementadas con Robot Framework A continuacioacuten se muestra un ejemplo de la documentacioacuten generada
para la libreriacutea implementada para los casos de prueba de inicio y cierre de sesioacuten de Galgus CHT Cloud
Manager
Figura 46 Ejemplo de documentacioacuten generada con Libdoc
5342 Testdoc
Testdoc es una herramienta para generar documentacioacuten de alto nivel basada en los casos de prueba de Robot
Framework Dicha documentacioacuten es generada en formato HTML e incluye el nombre la documentacioacuten y
otros metadatos de cada conjunto de pruebas y casos de prueba asiacute como las keywords de alto nivel y sus
argumentos
A continuacioacuten se muestra un ejemplo de la documentacioacuten generada para el conjunto de casos de prueba que
validan el inicio y cierre de sesioacuten de Galgus CHT Cloud Manager
Figura 47 Ejemplo de documentacioacuten generada con Testdoc
78
54 Pycharm (IDE)
Esta herramienta proporciona un entorno de desarrollo integrado (IDE) el cual ha sido usado para programar en
lenguaje Python por lo que es idoacuteneo tambieacuten para el desarrollo de pruebas con Robot Framework Esta
desarrollado por la empresa JetBrains Ademaacutes proporciona entre otras muchas herramientas el anaacutelisis de
coacutedigo un depurador graacutefico integracioacuten con sistemas de control de versiones y es multiplataforma
55 GitGitlab
551 Git
Git es un software de control de versiones disentildeado por Linux Torvalds pensando en la eficiencia y la
confiabilidad del mantenimiento de versiones de aplicaciones cuando eacutestas tienen un gran nuacutemero de archivos
de coacutedigo fuente Al principio Git se pensoacute como un motor de bajo nivel sobre el cual otros pudieran escribir la
interfaz de usuario como Cogito o StGIT Sin embargo Git se ha convertido desde entonces en un sistema de
control de versiones con funcionalidad plena Hay algunos proyectos de mucha relevancia que ya usan Git en
particular el grupo de programacioacuten del nuacutecleo Linux Ademaacutes cabe destacar que se ha hecho uso de
GitKraken como interfaz graacutefica de git para llevar a cabo el control de versiones de una forma maacutes intuitiva
552 Gitlab
Gitlab es un servicio Web de control de versiones y desarrollo de software colaborativo basado en Git Fue
implementado por los desarrolladores ucranianos Dimitry Zaporozhets y Valey Sizov en el lenguaje de
programacioacuten Ruby Este proyecto cuenta con un equipo de 150 miembros y maacutes de 1400 usuarios y es usado
por empresas como la NASA el CERN IBM o Sony [19]
Ademaacutes de gestor de repositorios tambieacuten ofrece la posibilidad de alojar documentacioacuten y un sistema de
seguimiento de errores Tambieacuten es de gran importancia destacar que esta herramienta proporciona su propia
herramienta de Integracioacuten Continua sin necesidad de usar otra herramienta externa
Se ha hecho uso de estas herramientas para tener un control de versiones sobre nuestro proyecto y una gestioacuten
centralizada de todos los repositorios de la empresa de forma que asiacute podemos tener un control de versiones de
todos los cambios realizados en el coacutedigo con posibilidad de contrastarlos con versiones anteriores y recuperar
dichos cambios Ademaacutes se hace uso tambieacuten de gitlab CICD para implementar procesos de Integracioacuten
continua sobre los diferentes proyectos En el caso particular de este proyecto para generar la documentacioacuten
de los casos de test y libreriacuteas y para generar un Docker con toda la bateriacutea de pruebas y dependencias necesarias
para lanzarlas
56 Redmine
Redmine es una herramienta para la gestioacuten de proyectos que ofrece un conjunto de funcionalidades que
permiten a los usuarios de diferentes proyectos realizar el seguimiento y organizacioacuten de los mismos Incluye
un sistema de seguimiento de incidentes Otras herramientas que incluye son un calendario de actividades
diagramas de Gantt una wiki para almacenar documentacioacuten control del flujo de trabajo basado en roles
integracioacuten con correo electroacutenico etc
Esta herramienta se usa para la gestioacuten del proyecto Galgus CHT Cloud Manager donde se integra como
subproyecto la automatizacioacuten del proceso de pruebas para la plataforma Web desarrollada
A continuacioacuten se muestra un ejemplo del flujo de trabajo implantado en la metodologiacutea de trabajo dentro del
proyecto donde cada historia puede contener un conjunto de tareas las cuales pueden pasar por diferentes
estados hasta ser completadas por el desarrollador o el ingeniero de pruebas
79
Figura 48 Ejemplo de Flujo de Trabajo en Redmine para Galgus CHT Cloud Manager
561 Uso en el Proyecto Galgus CHT Cloud Manager (Metodologiacutea Scrum)
Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas praacutecticas para trabajar
colaborativamente en equipo y obtener el mejor resultado posible de un proyecto Estas praacutecticas se apoyan
unas a otras y su seleccioacuten tiene origen en un estudio de la manera de trabajar de equipos altamente productivos
Esta metodologiacutea divide el trabajo en una lista de pequentildeas funcionalidades ordenadas por prioridad y estimadas
en esfuerzo Estas pequentildeas tareas son abordadas en iteraciones cortas de longitud fija denominadas Sprints de
1 a 4 semanas (en este caso se ha optado por iteraciones de 3 o 4 semanas) obteniendo coacutedigo potencialmente
entregable siendo demostrado al final de cada iteracioacuten Una vez decidido por el equipo de gestioacuten de proyectos
el alcance y conjunto de actividades a realizar dentro del sprint se transmite al resto del equipo que forma parte
del proyecto procediendo a la asignacioacuten de tareas mediante Redmine como herramienta de gestioacuten usada
Durante el sprint se va realizando un seguimiento perioacutedico del estado del proyecto y de la situacioacuten de cada
integrante mediante una actividad previa diaria de unos 15 minutos para situar el punto de partida de trabajo
diario que seriacutean reuniones diarias de apenas 15 minutos denominadas ldquoDaylisrdquo
Figura 49 Esquema Graacutefico de Metodologiacutea Scrum
80
La planificacioacuten que se pretende seguir en cada sprint es la siguiente
1 Semana 1 y 2 Realizacioacuten de tareas por parte del equipo de desarrollo incluyendo en estas tareas
nuevos desarrollos modificacioacuten de funcionalidades y verificacioacuten de las mismas mediante pruebas
unitarias y de integracioacuten
2 Semana 3 Realizacioacuten de pruebas de aceptacioacuten manuales por parte del equipo de pruebas y posterior
automatizacioacuten de dichas pruebas Para ello se usaraacute el entorno de UAT como escenario de pruebas
Ademaacutes el equipo de desarrollo iraacute corrigiendo todos aquellos errores o defectos encontrados
3 Semana 4 El jefe de proyecto realiza la fusioacuten de todos los desarrollos y actualiza las versiones en el
entorno de Preproduccioacuten incluyendo todas las actividades realizadas y validadas por el equipo de
desarrollo y de pruebas El equipo de pruebas realizaraacute la ejecucioacuten de todas las pruebas End-to-End
sobre el entorno de Preproduccioacuten para verificar y validar la nueva versioacuten que incluye todas las
funcionalidades Estas pruebas son denominadas pruebas de regresioacuten las cuales verifican que los
nuevos desarrollos no han provocado defectos o errores sobre funcionalidades que hasta ahora habiacutean
funcionado correctamente Finalmente el jefe de proyecto realiza el despliegue en produccioacuten
81
82
6 EXPERIMENTOS
na vez descrito el sistema bajo pruebas el proceso de pruebas y las herramientas que se usaraacuten para
automatizar las pruebas de aceptacioacuten sobre la plataforma de gestioacuten Galgus CHT Cloud Manager
solo queda presentar la forma en la que se ha puesto en praacutectica y el proceso seguido paso a paso
Dado que el objetivo es conseguir una bateriacutea de casos de pruebas End-to-End automatizadas se implementaraacuten
dichos casos de prueba de forma que permitan detectar el incorrecto funcionamiento de cada funcionalidad con
la mayor rapidez posible cubriendo los principales escenarios donde puedan surgir los mayores errores Por
tanto dichos casos de prueba seraacuten elegidos en base al riesgo que puedan introducir
Estos casos de prueba seraacuten definidos mediante un conjunto de criterios de aceptacioacuten descritos a traveacutes de
diagramas de flujo y agrupados seguacuten la funcionalidad de la aplicacioacuten que abarquen las cuales son
1 Vista de Gestioacuten Principal (Coud Tab) Esta seccioacuten de la Web estaacute destinada a la administracioacuten de
usuarios administracioacuten de los diferentes Zone Managers y finalmente incluye un Mapa con la
ubicacioacuten de cada Zone Manager
2 Vista de Configuracioacuten (Configuration Tab) En esta pestantildea se ofrece la gestioacuten de grupos de puntos
de acceso gestioacuten de backups y restauracioacuten gestioacuten de firmwares zonas CHT etc
3 Vista de Red (Network Tab) La pestantildea de red engloba toda la configuracioacuten de red de los puntos de
acceso siendo esta la pestantildea con mayor funcionalidad complejidad y por ello potencial de riesgo de
errores de la plataforma Web
Figura 50 Logo de Galgus CHT Cloud Manager
U
La uacutenica parte donde el ldquoeacutexitordquo aparece antes que el trabajo es en el diccionario
Vidal Sasoon
83
61 Estructura del Proyecto
La clasificacioacuten funcional anterior seraacute tomada de la misma forma para organizar la estructura del proyecto de
pruebas automatizadas con Robot Framework para un desarrollo ordenado y loacutegico de todo el conjunto de casos
de prueba A continuacioacuten se muestra un ejemplo de la estructura del proyecto el cual se encuentra en desarrollo
y continua mejora
Figura 51 Estructura del Proyecto
Para una mayor modularidad y limpieza en el desarrollo de los casos de Test se han centralizado todos los
localizadores en un archivo llamado ldquoSelectorpyrdquo En la siguiente figura se muestra un fragmento de dicho
fichero
Figura 52 Fragmento del fichero ldquoSelectorpyrdquo
A la hora de obtener los localizadores de los elementos que seraacuten comprobados o usados en los scripts de pruebas
se han usado las herramientas de desarrollador que incluye Google Chrome Para ello basta con navegar a la
paacutegina de la plataforma Web en cualquier navegador y pulsar la tecla F12 Esto mostraraacute las herramientas de
desarrolladores donde encontramos una pestantildea llamada ldquoElementosrdquo donde se puede inspeccionar el
documento ldquoHTMLrdquo de la paacutegina Una vez abierta dicha herramienta seraacute sencillo obtener propiedades de los
diversos elementos que nos permitiraacuten hacer referencia a los mismos en nuestro script de pruebas
Los ldquoXpathrdquo absolutos seraacuten lo usados praacutecticamente en toda la Suite de pruebas El beneficio de los
identificadores uacutenicos es que permiten seleccionar elementos sin que sea necesario hacer referencia a su posicioacuten
dentro del documento HTML Esto evita cualquier problema en caso de que las rutas de un elemento dentro del
citado documento cambien debido a mejoras o despistes por parte de los desarrolladores En cambio usar
selectores basados en la ruta del elemento dentro del documento HTML puede propiciar falsos fallos en el
escenario anterior debido a que no puedan encontrarse en la Web a pesar de que realmente sigan estando
presentes y totalmente funcionales
Por otro lado se han agrupado todas aquellas ldquokeywordsrdquo que puedan ser usadas por otras secciones en la
implementacioacuten de los casos de prueba mediante ficheros nombrados como ldquotab_common_keywords robotrdquo
84
Siguiendo esta jerarquiacutea se ha incluido un fichero llamado ldquoCommon_Keywordsrobotrdquo general en el que se
incluyen las principales ldquokeywordsrdquo que pueden ser usadas en todo el proyecto A continuacioacuten se muestra un
fragmento de este fichero
Figura 53 Fragmento del fichero ldquoCommon_Keywordsrobotrdquo
Tambieacuten se incluye el fichero ldquoConfigurationrobotrdquo para agrupar definiciones de variables que seraacuten
usadas en todo el proyecto ademaacutes de realizar la inclusioacuten de las libreriacuteas a usar Se muestra otra figura
con un fragmento del fichero ldquoConfigurationrobotrdquo
Figura 54 Fragmento del fichero de Configuracioacuten de pruebas ldquoConfigurationrobotrdquo
85
A continuacioacuten se muestra un diagrama que muestra las dependencias de los diferentes archivos y la estructura
seguida por el proyecto
Figura 55 Diagrama de paquetes del proyecto de pruebas
Tras introducir la estructura del proyecto y las diferentes funcionalidades de la plataforma Web Galgus CHT
Cloud Manager a continuacioacuten se mostraraacuten algunos criterios de aceptacioacuten de cada funcionalidad a probar
con diagramas de flujo y scripts de pruebas haciendo uso del estilo de representacioacuten Given-When-Then
Ademaacutes se mostraraacuten algunos detalles de implementacioacuten sobre las pruebas Por otro lado la ejecucioacuten de los
casos de prueba de ejemplo y el reporterevisioacuten de resultados se incluiraacute en la seccioacuten de Anexos
Cada una de las siguientes subsecciones dentro de cada funcionalidad principal de la aplicacioacuten o vista principal
tendraacute su correspondiente Suite de pruebas con un conjunto de casos de Test Todas estas Suites seguiraacuten la
siguiente estructura comuacuten para los casos de Test
Figura 56 Estructura de una Suite de Pruebas
86
Todas las Suites comienzan con una seccioacuten de documentacioacuten para describir el contenido de las pruebas de forma geneacuterica y varias secciones para importar los recursos necesarios para las pruebas (Resource)
Las secciones ldquoSuite Setuprdquo y ldquoSuite Teardownrdquo permiten la ejecucioacuten automaacutetica antes y despueacutes de la bateriacutea de pruebas y las secciones ldquoTest Setuprdquo y ldquoTest Teardownrdquo permiten la ejecucioacuten automaacutetica antes y despueacutes de cada caso de prueba
Un uso tiacutepico de ldquoSuite Setuprdquo es abrir un navegador Web y comprobar la disponibilidad de la Web a probar mientras que el cierre del navegador se realiza con ldquoSuite Teardownrdquo De este modo sea cual sea el resultado de la ejecucioacuten no se quedaraacuten abiertas ventanas gastando recursos de la maacutequina
Por otro lado el uso por defecto de ldquoTest Setuprdquo en este proyecto ha sido el inicio de sesioacuten en la Web CHT Cloud Manager mientras que ldquoTest Teardownrdquo ha sido usado para cerrar tambieacuten el navegador Web Sin embargo la mayoriacutea de las pruebas implementadas necesitan una serie de precondiciones previas a la ejecucioacuten del Test y un conjunto de postcondiciones necesarias para no provocar inconsistencias entre la ejecucioacuten de diferentes pruebas Por este motivo se ha hecho uso de las etiquetas [Setup] y [Teardown] para modificar la ejecucioacuten por defecto de ldquoTest Setuprdquo y ldquoTest Teardownrdquo en cada caso de prueba cuando sea necesario
Cabe destacar que la loacutegica implementada dentro de estas claacuteusulas no requiere que sea validada puesto que su uacutenico objetivo es preparar el entorno de pruebas para ejecutar una prueba sin que esta falle por causas ajenas al aacutembito y objetivo de la prueba evitando de esta forma los falsos positivos Por este motivo se hace uso de la Keyword ldquoRun Keyword And Ignore Errorrdquo ofrecida por la libreriacutea ldquoBuiltInrdquo para ignorar los errores en la ejecucioacuten de [Setup] y [Teardown] En la siguiente figura se muestra un ejemplo de dicha teacutecnica
Figura 57 Ejemplo de ldquoTest Setuprdquo personalizado para un caso de prueba
Finalmente la implementacioacuten de las ldquokeywordsrdquo usadas mediante la nomenclatura Given-When-Then seraacuten agrupadas en el correspondiente fichero ldquoTab_common_keywordsrobotrdquo para conseguir una abstraccioacuten de la loacutegica necesaria para la automatizacioacuten de las pruebas En las pruebas seleccionadas para describir en esta seccioacuten se detallaraacute la implementacioacuten de algunas keywords que se usaraacuten
87
62 Vista de Gestioacuten Principal (Cloud Tab)
En la siguiente figura se muestra la vista de Gestioacuten Principal de Galgus CHT Cloud Manager
Figura 58 Vista de Gestioacuten Principal (Cloud Tab)
Sobre esta vista se han automatizado un conjunto de Suites de pruebas que validan toda la funcionalidad
contenida en las pestantildeas MAP List of Zone Managers y Administration ademaacutes de toda la loacutegica ofrecida para
gestionar un conjunto de fabricantes
621 Administration
Comenzando con la pestantildea de administracioacuten se puede observar la existencia de cuatro flujos de navegacioacuten
principales en la siguiente figura
Figura 59 Pestantildea ldquoAdministrationrdquo
Una vez conocida la vista de administracioacuten de la Web se han realizado un total de 22 casos de prueba de los
cuales detallaremos el caso de prueba identificado con la etiqueta U0027
6211 Criterios de Aceptacioacuten
La pestantildea de administracioacuten permite la gestioacuten de los usuarios y roles que tienen acceso a la plataforma Web
ademaacutes de la configuracioacuten de los detalles de los fabricantes seleccionados A continuacioacuten se detallan los
criterios de aceptacioacuten del caso de prueba seleccionado
U0027 Un usuario con permisos de Super Usuario puede editar la informacioacuten de un fabricante
1 Un usuario con permisos de Super Usuario puede ver y acceder a la pestantildea de administracioacuten
2 Un usuario con permisos de Super Usuario puede editar la informacioacuten de un fabricante correctamente
88
6212 Diagramas de Flujo
A continuacioacuten se muestran los diagramas de flujo implementados para los dos casos de prueba analizados
Figura 60 Diagramas de Flujo de Casos de Prueba U0025 y U0027
6213 Script de Pruebas
Una vez establecidos los criterios de aceptacioacuten de ambos casos de prueba se mostraraacuten los scripts de pruebas
realizados
Figura 61 Script de Pruebas U0025
Entre las ldquokeywordsrdquo usadas en el caso de test anterior se puede destacar por ejemplo la implementacioacuten de
ldquoEdit Fieldsrdquo la cual permite editar los campos de un fabricante y verificar que han sido editados tras guardar
los cambios
Figura 62 Keyword ldquoEdit Fieldsrdquo
89
622 List
En la pestantildea de gestioacuten de los diferentes Zone Managers se puede observar una lista de los diferentes Zone
Managers disponibles y se pueden realizar un conjunto de acciones como la creacioacuten de nuevos Zone Managers
y edicioacuten o eliminacioacuten de los existentes entre otras
Figura 63 Pestantildea ldquoList of Zone Managersrdquo
Sobre esta vista se han realizado un total de 7 casos de prueba de los cuales detallaremos el caso de prueba
identificado con la etiqueta U0023 el cual permite validar la creacioacuten y eliminacioacuten de un Zone Manager
6221 Criterios de Aceptacioacuten
A continuacioacuten se detallan los criterios de aceptacioacuten del caso de prueba seleccionado
U0023 Verificar que un Usuario puede Crear y Eliminar un Zone Manager
1 Un usuario con permisos de Super Usuario puede Navegar a la pestantildea List Of Zone Managers
2 El usuario puede crear un Zone Manager correctamente
3 El usuario puede eliminar un Zone Manager correctamente
6222 Diagramas de Flujo
A continuacioacuten se muestra el diagrama de flujo implementado para el caso de prueba analizado
Figura 64 Diagrama de flujo de Caso de Prueba U0023
90
6223 Script de Pruebas
Una vez establecidos los criterios de aceptacioacuten se mostraraacute el script de pruebas realizado a partir del diagrama
de flujo anterior
Figura 65 Script de Prueba U0023
Cabe destacar la implementacioacuten de la Keyword ldquoZone Manager is Registered Successfullyrdquo la cual comprueba
que el Zone Manager registrado pasa a un estado ldquoOnlinerdquo tras un tiempo considerado como aceptable para que
la instancia de dicho Zone Manager este disponible en Cloud CHT Manager
Figura 66 Keyword ldquoZone Manager is registered successfullyrdquo
623 Manufacturer
La vista de gestioacuten principal ofrece una seccioacuten que permite la gestioacuten de los diferentes fabricantes permitiendo
su creacioacuten edicioacuten eliminacioacuten y bloqueo En la siguiente figura se muestra un ejemplo de la seccioacuten de
fabricantes
Figura 67 Seccioacuten de Fabricantes
Para validar el correcto funcionamiento de dicha seccioacuten se han realizado un total de 9 casos de prueba de los
cuales se detallaraacuten los casos de prueba identificados con las etiquetas U0009 Estos permiten validar que los
fabricantes pueden ser creados editados y eliminados correctamente y que todos los fabricantes disponibles son
mostrados correctamente
91
6231 Criterios de Aceptacioacuten
A continuacioacuten se detallan los criterios de aceptacioacuten de los casos de prueba seleccionados
U0009 Verificar que un Usuario con permisos de Super usuario puede ver correctamente todos los
fabricantes existentes
1 Un usuario con permisos de Super Usuario puede Navegar a la pestantildea de Administracioacuten
2 El usuario puede visualizar todos los fabricantes existentes
6232 Diagrama de Flujo
Figura 68 Diagrama de flujo de Caso de Prueba U0009
6233 Script de Pruebas
Una vez establecidos los criterios de aceptacioacuten se mostraraacuten los scripts de pruebas realizados a partir de los
diagramas de flujo anteriores
Figura 69 Script de Prueba U0009
En este punto cabe destacar la finalidad de la Keyword ldquoCorrectly Createrdquo la cual se usa en la mayoriacutea de las
pruebas para verificar que una operacioacuten se ha realizado con eacutexito en la plataforma Galgus CHT Cloud Manager
Esta Keyword verifica que tras realizar alguacuten tipo de operacioacuten en la plataforma Web ocurre un evento sobre la
Web que indica que dicha operacioacuten se ha realizado con eacutexito de la siguiente forma
92
Figura 70 Toast Success
Figura 71 Keyword ldquoCorrectly Createrdquo
Finalmente se muestra la implementacioacuten de las keywords usadas en [Setup] y [Teardown] del caso de prueba
U0009 las cuales preparan el escenario de pruebas creando un conjunto de fabricantes acotado y los elimina
tras la finalizacioacuten de la prueba
Figura 72 Setup amp Teardown de U0008
624 MAP
La plataforma Galgus CHT Cloud Manager ofrece una pestantildea ldquoMAPrdquo que contiene un mapa con la ubicacioacuten
asignada a cada uno de los Zone Managers disponibles por el usuario mostrando en su ubicacioacuten un icono con
el estado de dicho Zone Manager el cual cambia de color seguacuten su estado (offline online unsynchronized)
Figura 73 Mapa de Zone Managers
93
A traveacutes de dicho icono se puede realizar una serie de acciones entre ellas acceder a un Zone Manager
realizando doble click sobre el icono del mismo Sin embargo para automatizar este conjunto de acciones el
equipo de pruebas ha encontrado dificultades haciendo uso de Robot Framework ya que las libreriacuteas disponibles
permiten la interaccioacuten con elementos de la Web pero en este caso los iconos de los diferentes Zone Managers
son renderizados dentro del Mapa con ldquoOpen Street Mapsrdquo antes de ser mostrado en la vista Web de la
aplicacioacuten Por esta razoacuten el mapa es localizado en el DOM como un uacutenico elemento Web lo que imposibilita
localizar a priori el icono de cada Zone Manager dentro del Mapa
Para resolver este impedimento el equipo de pruebas tuvo que analizar con profundidad la libreriacutea de ldquoOpen
Street Maprdquo implementada en Javascript Esta ha sido usada en el Frontend para encontrar alguna funcioacuten que
permitiese obtener desde la consola del navegador Web los piacutexeles en los que cada Zone Manager ha sido
renderizado dentro del Mapa Dicha funcioacuten es ldquogetPixelsFromCoordinate(coordinate)rdquo la cual a traveacutes de las
coordenadas de [Latitud Longitud] de cada Zone Manager se obtienen los piacutexeles del mismo en la pantalla A
traveacutes del siguiente fragmento de coacutedigo en el frontend implementado con Angular 6 en typescript se consigue
obtener los piacutexeles de cada Zone Manager e imprimirlo en la consola del navegador Web
Figura 74 Funcioacuten que dibuja los ZM en el Mapa y obtiene los piacutexeles en pantalla
Para llevar a cabo la implementacioacuten de las pruebas sobre el mapa se ha hecho uso en su gran mayoriacutea de Scripts
con Python Selenium y otras libreriacuteas necesarias en lugar de Robot Framework debido a la necesidad de
realizar varias tareas simultaneas ademaacutes de tratarse de pruebas muy especiacuteficas y personalizadas A
continuacioacuten se muestra la prueba implementada para poder realizar doble click sobre un Zone manager en el
mapa e iniciar sesioacuten en el mismo (U0007)
6241 Criterios de Aceptacioacuten
U0007 Verificar que un Usuario acceder a un Zone Manager desde el Mapa
1 Un usuario con permisos de Super Usuario puede Navegar a la pestantildea MAP
2 El usuario puede hacer doble click en el Zone Manager e iniciar sesioacuten
94
6242 Diagrama de Flujo
Figura 75 Diagrama de Flujo de Caso de Prueba U0007
6243 Script de Pruebas
Para la implementacioacuten de este tipo de casos de prueba se ha hecho uso de la libreriacutea ldquoHtmlTestRunnerrdquo para
obtener un reporte similar al ofrecido por Robot Framework en la ejecucioacuten de la prueba Para obtener un reporte
de la prueba la implementacioacuten de la misma debe seguir una estructura determinada a la que ademaacutes se ha
incluido a traveacutes de la libreriacutea ldquomultiprocessingrdquo la ejecucioacuten simultaacutenea de los dos procesos descritos en el
diagrama de flujo anterior Es necesaria la ejecucioacuten de varios procesos para leer la consola del navegador Web
y obtener los piacutexeles de los Zone Manager para posteriormente hacer doble click
En la Seccioacuten A3 de los anexos puede encontrarse la implementacioacuten del script de pruebas para el caso de
prueba U0007
95
63 Vista de Configuracioacuten (Configuration Tab)
En esta vista se ha automatizado un conjunto de Suites de prueba que validan toda la funcionalidad contenida
en las pestantildeas Groups CHT Zones BackupRestore y Firmware
631 Groups
La pestantildea de grupos permite el descubrimiento de los puntos de acceso a traveacutes de su direccioacuten MAC quedando
estos registrados en base de datos y mostrando al usuario en una tabla los puntos de acceso registrados ademaacutes
del estado de los mismos y otros datos como el modelo o grupo al que pertenecen
Figura 76 Pestantildea ldquoGroupsrdquo
Sobre esta funcionalidad de la plataforma se han realizado un total de 19 casos de prueba de los cuales
detallaremos el caso de prueba identificado con la etiqueta U0119
6311 Criterios de Aceptacioacuten
U0119 Verificar que al descubrir dos puntos de acceso en grupos diferentes ambos son antildeadidos en el
grupo correcto
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Configuracioacuten
3 El usuario puede Navegar a la pestantildea de Grupos
4 El usuario puede descubrir un punto de acceso en el grupo ldquorootrdquo correctamente
5 El usuario puede crear un subgrupo predecesor del grupo ldquorootrdquo correctamente
6 El usuario puede navegar al subgrupo creado correctamente
7 El usuario puede descubrir un punto de acceso en el subgrupo correctamente
96
6312 Diagramas de Flujo
Figura 77 Diagrama de flujo de Caso de Prueba U0119
97
6313 Script de Pruebas
Una vez establecidos los criterios de aceptacioacuten el script de prueba realizado a partir del diagrama de flujo
anterior es el siguiente
Figura 78 Script de Prueba U0119
Entre las keywords implementadas para esta prueba cabe destacar la implementacioacuten de ldquoVerify if AP is
registered Succesfully on grouprdquo la cual permite validar si un punto de acceso ha sido asignado al grupo
correcto
Figura 79 Keyword ldquoVerify if AP is registered Succesfully on grouprdquo
Puede observarse como en primer lugar se obtiene la fila de la tabla que contiene el punto de acceso en cuestioacuten
para posteriormente comprobar si el grupo al que pertenece es el esperado
Observando dicha implementacioacuten cabe destacar el uso de la Keyword ldquoInput Into Text Fieldrdquo la cual ha sido
implementada para vaciar el contenido de campos de texto ya que mediante la Keyword ldquoClear Element Textrdquo
de la libreriacutea Selenium2Library no se conseguiacutea borrar ciertos campos de texto
Figura 80 Keywords Input Into Text Field y Clear Field Of Characters
98
632 CHT Zones
En la pestantildea de gestioacuten de las diferentes Zonas CHT se puede observar una lista de los puntos de acceso
disponibles y se pueden realizar un conjunto de acciones sobre ellos como la creacioacuten eliminacioacuten y asociacioacuten
de zonas CHT
En este punto es conveniente explicar el concepto de zona CHT el cual se refiere a un grupo IP Multicast a
traveacutes del cual un conjunto de Puntos de Acceso establece comunicacioacuten de forma colaborativa Esta
comunicacioacuten es necesaria para el funcionamiento de algunos de los algoritmos que ofrece CHT como por
ejemplo la asignacioacuten automaacutetica de canal (ACA)
Figura 81 Pestantildea ldquoCHT Zonesrdquo
Sobre esta vista se han realizado un total de 6 casos de prueba de los cuales detallaremos el caso de prueba
identificado con la etiqueta U0204 Este caso de prueba permite validar la asignacioacuten de zonas CHT a los Puntos
de Acceso
6321 Criterios de Aceptacioacuten
U0204 Verificar que un usuario puede asignar una Zona CHT a un punto de acceso correctamente
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Configuracioacuten
3 El usuario puede Navegar a la pestantildea de Grupos
4 El usuario puede asignar una Zona CHT existente a un punto de acceso registrado correctamente
99
6322 Diagramas de Flujo
Figura 82 Diagrama de Flujo de Caso de Prueba U0204
6323 Script de Pruebas
Tras presentar los criterios de aceptacioacuten y su correspondiente diagrama de flujo el script de pruebas
implementado para la automatizacioacuten de dicha prueba es el siguiente
Figura 83 Scripts de Prueba U0204
Figura 84 Keyword Add Zone CHT to AP
100
633 BackupRestore
En esta pestantildea se permite la gestioacuten de copias de seguridad y restauracioacuten de los puntos de acceso registrados
en un Zone Manager Se puede observar en esta vista una tabla con los puntos de acceso registrados y otra tabla
con las copias de seguridad realizadas sobre los puntos de acceso
Figura 85 Pestantildea BackupRestore
Partiendo de la representacioacuten funcional de esta vista se han realizado un total de 8 casos de prueba de los
cuales detallaremos el caso de prueba identificado con la etiqueta U0401 el cual permite verificar de forma
automaacutetica la realizacioacuten de un backup sobre un punto de acceso y su posterior restauracioacuten
6331 Criterios de Aceptacioacuten
U0401 Verificar que un usuario puede realizar un BackupRestore correctamente sobre un punto de
acceso previamente registrado
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Configuracioacuten
3 El usuario puede Navegar a la pestantildea de BackupRestore
4 El usuario puede realizar un Backup sobre un punto de acceso existente
5 La tabla de Backups contiene la copia de seguridad realizada
6 El usuario puede restaurar un punto de acceso correctamente
101
6332 Diagramas de Flujo
Figura 86 Diagrama de Flujo de Caso de Prueba U0401
6333 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 87 Script de Prueba U0401
Cabe destacar la implementacioacuten de la Keyword ldquoRestore for AP have done successfullyrdquo la cual verifica que
el punto de acceso ha sido restaurado correctamente esperando que el punto de acceso vuelva a estar en estado
ldquoonlinerdquo durante un tiempo aceptable Si pasado dicho tiempo no recupera dicho estado la prueba se dariacutea por
erroacutenea
Figura 88 Keyword Restore For AP hace done successfully
634 Firmware
Esta uacuteltima pestantildea de la vista principal de configuracioacuten proporciona al usuario la posibilidad de subir los
firmwares de los diferentes modelos de puntos de acceso en sus diferentes versiones del software CHT de forma
que es posible la actualizacioacuten del firmware de los puntos de acceso desde la plataforma Se puede observar en
esta vista una tabla con los puntos de acceso registrados y otra tabla con los firmwares subidos a la plataforma
102
Figura 89 Pestantildea ldquoFirmwarerdquo
Partiendo de la representacioacuten funcional de esta vista se han realizado un total de 7 casos de prueba de los
cuales detallaremos el caso de prueba identificado con la etiqueta U0303 el cual permite verificar de forma
automaacutetica la actualizacioacuten del firmware de un punto de acceso
6341 Criterios de Aceptacioacuten
U0303 Verificar que un usuario puede realizar correctamente la actualizacioacuten del firmware de un punto
de acceso
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Configuracioacuten
3 El usuario puede Navegar a la pestantildea de Firmware
4 El usuario puede subir un firmware correctamente
5 La tabla de Firmwares contiene la imagen de CHT subida a la plataforma
6 El usuario puede realizar la actualizacioacuten del firmware sobre un punto de acceso correctamente
Destacar que el firmware que se desea aplicar sobre un punto de acceso debe ser del modelo correspondiente al
punto de acceso usado ya que cada punto de acceso tiene una imagen de CHT compilada para una arquitectura
hardware determinada Las imaacutegenes son proporcionadas por un servidor interno de la empresa
103
6342 Diagramas de Flujo
Figura 90 Diagrama de Flujo de Caso de Prueba U0303
6343 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 91 Script de Prueba U0303
Cabe destacar la implementacioacuten de la Keyword ldquoFlash APrdquo la cual realiza la actualizacioacuten del firmware de un
punto de acceso verificando que este ha concluido correctamente Para ello espera un tiempo aceptable a que el
punto de acceso vuelva al estado ldquoonlinerdquo
Figura 92 Keyword Flash AP
104
64 Vista de Red (Network Tab)
La uacuteltima vista principal sobre la que se han automatizado pruebas es la vista de Red la cual ofrece al usuario
la gestioacuten y configuracioacuten de su red formada por un conjunto de puntos de acceso previamente registrados
Entre las funcionalidades ofrecidas se encuentran la creacioacuten de VLANS SSIDs Portales Cautivos Perfiles
Radius Activacioacuten de algoritmos CHT y la configuracioacuten de puntos de acceso en tiempo real desde la
plataforma Web
Para describir el proceso de automatizacioacuten se comenzaraacute detallando en primer lugar la creacioacuten de VLANS
Brigdes y SSIDs para posteriormente aplicar dichos paraacutemetros a puntos de acceso desde las pestantildeas ldquoGeneralrdquo
y ldquoAP Networkrdquo Finalmente se mostraraacuten algunos ejemplos sobre otras configuraciones maacutes avanzadas como
la creacioacuten y aplicacioacuten de perfiles radius y portales cautivos ademaacutes de la activacioacuten de algoritmos
641 VLANS amp Bridges
Comenzando con la pestantildea de VLANS amp Bridges se puede observar la existencia de una tabla para cada
elemento de dicha vista
Figura 93 Pestantildea ldquoVLAN amp Bridgesrdquo
Para cada elemento se han automatizado un conjunto de pruebas formado por 6 casos de prueba de los cuales
detallaremos el caso de prueba identificado con la etiqueta U0527 Este caso de prueba permite validar de forma
automaacutetica la creacioacuten y eliminacioacuten de VLANs De forma ideacutentica se procederiacutea para validar la creacioacuten y
eliminacioacuten de Bridges
6411 Criterios de Aceptacioacuten
A continuacioacuten se detallan los criterios de aceptacioacuten del caso de prueba seleccionado
U0527 Verificar que un usuario puede crear y eliminar una VLAN correctamente
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Network
3 El usuario puede Navegar a la pestantildea de VLANS amp Bridges
4 El usuario puede crear una VLAN correctamente
5 El usuario puede eliminar una VLAN correctamente
105
6412 Diagramas de Flujo
Figura 94 Diagrama de Flujo de Caso de Prueba U0527
6413 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 95 Script de Prueba U0527
Cabe destacar la implementacioacuten de la Keyword ldquoGo and Create VLANrdquo la cual permite crear una VLAN en
funcioacuten de los paraacutemetros de entrada deseados para configurar dicha VLAN como por ejemplo el ldquoIDrdquo de la
VLAN y alias o si se desea que dicha VLAN sea de tipo dinaacutemica
Figura 96 Keyword Go And Create VLAN
106
642 SSIDs
Esta pestantildea proporciona una tabla que permite registrar SSIDs con diferentes configuraciones posibles
Figura 97 Pestantildea SSIDs
Para cada funcionalidad de dicha pestantildea se han automatizado un conjunto de pruebas formado por 5 casos de
prueba de los cuales detallaremos el caso de prueba identificado con la etiqueta U0530 Este caso de prueba
permite validar de forma automaacutetica la creacioacuten y eliminacioacuten de SSIDS
6421 Criterios de Aceptacioacuten
A continuacioacuten se detallan los criterios de aceptacioacuten de los dos casos de prueba seleccionados
U0530 Verificar que un usuario puede crear y eliminar una SSID correctamente
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Network
3 El usuario puede Navegar a la pestantildea de SSIDs
4 El usuario puede crear una SSID correctamente
5 El usuario puede eliminar una SSID correctamente
6422 Diagramas de Flujo
Figura 98 Diagrama de Flujo de Caso de Prueba U0530
107
6423 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 99 Script de Prueba U0530
Cabe destacar la implementacioacuten de la Keyword ldquoGo and Create SSIDrdquo la cual permite crear una SSID en
funcioacuten de los paraacutemetros de entradas deseado para configurar dicha SSID como por ejemplo tipo de
encriptacioacuten de la contrasentildea modo oculto o habilitacioacuten de los algoritmos Load Balancing (LB) Smart
roaming (SR) o PRE
Figura 100 Keyword Go And Create SSID
108
643 CHT
Esta funcionalidad permite activar el algoritmo que permite la seleccioacuten automaacutetica de canal entre un conjunto
de puntos de acceso (ACA) Cuando se activa desde la plataforma Web todos los puntos de acceso
pertenecientes a un Zone Manager activan dicho algoritmo el cual se trata de un algoritmo colaborativo
mediante el cual los puntos de acceso acuerdan cual es el mejor canal para la comunicacioacuten WiFi con los clientes
que se conecten tanto en la banda de 24 GHz como en la de 5 GHz En la siguiente figura se muestra la vista
de la plataforma Web para activar el algoritmo en cuestioacuten
Figura 101 Pestantildea ldquoCHTrdquo
Dado que se trata de una funcionalidad en la que solo se debe comprobar si el algoritmo estaacute en el mismo estado
tanto en la plataforma Web como en los puntos de acceso registrados se ha implementado un uacutenico caso de
prueba identificado con la etiqueta U539 Este caso de prueba realiza la conexioacuten a los puntos de acceso para
verificar que dicho algoritmo presenta el mismo estado que en la plataforma
6431 Criterios de Aceptacioacuten
U0537 Verificar que un usuario puede Activar o Desactivar el algoritmo ACA correctamente
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Network
3 El usuario puede Navegar a la pestantildea de CHT
4 El usuario puede ActivarDesactivar el algoritmo ldquoACA ldquocorrectamente
5 Los APs recibieron las oacuterdenes para ActivarDesactivar el algoritmo ldquoACArdquo correctamente
109
6432 Diagramas de Flujo
Figura 102 Diagrama de Flujo de Caso de Prueba U0539
6433 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 103 Script de Prueba U0539
En cuanto a la implementacioacuten de dicho caso de prueba cabe destacar la implementacioacuten de la Keyword ldquoACA
Is Workingrdquo las cual se muestra en la siguiente figura
Figura 104 Keyword ACA Is Working
Puede observarse como en funcioacuten de si el algoritmo ACA esta activado o desactivado en la plataforma Web
(ENABLE DISABLE) se ejecuta la Keyword ldquoChanges On CLIrdquo con diferentes paraacutemetros Esta Keyword
permite la conexioacuten viacutea ldquoSSHrdquo con un punto de acceso para la ejecucioacuten de un comando sobre el mismo y la
posterior comparacioacuten del resultado obtenido por dicho comando con la salida deseada proporcionada tambieacuten
como paraacutemetro de la Keyword
110
En la siguiente figura se muestra la implementacioacuten de dicha Keyword
Figura 105 Keyword Changes On CLI
Para este caso de prueba el comando ejecutado de forma remota sobre el punto de acceso permite obtener de
forma automaacutetica el estado del algoritmo ldquoACArdquo de la siguiente forma
Figura 106 Comando CHT para obtener el estado del moacutedulo ACA en el punto de acceso
644 Radius
Esta pestantildea proporciona una tabla que permite registrar perfiles Radius con diferentes configuraciones posibles
Figura 107 Pestantildea ldquoRadiusrdquo
ldquoRadiusrdquo se define como un protocolo de autenticacioacuten y autorizacioacuten para aplicaciones de acceso a la red o
movilidad IP De esta forma los puntos de acceso mediante la existencia de un servidor radius permiten que los
usuarios que se quieran conectar por WiFi necesiten ser autenticados con credenciales Dicha autenticacioacuten seraacute
redirigida por el punto de acceso al servidor radius el cual autoriza al punto de acceso para que permita la
conexioacuten del cliente
Ademaacutes el uso de este servicio junto con la configuracioacuten mediante VLAN dinaacutemicas permite que diferentes
usuarios accedan al servicio de red con diferentes credenciales de forma que seguacuten el tipo de cliente su traacutefico
viajaraacute por una VLAN u otra Esto permite la separacioacuten del traacutefico a nivel de enlace ofreciendo la posibilidad
de establecer reglas de control de traacutefico y ofrece una QoS miacutenima en funcioacuten del tipo de cliente
Figura 108 Escenario de Funcionamiento de Servidor Radius
111
Para cada funcionalidad de dicha pestantildea se han automatizado un conjunto de pruebas formado por 7 casos de
prueba de los cuales detallaremos el caso de prueba identificado con la etiqueta U0601 Este caso de prueba
permite validar de forma automaacutetica la creacioacuten edicioacuten y borrado de un perfil radius en la plataforma Web
6441 Criterios de Aceptacioacuten
U0601 Verificar que un usuario puede crear editar y borrar un perfil Radius correctamente
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Network
3 El usuario puede Navegar a la pestantildea de Radius
4 El usuario puede Crear un perfil Radius correctamente
5 El usuario puede Editar un perfil Radius correctamente
6 El usuario puede Eliminar un perfil Radius correctamente
6442 Diagramas de Flujo
Figura 109 Diagrama de Flujo de Caso de Prueba U0601
6443 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 110 Script de Prueba U0601
En cuanto a la implementacioacuten de dicho caso de prueba puede destacarse por ejemplo la implementacioacuten de
la Keyword ldquoCreate Radius Profilerdquo la cual permite crear un perfil ldquoRadiusrdquo a partir de un conjunto de
paraacutemetros de entrada
112
Figura 111 Keyword Create Radius Profile
645 Captive Portal
Esta pestantildea proporciona una tabla que permite registrar perfiles de Portales Cautivos con diferentes
configuraciones posibles
Figura 112 Pestantildea Captive Portals
Un portal cautivo es un servicio que permite el control del traacutefico HTTP y fuerza a los usuarios de una red a la
autenticacioacuten mediante una paacutegina Web para tener acceso a Internet Dicho portal permite controlar paraacutemetros
como el tiempo de conexioacuten de un cliente a la red ancho de banda ofrecido a cada cliente etc
Figura 113 Escenario de Funcionamiento de un Portal Cautivo
Para cada funcionalidad de dicha pestantildea se han automatizado un conjunto de pruebas formado por 5 casos de
prueba de los cuales detallaremos el caso de prueba identificado con la etiqueta U0701 Este caso de prueba
permite validar de forma automaacutetica la creacioacuten edicioacuten y borrado de un perfil de portal cautivo en la plataforma
Web
113
6451 Criterios de Aceptacioacuten
U0701 Verificar que un usuario puede crear editar y borrar un perfil de Portal Cautivo correctamente
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Network
3 El usuario puede Navegar a la pestantildea de Captive Portals
4 El usuario puede Crear un perfil de Portal Cautivo correctamente
5 El usuario puede Editar un perfil de Portal Cautivo correctamente
6 El usuario puede Eliminar un perfil de Portal Cautivo correctamente
6452 Diagramas de Flujo
Figura 114 Diagrama de Flujo de Caso de Prueba U0701
6453 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 115 Script de Prueba U0701
114
En cuanto a la implementacioacuten de dicho caso de prueba puede destacarse por ejemplo la implementacioacuten de
la Keyword ldquoEdit or delete Captive Portal Profilerdquo la cual permite editar o eliminar un perfil de Portal Cautivo
a partir de un conjunto de paraacutemetros de entrada
Figura 116 Keyword Edit or Delete Captive Portal Profile
115
646 General
Esta pestantildea muestra la vista general de la pestantildea ldquoNetworkrdquo En esta pestantildea se agrupa el conjunto de puntos
de acceso actualmente registrados en el Zone Manager con un resumen de su configuracioacuten de red actual el
estado en el que se encuentran y nuacutemero de clientes conectados Ademaacutes dicha vista proporciona un acceso
directo a la pestantildea ldquoAP Networkrdquo seleccionando uno o varios puntos de acceso de un mismo modelo En la
siguiente seccioacuten se explica la funcionalidad de dicha pestantildea
Figura 117 Pestantildea General
Para cada elemento se han automatizado un conjunto de pruebas formado por 9 casos de prueba de los cuales
detallaremos el caso de prueba identificado con la etiqueta U0522 Este caso de prueba se permite validar de
forma automaacutetica la conexioacuten de clientes a un punto de acceso con una SSID asignada de forma que el nuacutemero
de clientes conectados que se muestra en la plataforma Web sea correcto
6461 Criterios de Aceptacioacuten
U0522 Conectar clientes y verificar que el nuacutemero de clientes conectados es correcto
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Network
3 El usuario puede Navegar a la pestantildea General
4 El usuario tiene disponible un punto de acceso en el Zone Manager con una SSID asignada
5 El usuario conecta un cliente al punto de acceso por WiFi a la SSID asignada
6 El usuario verifica que el nuacutemero de clientes conectados incrementa en una unidad
116
6462 Diagramas de Flujo
Figura 118 Diagrama de Flujo de Caso de Prueba U0522
6463 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de prueba automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 119 Script de Prueba U0522
En cuanto a la implementacioacuten de dicho caso de prueba puede destacarse por ejemplo la implementacioacuten de
la Keyword ldquoCheck Number of Clients Increasesrdquo la cual permite comprobar que el nuacutemero de clientes conectados incrementa al conectar un cliente a un punto de acceso
Figura 120 Keyword Check Number of Clients Increases
117
647 AP Network
Esta pestantildea muestra la vista principal de la pestantildea ldquoAP Networkrdquo La funcionalidad que proporciona engloba
todos los posibles paraacutemetros de configuracioacuten para un punto de acceso que ha sido seleccionado previamente
desde la pestantildea General Cualquier configuracioacuten aplicada sobre esta vista seraacute enviada al punto de acceso
desde la plataforma Web permitiendo configurar los puntos de acceso de Galgus
Desde el punto de vista de la plataforma Web esta vista abarca un conjunto de funcionalidades consideradas
como maacutes complejas que se ofrecen en la plataforma Web por lo que es en esta vista donde puede encontrarse
una de las mayores aacutereas de riesgo de la plataforma Entre las funcionalidades que se ofrecen estaacuten la
configuracioacuten de las radios de un punto de acceso (Potencia Ancho de banda Canal etc) asignacioacuten de SSIDs
a las interfaces inalaacutembricas y configuracioacuten de reglas de control de traacutefico (TC Rules) asignacioacuten de puertos a
las diferentes subredes virtuales de aacuterea local (VLANS) o configuracioacuten de Portal Cautivo
Figura 121 Pestantildea AP Network
Para cada elemento se han automatizado un conjunto de pruebas formado por 28 casos de prueba los cuales la
mayoriacutea han requerido un amplio esfuerzo de implementacioacuten para conseguir su automatizacioacuten ya que son
pruebas cuya secuencia de acciones es larga ademaacutes de requerir en muchas ocasiones la verificacioacuten de la
configuracioacuten en los puntos de acceso viacutea ldquosshrdquo Para ello se ha hecho uso entre otras de la libreriacutea
ldquoSSHLibraryrdquo proporcionada por Robot Framework
Figura 122 Libreriacutea SSH para Robot Framework
118
Del conjunto de casos de prueba que validan la funcionalidad de dicha pestantildea se va a detallar el caso de prueba
identificado con la etiqueta U0511 Este caso de prueba permite validar de forma automaacutetica que se pueden
aplicar reglas de control de traacutefico ldquoTCsrdquo a una SSID asignada a las interfaces inalaacutembricas de un punto de
acceso desde la plataforma Web
Figura 123 Ventana de Configuracioacuten de TC Rules
6471 Criterios de Aceptacioacuten
U0511 Asignar ldquoTC Rulesrdquo a una SSID asociada a un Punto de Acceso correctamente
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Network
3 El usuario puede Navegar a la pestantildea General
4 El usuario tiene disponible un punto de acceso en el Zone Manager
5 El usuario puede seleccionar un punto de acceso
6 El usuario puede Navegar a la pestantildea AP Network para el punto de acceso seleccionado
7 El usuario puede asignar a las interfaces inalaacutembricas una SSID existente y crear ldquoTC Rulesrdquo sobre
esa SSID
8 El usuario puede aplicar la configuracioacuten
9 El punto de acceso aplica su configuracioacuten correctamente
10 El punto de acceso pasa al estado ldquoOnlinerdquo en la plataforma Web y su configuracioacuten estaacute alineada
119
6472 Diagramas de Flujo
Figura 124 Diagrama de Flujo de Caso de Prueba U0511
120
6473 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 125 Script de Prueba U0511
En cuanto a la implementacioacuten de dicho caso de prueba puede destacarse por ejemplo la implementacioacuten de
la Keyword ldquoWait Timerrdquo la cual permite verificar que no se produce ninguacuten error al aplicar una configuracioacuten
determinada desde la plataforma Web durante un tiempo determinado
Figura 126 Keyword Wait Timer
Destacar tambieacuten la implementacioacuten de la Keyword ldquoCheck On CLIrdquo la cual permite contrastar que la
configuracioacuten aplicada desde la plataforma sobre un punto de acceso es la esperada En este caso se comprueba
que las ldquoTC Rulesrdquo han sido correctamente aplicadas para una SSID determinada en un punto de acceso de
forma remota mediante el uso de la libreriacutea ldquoSSHrdquo para Robot Framework
Figura 127 Keyword Check On CLI
121
122
7 LINEAS DE MEJORA Y CONCLUSIONES
n este uacuteltimo capiacutetulo se analizaraacuten resultados y conclusiones obtenidas sobre el uso de pruebas
automatizadas para la verificacioacuten y validacioacuten de una plataforma Web como la de Galgus Se
detallaraacuten algunas ventajas e inconvenientes encontrados y se plantearaacuten algunas liacuteneas de mejora
futuras sobre el proyecto desarrollado Con estas mejoras se busca como objetivo enriquecer el proceso de
automatizacioacuten de pruebas ademaacutes de hacerlo maacutes efectivo y metoacutedico en todos sus aspectos ya que siempre
hay algo que se puede mejorar para conseguir una herramienta maacutes completa y uacutetil
Se detallaraacuten tambieacuten aspectos de aprendizaje opiniones experiencias y en definitiva todas las conclusiones
sacadas sobre este proyecto incluyendo tambieacuten las dificultades encontradas para el desarrollo del mismo
71 Liacuteneas de Mejora Futuras
El estudio y puesta en marcha de este Proyecto de automatizacioacuten de pruebas de Software ha hecho uso de una
amplia cantidad de herramientas ofrecido por Selenium y Robot Framework ademaacutes de otras herramientas que
han permitido enriquecer el mismo con mayores funcionalidades ofrecidas al equipo de Proyecto Si bien se ha
logrado conseguir un paquete de pruebas con una capacidad de detectar defectos en un producto Web existen
diversas ampliaciones de dicho Proyecto que podriacutean aumentar de manera considerable el desempentildeo de las
herramientas de automatizacioacuten a lo largo del ciclo de vida del proyecto
A continuacioacuten se muestran algunas de las maacutes importantes
bull Uso de Integracioacuten Continua Robot Framework es faacutecilmente integrable principalmente con Jenkins
aunque tambieacuten ofrece la posibilidad de integrarlo con Gitlab CICD Esto permitiriacutea programar la
ejecucioacuten de pruebas automaacuteticamente para diferentes versiones del proyecto Galgus CHT Cloud
Manager o en diferentes fases del mismo Con esta caracteriacutestica se detectariacutean con mayor facilidad los
problemas relacionados con la configuracioacuten del entorno de trabajo y se podriacutea notificar por email a
los responsables de equipo ante los eventuales incidentes encontrados De este modo no seriacutea necesario
estar supervisando el proceso de ejecucioacuten para estar al tanto de un fallo en el sistema En este aspecto
se ha trabajado para conseguir estos objetivos con la creacioacuten de un Docker de Robot Framework que
permita la ejecucioacuten de las pruebas en el mismo para poder usarla en el entorno de integracioacuten continua
correspondiente Tambieacuten se ha implementado un primer un script que permita la ejecucioacuten de paquetes
de pruebas en dicho entorno
bull Selenium Grid El caso praacutectico descrito tiene un inconveniente y es que solo hace uso de Chrome
Suele ser frecuente que ciertos defectos en una aplicacioacuten Web solo aparezcan en determinados
navegadores Con herramientas como Selenium Grid permitiriacutean la ejecucioacuten en paralelo de las pruebas
en maacutequinas con diferentes sistemas operativos y navegadores Asiacute se podriacutea evaluar de manera
independiente la compatibilidad del producto en entornos multiplataforma Ademaacutes esta herramienta
es totalmente compatible con Jenkins o Gitlab CICD con las ventajas que esto supone
bull Headless browser Esto hace referencia al uso de navegadores sin interfaz graacutefica de usuario La mayor
parte del tiempo durante una ejecucioacuten es destinada a esperar a que el navegador renderice el contenido
Si se elimina este factor de la foacutermula y se accede directamente al DOM de la Web se consigue una
reduccioacuten en el tiempo de ejecucioacuten de las pruebas Durante el desarrollo de este proyecto se ha
trabajado en este aspecto ofrecieacutendose la posibilidad de ejecutar las pruebas en dos entornos diferentes
una primera de depuracioacuten de pruebas que realiza el renderizado del navegador y otra opcioacuten que
E
La tecnologiacutea por siacute sola no basta Tambieacuten tenemos que poner el corazoacuten
Jane Goodall
123
permite la ejecucioacuten de pruebas sin renderizado del navegador (Modo Headless)
bull Buenas praacutecticas en la localizacioacuten de elementos en el DOM de la Web La aplicacioacuten de este tipo
de buenas praacutecticas permitiriacutean una mejor y maacutes eficiente localizacioacuten de los elementos en el DOM
reduciendo la posibilidad de que las pruebas generen falsos errores Esto es lo que ha causado la mayor
parte de los problemas de implementacioacuten y ejecucioacuten de las pruebas automaacuteticas Actualmente la
herramienta de automatizacioacuten de pruebas se encuentra en un proceso de mejora continua en el que se
estaacute abordando una refactorizacioacuten para la aplicacioacuten de estas buenas praacutecticas Para ello se estaacuten
haciendo uso de selectores avanzados basados en rutas (Xpaths) relativas en el DOM de la Web las
cuales realizan la mayoriacutea de las buacutesquedas por contenido y no por ruta absoluta como se veniacutea
haciendo hasta ahora
bull Aplicacioacuten de Model Based Testing (MBT) Como estudio del arte se ha presentado una teacutecnica que
permite dar un paso maacutes en la automatizacioacuten de pruebas Como se ha detallado en el proyecto esta
teacutecnica permite ascender en el nivel de abstraccioacuten de las pruebas basando las mismas en el disentildeo y
modelado de la aplicacioacuten Dicha teacutecnica se encuentra principalmente en proceso de investigacioacuten lo
cual hace difiacutecil aplicarla aunque seriacutea de gran intereacutes conseguir su implantacioacuten
72 Conclusiones Finales
En el desarrollo del presente Proyecto se ha analizado una pequentildea extensioacuten del inmenso mundo de la gestioacuten
de calidad Esta ha ido tomando fuerza con el paso de los antildeos en el mercado actual introducieacutendose en todos
los aacutembitos incluido en el software La gestioacuten de calidad se ha profesionalizado de tal forma que el papel del
ingeniero de calidad en los proyectos de software es imprescindible en cualquier empresa que quiera hacerse un
hueco en el mercado como garantiacutea de calidad
La elevada exigencia del mercado del software provocada por la gran demanda de clientes y usuarios finales
para recibir un producto en el menor tiempo posible hace que en muchos casos las empresas centren su esfuerzo
en sacar un producto lo antes posible reduciendo los esfuerzos destinados a los procesos de calidad de dicho
producto software Originalmente las pruebas de software realizadas sobre un producto se realizaban de forma
manual por un ingeniero de calidad pero con el avance de las tecnologiacuteas la automatizacioacuten de las mismas
supone un elevado esfuerzo inicial pero una reduccioacuten de los mismos a medio plazo
En este proyecto se ha desarrollado una herramienta que permite la automatizacioacuten de pruebas funcionales sobre
una plataforma Web concretamente pruebas de aceptacioacuten sobre Galgus CHT Cloud Manager Las pruebas de
automatizacioacuten elaboradas reflejan que existen tecnologiacuteas muy asequibles en teacuterminos de coste compatibilidad
y facilidad de uso para iniciarse en el mundo de las pruebas funcionales de sistemas Algo muy presente en el
mundo laboral actual es la creciente demanda de expertos en automatizacioacuten en todas las principales
plataformas Web Moacutevil y Escritorio Muchos de estos profesionales vienen del mundo del testing manual por
lo que conociendo ya la nomenclatura y el funcionamiento de los procesos de calidad solo necesitan dar el paso
hacia el uso de este tipo de herramientas Sea con Selenium o con cualquier otra herramienta los conceptos
teoacutericos presentados en este proyecto son igualmente vaacutelidos
Por otra parte debe destacarse la dificultad encontrada a la hora de establecer unos criterios de aceptacioacuten de las
funcionalidades de la plataforma Web bajo pruebas Esto se debe al desarrollo de una herramienta de
automatizacioacuten de pruebas que se ha iniciado en una fase avanzada del desarrollo del proyecto con lo cual en
muchas ocasiones surgiacutean dudas sobre el disentildeo del proyecto Adicionalmente la propia estructura y tecnologiacuteas
usadas en la Web dificultaron al inicio la localizacioacuten de elementos A esta causa de une tambieacuten la ausencia de
identificadores uacutenicos en los elementos que componen la misma Esto se tradujo en el uso de selectores basados
en la ruta del elemento pudiendo acarrear la aparicioacuten de posibles falsos errores debidos a cambios en el coacutedigo
fuente de la plataforma Web La solucioacuten adoptada para tal problema no fue maacutes que analizar meticulosamente
aquellas ejecuciones fallidas para descartar errores reales y en caso de que sean debidas a los selectores aplicar
la debida actualizacioacuten de los mismos
En este uacuteltimo aspecto cabe destacar que el proyecto de automatizacioacuten de pruebas se encuentra actualmente
en una fase de mejora continua en la que se estaacuten adoptando teacutecnicas basadas en el uso de selectores avanzados
basados en rutas relativas y nombres que permitan reducir el impacto del problema presentado en este punto
124
A modo de resumen se plantean algunas ventajas en el uso de SeleniumRobot Framework para la
automatizacioacuten de pruebas
Facilidad de configuracioacuten y uso Su instalacioacuten requiere un esfuerzo miacutenimo y el poder de
abstraccioacuten ofrecido por Robot Framework hace posible la lectura y entendimiento de los paquetes de
pruebas y reportes a todos los miembros del equipo
Cantidad de documentacioacuten disponible La comunidad respalda ambos proyectos y es por ello que
encontramos soluciones de todo tipo adaptadas a las necesidades de cada uno
Soporte para la mayoriacutea de navegadores con el mismo script Ejecutar el script de pruebas
desarrollado para su automatizacioacuten en otro navegador requiere simplemente la instalacioacuten del
controlador deseado y usar un determinado paraacutemetro para indicar el uso de dicho controlador en la
llamada de la Keyword encargada de la apertura del navegador
De la misma forma se pueden destacar algunas desventajas
Selenium soacutelo es compatible con productos Web Cualquier software moacutevil o de escritorio requiere
del uso de otros frameworks o herramientas lo cual puede ser un punto negativo para empresas que
tengan productos multiplataforma Sin embargo Robot Framework si proporciona soporte
multiplataforma con la integracioacuten de otras herramientas o framework para su desarrollo
Tecnologiacuteas no optimizadas para pruebas de rendimiento En este punto cabe destacar el esfuerzo
de la comunidad para desarrollar herramientas que permitan la automatizacioacuten de este tipo de pruebas
con Robot Framework como por ejemplo ldquorfswarmrdquo
Compatibilidad de versiones de paquetes de Software Es frecuente usar determinadas
combinaciones de versiones de paquetes para lograr un framework estable y robusto Esto a veces puede
convertirse en una tarea tediosa donde cuestan encajar piezas Por suerte es algo que se estaacute teniendo
en cuenta con las uacuteltimas versiones de Selenium
Puede concluirse que durante el desarrollo de este proyecto se ha conseguido la creacioacuten de una herramienta
sencilla de usar y entender para la automatizacioacuten de pruebas funcionales sobre una plataforma Web ademaacutes
de preparar dicha herramienta para integrarla en el proceso de integracioacuten continua implantado para dicha
aplicacioacuten Web con Gitlab mediante Docker Ademaacutes se ha realizar un estudio del arte de una teacutecnica conocida
bajo el nombre de Model Based Testing (MBT) que permitiriacutea mejorar el proceso de automatizacioacuten y la
herramienta desarrollada para tal fin
Con todo ello he aprendido multitud de conceptos tecnologiacuteas y herramienta que hasta ahora desconociacutea cuaacutel
era su finalidad o funcionamiento como por ejemplo Robot Framework Para ello he necesitado gran cantidad
de formacioacuten previa antes de comenzar a ponerlo en praacutectica para el desarrollo de la herramienta de
automatizacioacuten
Son muchos los errores cometidos hasta conseguir los objetivos y metas propuestas los cuales creo que son los
sucesos maacutes importantes pues de ellos se aprende y son los que nos hacen avanzar cuando los resolvemos
Finalmente destacar que este proyecto me ha dado la oportunidad de abrir mi conocimiento en un campo de las
tecnologiacuteas de la informacioacuten el cual resulta de intereacutes Dar las Gracias a mis tutores Pablo Aguilera Bonet y
Daniel Gutieacuterrez Reina ademaacutes de mi responsable en Galgus Joseacute Antonio Delgado Alfonso por brindarme
esta oportunidad ademaacutes de ayudarme y asesorarme estando siempre disponible y con dedicacioacuten hacia este
proyecto para que haya podido llevarse a cabo
125
126
REFERENCIAS
[1] M Utting Bruno Legeard Practical Model-based Testing sl Elsevier 2007
[2] Ibrahim K El-Far Enjoying the perks of model-based testing In Proceedings of the Software Testing
Analysis and Review Conference
[3] A C Dias Neto Rajesh Subramanyan Marlon Vieirab Characterization of Model-based Software
[4] Model-based Testing Next Generation Functional Software Testing Legeard Bruno Dagstuhl Seminar
Proceedings 10111 Vol httpdropsdagstuhldeopusvolltexte20102620
[5] Perspectives of Model-Based Testing Ed Brinksma Wolfgang Grieskamp and Jan Tretmans IBFI
Schloss Dagstuhl Germany sn 2005 Dagstuhl Seminar Proceedings
[6] Definicioacuten de Calidad httpsdleraeesid=6nVpk8P|6nXVL1Z
[7] Modelos de calidad del software httpswwwresearchgatenetpublication316674475
[8] Calidad del Software ldquoEl camino al exitordquo LI Alma Delia Chaacutevez Rojas
[9] IEEE Software Engineering Book of Knowledge IEEE sl IEEE 2004
[10] Principios de pruebas software httpsmediumcomatejedaccsprincipios-del-testing-722323e16e76
[11] httpwwwsstqbesw3docsGLOSARIO_V00110pdf
[12] httpsepdfpubsoftware-testing-an-istqb-iseb-foundation-guidehtml
[14] IEEE standard glossary of software engineering terminology F Jay RMayer 1990 paacuteg IEEE Std 610
[15] Openwrt httpsopenwrtorgsupported_devices
[16] RabbitMQ httpswwwrabbitmqcom
[17] Zero Touch Provisioning httpssearchdatacentertechtargetcomesdefinicionAprovisionamiento-de-
cero-toque-ZTP-o-zero-touch-provisioning
[18] Robot Framework User Guide
httpsrobotframeworkorgrobotframeworklatestRobotFrameworkUserGuidehtml
[19] Gitlab httpsdocsgitlabcom
[20] httpswwwfederico-toledocomcuando-automatizar-una-prueba
127
128
ANEXO A PREPARACIOacuteN DEL ENTORNO DE
TRABAJO Y EJECUCIOacuteN DE PRUEBAS
A1 Preparacioacuten del entorno de trabajo
Para el desarrollo de las preubas automaacuteticas se ha hecho uso del sistema operative Linux con la distribucioacuten
Ubuntu El motivo de su uso es el amplio abanico de herramientas de coacutedigo libre que existen para esta
distribucioacuten asiacute como la enorme contribucioacuten que hace la comunidad de usuarios para mejorarla Sobre este
sistema operativo se ha hecho uso de un conjunto de herramientas para el montaje de un entorno de pruebas
automatizado basado en Python A continuacioacuten se detallaraacuten dichas herramientas
A11 Pip
Pip es un sistema de gestioacuten de paquetes que se utiliza para la instalacioacuten de los paquetes software
implementados en Python que se usaraacuten posteriormente La instalacioacuten de un paquete se realiza mediante la
ejecucioacuten del siguiente comando
A12 Virtualenv Entorno Virtual
Dado que cada proyecto basado en Python puede requerir la instalacioacuten de diferentes conjuntos de paquetes es
comuacuten usar la creacioacuten de entornos virtuales que nos permitan administrar cada proyecto de manera
independiente pudiendo tener otros proyectos haciendo uso de los mismos paquetes con otras versiones La
instalacioacuten se realiza mediante la herramienta ldquoPiprdquo a traveacutes del siguiente comando
Una vez instalado se puede crear un entorno virtual asociado a un proyecto de la siguiente forma
En este punto se creariacutea un entorno virtual para el proyecto deseado Ahora solo quedariacutea activarlo o iniciarlo
pip install nombre-del-paquete
pip install virtualenv
cd carpeta-del-proyecto
virtualenv ndashp usrbinpython27 mi-proyecto
source mi-proyectobinactivate
129
A13 Selenium y Chromedriver
La instalacioacuten de Selenium se realiza de la misma forma que el resto de paquetes con la herramienta ldquoPiprdquo
Por otra parte el controlador para el navegador Chrome Chromedriver puede ser descargado desde el
repositorio oficial httpschromedriverchromiumorg Ademaacutes Chromedriver debe ser accessible para
Selenium de cara a configurar el PATH
A14 Robot Framework y SeleniumLibrary
A continuacioacuten se realizariacutea la instalacioacuten de Robot Framework
Posteriormente se realizariacutea la instalacioacuten del paquete ldquoSelenium2Libraryrdquo el cual contiene la implementacioacuten
en python de las libreriacuteas necesarias para utilizar Robot Framework en Python
Llegados a este punto listando todos los paquetes instalados se deberiacutea tener algo similar a la siguiente figura
Con esta configuracioacuten del entorno este estariacutea preparado para elaborar los casos de prueba automatizados con
Robot Framework y Selenium
pip install selenium
export PATH=$PATHabsolute_path_of_chromedriver_file
pip install robotframework
pip install robotframework-selenium2library
130
A15 Otras dependencias
Para el desarrollo de pruebas que requieren otro tipo de herramientas como la transferencia de ficheros con el
servicio ldquoSCPrdquo o la conexioacuten remota a traveacutes del servicio ldquoSSHrdquo se require la instalacioacuten de los siguientes
paquetes
Ademaacutes para la realizacioacuten de pruebas avanzadas en Python para la gestioacuten del Mapa de la platform Web CHT
Cloud Manager se ha hecho uso de la librariacutea ldquohtml-testRunnerrdquo para ofrecer un reporte de la ejecucioacuten de
pruebas muy similar al ofrecido por Robot Framework
A2 Ejecucioacuten de Pruebas
Tras la implementacioacuten de las pruebas siguiendo el procedimiento indicado en la seccioacuten de Experimentos
ejecutar un script de pruebas se realiza mediante el uso del siguiente comando
Mediante el uso de la variable ldquoENVIROMENTrdquo puede seleccionarse el entorno en el que se desea ejecutar las
pruebas Con el entorno de ldquodebugrdquo las pruebas se ejecutariacutean de forma graacutefica mientras que el el entorno de
ldquodockerrdquo permite la ejecucioacuten de pruebas sin interfaz graacutefica Este uacuteltimo entorno seriacutea usado para la ejecucioacuten
de pruebas con el docker de Robot Framework que se ha implementado el cual se detallaraacute maacutes adelante
Por otro lado existen otras opciones para el comando anterio como por ejemplo
Las opciones ldquo-irdquo y ldquo-erdquo permiten ejecutar o excluir un caso de preuba en la ejecucioacuten de una Suite de pruebas
Por otro lado el uacuteltimo comando permite lanzar la ejcucioacuten de una Suite de pruebas y ejecutar soacutelo aquellos
casos de prueba que hayan fallado en la ejecucioacuten anterior
pip install robotframework-sshlibrary
pip install robotframework-scplibrary
pip install html-testRunner
robot --variable ENVIROMENTdebug_or_docker suite_filerobot
robot --variable ENVIROMENTdebug_or_docker ndashi U0000 suite_filerobot
robot --variable ENVIROMENTdebug_or_docker ndashe U0000 suite_filerobot
robot --rerunfailed outrerunfailedxml --output out2xml suite_filerobot
131
A continuacioacuten se muestra un ejemplo de ejecucioacuten de pruebas con Robot Framwork
132
A3 Script de Prueba U007 (MAP)
from selenium import webdriver
from seleniumwebdrivercommonby import By
from seleniumwebdriversupportui import WebDriverWait
from seleniumwebdriversupport import expected_conditions as EC
from seleniumwebdrivercommondesired_capabilities import DesiredCapabilities
from seleniumwebdrivercommonaction_chains import ActionChains
from seleniumcommonexceptions import TimeoutException
import math json multiprocessing time re
import sys
import unittest
import HtmlTestRunner
U0007 Double-click on Zone Manager and look if the Backend tab opens
class DClickZM(unittestTestCase)
driver = 0
canvas = 0
waitTime = 20
username = franciscodiaz
password = ahipeo8829g
classmethodg
def setUp(cls)
Enviroment Management
chrome_options = webdriverChromeOptions()
if sysargv[2] == docker
chrome_optionsadd_argument(--headless)
chrome_optionsadd_argument(--disable-extensions)
chrome_optionsadd_argument(--disable-gpu)
chrome_optionsadd_argument(--no-sandbox)
enable browser logging
d = DesiredCapabilitiesCHROME
d[loggingPrefs] = browser DEBUG
clsdriver = webdriverChrome(chrome_options=chrome_options desired_capabilities=d)
clsdrivermaximize_window()
clsdriverset_window_size(1920 1080)
load the desired webpage
clsdriverget(httpdevcloudgalgusnet)
def test_double_click_ZM(self)
loggin in the page
userNameBox = WebDriverWait(selfdriver 1)until(
ECpresence_of_element_located((ByXPATH [id=username])))
userNameBoxsend_keys(selfusername)
passwordBox = WebDriverWait(selfdriver selfwaitTime)until(
ECpresence_of_element_located((ByXPATH [id=password])))
passwordBoxsend_keys(selfpassword)
133
loginButton = WebDriverWait(selfdriver selfwaitTime)until(
ECpresence_of_element_located((ByXPATH
[id=myModalLabel]divdivformdiv[3]input)))
loginButtonclick() Tab General appears
selfcanvas = WebDriverWait(selfdriver selfwaitTime)
until(ECpresence_of_element_located((ByXPATH
htmlbodyappdivmaindivregister-
managersdivtabsetdivtab[1]aol-mapdivdivcanvas)))
timesleep(15)
action = ActionChains(selfdriver)
Manage Process
manager = multiprocessingManager()
return_dict = managerdict()
We create a Process
p_get_pixels_zm = multiprocessingProcess(target=selfGet_Pixels_ZM args=(return_dict selfdriver))
We create another Process
p_double_click_on_zm = multiprocessingProcess(target=selfDouble_Click_On_ZM args=(return_dict selfcanvas
action selfdriver))
We start the process and we block for 5 seconds
p_get_pixels_zmstart()
p_get_pixels_zmjoin(timeout=10)
p_double_click_on_zmstart()
p_double_click_on_zmjoin(timeout=10)
We terminate the process
p_get_pixels_zmterminate()
p_double_click_on_zmterminate()
try
Tab General appears
WebDriverWait(selfdriver 20)until(ECpresence_of_element_located(
(ByXPATH [id=app-sections]networktabsetulli[1]a)))
except TimeoutException
raise Exception(Cant Login in Zone Manager)
classmethod
def tearDown(cls)
clsdriverquit()
staticmethod
def Get_Pixels_ZM(return_dict driver)
return_dict[0] = 0
return_dict[1] = 0
regex = r(lt=c[-gt]cs)[wW]+(=)
while True
for entry in driverget_log(browser)
message = entry[message]
matches = refinditer(regex message reMULTILINE)
134
for matchNum match in enumerate(matches start=1)
try
p = matchgroup()replace( )
my_json = jsonloads(p)
if my_json[ZM] == Hotel MampM
return_dict[0] = my_json[top]
return_dict[1] = my_json[left]
break
except
pass
if return_dict[0] = 0 and return_dict[1] = 0
break
staticmethod
def Double_Click_On_ZM(return_dict canvasaction driver)
width = int(mathceil(float(return_dict[0])))
height = int(mathceil(float(return_dict[1])))
actionmove_to_element_with_offset(canvas width height)
actiondouble_click()
actionperform()
actiondouble_click()
actionperform()
driversave_screenshot(screenshot1png)
timesleep(5)
if __name__ == __main__
unittestmain(testRunner=HtmlTestRunnerHTMLTestRunner())
135
136
ANEXO B DOCKER DE ROBOT FRAMEWORK Y
ENTORNO DE UAT DOCKERIZADO
B1 Docker de Robot Framework
Para el entorno de UAT que se va a desarrollar se ha hecho uso de diferentes contenedores que han sido creados
por el equipo de desarrollo donde cada contenedor aloja un microservicio diferente de la plataforma
Para crear cada contenedor se ha hecho uso de Docker Esta herramienta permite crear contenedores ligeros y
portables para diferentes servicios que puedan ejecutarse en cualquier maacutequina con Docker instalado
independientemente del sistema operativo de la maacutequina que lo ejecute facilitando asi los despliegues
Mediante un fichero llamado ldquoDockerfilerdquo se definen los siguientes contenedores de servicios entre los cuales
se destacaraacute el fichero que define la creacioacuten del docker de Robot Framework el cual ha sido desarrollado por
el autor de este proyecto
Este contenedor ha sido creado sobre una imagen de Docker con el inteacuterprete de Python instalado Partiendo de
137
esta imagen se realiza la instalacioacuten de Robot Framework y las diferentes libreriacuteas y herramientas que se usaraacuten
en el proyecto para poder lanzar los Tests End-to-End
Ademaacutes se realiza la instalacioacuten de Google Chrome y Mozilla Firefox y la descarga de Chromedriver y
Geckodriver para poder lanzar los tests con dichos navegadores en modo headless Para el lanzamiento de los
test en modo headless se haraacute uso de la variable de entorno ldquoENVIROMENTrdquo definida en el anexo anterior
Finalmente se antildeade el proyecto de pruebas desarrollado para tener disponible las pruebas aumaacuteticas en el
contenedor
B2 Entorno de UAT Dockerizado
Para automatizar el despliegue de la plataforma Galgus CHT Cloud Manager con Docker se ha hecho uso de la
herramienta ldquodocker-composerdquo Esta herramienta permite simplificar el uso de Docker generando scripts que
facilitan el disentildeo y la construccion de servicios Con Docker Compose se pueden crear diferentes contenedores
y al mismo tiempo en cada contenedor diferentes servicios En la siguientefigura se muestra el fichero que
define el entorno de UAT con docker-compose
138
139
140
ANEXO C REVISIOacuteN DE REPORTES Y LOGS
C1 Reporte de Logs ofrecido por Robot Framework
Selenium no teniacutea la capacidad nativa de generar informes Este es uno de los motivos por el que se decidioacute
utilizar Robot Framework
Robot Framework genera tres archivos tras la ejecucioacuten de los scripts de pruebas A partir de la informacioacuten
contenida en el fichero ldquooutputxmlrdquo se rellenan las plantillas ldquohtmlrdquo del ldquologrdquo y del reporte El reporte permite
aplicar filtros a los resultados mientras que el ldquologrdquo contiene todos los detalles de la ejecucioacuten
A continuacioacuten se adjuntan las capturas de logs generados por los diferentes paquetes de pruebas desarrollados
C2 Cloud Tab
C21 Administration
141
142
C22 List
143
C23 Manufacturers
144
C24 MAP
145
C3 Configuration Tab
C31 BackupRestore
146
C32 CHT Zones
147
C33 Firmware
148
C34 Groups
149
150
C4 Network Tab
C41 General
151
C42 SSID
C43 CHT
152
C44 VLAN
153
C45 Radius
154
C46 Captive Portal
155
C47 AP Network
156
Como se ha visto reflejado en el conjunto de logs el tiempo total invertido en la ejecucioacuten ha sido de 1 hora 20
minutos y 22 segundos Dichas pruebas realizadas por una persona de forma manual hubiesen requerido como
miacutenimo el doble de tiempo Ya ni mencionar si se aplicase concurrencia en la ejecucioacuten de pruebas
157
ANEXO D DIAGRAMA DE GANTT
2
3
Trabajo de Fin de Maacutester
Maacutester en Ingenieriacutea de Telecomunicacioacuten
Testeo automatizado de una plataforma Web de
gestioacuten Galgus CHT Manager
Autor
Francisco Joseacute Diacuteaz Romero
Tutores
Pablo Aguilera Bonet
Daniel Gutieacuterrez Reina
Doctor Ingeniero en Electroacutenica
Escuela Teacutecnica Superior de Ingenieriacutea
Universidad de Sevilla
Sevilla 2020
4
5
Trabajo de Fin de Maacutester Testeo automatizado de una plataforma Web de gestioacuten
Galgus CHT Manager
Autor Francisco Joseacute Diacuteaz Romero
Tutor Pablo Aguilera Bonet
Daniel Gutieacuterrez Reina
El tribunal nombrado para juzgar el Proyecto arriba indicado compuesto por los siguientes miembros
Presidente
Vocales
Secretario
Acuerdan otorgarle la calificacioacuten de
Sevilla 2020
El Secretario del Tribunal
6
7
A mi familia
A mis maestros
A mis amigos
8
9
Agradecimientos
10
11
Resumen
La revolucioacuten tecnoloacutegica que vivimos hoy diacutea enfocada principalmente en el mundo de Internet y aplicaciones
Web estaacute permitiendo que todas las herramientas que tenemos a nuestro alrededor se encuentren en un proceso
de tremenda evolucioacuten y cambio continuo
En este proyecto se ha realizado un estudio del arte sobre una teacutecnica que permite mejorar el proceso de
automatizacioacuten de pruebas sobre una aplicacioacuten Web basaacutendose en el modelado de la aplicacioacuten para
proporcionar una abstraccioacuten en la implementacioacuten de las pruebas Tambiacuteeacuten se ha realizado una revisioacuten de los
diferentes modelos de calidad normativas y tipos de prueba de Software Finalmente se ha desarrollado una
herramienta de test comprendida por un conjunto de pruebas de aceptacioacuten automaacuteticas que permiten la
verificacioacuten y validacioacuten de la funcionalidad de la plataforma Web Galgus CHT Cloud Manager
Galgus CHT Cloud Manager es la plataforma Web distribuida ofrecida por Galgus para la gestioacuten de redes
compuestas por puntos de acceso Wifi Estas redes se encuentran instaladas en los diferentes clientes que hacen
uso de los servicios que ofrece Galgus los cuales se basan en la optimizacioacuten del rendimiento y las prestaciones
de las redes Wifi en entornos de alta densidad de usuarios Esto se consigue mediante un software embebido
patentado por Galgus conocido bajo el nombre de Cognitive Hostpot Technology (CHT) el cual es instalado
en los puntos de acceso Dicho software implementa un conjunto de algoritmos y caracteriacutescas colaborativas
para conseguir los objetivos planteados en redes Wifi
Como resultado del trabjo podemos proporcionar a los ingenieros de pruebas una herramienta con la que poder
automatizar el testeo de una plataforma Web De esta forma se consigue agilizar el proceso de pruebas y reducir
costes y esfuerzos en tareas repetitivas que anteriormente se haciacutean de forma manual
12
13
Abstract
The technological revolution we are living today focused mainly on the Internet world and therewith the Web
applications is allowing all the tools we have around us to be in a process of continuous evolution and change
In this project we have made a study of the art on a technique that allows to improve the process of automation
of testing on a Web application based on the modelling of the application to provide an abstraction in the
implementation of testing A review of the different quality models standards and types of software testing has
also been carried out Finally a tool comprised of a set of automated acceptance tests has been developed to
allow verification and validation of the functionality of the Galgus CHT Cloud Manager Web platform
Galgus CHT Cloud Manager is the distributed web platform offered by Galgus for the management of
networks composed by Wifi access points These networks are installed in the different clients that make
use of the services offered by Galgus which are based on the optimization of the performance and features
of Wifi networks in high user density environments This is achieved through an embedded software
patented by Galgus known as Cognitive Hostpot Technology (CHT) which is installed in the access points
This software implements a set of algorithms and collaborative features to achieve the objectives set in Wifi
networks
This allows us to provide quality assurance engineers with a tool to automate the testing of a Web platform In
this way the testing process is streamlined and costs and efforts are reduced in repetitive tasks that previously
used to be done manually
14
15
Iacutendice
Agradecimientos 9
Resumen 11
Abstract 13
Iacutendice 15
Iacutendice de Figuras 19
Glosario 24
1 Introduccioacuten 27 11 Motivacioacuten 28 12 Alcance y Objetivos 29 13 Estructura de la memoria 30
2 Estudio del Arte y Revisioacuten 32 21 Model Based Testing (MBT) 32
211 Introduccioacuten 32 212 iquestQueacute es Model Based Testing 33 213 iquestCoacutemo funciona Model Based Testing 33 214 Consideraciones para la aplicacioacuten de Model Based Testing (MBT) 36 215 Beneficios de Model Based Testing (MBT) 37 216 Problemas y Limitaciones de Model Based Testing (MBT) 38 217 Cuando elegir Model Based Testing (MBT) 38
22 Gestioacuten de Calidad Software 39 221 Introduccioacuten 39 222 Concepto de Calidad 39 223 Modelos de Calidad de Software 40 224 Principales Ventajas e Inconvenientes de Modelos de Calidad anteriores 44 225 Conclusiones 44
3 Marco Teoacuterico Pruebas de Software 46 31 Testing y Pruebas de Software 46 32 Principios de las Pruebas de Software 47 33 Proceso de Pruebas de Software Anaacutelisis disentildeo e implementacioacuten 48
331 Terminologiacutea 48 332 Proceso de Pruebas de Software 49
34 Clasificacioacuten de Pruebas de Software 51 341 Pruebas Funcionales 51 342 Pruebas No Funcionales 52 343 Pruebas Estructurales 54 344 Pruebas debidas a Cambios 54
35 Niveles de Prueba 54 351 Pruebas a Nivel de Componente 55 352 Pruebas a Nivel de Integracioacuten 55 353 Pruebas a Nivel de Aceptacioacuten 55
16
36 Dificultades de pruebas en aplicaciones Web e impacto 56
4 Sistema Galgus CHT Cloud Manager 58 41 Arquitectura y Descripcioacuten del Sistema 58
411 Puntos de Acceso (OpenWRT + CHT) 60 412 Broacuteker de Eventos AMQP (RabbitMQ) 61 413 Frontend 62 414 Zone Manager 62 415 MoMap 63 416 Servidor de Licencias 64
42 Alcance y Objetivos de las pruebas sobre el sistema planteado 65 43 Arquitectura de la Solucioacuten Entorno de UAT para el proceso de pruebas (User Acceptance Test) 67
5 Tecnologiacuteas y Herramientas Usadas 69 51 Selenium 69 52 Selenium WebDriver 70
521 Elementos del Navegador 70 53 Robot Framework (RF) 72
531 Estilo de representacioacuten Given-When-Then 72 532 Reportes 75 533 Libreriacuteas 76 534 Documentacioacuten 77
54 Pycharm (IDE) 78 55 GitGitlab 78
551 Git 78 552 Gitlab 78
56 Redmine 78 561 Uso en el Proyecto Galgus CHT Cloud Manager (Metodologiacutea Scrum) 79
6 Experimentos 82 61 Estructura del Proyecto 83 62 Vista de Gestioacuten Principal (Cloud Tab) 87
621 Administration 87 622 List 89 623 Manufacturer 90 624 MAP 92
63 Vista de Configuracioacuten (Configuration Tab) 95 631 Groups 95 632 CHT Zones 98 633 BackupRestore 100 634 Firmware 101
64 Vista de Red (Network Tab) 104 641 VLANS amp Bridges 104 642 SSIDs 106 643 CHT 108 644 Radius 110 645 Captive Portal 112 646 General 115 647 AP Network 117
7 Lineas de Mejora y Conclusiones 122 71 Liacuteneas de Mejora Futuras 122 72 Conclusiones Finales 123
Referencias 126
17
Anexo A Preparacioacuten del Entorno de Trabajo y Ejecucioacuten de Pruebas 128 A1 Preparacioacuten del entorno de trabajo 128
A11 Pip 128 A12 Virtualenv Entorno Virtual 128 A13 Selenium y Chromedriver 129 A14 Robot Framework y SeleniumLibrary 129 A15 Otras dependencias 130
A2 Ejecucioacuten de Pruebas 130 A3 Script de Prueba U007 (MAP) 132
Anexo B Docker de Robot Framework y Entorno de UAT Dockerizado 136 B1 Docker de Robot Framework 136 B2 Entorno de UAT Dockerizado 137
Anexo C Revisioacuten de Reportes y Logs 140 C1 Reporte de Logs ofrecido por Robot Framework 140 C2 Cloud Tab 140
C21 Administration 140 C22 List 142 C23 Manufacturers 143 C24 MAP 144
C3 Configuration Tab 145 C31 BackupRestore 145 C32 CHT Zones 146 C33 Firmware 147 C34 Groups 148
C4 Network Tab 150 C41 General 150 C42 SSID 151 C43 CHT 151 C44 VLAN 152 C45 Radius 153 C46 Captive Portal 154 C47 AP Network 155
Anexo D Diagrama de Gantt 157
18
19
IacuteNDICE DE FIGURAS
Figura 1 Fuente de datos Morgan Stanley 27
Figura 2 Manual Testing vs Automated Testing [20] 28
Figura 3 Fase de Pruebas y Validacioacuten 32
Figura 4 Esquema baacutesico de Model Based Testing 33
Figura 5 Proceso detallado de Model Based Testing (MBT) 34
Figura 6 Construccioacuten del Modelo 34
Figura 7 Concepto de Calidad 39
Figura 8 Liacutenea de tiempo de modelos a nivel de proceso 40
Figura 9 Logo de ITIL 40
Figura 10 ISOIEC 20000 41
Figura 11 Logo de WebQEM 41
Figura 12 Liacutenea de tiempo de modelos a nivel de producto 42
Figura 13 Esquema de ISO 9126 42
Figura 14 Esquema de ISOIEC 25000 43
Figura 15 Principios de las Pruebas de Software 47
Figura 16 Terminologiacutea para el proceso de pruebas 48
Figura 17 Proceso de Pruebas de Software 49
Figura 18 Clasificacioacuten de Pruebas de Software 51
Figura 19 Pruebas de Caja Negra 51
Figura 20 Pruebas de Rendimiento 52
Figura 21 Pruebas de Carga 52
Figura 22 Pruebas de Estreacutes 52
Figura 23 Pruebas de Usabilidad 53
Figura 24 Pruebas de Portabilidad 53
Figura 25 Pruebas de Caja Blanca 54
Figura 26 Modelo de desarrollo en V 55
Figura 27 Dificultades de pruebas en aplicaciones Web e impacto 56
Figura 28 Logo de Galgus 58
Figura 29 Arquitectura de CHT Cloud Manager 59
Figura 30 CHT_CLI 60
Figura 31 Plataforma de Gestioacuten de RabbitMQ 61
Figura 32 Patroacuten PublicadorSuscriptor 61
Figura 33 Ejemplo de Interfaz Graacutefica de un Zone Manager 62
Figura 34 Ejemplo de Interfaz Graacutefica de MoMap 63
20
Figura 35 Interfaz Graacutefica del Servidor de Licencias 64
Figura 36 Zero-Touch Provisioning (ZTP) 64
Figura 37 Test Plan de CHT Cloud Manager 65
Figura 38 Leyenda del Test Plan 66
Figura 39 Control de Versiones del Test Plan 66
Figura 40 Entorno de UAT con Docker (Anexo B) 67
Figura 41 Implementaciones disponibles de Selenium y Navegadores Web Compatibles 70
Figura 42 Coacutedigo de ejemplo con Python y Selenium 71
Figura 43 Estilo de representacioacuten Given-When-Then 72
Figura 44 Implementacioacuten de Pruebas en para el inicio de sesioacuten de CHT Cloud Manager 74
Figura 45 Ejemplo de reporte de pruebas automatizadas con Robot Framework 75
Figura 46 Ejemplo de documentacioacuten generada con Libdoc 77
Figura 47 Ejemplo de documentacioacuten generada con Testdoc 77
Figura 48 Ejemplo de Flujo de Trabajo en Redmine para Galgus CHT Cloud Manager 79
Figura 49 Esquema Graacutefico de Metodologiacutea Scrum 79
Figura 50 Logo de Galgus CHT Cloud Manager 82
Figura 51 Estructura del Proyecto 83
Figura 52 Fragmento del fichero ldquoSelectorpyrdquo 83
Figura 53 Fragmento del fichero ldquoCommon_Keywordsrobotrdquo 84
Figura 54 Fragmento del fichero de Configuracioacuten de pruebas ldquoConfigurationrobotrdquo 84
Figura 55 Diagrama de paquetes del proyecto de pruebas 85
Figura 56 Estructura de una Suite de Pruebas 85
Figura 57 Ejemplo de ldquoTest Setuprdquo personalizado para un caso de prueba 86
Figura 58 Vista de Gestioacuten Principal (Cloud Tab) 87
Figura 59 Pestantildea ldquoAdministrationrdquo 87
Figura 60 Diagramas de Flujo de Casos de Prueba U0025 y U0027 88
Figura 61 Script de Pruebas U0025 88
Figura 62 Keyword ldquoEdit Fieldsrdquo 88
Figura 63 Pestantildea ldquoList of Zone Managersrdquo 89
Figura 64 Diagrama de flujo de Caso de Prueba U0023 89
Figura 65 Script de Prueba U0023 90
Figura 66 Keyword ldquoZone Manager is registered successfullyrdquo 90
Figura 67 Seccioacuten de Fabricantes 90
Figura 68 Diagrama de flujo de Caso de Prueba U0009 91
Figura 69 Script de Prueba U0009 91
Figura 70 Toast Success 92
Figura 71 Keyword ldquoCorrectly Createrdquo 92
Figura 72 Setup amp Teardown de U0008 92
21
Figura 73 Mapa de Zone Managers 92
Figura 74 Funcioacuten que dibuja los ZM en el Mapa y obtiene los piacutexeles en pantalla 93
Figura 75 Diagrama de Flujo de Caso de Prueba U0007 94
Figura 76 Pestantildea ldquoGroupsrdquo 95
Figura 77 Diagrama de flujo de Caso de Prueba U0119 96
Figura 78 Script de Prueba U0119 97
Figura 79 Keyword ldquoVerify if AP is registered Succesfully on grouprdquo 97
Figura 80 Keywords Input Into Text Field y Clear Field Of Characters 97
Figura 81 Pestantildea ldquoCHT Zonesrdquo 98
Figura 82 Diagrama de Flujo de Caso de Prueba U0204 99
Figura 83 Scripts de Prueba U0204 99
Figura 84 Keyword Add Zone CHT to AP 99
Figura 85 Pestantildea BackupRestore 100
Figura 86 Diagrama de Flujo de Caso de Prueba U0401 101
Figura 87 Script de Prueba U0401 101
Figura 88 Keyword Restore For AP hace done successfully 101
Figura 89 Pestantildea ldquoFirmwarerdquo 102
Figura 90 Diagrama de Flujo de Caso de Prueba U0303 103
Figura 91 Script de Prueba U0303 103
Figura 92 Keyword Flash AP 103
Figura 93 Pestantildea ldquoVLAN amp Bridgesrdquo 104
Figura 94 Diagrama de Flujo de Caso de Prueba U0527 105
Figura 95 Script de Prueba U0527 105
Figura 96 Keyword Go And Create VLAN 105
Figura 97 Pestantildea SSIDs 106
Figura 98 Diagrama de Flujo de Caso de Prueba U0530 106
Figura 99 Script de Prueba U0530 107
Figura 100 Keyword Go And Create SSID 107
Figura 101 Pestantildea ldquoCHTrdquo 108
Figura 102 Diagrama de Flujo de Caso de Prueba U0539 109
Figura 103 Script de Prueba U0539 109
Figura 104 Keyword ACA Is Working 109
Figura 105 Keyword Changes On CLI 110
Figura 106 Comando CHT para obtener el estado del moacutedulo ACA en el punto de acceso 110
Figura 107 Pestantildea ldquoRadiusrdquo 110
Figura 108 Escenario de Funcionamiento de Servidor Radius 110
Figura 109 Diagrama de Flujo de Caso de Prueba U0601 111
Figura 110 Script de Prueba U0601 111
Figura 111 Keyword Create Radius Profile 112
22
Figura 112 Pestantildea Captive Portals 112
Figura 113 Escenario de Funcionamiento de un Portal Cautivo 112
Figura 114 Diagrama de Flujo de Caso de Prueba U0701 113
Figura 115 Script de Prueba U0701 113
Figura 116 Keyword Edit or Delete Captive Portal Profile 114
Figura 117 Pestantildea General 115
Figura 118 Diagrama de Flujo de Caso de Prueba U0522 116
Figura 119 Script de Prueba U0522 116
Figura 120 Keyword Check Number of Clients Increases 116
Figura 121 Pestantildea AP Network 117
Figura 122 Libreriacutea SSH para Robot Framework 117
Figura 123 Ventana de Configuracioacuten de TC Rules 118
Figura 124 Diagrama de Flujo de Caso de Prueba U0511 119
Figura 125 Script de Prueba U0511 120
Figura 126 Keyword Wait Timer 120
Figura 127 Keyword Check On CLI 120
23
24
GLOSARIO
CHT Cognitive Hostpot Technology
BDD Behaviour-Driven Development
MBT Model Based Testing
API Application Programing Interface
UAT User Acceptance Testing
SUT System Under Test
UML Unified Modeling Language
FSM Finite State Machine
RAE Real Academia Espantildeola
IEEE Institute of Electronical and Electronics Engineers
ITIL Information Technology Infrastructure Library
ISO International Organization for Standardization
WebQEM Web-site Quality Evaluation method
ISTQB International Software Testing Qualifications Board
TDD Test-Driven Development
SOA Service Oriented Architecture
WiFi Wireless Fidelity
MGR Manager Module
SB Smart Band Steering Module
TCM Traffic Congestion Management Module
LOC Localization Module
POWER Power Control Module
SR Smart Roaming Module
LB Load Balancing Module
AMQP Advance Message Queuing Protocol
HTML HyperText Markup Language
CSS Cascading Style Sheets
HTTPS HyperText Transfer Protocol Secure
TLS Transport Layer Security
REST REpresentational State Transfer
JSON JavaScript Object Notation
DOM Document Object Model
SQL Structure Query Language
ZMB Zone Manager Backend
ZTP Zero-Touch Provisioning
25
RF Robot Framework
CICD Continuous IntegrationContinuous Delivery
SSH Secure SHell
SCP Secure Copy ProtocolSimple Communication Protocol
26
27
1 INTRODUCCIOacuteN
ctualmente el desarrollo software se encuentra en un proceso revolucionario cuyo principal objetivo y
tendencia es la implantacioacuten y desarrollo de software distribuido donde se marcan como principales
objetivos la disponibilidad usabilidad y funcionalidad de cualquier aplicacioacuten a traveacutes de internet Es
aquiacute donde entran en juego entre otros el desarrollo de aplicaciones o servicios Web sustituyendo en gran
medida al desarrollo de aplicaciones y servicios de escritorio
Figura 1 Fuente de datos Morgan Stanley
Muchos son los aspectos a tener en cuenta entre los que cabe destacar la eficiencia la velocidad de respuesta y
de navegacioacuten los cuales para algunos servicios Web son excelentes pero para otros auacuten se encuentran en un
proceso de mejora Esto es debido a que gran cantidad de aplicaciones requieren de un buen disentildeo donde se
optimicen el uso de los recursos disponibles como el ancho de banda memoria carga del servidor respaldo
seguridad etc
A
Hemos establecido la civilizacioacuten de manera que los
maacutes cruciales elementos dependen de la ciencia y la
tecnologiacutea
Carl Sagan
28
11 Motivacioacuten
La gran demanda de servicios y aplicaciones Web distribuidas que permitan gestionar agilizar y simplificar
cualquier aacutembito de negocio hace que cada vez maacutes que dichas aplicaciones contemplen un mayor
conjunto de requisitos solicitados por los clientes lo cual se traduce en un mayor nuacutemero de funcionalidades
y casos de uso contemplados en dichas aplicaciones
Ademaacutes dichas aplicaciones se necesitan cada vez en un menor tiempo lo cual conlleva a reducir los
periodos en las diversas fases por las que pasa un proyecto software desde la fase de disentildeo hasta la de
pruebas Es en esta uacuteltima donde antes de ser entregada al cliente como un producto se detectan los
posibles errores e incluso se puede evaluar si la funcionalidad ofrecida por la aplicacioacuten esta alineada con
los requisitos demandados por el cliente
Los fallos o errores en las aplicaciones Web mal probadas bien por falta de asignacioacuten de tiempo o recursos
a la fase de pruebas tienen una mayor repercusioacuten teniendo el potencial de generar una gran cantidad de
quejas e insatisfaccioacuten por parte de los clientes casi inmediatamente En el caso de las aplicaciones Web
no soacutelo se trata de peacuterdidas econoacutemicas sino tambieacuten de peacuterdida de prestigio fiabilidad y credibilidad por
parte de nuestros usuarios o clientes Los consumidores de hoy demandan una tecnologiacutea intuitiva y de
confianza en un mercado en continuo crecimiento donde un pequentildeo error puede acarrear falta de
satisfaccioacuten en un usuario peacuterdidas millonarias a una empresa o incluso dantildeos humanos Y es en este tipo
de ciclos iterativos y raacutepidamente cambiantes donde la automatizacioacuten de pruebas juega un papel decisivo
iquestY cuaacutel es la causa de estos problemas Para ello debemos tener en cuenta que estos sistemas son disentildeados
por el ser humano el cual comete fallos ya sea por presioacuten en los plazos de trabajo por la complejidad del
coacutedigo o de la infraestructura por cambios de tecnologiacuteas o por cualquier otra interaccioacuten con el sistema
Como ha quedado reflejado un proceso riguroso de control de sistemas y documentacioacuten permiten
bull Ayudar a reducir el riesgo de los posibles fallos y Mejora la calidad de los sistemas a la hora de ser
usados
bull Un correcto mantenimiento del producto a lo largo del ciclo de desarrollo
bull Un cumplimiento de requisitos legales (normas nacionales e internacionales ordenanzas
municipales etc)
bull Una adecuacioacuten de un sistema a los requisitos contractuales
bull Una adaptacioacuten de estaacutendars especiacuteficos de la industria
La forma en la que se logre y las herramientas empleadas variaraacuten en funcioacuten de factores como la
envergadura y tipo de proyecto den cuanto a los riesgos tecnoloacutegicos de seguridad o de negocio asiacute como
del presupuesto y tiempo disponible
Figura 2 Manual Testing vs Automated Testing [20]
29
12 Alcance y Objetivos
Las pruebas de software o software testing pueden llevarse a la praacutectica de muacuteltiples maneras pero el
presente proyecto se centra en el componente funcional del producto enfocado en lo que hace el sistema y
no coacutemo primando la aceptacioacuten por parte de los usuarios en base a los requisitos de disentildeo originales Es
decir el punto de mira estaacute en cumplir los requisitos establecidos por el cliente dejando fuera del alcance
del proyecto la estructura del coacutedigo fuente implementado
Bajo este contexto se plantea la automatizacioacuten de la fase de pruebas de una aplicacioacuten Web distribuida
centrando el enfoque de este proyecto en la automatizacioacuten de pruebas funcionales maacutes concretamente
pruebas de humo or smoke tests y aceptacioacuten Hasta ahora dichas pruebas se realizaban manualmente por
un ingeniero de pruebas lo cual permitiacutea evaluar la calidad del producto que seriacutea entregado al cliente
Ademaacutes se realizaraacute un marco teoacuterico donde se resumiraacuten una clasificacioacuten de los diferentes tipos de
pruebas software que pueden realizarse sobre una aplicacioacuten
Concretamente la solucioacuten abordada en esta memoria se cintildee al mantenimiento de un producto Web como
es la plataforma Galgus CHT Cloud Manager Para ello se cubriraacuten un gran conjunto de funcionalidades
ofrecidas por dicha aplicacioacuten Web como por ejemplo inicio y cierre de sesioacuten flujos de navegacioacuten
comprobacioacuten de los elementos mostrados y uso de la caja de buacutesquedas Sin llegar a ser exhaustivos este
tipo de pruebas conocidas como smoke tests son faacutecilmente automatizables y permiten detectar las primeras
sentildeales de que un sistema no funciona de manera correcta Por tanto es necesario traducir los requisitos
funcionales a instrucciones de alto nivel faacutecilmente entendibles por personas con poca formacioacuten teacutecnica
dado que seraacute el el resultado mostrado de las pruebas realizadas (informes de pruebas) Estas instrucciones
usaraacuten Behaviour-Driven Development (BDD) para describir interacciones entre el usuario y el sistema
definiendo actor accioacuten y comportamiento esperado del sistema Robot Framework es la herramienta que
se usa para este punto
Una vez tenemos dichas instrucciones se deben traducir de nuevo a un lenguaje de menor nivel como es
Python para implementar los test scripts Estos scripts seraacuten los que Selenium Webdriver procese y traduzca
para comunicarse con el controlador del navegador Web Chrome en nuestro caso a traveacutes de una API
Posteriormente el navegador se encargaraacute de ejecutar los comandos de accioacuten y de devolver la informacioacuten
de estado de vuelta Finalmente Robot Framework elaboraraacute un informe en formato html detallando las
pruebas realizadas resultados de las interacciones tiempos de ejecucioacuten y espera errores producidos etc
Tambieacuten se realizaraacute un estudio del arte sobre una teacutecnica conocida como Model Based Testing (MBT)
Dicha teacutecnica permite la generacioacuten automaacutetica de las pruebas a realizar sobre un sistema partiendo del
modelado del comportamiento de dicho sistema Ademaacutes esta teacutecnica tambieacuten abarca la traduccioacuten de las
pruebas generadas en scripts ejecutables para aplicar dichas pruebas sobre el sistema dando tambiacuteeacuten la
posibilidad de evaluar los resultados Esto proporciona muchas ventajas sobre la fase de pruebas pero a la
vez tambieacuten requiere un mayor esfuerzo en la fase de disentildeo y una presencia continua de la fase de pruebas
en otras etapas del ciclo de vida del proyecto Tambieacuten se presentaraacute un conjunto de normativas que regula
y normaliza la gestioacuten de calidad software
Posteriormente se describiraacute el sistema sobre el cual se basa la aplicacioacuten bajo pruebas llamada CHT
Cloud Manager Se presentaraacute la arquitectura de la aplicacioacuten y posteriormente se destacaraacuten los objetivos
de automatizacioacuten de testeo sobre la misma proponiendo el entorno de UAT planteado para someter la
aplicacioacuten a las pruebas automaacuteticas desarrolladas Se dedicaraacute una seccioacuten a analizar las tecnologiacuteas y
herramientas usadas donde se centraraacute la atencioacuten en Robot Framework Selenium y Python como las
tecnologiacuteas usadas para automatizar el testeo Ademaacutes se destacaraacute la integracioacuten del entorno de UAT
como fase de la integracioacuten continua de la aplicacioacuten ademaacutes de la metodologiacutea de trabajo llevada a cabo
Finalmente se presentaraacuten algunos experimentos y demostraciones de uso de la herramienta desarrollada
se describiraacuten algunas liacuteneas de mejora y conclusiones y se incluiraacuten algunos posibles anexos para la puesta
en marcha de la aplicacioacuten y reportes de algunas pruebas entre otros
30
13 Estructura de la memoria
El siguiente esquema resume de forma geneacuterica los puntos tratados en esta memoria para que el lector pueda
tener una idea orientativa de la organizacioacuten de este documento
1 Introduccioacuten En este punto se abordan temas geneacutericos como los objetivos motivacioacuten y alcance de
forma que pueda adquirirse una breve aproximacioacuten a los detalles del proyecto
2 Estudio del Arte y Revisioacuten A lo largo de esta seccioacuten se presentaraacute un estudio sobre la teacutecnica
conocida como Model Based Testing la cual permitiriacutea mejorar el proceso de automatizacioacuten de
pruebas Ademaacutes se realiza una revisioacuten sobre la gestioacuten de Calidad Software presentado algunos
modelos existentes en la actualidad
3 Marco Teoacuterico Consta de un estudio sobre el proceso de pruebas en un proyecto Software y los
principales tipos de pruebas Software existentes
4 Sistema En este punto se presenta la arquitectura del sistema sobre el que se van a automatizar las
pruebas de aceptacioacuten o Smoke Tests Ademaacutes se describe el alcance y objetivos de dichas pruebas y
se presenta la arquitectura de la solucioacuten planteada como escenario de pruebas haciendo uso de Docker
como tecnologiacutea de automatizacioacuten en el despliegue de aplicaciones software alojadas en contenedores
de software
5 Tecnologiacuteas y Herramientas usadas Consta del conjunto de tecnologiacuteas usadas para la
implementacioacuten de las pruebas de aceptacioacuten automatizadas y las herramientas para utilizar dichas
pruebas y para gestionar el trabajo del equipo de desarrollo y calidad responsable de este proyecto
6 Experimentos Consta de un detalle sobre la funcionalidad de un conjunto de pruebas que han sido
implementadas para verificar y validar el funcionamiento esperado del sistema Para cada prueba se
definen criterios de aceptacioacuten diagramas de flujo y scripts de implementacioacuten detallando algunas de
las implementaciones clave
7 Liacuteneas de Mejora y Conclusiones Se incluye una seccioacuten conclusiones finales tras la realizacioacuten del
proyecto y una valoracioacuten del mismo a nivel general y personal Ademaacutes se destacaraacuten algunas liacuteneas
de mejora futuras relacionadas principalmente con la aplicacioacuten de Model Based Testing (MBT) y otros
aspectos sobre la implementacioacuten actual de la herramienta de automatizacioacuten
Ademaacutes se realizaraacute una seccioacuten de anexos en el que se trataraacuten puntos adicionales sobre el proyecto
bull Anexo A Preparacioacuten del Entorno de Trabajo y Ejecucioacuten de Pruebas
bull Anexo B Docker de Robot Framework y Entorno de UAT Dockerizado
bull Anexo C Revisioacuten de Reportes y Logs
31
32
2 ESTUDIO DEL ARTE Y REVISIOacuteN
n este punto se realizaraacute un estudio sobre el marco teoacuterico de una de las teacutecnicas existentes que permite
la generacioacuten y ejecucioacuten automaacutetica de casos de test a partir del modelado de un sistema para la fase
de pruebas de una aplicacioacuten Esta teacutecnica es conocida como Model Based Testing (MBT) Ademaacutes
se realizaraacute una revisioacuten de la normativa relacionada con la gestioacuten de calidad software analizando la familia de
normas ISOIEC 25000
21 Model Based Testing (MBT)
211 Introduccioacuten
Dada la rapidez con la que se demandan los servicios contratados por los clientes en muchas ocasiones la
mayoriacutea del tiempo y esfuerzo asignado para la realizacioacuten de proyectos de software van destinados a la
labor de desarrollo dedicando menos esfuerzos en otras fases del ciclo de vida de un proyecto como las
fases de disentildeo o de pruebas Esto puede conllevar a que el proyecto no se desarrolle de acuerdo con los
requisitos demandados por los clientes y que el nuacutemero de puntos de fallo del producto software aumente
La fase de testeo o prueba de un producto software durante su ciclo de vida es una etapa fundamental para
validar la calidad del producto desarrollado y ofrecido a un cliente para conseguir un grado de satisfaccioacuten
aceptable de forma que se cumpla con los requisitos demandados y con el menor grado de error posible
Figura 3 Fase de Pruebas y Validacioacuten
Uno de los factores por los que en ocasiones no se emplean suficientes recursos a la fase de pruebas es la
gran cantidad de casos de pruebas que se deben realizar para validar un sistema Por cada caso de prueba
se deben asignar recursos relacionados con la planificacioacuten disentildeo y ejecucioacuten del mismo
Por tanto en este punto cabe plantearse la idea de automatizar no solo los casos de pruebas que validan un
sistema sino la generacioacuten de los casos de prueba Esto puede permitir reducir de forma considerable el
coste y esfuerzos en la fase de pruebas En este contexto surge el concepto de Model Based Testing (MBT)
E
La tecnologiacutea no es en siacute el fin sino el medio entre la
sociedad del conocimiento y el desarrollo mundial
Anoacutenimo
33
212 iquestQueacute es Model Based Testing
Este se trata de un meacutetodo capaz de controlar la calidad del software durante su ciclo de vida permitiendo
la generacioacuten automaacutetica de los casos de prueba e incluso la ejecucioacuten y evaluacioacuten automaacutetica de
resultados Para ello se requiere de un modelado y disentildeo correcto del sistema bajo pruebas como base
para la aplicacioacuten de esta teacutecnica
Figura 4 Esquema baacutesico de Model Based Testing
MBT permite crear un modelo del comportamiento esperado por el sistema a traveacutes del cual permite la
aplicacioacuten de diferentes teacutecnicas para la generacioacuten de casos de prueba [1]
bull Generacioacuten de casos de pruebas con datos de entrada sobre un modelo de dominio del sistema bull Generacioacuten de casos de pruebas de un modelo de entorno bull Generacioacuten de casos de prueba con predicciones del comportamiento del modelo bull Generacioacuten de scripts de prueba a partir de pruebas abstractas
213 iquestCoacutemo funciona Model Based Testing
En primer lugar se requiere del disentildeo de un modelo del sistema bajo test el cual debe tener al menos dos
caracteriacutesticas principales debe ser pequentildeo en relacioacuten al tamantildeo del sistema de forma que no requiera
un coste elevado pero debe ser lo suficientemente detallado para describir completamente las
caracteriacutesticas que se quieran probar sobre el sistema
Una vez implementado el modelo del sistema a probar se procederiacutea a la utilizacioacuten de herramientas
basadas en la teacutecnica MBT para generar automaacuteticamente el banco de pruebas a partir del modelo del
sistema bajo test (SUT) Estos bancos de pruebas generados seraacuten un conjunto de pruebas abstractas cada
una de las cuales define la secuencia de operaciones a realizar para probar una funcionalidad determinada
con sus respectivos valores o datos de entrada necesarios y las salidas o respuestas del sistema que se
esperan
A partir del banco de pruebas abstractas se deben transformar en scripts de pruebas ejecutables lo cual
puede realizarse con herramientas basadas en la teacutecnica MBT Estos scripts podriacutean ser ejecutados para la
deteccioacuten de errores sobre el sistema bajo test y esta ejecucioacuten podriacutea ser controlada y monitorizada por
alguna herramienta de ejecucioacuten de pruebas
En el siguiente diagrama se muestra el proceso de aplicacioacuten de este meacutetodo donde se propone dividir el
proceso en cinco fases principales [1]
1 Modelado Modelar el sistema bajo test y su entorno 2 Generacioacuten Generar las pruebas abstractas a partir del modelo planteado en la fase anterior 3 Concretizado Concretizar o adaptar las pruebas abstractas para transformarlas en ejecutables 4 Ejecucioacuten Ejecutar las pruebas sobre el sistema bajo test y definir decisiones o veredictos para las
mismas de forma que se pueda determinar el correcto funcionamiento del sistema bajo test 5 Anaacutelisis Analizar los resultados obtenidos a partir de la ejecucioacuten de los casos de prueba
34
Destacar que para el generador de casos de prueba y el script de pruebas se suelen usar herramientas de pruebas
especiales Por este motivo se encuentran resaltados en negrita
Figura 5 Proceso detallado de Model Based Testing (MBT)
Una vez presentado el proceso o metodologiacutea para llevar a cabo dicha teacutecnica se describiraacuten las principales
fases
2131 Construccioacuten del Modelo
Dicha fase consiste en la construccioacuten de un modelo que represente el comportamiento detallado del sistema
bajo pruebas yo su entorno a partir de los requisitos de disentildeo del mismo y el plan de pruebas desarrollado para
cumplir con estos requisitos
Este es el paso maacutes importante en la aplicacioacuten de la teacutecnica Model Based Testing ya que el resto de fases
dependeraacute siempre del modelo del sistema bajo pruebas Cuanto maacutes completo sea el modelo maacutes efectivos
seraacuten los casos de prueba generados a partir de este
Figura 6 Construccioacuten del Modelo
35
Para llevar a cabo el modelo del comportamiento de la aplicacioacuten se requiere conocer exactamente el
comportamiento esperado de la misma lo cual lleva a estudiar y analizar en profundidad el sistema y su entorno
previamente
Existen diversas especificaciones formales para el modelado a partir de los requisitos como por ejemplo los
diagramas UML Estos ayudan a que el modelado sea una tarea algo maacutes sencilla de realizar que si se llevara a
cabo a partir de los requisitos escritos en lenguaje natural Por otro lado para modelar el comportamiento existen
diversas teacutecnicas como las maacutequinas de estados finitos (FSM) Cadenas de Maacuterkov Tablas de decisiones
Diagramas de estados etc
En conclusioacuten modelar un sistema no es una tarea sencilla ya que requiere de habilidades teacutecnicas experiencia
e imaginacioacuten para construir un modelo que se comporte de la forma deseada Dicho modelo debe cumplir con
las siguientes propiedades [2]
bull Debe ser lo maacutes abstracto posible sin perder la informacioacuten importante
bull No debe contener informacioacuten que sea redundante o que no esteacute relacionada con el alcance de las
pruebas
bull Debe ser entendible para los ingenieros de pruebas incluso a expensas de la brevedad y abstraccioacuten del
mismo
bull Debe ser flexible y abierto para permitir cambios y antildeadir o eliminar nuevas funcionalidades
bull Debe considerar todos los detalles de implementacioacuten de las pruebas
2132 Generacioacuten de Casos de Prueba
Los casos de prueba seraacuten generados tras la construccioacuten previa del modelo del sistema Antes de la creacioacuten de
los casos de prueba los ingenieros de pruebas deben especificar o proveer informacioacuten sobre el criterio o
propoacutesito de los casos de prueba las entradas y en algunos casos las salidas esperadas del sistema
Destacar que generar las salidas esperadas correspondientes a unas determinadas entradas es maacutes complejo que
generar soacutelo las entradas Para ello se necesita un oraacuteculo que cree salidas vaacutelidas y las mapee a los casos de
prueba Crear el oraacuteculo es la tarea maacutes compleja
Las dificultades presentadas en esta fase dependeraacuten de si el modelo es complejo o simple y la efectividad de
los casos de prueba generados dependeraacute de lo completo y preciso que sea dicho modelo para poder generar
automaacuteticamente los casos de prueba
Cuando el sistema es complejo la cantidad de casos de test es muy grande e incluso infinita Por tanto evaluar
todos los casos de test resulta inviable y costoso En este caso para mejorar la calidad del sistema se necesita
seleccionar los casos de test que realmente puedan ayudar a localizar tantos fallos como sea posible con un coste
aceptable
Existen diferentes criterios de cobertura que permiten ayudar a controlar el proceso de generacioacuten de casos de
prueba Sin embargo se recomienda seleccionar maacutes de uno de estos criterios para lograr un mayor resultado en
la cobertura de pruebas
2133 Ejecucioacuten de Casos de Prueba
La ejecucioacuten de los casos de pruebas requiere la transformacioacuten de los mismos en una forma ejecutable Debido
a que los los scripts de pruebas ejecutables pueden ser reutilizados durante todo el tiempo empleado en la
validacioacuten del sistema estos deben ser escritos de una forma maacutes eficiente que permita que sean reutilizables e
incluso que frente a una modificacioacuten sean maacutes faacuteciles generarlos y ejecutarlos Por ello se crean scripts
ejecutables para los casos de prueba abstractos
El proceso de transformacioacuten en pruebas ejecutables seriacutea maacutes eficiente si es hecha de forma automaacutetica
Despueacutes de aplicar los casos de prueba ejecutables al sistema bajo pruebas se obtienen las salidas actuales del
sistema las cuales deberaacuten ser contrastadas con las salidas esperadas
36
2134 Anaacutelisis de los Resultados
Una vez ejecutados los casos de pruebas y obtenidas las salidas actuales del sistema se deben evaluar y analizar
los resultados obtenidos Para ello se debe comparar las salidas actuales obtenidas con las salidas esperadas
especificadas en los casos de prueba Esta tarea de comparacioacuten podriacutea realizarse idealmente de forma
automaacutetica lo cual dariacutea como resultados posibles
1 Pasa Cuando las salidas actuales se encuentran acordes con las salidas esperadas
2 Falla Cuando las salidas actuales no se encuentran acordes con las salidas esperadas
3 Inconcluso Cuando no se puede tomar una decisioacuten en el momento
Hay que destacar que puede darse el caso en el que si las salidas esperadas no estaacuten bien determinadas los
resultados obtenidos al contrastar dichas salidas con las actuales sean falsos dando lugar a resultados sin utilidad
y que pueden dar lugar a confusioacuten
Por este motivo la generacioacuten automaacutetica de las salidas esperadas es una tarea compleja e importante en todo el
proceso especialmente en sistemas complejos Por tanto el nivel de dificultad para encontrar un oraacuteculo de
pruebas depende del tamantildeo y complejidad del sistema Sin embargo la necesidad e importancia del oraacuteculo de
pruebas tambieacuten aumenta cuando el sistema es maacutes complejo
Tras obtener los resultados se debe determinar si se decide generar maacutes casos de prueba si se debe modificar el
modelo o si la fase de pruebas debe ser detenida y debe ponerse en marcha el software del sistema que se estaacute
probando
214 Consideraciones para la aplicacioacuten de Model Based Testing (MBT)
Son muchos los artiacuteculos que describen aspectos importantes a tener en cuenta durante el desarrollo o la
aplicacioacuten de esta teacutecnica Algunas de estas consideraciones a destacar seriacutean las siguientes [3]
1 El modelo que describe el comportamiento del sistema es el punto clave
El comportamiento del modelo debe ser desarrollado cuidadosamente Sus limitaciones y restricciones deben
ser respetadas durante el modelado del sistema bajo pruebas De esta forma si el modelo estaacute mal las pruebas
generadas tambieacuten lo estaraacuten Por tanto la exactitud del modelo es fundamental para pasar a la fase de
generacioacuten de casos de prueba
2 Las pruebas deben cubrir los criterios de control de flujo y datos
Los criterios de cobertura de las pruebas definen un conjunto de casos de prueba seleccionados para la misma
Estos casos de pruebas pueden ser generados a partir de dos fuentes criterios de flujo de control o de flujo
de datos En el caso de pruebas aplicadas a grandes sistemas es importante combinar ambos criterios para
incrementar la cobertura de las pruebas
3 El nivel de automatizacioacuten debe ser elevado
El nivel de automatizacioacuten es un factor importante para definir la factibilidad de uso de MBT Normalmente
suele haber un uacutenico paso no automatizado el modelado del comportamiento del sistema el cual es utilizado
como entrada para el proceso de generacioacuten de los casos de prueba Si hubiese otros pasos no automatizados
se incrementariacutea el esfuerzo los costes y la complejidad de su uso
4 Son fundamentales las herramientas que soportan la automatizacioacuten de las fases de MBT
Las herramientas usadas deben soportar la ejecucioacuten de los pasos automatizados Si no hay una herramienta
que soporte un determinado paso esta tarea podriacutea ser difiacutecil e inviable Por tanto una herramienta debe
soportar la integracioacuten entre los diferentes pasos no automatizados y automatizados
5 Los liacutederes del proyecto deben entender las habilidades requeridas y la complejidad para usar
MBT
Las personas encargadas de la fase de pruebas necesitan conocer ademaacutes de las teacutecnicas de pruebas los
lenguajes de modelado y algunos lenguajes de programacioacuten
37
6 El orden de los pasos a seguir mientras se usa un enfoque MBT
Es necesario respetar los pasos seguidos para la generacioacuten de los casos de prueba de forma que sean
respetados en la fase de ejecucioacuten de las pruebas siendo ejecutados en la misma secuencia en que fueron
definidos En caso contrario se podriacutean generar salidas erroacuteneas de dichas pruebas
7 Transferencia de la Tecnologiacutea
Las tecnologiacuteas usadas para la aplicacioacuten de la teacutecnica MBT se transfieren desde entornos acadeacutemicos o de
investigacioacuten para ser implementados en proyectos industriales Por este motivo necesitan ser analizados
cuidadosamente antes de ser usadas
215 Beneficios de Model Based Testing (MBT)
A continuacioacuten se definen diversos beneficios que proporciona la aplicacioacuten de Model Based Testing para la
fase de pruebas [1] [4]
1 Deteccioacuten de Fallos del Sistema Bajo Pruebas
El modelado del comportamiento del sistema bajo pruebas permite detectar errores ambiguumledades o lagunas
que pueden presenciarse en la toma de requisitos especificacioacuten y disentildeo del software Por tanto permite
una deteccioacuten temprana de errores
2 Reduccioacuten de costes y tiempo en la fase de pruebas
La aplicacioacuten de esta teacutecnica contribuye a que el tiempo coste y recursos empleados a la fase de pruebas
disminuya Sin embargo se requiere una mayor asignacioacuten de recursos para el modelado y mantenimiento
del sistema
3 Mejora de la calidad de las pruebas
Cuando las pruebas se desarrollan manualmente la calidad de las mismas es muy dependiente de los
desarrolladores que la implementan Ademaacutes el proceso de disentildeo no puede ser reproducido el criterio
racional aplicado para cada prueba normalmente no es recordado y el resultado de los casos de prueba no es
faacutecilmente interpretado ni contrastado con los requisitos originales del sistema
Model Based Testing es una teacutecnica capaz de mejorar mucho estos inconvenientes que se presentan sobre el
desarrollo de pruebas manuales gracias al generador automatizado de casos de prueba
4 Trazabilidad
Puede definirse como la habilidad para relacionar cada caso de prueba al modelo criterio de seleccioacuten e
incluso a los requisitos informales del sistema Esto ayuda a explicar los casos de prueba asiacute como justificar
por queacute fueron creados Los algoritmos aplicados para la generacioacuten de pruebas deben saber queacute partes del
modelo seraacuten empleadas en cada caso de prueba y las salidas esperadas
5 Evolucioacuten de los requisitos
Si los requisitos del sistema cambian con la aplicacioacuten de Model Based Testing bastariacutea con actualizar el
modelo y las pruebas seraacuten generadas de nuevo de forma automaacutetica Debido a que el modelo es usualmente
maacutes pequentildeo que el conjunto de pruebas del sistema requiere menos tiempo actualizar el modelo que
actualizar todos los casos de prueba Por tanto puede concluirse que se obtiene una respuesta maacutes raacutepida
frente a un cambio en los requisitos
6 Reusabilidad del modelo
El modelo contiene informacioacuten sobre el comportamiento del sistema bajo pruebas Por tanto este puede ser
reutilizado en futuras pruebas incluso cuando los requisitos cambian
38
216 Problemas y Limitaciones de Model Based Testing (MBT)
Una vez destacados los beneficios que aporta dicha teacutecnica tambieacuten es importante detallar algunos problemas
y limitaciones sobre su uso [1] [5]
2161 Problemas
bull Para abordar dicha teacutecnica es necesario que los ingenieros de pruebas tengan habilidades teacutecnicas sobre
la notacioacuten usada para el modelado del sistema Ademaacutes deberiacutean tener experiencia con herramientas
scripts y lenguajes de programacioacuten usados para ejecutar las tareas de Model Based Testing
bull Cuando dicha teacutecnica se pretende aplicar a sistemas complejos el modelado del sistema es maacutes
complejo y existe riesgo de producirse un desbordamiento de la cantidad de casos de prueba generados
a partir del modelo Por esta razoacuten es muy importante definir bien el conjunto de criterios para la
generacioacuten de las pruebas lo cual permite acotar la cobertura de pruebas de forma razonable
bull La automatizacioacuten de la generacioacuten del oraacuteculo de pruebas a partir del modelo es compleja
especialmente en sistemas complejos Cuando el tamantildeo del sistema aumenta la necesidad de
automatizacioacuten tambieacuten aumenta
bull Es necesario desarrollar un modelo de software especiacutefico para un dominio en concreto de aplicacioacuten
ya que existen diversas notaciones de modelado del sistema
bull Es necesario la especificacioacuten formal de los requisitos para obtener el modelo del sistema a partir de
estos La especificacioacuten informal o en lenguaje natural de los requisitos puede dar lugar a ambiguumledades
que dificultan la exactitud en el modelado
2162 Limitaciones
bull No es posible modelar todos los aspectos del comportamiento del sistema bajo pruebas Por tanto es
necesario el uso de otras notaciones de modelado que cubran dichos aspectos
bull Los proyectos software evolucionan continuamente surgiendo nuevos requisitos los cuales algunos
pueden quedar fuera de la fecha de planificacioacuten Si se ha comenzado con el modelado a partir de
requisitos antiguos se construiraacute un modelo erroacuteneo que no reflejaraacute los nuevos requisitos
contemplados lo cual daraacute lugar a errores en el sistema bajo pruebas o resultados no fiables
bull Cuando se produce un fallo en una prueba generada podriacutea resultar maacutes complejo determinar la causa
del fallo ya que la secuencia de pruebas generadas en Model Based Testing podriacutea ser maacutes compleja y
menos intuitiva que las disentildeadas manualmente
217 Cuando elegir Model Based Testing (MBT)
Finamente tras detallar los beneficios problemas y limitaciones sobre la teacutecnica bajo estudio se destacan
algunos puntos principales a tener en cuenta para la aplicacioacuten de dicha teacutecnica
bull Debe existir documentacioacuten lo suficientemente buena sobre el sistema para poder aplicarla
bull Si ya existe un modelo del sistema seriacutea un primer paso que facilitariacutea su aplicacioacuten
bull El manager del proyecto debe ser consciente que la fase de pruebas con Model Based Testing comienza
desde la toma de requisitos ya que se debe modelar el comportamiento del sistema bajo pruebas a partir
de estos Por tanto no se puede esperar que la fase de pruebas comience despueacutes del desarrollo Hacerlo
tras el desarrollo podriacutea significar la modificacioacuten de los requisitos y en consecuencia el desarrollo
39
22 Gestioacuten de Calidad Software
221 Introduccioacuten
En los uacuteltimos antildeos la creciente demanda de productos software principalmente de aplicaciones distribuidas
como los servicios Web provoca que diferentes empresas busquen soluciones software para satisfacer las
necesidades de los clientes Este conjunto de empresas forma un entorno competitivo en el que se intenta buscar
algunos factores para destacar sobre los demaacutes competidores respondiendo a las nuevas exigencias del mercado
Bajo este contexto se plantea la implantacioacuten de una direccioacuten basada en la calidad como la propuesta que
mejores resultados ha ofrecido No solo basta con desarrollar software acorde a los requisitos de los clientes y
las exigencias de los mismos sino que se trata de crear un producto que garantice su correcto funcionamiento
bajo el sustento de una garantiacutea de calidad razonable
El concepto de ldquocalidadrdquo siempre se ha relacionado con la inspeccioacuten de productos fiacutesicos Pero dicho teacutermino
ha ido expandiendo su contexto de una forma maacutes global y aplicable a cualquier tipo de servicio o producto
ofrecido a un cliente
222 Concepto de Calidad
Acorde a la definicioacuten ofrecida por la Real Academia Espantildeola (RAE) la calidad se define como ldquouna propiedad
o conjunto de propiedades inherente a algordquo ldquoAdecuacioacuten de un producto o servicio a las caracteriacutesticas
especificadasrdquo o ldquocondicioacuten o requisito que se pone en un contratordquo [6]
Por otro lado el instituto de Ingenieros Eleacutectricos y Electroacutenicos (IEEE) define la calidad como ldquoel grado con
el que un sistema componente o proceso cumple con los requisitos especificados y las necesidades o
expectativas del cliente o usuariordquo destacando que el eacutenfasis radica en los requisitos especiacuteficos del sistema y
en la buacutesqueda de la satisfaccioacuten del cliente [7]
Roger Pressmann define la Calidad del Software como ldquoConcordancia del software producido con los requisitos
expliacutecitamente establecidos con los estaacutendares de desarrollo prefijados y con los requisitos impliacutecitos no
establecidos formalmente que desea el cliente y en uacuteltima instancia el usuariordquo [8]
Una vez presentado el concepto de calidad su definicioacuten orientada al software se refiere al grado de desempentildeo
de las principales caracteriacutesticas con las que debe cumplir un sistema durante su ciclo de vida Estas
caracteriacutesticas son las que garantizan que el cliente cuente con un sistema confiable lo que permite un aumento
de la satisfaccioacuten frente a la funcionalidad y eficiencia del sistema construido
Figura 7 Concepto de Calidad
40
223 Modelos de Calidad de Software
Los modelos de calidad son aquellos documentos que integran la mayor parte de las mejores praacutecticas proponen
temas de administracioacuten en los que cada organizacioacuten debe hacer eacutenfasis integran diferentes praacutecticas dirigidas
a los procesos clave y permiten medir los avances en calidad
Bajo este contexto los modelos de calidad deben permitir la evaluacioacuten del sistema de forma cualitativa o
cuantitativa y de acuerdo con esta evaluacioacuten la organizacioacuten podraacute proponer implementar estrategias que
permitan la mejora continua en el resto de etapas del ciclo de vida como son las etapas de anaacutelisis disentildeo
desarrollo y pruebas software [7] Desde finales de los antildeos 70 se han ido desarrollando diversos modelos de
calidad del producto software con el fin de fijar una terminologiacutea y entender queacute concepto de calidad se estaacute
usando Asiacute mismo dichos modelos de calidad se clasifican de acuerdo con el enfoque de evaluacioacuten
contemplado ya sea a nivel de proceso producto o calidad de uso
2231 Calidad a Nivel de Proceso
Este enfoque de calidad de software describe que la calidad de un sistema software debe ser implementada desde
el inicio del proyecto y en cada etapa de su ciclo de vida debiendo permitir el control y seguimiento de los
aspectos de calidad para minimizar los riesgos y ofrecer un soporte continuo De esta forma se consigue
garantizar un nivel oacuteptimo de cumplimiento de los factores de calidad definidos teniendo en cuenta que si en
alguna etapa no se verifican dichos factores posiblemente disminuya el nivel de calidad no solo del proceso si
no tambieacuten del producto en desarrollo [7]
A continuacioacuten se muestra una liacutenea de tiempo de algunos modelos a nivel de proceso y se describen dos de los
que maacutes intereacutes presentan dentro del aacutembito de este proyecto
Figura 8 Liacutenea de tiempo de modelos a nivel de proceso
ITIL (Information Technology Infrastructure Library)
Desarrollado en el Reino Unido con el fin de fortalecer la gestioacuten gubernamental a partir de cinco elementos
fundamentales la perspectiva del negocio entrega del servicio soporte del servicio manejo de la infraestructura
y manejo de aplicaciones con el propoacutesito de ofrecer una estructura integral para prestar a la organizacioacuten un
servicio completo cubriendo necesidades de apoyo de instalacioacuten adecuacioacuten de redes comunicaciones
hardware servidores sistema operativo y software necesarios
Figura 9 Logo de ITIL
41
ISOIEC 20000
El objetivo principal de esta norma es avalar que la prestacioacuten de servicios de TI en una empresa cuenta con la
calidad necesaria para brindar dichos servicios a los clientes Esta norma engloba diferentes secciones dedicadas
a las especificaciones de dicha norma y a los coacutedigos de buenas praacutecticas
Figura 10 ISOIEC 20000
WebQEM
Web-site Quality Evaluation Method se trata de una metodologiacutea de evaluacioacuten de calidad de sitios Web en seis fases planificacioacuten y programacioacuten de la evaluacioacuten de la calidad definicioacuten y especificacioacuten de los requisitos de calidad establecidos definicioacuten e implementacioacuten de la evaluacioacuten elemental definicioacuten e implementacioacuten de la evaluacioacuten global anaacutelisis de resultados y evaluacioacuten de meacutetricas y finalmente conclusiones y documentacioacuten
Figura 11 Logo de WebQEM
42
2232 Calidad a Nivel de Producto
El enfoque de la calidad de software a nivel de producto tiene como objetivo especificar y evaluar el
cumplimiento de los criterios del producto Para ello se suelen definir y aplicar medidas o meacutetricas internas o
externas Por esta razoacuten muchas normas definen la calidad a nivel de producto de tipo interna externa y en uso
Esta uacuteltima se define como el conjunto de atributos relacionados con la aceptacioacuten por parte del usuario final y
seguridad
A continuacioacuten se muestra una liacutenea de tiempo de algunos modelos a nivel de proceso y se describen tres de los
que maacutes intereacutes presentan dentro del aacutembito de este proyecto
Figura 12 Liacutenea de tiempo de modelos a nivel de producto
ISO 9126
Este se basa en el modelo McCall el cual es uno de los modelos pioneros en la evaluacioacuten de la calidad de
software Desarrollado en 1991 es un marco normativo dirigido a desarrolladores aseguradores de calidad
evaluadores analistas y cualquier otro involucrado en el proceso de construccioacuten de software y la gestioacuten de
calidad del mismo Estaacute dividido en cuatro partes Modelo de Calidad Meacutetricas Externas Meacutetricas Internas y
Calidad de Meacutetricas en Uso
Esta norma busca la fiabilidad funcionalidad usabilidad eficiencia mantenibilidad y portabilidad en la
construccioacuten de productos software A continuacioacuten se muestra un esquema que resume dichas caracteriacutesticas
y subcaracteriacutesticas [8]
Figura 13 Esquema de ISO 9126
43
ISOIEC 25000
Basada en la norma ISO 9126 y adaptando parte del marco normativo a las necesidades del mercado actual Esta
norma tambieacuten conocida como SQuaRE (Software Product Quality Requirements and Evaluation) establece
un marco de trabajo comuacuten para evaluar la calidad de productos de Software
En dicha norma se definen los modelos teacuterminos y definiciones comunes para el resto de normas que componen
la serie 25000 La ISOIEC 25000 presenta diversas secciones entre las que se puede destacar [9]
ISOIEC 25010 Describe las caracteriacutesticas y subcaracteriacutesiticas de calidad que pueden ser evaluadas
en un producto software diferenciando entre calidad interna externa y de uso En la siguiente figura se
presenta un desglose de dichas caracteriacutesticas
ISOIEC 25040 Define el proceso de evaluacioacuten perioacutedico de la calidad del producto software
Figura 14 Esquema de ISOIEC 25000
44
224 Principales Ventajas e Inconvenientes de Modelos de Calidad anteriores
2241 A nivel de Proceso
Modelo Ventajas Inconvenientes
ITIL bull Mejor estructuracioacuten organizacioacuten y
claridad de los proyectos
bull Mayor control administrativo
bull Mayor eficacia y rapidez ante cambios
bull Incrementa la productividad del negocio y la
fiabilidad de los clientes
bull Tiempo y esfuerzo necesarios
bull Falta de conocimiento para apreciar la mejora
proporcionada
bull Involucracioacuten y compromiso de todo el
personal de la organizacioacuten
bull Frustracioacuten generada por expectativas a corto
plazo
bull No hay mejoriacutea si la inversioacuten asignada para
implantar el modelo es insuficiente
ISOIEC
20000 bull Reconocimiento internacional
bull Muy usado por las organizaciones
WebQUEM bull Calidad medida en fases y actividades de
forma cuantitativa con indicadores
bull Aplicaciones de Software centradas en la Web
son cada vez maacutes complejas provocan mayor
complejidad en su implantacioacuten
2242 A nivel de Producto
Modelo Ventajas Inconvenientes
ISO 9126 bull Determina queacute caracteriacutesticas y
subcaracteriacutesticas son importantes para el
producto
bull Define meacutetricas especiacuteficas para los
componentes Software
bull Define indicadores para las caracteriacutesticas de
calidad
bull Usabilidad tratada desde la perspectiva del
proceso no del producto
bull No tiene en cuenta la caracteriacutestica de ldquofacilidad
de aprendizajerdquo siendo esta recomendada por
otros estaacutendares
bull Meacutetricas complejas difiacutecilmente medibles
Requieren descomposicioacuten
ISOIEC
25000 bull Detecta objetivos del producto alineados con
necesidades reales de clientes finales
bull Evita ineficiencias y maximiza rentabilidad
y calidad del producto
bull El proceso de evaluacioacuten perioacutedica permite
la mejora continua
bull No establece niveles de calidad para cada
proyecto
bull No hace uso de meacutetricas o umbrales de calidad
225 Conclusiones
Una vez presentado el concepto de gestioacuten de calidad de software y los principales modelos y normas es
interesante destacar la diferencia entre calidad interna y externa La calidad interna se centra en las caracteriacutesticas
propias del producto software (disentildeo especificacioneshellip) mientras que la calidad externa lo hace con las
caracteriacutesticas dinaacutemicas del mismo es decir con el comportamiento Es por ello que el proceso de calidad
interna se inicia en las fases tempranas del ciclo de vida de un proyecto mientras la calidad externa se aplica
una vez se tiene un primer prototipo funcional del producto software desarrollado Por tanto se trataraacute de
automatizar el proceso de evaluacioacuten de la calidad externa del proyecto CHT Cloud Manager analizando
verificando y validando automaacuteticamente la aceptacioacuten de dicho producto
45
46
3 MARCO TEOacuteRICO PRUEBAS DE SOFTWARE
ras presentar el concepto de calidad y algunas de las normas y estaacutendares maacutes conocidos que describen
la aplicacioacuten de dicho concepto en el aacutembito del desarrollo de software se centraraacute el enfoque en el
papel del testeo y las pruebas de software Con ello se destacaraacuten algunos puntos principales para
llevar a cabo las pruebas de software el anaacutelisis disentildeo e implementacioacuten de dichas pruebas los diferentes tipos
y niveles de pruebas y las dificultades de la aplicacioacuten de pruebas de software sobre aplicaciones Web
31 Testing y Pruebas de Software
Habitualmente se tiene una percepcioacuten del testing de un producto como una tarea basada en la ejecucioacuten de
pruebas de forma repetitiva para la buacutesqueda de errores o problemas que puedan repercutir sobre la calidad del
mismo Pero el testing no solo se basa en la realizacioacuten de pruebas
Se deben identificar otras tareas que estaacuten relacionadas con el testing las cuales se llevan a cabo antes y despueacutes
de la ejecucioacuten de pruebas Estas tareas estaacuten relacionadas principalmente con la planificacioacuten y control del
proceso de pruebas el disentildeo de los diferentes casos de prueba o test cases y la posterior comprobacioacuten de los
resultados obtenidos tras llevar a cabo las pruebas Otras tareas podriacutean ser la propia evaluacioacuten de los diferentes
criterios de finalizacioacuten del proceso de pruebas el anaacutelisis de informes de resultados o la revisioacuten de la
documentacioacuten generada en la fase de pruebas
A continuacioacuten se citan algunas definiciones para explicar el concepto de pruebas de software
ldquoUna prueba es una actividad ejecutada para evaluar la calidad del producto software y mejorarlo mediante
la identificacioacuten de problemas errores o defectos en su funcionamiento [9]rdquo
ldquoLas pruebas de Software consisten en verificaciones dinaacutemicas del comportamiento del software bajo
pruebas mediante un conjunto finito de casos de prueba seleccionadas adecuadamente sobre un dominio
infinito de casos posibles [1]rdquo
Atendiendo a las definiciones presentadas las pruebas de software son dinaacutemicas porque se puede ejecutar el
software bajo pruebas con un conjunto de valores de entrada especiacuteficos para encontrar fallos en su
comportamiento Por otro lado la realizacioacuten de pruebas exhaustivas no es posible para la mayoriacutea de los
productos software reales debido a la gran cantidad de entradas posibles para cada operacioacuten entradas invaacutelidas
o no esperadas y las infinitas secuencias de operaciones posibles
Por estas razones para aplicar un proceso de pruebas de software razonable en cuanto a recursos y tiempo de un
proyecto es necesario seleccionar un conjunto abarcable de pruebas Debido a esto la clave estaacute en el criterio
de seleccioacuten de dichas pruebas Una vez ejecutadas las pruebas seleccionadas se debe decidir si el
comportamiento esperado del sistema falla o no Este es el llamado problema del oraacuteculo el cual es resuelto en
la mayoriacutea de los casos de forma manual mediante la inspeccioacuten de los resultados de la prueba
T
La tecnologiacutea no es nada Lo importante es que tengas feacute
en la gente que sean baacutesicamente buenas e inteligentes
y si les das herramientas haraacuten cosas maravillosas con
ellas
Steve Jobs
47
32 Principios de las Pruebas de Software
Una vez presentada la definicioacuten de pruebas de Software se han obtenido algunos detalles que encajan
perfectamente con una serie de principios que han sido establecidos para el testing de productos software seguacuten
ISTQB (International Software Testing Qualifications Board) [10]
Figura 15 Principios de las Pruebas de Software
1 Las pruebas demuestran la presencia de defectos no su ausencia Las pruebas pueden mostrar que
los defectos estaacuten presentes en el producto pero no pueden probar que no haya defectos Por tanto las
pruebas pueden reducir la probabilidad de existencia de defectos en el software pero incluso si no se
encuentran defectos las pruebas no son una garantiacutea total para afirmar la ausencia de defectos en el
producto final
2 Las pruebas exhaustivas son imposibles Probar todas las posibles combinaciones de entradas y
condiciones previas sobre una aplicacioacuten no es factible excepto en casos muy triviales En lugar de
intentar realizar pruebas exhaustivas se debe usar el anaacutelisis de riesgos las teacutecnicas de prueba y las
prioridades ademaacutes de la automatizacioacuten para enfocar los esfuerzos en la fase de pruebas
3 Las pruebas tempranas ahorran tiempo y dinero Para una deteccioacuten temprana de errores y defectos
las actividades de pruebas deben iniciarse lo antes posible en el ciclo de vida del desarrollo del software
De esta forma se consigue una reduccioacuten de costes ya que cuanto maacutes tarde se detecte un defecto maacutes
costoso y difiacutecil seraacute corregirlo
4 Los defectos se agrupan Generalmente una pequentildea parte del software desarrollado concentra la
mayor complejidad del mismo por lo que la mayoriacutea de los defectos detectados tienen una mayor
probabilidad de encontrarse en esos elementos maacutes complejos Por tanto la realizacioacuten de un buen
anaacutelisis de riesgos permite enfocar el esfuerzo de pruebas en las aacutereas del producto con mayor
probabilidad de presentar defectos
Aplicando el Principio de Pareto al control de calidad [11] el 80 de los errores y defectos estaacute causado
por un 20 del total del producto software desarrollado lo cual podriacutea ser un buen principio sobre el
que basar el anaacutelisis de riesgos
5 Cuidado con la paradoja del pesticida Si las mismas pruebas se repiten una y otra vez con el tiempo
los mismos casos de pruebas ya no encontraraacuten nuevos defectos lo cual no quiere decir que la aplicacioacuten
presente una ausencia completa de los mismos (Las pruebas ya no son eficaces para detectar defectos
al igual que los pesticidas ya no son eficaces para matar insectos despueacutes de un tiempo) Para detectar
nuevos defectos es necesario que las pruebas existentes y los datos de las pruebas deban cambiar
ademaacutes de surgir la necesidad de disentildear nuevas pruebas
48
6 Las pruebas dependen del contexto Cada empresa organizacioacuten o proyecto adaptaraacute el proceso de
pruebas a sus necesidades recursos disponibles o aacutereas de riesgo existentes
7 La ausencia de errores es una falacia Un producto software puede tener un 100 de casos de eacutexito
en su fase de pruebas pero esto solo indica que hay defectos que auacuten no han sido localizados e
identificados
33 Proceso de Pruebas de Software Anaacutelisis disentildeo e implementacioacuten
Partiendo de los principios detallados en la seccioacuten anterior se presentan las diferentes etapas del proceso de
pruebas de software asiacute como la documentacioacuten generada en cada etapa
331 Terminologiacutea
Previamente se presentaraacuten algunos teacuterminos y definiciones que convienen describir para una mejor
comprensioacuten de todo el proceso de pruebas [3]
Figura 16 Terminologiacutea para el proceso de pruebas
1 Condicioacuten de prueba Elemento o evento de un componente o sistema que puede ser verificado por
uno o maacutes casos de prueba Los diferentes requisitos que definen la funcionalidad de un sistema pueden
ser descompuestos en diferentes condiciones de prueba
2 Caso de prueba conjunto de valores de entrada precondiciones de ejecucioacuten y valores esperados
Estos son desarrollados para perseguir un objetivo particular por ejemplo una condicioacuten de prueba
3 Precondicioacuten Condiciones de entorno y estado que deben ser satisfechas antes de que un componente
o sistema pueda ser sometido a un caso de prueba o conjunto de estos
4 Abstraccioacuten de casos de prueba Consiste en la generalizacioacuten de los casos de prueba especiacuteficos sin
valores concretos para sus entradas condiciones de prueba o valores esperados En resumen no es maacutes
que llevar las condiciones de prueba a un caso general para cualquier valor de entrada
5 Script de pruebas Una vez disentildeados los casos de prueba estos pueden ser implementados y
ejecutados por una herramienta de automatizacioacuten Un script de pruebas puede contener varios casos
de prueba
6 Paquete de pruebas Consiste en la agrupacioacuten de casos de prueba relacionados en cuanto a la
funcionalidad que automatizan sobre el sistema
7 Programacioacuten de la ejecucioacuten de pruebas Describen el flujo de ejecucioacuten de los diferentes paquetes
de pruebas
49
332 Proceso de Pruebas de Software
No existe un proceso de pruebas universal pero existen conjuntos comunes de actividades de prueba sin las
cuales las pruebas disentildeadas e implementadas tendriacutean menos probabilidad de alcanzar sus objetivos
establecidos Estos conjuntos de actividades de prueba constituyen un proceso de pruebas
Como se ha mencionado en secciones anteriores el proceso de pruebas se debe iniciar en las fases maacutes iniciales
del ciclo de vida de un proyecto Por tanto las actividades del proceso de pruebas la manera en que se
implementan dichas actividades y cuaacutendo ocurren pueden ser discutidas en la estrategia de pruebas de una
organizacioacuten
A continuacioacuten se exponen las etapas fundamentales del proceso de pruebas detallando en cada una de ellas la
documentacioacuten generada y coacutemo contribuyen a la mejora de la calidad del producto con su aplicacioacuten en el ciclo
de vida de un proyecto [13]
Figura 17 Proceso de Pruebas de Software
3321 Planificacioacuten y Control de Pruebas
La planificacioacuten consiste en determinar los diferentes objetivos de las pruebas realizadas sobre el Sistema bajo
test las especificaciones y los recursos que se necesitaraacuten para llevar a cabo la fase de pruebas y cumplir con los
objetivos planteados
Es en este punto donde se define el alcance de las pruebas a realizar de forma que se selecciona lo que seraacute y
no seraacute testeado ademaacutes de indicar quieacuten haraacute cada prueba y como la llevaraacute a cabo Mediante los objetivos de
las pruebas se puede establecer un punto de finalizacioacuten del proceso
Como salida de la actividad de planificacioacuten se obtendriacutea el ldquoPlan de Pruebasrdquo el cual documenta la estrategia
y el alcance de las pruebas la prioridad en cuanto a su realizacioacuten y las estimaciones temporales para su
evaluacioacuten ademaacutes de los recursos materiales y humanos para llevarlas a cabo
Es crucial que dicho documento sea validado por el personal correspondiente del proyecto antes de continuar
con las siguientes etapas del proceso de pruebas
Por otro lado el control de pruebas es una actividad desarrollada durante todo el ciclo de vida del proceso de
pruebas el cual permite contrastar el progreso actual con el plan original trazado para la aplicacioacuten de dicho
proceso incluyendo informes y desviaciones
Cuando se produce una desviacioacuten del plan original que introduce cierto riesgo adicional puede hacerse
necesario modificar los objetivos fijados para asegurar la calidad del producto De ahiacute que sea sumamente
importante tener en consideracioacuten la documentacioacuten generada en antiguos proyectos
50
3322 Anaacutelisis y Disentildeo de Pruebas
Una vez planificado el alcance y objetivos de las pruebas se realiza una actividad de anaacutelisis donde se traducen
a condiciones de prueba y posteriormente se disentildean los casos de prueba de alto nivel a partir de la abstraccioacuten
de los casos de prueba
Por otro lado cabe destacar la necesidad de un mecanismo que garantice la trazabilidad con la finalidad de
mantener alineados en todo momento los casos de prueba con los objetivos de la misma incluso contemplando
la posibilidad de que los objetivos puedan cambiar en alguacuten momento del proceso de pruebas
El documento generado en esta actividad es conocido como ldquoespecificaciones de disentildeo de pruebasrdquo
3323 Implementacioacuten y Ejecucioacuten de Pruebas
Dicha etapa consiste en la implementacioacuten de los casos de prueba de alto nivel que cumplen con las
especificaciones de disentildeo de la etapa anterior Es en esta fase donde se haraacute uso de herramientas para la
implementacioacuten y ejecucioacuten de las pruebas
Cabe destacar que para llevar a cabo dicha etapa en cuanto a la verificacioacuten y validacioacuten funcional de un
proyecto es necesario que durante la etapa de desarrollo se haya creado un producto funcional sobre el cual
puedan ejecutarse las pruebas
Durante la ejecucioacuten de las pruebas los resultados obtenidos quedaraacuten documentados en un documento
denominado ldquoRegistro de Pruebasrdquo el cual contiene todas las pruebas realizadas y un ldquoReporte de Incidenterdquo
por cada resultado no esperado que se haya detectado
Una vez sean corregidos los incidentes se debe volver a ejecutar las pruebas con la finalidad de asegurar que
dicho incidente haya sido corregido ademaacutes de asegurar que la correccioacuten realizada no haya introducido otros
defectos o errores Esto es lo que se denomina ldquoPruebas de Regresioacutenrdquo
3324 Evaluacioacuten de los criterios de eacutexito y Elaboracioacuten de reportes e informes
Tras la ejecucioacuten de las pruebas se deben evaluar los criterios de eacutexito los cuales han sido definidos en la etapa
de planificacioacuten
El personal responsable e involucrado en el proyecto se reuniraacute y revisaraacute el cumplimiento de dichos criterios
el registro de pruebas obtenido y los reportes de incidentes que hayan podido ser abiertos en la etapa anterior
Finalmente como resultado de dicha actividad se elabora un ldquoSumario final de Pruebasrdquo
3325 Cierre de la fase de pruebas
Las actividades de cierre de la fase de pruebas se centran mayormente en asegurar que todo el ciclo de vida del
proceso de pruebas se ha cumplido ademaacutes de analizar las posibles mejoras y defectos en las fases llevadas a
cabo
Ademaacutes se lleva a cabo el cierre de los incidentes corregidos y la liberacioacuten de los entornos y recursos asignados
a la fase de pruebas
51
34 Clasificacioacuten de Pruebas de Software
Existen diversos tipos de pruebas las cuales pueden ser clasificadas en funcioacuten del objetivo de prueba para lo
cual hayan sido establecidos Cada tipo de prueba persigue unos objetivos especiacuteficos sobre el producto pero
todas ellas persiguen como objetivo comuacuten ofrecer un producto con garantiacutea de calidad al cliente o usuario final
Dichas pruebas pueden ser clasificadas en cuatro tipos
Figura 18 Clasificacioacuten de Pruebas de Software
341 Pruebas Funcionales
Tambieacuten conocidas como ldquoPruebas de caja Negrardquo En [14] la IEEE define este tipo de pruebas como
ldquoPruebas que ignoran los mecanismos internos de un sistema o componente y se enfocan
solamente en las salidas generadas como respuesta a las entradas seleccionadas y a las
condiciones de ejecucioacutenrdquo
Figura 19 Pruebas de Caja Negra
Atendiendo a la definicioacuten anterior el sistema o componente sujeto a pruebas debe realizar una funcioacuten
determinada Estaraacute descrita en las especificaciones funcionales y se pueden llevar a cabo a cualquier nivel
Dichas especificaciones funcionales describen el comportamiento del sistema sin revelar informacioacuten acerca de
su implementacioacuten interna
Un tipo especial de prueba funcional son las ldquoPruebas de Humordquo o ldquoSmoke Testsrdquo Este tipo de pruebas suele
realizarse en fases tardiacuteas del desarrollo y permiten asegurar que las funcionalidades baacutesicas del software
responden adecuadamente
Por tanto dichas pruebas pueden quedar lejos de ser pruebas exhaustivas aunque siacute permiten asegurar que el
producto entregado al cliente cumple con los requisitos de funcionamiento establecidos Este tipo de pruebas
son las que se han implementado y automatizado en el proyecto presente lo cual se detallaraacute en capiacutetulos
posteriores
52
342 Pruebas No Funcionales
Este tipo de pruebas estaacuten orientadas a verificar coacutemo de bien funciona el sistema bajo pruebas en lugar de la
funcionalidad que ofrece Por ello pueden ser agrupadas tambieacuten dentro de la categoriacutea de pruebas de caja negra
Atendiendo al estaacutendar de evaluacioacuten del producto software ldquoISO 25000rdquo todas las caracteriacutesticas excepto la de
funcionalidad definen caracteriacutesticas de calidad no funcionales de un producto software Estas caracteriacutesticas de
calidad tienen su correspondiente tipo de prueba
3421 Pruebas de Rendimiento
Las pruebas de rendimiento son usadas para determinar la rapidez con la que se realiza una tarea en el sistema
bajo unas condiciones particulares de trabajo Estas pruebas tambieacuten pueden ser usadas para validar y verificar
otros atributos de calidad del sistema tales como la escalabilidad fiabilidad y uso de recursos
Figura 20 Pruebas de Rendimiento
3422 Pruebas de Carga
Este tipo de pruebas miden el rendimiento del sistema con una carga de trabajo manejable y conocida Se trata
de someter al sistema a cargas de trabajo controladas por el ingeniero de pruebas para validar prestaciones de
rendimiento sobre el sistema
Figura 21 Pruebas de Carga
3423 Pruebas de Estreacutes
Las pruebas de estreacutes ponen a prueba la robustez y confiabilidad del sistema sometieacutendolo a condiciones de uso
extremas Entre estas condiciones se incluyen el enviacuteo masivo de peticiones y la ejecucioacuten en condiciones de
hardware limitadas Dichas condiciones van maacutes allaacute de los liacutemites de operacioacuten considerados en el disentildeo
Figura 22 Pruebas de Estreacutes
53
3424 Pruebas de Usabilidad
Estas pruebas se centran en encontrar problemas de la interfaz de usuario que podriacutean hacer que el software sea
difiacutecil de utilizar o podriacutean causar que los usuarios mal interpreten las salidas Por tanto permiten medir coacutemo
de atractivo resulta un producto software basaacutendose en la facilidad de adaptacioacuten y uso por parte de los clientes
Figura 23 Pruebas de Usabilidad
3425 Pruebas de Fiabilidad
Prueban el rendimiento del sistema ante un determinado nuacutemero de operaciones o tras cierto periodo de
tiempo
3426 Pruebas de Instalacioacuten
Las pruebas de instalacioacuten tienen dos propoacutesitos El primero es asegurar que el sistema puede ser instalado
en todas las configuraciones posibles tales como nuevas instalaciones actualizaciones instalaciones
completas o personalizadas y bajo condiciones normales o anormales estas uacuteltimas incluyen insuficiente
espacio en disco falta de privilegios para algunas tareas etc
El segundo propoacutesito es verificar que una vez instalado el sistema opera correctamente Esto usualmente
implica ejecutar un nuacutemero significativo de pruebas de Funcionalidad
Por tanto miden coacutemo de sencillo resulta instalar la aplicacioacuten en distintas plataformas o entornos
3427 Pruebas de Portabilidad
Miden coacutemo de sencillo resulta migrar una aplicacioacuten de una plataforma a otra
Figura 24 Pruebas de Portabilidad
54
343 Pruebas Estructurales
Este tipo de pruebas son tambieacuten conocidas como ldquoPruebas de Caja Blancardquo En [14] la IEEE define este tipo
de pruebas como
ldquoPruebas que tienen en cuenta los mecanismos internos de un sistema o componenterdquo
Figura 25 Pruebas de Caja Blanca
Atendiendo a dicha definicioacuten estas pruebas tienen en cuenta la estructura del coacutedigo fuente del software a partir
del cual se seleccionan los diferentes casos de prueba guiaacutendose por la existencia de sentencias condicionales
bucles etc
Por tanto los casos de prueba son desarrollados usando criterios de cobertura para el coacutedigo del programa De
esta forma el sistema bajo pruebas se trata como una caja de cristal que permite ver su estructura
El criterio de cobertura hace referencia a cada miacutenima unidad de coacutedigo que puede ser probada de forma
independiente Es frecuente usar este tipo de pruebas en los niveles de prueba maacutes bajos como por ejemplo en
las ldquoPruebas Unitariasrdquo o las ldquoPruebas de Componenterdquo
344 Pruebas debidas a Cambios
Finalmente en el proceso de pruebas tras ejecutar las pruebas y encontrar un defecto o error en el sistema bajo
pruebas este se corrige pero es necesario validar la correccioacuten realizada para confirmar que el fallo no se
reproduce A este proceso se le denomina ldquoPrueba de confirmacioacuten o re-testingrdquo
Ademaacutes las correcciones pueden ser validadas pero tambieacuten es necesario asegurar que los cambios introducidos
para corregir dicho fallo no han provocado maacutes defectos Por tanto puede concluirse que es necesario volver a
realizar pruebas sobre el resto del sistema Estas son las ldquoPruebas de Regresioacutenrdquo
35 Niveles de Prueba
El proceso de pruebas es una etapa del ciclo de vida de un proyecto cuyas actividades estaacuten completamente
relacionadas con las actividades del proceso de desarrollo Existen diversos modelos que describen las fases y
actividades del proceso de desarrollo de software En esta seccioacuten se detallaraacute el uso del ldquoModelo de desarrollo
en Vrdquo
Este modelo describe las diferentes fases del proceso de desarrollo y sugiere la realizacioacuten de pruebas en cada
una de ellas Estas pruebas seraacuten ejecutadas posteriormente en orden ascendente Por tanto para cada fase existen
unos objetivos a cumplir los cuales deben ser probados para medir la integridad del trabajo realizado
55
A continuacioacuten se detallaraacuten los diferentes niveles de prueba para cada etapa del desarrollo software atendiendo
al modelo de desarrollo en V
Figura 26 Modelo de desarrollo en V
351 Pruebas a Nivel de Componente
Tambieacuten llamadas ldquoPruebas Unitariasrdquo El objetivo de estas pruebas es el de cubrir la unidad miacutenima funcional
que compone el software Estos componentes suelen tener una uacutenica funcioacuten especiacutefica la cual seraacute usada por
el resto del Sistema A menudo son realizadas por los propios desarrolladores haciendo uso de la metodologiacutea
de desarrollo guiado por prueba o Test-Driven-Development (TDD)
352 Pruebas a Nivel de Integracioacuten
Son aquellas pruebas realizadas en el aacutembito del desarrollo software una vez validadas las pruebas unitarias
Estas pruebas verifican que todos los elementos unitarios que componen el software funcionan en conjunto de
forma correcta Se centran principalmente en probar la comunicacioacuten entre los diferentes componentes del
sistema
353 Pruebas a Nivel de Aceptacioacuten
Este uacuteltimo nivel se centra en las necesidades del usuario requisitos y procesos de negocio con el fin de
determinar si el sistema satisface los criterios de aceptacioacuten acordados con el cliente en un contrato o acuerdo
de nivel de servicio en caso de ser un software de uso interno dentro de una compantildeiacutea
Ejemplos de este tipo de pruebas pueden ser las ldquoPruebas Alfa y Betardquo
Como se ha detallado anteriormente las pruebas desarrolladas y automatizadas en este Proyecto son ldquoPruebas
de humordquo o Smoke Tests Estas pruebas se centran en la verificacioacuten y validacioacuten de las especificaciones de uso
de un Sistema en este caso de la plataforma Web de gestioacuten Galgus CHT Manager
56
36 Dificultades de pruebas en aplicaciones Web e impacto
La complejidad antildeadida de las aplicaciones y servicios Web frente a otros tipos de aplicaciones recae sobre el
uso de muacuteltiples tecnologiacuteas de vanguardia que permiten la construccioacuten de sistemas distribuidos con un amplio
grado de escalabilidad accesibilidad disponibilidad interoperabilidad e independencia del hardware
Como consecuencia del incremento de la complejidad de las aplicaciones surgen nuevos paradigmas como la
Arquitectura Orientada a Servicios (SOA) la cual permite interoperabilidad y flexibilidad de las aplicaciones
distribuidas
Todo ello conlleva a plantearse queacute se deberiacutea hacer para garantizar que una aplicacioacuten Web puesta en marcha
funciona de acuerdo a los requisitos definidos y acordados con el cliente Podriacutean optimizarse y mejorarse los
diferentes procesos dentro del ciclo de vida de un proyecto pero siempre la fase de pruebas termina siendo la
fase previa a la puesta en marcha de la aplicacioacuten con lo que resulta siendo la uacuteltima oportunidad para detectar
posibles fallos que puedan terminar en ocasiones en peacuterdidas econoacutemicas de prestigio de fiabilidad y de
credibilidad por parte de los clientes
Realizar pruebas en una aplicacioacuten Web no es tarea faacutecil ya que son muchos los factores que influyen en el
testeo del sistema para abarcar y contemplar el maacuteximo de flujos posibles que se pueden llevar a cabo durante
el uso de la aplicacioacuten
Hoy en diacutea las aplicaciones Web pueden ser construidas con componentes implementados en diferentes
lenguajes y arquitecturas basaacutendose en diferentes modelos de programacioacuten y pudiendo ejecutarse en diferentes
plataformas de hardware y software
Esto incrementa la complejidad de las pruebas a realizar sobre un sistema de este tipo por lo que seriacutea interesante
plantearse la posibilidad de usar herramientas que permitan una abstraccioacuten de dicha complejidad ademaacutes de la
automatizacioacuten de la fase de pruebas En el caso de las pruebas a nivel de aceptacioacuten en este proyecto se
propondraacute el uso de herramientas que persiguen dichos fines
Figura 27 Dificultades de pruebas en aplicaciones Web e impacto
57
58
4 SISTEMA GALGUS CHT CLOUD MANAGER
ras realizar un estudio del arte sobre una teacutecnica que puede ser de gran utilidad para optimizar y
perfeccionar las teacutecnicas de automatizacioacuten para el proceso de pruebas sobre un sistema se han puesto
en contexto los diferentes tipos de pruebas que pueden realizarse sobre un sistema ademaacutes de definir
el proceso de pruebas Una vez llegados a este punto en primer lugar se realizaraacute una descripcioacuten del sistema
bajo pruebas sobre el cual se plantearaacute una solucioacuten para la fase de pruebas y su automatizacioacuten Maacutes
concretamente para la realizacioacuten de las pruebas a nivel de aceptacioacuten
41 Arquitectura y Descripcioacuten del Sistema
CHT Cloud Manager es un proyecto de la empresa Galgus el cual ofrece una plataforma Web de gestioacuten
configuracioacuten y monitorizacioacuten de redes WiFi Maacutes concretamente dicha plataforma permite gestionar un
conjunto de puntos de acceso desplegados con un conjunto de algoritmos definidos por software los cuales
permiten la optimizacioacuten de los recursos de red inalaacutembricos ofreciendo mayores prestaciones y una mayor
calidad de servicio al usuario Ademaacutes dicho software embebido ofrece otros servicios al cliente como la
localizacioacuten de estaciones dentro de la zona de alcance de la red WiFi o la deteccioacuten de intrusos y ataques de
suplantacioacuten de identidad
A este conjunto de algoritmos se le conoce bajo el nombre Cognitive Hostpot Technology (CHT) Este software
implementado en lenguaje C y preparado para sistemas embebidos como los puntos de acceso presenta una
estructura modular donde cada moacutedulo se encarga de una tarea determinada o de ejecutar un algoritmo
determinado
Figura 28 Logo de Galgus
Para permitir la comunicacioacuten con la plataforma Web CHT implementa un moacutedulo denominado MGR el cual
permite la conexioacuten con un broacuteker de eventos o intermediario para permitir el enviacuteo y la recepcioacuten de eventos
desde dicha plataforma
T
La simplicidad llevada al extremo se convierte en
elegancia
Jon Franklin
59
En la siguiente figura se muestra la arquitectura orientada a servicios para CHT Cloud Manager
Figura 29 Arquitectura de CHT Cloud Manager
Puede observarse que dicha plataforma estaacute formada por diferentes microservicios desplegados en la nube Cada
uno de ellos realiza una serie de tareas bien definidas e interactuacutean entre ellos enviando y recibiendo mensajes
haciendo uso de diferentes protocolos y modelos de comunicacioacuten
De esta forma se consigue mantener actualizado el estado de la informacioacuten de los diferentes elementos en
tiempo real sobre los diferentes eventos que puedan ocurrir en el sistema Dichos eventos proceden en su gran
mayoriacutea del conjunto de puntos de acceso que conforma una red de Galgus la cual pretende ser gestionada desde
la plataforma en cuestioacuten
A continuacioacuten se detallaraacuten los diferentes microservicios que conforman dicha plataforma ademaacutes de describir
a los puntos de acceso con la tecnologiacutea CHT como elementos a gestionar desde dicha plataforma
60
411 Puntos de Acceso (OpenWRT + CHT)
4111 OpenWRT
Los puntos de acceso WiFi de Galgus son sistemas embebidos de diferentes modelos en funcioacuten de las
especificaciones hardware que ofrezcan (nuacutemero de streams espaciales nuacutemero de antenas de exterior de
interior etc)
Todos ellos tienen en comuacuten el uso de OpenWRT como sistema operativo Este se trata de un sistema operativo
open source basado en Linux y usado para sistemas de red embebidos Todos los componentes de dicho sistema
han sido optimizados para dispositivos con limitaciones de hardware y este permite configurarlos mediante
interfaz de liacutenea de comandos o mediante una interfaz Web (LuCI) [15]
Partiendo de dicho sistema operativo Galgus desarrolla CHT como producto software que dota a los puntos de
acceso de una serie de prestaciones en una serie de moacutedulos Dicho producto es ofrecido al cliente mediante
licencias las cuales son gestionadas desde un servidor de licencias y obtenidas por los puntos de acceso de
forma automaacutetica Todo ello se detallaraacute maacutes adelante
4112 CHT
CHT tambieacuten ofrece su propia interfaz de liacutenea de comandos denominada CHT_CLI Esta herramienta permite
configurar los distintos moacutedulos de los que se compone CHT y obtener informacioacuten tanto de la configuracioacuten
como del funcionamiento de los algoritmos CHT
A continuacioacuten se presenta la interfaz y algunos de los comandos que se pueden utilizar
Figura 30 CHT_CLI
CHT_CLI es fundamental tanto en el desarrollo como en el testeo de CHT y CHT Cloud Manager ya que nos
permite acceder a paraacutemetros de configuracioacuten que no estaacuten accesibles desde la interfaz graacutefica LuCI Desde
CHT_CLI se controlan todos los moacutedulos de CHT entre los que se pueden destacar los siguientes Load Balance
(LB) Smart Roaming (SR) Power Control (POWER) Localization (LOC) Traffic Congestion Management
(TCM) Smart Band Steering (SB) y el moacutedulo Manager (MGR)
En este caso es de intereacutes resaltar el moacutedulo que permite la comunicacioacuten con la plataforma de gestioacuten CHT
Cloud Manager Dicho moacutedulo conocido bajo el nombre de MGR implementa un cliente AMQP para
establecer la comunicacioacuten con el broacuteker de eventos usado como intermediario para permitir la comunicacioacuten
entre los puntos de acceso y la plataforma de gestioacuten CHT Cloud Manager
Ademaacutes implementa una serie de estructuras de datos que son enviados a traveacutes de dicho intermediario basadas
en FlatBuffers como plataforma eficiente de serializacioacuten cruzada de datos ofrecida por Google Esta
herramienta permite crear un modelo de datos bajo la sintaxis ofrecida por FlatBuffers para posteriormente
generar dichas estructuras de datos en diferentes lenguajes de programacioacuten como por ejemplo C++ C C
Go Java JavaScript etc
Con esto se consigue generar estructuras de datos con una compatibilidad absoluta que se intercambiaraacuten entre
la plataforma de gestioacuten en lenguaje Java y los puntos de acceso en lenguaje C
61
412 Broacuteker de Eventos AMQP (RabbitMQ)
Este microservicio implementa un broacuteker de eventos que actuacutea como intermediario entre los puntos de acceso
WiFi y algunos microservicios que componen la plataforma Web de gestioacuten Se basa en el protocolo AMQP el
cual sigue el patroacuten publicadorsuscriptor como paradigma de comunicacioacuten indirecta
Estaacute involucrado en la entrega de mensajes entre los diferentes dispositivos embebidos con CHT y sus
respectivos servicios de gestioacuten en la plataforma Web de forma que los agentes que publican y consumen
eventos en el broacuteker no necesitan conocer al destinatario si no que el broacuteker es el que se encarga de publicar los
eventos para los destinatarios suscritos a eacutel En la siguiente figura se muestra la interfaz graacutefica de gestioacuten de
RabbitMQ [16]
Figura 31 Plataforma de Gestioacuten de RabbitMQ
Un broacuteker de eventos es un elemento del patroacuten PublicadorSuscriptor que recibe y mensajes de un conjunto de
elementos de red que quieren comunicarse ejecutan mecanismos de filtrado y permite la entrega correcta de los
diferentes mensajes a los consumidores correspondientes Por tanto el broacuteker de eventos permite ofrecer un
desacoplamiento entre emisores y receptores de la informacioacuten siendo este responsable de las tareas de
encaminamiento y reenvioacute de mensajes En conclusioacuten es responsable de coordinar la comunicacioacuten
proporcionando transparencia de acceso y localizacioacuten permitiendo la localizacioacuten de emisores y receptores
mediante un sistema de identificadores uacutenicos
Figura 32 Patroacuten PublicadorSuscriptor
62
413 Frontend
El Frontend de la plataforma Web estaacute implementado con Angular 6 HTML5 y CSS3 Su finalidad es ofrecer
una interfaz graacutefica al usuario final la cual permite mostrar el estado de los diferentes Zone Managers ademaacutes
de permitir el acceso a estos y gestionar el conjunto de puntos de acceso registrados en ellos de forma raacutepida e
intuitiva
Este microservicio recibe informacioacuten proporcionada por MoMap y los diferentes Zone Managers La
aplicacioacuten se sirve mediante un servidor Apache el cual proporciona una comunicacioacuten fiable con HTTPS
implementando una capa de transporte segura mediante el protocolo TLS
414 Zone Manager
Microservicio responsable de gestionar un conjunto de puntos de acceso CHT los cuales forman un despliegue
de red WiFi de Galgus para un cliente determinado Este microservicio estaacute formado por un servicio Web REST
implementado con Java Spring Framework desplegado en un servidor Jetty embebido y cuya persistencia se ha
implementado a traveacutes de Hybernate con el uso de Postgress SQL como gestor de bases de datos relacional
Un Zone Manager ofrece todas las tareas y acciones necesarias para configurar un conjunto de puntos de acceso
y consultar datos estadiacutesticos de usuarios conectados a dichos puntos de acceso entre otras Cabe destacar en
este punto la importancia que tiene el uso de FlatBuffers para garantizar la compatibilidad de datos enviados y
recibidos entre los puntos de acceso y el Zone Manager ambos implementados en tecnologiacuteas totalmente
diferentes
Figura 33 Ejemplo de Interfaz Graacutefica de un Zone Manager
63
415 MoMap
Dicho microservicio implementado en NodeJS gestiona y administra toda la infraestructura que conforma la
plataforma Web Establece y mantiene todas las conexiones y relaciones entre los diferentes puntos de acceso
con CHT y los Zone Managers (ZMB) que los gestiona
Ademaacutes este microservicio implementa una serie de maacutequinas de estado que permiten controlar el estado de
todos los Zone Managers y puntos de acceso CHT alertando sobre los eventos de error conexioacuten o desconexioacuten
en tiempo real a los usuarios finales a traveacutes del Frontend El soporte a la persistencia para dicho microservicio
se proporciona mediante MongoDB
Por tanto el microservicio MoMap actuacutea como proxy inverso HTTP2 Cuando un usuario intenta acceder a
traveacutes del Frontend de la plataforma Web puede gestionar y administrar un conjunto de Zone Managers o
administrar usuarios y asignar roles y permisos Tambieacuten se permite la creacioacuten eliminacioacuten y conexioacuten con un
Zone Manager redirigiendo las peticiones hacia el mismo
Cuando ocurre un evento de conexioacuten con un Zone Manager desde el microservicio MoMap se recupera y
enviacutea la informacioacuten necesaria para mostrar toda la informacioacuten correspondiente a ese Zone Manager en el
Frontend para el usuario final En la siguiente figura se muestra la interfaz graacutefica ofrecida por el servicio
MoMap a traveacutes del Frontend
Figura 34 Ejemplo de Interfaz Graacutefica de MoMap
64
416 Servidor de Licencias
El objetivo principal de este servicio es proporcionar una aplicacioacuten con una gestioacuten y control centralizado de
las licencias de todos los Puntos de Acceso desplegados con CHT Este servidor desplegado con Jetty de forma
embebida almacena el registro de un conjunto de Puntos de Acceso CHT para un conjunto de Clientes y
proyectos determinados Proporciona una API REST implementada con Java Spring Framework que permite
el registro de dichos dispositivos y la asignacioacuten de licencias CHT para habilitar los diferentes moacutedulos de dicha
aplicacioacuten embebida sobre los Puntos de Acceso Ademaacutes proporciona una interfaz Web de usuario
implementada con Angular 6 HTML5 y CSS3
En la siguiente figura se muestra un ejemplo de dicha interfaz graacutefica
Figura 35 Interfaz Graacutefica del Servidor de Licencias
4161 Zero-Touch Provisioning (ZTP)
En el contexto de la automatizacioacuten de redes WiFi el aprovisionamiento sin contacto es una caracteriacutestica
que permite que los puntos de acceso de una red se configuren automaacuteticamente evitando la intervencioacuten
humana para su configuracioacuten La configuracioacuten manual de dispositivos y conmutadores es costosa y
requiere lo que a menudo puede ser una gran cantidad de tiempo y esfuerzo dependiendo del tamantildeo de la
red [17]
Con el uso de sistemas automaacuteticos de aprovisionamiento y configuracioacuten se consigue reducir la carga de
trabajo y el esfuerzo que normalmente se requiere cuando se instalan y configuran nuevos dispositivos
Figura 36 Zero-Touch Provisioning (ZTP)
65
Haciendo uso de esta caracteriacutestica Galgus implementa en su infraestructura orientada a microservicios
un acceso directo de los Puntos de Acceso al servidor para que soliciten su licencia de CHT
automaacuteticamente de forma que cuando el usuario final vaya a instalar un Punto de Acceso CHT dicho
dispositivo obtendraacute su licencia de forma segura a traveacutes de la API REST del servidor de licencias siempre
y cuando esteacute registrado en el mismo y disponga de licencia sin necesidad de que el usuario intervenga en
dicho proceso
La comunicacioacuten entre los puntos de acceso y el resto de la infraestructura se realiza a traveacutes de un broacuteker
de eventos AMQP con su implementacioacuten en RabbitMQ Debido a esto cuando se crea y asigna licencia
a un dispositivo en el servidor de licencias dicho servidor crea un usuario en RabbitMQ de forma que el
punto de acceso en el momento que obtiene su licencia intentaraacute establecer conexioacuten con el broacuteker para
permitir el intercambio de eventos con los microservicios que lo gestionaraacuten mediante la plataforma CHT
Cloud Manager
Una vez el punto de acceso establece conexioacuten con el broacuteker de eventos este podraacute ser descubierto por el
Zone Manager que lo gestionaraacute El microservicio MoMap se encarga de establecer el descubrimiento de
los puntos de acceso comprobando si el punto de acceso estaacute registrado en el servidor de licencias con
licencia asignada y verificando que el punto de acceso estaacute operativo con conexioacuten a internet
42 Alcance y Objetivos de las pruebas sobre el sistema planteado
Una vez presentada y descrita toda la arquitectura de la plataforma Web ofrecida por Galgus se procederaacute a
detallar los principales objetivos del proceso de pruebas que se pretenderaacute conseguir sobre dicha aplicacioacuten Para
ello inicialmente se presentaraacute en queacute punto se encontraba el proceso de pruebas inicialmente
En este proyecto se ha centrado la atencioacuten en el conjunto de pruebas funcionales realizadas a la aplicacioacuten maacutes
concretamente las pruebas a nivel de aceptacioacuten
Dentro de las pruebas a nivel de aceptacioacuten los ingenieros de prueba hasta ahora habiacutean disentildeado un plan de
pruebas de aceptacioacuten o tests End-to-End los cuales se ejecutaban verificaban y validaban manualmente por
los ingenieros de QA Dicho plan de pruebas estaacute formado por una bateriacutea de casos de prueba a realizar sobre
las diferentes funcionalidades del sistema A continuacioacuten se muestra un fragmento de dicho plan de pruebas
Figura 37 Test Plan de CHT Cloud Manager
Como puede observarse en la figura anterior dicho plan de pruebas contiene un conjunto de casos de prueba
cada uno de ellos con un identificador uacutenico una descripcioacuten algunas especificaciones o detalles necesarios un
indicador de eacutexito o fallo y finalmente la descripcioacuten de los resultados obtenidos
Ademaacutes en dicho test plan se incluye una cabecera y una leyenda para clasificar los distintos resultados
obtenidos en la ejecucioacuten de las pruebas registrar algunos datos de relevancia y tener archivado dicho plan de
pruebas con las versiones de los diferentes microservicios que componen la plataforma Web
66
Figura 38 Leyenda del Test Plan
Figura 39 Control de Versiones del Test Plan
Una vez presentado el estado actual del proceso de pruebas a nivel de aceptacioacuten el nuevo equipo encargado de
evaluar la calidad de la plataforma Web planteoacute la oportunidad de automatizar dicho plan de pruebas Por tanto
el principal objetivo de este proyecto ha sido el de automatizar las actividades de ejecucioacuten y generacioacuten de
reportes de las pruebas de aceptacioacuten automatizadas sobre la aplicacioacuten
Sin embargo las actividades de planificacioacuten disentildeo e implementacioacuten de los diferentes casos de prueba se
realizaraacuten de forma manual haciendo uso de un conjunto de tecnologiacuteas que se usaraacuten para desarrollar la
automatizacioacuten de dichas pruebas Dichas tecnologiacuteas principalmente son Robot Framework Selenium y
Python las cuales se detallaraacuten maacutes adelante
En este punto es donde podriacutea entrar en juego la aplicacioacuten de Model-Based-Testing (MBT) detallado en la
seccioacuten 2 de este proyecto como teacutecnica que permite la abstraccioacuten de la actividad de implementacioacuten del plan
de pruebas mejorando el proceso de pruebas e independizando este de las actividades de desarrollo
En este proyecto queda fuera del alcance la aplicacioacuten de dicha teacutecnica debido a la necesidad de disponer de un
disentildeo completo y detallado de la plataforma Web para permitir la generacioacuten de los casos de prueba abstractos
y su posterior generacioacuten automaacutetica de los casos de prueba ejecutables Es de intereacutes destacar que a lo largo
del desarrollo del proyecto han ido surgiendo otros objetivos de intereacutes para mejorar el proceso de pruebas los
cuales permiten agilizar dicho proceso y ampliar su alcance
Entre estos objetivos se encuentran la generacioacuten automaacutetica de documentacioacuten del plan de pruebas la
implementacioacuten de un entorno de UAT (User Acceptance Testing) con Docker la integracioacuten de las pruebas a
nivel de aceptacioacuten en el proceso de integracioacuten continua del proyecto o la creacioacuten de un Docker que permita
ejecutar todo el plan de pruebas Todos estos objetivos se iraacuten detallando maacutes adelante
67
43 Arquitectura de la Solucioacuten Entorno de UAT para el proceso de pruebas (User Acceptance Test)
Hasta ahora dentro del proceso de desarrollo de la plataforma Web existiacutean las siguientes fases etapas o
entornos Desarrollo Preproduccioacuten y Produccioacuten
Bajo este contexto las actividades del proceso de pruebas eran realizadas sobre la fase de Preproduccioacuten Esto
provocaba una dependencia directa del cierre de la mayoriacutea de actividades de desarrollo para el despliegue en la
fase de Preproduccioacuten Como consecuencia la fase de pruebas a nivel de aceptacioacuten se podriacutea ver perjudicada
por esta metodologiacutea provocando en muchas ocasiones el retraso en el feedback necesario por los ingenieros de
desarrollo de los reportes e informes generados al ejecutar las pruebas de aceptacioacuten Para mejorar este proceso
se ha disentildeado un nuevo entorno de UAT en el proceso de desarrollo que permita disminuir la dependencia del
proceso de pruebas y desarrollo La inclusioacuten de este nuevo entorno ha sido posible gracias a la mejora del
proceso de integracioacuten continuacutea implementado en el desarrollo de la plataforma
Dentro de este proceso de integracioacuten continua se realiza la generacioacuten automaacutetica de los Docker que contienen
los diferentes microservicios de la plataforma Web en cualquier etapa del proceso de desarrollo Ademaacutes dentro
del proceso de integracioacuten continua se ha automatizado por parte de los ingenieros de desarrollo la ejecucioacuten
de pruebas unitarias y de integracioacuten que garantizan una miacutenima garantiacutea de estabilidad funcional de la
plataforma necesaria para el proceso de pruebas Partiendo de este punto el equipo de calidad ha disentildeado un
entorno de UAT con Docker el cual se muestra de forma graacutefica en la siguiente figura
Figura 40 Entorno de UAT con Docker (Anexo B)
68
69
5 TECNOLOGIacuteAS Y HERRAMIENTAS USADAS
na vez descrito el sistema bajo pruebas y presentada la arquitectura de la solucioacuten para el escenario de
pruebas con Docker se expondraacute a continuacioacuten el conjunto de tecnologiacuteas y herramientas usadas para
llevar a cabo el desarrollo de las pruebas automatizadas de aceptacioacuten o pruebas End-to-End Con este
conjunto de herramientas se pretende conseguir la implementacioacuten de los diferentes scripts de pruebas que
automaticen las acciones e interacciones necesarias con la plataforma Web CHT Cloud Manager como si de
una persona se tratase
51 Selenium
Selenium es una herramienta de coacutedigo abierto utilizada para la automatizacioacuten de pruebas en navegadores web
Dicha herramienta posee una enorme popularidad en el mundo de las pruebas de software debido a que
Presenta compatibilidad con diferentes lenguajes de programacioacuten para la implementacioacuten de scripts de
pruebas ofreciendo libreriacuteas en Java Python C PHP Ruby Perl y Net
Es multiplataforma permitiendo el lanzamiento de los scripts de pruebas en diversos sistemas
operativos como Windows Mac o Linux y en diferentes navegadores como Mozilla Firefox Internet
Explorer Google Chrome Safari y Opera
Soporta la integracioacuten con otras herramientas como TestNG o JUnit
Permite la integracioacuten continua con Maven Jenkins gitlab CICD y Docker
Sin embargo presenta una serie de inconvenientes que se deben mencionar
bull Solo permite probar aplicaciones Web
bull No hay soporte garantizado desde Selenium Muchas de las soluciones a problemas de la herramienta
han sido generadas por la comunidad
bull No es posible realizar pruebas en imaacutegenes Para ello es necesaria la integracioacuten con otras herramientas
bull No tiene capacidad nativa para generar informes o reportes de los resultados de las pruebas Para ello
se requiere el uso de un framework como puede ser el Robot Framework
Centrando la atencioacuten en el enfoque de dicho proyecto se haraacute uso de la libreriacutea Selenium para Python y la
facilidad de Robot Framework tanto para abstraer la posible complejidad antildeadida del lenguaje de programacioacuten
usado para la implementacioacuten de los scripts de prueba como para permitir la generacioacuten automaacutetica de informes
y reportes de resultados
Realmente Selenium estaacute formado por un conjunto de herramientas las cuales son Selenium RC Selenium
IDE Selenium Grid y Selenium Webdriver Dichas herramientas permiten desde la realizacioacuten de pruebas en
maacutequinas remotas a la ejecucioacuten de pruebas en diferentes maacutequinas con diferentes navegadores cada una
Con el lanzamiento de Selenium 2 en 2008 se antildeadieron nuevas funcionalidades de Selenium RC y Webdriver
en una misma herramienta aunque es frecuente mantener la nomenclatura de WebDriver a la hora de referirse
a la misma En este proyecto se centraraacute la atencioacuten en la herramienta WebDriver de Selenium
U
El disentildeo es el alma de todo lo creado por el hombre
Steve Jobs
70
52 Selenium WebDriver
Esta herramienta de Selenium ofrece una interfaz para ejecutar los casos de prueba descritos en los scripts
de prueba A traveacutes de esta API WebDriver se comunica directamente con el controlador del navegador
donde corre la aplicacioacuten Para ello seraacute necesario el uso de controladores para los diferentes navegadores
Web desde los que se validan las pruebas automaacuteticas
Todas las implementaciones de WebDriver que se comunican con el navegador usan un protocolo punto a
punto comuacuten Este protocolo define un servicio RESTfull usando JSON sobre HTTP Cada operacioacuten
realizada por WebDriver se mapea en un meacutetodo HTTP que se comunica con el navegador Las respuestas
a dichas operaciones seraacuten devueltas en mensajes HTTP de respuesta
Existen diversas implementaciones de Selenium para diferentes entornos tal y como se muestra en la
siguiente figura
Figura 41 Implementaciones disponibles de Selenium y Navegadores Web Compatibles
Para la ejecucioacuten de las pruebas implementadas en este proyecto se ha hecho uso de los controladores Gecko
Driver y Chromedriver para los navegadores Web Firefox y Google Chrome
521 Elementos del Navegador
Una vez tenemos una viacutea de comunicacioacuten con el navegador planteamos la pregunta iquesty coacutemo le indico al
navegador con queacute componente quiero interactuar
La cantidad de componentes que existen es muy amplia cajas de texto botones imaacutegenes hiperviacutenculos
botones de radio check boxes aacutereas de texto mensajes de error desplegables tablas frames etc Todos
estos elementos tienen una serie de propiedades que pueden ser uacutenicas o no en toda la paacutegina Por ejemplo
un identificador (ID) debe distinguir de manera uniacutevoca a un elemento Este identificador es lo que se
denomina un localizador Existen 8 tipos distintos de localizadores diferentes
bull Id Name Class Name Tag Name Link Text Partial Link Text CSS Xpath
71
Se podraacuten implementar las interacciones con el navegador mediante la llamada a un meacutetodo (accioacuten) que
se aplicaraacute sobre el elemento que nosotros indiquemos A continuacioacuten se muestra el diagrama de bloques
y la implementacioacuten de un ejemplo simple del inicio de sesioacuten usando Python y la libreriacutea de Selenium
Figura 42 Coacutedigo de ejemplo con Python y Selenium
La implementacioacuten anterior permite abrir un navegador Web Chrome en pantalla completa y acceder a la
plataforma Web Galgus CHT Cloud Manager Una vez ha sido posible el acceso y la paacutegina Web estaacute
disponible se realiza el inicio de sesioacuten en la plataforma con las credenciales correspondientes esperando que
dicho inicio de sesioacuten se haya realizado con eacutexito Finalmente se cierran todas las instancias de navegadores
Web abiertas por Selenium en la automatizacioacuten de dicha prueba de concepto
72
53 Robot Framework (RF)
Para la automatizacioacuten del testeo de la aplicacioacuten se ha hecho uso de este framework como herramienta
para dicha finalidad Robot Framework es un framework geneacuterico de automatizacioacuten de pruebas de coacutedigo
abierto desarrolla do por Pekka Klaumlrck en el antildeo 2005
Este framework sigue el enfoque Keyword-Driven Testing y es un candidato idoacuteneo debido a su alto nivel
de abstraccioacuten para pruebas de aceptacioacuten y desarrollo guiado por pruebas de aceptacioacuten o Acceptance
Test-Driven Development (ATDD) Las capacidades de pruebas pueden ser ampliadas con nuevas libreriacuteas
implementadas tanto en Python como en Java y los usuarios pueden crear nuevas keywords a partir de las
existentes usando la misma sintaxis que para los casos de prueba [18]
Robot Framework es independiente del sistema operativo y de la aplicacioacuten El nuacutecleo del framework estaacute
implementado en Python soportando tanto Python 2 como Python 3
Se ha decidido utilizar este framework por la disponibilidad de un amplio conjunto de libreriacuteas de propoacutesito
general y la integracioacuten con libreriacuteas externas como Selenium2Library Entre otras prestaciones permite el
uso de variables que aportan mayor flexibilidad a la hora de disentildear y controlar los scripts de prueba
permite el etiquetado para poder identificar y ejecutar los casos de prueba por separado proporciona una
faacutecil integracioacuten con Jenkins y Maven y proporciona un sistema de reporte de informes de resultados
detallados y de faacutecil lectura Ademaacutes hay que destacar la faacutecil abstraccioacuten que ofrece al poder utlizar
keywords de alto nivel permitiendo el uso del estilo de representacioacuten Given-When-Then para los casos
de prueba A continuacioacuten se describe dicho estilo de representacioacuten
531 Estilo de representacioacuten Given-When-Then
Dicho estilo ofrecido por Robot Framework es uno de los puntos fuertes de este framework Esta caracteriacutestica
permite el uso del siguiente estilo de representacioacuten para los casos de prueba
Figura 43 Estilo de representacioacuten Given-When-Then
bull Given Define las precondiciones necesarias para llevar a cabo la accioacuten asiacute como el actor de la
misma
bull When Accioacuten llevada a cabo por el actor definido en la claacuteusula Given
bull Then Es el comportamiento esperado o la salida del sistema esperada ante una entrada
determinada
bull And Claacuteusula auxiliar que se usa de forma combinada con las anteriores
73
Como ejemplo de aplicacioacuten de este estilo de representacioacuten supongamos que tenemos unos requisitos de
aceptacioacuten establecidos en un documento entre los que se encuentran el inicio y cierre de sesioacuten mediante
usuario y contrasentildea a la plataforma Galgus CHT Cloud Manager En la siguiente tabla se muestran los
criterios de aceptacioacuten definidos en el documento de requisitos para dicha funcionalidad
1 Un usuario no identificado puede iniciar sesioacuten desde la vista principal de la plataforma Web
2 Un usuario no identificado debe insertar un usuario y contrasentildea vaacutelidos para el inicio de sesioacuten
A continuacioacuten se muestra coacutemo se llevariacutea a cabo la implementacioacuten de los scripts de pruebas abstractos
asociados a las especificaciones anteriores haciendo uso del estilo de representacioacuten Given-When-Then
Es complicado implementar todos los casos de prueba posibles principalmente cuando el requisito de
aceptacioacuten requiere de una funcionalidad compleja En este caso se muestran tres casos de prueba
abstractos los cuales han sido implementados en el proyecto para validar el inicio y cierre de sesioacuten
Caso de Prueba 1 Inicio de Sesioacuten en Galgus CHT Cloud Manager
Claacuteusula Keyword
Given Navegacioacuten a la paacutegina principal de Galgus CHT Cloud Manager
When Insertar nombre de usuario vaacutelido
And Insertar contrasentildea vaacutelida
Then Iniciar sesioacuten con eacutexito
Caso de Prueba 2 Intento de Inicio de sesioacuten con usuario no vaacutelido
Claacuteusula Keyword
Given Navegacioacuten a la paacutegina principal de Galgus CHT Cloud Manager
When Insertar nombre de usuario invaacutelido
And Insertar contrasentildea vaacutelida
Then No es posible el inicio de sesioacuten Se muestra mensaje de error
Caso de Prueba 3 Intento de Inicio de sesioacuten con contrasentildea no vaacutelida
Claacuteusula Keyword
Given Navegacioacuten a la paacutegina principal de Galgus CHT Cloud Manager
When Insertar nombre de usuario vaacutelido
And Insertar contrasentildea invaacutelida
Then No es posible el inicio de sesioacuten Se muestra mensaje de error
74
En la siguiente figura se muestra la implementacioacuten de dichas pruebas con Robot Framework donde cada
Keyword implementada permite la abstraccioacuten de toda la funcionalidad necesaria para realizar las pruebas
Figura 44 Implementacioacuten de Pruebas en para el inicio de sesioacuten de CHT Cloud Manager
75
532 Reportes
A continuacioacuten se muestra un ejemplo de los reportes obtenidos tras la ejecucioacuten del primer caso de prueba de
los anteriores donde pueden identificarse las diversas keywords necesarias para implementar cada caso de
prueba asiacute como otras adicionales que ayudan a crear el contexto (precondiciones) Tambieacuten se incluyen
estadiacutesticas sobre el tiempo de ejecucioacuten nuacutemero de tests total nuacutemero de tests que han fallado o que han pasado
con eacutexito [18]
Figura 45 Ejemplo de reporte de pruebas automatizadas con Robot Framework
76
533 Libreriacuteas
Robot Framework permite el uso de Selenium mediante la libreriacutea de pruebas Web SeleniumLibrary Dicha
libreriacutea es compatible con las versiones de Selenium 2536 y sucesivas y con Python 27 y Python 3 Ademaacutes
del inteacuterprete por defecto de Python esta libreriacutea funciona tambieacuten con PyPy y Jython [18]
Esta libreriacutea estaacute compuesta entre otras muchas por una serie de archivos de Python (py) que implementan
las clases que contienen las diversas keywords que pueden ser usadas en nuestro framework La estructura de
estos archivos se presenta en la siguiente tabla
Archivo de Clase Funcioacuten
Alertpy Interacciones con mensajes de alerta
Browsermanagementpy Apertura cierre y cambio de navegadores
Cookiepy Manipulacioacuten de cookies del navegador
Elementpy Interaccioacuten con elementos y sus atributos
Formelementpy Interaccioacuten con elementos en formularios
Framespy Manejo de frames y su contenido
Javascriptpy Facilidades para inyectar coacutedigo javascript
Runonfailurepy Uso de funcionalidades en caso de fallo
Screenshotpy Manejo de capturas de pantalla
Selectelementpy Manejo de elementos en listas
Tableelementpy Manejo de elementos en tablas
Waitingpy Manejo de temporizadores de espera para
transiciones en una paacutegina
Webdrivertoolspy Interaccioacuten directa con el controlador del navegador
Windowpy Manejo de ventanas del navegador
Estas libreriacuteas fueron desarrolladas en sus oriacutegenes por el ingeniero finlandeacutes Tatu Aalto y posteriormente
mejoradas por toda la comunidad de expertos en automatizacioacuten de pruebas Sin embargo Robot Framework
mediante el uso de Python con Selenium permite la implementacioacuten de libreriacuteas propias o funcionalidades
desarrolladas en Python que pueden ser integradas en Robot Framework En este proyecto se hace uso de Python
con Selenium para desarrollar algunas funcionalidades avanzadas que permiten probar ciertos criterios de la
aplicacioacuten muy especiacuteficos y avanzados de la plataforma Web para los cuales las libreriacuteas ofrecidas por Robot
Framework no proporcionan la funcionalidad requerida
Ademaacutes se ha hecho uso de otras libreriacuteas como BuiltIn para el uso de bucles condicionales y otras keywords
String y Collections para el tratamiento de cadenas de caracteres y colecciones de datos SSHLibrary para usar
un cliente ssh Process para la ejecucioacuten de subprocesos haciendo uso la libreriacutea subprocess de python y
OperatingSystem para realizar algunas tareas sobre el sistema operativo
77
534 Documentacioacuten
La documentacioacuten de los diferentes casos de pruebas implementados con Robot Framework es muy redundante
y una tarea la cual seriacutea deseable de poder automatizar Dicho framework ofrece esta posibilidad a traveacutes de dos
herramientas para crear documentacioacuten basada en las pruebas y libreriacuteas implementadas para dichas pruebas
Libdoc y Testdoc [18]
5341 Libdoc
Libdoc es una herramienta ofrecida por Robot Framework para construir documentacioacuten sobre las keywords
implementadas para los casos de prueba Dicha documentacioacuten es generada en formato HTML y XML
Se puede crear documentacioacuten para bibliotecas implementadas con Python o Java y para las propias libreriacuteas
implementadas con Robot Framework A continuacioacuten se muestra un ejemplo de la documentacioacuten generada
para la libreriacutea implementada para los casos de prueba de inicio y cierre de sesioacuten de Galgus CHT Cloud
Manager
Figura 46 Ejemplo de documentacioacuten generada con Libdoc
5342 Testdoc
Testdoc es una herramienta para generar documentacioacuten de alto nivel basada en los casos de prueba de Robot
Framework Dicha documentacioacuten es generada en formato HTML e incluye el nombre la documentacioacuten y
otros metadatos de cada conjunto de pruebas y casos de prueba asiacute como las keywords de alto nivel y sus
argumentos
A continuacioacuten se muestra un ejemplo de la documentacioacuten generada para el conjunto de casos de prueba que
validan el inicio y cierre de sesioacuten de Galgus CHT Cloud Manager
Figura 47 Ejemplo de documentacioacuten generada con Testdoc
78
54 Pycharm (IDE)
Esta herramienta proporciona un entorno de desarrollo integrado (IDE) el cual ha sido usado para programar en
lenguaje Python por lo que es idoacuteneo tambieacuten para el desarrollo de pruebas con Robot Framework Esta
desarrollado por la empresa JetBrains Ademaacutes proporciona entre otras muchas herramientas el anaacutelisis de
coacutedigo un depurador graacutefico integracioacuten con sistemas de control de versiones y es multiplataforma
55 GitGitlab
551 Git
Git es un software de control de versiones disentildeado por Linux Torvalds pensando en la eficiencia y la
confiabilidad del mantenimiento de versiones de aplicaciones cuando eacutestas tienen un gran nuacutemero de archivos
de coacutedigo fuente Al principio Git se pensoacute como un motor de bajo nivel sobre el cual otros pudieran escribir la
interfaz de usuario como Cogito o StGIT Sin embargo Git se ha convertido desde entonces en un sistema de
control de versiones con funcionalidad plena Hay algunos proyectos de mucha relevancia que ya usan Git en
particular el grupo de programacioacuten del nuacutecleo Linux Ademaacutes cabe destacar que se ha hecho uso de
GitKraken como interfaz graacutefica de git para llevar a cabo el control de versiones de una forma maacutes intuitiva
552 Gitlab
Gitlab es un servicio Web de control de versiones y desarrollo de software colaborativo basado en Git Fue
implementado por los desarrolladores ucranianos Dimitry Zaporozhets y Valey Sizov en el lenguaje de
programacioacuten Ruby Este proyecto cuenta con un equipo de 150 miembros y maacutes de 1400 usuarios y es usado
por empresas como la NASA el CERN IBM o Sony [19]
Ademaacutes de gestor de repositorios tambieacuten ofrece la posibilidad de alojar documentacioacuten y un sistema de
seguimiento de errores Tambieacuten es de gran importancia destacar que esta herramienta proporciona su propia
herramienta de Integracioacuten Continua sin necesidad de usar otra herramienta externa
Se ha hecho uso de estas herramientas para tener un control de versiones sobre nuestro proyecto y una gestioacuten
centralizada de todos los repositorios de la empresa de forma que asiacute podemos tener un control de versiones de
todos los cambios realizados en el coacutedigo con posibilidad de contrastarlos con versiones anteriores y recuperar
dichos cambios Ademaacutes se hace uso tambieacuten de gitlab CICD para implementar procesos de Integracioacuten
continua sobre los diferentes proyectos En el caso particular de este proyecto para generar la documentacioacuten
de los casos de test y libreriacuteas y para generar un Docker con toda la bateriacutea de pruebas y dependencias necesarias
para lanzarlas
56 Redmine
Redmine es una herramienta para la gestioacuten de proyectos que ofrece un conjunto de funcionalidades que
permiten a los usuarios de diferentes proyectos realizar el seguimiento y organizacioacuten de los mismos Incluye
un sistema de seguimiento de incidentes Otras herramientas que incluye son un calendario de actividades
diagramas de Gantt una wiki para almacenar documentacioacuten control del flujo de trabajo basado en roles
integracioacuten con correo electroacutenico etc
Esta herramienta se usa para la gestioacuten del proyecto Galgus CHT Cloud Manager donde se integra como
subproyecto la automatizacioacuten del proceso de pruebas para la plataforma Web desarrollada
A continuacioacuten se muestra un ejemplo del flujo de trabajo implantado en la metodologiacutea de trabajo dentro del
proyecto donde cada historia puede contener un conjunto de tareas las cuales pueden pasar por diferentes
estados hasta ser completadas por el desarrollador o el ingeniero de pruebas
79
Figura 48 Ejemplo de Flujo de Trabajo en Redmine para Galgus CHT Cloud Manager
561 Uso en el Proyecto Galgus CHT Cloud Manager (Metodologiacutea Scrum)
Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas praacutecticas para trabajar
colaborativamente en equipo y obtener el mejor resultado posible de un proyecto Estas praacutecticas se apoyan
unas a otras y su seleccioacuten tiene origen en un estudio de la manera de trabajar de equipos altamente productivos
Esta metodologiacutea divide el trabajo en una lista de pequentildeas funcionalidades ordenadas por prioridad y estimadas
en esfuerzo Estas pequentildeas tareas son abordadas en iteraciones cortas de longitud fija denominadas Sprints de
1 a 4 semanas (en este caso se ha optado por iteraciones de 3 o 4 semanas) obteniendo coacutedigo potencialmente
entregable siendo demostrado al final de cada iteracioacuten Una vez decidido por el equipo de gestioacuten de proyectos
el alcance y conjunto de actividades a realizar dentro del sprint se transmite al resto del equipo que forma parte
del proyecto procediendo a la asignacioacuten de tareas mediante Redmine como herramienta de gestioacuten usada
Durante el sprint se va realizando un seguimiento perioacutedico del estado del proyecto y de la situacioacuten de cada
integrante mediante una actividad previa diaria de unos 15 minutos para situar el punto de partida de trabajo
diario que seriacutean reuniones diarias de apenas 15 minutos denominadas ldquoDaylisrdquo
Figura 49 Esquema Graacutefico de Metodologiacutea Scrum
80
La planificacioacuten que se pretende seguir en cada sprint es la siguiente
1 Semana 1 y 2 Realizacioacuten de tareas por parte del equipo de desarrollo incluyendo en estas tareas
nuevos desarrollos modificacioacuten de funcionalidades y verificacioacuten de las mismas mediante pruebas
unitarias y de integracioacuten
2 Semana 3 Realizacioacuten de pruebas de aceptacioacuten manuales por parte del equipo de pruebas y posterior
automatizacioacuten de dichas pruebas Para ello se usaraacute el entorno de UAT como escenario de pruebas
Ademaacutes el equipo de desarrollo iraacute corrigiendo todos aquellos errores o defectos encontrados
3 Semana 4 El jefe de proyecto realiza la fusioacuten de todos los desarrollos y actualiza las versiones en el
entorno de Preproduccioacuten incluyendo todas las actividades realizadas y validadas por el equipo de
desarrollo y de pruebas El equipo de pruebas realizaraacute la ejecucioacuten de todas las pruebas End-to-End
sobre el entorno de Preproduccioacuten para verificar y validar la nueva versioacuten que incluye todas las
funcionalidades Estas pruebas son denominadas pruebas de regresioacuten las cuales verifican que los
nuevos desarrollos no han provocado defectos o errores sobre funcionalidades que hasta ahora habiacutean
funcionado correctamente Finalmente el jefe de proyecto realiza el despliegue en produccioacuten
81
82
6 EXPERIMENTOS
na vez descrito el sistema bajo pruebas el proceso de pruebas y las herramientas que se usaraacuten para
automatizar las pruebas de aceptacioacuten sobre la plataforma de gestioacuten Galgus CHT Cloud Manager
solo queda presentar la forma en la que se ha puesto en praacutectica y el proceso seguido paso a paso
Dado que el objetivo es conseguir una bateriacutea de casos de pruebas End-to-End automatizadas se implementaraacuten
dichos casos de prueba de forma que permitan detectar el incorrecto funcionamiento de cada funcionalidad con
la mayor rapidez posible cubriendo los principales escenarios donde puedan surgir los mayores errores Por
tanto dichos casos de prueba seraacuten elegidos en base al riesgo que puedan introducir
Estos casos de prueba seraacuten definidos mediante un conjunto de criterios de aceptacioacuten descritos a traveacutes de
diagramas de flujo y agrupados seguacuten la funcionalidad de la aplicacioacuten que abarquen las cuales son
1 Vista de Gestioacuten Principal (Coud Tab) Esta seccioacuten de la Web estaacute destinada a la administracioacuten de
usuarios administracioacuten de los diferentes Zone Managers y finalmente incluye un Mapa con la
ubicacioacuten de cada Zone Manager
2 Vista de Configuracioacuten (Configuration Tab) En esta pestantildea se ofrece la gestioacuten de grupos de puntos
de acceso gestioacuten de backups y restauracioacuten gestioacuten de firmwares zonas CHT etc
3 Vista de Red (Network Tab) La pestantildea de red engloba toda la configuracioacuten de red de los puntos de
acceso siendo esta la pestantildea con mayor funcionalidad complejidad y por ello potencial de riesgo de
errores de la plataforma Web
Figura 50 Logo de Galgus CHT Cloud Manager
U
La uacutenica parte donde el ldquoeacutexitordquo aparece antes que el trabajo es en el diccionario
Vidal Sasoon
83
61 Estructura del Proyecto
La clasificacioacuten funcional anterior seraacute tomada de la misma forma para organizar la estructura del proyecto de
pruebas automatizadas con Robot Framework para un desarrollo ordenado y loacutegico de todo el conjunto de casos
de prueba A continuacioacuten se muestra un ejemplo de la estructura del proyecto el cual se encuentra en desarrollo
y continua mejora
Figura 51 Estructura del Proyecto
Para una mayor modularidad y limpieza en el desarrollo de los casos de Test se han centralizado todos los
localizadores en un archivo llamado ldquoSelectorpyrdquo En la siguiente figura se muestra un fragmento de dicho
fichero
Figura 52 Fragmento del fichero ldquoSelectorpyrdquo
A la hora de obtener los localizadores de los elementos que seraacuten comprobados o usados en los scripts de pruebas
se han usado las herramientas de desarrollador que incluye Google Chrome Para ello basta con navegar a la
paacutegina de la plataforma Web en cualquier navegador y pulsar la tecla F12 Esto mostraraacute las herramientas de
desarrolladores donde encontramos una pestantildea llamada ldquoElementosrdquo donde se puede inspeccionar el
documento ldquoHTMLrdquo de la paacutegina Una vez abierta dicha herramienta seraacute sencillo obtener propiedades de los
diversos elementos que nos permitiraacuten hacer referencia a los mismos en nuestro script de pruebas
Los ldquoXpathrdquo absolutos seraacuten lo usados praacutecticamente en toda la Suite de pruebas El beneficio de los
identificadores uacutenicos es que permiten seleccionar elementos sin que sea necesario hacer referencia a su posicioacuten
dentro del documento HTML Esto evita cualquier problema en caso de que las rutas de un elemento dentro del
citado documento cambien debido a mejoras o despistes por parte de los desarrolladores En cambio usar
selectores basados en la ruta del elemento dentro del documento HTML puede propiciar falsos fallos en el
escenario anterior debido a que no puedan encontrarse en la Web a pesar de que realmente sigan estando
presentes y totalmente funcionales
Por otro lado se han agrupado todas aquellas ldquokeywordsrdquo que puedan ser usadas por otras secciones en la
implementacioacuten de los casos de prueba mediante ficheros nombrados como ldquotab_common_keywords robotrdquo
84
Siguiendo esta jerarquiacutea se ha incluido un fichero llamado ldquoCommon_Keywordsrobotrdquo general en el que se
incluyen las principales ldquokeywordsrdquo que pueden ser usadas en todo el proyecto A continuacioacuten se muestra un
fragmento de este fichero
Figura 53 Fragmento del fichero ldquoCommon_Keywordsrobotrdquo
Tambieacuten se incluye el fichero ldquoConfigurationrobotrdquo para agrupar definiciones de variables que seraacuten
usadas en todo el proyecto ademaacutes de realizar la inclusioacuten de las libreriacuteas a usar Se muestra otra figura
con un fragmento del fichero ldquoConfigurationrobotrdquo
Figura 54 Fragmento del fichero de Configuracioacuten de pruebas ldquoConfigurationrobotrdquo
85
A continuacioacuten se muestra un diagrama que muestra las dependencias de los diferentes archivos y la estructura
seguida por el proyecto
Figura 55 Diagrama de paquetes del proyecto de pruebas
Tras introducir la estructura del proyecto y las diferentes funcionalidades de la plataforma Web Galgus CHT
Cloud Manager a continuacioacuten se mostraraacuten algunos criterios de aceptacioacuten de cada funcionalidad a probar
con diagramas de flujo y scripts de pruebas haciendo uso del estilo de representacioacuten Given-When-Then
Ademaacutes se mostraraacuten algunos detalles de implementacioacuten sobre las pruebas Por otro lado la ejecucioacuten de los
casos de prueba de ejemplo y el reporterevisioacuten de resultados se incluiraacute en la seccioacuten de Anexos
Cada una de las siguientes subsecciones dentro de cada funcionalidad principal de la aplicacioacuten o vista principal
tendraacute su correspondiente Suite de pruebas con un conjunto de casos de Test Todas estas Suites seguiraacuten la
siguiente estructura comuacuten para los casos de Test
Figura 56 Estructura de una Suite de Pruebas
86
Todas las Suites comienzan con una seccioacuten de documentacioacuten para describir el contenido de las pruebas de forma geneacuterica y varias secciones para importar los recursos necesarios para las pruebas (Resource)
Las secciones ldquoSuite Setuprdquo y ldquoSuite Teardownrdquo permiten la ejecucioacuten automaacutetica antes y despueacutes de la bateriacutea de pruebas y las secciones ldquoTest Setuprdquo y ldquoTest Teardownrdquo permiten la ejecucioacuten automaacutetica antes y despueacutes de cada caso de prueba
Un uso tiacutepico de ldquoSuite Setuprdquo es abrir un navegador Web y comprobar la disponibilidad de la Web a probar mientras que el cierre del navegador se realiza con ldquoSuite Teardownrdquo De este modo sea cual sea el resultado de la ejecucioacuten no se quedaraacuten abiertas ventanas gastando recursos de la maacutequina
Por otro lado el uso por defecto de ldquoTest Setuprdquo en este proyecto ha sido el inicio de sesioacuten en la Web CHT Cloud Manager mientras que ldquoTest Teardownrdquo ha sido usado para cerrar tambieacuten el navegador Web Sin embargo la mayoriacutea de las pruebas implementadas necesitan una serie de precondiciones previas a la ejecucioacuten del Test y un conjunto de postcondiciones necesarias para no provocar inconsistencias entre la ejecucioacuten de diferentes pruebas Por este motivo se ha hecho uso de las etiquetas [Setup] y [Teardown] para modificar la ejecucioacuten por defecto de ldquoTest Setuprdquo y ldquoTest Teardownrdquo en cada caso de prueba cuando sea necesario
Cabe destacar que la loacutegica implementada dentro de estas claacuteusulas no requiere que sea validada puesto que su uacutenico objetivo es preparar el entorno de pruebas para ejecutar una prueba sin que esta falle por causas ajenas al aacutembito y objetivo de la prueba evitando de esta forma los falsos positivos Por este motivo se hace uso de la Keyword ldquoRun Keyword And Ignore Errorrdquo ofrecida por la libreriacutea ldquoBuiltInrdquo para ignorar los errores en la ejecucioacuten de [Setup] y [Teardown] En la siguiente figura se muestra un ejemplo de dicha teacutecnica
Figura 57 Ejemplo de ldquoTest Setuprdquo personalizado para un caso de prueba
Finalmente la implementacioacuten de las ldquokeywordsrdquo usadas mediante la nomenclatura Given-When-Then seraacuten agrupadas en el correspondiente fichero ldquoTab_common_keywordsrobotrdquo para conseguir una abstraccioacuten de la loacutegica necesaria para la automatizacioacuten de las pruebas En las pruebas seleccionadas para describir en esta seccioacuten se detallaraacute la implementacioacuten de algunas keywords que se usaraacuten
87
62 Vista de Gestioacuten Principal (Cloud Tab)
En la siguiente figura se muestra la vista de Gestioacuten Principal de Galgus CHT Cloud Manager
Figura 58 Vista de Gestioacuten Principal (Cloud Tab)
Sobre esta vista se han automatizado un conjunto de Suites de pruebas que validan toda la funcionalidad
contenida en las pestantildeas MAP List of Zone Managers y Administration ademaacutes de toda la loacutegica ofrecida para
gestionar un conjunto de fabricantes
621 Administration
Comenzando con la pestantildea de administracioacuten se puede observar la existencia de cuatro flujos de navegacioacuten
principales en la siguiente figura
Figura 59 Pestantildea ldquoAdministrationrdquo
Una vez conocida la vista de administracioacuten de la Web se han realizado un total de 22 casos de prueba de los
cuales detallaremos el caso de prueba identificado con la etiqueta U0027
6211 Criterios de Aceptacioacuten
La pestantildea de administracioacuten permite la gestioacuten de los usuarios y roles que tienen acceso a la plataforma Web
ademaacutes de la configuracioacuten de los detalles de los fabricantes seleccionados A continuacioacuten se detallan los
criterios de aceptacioacuten del caso de prueba seleccionado
U0027 Un usuario con permisos de Super Usuario puede editar la informacioacuten de un fabricante
1 Un usuario con permisos de Super Usuario puede ver y acceder a la pestantildea de administracioacuten
2 Un usuario con permisos de Super Usuario puede editar la informacioacuten de un fabricante correctamente
88
6212 Diagramas de Flujo
A continuacioacuten se muestran los diagramas de flujo implementados para los dos casos de prueba analizados
Figura 60 Diagramas de Flujo de Casos de Prueba U0025 y U0027
6213 Script de Pruebas
Una vez establecidos los criterios de aceptacioacuten de ambos casos de prueba se mostraraacuten los scripts de pruebas
realizados
Figura 61 Script de Pruebas U0025
Entre las ldquokeywordsrdquo usadas en el caso de test anterior se puede destacar por ejemplo la implementacioacuten de
ldquoEdit Fieldsrdquo la cual permite editar los campos de un fabricante y verificar que han sido editados tras guardar
los cambios
Figura 62 Keyword ldquoEdit Fieldsrdquo
89
622 List
En la pestantildea de gestioacuten de los diferentes Zone Managers se puede observar una lista de los diferentes Zone
Managers disponibles y se pueden realizar un conjunto de acciones como la creacioacuten de nuevos Zone Managers
y edicioacuten o eliminacioacuten de los existentes entre otras
Figura 63 Pestantildea ldquoList of Zone Managersrdquo
Sobre esta vista se han realizado un total de 7 casos de prueba de los cuales detallaremos el caso de prueba
identificado con la etiqueta U0023 el cual permite validar la creacioacuten y eliminacioacuten de un Zone Manager
6221 Criterios de Aceptacioacuten
A continuacioacuten se detallan los criterios de aceptacioacuten del caso de prueba seleccionado
U0023 Verificar que un Usuario puede Crear y Eliminar un Zone Manager
1 Un usuario con permisos de Super Usuario puede Navegar a la pestantildea List Of Zone Managers
2 El usuario puede crear un Zone Manager correctamente
3 El usuario puede eliminar un Zone Manager correctamente
6222 Diagramas de Flujo
A continuacioacuten se muestra el diagrama de flujo implementado para el caso de prueba analizado
Figura 64 Diagrama de flujo de Caso de Prueba U0023
90
6223 Script de Pruebas
Una vez establecidos los criterios de aceptacioacuten se mostraraacute el script de pruebas realizado a partir del diagrama
de flujo anterior
Figura 65 Script de Prueba U0023
Cabe destacar la implementacioacuten de la Keyword ldquoZone Manager is Registered Successfullyrdquo la cual comprueba
que el Zone Manager registrado pasa a un estado ldquoOnlinerdquo tras un tiempo considerado como aceptable para que
la instancia de dicho Zone Manager este disponible en Cloud CHT Manager
Figura 66 Keyword ldquoZone Manager is registered successfullyrdquo
623 Manufacturer
La vista de gestioacuten principal ofrece una seccioacuten que permite la gestioacuten de los diferentes fabricantes permitiendo
su creacioacuten edicioacuten eliminacioacuten y bloqueo En la siguiente figura se muestra un ejemplo de la seccioacuten de
fabricantes
Figura 67 Seccioacuten de Fabricantes
Para validar el correcto funcionamiento de dicha seccioacuten se han realizado un total de 9 casos de prueba de los
cuales se detallaraacuten los casos de prueba identificados con las etiquetas U0009 Estos permiten validar que los
fabricantes pueden ser creados editados y eliminados correctamente y que todos los fabricantes disponibles son
mostrados correctamente
91
6231 Criterios de Aceptacioacuten
A continuacioacuten se detallan los criterios de aceptacioacuten de los casos de prueba seleccionados
U0009 Verificar que un Usuario con permisos de Super usuario puede ver correctamente todos los
fabricantes existentes
1 Un usuario con permisos de Super Usuario puede Navegar a la pestantildea de Administracioacuten
2 El usuario puede visualizar todos los fabricantes existentes
6232 Diagrama de Flujo
Figura 68 Diagrama de flujo de Caso de Prueba U0009
6233 Script de Pruebas
Una vez establecidos los criterios de aceptacioacuten se mostraraacuten los scripts de pruebas realizados a partir de los
diagramas de flujo anteriores
Figura 69 Script de Prueba U0009
En este punto cabe destacar la finalidad de la Keyword ldquoCorrectly Createrdquo la cual se usa en la mayoriacutea de las
pruebas para verificar que una operacioacuten se ha realizado con eacutexito en la plataforma Galgus CHT Cloud Manager
Esta Keyword verifica que tras realizar alguacuten tipo de operacioacuten en la plataforma Web ocurre un evento sobre la
Web que indica que dicha operacioacuten se ha realizado con eacutexito de la siguiente forma
92
Figura 70 Toast Success
Figura 71 Keyword ldquoCorrectly Createrdquo
Finalmente se muestra la implementacioacuten de las keywords usadas en [Setup] y [Teardown] del caso de prueba
U0009 las cuales preparan el escenario de pruebas creando un conjunto de fabricantes acotado y los elimina
tras la finalizacioacuten de la prueba
Figura 72 Setup amp Teardown de U0008
624 MAP
La plataforma Galgus CHT Cloud Manager ofrece una pestantildea ldquoMAPrdquo que contiene un mapa con la ubicacioacuten
asignada a cada uno de los Zone Managers disponibles por el usuario mostrando en su ubicacioacuten un icono con
el estado de dicho Zone Manager el cual cambia de color seguacuten su estado (offline online unsynchronized)
Figura 73 Mapa de Zone Managers
93
A traveacutes de dicho icono se puede realizar una serie de acciones entre ellas acceder a un Zone Manager
realizando doble click sobre el icono del mismo Sin embargo para automatizar este conjunto de acciones el
equipo de pruebas ha encontrado dificultades haciendo uso de Robot Framework ya que las libreriacuteas disponibles
permiten la interaccioacuten con elementos de la Web pero en este caso los iconos de los diferentes Zone Managers
son renderizados dentro del Mapa con ldquoOpen Street Mapsrdquo antes de ser mostrado en la vista Web de la
aplicacioacuten Por esta razoacuten el mapa es localizado en el DOM como un uacutenico elemento Web lo que imposibilita
localizar a priori el icono de cada Zone Manager dentro del Mapa
Para resolver este impedimento el equipo de pruebas tuvo que analizar con profundidad la libreriacutea de ldquoOpen
Street Maprdquo implementada en Javascript Esta ha sido usada en el Frontend para encontrar alguna funcioacuten que
permitiese obtener desde la consola del navegador Web los piacutexeles en los que cada Zone Manager ha sido
renderizado dentro del Mapa Dicha funcioacuten es ldquogetPixelsFromCoordinate(coordinate)rdquo la cual a traveacutes de las
coordenadas de [Latitud Longitud] de cada Zone Manager se obtienen los piacutexeles del mismo en la pantalla A
traveacutes del siguiente fragmento de coacutedigo en el frontend implementado con Angular 6 en typescript se consigue
obtener los piacutexeles de cada Zone Manager e imprimirlo en la consola del navegador Web
Figura 74 Funcioacuten que dibuja los ZM en el Mapa y obtiene los piacutexeles en pantalla
Para llevar a cabo la implementacioacuten de las pruebas sobre el mapa se ha hecho uso en su gran mayoriacutea de Scripts
con Python Selenium y otras libreriacuteas necesarias en lugar de Robot Framework debido a la necesidad de
realizar varias tareas simultaneas ademaacutes de tratarse de pruebas muy especiacuteficas y personalizadas A
continuacioacuten se muestra la prueba implementada para poder realizar doble click sobre un Zone manager en el
mapa e iniciar sesioacuten en el mismo (U0007)
6241 Criterios de Aceptacioacuten
U0007 Verificar que un Usuario acceder a un Zone Manager desde el Mapa
1 Un usuario con permisos de Super Usuario puede Navegar a la pestantildea MAP
2 El usuario puede hacer doble click en el Zone Manager e iniciar sesioacuten
94
6242 Diagrama de Flujo
Figura 75 Diagrama de Flujo de Caso de Prueba U0007
6243 Script de Pruebas
Para la implementacioacuten de este tipo de casos de prueba se ha hecho uso de la libreriacutea ldquoHtmlTestRunnerrdquo para
obtener un reporte similar al ofrecido por Robot Framework en la ejecucioacuten de la prueba Para obtener un reporte
de la prueba la implementacioacuten de la misma debe seguir una estructura determinada a la que ademaacutes se ha
incluido a traveacutes de la libreriacutea ldquomultiprocessingrdquo la ejecucioacuten simultaacutenea de los dos procesos descritos en el
diagrama de flujo anterior Es necesaria la ejecucioacuten de varios procesos para leer la consola del navegador Web
y obtener los piacutexeles de los Zone Manager para posteriormente hacer doble click
En la Seccioacuten A3 de los anexos puede encontrarse la implementacioacuten del script de pruebas para el caso de
prueba U0007
95
63 Vista de Configuracioacuten (Configuration Tab)
En esta vista se ha automatizado un conjunto de Suites de prueba que validan toda la funcionalidad contenida
en las pestantildeas Groups CHT Zones BackupRestore y Firmware
631 Groups
La pestantildea de grupos permite el descubrimiento de los puntos de acceso a traveacutes de su direccioacuten MAC quedando
estos registrados en base de datos y mostrando al usuario en una tabla los puntos de acceso registrados ademaacutes
del estado de los mismos y otros datos como el modelo o grupo al que pertenecen
Figura 76 Pestantildea ldquoGroupsrdquo
Sobre esta funcionalidad de la plataforma se han realizado un total de 19 casos de prueba de los cuales
detallaremos el caso de prueba identificado con la etiqueta U0119
6311 Criterios de Aceptacioacuten
U0119 Verificar que al descubrir dos puntos de acceso en grupos diferentes ambos son antildeadidos en el
grupo correcto
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Configuracioacuten
3 El usuario puede Navegar a la pestantildea de Grupos
4 El usuario puede descubrir un punto de acceso en el grupo ldquorootrdquo correctamente
5 El usuario puede crear un subgrupo predecesor del grupo ldquorootrdquo correctamente
6 El usuario puede navegar al subgrupo creado correctamente
7 El usuario puede descubrir un punto de acceso en el subgrupo correctamente
96
6312 Diagramas de Flujo
Figura 77 Diagrama de flujo de Caso de Prueba U0119
97
6313 Script de Pruebas
Una vez establecidos los criterios de aceptacioacuten el script de prueba realizado a partir del diagrama de flujo
anterior es el siguiente
Figura 78 Script de Prueba U0119
Entre las keywords implementadas para esta prueba cabe destacar la implementacioacuten de ldquoVerify if AP is
registered Succesfully on grouprdquo la cual permite validar si un punto de acceso ha sido asignado al grupo
correcto
Figura 79 Keyword ldquoVerify if AP is registered Succesfully on grouprdquo
Puede observarse como en primer lugar se obtiene la fila de la tabla que contiene el punto de acceso en cuestioacuten
para posteriormente comprobar si el grupo al que pertenece es el esperado
Observando dicha implementacioacuten cabe destacar el uso de la Keyword ldquoInput Into Text Fieldrdquo la cual ha sido
implementada para vaciar el contenido de campos de texto ya que mediante la Keyword ldquoClear Element Textrdquo
de la libreriacutea Selenium2Library no se conseguiacutea borrar ciertos campos de texto
Figura 80 Keywords Input Into Text Field y Clear Field Of Characters
98
632 CHT Zones
En la pestantildea de gestioacuten de las diferentes Zonas CHT se puede observar una lista de los puntos de acceso
disponibles y se pueden realizar un conjunto de acciones sobre ellos como la creacioacuten eliminacioacuten y asociacioacuten
de zonas CHT
En este punto es conveniente explicar el concepto de zona CHT el cual se refiere a un grupo IP Multicast a
traveacutes del cual un conjunto de Puntos de Acceso establece comunicacioacuten de forma colaborativa Esta
comunicacioacuten es necesaria para el funcionamiento de algunos de los algoritmos que ofrece CHT como por
ejemplo la asignacioacuten automaacutetica de canal (ACA)
Figura 81 Pestantildea ldquoCHT Zonesrdquo
Sobre esta vista se han realizado un total de 6 casos de prueba de los cuales detallaremos el caso de prueba
identificado con la etiqueta U0204 Este caso de prueba permite validar la asignacioacuten de zonas CHT a los Puntos
de Acceso
6321 Criterios de Aceptacioacuten
U0204 Verificar que un usuario puede asignar una Zona CHT a un punto de acceso correctamente
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Configuracioacuten
3 El usuario puede Navegar a la pestantildea de Grupos
4 El usuario puede asignar una Zona CHT existente a un punto de acceso registrado correctamente
99
6322 Diagramas de Flujo
Figura 82 Diagrama de Flujo de Caso de Prueba U0204
6323 Script de Pruebas
Tras presentar los criterios de aceptacioacuten y su correspondiente diagrama de flujo el script de pruebas
implementado para la automatizacioacuten de dicha prueba es el siguiente
Figura 83 Scripts de Prueba U0204
Figura 84 Keyword Add Zone CHT to AP
100
633 BackupRestore
En esta pestantildea se permite la gestioacuten de copias de seguridad y restauracioacuten de los puntos de acceso registrados
en un Zone Manager Se puede observar en esta vista una tabla con los puntos de acceso registrados y otra tabla
con las copias de seguridad realizadas sobre los puntos de acceso
Figura 85 Pestantildea BackupRestore
Partiendo de la representacioacuten funcional de esta vista se han realizado un total de 8 casos de prueba de los
cuales detallaremos el caso de prueba identificado con la etiqueta U0401 el cual permite verificar de forma
automaacutetica la realizacioacuten de un backup sobre un punto de acceso y su posterior restauracioacuten
6331 Criterios de Aceptacioacuten
U0401 Verificar que un usuario puede realizar un BackupRestore correctamente sobre un punto de
acceso previamente registrado
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Configuracioacuten
3 El usuario puede Navegar a la pestantildea de BackupRestore
4 El usuario puede realizar un Backup sobre un punto de acceso existente
5 La tabla de Backups contiene la copia de seguridad realizada
6 El usuario puede restaurar un punto de acceso correctamente
101
6332 Diagramas de Flujo
Figura 86 Diagrama de Flujo de Caso de Prueba U0401
6333 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 87 Script de Prueba U0401
Cabe destacar la implementacioacuten de la Keyword ldquoRestore for AP have done successfullyrdquo la cual verifica que
el punto de acceso ha sido restaurado correctamente esperando que el punto de acceso vuelva a estar en estado
ldquoonlinerdquo durante un tiempo aceptable Si pasado dicho tiempo no recupera dicho estado la prueba se dariacutea por
erroacutenea
Figura 88 Keyword Restore For AP hace done successfully
634 Firmware
Esta uacuteltima pestantildea de la vista principal de configuracioacuten proporciona al usuario la posibilidad de subir los
firmwares de los diferentes modelos de puntos de acceso en sus diferentes versiones del software CHT de forma
que es posible la actualizacioacuten del firmware de los puntos de acceso desde la plataforma Se puede observar en
esta vista una tabla con los puntos de acceso registrados y otra tabla con los firmwares subidos a la plataforma
102
Figura 89 Pestantildea ldquoFirmwarerdquo
Partiendo de la representacioacuten funcional de esta vista se han realizado un total de 7 casos de prueba de los
cuales detallaremos el caso de prueba identificado con la etiqueta U0303 el cual permite verificar de forma
automaacutetica la actualizacioacuten del firmware de un punto de acceso
6341 Criterios de Aceptacioacuten
U0303 Verificar que un usuario puede realizar correctamente la actualizacioacuten del firmware de un punto
de acceso
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Configuracioacuten
3 El usuario puede Navegar a la pestantildea de Firmware
4 El usuario puede subir un firmware correctamente
5 La tabla de Firmwares contiene la imagen de CHT subida a la plataforma
6 El usuario puede realizar la actualizacioacuten del firmware sobre un punto de acceso correctamente
Destacar que el firmware que se desea aplicar sobre un punto de acceso debe ser del modelo correspondiente al
punto de acceso usado ya que cada punto de acceso tiene una imagen de CHT compilada para una arquitectura
hardware determinada Las imaacutegenes son proporcionadas por un servidor interno de la empresa
103
6342 Diagramas de Flujo
Figura 90 Diagrama de Flujo de Caso de Prueba U0303
6343 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 91 Script de Prueba U0303
Cabe destacar la implementacioacuten de la Keyword ldquoFlash APrdquo la cual realiza la actualizacioacuten del firmware de un
punto de acceso verificando que este ha concluido correctamente Para ello espera un tiempo aceptable a que el
punto de acceso vuelva al estado ldquoonlinerdquo
Figura 92 Keyword Flash AP
104
64 Vista de Red (Network Tab)
La uacuteltima vista principal sobre la que se han automatizado pruebas es la vista de Red la cual ofrece al usuario
la gestioacuten y configuracioacuten de su red formada por un conjunto de puntos de acceso previamente registrados
Entre las funcionalidades ofrecidas se encuentran la creacioacuten de VLANS SSIDs Portales Cautivos Perfiles
Radius Activacioacuten de algoritmos CHT y la configuracioacuten de puntos de acceso en tiempo real desde la
plataforma Web
Para describir el proceso de automatizacioacuten se comenzaraacute detallando en primer lugar la creacioacuten de VLANS
Brigdes y SSIDs para posteriormente aplicar dichos paraacutemetros a puntos de acceso desde las pestantildeas ldquoGeneralrdquo
y ldquoAP Networkrdquo Finalmente se mostraraacuten algunos ejemplos sobre otras configuraciones maacutes avanzadas como
la creacioacuten y aplicacioacuten de perfiles radius y portales cautivos ademaacutes de la activacioacuten de algoritmos
641 VLANS amp Bridges
Comenzando con la pestantildea de VLANS amp Bridges se puede observar la existencia de una tabla para cada
elemento de dicha vista
Figura 93 Pestantildea ldquoVLAN amp Bridgesrdquo
Para cada elemento se han automatizado un conjunto de pruebas formado por 6 casos de prueba de los cuales
detallaremos el caso de prueba identificado con la etiqueta U0527 Este caso de prueba permite validar de forma
automaacutetica la creacioacuten y eliminacioacuten de VLANs De forma ideacutentica se procederiacutea para validar la creacioacuten y
eliminacioacuten de Bridges
6411 Criterios de Aceptacioacuten
A continuacioacuten se detallan los criterios de aceptacioacuten del caso de prueba seleccionado
U0527 Verificar que un usuario puede crear y eliminar una VLAN correctamente
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Network
3 El usuario puede Navegar a la pestantildea de VLANS amp Bridges
4 El usuario puede crear una VLAN correctamente
5 El usuario puede eliminar una VLAN correctamente
105
6412 Diagramas de Flujo
Figura 94 Diagrama de Flujo de Caso de Prueba U0527
6413 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 95 Script de Prueba U0527
Cabe destacar la implementacioacuten de la Keyword ldquoGo and Create VLANrdquo la cual permite crear una VLAN en
funcioacuten de los paraacutemetros de entrada deseados para configurar dicha VLAN como por ejemplo el ldquoIDrdquo de la
VLAN y alias o si se desea que dicha VLAN sea de tipo dinaacutemica
Figura 96 Keyword Go And Create VLAN
106
642 SSIDs
Esta pestantildea proporciona una tabla que permite registrar SSIDs con diferentes configuraciones posibles
Figura 97 Pestantildea SSIDs
Para cada funcionalidad de dicha pestantildea se han automatizado un conjunto de pruebas formado por 5 casos de
prueba de los cuales detallaremos el caso de prueba identificado con la etiqueta U0530 Este caso de prueba
permite validar de forma automaacutetica la creacioacuten y eliminacioacuten de SSIDS
6421 Criterios de Aceptacioacuten
A continuacioacuten se detallan los criterios de aceptacioacuten de los dos casos de prueba seleccionados
U0530 Verificar que un usuario puede crear y eliminar una SSID correctamente
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Network
3 El usuario puede Navegar a la pestantildea de SSIDs
4 El usuario puede crear una SSID correctamente
5 El usuario puede eliminar una SSID correctamente
6422 Diagramas de Flujo
Figura 98 Diagrama de Flujo de Caso de Prueba U0530
107
6423 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 99 Script de Prueba U0530
Cabe destacar la implementacioacuten de la Keyword ldquoGo and Create SSIDrdquo la cual permite crear una SSID en
funcioacuten de los paraacutemetros de entradas deseado para configurar dicha SSID como por ejemplo tipo de
encriptacioacuten de la contrasentildea modo oculto o habilitacioacuten de los algoritmos Load Balancing (LB) Smart
roaming (SR) o PRE
Figura 100 Keyword Go And Create SSID
108
643 CHT
Esta funcionalidad permite activar el algoritmo que permite la seleccioacuten automaacutetica de canal entre un conjunto
de puntos de acceso (ACA) Cuando se activa desde la plataforma Web todos los puntos de acceso
pertenecientes a un Zone Manager activan dicho algoritmo el cual se trata de un algoritmo colaborativo
mediante el cual los puntos de acceso acuerdan cual es el mejor canal para la comunicacioacuten WiFi con los clientes
que se conecten tanto en la banda de 24 GHz como en la de 5 GHz En la siguiente figura se muestra la vista
de la plataforma Web para activar el algoritmo en cuestioacuten
Figura 101 Pestantildea ldquoCHTrdquo
Dado que se trata de una funcionalidad en la que solo se debe comprobar si el algoritmo estaacute en el mismo estado
tanto en la plataforma Web como en los puntos de acceso registrados se ha implementado un uacutenico caso de
prueba identificado con la etiqueta U539 Este caso de prueba realiza la conexioacuten a los puntos de acceso para
verificar que dicho algoritmo presenta el mismo estado que en la plataforma
6431 Criterios de Aceptacioacuten
U0537 Verificar que un usuario puede Activar o Desactivar el algoritmo ACA correctamente
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Network
3 El usuario puede Navegar a la pestantildea de CHT
4 El usuario puede ActivarDesactivar el algoritmo ldquoACA ldquocorrectamente
5 Los APs recibieron las oacuterdenes para ActivarDesactivar el algoritmo ldquoACArdquo correctamente
109
6432 Diagramas de Flujo
Figura 102 Diagrama de Flujo de Caso de Prueba U0539
6433 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 103 Script de Prueba U0539
En cuanto a la implementacioacuten de dicho caso de prueba cabe destacar la implementacioacuten de la Keyword ldquoACA
Is Workingrdquo las cual se muestra en la siguiente figura
Figura 104 Keyword ACA Is Working
Puede observarse como en funcioacuten de si el algoritmo ACA esta activado o desactivado en la plataforma Web
(ENABLE DISABLE) se ejecuta la Keyword ldquoChanges On CLIrdquo con diferentes paraacutemetros Esta Keyword
permite la conexioacuten viacutea ldquoSSHrdquo con un punto de acceso para la ejecucioacuten de un comando sobre el mismo y la
posterior comparacioacuten del resultado obtenido por dicho comando con la salida deseada proporcionada tambieacuten
como paraacutemetro de la Keyword
110
En la siguiente figura se muestra la implementacioacuten de dicha Keyword
Figura 105 Keyword Changes On CLI
Para este caso de prueba el comando ejecutado de forma remota sobre el punto de acceso permite obtener de
forma automaacutetica el estado del algoritmo ldquoACArdquo de la siguiente forma
Figura 106 Comando CHT para obtener el estado del moacutedulo ACA en el punto de acceso
644 Radius
Esta pestantildea proporciona una tabla que permite registrar perfiles Radius con diferentes configuraciones posibles
Figura 107 Pestantildea ldquoRadiusrdquo
ldquoRadiusrdquo se define como un protocolo de autenticacioacuten y autorizacioacuten para aplicaciones de acceso a la red o
movilidad IP De esta forma los puntos de acceso mediante la existencia de un servidor radius permiten que los
usuarios que se quieran conectar por WiFi necesiten ser autenticados con credenciales Dicha autenticacioacuten seraacute
redirigida por el punto de acceso al servidor radius el cual autoriza al punto de acceso para que permita la
conexioacuten del cliente
Ademaacutes el uso de este servicio junto con la configuracioacuten mediante VLAN dinaacutemicas permite que diferentes
usuarios accedan al servicio de red con diferentes credenciales de forma que seguacuten el tipo de cliente su traacutefico
viajaraacute por una VLAN u otra Esto permite la separacioacuten del traacutefico a nivel de enlace ofreciendo la posibilidad
de establecer reglas de control de traacutefico y ofrece una QoS miacutenima en funcioacuten del tipo de cliente
Figura 108 Escenario de Funcionamiento de Servidor Radius
111
Para cada funcionalidad de dicha pestantildea se han automatizado un conjunto de pruebas formado por 7 casos de
prueba de los cuales detallaremos el caso de prueba identificado con la etiqueta U0601 Este caso de prueba
permite validar de forma automaacutetica la creacioacuten edicioacuten y borrado de un perfil radius en la plataforma Web
6441 Criterios de Aceptacioacuten
U0601 Verificar que un usuario puede crear editar y borrar un perfil Radius correctamente
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Network
3 El usuario puede Navegar a la pestantildea de Radius
4 El usuario puede Crear un perfil Radius correctamente
5 El usuario puede Editar un perfil Radius correctamente
6 El usuario puede Eliminar un perfil Radius correctamente
6442 Diagramas de Flujo
Figura 109 Diagrama de Flujo de Caso de Prueba U0601
6443 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 110 Script de Prueba U0601
En cuanto a la implementacioacuten de dicho caso de prueba puede destacarse por ejemplo la implementacioacuten de
la Keyword ldquoCreate Radius Profilerdquo la cual permite crear un perfil ldquoRadiusrdquo a partir de un conjunto de
paraacutemetros de entrada
112
Figura 111 Keyword Create Radius Profile
645 Captive Portal
Esta pestantildea proporciona una tabla que permite registrar perfiles de Portales Cautivos con diferentes
configuraciones posibles
Figura 112 Pestantildea Captive Portals
Un portal cautivo es un servicio que permite el control del traacutefico HTTP y fuerza a los usuarios de una red a la
autenticacioacuten mediante una paacutegina Web para tener acceso a Internet Dicho portal permite controlar paraacutemetros
como el tiempo de conexioacuten de un cliente a la red ancho de banda ofrecido a cada cliente etc
Figura 113 Escenario de Funcionamiento de un Portal Cautivo
Para cada funcionalidad de dicha pestantildea se han automatizado un conjunto de pruebas formado por 5 casos de
prueba de los cuales detallaremos el caso de prueba identificado con la etiqueta U0701 Este caso de prueba
permite validar de forma automaacutetica la creacioacuten edicioacuten y borrado de un perfil de portal cautivo en la plataforma
Web
113
6451 Criterios de Aceptacioacuten
U0701 Verificar que un usuario puede crear editar y borrar un perfil de Portal Cautivo correctamente
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Network
3 El usuario puede Navegar a la pestantildea de Captive Portals
4 El usuario puede Crear un perfil de Portal Cautivo correctamente
5 El usuario puede Editar un perfil de Portal Cautivo correctamente
6 El usuario puede Eliminar un perfil de Portal Cautivo correctamente
6452 Diagramas de Flujo
Figura 114 Diagrama de Flujo de Caso de Prueba U0701
6453 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 115 Script de Prueba U0701
114
En cuanto a la implementacioacuten de dicho caso de prueba puede destacarse por ejemplo la implementacioacuten de
la Keyword ldquoEdit or delete Captive Portal Profilerdquo la cual permite editar o eliminar un perfil de Portal Cautivo
a partir de un conjunto de paraacutemetros de entrada
Figura 116 Keyword Edit or Delete Captive Portal Profile
115
646 General
Esta pestantildea muestra la vista general de la pestantildea ldquoNetworkrdquo En esta pestantildea se agrupa el conjunto de puntos
de acceso actualmente registrados en el Zone Manager con un resumen de su configuracioacuten de red actual el
estado en el que se encuentran y nuacutemero de clientes conectados Ademaacutes dicha vista proporciona un acceso
directo a la pestantildea ldquoAP Networkrdquo seleccionando uno o varios puntos de acceso de un mismo modelo En la
siguiente seccioacuten se explica la funcionalidad de dicha pestantildea
Figura 117 Pestantildea General
Para cada elemento se han automatizado un conjunto de pruebas formado por 9 casos de prueba de los cuales
detallaremos el caso de prueba identificado con la etiqueta U0522 Este caso de prueba se permite validar de
forma automaacutetica la conexioacuten de clientes a un punto de acceso con una SSID asignada de forma que el nuacutemero
de clientes conectados que se muestra en la plataforma Web sea correcto
6461 Criterios de Aceptacioacuten
U0522 Conectar clientes y verificar que el nuacutemero de clientes conectados es correcto
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Network
3 El usuario puede Navegar a la pestantildea General
4 El usuario tiene disponible un punto de acceso en el Zone Manager con una SSID asignada
5 El usuario conecta un cliente al punto de acceso por WiFi a la SSID asignada
6 El usuario verifica que el nuacutemero de clientes conectados incrementa en una unidad
116
6462 Diagramas de Flujo
Figura 118 Diagrama de Flujo de Caso de Prueba U0522
6463 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de prueba automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 119 Script de Prueba U0522
En cuanto a la implementacioacuten de dicho caso de prueba puede destacarse por ejemplo la implementacioacuten de
la Keyword ldquoCheck Number of Clients Increasesrdquo la cual permite comprobar que el nuacutemero de clientes conectados incrementa al conectar un cliente a un punto de acceso
Figura 120 Keyword Check Number of Clients Increases
117
647 AP Network
Esta pestantildea muestra la vista principal de la pestantildea ldquoAP Networkrdquo La funcionalidad que proporciona engloba
todos los posibles paraacutemetros de configuracioacuten para un punto de acceso que ha sido seleccionado previamente
desde la pestantildea General Cualquier configuracioacuten aplicada sobre esta vista seraacute enviada al punto de acceso
desde la plataforma Web permitiendo configurar los puntos de acceso de Galgus
Desde el punto de vista de la plataforma Web esta vista abarca un conjunto de funcionalidades consideradas
como maacutes complejas que se ofrecen en la plataforma Web por lo que es en esta vista donde puede encontrarse
una de las mayores aacutereas de riesgo de la plataforma Entre las funcionalidades que se ofrecen estaacuten la
configuracioacuten de las radios de un punto de acceso (Potencia Ancho de banda Canal etc) asignacioacuten de SSIDs
a las interfaces inalaacutembricas y configuracioacuten de reglas de control de traacutefico (TC Rules) asignacioacuten de puertos a
las diferentes subredes virtuales de aacuterea local (VLANS) o configuracioacuten de Portal Cautivo
Figura 121 Pestantildea AP Network
Para cada elemento se han automatizado un conjunto de pruebas formado por 28 casos de prueba los cuales la
mayoriacutea han requerido un amplio esfuerzo de implementacioacuten para conseguir su automatizacioacuten ya que son
pruebas cuya secuencia de acciones es larga ademaacutes de requerir en muchas ocasiones la verificacioacuten de la
configuracioacuten en los puntos de acceso viacutea ldquosshrdquo Para ello se ha hecho uso entre otras de la libreriacutea
ldquoSSHLibraryrdquo proporcionada por Robot Framework
Figura 122 Libreriacutea SSH para Robot Framework
118
Del conjunto de casos de prueba que validan la funcionalidad de dicha pestantildea se va a detallar el caso de prueba
identificado con la etiqueta U0511 Este caso de prueba permite validar de forma automaacutetica que se pueden
aplicar reglas de control de traacutefico ldquoTCsrdquo a una SSID asignada a las interfaces inalaacutembricas de un punto de
acceso desde la plataforma Web
Figura 123 Ventana de Configuracioacuten de TC Rules
6471 Criterios de Aceptacioacuten
U0511 Asignar ldquoTC Rulesrdquo a una SSID asociada a un Punto de Acceso correctamente
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Network
3 El usuario puede Navegar a la pestantildea General
4 El usuario tiene disponible un punto de acceso en el Zone Manager
5 El usuario puede seleccionar un punto de acceso
6 El usuario puede Navegar a la pestantildea AP Network para el punto de acceso seleccionado
7 El usuario puede asignar a las interfaces inalaacutembricas una SSID existente y crear ldquoTC Rulesrdquo sobre
esa SSID
8 El usuario puede aplicar la configuracioacuten
9 El punto de acceso aplica su configuracioacuten correctamente
10 El punto de acceso pasa al estado ldquoOnlinerdquo en la plataforma Web y su configuracioacuten estaacute alineada
119
6472 Diagramas de Flujo
Figura 124 Diagrama de Flujo de Caso de Prueba U0511
120
6473 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 125 Script de Prueba U0511
En cuanto a la implementacioacuten de dicho caso de prueba puede destacarse por ejemplo la implementacioacuten de
la Keyword ldquoWait Timerrdquo la cual permite verificar que no se produce ninguacuten error al aplicar una configuracioacuten
determinada desde la plataforma Web durante un tiempo determinado
Figura 126 Keyword Wait Timer
Destacar tambieacuten la implementacioacuten de la Keyword ldquoCheck On CLIrdquo la cual permite contrastar que la
configuracioacuten aplicada desde la plataforma sobre un punto de acceso es la esperada En este caso se comprueba
que las ldquoTC Rulesrdquo han sido correctamente aplicadas para una SSID determinada en un punto de acceso de
forma remota mediante el uso de la libreriacutea ldquoSSHrdquo para Robot Framework
Figura 127 Keyword Check On CLI
121
122
7 LINEAS DE MEJORA Y CONCLUSIONES
n este uacuteltimo capiacutetulo se analizaraacuten resultados y conclusiones obtenidas sobre el uso de pruebas
automatizadas para la verificacioacuten y validacioacuten de una plataforma Web como la de Galgus Se
detallaraacuten algunas ventajas e inconvenientes encontrados y se plantearaacuten algunas liacuteneas de mejora
futuras sobre el proyecto desarrollado Con estas mejoras se busca como objetivo enriquecer el proceso de
automatizacioacuten de pruebas ademaacutes de hacerlo maacutes efectivo y metoacutedico en todos sus aspectos ya que siempre
hay algo que se puede mejorar para conseguir una herramienta maacutes completa y uacutetil
Se detallaraacuten tambieacuten aspectos de aprendizaje opiniones experiencias y en definitiva todas las conclusiones
sacadas sobre este proyecto incluyendo tambieacuten las dificultades encontradas para el desarrollo del mismo
71 Liacuteneas de Mejora Futuras
El estudio y puesta en marcha de este Proyecto de automatizacioacuten de pruebas de Software ha hecho uso de una
amplia cantidad de herramientas ofrecido por Selenium y Robot Framework ademaacutes de otras herramientas que
han permitido enriquecer el mismo con mayores funcionalidades ofrecidas al equipo de Proyecto Si bien se ha
logrado conseguir un paquete de pruebas con una capacidad de detectar defectos en un producto Web existen
diversas ampliaciones de dicho Proyecto que podriacutean aumentar de manera considerable el desempentildeo de las
herramientas de automatizacioacuten a lo largo del ciclo de vida del proyecto
A continuacioacuten se muestran algunas de las maacutes importantes
bull Uso de Integracioacuten Continua Robot Framework es faacutecilmente integrable principalmente con Jenkins
aunque tambieacuten ofrece la posibilidad de integrarlo con Gitlab CICD Esto permitiriacutea programar la
ejecucioacuten de pruebas automaacuteticamente para diferentes versiones del proyecto Galgus CHT Cloud
Manager o en diferentes fases del mismo Con esta caracteriacutestica se detectariacutean con mayor facilidad los
problemas relacionados con la configuracioacuten del entorno de trabajo y se podriacutea notificar por email a
los responsables de equipo ante los eventuales incidentes encontrados De este modo no seriacutea necesario
estar supervisando el proceso de ejecucioacuten para estar al tanto de un fallo en el sistema En este aspecto
se ha trabajado para conseguir estos objetivos con la creacioacuten de un Docker de Robot Framework que
permita la ejecucioacuten de las pruebas en el mismo para poder usarla en el entorno de integracioacuten continua
correspondiente Tambieacuten se ha implementado un primer un script que permita la ejecucioacuten de paquetes
de pruebas en dicho entorno
bull Selenium Grid El caso praacutectico descrito tiene un inconveniente y es que solo hace uso de Chrome
Suele ser frecuente que ciertos defectos en una aplicacioacuten Web solo aparezcan en determinados
navegadores Con herramientas como Selenium Grid permitiriacutean la ejecucioacuten en paralelo de las pruebas
en maacutequinas con diferentes sistemas operativos y navegadores Asiacute se podriacutea evaluar de manera
independiente la compatibilidad del producto en entornos multiplataforma Ademaacutes esta herramienta
es totalmente compatible con Jenkins o Gitlab CICD con las ventajas que esto supone
bull Headless browser Esto hace referencia al uso de navegadores sin interfaz graacutefica de usuario La mayor
parte del tiempo durante una ejecucioacuten es destinada a esperar a que el navegador renderice el contenido
Si se elimina este factor de la foacutermula y se accede directamente al DOM de la Web se consigue una
reduccioacuten en el tiempo de ejecucioacuten de las pruebas Durante el desarrollo de este proyecto se ha
trabajado en este aspecto ofrecieacutendose la posibilidad de ejecutar las pruebas en dos entornos diferentes
una primera de depuracioacuten de pruebas que realiza el renderizado del navegador y otra opcioacuten que
E
La tecnologiacutea por siacute sola no basta Tambieacuten tenemos que poner el corazoacuten
Jane Goodall
123
permite la ejecucioacuten de pruebas sin renderizado del navegador (Modo Headless)
bull Buenas praacutecticas en la localizacioacuten de elementos en el DOM de la Web La aplicacioacuten de este tipo
de buenas praacutecticas permitiriacutean una mejor y maacutes eficiente localizacioacuten de los elementos en el DOM
reduciendo la posibilidad de que las pruebas generen falsos errores Esto es lo que ha causado la mayor
parte de los problemas de implementacioacuten y ejecucioacuten de las pruebas automaacuteticas Actualmente la
herramienta de automatizacioacuten de pruebas se encuentra en un proceso de mejora continua en el que se
estaacute abordando una refactorizacioacuten para la aplicacioacuten de estas buenas praacutecticas Para ello se estaacuten
haciendo uso de selectores avanzados basados en rutas (Xpaths) relativas en el DOM de la Web las
cuales realizan la mayoriacutea de las buacutesquedas por contenido y no por ruta absoluta como se veniacutea
haciendo hasta ahora
bull Aplicacioacuten de Model Based Testing (MBT) Como estudio del arte se ha presentado una teacutecnica que
permite dar un paso maacutes en la automatizacioacuten de pruebas Como se ha detallado en el proyecto esta
teacutecnica permite ascender en el nivel de abstraccioacuten de las pruebas basando las mismas en el disentildeo y
modelado de la aplicacioacuten Dicha teacutecnica se encuentra principalmente en proceso de investigacioacuten lo
cual hace difiacutecil aplicarla aunque seriacutea de gran intereacutes conseguir su implantacioacuten
72 Conclusiones Finales
En el desarrollo del presente Proyecto se ha analizado una pequentildea extensioacuten del inmenso mundo de la gestioacuten
de calidad Esta ha ido tomando fuerza con el paso de los antildeos en el mercado actual introducieacutendose en todos
los aacutembitos incluido en el software La gestioacuten de calidad se ha profesionalizado de tal forma que el papel del
ingeniero de calidad en los proyectos de software es imprescindible en cualquier empresa que quiera hacerse un
hueco en el mercado como garantiacutea de calidad
La elevada exigencia del mercado del software provocada por la gran demanda de clientes y usuarios finales
para recibir un producto en el menor tiempo posible hace que en muchos casos las empresas centren su esfuerzo
en sacar un producto lo antes posible reduciendo los esfuerzos destinados a los procesos de calidad de dicho
producto software Originalmente las pruebas de software realizadas sobre un producto se realizaban de forma
manual por un ingeniero de calidad pero con el avance de las tecnologiacuteas la automatizacioacuten de las mismas
supone un elevado esfuerzo inicial pero una reduccioacuten de los mismos a medio plazo
En este proyecto se ha desarrollado una herramienta que permite la automatizacioacuten de pruebas funcionales sobre
una plataforma Web concretamente pruebas de aceptacioacuten sobre Galgus CHT Cloud Manager Las pruebas de
automatizacioacuten elaboradas reflejan que existen tecnologiacuteas muy asequibles en teacuterminos de coste compatibilidad
y facilidad de uso para iniciarse en el mundo de las pruebas funcionales de sistemas Algo muy presente en el
mundo laboral actual es la creciente demanda de expertos en automatizacioacuten en todas las principales
plataformas Web Moacutevil y Escritorio Muchos de estos profesionales vienen del mundo del testing manual por
lo que conociendo ya la nomenclatura y el funcionamiento de los procesos de calidad solo necesitan dar el paso
hacia el uso de este tipo de herramientas Sea con Selenium o con cualquier otra herramienta los conceptos
teoacutericos presentados en este proyecto son igualmente vaacutelidos
Por otra parte debe destacarse la dificultad encontrada a la hora de establecer unos criterios de aceptacioacuten de las
funcionalidades de la plataforma Web bajo pruebas Esto se debe al desarrollo de una herramienta de
automatizacioacuten de pruebas que se ha iniciado en una fase avanzada del desarrollo del proyecto con lo cual en
muchas ocasiones surgiacutean dudas sobre el disentildeo del proyecto Adicionalmente la propia estructura y tecnologiacuteas
usadas en la Web dificultaron al inicio la localizacioacuten de elementos A esta causa de une tambieacuten la ausencia de
identificadores uacutenicos en los elementos que componen la misma Esto se tradujo en el uso de selectores basados
en la ruta del elemento pudiendo acarrear la aparicioacuten de posibles falsos errores debidos a cambios en el coacutedigo
fuente de la plataforma Web La solucioacuten adoptada para tal problema no fue maacutes que analizar meticulosamente
aquellas ejecuciones fallidas para descartar errores reales y en caso de que sean debidas a los selectores aplicar
la debida actualizacioacuten de los mismos
En este uacuteltimo aspecto cabe destacar que el proyecto de automatizacioacuten de pruebas se encuentra actualmente
en una fase de mejora continua en la que se estaacuten adoptando teacutecnicas basadas en el uso de selectores avanzados
basados en rutas relativas y nombres que permitan reducir el impacto del problema presentado en este punto
124
A modo de resumen se plantean algunas ventajas en el uso de SeleniumRobot Framework para la
automatizacioacuten de pruebas
Facilidad de configuracioacuten y uso Su instalacioacuten requiere un esfuerzo miacutenimo y el poder de
abstraccioacuten ofrecido por Robot Framework hace posible la lectura y entendimiento de los paquetes de
pruebas y reportes a todos los miembros del equipo
Cantidad de documentacioacuten disponible La comunidad respalda ambos proyectos y es por ello que
encontramos soluciones de todo tipo adaptadas a las necesidades de cada uno
Soporte para la mayoriacutea de navegadores con el mismo script Ejecutar el script de pruebas
desarrollado para su automatizacioacuten en otro navegador requiere simplemente la instalacioacuten del
controlador deseado y usar un determinado paraacutemetro para indicar el uso de dicho controlador en la
llamada de la Keyword encargada de la apertura del navegador
De la misma forma se pueden destacar algunas desventajas
Selenium soacutelo es compatible con productos Web Cualquier software moacutevil o de escritorio requiere
del uso de otros frameworks o herramientas lo cual puede ser un punto negativo para empresas que
tengan productos multiplataforma Sin embargo Robot Framework si proporciona soporte
multiplataforma con la integracioacuten de otras herramientas o framework para su desarrollo
Tecnologiacuteas no optimizadas para pruebas de rendimiento En este punto cabe destacar el esfuerzo
de la comunidad para desarrollar herramientas que permitan la automatizacioacuten de este tipo de pruebas
con Robot Framework como por ejemplo ldquorfswarmrdquo
Compatibilidad de versiones de paquetes de Software Es frecuente usar determinadas
combinaciones de versiones de paquetes para lograr un framework estable y robusto Esto a veces puede
convertirse en una tarea tediosa donde cuestan encajar piezas Por suerte es algo que se estaacute teniendo
en cuenta con las uacuteltimas versiones de Selenium
Puede concluirse que durante el desarrollo de este proyecto se ha conseguido la creacioacuten de una herramienta
sencilla de usar y entender para la automatizacioacuten de pruebas funcionales sobre una plataforma Web ademaacutes
de preparar dicha herramienta para integrarla en el proceso de integracioacuten continua implantado para dicha
aplicacioacuten Web con Gitlab mediante Docker Ademaacutes se ha realizar un estudio del arte de una teacutecnica conocida
bajo el nombre de Model Based Testing (MBT) que permitiriacutea mejorar el proceso de automatizacioacuten y la
herramienta desarrollada para tal fin
Con todo ello he aprendido multitud de conceptos tecnologiacuteas y herramienta que hasta ahora desconociacutea cuaacutel
era su finalidad o funcionamiento como por ejemplo Robot Framework Para ello he necesitado gran cantidad
de formacioacuten previa antes de comenzar a ponerlo en praacutectica para el desarrollo de la herramienta de
automatizacioacuten
Son muchos los errores cometidos hasta conseguir los objetivos y metas propuestas los cuales creo que son los
sucesos maacutes importantes pues de ellos se aprende y son los que nos hacen avanzar cuando los resolvemos
Finalmente destacar que este proyecto me ha dado la oportunidad de abrir mi conocimiento en un campo de las
tecnologiacuteas de la informacioacuten el cual resulta de intereacutes Dar las Gracias a mis tutores Pablo Aguilera Bonet y
Daniel Gutieacuterrez Reina ademaacutes de mi responsable en Galgus Joseacute Antonio Delgado Alfonso por brindarme
esta oportunidad ademaacutes de ayudarme y asesorarme estando siempre disponible y con dedicacioacuten hacia este
proyecto para que haya podido llevarse a cabo
125
126
REFERENCIAS
[1] M Utting Bruno Legeard Practical Model-based Testing sl Elsevier 2007
[2] Ibrahim K El-Far Enjoying the perks of model-based testing In Proceedings of the Software Testing
Analysis and Review Conference
[3] A C Dias Neto Rajesh Subramanyan Marlon Vieirab Characterization of Model-based Software
[4] Model-based Testing Next Generation Functional Software Testing Legeard Bruno Dagstuhl Seminar
Proceedings 10111 Vol httpdropsdagstuhldeopusvolltexte20102620
[5] Perspectives of Model-Based Testing Ed Brinksma Wolfgang Grieskamp and Jan Tretmans IBFI
Schloss Dagstuhl Germany sn 2005 Dagstuhl Seminar Proceedings
[6] Definicioacuten de Calidad httpsdleraeesid=6nVpk8P|6nXVL1Z
[7] Modelos de calidad del software httpswwwresearchgatenetpublication316674475
[8] Calidad del Software ldquoEl camino al exitordquo LI Alma Delia Chaacutevez Rojas
[9] IEEE Software Engineering Book of Knowledge IEEE sl IEEE 2004
[10] Principios de pruebas software httpsmediumcomatejedaccsprincipios-del-testing-722323e16e76
[11] httpwwwsstqbesw3docsGLOSARIO_V00110pdf
[12] httpsepdfpubsoftware-testing-an-istqb-iseb-foundation-guidehtml
[14] IEEE standard glossary of software engineering terminology F Jay RMayer 1990 paacuteg IEEE Std 610
[15] Openwrt httpsopenwrtorgsupported_devices
[16] RabbitMQ httpswwwrabbitmqcom
[17] Zero Touch Provisioning httpssearchdatacentertechtargetcomesdefinicionAprovisionamiento-de-
cero-toque-ZTP-o-zero-touch-provisioning
[18] Robot Framework User Guide
httpsrobotframeworkorgrobotframeworklatestRobotFrameworkUserGuidehtml
[19] Gitlab httpsdocsgitlabcom
[20] httpswwwfederico-toledocomcuando-automatizar-una-prueba
127
128
ANEXO A PREPARACIOacuteN DEL ENTORNO DE
TRABAJO Y EJECUCIOacuteN DE PRUEBAS
A1 Preparacioacuten del entorno de trabajo
Para el desarrollo de las preubas automaacuteticas se ha hecho uso del sistema operative Linux con la distribucioacuten
Ubuntu El motivo de su uso es el amplio abanico de herramientas de coacutedigo libre que existen para esta
distribucioacuten asiacute como la enorme contribucioacuten que hace la comunidad de usuarios para mejorarla Sobre este
sistema operativo se ha hecho uso de un conjunto de herramientas para el montaje de un entorno de pruebas
automatizado basado en Python A continuacioacuten se detallaraacuten dichas herramientas
A11 Pip
Pip es un sistema de gestioacuten de paquetes que se utiliza para la instalacioacuten de los paquetes software
implementados en Python que se usaraacuten posteriormente La instalacioacuten de un paquete se realiza mediante la
ejecucioacuten del siguiente comando
A12 Virtualenv Entorno Virtual
Dado que cada proyecto basado en Python puede requerir la instalacioacuten de diferentes conjuntos de paquetes es
comuacuten usar la creacioacuten de entornos virtuales que nos permitan administrar cada proyecto de manera
independiente pudiendo tener otros proyectos haciendo uso de los mismos paquetes con otras versiones La
instalacioacuten se realiza mediante la herramienta ldquoPiprdquo a traveacutes del siguiente comando
Una vez instalado se puede crear un entorno virtual asociado a un proyecto de la siguiente forma
En este punto se creariacutea un entorno virtual para el proyecto deseado Ahora solo quedariacutea activarlo o iniciarlo
pip install nombre-del-paquete
pip install virtualenv
cd carpeta-del-proyecto
virtualenv ndashp usrbinpython27 mi-proyecto
source mi-proyectobinactivate
129
A13 Selenium y Chromedriver
La instalacioacuten de Selenium se realiza de la misma forma que el resto de paquetes con la herramienta ldquoPiprdquo
Por otra parte el controlador para el navegador Chrome Chromedriver puede ser descargado desde el
repositorio oficial httpschromedriverchromiumorg Ademaacutes Chromedriver debe ser accessible para
Selenium de cara a configurar el PATH
A14 Robot Framework y SeleniumLibrary
A continuacioacuten se realizariacutea la instalacioacuten de Robot Framework
Posteriormente se realizariacutea la instalacioacuten del paquete ldquoSelenium2Libraryrdquo el cual contiene la implementacioacuten
en python de las libreriacuteas necesarias para utilizar Robot Framework en Python
Llegados a este punto listando todos los paquetes instalados se deberiacutea tener algo similar a la siguiente figura
Con esta configuracioacuten del entorno este estariacutea preparado para elaborar los casos de prueba automatizados con
Robot Framework y Selenium
pip install selenium
export PATH=$PATHabsolute_path_of_chromedriver_file
pip install robotframework
pip install robotframework-selenium2library
130
A15 Otras dependencias
Para el desarrollo de pruebas que requieren otro tipo de herramientas como la transferencia de ficheros con el
servicio ldquoSCPrdquo o la conexioacuten remota a traveacutes del servicio ldquoSSHrdquo se require la instalacioacuten de los siguientes
paquetes
Ademaacutes para la realizacioacuten de pruebas avanzadas en Python para la gestioacuten del Mapa de la platform Web CHT
Cloud Manager se ha hecho uso de la librariacutea ldquohtml-testRunnerrdquo para ofrecer un reporte de la ejecucioacuten de
pruebas muy similar al ofrecido por Robot Framework
A2 Ejecucioacuten de Pruebas
Tras la implementacioacuten de las pruebas siguiendo el procedimiento indicado en la seccioacuten de Experimentos
ejecutar un script de pruebas se realiza mediante el uso del siguiente comando
Mediante el uso de la variable ldquoENVIROMENTrdquo puede seleccionarse el entorno en el que se desea ejecutar las
pruebas Con el entorno de ldquodebugrdquo las pruebas se ejecutariacutean de forma graacutefica mientras que el el entorno de
ldquodockerrdquo permite la ejecucioacuten de pruebas sin interfaz graacutefica Este uacuteltimo entorno seriacutea usado para la ejecucioacuten
de pruebas con el docker de Robot Framework que se ha implementado el cual se detallaraacute maacutes adelante
Por otro lado existen otras opciones para el comando anterio como por ejemplo
Las opciones ldquo-irdquo y ldquo-erdquo permiten ejecutar o excluir un caso de preuba en la ejecucioacuten de una Suite de pruebas
Por otro lado el uacuteltimo comando permite lanzar la ejcucioacuten de una Suite de pruebas y ejecutar soacutelo aquellos
casos de prueba que hayan fallado en la ejecucioacuten anterior
pip install robotframework-sshlibrary
pip install robotframework-scplibrary
pip install html-testRunner
robot --variable ENVIROMENTdebug_or_docker suite_filerobot
robot --variable ENVIROMENTdebug_or_docker ndashi U0000 suite_filerobot
robot --variable ENVIROMENTdebug_or_docker ndashe U0000 suite_filerobot
robot --rerunfailed outrerunfailedxml --output out2xml suite_filerobot
131
A continuacioacuten se muestra un ejemplo de ejecucioacuten de pruebas con Robot Framwork
132
A3 Script de Prueba U007 (MAP)
from selenium import webdriver
from seleniumwebdrivercommonby import By
from seleniumwebdriversupportui import WebDriverWait
from seleniumwebdriversupport import expected_conditions as EC
from seleniumwebdrivercommondesired_capabilities import DesiredCapabilities
from seleniumwebdrivercommonaction_chains import ActionChains
from seleniumcommonexceptions import TimeoutException
import math json multiprocessing time re
import sys
import unittest
import HtmlTestRunner
U0007 Double-click on Zone Manager and look if the Backend tab opens
class DClickZM(unittestTestCase)
driver = 0
canvas = 0
waitTime = 20
username = franciscodiaz
password = ahipeo8829g
classmethodg
def setUp(cls)
Enviroment Management
chrome_options = webdriverChromeOptions()
if sysargv[2] == docker
chrome_optionsadd_argument(--headless)
chrome_optionsadd_argument(--disable-extensions)
chrome_optionsadd_argument(--disable-gpu)
chrome_optionsadd_argument(--no-sandbox)
enable browser logging
d = DesiredCapabilitiesCHROME
d[loggingPrefs] = browser DEBUG
clsdriver = webdriverChrome(chrome_options=chrome_options desired_capabilities=d)
clsdrivermaximize_window()
clsdriverset_window_size(1920 1080)
load the desired webpage
clsdriverget(httpdevcloudgalgusnet)
def test_double_click_ZM(self)
loggin in the page
userNameBox = WebDriverWait(selfdriver 1)until(
ECpresence_of_element_located((ByXPATH [id=username])))
userNameBoxsend_keys(selfusername)
passwordBox = WebDriverWait(selfdriver selfwaitTime)until(
ECpresence_of_element_located((ByXPATH [id=password])))
passwordBoxsend_keys(selfpassword)
133
loginButton = WebDriverWait(selfdriver selfwaitTime)until(
ECpresence_of_element_located((ByXPATH
[id=myModalLabel]divdivformdiv[3]input)))
loginButtonclick() Tab General appears
selfcanvas = WebDriverWait(selfdriver selfwaitTime)
until(ECpresence_of_element_located((ByXPATH
htmlbodyappdivmaindivregister-
managersdivtabsetdivtab[1]aol-mapdivdivcanvas)))
timesleep(15)
action = ActionChains(selfdriver)
Manage Process
manager = multiprocessingManager()
return_dict = managerdict()
We create a Process
p_get_pixels_zm = multiprocessingProcess(target=selfGet_Pixels_ZM args=(return_dict selfdriver))
We create another Process
p_double_click_on_zm = multiprocessingProcess(target=selfDouble_Click_On_ZM args=(return_dict selfcanvas
action selfdriver))
We start the process and we block for 5 seconds
p_get_pixels_zmstart()
p_get_pixels_zmjoin(timeout=10)
p_double_click_on_zmstart()
p_double_click_on_zmjoin(timeout=10)
We terminate the process
p_get_pixels_zmterminate()
p_double_click_on_zmterminate()
try
Tab General appears
WebDriverWait(selfdriver 20)until(ECpresence_of_element_located(
(ByXPATH [id=app-sections]networktabsetulli[1]a)))
except TimeoutException
raise Exception(Cant Login in Zone Manager)
classmethod
def tearDown(cls)
clsdriverquit()
staticmethod
def Get_Pixels_ZM(return_dict driver)
return_dict[0] = 0
return_dict[1] = 0
regex = r(lt=c[-gt]cs)[wW]+(=)
while True
for entry in driverget_log(browser)
message = entry[message]
matches = refinditer(regex message reMULTILINE)
134
for matchNum match in enumerate(matches start=1)
try
p = matchgroup()replace( )
my_json = jsonloads(p)
if my_json[ZM] == Hotel MampM
return_dict[0] = my_json[top]
return_dict[1] = my_json[left]
break
except
pass
if return_dict[0] = 0 and return_dict[1] = 0
break
staticmethod
def Double_Click_On_ZM(return_dict canvasaction driver)
width = int(mathceil(float(return_dict[0])))
height = int(mathceil(float(return_dict[1])))
actionmove_to_element_with_offset(canvas width height)
actiondouble_click()
actionperform()
actiondouble_click()
actionperform()
driversave_screenshot(screenshot1png)
timesleep(5)
if __name__ == __main__
unittestmain(testRunner=HtmlTestRunnerHTMLTestRunner())
135
136
ANEXO B DOCKER DE ROBOT FRAMEWORK Y
ENTORNO DE UAT DOCKERIZADO
B1 Docker de Robot Framework
Para el entorno de UAT que se va a desarrollar se ha hecho uso de diferentes contenedores que han sido creados
por el equipo de desarrollo donde cada contenedor aloja un microservicio diferente de la plataforma
Para crear cada contenedor se ha hecho uso de Docker Esta herramienta permite crear contenedores ligeros y
portables para diferentes servicios que puedan ejecutarse en cualquier maacutequina con Docker instalado
independientemente del sistema operativo de la maacutequina que lo ejecute facilitando asi los despliegues
Mediante un fichero llamado ldquoDockerfilerdquo se definen los siguientes contenedores de servicios entre los cuales
se destacaraacute el fichero que define la creacioacuten del docker de Robot Framework el cual ha sido desarrollado por
el autor de este proyecto
Este contenedor ha sido creado sobre una imagen de Docker con el inteacuterprete de Python instalado Partiendo de
137
esta imagen se realiza la instalacioacuten de Robot Framework y las diferentes libreriacuteas y herramientas que se usaraacuten
en el proyecto para poder lanzar los Tests End-to-End
Ademaacutes se realiza la instalacioacuten de Google Chrome y Mozilla Firefox y la descarga de Chromedriver y
Geckodriver para poder lanzar los tests con dichos navegadores en modo headless Para el lanzamiento de los
test en modo headless se haraacute uso de la variable de entorno ldquoENVIROMENTrdquo definida en el anexo anterior
Finalmente se antildeade el proyecto de pruebas desarrollado para tener disponible las pruebas aumaacuteticas en el
contenedor
B2 Entorno de UAT Dockerizado
Para automatizar el despliegue de la plataforma Galgus CHT Cloud Manager con Docker se ha hecho uso de la
herramienta ldquodocker-composerdquo Esta herramienta permite simplificar el uso de Docker generando scripts que
facilitan el disentildeo y la construccion de servicios Con Docker Compose se pueden crear diferentes contenedores
y al mismo tiempo en cada contenedor diferentes servicios En la siguientefigura se muestra el fichero que
define el entorno de UAT con docker-compose
138
139
140
ANEXO C REVISIOacuteN DE REPORTES Y LOGS
C1 Reporte de Logs ofrecido por Robot Framework
Selenium no teniacutea la capacidad nativa de generar informes Este es uno de los motivos por el que se decidioacute
utilizar Robot Framework
Robot Framework genera tres archivos tras la ejecucioacuten de los scripts de pruebas A partir de la informacioacuten
contenida en el fichero ldquooutputxmlrdquo se rellenan las plantillas ldquohtmlrdquo del ldquologrdquo y del reporte El reporte permite
aplicar filtros a los resultados mientras que el ldquologrdquo contiene todos los detalles de la ejecucioacuten
A continuacioacuten se adjuntan las capturas de logs generados por los diferentes paquetes de pruebas desarrollados
C2 Cloud Tab
C21 Administration
141
142
C22 List
143
C23 Manufacturers
144
C24 MAP
145
C3 Configuration Tab
C31 BackupRestore
146
C32 CHT Zones
147
C33 Firmware
148
C34 Groups
149
150
C4 Network Tab
C41 General
151
C42 SSID
C43 CHT
152
C44 VLAN
153
C45 Radius
154
C46 Captive Portal
155
C47 AP Network
156
Como se ha visto reflejado en el conjunto de logs el tiempo total invertido en la ejecucioacuten ha sido de 1 hora 20
minutos y 22 segundos Dichas pruebas realizadas por una persona de forma manual hubiesen requerido como
miacutenimo el doble de tiempo Ya ni mencionar si se aplicase concurrencia en la ejecucioacuten de pruebas
157
ANEXO D DIAGRAMA DE GANTT
3
Trabajo de Fin de Maacutester
Maacutester en Ingenieriacutea de Telecomunicacioacuten
Testeo automatizado de una plataforma Web de
gestioacuten Galgus CHT Manager
Autor
Francisco Joseacute Diacuteaz Romero
Tutores
Pablo Aguilera Bonet
Daniel Gutieacuterrez Reina
Doctor Ingeniero en Electroacutenica
Escuela Teacutecnica Superior de Ingenieriacutea
Universidad de Sevilla
Sevilla 2020
4
5
Trabajo de Fin de Maacutester Testeo automatizado de una plataforma Web de gestioacuten
Galgus CHT Manager
Autor Francisco Joseacute Diacuteaz Romero
Tutor Pablo Aguilera Bonet
Daniel Gutieacuterrez Reina
El tribunal nombrado para juzgar el Proyecto arriba indicado compuesto por los siguientes miembros
Presidente
Vocales
Secretario
Acuerdan otorgarle la calificacioacuten de
Sevilla 2020
El Secretario del Tribunal
6
7
A mi familia
A mis maestros
A mis amigos
8
9
Agradecimientos
10
11
Resumen
La revolucioacuten tecnoloacutegica que vivimos hoy diacutea enfocada principalmente en el mundo de Internet y aplicaciones
Web estaacute permitiendo que todas las herramientas que tenemos a nuestro alrededor se encuentren en un proceso
de tremenda evolucioacuten y cambio continuo
En este proyecto se ha realizado un estudio del arte sobre una teacutecnica que permite mejorar el proceso de
automatizacioacuten de pruebas sobre una aplicacioacuten Web basaacutendose en el modelado de la aplicacioacuten para
proporcionar una abstraccioacuten en la implementacioacuten de las pruebas Tambiacuteeacuten se ha realizado una revisioacuten de los
diferentes modelos de calidad normativas y tipos de prueba de Software Finalmente se ha desarrollado una
herramienta de test comprendida por un conjunto de pruebas de aceptacioacuten automaacuteticas que permiten la
verificacioacuten y validacioacuten de la funcionalidad de la plataforma Web Galgus CHT Cloud Manager
Galgus CHT Cloud Manager es la plataforma Web distribuida ofrecida por Galgus para la gestioacuten de redes
compuestas por puntos de acceso Wifi Estas redes se encuentran instaladas en los diferentes clientes que hacen
uso de los servicios que ofrece Galgus los cuales se basan en la optimizacioacuten del rendimiento y las prestaciones
de las redes Wifi en entornos de alta densidad de usuarios Esto se consigue mediante un software embebido
patentado por Galgus conocido bajo el nombre de Cognitive Hostpot Technology (CHT) el cual es instalado
en los puntos de acceso Dicho software implementa un conjunto de algoritmos y caracteriacutescas colaborativas
para conseguir los objetivos planteados en redes Wifi
Como resultado del trabjo podemos proporcionar a los ingenieros de pruebas una herramienta con la que poder
automatizar el testeo de una plataforma Web De esta forma se consigue agilizar el proceso de pruebas y reducir
costes y esfuerzos en tareas repetitivas que anteriormente se haciacutean de forma manual
12
13
Abstract
The technological revolution we are living today focused mainly on the Internet world and therewith the Web
applications is allowing all the tools we have around us to be in a process of continuous evolution and change
In this project we have made a study of the art on a technique that allows to improve the process of automation
of testing on a Web application based on the modelling of the application to provide an abstraction in the
implementation of testing A review of the different quality models standards and types of software testing has
also been carried out Finally a tool comprised of a set of automated acceptance tests has been developed to
allow verification and validation of the functionality of the Galgus CHT Cloud Manager Web platform
Galgus CHT Cloud Manager is the distributed web platform offered by Galgus for the management of
networks composed by Wifi access points These networks are installed in the different clients that make
use of the services offered by Galgus which are based on the optimization of the performance and features
of Wifi networks in high user density environments This is achieved through an embedded software
patented by Galgus known as Cognitive Hostpot Technology (CHT) which is installed in the access points
This software implements a set of algorithms and collaborative features to achieve the objectives set in Wifi
networks
This allows us to provide quality assurance engineers with a tool to automate the testing of a Web platform In
this way the testing process is streamlined and costs and efforts are reduced in repetitive tasks that previously
used to be done manually
14
15
Iacutendice
Agradecimientos 9
Resumen 11
Abstract 13
Iacutendice 15
Iacutendice de Figuras 19
Glosario 24
1 Introduccioacuten 27 11 Motivacioacuten 28 12 Alcance y Objetivos 29 13 Estructura de la memoria 30
2 Estudio del Arte y Revisioacuten 32 21 Model Based Testing (MBT) 32
211 Introduccioacuten 32 212 iquestQueacute es Model Based Testing 33 213 iquestCoacutemo funciona Model Based Testing 33 214 Consideraciones para la aplicacioacuten de Model Based Testing (MBT) 36 215 Beneficios de Model Based Testing (MBT) 37 216 Problemas y Limitaciones de Model Based Testing (MBT) 38 217 Cuando elegir Model Based Testing (MBT) 38
22 Gestioacuten de Calidad Software 39 221 Introduccioacuten 39 222 Concepto de Calidad 39 223 Modelos de Calidad de Software 40 224 Principales Ventajas e Inconvenientes de Modelos de Calidad anteriores 44 225 Conclusiones 44
3 Marco Teoacuterico Pruebas de Software 46 31 Testing y Pruebas de Software 46 32 Principios de las Pruebas de Software 47 33 Proceso de Pruebas de Software Anaacutelisis disentildeo e implementacioacuten 48
331 Terminologiacutea 48 332 Proceso de Pruebas de Software 49
34 Clasificacioacuten de Pruebas de Software 51 341 Pruebas Funcionales 51 342 Pruebas No Funcionales 52 343 Pruebas Estructurales 54 344 Pruebas debidas a Cambios 54
35 Niveles de Prueba 54 351 Pruebas a Nivel de Componente 55 352 Pruebas a Nivel de Integracioacuten 55 353 Pruebas a Nivel de Aceptacioacuten 55
16
36 Dificultades de pruebas en aplicaciones Web e impacto 56
4 Sistema Galgus CHT Cloud Manager 58 41 Arquitectura y Descripcioacuten del Sistema 58
411 Puntos de Acceso (OpenWRT + CHT) 60 412 Broacuteker de Eventos AMQP (RabbitMQ) 61 413 Frontend 62 414 Zone Manager 62 415 MoMap 63 416 Servidor de Licencias 64
42 Alcance y Objetivos de las pruebas sobre el sistema planteado 65 43 Arquitectura de la Solucioacuten Entorno de UAT para el proceso de pruebas (User Acceptance Test) 67
5 Tecnologiacuteas y Herramientas Usadas 69 51 Selenium 69 52 Selenium WebDriver 70
521 Elementos del Navegador 70 53 Robot Framework (RF) 72
531 Estilo de representacioacuten Given-When-Then 72 532 Reportes 75 533 Libreriacuteas 76 534 Documentacioacuten 77
54 Pycharm (IDE) 78 55 GitGitlab 78
551 Git 78 552 Gitlab 78
56 Redmine 78 561 Uso en el Proyecto Galgus CHT Cloud Manager (Metodologiacutea Scrum) 79
6 Experimentos 82 61 Estructura del Proyecto 83 62 Vista de Gestioacuten Principal (Cloud Tab) 87
621 Administration 87 622 List 89 623 Manufacturer 90 624 MAP 92
63 Vista de Configuracioacuten (Configuration Tab) 95 631 Groups 95 632 CHT Zones 98 633 BackupRestore 100 634 Firmware 101
64 Vista de Red (Network Tab) 104 641 VLANS amp Bridges 104 642 SSIDs 106 643 CHT 108 644 Radius 110 645 Captive Portal 112 646 General 115 647 AP Network 117
7 Lineas de Mejora y Conclusiones 122 71 Liacuteneas de Mejora Futuras 122 72 Conclusiones Finales 123
Referencias 126
17
Anexo A Preparacioacuten del Entorno de Trabajo y Ejecucioacuten de Pruebas 128 A1 Preparacioacuten del entorno de trabajo 128
A11 Pip 128 A12 Virtualenv Entorno Virtual 128 A13 Selenium y Chromedriver 129 A14 Robot Framework y SeleniumLibrary 129 A15 Otras dependencias 130
A2 Ejecucioacuten de Pruebas 130 A3 Script de Prueba U007 (MAP) 132
Anexo B Docker de Robot Framework y Entorno de UAT Dockerizado 136 B1 Docker de Robot Framework 136 B2 Entorno de UAT Dockerizado 137
Anexo C Revisioacuten de Reportes y Logs 140 C1 Reporte de Logs ofrecido por Robot Framework 140 C2 Cloud Tab 140
C21 Administration 140 C22 List 142 C23 Manufacturers 143 C24 MAP 144
C3 Configuration Tab 145 C31 BackupRestore 145 C32 CHT Zones 146 C33 Firmware 147 C34 Groups 148
C4 Network Tab 150 C41 General 150 C42 SSID 151 C43 CHT 151 C44 VLAN 152 C45 Radius 153 C46 Captive Portal 154 C47 AP Network 155
Anexo D Diagrama de Gantt 157
18
19
IacuteNDICE DE FIGURAS
Figura 1 Fuente de datos Morgan Stanley 27
Figura 2 Manual Testing vs Automated Testing [20] 28
Figura 3 Fase de Pruebas y Validacioacuten 32
Figura 4 Esquema baacutesico de Model Based Testing 33
Figura 5 Proceso detallado de Model Based Testing (MBT) 34
Figura 6 Construccioacuten del Modelo 34
Figura 7 Concepto de Calidad 39
Figura 8 Liacutenea de tiempo de modelos a nivel de proceso 40
Figura 9 Logo de ITIL 40
Figura 10 ISOIEC 20000 41
Figura 11 Logo de WebQEM 41
Figura 12 Liacutenea de tiempo de modelos a nivel de producto 42
Figura 13 Esquema de ISO 9126 42
Figura 14 Esquema de ISOIEC 25000 43
Figura 15 Principios de las Pruebas de Software 47
Figura 16 Terminologiacutea para el proceso de pruebas 48
Figura 17 Proceso de Pruebas de Software 49
Figura 18 Clasificacioacuten de Pruebas de Software 51
Figura 19 Pruebas de Caja Negra 51
Figura 20 Pruebas de Rendimiento 52
Figura 21 Pruebas de Carga 52
Figura 22 Pruebas de Estreacutes 52
Figura 23 Pruebas de Usabilidad 53
Figura 24 Pruebas de Portabilidad 53
Figura 25 Pruebas de Caja Blanca 54
Figura 26 Modelo de desarrollo en V 55
Figura 27 Dificultades de pruebas en aplicaciones Web e impacto 56
Figura 28 Logo de Galgus 58
Figura 29 Arquitectura de CHT Cloud Manager 59
Figura 30 CHT_CLI 60
Figura 31 Plataforma de Gestioacuten de RabbitMQ 61
Figura 32 Patroacuten PublicadorSuscriptor 61
Figura 33 Ejemplo de Interfaz Graacutefica de un Zone Manager 62
Figura 34 Ejemplo de Interfaz Graacutefica de MoMap 63
20
Figura 35 Interfaz Graacutefica del Servidor de Licencias 64
Figura 36 Zero-Touch Provisioning (ZTP) 64
Figura 37 Test Plan de CHT Cloud Manager 65
Figura 38 Leyenda del Test Plan 66
Figura 39 Control de Versiones del Test Plan 66
Figura 40 Entorno de UAT con Docker (Anexo B) 67
Figura 41 Implementaciones disponibles de Selenium y Navegadores Web Compatibles 70
Figura 42 Coacutedigo de ejemplo con Python y Selenium 71
Figura 43 Estilo de representacioacuten Given-When-Then 72
Figura 44 Implementacioacuten de Pruebas en para el inicio de sesioacuten de CHT Cloud Manager 74
Figura 45 Ejemplo de reporte de pruebas automatizadas con Robot Framework 75
Figura 46 Ejemplo de documentacioacuten generada con Libdoc 77
Figura 47 Ejemplo de documentacioacuten generada con Testdoc 77
Figura 48 Ejemplo de Flujo de Trabajo en Redmine para Galgus CHT Cloud Manager 79
Figura 49 Esquema Graacutefico de Metodologiacutea Scrum 79
Figura 50 Logo de Galgus CHT Cloud Manager 82
Figura 51 Estructura del Proyecto 83
Figura 52 Fragmento del fichero ldquoSelectorpyrdquo 83
Figura 53 Fragmento del fichero ldquoCommon_Keywordsrobotrdquo 84
Figura 54 Fragmento del fichero de Configuracioacuten de pruebas ldquoConfigurationrobotrdquo 84
Figura 55 Diagrama de paquetes del proyecto de pruebas 85
Figura 56 Estructura de una Suite de Pruebas 85
Figura 57 Ejemplo de ldquoTest Setuprdquo personalizado para un caso de prueba 86
Figura 58 Vista de Gestioacuten Principal (Cloud Tab) 87
Figura 59 Pestantildea ldquoAdministrationrdquo 87
Figura 60 Diagramas de Flujo de Casos de Prueba U0025 y U0027 88
Figura 61 Script de Pruebas U0025 88
Figura 62 Keyword ldquoEdit Fieldsrdquo 88
Figura 63 Pestantildea ldquoList of Zone Managersrdquo 89
Figura 64 Diagrama de flujo de Caso de Prueba U0023 89
Figura 65 Script de Prueba U0023 90
Figura 66 Keyword ldquoZone Manager is registered successfullyrdquo 90
Figura 67 Seccioacuten de Fabricantes 90
Figura 68 Diagrama de flujo de Caso de Prueba U0009 91
Figura 69 Script de Prueba U0009 91
Figura 70 Toast Success 92
Figura 71 Keyword ldquoCorrectly Createrdquo 92
Figura 72 Setup amp Teardown de U0008 92
21
Figura 73 Mapa de Zone Managers 92
Figura 74 Funcioacuten que dibuja los ZM en el Mapa y obtiene los piacutexeles en pantalla 93
Figura 75 Diagrama de Flujo de Caso de Prueba U0007 94
Figura 76 Pestantildea ldquoGroupsrdquo 95
Figura 77 Diagrama de flujo de Caso de Prueba U0119 96
Figura 78 Script de Prueba U0119 97
Figura 79 Keyword ldquoVerify if AP is registered Succesfully on grouprdquo 97
Figura 80 Keywords Input Into Text Field y Clear Field Of Characters 97
Figura 81 Pestantildea ldquoCHT Zonesrdquo 98
Figura 82 Diagrama de Flujo de Caso de Prueba U0204 99
Figura 83 Scripts de Prueba U0204 99
Figura 84 Keyword Add Zone CHT to AP 99
Figura 85 Pestantildea BackupRestore 100
Figura 86 Diagrama de Flujo de Caso de Prueba U0401 101
Figura 87 Script de Prueba U0401 101
Figura 88 Keyword Restore For AP hace done successfully 101
Figura 89 Pestantildea ldquoFirmwarerdquo 102
Figura 90 Diagrama de Flujo de Caso de Prueba U0303 103
Figura 91 Script de Prueba U0303 103
Figura 92 Keyword Flash AP 103
Figura 93 Pestantildea ldquoVLAN amp Bridgesrdquo 104
Figura 94 Diagrama de Flujo de Caso de Prueba U0527 105
Figura 95 Script de Prueba U0527 105
Figura 96 Keyword Go And Create VLAN 105
Figura 97 Pestantildea SSIDs 106
Figura 98 Diagrama de Flujo de Caso de Prueba U0530 106
Figura 99 Script de Prueba U0530 107
Figura 100 Keyword Go And Create SSID 107
Figura 101 Pestantildea ldquoCHTrdquo 108
Figura 102 Diagrama de Flujo de Caso de Prueba U0539 109
Figura 103 Script de Prueba U0539 109
Figura 104 Keyword ACA Is Working 109
Figura 105 Keyword Changes On CLI 110
Figura 106 Comando CHT para obtener el estado del moacutedulo ACA en el punto de acceso 110
Figura 107 Pestantildea ldquoRadiusrdquo 110
Figura 108 Escenario de Funcionamiento de Servidor Radius 110
Figura 109 Diagrama de Flujo de Caso de Prueba U0601 111
Figura 110 Script de Prueba U0601 111
Figura 111 Keyword Create Radius Profile 112
22
Figura 112 Pestantildea Captive Portals 112
Figura 113 Escenario de Funcionamiento de un Portal Cautivo 112
Figura 114 Diagrama de Flujo de Caso de Prueba U0701 113
Figura 115 Script de Prueba U0701 113
Figura 116 Keyword Edit or Delete Captive Portal Profile 114
Figura 117 Pestantildea General 115
Figura 118 Diagrama de Flujo de Caso de Prueba U0522 116
Figura 119 Script de Prueba U0522 116
Figura 120 Keyword Check Number of Clients Increases 116
Figura 121 Pestantildea AP Network 117
Figura 122 Libreriacutea SSH para Robot Framework 117
Figura 123 Ventana de Configuracioacuten de TC Rules 118
Figura 124 Diagrama de Flujo de Caso de Prueba U0511 119
Figura 125 Script de Prueba U0511 120
Figura 126 Keyword Wait Timer 120
Figura 127 Keyword Check On CLI 120
23
24
GLOSARIO
CHT Cognitive Hostpot Technology
BDD Behaviour-Driven Development
MBT Model Based Testing
API Application Programing Interface
UAT User Acceptance Testing
SUT System Under Test
UML Unified Modeling Language
FSM Finite State Machine
RAE Real Academia Espantildeola
IEEE Institute of Electronical and Electronics Engineers
ITIL Information Technology Infrastructure Library
ISO International Organization for Standardization
WebQEM Web-site Quality Evaluation method
ISTQB International Software Testing Qualifications Board
TDD Test-Driven Development
SOA Service Oriented Architecture
WiFi Wireless Fidelity
MGR Manager Module
SB Smart Band Steering Module
TCM Traffic Congestion Management Module
LOC Localization Module
POWER Power Control Module
SR Smart Roaming Module
LB Load Balancing Module
AMQP Advance Message Queuing Protocol
HTML HyperText Markup Language
CSS Cascading Style Sheets
HTTPS HyperText Transfer Protocol Secure
TLS Transport Layer Security
REST REpresentational State Transfer
JSON JavaScript Object Notation
DOM Document Object Model
SQL Structure Query Language
ZMB Zone Manager Backend
ZTP Zero-Touch Provisioning
25
RF Robot Framework
CICD Continuous IntegrationContinuous Delivery
SSH Secure SHell
SCP Secure Copy ProtocolSimple Communication Protocol
26
27
1 INTRODUCCIOacuteN
ctualmente el desarrollo software se encuentra en un proceso revolucionario cuyo principal objetivo y
tendencia es la implantacioacuten y desarrollo de software distribuido donde se marcan como principales
objetivos la disponibilidad usabilidad y funcionalidad de cualquier aplicacioacuten a traveacutes de internet Es
aquiacute donde entran en juego entre otros el desarrollo de aplicaciones o servicios Web sustituyendo en gran
medida al desarrollo de aplicaciones y servicios de escritorio
Figura 1 Fuente de datos Morgan Stanley
Muchos son los aspectos a tener en cuenta entre los que cabe destacar la eficiencia la velocidad de respuesta y
de navegacioacuten los cuales para algunos servicios Web son excelentes pero para otros auacuten se encuentran en un
proceso de mejora Esto es debido a que gran cantidad de aplicaciones requieren de un buen disentildeo donde se
optimicen el uso de los recursos disponibles como el ancho de banda memoria carga del servidor respaldo
seguridad etc
A
Hemos establecido la civilizacioacuten de manera que los
maacutes cruciales elementos dependen de la ciencia y la
tecnologiacutea
Carl Sagan
28
11 Motivacioacuten
La gran demanda de servicios y aplicaciones Web distribuidas que permitan gestionar agilizar y simplificar
cualquier aacutembito de negocio hace que cada vez maacutes que dichas aplicaciones contemplen un mayor
conjunto de requisitos solicitados por los clientes lo cual se traduce en un mayor nuacutemero de funcionalidades
y casos de uso contemplados en dichas aplicaciones
Ademaacutes dichas aplicaciones se necesitan cada vez en un menor tiempo lo cual conlleva a reducir los
periodos en las diversas fases por las que pasa un proyecto software desde la fase de disentildeo hasta la de
pruebas Es en esta uacuteltima donde antes de ser entregada al cliente como un producto se detectan los
posibles errores e incluso se puede evaluar si la funcionalidad ofrecida por la aplicacioacuten esta alineada con
los requisitos demandados por el cliente
Los fallos o errores en las aplicaciones Web mal probadas bien por falta de asignacioacuten de tiempo o recursos
a la fase de pruebas tienen una mayor repercusioacuten teniendo el potencial de generar una gran cantidad de
quejas e insatisfaccioacuten por parte de los clientes casi inmediatamente En el caso de las aplicaciones Web
no soacutelo se trata de peacuterdidas econoacutemicas sino tambieacuten de peacuterdida de prestigio fiabilidad y credibilidad por
parte de nuestros usuarios o clientes Los consumidores de hoy demandan una tecnologiacutea intuitiva y de
confianza en un mercado en continuo crecimiento donde un pequentildeo error puede acarrear falta de
satisfaccioacuten en un usuario peacuterdidas millonarias a una empresa o incluso dantildeos humanos Y es en este tipo
de ciclos iterativos y raacutepidamente cambiantes donde la automatizacioacuten de pruebas juega un papel decisivo
iquestY cuaacutel es la causa de estos problemas Para ello debemos tener en cuenta que estos sistemas son disentildeados
por el ser humano el cual comete fallos ya sea por presioacuten en los plazos de trabajo por la complejidad del
coacutedigo o de la infraestructura por cambios de tecnologiacuteas o por cualquier otra interaccioacuten con el sistema
Como ha quedado reflejado un proceso riguroso de control de sistemas y documentacioacuten permiten
bull Ayudar a reducir el riesgo de los posibles fallos y Mejora la calidad de los sistemas a la hora de ser
usados
bull Un correcto mantenimiento del producto a lo largo del ciclo de desarrollo
bull Un cumplimiento de requisitos legales (normas nacionales e internacionales ordenanzas
municipales etc)
bull Una adecuacioacuten de un sistema a los requisitos contractuales
bull Una adaptacioacuten de estaacutendars especiacuteficos de la industria
La forma en la que se logre y las herramientas empleadas variaraacuten en funcioacuten de factores como la
envergadura y tipo de proyecto den cuanto a los riesgos tecnoloacutegicos de seguridad o de negocio asiacute como
del presupuesto y tiempo disponible
Figura 2 Manual Testing vs Automated Testing [20]
29
12 Alcance y Objetivos
Las pruebas de software o software testing pueden llevarse a la praacutectica de muacuteltiples maneras pero el
presente proyecto se centra en el componente funcional del producto enfocado en lo que hace el sistema y
no coacutemo primando la aceptacioacuten por parte de los usuarios en base a los requisitos de disentildeo originales Es
decir el punto de mira estaacute en cumplir los requisitos establecidos por el cliente dejando fuera del alcance
del proyecto la estructura del coacutedigo fuente implementado
Bajo este contexto se plantea la automatizacioacuten de la fase de pruebas de una aplicacioacuten Web distribuida
centrando el enfoque de este proyecto en la automatizacioacuten de pruebas funcionales maacutes concretamente
pruebas de humo or smoke tests y aceptacioacuten Hasta ahora dichas pruebas se realizaban manualmente por
un ingeniero de pruebas lo cual permitiacutea evaluar la calidad del producto que seriacutea entregado al cliente
Ademaacutes se realizaraacute un marco teoacuterico donde se resumiraacuten una clasificacioacuten de los diferentes tipos de
pruebas software que pueden realizarse sobre una aplicacioacuten
Concretamente la solucioacuten abordada en esta memoria se cintildee al mantenimiento de un producto Web como
es la plataforma Galgus CHT Cloud Manager Para ello se cubriraacuten un gran conjunto de funcionalidades
ofrecidas por dicha aplicacioacuten Web como por ejemplo inicio y cierre de sesioacuten flujos de navegacioacuten
comprobacioacuten de los elementos mostrados y uso de la caja de buacutesquedas Sin llegar a ser exhaustivos este
tipo de pruebas conocidas como smoke tests son faacutecilmente automatizables y permiten detectar las primeras
sentildeales de que un sistema no funciona de manera correcta Por tanto es necesario traducir los requisitos
funcionales a instrucciones de alto nivel faacutecilmente entendibles por personas con poca formacioacuten teacutecnica
dado que seraacute el el resultado mostrado de las pruebas realizadas (informes de pruebas) Estas instrucciones
usaraacuten Behaviour-Driven Development (BDD) para describir interacciones entre el usuario y el sistema
definiendo actor accioacuten y comportamiento esperado del sistema Robot Framework es la herramienta que
se usa para este punto
Una vez tenemos dichas instrucciones se deben traducir de nuevo a un lenguaje de menor nivel como es
Python para implementar los test scripts Estos scripts seraacuten los que Selenium Webdriver procese y traduzca
para comunicarse con el controlador del navegador Web Chrome en nuestro caso a traveacutes de una API
Posteriormente el navegador se encargaraacute de ejecutar los comandos de accioacuten y de devolver la informacioacuten
de estado de vuelta Finalmente Robot Framework elaboraraacute un informe en formato html detallando las
pruebas realizadas resultados de las interacciones tiempos de ejecucioacuten y espera errores producidos etc
Tambieacuten se realizaraacute un estudio del arte sobre una teacutecnica conocida como Model Based Testing (MBT)
Dicha teacutecnica permite la generacioacuten automaacutetica de las pruebas a realizar sobre un sistema partiendo del
modelado del comportamiento de dicho sistema Ademaacutes esta teacutecnica tambieacuten abarca la traduccioacuten de las
pruebas generadas en scripts ejecutables para aplicar dichas pruebas sobre el sistema dando tambiacuteeacuten la
posibilidad de evaluar los resultados Esto proporciona muchas ventajas sobre la fase de pruebas pero a la
vez tambieacuten requiere un mayor esfuerzo en la fase de disentildeo y una presencia continua de la fase de pruebas
en otras etapas del ciclo de vida del proyecto Tambieacuten se presentaraacute un conjunto de normativas que regula
y normaliza la gestioacuten de calidad software
Posteriormente se describiraacute el sistema sobre el cual se basa la aplicacioacuten bajo pruebas llamada CHT
Cloud Manager Se presentaraacute la arquitectura de la aplicacioacuten y posteriormente se destacaraacuten los objetivos
de automatizacioacuten de testeo sobre la misma proponiendo el entorno de UAT planteado para someter la
aplicacioacuten a las pruebas automaacuteticas desarrolladas Se dedicaraacute una seccioacuten a analizar las tecnologiacuteas y
herramientas usadas donde se centraraacute la atencioacuten en Robot Framework Selenium y Python como las
tecnologiacuteas usadas para automatizar el testeo Ademaacutes se destacaraacute la integracioacuten del entorno de UAT
como fase de la integracioacuten continua de la aplicacioacuten ademaacutes de la metodologiacutea de trabajo llevada a cabo
Finalmente se presentaraacuten algunos experimentos y demostraciones de uso de la herramienta desarrollada
se describiraacuten algunas liacuteneas de mejora y conclusiones y se incluiraacuten algunos posibles anexos para la puesta
en marcha de la aplicacioacuten y reportes de algunas pruebas entre otros
30
13 Estructura de la memoria
El siguiente esquema resume de forma geneacuterica los puntos tratados en esta memoria para que el lector pueda
tener una idea orientativa de la organizacioacuten de este documento
1 Introduccioacuten En este punto se abordan temas geneacutericos como los objetivos motivacioacuten y alcance de
forma que pueda adquirirse una breve aproximacioacuten a los detalles del proyecto
2 Estudio del Arte y Revisioacuten A lo largo de esta seccioacuten se presentaraacute un estudio sobre la teacutecnica
conocida como Model Based Testing la cual permitiriacutea mejorar el proceso de automatizacioacuten de
pruebas Ademaacutes se realiza una revisioacuten sobre la gestioacuten de Calidad Software presentado algunos
modelos existentes en la actualidad
3 Marco Teoacuterico Consta de un estudio sobre el proceso de pruebas en un proyecto Software y los
principales tipos de pruebas Software existentes
4 Sistema En este punto se presenta la arquitectura del sistema sobre el que se van a automatizar las
pruebas de aceptacioacuten o Smoke Tests Ademaacutes se describe el alcance y objetivos de dichas pruebas y
se presenta la arquitectura de la solucioacuten planteada como escenario de pruebas haciendo uso de Docker
como tecnologiacutea de automatizacioacuten en el despliegue de aplicaciones software alojadas en contenedores
de software
5 Tecnologiacuteas y Herramientas usadas Consta del conjunto de tecnologiacuteas usadas para la
implementacioacuten de las pruebas de aceptacioacuten automatizadas y las herramientas para utilizar dichas
pruebas y para gestionar el trabajo del equipo de desarrollo y calidad responsable de este proyecto
6 Experimentos Consta de un detalle sobre la funcionalidad de un conjunto de pruebas que han sido
implementadas para verificar y validar el funcionamiento esperado del sistema Para cada prueba se
definen criterios de aceptacioacuten diagramas de flujo y scripts de implementacioacuten detallando algunas de
las implementaciones clave
7 Liacuteneas de Mejora y Conclusiones Se incluye una seccioacuten conclusiones finales tras la realizacioacuten del
proyecto y una valoracioacuten del mismo a nivel general y personal Ademaacutes se destacaraacuten algunas liacuteneas
de mejora futuras relacionadas principalmente con la aplicacioacuten de Model Based Testing (MBT) y otros
aspectos sobre la implementacioacuten actual de la herramienta de automatizacioacuten
Ademaacutes se realizaraacute una seccioacuten de anexos en el que se trataraacuten puntos adicionales sobre el proyecto
bull Anexo A Preparacioacuten del Entorno de Trabajo y Ejecucioacuten de Pruebas
bull Anexo B Docker de Robot Framework y Entorno de UAT Dockerizado
bull Anexo C Revisioacuten de Reportes y Logs
31
32
2 ESTUDIO DEL ARTE Y REVISIOacuteN
n este punto se realizaraacute un estudio sobre el marco teoacuterico de una de las teacutecnicas existentes que permite
la generacioacuten y ejecucioacuten automaacutetica de casos de test a partir del modelado de un sistema para la fase
de pruebas de una aplicacioacuten Esta teacutecnica es conocida como Model Based Testing (MBT) Ademaacutes
se realizaraacute una revisioacuten de la normativa relacionada con la gestioacuten de calidad software analizando la familia de
normas ISOIEC 25000
21 Model Based Testing (MBT)
211 Introduccioacuten
Dada la rapidez con la que se demandan los servicios contratados por los clientes en muchas ocasiones la
mayoriacutea del tiempo y esfuerzo asignado para la realizacioacuten de proyectos de software van destinados a la
labor de desarrollo dedicando menos esfuerzos en otras fases del ciclo de vida de un proyecto como las
fases de disentildeo o de pruebas Esto puede conllevar a que el proyecto no se desarrolle de acuerdo con los
requisitos demandados por los clientes y que el nuacutemero de puntos de fallo del producto software aumente
La fase de testeo o prueba de un producto software durante su ciclo de vida es una etapa fundamental para
validar la calidad del producto desarrollado y ofrecido a un cliente para conseguir un grado de satisfaccioacuten
aceptable de forma que se cumpla con los requisitos demandados y con el menor grado de error posible
Figura 3 Fase de Pruebas y Validacioacuten
Uno de los factores por los que en ocasiones no se emplean suficientes recursos a la fase de pruebas es la
gran cantidad de casos de pruebas que se deben realizar para validar un sistema Por cada caso de prueba
se deben asignar recursos relacionados con la planificacioacuten disentildeo y ejecucioacuten del mismo
Por tanto en este punto cabe plantearse la idea de automatizar no solo los casos de pruebas que validan un
sistema sino la generacioacuten de los casos de prueba Esto puede permitir reducir de forma considerable el
coste y esfuerzos en la fase de pruebas En este contexto surge el concepto de Model Based Testing (MBT)
E
La tecnologiacutea no es en siacute el fin sino el medio entre la
sociedad del conocimiento y el desarrollo mundial
Anoacutenimo
33
212 iquestQueacute es Model Based Testing
Este se trata de un meacutetodo capaz de controlar la calidad del software durante su ciclo de vida permitiendo
la generacioacuten automaacutetica de los casos de prueba e incluso la ejecucioacuten y evaluacioacuten automaacutetica de
resultados Para ello se requiere de un modelado y disentildeo correcto del sistema bajo pruebas como base
para la aplicacioacuten de esta teacutecnica
Figura 4 Esquema baacutesico de Model Based Testing
MBT permite crear un modelo del comportamiento esperado por el sistema a traveacutes del cual permite la
aplicacioacuten de diferentes teacutecnicas para la generacioacuten de casos de prueba [1]
bull Generacioacuten de casos de pruebas con datos de entrada sobre un modelo de dominio del sistema bull Generacioacuten de casos de pruebas de un modelo de entorno bull Generacioacuten de casos de prueba con predicciones del comportamiento del modelo bull Generacioacuten de scripts de prueba a partir de pruebas abstractas
213 iquestCoacutemo funciona Model Based Testing
En primer lugar se requiere del disentildeo de un modelo del sistema bajo test el cual debe tener al menos dos
caracteriacutesticas principales debe ser pequentildeo en relacioacuten al tamantildeo del sistema de forma que no requiera
un coste elevado pero debe ser lo suficientemente detallado para describir completamente las
caracteriacutesticas que se quieran probar sobre el sistema
Una vez implementado el modelo del sistema a probar se procederiacutea a la utilizacioacuten de herramientas
basadas en la teacutecnica MBT para generar automaacuteticamente el banco de pruebas a partir del modelo del
sistema bajo test (SUT) Estos bancos de pruebas generados seraacuten un conjunto de pruebas abstractas cada
una de las cuales define la secuencia de operaciones a realizar para probar una funcionalidad determinada
con sus respectivos valores o datos de entrada necesarios y las salidas o respuestas del sistema que se
esperan
A partir del banco de pruebas abstractas se deben transformar en scripts de pruebas ejecutables lo cual
puede realizarse con herramientas basadas en la teacutecnica MBT Estos scripts podriacutean ser ejecutados para la
deteccioacuten de errores sobre el sistema bajo test y esta ejecucioacuten podriacutea ser controlada y monitorizada por
alguna herramienta de ejecucioacuten de pruebas
En el siguiente diagrama se muestra el proceso de aplicacioacuten de este meacutetodo donde se propone dividir el
proceso en cinco fases principales [1]
1 Modelado Modelar el sistema bajo test y su entorno 2 Generacioacuten Generar las pruebas abstractas a partir del modelo planteado en la fase anterior 3 Concretizado Concretizar o adaptar las pruebas abstractas para transformarlas en ejecutables 4 Ejecucioacuten Ejecutar las pruebas sobre el sistema bajo test y definir decisiones o veredictos para las
mismas de forma que se pueda determinar el correcto funcionamiento del sistema bajo test 5 Anaacutelisis Analizar los resultados obtenidos a partir de la ejecucioacuten de los casos de prueba
34
Destacar que para el generador de casos de prueba y el script de pruebas se suelen usar herramientas de pruebas
especiales Por este motivo se encuentran resaltados en negrita
Figura 5 Proceso detallado de Model Based Testing (MBT)
Una vez presentado el proceso o metodologiacutea para llevar a cabo dicha teacutecnica se describiraacuten las principales
fases
2131 Construccioacuten del Modelo
Dicha fase consiste en la construccioacuten de un modelo que represente el comportamiento detallado del sistema
bajo pruebas yo su entorno a partir de los requisitos de disentildeo del mismo y el plan de pruebas desarrollado para
cumplir con estos requisitos
Este es el paso maacutes importante en la aplicacioacuten de la teacutecnica Model Based Testing ya que el resto de fases
dependeraacute siempre del modelo del sistema bajo pruebas Cuanto maacutes completo sea el modelo maacutes efectivos
seraacuten los casos de prueba generados a partir de este
Figura 6 Construccioacuten del Modelo
35
Para llevar a cabo el modelo del comportamiento de la aplicacioacuten se requiere conocer exactamente el
comportamiento esperado de la misma lo cual lleva a estudiar y analizar en profundidad el sistema y su entorno
previamente
Existen diversas especificaciones formales para el modelado a partir de los requisitos como por ejemplo los
diagramas UML Estos ayudan a que el modelado sea una tarea algo maacutes sencilla de realizar que si se llevara a
cabo a partir de los requisitos escritos en lenguaje natural Por otro lado para modelar el comportamiento existen
diversas teacutecnicas como las maacutequinas de estados finitos (FSM) Cadenas de Maacuterkov Tablas de decisiones
Diagramas de estados etc
En conclusioacuten modelar un sistema no es una tarea sencilla ya que requiere de habilidades teacutecnicas experiencia
e imaginacioacuten para construir un modelo que se comporte de la forma deseada Dicho modelo debe cumplir con
las siguientes propiedades [2]
bull Debe ser lo maacutes abstracto posible sin perder la informacioacuten importante
bull No debe contener informacioacuten que sea redundante o que no esteacute relacionada con el alcance de las
pruebas
bull Debe ser entendible para los ingenieros de pruebas incluso a expensas de la brevedad y abstraccioacuten del
mismo
bull Debe ser flexible y abierto para permitir cambios y antildeadir o eliminar nuevas funcionalidades
bull Debe considerar todos los detalles de implementacioacuten de las pruebas
2132 Generacioacuten de Casos de Prueba
Los casos de prueba seraacuten generados tras la construccioacuten previa del modelo del sistema Antes de la creacioacuten de
los casos de prueba los ingenieros de pruebas deben especificar o proveer informacioacuten sobre el criterio o
propoacutesito de los casos de prueba las entradas y en algunos casos las salidas esperadas del sistema
Destacar que generar las salidas esperadas correspondientes a unas determinadas entradas es maacutes complejo que
generar soacutelo las entradas Para ello se necesita un oraacuteculo que cree salidas vaacutelidas y las mapee a los casos de
prueba Crear el oraacuteculo es la tarea maacutes compleja
Las dificultades presentadas en esta fase dependeraacuten de si el modelo es complejo o simple y la efectividad de
los casos de prueba generados dependeraacute de lo completo y preciso que sea dicho modelo para poder generar
automaacuteticamente los casos de prueba
Cuando el sistema es complejo la cantidad de casos de test es muy grande e incluso infinita Por tanto evaluar
todos los casos de test resulta inviable y costoso En este caso para mejorar la calidad del sistema se necesita
seleccionar los casos de test que realmente puedan ayudar a localizar tantos fallos como sea posible con un coste
aceptable
Existen diferentes criterios de cobertura que permiten ayudar a controlar el proceso de generacioacuten de casos de
prueba Sin embargo se recomienda seleccionar maacutes de uno de estos criterios para lograr un mayor resultado en
la cobertura de pruebas
2133 Ejecucioacuten de Casos de Prueba
La ejecucioacuten de los casos de pruebas requiere la transformacioacuten de los mismos en una forma ejecutable Debido
a que los los scripts de pruebas ejecutables pueden ser reutilizados durante todo el tiempo empleado en la
validacioacuten del sistema estos deben ser escritos de una forma maacutes eficiente que permita que sean reutilizables e
incluso que frente a una modificacioacuten sean maacutes faacuteciles generarlos y ejecutarlos Por ello se crean scripts
ejecutables para los casos de prueba abstractos
El proceso de transformacioacuten en pruebas ejecutables seriacutea maacutes eficiente si es hecha de forma automaacutetica
Despueacutes de aplicar los casos de prueba ejecutables al sistema bajo pruebas se obtienen las salidas actuales del
sistema las cuales deberaacuten ser contrastadas con las salidas esperadas
36
2134 Anaacutelisis de los Resultados
Una vez ejecutados los casos de pruebas y obtenidas las salidas actuales del sistema se deben evaluar y analizar
los resultados obtenidos Para ello se debe comparar las salidas actuales obtenidas con las salidas esperadas
especificadas en los casos de prueba Esta tarea de comparacioacuten podriacutea realizarse idealmente de forma
automaacutetica lo cual dariacutea como resultados posibles
1 Pasa Cuando las salidas actuales se encuentran acordes con las salidas esperadas
2 Falla Cuando las salidas actuales no se encuentran acordes con las salidas esperadas
3 Inconcluso Cuando no se puede tomar una decisioacuten en el momento
Hay que destacar que puede darse el caso en el que si las salidas esperadas no estaacuten bien determinadas los
resultados obtenidos al contrastar dichas salidas con las actuales sean falsos dando lugar a resultados sin utilidad
y que pueden dar lugar a confusioacuten
Por este motivo la generacioacuten automaacutetica de las salidas esperadas es una tarea compleja e importante en todo el
proceso especialmente en sistemas complejos Por tanto el nivel de dificultad para encontrar un oraacuteculo de
pruebas depende del tamantildeo y complejidad del sistema Sin embargo la necesidad e importancia del oraacuteculo de
pruebas tambieacuten aumenta cuando el sistema es maacutes complejo
Tras obtener los resultados se debe determinar si se decide generar maacutes casos de prueba si se debe modificar el
modelo o si la fase de pruebas debe ser detenida y debe ponerse en marcha el software del sistema que se estaacute
probando
214 Consideraciones para la aplicacioacuten de Model Based Testing (MBT)
Son muchos los artiacuteculos que describen aspectos importantes a tener en cuenta durante el desarrollo o la
aplicacioacuten de esta teacutecnica Algunas de estas consideraciones a destacar seriacutean las siguientes [3]
1 El modelo que describe el comportamiento del sistema es el punto clave
El comportamiento del modelo debe ser desarrollado cuidadosamente Sus limitaciones y restricciones deben
ser respetadas durante el modelado del sistema bajo pruebas De esta forma si el modelo estaacute mal las pruebas
generadas tambieacuten lo estaraacuten Por tanto la exactitud del modelo es fundamental para pasar a la fase de
generacioacuten de casos de prueba
2 Las pruebas deben cubrir los criterios de control de flujo y datos
Los criterios de cobertura de las pruebas definen un conjunto de casos de prueba seleccionados para la misma
Estos casos de pruebas pueden ser generados a partir de dos fuentes criterios de flujo de control o de flujo
de datos En el caso de pruebas aplicadas a grandes sistemas es importante combinar ambos criterios para
incrementar la cobertura de las pruebas
3 El nivel de automatizacioacuten debe ser elevado
El nivel de automatizacioacuten es un factor importante para definir la factibilidad de uso de MBT Normalmente
suele haber un uacutenico paso no automatizado el modelado del comportamiento del sistema el cual es utilizado
como entrada para el proceso de generacioacuten de los casos de prueba Si hubiese otros pasos no automatizados
se incrementariacutea el esfuerzo los costes y la complejidad de su uso
4 Son fundamentales las herramientas que soportan la automatizacioacuten de las fases de MBT
Las herramientas usadas deben soportar la ejecucioacuten de los pasos automatizados Si no hay una herramienta
que soporte un determinado paso esta tarea podriacutea ser difiacutecil e inviable Por tanto una herramienta debe
soportar la integracioacuten entre los diferentes pasos no automatizados y automatizados
5 Los liacutederes del proyecto deben entender las habilidades requeridas y la complejidad para usar
MBT
Las personas encargadas de la fase de pruebas necesitan conocer ademaacutes de las teacutecnicas de pruebas los
lenguajes de modelado y algunos lenguajes de programacioacuten
37
6 El orden de los pasos a seguir mientras se usa un enfoque MBT
Es necesario respetar los pasos seguidos para la generacioacuten de los casos de prueba de forma que sean
respetados en la fase de ejecucioacuten de las pruebas siendo ejecutados en la misma secuencia en que fueron
definidos En caso contrario se podriacutean generar salidas erroacuteneas de dichas pruebas
7 Transferencia de la Tecnologiacutea
Las tecnologiacuteas usadas para la aplicacioacuten de la teacutecnica MBT se transfieren desde entornos acadeacutemicos o de
investigacioacuten para ser implementados en proyectos industriales Por este motivo necesitan ser analizados
cuidadosamente antes de ser usadas
215 Beneficios de Model Based Testing (MBT)
A continuacioacuten se definen diversos beneficios que proporciona la aplicacioacuten de Model Based Testing para la
fase de pruebas [1] [4]
1 Deteccioacuten de Fallos del Sistema Bajo Pruebas
El modelado del comportamiento del sistema bajo pruebas permite detectar errores ambiguumledades o lagunas
que pueden presenciarse en la toma de requisitos especificacioacuten y disentildeo del software Por tanto permite
una deteccioacuten temprana de errores
2 Reduccioacuten de costes y tiempo en la fase de pruebas
La aplicacioacuten de esta teacutecnica contribuye a que el tiempo coste y recursos empleados a la fase de pruebas
disminuya Sin embargo se requiere una mayor asignacioacuten de recursos para el modelado y mantenimiento
del sistema
3 Mejora de la calidad de las pruebas
Cuando las pruebas se desarrollan manualmente la calidad de las mismas es muy dependiente de los
desarrolladores que la implementan Ademaacutes el proceso de disentildeo no puede ser reproducido el criterio
racional aplicado para cada prueba normalmente no es recordado y el resultado de los casos de prueba no es
faacutecilmente interpretado ni contrastado con los requisitos originales del sistema
Model Based Testing es una teacutecnica capaz de mejorar mucho estos inconvenientes que se presentan sobre el
desarrollo de pruebas manuales gracias al generador automatizado de casos de prueba
4 Trazabilidad
Puede definirse como la habilidad para relacionar cada caso de prueba al modelo criterio de seleccioacuten e
incluso a los requisitos informales del sistema Esto ayuda a explicar los casos de prueba asiacute como justificar
por queacute fueron creados Los algoritmos aplicados para la generacioacuten de pruebas deben saber queacute partes del
modelo seraacuten empleadas en cada caso de prueba y las salidas esperadas
5 Evolucioacuten de los requisitos
Si los requisitos del sistema cambian con la aplicacioacuten de Model Based Testing bastariacutea con actualizar el
modelo y las pruebas seraacuten generadas de nuevo de forma automaacutetica Debido a que el modelo es usualmente
maacutes pequentildeo que el conjunto de pruebas del sistema requiere menos tiempo actualizar el modelo que
actualizar todos los casos de prueba Por tanto puede concluirse que se obtiene una respuesta maacutes raacutepida
frente a un cambio en los requisitos
6 Reusabilidad del modelo
El modelo contiene informacioacuten sobre el comportamiento del sistema bajo pruebas Por tanto este puede ser
reutilizado en futuras pruebas incluso cuando los requisitos cambian
38
216 Problemas y Limitaciones de Model Based Testing (MBT)
Una vez destacados los beneficios que aporta dicha teacutecnica tambieacuten es importante detallar algunos problemas
y limitaciones sobre su uso [1] [5]
2161 Problemas
bull Para abordar dicha teacutecnica es necesario que los ingenieros de pruebas tengan habilidades teacutecnicas sobre
la notacioacuten usada para el modelado del sistema Ademaacutes deberiacutean tener experiencia con herramientas
scripts y lenguajes de programacioacuten usados para ejecutar las tareas de Model Based Testing
bull Cuando dicha teacutecnica se pretende aplicar a sistemas complejos el modelado del sistema es maacutes
complejo y existe riesgo de producirse un desbordamiento de la cantidad de casos de prueba generados
a partir del modelo Por esta razoacuten es muy importante definir bien el conjunto de criterios para la
generacioacuten de las pruebas lo cual permite acotar la cobertura de pruebas de forma razonable
bull La automatizacioacuten de la generacioacuten del oraacuteculo de pruebas a partir del modelo es compleja
especialmente en sistemas complejos Cuando el tamantildeo del sistema aumenta la necesidad de
automatizacioacuten tambieacuten aumenta
bull Es necesario desarrollar un modelo de software especiacutefico para un dominio en concreto de aplicacioacuten
ya que existen diversas notaciones de modelado del sistema
bull Es necesario la especificacioacuten formal de los requisitos para obtener el modelo del sistema a partir de
estos La especificacioacuten informal o en lenguaje natural de los requisitos puede dar lugar a ambiguumledades
que dificultan la exactitud en el modelado
2162 Limitaciones
bull No es posible modelar todos los aspectos del comportamiento del sistema bajo pruebas Por tanto es
necesario el uso de otras notaciones de modelado que cubran dichos aspectos
bull Los proyectos software evolucionan continuamente surgiendo nuevos requisitos los cuales algunos
pueden quedar fuera de la fecha de planificacioacuten Si se ha comenzado con el modelado a partir de
requisitos antiguos se construiraacute un modelo erroacuteneo que no reflejaraacute los nuevos requisitos
contemplados lo cual daraacute lugar a errores en el sistema bajo pruebas o resultados no fiables
bull Cuando se produce un fallo en una prueba generada podriacutea resultar maacutes complejo determinar la causa
del fallo ya que la secuencia de pruebas generadas en Model Based Testing podriacutea ser maacutes compleja y
menos intuitiva que las disentildeadas manualmente
217 Cuando elegir Model Based Testing (MBT)
Finamente tras detallar los beneficios problemas y limitaciones sobre la teacutecnica bajo estudio se destacan
algunos puntos principales a tener en cuenta para la aplicacioacuten de dicha teacutecnica
bull Debe existir documentacioacuten lo suficientemente buena sobre el sistema para poder aplicarla
bull Si ya existe un modelo del sistema seriacutea un primer paso que facilitariacutea su aplicacioacuten
bull El manager del proyecto debe ser consciente que la fase de pruebas con Model Based Testing comienza
desde la toma de requisitos ya que se debe modelar el comportamiento del sistema bajo pruebas a partir
de estos Por tanto no se puede esperar que la fase de pruebas comience despueacutes del desarrollo Hacerlo
tras el desarrollo podriacutea significar la modificacioacuten de los requisitos y en consecuencia el desarrollo
39
22 Gestioacuten de Calidad Software
221 Introduccioacuten
En los uacuteltimos antildeos la creciente demanda de productos software principalmente de aplicaciones distribuidas
como los servicios Web provoca que diferentes empresas busquen soluciones software para satisfacer las
necesidades de los clientes Este conjunto de empresas forma un entorno competitivo en el que se intenta buscar
algunos factores para destacar sobre los demaacutes competidores respondiendo a las nuevas exigencias del mercado
Bajo este contexto se plantea la implantacioacuten de una direccioacuten basada en la calidad como la propuesta que
mejores resultados ha ofrecido No solo basta con desarrollar software acorde a los requisitos de los clientes y
las exigencias de los mismos sino que se trata de crear un producto que garantice su correcto funcionamiento
bajo el sustento de una garantiacutea de calidad razonable
El concepto de ldquocalidadrdquo siempre se ha relacionado con la inspeccioacuten de productos fiacutesicos Pero dicho teacutermino
ha ido expandiendo su contexto de una forma maacutes global y aplicable a cualquier tipo de servicio o producto
ofrecido a un cliente
222 Concepto de Calidad
Acorde a la definicioacuten ofrecida por la Real Academia Espantildeola (RAE) la calidad se define como ldquouna propiedad
o conjunto de propiedades inherente a algordquo ldquoAdecuacioacuten de un producto o servicio a las caracteriacutesticas
especificadasrdquo o ldquocondicioacuten o requisito que se pone en un contratordquo [6]
Por otro lado el instituto de Ingenieros Eleacutectricos y Electroacutenicos (IEEE) define la calidad como ldquoel grado con
el que un sistema componente o proceso cumple con los requisitos especificados y las necesidades o
expectativas del cliente o usuariordquo destacando que el eacutenfasis radica en los requisitos especiacuteficos del sistema y
en la buacutesqueda de la satisfaccioacuten del cliente [7]
Roger Pressmann define la Calidad del Software como ldquoConcordancia del software producido con los requisitos
expliacutecitamente establecidos con los estaacutendares de desarrollo prefijados y con los requisitos impliacutecitos no
establecidos formalmente que desea el cliente y en uacuteltima instancia el usuariordquo [8]
Una vez presentado el concepto de calidad su definicioacuten orientada al software se refiere al grado de desempentildeo
de las principales caracteriacutesticas con las que debe cumplir un sistema durante su ciclo de vida Estas
caracteriacutesticas son las que garantizan que el cliente cuente con un sistema confiable lo que permite un aumento
de la satisfaccioacuten frente a la funcionalidad y eficiencia del sistema construido
Figura 7 Concepto de Calidad
40
223 Modelos de Calidad de Software
Los modelos de calidad son aquellos documentos que integran la mayor parte de las mejores praacutecticas proponen
temas de administracioacuten en los que cada organizacioacuten debe hacer eacutenfasis integran diferentes praacutecticas dirigidas
a los procesos clave y permiten medir los avances en calidad
Bajo este contexto los modelos de calidad deben permitir la evaluacioacuten del sistema de forma cualitativa o
cuantitativa y de acuerdo con esta evaluacioacuten la organizacioacuten podraacute proponer implementar estrategias que
permitan la mejora continua en el resto de etapas del ciclo de vida como son las etapas de anaacutelisis disentildeo
desarrollo y pruebas software [7] Desde finales de los antildeos 70 se han ido desarrollando diversos modelos de
calidad del producto software con el fin de fijar una terminologiacutea y entender queacute concepto de calidad se estaacute
usando Asiacute mismo dichos modelos de calidad se clasifican de acuerdo con el enfoque de evaluacioacuten
contemplado ya sea a nivel de proceso producto o calidad de uso
2231 Calidad a Nivel de Proceso
Este enfoque de calidad de software describe que la calidad de un sistema software debe ser implementada desde
el inicio del proyecto y en cada etapa de su ciclo de vida debiendo permitir el control y seguimiento de los
aspectos de calidad para minimizar los riesgos y ofrecer un soporte continuo De esta forma se consigue
garantizar un nivel oacuteptimo de cumplimiento de los factores de calidad definidos teniendo en cuenta que si en
alguna etapa no se verifican dichos factores posiblemente disminuya el nivel de calidad no solo del proceso si
no tambieacuten del producto en desarrollo [7]
A continuacioacuten se muestra una liacutenea de tiempo de algunos modelos a nivel de proceso y se describen dos de los
que maacutes intereacutes presentan dentro del aacutembito de este proyecto
Figura 8 Liacutenea de tiempo de modelos a nivel de proceso
ITIL (Information Technology Infrastructure Library)
Desarrollado en el Reino Unido con el fin de fortalecer la gestioacuten gubernamental a partir de cinco elementos
fundamentales la perspectiva del negocio entrega del servicio soporte del servicio manejo de la infraestructura
y manejo de aplicaciones con el propoacutesito de ofrecer una estructura integral para prestar a la organizacioacuten un
servicio completo cubriendo necesidades de apoyo de instalacioacuten adecuacioacuten de redes comunicaciones
hardware servidores sistema operativo y software necesarios
Figura 9 Logo de ITIL
41
ISOIEC 20000
El objetivo principal de esta norma es avalar que la prestacioacuten de servicios de TI en una empresa cuenta con la
calidad necesaria para brindar dichos servicios a los clientes Esta norma engloba diferentes secciones dedicadas
a las especificaciones de dicha norma y a los coacutedigos de buenas praacutecticas
Figura 10 ISOIEC 20000
WebQEM
Web-site Quality Evaluation Method se trata de una metodologiacutea de evaluacioacuten de calidad de sitios Web en seis fases planificacioacuten y programacioacuten de la evaluacioacuten de la calidad definicioacuten y especificacioacuten de los requisitos de calidad establecidos definicioacuten e implementacioacuten de la evaluacioacuten elemental definicioacuten e implementacioacuten de la evaluacioacuten global anaacutelisis de resultados y evaluacioacuten de meacutetricas y finalmente conclusiones y documentacioacuten
Figura 11 Logo de WebQEM
42
2232 Calidad a Nivel de Producto
El enfoque de la calidad de software a nivel de producto tiene como objetivo especificar y evaluar el
cumplimiento de los criterios del producto Para ello se suelen definir y aplicar medidas o meacutetricas internas o
externas Por esta razoacuten muchas normas definen la calidad a nivel de producto de tipo interna externa y en uso
Esta uacuteltima se define como el conjunto de atributos relacionados con la aceptacioacuten por parte del usuario final y
seguridad
A continuacioacuten se muestra una liacutenea de tiempo de algunos modelos a nivel de proceso y se describen tres de los
que maacutes intereacutes presentan dentro del aacutembito de este proyecto
Figura 12 Liacutenea de tiempo de modelos a nivel de producto
ISO 9126
Este se basa en el modelo McCall el cual es uno de los modelos pioneros en la evaluacioacuten de la calidad de
software Desarrollado en 1991 es un marco normativo dirigido a desarrolladores aseguradores de calidad
evaluadores analistas y cualquier otro involucrado en el proceso de construccioacuten de software y la gestioacuten de
calidad del mismo Estaacute dividido en cuatro partes Modelo de Calidad Meacutetricas Externas Meacutetricas Internas y
Calidad de Meacutetricas en Uso
Esta norma busca la fiabilidad funcionalidad usabilidad eficiencia mantenibilidad y portabilidad en la
construccioacuten de productos software A continuacioacuten se muestra un esquema que resume dichas caracteriacutesticas
y subcaracteriacutesticas [8]
Figura 13 Esquema de ISO 9126
43
ISOIEC 25000
Basada en la norma ISO 9126 y adaptando parte del marco normativo a las necesidades del mercado actual Esta
norma tambieacuten conocida como SQuaRE (Software Product Quality Requirements and Evaluation) establece
un marco de trabajo comuacuten para evaluar la calidad de productos de Software
En dicha norma se definen los modelos teacuterminos y definiciones comunes para el resto de normas que componen
la serie 25000 La ISOIEC 25000 presenta diversas secciones entre las que se puede destacar [9]
ISOIEC 25010 Describe las caracteriacutesticas y subcaracteriacutesiticas de calidad que pueden ser evaluadas
en un producto software diferenciando entre calidad interna externa y de uso En la siguiente figura se
presenta un desglose de dichas caracteriacutesticas
ISOIEC 25040 Define el proceso de evaluacioacuten perioacutedico de la calidad del producto software
Figura 14 Esquema de ISOIEC 25000
44
224 Principales Ventajas e Inconvenientes de Modelos de Calidad anteriores
2241 A nivel de Proceso
Modelo Ventajas Inconvenientes
ITIL bull Mejor estructuracioacuten organizacioacuten y
claridad de los proyectos
bull Mayor control administrativo
bull Mayor eficacia y rapidez ante cambios
bull Incrementa la productividad del negocio y la
fiabilidad de los clientes
bull Tiempo y esfuerzo necesarios
bull Falta de conocimiento para apreciar la mejora
proporcionada
bull Involucracioacuten y compromiso de todo el
personal de la organizacioacuten
bull Frustracioacuten generada por expectativas a corto
plazo
bull No hay mejoriacutea si la inversioacuten asignada para
implantar el modelo es insuficiente
ISOIEC
20000 bull Reconocimiento internacional
bull Muy usado por las organizaciones
WebQUEM bull Calidad medida en fases y actividades de
forma cuantitativa con indicadores
bull Aplicaciones de Software centradas en la Web
son cada vez maacutes complejas provocan mayor
complejidad en su implantacioacuten
2242 A nivel de Producto
Modelo Ventajas Inconvenientes
ISO 9126 bull Determina queacute caracteriacutesticas y
subcaracteriacutesticas son importantes para el
producto
bull Define meacutetricas especiacuteficas para los
componentes Software
bull Define indicadores para las caracteriacutesticas de
calidad
bull Usabilidad tratada desde la perspectiva del
proceso no del producto
bull No tiene en cuenta la caracteriacutestica de ldquofacilidad
de aprendizajerdquo siendo esta recomendada por
otros estaacutendares
bull Meacutetricas complejas difiacutecilmente medibles
Requieren descomposicioacuten
ISOIEC
25000 bull Detecta objetivos del producto alineados con
necesidades reales de clientes finales
bull Evita ineficiencias y maximiza rentabilidad
y calidad del producto
bull El proceso de evaluacioacuten perioacutedica permite
la mejora continua
bull No establece niveles de calidad para cada
proyecto
bull No hace uso de meacutetricas o umbrales de calidad
225 Conclusiones
Una vez presentado el concepto de gestioacuten de calidad de software y los principales modelos y normas es
interesante destacar la diferencia entre calidad interna y externa La calidad interna se centra en las caracteriacutesticas
propias del producto software (disentildeo especificacioneshellip) mientras que la calidad externa lo hace con las
caracteriacutesticas dinaacutemicas del mismo es decir con el comportamiento Es por ello que el proceso de calidad
interna se inicia en las fases tempranas del ciclo de vida de un proyecto mientras la calidad externa se aplica
una vez se tiene un primer prototipo funcional del producto software desarrollado Por tanto se trataraacute de
automatizar el proceso de evaluacioacuten de la calidad externa del proyecto CHT Cloud Manager analizando
verificando y validando automaacuteticamente la aceptacioacuten de dicho producto
45
46
3 MARCO TEOacuteRICO PRUEBAS DE SOFTWARE
ras presentar el concepto de calidad y algunas de las normas y estaacutendares maacutes conocidos que describen
la aplicacioacuten de dicho concepto en el aacutembito del desarrollo de software se centraraacute el enfoque en el
papel del testeo y las pruebas de software Con ello se destacaraacuten algunos puntos principales para
llevar a cabo las pruebas de software el anaacutelisis disentildeo e implementacioacuten de dichas pruebas los diferentes tipos
y niveles de pruebas y las dificultades de la aplicacioacuten de pruebas de software sobre aplicaciones Web
31 Testing y Pruebas de Software
Habitualmente se tiene una percepcioacuten del testing de un producto como una tarea basada en la ejecucioacuten de
pruebas de forma repetitiva para la buacutesqueda de errores o problemas que puedan repercutir sobre la calidad del
mismo Pero el testing no solo se basa en la realizacioacuten de pruebas
Se deben identificar otras tareas que estaacuten relacionadas con el testing las cuales se llevan a cabo antes y despueacutes
de la ejecucioacuten de pruebas Estas tareas estaacuten relacionadas principalmente con la planificacioacuten y control del
proceso de pruebas el disentildeo de los diferentes casos de prueba o test cases y la posterior comprobacioacuten de los
resultados obtenidos tras llevar a cabo las pruebas Otras tareas podriacutean ser la propia evaluacioacuten de los diferentes
criterios de finalizacioacuten del proceso de pruebas el anaacutelisis de informes de resultados o la revisioacuten de la
documentacioacuten generada en la fase de pruebas
A continuacioacuten se citan algunas definiciones para explicar el concepto de pruebas de software
ldquoUna prueba es una actividad ejecutada para evaluar la calidad del producto software y mejorarlo mediante
la identificacioacuten de problemas errores o defectos en su funcionamiento [9]rdquo
ldquoLas pruebas de Software consisten en verificaciones dinaacutemicas del comportamiento del software bajo
pruebas mediante un conjunto finito de casos de prueba seleccionadas adecuadamente sobre un dominio
infinito de casos posibles [1]rdquo
Atendiendo a las definiciones presentadas las pruebas de software son dinaacutemicas porque se puede ejecutar el
software bajo pruebas con un conjunto de valores de entrada especiacuteficos para encontrar fallos en su
comportamiento Por otro lado la realizacioacuten de pruebas exhaustivas no es posible para la mayoriacutea de los
productos software reales debido a la gran cantidad de entradas posibles para cada operacioacuten entradas invaacutelidas
o no esperadas y las infinitas secuencias de operaciones posibles
Por estas razones para aplicar un proceso de pruebas de software razonable en cuanto a recursos y tiempo de un
proyecto es necesario seleccionar un conjunto abarcable de pruebas Debido a esto la clave estaacute en el criterio
de seleccioacuten de dichas pruebas Una vez ejecutadas las pruebas seleccionadas se debe decidir si el
comportamiento esperado del sistema falla o no Este es el llamado problema del oraacuteculo el cual es resuelto en
la mayoriacutea de los casos de forma manual mediante la inspeccioacuten de los resultados de la prueba
T
La tecnologiacutea no es nada Lo importante es que tengas feacute
en la gente que sean baacutesicamente buenas e inteligentes
y si les das herramientas haraacuten cosas maravillosas con
ellas
Steve Jobs
47
32 Principios de las Pruebas de Software
Una vez presentada la definicioacuten de pruebas de Software se han obtenido algunos detalles que encajan
perfectamente con una serie de principios que han sido establecidos para el testing de productos software seguacuten
ISTQB (International Software Testing Qualifications Board) [10]
Figura 15 Principios de las Pruebas de Software
1 Las pruebas demuestran la presencia de defectos no su ausencia Las pruebas pueden mostrar que
los defectos estaacuten presentes en el producto pero no pueden probar que no haya defectos Por tanto las
pruebas pueden reducir la probabilidad de existencia de defectos en el software pero incluso si no se
encuentran defectos las pruebas no son una garantiacutea total para afirmar la ausencia de defectos en el
producto final
2 Las pruebas exhaustivas son imposibles Probar todas las posibles combinaciones de entradas y
condiciones previas sobre una aplicacioacuten no es factible excepto en casos muy triviales En lugar de
intentar realizar pruebas exhaustivas se debe usar el anaacutelisis de riesgos las teacutecnicas de prueba y las
prioridades ademaacutes de la automatizacioacuten para enfocar los esfuerzos en la fase de pruebas
3 Las pruebas tempranas ahorran tiempo y dinero Para una deteccioacuten temprana de errores y defectos
las actividades de pruebas deben iniciarse lo antes posible en el ciclo de vida del desarrollo del software
De esta forma se consigue una reduccioacuten de costes ya que cuanto maacutes tarde se detecte un defecto maacutes
costoso y difiacutecil seraacute corregirlo
4 Los defectos se agrupan Generalmente una pequentildea parte del software desarrollado concentra la
mayor complejidad del mismo por lo que la mayoriacutea de los defectos detectados tienen una mayor
probabilidad de encontrarse en esos elementos maacutes complejos Por tanto la realizacioacuten de un buen
anaacutelisis de riesgos permite enfocar el esfuerzo de pruebas en las aacutereas del producto con mayor
probabilidad de presentar defectos
Aplicando el Principio de Pareto al control de calidad [11] el 80 de los errores y defectos estaacute causado
por un 20 del total del producto software desarrollado lo cual podriacutea ser un buen principio sobre el
que basar el anaacutelisis de riesgos
5 Cuidado con la paradoja del pesticida Si las mismas pruebas se repiten una y otra vez con el tiempo
los mismos casos de pruebas ya no encontraraacuten nuevos defectos lo cual no quiere decir que la aplicacioacuten
presente una ausencia completa de los mismos (Las pruebas ya no son eficaces para detectar defectos
al igual que los pesticidas ya no son eficaces para matar insectos despueacutes de un tiempo) Para detectar
nuevos defectos es necesario que las pruebas existentes y los datos de las pruebas deban cambiar
ademaacutes de surgir la necesidad de disentildear nuevas pruebas
48
6 Las pruebas dependen del contexto Cada empresa organizacioacuten o proyecto adaptaraacute el proceso de
pruebas a sus necesidades recursos disponibles o aacutereas de riesgo existentes
7 La ausencia de errores es una falacia Un producto software puede tener un 100 de casos de eacutexito
en su fase de pruebas pero esto solo indica que hay defectos que auacuten no han sido localizados e
identificados
33 Proceso de Pruebas de Software Anaacutelisis disentildeo e implementacioacuten
Partiendo de los principios detallados en la seccioacuten anterior se presentan las diferentes etapas del proceso de
pruebas de software asiacute como la documentacioacuten generada en cada etapa
331 Terminologiacutea
Previamente se presentaraacuten algunos teacuterminos y definiciones que convienen describir para una mejor
comprensioacuten de todo el proceso de pruebas [3]
Figura 16 Terminologiacutea para el proceso de pruebas
1 Condicioacuten de prueba Elemento o evento de un componente o sistema que puede ser verificado por
uno o maacutes casos de prueba Los diferentes requisitos que definen la funcionalidad de un sistema pueden
ser descompuestos en diferentes condiciones de prueba
2 Caso de prueba conjunto de valores de entrada precondiciones de ejecucioacuten y valores esperados
Estos son desarrollados para perseguir un objetivo particular por ejemplo una condicioacuten de prueba
3 Precondicioacuten Condiciones de entorno y estado que deben ser satisfechas antes de que un componente
o sistema pueda ser sometido a un caso de prueba o conjunto de estos
4 Abstraccioacuten de casos de prueba Consiste en la generalizacioacuten de los casos de prueba especiacuteficos sin
valores concretos para sus entradas condiciones de prueba o valores esperados En resumen no es maacutes
que llevar las condiciones de prueba a un caso general para cualquier valor de entrada
5 Script de pruebas Una vez disentildeados los casos de prueba estos pueden ser implementados y
ejecutados por una herramienta de automatizacioacuten Un script de pruebas puede contener varios casos
de prueba
6 Paquete de pruebas Consiste en la agrupacioacuten de casos de prueba relacionados en cuanto a la
funcionalidad que automatizan sobre el sistema
7 Programacioacuten de la ejecucioacuten de pruebas Describen el flujo de ejecucioacuten de los diferentes paquetes
de pruebas
49
332 Proceso de Pruebas de Software
No existe un proceso de pruebas universal pero existen conjuntos comunes de actividades de prueba sin las
cuales las pruebas disentildeadas e implementadas tendriacutean menos probabilidad de alcanzar sus objetivos
establecidos Estos conjuntos de actividades de prueba constituyen un proceso de pruebas
Como se ha mencionado en secciones anteriores el proceso de pruebas se debe iniciar en las fases maacutes iniciales
del ciclo de vida de un proyecto Por tanto las actividades del proceso de pruebas la manera en que se
implementan dichas actividades y cuaacutendo ocurren pueden ser discutidas en la estrategia de pruebas de una
organizacioacuten
A continuacioacuten se exponen las etapas fundamentales del proceso de pruebas detallando en cada una de ellas la
documentacioacuten generada y coacutemo contribuyen a la mejora de la calidad del producto con su aplicacioacuten en el ciclo
de vida de un proyecto [13]
Figura 17 Proceso de Pruebas de Software
3321 Planificacioacuten y Control de Pruebas
La planificacioacuten consiste en determinar los diferentes objetivos de las pruebas realizadas sobre el Sistema bajo
test las especificaciones y los recursos que se necesitaraacuten para llevar a cabo la fase de pruebas y cumplir con los
objetivos planteados
Es en este punto donde se define el alcance de las pruebas a realizar de forma que se selecciona lo que seraacute y
no seraacute testeado ademaacutes de indicar quieacuten haraacute cada prueba y como la llevaraacute a cabo Mediante los objetivos de
las pruebas se puede establecer un punto de finalizacioacuten del proceso
Como salida de la actividad de planificacioacuten se obtendriacutea el ldquoPlan de Pruebasrdquo el cual documenta la estrategia
y el alcance de las pruebas la prioridad en cuanto a su realizacioacuten y las estimaciones temporales para su
evaluacioacuten ademaacutes de los recursos materiales y humanos para llevarlas a cabo
Es crucial que dicho documento sea validado por el personal correspondiente del proyecto antes de continuar
con las siguientes etapas del proceso de pruebas
Por otro lado el control de pruebas es una actividad desarrollada durante todo el ciclo de vida del proceso de
pruebas el cual permite contrastar el progreso actual con el plan original trazado para la aplicacioacuten de dicho
proceso incluyendo informes y desviaciones
Cuando se produce una desviacioacuten del plan original que introduce cierto riesgo adicional puede hacerse
necesario modificar los objetivos fijados para asegurar la calidad del producto De ahiacute que sea sumamente
importante tener en consideracioacuten la documentacioacuten generada en antiguos proyectos
50
3322 Anaacutelisis y Disentildeo de Pruebas
Una vez planificado el alcance y objetivos de las pruebas se realiza una actividad de anaacutelisis donde se traducen
a condiciones de prueba y posteriormente se disentildean los casos de prueba de alto nivel a partir de la abstraccioacuten
de los casos de prueba
Por otro lado cabe destacar la necesidad de un mecanismo que garantice la trazabilidad con la finalidad de
mantener alineados en todo momento los casos de prueba con los objetivos de la misma incluso contemplando
la posibilidad de que los objetivos puedan cambiar en alguacuten momento del proceso de pruebas
El documento generado en esta actividad es conocido como ldquoespecificaciones de disentildeo de pruebasrdquo
3323 Implementacioacuten y Ejecucioacuten de Pruebas
Dicha etapa consiste en la implementacioacuten de los casos de prueba de alto nivel que cumplen con las
especificaciones de disentildeo de la etapa anterior Es en esta fase donde se haraacute uso de herramientas para la
implementacioacuten y ejecucioacuten de las pruebas
Cabe destacar que para llevar a cabo dicha etapa en cuanto a la verificacioacuten y validacioacuten funcional de un
proyecto es necesario que durante la etapa de desarrollo se haya creado un producto funcional sobre el cual
puedan ejecutarse las pruebas
Durante la ejecucioacuten de las pruebas los resultados obtenidos quedaraacuten documentados en un documento
denominado ldquoRegistro de Pruebasrdquo el cual contiene todas las pruebas realizadas y un ldquoReporte de Incidenterdquo
por cada resultado no esperado que se haya detectado
Una vez sean corregidos los incidentes se debe volver a ejecutar las pruebas con la finalidad de asegurar que
dicho incidente haya sido corregido ademaacutes de asegurar que la correccioacuten realizada no haya introducido otros
defectos o errores Esto es lo que se denomina ldquoPruebas de Regresioacutenrdquo
3324 Evaluacioacuten de los criterios de eacutexito y Elaboracioacuten de reportes e informes
Tras la ejecucioacuten de las pruebas se deben evaluar los criterios de eacutexito los cuales han sido definidos en la etapa
de planificacioacuten
El personal responsable e involucrado en el proyecto se reuniraacute y revisaraacute el cumplimiento de dichos criterios
el registro de pruebas obtenido y los reportes de incidentes que hayan podido ser abiertos en la etapa anterior
Finalmente como resultado de dicha actividad se elabora un ldquoSumario final de Pruebasrdquo
3325 Cierre de la fase de pruebas
Las actividades de cierre de la fase de pruebas se centran mayormente en asegurar que todo el ciclo de vida del
proceso de pruebas se ha cumplido ademaacutes de analizar las posibles mejoras y defectos en las fases llevadas a
cabo
Ademaacutes se lleva a cabo el cierre de los incidentes corregidos y la liberacioacuten de los entornos y recursos asignados
a la fase de pruebas
51
34 Clasificacioacuten de Pruebas de Software
Existen diversos tipos de pruebas las cuales pueden ser clasificadas en funcioacuten del objetivo de prueba para lo
cual hayan sido establecidos Cada tipo de prueba persigue unos objetivos especiacuteficos sobre el producto pero
todas ellas persiguen como objetivo comuacuten ofrecer un producto con garantiacutea de calidad al cliente o usuario final
Dichas pruebas pueden ser clasificadas en cuatro tipos
Figura 18 Clasificacioacuten de Pruebas de Software
341 Pruebas Funcionales
Tambieacuten conocidas como ldquoPruebas de caja Negrardquo En [14] la IEEE define este tipo de pruebas como
ldquoPruebas que ignoran los mecanismos internos de un sistema o componente y se enfocan
solamente en las salidas generadas como respuesta a las entradas seleccionadas y a las
condiciones de ejecucioacutenrdquo
Figura 19 Pruebas de Caja Negra
Atendiendo a la definicioacuten anterior el sistema o componente sujeto a pruebas debe realizar una funcioacuten
determinada Estaraacute descrita en las especificaciones funcionales y se pueden llevar a cabo a cualquier nivel
Dichas especificaciones funcionales describen el comportamiento del sistema sin revelar informacioacuten acerca de
su implementacioacuten interna
Un tipo especial de prueba funcional son las ldquoPruebas de Humordquo o ldquoSmoke Testsrdquo Este tipo de pruebas suele
realizarse en fases tardiacuteas del desarrollo y permiten asegurar que las funcionalidades baacutesicas del software
responden adecuadamente
Por tanto dichas pruebas pueden quedar lejos de ser pruebas exhaustivas aunque siacute permiten asegurar que el
producto entregado al cliente cumple con los requisitos de funcionamiento establecidos Este tipo de pruebas
son las que se han implementado y automatizado en el proyecto presente lo cual se detallaraacute en capiacutetulos
posteriores
52
342 Pruebas No Funcionales
Este tipo de pruebas estaacuten orientadas a verificar coacutemo de bien funciona el sistema bajo pruebas en lugar de la
funcionalidad que ofrece Por ello pueden ser agrupadas tambieacuten dentro de la categoriacutea de pruebas de caja negra
Atendiendo al estaacutendar de evaluacioacuten del producto software ldquoISO 25000rdquo todas las caracteriacutesticas excepto la de
funcionalidad definen caracteriacutesticas de calidad no funcionales de un producto software Estas caracteriacutesticas de
calidad tienen su correspondiente tipo de prueba
3421 Pruebas de Rendimiento
Las pruebas de rendimiento son usadas para determinar la rapidez con la que se realiza una tarea en el sistema
bajo unas condiciones particulares de trabajo Estas pruebas tambieacuten pueden ser usadas para validar y verificar
otros atributos de calidad del sistema tales como la escalabilidad fiabilidad y uso de recursos
Figura 20 Pruebas de Rendimiento
3422 Pruebas de Carga
Este tipo de pruebas miden el rendimiento del sistema con una carga de trabajo manejable y conocida Se trata
de someter al sistema a cargas de trabajo controladas por el ingeniero de pruebas para validar prestaciones de
rendimiento sobre el sistema
Figura 21 Pruebas de Carga
3423 Pruebas de Estreacutes
Las pruebas de estreacutes ponen a prueba la robustez y confiabilidad del sistema sometieacutendolo a condiciones de uso
extremas Entre estas condiciones se incluyen el enviacuteo masivo de peticiones y la ejecucioacuten en condiciones de
hardware limitadas Dichas condiciones van maacutes allaacute de los liacutemites de operacioacuten considerados en el disentildeo
Figura 22 Pruebas de Estreacutes
53
3424 Pruebas de Usabilidad
Estas pruebas se centran en encontrar problemas de la interfaz de usuario que podriacutean hacer que el software sea
difiacutecil de utilizar o podriacutean causar que los usuarios mal interpreten las salidas Por tanto permiten medir coacutemo
de atractivo resulta un producto software basaacutendose en la facilidad de adaptacioacuten y uso por parte de los clientes
Figura 23 Pruebas de Usabilidad
3425 Pruebas de Fiabilidad
Prueban el rendimiento del sistema ante un determinado nuacutemero de operaciones o tras cierto periodo de
tiempo
3426 Pruebas de Instalacioacuten
Las pruebas de instalacioacuten tienen dos propoacutesitos El primero es asegurar que el sistema puede ser instalado
en todas las configuraciones posibles tales como nuevas instalaciones actualizaciones instalaciones
completas o personalizadas y bajo condiciones normales o anormales estas uacuteltimas incluyen insuficiente
espacio en disco falta de privilegios para algunas tareas etc
El segundo propoacutesito es verificar que una vez instalado el sistema opera correctamente Esto usualmente
implica ejecutar un nuacutemero significativo de pruebas de Funcionalidad
Por tanto miden coacutemo de sencillo resulta instalar la aplicacioacuten en distintas plataformas o entornos
3427 Pruebas de Portabilidad
Miden coacutemo de sencillo resulta migrar una aplicacioacuten de una plataforma a otra
Figura 24 Pruebas de Portabilidad
54
343 Pruebas Estructurales
Este tipo de pruebas son tambieacuten conocidas como ldquoPruebas de Caja Blancardquo En [14] la IEEE define este tipo
de pruebas como
ldquoPruebas que tienen en cuenta los mecanismos internos de un sistema o componenterdquo
Figura 25 Pruebas de Caja Blanca
Atendiendo a dicha definicioacuten estas pruebas tienen en cuenta la estructura del coacutedigo fuente del software a partir
del cual se seleccionan los diferentes casos de prueba guiaacutendose por la existencia de sentencias condicionales
bucles etc
Por tanto los casos de prueba son desarrollados usando criterios de cobertura para el coacutedigo del programa De
esta forma el sistema bajo pruebas se trata como una caja de cristal que permite ver su estructura
El criterio de cobertura hace referencia a cada miacutenima unidad de coacutedigo que puede ser probada de forma
independiente Es frecuente usar este tipo de pruebas en los niveles de prueba maacutes bajos como por ejemplo en
las ldquoPruebas Unitariasrdquo o las ldquoPruebas de Componenterdquo
344 Pruebas debidas a Cambios
Finalmente en el proceso de pruebas tras ejecutar las pruebas y encontrar un defecto o error en el sistema bajo
pruebas este se corrige pero es necesario validar la correccioacuten realizada para confirmar que el fallo no se
reproduce A este proceso se le denomina ldquoPrueba de confirmacioacuten o re-testingrdquo
Ademaacutes las correcciones pueden ser validadas pero tambieacuten es necesario asegurar que los cambios introducidos
para corregir dicho fallo no han provocado maacutes defectos Por tanto puede concluirse que es necesario volver a
realizar pruebas sobre el resto del sistema Estas son las ldquoPruebas de Regresioacutenrdquo
35 Niveles de Prueba
El proceso de pruebas es una etapa del ciclo de vida de un proyecto cuyas actividades estaacuten completamente
relacionadas con las actividades del proceso de desarrollo Existen diversos modelos que describen las fases y
actividades del proceso de desarrollo de software En esta seccioacuten se detallaraacute el uso del ldquoModelo de desarrollo
en Vrdquo
Este modelo describe las diferentes fases del proceso de desarrollo y sugiere la realizacioacuten de pruebas en cada
una de ellas Estas pruebas seraacuten ejecutadas posteriormente en orden ascendente Por tanto para cada fase existen
unos objetivos a cumplir los cuales deben ser probados para medir la integridad del trabajo realizado
55
A continuacioacuten se detallaraacuten los diferentes niveles de prueba para cada etapa del desarrollo software atendiendo
al modelo de desarrollo en V
Figura 26 Modelo de desarrollo en V
351 Pruebas a Nivel de Componente
Tambieacuten llamadas ldquoPruebas Unitariasrdquo El objetivo de estas pruebas es el de cubrir la unidad miacutenima funcional
que compone el software Estos componentes suelen tener una uacutenica funcioacuten especiacutefica la cual seraacute usada por
el resto del Sistema A menudo son realizadas por los propios desarrolladores haciendo uso de la metodologiacutea
de desarrollo guiado por prueba o Test-Driven-Development (TDD)
352 Pruebas a Nivel de Integracioacuten
Son aquellas pruebas realizadas en el aacutembito del desarrollo software una vez validadas las pruebas unitarias
Estas pruebas verifican que todos los elementos unitarios que componen el software funcionan en conjunto de
forma correcta Se centran principalmente en probar la comunicacioacuten entre los diferentes componentes del
sistema
353 Pruebas a Nivel de Aceptacioacuten
Este uacuteltimo nivel se centra en las necesidades del usuario requisitos y procesos de negocio con el fin de
determinar si el sistema satisface los criterios de aceptacioacuten acordados con el cliente en un contrato o acuerdo
de nivel de servicio en caso de ser un software de uso interno dentro de una compantildeiacutea
Ejemplos de este tipo de pruebas pueden ser las ldquoPruebas Alfa y Betardquo
Como se ha detallado anteriormente las pruebas desarrolladas y automatizadas en este Proyecto son ldquoPruebas
de humordquo o Smoke Tests Estas pruebas se centran en la verificacioacuten y validacioacuten de las especificaciones de uso
de un Sistema en este caso de la plataforma Web de gestioacuten Galgus CHT Manager
56
36 Dificultades de pruebas en aplicaciones Web e impacto
La complejidad antildeadida de las aplicaciones y servicios Web frente a otros tipos de aplicaciones recae sobre el
uso de muacuteltiples tecnologiacuteas de vanguardia que permiten la construccioacuten de sistemas distribuidos con un amplio
grado de escalabilidad accesibilidad disponibilidad interoperabilidad e independencia del hardware
Como consecuencia del incremento de la complejidad de las aplicaciones surgen nuevos paradigmas como la
Arquitectura Orientada a Servicios (SOA) la cual permite interoperabilidad y flexibilidad de las aplicaciones
distribuidas
Todo ello conlleva a plantearse queacute se deberiacutea hacer para garantizar que una aplicacioacuten Web puesta en marcha
funciona de acuerdo a los requisitos definidos y acordados con el cliente Podriacutean optimizarse y mejorarse los
diferentes procesos dentro del ciclo de vida de un proyecto pero siempre la fase de pruebas termina siendo la
fase previa a la puesta en marcha de la aplicacioacuten con lo que resulta siendo la uacuteltima oportunidad para detectar
posibles fallos que puedan terminar en ocasiones en peacuterdidas econoacutemicas de prestigio de fiabilidad y de
credibilidad por parte de los clientes
Realizar pruebas en una aplicacioacuten Web no es tarea faacutecil ya que son muchos los factores que influyen en el
testeo del sistema para abarcar y contemplar el maacuteximo de flujos posibles que se pueden llevar a cabo durante
el uso de la aplicacioacuten
Hoy en diacutea las aplicaciones Web pueden ser construidas con componentes implementados en diferentes
lenguajes y arquitecturas basaacutendose en diferentes modelos de programacioacuten y pudiendo ejecutarse en diferentes
plataformas de hardware y software
Esto incrementa la complejidad de las pruebas a realizar sobre un sistema de este tipo por lo que seriacutea interesante
plantearse la posibilidad de usar herramientas que permitan una abstraccioacuten de dicha complejidad ademaacutes de la
automatizacioacuten de la fase de pruebas En el caso de las pruebas a nivel de aceptacioacuten en este proyecto se
propondraacute el uso de herramientas que persiguen dichos fines
Figura 27 Dificultades de pruebas en aplicaciones Web e impacto
57
58
4 SISTEMA GALGUS CHT CLOUD MANAGER
ras realizar un estudio del arte sobre una teacutecnica que puede ser de gran utilidad para optimizar y
perfeccionar las teacutecnicas de automatizacioacuten para el proceso de pruebas sobre un sistema se han puesto
en contexto los diferentes tipos de pruebas que pueden realizarse sobre un sistema ademaacutes de definir
el proceso de pruebas Una vez llegados a este punto en primer lugar se realizaraacute una descripcioacuten del sistema
bajo pruebas sobre el cual se plantearaacute una solucioacuten para la fase de pruebas y su automatizacioacuten Maacutes
concretamente para la realizacioacuten de las pruebas a nivel de aceptacioacuten
41 Arquitectura y Descripcioacuten del Sistema
CHT Cloud Manager es un proyecto de la empresa Galgus el cual ofrece una plataforma Web de gestioacuten
configuracioacuten y monitorizacioacuten de redes WiFi Maacutes concretamente dicha plataforma permite gestionar un
conjunto de puntos de acceso desplegados con un conjunto de algoritmos definidos por software los cuales
permiten la optimizacioacuten de los recursos de red inalaacutembricos ofreciendo mayores prestaciones y una mayor
calidad de servicio al usuario Ademaacutes dicho software embebido ofrece otros servicios al cliente como la
localizacioacuten de estaciones dentro de la zona de alcance de la red WiFi o la deteccioacuten de intrusos y ataques de
suplantacioacuten de identidad
A este conjunto de algoritmos se le conoce bajo el nombre Cognitive Hostpot Technology (CHT) Este software
implementado en lenguaje C y preparado para sistemas embebidos como los puntos de acceso presenta una
estructura modular donde cada moacutedulo se encarga de una tarea determinada o de ejecutar un algoritmo
determinado
Figura 28 Logo de Galgus
Para permitir la comunicacioacuten con la plataforma Web CHT implementa un moacutedulo denominado MGR el cual
permite la conexioacuten con un broacuteker de eventos o intermediario para permitir el enviacuteo y la recepcioacuten de eventos
desde dicha plataforma
T
La simplicidad llevada al extremo se convierte en
elegancia
Jon Franklin
59
En la siguiente figura se muestra la arquitectura orientada a servicios para CHT Cloud Manager
Figura 29 Arquitectura de CHT Cloud Manager
Puede observarse que dicha plataforma estaacute formada por diferentes microservicios desplegados en la nube Cada
uno de ellos realiza una serie de tareas bien definidas e interactuacutean entre ellos enviando y recibiendo mensajes
haciendo uso de diferentes protocolos y modelos de comunicacioacuten
De esta forma se consigue mantener actualizado el estado de la informacioacuten de los diferentes elementos en
tiempo real sobre los diferentes eventos que puedan ocurrir en el sistema Dichos eventos proceden en su gran
mayoriacutea del conjunto de puntos de acceso que conforma una red de Galgus la cual pretende ser gestionada desde
la plataforma en cuestioacuten
A continuacioacuten se detallaraacuten los diferentes microservicios que conforman dicha plataforma ademaacutes de describir
a los puntos de acceso con la tecnologiacutea CHT como elementos a gestionar desde dicha plataforma
60
411 Puntos de Acceso (OpenWRT + CHT)
4111 OpenWRT
Los puntos de acceso WiFi de Galgus son sistemas embebidos de diferentes modelos en funcioacuten de las
especificaciones hardware que ofrezcan (nuacutemero de streams espaciales nuacutemero de antenas de exterior de
interior etc)
Todos ellos tienen en comuacuten el uso de OpenWRT como sistema operativo Este se trata de un sistema operativo
open source basado en Linux y usado para sistemas de red embebidos Todos los componentes de dicho sistema
han sido optimizados para dispositivos con limitaciones de hardware y este permite configurarlos mediante
interfaz de liacutenea de comandos o mediante una interfaz Web (LuCI) [15]
Partiendo de dicho sistema operativo Galgus desarrolla CHT como producto software que dota a los puntos de
acceso de una serie de prestaciones en una serie de moacutedulos Dicho producto es ofrecido al cliente mediante
licencias las cuales son gestionadas desde un servidor de licencias y obtenidas por los puntos de acceso de
forma automaacutetica Todo ello se detallaraacute maacutes adelante
4112 CHT
CHT tambieacuten ofrece su propia interfaz de liacutenea de comandos denominada CHT_CLI Esta herramienta permite
configurar los distintos moacutedulos de los que se compone CHT y obtener informacioacuten tanto de la configuracioacuten
como del funcionamiento de los algoritmos CHT
A continuacioacuten se presenta la interfaz y algunos de los comandos que se pueden utilizar
Figura 30 CHT_CLI
CHT_CLI es fundamental tanto en el desarrollo como en el testeo de CHT y CHT Cloud Manager ya que nos
permite acceder a paraacutemetros de configuracioacuten que no estaacuten accesibles desde la interfaz graacutefica LuCI Desde
CHT_CLI se controlan todos los moacutedulos de CHT entre los que se pueden destacar los siguientes Load Balance
(LB) Smart Roaming (SR) Power Control (POWER) Localization (LOC) Traffic Congestion Management
(TCM) Smart Band Steering (SB) y el moacutedulo Manager (MGR)
En este caso es de intereacutes resaltar el moacutedulo que permite la comunicacioacuten con la plataforma de gestioacuten CHT
Cloud Manager Dicho moacutedulo conocido bajo el nombre de MGR implementa un cliente AMQP para
establecer la comunicacioacuten con el broacuteker de eventos usado como intermediario para permitir la comunicacioacuten
entre los puntos de acceso y la plataforma de gestioacuten CHT Cloud Manager
Ademaacutes implementa una serie de estructuras de datos que son enviados a traveacutes de dicho intermediario basadas
en FlatBuffers como plataforma eficiente de serializacioacuten cruzada de datos ofrecida por Google Esta
herramienta permite crear un modelo de datos bajo la sintaxis ofrecida por FlatBuffers para posteriormente
generar dichas estructuras de datos en diferentes lenguajes de programacioacuten como por ejemplo C++ C C
Go Java JavaScript etc
Con esto se consigue generar estructuras de datos con una compatibilidad absoluta que se intercambiaraacuten entre
la plataforma de gestioacuten en lenguaje Java y los puntos de acceso en lenguaje C
61
412 Broacuteker de Eventos AMQP (RabbitMQ)
Este microservicio implementa un broacuteker de eventos que actuacutea como intermediario entre los puntos de acceso
WiFi y algunos microservicios que componen la plataforma Web de gestioacuten Se basa en el protocolo AMQP el
cual sigue el patroacuten publicadorsuscriptor como paradigma de comunicacioacuten indirecta
Estaacute involucrado en la entrega de mensajes entre los diferentes dispositivos embebidos con CHT y sus
respectivos servicios de gestioacuten en la plataforma Web de forma que los agentes que publican y consumen
eventos en el broacuteker no necesitan conocer al destinatario si no que el broacuteker es el que se encarga de publicar los
eventos para los destinatarios suscritos a eacutel En la siguiente figura se muestra la interfaz graacutefica de gestioacuten de
RabbitMQ [16]
Figura 31 Plataforma de Gestioacuten de RabbitMQ
Un broacuteker de eventos es un elemento del patroacuten PublicadorSuscriptor que recibe y mensajes de un conjunto de
elementos de red que quieren comunicarse ejecutan mecanismos de filtrado y permite la entrega correcta de los
diferentes mensajes a los consumidores correspondientes Por tanto el broacuteker de eventos permite ofrecer un
desacoplamiento entre emisores y receptores de la informacioacuten siendo este responsable de las tareas de
encaminamiento y reenvioacute de mensajes En conclusioacuten es responsable de coordinar la comunicacioacuten
proporcionando transparencia de acceso y localizacioacuten permitiendo la localizacioacuten de emisores y receptores
mediante un sistema de identificadores uacutenicos
Figura 32 Patroacuten PublicadorSuscriptor
62
413 Frontend
El Frontend de la plataforma Web estaacute implementado con Angular 6 HTML5 y CSS3 Su finalidad es ofrecer
una interfaz graacutefica al usuario final la cual permite mostrar el estado de los diferentes Zone Managers ademaacutes
de permitir el acceso a estos y gestionar el conjunto de puntos de acceso registrados en ellos de forma raacutepida e
intuitiva
Este microservicio recibe informacioacuten proporcionada por MoMap y los diferentes Zone Managers La
aplicacioacuten se sirve mediante un servidor Apache el cual proporciona una comunicacioacuten fiable con HTTPS
implementando una capa de transporte segura mediante el protocolo TLS
414 Zone Manager
Microservicio responsable de gestionar un conjunto de puntos de acceso CHT los cuales forman un despliegue
de red WiFi de Galgus para un cliente determinado Este microservicio estaacute formado por un servicio Web REST
implementado con Java Spring Framework desplegado en un servidor Jetty embebido y cuya persistencia se ha
implementado a traveacutes de Hybernate con el uso de Postgress SQL como gestor de bases de datos relacional
Un Zone Manager ofrece todas las tareas y acciones necesarias para configurar un conjunto de puntos de acceso
y consultar datos estadiacutesticos de usuarios conectados a dichos puntos de acceso entre otras Cabe destacar en
este punto la importancia que tiene el uso de FlatBuffers para garantizar la compatibilidad de datos enviados y
recibidos entre los puntos de acceso y el Zone Manager ambos implementados en tecnologiacuteas totalmente
diferentes
Figura 33 Ejemplo de Interfaz Graacutefica de un Zone Manager
63
415 MoMap
Dicho microservicio implementado en NodeJS gestiona y administra toda la infraestructura que conforma la
plataforma Web Establece y mantiene todas las conexiones y relaciones entre los diferentes puntos de acceso
con CHT y los Zone Managers (ZMB) que los gestiona
Ademaacutes este microservicio implementa una serie de maacutequinas de estado que permiten controlar el estado de
todos los Zone Managers y puntos de acceso CHT alertando sobre los eventos de error conexioacuten o desconexioacuten
en tiempo real a los usuarios finales a traveacutes del Frontend El soporte a la persistencia para dicho microservicio
se proporciona mediante MongoDB
Por tanto el microservicio MoMap actuacutea como proxy inverso HTTP2 Cuando un usuario intenta acceder a
traveacutes del Frontend de la plataforma Web puede gestionar y administrar un conjunto de Zone Managers o
administrar usuarios y asignar roles y permisos Tambieacuten se permite la creacioacuten eliminacioacuten y conexioacuten con un
Zone Manager redirigiendo las peticiones hacia el mismo
Cuando ocurre un evento de conexioacuten con un Zone Manager desde el microservicio MoMap se recupera y
enviacutea la informacioacuten necesaria para mostrar toda la informacioacuten correspondiente a ese Zone Manager en el
Frontend para el usuario final En la siguiente figura se muestra la interfaz graacutefica ofrecida por el servicio
MoMap a traveacutes del Frontend
Figura 34 Ejemplo de Interfaz Graacutefica de MoMap
64
416 Servidor de Licencias
El objetivo principal de este servicio es proporcionar una aplicacioacuten con una gestioacuten y control centralizado de
las licencias de todos los Puntos de Acceso desplegados con CHT Este servidor desplegado con Jetty de forma
embebida almacena el registro de un conjunto de Puntos de Acceso CHT para un conjunto de Clientes y
proyectos determinados Proporciona una API REST implementada con Java Spring Framework que permite
el registro de dichos dispositivos y la asignacioacuten de licencias CHT para habilitar los diferentes moacutedulos de dicha
aplicacioacuten embebida sobre los Puntos de Acceso Ademaacutes proporciona una interfaz Web de usuario
implementada con Angular 6 HTML5 y CSS3
En la siguiente figura se muestra un ejemplo de dicha interfaz graacutefica
Figura 35 Interfaz Graacutefica del Servidor de Licencias
4161 Zero-Touch Provisioning (ZTP)
En el contexto de la automatizacioacuten de redes WiFi el aprovisionamiento sin contacto es una caracteriacutestica
que permite que los puntos de acceso de una red se configuren automaacuteticamente evitando la intervencioacuten
humana para su configuracioacuten La configuracioacuten manual de dispositivos y conmutadores es costosa y
requiere lo que a menudo puede ser una gran cantidad de tiempo y esfuerzo dependiendo del tamantildeo de la
red [17]
Con el uso de sistemas automaacuteticos de aprovisionamiento y configuracioacuten se consigue reducir la carga de
trabajo y el esfuerzo que normalmente se requiere cuando se instalan y configuran nuevos dispositivos
Figura 36 Zero-Touch Provisioning (ZTP)
65
Haciendo uso de esta caracteriacutestica Galgus implementa en su infraestructura orientada a microservicios
un acceso directo de los Puntos de Acceso al servidor para que soliciten su licencia de CHT
automaacuteticamente de forma que cuando el usuario final vaya a instalar un Punto de Acceso CHT dicho
dispositivo obtendraacute su licencia de forma segura a traveacutes de la API REST del servidor de licencias siempre
y cuando esteacute registrado en el mismo y disponga de licencia sin necesidad de que el usuario intervenga en
dicho proceso
La comunicacioacuten entre los puntos de acceso y el resto de la infraestructura se realiza a traveacutes de un broacuteker
de eventos AMQP con su implementacioacuten en RabbitMQ Debido a esto cuando se crea y asigna licencia
a un dispositivo en el servidor de licencias dicho servidor crea un usuario en RabbitMQ de forma que el
punto de acceso en el momento que obtiene su licencia intentaraacute establecer conexioacuten con el broacuteker para
permitir el intercambio de eventos con los microservicios que lo gestionaraacuten mediante la plataforma CHT
Cloud Manager
Una vez el punto de acceso establece conexioacuten con el broacuteker de eventos este podraacute ser descubierto por el
Zone Manager que lo gestionaraacute El microservicio MoMap se encarga de establecer el descubrimiento de
los puntos de acceso comprobando si el punto de acceso estaacute registrado en el servidor de licencias con
licencia asignada y verificando que el punto de acceso estaacute operativo con conexioacuten a internet
42 Alcance y Objetivos de las pruebas sobre el sistema planteado
Una vez presentada y descrita toda la arquitectura de la plataforma Web ofrecida por Galgus se procederaacute a
detallar los principales objetivos del proceso de pruebas que se pretenderaacute conseguir sobre dicha aplicacioacuten Para
ello inicialmente se presentaraacute en queacute punto se encontraba el proceso de pruebas inicialmente
En este proyecto se ha centrado la atencioacuten en el conjunto de pruebas funcionales realizadas a la aplicacioacuten maacutes
concretamente las pruebas a nivel de aceptacioacuten
Dentro de las pruebas a nivel de aceptacioacuten los ingenieros de prueba hasta ahora habiacutean disentildeado un plan de
pruebas de aceptacioacuten o tests End-to-End los cuales se ejecutaban verificaban y validaban manualmente por
los ingenieros de QA Dicho plan de pruebas estaacute formado por una bateriacutea de casos de prueba a realizar sobre
las diferentes funcionalidades del sistema A continuacioacuten se muestra un fragmento de dicho plan de pruebas
Figura 37 Test Plan de CHT Cloud Manager
Como puede observarse en la figura anterior dicho plan de pruebas contiene un conjunto de casos de prueba
cada uno de ellos con un identificador uacutenico una descripcioacuten algunas especificaciones o detalles necesarios un
indicador de eacutexito o fallo y finalmente la descripcioacuten de los resultados obtenidos
Ademaacutes en dicho test plan se incluye una cabecera y una leyenda para clasificar los distintos resultados
obtenidos en la ejecucioacuten de las pruebas registrar algunos datos de relevancia y tener archivado dicho plan de
pruebas con las versiones de los diferentes microservicios que componen la plataforma Web
66
Figura 38 Leyenda del Test Plan
Figura 39 Control de Versiones del Test Plan
Una vez presentado el estado actual del proceso de pruebas a nivel de aceptacioacuten el nuevo equipo encargado de
evaluar la calidad de la plataforma Web planteoacute la oportunidad de automatizar dicho plan de pruebas Por tanto
el principal objetivo de este proyecto ha sido el de automatizar las actividades de ejecucioacuten y generacioacuten de
reportes de las pruebas de aceptacioacuten automatizadas sobre la aplicacioacuten
Sin embargo las actividades de planificacioacuten disentildeo e implementacioacuten de los diferentes casos de prueba se
realizaraacuten de forma manual haciendo uso de un conjunto de tecnologiacuteas que se usaraacuten para desarrollar la
automatizacioacuten de dichas pruebas Dichas tecnologiacuteas principalmente son Robot Framework Selenium y
Python las cuales se detallaraacuten maacutes adelante
En este punto es donde podriacutea entrar en juego la aplicacioacuten de Model-Based-Testing (MBT) detallado en la
seccioacuten 2 de este proyecto como teacutecnica que permite la abstraccioacuten de la actividad de implementacioacuten del plan
de pruebas mejorando el proceso de pruebas e independizando este de las actividades de desarrollo
En este proyecto queda fuera del alcance la aplicacioacuten de dicha teacutecnica debido a la necesidad de disponer de un
disentildeo completo y detallado de la plataforma Web para permitir la generacioacuten de los casos de prueba abstractos
y su posterior generacioacuten automaacutetica de los casos de prueba ejecutables Es de intereacutes destacar que a lo largo
del desarrollo del proyecto han ido surgiendo otros objetivos de intereacutes para mejorar el proceso de pruebas los
cuales permiten agilizar dicho proceso y ampliar su alcance
Entre estos objetivos se encuentran la generacioacuten automaacutetica de documentacioacuten del plan de pruebas la
implementacioacuten de un entorno de UAT (User Acceptance Testing) con Docker la integracioacuten de las pruebas a
nivel de aceptacioacuten en el proceso de integracioacuten continua del proyecto o la creacioacuten de un Docker que permita
ejecutar todo el plan de pruebas Todos estos objetivos se iraacuten detallando maacutes adelante
67
43 Arquitectura de la Solucioacuten Entorno de UAT para el proceso de pruebas (User Acceptance Test)
Hasta ahora dentro del proceso de desarrollo de la plataforma Web existiacutean las siguientes fases etapas o
entornos Desarrollo Preproduccioacuten y Produccioacuten
Bajo este contexto las actividades del proceso de pruebas eran realizadas sobre la fase de Preproduccioacuten Esto
provocaba una dependencia directa del cierre de la mayoriacutea de actividades de desarrollo para el despliegue en la
fase de Preproduccioacuten Como consecuencia la fase de pruebas a nivel de aceptacioacuten se podriacutea ver perjudicada
por esta metodologiacutea provocando en muchas ocasiones el retraso en el feedback necesario por los ingenieros de
desarrollo de los reportes e informes generados al ejecutar las pruebas de aceptacioacuten Para mejorar este proceso
se ha disentildeado un nuevo entorno de UAT en el proceso de desarrollo que permita disminuir la dependencia del
proceso de pruebas y desarrollo La inclusioacuten de este nuevo entorno ha sido posible gracias a la mejora del
proceso de integracioacuten continuacutea implementado en el desarrollo de la plataforma
Dentro de este proceso de integracioacuten continua se realiza la generacioacuten automaacutetica de los Docker que contienen
los diferentes microservicios de la plataforma Web en cualquier etapa del proceso de desarrollo Ademaacutes dentro
del proceso de integracioacuten continua se ha automatizado por parte de los ingenieros de desarrollo la ejecucioacuten
de pruebas unitarias y de integracioacuten que garantizan una miacutenima garantiacutea de estabilidad funcional de la
plataforma necesaria para el proceso de pruebas Partiendo de este punto el equipo de calidad ha disentildeado un
entorno de UAT con Docker el cual se muestra de forma graacutefica en la siguiente figura
Figura 40 Entorno de UAT con Docker (Anexo B)
68
69
5 TECNOLOGIacuteAS Y HERRAMIENTAS USADAS
na vez descrito el sistema bajo pruebas y presentada la arquitectura de la solucioacuten para el escenario de
pruebas con Docker se expondraacute a continuacioacuten el conjunto de tecnologiacuteas y herramientas usadas para
llevar a cabo el desarrollo de las pruebas automatizadas de aceptacioacuten o pruebas End-to-End Con este
conjunto de herramientas se pretende conseguir la implementacioacuten de los diferentes scripts de pruebas que
automaticen las acciones e interacciones necesarias con la plataforma Web CHT Cloud Manager como si de
una persona se tratase
51 Selenium
Selenium es una herramienta de coacutedigo abierto utilizada para la automatizacioacuten de pruebas en navegadores web
Dicha herramienta posee una enorme popularidad en el mundo de las pruebas de software debido a que
Presenta compatibilidad con diferentes lenguajes de programacioacuten para la implementacioacuten de scripts de
pruebas ofreciendo libreriacuteas en Java Python C PHP Ruby Perl y Net
Es multiplataforma permitiendo el lanzamiento de los scripts de pruebas en diversos sistemas
operativos como Windows Mac o Linux y en diferentes navegadores como Mozilla Firefox Internet
Explorer Google Chrome Safari y Opera
Soporta la integracioacuten con otras herramientas como TestNG o JUnit
Permite la integracioacuten continua con Maven Jenkins gitlab CICD y Docker
Sin embargo presenta una serie de inconvenientes que se deben mencionar
bull Solo permite probar aplicaciones Web
bull No hay soporte garantizado desde Selenium Muchas de las soluciones a problemas de la herramienta
han sido generadas por la comunidad
bull No es posible realizar pruebas en imaacutegenes Para ello es necesaria la integracioacuten con otras herramientas
bull No tiene capacidad nativa para generar informes o reportes de los resultados de las pruebas Para ello
se requiere el uso de un framework como puede ser el Robot Framework
Centrando la atencioacuten en el enfoque de dicho proyecto se haraacute uso de la libreriacutea Selenium para Python y la
facilidad de Robot Framework tanto para abstraer la posible complejidad antildeadida del lenguaje de programacioacuten
usado para la implementacioacuten de los scripts de prueba como para permitir la generacioacuten automaacutetica de informes
y reportes de resultados
Realmente Selenium estaacute formado por un conjunto de herramientas las cuales son Selenium RC Selenium
IDE Selenium Grid y Selenium Webdriver Dichas herramientas permiten desde la realizacioacuten de pruebas en
maacutequinas remotas a la ejecucioacuten de pruebas en diferentes maacutequinas con diferentes navegadores cada una
Con el lanzamiento de Selenium 2 en 2008 se antildeadieron nuevas funcionalidades de Selenium RC y Webdriver
en una misma herramienta aunque es frecuente mantener la nomenclatura de WebDriver a la hora de referirse
a la misma En este proyecto se centraraacute la atencioacuten en la herramienta WebDriver de Selenium
U
El disentildeo es el alma de todo lo creado por el hombre
Steve Jobs
70
52 Selenium WebDriver
Esta herramienta de Selenium ofrece una interfaz para ejecutar los casos de prueba descritos en los scripts
de prueba A traveacutes de esta API WebDriver se comunica directamente con el controlador del navegador
donde corre la aplicacioacuten Para ello seraacute necesario el uso de controladores para los diferentes navegadores
Web desde los que se validan las pruebas automaacuteticas
Todas las implementaciones de WebDriver que se comunican con el navegador usan un protocolo punto a
punto comuacuten Este protocolo define un servicio RESTfull usando JSON sobre HTTP Cada operacioacuten
realizada por WebDriver se mapea en un meacutetodo HTTP que se comunica con el navegador Las respuestas
a dichas operaciones seraacuten devueltas en mensajes HTTP de respuesta
Existen diversas implementaciones de Selenium para diferentes entornos tal y como se muestra en la
siguiente figura
Figura 41 Implementaciones disponibles de Selenium y Navegadores Web Compatibles
Para la ejecucioacuten de las pruebas implementadas en este proyecto se ha hecho uso de los controladores Gecko
Driver y Chromedriver para los navegadores Web Firefox y Google Chrome
521 Elementos del Navegador
Una vez tenemos una viacutea de comunicacioacuten con el navegador planteamos la pregunta iquesty coacutemo le indico al
navegador con queacute componente quiero interactuar
La cantidad de componentes que existen es muy amplia cajas de texto botones imaacutegenes hiperviacutenculos
botones de radio check boxes aacutereas de texto mensajes de error desplegables tablas frames etc Todos
estos elementos tienen una serie de propiedades que pueden ser uacutenicas o no en toda la paacutegina Por ejemplo
un identificador (ID) debe distinguir de manera uniacutevoca a un elemento Este identificador es lo que se
denomina un localizador Existen 8 tipos distintos de localizadores diferentes
bull Id Name Class Name Tag Name Link Text Partial Link Text CSS Xpath
71
Se podraacuten implementar las interacciones con el navegador mediante la llamada a un meacutetodo (accioacuten) que
se aplicaraacute sobre el elemento que nosotros indiquemos A continuacioacuten se muestra el diagrama de bloques
y la implementacioacuten de un ejemplo simple del inicio de sesioacuten usando Python y la libreriacutea de Selenium
Figura 42 Coacutedigo de ejemplo con Python y Selenium
La implementacioacuten anterior permite abrir un navegador Web Chrome en pantalla completa y acceder a la
plataforma Web Galgus CHT Cloud Manager Una vez ha sido posible el acceso y la paacutegina Web estaacute
disponible se realiza el inicio de sesioacuten en la plataforma con las credenciales correspondientes esperando que
dicho inicio de sesioacuten se haya realizado con eacutexito Finalmente se cierran todas las instancias de navegadores
Web abiertas por Selenium en la automatizacioacuten de dicha prueba de concepto
72
53 Robot Framework (RF)
Para la automatizacioacuten del testeo de la aplicacioacuten se ha hecho uso de este framework como herramienta
para dicha finalidad Robot Framework es un framework geneacuterico de automatizacioacuten de pruebas de coacutedigo
abierto desarrolla do por Pekka Klaumlrck en el antildeo 2005
Este framework sigue el enfoque Keyword-Driven Testing y es un candidato idoacuteneo debido a su alto nivel
de abstraccioacuten para pruebas de aceptacioacuten y desarrollo guiado por pruebas de aceptacioacuten o Acceptance
Test-Driven Development (ATDD) Las capacidades de pruebas pueden ser ampliadas con nuevas libreriacuteas
implementadas tanto en Python como en Java y los usuarios pueden crear nuevas keywords a partir de las
existentes usando la misma sintaxis que para los casos de prueba [18]
Robot Framework es independiente del sistema operativo y de la aplicacioacuten El nuacutecleo del framework estaacute
implementado en Python soportando tanto Python 2 como Python 3
Se ha decidido utilizar este framework por la disponibilidad de un amplio conjunto de libreriacuteas de propoacutesito
general y la integracioacuten con libreriacuteas externas como Selenium2Library Entre otras prestaciones permite el
uso de variables que aportan mayor flexibilidad a la hora de disentildear y controlar los scripts de prueba
permite el etiquetado para poder identificar y ejecutar los casos de prueba por separado proporciona una
faacutecil integracioacuten con Jenkins y Maven y proporciona un sistema de reporte de informes de resultados
detallados y de faacutecil lectura Ademaacutes hay que destacar la faacutecil abstraccioacuten que ofrece al poder utlizar
keywords de alto nivel permitiendo el uso del estilo de representacioacuten Given-When-Then para los casos
de prueba A continuacioacuten se describe dicho estilo de representacioacuten
531 Estilo de representacioacuten Given-When-Then
Dicho estilo ofrecido por Robot Framework es uno de los puntos fuertes de este framework Esta caracteriacutestica
permite el uso del siguiente estilo de representacioacuten para los casos de prueba
Figura 43 Estilo de representacioacuten Given-When-Then
bull Given Define las precondiciones necesarias para llevar a cabo la accioacuten asiacute como el actor de la
misma
bull When Accioacuten llevada a cabo por el actor definido en la claacuteusula Given
bull Then Es el comportamiento esperado o la salida del sistema esperada ante una entrada
determinada
bull And Claacuteusula auxiliar que se usa de forma combinada con las anteriores
73
Como ejemplo de aplicacioacuten de este estilo de representacioacuten supongamos que tenemos unos requisitos de
aceptacioacuten establecidos en un documento entre los que se encuentran el inicio y cierre de sesioacuten mediante
usuario y contrasentildea a la plataforma Galgus CHT Cloud Manager En la siguiente tabla se muestran los
criterios de aceptacioacuten definidos en el documento de requisitos para dicha funcionalidad
1 Un usuario no identificado puede iniciar sesioacuten desde la vista principal de la plataforma Web
2 Un usuario no identificado debe insertar un usuario y contrasentildea vaacutelidos para el inicio de sesioacuten
A continuacioacuten se muestra coacutemo se llevariacutea a cabo la implementacioacuten de los scripts de pruebas abstractos
asociados a las especificaciones anteriores haciendo uso del estilo de representacioacuten Given-When-Then
Es complicado implementar todos los casos de prueba posibles principalmente cuando el requisito de
aceptacioacuten requiere de una funcionalidad compleja En este caso se muestran tres casos de prueba
abstractos los cuales han sido implementados en el proyecto para validar el inicio y cierre de sesioacuten
Caso de Prueba 1 Inicio de Sesioacuten en Galgus CHT Cloud Manager
Claacuteusula Keyword
Given Navegacioacuten a la paacutegina principal de Galgus CHT Cloud Manager
When Insertar nombre de usuario vaacutelido
And Insertar contrasentildea vaacutelida
Then Iniciar sesioacuten con eacutexito
Caso de Prueba 2 Intento de Inicio de sesioacuten con usuario no vaacutelido
Claacuteusula Keyword
Given Navegacioacuten a la paacutegina principal de Galgus CHT Cloud Manager
When Insertar nombre de usuario invaacutelido
And Insertar contrasentildea vaacutelida
Then No es posible el inicio de sesioacuten Se muestra mensaje de error
Caso de Prueba 3 Intento de Inicio de sesioacuten con contrasentildea no vaacutelida
Claacuteusula Keyword
Given Navegacioacuten a la paacutegina principal de Galgus CHT Cloud Manager
When Insertar nombre de usuario vaacutelido
And Insertar contrasentildea invaacutelida
Then No es posible el inicio de sesioacuten Se muestra mensaje de error
74
En la siguiente figura se muestra la implementacioacuten de dichas pruebas con Robot Framework donde cada
Keyword implementada permite la abstraccioacuten de toda la funcionalidad necesaria para realizar las pruebas
Figura 44 Implementacioacuten de Pruebas en para el inicio de sesioacuten de CHT Cloud Manager
75
532 Reportes
A continuacioacuten se muestra un ejemplo de los reportes obtenidos tras la ejecucioacuten del primer caso de prueba de
los anteriores donde pueden identificarse las diversas keywords necesarias para implementar cada caso de
prueba asiacute como otras adicionales que ayudan a crear el contexto (precondiciones) Tambieacuten se incluyen
estadiacutesticas sobre el tiempo de ejecucioacuten nuacutemero de tests total nuacutemero de tests que han fallado o que han pasado
con eacutexito [18]
Figura 45 Ejemplo de reporte de pruebas automatizadas con Robot Framework
76
533 Libreriacuteas
Robot Framework permite el uso de Selenium mediante la libreriacutea de pruebas Web SeleniumLibrary Dicha
libreriacutea es compatible con las versiones de Selenium 2536 y sucesivas y con Python 27 y Python 3 Ademaacutes
del inteacuterprete por defecto de Python esta libreriacutea funciona tambieacuten con PyPy y Jython [18]
Esta libreriacutea estaacute compuesta entre otras muchas por una serie de archivos de Python (py) que implementan
las clases que contienen las diversas keywords que pueden ser usadas en nuestro framework La estructura de
estos archivos se presenta en la siguiente tabla
Archivo de Clase Funcioacuten
Alertpy Interacciones con mensajes de alerta
Browsermanagementpy Apertura cierre y cambio de navegadores
Cookiepy Manipulacioacuten de cookies del navegador
Elementpy Interaccioacuten con elementos y sus atributos
Formelementpy Interaccioacuten con elementos en formularios
Framespy Manejo de frames y su contenido
Javascriptpy Facilidades para inyectar coacutedigo javascript
Runonfailurepy Uso de funcionalidades en caso de fallo
Screenshotpy Manejo de capturas de pantalla
Selectelementpy Manejo de elementos en listas
Tableelementpy Manejo de elementos en tablas
Waitingpy Manejo de temporizadores de espera para
transiciones en una paacutegina
Webdrivertoolspy Interaccioacuten directa con el controlador del navegador
Windowpy Manejo de ventanas del navegador
Estas libreriacuteas fueron desarrolladas en sus oriacutegenes por el ingeniero finlandeacutes Tatu Aalto y posteriormente
mejoradas por toda la comunidad de expertos en automatizacioacuten de pruebas Sin embargo Robot Framework
mediante el uso de Python con Selenium permite la implementacioacuten de libreriacuteas propias o funcionalidades
desarrolladas en Python que pueden ser integradas en Robot Framework En este proyecto se hace uso de Python
con Selenium para desarrollar algunas funcionalidades avanzadas que permiten probar ciertos criterios de la
aplicacioacuten muy especiacuteficos y avanzados de la plataforma Web para los cuales las libreriacuteas ofrecidas por Robot
Framework no proporcionan la funcionalidad requerida
Ademaacutes se ha hecho uso de otras libreriacuteas como BuiltIn para el uso de bucles condicionales y otras keywords
String y Collections para el tratamiento de cadenas de caracteres y colecciones de datos SSHLibrary para usar
un cliente ssh Process para la ejecucioacuten de subprocesos haciendo uso la libreriacutea subprocess de python y
OperatingSystem para realizar algunas tareas sobre el sistema operativo
77
534 Documentacioacuten
La documentacioacuten de los diferentes casos de pruebas implementados con Robot Framework es muy redundante
y una tarea la cual seriacutea deseable de poder automatizar Dicho framework ofrece esta posibilidad a traveacutes de dos
herramientas para crear documentacioacuten basada en las pruebas y libreriacuteas implementadas para dichas pruebas
Libdoc y Testdoc [18]
5341 Libdoc
Libdoc es una herramienta ofrecida por Robot Framework para construir documentacioacuten sobre las keywords
implementadas para los casos de prueba Dicha documentacioacuten es generada en formato HTML y XML
Se puede crear documentacioacuten para bibliotecas implementadas con Python o Java y para las propias libreriacuteas
implementadas con Robot Framework A continuacioacuten se muestra un ejemplo de la documentacioacuten generada
para la libreriacutea implementada para los casos de prueba de inicio y cierre de sesioacuten de Galgus CHT Cloud
Manager
Figura 46 Ejemplo de documentacioacuten generada con Libdoc
5342 Testdoc
Testdoc es una herramienta para generar documentacioacuten de alto nivel basada en los casos de prueba de Robot
Framework Dicha documentacioacuten es generada en formato HTML e incluye el nombre la documentacioacuten y
otros metadatos de cada conjunto de pruebas y casos de prueba asiacute como las keywords de alto nivel y sus
argumentos
A continuacioacuten se muestra un ejemplo de la documentacioacuten generada para el conjunto de casos de prueba que
validan el inicio y cierre de sesioacuten de Galgus CHT Cloud Manager
Figura 47 Ejemplo de documentacioacuten generada con Testdoc
78
54 Pycharm (IDE)
Esta herramienta proporciona un entorno de desarrollo integrado (IDE) el cual ha sido usado para programar en
lenguaje Python por lo que es idoacuteneo tambieacuten para el desarrollo de pruebas con Robot Framework Esta
desarrollado por la empresa JetBrains Ademaacutes proporciona entre otras muchas herramientas el anaacutelisis de
coacutedigo un depurador graacutefico integracioacuten con sistemas de control de versiones y es multiplataforma
55 GitGitlab
551 Git
Git es un software de control de versiones disentildeado por Linux Torvalds pensando en la eficiencia y la
confiabilidad del mantenimiento de versiones de aplicaciones cuando eacutestas tienen un gran nuacutemero de archivos
de coacutedigo fuente Al principio Git se pensoacute como un motor de bajo nivel sobre el cual otros pudieran escribir la
interfaz de usuario como Cogito o StGIT Sin embargo Git se ha convertido desde entonces en un sistema de
control de versiones con funcionalidad plena Hay algunos proyectos de mucha relevancia que ya usan Git en
particular el grupo de programacioacuten del nuacutecleo Linux Ademaacutes cabe destacar que se ha hecho uso de
GitKraken como interfaz graacutefica de git para llevar a cabo el control de versiones de una forma maacutes intuitiva
552 Gitlab
Gitlab es un servicio Web de control de versiones y desarrollo de software colaborativo basado en Git Fue
implementado por los desarrolladores ucranianos Dimitry Zaporozhets y Valey Sizov en el lenguaje de
programacioacuten Ruby Este proyecto cuenta con un equipo de 150 miembros y maacutes de 1400 usuarios y es usado
por empresas como la NASA el CERN IBM o Sony [19]
Ademaacutes de gestor de repositorios tambieacuten ofrece la posibilidad de alojar documentacioacuten y un sistema de
seguimiento de errores Tambieacuten es de gran importancia destacar que esta herramienta proporciona su propia
herramienta de Integracioacuten Continua sin necesidad de usar otra herramienta externa
Se ha hecho uso de estas herramientas para tener un control de versiones sobre nuestro proyecto y una gestioacuten
centralizada de todos los repositorios de la empresa de forma que asiacute podemos tener un control de versiones de
todos los cambios realizados en el coacutedigo con posibilidad de contrastarlos con versiones anteriores y recuperar
dichos cambios Ademaacutes se hace uso tambieacuten de gitlab CICD para implementar procesos de Integracioacuten
continua sobre los diferentes proyectos En el caso particular de este proyecto para generar la documentacioacuten
de los casos de test y libreriacuteas y para generar un Docker con toda la bateriacutea de pruebas y dependencias necesarias
para lanzarlas
56 Redmine
Redmine es una herramienta para la gestioacuten de proyectos que ofrece un conjunto de funcionalidades que
permiten a los usuarios de diferentes proyectos realizar el seguimiento y organizacioacuten de los mismos Incluye
un sistema de seguimiento de incidentes Otras herramientas que incluye son un calendario de actividades
diagramas de Gantt una wiki para almacenar documentacioacuten control del flujo de trabajo basado en roles
integracioacuten con correo electroacutenico etc
Esta herramienta se usa para la gestioacuten del proyecto Galgus CHT Cloud Manager donde se integra como
subproyecto la automatizacioacuten del proceso de pruebas para la plataforma Web desarrollada
A continuacioacuten se muestra un ejemplo del flujo de trabajo implantado en la metodologiacutea de trabajo dentro del
proyecto donde cada historia puede contener un conjunto de tareas las cuales pueden pasar por diferentes
estados hasta ser completadas por el desarrollador o el ingeniero de pruebas
79
Figura 48 Ejemplo de Flujo de Trabajo en Redmine para Galgus CHT Cloud Manager
561 Uso en el Proyecto Galgus CHT Cloud Manager (Metodologiacutea Scrum)
Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas praacutecticas para trabajar
colaborativamente en equipo y obtener el mejor resultado posible de un proyecto Estas praacutecticas se apoyan
unas a otras y su seleccioacuten tiene origen en un estudio de la manera de trabajar de equipos altamente productivos
Esta metodologiacutea divide el trabajo en una lista de pequentildeas funcionalidades ordenadas por prioridad y estimadas
en esfuerzo Estas pequentildeas tareas son abordadas en iteraciones cortas de longitud fija denominadas Sprints de
1 a 4 semanas (en este caso se ha optado por iteraciones de 3 o 4 semanas) obteniendo coacutedigo potencialmente
entregable siendo demostrado al final de cada iteracioacuten Una vez decidido por el equipo de gestioacuten de proyectos
el alcance y conjunto de actividades a realizar dentro del sprint se transmite al resto del equipo que forma parte
del proyecto procediendo a la asignacioacuten de tareas mediante Redmine como herramienta de gestioacuten usada
Durante el sprint se va realizando un seguimiento perioacutedico del estado del proyecto y de la situacioacuten de cada
integrante mediante una actividad previa diaria de unos 15 minutos para situar el punto de partida de trabajo
diario que seriacutean reuniones diarias de apenas 15 minutos denominadas ldquoDaylisrdquo
Figura 49 Esquema Graacutefico de Metodologiacutea Scrum
80
La planificacioacuten que se pretende seguir en cada sprint es la siguiente
1 Semana 1 y 2 Realizacioacuten de tareas por parte del equipo de desarrollo incluyendo en estas tareas
nuevos desarrollos modificacioacuten de funcionalidades y verificacioacuten de las mismas mediante pruebas
unitarias y de integracioacuten
2 Semana 3 Realizacioacuten de pruebas de aceptacioacuten manuales por parte del equipo de pruebas y posterior
automatizacioacuten de dichas pruebas Para ello se usaraacute el entorno de UAT como escenario de pruebas
Ademaacutes el equipo de desarrollo iraacute corrigiendo todos aquellos errores o defectos encontrados
3 Semana 4 El jefe de proyecto realiza la fusioacuten de todos los desarrollos y actualiza las versiones en el
entorno de Preproduccioacuten incluyendo todas las actividades realizadas y validadas por el equipo de
desarrollo y de pruebas El equipo de pruebas realizaraacute la ejecucioacuten de todas las pruebas End-to-End
sobre el entorno de Preproduccioacuten para verificar y validar la nueva versioacuten que incluye todas las
funcionalidades Estas pruebas son denominadas pruebas de regresioacuten las cuales verifican que los
nuevos desarrollos no han provocado defectos o errores sobre funcionalidades que hasta ahora habiacutean
funcionado correctamente Finalmente el jefe de proyecto realiza el despliegue en produccioacuten
81
82
6 EXPERIMENTOS
na vez descrito el sistema bajo pruebas el proceso de pruebas y las herramientas que se usaraacuten para
automatizar las pruebas de aceptacioacuten sobre la plataforma de gestioacuten Galgus CHT Cloud Manager
solo queda presentar la forma en la que se ha puesto en praacutectica y el proceso seguido paso a paso
Dado que el objetivo es conseguir una bateriacutea de casos de pruebas End-to-End automatizadas se implementaraacuten
dichos casos de prueba de forma que permitan detectar el incorrecto funcionamiento de cada funcionalidad con
la mayor rapidez posible cubriendo los principales escenarios donde puedan surgir los mayores errores Por
tanto dichos casos de prueba seraacuten elegidos en base al riesgo que puedan introducir
Estos casos de prueba seraacuten definidos mediante un conjunto de criterios de aceptacioacuten descritos a traveacutes de
diagramas de flujo y agrupados seguacuten la funcionalidad de la aplicacioacuten que abarquen las cuales son
1 Vista de Gestioacuten Principal (Coud Tab) Esta seccioacuten de la Web estaacute destinada a la administracioacuten de
usuarios administracioacuten de los diferentes Zone Managers y finalmente incluye un Mapa con la
ubicacioacuten de cada Zone Manager
2 Vista de Configuracioacuten (Configuration Tab) En esta pestantildea se ofrece la gestioacuten de grupos de puntos
de acceso gestioacuten de backups y restauracioacuten gestioacuten de firmwares zonas CHT etc
3 Vista de Red (Network Tab) La pestantildea de red engloba toda la configuracioacuten de red de los puntos de
acceso siendo esta la pestantildea con mayor funcionalidad complejidad y por ello potencial de riesgo de
errores de la plataforma Web
Figura 50 Logo de Galgus CHT Cloud Manager
U
La uacutenica parte donde el ldquoeacutexitordquo aparece antes que el trabajo es en el diccionario
Vidal Sasoon
83
61 Estructura del Proyecto
La clasificacioacuten funcional anterior seraacute tomada de la misma forma para organizar la estructura del proyecto de
pruebas automatizadas con Robot Framework para un desarrollo ordenado y loacutegico de todo el conjunto de casos
de prueba A continuacioacuten se muestra un ejemplo de la estructura del proyecto el cual se encuentra en desarrollo
y continua mejora
Figura 51 Estructura del Proyecto
Para una mayor modularidad y limpieza en el desarrollo de los casos de Test se han centralizado todos los
localizadores en un archivo llamado ldquoSelectorpyrdquo En la siguiente figura se muestra un fragmento de dicho
fichero
Figura 52 Fragmento del fichero ldquoSelectorpyrdquo
A la hora de obtener los localizadores de los elementos que seraacuten comprobados o usados en los scripts de pruebas
se han usado las herramientas de desarrollador que incluye Google Chrome Para ello basta con navegar a la
paacutegina de la plataforma Web en cualquier navegador y pulsar la tecla F12 Esto mostraraacute las herramientas de
desarrolladores donde encontramos una pestantildea llamada ldquoElementosrdquo donde se puede inspeccionar el
documento ldquoHTMLrdquo de la paacutegina Una vez abierta dicha herramienta seraacute sencillo obtener propiedades de los
diversos elementos que nos permitiraacuten hacer referencia a los mismos en nuestro script de pruebas
Los ldquoXpathrdquo absolutos seraacuten lo usados praacutecticamente en toda la Suite de pruebas El beneficio de los
identificadores uacutenicos es que permiten seleccionar elementos sin que sea necesario hacer referencia a su posicioacuten
dentro del documento HTML Esto evita cualquier problema en caso de que las rutas de un elemento dentro del
citado documento cambien debido a mejoras o despistes por parte de los desarrolladores En cambio usar
selectores basados en la ruta del elemento dentro del documento HTML puede propiciar falsos fallos en el
escenario anterior debido a que no puedan encontrarse en la Web a pesar de que realmente sigan estando
presentes y totalmente funcionales
Por otro lado se han agrupado todas aquellas ldquokeywordsrdquo que puedan ser usadas por otras secciones en la
implementacioacuten de los casos de prueba mediante ficheros nombrados como ldquotab_common_keywords robotrdquo
84
Siguiendo esta jerarquiacutea se ha incluido un fichero llamado ldquoCommon_Keywordsrobotrdquo general en el que se
incluyen las principales ldquokeywordsrdquo que pueden ser usadas en todo el proyecto A continuacioacuten se muestra un
fragmento de este fichero
Figura 53 Fragmento del fichero ldquoCommon_Keywordsrobotrdquo
Tambieacuten se incluye el fichero ldquoConfigurationrobotrdquo para agrupar definiciones de variables que seraacuten
usadas en todo el proyecto ademaacutes de realizar la inclusioacuten de las libreriacuteas a usar Se muestra otra figura
con un fragmento del fichero ldquoConfigurationrobotrdquo
Figura 54 Fragmento del fichero de Configuracioacuten de pruebas ldquoConfigurationrobotrdquo
85
A continuacioacuten se muestra un diagrama que muestra las dependencias de los diferentes archivos y la estructura
seguida por el proyecto
Figura 55 Diagrama de paquetes del proyecto de pruebas
Tras introducir la estructura del proyecto y las diferentes funcionalidades de la plataforma Web Galgus CHT
Cloud Manager a continuacioacuten se mostraraacuten algunos criterios de aceptacioacuten de cada funcionalidad a probar
con diagramas de flujo y scripts de pruebas haciendo uso del estilo de representacioacuten Given-When-Then
Ademaacutes se mostraraacuten algunos detalles de implementacioacuten sobre las pruebas Por otro lado la ejecucioacuten de los
casos de prueba de ejemplo y el reporterevisioacuten de resultados se incluiraacute en la seccioacuten de Anexos
Cada una de las siguientes subsecciones dentro de cada funcionalidad principal de la aplicacioacuten o vista principal
tendraacute su correspondiente Suite de pruebas con un conjunto de casos de Test Todas estas Suites seguiraacuten la
siguiente estructura comuacuten para los casos de Test
Figura 56 Estructura de una Suite de Pruebas
86
Todas las Suites comienzan con una seccioacuten de documentacioacuten para describir el contenido de las pruebas de forma geneacuterica y varias secciones para importar los recursos necesarios para las pruebas (Resource)
Las secciones ldquoSuite Setuprdquo y ldquoSuite Teardownrdquo permiten la ejecucioacuten automaacutetica antes y despueacutes de la bateriacutea de pruebas y las secciones ldquoTest Setuprdquo y ldquoTest Teardownrdquo permiten la ejecucioacuten automaacutetica antes y despueacutes de cada caso de prueba
Un uso tiacutepico de ldquoSuite Setuprdquo es abrir un navegador Web y comprobar la disponibilidad de la Web a probar mientras que el cierre del navegador se realiza con ldquoSuite Teardownrdquo De este modo sea cual sea el resultado de la ejecucioacuten no se quedaraacuten abiertas ventanas gastando recursos de la maacutequina
Por otro lado el uso por defecto de ldquoTest Setuprdquo en este proyecto ha sido el inicio de sesioacuten en la Web CHT Cloud Manager mientras que ldquoTest Teardownrdquo ha sido usado para cerrar tambieacuten el navegador Web Sin embargo la mayoriacutea de las pruebas implementadas necesitan una serie de precondiciones previas a la ejecucioacuten del Test y un conjunto de postcondiciones necesarias para no provocar inconsistencias entre la ejecucioacuten de diferentes pruebas Por este motivo se ha hecho uso de las etiquetas [Setup] y [Teardown] para modificar la ejecucioacuten por defecto de ldquoTest Setuprdquo y ldquoTest Teardownrdquo en cada caso de prueba cuando sea necesario
Cabe destacar que la loacutegica implementada dentro de estas claacuteusulas no requiere que sea validada puesto que su uacutenico objetivo es preparar el entorno de pruebas para ejecutar una prueba sin que esta falle por causas ajenas al aacutembito y objetivo de la prueba evitando de esta forma los falsos positivos Por este motivo se hace uso de la Keyword ldquoRun Keyword And Ignore Errorrdquo ofrecida por la libreriacutea ldquoBuiltInrdquo para ignorar los errores en la ejecucioacuten de [Setup] y [Teardown] En la siguiente figura se muestra un ejemplo de dicha teacutecnica
Figura 57 Ejemplo de ldquoTest Setuprdquo personalizado para un caso de prueba
Finalmente la implementacioacuten de las ldquokeywordsrdquo usadas mediante la nomenclatura Given-When-Then seraacuten agrupadas en el correspondiente fichero ldquoTab_common_keywordsrobotrdquo para conseguir una abstraccioacuten de la loacutegica necesaria para la automatizacioacuten de las pruebas En las pruebas seleccionadas para describir en esta seccioacuten se detallaraacute la implementacioacuten de algunas keywords que se usaraacuten
87
62 Vista de Gestioacuten Principal (Cloud Tab)
En la siguiente figura se muestra la vista de Gestioacuten Principal de Galgus CHT Cloud Manager
Figura 58 Vista de Gestioacuten Principal (Cloud Tab)
Sobre esta vista se han automatizado un conjunto de Suites de pruebas que validan toda la funcionalidad
contenida en las pestantildeas MAP List of Zone Managers y Administration ademaacutes de toda la loacutegica ofrecida para
gestionar un conjunto de fabricantes
621 Administration
Comenzando con la pestantildea de administracioacuten se puede observar la existencia de cuatro flujos de navegacioacuten
principales en la siguiente figura
Figura 59 Pestantildea ldquoAdministrationrdquo
Una vez conocida la vista de administracioacuten de la Web se han realizado un total de 22 casos de prueba de los
cuales detallaremos el caso de prueba identificado con la etiqueta U0027
6211 Criterios de Aceptacioacuten
La pestantildea de administracioacuten permite la gestioacuten de los usuarios y roles que tienen acceso a la plataforma Web
ademaacutes de la configuracioacuten de los detalles de los fabricantes seleccionados A continuacioacuten se detallan los
criterios de aceptacioacuten del caso de prueba seleccionado
U0027 Un usuario con permisos de Super Usuario puede editar la informacioacuten de un fabricante
1 Un usuario con permisos de Super Usuario puede ver y acceder a la pestantildea de administracioacuten
2 Un usuario con permisos de Super Usuario puede editar la informacioacuten de un fabricante correctamente
88
6212 Diagramas de Flujo
A continuacioacuten se muestran los diagramas de flujo implementados para los dos casos de prueba analizados
Figura 60 Diagramas de Flujo de Casos de Prueba U0025 y U0027
6213 Script de Pruebas
Una vez establecidos los criterios de aceptacioacuten de ambos casos de prueba se mostraraacuten los scripts de pruebas
realizados
Figura 61 Script de Pruebas U0025
Entre las ldquokeywordsrdquo usadas en el caso de test anterior se puede destacar por ejemplo la implementacioacuten de
ldquoEdit Fieldsrdquo la cual permite editar los campos de un fabricante y verificar que han sido editados tras guardar
los cambios
Figura 62 Keyword ldquoEdit Fieldsrdquo
89
622 List
En la pestantildea de gestioacuten de los diferentes Zone Managers se puede observar una lista de los diferentes Zone
Managers disponibles y se pueden realizar un conjunto de acciones como la creacioacuten de nuevos Zone Managers
y edicioacuten o eliminacioacuten de los existentes entre otras
Figura 63 Pestantildea ldquoList of Zone Managersrdquo
Sobre esta vista se han realizado un total de 7 casos de prueba de los cuales detallaremos el caso de prueba
identificado con la etiqueta U0023 el cual permite validar la creacioacuten y eliminacioacuten de un Zone Manager
6221 Criterios de Aceptacioacuten
A continuacioacuten se detallan los criterios de aceptacioacuten del caso de prueba seleccionado
U0023 Verificar que un Usuario puede Crear y Eliminar un Zone Manager
1 Un usuario con permisos de Super Usuario puede Navegar a la pestantildea List Of Zone Managers
2 El usuario puede crear un Zone Manager correctamente
3 El usuario puede eliminar un Zone Manager correctamente
6222 Diagramas de Flujo
A continuacioacuten se muestra el diagrama de flujo implementado para el caso de prueba analizado
Figura 64 Diagrama de flujo de Caso de Prueba U0023
90
6223 Script de Pruebas
Una vez establecidos los criterios de aceptacioacuten se mostraraacute el script de pruebas realizado a partir del diagrama
de flujo anterior
Figura 65 Script de Prueba U0023
Cabe destacar la implementacioacuten de la Keyword ldquoZone Manager is Registered Successfullyrdquo la cual comprueba
que el Zone Manager registrado pasa a un estado ldquoOnlinerdquo tras un tiempo considerado como aceptable para que
la instancia de dicho Zone Manager este disponible en Cloud CHT Manager
Figura 66 Keyword ldquoZone Manager is registered successfullyrdquo
623 Manufacturer
La vista de gestioacuten principal ofrece una seccioacuten que permite la gestioacuten de los diferentes fabricantes permitiendo
su creacioacuten edicioacuten eliminacioacuten y bloqueo En la siguiente figura se muestra un ejemplo de la seccioacuten de
fabricantes
Figura 67 Seccioacuten de Fabricantes
Para validar el correcto funcionamiento de dicha seccioacuten se han realizado un total de 9 casos de prueba de los
cuales se detallaraacuten los casos de prueba identificados con las etiquetas U0009 Estos permiten validar que los
fabricantes pueden ser creados editados y eliminados correctamente y que todos los fabricantes disponibles son
mostrados correctamente
91
6231 Criterios de Aceptacioacuten
A continuacioacuten se detallan los criterios de aceptacioacuten de los casos de prueba seleccionados
U0009 Verificar que un Usuario con permisos de Super usuario puede ver correctamente todos los
fabricantes existentes
1 Un usuario con permisos de Super Usuario puede Navegar a la pestantildea de Administracioacuten
2 El usuario puede visualizar todos los fabricantes existentes
6232 Diagrama de Flujo
Figura 68 Diagrama de flujo de Caso de Prueba U0009
6233 Script de Pruebas
Una vez establecidos los criterios de aceptacioacuten se mostraraacuten los scripts de pruebas realizados a partir de los
diagramas de flujo anteriores
Figura 69 Script de Prueba U0009
En este punto cabe destacar la finalidad de la Keyword ldquoCorrectly Createrdquo la cual se usa en la mayoriacutea de las
pruebas para verificar que una operacioacuten se ha realizado con eacutexito en la plataforma Galgus CHT Cloud Manager
Esta Keyword verifica que tras realizar alguacuten tipo de operacioacuten en la plataforma Web ocurre un evento sobre la
Web que indica que dicha operacioacuten se ha realizado con eacutexito de la siguiente forma
92
Figura 70 Toast Success
Figura 71 Keyword ldquoCorrectly Createrdquo
Finalmente se muestra la implementacioacuten de las keywords usadas en [Setup] y [Teardown] del caso de prueba
U0009 las cuales preparan el escenario de pruebas creando un conjunto de fabricantes acotado y los elimina
tras la finalizacioacuten de la prueba
Figura 72 Setup amp Teardown de U0008
624 MAP
La plataforma Galgus CHT Cloud Manager ofrece una pestantildea ldquoMAPrdquo que contiene un mapa con la ubicacioacuten
asignada a cada uno de los Zone Managers disponibles por el usuario mostrando en su ubicacioacuten un icono con
el estado de dicho Zone Manager el cual cambia de color seguacuten su estado (offline online unsynchronized)
Figura 73 Mapa de Zone Managers
93
A traveacutes de dicho icono se puede realizar una serie de acciones entre ellas acceder a un Zone Manager
realizando doble click sobre el icono del mismo Sin embargo para automatizar este conjunto de acciones el
equipo de pruebas ha encontrado dificultades haciendo uso de Robot Framework ya que las libreriacuteas disponibles
permiten la interaccioacuten con elementos de la Web pero en este caso los iconos de los diferentes Zone Managers
son renderizados dentro del Mapa con ldquoOpen Street Mapsrdquo antes de ser mostrado en la vista Web de la
aplicacioacuten Por esta razoacuten el mapa es localizado en el DOM como un uacutenico elemento Web lo que imposibilita
localizar a priori el icono de cada Zone Manager dentro del Mapa
Para resolver este impedimento el equipo de pruebas tuvo que analizar con profundidad la libreriacutea de ldquoOpen
Street Maprdquo implementada en Javascript Esta ha sido usada en el Frontend para encontrar alguna funcioacuten que
permitiese obtener desde la consola del navegador Web los piacutexeles en los que cada Zone Manager ha sido
renderizado dentro del Mapa Dicha funcioacuten es ldquogetPixelsFromCoordinate(coordinate)rdquo la cual a traveacutes de las
coordenadas de [Latitud Longitud] de cada Zone Manager se obtienen los piacutexeles del mismo en la pantalla A
traveacutes del siguiente fragmento de coacutedigo en el frontend implementado con Angular 6 en typescript se consigue
obtener los piacutexeles de cada Zone Manager e imprimirlo en la consola del navegador Web
Figura 74 Funcioacuten que dibuja los ZM en el Mapa y obtiene los piacutexeles en pantalla
Para llevar a cabo la implementacioacuten de las pruebas sobre el mapa se ha hecho uso en su gran mayoriacutea de Scripts
con Python Selenium y otras libreriacuteas necesarias en lugar de Robot Framework debido a la necesidad de
realizar varias tareas simultaneas ademaacutes de tratarse de pruebas muy especiacuteficas y personalizadas A
continuacioacuten se muestra la prueba implementada para poder realizar doble click sobre un Zone manager en el
mapa e iniciar sesioacuten en el mismo (U0007)
6241 Criterios de Aceptacioacuten
U0007 Verificar que un Usuario acceder a un Zone Manager desde el Mapa
1 Un usuario con permisos de Super Usuario puede Navegar a la pestantildea MAP
2 El usuario puede hacer doble click en el Zone Manager e iniciar sesioacuten
94
6242 Diagrama de Flujo
Figura 75 Diagrama de Flujo de Caso de Prueba U0007
6243 Script de Pruebas
Para la implementacioacuten de este tipo de casos de prueba se ha hecho uso de la libreriacutea ldquoHtmlTestRunnerrdquo para
obtener un reporte similar al ofrecido por Robot Framework en la ejecucioacuten de la prueba Para obtener un reporte
de la prueba la implementacioacuten de la misma debe seguir una estructura determinada a la que ademaacutes se ha
incluido a traveacutes de la libreriacutea ldquomultiprocessingrdquo la ejecucioacuten simultaacutenea de los dos procesos descritos en el
diagrama de flujo anterior Es necesaria la ejecucioacuten de varios procesos para leer la consola del navegador Web
y obtener los piacutexeles de los Zone Manager para posteriormente hacer doble click
En la Seccioacuten A3 de los anexos puede encontrarse la implementacioacuten del script de pruebas para el caso de
prueba U0007
95
63 Vista de Configuracioacuten (Configuration Tab)
En esta vista se ha automatizado un conjunto de Suites de prueba que validan toda la funcionalidad contenida
en las pestantildeas Groups CHT Zones BackupRestore y Firmware
631 Groups
La pestantildea de grupos permite el descubrimiento de los puntos de acceso a traveacutes de su direccioacuten MAC quedando
estos registrados en base de datos y mostrando al usuario en una tabla los puntos de acceso registrados ademaacutes
del estado de los mismos y otros datos como el modelo o grupo al que pertenecen
Figura 76 Pestantildea ldquoGroupsrdquo
Sobre esta funcionalidad de la plataforma se han realizado un total de 19 casos de prueba de los cuales
detallaremos el caso de prueba identificado con la etiqueta U0119
6311 Criterios de Aceptacioacuten
U0119 Verificar que al descubrir dos puntos de acceso en grupos diferentes ambos son antildeadidos en el
grupo correcto
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Configuracioacuten
3 El usuario puede Navegar a la pestantildea de Grupos
4 El usuario puede descubrir un punto de acceso en el grupo ldquorootrdquo correctamente
5 El usuario puede crear un subgrupo predecesor del grupo ldquorootrdquo correctamente
6 El usuario puede navegar al subgrupo creado correctamente
7 El usuario puede descubrir un punto de acceso en el subgrupo correctamente
96
6312 Diagramas de Flujo
Figura 77 Diagrama de flujo de Caso de Prueba U0119
97
6313 Script de Pruebas
Una vez establecidos los criterios de aceptacioacuten el script de prueba realizado a partir del diagrama de flujo
anterior es el siguiente
Figura 78 Script de Prueba U0119
Entre las keywords implementadas para esta prueba cabe destacar la implementacioacuten de ldquoVerify if AP is
registered Succesfully on grouprdquo la cual permite validar si un punto de acceso ha sido asignado al grupo
correcto
Figura 79 Keyword ldquoVerify if AP is registered Succesfully on grouprdquo
Puede observarse como en primer lugar se obtiene la fila de la tabla que contiene el punto de acceso en cuestioacuten
para posteriormente comprobar si el grupo al que pertenece es el esperado
Observando dicha implementacioacuten cabe destacar el uso de la Keyword ldquoInput Into Text Fieldrdquo la cual ha sido
implementada para vaciar el contenido de campos de texto ya que mediante la Keyword ldquoClear Element Textrdquo
de la libreriacutea Selenium2Library no se conseguiacutea borrar ciertos campos de texto
Figura 80 Keywords Input Into Text Field y Clear Field Of Characters
98
632 CHT Zones
En la pestantildea de gestioacuten de las diferentes Zonas CHT se puede observar una lista de los puntos de acceso
disponibles y se pueden realizar un conjunto de acciones sobre ellos como la creacioacuten eliminacioacuten y asociacioacuten
de zonas CHT
En este punto es conveniente explicar el concepto de zona CHT el cual se refiere a un grupo IP Multicast a
traveacutes del cual un conjunto de Puntos de Acceso establece comunicacioacuten de forma colaborativa Esta
comunicacioacuten es necesaria para el funcionamiento de algunos de los algoritmos que ofrece CHT como por
ejemplo la asignacioacuten automaacutetica de canal (ACA)
Figura 81 Pestantildea ldquoCHT Zonesrdquo
Sobre esta vista se han realizado un total de 6 casos de prueba de los cuales detallaremos el caso de prueba
identificado con la etiqueta U0204 Este caso de prueba permite validar la asignacioacuten de zonas CHT a los Puntos
de Acceso
6321 Criterios de Aceptacioacuten
U0204 Verificar que un usuario puede asignar una Zona CHT a un punto de acceso correctamente
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Configuracioacuten
3 El usuario puede Navegar a la pestantildea de Grupos
4 El usuario puede asignar una Zona CHT existente a un punto de acceso registrado correctamente
99
6322 Diagramas de Flujo
Figura 82 Diagrama de Flujo de Caso de Prueba U0204
6323 Script de Pruebas
Tras presentar los criterios de aceptacioacuten y su correspondiente diagrama de flujo el script de pruebas
implementado para la automatizacioacuten de dicha prueba es el siguiente
Figura 83 Scripts de Prueba U0204
Figura 84 Keyword Add Zone CHT to AP
100
633 BackupRestore
En esta pestantildea se permite la gestioacuten de copias de seguridad y restauracioacuten de los puntos de acceso registrados
en un Zone Manager Se puede observar en esta vista una tabla con los puntos de acceso registrados y otra tabla
con las copias de seguridad realizadas sobre los puntos de acceso
Figura 85 Pestantildea BackupRestore
Partiendo de la representacioacuten funcional de esta vista se han realizado un total de 8 casos de prueba de los
cuales detallaremos el caso de prueba identificado con la etiqueta U0401 el cual permite verificar de forma
automaacutetica la realizacioacuten de un backup sobre un punto de acceso y su posterior restauracioacuten
6331 Criterios de Aceptacioacuten
U0401 Verificar que un usuario puede realizar un BackupRestore correctamente sobre un punto de
acceso previamente registrado
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Configuracioacuten
3 El usuario puede Navegar a la pestantildea de BackupRestore
4 El usuario puede realizar un Backup sobre un punto de acceso existente
5 La tabla de Backups contiene la copia de seguridad realizada
6 El usuario puede restaurar un punto de acceso correctamente
101
6332 Diagramas de Flujo
Figura 86 Diagrama de Flujo de Caso de Prueba U0401
6333 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 87 Script de Prueba U0401
Cabe destacar la implementacioacuten de la Keyword ldquoRestore for AP have done successfullyrdquo la cual verifica que
el punto de acceso ha sido restaurado correctamente esperando que el punto de acceso vuelva a estar en estado
ldquoonlinerdquo durante un tiempo aceptable Si pasado dicho tiempo no recupera dicho estado la prueba se dariacutea por
erroacutenea
Figura 88 Keyword Restore For AP hace done successfully
634 Firmware
Esta uacuteltima pestantildea de la vista principal de configuracioacuten proporciona al usuario la posibilidad de subir los
firmwares de los diferentes modelos de puntos de acceso en sus diferentes versiones del software CHT de forma
que es posible la actualizacioacuten del firmware de los puntos de acceso desde la plataforma Se puede observar en
esta vista una tabla con los puntos de acceso registrados y otra tabla con los firmwares subidos a la plataforma
102
Figura 89 Pestantildea ldquoFirmwarerdquo
Partiendo de la representacioacuten funcional de esta vista se han realizado un total de 7 casos de prueba de los
cuales detallaremos el caso de prueba identificado con la etiqueta U0303 el cual permite verificar de forma
automaacutetica la actualizacioacuten del firmware de un punto de acceso
6341 Criterios de Aceptacioacuten
U0303 Verificar que un usuario puede realizar correctamente la actualizacioacuten del firmware de un punto
de acceso
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Configuracioacuten
3 El usuario puede Navegar a la pestantildea de Firmware
4 El usuario puede subir un firmware correctamente
5 La tabla de Firmwares contiene la imagen de CHT subida a la plataforma
6 El usuario puede realizar la actualizacioacuten del firmware sobre un punto de acceso correctamente
Destacar que el firmware que se desea aplicar sobre un punto de acceso debe ser del modelo correspondiente al
punto de acceso usado ya que cada punto de acceso tiene una imagen de CHT compilada para una arquitectura
hardware determinada Las imaacutegenes son proporcionadas por un servidor interno de la empresa
103
6342 Diagramas de Flujo
Figura 90 Diagrama de Flujo de Caso de Prueba U0303
6343 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 91 Script de Prueba U0303
Cabe destacar la implementacioacuten de la Keyword ldquoFlash APrdquo la cual realiza la actualizacioacuten del firmware de un
punto de acceso verificando que este ha concluido correctamente Para ello espera un tiempo aceptable a que el
punto de acceso vuelva al estado ldquoonlinerdquo
Figura 92 Keyword Flash AP
104
64 Vista de Red (Network Tab)
La uacuteltima vista principal sobre la que se han automatizado pruebas es la vista de Red la cual ofrece al usuario
la gestioacuten y configuracioacuten de su red formada por un conjunto de puntos de acceso previamente registrados
Entre las funcionalidades ofrecidas se encuentran la creacioacuten de VLANS SSIDs Portales Cautivos Perfiles
Radius Activacioacuten de algoritmos CHT y la configuracioacuten de puntos de acceso en tiempo real desde la
plataforma Web
Para describir el proceso de automatizacioacuten se comenzaraacute detallando en primer lugar la creacioacuten de VLANS
Brigdes y SSIDs para posteriormente aplicar dichos paraacutemetros a puntos de acceso desde las pestantildeas ldquoGeneralrdquo
y ldquoAP Networkrdquo Finalmente se mostraraacuten algunos ejemplos sobre otras configuraciones maacutes avanzadas como
la creacioacuten y aplicacioacuten de perfiles radius y portales cautivos ademaacutes de la activacioacuten de algoritmos
641 VLANS amp Bridges
Comenzando con la pestantildea de VLANS amp Bridges se puede observar la existencia de una tabla para cada
elemento de dicha vista
Figura 93 Pestantildea ldquoVLAN amp Bridgesrdquo
Para cada elemento se han automatizado un conjunto de pruebas formado por 6 casos de prueba de los cuales
detallaremos el caso de prueba identificado con la etiqueta U0527 Este caso de prueba permite validar de forma
automaacutetica la creacioacuten y eliminacioacuten de VLANs De forma ideacutentica se procederiacutea para validar la creacioacuten y
eliminacioacuten de Bridges
6411 Criterios de Aceptacioacuten
A continuacioacuten se detallan los criterios de aceptacioacuten del caso de prueba seleccionado
U0527 Verificar que un usuario puede crear y eliminar una VLAN correctamente
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Network
3 El usuario puede Navegar a la pestantildea de VLANS amp Bridges
4 El usuario puede crear una VLAN correctamente
5 El usuario puede eliminar una VLAN correctamente
105
6412 Diagramas de Flujo
Figura 94 Diagrama de Flujo de Caso de Prueba U0527
6413 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 95 Script de Prueba U0527
Cabe destacar la implementacioacuten de la Keyword ldquoGo and Create VLANrdquo la cual permite crear una VLAN en
funcioacuten de los paraacutemetros de entrada deseados para configurar dicha VLAN como por ejemplo el ldquoIDrdquo de la
VLAN y alias o si se desea que dicha VLAN sea de tipo dinaacutemica
Figura 96 Keyword Go And Create VLAN
106
642 SSIDs
Esta pestantildea proporciona una tabla que permite registrar SSIDs con diferentes configuraciones posibles
Figura 97 Pestantildea SSIDs
Para cada funcionalidad de dicha pestantildea se han automatizado un conjunto de pruebas formado por 5 casos de
prueba de los cuales detallaremos el caso de prueba identificado con la etiqueta U0530 Este caso de prueba
permite validar de forma automaacutetica la creacioacuten y eliminacioacuten de SSIDS
6421 Criterios de Aceptacioacuten
A continuacioacuten se detallan los criterios de aceptacioacuten de los dos casos de prueba seleccionados
U0530 Verificar que un usuario puede crear y eliminar una SSID correctamente
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Network
3 El usuario puede Navegar a la pestantildea de SSIDs
4 El usuario puede crear una SSID correctamente
5 El usuario puede eliminar una SSID correctamente
6422 Diagramas de Flujo
Figura 98 Diagrama de Flujo de Caso de Prueba U0530
107
6423 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 99 Script de Prueba U0530
Cabe destacar la implementacioacuten de la Keyword ldquoGo and Create SSIDrdquo la cual permite crear una SSID en
funcioacuten de los paraacutemetros de entradas deseado para configurar dicha SSID como por ejemplo tipo de
encriptacioacuten de la contrasentildea modo oculto o habilitacioacuten de los algoritmos Load Balancing (LB) Smart
roaming (SR) o PRE
Figura 100 Keyword Go And Create SSID
108
643 CHT
Esta funcionalidad permite activar el algoritmo que permite la seleccioacuten automaacutetica de canal entre un conjunto
de puntos de acceso (ACA) Cuando se activa desde la plataforma Web todos los puntos de acceso
pertenecientes a un Zone Manager activan dicho algoritmo el cual se trata de un algoritmo colaborativo
mediante el cual los puntos de acceso acuerdan cual es el mejor canal para la comunicacioacuten WiFi con los clientes
que se conecten tanto en la banda de 24 GHz como en la de 5 GHz En la siguiente figura se muestra la vista
de la plataforma Web para activar el algoritmo en cuestioacuten
Figura 101 Pestantildea ldquoCHTrdquo
Dado que se trata de una funcionalidad en la que solo se debe comprobar si el algoritmo estaacute en el mismo estado
tanto en la plataforma Web como en los puntos de acceso registrados se ha implementado un uacutenico caso de
prueba identificado con la etiqueta U539 Este caso de prueba realiza la conexioacuten a los puntos de acceso para
verificar que dicho algoritmo presenta el mismo estado que en la plataforma
6431 Criterios de Aceptacioacuten
U0537 Verificar que un usuario puede Activar o Desactivar el algoritmo ACA correctamente
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Network
3 El usuario puede Navegar a la pestantildea de CHT
4 El usuario puede ActivarDesactivar el algoritmo ldquoACA ldquocorrectamente
5 Los APs recibieron las oacuterdenes para ActivarDesactivar el algoritmo ldquoACArdquo correctamente
109
6432 Diagramas de Flujo
Figura 102 Diagrama de Flujo de Caso de Prueba U0539
6433 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 103 Script de Prueba U0539
En cuanto a la implementacioacuten de dicho caso de prueba cabe destacar la implementacioacuten de la Keyword ldquoACA
Is Workingrdquo las cual se muestra en la siguiente figura
Figura 104 Keyword ACA Is Working
Puede observarse como en funcioacuten de si el algoritmo ACA esta activado o desactivado en la plataforma Web
(ENABLE DISABLE) se ejecuta la Keyword ldquoChanges On CLIrdquo con diferentes paraacutemetros Esta Keyword
permite la conexioacuten viacutea ldquoSSHrdquo con un punto de acceso para la ejecucioacuten de un comando sobre el mismo y la
posterior comparacioacuten del resultado obtenido por dicho comando con la salida deseada proporcionada tambieacuten
como paraacutemetro de la Keyword
110
En la siguiente figura se muestra la implementacioacuten de dicha Keyword
Figura 105 Keyword Changes On CLI
Para este caso de prueba el comando ejecutado de forma remota sobre el punto de acceso permite obtener de
forma automaacutetica el estado del algoritmo ldquoACArdquo de la siguiente forma
Figura 106 Comando CHT para obtener el estado del moacutedulo ACA en el punto de acceso
644 Radius
Esta pestantildea proporciona una tabla que permite registrar perfiles Radius con diferentes configuraciones posibles
Figura 107 Pestantildea ldquoRadiusrdquo
ldquoRadiusrdquo se define como un protocolo de autenticacioacuten y autorizacioacuten para aplicaciones de acceso a la red o
movilidad IP De esta forma los puntos de acceso mediante la existencia de un servidor radius permiten que los
usuarios que se quieran conectar por WiFi necesiten ser autenticados con credenciales Dicha autenticacioacuten seraacute
redirigida por el punto de acceso al servidor radius el cual autoriza al punto de acceso para que permita la
conexioacuten del cliente
Ademaacutes el uso de este servicio junto con la configuracioacuten mediante VLAN dinaacutemicas permite que diferentes
usuarios accedan al servicio de red con diferentes credenciales de forma que seguacuten el tipo de cliente su traacutefico
viajaraacute por una VLAN u otra Esto permite la separacioacuten del traacutefico a nivel de enlace ofreciendo la posibilidad
de establecer reglas de control de traacutefico y ofrece una QoS miacutenima en funcioacuten del tipo de cliente
Figura 108 Escenario de Funcionamiento de Servidor Radius
111
Para cada funcionalidad de dicha pestantildea se han automatizado un conjunto de pruebas formado por 7 casos de
prueba de los cuales detallaremos el caso de prueba identificado con la etiqueta U0601 Este caso de prueba
permite validar de forma automaacutetica la creacioacuten edicioacuten y borrado de un perfil radius en la plataforma Web
6441 Criterios de Aceptacioacuten
U0601 Verificar que un usuario puede crear editar y borrar un perfil Radius correctamente
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Network
3 El usuario puede Navegar a la pestantildea de Radius
4 El usuario puede Crear un perfil Radius correctamente
5 El usuario puede Editar un perfil Radius correctamente
6 El usuario puede Eliminar un perfil Radius correctamente
6442 Diagramas de Flujo
Figura 109 Diagrama de Flujo de Caso de Prueba U0601
6443 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 110 Script de Prueba U0601
En cuanto a la implementacioacuten de dicho caso de prueba puede destacarse por ejemplo la implementacioacuten de
la Keyword ldquoCreate Radius Profilerdquo la cual permite crear un perfil ldquoRadiusrdquo a partir de un conjunto de
paraacutemetros de entrada
112
Figura 111 Keyword Create Radius Profile
645 Captive Portal
Esta pestantildea proporciona una tabla que permite registrar perfiles de Portales Cautivos con diferentes
configuraciones posibles
Figura 112 Pestantildea Captive Portals
Un portal cautivo es un servicio que permite el control del traacutefico HTTP y fuerza a los usuarios de una red a la
autenticacioacuten mediante una paacutegina Web para tener acceso a Internet Dicho portal permite controlar paraacutemetros
como el tiempo de conexioacuten de un cliente a la red ancho de banda ofrecido a cada cliente etc
Figura 113 Escenario de Funcionamiento de un Portal Cautivo
Para cada funcionalidad de dicha pestantildea se han automatizado un conjunto de pruebas formado por 5 casos de
prueba de los cuales detallaremos el caso de prueba identificado con la etiqueta U0701 Este caso de prueba
permite validar de forma automaacutetica la creacioacuten edicioacuten y borrado de un perfil de portal cautivo en la plataforma
Web
113
6451 Criterios de Aceptacioacuten
U0701 Verificar que un usuario puede crear editar y borrar un perfil de Portal Cautivo correctamente
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Network
3 El usuario puede Navegar a la pestantildea de Captive Portals
4 El usuario puede Crear un perfil de Portal Cautivo correctamente
5 El usuario puede Editar un perfil de Portal Cautivo correctamente
6 El usuario puede Eliminar un perfil de Portal Cautivo correctamente
6452 Diagramas de Flujo
Figura 114 Diagrama de Flujo de Caso de Prueba U0701
6453 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 115 Script de Prueba U0701
114
En cuanto a la implementacioacuten de dicho caso de prueba puede destacarse por ejemplo la implementacioacuten de
la Keyword ldquoEdit or delete Captive Portal Profilerdquo la cual permite editar o eliminar un perfil de Portal Cautivo
a partir de un conjunto de paraacutemetros de entrada
Figura 116 Keyword Edit or Delete Captive Portal Profile
115
646 General
Esta pestantildea muestra la vista general de la pestantildea ldquoNetworkrdquo En esta pestantildea se agrupa el conjunto de puntos
de acceso actualmente registrados en el Zone Manager con un resumen de su configuracioacuten de red actual el
estado en el que se encuentran y nuacutemero de clientes conectados Ademaacutes dicha vista proporciona un acceso
directo a la pestantildea ldquoAP Networkrdquo seleccionando uno o varios puntos de acceso de un mismo modelo En la
siguiente seccioacuten se explica la funcionalidad de dicha pestantildea
Figura 117 Pestantildea General
Para cada elemento se han automatizado un conjunto de pruebas formado por 9 casos de prueba de los cuales
detallaremos el caso de prueba identificado con la etiqueta U0522 Este caso de prueba se permite validar de
forma automaacutetica la conexioacuten de clientes a un punto de acceso con una SSID asignada de forma que el nuacutemero
de clientes conectados que se muestra en la plataforma Web sea correcto
6461 Criterios de Aceptacioacuten
U0522 Conectar clientes y verificar que el nuacutemero de clientes conectados es correcto
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Network
3 El usuario puede Navegar a la pestantildea General
4 El usuario tiene disponible un punto de acceso en el Zone Manager con una SSID asignada
5 El usuario conecta un cliente al punto de acceso por WiFi a la SSID asignada
6 El usuario verifica que el nuacutemero de clientes conectados incrementa en una unidad
116
6462 Diagramas de Flujo
Figura 118 Diagrama de Flujo de Caso de Prueba U0522
6463 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de prueba automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 119 Script de Prueba U0522
En cuanto a la implementacioacuten de dicho caso de prueba puede destacarse por ejemplo la implementacioacuten de
la Keyword ldquoCheck Number of Clients Increasesrdquo la cual permite comprobar que el nuacutemero de clientes conectados incrementa al conectar un cliente a un punto de acceso
Figura 120 Keyword Check Number of Clients Increases
117
647 AP Network
Esta pestantildea muestra la vista principal de la pestantildea ldquoAP Networkrdquo La funcionalidad que proporciona engloba
todos los posibles paraacutemetros de configuracioacuten para un punto de acceso que ha sido seleccionado previamente
desde la pestantildea General Cualquier configuracioacuten aplicada sobre esta vista seraacute enviada al punto de acceso
desde la plataforma Web permitiendo configurar los puntos de acceso de Galgus
Desde el punto de vista de la plataforma Web esta vista abarca un conjunto de funcionalidades consideradas
como maacutes complejas que se ofrecen en la plataforma Web por lo que es en esta vista donde puede encontrarse
una de las mayores aacutereas de riesgo de la plataforma Entre las funcionalidades que se ofrecen estaacuten la
configuracioacuten de las radios de un punto de acceso (Potencia Ancho de banda Canal etc) asignacioacuten de SSIDs
a las interfaces inalaacutembricas y configuracioacuten de reglas de control de traacutefico (TC Rules) asignacioacuten de puertos a
las diferentes subredes virtuales de aacuterea local (VLANS) o configuracioacuten de Portal Cautivo
Figura 121 Pestantildea AP Network
Para cada elemento se han automatizado un conjunto de pruebas formado por 28 casos de prueba los cuales la
mayoriacutea han requerido un amplio esfuerzo de implementacioacuten para conseguir su automatizacioacuten ya que son
pruebas cuya secuencia de acciones es larga ademaacutes de requerir en muchas ocasiones la verificacioacuten de la
configuracioacuten en los puntos de acceso viacutea ldquosshrdquo Para ello se ha hecho uso entre otras de la libreriacutea
ldquoSSHLibraryrdquo proporcionada por Robot Framework
Figura 122 Libreriacutea SSH para Robot Framework
118
Del conjunto de casos de prueba que validan la funcionalidad de dicha pestantildea se va a detallar el caso de prueba
identificado con la etiqueta U0511 Este caso de prueba permite validar de forma automaacutetica que se pueden
aplicar reglas de control de traacutefico ldquoTCsrdquo a una SSID asignada a las interfaces inalaacutembricas de un punto de
acceso desde la plataforma Web
Figura 123 Ventana de Configuracioacuten de TC Rules
6471 Criterios de Aceptacioacuten
U0511 Asignar ldquoTC Rulesrdquo a una SSID asociada a un Punto de Acceso correctamente
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Network
3 El usuario puede Navegar a la pestantildea General
4 El usuario tiene disponible un punto de acceso en el Zone Manager
5 El usuario puede seleccionar un punto de acceso
6 El usuario puede Navegar a la pestantildea AP Network para el punto de acceso seleccionado
7 El usuario puede asignar a las interfaces inalaacutembricas una SSID existente y crear ldquoTC Rulesrdquo sobre
esa SSID
8 El usuario puede aplicar la configuracioacuten
9 El punto de acceso aplica su configuracioacuten correctamente
10 El punto de acceso pasa al estado ldquoOnlinerdquo en la plataforma Web y su configuracioacuten estaacute alineada
119
6472 Diagramas de Flujo
Figura 124 Diagrama de Flujo de Caso de Prueba U0511
120
6473 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 125 Script de Prueba U0511
En cuanto a la implementacioacuten de dicho caso de prueba puede destacarse por ejemplo la implementacioacuten de
la Keyword ldquoWait Timerrdquo la cual permite verificar que no se produce ninguacuten error al aplicar una configuracioacuten
determinada desde la plataforma Web durante un tiempo determinado
Figura 126 Keyword Wait Timer
Destacar tambieacuten la implementacioacuten de la Keyword ldquoCheck On CLIrdquo la cual permite contrastar que la
configuracioacuten aplicada desde la plataforma sobre un punto de acceso es la esperada En este caso se comprueba
que las ldquoTC Rulesrdquo han sido correctamente aplicadas para una SSID determinada en un punto de acceso de
forma remota mediante el uso de la libreriacutea ldquoSSHrdquo para Robot Framework
Figura 127 Keyword Check On CLI
121
122
7 LINEAS DE MEJORA Y CONCLUSIONES
n este uacuteltimo capiacutetulo se analizaraacuten resultados y conclusiones obtenidas sobre el uso de pruebas
automatizadas para la verificacioacuten y validacioacuten de una plataforma Web como la de Galgus Se
detallaraacuten algunas ventajas e inconvenientes encontrados y se plantearaacuten algunas liacuteneas de mejora
futuras sobre el proyecto desarrollado Con estas mejoras se busca como objetivo enriquecer el proceso de
automatizacioacuten de pruebas ademaacutes de hacerlo maacutes efectivo y metoacutedico en todos sus aspectos ya que siempre
hay algo que se puede mejorar para conseguir una herramienta maacutes completa y uacutetil
Se detallaraacuten tambieacuten aspectos de aprendizaje opiniones experiencias y en definitiva todas las conclusiones
sacadas sobre este proyecto incluyendo tambieacuten las dificultades encontradas para el desarrollo del mismo
71 Liacuteneas de Mejora Futuras
El estudio y puesta en marcha de este Proyecto de automatizacioacuten de pruebas de Software ha hecho uso de una
amplia cantidad de herramientas ofrecido por Selenium y Robot Framework ademaacutes de otras herramientas que
han permitido enriquecer el mismo con mayores funcionalidades ofrecidas al equipo de Proyecto Si bien se ha
logrado conseguir un paquete de pruebas con una capacidad de detectar defectos en un producto Web existen
diversas ampliaciones de dicho Proyecto que podriacutean aumentar de manera considerable el desempentildeo de las
herramientas de automatizacioacuten a lo largo del ciclo de vida del proyecto
A continuacioacuten se muestran algunas de las maacutes importantes
bull Uso de Integracioacuten Continua Robot Framework es faacutecilmente integrable principalmente con Jenkins
aunque tambieacuten ofrece la posibilidad de integrarlo con Gitlab CICD Esto permitiriacutea programar la
ejecucioacuten de pruebas automaacuteticamente para diferentes versiones del proyecto Galgus CHT Cloud
Manager o en diferentes fases del mismo Con esta caracteriacutestica se detectariacutean con mayor facilidad los
problemas relacionados con la configuracioacuten del entorno de trabajo y se podriacutea notificar por email a
los responsables de equipo ante los eventuales incidentes encontrados De este modo no seriacutea necesario
estar supervisando el proceso de ejecucioacuten para estar al tanto de un fallo en el sistema En este aspecto
se ha trabajado para conseguir estos objetivos con la creacioacuten de un Docker de Robot Framework que
permita la ejecucioacuten de las pruebas en el mismo para poder usarla en el entorno de integracioacuten continua
correspondiente Tambieacuten se ha implementado un primer un script que permita la ejecucioacuten de paquetes
de pruebas en dicho entorno
bull Selenium Grid El caso praacutectico descrito tiene un inconveniente y es que solo hace uso de Chrome
Suele ser frecuente que ciertos defectos en una aplicacioacuten Web solo aparezcan en determinados
navegadores Con herramientas como Selenium Grid permitiriacutean la ejecucioacuten en paralelo de las pruebas
en maacutequinas con diferentes sistemas operativos y navegadores Asiacute se podriacutea evaluar de manera
independiente la compatibilidad del producto en entornos multiplataforma Ademaacutes esta herramienta
es totalmente compatible con Jenkins o Gitlab CICD con las ventajas que esto supone
bull Headless browser Esto hace referencia al uso de navegadores sin interfaz graacutefica de usuario La mayor
parte del tiempo durante una ejecucioacuten es destinada a esperar a que el navegador renderice el contenido
Si se elimina este factor de la foacutermula y se accede directamente al DOM de la Web se consigue una
reduccioacuten en el tiempo de ejecucioacuten de las pruebas Durante el desarrollo de este proyecto se ha
trabajado en este aspecto ofrecieacutendose la posibilidad de ejecutar las pruebas en dos entornos diferentes
una primera de depuracioacuten de pruebas que realiza el renderizado del navegador y otra opcioacuten que
E
La tecnologiacutea por siacute sola no basta Tambieacuten tenemos que poner el corazoacuten
Jane Goodall
123
permite la ejecucioacuten de pruebas sin renderizado del navegador (Modo Headless)
bull Buenas praacutecticas en la localizacioacuten de elementos en el DOM de la Web La aplicacioacuten de este tipo
de buenas praacutecticas permitiriacutean una mejor y maacutes eficiente localizacioacuten de los elementos en el DOM
reduciendo la posibilidad de que las pruebas generen falsos errores Esto es lo que ha causado la mayor
parte de los problemas de implementacioacuten y ejecucioacuten de las pruebas automaacuteticas Actualmente la
herramienta de automatizacioacuten de pruebas se encuentra en un proceso de mejora continua en el que se
estaacute abordando una refactorizacioacuten para la aplicacioacuten de estas buenas praacutecticas Para ello se estaacuten
haciendo uso de selectores avanzados basados en rutas (Xpaths) relativas en el DOM de la Web las
cuales realizan la mayoriacutea de las buacutesquedas por contenido y no por ruta absoluta como se veniacutea
haciendo hasta ahora
bull Aplicacioacuten de Model Based Testing (MBT) Como estudio del arte se ha presentado una teacutecnica que
permite dar un paso maacutes en la automatizacioacuten de pruebas Como se ha detallado en el proyecto esta
teacutecnica permite ascender en el nivel de abstraccioacuten de las pruebas basando las mismas en el disentildeo y
modelado de la aplicacioacuten Dicha teacutecnica se encuentra principalmente en proceso de investigacioacuten lo
cual hace difiacutecil aplicarla aunque seriacutea de gran intereacutes conseguir su implantacioacuten
72 Conclusiones Finales
En el desarrollo del presente Proyecto se ha analizado una pequentildea extensioacuten del inmenso mundo de la gestioacuten
de calidad Esta ha ido tomando fuerza con el paso de los antildeos en el mercado actual introducieacutendose en todos
los aacutembitos incluido en el software La gestioacuten de calidad se ha profesionalizado de tal forma que el papel del
ingeniero de calidad en los proyectos de software es imprescindible en cualquier empresa que quiera hacerse un
hueco en el mercado como garantiacutea de calidad
La elevada exigencia del mercado del software provocada por la gran demanda de clientes y usuarios finales
para recibir un producto en el menor tiempo posible hace que en muchos casos las empresas centren su esfuerzo
en sacar un producto lo antes posible reduciendo los esfuerzos destinados a los procesos de calidad de dicho
producto software Originalmente las pruebas de software realizadas sobre un producto se realizaban de forma
manual por un ingeniero de calidad pero con el avance de las tecnologiacuteas la automatizacioacuten de las mismas
supone un elevado esfuerzo inicial pero una reduccioacuten de los mismos a medio plazo
En este proyecto se ha desarrollado una herramienta que permite la automatizacioacuten de pruebas funcionales sobre
una plataforma Web concretamente pruebas de aceptacioacuten sobre Galgus CHT Cloud Manager Las pruebas de
automatizacioacuten elaboradas reflejan que existen tecnologiacuteas muy asequibles en teacuterminos de coste compatibilidad
y facilidad de uso para iniciarse en el mundo de las pruebas funcionales de sistemas Algo muy presente en el
mundo laboral actual es la creciente demanda de expertos en automatizacioacuten en todas las principales
plataformas Web Moacutevil y Escritorio Muchos de estos profesionales vienen del mundo del testing manual por
lo que conociendo ya la nomenclatura y el funcionamiento de los procesos de calidad solo necesitan dar el paso
hacia el uso de este tipo de herramientas Sea con Selenium o con cualquier otra herramienta los conceptos
teoacutericos presentados en este proyecto son igualmente vaacutelidos
Por otra parte debe destacarse la dificultad encontrada a la hora de establecer unos criterios de aceptacioacuten de las
funcionalidades de la plataforma Web bajo pruebas Esto se debe al desarrollo de una herramienta de
automatizacioacuten de pruebas que se ha iniciado en una fase avanzada del desarrollo del proyecto con lo cual en
muchas ocasiones surgiacutean dudas sobre el disentildeo del proyecto Adicionalmente la propia estructura y tecnologiacuteas
usadas en la Web dificultaron al inicio la localizacioacuten de elementos A esta causa de une tambieacuten la ausencia de
identificadores uacutenicos en los elementos que componen la misma Esto se tradujo en el uso de selectores basados
en la ruta del elemento pudiendo acarrear la aparicioacuten de posibles falsos errores debidos a cambios en el coacutedigo
fuente de la plataforma Web La solucioacuten adoptada para tal problema no fue maacutes que analizar meticulosamente
aquellas ejecuciones fallidas para descartar errores reales y en caso de que sean debidas a los selectores aplicar
la debida actualizacioacuten de los mismos
En este uacuteltimo aspecto cabe destacar que el proyecto de automatizacioacuten de pruebas se encuentra actualmente
en una fase de mejora continua en la que se estaacuten adoptando teacutecnicas basadas en el uso de selectores avanzados
basados en rutas relativas y nombres que permitan reducir el impacto del problema presentado en este punto
124
A modo de resumen se plantean algunas ventajas en el uso de SeleniumRobot Framework para la
automatizacioacuten de pruebas
Facilidad de configuracioacuten y uso Su instalacioacuten requiere un esfuerzo miacutenimo y el poder de
abstraccioacuten ofrecido por Robot Framework hace posible la lectura y entendimiento de los paquetes de
pruebas y reportes a todos los miembros del equipo
Cantidad de documentacioacuten disponible La comunidad respalda ambos proyectos y es por ello que
encontramos soluciones de todo tipo adaptadas a las necesidades de cada uno
Soporte para la mayoriacutea de navegadores con el mismo script Ejecutar el script de pruebas
desarrollado para su automatizacioacuten en otro navegador requiere simplemente la instalacioacuten del
controlador deseado y usar un determinado paraacutemetro para indicar el uso de dicho controlador en la
llamada de la Keyword encargada de la apertura del navegador
De la misma forma se pueden destacar algunas desventajas
Selenium soacutelo es compatible con productos Web Cualquier software moacutevil o de escritorio requiere
del uso de otros frameworks o herramientas lo cual puede ser un punto negativo para empresas que
tengan productos multiplataforma Sin embargo Robot Framework si proporciona soporte
multiplataforma con la integracioacuten de otras herramientas o framework para su desarrollo
Tecnologiacuteas no optimizadas para pruebas de rendimiento En este punto cabe destacar el esfuerzo
de la comunidad para desarrollar herramientas que permitan la automatizacioacuten de este tipo de pruebas
con Robot Framework como por ejemplo ldquorfswarmrdquo
Compatibilidad de versiones de paquetes de Software Es frecuente usar determinadas
combinaciones de versiones de paquetes para lograr un framework estable y robusto Esto a veces puede
convertirse en una tarea tediosa donde cuestan encajar piezas Por suerte es algo que se estaacute teniendo
en cuenta con las uacuteltimas versiones de Selenium
Puede concluirse que durante el desarrollo de este proyecto se ha conseguido la creacioacuten de una herramienta
sencilla de usar y entender para la automatizacioacuten de pruebas funcionales sobre una plataforma Web ademaacutes
de preparar dicha herramienta para integrarla en el proceso de integracioacuten continua implantado para dicha
aplicacioacuten Web con Gitlab mediante Docker Ademaacutes se ha realizar un estudio del arte de una teacutecnica conocida
bajo el nombre de Model Based Testing (MBT) que permitiriacutea mejorar el proceso de automatizacioacuten y la
herramienta desarrollada para tal fin
Con todo ello he aprendido multitud de conceptos tecnologiacuteas y herramienta que hasta ahora desconociacutea cuaacutel
era su finalidad o funcionamiento como por ejemplo Robot Framework Para ello he necesitado gran cantidad
de formacioacuten previa antes de comenzar a ponerlo en praacutectica para el desarrollo de la herramienta de
automatizacioacuten
Son muchos los errores cometidos hasta conseguir los objetivos y metas propuestas los cuales creo que son los
sucesos maacutes importantes pues de ellos se aprende y son los que nos hacen avanzar cuando los resolvemos
Finalmente destacar que este proyecto me ha dado la oportunidad de abrir mi conocimiento en un campo de las
tecnologiacuteas de la informacioacuten el cual resulta de intereacutes Dar las Gracias a mis tutores Pablo Aguilera Bonet y
Daniel Gutieacuterrez Reina ademaacutes de mi responsable en Galgus Joseacute Antonio Delgado Alfonso por brindarme
esta oportunidad ademaacutes de ayudarme y asesorarme estando siempre disponible y con dedicacioacuten hacia este
proyecto para que haya podido llevarse a cabo
125
126
REFERENCIAS
[1] M Utting Bruno Legeard Practical Model-based Testing sl Elsevier 2007
[2] Ibrahim K El-Far Enjoying the perks of model-based testing In Proceedings of the Software Testing
Analysis and Review Conference
[3] A C Dias Neto Rajesh Subramanyan Marlon Vieirab Characterization of Model-based Software
[4] Model-based Testing Next Generation Functional Software Testing Legeard Bruno Dagstuhl Seminar
Proceedings 10111 Vol httpdropsdagstuhldeopusvolltexte20102620
[5] Perspectives of Model-Based Testing Ed Brinksma Wolfgang Grieskamp and Jan Tretmans IBFI
Schloss Dagstuhl Germany sn 2005 Dagstuhl Seminar Proceedings
[6] Definicioacuten de Calidad httpsdleraeesid=6nVpk8P|6nXVL1Z
[7] Modelos de calidad del software httpswwwresearchgatenetpublication316674475
[8] Calidad del Software ldquoEl camino al exitordquo LI Alma Delia Chaacutevez Rojas
[9] IEEE Software Engineering Book of Knowledge IEEE sl IEEE 2004
[10] Principios de pruebas software httpsmediumcomatejedaccsprincipios-del-testing-722323e16e76
[11] httpwwwsstqbesw3docsGLOSARIO_V00110pdf
[12] httpsepdfpubsoftware-testing-an-istqb-iseb-foundation-guidehtml
[14] IEEE standard glossary of software engineering terminology F Jay RMayer 1990 paacuteg IEEE Std 610
[15] Openwrt httpsopenwrtorgsupported_devices
[16] RabbitMQ httpswwwrabbitmqcom
[17] Zero Touch Provisioning httpssearchdatacentertechtargetcomesdefinicionAprovisionamiento-de-
cero-toque-ZTP-o-zero-touch-provisioning
[18] Robot Framework User Guide
httpsrobotframeworkorgrobotframeworklatestRobotFrameworkUserGuidehtml
[19] Gitlab httpsdocsgitlabcom
[20] httpswwwfederico-toledocomcuando-automatizar-una-prueba
127
128
ANEXO A PREPARACIOacuteN DEL ENTORNO DE
TRABAJO Y EJECUCIOacuteN DE PRUEBAS
A1 Preparacioacuten del entorno de trabajo
Para el desarrollo de las preubas automaacuteticas se ha hecho uso del sistema operative Linux con la distribucioacuten
Ubuntu El motivo de su uso es el amplio abanico de herramientas de coacutedigo libre que existen para esta
distribucioacuten asiacute como la enorme contribucioacuten que hace la comunidad de usuarios para mejorarla Sobre este
sistema operativo se ha hecho uso de un conjunto de herramientas para el montaje de un entorno de pruebas
automatizado basado en Python A continuacioacuten se detallaraacuten dichas herramientas
A11 Pip
Pip es un sistema de gestioacuten de paquetes que se utiliza para la instalacioacuten de los paquetes software
implementados en Python que se usaraacuten posteriormente La instalacioacuten de un paquete se realiza mediante la
ejecucioacuten del siguiente comando
A12 Virtualenv Entorno Virtual
Dado que cada proyecto basado en Python puede requerir la instalacioacuten de diferentes conjuntos de paquetes es
comuacuten usar la creacioacuten de entornos virtuales que nos permitan administrar cada proyecto de manera
independiente pudiendo tener otros proyectos haciendo uso de los mismos paquetes con otras versiones La
instalacioacuten se realiza mediante la herramienta ldquoPiprdquo a traveacutes del siguiente comando
Una vez instalado se puede crear un entorno virtual asociado a un proyecto de la siguiente forma
En este punto se creariacutea un entorno virtual para el proyecto deseado Ahora solo quedariacutea activarlo o iniciarlo
pip install nombre-del-paquete
pip install virtualenv
cd carpeta-del-proyecto
virtualenv ndashp usrbinpython27 mi-proyecto
source mi-proyectobinactivate
129
A13 Selenium y Chromedriver
La instalacioacuten de Selenium se realiza de la misma forma que el resto de paquetes con la herramienta ldquoPiprdquo
Por otra parte el controlador para el navegador Chrome Chromedriver puede ser descargado desde el
repositorio oficial httpschromedriverchromiumorg Ademaacutes Chromedriver debe ser accessible para
Selenium de cara a configurar el PATH
A14 Robot Framework y SeleniumLibrary
A continuacioacuten se realizariacutea la instalacioacuten de Robot Framework
Posteriormente se realizariacutea la instalacioacuten del paquete ldquoSelenium2Libraryrdquo el cual contiene la implementacioacuten
en python de las libreriacuteas necesarias para utilizar Robot Framework en Python
Llegados a este punto listando todos los paquetes instalados se deberiacutea tener algo similar a la siguiente figura
Con esta configuracioacuten del entorno este estariacutea preparado para elaborar los casos de prueba automatizados con
Robot Framework y Selenium
pip install selenium
export PATH=$PATHabsolute_path_of_chromedriver_file
pip install robotframework
pip install robotframework-selenium2library
130
A15 Otras dependencias
Para el desarrollo de pruebas que requieren otro tipo de herramientas como la transferencia de ficheros con el
servicio ldquoSCPrdquo o la conexioacuten remota a traveacutes del servicio ldquoSSHrdquo se require la instalacioacuten de los siguientes
paquetes
Ademaacutes para la realizacioacuten de pruebas avanzadas en Python para la gestioacuten del Mapa de la platform Web CHT
Cloud Manager se ha hecho uso de la librariacutea ldquohtml-testRunnerrdquo para ofrecer un reporte de la ejecucioacuten de
pruebas muy similar al ofrecido por Robot Framework
A2 Ejecucioacuten de Pruebas
Tras la implementacioacuten de las pruebas siguiendo el procedimiento indicado en la seccioacuten de Experimentos
ejecutar un script de pruebas se realiza mediante el uso del siguiente comando
Mediante el uso de la variable ldquoENVIROMENTrdquo puede seleccionarse el entorno en el que se desea ejecutar las
pruebas Con el entorno de ldquodebugrdquo las pruebas se ejecutariacutean de forma graacutefica mientras que el el entorno de
ldquodockerrdquo permite la ejecucioacuten de pruebas sin interfaz graacutefica Este uacuteltimo entorno seriacutea usado para la ejecucioacuten
de pruebas con el docker de Robot Framework que se ha implementado el cual se detallaraacute maacutes adelante
Por otro lado existen otras opciones para el comando anterio como por ejemplo
Las opciones ldquo-irdquo y ldquo-erdquo permiten ejecutar o excluir un caso de preuba en la ejecucioacuten de una Suite de pruebas
Por otro lado el uacuteltimo comando permite lanzar la ejcucioacuten de una Suite de pruebas y ejecutar soacutelo aquellos
casos de prueba que hayan fallado en la ejecucioacuten anterior
pip install robotframework-sshlibrary
pip install robotframework-scplibrary
pip install html-testRunner
robot --variable ENVIROMENTdebug_or_docker suite_filerobot
robot --variable ENVIROMENTdebug_or_docker ndashi U0000 suite_filerobot
robot --variable ENVIROMENTdebug_or_docker ndashe U0000 suite_filerobot
robot --rerunfailed outrerunfailedxml --output out2xml suite_filerobot
131
A continuacioacuten se muestra un ejemplo de ejecucioacuten de pruebas con Robot Framwork
132
A3 Script de Prueba U007 (MAP)
from selenium import webdriver
from seleniumwebdrivercommonby import By
from seleniumwebdriversupportui import WebDriverWait
from seleniumwebdriversupport import expected_conditions as EC
from seleniumwebdrivercommondesired_capabilities import DesiredCapabilities
from seleniumwebdrivercommonaction_chains import ActionChains
from seleniumcommonexceptions import TimeoutException
import math json multiprocessing time re
import sys
import unittest
import HtmlTestRunner
U0007 Double-click on Zone Manager and look if the Backend tab opens
class DClickZM(unittestTestCase)
driver = 0
canvas = 0
waitTime = 20
username = franciscodiaz
password = ahipeo8829g
classmethodg
def setUp(cls)
Enviroment Management
chrome_options = webdriverChromeOptions()
if sysargv[2] == docker
chrome_optionsadd_argument(--headless)
chrome_optionsadd_argument(--disable-extensions)
chrome_optionsadd_argument(--disable-gpu)
chrome_optionsadd_argument(--no-sandbox)
enable browser logging
d = DesiredCapabilitiesCHROME
d[loggingPrefs] = browser DEBUG
clsdriver = webdriverChrome(chrome_options=chrome_options desired_capabilities=d)
clsdrivermaximize_window()
clsdriverset_window_size(1920 1080)
load the desired webpage
clsdriverget(httpdevcloudgalgusnet)
def test_double_click_ZM(self)
loggin in the page
userNameBox = WebDriverWait(selfdriver 1)until(
ECpresence_of_element_located((ByXPATH [id=username])))
userNameBoxsend_keys(selfusername)
passwordBox = WebDriverWait(selfdriver selfwaitTime)until(
ECpresence_of_element_located((ByXPATH [id=password])))
passwordBoxsend_keys(selfpassword)
133
loginButton = WebDriverWait(selfdriver selfwaitTime)until(
ECpresence_of_element_located((ByXPATH
[id=myModalLabel]divdivformdiv[3]input)))
loginButtonclick() Tab General appears
selfcanvas = WebDriverWait(selfdriver selfwaitTime)
until(ECpresence_of_element_located((ByXPATH
htmlbodyappdivmaindivregister-
managersdivtabsetdivtab[1]aol-mapdivdivcanvas)))
timesleep(15)
action = ActionChains(selfdriver)
Manage Process
manager = multiprocessingManager()
return_dict = managerdict()
We create a Process
p_get_pixels_zm = multiprocessingProcess(target=selfGet_Pixels_ZM args=(return_dict selfdriver))
We create another Process
p_double_click_on_zm = multiprocessingProcess(target=selfDouble_Click_On_ZM args=(return_dict selfcanvas
action selfdriver))
We start the process and we block for 5 seconds
p_get_pixels_zmstart()
p_get_pixels_zmjoin(timeout=10)
p_double_click_on_zmstart()
p_double_click_on_zmjoin(timeout=10)
We terminate the process
p_get_pixels_zmterminate()
p_double_click_on_zmterminate()
try
Tab General appears
WebDriverWait(selfdriver 20)until(ECpresence_of_element_located(
(ByXPATH [id=app-sections]networktabsetulli[1]a)))
except TimeoutException
raise Exception(Cant Login in Zone Manager)
classmethod
def tearDown(cls)
clsdriverquit()
staticmethod
def Get_Pixels_ZM(return_dict driver)
return_dict[0] = 0
return_dict[1] = 0
regex = r(lt=c[-gt]cs)[wW]+(=)
while True
for entry in driverget_log(browser)
message = entry[message]
matches = refinditer(regex message reMULTILINE)
134
for matchNum match in enumerate(matches start=1)
try
p = matchgroup()replace( )
my_json = jsonloads(p)
if my_json[ZM] == Hotel MampM
return_dict[0] = my_json[top]
return_dict[1] = my_json[left]
break
except
pass
if return_dict[0] = 0 and return_dict[1] = 0
break
staticmethod
def Double_Click_On_ZM(return_dict canvasaction driver)
width = int(mathceil(float(return_dict[0])))
height = int(mathceil(float(return_dict[1])))
actionmove_to_element_with_offset(canvas width height)
actiondouble_click()
actionperform()
actiondouble_click()
actionperform()
driversave_screenshot(screenshot1png)
timesleep(5)
if __name__ == __main__
unittestmain(testRunner=HtmlTestRunnerHTMLTestRunner())
135
136
ANEXO B DOCKER DE ROBOT FRAMEWORK Y
ENTORNO DE UAT DOCKERIZADO
B1 Docker de Robot Framework
Para el entorno de UAT que se va a desarrollar se ha hecho uso de diferentes contenedores que han sido creados
por el equipo de desarrollo donde cada contenedor aloja un microservicio diferente de la plataforma
Para crear cada contenedor se ha hecho uso de Docker Esta herramienta permite crear contenedores ligeros y
portables para diferentes servicios que puedan ejecutarse en cualquier maacutequina con Docker instalado
independientemente del sistema operativo de la maacutequina que lo ejecute facilitando asi los despliegues
Mediante un fichero llamado ldquoDockerfilerdquo se definen los siguientes contenedores de servicios entre los cuales
se destacaraacute el fichero que define la creacioacuten del docker de Robot Framework el cual ha sido desarrollado por
el autor de este proyecto
Este contenedor ha sido creado sobre una imagen de Docker con el inteacuterprete de Python instalado Partiendo de
137
esta imagen se realiza la instalacioacuten de Robot Framework y las diferentes libreriacuteas y herramientas que se usaraacuten
en el proyecto para poder lanzar los Tests End-to-End
Ademaacutes se realiza la instalacioacuten de Google Chrome y Mozilla Firefox y la descarga de Chromedriver y
Geckodriver para poder lanzar los tests con dichos navegadores en modo headless Para el lanzamiento de los
test en modo headless se haraacute uso de la variable de entorno ldquoENVIROMENTrdquo definida en el anexo anterior
Finalmente se antildeade el proyecto de pruebas desarrollado para tener disponible las pruebas aumaacuteticas en el
contenedor
B2 Entorno de UAT Dockerizado
Para automatizar el despliegue de la plataforma Galgus CHT Cloud Manager con Docker se ha hecho uso de la
herramienta ldquodocker-composerdquo Esta herramienta permite simplificar el uso de Docker generando scripts que
facilitan el disentildeo y la construccion de servicios Con Docker Compose se pueden crear diferentes contenedores
y al mismo tiempo en cada contenedor diferentes servicios En la siguientefigura se muestra el fichero que
define el entorno de UAT con docker-compose
138
139
140
ANEXO C REVISIOacuteN DE REPORTES Y LOGS
C1 Reporte de Logs ofrecido por Robot Framework
Selenium no teniacutea la capacidad nativa de generar informes Este es uno de los motivos por el que se decidioacute
utilizar Robot Framework
Robot Framework genera tres archivos tras la ejecucioacuten de los scripts de pruebas A partir de la informacioacuten
contenida en el fichero ldquooutputxmlrdquo se rellenan las plantillas ldquohtmlrdquo del ldquologrdquo y del reporte El reporte permite
aplicar filtros a los resultados mientras que el ldquologrdquo contiene todos los detalles de la ejecucioacuten
A continuacioacuten se adjuntan las capturas de logs generados por los diferentes paquetes de pruebas desarrollados
C2 Cloud Tab
C21 Administration
141
142
C22 List
143
C23 Manufacturers
144
C24 MAP
145
C3 Configuration Tab
C31 BackupRestore
146
C32 CHT Zones
147
C33 Firmware
148
C34 Groups
149
150
C4 Network Tab
C41 General
151
C42 SSID
C43 CHT
152
C44 VLAN
153
C45 Radius
154
C46 Captive Portal
155
C47 AP Network
156
Como se ha visto reflejado en el conjunto de logs el tiempo total invertido en la ejecucioacuten ha sido de 1 hora 20
minutos y 22 segundos Dichas pruebas realizadas por una persona de forma manual hubiesen requerido como
miacutenimo el doble de tiempo Ya ni mencionar si se aplicase concurrencia en la ejecucioacuten de pruebas
157
ANEXO D DIAGRAMA DE GANTT
4
5
Trabajo de Fin de Maacutester Testeo automatizado de una plataforma Web de gestioacuten
Galgus CHT Manager
Autor Francisco Joseacute Diacuteaz Romero
Tutor Pablo Aguilera Bonet
Daniel Gutieacuterrez Reina
El tribunal nombrado para juzgar el Proyecto arriba indicado compuesto por los siguientes miembros
Presidente
Vocales
Secretario
Acuerdan otorgarle la calificacioacuten de
Sevilla 2020
El Secretario del Tribunal
6
7
A mi familia
A mis maestros
A mis amigos
8
9
Agradecimientos
10
11
Resumen
La revolucioacuten tecnoloacutegica que vivimos hoy diacutea enfocada principalmente en el mundo de Internet y aplicaciones
Web estaacute permitiendo que todas las herramientas que tenemos a nuestro alrededor se encuentren en un proceso
de tremenda evolucioacuten y cambio continuo
En este proyecto se ha realizado un estudio del arte sobre una teacutecnica que permite mejorar el proceso de
automatizacioacuten de pruebas sobre una aplicacioacuten Web basaacutendose en el modelado de la aplicacioacuten para
proporcionar una abstraccioacuten en la implementacioacuten de las pruebas Tambiacuteeacuten se ha realizado una revisioacuten de los
diferentes modelos de calidad normativas y tipos de prueba de Software Finalmente se ha desarrollado una
herramienta de test comprendida por un conjunto de pruebas de aceptacioacuten automaacuteticas que permiten la
verificacioacuten y validacioacuten de la funcionalidad de la plataforma Web Galgus CHT Cloud Manager
Galgus CHT Cloud Manager es la plataforma Web distribuida ofrecida por Galgus para la gestioacuten de redes
compuestas por puntos de acceso Wifi Estas redes se encuentran instaladas en los diferentes clientes que hacen
uso de los servicios que ofrece Galgus los cuales se basan en la optimizacioacuten del rendimiento y las prestaciones
de las redes Wifi en entornos de alta densidad de usuarios Esto se consigue mediante un software embebido
patentado por Galgus conocido bajo el nombre de Cognitive Hostpot Technology (CHT) el cual es instalado
en los puntos de acceso Dicho software implementa un conjunto de algoritmos y caracteriacutescas colaborativas
para conseguir los objetivos planteados en redes Wifi
Como resultado del trabjo podemos proporcionar a los ingenieros de pruebas una herramienta con la que poder
automatizar el testeo de una plataforma Web De esta forma se consigue agilizar el proceso de pruebas y reducir
costes y esfuerzos en tareas repetitivas que anteriormente se haciacutean de forma manual
12
13
Abstract
The technological revolution we are living today focused mainly on the Internet world and therewith the Web
applications is allowing all the tools we have around us to be in a process of continuous evolution and change
In this project we have made a study of the art on a technique that allows to improve the process of automation
of testing on a Web application based on the modelling of the application to provide an abstraction in the
implementation of testing A review of the different quality models standards and types of software testing has
also been carried out Finally a tool comprised of a set of automated acceptance tests has been developed to
allow verification and validation of the functionality of the Galgus CHT Cloud Manager Web platform
Galgus CHT Cloud Manager is the distributed web platform offered by Galgus for the management of
networks composed by Wifi access points These networks are installed in the different clients that make
use of the services offered by Galgus which are based on the optimization of the performance and features
of Wifi networks in high user density environments This is achieved through an embedded software
patented by Galgus known as Cognitive Hostpot Technology (CHT) which is installed in the access points
This software implements a set of algorithms and collaborative features to achieve the objectives set in Wifi
networks
This allows us to provide quality assurance engineers with a tool to automate the testing of a Web platform In
this way the testing process is streamlined and costs and efforts are reduced in repetitive tasks that previously
used to be done manually
14
15
Iacutendice
Agradecimientos 9
Resumen 11
Abstract 13
Iacutendice 15
Iacutendice de Figuras 19
Glosario 24
1 Introduccioacuten 27 11 Motivacioacuten 28 12 Alcance y Objetivos 29 13 Estructura de la memoria 30
2 Estudio del Arte y Revisioacuten 32 21 Model Based Testing (MBT) 32
211 Introduccioacuten 32 212 iquestQueacute es Model Based Testing 33 213 iquestCoacutemo funciona Model Based Testing 33 214 Consideraciones para la aplicacioacuten de Model Based Testing (MBT) 36 215 Beneficios de Model Based Testing (MBT) 37 216 Problemas y Limitaciones de Model Based Testing (MBT) 38 217 Cuando elegir Model Based Testing (MBT) 38
22 Gestioacuten de Calidad Software 39 221 Introduccioacuten 39 222 Concepto de Calidad 39 223 Modelos de Calidad de Software 40 224 Principales Ventajas e Inconvenientes de Modelos de Calidad anteriores 44 225 Conclusiones 44
3 Marco Teoacuterico Pruebas de Software 46 31 Testing y Pruebas de Software 46 32 Principios de las Pruebas de Software 47 33 Proceso de Pruebas de Software Anaacutelisis disentildeo e implementacioacuten 48
331 Terminologiacutea 48 332 Proceso de Pruebas de Software 49
34 Clasificacioacuten de Pruebas de Software 51 341 Pruebas Funcionales 51 342 Pruebas No Funcionales 52 343 Pruebas Estructurales 54 344 Pruebas debidas a Cambios 54
35 Niveles de Prueba 54 351 Pruebas a Nivel de Componente 55 352 Pruebas a Nivel de Integracioacuten 55 353 Pruebas a Nivel de Aceptacioacuten 55
16
36 Dificultades de pruebas en aplicaciones Web e impacto 56
4 Sistema Galgus CHT Cloud Manager 58 41 Arquitectura y Descripcioacuten del Sistema 58
411 Puntos de Acceso (OpenWRT + CHT) 60 412 Broacuteker de Eventos AMQP (RabbitMQ) 61 413 Frontend 62 414 Zone Manager 62 415 MoMap 63 416 Servidor de Licencias 64
42 Alcance y Objetivos de las pruebas sobre el sistema planteado 65 43 Arquitectura de la Solucioacuten Entorno de UAT para el proceso de pruebas (User Acceptance Test) 67
5 Tecnologiacuteas y Herramientas Usadas 69 51 Selenium 69 52 Selenium WebDriver 70
521 Elementos del Navegador 70 53 Robot Framework (RF) 72
531 Estilo de representacioacuten Given-When-Then 72 532 Reportes 75 533 Libreriacuteas 76 534 Documentacioacuten 77
54 Pycharm (IDE) 78 55 GitGitlab 78
551 Git 78 552 Gitlab 78
56 Redmine 78 561 Uso en el Proyecto Galgus CHT Cloud Manager (Metodologiacutea Scrum) 79
6 Experimentos 82 61 Estructura del Proyecto 83 62 Vista de Gestioacuten Principal (Cloud Tab) 87
621 Administration 87 622 List 89 623 Manufacturer 90 624 MAP 92
63 Vista de Configuracioacuten (Configuration Tab) 95 631 Groups 95 632 CHT Zones 98 633 BackupRestore 100 634 Firmware 101
64 Vista de Red (Network Tab) 104 641 VLANS amp Bridges 104 642 SSIDs 106 643 CHT 108 644 Radius 110 645 Captive Portal 112 646 General 115 647 AP Network 117
7 Lineas de Mejora y Conclusiones 122 71 Liacuteneas de Mejora Futuras 122 72 Conclusiones Finales 123
Referencias 126
17
Anexo A Preparacioacuten del Entorno de Trabajo y Ejecucioacuten de Pruebas 128 A1 Preparacioacuten del entorno de trabajo 128
A11 Pip 128 A12 Virtualenv Entorno Virtual 128 A13 Selenium y Chromedriver 129 A14 Robot Framework y SeleniumLibrary 129 A15 Otras dependencias 130
A2 Ejecucioacuten de Pruebas 130 A3 Script de Prueba U007 (MAP) 132
Anexo B Docker de Robot Framework y Entorno de UAT Dockerizado 136 B1 Docker de Robot Framework 136 B2 Entorno de UAT Dockerizado 137
Anexo C Revisioacuten de Reportes y Logs 140 C1 Reporte de Logs ofrecido por Robot Framework 140 C2 Cloud Tab 140
C21 Administration 140 C22 List 142 C23 Manufacturers 143 C24 MAP 144
C3 Configuration Tab 145 C31 BackupRestore 145 C32 CHT Zones 146 C33 Firmware 147 C34 Groups 148
C4 Network Tab 150 C41 General 150 C42 SSID 151 C43 CHT 151 C44 VLAN 152 C45 Radius 153 C46 Captive Portal 154 C47 AP Network 155
Anexo D Diagrama de Gantt 157
18
19
IacuteNDICE DE FIGURAS
Figura 1 Fuente de datos Morgan Stanley 27
Figura 2 Manual Testing vs Automated Testing [20] 28
Figura 3 Fase de Pruebas y Validacioacuten 32
Figura 4 Esquema baacutesico de Model Based Testing 33
Figura 5 Proceso detallado de Model Based Testing (MBT) 34
Figura 6 Construccioacuten del Modelo 34
Figura 7 Concepto de Calidad 39
Figura 8 Liacutenea de tiempo de modelos a nivel de proceso 40
Figura 9 Logo de ITIL 40
Figura 10 ISOIEC 20000 41
Figura 11 Logo de WebQEM 41
Figura 12 Liacutenea de tiempo de modelos a nivel de producto 42
Figura 13 Esquema de ISO 9126 42
Figura 14 Esquema de ISOIEC 25000 43
Figura 15 Principios de las Pruebas de Software 47
Figura 16 Terminologiacutea para el proceso de pruebas 48
Figura 17 Proceso de Pruebas de Software 49
Figura 18 Clasificacioacuten de Pruebas de Software 51
Figura 19 Pruebas de Caja Negra 51
Figura 20 Pruebas de Rendimiento 52
Figura 21 Pruebas de Carga 52
Figura 22 Pruebas de Estreacutes 52
Figura 23 Pruebas de Usabilidad 53
Figura 24 Pruebas de Portabilidad 53
Figura 25 Pruebas de Caja Blanca 54
Figura 26 Modelo de desarrollo en V 55
Figura 27 Dificultades de pruebas en aplicaciones Web e impacto 56
Figura 28 Logo de Galgus 58
Figura 29 Arquitectura de CHT Cloud Manager 59
Figura 30 CHT_CLI 60
Figura 31 Plataforma de Gestioacuten de RabbitMQ 61
Figura 32 Patroacuten PublicadorSuscriptor 61
Figura 33 Ejemplo de Interfaz Graacutefica de un Zone Manager 62
Figura 34 Ejemplo de Interfaz Graacutefica de MoMap 63
20
Figura 35 Interfaz Graacutefica del Servidor de Licencias 64
Figura 36 Zero-Touch Provisioning (ZTP) 64
Figura 37 Test Plan de CHT Cloud Manager 65
Figura 38 Leyenda del Test Plan 66
Figura 39 Control de Versiones del Test Plan 66
Figura 40 Entorno de UAT con Docker (Anexo B) 67
Figura 41 Implementaciones disponibles de Selenium y Navegadores Web Compatibles 70
Figura 42 Coacutedigo de ejemplo con Python y Selenium 71
Figura 43 Estilo de representacioacuten Given-When-Then 72
Figura 44 Implementacioacuten de Pruebas en para el inicio de sesioacuten de CHT Cloud Manager 74
Figura 45 Ejemplo de reporte de pruebas automatizadas con Robot Framework 75
Figura 46 Ejemplo de documentacioacuten generada con Libdoc 77
Figura 47 Ejemplo de documentacioacuten generada con Testdoc 77
Figura 48 Ejemplo de Flujo de Trabajo en Redmine para Galgus CHT Cloud Manager 79
Figura 49 Esquema Graacutefico de Metodologiacutea Scrum 79
Figura 50 Logo de Galgus CHT Cloud Manager 82
Figura 51 Estructura del Proyecto 83
Figura 52 Fragmento del fichero ldquoSelectorpyrdquo 83
Figura 53 Fragmento del fichero ldquoCommon_Keywordsrobotrdquo 84
Figura 54 Fragmento del fichero de Configuracioacuten de pruebas ldquoConfigurationrobotrdquo 84
Figura 55 Diagrama de paquetes del proyecto de pruebas 85
Figura 56 Estructura de una Suite de Pruebas 85
Figura 57 Ejemplo de ldquoTest Setuprdquo personalizado para un caso de prueba 86
Figura 58 Vista de Gestioacuten Principal (Cloud Tab) 87
Figura 59 Pestantildea ldquoAdministrationrdquo 87
Figura 60 Diagramas de Flujo de Casos de Prueba U0025 y U0027 88
Figura 61 Script de Pruebas U0025 88
Figura 62 Keyword ldquoEdit Fieldsrdquo 88
Figura 63 Pestantildea ldquoList of Zone Managersrdquo 89
Figura 64 Diagrama de flujo de Caso de Prueba U0023 89
Figura 65 Script de Prueba U0023 90
Figura 66 Keyword ldquoZone Manager is registered successfullyrdquo 90
Figura 67 Seccioacuten de Fabricantes 90
Figura 68 Diagrama de flujo de Caso de Prueba U0009 91
Figura 69 Script de Prueba U0009 91
Figura 70 Toast Success 92
Figura 71 Keyword ldquoCorrectly Createrdquo 92
Figura 72 Setup amp Teardown de U0008 92
21
Figura 73 Mapa de Zone Managers 92
Figura 74 Funcioacuten que dibuja los ZM en el Mapa y obtiene los piacutexeles en pantalla 93
Figura 75 Diagrama de Flujo de Caso de Prueba U0007 94
Figura 76 Pestantildea ldquoGroupsrdquo 95
Figura 77 Diagrama de flujo de Caso de Prueba U0119 96
Figura 78 Script de Prueba U0119 97
Figura 79 Keyword ldquoVerify if AP is registered Succesfully on grouprdquo 97
Figura 80 Keywords Input Into Text Field y Clear Field Of Characters 97
Figura 81 Pestantildea ldquoCHT Zonesrdquo 98
Figura 82 Diagrama de Flujo de Caso de Prueba U0204 99
Figura 83 Scripts de Prueba U0204 99
Figura 84 Keyword Add Zone CHT to AP 99
Figura 85 Pestantildea BackupRestore 100
Figura 86 Diagrama de Flujo de Caso de Prueba U0401 101
Figura 87 Script de Prueba U0401 101
Figura 88 Keyword Restore For AP hace done successfully 101
Figura 89 Pestantildea ldquoFirmwarerdquo 102
Figura 90 Diagrama de Flujo de Caso de Prueba U0303 103
Figura 91 Script de Prueba U0303 103
Figura 92 Keyword Flash AP 103
Figura 93 Pestantildea ldquoVLAN amp Bridgesrdquo 104
Figura 94 Diagrama de Flujo de Caso de Prueba U0527 105
Figura 95 Script de Prueba U0527 105
Figura 96 Keyword Go And Create VLAN 105
Figura 97 Pestantildea SSIDs 106
Figura 98 Diagrama de Flujo de Caso de Prueba U0530 106
Figura 99 Script de Prueba U0530 107
Figura 100 Keyword Go And Create SSID 107
Figura 101 Pestantildea ldquoCHTrdquo 108
Figura 102 Diagrama de Flujo de Caso de Prueba U0539 109
Figura 103 Script de Prueba U0539 109
Figura 104 Keyword ACA Is Working 109
Figura 105 Keyword Changes On CLI 110
Figura 106 Comando CHT para obtener el estado del moacutedulo ACA en el punto de acceso 110
Figura 107 Pestantildea ldquoRadiusrdquo 110
Figura 108 Escenario de Funcionamiento de Servidor Radius 110
Figura 109 Diagrama de Flujo de Caso de Prueba U0601 111
Figura 110 Script de Prueba U0601 111
Figura 111 Keyword Create Radius Profile 112
22
Figura 112 Pestantildea Captive Portals 112
Figura 113 Escenario de Funcionamiento de un Portal Cautivo 112
Figura 114 Diagrama de Flujo de Caso de Prueba U0701 113
Figura 115 Script de Prueba U0701 113
Figura 116 Keyword Edit or Delete Captive Portal Profile 114
Figura 117 Pestantildea General 115
Figura 118 Diagrama de Flujo de Caso de Prueba U0522 116
Figura 119 Script de Prueba U0522 116
Figura 120 Keyword Check Number of Clients Increases 116
Figura 121 Pestantildea AP Network 117
Figura 122 Libreriacutea SSH para Robot Framework 117
Figura 123 Ventana de Configuracioacuten de TC Rules 118
Figura 124 Diagrama de Flujo de Caso de Prueba U0511 119
Figura 125 Script de Prueba U0511 120
Figura 126 Keyword Wait Timer 120
Figura 127 Keyword Check On CLI 120
23
24
GLOSARIO
CHT Cognitive Hostpot Technology
BDD Behaviour-Driven Development
MBT Model Based Testing
API Application Programing Interface
UAT User Acceptance Testing
SUT System Under Test
UML Unified Modeling Language
FSM Finite State Machine
RAE Real Academia Espantildeola
IEEE Institute of Electronical and Electronics Engineers
ITIL Information Technology Infrastructure Library
ISO International Organization for Standardization
WebQEM Web-site Quality Evaluation method
ISTQB International Software Testing Qualifications Board
TDD Test-Driven Development
SOA Service Oriented Architecture
WiFi Wireless Fidelity
MGR Manager Module
SB Smart Band Steering Module
TCM Traffic Congestion Management Module
LOC Localization Module
POWER Power Control Module
SR Smart Roaming Module
LB Load Balancing Module
AMQP Advance Message Queuing Protocol
HTML HyperText Markup Language
CSS Cascading Style Sheets
HTTPS HyperText Transfer Protocol Secure
TLS Transport Layer Security
REST REpresentational State Transfer
JSON JavaScript Object Notation
DOM Document Object Model
SQL Structure Query Language
ZMB Zone Manager Backend
ZTP Zero-Touch Provisioning
25
RF Robot Framework
CICD Continuous IntegrationContinuous Delivery
SSH Secure SHell
SCP Secure Copy ProtocolSimple Communication Protocol
26
27
1 INTRODUCCIOacuteN
ctualmente el desarrollo software se encuentra en un proceso revolucionario cuyo principal objetivo y
tendencia es la implantacioacuten y desarrollo de software distribuido donde se marcan como principales
objetivos la disponibilidad usabilidad y funcionalidad de cualquier aplicacioacuten a traveacutes de internet Es
aquiacute donde entran en juego entre otros el desarrollo de aplicaciones o servicios Web sustituyendo en gran
medida al desarrollo de aplicaciones y servicios de escritorio
Figura 1 Fuente de datos Morgan Stanley
Muchos son los aspectos a tener en cuenta entre los que cabe destacar la eficiencia la velocidad de respuesta y
de navegacioacuten los cuales para algunos servicios Web son excelentes pero para otros auacuten se encuentran en un
proceso de mejora Esto es debido a que gran cantidad de aplicaciones requieren de un buen disentildeo donde se
optimicen el uso de los recursos disponibles como el ancho de banda memoria carga del servidor respaldo
seguridad etc
A
Hemos establecido la civilizacioacuten de manera que los
maacutes cruciales elementos dependen de la ciencia y la
tecnologiacutea
Carl Sagan
28
11 Motivacioacuten
La gran demanda de servicios y aplicaciones Web distribuidas que permitan gestionar agilizar y simplificar
cualquier aacutembito de negocio hace que cada vez maacutes que dichas aplicaciones contemplen un mayor
conjunto de requisitos solicitados por los clientes lo cual se traduce en un mayor nuacutemero de funcionalidades
y casos de uso contemplados en dichas aplicaciones
Ademaacutes dichas aplicaciones se necesitan cada vez en un menor tiempo lo cual conlleva a reducir los
periodos en las diversas fases por las que pasa un proyecto software desde la fase de disentildeo hasta la de
pruebas Es en esta uacuteltima donde antes de ser entregada al cliente como un producto se detectan los
posibles errores e incluso se puede evaluar si la funcionalidad ofrecida por la aplicacioacuten esta alineada con
los requisitos demandados por el cliente
Los fallos o errores en las aplicaciones Web mal probadas bien por falta de asignacioacuten de tiempo o recursos
a la fase de pruebas tienen una mayor repercusioacuten teniendo el potencial de generar una gran cantidad de
quejas e insatisfaccioacuten por parte de los clientes casi inmediatamente En el caso de las aplicaciones Web
no soacutelo se trata de peacuterdidas econoacutemicas sino tambieacuten de peacuterdida de prestigio fiabilidad y credibilidad por
parte de nuestros usuarios o clientes Los consumidores de hoy demandan una tecnologiacutea intuitiva y de
confianza en un mercado en continuo crecimiento donde un pequentildeo error puede acarrear falta de
satisfaccioacuten en un usuario peacuterdidas millonarias a una empresa o incluso dantildeos humanos Y es en este tipo
de ciclos iterativos y raacutepidamente cambiantes donde la automatizacioacuten de pruebas juega un papel decisivo
iquestY cuaacutel es la causa de estos problemas Para ello debemos tener en cuenta que estos sistemas son disentildeados
por el ser humano el cual comete fallos ya sea por presioacuten en los plazos de trabajo por la complejidad del
coacutedigo o de la infraestructura por cambios de tecnologiacuteas o por cualquier otra interaccioacuten con el sistema
Como ha quedado reflejado un proceso riguroso de control de sistemas y documentacioacuten permiten
bull Ayudar a reducir el riesgo de los posibles fallos y Mejora la calidad de los sistemas a la hora de ser
usados
bull Un correcto mantenimiento del producto a lo largo del ciclo de desarrollo
bull Un cumplimiento de requisitos legales (normas nacionales e internacionales ordenanzas
municipales etc)
bull Una adecuacioacuten de un sistema a los requisitos contractuales
bull Una adaptacioacuten de estaacutendars especiacuteficos de la industria
La forma en la que se logre y las herramientas empleadas variaraacuten en funcioacuten de factores como la
envergadura y tipo de proyecto den cuanto a los riesgos tecnoloacutegicos de seguridad o de negocio asiacute como
del presupuesto y tiempo disponible
Figura 2 Manual Testing vs Automated Testing [20]
29
12 Alcance y Objetivos
Las pruebas de software o software testing pueden llevarse a la praacutectica de muacuteltiples maneras pero el
presente proyecto se centra en el componente funcional del producto enfocado en lo que hace el sistema y
no coacutemo primando la aceptacioacuten por parte de los usuarios en base a los requisitos de disentildeo originales Es
decir el punto de mira estaacute en cumplir los requisitos establecidos por el cliente dejando fuera del alcance
del proyecto la estructura del coacutedigo fuente implementado
Bajo este contexto se plantea la automatizacioacuten de la fase de pruebas de una aplicacioacuten Web distribuida
centrando el enfoque de este proyecto en la automatizacioacuten de pruebas funcionales maacutes concretamente
pruebas de humo or smoke tests y aceptacioacuten Hasta ahora dichas pruebas se realizaban manualmente por
un ingeniero de pruebas lo cual permitiacutea evaluar la calidad del producto que seriacutea entregado al cliente
Ademaacutes se realizaraacute un marco teoacuterico donde se resumiraacuten una clasificacioacuten de los diferentes tipos de
pruebas software que pueden realizarse sobre una aplicacioacuten
Concretamente la solucioacuten abordada en esta memoria se cintildee al mantenimiento de un producto Web como
es la plataforma Galgus CHT Cloud Manager Para ello se cubriraacuten un gran conjunto de funcionalidades
ofrecidas por dicha aplicacioacuten Web como por ejemplo inicio y cierre de sesioacuten flujos de navegacioacuten
comprobacioacuten de los elementos mostrados y uso de la caja de buacutesquedas Sin llegar a ser exhaustivos este
tipo de pruebas conocidas como smoke tests son faacutecilmente automatizables y permiten detectar las primeras
sentildeales de que un sistema no funciona de manera correcta Por tanto es necesario traducir los requisitos
funcionales a instrucciones de alto nivel faacutecilmente entendibles por personas con poca formacioacuten teacutecnica
dado que seraacute el el resultado mostrado de las pruebas realizadas (informes de pruebas) Estas instrucciones
usaraacuten Behaviour-Driven Development (BDD) para describir interacciones entre el usuario y el sistema
definiendo actor accioacuten y comportamiento esperado del sistema Robot Framework es la herramienta que
se usa para este punto
Una vez tenemos dichas instrucciones se deben traducir de nuevo a un lenguaje de menor nivel como es
Python para implementar los test scripts Estos scripts seraacuten los que Selenium Webdriver procese y traduzca
para comunicarse con el controlador del navegador Web Chrome en nuestro caso a traveacutes de una API
Posteriormente el navegador se encargaraacute de ejecutar los comandos de accioacuten y de devolver la informacioacuten
de estado de vuelta Finalmente Robot Framework elaboraraacute un informe en formato html detallando las
pruebas realizadas resultados de las interacciones tiempos de ejecucioacuten y espera errores producidos etc
Tambieacuten se realizaraacute un estudio del arte sobre una teacutecnica conocida como Model Based Testing (MBT)
Dicha teacutecnica permite la generacioacuten automaacutetica de las pruebas a realizar sobre un sistema partiendo del
modelado del comportamiento de dicho sistema Ademaacutes esta teacutecnica tambieacuten abarca la traduccioacuten de las
pruebas generadas en scripts ejecutables para aplicar dichas pruebas sobre el sistema dando tambiacuteeacuten la
posibilidad de evaluar los resultados Esto proporciona muchas ventajas sobre la fase de pruebas pero a la
vez tambieacuten requiere un mayor esfuerzo en la fase de disentildeo y una presencia continua de la fase de pruebas
en otras etapas del ciclo de vida del proyecto Tambieacuten se presentaraacute un conjunto de normativas que regula
y normaliza la gestioacuten de calidad software
Posteriormente se describiraacute el sistema sobre el cual se basa la aplicacioacuten bajo pruebas llamada CHT
Cloud Manager Se presentaraacute la arquitectura de la aplicacioacuten y posteriormente se destacaraacuten los objetivos
de automatizacioacuten de testeo sobre la misma proponiendo el entorno de UAT planteado para someter la
aplicacioacuten a las pruebas automaacuteticas desarrolladas Se dedicaraacute una seccioacuten a analizar las tecnologiacuteas y
herramientas usadas donde se centraraacute la atencioacuten en Robot Framework Selenium y Python como las
tecnologiacuteas usadas para automatizar el testeo Ademaacutes se destacaraacute la integracioacuten del entorno de UAT
como fase de la integracioacuten continua de la aplicacioacuten ademaacutes de la metodologiacutea de trabajo llevada a cabo
Finalmente se presentaraacuten algunos experimentos y demostraciones de uso de la herramienta desarrollada
se describiraacuten algunas liacuteneas de mejora y conclusiones y se incluiraacuten algunos posibles anexos para la puesta
en marcha de la aplicacioacuten y reportes de algunas pruebas entre otros
30
13 Estructura de la memoria
El siguiente esquema resume de forma geneacuterica los puntos tratados en esta memoria para que el lector pueda
tener una idea orientativa de la organizacioacuten de este documento
1 Introduccioacuten En este punto se abordan temas geneacutericos como los objetivos motivacioacuten y alcance de
forma que pueda adquirirse una breve aproximacioacuten a los detalles del proyecto
2 Estudio del Arte y Revisioacuten A lo largo de esta seccioacuten se presentaraacute un estudio sobre la teacutecnica
conocida como Model Based Testing la cual permitiriacutea mejorar el proceso de automatizacioacuten de
pruebas Ademaacutes se realiza una revisioacuten sobre la gestioacuten de Calidad Software presentado algunos
modelos existentes en la actualidad
3 Marco Teoacuterico Consta de un estudio sobre el proceso de pruebas en un proyecto Software y los
principales tipos de pruebas Software existentes
4 Sistema En este punto se presenta la arquitectura del sistema sobre el que se van a automatizar las
pruebas de aceptacioacuten o Smoke Tests Ademaacutes se describe el alcance y objetivos de dichas pruebas y
se presenta la arquitectura de la solucioacuten planteada como escenario de pruebas haciendo uso de Docker
como tecnologiacutea de automatizacioacuten en el despliegue de aplicaciones software alojadas en contenedores
de software
5 Tecnologiacuteas y Herramientas usadas Consta del conjunto de tecnologiacuteas usadas para la
implementacioacuten de las pruebas de aceptacioacuten automatizadas y las herramientas para utilizar dichas
pruebas y para gestionar el trabajo del equipo de desarrollo y calidad responsable de este proyecto
6 Experimentos Consta de un detalle sobre la funcionalidad de un conjunto de pruebas que han sido
implementadas para verificar y validar el funcionamiento esperado del sistema Para cada prueba se
definen criterios de aceptacioacuten diagramas de flujo y scripts de implementacioacuten detallando algunas de
las implementaciones clave
7 Liacuteneas de Mejora y Conclusiones Se incluye una seccioacuten conclusiones finales tras la realizacioacuten del
proyecto y una valoracioacuten del mismo a nivel general y personal Ademaacutes se destacaraacuten algunas liacuteneas
de mejora futuras relacionadas principalmente con la aplicacioacuten de Model Based Testing (MBT) y otros
aspectos sobre la implementacioacuten actual de la herramienta de automatizacioacuten
Ademaacutes se realizaraacute una seccioacuten de anexos en el que se trataraacuten puntos adicionales sobre el proyecto
bull Anexo A Preparacioacuten del Entorno de Trabajo y Ejecucioacuten de Pruebas
bull Anexo B Docker de Robot Framework y Entorno de UAT Dockerizado
bull Anexo C Revisioacuten de Reportes y Logs
31
32
2 ESTUDIO DEL ARTE Y REVISIOacuteN
n este punto se realizaraacute un estudio sobre el marco teoacuterico de una de las teacutecnicas existentes que permite
la generacioacuten y ejecucioacuten automaacutetica de casos de test a partir del modelado de un sistema para la fase
de pruebas de una aplicacioacuten Esta teacutecnica es conocida como Model Based Testing (MBT) Ademaacutes
se realizaraacute una revisioacuten de la normativa relacionada con la gestioacuten de calidad software analizando la familia de
normas ISOIEC 25000
21 Model Based Testing (MBT)
211 Introduccioacuten
Dada la rapidez con la que se demandan los servicios contratados por los clientes en muchas ocasiones la
mayoriacutea del tiempo y esfuerzo asignado para la realizacioacuten de proyectos de software van destinados a la
labor de desarrollo dedicando menos esfuerzos en otras fases del ciclo de vida de un proyecto como las
fases de disentildeo o de pruebas Esto puede conllevar a que el proyecto no se desarrolle de acuerdo con los
requisitos demandados por los clientes y que el nuacutemero de puntos de fallo del producto software aumente
La fase de testeo o prueba de un producto software durante su ciclo de vida es una etapa fundamental para
validar la calidad del producto desarrollado y ofrecido a un cliente para conseguir un grado de satisfaccioacuten
aceptable de forma que se cumpla con los requisitos demandados y con el menor grado de error posible
Figura 3 Fase de Pruebas y Validacioacuten
Uno de los factores por los que en ocasiones no se emplean suficientes recursos a la fase de pruebas es la
gran cantidad de casos de pruebas que se deben realizar para validar un sistema Por cada caso de prueba
se deben asignar recursos relacionados con la planificacioacuten disentildeo y ejecucioacuten del mismo
Por tanto en este punto cabe plantearse la idea de automatizar no solo los casos de pruebas que validan un
sistema sino la generacioacuten de los casos de prueba Esto puede permitir reducir de forma considerable el
coste y esfuerzos en la fase de pruebas En este contexto surge el concepto de Model Based Testing (MBT)
E
La tecnologiacutea no es en siacute el fin sino el medio entre la
sociedad del conocimiento y el desarrollo mundial
Anoacutenimo
33
212 iquestQueacute es Model Based Testing
Este se trata de un meacutetodo capaz de controlar la calidad del software durante su ciclo de vida permitiendo
la generacioacuten automaacutetica de los casos de prueba e incluso la ejecucioacuten y evaluacioacuten automaacutetica de
resultados Para ello se requiere de un modelado y disentildeo correcto del sistema bajo pruebas como base
para la aplicacioacuten de esta teacutecnica
Figura 4 Esquema baacutesico de Model Based Testing
MBT permite crear un modelo del comportamiento esperado por el sistema a traveacutes del cual permite la
aplicacioacuten de diferentes teacutecnicas para la generacioacuten de casos de prueba [1]
bull Generacioacuten de casos de pruebas con datos de entrada sobre un modelo de dominio del sistema bull Generacioacuten de casos de pruebas de un modelo de entorno bull Generacioacuten de casos de prueba con predicciones del comportamiento del modelo bull Generacioacuten de scripts de prueba a partir de pruebas abstractas
213 iquestCoacutemo funciona Model Based Testing
En primer lugar se requiere del disentildeo de un modelo del sistema bajo test el cual debe tener al menos dos
caracteriacutesticas principales debe ser pequentildeo en relacioacuten al tamantildeo del sistema de forma que no requiera
un coste elevado pero debe ser lo suficientemente detallado para describir completamente las
caracteriacutesticas que se quieran probar sobre el sistema
Una vez implementado el modelo del sistema a probar se procederiacutea a la utilizacioacuten de herramientas
basadas en la teacutecnica MBT para generar automaacuteticamente el banco de pruebas a partir del modelo del
sistema bajo test (SUT) Estos bancos de pruebas generados seraacuten un conjunto de pruebas abstractas cada
una de las cuales define la secuencia de operaciones a realizar para probar una funcionalidad determinada
con sus respectivos valores o datos de entrada necesarios y las salidas o respuestas del sistema que se
esperan
A partir del banco de pruebas abstractas se deben transformar en scripts de pruebas ejecutables lo cual
puede realizarse con herramientas basadas en la teacutecnica MBT Estos scripts podriacutean ser ejecutados para la
deteccioacuten de errores sobre el sistema bajo test y esta ejecucioacuten podriacutea ser controlada y monitorizada por
alguna herramienta de ejecucioacuten de pruebas
En el siguiente diagrama se muestra el proceso de aplicacioacuten de este meacutetodo donde se propone dividir el
proceso en cinco fases principales [1]
1 Modelado Modelar el sistema bajo test y su entorno 2 Generacioacuten Generar las pruebas abstractas a partir del modelo planteado en la fase anterior 3 Concretizado Concretizar o adaptar las pruebas abstractas para transformarlas en ejecutables 4 Ejecucioacuten Ejecutar las pruebas sobre el sistema bajo test y definir decisiones o veredictos para las
mismas de forma que se pueda determinar el correcto funcionamiento del sistema bajo test 5 Anaacutelisis Analizar los resultados obtenidos a partir de la ejecucioacuten de los casos de prueba
34
Destacar que para el generador de casos de prueba y el script de pruebas se suelen usar herramientas de pruebas
especiales Por este motivo se encuentran resaltados en negrita
Figura 5 Proceso detallado de Model Based Testing (MBT)
Una vez presentado el proceso o metodologiacutea para llevar a cabo dicha teacutecnica se describiraacuten las principales
fases
2131 Construccioacuten del Modelo
Dicha fase consiste en la construccioacuten de un modelo que represente el comportamiento detallado del sistema
bajo pruebas yo su entorno a partir de los requisitos de disentildeo del mismo y el plan de pruebas desarrollado para
cumplir con estos requisitos
Este es el paso maacutes importante en la aplicacioacuten de la teacutecnica Model Based Testing ya que el resto de fases
dependeraacute siempre del modelo del sistema bajo pruebas Cuanto maacutes completo sea el modelo maacutes efectivos
seraacuten los casos de prueba generados a partir de este
Figura 6 Construccioacuten del Modelo
35
Para llevar a cabo el modelo del comportamiento de la aplicacioacuten se requiere conocer exactamente el
comportamiento esperado de la misma lo cual lleva a estudiar y analizar en profundidad el sistema y su entorno
previamente
Existen diversas especificaciones formales para el modelado a partir de los requisitos como por ejemplo los
diagramas UML Estos ayudan a que el modelado sea una tarea algo maacutes sencilla de realizar que si se llevara a
cabo a partir de los requisitos escritos en lenguaje natural Por otro lado para modelar el comportamiento existen
diversas teacutecnicas como las maacutequinas de estados finitos (FSM) Cadenas de Maacuterkov Tablas de decisiones
Diagramas de estados etc
En conclusioacuten modelar un sistema no es una tarea sencilla ya que requiere de habilidades teacutecnicas experiencia
e imaginacioacuten para construir un modelo que se comporte de la forma deseada Dicho modelo debe cumplir con
las siguientes propiedades [2]
bull Debe ser lo maacutes abstracto posible sin perder la informacioacuten importante
bull No debe contener informacioacuten que sea redundante o que no esteacute relacionada con el alcance de las
pruebas
bull Debe ser entendible para los ingenieros de pruebas incluso a expensas de la brevedad y abstraccioacuten del
mismo
bull Debe ser flexible y abierto para permitir cambios y antildeadir o eliminar nuevas funcionalidades
bull Debe considerar todos los detalles de implementacioacuten de las pruebas
2132 Generacioacuten de Casos de Prueba
Los casos de prueba seraacuten generados tras la construccioacuten previa del modelo del sistema Antes de la creacioacuten de
los casos de prueba los ingenieros de pruebas deben especificar o proveer informacioacuten sobre el criterio o
propoacutesito de los casos de prueba las entradas y en algunos casos las salidas esperadas del sistema
Destacar que generar las salidas esperadas correspondientes a unas determinadas entradas es maacutes complejo que
generar soacutelo las entradas Para ello se necesita un oraacuteculo que cree salidas vaacutelidas y las mapee a los casos de
prueba Crear el oraacuteculo es la tarea maacutes compleja
Las dificultades presentadas en esta fase dependeraacuten de si el modelo es complejo o simple y la efectividad de
los casos de prueba generados dependeraacute de lo completo y preciso que sea dicho modelo para poder generar
automaacuteticamente los casos de prueba
Cuando el sistema es complejo la cantidad de casos de test es muy grande e incluso infinita Por tanto evaluar
todos los casos de test resulta inviable y costoso En este caso para mejorar la calidad del sistema se necesita
seleccionar los casos de test que realmente puedan ayudar a localizar tantos fallos como sea posible con un coste
aceptable
Existen diferentes criterios de cobertura que permiten ayudar a controlar el proceso de generacioacuten de casos de
prueba Sin embargo se recomienda seleccionar maacutes de uno de estos criterios para lograr un mayor resultado en
la cobertura de pruebas
2133 Ejecucioacuten de Casos de Prueba
La ejecucioacuten de los casos de pruebas requiere la transformacioacuten de los mismos en una forma ejecutable Debido
a que los los scripts de pruebas ejecutables pueden ser reutilizados durante todo el tiempo empleado en la
validacioacuten del sistema estos deben ser escritos de una forma maacutes eficiente que permita que sean reutilizables e
incluso que frente a una modificacioacuten sean maacutes faacuteciles generarlos y ejecutarlos Por ello se crean scripts
ejecutables para los casos de prueba abstractos
El proceso de transformacioacuten en pruebas ejecutables seriacutea maacutes eficiente si es hecha de forma automaacutetica
Despueacutes de aplicar los casos de prueba ejecutables al sistema bajo pruebas se obtienen las salidas actuales del
sistema las cuales deberaacuten ser contrastadas con las salidas esperadas
36
2134 Anaacutelisis de los Resultados
Una vez ejecutados los casos de pruebas y obtenidas las salidas actuales del sistema se deben evaluar y analizar
los resultados obtenidos Para ello se debe comparar las salidas actuales obtenidas con las salidas esperadas
especificadas en los casos de prueba Esta tarea de comparacioacuten podriacutea realizarse idealmente de forma
automaacutetica lo cual dariacutea como resultados posibles
1 Pasa Cuando las salidas actuales se encuentran acordes con las salidas esperadas
2 Falla Cuando las salidas actuales no se encuentran acordes con las salidas esperadas
3 Inconcluso Cuando no se puede tomar una decisioacuten en el momento
Hay que destacar que puede darse el caso en el que si las salidas esperadas no estaacuten bien determinadas los
resultados obtenidos al contrastar dichas salidas con las actuales sean falsos dando lugar a resultados sin utilidad
y que pueden dar lugar a confusioacuten
Por este motivo la generacioacuten automaacutetica de las salidas esperadas es una tarea compleja e importante en todo el
proceso especialmente en sistemas complejos Por tanto el nivel de dificultad para encontrar un oraacuteculo de
pruebas depende del tamantildeo y complejidad del sistema Sin embargo la necesidad e importancia del oraacuteculo de
pruebas tambieacuten aumenta cuando el sistema es maacutes complejo
Tras obtener los resultados se debe determinar si se decide generar maacutes casos de prueba si se debe modificar el
modelo o si la fase de pruebas debe ser detenida y debe ponerse en marcha el software del sistema que se estaacute
probando
214 Consideraciones para la aplicacioacuten de Model Based Testing (MBT)
Son muchos los artiacuteculos que describen aspectos importantes a tener en cuenta durante el desarrollo o la
aplicacioacuten de esta teacutecnica Algunas de estas consideraciones a destacar seriacutean las siguientes [3]
1 El modelo que describe el comportamiento del sistema es el punto clave
El comportamiento del modelo debe ser desarrollado cuidadosamente Sus limitaciones y restricciones deben
ser respetadas durante el modelado del sistema bajo pruebas De esta forma si el modelo estaacute mal las pruebas
generadas tambieacuten lo estaraacuten Por tanto la exactitud del modelo es fundamental para pasar a la fase de
generacioacuten de casos de prueba
2 Las pruebas deben cubrir los criterios de control de flujo y datos
Los criterios de cobertura de las pruebas definen un conjunto de casos de prueba seleccionados para la misma
Estos casos de pruebas pueden ser generados a partir de dos fuentes criterios de flujo de control o de flujo
de datos En el caso de pruebas aplicadas a grandes sistemas es importante combinar ambos criterios para
incrementar la cobertura de las pruebas
3 El nivel de automatizacioacuten debe ser elevado
El nivel de automatizacioacuten es un factor importante para definir la factibilidad de uso de MBT Normalmente
suele haber un uacutenico paso no automatizado el modelado del comportamiento del sistema el cual es utilizado
como entrada para el proceso de generacioacuten de los casos de prueba Si hubiese otros pasos no automatizados
se incrementariacutea el esfuerzo los costes y la complejidad de su uso
4 Son fundamentales las herramientas que soportan la automatizacioacuten de las fases de MBT
Las herramientas usadas deben soportar la ejecucioacuten de los pasos automatizados Si no hay una herramienta
que soporte un determinado paso esta tarea podriacutea ser difiacutecil e inviable Por tanto una herramienta debe
soportar la integracioacuten entre los diferentes pasos no automatizados y automatizados
5 Los liacutederes del proyecto deben entender las habilidades requeridas y la complejidad para usar
MBT
Las personas encargadas de la fase de pruebas necesitan conocer ademaacutes de las teacutecnicas de pruebas los
lenguajes de modelado y algunos lenguajes de programacioacuten
37
6 El orden de los pasos a seguir mientras se usa un enfoque MBT
Es necesario respetar los pasos seguidos para la generacioacuten de los casos de prueba de forma que sean
respetados en la fase de ejecucioacuten de las pruebas siendo ejecutados en la misma secuencia en que fueron
definidos En caso contrario se podriacutean generar salidas erroacuteneas de dichas pruebas
7 Transferencia de la Tecnologiacutea
Las tecnologiacuteas usadas para la aplicacioacuten de la teacutecnica MBT se transfieren desde entornos acadeacutemicos o de
investigacioacuten para ser implementados en proyectos industriales Por este motivo necesitan ser analizados
cuidadosamente antes de ser usadas
215 Beneficios de Model Based Testing (MBT)
A continuacioacuten se definen diversos beneficios que proporciona la aplicacioacuten de Model Based Testing para la
fase de pruebas [1] [4]
1 Deteccioacuten de Fallos del Sistema Bajo Pruebas
El modelado del comportamiento del sistema bajo pruebas permite detectar errores ambiguumledades o lagunas
que pueden presenciarse en la toma de requisitos especificacioacuten y disentildeo del software Por tanto permite
una deteccioacuten temprana de errores
2 Reduccioacuten de costes y tiempo en la fase de pruebas
La aplicacioacuten de esta teacutecnica contribuye a que el tiempo coste y recursos empleados a la fase de pruebas
disminuya Sin embargo se requiere una mayor asignacioacuten de recursos para el modelado y mantenimiento
del sistema
3 Mejora de la calidad de las pruebas
Cuando las pruebas se desarrollan manualmente la calidad de las mismas es muy dependiente de los
desarrolladores que la implementan Ademaacutes el proceso de disentildeo no puede ser reproducido el criterio
racional aplicado para cada prueba normalmente no es recordado y el resultado de los casos de prueba no es
faacutecilmente interpretado ni contrastado con los requisitos originales del sistema
Model Based Testing es una teacutecnica capaz de mejorar mucho estos inconvenientes que se presentan sobre el
desarrollo de pruebas manuales gracias al generador automatizado de casos de prueba
4 Trazabilidad
Puede definirse como la habilidad para relacionar cada caso de prueba al modelo criterio de seleccioacuten e
incluso a los requisitos informales del sistema Esto ayuda a explicar los casos de prueba asiacute como justificar
por queacute fueron creados Los algoritmos aplicados para la generacioacuten de pruebas deben saber queacute partes del
modelo seraacuten empleadas en cada caso de prueba y las salidas esperadas
5 Evolucioacuten de los requisitos
Si los requisitos del sistema cambian con la aplicacioacuten de Model Based Testing bastariacutea con actualizar el
modelo y las pruebas seraacuten generadas de nuevo de forma automaacutetica Debido a que el modelo es usualmente
maacutes pequentildeo que el conjunto de pruebas del sistema requiere menos tiempo actualizar el modelo que
actualizar todos los casos de prueba Por tanto puede concluirse que se obtiene una respuesta maacutes raacutepida
frente a un cambio en los requisitos
6 Reusabilidad del modelo
El modelo contiene informacioacuten sobre el comportamiento del sistema bajo pruebas Por tanto este puede ser
reutilizado en futuras pruebas incluso cuando los requisitos cambian
38
216 Problemas y Limitaciones de Model Based Testing (MBT)
Una vez destacados los beneficios que aporta dicha teacutecnica tambieacuten es importante detallar algunos problemas
y limitaciones sobre su uso [1] [5]
2161 Problemas
bull Para abordar dicha teacutecnica es necesario que los ingenieros de pruebas tengan habilidades teacutecnicas sobre
la notacioacuten usada para el modelado del sistema Ademaacutes deberiacutean tener experiencia con herramientas
scripts y lenguajes de programacioacuten usados para ejecutar las tareas de Model Based Testing
bull Cuando dicha teacutecnica se pretende aplicar a sistemas complejos el modelado del sistema es maacutes
complejo y existe riesgo de producirse un desbordamiento de la cantidad de casos de prueba generados
a partir del modelo Por esta razoacuten es muy importante definir bien el conjunto de criterios para la
generacioacuten de las pruebas lo cual permite acotar la cobertura de pruebas de forma razonable
bull La automatizacioacuten de la generacioacuten del oraacuteculo de pruebas a partir del modelo es compleja
especialmente en sistemas complejos Cuando el tamantildeo del sistema aumenta la necesidad de
automatizacioacuten tambieacuten aumenta
bull Es necesario desarrollar un modelo de software especiacutefico para un dominio en concreto de aplicacioacuten
ya que existen diversas notaciones de modelado del sistema
bull Es necesario la especificacioacuten formal de los requisitos para obtener el modelo del sistema a partir de
estos La especificacioacuten informal o en lenguaje natural de los requisitos puede dar lugar a ambiguumledades
que dificultan la exactitud en el modelado
2162 Limitaciones
bull No es posible modelar todos los aspectos del comportamiento del sistema bajo pruebas Por tanto es
necesario el uso de otras notaciones de modelado que cubran dichos aspectos
bull Los proyectos software evolucionan continuamente surgiendo nuevos requisitos los cuales algunos
pueden quedar fuera de la fecha de planificacioacuten Si se ha comenzado con el modelado a partir de
requisitos antiguos se construiraacute un modelo erroacuteneo que no reflejaraacute los nuevos requisitos
contemplados lo cual daraacute lugar a errores en el sistema bajo pruebas o resultados no fiables
bull Cuando se produce un fallo en una prueba generada podriacutea resultar maacutes complejo determinar la causa
del fallo ya que la secuencia de pruebas generadas en Model Based Testing podriacutea ser maacutes compleja y
menos intuitiva que las disentildeadas manualmente
217 Cuando elegir Model Based Testing (MBT)
Finamente tras detallar los beneficios problemas y limitaciones sobre la teacutecnica bajo estudio se destacan
algunos puntos principales a tener en cuenta para la aplicacioacuten de dicha teacutecnica
bull Debe existir documentacioacuten lo suficientemente buena sobre el sistema para poder aplicarla
bull Si ya existe un modelo del sistema seriacutea un primer paso que facilitariacutea su aplicacioacuten
bull El manager del proyecto debe ser consciente que la fase de pruebas con Model Based Testing comienza
desde la toma de requisitos ya que se debe modelar el comportamiento del sistema bajo pruebas a partir
de estos Por tanto no se puede esperar que la fase de pruebas comience despueacutes del desarrollo Hacerlo
tras el desarrollo podriacutea significar la modificacioacuten de los requisitos y en consecuencia el desarrollo
39
22 Gestioacuten de Calidad Software
221 Introduccioacuten
En los uacuteltimos antildeos la creciente demanda de productos software principalmente de aplicaciones distribuidas
como los servicios Web provoca que diferentes empresas busquen soluciones software para satisfacer las
necesidades de los clientes Este conjunto de empresas forma un entorno competitivo en el que se intenta buscar
algunos factores para destacar sobre los demaacutes competidores respondiendo a las nuevas exigencias del mercado
Bajo este contexto se plantea la implantacioacuten de una direccioacuten basada en la calidad como la propuesta que
mejores resultados ha ofrecido No solo basta con desarrollar software acorde a los requisitos de los clientes y
las exigencias de los mismos sino que se trata de crear un producto que garantice su correcto funcionamiento
bajo el sustento de una garantiacutea de calidad razonable
El concepto de ldquocalidadrdquo siempre se ha relacionado con la inspeccioacuten de productos fiacutesicos Pero dicho teacutermino
ha ido expandiendo su contexto de una forma maacutes global y aplicable a cualquier tipo de servicio o producto
ofrecido a un cliente
222 Concepto de Calidad
Acorde a la definicioacuten ofrecida por la Real Academia Espantildeola (RAE) la calidad se define como ldquouna propiedad
o conjunto de propiedades inherente a algordquo ldquoAdecuacioacuten de un producto o servicio a las caracteriacutesticas
especificadasrdquo o ldquocondicioacuten o requisito que se pone en un contratordquo [6]
Por otro lado el instituto de Ingenieros Eleacutectricos y Electroacutenicos (IEEE) define la calidad como ldquoel grado con
el que un sistema componente o proceso cumple con los requisitos especificados y las necesidades o
expectativas del cliente o usuariordquo destacando que el eacutenfasis radica en los requisitos especiacuteficos del sistema y
en la buacutesqueda de la satisfaccioacuten del cliente [7]
Roger Pressmann define la Calidad del Software como ldquoConcordancia del software producido con los requisitos
expliacutecitamente establecidos con los estaacutendares de desarrollo prefijados y con los requisitos impliacutecitos no
establecidos formalmente que desea el cliente y en uacuteltima instancia el usuariordquo [8]
Una vez presentado el concepto de calidad su definicioacuten orientada al software se refiere al grado de desempentildeo
de las principales caracteriacutesticas con las que debe cumplir un sistema durante su ciclo de vida Estas
caracteriacutesticas son las que garantizan que el cliente cuente con un sistema confiable lo que permite un aumento
de la satisfaccioacuten frente a la funcionalidad y eficiencia del sistema construido
Figura 7 Concepto de Calidad
40
223 Modelos de Calidad de Software
Los modelos de calidad son aquellos documentos que integran la mayor parte de las mejores praacutecticas proponen
temas de administracioacuten en los que cada organizacioacuten debe hacer eacutenfasis integran diferentes praacutecticas dirigidas
a los procesos clave y permiten medir los avances en calidad
Bajo este contexto los modelos de calidad deben permitir la evaluacioacuten del sistema de forma cualitativa o
cuantitativa y de acuerdo con esta evaluacioacuten la organizacioacuten podraacute proponer implementar estrategias que
permitan la mejora continua en el resto de etapas del ciclo de vida como son las etapas de anaacutelisis disentildeo
desarrollo y pruebas software [7] Desde finales de los antildeos 70 se han ido desarrollando diversos modelos de
calidad del producto software con el fin de fijar una terminologiacutea y entender queacute concepto de calidad se estaacute
usando Asiacute mismo dichos modelos de calidad se clasifican de acuerdo con el enfoque de evaluacioacuten
contemplado ya sea a nivel de proceso producto o calidad de uso
2231 Calidad a Nivel de Proceso
Este enfoque de calidad de software describe que la calidad de un sistema software debe ser implementada desde
el inicio del proyecto y en cada etapa de su ciclo de vida debiendo permitir el control y seguimiento de los
aspectos de calidad para minimizar los riesgos y ofrecer un soporte continuo De esta forma se consigue
garantizar un nivel oacuteptimo de cumplimiento de los factores de calidad definidos teniendo en cuenta que si en
alguna etapa no se verifican dichos factores posiblemente disminuya el nivel de calidad no solo del proceso si
no tambieacuten del producto en desarrollo [7]
A continuacioacuten se muestra una liacutenea de tiempo de algunos modelos a nivel de proceso y se describen dos de los
que maacutes intereacutes presentan dentro del aacutembito de este proyecto
Figura 8 Liacutenea de tiempo de modelos a nivel de proceso
ITIL (Information Technology Infrastructure Library)
Desarrollado en el Reino Unido con el fin de fortalecer la gestioacuten gubernamental a partir de cinco elementos
fundamentales la perspectiva del negocio entrega del servicio soporte del servicio manejo de la infraestructura
y manejo de aplicaciones con el propoacutesito de ofrecer una estructura integral para prestar a la organizacioacuten un
servicio completo cubriendo necesidades de apoyo de instalacioacuten adecuacioacuten de redes comunicaciones
hardware servidores sistema operativo y software necesarios
Figura 9 Logo de ITIL
41
ISOIEC 20000
El objetivo principal de esta norma es avalar que la prestacioacuten de servicios de TI en una empresa cuenta con la
calidad necesaria para brindar dichos servicios a los clientes Esta norma engloba diferentes secciones dedicadas
a las especificaciones de dicha norma y a los coacutedigos de buenas praacutecticas
Figura 10 ISOIEC 20000
WebQEM
Web-site Quality Evaluation Method se trata de una metodologiacutea de evaluacioacuten de calidad de sitios Web en seis fases planificacioacuten y programacioacuten de la evaluacioacuten de la calidad definicioacuten y especificacioacuten de los requisitos de calidad establecidos definicioacuten e implementacioacuten de la evaluacioacuten elemental definicioacuten e implementacioacuten de la evaluacioacuten global anaacutelisis de resultados y evaluacioacuten de meacutetricas y finalmente conclusiones y documentacioacuten
Figura 11 Logo de WebQEM
42
2232 Calidad a Nivel de Producto
El enfoque de la calidad de software a nivel de producto tiene como objetivo especificar y evaluar el
cumplimiento de los criterios del producto Para ello se suelen definir y aplicar medidas o meacutetricas internas o
externas Por esta razoacuten muchas normas definen la calidad a nivel de producto de tipo interna externa y en uso
Esta uacuteltima se define como el conjunto de atributos relacionados con la aceptacioacuten por parte del usuario final y
seguridad
A continuacioacuten se muestra una liacutenea de tiempo de algunos modelos a nivel de proceso y se describen tres de los
que maacutes intereacutes presentan dentro del aacutembito de este proyecto
Figura 12 Liacutenea de tiempo de modelos a nivel de producto
ISO 9126
Este se basa en el modelo McCall el cual es uno de los modelos pioneros en la evaluacioacuten de la calidad de
software Desarrollado en 1991 es un marco normativo dirigido a desarrolladores aseguradores de calidad
evaluadores analistas y cualquier otro involucrado en el proceso de construccioacuten de software y la gestioacuten de
calidad del mismo Estaacute dividido en cuatro partes Modelo de Calidad Meacutetricas Externas Meacutetricas Internas y
Calidad de Meacutetricas en Uso
Esta norma busca la fiabilidad funcionalidad usabilidad eficiencia mantenibilidad y portabilidad en la
construccioacuten de productos software A continuacioacuten se muestra un esquema que resume dichas caracteriacutesticas
y subcaracteriacutesticas [8]
Figura 13 Esquema de ISO 9126
43
ISOIEC 25000
Basada en la norma ISO 9126 y adaptando parte del marco normativo a las necesidades del mercado actual Esta
norma tambieacuten conocida como SQuaRE (Software Product Quality Requirements and Evaluation) establece
un marco de trabajo comuacuten para evaluar la calidad de productos de Software
En dicha norma se definen los modelos teacuterminos y definiciones comunes para el resto de normas que componen
la serie 25000 La ISOIEC 25000 presenta diversas secciones entre las que se puede destacar [9]
ISOIEC 25010 Describe las caracteriacutesticas y subcaracteriacutesiticas de calidad que pueden ser evaluadas
en un producto software diferenciando entre calidad interna externa y de uso En la siguiente figura se
presenta un desglose de dichas caracteriacutesticas
ISOIEC 25040 Define el proceso de evaluacioacuten perioacutedico de la calidad del producto software
Figura 14 Esquema de ISOIEC 25000
44
224 Principales Ventajas e Inconvenientes de Modelos de Calidad anteriores
2241 A nivel de Proceso
Modelo Ventajas Inconvenientes
ITIL bull Mejor estructuracioacuten organizacioacuten y
claridad de los proyectos
bull Mayor control administrativo
bull Mayor eficacia y rapidez ante cambios
bull Incrementa la productividad del negocio y la
fiabilidad de los clientes
bull Tiempo y esfuerzo necesarios
bull Falta de conocimiento para apreciar la mejora
proporcionada
bull Involucracioacuten y compromiso de todo el
personal de la organizacioacuten
bull Frustracioacuten generada por expectativas a corto
plazo
bull No hay mejoriacutea si la inversioacuten asignada para
implantar el modelo es insuficiente
ISOIEC
20000 bull Reconocimiento internacional
bull Muy usado por las organizaciones
WebQUEM bull Calidad medida en fases y actividades de
forma cuantitativa con indicadores
bull Aplicaciones de Software centradas en la Web
son cada vez maacutes complejas provocan mayor
complejidad en su implantacioacuten
2242 A nivel de Producto
Modelo Ventajas Inconvenientes
ISO 9126 bull Determina queacute caracteriacutesticas y
subcaracteriacutesticas son importantes para el
producto
bull Define meacutetricas especiacuteficas para los
componentes Software
bull Define indicadores para las caracteriacutesticas de
calidad
bull Usabilidad tratada desde la perspectiva del
proceso no del producto
bull No tiene en cuenta la caracteriacutestica de ldquofacilidad
de aprendizajerdquo siendo esta recomendada por
otros estaacutendares
bull Meacutetricas complejas difiacutecilmente medibles
Requieren descomposicioacuten
ISOIEC
25000 bull Detecta objetivos del producto alineados con
necesidades reales de clientes finales
bull Evita ineficiencias y maximiza rentabilidad
y calidad del producto
bull El proceso de evaluacioacuten perioacutedica permite
la mejora continua
bull No establece niveles de calidad para cada
proyecto
bull No hace uso de meacutetricas o umbrales de calidad
225 Conclusiones
Una vez presentado el concepto de gestioacuten de calidad de software y los principales modelos y normas es
interesante destacar la diferencia entre calidad interna y externa La calidad interna se centra en las caracteriacutesticas
propias del producto software (disentildeo especificacioneshellip) mientras que la calidad externa lo hace con las
caracteriacutesticas dinaacutemicas del mismo es decir con el comportamiento Es por ello que el proceso de calidad
interna se inicia en las fases tempranas del ciclo de vida de un proyecto mientras la calidad externa se aplica
una vez se tiene un primer prototipo funcional del producto software desarrollado Por tanto se trataraacute de
automatizar el proceso de evaluacioacuten de la calidad externa del proyecto CHT Cloud Manager analizando
verificando y validando automaacuteticamente la aceptacioacuten de dicho producto
45
46
3 MARCO TEOacuteRICO PRUEBAS DE SOFTWARE
ras presentar el concepto de calidad y algunas de las normas y estaacutendares maacutes conocidos que describen
la aplicacioacuten de dicho concepto en el aacutembito del desarrollo de software se centraraacute el enfoque en el
papel del testeo y las pruebas de software Con ello se destacaraacuten algunos puntos principales para
llevar a cabo las pruebas de software el anaacutelisis disentildeo e implementacioacuten de dichas pruebas los diferentes tipos
y niveles de pruebas y las dificultades de la aplicacioacuten de pruebas de software sobre aplicaciones Web
31 Testing y Pruebas de Software
Habitualmente se tiene una percepcioacuten del testing de un producto como una tarea basada en la ejecucioacuten de
pruebas de forma repetitiva para la buacutesqueda de errores o problemas que puedan repercutir sobre la calidad del
mismo Pero el testing no solo se basa en la realizacioacuten de pruebas
Se deben identificar otras tareas que estaacuten relacionadas con el testing las cuales se llevan a cabo antes y despueacutes
de la ejecucioacuten de pruebas Estas tareas estaacuten relacionadas principalmente con la planificacioacuten y control del
proceso de pruebas el disentildeo de los diferentes casos de prueba o test cases y la posterior comprobacioacuten de los
resultados obtenidos tras llevar a cabo las pruebas Otras tareas podriacutean ser la propia evaluacioacuten de los diferentes
criterios de finalizacioacuten del proceso de pruebas el anaacutelisis de informes de resultados o la revisioacuten de la
documentacioacuten generada en la fase de pruebas
A continuacioacuten se citan algunas definiciones para explicar el concepto de pruebas de software
ldquoUna prueba es una actividad ejecutada para evaluar la calidad del producto software y mejorarlo mediante
la identificacioacuten de problemas errores o defectos en su funcionamiento [9]rdquo
ldquoLas pruebas de Software consisten en verificaciones dinaacutemicas del comportamiento del software bajo
pruebas mediante un conjunto finito de casos de prueba seleccionadas adecuadamente sobre un dominio
infinito de casos posibles [1]rdquo
Atendiendo a las definiciones presentadas las pruebas de software son dinaacutemicas porque se puede ejecutar el
software bajo pruebas con un conjunto de valores de entrada especiacuteficos para encontrar fallos en su
comportamiento Por otro lado la realizacioacuten de pruebas exhaustivas no es posible para la mayoriacutea de los
productos software reales debido a la gran cantidad de entradas posibles para cada operacioacuten entradas invaacutelidas
o no esperadas y las infinitas secuencias de operaciones posibles
Por estas razones para aplicar un proceso de pruebas de software razonable en cuanto a recursos y tiempo de un
proyecto es necesario seleccionar un conjunto abarcable de pruebas Debido a esto la clave estaacute en el criterio
de seleccioacuten de dichas pruebas Una vez ejecutadas las pruebas seleccionadas se debe decidir si el
comportamiento esperado del sistema falla o no Este es el llamado problema del oraacuteculo el cual es resuelto en
la mayoriacutea de los casos de forma manual mediante la inspeccioacuten de los resultados de la prueba
T
La tecnologiacutea no es nada Lo importante es que tengas feacute
en la gente que sean baacutesicamente buenas e inteligentes
y si les das herramientas haraacuten cosas maravillosas con
ellas
Steve Jobs
47
32 Principios de las Pruebas de Software
Una vez presentada la definicioacuten de pruebas de Software se han obtenido algunos detalles que encajan
perfectamente con una serie de principios que han sido establecidos para el testing de productos software seguacuten
ISTQB (International Software Testing Qualifications Board) [10]
Figura 15 Principios de las Pruebas de Software
1 Las pruebas demuestran la presencia de defectos no su ausencia Las pruebas pueden mostrar que
los defectos estaacuten presentes en el producto pero no pueden probar que no haya defectos Por tanto las
pruebas pueden reducir la probabilidad de existencia de defectos en el software pero incluso si no se
encuentran defectos las pruebas no son una garantiacutea total para afirmar la ausencia de defectos en el
producto final
2 Las pruebas exhaustivas son imposibles Probar todas las posibles combinaciones de entradas y
condiciones previas sobre una aplicacioacuten no es factible excepto en casos muy triviales En lugar de
intentar realizar pruebas exhaustivas se debe usar el anaacutelisis de riesgos las teacutecnicas de prueba y las
prioridades ademaacutes de la automatizacioacuten para enfocar los esfuerzos en la fase de pruebas
3 Las pruebas tempranas ahorran tiempo y dinero Para una deteccioacuten temprana de errores y defectos
las actividades de pruebas deben iniciarse lo antes posible en el ciclo de vida del desarrollo del software
De esta forma se consigue una reduccioacuten de costes ya que cuanto maacutes tarde se detecte un defecto maacutes
costoso y difiacutecil seraacute corregirlo
4 Los defectos se agrupan Generalmente una pequentildea parte del software desarrollado concentra la
mayor complejidad del mismo por lo que la mayoriacutea de los defectos detectados tienen una mayor
probabilidad de encontrarse en esos elementos maacutes complejos Por tanto la realizacioacuten de un buen
anaacutelisis de riesgos permite enfocar el esfuerzo de pruebas en las aacutereas del producto con mayor
probabilidad de presentar defectos
Aplicando el Principio de Pareto al control de calidad [11] el 80 de los errores y defectos estaacute causado
por un 20 del total del producto software desarrollado lo cual podriacutea ser un buen principio sobre el
que basar el anaacutelisis de riesgos
5 Cuidado con la paradoja del pesticida Si las mismas pruebas se repiten una y otra vez con el tiempo
los mismos casos de pruebas ya no encontraraacuten nuevos defectos lo cual no quiere decir que la aplicacioacuten
presente una ausencia completa de los mismos (Las pruebas ya no son eficaces para detectar defectos
al igual que los pesticidas ya no son eficaces para matar insectos despueacutes de un tiempo) Para detectar
nuevos defectos es necesario que las pruebas existentes y los datos de las pruebas deban cambiar
ademaacutes de surgir la necesidad de disentildear nuevas pruebas
48
6 Las pruebas dependen del contexto Cada empresa organizacioacuten o proyecto adaptaraacute el proceso de
pruebas a sus necesidades recursos disponibles o aacutereas de riesgo existentes
7 La ausencia de errores es una falacia Un producto software puede tener un 100 de casos de eacutexito
en su fase de pruebas pero esto solo indica que hay defectos que auacuten no han sido localizados e
identificados
33 Proceso de Pruebas de Software Anaacutelisis disentildeo e implementacioacuten
Partiendo de los principios detallados en la seccioacuten anterior se presentan las diferentes etapas del proceso de
pruebas de software asiacute como la documentacioacuten generada en cada etapa
331 Terminologiacutea
Previamente se presentaraacuten algunos teacuterminos y definiciones que convienen describir para una mejor
comprensioacuten de todo el proceso de pruebas [3]
Figura 16 Terminologiacutea para el proceso de pruebas
1 Condicioacuten de prueba Elemento o evento de un componente o sistema que puede ser verificado por
uno o maacutes casos de prueba Los diferentes requisitos que definen la funcionalidad de un sistema pueden
ser descompuestos en diferentes condiciones de prueba
2 Caso de prueba conjunto de valores de entrada precondiciones de ejecucioacuten y valores esperados
Estos son desarrollados para perseguir un objetivo particular por ejemplo una condicioacuten de prueba
3 Precondicioacuten Condiciones de entorno y estado que deben ser satisfechas antes de que un componente
o sistema pueda ser sometido a un caso de prueba o conjunto de estos
4 Abstraccioacuten de casos de prueba Consiste en la generalizacioacuten de los casos de prueba especiacuteficos sin
valores concretos para sus entradas condiciones de prueba o valores esperados En resumen no es maacutes
que llevar las condiciones de prueba a un caso general para cualquier valor de entrada
5 Script de pruebas Una vez disentildeados los casos de prueba estos pueden ser implementados y
ejecutados por una herramienta de automatizacioacuten Un script de pruebas puede contener varios casos
de prueba
6 Paquete de pruebas Consiste en la agrupacioacuten de casos de prueba relacionados en cuanto a la
funcionalidad que automatizan sobre el sistema
7 Programacioacuten de la ejecucioacuten de pruebas Describen el flujo de ejecucioacuten de los diferentes paquetes
de pruebas
49
332 Proceso de Pruebas de Software
No existe un proceso de pruebas universal pero existen conjuntos comunes de actividades de prueba sin las
cuales las pruebas disentildeadas e implementadas tendriacutean menos probabilidad de alcanzar sus objetivos
establecidos Estos conjuntos de actividades de prueba constituyen un proceso de pruebas
Como se ha mencionado en secciones anteriores el proceso de pruebas se debe iniciar en las fases maacutes iniciales
del ciclo de vida de un proyecto Por tanto las actividades del proceso de pruebas la manera en que se
implementan dichas actividades y cuaacutendo ocurren pueden ser discutidas en la estrategia de pruebas de una
organizacioacuten
A continuacioacuten se exponen las etapas fundamentales del proceso de pruebas detallando en cada una de ellas la
documentacioacuten generada y coacutemo contribuyen a la mejora de la calidad del producto con su aplicacioacuten en el ciclo
de vida de un proyecto [13]
Figura 17 Proceso de Pruebas de Software
3321 Planificacioacuten y Control de Pruebas
La planificacioacuten consiste en determinar los diferentes objetivos de las pruebas realizadas sobre el Sistema bajo
test las especificaciones y los recursos que se necesitaraacuten para llevar a cabo la fase de pruebas y cumplir con los
objetivos planteados
Es en este punto donde se define el alcance de las pruebas a realizar de forma que se selecciona lo que seraacute y
no seraacute testeado ademaacutes de indicar quieacuten haraacute cada prueba y como la llevaraacute a cabo Mediante los objetivos de
las pruebas se puede establecer un punto de finalizacioacuten del proceso
Como salida de la actividad de planificacioacuten se obtendriacutea el ldquoPlan de Pruebasrdquo el cual documenta la estrategia
y el alcance de las pruebas la prioridad en cuanto a su realizacioacuten y las estimaciones temporales para su
evaluacioacuten ademaacutes de los recursos materiales y humanos para llevarlas a cabo
Es crucial que dicho documento sea validado por el personal correspondiente del proyecto antes de continuar
con las siguientes etapas del proceso de pruebas
Por otro lado el control de pruebas es una actividad desarrollada durante todo el ciclo de vida del proceso de
pruebas el cual permite contrastar el progreso actual con el plan original trazado para la aplicacioacuten de dicho
proceso incluyendo informes y desviaciones
Cuando se produce una desviacioacuten del plan original que introduce cierto riesgo adicional puede hacerse
necesario modificar los objetivos fijados para asegurar la calidad del producto De ahiacute que sea sumamente
importante tener en consideracioacuten la documentacioacuten generada en antiguos proyectos
50
3322 Anaacutelisis y Disentildeo de Pruebas
Una vez planificado el alcance y objetivos de las pruebas se realiza una actividad de anaacutelisis donde se traducen
a condiciones de prueba y posteriormente se disentildean los casos de prueba de alto nivel a partir de la abstraccioacuten
de los casos de prueba
Por otro lado cabe destacar la necesidad de un mecanismo que garantice la trazabilidad con la finalidad de
mantener alineados en todo momento los casos de prueba con los objetivos de la misma incluso contemplando
la posibilidad de que los objetivos puedan cambiar en alguacuten momento del proceso de pruebas
El documento generado en esta actividad es conocido como ldquoespecificaciones de disentildeo de pruebasrdquo
3323 Implementacioacuten y Ejecucioacuten de Pruebas
Dicha etapa consiste en la implementacioacuten de los casos de prueba de alto nivel que cumplen con las
especificaciones de disentildeo de la etapa anterior Es en esta fase donde se haraacute uso de herramientas para la
implementacioacuten y ejecucioacuten de las pruebas
Cabe destacar que para llevar a cabo dicha etapa en cuanto a la verificacioacuten y validacioacuten funcional de un
proyecto es necesario que durante la etapa de desarrollo se haya creado un producto funcional sobre el cual
puedan ejecutarse las pruebas
Durante la ejecucioacuten de las pruebas los resultados obtenidos quedaraacuten documentados en un documento
denominado ldquoRegistro de Pruebasrdquo el cual contiene todas las pruebas realizadas y un ldquoReporte de Incidenterdquo
por cada resultado no esperado que se haya detectado
Una vez sean corregidos los incidentes se debe volver a ejecutar las pruebas con la finalidad de asegurar que
dicho incidente haya sido corregido ademaacutes de asegurar que la correccioacuten realizada no haya introducido otros
defectos o errores Esto es lo que se denomina ldquoPruebas de Regresioacutenrdquo
3324 Evaluacioacuten de los criterios de eacutexito y Elaboracioacuten de reportes e informes
Tras la ejecucioacuten de las pruebas se deben evaluar los criterios de eacutexito los cuales han sido definidos en la etapa
de planificacioacuten
El personal responsable e involucrado en el proyecto se reuniraacute y revisaraacute el cumplimiento de dichos criterios
el registro de pruebas obtenido y los reportes de incidentes que hayan podido ser abiertos en la etapa anterior
Finalmente como resultado de dicha actividad se elabora un ldquoSumario final de Pruebasrdquo
3325 Cierre de la fase de pruebas
Las actividades de cierre de la fase de pruebas se centran mayormente en asegurar que todo el ciclo de vida del
proceso de pruebas se ha cumplido ademaacutes de analizar las posibles mejoras y defectos en las fases llevadas a
cabo
Ademaacutes se lleva a cabo el cierre de los incidentes corregidos y la liberacioacuten de los entornos y recursos asignados
a la fase de pruebas
51
34 Clasificacioacuten de Pruebas de Software
Existen diversos tipos de pruebas las cuales pueden ser clasificadas en funcioacuten del objetivo de prueba para lo
cual hayan sido establecidos Cada tipo de prueba persigue unos objetivos especiacuteficos sobre el producto pero
todas ellas persiguen como objetivo comuacuten ofrecer un producto con garantiacutea de calidad al cliente o usuario final
Dichas pruebas pueden ser clasificadas en cuatro tipos
Figura 18 Clasificacioacuten de Pruebas de Software
341 Pruebas Funcionales
Tambieacuten conocidas como ldquoPruebas de caja Negrardquo En [14] la IEEE define este tipo de pruebas como
ldquoPruebas que ignoran los mecanismos internos de un sistema o componente y se enfocan
solamente en las salidas generadas como respuesta a las entradas seleccionadas y a las
condiciones de ejecucioacutenrdquo
Figura 19 Pruebas de Caja Negra
Atendiendo a la definicioacuten anterior el sistema o componente sujeto a pruebas debe realizar una funcioacuten
determinada Estaraacute descrita en las especificaciones funcionales y se pueden llevar a cabo a cualquier nivel
Dichas especificaciones funcionales describen el comportamiento del sistema sin revelar informacioacuten acerca de
su implementacioacuten interna
Un tipo especial de prueba funcional son las ldquoPruebas de Humordquo o ldquoSmoke Testsrdquo Este tipo de pruebas suele
realizarse en fases tardiacuteas del desarrollo y permiten asegurar que las funcionalidades baacutesicas del software
responden adecuadamente
Por tanto dichas pruebas pueden quedar lejos de ser pruebas exhaustivas aunque siacute permiten asegurar que el
producto entregado al cliente cumple con los requisitos de funcionamiento establecidos Este tipo de pruebas
son las que se han implementado y automatizado en el proyecto presente lo cual se detallaraacute en capiacutetulos
posteriores
52
342 Pruebas No Funcionales
Este tipo de pruebas estaacuten orientadas a verificar coacutemo de bien funciona el sistema bajo pruebas en lugar de la
funcionalidad que ofrece Por ello pueden ser agrupadas tambieacuten dentro de la categoriacutea de pruebas de caja negra
Atendiendo al estaacutendar de evaluacioacuten del producto software ldquoISO 25000rdquo todas las caracteriacutesticas excepto la de
funcionalidad definen caracteriacutesticas de calidad no funcionales de un producto software Estas caracteriacutesticas de
calidad tienen su correspondiente tipo de prueba
3421 Pruebas de Rendimiento
Las pruebas de rendimiento son usadas para determinar la rapidez con la que se realiza una tarea en el sistema
bajo unas condiciones particulares de trabajo Estas pruebas tambieacuten pueden ser usadas para validar y verificar
otros atributos de calidad del sistema tales como la escalabilidad fiabilidad y uso de recursos
Figura 20 Pruebas de Rendimiento
3422 Pruebas de Carga
Este tipo de pruebas miden el rendimiento del sistema con una carga de trabajo manejable y conocida Se trata
de someter al sistema a cargas de trabajo controladas por el ingeniero de pruebas para validar prestaciones de
rendimiento sobre el sistema
Figura 21 Pruebas de Carga
3423 Pruebas de Estreacutes
Las pruebas de estreacutes ponen a prueba la robustez y confiabilidad del sistema sometieacutendolo a condiciones de uso
extremas Entre estas condiciones se incluyen el enviacuteo masivo de peticiones y la ejecucioacuten en condiciones de
hardware limitadas Dichas condiciones van maacutes allaacute de los liacutemites de operacioacuten considerados en el disentildeo
Figura 22 Pruebas de Estreacutes
53
3424 Pruebas de Usabilidad
Estas pruebas se centran en encontrar problemas de la interfaz de usuario que podriacutean hacer que el software sea
difiacutecil de utilizar o podriacutean causar que los usuarios mal interpreten las salidas Por tanto permiten medir coacutemo
de atractivo resulta un producto software basaacutendose en la facilidad de adaptacioacuten y uso por parte de los clientes
Figura 23 Pruebas de Usabilidad
3425 Pruebas de Fiabilidad
Prueban el rendimiento del sistema ante un determinado nuacutemero de operaciones o tras cierto periodo de
tiempo
3426 Pruebas de Instalacioacuten
Las pruebas de instalacioacuten tienen dos propoacutesitos El primero es asegurar que el sistema puede ser instalado
en todas las configuraciones posibles tales como nuevas instalaciones actualizaciones instalaciones
completas o personalizadas y bajo condiciones normales o anormales estas uacuteltimas incluyen insuficiente
espacio en disco falta de privilegios para algunas tareas etc
El segundo propoacutesito es verificar que una vez instalado el sistema opera correctamente Esto usualmente
implica ejecutar un nuacutemero significativo de pruebas de Funcionalidad
Por tanto miden coacutemo de sencillo resulta instalar la aplicacioacuten en distintas plataformas o entornos
3427 Pruebas de Portabilidad
Miden coacutemo de sencillo resulta migrar una aplicacioacuten de una plataforma a otra
Figura 24 Pruebas de Portabilidad
54
343 Pruebas Estructurales
Este tipo de pruebas son tambieacuten conocidas como ldquoPruebas de Caja Blancardquo En [14] la IEEE define este tipo
de pruebas como
ldquoPruebas que tienen en cuenta los mecanismos internos de un sistema o componenterdquo
Figura 25 Pruebas de Caja Blanca
Atendiendo a dicha definicioacuten estas pruebas tienen en cuenta la estructura del coacutedigo fuente del software a partir
del cual se seleccionan los diferentes casos de prueba guiaacutendose por la existencia de sentencias condicionales
bucles etc
Por tanto los casos de prueba son desarrollados usando criterios de cobertura para el coacutedigo del programa De
esta forma el sistema bajo pruebas se trata como una caja de cristal que permite ver su estructura
El criterio de cobertura hace referencia a cada miacutenima unidad de coacutedigo que puede ser probada de forma
independiente Es frecuente usar este tipo de pruebas en los niveles de prueba maacutes bajos como por ejemplo en
las ldquoPruebas Unitariasrdquo o las ldquoPruebas de Componenterdquo
344 Pruebas debidas a Cambios
Finalmente en el proceso de pruebas tras ejecutar las pruebas y encontrar un defecto o error en el sistema bajo
pruebas este se corrige pero es necesario validar la correccioacuten realizada para confirmar que el fallo no se
reproduce A este proceso se le denomina ldquoPrueba de confirmacioacuten o re-testingrdquo
Ademaacutes las correcciones pueden ser validadas pero tambieacuten es necesario asegurar que los cambios introducidos
para corregir dicho fallo no han provocado maacutes defectos Por tanto puede concluirse que es necesario volver a
realizar pruebas sobre el resto del sistema Estas son las ldquoPruebas de Regresioacutenrdquo
35 Niveles de Prueba
El proceso de pruebas es una etapa del ciclo de vida de un proyecto cuyas actividades estaacuten completamente
relacionadas con las actividades del proceso de desarrollo Existen diversos modelos que describen las fases y
actividades del proceso de desarrollo de software En esta seccioacuten se detallaraacute el uso del ldquoModelo de desarrollo
en Vrdquo
Este modelo describe las diferentes fases del proceso de desarrollo y sugiere la realizacioacuten de pruebas en cada
una de ellas Estas pruebas seraacuten ejecutadas posteriormente en orden ascendente Por tanto para cada fase existen
unos objetivos a cumplir los cuales deben ser probados para medir la integridad del trabajo realizado
55
A continuacioacuten se detallaraacuten los diferentes niveles de prueba para cada etapa del desarrollo software atendiendo
al modelo de desarrollo en V
Figura 26 Modelo de desarrollo en V
351 Pruebas a Nivel de Componente
Tambieacuten llamadas ldquoPruebas Unitariasrdquo El objetivo de estas pruebas es el de cubrir la unidad miacutenima funcional
que compone el software Estos componentes suelen tener una uacutenica funcioacuten especiacutefica la cual seraacute usada por
el resto del Sistema A menudo son realizadas por los propios desarrolladores haciendo uso de la metodologiacutea
de desarrollo guiado por prueba o Test-Driven-Development (TDD)
352 Pruebas a Nivel de Integracioacuten
Son aquellas pruebas realizadas en el aacutembito del desarrollo software una vez validadas las pruebas unitarias
Estas pruebas verifican que todos los elementos unitarios que componen el software funcionan en conjunto de
forma correcta Se centran principalmente en probar la comunicacioacuten entre los diferentes componentes del
sistema
353 Pruebas a Nivel de Aceptacioacuten
Este uacuteltimo nivel se centra en las necesidades del usuario requisitos y procesos de negocio con el fin de
determinar si el sistema satisface los criterios de aceptacioacuten acordados con el cliente en un contrato o acuerdo
de nivel de servicio en caso de ser un software de uso interno dentro de una compantildeiacutea
Ejemplos de este tipo de pruebas pueden ser las ldquoPruebas Alfa y Betardquo
Como se ha detallado anteriormente las pruebas desarrolladas y automatizadas en este Proyecto son ldquoPruebas
de humordquo o Smoke Tests Estas pruebas se centran en la verificacioacuten y validacioacuten de las especificaciones de uso
de un Sistema en este caso de la plataforma Web de gestioacuten Galgus CHT Manager
56
36 Dificultades de pruebas en aplicaciones Web e impacto
La complejidad antildeadida de las aplicaciones y servicios Web frente a otros tipos de aplicaciones recae sobre el
uso de muacuteltiples tecnologiacuteas de vanguardia que permiten la construccioacuten de sistemas distribuidos con un amplio
grado de escalabilidad accesibilidad disponibilidad interoperabilidad e independencia del hardware
Como consecuencia del incremento de la complejidad de las aplicaciones surgen nuevos paradigmas como la
Arquitectura Orientada a Servicios (SOA) la cual permite interoperabilidad y flexibilidad de las aplicaciones
distribuidas
Todo ello conlleva a plantearse queacute se deberiacutea hacer para garantizar que una aplicacioacuten Web puesta en marcha
funciona de acuerdo a los requisitos definidos y acordados con el cliente Podriacutean optimizarse y mejorarse los
diferentes procesos dentro del ciclo de vida de un proyecto pero siempre la fase de pruebas termina siendo la
fase previa a la puesta en marcha de la aplicacioacuten con lo que resulta siendo la uacuteltima oportunidad para detectar
posibles fallos que puedan terminar en ocasiones en peacuterdidas econoacutemicas de prestigio de fiabilidad y de
credibilidad por parte de los clientes
Realizar pruebas en una aplicacioacuten Web no es tarea faacutecil ya que son muchos los factores que influyen en el
testeo del sistema para abarcar y contemplar el maacuteximo de flujos posibles que se pueden llevar a cabo durante
el uso de la aplicacioacuten
Hoy en diacutea las aplicaciones Web pueden ser construidas con componentes implementados en diferentes
lenguajes y arquitecturas basaacutendose en diferentes modelos de programacioacuten y pudiendo ejecutarse en diferentes
plataformas de hardware y software
Esto incrementa la complejidad de las pruebas a realizar sobre un sistema de este tipo por lo que seriacutea interesante
plantearse la posibilidad de usar herramientas que permitan una abstraccioacuten de dicha complejidad ademaacutes de la
automatizacioacuten de la fase de pruebas En el caso de las pruebas a nivel de aceptacioacuten en este proyecto se
propondraacute el uso de herramientas que persiguen dichos fines
Figura 27 Dificultades de pruebas en aplicaciones Web e impacto
57
58
4 SISTEMA GALGUS CHT CLOUD MANAGER
ras realizar un estudio del arte sobre una teacutecnica que puede ser de gran utilidad para optimizar y
perfeccionar las teacutecnicas de automatizacioacuten para el proceso de pruebas sobre un sistema se han puesto
en contexto los diferentes tipos de pruebas que pueden realizarse sobre un sistema ademaacutes de definir
el proceso de pruebas Una vez llegados a este punto en primer lugar se realizaraacute una descripcioacuten del sistema
bajo pruebas sobre el cual se plantearaacute una solucioacuten para la fase de pruebas y su automatizacioacuten Maacutes
concretamente para la realizacioacuten de las pruebas a nivel de aceptacioacuten
41 Arquitectura y Descripcioacuten del Sistema
CHT Cloud Manager es un proyecto de la empresa Galgus el cual ofrece una plataforma Web de gestioacuten
configuracioacuten y monitorizacioacuten de redes WiFi Maacutes concretamente dicha plataforma permite gestionar un
conjunto de puntos de acceso desplegados con un conjunto de algoritmos definidos por software los cuales
permiten la optimizacioacuten de los recursos de red inalaacutembricos ofreciendo mayores prestaciones y una mayor
calidad de servicio al usuario Ademaacutes dicho software embebido ofrece otros servicios al cliente como la
localizacioacuten de estaciones dentro de la zona de alcance de la red WiFi o la deteccioacuten de intrusos y ataques de
suplantacioacuten de identidad
A este conjunto de algoritmos se le conoce bajo el nombre Cognitive Hostpot Technology (CHT) Este software
implementado en lenguaje C y preparado para sistemas embebidos como los puntos de acceso presenta una
estructura modular donde cada moacutedulo se encarga de una tarea determinada o de ejecutar un algoritmo
determinado
Figura 28 Logo de Galgus
Para permitir la comunicacioacuten con la plataforma Web CHT implementa un moacutedulo denominado MGR el cual
permite la conexioacuten con un broacuteker de eventos o intermediario para permitir el enviacuteo y la recepcioacuten de eventos
desde dicha plataforma
T
La simplicidad llevada al extremo se convierte en
elegancia
Jon Franklin
59
En la siguiente figura se muestra la arquitectura orientada a servicios para CHT Cloud Manager
Figura 29 Arquitectura de CHT Cloud Manager
Puede observarse que dicha plataforma estaacute formada por diferentes microservicios desplegados en la nube Cada
uno de ellos realiza una serie de tareas bien definidas e interactuacutean entre ellos enviando y recibiendo mensajes
haciendo uso de diferentes protocolos y modelos de comunicacioacuten
De esta forma se consigue mantener actualizado el estado de la informacioacuten de los diferentes elementos en
tiempo real sobre los diferentes eventos que puedan ocurrir en el sistema Dichos eventos proceden en su gran
mayoriacutea del conjunto de puntos de acceso que conforma una red de Galgus la cual pretende ser gestionada desde
la plataforma en cuestioacuten
A continuacioacuten se detallaraacuten los diferentes microservicios que conforman dicha plataforma ademaacutes de describir
a los puntos de acceso con la tecnologiacutea CHT como elementos a gestionar desde dicha plataforma
60
411 Puntos de Acceso (OpenWRT + CHT)
4111 OpenWRT
Los puntos de acceso WiFi de Galgus son sistemas embebidos de diferentes modelos en funcioacuten de las
especificaciones hardware que ofrezcan (nuacutemero de streams espaciales nuacutemero de antenas de exterior de
interior etc)
Todos ellos tienen en comuacuten el uso de OpenWRT como sistema operativo Este se trata de un sistema operativo
open source basado en Linux y usado para sistemas de red embebidos Todos los componentes de dicho sistema
han sido optimizados para dispositivos con limitaciones de hardware y este permite configurarlos mediante
interfaz de liacutenea de comandos o mediante una interfaz Web (LuCI) [15]
Partiendo de dicho sistema operativo Galgus desarrolla CHT como producto software que dota a los puntos de
acceso de una serie de prestaciones en una serie de moacutedulos Dicho producto es ofrecido al cliente mediante
licencias las cuales son gestionadas desde un servidor de licencias y obtenidas por los puntos de acceso de
forma automaacutetica Todo ello se detallaraacute maacutes adelante
4112 CHT
CHT tambieacuten ofrece su propia interfaz de liacutenea de comandos denominada CHT_CLI Esta herramienta permite
configurar los distintos moacutedulos de los que se compone CHT y obtener informacioacuten tanto de la configuracioacuten
como del funcionamiento de los algoritmos CHT
A continuacioacuten se presenta la interfaz y algunos de los comandos que se pueden utilizar
Figura 30 CHT_CLI
CHT_CLI es fundamental tanto en el desarrollo como en el testeo de CHT y CHT Cloud Manager ya que nos
permite acceder a paraacutemetros de configuracioacuten que no estaacuten accesibles desde la interfaz graacutefica LuCI Desde
CHT_CLI se controlan todos los moacutedulos de CHT entre los que se pueden destacar los siguientes Load Balance
(LB) Smart Roaming (SR) Power Control (POWER) Localization (LOC) Traffic Congestion Management
(TCM) Smart Band Steering (SB) y el moacutedulo Manager (MGR)
En este caso es de intereacutes resaltar el moacutedulo que permite la comunicacioacuten con la plataforma de gestioacuten CHT
Cloud Manager Dicho moacutedulo conocido bajo el nombre de MGR implementa un cliente AMQP para
establecer la comunicacioacuten con el broacuteker de eventos usado como intermediario para permitir la comunicacioacuten
entre los puntos de acceso y la plataforma de gestioacuten CHT Cloud Manager
Ademaacutes implementa una serie de estructuras de datos que son enviados a traveacutes de dicho intermediario basadas
en FlatBuffers como plataforma eficiente de serializacioacuten cruzada de datos ofrecida por Google Esta
herramienta permite crear un modelo de datos bajo la sintaxis ofrecida por FlatBuffers para posteriormente
generar dichas estructuras de datos en diferentes lenguajes de programacioacuten como por ejemplo C++ C C
Go Java JavaScript etc
Con esto se consigue generar estructuras de datos con una compatibilidad absoluta que se intercambiaraacuten entre
la plataforma de gestioacuten en lenguaje Java y los puntos de acceso en lenguaje C
61
412 Broacuteker de Eventos AMQP (RabbitMQ)
Este microservicio implementa un broacuteker de eventos que actuacutea como intermediario entre los puntos de acceso
WiFi y algunos microservicios que componen la plataforma Web de gestioacuten Se basa en el protocolo AMQP el
cual sigue el patroacuten publicadorsuscriptor como paradigma de comunicacioacuten indirecta
Estaacute involucrado en la entrega de mensajes entre los diferentes dispositivos embebidos con CHT y sus
respectivos servicios de gestioacuten en la plataforma Web de forma que los agentes que publican y consumen
eventos en el broacuteker no necesitan conocer al destinatario si no que el broacuteker es el que se encarga de publicar los
eventos para los destinatarios suscritos a eacutel En la siguiente figura se muestra la interfaz graacutefica de gestioacuten de
RabbitMQ [16]
Figura 31 Plataforma de Gestioacuten de RabbitMQ
Un broacuteker de eventos es un elemento del patroacuten PublicadorSuscriptor que recibe y mensajes de un conjunto de
elementos de red que quieren comunicarse ejecutan mecanismos de filtrado y permite la entrega correcta de los
diferentes mensajes a los consumidores correspondientes Por tanto el broacuteker de eventos permite ofrecer un
desacoplamiento entre emisores y receptores de la informacioacuten siendo este responsable de las tareas de
encaminamiento y reenvioacute de mensajes En conclusioacuten es responsable de coordinar la comunicacioacuten
proporcionando transparencia de acceso y localizacioacuten permitiendo la localizacioacuten de emisores y receptores
mediante un sistema de identificadores uacutenicos
Figura 32 Patroacuten PublicadorSuscriptor
62
413 Frontend
El Frontend de la plataforma Web estaacute implementado con Angular 6 HTML5 y CSS3 Su finalidad es ofrecer
una interfaz graacutefica al usuario final la cual permite mostrar el estado de los diferentes Zone Managers ademaacutes
de permitir el acceso a estos y gestionar el conjunto de puntos de acceso registrados en ellos de forma raacutepida e
intuitiva
Este microservicio recibe informacioacuten proporcionada por MoMap y los diferentes Zone Managers La
aplicacioacuten se sirve mediante un servidor Apache el cual proporciona una comunicacioacuten fiable con HTTPS
implementando una capa de transporte segura mediante el protocolo TLS
414 Zone Manager
Microservicio responsable de gestionar un conjunto de puntos de acceso CHT los cuales forman un despliegue
de red WiFi de Galgus para un cliente determinado Este microservicio estaacute formado por un servicio Web REST
implementado con Java Spring Framework desplegado en un servidor Jetty embebido y cuya persistencia se ha
implementado a traveacutes de Hybernate con el uso de Postgress SQL como gestor de bases de datos relacional
Un Zone Manager ofrece todas las tareas y acciones necesarias para configurar un conjunto de puntos de acceso
y consultar datos estadiacutesticos de usuarios conectados a dichos puntos de acceso entre otras Cabe destacar en
este punto la importancia que tiene el uso de FlatBuffers para garantizar la compatibilidad de datos enviados y
recibidos entre los puntos de acceso y el Zone Manager ambos implementados en tecnologiacuteas totalmente
diferentes
Figura 33 Ejemplo de Interfaz Graacutefica de un Zone Manager
63
415 MoMap
Dicho microservicio implementado en NodeJS gestiona y administra toda la infraestructura que conforma la
plataforma Web Establece y mantiene todas las conexiones y relaciones entre los diferentes puntos de acceso
con CHT y los Zone Managers (ZMB) que los gestiona
Ademaacutes este microservicio implementa una serie de maacutequinas de estado que permiten controlar el estado de
todos los Zone Managers y puntos de acceso CHT alertando sobre los eventos de error conexioacuten o desconexioacuten
en tiempo real a los usuarios finales a traveacutes del Frontend El soporte a la persistencia para dicho microservicio
se proporciona mediante MongoDB
Por tanto el microservicio MoMap actuacutea como proxy inverso HTTP2 Cuando un usuario intenta acceder a
traveacutes del Frontend de la plataforma Web puede gestionar y administrar un conjunto de Zone Managers o
administrar usuarios y asignar roles y permisos Tambieacuten se permite la creacioacuten eliminacioacuten y conexioacuten con un
Zone Manager redirigiendo las peticiones hacia el mismo
Cuando ocurre un evento de conexioacuten con un Zone Manager desde el microservicio MoMap se recupera y
enviacutea la informacioacuten necesaria para mostrar toda la informacioacuten correspondiente a ese Zone Manager en el
Frontend para el usuario final En la siguiente figura se muestra la interfaz graacutefica ofrecida por el servicio
MoMap a traveacutes del Frontend
Figura 34 Ejemplo de Interfaz Graacutefica de MoMap
64
416 Servidor de Licencias
El objetivo principal de este servicio es proporcionar una aplicacioacuten con una gestioacuten y control centralizado de
las licencias de todos los Puntos de Acceso desplegados con CHT Este servidor desplegado con Jetty de forma
embebida almacena el registro de un conjunto de Puntos de Acceso CHT para un conjunto de Clientes y
proyectos determinados Proporciona una API REST implementada con Java Spring Framework que permite
el registro de dichos dispositivos y la asignacioacuten de licencias CHT para habilitar los diferentes moacutedulos de dicha
aplicacioacuten embebida sobre los Puntos de Acceso Ademaacutes proporciona una interfaz Web de usuario
implementada con Angular 6 HTML5 y CSS3
En la siguiente figura se muestra un ejemplo de dicha interfaz graacutefica
Figura 35 Interfaz Graacutefica del Servidor de Licencias
4161 Zero-Touch Provisioning (ZTP)
En el contexto de la automatizacioacuten de redes WiFi el aprovisionamiento sin contacto es una caracteriacutestica
que permite que los puntos de acceso de una red se configuren automaacuteticamente evitando la intervencioacuten
humana para su configuracioacuten La configuracioacuten manual de dispositivos y conmutadores es costosa y
requiere lo que a menudo puede ser una gran cantidad de tiempo y esfuerzo dependiendo del tamantildeo de la
red [17]
Con el uso de sistemas automaacuteticos de aprovisionamiento y configuracioacuten se consigue reducir la carga de
trabajo y el esfuerzo que normalmente se requiere cuando se instalan y configuran nuevos dispositivos
Figura 36 Zero-Touch Provisioning (ZTP)
65
Haciendo uso de esta caracteriacutestica Galgus implementa en su infraestructura orientada a microservicios
un acceso directo de los Puntos de Acceso al servidor para que soliciten su licencia de CHT
automaacuteticamente de forma que cuando el usuario final vaya a instalar un Punto de Acceso CHT dicho
dispositivo obtendraacute su licencia de forma segura a traveacutes de la API REST del servidor de licencias siempre
y cuando esteacute registrado en el mismo y disponga de licencia sin necesidad de que el usuario intervenga en
dicho proceso
La comunicacioacuten entre los puntos de acceso y el resto de la infraestructura se realiza a traveacutes de un broacuteker
de eventos AMQP con su implementacioacuten en RabbitMQ Debido a esto cuando se crea y asigna licencia
a un dispositivo en el servidor de licencias dicho servidor crea un usuario en RabbitMQ de forma que el
punto de acceso en el momento que obtiene su licencia intentaraacute establecer conexioacuten con el broacuteker para
permitir el intercambio de eventos con los microservicios que lo gestionaraacuten mediante la plataforma CHT
Cloud Manager
Una vez el punto de acceso establece conexioacuten con el broacuteker de eventos este podraacute ser descubierto por el
Zone Manager que lo gestionaraacute El microservicio MoMap se encarga de establecer el descubrimiento de
los puntos de acceso comprobando si el punto de acceso estaacute registrado en el servidor de licencias con
licencia asignada y verificando que el punto de acceso estaacute operativo con conexioacuten a internet
42 Alcance y Objetivos de las pruebas sobre el sistema planteado
Una vez presentada y descrita toda la arquitectura de la plataforma Web ofrecida por Galgus se procederaacute a
detallar los principales objetivos del proceso de pruebas que se pretenderaacute conseguir sobre dicha aplicacioacuten Para
ello inicialmente se presentaraacute en queacute punto se encontraba el proceso de pruebas inicialmente
En este proyecto se ha centrado la atencioacuten en el conjunto de pruebas funcionales realizadas a la aplicacioacuten maacutes
concretamente las pruebas a nivel de aceptacioacuten
Dentro de las pruebas a nivel de aceptacioacuten los ingenieros de prueba hasta ahora habiacutean disentildeado un plan de
pruebas de aceptacioacuten o tests End-to-End los cuales se ejecutaban verificaban y validaban manualmente por
los ingenieros de QA Dicho plan de pruebas estaacute formado por una bateriacutea de casos de prueba a realizar sobre
las diferentes funcionalidades del sistema A continuacioacuten se muestra un fragmento de dicho plan de pruebas
Figura 37 Test Plan de CHT Cloud Manager
Como puede observarse en la figura anterior dicho plan de pruebas contiene un conjunto de casos de prueba
cada uno de ellos con un identificador uacutenico una descripcioacuten algunas especificaciones o detalles necesarios un
indicador de eacutexito o fallo y finalmente la descripcioacuten de los resultados obtenidos
Ademaacutes en dicho test plan se incluye una cabecera y una leyenda para clasificar los distintos resultados
obtenidos en la ejecucioacuten de las pruebas registrar algunos datos de relevancia y tener archivado dicho plan de
pruebas con las versiones de los diferentes microservicios que componen la plataforma Web
66
Figura 38 Leyenda del Test Plan
Figura 39 Control de Versiones del Test Plan
Una vez presentado el estado actual del proceso de pruebas a nivel de aceptacioacuten el nuevo equipo encargado de
evaluar la calidad de la plataforma Web planteoacute la oportunidad de automatizar dicho plan de pruebas Por tanto
el principal objetivo de este proyecto ha sido el de automatizar las actividades de ejecucioacuten y generacioacuten de
reportes de las pruebas de aceptacioacuten automatizadas sobre la aplicacioacuten
Sin embargo las actividades de planificacioacuten disentildeo e implementacioacuten de los diferentes casos de prueba se
realizaraacuten de forma manual haciendo uso de un conjunto de tecnologiacuteas que se usaraacuten para desarrollar la
automatizacioacuten de dichas pruebas Dichas tecnologiacuteas principalmente son Robot Framework Selenium y
Python las cuales se detallaraacuten maacutes adelante
En este punto es donde podriacutea entrar en juego la aplicacioacuten de Model-Based-Testing (MBT) detallado en la
seccioacuten 2 de este proyecto como teacutecnica que permite la abstraccioacuten de la actividad de implementacioacuten del plan
de pruebas mejorando el proceso de pruebas e independizando este de las actividades de desarrollo
En este proyecto queda fuera del alcance la aplicacioacuten de dicha teacutecnica debido a la necesidad de disponer de un
disentildeo completo y detallado de la plataforma Web para permitir la generacioacuten de los casos de prueba abstractos
y su posterior generacioacuten automaacutetica de los casos de prueba ejecutables Es de intereacutes destacar que a lo largo
del desarrollo del proyecto han ido surgiendo otros objetivos de intereacutes para mejorar el proceso de pruebas los
cuales permiten agilizar dicho proceso y ampliar su alcance
Entre estos objetivos se encuentran la generacioacuten automaacutetica de documentacioacuten del plan de pruebas la
implementacioacuten de un entorno de UAT (User Acceptance Testing) con Docker la integracioacuten de las pruebas a
nivel de aceptacioacuten en el proceso de integracioacuten continua del proyecto o la creacioacuten de un Docker que permita
ejecutar todo el plan de pruebas Todos estos objetivos se iraacuten detallando maacutes adelante
67
43 Arquitectura de la Solucioacuten Entorno de UAT para el proceso de pruebas (User Acceptance Test)
Hasta ahora dentro del proceso de desarrollo de la plataforma Web existiacutean las siguientes fases etapas o
entornos Desarrollo Preproduccioacuten y Produccioacuten
Bajo este contexto las actividades del proceso de pruebas eran realizadas sobre la fase de Preproduccioacuten Esto
provocaba una dependencia directa del cierre de la mayoriacutea de actividades de desarrollo para el despliegue en la
fase de Preproduccioacuten Como consecuencia la fase de pruebas a nivel de aceptacioacuten se podriacutea ver perjudicada
por esta metodologiacutea provocando en muchas ocasiones el retraso en el feedback necesario por los ingenieros de
desarrollo de los reportes e informes generados al ejecutar las pruebas de aceptacioacuten Para mejorar este proceso
se ha disentildeado un nuevo entorno de UAT en el proceso de desarrollo que permita disminuir la dependencia del
proceso de pruebas y desarrollo La inclusioacuten de este nuevo entorno ha sido posible gracias a la mejora del
proceso de integracioacuten continuacutea implementado en el desarrollo de la plataforma
Dentro de este proceso de integracioacuten continua se realiza la generacioacuten automaacutetica de los Docker que contienen
los diferentes microservicios de la plataforma Web en cualquier etapa del proceso de desarrollo Ademaacutes dentro
del proceso de integracioacuten continua se ha automatizado por parte de los ingenieros de desarrollo la ejecucioacuten
de pruebas unitarias y de integracioacuten que garantizan una miacutenima garantiacutea de estabilidad funcional de la
plataforma necesaria para el proceso de pruebas Partiendo de este punto el equipo de calidad ha disentildeado un
entorno de UAT con Docker el cual se muestra de forma graacutefica en la siguiente figura
Figura 40 Entorno de UAT con Docker (Anexo B)
68
69
5 TECNOLOGIacuteAS Y HERRAMIENTAS USADAS
na vez descrito el sistema bajo pruebas y presentada la arquitectura de la solucioacuten para el escenario de
pruebas con Docker se expondraacute a continuacioacuten el conjunto de tecnologiacuteas y herramientas usadas para
llevar a cabo el desarrollo de las pruebas automatizadas de aceptacioacuten o pruebas End-to-End Con este
conjunto de herramientas se pretende conseguir la implementacioacuten de los diferentes scripts de pruebas que
automaticen las acciones e interacciones necesarias con la plataforma Web CHT Cloud Manager como si de
una persona se tratase
51 Selenium
Selenium es una herramienta de coacutedigo abierto utilizada para la automatizacioacuten de pruebas en navegadores web
Dicha herramienta posee una enorme popularidad en el mundo de las pruebas de software debido a que
Presenta compatibilidad con diferentes lenguajes de programacioacuten para la implementacioacuten de scripts de
pruebas ofreciendo libreriacuteas en Java Python C PHP Ruby Perl y Net
Es multiplataforma permitiendo el lanzamiento de los scripts de pruebas en diversos sistemas
operativos como Windows Mac o Linux y en diferentes navegadores como Mozilla Firefox Internet
Explorer Google Chrome Safari y Opera
Soporta la integracioacuten con otras herramientas como TestNG o JUnit
Permite la integracioacuten continua con Maven Jenkins gitlab CICD y Docker
Sin embargo presenta una serie de inconvenientes que se deben mencionar
bull Solo permite probar aplicaciones Web
bull No hay soporte garantizado desde Selenium Muchas de las soluciones a problemas de la herramienta
han sido generadas por la comunidad
bull No es posible realizar pruebas en imaacutegenes Para ello es necesaria la integracioacuten con otras herramientas
bull No tiene capacidad nativa para generar informes o reportes de los resultados de las pruebas Para ello
se requiere el uso de un framework como puede ser el Robot Framework
Centrando la atencioacuten en el enfoque de dicho proyecto se haraacute uso de la libreriacutea Selenium para Python y la
facilidad de Robot Framework tanto para abstraer la posible complejidad antildeadida del lenguaje de programacioacuten
usado para la implementacioacuten de los scripts de prueba como para permitir la generacioacuten automaacutetica de informes
y reportes de resultados
Realmente Selenium estaacute formado por un conjunto de herramientas las cuales son Selenium RC Selenium
IDE Selenium Grid y Selenium Webdriver Dichas herramientas permiten desde la realizacioacuten de pruebas en
maacutequinas remotas a la ejecucioacuten de pruebas en diferentes maacutequinas con diferentes navegadores cada una
Con el lanzamiento de Selenium 2 en 2008 se antildeadieron nuevas funcionalidades de Selenium RC y Webdriver
en una misma herramienta aunque es frecuente mantener la nomenclatura de WebDriver a la hora de referirse
a la misma En este proyecto se centraraacute la atencioacuten en la herramienta WebDriver de Selenium
U
El disentildeo es el alma de todo lo creado por el hombre
Steve Jobs
70
52 Selenium WebDriver
Esta herramienta de Selenium ofrece una interfaz para ejecutar los casos de prueba descritos en los scripts
de prueba A traveacutes de esta API WebDriver se comunica directamente con el controlador del navegador
donde corre la aplicacioacuten Para ello seraacute necesario el uso de controladores para los diferentes navegadores
Web desde los que se validan las pruebas automaacuteticas
Todas las implementaciones de WebDriver que se comunican con el navegador usan un protocolo punto a
punto comuacuten Este protocolo define un servicio RESTfull usando JSON sobre HTTP Cada operacioacuten
realizada por WebDriver se mapea en un meacutetodo HTTP que se comunica con el navegador Las respuestas
a dichas operaciones seraacuten devueltas en mensajes HTTP de respuesta
Existen diversas implementaciones de Selenium para diferentes entornos tal y como se muestra en la
siguiente figura
Figura 41 Implementaciones disponibles de Selenium y Navegadores Web Compatibles
Para la ejecucioacuten de las pruebas implementadas en este proyecto se ha hecho uso de los controladores Gecko
Driver y Chromedriver para los navegadores Web Firefox y Google Chrome
521 Elementos del Navegador
Una vez tenemos una viacutea de comunicacioacuten con el navegador planteamos la pregunta iquesty coacutemo le indico al
navegador con queacute componente quiero interactuar
La cantidad de componentes que existen es muy amplia cajas de texto botones imaacutegenes hiperviacutenculos
botones de radio check boxes aacutereas de texto mensajes de error desplegables tablas frames etc Todos
estos elementos tienen una serie de propiedades que pueden ser uacutenicas o no en toda la paacutegina Por ejemplo
un identificador (ID) debe distinguir de manera uniacutevoca a un elemento Este identificador es lo que se
denomina un localizador Existen 8 tipos distintos de localizadores diferentes
bull Id Name Class Name Tag Name Link Text Partial Link Text CSS Xpath
71
Se podraacuten implementar las interacciones con el navegador mediante la llamada a un meacutetodo (accioacuten) que
se aplicaraacute sobre el elemento que nosotros indiquemos A continuacioacuten se muestra el diagrama de bloques
y la implementacioacuten de un ejemplo simple del inicio de sesioacuten usando Python y la libreriacutea de Selenium
Figura 42 Coacutedigo de ejemplo con Python y Selenium
La implementacioacuten anterior permite abrir un navegador Web Chrome en pantalla completa y acceder a la
plataforma Web Galgus CHT Cloud Manager Una vez ha sido posible el acceso y la paacutegina Web estaacute
disponible se realiza el inicio de sesioacuten en la plataforma con las credenciales correspondientes esperando que
dicho inicio de sesioacuten se haya realizado con eacutexito Finalmente se cierran todas las instancias de navegadores
Web abiertas por Selenium en la automatizacioacuten de dicha prueba de concepto
72
53 Robot Framework (RF)
Para la automatizacioacuten del testeo de la aplicacioacuten se ha hecho uso de este framework como herramienta
para dicha finalidad Robot Framework es un framework geneacuterico de automatizacioacuten de pruebas de coacutedigo
abierto desarrolla do por Pekka Klaumlrck en el antildeo 2005
Este framework sigue el enfoque Keyword-Driven Testing y es un candidato idoacuteneo debido a su alto nivel
de abstraccioacuten para pruebas de aceptacioacuten y desarrollo guiado por pruebas de aceptacioacuten o Acceptance
Test-Driven Development (ATDD) Las capacidades de pruebas pueden ser ampliadas con nuevas libreriacuteas
implementadas tanto en Python como en Java y los usuarios pueden crear nuevas keywords a partir de las
existentes usando la misma sintaxis que para los casos de prueba [18]
Robot Framework es independiente del sistema operativo y de la aplicacioacuten El nuacutecleo del framework estaacute
implementado en Python soportando tanto Python 2 como Python 3
Se ha decidido utilizar este framework por la disponibilidad de un amplio conjunto de libreriacuteas de propoacutesito
general y la integracioacuten con libreriacuteas externas como Selenium2Library Entre otras prestaciones permite el
uso de variables que aportan mayor flexibilidad a la hora de disentildear y controlar los scripts de prueba
permite el etiquetado para poder identificar y ejecutar los casos de prueba por separado proporciona una
faacutecil integracioacuten con Jenkins y Maven y proporciona un sistema de reporte de informes de resultados
detallados y de faacutecil lectura Ademaacutes hay que destacar la faacutecil abstraccioacuten que ofrece al poder utlizar
keywords de alto nivel permitiendo el uso del estilo de representacioacuten Given-When-Then para los casos
de prueba A continuacioacuten se describe dicho estilo de representacioacuten
531 Estilo de representacioacuten Given-When-Then
Dicho estilo ofrecido por Robot Framework es uno de los puntos fuertes de este framework Esta caracteriacutestica
permite el uso del siguiente estilo de representacioacuten para los casos de prueba
Figura 43 Estilo de representacioacuten Given-When-Then
bull Given Define las precondiciones necesarias para llevar a cabo la accioacuten asiacute como el actor de la
misma
bull When Accioacuten llevada a cabo por el actor definido en la claacuteusula Given
bull Then Es el comportamiento esperado o la salida del sistema esperada ante una entrada
determinada
bull And Claacuteusula auxiliar que se usa de forma combinada con las anteriores
73
Como ejemplo de aplicacioacuten de este estilo de representacioacuten supongamos que tenemos unos requisitos de
aceptacioacuten establecidos en un documento entre los que se encuentran el inicio y cierre de sesioacuten mediante
usuario y contrasentildea a la plataforma Galgus CHT Cloud Manager En la siguiente tabla se muestran los
criterios de aceptacioacuten definidos en el documento de requisitos para dicha funcionalidad
1 Un usuario no identificado puede iniciar sesioacuten desde la vista principal de la plataforma Web
2 Un usuario no identificado debe insertar un usuario y contrasentildea vaacutelidos para el inicio de sesioacuten
A continuacioacuten se muestra coacutemo se llevariacutea a cabo la implementacioacuten de los scripts de pruebas abstractos
asociados a las especificaciones anteriores haciendo uso del estilo de representacioacuten Given-When-Then
Es complicado implementar todos los casos de prueba posibles principalmente cuando el requisito de
aceptacioacuten requiere de una funcionalidad compleja En este caso se muestran tres casos de prueba
abstractos los cuales han sido implementados en el proyecto para validar el inicio y cierre de sesioacuten
Caso de Prueba 1 Inicio de Sesioacuten en Galgus CHT Cloud Manager
Claacuteusula Keyword
Given Navegacioacuten a la paacutegina principal de Galgus CHT Cloud Manager
When Insertar nombre de usuario vaacutelido
And Insertar contrasentildea vaacutelida
Then Iniciar sesioacuten con eacutexito
Caso de Prueba 2 Intento de Inicio de sesioacuten con usuario no vaacutelido
Claacuteusula Keyword
Given Navegacioacuten a la paacutegina principal de Galgus CHT Cloud Manager
When Insertar nombre de usuario invaacutelido
And Insertar contrasentildea vaacutelida
Then No es posible el inicio de sesioacuten Se muestra mensaje de error
Caso de Prueba 3 Intento de Inicio de sesioacuten con contrasentildea no vaacutelida
Claacuteusula Keyword
Given Navegacioacuten a la paacutegina principal de Galgus CHT Cloud Manager
When Insertar nombre de usuario vaacutelido
And Insertar contrasentildea invaacutelida
Then No es posible el inicio de sesioacuten Se muestra mensaje de error
74
En la siguiente figura se muestra la implementacioacuten de dichas pruebas con Robot Framework donde cada
Keyword implementada permite la abstraccioacuten de toda la funcionalidad necesaria para realizar las pruebas
Figura 44 Implementacioacuten de Pruebas en para el inicio de sesioacuten de CHT Cloud Manager
75
532 Reportes
A continuacioacuten se muestra un ejemplo de los reportes obtenidos tras la ejecucioacuten del primer caso de prueba de
los anteriores donde pueden identificarse las diversas keywords necesarias para implementar cada caso de
prueba asiacute como otras adicionales que ayudan a crear el contexto (precondiciones) Tambieacuten se incluyen
estadiacutesticas sobre el tiempo de ejecucioacuten nuacutemero de tests total nuacutemero de tests que han fallado o que han pasado
con eacutexito [18]
Figura 45 Ejemplo de reporte de pruebas automatizadas con Robot Framework
76
533 Libreriacuteas
Robot Framework permite el uso de Selenium mediante la libreriacutea de pruebas Web SeleniumLibrary Dicha
libreriacutea es compatible con las versiones de Selenium 2536 y sucesivas y con Python 27 y Python 3 Ademaacutes
del inteacuterprete por defecto de Python esta libreriacutea funciona tambieacuten con PyPy y Jython [18]
Esta libreriacutea estaacute compuesta entre otras muchas por una serie de archivos de Python (py) que implementan
las clases que contienen las diversas keywords que pueden ser usadas en nuestro framework La estructura de
estos archivos se presenta en la siguiente tabla
Archivo de Clase Funcioacuten
Alertpy Interacciones con mensajes de alerta
Browsermanagementpy Apertura cierre y cambio de navegadores
Cookiepy Manipulacioacuten de cookies del navegador
Elementpy Interaccioacuten con elementos y sus atributos
Formelementpy Interaccioacuten con elementos en formularios
Framespy Manejo de frames y su contenido
Javascriptpy Facilidades para inyectar coacutedigo javascript
Runonfailurepy Uso de funcionalidades en caso de fallo
Screenshotpy Manejo de capturas de pantalla
Selectelementpy Manejo de elementos en listas
Tableelementpy Manejo de elementos en tablas
Waitingpy Manejo de temporizadores de espera para
transiciones en una paacutegina
Webdrivertoolspy Interaccioacuten directa con el controlador del navegador
Windowpy Manejo de ventanas del navegador
Estas libreriacuteas fueron desarrolladas en sus oriacutegenes por el ingeniero finlandeacutes Tatu Aalto y posteriormente
mejoradas por toda la comunidad de expertos en automatizacioacuten de pruebas Sin embargo Robot Framework
mediante el uso de Python con Selenium permite la implementacioacuten de libreriacuteas propias o funcionalidades
desarrolladas en Python que pueden ser integradas en Robot Framework En este proyecto se hace uso de Python
con Selenium para desarrollar algunas funcionalidades avanzadas que permiten probar ciertos criterios de la
aplicacioacuten muy especiacuteficos y avanzados de la plataforma Web para los cuales las libreriacuteas ofrecidas por Robot
Framework no proporcionan la funcionalidad requerida
Ademaacutes se ha hecho uso de otras libreriacuteas como BuiltIn para el uso de bucles condicionales y otras keywords
String y Collections para el tratamiento de cadenas de caracteres y colecciones de datos SSHLibrary para usar
un cliente ssh Process para la ejecucioacuten de subprocesos haciendo uso la libreriacutea subprocess de python y
OperatingSystem para realizar algunas tareas sobre el sistema operativo
77
534 Documentacioacuten
La documentacioacuten de los diferentes casos de pruebas implementados con Robot Framework es muy redundante
y una tarea la cual seriacutea deseable de poder automatizar Dicho framework ofrece esta posibilidad a traveacutes de dos
herramientas para crear documentacioacuten basada en las pruebas y libreriacuteas implementadas para dichas pruebas
Libdoc y Testdoc [18]
5341 Libdoc
Libdoc es una herramienta ofrecida por Robot Framework para construir documentacioacuten sobre las keywords
implementadas para los casos de prueba Dicha documentacioacuten es generada en formato HTML y XML
Se puede crear documentacioacuten para bibliotecas implementadas con Python o Java y para las propias libreriacuteas
implementadas con Robot Framework A continuacioacuten se muestra un ejemplo de la documentacioacuten generada
para la libreriacutea implementada para los casos de prueba de inicio y cierre de sesioacuten de Galgus CHT Cloud
Manager
Figura 46 Ejemplo de documentacioacuten generada con Libdoc
5342 Testdoc
Testdoc es una herramienta para generar documentacioacuten de alto nivel basada en los casos de prueba de Robot
Framework Dicha documentacioacuten es generada en formato HTML e incluye el nombre la documentacioacuten y
otros metadatos de cada conjunto de pruebas y casos de prueba asiacute como las keywords de alto nivel y sus
argumentos
A continuacioacuten se muestra un ejemplo de la documentacioacuten generada para el conjunto de casos de prueba que
validan el inicio y cierre de sesioacuten de Galgus CHT Cloud Manager
Figura 47 Ejemplo de documentacioacuten generada con Testdoc
78
54 Pycharm (IDE)
Esta herramienta proporciona un entorno de desarrollo integrado (IDE) el cual ha sido usado para programar en
lenguaje Python por lo que es idoacuteneo tambieacuten para el desarrollo de pruebas con Robot Framework Esta
desarrollado por la empresa JetBrains Ademaacutes proporciona entre otras muchas herramientas el anaacutelisis de
coacutedigo un depurador graacutefico integracioacuten con sistemas de control de versiones y es multiplataforma
55 GitGitlab
551 Git
Git es un software de control de versiones disentildeado por Linux Torvalds pensando en la eficiencia y la
confiabilidad del mantenimiento de versiones de aplicaciones cuando eacutestas tienen un gran nuacutemero de archivos
de coacutedigo fuente Al principio Git se pensoacute como un motor de bajo nivel sobre el cual otros pudieran escribir la
interfaz de usuario como Cogito o StGIT Sin embargo Git se ha convertido desde entonces en un sistema de
control de versiones con funcionalidad plena Hay algunos proyectos de mucha relevancia que ya usan Git en
particular el grupo de programacioacuten del nuacutecleo Linux Ademaacutes cabe destacar que se ha hecho uso de
GitKraken como interfaz graacutefica de git para llevar a cabo el control de versiones de una forma maacutes intuitiva
552 Gitlab
Gitlab es un servicio Web de control de versiones y desarrollo de software colaborativo basado en Git Fue
implementado por los desarrolladores ucranianos Dimitry Zaporozhets y Valey Sizov en el lenguaje de
programacioacuten Ruby Este proyecto cuenta con un equipo de 150 miembros y maacutes de 1400 usuarios y es usado
por empresas como la NASA el CERN IBM o Sony [19]
Ademaacutes de gestor de repositorios tambieacuten ofrece la posibilidad de alojar documentacioacuten y un sistema de
seguimiento de errores Tambieacuten es de gran importancia destacar que esta herramienta proporciona su propia
herramienta de Integracioacuten Continua sin necesidad de usar otra herramienta externa
Se ha hecho uso de estas herramientas para tener un control de versiones sobre nuestro proyecto y una gestioacuten
centralizada de todos los repositorios de la empresa de forma que asiacute podemos tener un control de versiones de
todos los cambios realizados en el coacutedigo con posibilidad de contrastarlos con versiones anteriores y recuperar
dichos cambios Ademaacutes se hace uso tambieacuten de gitlab CICD para implementar procesos de Integracioacuten
continua sobre los diferentes proyectos En el caso particular de este proyecto para generar la documentacioacuten
de los casos de test y libreriacuteas y para generar un Docker con toda la bateriacutea de pruebas y dependencias necesarias
para lanzarlas
56 Redmine
Redmine es una herramienta para la gestioacuten de proyectos que ofrece un conjunto de funcionalidades que
permiten a los usuarios de diferentes proyectos realizar el seguimiento y organizacioacuten de los mismos Incluye
un sistema de seguimiento de incidentes Otras herramientas que incluye son un calendario de actividades
diagramas de Gantt una wiki para almacenar documentacioacuten control del flujo de trabajo basado en roles
integracioacuten con correo electroacutenico etc
Esta herramienta se usa para la gestioacuten del proyecto Galgus CHT Cloud Manager donde se integra como
subproyecto la automatizacioacuten del proceso de pruebas para la plataforma Web desarrollada
A continuacioacuten se muestra un ejemplo del flujo de trabajo implantado en la metodologiacutea de trabajo dentro del
proyecto donde cada historia puede contener un conjunto de tareas las cuales pueden pasar por diferentes
estados hasta ser completadas por el desarrollador o el ingeniero de pruebas
79
Figura 48 Ejemplo de Flujo de Trabajo en Redmine para Galgus CHT Cloud Manager
561 Uso en el Proyecto Galgus CHT Cloud Manager (Metodologiacutea Scrum)
Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas praacutecticas para trabajar
colaborativamente en equipo y obtener el mejor resultado posible de un proyecto Estas praacutecticas se apoyan
unas a otras y su seleccioacuten tiene origen en un estudio de la manera de trabajar de equipos altamente productivos
Esta metodologiacutea divide el trabajo en una lista de pequentildeas funcionalidades ordenadas por prioridad y estimadas
en esfuerzo Estas pequentildeas tareas son abordadas en iteraciones cortas de longitud fija denominadas Sprints de
1 a 4 semanas (en este caso se ha optado por iteraciones de 3 o 4 semanas) obteniendo coacutedigo potencialmente
entregable siendo demostrado al final de cada iteracioacuten Una vez decidido por el equipo de gestioacuten de proyectos
el alcance y conjunto de actividades a realizar dentro del sprint se transmite al resto del equipo que forma parte
del proyecto procediendo a la asignacioacuten de tareas mediante Redmine como herramienta de gestioacuten usada
Durante el sprint se va realizando un seguimiento perioacutedico del estado del proyecto y de la situacioacuten de cada
integrante mediante una actividad previa diaria de unos 15 minutos para situar el punto de partida de trabajo
diario que seriacutean reuniones diarias de apenas 15 minutos denominadas ldquoDaylisrdquo
Figura 49 Esquema Graacutefico de Metodologiacutea Scrum
80
La planificacioacuten que se pretende seguir en cada sprint es la siguiente
1 Semana 1 y 2 Realizacioacuten de tareas por parte del equipo de desarrollo incluyendo en estas tareas
nuevos desarrollos modificacioacuten de funcionalidades y verificacioacuten de las mismas mediante pruebas
unitarias y de integracioacuten
2 Semana 3 Realizacioacuten de pruebas de aceptacioacuten manuales por parte del equipo de pruebas y posterior
automatizacioacuten de dichas pruebas Para ello se usaraacute el entorno de UAT como escenario de pruebas
Ademaacutes el equipo de desarrollo iraacute corrigiendo todos aquellos errores o defectos encontrados
3 Semana 4 El jefe de proyecto realiza la fusioacuten de todos los desarrollos y actualiza las versiones en el
entorno de Preproduccioacuten incluyendo todas las actividades realizadas y validadas por el equipo de
desarrollo y de pruebas El equipo de pruebas realizaraacute la ejecucioacuten de todas las pruebas End-to-End
sobre el entorno de Preproduccioacuten para verificar y validar la nueva versioacuten que incluye todas las
funcionalidades Estas pruebas son denominadas pruebas de regresioacuten las cuales verifican que los
nuevos desarrollos no han provocado defectos o errores sobre funcionalidades que hasta ahora habiacutean
funcionado correctamente Finalmente el jefe de proyecto realiza el despliegue en produccioacuten
81
82
6 EXPERIMENTOS
na vez descrito el sistema bajo pruebas el proceso de pruebas y las herramientas que se usaraacuten para
automatizar las pruebas de aceptacioacuten sobre la plataforma de gestioacuten Galgus CHT Cloud Manager
solo queda presentar la forma en la que se ha puesto en praacutectica y el proceso seguido paso a paso
Dado que el objetivo es conseguir una bateriacutea de casos de pruebas End-to-End automatizadas se implementaraacuten
dichos casos de prueba de forma que permitan detectar el incorrecto funcionamiento de cada funcionalidad con
la mayor rapidez posible cubriendo los principales escenarios donde puedan surgir los mayores errores Por
tanto dichos casos de prueba seraacuten elegidos en base al riesgo que puedan introducir
Estos casos de prueba seraacuten definidos mediante un conjunto de criterios de aceptacioacuten descritos a traveacutes de
diagramas de flujo y agrupados seguacuten la funcionalidad de la aplicacioacuten que abarquen las cuales son
1 Vista de Gestioacuten Principal (Coud Tab) Esta seccioacuten de la Web estaacute destinada a la administracioacuten de
usuarios administracioacuten de los diferentes Zone Managers y finalmente incluye un Mapa con la
ubicacioacuten de cada Zone Manager
2 Vista de Configuracioacuten (Configuration Tab) En esta pestantildea se ofrece la gestioacuten de grupos de puntos
de acceso gestioacuten de backups y restauracioacuten gestioacuten de firmwares zonas CHT etc
3 Vista de Red (Network Tab) La pestantildea de red engloba toda la configuracioacuten de red de los puntos de
acceso siendo esta la pestantildea con mayor funcionalidad complejidad y por ello potencial de riesgo de
errores de la plataforma Web
Figura 50 Logo de Galgus CHT Cloud Manager
U
La uacutenica parte donde el ldquoeacutexitordquo aparece antes que el trabajo es en el diccionario
Vidal Sasoon
83
61 Estructura del Proyecto
La clasificacioacuten funcional anterior seraacute tomada de la misma forma para organizar la estructura del proyecto de
pruebas automatizadas con Robot Framework para un desarrollo ordenado y loacutegico de todo el conjunto de casos
de prueba A continuacioacuten se muestra un ejemplo de la estructura del proyecto el cual se encuentra en desarrollo
y continua mejora
Figura 51 Estructura del Proyecto
Para una mayor modularidad y limpieza en el desarrollo de los casos de Test se han centralizado todos los
localizadores en un archivo llamado ldquoSelectorpyrdquo En la siguiente figura se muestra un fragmento de dicho
fichero
Figura 52 Fragmento del fichero ldquoSelectorpyrdquo
A la hora de obtener los localizadores de los elementos que seraacuten comprobados o usados en los scripts de pruebas
se han usado las herramientas de desarrollador que incluye Google Chrome Para ello basta con navegar a la
paacutegina de la plataforma Web en cualquier navegador y pulsar la tecla F12 Esto mostraraacute las herramientas de
desarrolladores donde encontramos una pestantildea llamada ldquoElementosrdquo donde se puede inspeccionar el
documento ldquoHTMLrdquo de la paacutegina Una vez abierta dicha herramienta seraacute sencillo obtener propiedades de los
diversos elementos que nos permitiraacuten hacer referencia a los mismos en nuestro script de pruebas
Los ldquoXpathrdquo absolutos seraacuten lo usados praacutecticamente en toda la Suite de pruebas El beneficio de los
identificadores uacutenicos es que permiten seleccionar elementos sin que sea necesario hacer referencia a su posicioacuten
dentro del documento HTML Esto evita cualquier problema en caso de que las rutas de un elemento dentro del
citado documento cambien debido a mejoras o despistes por parte de los desarrolladores En cambio usar
selectores basados en la ruta del elemento dentro del documento HTML puede propiciar falsos fallos en el
escenario anterior debido a que no puedan encontrarse en la Web a pesar de que realmente sigan estando
presentes y totalmente funcionales
Por otro lado se han agrupado todas aquellas ldquokeywordsrdquo que puedan ser usadas por otras secciones en la
implementacioacuten de los casos de prueba mediante ficheros nombrados como ldquotab_common_keywords robotrdquo
84
Siguiendo esta jerarquiacutea se ha incluido un fichero llamado ldquoCommon_Keywordsrobotrdquo general en el que se
incluyen las principales ldquokeywordsrdquo que pueden ser usadas en todo el proyecto A continuacioacuten se muestra un
fragmento de este fichero
Figura 53 Fragmento del fichero ldquoCommon_Keywordsrobotrdquo
Tambieacuten se incluye el fichero ldquoConfigurationrobotrdquo para agrupar definiciones de variables que seraacuten
usadas en todo el proyecto ademaacutes de realizar la inclusioacuten de las libreriacuteas a usar Se muestra otra figura
con un fragmento del fichero ldquoConfigurationrobotrdquo
Figura 54 Fragmento del fichero de Configuracioacuten de pruebas ldquoConfigurationrobotrdquo
85
A continuacioacuten se muestra un diagrama que muestra las dependencias de los diferentes archivos y la estructura
seguida por el proyecto
Figura 55 Diagrama de paquetes del proyecto de pruebas
Tras introducir la estructura del proyecto y las diferentes funcionalidades de la plataforma Web Galgus CHT
Cloud Manager a continuacioacuten se mostraraacuten algunos criterios de aceptacioacuten de cada funcionalidad a probar
con diagramas de flujo y scripts de pruebas haciendo uso del estilo de representacioacuten Given-When-Then
Ademaacutes se mostraraacuten algunos detalles de implementacioacuten sobre las pruebas Por otro lado la ejecucioacuten de los
casos de prueba de ejemplo y el reporterevisioacuten de resultados se incluiraacute en la seccioacuten de Anexos
Cada una de las siguientes subsecciones dentro de cada funcionalidad principal de la aplicacioacuten o vista principal
tendraacute su correspondiente Suite de pruebas con un conjunto de casos de Test Todas estas Suites seguiraacuten la
siguiente estructura comuacuten para los casos de Test
Figura 56 Estructura de una Suite de Pruebas
86
Todas las Suites comienzan con una seccioacuten de documentacioacuten para describir el contenido de las pruebas de forma geneacuterica y varias secciones para importar los recursos necesarios para las pruebas (Resource)
Las secciones ldquoSuite Setuprdquo y ldquoSuite Teardownrdquo permiten la ejecucioacuten automaacutetica antes y despueacutes de la bateriacutea de pruebas y las secciones ldquoTest Setuprdquo y ldquoTest Teardownrdquo permiten la ejecucioacuten automaacutetica antes y despueacutes de cada caso de prueba
Un uso tiacutepico de ldquoSuite Setuprdquo es abrir un navegador Web y comprobar la disponibilidad de la Web a probar mientras que el cierre del navegador se realiza con ldquoSuite Teardownrdquo De este modo sea cual sea el resultado de la ejecucioacuten no se quedaraacuten abiertas ventanas gastando recursos de la maacutequina
Por otro lado el uso por defecto de ldquoTest Setuprdquo en este proyecto ha sido el inicio de sesioacuten en la Web CHT Cloud Manager mientras que ldquoTest Teardownrdquo ha sido usado para cerrar tambieacuten el navegador Web Sin embargo la mayoriacutea de las pruebas implementadas necesitan una serie de precondiciones previas a la ejecucioacuten del Test y un conjunto de postcondiciones necesarias para no provocar inconsistencias entre la ejecucioacuten de diferentes pruebas Por este motivo se ha hecho uso de las etiquetas [Setup] y [Teardown] para modificar la ejecucioacuten por defecto de ldquoTest Setuprdquo y ldquoTest Teardownrdquo en cada caso de prueba cuando sea necesario
Cabe destacar que la loacutegica implementada dentro de estas claacuteusulas no requiere que sea validada puesto que su uacutenico objetivo es preparar el entorno de pruebas para ejecutar una prueba sin que esta falle por causas ajenas al aacutembito y objetivo de la prueba evitando de esta forma los falsos positivos Por este motivo se hace uso de la Keyword ldquoRun Keyword And Ignore Errorrdquo ofrecida por la libreriacutea ldquoBuiltInrdquo para ignorar los errores en la ejecucioacuten de [Setup] y [Teardown] En la siguiente figura se muestra un ejemplo de dicha teacutecnica
Figura 57 Ejemplo de ldquoTest Setuprdquo personalizado para un caso de prueba
Finalmente la implementacioacuten de las ldquokeywordsrdquo usadas mediante la nomenclatura Given-When-Then seraacuten agrupadas en el correspondiente fichero ldquoTab_common_keywordsrobotrdquo para conseguir una abstraccioacuten de la loacutegica necesaria para la automatizacioacuten de las pruebas En las pruebas seleccionadas para describir en esta seccioacuten se detallaraacute la implementacioacuten de algunas keywords que se usaraacuten
87
62 Vista de Gestioacuten Principal (Cloud Tab)
En la siguiente figura se muestra la vista de Gestioacuten Principal de Galgus CHT Cloud Manager
Figura 58 Vista de Gestioacuten Principal (Cloud Tab)
Sobre esta vista se han automatizado un conjunto de Suites de pruebas que validan toda la funcionalidad
contenida en las pestantildeas MAP List of Zone Managers y Administration ademaacutes de toda la loacutegica ofrecida para
gestionar un conjunto de fabricantes
621 Administration
Comenzando con la pestantildea de administracioacuten se puede observar la existencia de cuatro flujos de navegacioacuten
principales en la siguiente figura
Figura 59 Pestantildea ldquoAdministrationrdquo
Una vez conocida la vista de administracioacuten de la Web se han realizado un total de 22 casos de prueba de los
cuales detallaremos el caso de prueba identificado con la etiqueta U0027
6211 Criterios de Aceptacioacuten
La pestantildea de administracioacuten permite la gestioacuten de los usuarios y roles que tienen acceso a la plataforma Web
ademaacutes de la configuracioacuten de los detalles de los fabricantes seleccionados A continuacioacuten se detallan los
criterios de aceptacioacuten del caso de prueba seleccionado
U0027 Un usuario con permisos de Super Usuario puede editar la informacioacuten de un fabricante
1 Un usuario con permisos de Super Usuario puede ver y acceder a la pestantildea de administracioacuten
2 Un usuario con permisos de Super Usuario puede editar la informacioacuten de un fabricante correctamente
88
6212 Diagramas de Flujo
A continuacioacuten se muestran los diagramas de flujo implementados para los dos casos de prueba analizados
Figura 60 Diagramas de Flujo de Casos de Prueba U0025 y U0027
6213 Script de Pruebas
Una vez establecidos los criterios de aceptacioacuten de ambos casos de prueba se mostraraacuten los scripts de pruebas
realizados
Figura 61 Script de Pruebas U0025
Entre las ldquokeywordsrdquo usadas en el caso de test anterior se puede destacar por ejemplo la implementacioacuten de
ldquoEdit Fieldsrdquo la cual permite editar los campos de un fabricante y verificar que han sido editados tras guardar
los cambios
Figura 62 Keyword ldquoEdit Fieldsrdquo
89
622 List
En la pestantildea de gestioacuten de los diferentes Zone Managers se puede observar una lista de los diferentes Zone
Managers disponibles y se pueden realizar un conjunto de acciones como la creacioacuten de nuevos Zone Managers
y edicioacuten o eliminacioacuten de los existentes entre otras
Figura 63 Pestantildea ldquoList of Zone Managersrdquo
Sobre esta vista se han realizado un total de 7 casos de prueba de los cuales detallaremos el caso de prueba
identificado con la etiqueta U0023 el cual permite validar la creacioacuten y eliminacioacuten de un Zone Manager
6221 Criterios de Aceptacioacuten
A continuacioacuten se detallan los criterios de aceptacioacuten del caso de prueba seleccionado
U0023 Verificar que un Usuario puede Crear y Eliminar un Zone Manager
1 Un usuario con permisos de Super Usuario puede Navegar a la pestantildea List Of Zone Managers
2 El usuario puede crear un Zone Manager correctamente
3 El usuario puede eliminar un Zone Manager correctamente
6222 Diagramas de Flujo
A continuacioacuten se muestra el diagrama de flujo implementado para el caso de prueba analizado
Figura 64 Diagrama de flujo de Caso de Prueba U0023
90
6223 Script de Pruebas
Una vez establecidos los criterios de aceptacioacuten se mostraraacute el script de pruebas realizado a partir del diagrama
de flujo anterior
Figura 65 Script de Prueba U0023
Cabe destacar la implementacioacuten de la Keyword ldquoZone Manager is Registered Successfullyrdquo la cual comprueba
que el Zone Manager registrado pasa a un estado ldquoOnlinerdquo tras un tiempo considerado como aceptable para que
la instancia de dicho Zone Manager este disponible en Cloud CHT Manager
Figura 66 Keyword ldquoZone Manager is registered successfullyrdquo
623 Manufacturer
La vista de gestioacuten principal ofrece una seccioacuten que permite la gestioacuten de los diferentes fabricantes permitiendo
su creacioacuten edicioacuten eliminacioacuten y bloqueo En la siguiente figura se muestra un ejemplo de la seccioacuten de
fabricantes
Figura 67 Seccioacuten de Fabricantes
Para validar el correcto funcionamiento de dicha seccioacuten se han realizado un total de 9 casos de prueba de los
cuales se detallaraacuten los casos de prueba identificados con las etiquetas U0009 Estos permiten validar que los
fabricantes pueden ser creados editados y eliminados correctamente y que todos los fabricantes disponibles son
mostrados correctamente
91
6231 Criterios de Aceptacioacuten
A continuacioacuten se detallan los criterios de aceptacioacuten de los casos de prueba seleccionados
U0009 Verificar que un Usuario con permisos de Super usuario puede ver correctamente todos los
fabricantes existentes
1 Un usuario con permisos de Super Usuario puede Navegar a la pestantildea de Administracioacuten
2 El usuario puede visualizar todos los fabricantes existentes
6232 Diagrama de Flujo
Figura 68 Diagrama de flujo de Caso de Prueba U0009
6233 Script de Pruebas
Una vez establecidos los criterios de aceptacioacuten se mostraraacuten los scripts de pruebas realizados a partir de los
diagramas de flujo anteriores
Figura 69 Script de Prueba U0009
En este punto cabe destacar la finalidad de la Keyword ldquoCorrectly Createrdquo la cual se usa en la mayoriacutea de las
pruebas para verificar que una operacioacuten se ha realizado con eacutexito en la plataforma Galgus CHT Cloud Manager
Esta Keyword verifica que tras realizar alguacuten tipo de operacioacuten en la plataforma Web ocurre un evento sobre la
Web que indica que dicha operacioacuten se ha realizado con eacutexito de la siguiente forma
92
Figura 70 Toast Success
Figura 71 Keyword ldquoCorrectly Createrdquo
Finalmente se muestra la implementacioacuten de las keywords usadas en [Setup] y [Teardown] del caso de prueba
U0009 las cuales preparan el escenario de pruebas creando un conjunto de fabricantes acotado y los elimina
tras la finalizacioacuten de la prueba
Figura 72 Setup amp Teardown de U0008
624 MAP
La plataforma Galgus CHT Cloud Manager ofrece una pestantildea ldquoMAPrdquo que contiene un mapa con la ubicacioacuten
asignada a cada uno de los Zone Managers disponibles por el usuario mostrando en su ubicacioacuten un icono con
el estado de dicho Zone Manager el cual cambia de color seguacuten su estado (offline online unsynchronized)
Figura 73 Mapa de Zone Managers
93
A traveacutes de dicho icono se puede realizar una serie de acciones entre ellas acceder a un Zone Manager
realizando doble click sobre el icono del mismo Sin embargo para automatizar este conjunto de acciones el
equipo de pruebas ha encontrado dificultades haciendo uso de Robot Framework ya que las libreriacuteas disponibles
permiten la interaccioacuten con elementos de la Web pero en este caso los iconos de los diferentes Zone Managers
son renderizados dentro del Mapa con ldquoOpen Street Mapsrdquo antes de ser mostrado en la vista Web de la
aplicacioacuten Por esta razoacuten el mapa es localizado en el DOM como un uacutenico elemento Web lo que imposibilita
localizar a priori el icono de cada Zone Manager dentro del Mapa
Para resolver este impedimento el equipo de pruebas tuvo que analizar con profundidad la libreriacutea de ldquoOpen
Street Maprdquo implementada en Javascript Esta ha sido usada en el Frontend para encontrar alguna funcioacuten que
permitiese obtener desde la consola del navegador Web los piacutexeles en los que cada Zone Manager ha sido
renderizado dentro del Mapa Dicha funcioacuten es ldquogetPixelsFromCoordinate(coordinate)rdquo la cual a traveacutes de las
coordenadas de [Latitud Longitud] de cada Zone Manager se obtienen los piacutexeles del mismo en la pantalla A
traveacutes del siguiente fragmento de coacutedigo en el frontend implementado con Angular 6 en typescript se consigue
obtener los piacutexeles de cada Zone Manager e imprimirlo en la consola del navegador Web
Figura 74 Funcioacuten que dibuja los ZM en el Mapa y obtiene los piacutexeles en pantalla
Para llevar a cabo la implementacioacuten de las pruebas sobre el mapa se ha hecho uso en su gran mayoriacutea de Scripts
con Python Selenium y otras libreriacuteas necesarias en lugar de Robot Framework debido a la necesidad de
realizar varias tareas simultaneas ademaacutes de tratarse de pruebas muy especiacuteficas y personalizadas A
continuacioacuten se muestra la prueba implementada para poder realizar doble click sobre un Zone manager en el
mapa e iniciar sesioacuten en el mismo (U0007)
6241 Criterios de Aceptacioacuten
U0007 Verificar que un Usuario acceder a un Zone Manager desde el Mapa
1 Un usuario con permisos de Super Usuario puede Navegar a la pestantildea MAP
2 El usuario puede hacer doble click en el Zone Manager e iniciar sesioacuten
94
6242 Diagrama de Flujo
Figura 75 Diagrama de Flujo de Caso de Prueba U0007
6243 Script de Pruebas
Para la implementacioacuten de este tipo de casos de prueba se ha hecho uso de la libreriacutea ldquoHtmlTestRunnerrdquo para
obtener un reporte similar al ofrecido por Robot Framework en la ejecucioacuten de la prueba Para obtener un reporte
de la prueba la implementacioacuten de la misma debe seguir una estructura determinada a la que ademaacutes se ha
incluido a traveacutes de la libreriacutea ldquomultiprocessingrdquo la ejecucioacuten simultaacutenea de los dos procesos descritos en el
diagrama de flujo anterior Es necesaria la ejecucioacuten de varios procesos para leer la consola del navegador Web
y obtener los piacutexeles de los Zone Manager para posteriormente hacer doble click
En la Seccioacuten A3 de los anexos puede encontrarse la implementacioacuten del script de pruebas para el caso de
prueba U0007
95
63 Vista de Configuracioacuten (Configuration Tab)
En esta vista se ha automatizado un conjunto de Suites de prueba que validan toda la funcionalidad contenida
en las pestantildeas Groups CHT Zones BackupRestore y Firmware
631 Groups
La pestantildea de grupos permite el descubrimiento de los puntos de acceso a traveacutes de su direccioacuten MAC quedando
estos registrados en base de datos y mostrando al usuario en una tabla los puntos de acceso registrados ademaacutes
del estado de los mismos y otros datos como el modelo o grupo al que pertenecen
Figura 76 Pestantildea ldquoGroupsrdquo
Sobre esta funcionalidad de la plataforma se han realizado un total de 19 casos de prueba de los cuales
detallaremos el caso de prueba identificado con la etiqueta U0119
6311 Criterios de Aceptacioacuten
U0119 Verificar que al descubrir dos puntos de acceso en grupos diferentes ambos son antildeadidos en el
grupo correcto
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Configuracioacuten
3 El usuario puede Navegar a la pestantildea de Grupos
4 El usuario puede descubrir un punto de acceso en el grupo ldquorootrdquo correctamente
5 El usuario puede crear un subgrupo predecesor del grupo ldquorootrdquo correctamente
6 El usuario puede navegar al subgrupo creado correctamente
7 El usuario puede descubrir un punto de acceso en el subgrupo correctamente
96
6312 Diagramas de Flujo
Figura 77 Diagrama de flujo de Caso de Prueba U0119
97
6313 Script de Pruebas
Una vez establecidos los criterios de aceptacioacuten el script de prueba realizado a partir del diagrama de flujo
anterior es el siguiente
Figura 78 Script de Prueba U0119
Entre las keywords implementadas para esta prueba cabe destacar la implementacioacuten de ldquoVerify if AP is
registered Succesfully on grouprdquo la cual permite validar si un punto de acceso ha sido asignado al grupo
correcto
Figura 79 Keyword ldquoVerify if AP is registered Succesfully on grouprdquo
Puede observarse como en primer lugar se obtiene la fila de la tabla que contiene el punto de acceso en cuestioacuten
para posteriormente comprobar si el grupo al que pertenece es el esperado
Observando dicha implementacioacuten cabe destacar el uso de la Keyword ldquoInput Into Text Fieldrdquo la cual ha sido
implementada para vaciar el contenido de campos de texto ya que mediante la Keyword ldquoClear Element Textrdquo
de la libreriacutea Selenium2Library no se conseguiacutea borrar ciertos campos de texto
Figura 80 Keywords Input Into Text Field y Clear Field Of Characters
98
632 CHT Zones
En la pestantildea de gestioacuten de las diferentes Zonas CHT se puede observar una lista de los puntos de acceso
disponibles y se pueden realizar un conjunto de acciones sobre ellos como la creacioacuten eliminacioacuten y asociacioacuten
de zonas CHT
En este punto es conveniente explicar el concepto de zona CHT el cual se refiere a un grupo IP Multicast a
traveacutes del cual un conjunto de Puntos de Acceso establece comunicacioacuten de forma colaborativa Esta
comunicacioacuten es necesaria para el funcionamiento de algunos de los algoritmos que ofrece CHT como por
ejemplo la asignacioacuten automaacutetica de canal (ACA)
Figura 81 Pestantildea ldquoCHT Zonesrdquo
Sobre esta vista se han realizado un total de 6 casos de prueba de los cuales detallaremos el caso de prueba
identificado con la etiqueta U0204 Este caso de prueba permite validar la asignacioacuten de zonas CHT a los Puntos
de Acceso
6321 Criterios de Aceptacioacuten
U0204 Verificar que un usuario puede asignar una Zona CHT a un punto de acceso correctamente
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Configuracioacuten
3 El usuario puede Navegar a la pestantildea de Grupos
4 El usuario puede asignar una Zona CHT existente a un punto de acceso registrado correctamente
99
6322 Diagramas de Flujo
Figura 82 Diagrama de Flujo de Caso de Prueba U0204
6323 Script de Pruebas
Tras presentar los criterios de aceptacioacuten y su correspondiente diagrama de flujo el script de pruebas
implementado para la automatizacioacuten de dicha prueba es el siguiente
Figura 83 Scripts de Prueba U0204
Figura 84 Keyword Add Zone CHT to AP
100
633 BackupRestore
En esta pestantildea se permite la gestioacuten de copias de seguridad y restauracioacuten de los puntos de acceso registrados
en un Zone Manager Se puede observar en esta vista una tabla con los puntos de acceso registrados y otra tabla
con las copias de seguridad realizadas sobre los puntos de acceso
Figura 85 Pestantildea BackupRestore
Partiendo de la representacioacuten funcional de esta vista se han realizado un total de 8 casos de prueba de los
cuales detallaremos el caso de prueba identificado con la etiqueta U0401 el cual permite verificar de forma
automaacutetica la realizacioacuten de un backup sobre un punto de acceso y su posterior restauracioacuten
6331 Criterios de Aceptacioacuten
U0401 Verificar que un usuario puede realizar un BackupRestore correctamente sobre un punto de
acceso previamente registrado
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Configuracioacuten
3 El usuario puede Navegar a la pestantildea de BackupRestore
4 El usuario puede realizar un Backup sobre un punto de acceso existente
5 La tabla de Backups contiene la copia de seguridad realizada
6 El usuario puede restaurar un punto de acceso correctamente
101
6332 Diagramas de Flujo
Figura 86 Diagrama de Flujo de Caso de Prueba U0401
6333 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 87 Script de Prueba U0401
Cabe destacar la implementacioacuten de la Keyword ldquoRestore for AP have done successfullyrdquo la cual verifica que
el punto de acceso ha sido restaurado correctamente esperando que el punto de acceso vuelva a estar en estado
ldquoonlinerdquo durante un tiempo aceptable Si pasado dicho tiempo no recupera dicho estado la prueba se dariacutea por
erroacutenea
Figura 88 Keyword Restore For AP hace done successfully
634 Firmware
Esta uacuteltima pestantildea de la vista principal de configuracioacuten proporciona al usuario la posibilidad de subir los
firmwares de los diferentes modelos de puntos de acceso en sus diferentes versiones del software CHT de forma
que es posible la actualizacioacuten del firmware de los puntos de acceso desde la plataforma Se puede observar en
esta vista una tabla con los puntos de acceso registrados y otra tabla con los firmwares subidos a la plataforma
102
Figura 89 Pestantildea ldquoFirmwarerdquo
Partiendo de la representacioacuten funcional de esta vista se han realizado un total de 7 casos de prueba de los
cuales detallaremos el caso de prueba identificado con la etiqueta U0303 el cual permite verificar de forma
automaacutetica la actualizacioacuten del firmware de un punto de acceso
6341 Criterios de Aceptacioacuten
U0303 Verificar que un usuario puede realizar correctamente la actualizacioacuten del firmware de un punto
de acceso
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Configuracioacuten
3 El usuario puede Navegar a la pestantildea de Firmware
4 El usuario puede subir un firmware correctamente
5 La tabla de Firmwares contiene la imagen de CHT subida a la plataforma
6 El usuario puede realizar la actualizacioacuten del firmware sobre un punto de acceso correctamente
Destacar que el firmware que se desea aplicar sobre un punto de acceso debe ser del modelo correspondiente al
punto de acceso usado ya que cada punto de acceso tiene una imagen de CHT compilada para una arquitectura
hardware determinada Las imaacutegenes son proporcionadas por un servidor interno de la empresa
103
6342 Diagramas de Flujo
Figura 90 Diagrama de Flujo de Caso de Prueba U0303
6343 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 91 Script de Prueba U0303
Cabe destacar la implementacioacuten de la Keyword ldquoFlash APrdquo la cual realiza la actualizacioacuten del firmware de un
punto de acceso verificando que este ha concluido correctamente Para ello espera un tiempo aceptable a que el
punto de acceso vuelva al estado ldquoonlinerdquo
Figura 92 Keyword Flash AP
104
64 Vista de Red (Network Tab)
La uacuteltima vista principal sobre la que se han automatizado pruebas es la vista de Red la cual ofrece al usuario
la gestioacuten y configuracioacuten de su red formada por un conjunto de puntos de acceso previamente registrados
Entre las funcionalidades ofrecidas se encuentran la creacioacuten de VLANS SSIDs Portales Cautivos Perfiles
Radius Activacioacuten de algoritmos CHT y la configuracioacuten de puntos de acceso en tiempo real desde la
plataforma Web
Para describir el proceso de automatizacioacuten se comenzaraacute detallando en primer lugar la creacioacuten de VLANS
Brigdes y SSIDs para posteriormente aplicar dichos paraacutemetros a puntos de acceso desde las pestantildeas ldquoGeneralrdquo
y ldquoAP Networkrdquo Finalmente se mostraraacuten algunos ejemplos sobre otras configuraciones maacutes avanzadas como
la creacioacuten y aplicacioacuten de perfiles radius y portales cautivos ademaacutes de la activacioacuten de algoritmos
641 VLANS amp Bridges
Comenzando con la pestantildea de VLANS amp Bridges se puede observar la existencia de una tabla para cada
elemento de dicha vista
Figura 93 Pestantildea ldquoVLAN amp Bridgesrdquo
Para cada elemento se han automatizado un conjunto de pruebas formado por 6 casos de prueba de los cuales
detallaremos el caso de prueba identificado con la etiqueta U0527 Este caso de prueba permite validar de forma
automaacutetica la creacioacuten y eliminacioacuten de VLANs De forma ideacutentica se procederiacutea para validar la creacioacuten y
eliminacioacuten de Bridges
6411 Criterios de Aceptacioacuten
A continuacioacuten se detallan los criterios de aceptacioacuten del caso de prueba seleccionado
U0527 Verificar que un usuario puede crear y eliminar una VLAN correctamente
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Network
3 El usuario puede Navegar a la pestantildea de VLANS amp Bridges
4 El usuario puede crear una VLAN correctamente
5 El usuario puede eliminar una VLAN correctamente
105
6412 Diagramas de Flujo
Figura 94 Diagrama de Flujo de Caso de Prueba U0527
6413 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 95 Script de Prueba U0527
Cabe destacar la implementacioacuten de la Keyword ldquoGo and Create VLANrdquo la cual permite crear una VLAN en
funcioacuten de los paraacutemetros de entrada deseados para configurar dicha VLAN como por ejemplo el ldquoIDrdquo de la
VLAN y alias o si se desea que dicha VLAN sea de tipo dinaacutemica
Figura 96 Keyword Go And Create VLAN
106
642 SSIDs
Esta pestantildea proporciona una tabla que permite registrar SSIDs con diferentes configuraciones posibles
Figura 97 Pestantildea SSIDs
Para cada funcionalidad de dicha pestantildea se han automatizado un conjunto de pruebas formado por 5 casos de
prueba de los cuales detallaremos el caso de prueba identificado con la etiqueta U0530 Este caso de prueba
permite validar de forma automaacutetica la creacioacuten y eliminacioacuten de SSIDS
6421 Criterios de Aceptacioacuten
A continuacioacuten se detallan los criterios de aceptacioacuten de los dos casos de prueba seleccionados
U0530 Verificar que un usuario puede crear y eliminar una SSID correctamente
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Network
3 El usuario puede Navegar a la pestantildea de SSIDs
4 El usuario puede crear una SSID correctamente
5 El usuario puede eliminar una SSID correctamente
6422 Diagramas de Flujo
Figura 98 Diagrama de Flujo de Caso de Prueba U0530
107
6423 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 99 Script de Prueba U0530
Cabe destacar la implementacioacuten de la Keyword ldquoGo and Create SSIDrdquo la cual permite crear una SSID en
funcioacuten de los paraacutemetros de entradas deseado para configurar dicha SSID como por ejemplo tipo de
encriptacioacuten de la contrasentildea modo oculto o habilitacioacuten de los algoritmos Load Balancing (LB) Smart
roaming (SR) o PRE
Figura 100 Keyword Go And Create SSID
108
643 CHT
Esta funcionalidad permite activar el algoritmo que permite la seleccioacuten automaacutetica de canal entre un conjunto
de puntos de acceso (ACA) Cuando se activa desde la plataforma Web todos los puntos de acceso
pertenecientes a un Zone Manager activan dicho algoritmo el cual se trata de un algoritmo colaborativo
mediante el cual los puntos de acceso acuerdan cual es el mejor canal para la comunicacioacuten WiFi con los clientes
que se conecten tanto en la banda de 24 GHz como en la de 5 GHz En la siguiente figura se muestra la vista
de la plataforma Web para activar el algoritmo en cuestioacuten
Figura 101 Pestantildea ldquoCHTrdquo
Dado que se trata de una funcionalidad en la que solo se debe comprobar si el algoritmo estaacute en el mismo estado
tanto en la plataforma Web como en los puntos de acceso registrados se ha implementado un uacutenico caso de
prueba identificado con la etiqueta U539 Este caso de prueba realiza la conexioacuten a los puntos de acceso para
verificar que dicho algoritmo presenta el mismo estado que en la plataforma
6431 Criterios de Aceptacioacuten
U0537 Verificar que un usuario puede Activar o Desactivar el algoritmo ACA correctamente
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Network
3 El usuario puede Navegar a la pestantildea de CHT
4 El usuario puede ActivarDesactivar el algoritmo ldquoACA ldquocorrectamente
5 Los APs recibieron las oacuterdenes para ActivarDesactivar el algoritmo ldquoACArdquo correctamente
109
6432 Diagramas de Flujo
Figura 102 Diagrama de Flujo de Caso de Prueba U0539
6433 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 103 Script de Prueba U0539
En cuanto a la implementacioacuten de dicho caso de prueba cabe destacar la implementacioacuten de la Keyword ldquoACA
Is Workingrdquo las cual se muestra en la siguiente figura
Figura 104 Keyword ACA Is Working
Puede observarse como en funcioacuten de si el algoritmo ACA esta activado o desactivado en la plataforma Web
(ENABLE DISABLE) se ejecuta la Keyword ldquoChanges On CLIrdquo con diferentes paraacutemetros Esta Keyword
permite la conexioacuten viacutea ldquoSSHrdquo con un punto de acceso para la ejecucioacuten de un comando sobre el mismo y la
posterior comparacioacuten del resultado obtenido por dicho comando con la salida deseada proporcionada tambieacuten
como paraacutemetro de la Keyword
110
En la siguiente figura se muestra la implementacioacuten de dicha Keyword
Figura 105 Keyword Changes On CLI
Para este caso de prueba el comando ejecutado de forma remota sobre el punto de acceso permite obtener de
forma automaacutetica el estado del algoritmo ldquoACArdquo de la siguiente forma
Figura 106 Comando CHT para obtener el estado del moacutedulo ACA en el punto de acceso
644 Radius
Esta pestantildea proporciona una tabla que permite registrar perfiles Radius con diferentes configuraciones posibles
Figura 107 Pestantildea ldquoRadiusrdquo
ldquoRadiusrdquo se define como un protocolo de autenticacioacuten y autorizacioacuten para aplicaciones de acceso a la red o
movilidad IP De esta forma los puntos de acceso mediante la existencia de un servidor radius permiten que los
usuarios que se quieran conectar por WiFi necesiten ser autenticados con credenciales Dicha autenticacioacuten seraacute
redirigida por el punto de acceso al servidor radius el cual autoriza al punto de acceso para que permita la
conexioacuten del cliente
Ademaacutes el uso de este servicio junto con la configuracioacuten mediante VLAN dinaacutemicas permite que diferentes
usuarios accedan al servicio de red con diferentes credenciales de forma que seguacuten el tipo de cliente su traacutefico
viajaraacute por una VLAN u otra Esto permite la separacioacuten del traacutefico a nivel de enlace ofreciendo la posibilidad
de establecer reglas de control de traacutefico y ofrece una QoS miacutenima en funcioacuten del tipo de cliente
Figura 108 Escenario de Funcionamiento de Servidor Radius
111
Para cada funcionalidad de dicha pestantildea se han automatizado un conjunto de pruebas formado por 7 casos de
prueba de los cuales detallaremos el caso de prueba identificado con la etiqueta U0601 Este caso de prueba
permite validar de forma automaacutetica la creacioacuten edicioacuten y borrado de un perfil radius en la plataforma Web
6441 Criterios de Aceptacioacuten
U0601 Verificar que un usuario puede crear editar y borrar un perfil Radius correctamente
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Network
3 El usuario puede Navegar a la pestantildea de Radius
4 El usuario puede Crear un perfil Radius correctamente
5 El usuario puede Editar un perfil Radius correctamente
6 El usuario puede Eliminar un perfil Radius correctamente
6442 Diagramas de Flujo
Figura 109 Diagrama de Flujo de Caso de Prueba U0601
6443 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 110 Script de Prueba U0601
En cuanto a la implementacioacuten de dicho caso de prueba puede destacarse por ejemplo la implementacioacuten de
la Keyword ldquoCreate Radius Profilerdquo la cual permite crear un perfil ldquoRadiusrdquo a partir de un conjunto de
paraacutemetros de entrada
112
Figura 111 Keyword Create Radius Profile
645 Captive Portal
Esta pestantildea proporciona una tabla que permite registrar perfiles de Portales Cautivos con diferentes
configuraciones posibles
Figura 112 Pestantildea Captive Portals
Un portal cautivo es un servicio que permite el control del traacutefico HTTP y fuerza a los usuarios de una red a la
autenticacioacuten mediante una paacutegina Web para tener acceso a Internet Dicho portal permite controlar paraacutemetros
como el tiempo de conexioacuten de un cliente a la red ancho de banda ofrecido a cada cliente etc
Figura 113 Escenario de Funcionamiento de un Portal Cautivo
Para cada funcionalidad de dicha pestantildea se han automatizado un conjunto de pruebas formado por 5 casos de
prueba de los cuales detallaremos el caso de prueba identificado con la etiqueta U0701 Este caso de prueba
permite validar de forma automaacutetica la creacioacuten edicioacuten y borrado de un perfil de portal cautivo en la plataforma
Web
113
6451 Criterios de Aceptacioacuten
U0701 Verificar que un usuario puede crear editar y borrar un perfil de Portal Cautivo correctamente
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Network
3 El usuario puede Navegar a la pestantildea de Captive Portals
4 El usuario puede Crear un perfil de Portal Cautivo correctamente
5 El usuario puede Editar un perfil de Portal Cautivo correctamente
6 El usuario puede Eliminar un perfil de Portal Cautivo correctamente
6452 Diagramas de Flujo
Figura 114 Diagrama de Flujo de Caso de Prueba U0701
6453 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 115 Script de Prueba U0701
114
En cuanto a la implementacioacuten de dicho caso de prueba puede destacarse por ejemplo la implementacioacuten de
la Keyword ldquoEdit or delete Captive Portal Profilerdquo la cual permite editar o eliminar un perfil de Portal Cautivo
a partir de un conjunto de paraacutemetros de entrada
Figura 116 Keyword Edit or Delete Captive Portal Profile
115
646 General
Esta pestantildea muestra la vista general de la pestantildea ldquoNetworkrdquo En esta pestantildea se agrupa el conjunto de puntos
de acceso actualmente registrados en el Zone Manager con un resumen de su configuracioacuten de red actual el
estado en el que se encuentran y nuacutemero de clientes conectados Ademaacutes dicha vista proporciona un acceso
directo a la pestantildea ldquoAP Networkrdquo seleccionando uno o varios puntos de acceso de un mismo modelo En la
siguiente seccioacuten se explica la funcionalidad de dicha pestantildea
Figura 117 Pestantildea General
Para cada elemento se han automatizado un conjunto de pruebas formado por 9 casos de prueba de los cuales
detallaremos el caso de prueba identificado con la etiqueta U0522 Este caso de prueba se permite validar de
forma automaacutetica la conexioacuten de clientes a un punto de acceso con una SSID asignada de forma que el nuacutemero
de clientes conectados que se muestra en la plataforma Web sea correcto
6461 Criterios de Aceptacioacuten
U0522 Conectar clientes y verificar que el nuacutemero de clientes conectados es correcto
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Network
3 El usuario puede Navegar a la pestantildea General
4 El usuario tiene disponible un punto de acceso en el Zone Manager con una SSID asignada
5 El usuario conecta un cliente al punto de acceso por WiFi a la SSID asignada
6 El usuario verifica que el nuacutemero de clientes conectados incrementa en una unidad
116
6462 Diagramas de Flujo
Figura 118 Diagrama de Flujo de Caso de Prueba U0522
6463 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de prueba automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 119 Script de Prueba U0522
En cuanto a la implementacioacuten de dicho caso de prueba puede destacarse por ejemplo la implementacioacuten de
la Keyword ldquoCheck Number of Clients Increasesrdquo la cual permite comprobar que el nuacutemero de clientes conectados incrementa al conectar un cliente a un punto de acceso
Figura 120 Keyword Check Number of Clients Increases
117
647 AP Network
Esta pestantildea muestra la vista principal de la pestantildea ldquoAP Networkrdquo La funcionalidad que proporciona engloba
todos los posibles paraacutemetros de configuracioacuten para un punto de acceso que ha sido seleccionado previamente
desde la pestantildea General Cualquier configuracioacuten aplicada sobre esta vista seraacute enviada al punto de acceso
desde la plataforma Web permitiendo configurar los puntos de acceso de Galgus
Desde el punto de vista de la plataforma Web esta vista abarca un conjunto de funcionalidades consideradas
como maacutes complejas que se ofrecen en la plataforma Web por lo que es en esta vista donde puede encontrarse
una de las mayores aacutereas de riesgo de la plataforma Entre las funcionalidades que se ofrecen estaacuten la
configuracioacuten de las radios de un punto de acceso (Potencia Ancho de banda Canal etc) asignacioacuten de SSIDs
a las interfaces inalaacutembricas y configuracioacuten de reglas de control de traacutefico (TC Rules) asignacioacuten de puertos a
las diferentes subredes virtuales de aacuterea local (VLANS) o configuracioacuten de Portal Cautivo
Figura 121 Pestantildea AP Network
Para cada elemento se han automatizado un conjunto de pruebas formado por 28 casos de prueba los cuales la
mayoriacutea han requerido un amplio esfuerzo de implementacioacuten para conseguir su automatizacioacuten ya que son
pruebas cuya secuencia de acciones es larga ademaacutes de requerir en muchas ocasiones la verificacioacuten de la
configuracioacuten en los puntos de acceso viacutea ldquosshrdquo Para ello se ha hecho uso entre otras de la libreriacutea
ldquoSSHLibraryrdquo proporcionada por Robot Framework
Figura 122 Libreriacutea SSH para Robot Framework
118
Del conjunto de casos de prueba que validan la funcionalidad de dicha pestantildea se va a detallar el caso de prueba
identificado con la etiqueta U0511 Este caso de prueba permite validar de forma automaacutetica que se pueden
aplicar reglas de control de traacutefico ldquoTCsrdquo a una SSID asignada a las interfaces inalaacutembricas de un punto de
acceso desde la plataforma Web
Figura 123 Ventana de Configuracioacuten de TC Rules
6471 Criterios de Aceptacioacuten
U0511 Asignar ldquoTC Rulesrdquo a una SSID asociada a un Punto de Acceso correctamente
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Network
3 El usuario puede Navegar a la pestantildea General
4 El usuario tiene disponible un punto de acceso en el Zone Manager
5 El usuario puede seleccionar un punto de acceso
6 El usuario puede Navegar a la pestantildea AP Network para el punto de acceso seleccionado
7 El usuario puede asignar a las interfaces inalaacutembricas una SSID existente y crear ldquoTC Rulesrdquo sobre
esa SSID
8 El usuario puede aplicar la configuracioacuten
9 El punto de acceso aplica su configuracioacuten correctamente
10 El punto de acceso pasa al estado ldquoOnlinerdquo en la plataforma Web y su configuracioacuten estaacute alineada
119
6472 Diagramas de Flujo
Figura 124 Diagrama de Flujo de Caso de Prueba U0511
120
6473 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 125 Script de Prueba U0511
En cuanto a la implementacioacuten de dicho caso de prueba puede destacarse por ejemplo la implementacioacuten de
la Keyword ldquoWait Timerrdquo la cual permite verificar que no se produce ninguacuten error al aplicar una configuracioacuten
determinada desde la plataforma Web durante un tiempo determinado
Figura 126 Keyword Wait Timer
Destacar tambieacuten la implementacioacuten de la Keyword ldquoCheck On CLIrdquo la cual permite contrastar que la
configuracioacuten aplicada desde la plataforma sobre un punto de acceso es la esperada En este caso se comprueba
que las ldquoTC Rulesrdquo han sido correctamente aplicadas para una SSID determinada en un punto de acceso de
forma remota mediante el uso de la libreriacutea ldquoSSHrdquo para Robot Framework
Figura 127 Keyword Check On CLI
121
122
7 LINEAS DE MEJORA Y CONCLUSIONES
n este uacuteltimo capiacutetulo se analizaraacuten resultados y conclusiones obtenidas sobre el uso de pruebas
automatizadas para la verificacioacuten y validacioacuten de una plataforma Web como la de Galgus Se
detallaraacuten algunas ventajas e inconvenientes encontrados y se plantearaacuten algunas liacuteneas de mejora
futuras sobre el proyecto desarrollado Con estas mejoras se busca como objetivo enriquecer el proceso de
automatizacioacuten de pruebas ademaacutes de hacerlo maacutes efectivo y metoacutedico en todos sus aspectos ya que siempre
hay algo que se puede mejorar para conseguir una herramienta maacutes completa y uacutetil
Se detallaraacuten tambieacuten aspectos de aprendizaje opiniones experiencias y en definitiva todas las conclusiones
sacadas sobre este proyecto incluyendo tambieacuten las dificultades encontradas para el desarrollo del mismo
71 Liacuteneas de Mejora Futuras
El estudio y puesta en marcha de este Proyecto de automatizacioacuten de pruebas de Software ha hecho uso de una
amplia cantidad de herramientas ofrecido por Selenium y Robot Framework ademaacutes de otras herramientas que
han permitido enriquecer el mismo con mayores funcionalidades ofrecidas al equipo de Proyecto Si bien se ha
logrado conseguir un paquete de pruebas con una capacidad de detectar defectos en un producto Web existen
diversas ampliaciones de dicho Proyecto que podriacutean aumentar de manera considerable el desempentildeo de las
herramientas de automatizacioacuten a lo largo del ciclo de vida del proyecto
A continuacioacuten se muestran algunas de las maacutes importantes
bull Uso de Integracioacuten Continua Robot Framework es faacutecilmente integrable principalmente con Jenkins
aunque tambieacuten ofrece la posibilidad de integrarlo con Gitlab CICD Esto permitiriacutea programar la
ejecucioacuten de pruebas automaacuteticamente para diferentes versiones del proyecto Galgus CHT Cloud
Manager o en diferentes fases del mismo Con esta caracteriacutestica se detectariacutean con mayor facilidad los
problemas relacionados con la configuracioacuten del entorno de trabajo y se podriacutea notificar por email a
los responsables de equipo ante los eventuales incidentes encontrados De este modo no seriacutea necesario
estar supervisando el proceso de ejecucioacuten para estar al tanto de un fallo en el sistema En este aspecto
se ha trabajado para conseguir estos objetivos con la creacioacuten de un Docker de Robot Framework que
permita la ejecucioacuten de las pruebas en el mismo para poder usarla en el entorno de integracioacuten continua
correspondiente Tambieacuten se ha implementado un primer un script que permita la ejecucioacuten de paquetes
de pruebas en dicho entorno
bull Selenium Grid El caso praacutectico descrito tiene un inconveniente y es que solo hace uso de Chrome
Suele ser frecuente que ciertos defectos en una aplicacioacuten Web solo aparezcan en determinados
navegadores Con herramientas como Selenium Grid permitiriacutean la ejecucioacuten en paralelo de las pruebas
en maacutequinas con diferentes sistemas operativos y navegadores Asiacute se podriacutea evaluar de manera
independiente la compatibilidad del producto en entornos multiplataforma Ademaacutes esta herramienta
es totalmente compatible con Jenkins o Gitlab CICD con las ventajas que esto supone
bull Headless browser Esto hace referencia al uso de navegadores sin interfaz graacutefica de usuario La mayor
parte del tiempo durante una ejecucioacuten es destinada a esperar a que el navegador renderice el contenido
Si se elimina este factor de la foacutermula y se accede directamente al DOM de la Web se consigue una
reduccioacuten en el tiempo de ejecucioacuten de las pruebas Durante el desarrollo de este proyecto se ha
trabajado en este aspecto ofrecieacutendose la posibilidad de ejecutar las pruebas en dos entornos diferentes
una primera de depuracioacuten de pruebas que realiza el renderizado del navegador y otra opcioacuten que
E
La tecnologiacutea por siacute sola no basta Tambieacuten tenemos que poner el corazoacuten
Jane Goodall
123
permite la ejecucioacuten de pruebas sin renderizado del navegador (Modo Headless)
bull Buenas praacutecticas en la localizacioacuten de elementos en el DOM de la Web La aplicacioacuten de este tipo
de buenas praacutecticas permitiriacutean una mejor y maacutes eficiente localizacioacuten de los elementos en el DOM
reduciendo la posibilidad de que las pruebas generen falsos errores Esto es lo que ha causado la mayor
parte de los problemas de implementacioacuten y ejecucioacuten de las pruebas automaacuteticas Actualmente la
herramienta de automatizacioacuten de pruebas se encuentra en un proceso de mejora continua en el que se
estaacute abordando una refactorizacioacuten para la aplicacioacuten de estas buenas praacutecticas Para ello se estaacuten
haciendo uso de selectores avanzados basados en rutas (Xpaths) relativas en el DOM de la Web las
cuales realizan la mayoriacutea de las buacutesquedas por contenido y no por ruta absoluta como se veniacutea
haciendo hasta ahora
bull Aplicacioacuten de Model Based Testing (MBT) Como estudio del arte se ha presentado una teacutecnica que
permite dar un paso maacutes en la automatizacioacuten de pruebas Como se ha detallado en el proyecto esta
teacutecnica permite ascender en el nivel de abstraccioacuten de las pruebas basando las mismas en el disentildeo y
modelado de la aplicacioacuten Dicha teacutecnica se encuentra principalmente en proceso de investigacioacuten lo
cual hace difiacutecil aplicarla aunque seriacutea de gran intereacutes conseguir su implantacioacuten
72 Conclusiones Finales
En el desarrollo del presente Proyecto se ha analizado una pequentildea extensioacuten del inmenso mundo de la gestioacuten
de calidad Esta ha ido tomando fuerza con el paso de los antildeos en el mercado actual introducieacutendose en todos
los aacutembitos incluido en el software La gestioacuten de calidad se ha profesionalizado de tal forma que el papel del
ingeniero de calidad en los proyectos de software es imprescindible en cualquier empresa que quiera hacerse un
hueco en el mercado como garantiacutea de calidad
La elevada exigencia del mercado del software provocada por la gran demanda de clientes y usuarios finales
para recibir un producto en el menor tiempo posible hace que en muchos casos las empresas centren su esfuerzo
en sacar un producto lo antes posible reduciendo los esfuerzos destinados a los procesos de calidad de dicho
producto software Originalmente las pruebas de software realizadas sobre un producto se realizaban de forma
manual por un ingeniero de calidad pero con el avance de las tecnologiacuteas la automatizacioacuten de las mismas
supone un elevado esfuerzo inicial pero una reduccioacuten de los mismos a medio plazo
En este proyecto se ha desarrollado una herramienta que permite la automatizacioacuten de pruebas funcionales sobre
una plataforma Web concretamente pruebas de aceptacioacuten sobre Galgus CHT Cloud Manager Las pruebas de
automatizacioacuten elaboradas reflejan que existen tecnologiacuteas muy asequibles en teacuterminos de coste compatibilidad
y facilidad de uso para iniciarse en el mundo de las pruebas funcionales de sistemas Algo muy presente en el
mundo laboral actual es la creciente demanda de expertos en automatizacioacuten en todas las principales
plataformas Web Moacutevil y Escritorio Muchos de estos profesionales vienen del mundo del testing manual por
lo que conociendo ya la nomenclatura y el funcionamiento de los procesos de calidad solo necesitan dar el paso
hacia el uso de este tipo de herramientas Sea con Selenium o con cualquier otra herramienta los conceptos
teoacutericos presentados en este proyecto son igualmente vaacutelidos
Por otra parte debe destacarse la dificultad encontrada a la hora de establecer unos criterios de aceptacioacuten de las
funcionalidades de la plataforma Web bajo pruebas Esto se debe al desarrollo de una herramienta de
automatizacioacuten de pruebas que se ha iniciado en una fase avanzada del desarrollo del proyecto con lo cual en
muchas ocasiones surgiacutean dudas sobre el disentildeo del proyecto Adicionalmente la propia estructura y tecnologiacuteas
usadas en la Web dificultaron al inicio la localizacioacuten de elementos A esta causa de une tambieacuten la ausencia de
identificadores uacutenicos en los elementos que componen la misma Esto se tradujo en el uso de selectores basados
en la ruta del elemento pudiendo acarrear la aparicioacuten de posibles falsos errores debidos a cambios en el coacutedigo
fuente de la plataforma Web La solucioacuten adoptada para tal problema no fue maacutes que analizar meticulosamente
aquellas ejecuciones fallidas para descartar errores reales y en caso de que sean debidas a los selectores aplicar
la debida actualizacioacuten de los mismos
En este uacuteltimo aspecto cabe destacar que el proyecto de automatizacioacuten de pruebas se encuentra actualmente
en una fase de mejora continua en la que se estaacuten adoptando teacutecnicas basadas en el uso de selectores avanzados
basados en rutas relativas y nombres que permitan reducir el impacto del problema presentado en este punto
124
A modo de resumen se plantean algunas ventajas en el uso de SeleniumRobot Framework para la
automatizacioacuten de pruebas
Facilidad de configuracioacuten y uso Su instalacioacuten requiere un esfuerzo miacutenimo y el poder de
abstraccioacuten ofrecido por Robot Framework hace posible la lectura y entendimiento de los paquetes de
pruebas y reportes a todos los miembros del equipo
Cantidad de documentacioacuten disponible La comunidad respalda ambos proyectos y es por ello que
encontramos soluciones de todo tipo adaptadas a las necesidades de cada uno
Soporte para la mayoriacutea de navegadores con el mismo script Ejecutar el script de pruebas
desarrollado para su automatizacioacuten en otro navegador requiere simplemente la instalacioacuten del
controlador deseado y usar un determinado paraacutemetro para indicar el uso de dicho controlador en la
llamada de la Keyword encargada de la apertura del navegador
De la misma forma se pueden destacar algunas desventajas
Selenium soacutelo es compatible con productos Web Cualquier software moacutevil o de escritorio requiere
del uso de otros frameworks o herramientas lo cual puede ser un punto negativo para empresas que
tengan productos multiplataforma Sin embargo Robot Framework si proporciona soporte
multiplataforma con la integracioacuten de otras herramientas o framework para su desarrollo
Tecnologiacuteas no optimizadas para pruebas de rendimiento En este punto cabe destacar el esfuerzo
de la comunidad para desarrollar herramientas que permitan la automatizacioacuten de este tipo de pruebas
con Robot Framework como por ejemplo ldquorfswarmrdquo
Compatibilidad de versiones de paquetes de Software Es frecuente usar determinadas
combinaciones de versiones de paquetes para lograr un framework estable y robusto Esto a veces puede
convertirse en una tarea tediosa donde cuestan encajar piezas Por suerte es algo que se estaacute teniendo
en cuenta con las uacuteltimas versiones de Selenium
Puede concluirse que durante el desarrollo de este proyecto se ha conseguido la creacioacuten de una herramienta
sencilla de usar y entender para la automatizacioacuten de pruebas funcionales sobre una plataforma Web ademaacutes
de preparar dicha herramienta para integrarla en el proceso de integracioacuten continua implantado para dicha
aplicacioacuten Web con Gitlab mediante Docker Ademaacutes se ha realizar un estudio del arte de una teacutecnica conocida
bajo el nombre de Model Based Testing (MBT) que permitiriacutea mejorar el proceso de automatizacioacuten y la
herramienta desarrollada para tal fin
Con todo ello he aprendido multitud de conceptos tecnologiacuteas y herramienta que hasta ahora desconociacutea cuaacutel
era su finalidad o funcionamiento como por ejemplo Robot Framework Para ello he necesitado gran cantidad
de formacioacuten previa antes de comenzar a ponerlo en praacutectica para el desarrollo de la herramienta de
automatizacioacuten
Son muchos los errores cometidos hasta conseguir los objetivos y metas propuestas los cuales creo que son los
sucesos maacutes importantes pues de ellos se aprende y son los que nos hacen avanzar cuando los resolvemos
Finalmente destacar que este proyecto me ha dado la oportunidad de abrir mi conocimiento en un campo de las
tecnologiacuteas de la informacioacuten el cual resulta de intereacutes Dar las Gracias a mis tutores Pablo Aguilera Bonet y
Daniel Gutieacuterrez Reina ademaacutes de mi responsable en Galgus Joseacute Antonio Delgado Alfonso por brindarme
esta oportunidad ademaacutes de ayudarme y asesorarme estando siempre disponible y con dedicacioacuten hacia este
proyecto para que haya podido llevarse a cabo
125
126
REFERENCIAS
[1] M Utting Bruno Legeard Practical Model-based Testing sl Elsevier 2007
[2] Ibrahim K El-Far Enjoying the perks of model-based testing In Proceedings of the Software Testing
Analysis and Review Conference
[3] A C Dias Neto Rajesh Subramanyan Marlon Vieirab Characterization of Model-based Software
[4] Model-based Testing Next Generation Functional Software Testing Legeard Bruno Dagstuhl Seminar
Proceedings 10111 Vol httpdropsdagstuhldeopusvolltexte20102620
[5] Perspectives of Model-Based Testing Ed Brinksma Wolfgang Grieskamp and Jan Tretmans IBFI
Schloss Dagstuhl Germany sn 2005 Dagstuhl Seminar Proceedings
[6] Definicioacuten de Calidad httpsdleraeesid=6nVpk8P|6nXVL1Z
[7] Modelos de calidad del software httpswwwresearchgatenetpublication316674475
[8] Calidad del Software ldquoEl camino al exitordquo LI Alma Delia Chaacutevez Rojas
[9] IEEE Software Engineering Book of Knowledge IEEE sl IEEE 2004
[10] Principios de pruebas software httpsmediumcomatejedaccsprincipios-del-testing-722323e16e76
[11] httpwwwsstqbesw3docsGLOSARIO_V00110pdf
[12] httpsepdfpubsoftware-testing-an-istqb-iseb-foundation-guidehtml
[14] IEEE standard glossary of software engineering terminology F Jay RMayer 1990 paacuteg IEEE Std 610
[15] Openwrt httpsopenwrtorgsupported_devices
[16] RabbitMQ httpswwwrabbitmqcom
[17] Zero Touch Provisioning httpssearchdatacentertechtargetcomesdefinicionAprovisionamiento-de-
cero-toque-ZTP-o-zero-touch-provisioning
[18] Robot Framework User Guide
httpsrobotframeworkorgrobotframeworklatestRobotFrameworkUserGuidehtml
[19] Gitlab httpsdocsgitlabcom
[20] httpswwwfederico-toledocomcuando-automatizar-una-prueba
127
128
ANEXO A PREPARACIOacuteN DEL ENTORNO DE
TRABAJO Y EJECUCIOacuteN DE PRUEBAS
A1 Preparacioacuten del entorno de trabajo
Para el desarrollo de las preubas automaacuteticas se ha hecho uso del sistema operative Linux con la distribucioacuten
Ubuntu El motivo de su uso es el amplio abanico de herramientas de coacutedigo libre que existen para esta
distribucioacuten asiacute como la enorme contribucioacuten que hace la comunidad de usuarios para mejorarla Sobre este
sistema operativo se ha hecho uso de un conjunto de herramientas para el montaje de un entorno de pruebas
automatizado basado en Python A continuacioacuten se detallaraacuten dichas herramientas
A11 Pip
Pip es un sistema de gestioacuten de paquetes que se utiliza para la instalacioacuten de los paquetes software
implementados en Python que se usaraacuten posteriormente La instalacioacuten de un paquete se realiza mediante la
ejecucioacuten del siguiente comando
A12 Virtualenv Entorno Virtual
Dado que cada proyecto basado en Python puede requerir la instalacioacuten de diferentes conjuntos de paquetes es
comuacuten usar la creacioacuten de entornos virtuales que nos permitan administrar cada proyecto de manera
independiente pudiendo tener otros proyectos haciendo uso de los mismos paquetes con otras versiones La
instalacioacuten se realiza mediante la herramienta ldquoPiprdquo a traveacutes del siguiente comando
Una vez instalado se puede crear un entorno virtual asociado a un proyecto de la siguiente forma
En este punto se creariacutea un entorno virtual para el proyecto deseado Ahora solo quedariacutea activarlo o iniciarlo
pip install nombre-del-paquete
pip install virtualenv
cd carpeta-del-proyecto
virtualenv ndashp usrbinpython27 mi-proyecto
source mi-proyectobinactivate
129
A13 Selenium y Chromedriver
La instalacioacuten de Selenium se realiza de la misma forma que el resto de paquetes con la herramienta ldquoPiprdquo
Por otra parte el controlador para el navegador Chrome Chromedriver puede ser descargado desde el
repositorio oficial httpschromedriverchromiumorg Ademaacutes Chromedriver debe ser accessible para
Selenium de cara a configurar el PATH
A14 Robot Framework y SeleniumLibrary
A continuacioacuten se realizariacutea la instalacioacuten de Robot Framework
Posteriormente se realizariacutea la instalacioacuten del paquete ldquoSelenium2Libraryrdquo el cual contiene la implementacioacuten
en python de las libreriacuteas necesarias para utilizar Robot Framework en Python
Llegados a este punto listando todos los paquetes instalados se deberiacutea tener algo similar a la siguiente figura
Con esta configuracioacuten del entorno este estariacutea preparado para elaborar los casos de prueba automatizados con
Robot Framework y Selenium
pip install selenium
export PATH=$PATHabsolute_path_of_chromedriver_file
pip install robotframework
pip install robotframework-selenium2library
130
A15 Otras dependencias
Para el desarrollo de pruebas que requieren otro tipo de herramientas como la transferencia de ficheros con el
servicio ldquoSCPrdquo o la conexioacuten remota a traveacutes del servicio ldquoSSHrdquo se require la instalacioacuten de los siguientes
paquetes
Ademaacutes para la realizacioacuten de pruebas avanzadas en Python para la gestioacuten del Mapa de la platform Web CHT
Cloud Manager se ha hecho uso de la librariacutea ldquohtml-testRunnerrdquo para ofrecer un reporte de la ejecucioacuten de
pruebas muy similar al ofrecido por Robot Framework
A2 Ejecucioacuten de Pruebas
Tras la implementacioacuten de las pruebas siguiendo el procedimiento indicado en la seccioacuten de Experimentos
ejecutar un script de pruebas se realiza mediante el uso del siguiente comando
Mediante el uso de la variable ldquoENVIROMENTrdquo puede seleccionarse el entorno en el que se desea ejecutar las
pruebas Con el entorno de ldquodebugrdquo las pruebas se ejecutariacutean de forma graacutefica mientras que el el entorno de
ldquodockerrdquo permite la ejecucioacuten de pruebas sin interfaz graacutefica Este uacuteltimo entorno seriacutea usado para la ejecucioacuten
de pruebas con el docker de Robot Framework que se ha implementado el cual se detallaraacute maacutes adelante
Por otro lado existen otras opciones para el comando anterio como por ejemplo
Las opciones ldquo-irdquo y ldquo-erdquo permiten ejecutar o excluir un caso de preuba en la ejecucioacuten de una Suite de pruebas
Por otro lado el uacuteltimo comando permite lanzar la ejcucioacuten de una Suite de pruebas y ejecutar soacutelo aquellos
casos de prueba que hayan fallado en la ejecucioacuten anterior
pip install robotframework-sshlibrary
pip install robotframework-scplibrary
pip install html-testRunner
robot --variable ENVIROMENTdebug_or_docker suite_filerobot
robot --variable ENVIROMENTdebug_or_docker ndashi U0000 suite_filerobot
robot --variable ENVIROMENTdebug_or_docker ndashe U0000 suite_filerobot
robot --rerunfailed outrerunfailedxml --output out2xml suite_filerobot
131
A continuacioacuten se muestra un ejemplo de ejecucioacuten de pruebas con Robot Framwork
132
A3 Script de Prueba U007 (MAP)
from selenium import webdriver
from seleniumwebdrivercommonby import By
from seleniumwebdriversupportui import WebDriverWait
from seleniumwebdriversupport import expected_conditions as EC
from seleniumwebdrivercommondesired_capabilities import DesiredCapabilities
from seleniumwebdrivercommonaction_chains import ActionChains
from seleniumcommonexceptions import TimeoutException
import math json multiprocessing time re
import sys
import unittest
import HtmlTestRunner
U0007 Double-click on Zone Manager and look if the Backend tab opens
class DClickZM(unittestTestCase)
driver = 0
canvas = 0
waitTime = 20
username = franciscodiaz
password = ahipeo8829g
classmethodg
def setUp(cls)
Enviroment Management
chrome_options = webdriverChromeOptions()
if sysargv[2] == docker
chrome_optionsadd_argument(--headless)
chrome_optionsadd_argument(--disable-extensions)
chrome_optionsadd_argument(--disable-gpu)
chrome_optionsadd_argument(--no-sandbox)
enable browser logging
d = DesiredCapabilitiesCHROME
d[loggingPrefs] = browser DEBUG
clsdriver = webdriverChrome(chrome_options=chrome_options desired_capabilities=d)
clsdrivermaximize_window()
clsdriverset_window_size(1920 1080)
load the desired webpage
clsdriverget(httpdevcloudgalgusnet)
def test_double_click_ZM(self)
loggin in the page
userNameBox = WebDriverWait(selfdriver 1)until(
ECpresence_of_element_located((ByXPATH [id=username])))
userNameBoxsend_keys(selfusername)
passwordBox = WebDriverWait(selfdriver selfwaitTime)until(
ECpresence_of_element_located((ByXPATH [id=password])))
passwordBoxsend_keys(selfpassword)
133
loginButton = WebDriverWait(selfdriver selfwaitTime)until(
ECpresence_of_element_located((ByXPATH
[id=myModalLabel]divdivformdiv[3]input)))
loginButtonclick() Tab General appears
selfcanvas = WebDriverWait(selfdriver selfwaitTime)
until(ECpresence_of_element_located((ByXPATH
htmlbodyappdivmaindivregister-
managersdivtabsetdivtab[1]aol-mapdivdivcanvas)))
timesleep(15)
action = ActionChains(selfdriver)
Manage Process
manager = multiprocessingManager()
return_dict = managerdict()
We create a Process
p_get_pixels_zm = multiprocessingProcess(target=selfGet_Pixels_ZM args=(return_dict selfdriver))
We create another Process
p_double_click_on_zm = multiprocessingProcess(target=selfDouble_Click_On_ZM args=(return_dict selfcanvas
action selfdriver))
We start the process and we block for 5 seconds
p_get_pixels_zmstart()
p_get_pixels_zmjoin(timeout=10)
p_double_click_on_zmstart()
p_double_click_on_zmjoin(timeout=10)
We terminate the process
p_get_pixels_zmterminate()
p_double_click_on_zmterminate()
try
Tab General appears
WebDriverWait(selfdriver 20)until(ECpresence_of_element_located(
(ByXPATH [id=app-sections]networktabsetulli[1]a)))
except TimeoutException
raise Exception(Cant Login in Zone Manager)
classmethod
def tearDown(cls)
clsdriverquit()
staticmethod
def Get_Pixels_ZM(return_dict driver)
return_dict[0] = 0
return_dict[1] = 0
regex = r(lt=c[-gt]cs)[wW]+(=)
while True
for entry in driverget_log(browser)
message = entry[message]
matches = refinditer(regex message reMULTILINE)
134
for matchNum match in enumerate(matches start=1)
try
p = matchgroup()replace( )
my_json = jsonloads(p)
if my_json[ZM] == Hotel MampM
return_dict[0] = my_json[top]
return_dict[1] = my_json[left]
break
except
pass
if return_dict[0] = 0 and return_dict[1] = 0
break
staticmethod
def Double_Click_On_ZM(return_dict canvasaction driver)
width = int(mathceil(float(return_dict[0])))
height = int(mathceil(float(return_dict[1])))
actionmove_to_element_with_offset(canvas width height)
actiondouble_click()
actionperform()
actiondouble_click()
actionperform()
driversave_screenshot(screenshot1png)
timesleep(5)
if __name__ == __main__
unittestmain(testRunner=HtmlTestRunnerHTMLTestRunner())
135
136
ANEXO B DOCKER DE ROBOT FRAMEWORK Y
ENTORNO DE UAT DOCKERIZADO
B1 Docker de Robot Framework
Para el entorno de UAT que se va a desarrollar se ha hecho uso de diferentes contenedores que han sido creados
por el equipo de desarrollo donde cada contenedor aloja un microservicio diferente de la plataforma
Para crear cada contenedor se ha hecho uso de Docker Esta herramienta permite crear contenedores ligeros y
portables para diferentes servicios que puedan ejecutarse en cualquier maacutequina con Docker instalado
independientemente del sistema operativo de la maacutequina que lo ejecute facilitando asi los despliegues
Mediante un fichero llamado ldquoDockerfilerdquo se definen los siguientes contenedores de servicios entre los cuales
se destacaraacute el fichero que define la creacioacuten del docker de Robot Framework el cual ha sido desarrollado por
el autor de este proyecto
Este contenedor ha sido creado sobre una imagen de Docker con el inteacuterprete de Python instalado Partiendo de
137
esta imagen se realiza la instalacioacuten de Robot Framework y las diferentes libreriacuteas y herramientas que se usaraacuten
en el proyecto para poder lanzar los Tests End-to-End
Ademaacutes se realiza la instalacioacuten de Google Chrome y Mozilla Firefox y la descarga de Chromedriver y
Geckodriver para poder lanzar los tests con dichos navegadores en modo headless Para el lanzamiento de los
test en modo headless se haraacute uso de la variable de entorno ldquoENVIROMENTrdquo definida en el anexo anterior
Finalmente se antildeade el proyecto de pruebas desarrollado para tener disponible las pruebas aumaacuteticas en el
contenedor
B2 Entorno de UAT Dockerizado
Para automatizar el despliegue de la plataforma Galgus CHT Cloud Manager con Docker se ha hecho uso de la
herramienta ldquodocker-composerdquo Esta herramienta permite simplificar el uso de Docker generando scripts que
facilitan el disentildeo y la construccion de servicios Con Docker Compose se pueden crear diferentes contenedores
y al mismo tiempo en cada contenedor diferentes servicios En la siguientefigura se muestra el fichero que
define el entorno de UAT con docker-compose
138
139
140
ANEXO C REVISIOacuteN DE REPORTES Y LOGS
C1 Reporte de Logs ofrecido por Robot Framework
Selenium no teniacutea la capacidad nativa de generar informes Este es uno de los motivos por el que se decidioacute
utilizar Robot Framework
Robot Framework genera tres archivos tras la ejecucioacuten de los scripts de pruebas A partir de la informacioacuten
contenida en el fichero ldquooutputxmlrdquo se rellenan las plantillas ldquohtmlrdquo del ldquologrdquo y del reporte El reporte permite
aplicar filtros a los resultados mientras que el ldquologrdquo contiene todos los detalles de la ejecucioacuten
A continuacioacuten se adjuntan las capturas de logs generados por los diferentes paquetes de pruebas desarrollados
C2 Cloud Tab
C21 Administration
141
142
C22 List
143
C23 Manufacturers
144
C24 MAP
145
C3 Configuration Tab
C31 BackupRestore
146
C32 CHT Zones
147
C33 Firmware
148
C34 Groups
149
150
C4 Network Tab
C41 General
151
C42 SSID
C43 CHT
152
C44 VLAN
153
C45 Radius
154
C46 Captive Portal
155
C47 AP Network
156
Como se ha visto reflejado en el conjunto de logs el tiempo total invertido en la ejecucioacuten ha sido de 1 hora 20
minutos y 22 segundos Dichas pruebas realizadas por una persona de forma manual hubiesen requerido como
miacutenimo el doble de tiempo Ya ni mencionar si se aplicase concurrencia en la ejecucioacuten de pruebas
157
ANEXO D DIAGRAMA DE GANTT
5
Trabajo de Fin de Maacutester Testeo automatizado de una plataforma Web de gestioacuten
Galgus CHT Manager
Autor Francisco Joseacute Diacuteaz Romero
Tutor Pablo Aguilera Bonet
Daniel Gutieacuterrez Reina
El tribunal nombrado para juzgar el Proyecto arriba indicado compuesto por los siguientes miembros
Presidente
Vocales
Secretario
Acuerdan otorgarle la calificacioacuten de
Sevilla 2020
El Secretario del Tribunal
6
7
A mi familia
A mis maestros
A mis amigos
8
9
Agradecimientos
10
11
Resumen
La revolucioacuten tecnoloacutegica que vivimos hoy diacutea enfocada principalmente en el mundo de Internet y aplicaciones
Web estaacute permitiendo que todas las herramientas que tenemos a nuestro alrededor se encuentren en un proceso
de tremenda evolucioacuten y cambio continuo
En este proyecto se ha realizado un estudio del arte sobre una teacutecnica que permite mejorar el proceso de
automatizacioacuten de pruebas sobre una aplicacioacuten Web basaacutendose en el modelado de la aplicacioacuten para
proporcionar una abstraccioacuten en la implementacioacuten de las pruebas Tambiacuteeacuten se ha realizado una revisioacuten de los
diferentes modelos de calidad normativas y tipos de prueba de Software Finalmente se ha desarrollado una
herramienta de test comprendida por un conjunto de pruebas de aceptacioacuten automaacuteticas que permiten la
verificacioacuten y validacioacuten de la funcionalidad de la plataforma Web Galgus CHT Cloud Manager
Galgus CHT Cloud Manager es la plataforma Web distribuida ofrecida por Galgus para la gestioacuten de redes
compuestas por puntos de acceso Wifi Estas redes se encuentran instaladas en los diferentes clientes que hacen
uso de los servicios que ofrece Galgus los cuales se basan en la optimizacioacuten del rendimiento y las prestaciones
de las redes Wifi en entornos de alta densidad de usuarios Esto se consigue mediante un software embebido
patentado por Galgus conocido bajo el nombre de Cognitive Hostpot Technology (CHT) el cual es instalado
en los puntos de acceso Dicho software implementa un conjunto de algoritmos y caracteriacutescas colaborativas
para conseguir los objetivos planteados en redes Wifi
Como resultado del trabjo podemos proporcionar a los ingenieros de pruebas una herramienta con la que poder
automatizar el testeo de una plataforma Web De esta forma se consigue agilizar el proceso de pruebas y reducir
costes y esfuerzos en tareas repetitivas que anteriormente se haciacutean de forma manual
12
13
Abstract
The technological revolution we are living today focused mainly on the Internet world and therewith the Web
applications is allowing all the tools we have around us to be in a process of continuous evolution and change
In this project we have made a study of the art on a technique that allows to improve the process of automation
of testing on a Web application based on the modelling of the application to provide an abstraction in the
implementation of testing A review of the different quality models standards and types of software testing has
also been carried out Finally a tool comprised of a set of automated acceptance tests has been developed to
allow verification and validation of the functionality of the Galgus CHT Cloud Manager Web platform
Galgus CHT Cloud Manager is the distributed web platform offered by Galgus for the management of
networks composed by Wifi access points These networks are installed in the different clients that make
use of the services offered by Galgus which are based on the optimization of the performance and features
of Wifi networks in high user density environments This is achieved through an embedded software
patented by Galgus known as Cognitive Hostpot Technology (CHT) which is installed in the access points
This software implements a set of algorithms and collaborative features to achieve the objectives set in Wifi
networks
This allows us to provide quality assurance engineers with a tool to automate the testing of a Web platform In
this way the testing process is streamlined and costs and efforts are reduced in repetitive tasks that previously
used to be done manually
14
15
Iacutendice
Agradecimientos 9
Resumen 11
Abstract 13
Iacutendice 15
Iacutendice de Figuras 19
Glosario 24
1 Introduccioacuten 27 11 Motivacioacuten 28 12 Alcance y Objetivos 29 13 Estructura de la memoria 30
2 Estudio del Arte y Revisioacuten 32 21 Model Based Testing (MBT) 32
211 Introduccioacuten 32 212 iquestQueacute es Model Based Testing 33 213 iquestCoacutemo funciona Model Based Testing 33 214 Consideraciones para la aplicacioacuten de Model Based Testing (MBT) 36 215 Beneficios de Model Based Testing (MBT) 37 216 Problemas y Limitaciones de Model Based Testing (MBT) 38 217 Cuando elegir Model Based Testing (MBT) 38
22 Gestioacuten de Calidad Software 39 221 Introduccioacuten 39 222 Concepto de Calidad 39 223 Modelos de Calidad de Software 40 224 Principales Ventajas e Inconvenientes de Modelos de Calidad anteriores 44 225 Conclusiones 44
3 Marco Teoacuterico Pruebas de Software 46 31 Testing y Pruebas de Software 46 32 Principios de las Pruebas de Software 47 33 Proceso de Pruebas de Software Anaacutelisis disentildeo e implementacioacuten 48
331 Terminologiacutea 48 332 Proceso de Pruebas de Software 49
34 Clasificacioacuten de Pruebas de Software 51 341 Pruebas Funcionales 51 342 Pruebas No Funcionales 52 343 Pruebas Estructurales 54 344 Pruebas debidas a Cambios 54
35 Niveles de Prueba 54 351 Pruebas a Nivel de Componente 55 352 Pruebas a Nivel de Integracioacuten 55 353 Pruebas a Nivel de Aceptacioacuten 55
16
36 Dificultades de pruebas en aplicaciones Web e impacto 56
4 Sistema Galgus CHT Cloud Manager 58 41 Arquitectura y Descripcioacuten del Sistema 58
411 Puntos de Acceso (OpenWRT + CHT) 60 412 Broacuteker de Eventos AMQP (RabbitMQ) 61 413 Frontend 62 414 Zone Manager 62 415 MoMap 63 416 Servidor de Licencias 64
42 Alcance y Objetivos de las pruebas sobre el sistema planteado 65 43 Arquitectura de la Solucioacuten Entorno de UAT para el proceso de pruebas (User Acceptance Test) 67
5 Tecnologiacuteas y Herramientas Usadas 69 51 Selenium 69 52 Selenium WebDriver 70
521 Elementos del Navegador 70 53 Robot Framework (RF) 72
531 Estilo de representacioacuten Given-When-Then 72 532 Reportes 75 533 Libreriacuteas 76 534 Documentacioacuten 77
54 Pycharm (IDE) 78 55 GitGitlab 78
551 Git 78 552 Gitlab 78
56 Redmine 78 561 Uso en el Proyecto Galgus CHT Cloud Manager (Metodologiacutea Scrum) 79
6 Experimentos 82 61 Estructura del Proyecto 83 62 Vista de Gestioacuten Principal (Cloud Tab) 87
621 Administration 87 622 List 89 623 Manufacturer 90 624 MAP 92
63 Vista de Configuracioacuten (Configuration Tab) 95 631 Groups 95 632 CHT Zones 98 633 BackupRestore 100 634 Firmware 101
64 Vista de Red (Network Tab) 104 641 VLANS amp Bridges 104 642 SSIDs 106 643 CHT 108 644 Radius 110 645 Captive Portal 112 646 General 115 647 AP Network 117
7 Lineas de Mejora y Conclusiones 122 71 Liacuteneas de Mejora Futuras 122 72 Conclusiones Finales 123
Referencias 126
17
Anexo A Preparacioacuten del Entorno de Trabajo y Ejecucioacuten de Pruebas 128 A1 Preparacioacuten del entorno de trabajo 128
A11 Pip 128 A12 Virtualenv Entorno Virtual 128 A13 Selenium y Chromedriver 129 A14 Robot Framework y SeleniumLibrary 129 A15 Otras dependencias 130
A2 Ejecucioacuten de Pruebas 130 A3 Script de Prueba U007 (MAP) 132
Anexo B Docker de Robot Framework y Entorno de UAT Dockerizado 136 B1 Docker de Robot Framework 136 B2 Entorno de UAT Dockerizado 137
Anexo C Revisioacuten de Reportes y Logs 140 C1 Reporte de Logs ofrecido por Robot Framework 140 C2 Cloud Tab 140
C21 Administration 140 C22 List 142 C23 Manufacturers 143 C24 MAP 144
C3 Configuration Tab 145 C31 BackupRestore 145 C32 CHT Zones 146 C33 Firmware 147 C34 Groups 148
C4 Network Tab 150 C41 General 150 C42 SSID 151 C43 CHT 151 C44 VLAN 152 C45 Radius 153 C46 Captive Portal 154 C47 AP Network 155
Anexo D Diagrama de Gantt 157
18
19
IacuteNDICE DE FIGURAS
Figura 1 Fuente de datos Morgan Stanley 27
Figura 2 Manual Testing vs Automated Testing [20] 28
Figura 3 Fase de Pruebas y Validacioacuten 32
Figura 4 Esquema baacutesico de Model Based Testing 33
Figura 5 Proceso detallado de Model Based Testing (MBT) 34
Figura 6 Construccioacuten del Modelo 34
Figura 7 Concepto de Calidad 39
Figura 8 Liacutenea de tiempo de modelos a nivel de proceso 40
Figura 9 Logo de ITIL 40
Figura 10 ISOIEC 20000 41
Figura 11 Logo de WebQEM 41
Figura 12 Liacutenea de tiempo de modelos a nivel de producto 42
Figura 13 Esquema de ISO 9126 42
Figura 14 Esquema de ISOIEC 25000 43
Figura 15 Principios de las Pruebas de Software 47
Figura 16 Terminologiacutea para el proceso de pruebas 48
Figura 17 Proceso de Pruebas de Software 49
Figura 18 Clasificacioacuten de Pruebas de Software 51
Figura 19 Pruebas de Caja Negra 51
Figura 20 Pruebas de Rendimiento 52
Figura 21 Pruebas de Carga 52
Figura 22 Pruebas de Estreacutes 52
Figura 23 Pruebas de Usabilidad 53
Figura 24 Pruebas de Portabilidad 53
Figura 25 Pruebas de Caja Blanca 54
Figura 26 Modelo de desarrollo en V 55
Figura 27 Dificultades de pruebas en aplicaciones Web e impacto 56
Figura 28 Logo de Galgus 58
Figura 29 Arquitectura de CHT Cloud Manager 59
Figura 30 CHT_CLI 60
Figura 31 Plataforma de Gestioacuten de RabbitMQ 61
Figura 32 Patroacuten PublicadorSuscriptor 61
Figura 33 Ejemplo de Interfaz Graacutefica de un Zone Manager 62
Figura 34 Ejemplo de Interfaz Graacutefica de MoMap 63
20
Figura 35 Interfaz Graacutefica del Servidor de Licencias 64
Figura 36 Zero-Touch Provisioning (ZTP) 64
Figura 37 Test Plan de CHT Cloud Manager 65
Figura 38 Leyenda del Test Plan 66
Figura 39 Control de Versiones del Test Plan 66
Figura 40 Entorno de UAT con Docker (Anexo B) 67
Figura 41 Implementaciones disponibles de Selenium y Navegadores Web Compatibles 70
Figura 42 Coacutedigo de ejemplo con Python y Selenium 71
Figura 43 Estilo de representacioacuten Given-When-Then 72
Figura 44 Implementacioacuten de Pruebas en para el inicio de sesioacuten de CHT Cloud Manager 74
Figura 45 Ejemplo de reporte de pruebas automatizadas con Robot Framework 75
Figura 46 Ejemplo de documentacioacuten generada con Libdoc 77
Figura 47 Ejemplo de documentacioacuten generada con Testdoc 77
Figura 48 Ejemplo de Flujo de Trabajo en Redmine para Galgus CHT Cloud Manager 79
Figura 49 Esquema Graacutefico de Metodologiacutea Scrum 79
Figura 50 Logo de Galgus CHT Cloud Manager 82
Figura 51 Estructura del Proyecto 83
Figura 52 Fragmento del fichero ldquoSelectorpyrdquo 83
Figura 53 Fragmento del fichero ldquoCommon_Keywordsrobotrdquo 84
Figura 54 Fragmento del fichero de Configuracioacuten de pruebas ldquoConfigurationrobotrdquo 84
Figura 55 Diagrama de paquetes del proyecto de pruebas 85
Figura 56 Estructura de una Suite de Pruebas 85
Figura 57 Ejemplo de ldquoTest Setuprdquo personalizado para un caso de prueba 86
Figura 58 Vista de Gestioacuten Principal (Cloud Tab) 87
Figura 59 Pestantildea ldquoAdministrationrdquo 87
Figura 60 Diagramas de Flujo de Casos de Prueba U0025 y U0027 88
Figura 61 Script de Pruebas U0025 88
Figura 62 Keyword ldquoEdit Fieldsrdquo 88
Figura 63 Pestantildea ldquoList of Zone Managersrdquo 89
Figura 64 Diagrama de flujo de Caso de Prueba U0023 89
Figura 65 Script de Prueba U0023 90
Figura 66 Keyword ldquoZone Manager is registered successfullyrdquo 90
Figura 67 Seccioacuten de Fabricantes 90
Figura 68 Diagrama de flujo de Caso de Prueba U0009 91
Figura 69 Script de Prueba U0009 91
Figura 70 Toast Success 92
Figura 71 Keyword ldquoCorrectly Createrdquo 92
Figura 72 Setup amp Teardown de U0008 92
21
Figura 73 Mapa de Zone Managers 92
Figura 74 Funcioacuten que dibuja los ZM en el Mapa y obtiene los piacutexeles en pantalla 93
Figura 75 Diagrama de Flujo de Caso de Prueba U0007 94
Figura 76 Pestantildea ldquoGroupsrdquo 95
Figura 77 Diagrama de flujo de Caso de Prueba U0119 96
Figura 78 Script de Prueba U0119 97
Figura 79 Keyword ldquoVerify if AP is registered Succesfully on grouprdquo 97
Figura 80 Keywords Input Into Text Field y Clear Field Of Characters 97
Figura 81 Pestantildea ldquoCHT Zonesrdquo 98
Figura 82 Diagrama de Flujo de Caso de Prueba U0204 99
Figura 83 Scripts de Prueba U0204 99
Figura 84 Keyword Add Zone CHT to AP 99
Figura 85 Pestantildea BackupRestore 100
Figura 86 Diagrama de Flujo de Caso de Prueba U0401 101
Figura 87 Script de Prueba U0401 101
Figura 88 Keyword Restore For AP hace done successfully 101
Figura 89 Pestantildea ldquoFirmwarerdquo 102
Figura 90 Diagrama de Flujo de Caso de Prueba U0303 103
Figura 91 Script de Prueba U0303 103
Figura 92 Keyword Flash AP 103
Figura 93 Pestantildea ldquoVLAN amp Bridgesrdquo 104
Figura 94 Diagrama de Flujo de Caso de Prueba U0527 105
Figura 95 Script de Prueba U0527 105
Figura 96 Keyword Go And Create VLAN 105
Figura 97 Pestantildea SSIDs 106
Figura 98 Diagrama de Flujo de Caso de Prueba U0530 106
Figura 99 Script de Prueba U0530 107
Figura 100 Keyword Go And Create SSID 107
Figura 101 Pestantildea ldquoCHTrdquo 108
Figura 102 Diagrama de Flujo de Caso de Prueba U0539 109
Figura 103 Script de Prueba U0539 109
Figura 104 Keyword ACA Is Working 109
Figura 105 Keyword Changes On CLI 110
Figura 106 Comando CHT para obtener el estado del moacutedulo ACA en el punto de acceso 110
Figura 107 Pestantildea ldquoRadiusrdquo 110
Figura 108 Escenario de Funcionamiento de Servidor Radius 110
Figura 109 Diagrama de Flujo de Caso de Prueba U0601 111
Figura 110 Script de Prueba U0601 111
Figura 111 Keyword Create Radius Profile 112
22
Figura 112 Pestantildea Captive Portals 112
Figura 113 Escenario de Funcionamiento de un Portal Cautivo 112
Figura 114 Diagrama de Flujo de Caso de Prueba U0701 113
Figura 115 Script de Prueba U0701 113
Figura 116 Keyword Edit or Delete Captive Portal Profile 114
Figura 117 Pestantildea General 115
Figura 118 Diagrama de Flujo de Caso de Prueba U0522 116
Figura 119 Script de Prueba U0522 116
Figura 120 Keyword Check Number of Clients Increases 116
Figura 121 Pestantildea AP Network 117
Figura 122 Libreriacutea SSH para Robot Framework 117
Figura 123 Ventana de Configuracioacuten de TC Rules 118
Figura 124 Diagrama de Flujo de Caso de Prueba U0511 119
Figura 125 Script de Prueba U0511 120
Figura 126 Keyword Wait Timer 120
Figura 127 Keyword Check On CLI 120
23
24
GLOSARIO
CHT Cognitive Hostpot Technology
BDD Behaviour-Driven Development
MBT Model Based Testing
API Application Programing Interface
UAT User Acceptance Testing
SUT System Under Test
UML Unified Modeling Language
FSM Finite State Machine
RAE Real Academia Espantildeola
IEEE Institute of Electronical and Electronics Engineers
ITIL Information Technology Infrastructure Library
ISO International Organization for Standardization
WebQEM Web-site Quality Evaluation method
ISTQB International Software Testing Qualifications Board
TDD Test-Driven Development
SOA Service Oriented Architecture
WiFi Wireless Fidelity
MGR Manager Module
SB Smart Band Steering Module
TCM Traffic Congestion Management Module
LOC Localization Module
POWER Power Control Module
SR Smart Roaming Module
LB Load Balancing Module
AMQP Advance Message Queuing Protocol
HTML HyperText Markup Language
CSS Cascading Style Sheets
HTTPS HyperText Transfer Protocol Secure
TLS Transport Layer Security
REST REpresentational State Transfer
JSON JavaScript Object Notation
DOM Document Object Model
SQL Structure Query Language
ZMB Zone Manager Backend
ZTP Zero-Touch Provisioning
25
RF Robot Framework
CICD Continuous IntegrationContinuous Delivery
SSH Secure SHell
SCP Secure Copy ProtocolSimple Communication Protocol
26
27
1 INTRODUCCIOacuteN
ctualmente el desarrollo software se encuentra en un proceso revolucionario cuyo principal objetivo y
tendencia es la implantacioacuten y desarrollo de software distribuido donde se marcan como principales
objetivos la disponibilidad usabilidad y funcionalidad de cualquier aplicacioacuten a traveacutes de internet Es
aquiacute donde entran en juego entre otros el desarrollo de aplicaciones o servicios Web sustituyendo en gran
medida al desarrollo de aplicaciones y servicios de escritorio
Figura 1 Fuente de datos Morgan Stanley
Muchos son los aspectos a tener en cuenta entre los que cabe destacar la eficiencia la velocidad de respuesta y
de navegacioacuten los cuales para algunos servicios Web son excelentes pero para otros auacuten se encuentran en un
proceso de mejora Esto es debido a que gran cantidad de aplicaciones requieren de un buen disentildeo donde se
optimicen el uso de los recursos disponibles como el ancho de banda memoria carga del servidor respaldo
seguridad etc
A
Hemos establecido la civilizacioacuten de manera que los
maacutes cruciales elementos dependen de la ciencia y la
tecnologiacutea
Carl Sagan
28
11 Motivacioacuten
La gran demanda de servicios y aplicaciones Web distribuidas que permitan gestionar agilizar y simplificar
cualquier aacutembito de negocio hace que cada vez maacutes que dichas aplicaciones contemplen un mayor
conjunto de requisitos solicitados por los clientes lo cual se traduce en un mayor nuacutemero de funcionalidades
y casos de uso contemplados en dichas aplicaciones
Ademaacutes dichas aplicaciones se necesitan cada vez en un menor tiempo lo cual conlleva a reducir los
periodos en las diversas fases por las que pasa un proyecto software desde la fase de disentildeo hasta la de
pruebas Es en esta uacuteltima donde antes de ser entregada al cliente como un producto se detectan los
posibles errores e incluso se puede evaluar si la funcionalidad ofrecida por la aplicacioacuten esta alineada con
los requisitos demandados por el cliente
Los fallos o errores en las aplicaciones Web mal probadas bien por falta de asignacioacuten de tiempo o recursos
a la fase de pruebas tienen una mayor repercusioacuten teniendo el potencial de generar una gran cantidad de
quejas e insatisfaccioacuten por parte de los clientes casi inmediatamente En el caso de las aplicaciones Web
no soacutelo se trata de peacuterdidas econoacutemicas sino tambieacuten de peacuterdida de prestigio fiabilidad y credibilidad por
parte de nuestros usuarios o clientes Los consumidores de hoy demandan una tecnologiacutea intuitiva y de
confianza en un mercado en continuo crecimiento donde un pequentildeo error puede acarrear falta de
satisfaccioacuten en un usuario peacuterdidas millonarias a una empresa o incluso dantildeos humanos Y es en este tipo
de ciclos iterativos y raacutepidamente cambiantes donde la automatizacioacuten de pruebas juega un papel decisivo
iquestY cuaacutel es la causa de estos problemas Para ello debemos tener en cuenta que estos sistemas son disentildeados
por el ser humano el cual comete fallos ya sea por presioacuten en los plazos de trabajo por la complejidad del
coacutedigo o de la infraestructura por cambios de tecnologiacuteas o por cualquier otra interaccioacuten con el sistema
Como ha quedado reflejado un proceso riguroso de control de sistemas y documentacioacuten permiten
bull Ayudar a reducir el riesgo de los posibles fallos y Mejora la calidad de los sistemas a la hora de ser
usados
bull Un correcto mantenimiento del producto a lo largo del ciclo de desarrollo
bull Un cumplimiento de requisitos legales (normas nacionales e internacionales ordenanzas
municipales etc)
bull Una adecuacioacuten de un sistema a los requisitos contractuales
bull Una adaptacioacuten de estaacutendars especiacuteficos de la industria
La forma en la que se logre y las herramientas empleadas variaraacuten en funcioacuten de factores como la
envergadura y tipo de proyecto den cuanto a los riesgos tecnoloacutegicos de seguridad o de negocio asiacute como
del presupuesto y tiempo disponible
Figura 2 Manual Testing vs Automated Testing [20]
29
12 Alcance y Objetivos
Las pruebas de software o software testing pueden llevarse a la praacutectica de muacuteltiples maneras pero el
presente proyecto se centra en el componente funcional del producto enfocado en lo que hace el sistema y
no coacutemo primando la aceptacioacuten por parte de los usuarios en base a los requisitos de disentildeo originales Es
decir el punto de mira estaacute en cumplir los requisitos establecidos por el cliente dejando fuera del alcance
del proyecto la estructura del coacutedigo fuente implementado
Bajo este contexto se plantea la automatizacioacuten de la fase de pruebas de una aplicacioacuten Web distribuida
centrando el enfoque de este proyecto en la automatizacioacuten de pruebas funcionales maacutes concretamente
pruebas de humo or smoke tests y aceptacioacuten Hasta ahora dichas pruebas se realizaban manualmente por
un ingeniero de pruebas lo cual permitiacutea evaluar la calidad del producto que seriacutea entregado al cliente
Ademaacutes se realizaraacute un marco teoacuterico donde se resumiraacuten una clasificacioacuten de los diferentes tipos de
pruebas software que pueden realizarse sobre una aplicacioacuten
Concretamente la solucioacuten abordada en esta memoria se cintildee al mantenimiento de un producto Web como
es la plataforma Galgus CHT Cloud Manager Para ello se cubriraacuten un gran conjunto de funcionalidades
ofrecidas por dicha aplicacioacuten Web como por ejemplo inicio y cierre de sesioacuten flujos de navegacioacuten
comprobacioacuten de los elementos mostrados y uso de la caja de buacutesquedas Sin llegar a ser exhaustivos este
tipo de pruebas conocidas como smoke tests son faacutecilmente automatizables y permiten detectar las primeras
sentildeales de que un sistema no funciona de manera correcta Por tanto es necesario traducir los requisitos
funcionales a instrucciones de alto nivel faacutecilmente entendibles por personas con poca formacioacuten teacutecnica
dado que seraacute el el resultado mostrado de las pruebas realizadas (informes de pruebas) Estas instrucciones
usaraacuten Behaviour-Driven Development (BDD) para describir interacciones entre el usuario y el sistema
definiendo actor accioacuten y comportamiento esperado del sistema Robot Framework es la herramienta que
se usa para este punto
Una vez tenemos dichas instrucciones se deben traducir de nuevo a un lenguaje de menor nivel como es
Python para implementar los test scripts Estos scripts seraacuten los que Selenium Webdriver procese y traduzca
para comunicarse con el controlador del navegador Web Chrome en nuestro caso a traveacutes de una API
Posteriormente el navegador se encargaraacute de ejecutar los comandos de accioacuten y de devolver la informacioacuten
de estado de vuelta Finalmente Robot Framework elaboraraacute un informe en formato html detallando las
pruebas realizadas resultados de las interacciones tiempos de ejecucioacuten y espera errores producidos etc
Tambieacuten se realizaraacute un estudio del arte sobre una teacutecnica conocida como Model Based Testing (MBT)
Dicha teacutecnica permite la generacioacuten automaacutetica de las pruebas a realizar sobre un sistema partiendo del
modelado del comportamiento de dicho sistema Ademaacutes esta teacutecnica tambieacuten abarca la traduccioacuten de las
pruebas generadas en scripts ejecutables para aplicar dichas pruebas sobre el sistema dando tambiacuteeacuten la
posibilidad de evaluar los resultados Esto proporciona muchas ventajas sobre la fase de pruebas pero a la
vez tambieacuten requiere un mayor esfuerzo en la fase de disentildeo y una presencia continua de la fase de pruebas
en otras etapas del ciclo de vida del proyecto Tambieacuten se presentaraacute un conjunto de normativas que regula
y normaliza la gestioacuten de calidad software
Posteriormente se describiraacute el sistema sobre el cual se basa la aplicacioacuten bajo pruebas llamada CHT
Cloud Manager Se presentaraacute la arquitectura de la aplicacioacuten y posteriormente se destacaraacuten los objetivos
de automatizacioacuten de testeo sobre la misma proponiendo el entorno de UAT planteado para someter la
aplicacioacuten a las pruebas automaacuteticas desarrolladas Se dedicaraacute una seccioacuten a analizar las tecnologiacuteas y
herramientas usadas donde se centraraacute la atencioacuten en Robot Framework Selenium y Python como las
tecnologiacuteas usadas para automatizar el testeo Ademaacutes se destacaraacute la integracioacuten del entorno de UAT
como fase de la integracioacuten continua de la aplicacioacuten ademaacutes de la metodologiacutea de trabajo llevada a cabo
Finalmente se presentaraacuten algunos experimentos y demostraciones de uso de la herramienta desarrollada
se describiraacuten algunas liacuteneas de mejora y conclusiones y se incluiraacuten algunos posibles anexos para la puesta
en marcha de la aplicacioacuten y reportes de algunas pruebas entre otros
30
13 Estructura de la memoria
El siguiente esquema resume de forma geneacuterica los puntos tratados en esta memoria para que el lector pueda
tener una idea orientativa de la organizacioacuten de este documento
1 Introduccioacuten En este punto se abordan temas geneacutericos como los objetivos motivacioacuten y alcance de
forma que pueda adquirirse una breve aproximacioacuten a los detalles del proyecto
2 Estudio del Arte y Revisioacuten A lo largo de esta seccioacuten se presentaraacute un estudio sobre la teacutecnica
conocida como Model Based Testing la cual permitiriacutea mejorar el proceso de automatizacioacuten de
pruebas Ademaacutes se realiza una revisioacuten sobre la gestioacuten de Calidad Software presentado algunos
modelos existentes en la actualidad
3 Marco Teoacuterico Consta de un estudio sobre el proceso de pruebas en un proyecto Software y los
principales tipos de pruebas Software existentes
4 Sistema En este punto se presenta la arquitectura del sistema sobre el que se van a automatizar las
pruebas de aceptacioacuten o Smoke Tests Ademaacutes se describe el alcance y objetivos de dichas pruebas y
se presenta la arquitectura de la solucioacuten planteada como escenario de pruebas haciendo uso de Docker
como tecnologiacutea de automatizacioacuten en el despliegue de aplicaciones software alojadas en contenedores
de software
5 Tecnologiacuteas y Herramientas usadas Consta del conjunto de tecnologiacuteas usadas para la
implementacioacuten de las pruebas de aceptacioacuten automatizadas y las herramientas para utilizar dichas
pruebas y para gestionar el trabajo del equipo de desarrollo y calidad responsable de este proyecto
6 Experimentos Consta de un detalle sobre la funcionalidad de un conjunto de pruebas que han sido
implementadas para verificar y validar el funcionamiento esperado del sistema Para cada prueba se
definen criterios de aceptacioacuten diagramas de flujo y scripts de implementacioacuten detallando algunas de
las implementaciones clave
7 Liacuteneas de Mejora y Conclusiones Se incluye una seccioacuten conclusiones finales tras la realizacioacuten del
proyecto y una valoracioacuten del mismo a nivel general y personal Ademaacutes se destacaraacuten algunas liacuteneas
de mejora futuras relacionadas principalmente con la aplicacioacuten de Model Based Testing (MBT) y otros
aspectos sobre la implementacioacuten actual de la herramienta de automatizacioacuten
Ademaacutes se realizaraacute una seccioacuten de anexos en el que se trataraacuten puntos adicionales sobre el proyecto
bull Anexo A Preparacioacuten del Entorno de Trabajo y Ejecucioacuten de Pruebas
bull Anexo B Docker de Robot Framework y Entorno de UAT Dockerizado
bull Anexo C Revisioacuten de Reportes y Logs
31
32
2 ESTUDIO DEL ARTE Y REVISIOacuteN
n este punto se realizaraacute un estudio sobre el marco teoacuterico de una de las teacutecnicas existentes que permite
la generacioacuten y ejecucioacuten automaacutetica de casos de test a partir del modelado de un sistema para la fase
de pruebas de una aplicacioacuten Esta teacutecnica es conocida como Model Based Testing (MBT) Ademaacutes
se realizaraacute una revisioacuten de la normativa relacionada con la gestioacuten de calidad software analizando la familia de
normas ISOIEC 25000
21 Model Based Testing (MBT)
211 Introduccioacuten
Dada la rapidez con la que se demandan los servicios contratados por los clientes en muchas ocasiones la
mayoriacutea del tiempo y esfuerzo asignado para la realizacioacuten de proyectos de software van destinados a la
labor de desarrollo dedicando menos esfuerzos en otras fases del ciclo de vida de un proyecto como las
fases de disentildeo o de pruebas Esto puede conllevar a que el proyecto no se desarrolle de acuerdo con los
requisitos demandados por los clientes y que el nuacutemero de puntos de fallo del producto software aumente
La fase de testeo o prueba de un producto software durante su ciclo de vida es una etapa fundamental para
validar la calidad del producto desarrollado y ofrecido a un cliente para conseguir un grado de satisfaccioacuten
aceptable de forma que se cumpla con los requisitos demandados y con el menor grado de error posible
Figura 3 Fase de Pruebas y Validacioacuten
Uno de los factores por los que en ocasiones no se emplean suficientes recursos a la fase de pruebas es la
gran cantidad de casos de pruebas que se deben realizar para validar un sistema Por cada caso de prueba
se deben asignar recursos relacionados con la planificacioacuten disentildeo y ejecucioacuten del mismo
Por tanto en este punto cabe plantearse la idea de automatizar no solo los casos de pruebas que validan un
sistema sino la generacioacuten de los casos de prueba Esto puede permitir reducir de forma considerable el
coste y esfuerzos en la fase de pruebas En este contexto surge el concepto de Model Based Testing (MBT)
E
La tecnologiacutea no es en siacute el fin sino el medio entre la
sociedad del conocimiento y el desarrollo mundial
Anoacutenimo
33
212 iquestQueacute es Model Based Testing
Este se trata de un meacutetodo capaz de controlar la calidad del software durante su ciclo de vida permitiendo
la generacioacuten automaacutetica de los casos de prueba e incluso la ejecucioacuten y evaluacioacuten automaacutetica de
resultados Para ello se requiere de un modelado y disentildeo correcto del sistema bajo pruebas como base
para la aplicacioacuten de esta teacutecnica
Figura 4 Esquema baacutesico de Model Based Testing
MBT permite crear un modelo del comportamiento esperado por el sistema a traveacutes del cual permite la
aplicacioacuten de diferentes teacutecnicas para la generacioacuten de casos de prueba [1]
bull Generacioacuten de casos de pruebas con datos de entrada sobre un modelo de dominio del sistema bull Generacioacuten de casos de pruebas de un modelo de entorno bull Generacioacuten de casos de prueba con predicciones del comportamiento del modelo bull Generacioacuten de scripts de prueba a partir de pruebas abstractas
213 iquestCoacutemo funciona Model Based Testing
En primer lugar se requiere del disentildeo de un modelo del sistema bajo test el cual debe tener al menos dos
caracteriacutesticas principales debe ser pequentildeo en relacioacuten al tamantildeo del sistema de forma que no requiera
un coste elevado pero debe ser lo suficientemente detallado para describir completamente las
caracteriacutesticas que se quieran probar sobre el sistema
Una vez implementado el modelo del sistema a probar se procederiacutea a la utilizacioacuten de herramientas
basadas en la teacutecnica MBT para generar automaacuteticamente el banco de pruebas a partir del modelo del
sistema bajo test (SUT) Estos bancos de pruebas generados seraacuten un conjunto de pruebas abstractas cada
una de las cuales define la secuencia de operaciones a realizar para probar una funcionalidad determinada
con sus respectivos valores o datos de entrada necesarios y las salidas o respuestas del sistema que se
esperan
A partir del banco de pruebas abstractas se deben transformar en scripts de pruebas ejecutables lo cual
puede realizarse con herramientas basadas en la teacutecnica MBT Estos scripts podriacutean ser ejecutados para la
deteccioacuten de errores sobre el sistema bajo test y esta ejecucioacuten podriacutea ser controlada y monitorizada por
alguna herramienta de ejecucioacuten de pruebas
En el siguiente diagrama se muestra el proceso de aplicacioacuten de este meacutetodo donde se propone dividir el
proceso en cinco fases principales [1]
1 Modelado Modelar el sistema bajo test y su entorno 2 Generacioacuten Generar las pruebas abstractas a partir del modelo planteado en la fase anterior 3 Concretizado Concretizar o adaptar las pruebas abstractas para transformarlas en ejecutables 4 Ejecucioacuten Ejecutar las pruebas sobre el sistema bajo test y definir decisiones o veredictos para las
mismas de forma que se pueda determinar el correcto funcionamiento del sistema bajo test 5 Anaacutelisis Analizar los resultados obtenidos a partir de la ejecucioacuten de los casos de prueba
34
Destacar que para el generador de casos de prueba y el script de pruebas se suelen usar herramientas de pruebas
especiales Por este motivo se encuentran resaltados en negrita
Figura 5 Proceso detallado de Model Based Testing (MBT)
Una vez presentado el proceso o metodologiacutea para llevar a cabo dicha teacutecnica se describiraacuten las principales
fases
2131 Construccioacuten del Modelo
Dicha fase consiste en la construccioacuten de un modelo que represente el comportamiento detallado del sistema
bajo pruebas yo su entorno a partir de los requisitos de disentildeo del mismo y el plan de pruebas desarrollado para
cumplir con estos requisitos
Este es el paso maacutes importante en la aplicacioacuten de la teacutecnica Model Based Testing ya que el resto de fases
dependeraacute siempre del modelo del sistema bajo pruebas Cuanto maacutes completo sea el modelo maacutes efectivos
seraacuten los casos de prueba generados a partir de este
Figura 6 Construccioacuten del Modelo
35
Para llevar a cabo el modelo del comportamiento de la aplicacioacuten se requiere conocer exactamente el
comportamiento esperado de la misma lo cual lleva a estudiar y analizar en profundidad el sistema y su entorno
previamente
Existen diversas especificaciones formales para el modelado a partir de los requisitos como por ejemplo los
diagramas UML Estos ayudan a que el modelado sea una tarea algo maacutes sencilla de realizar que si se llevara a
cabo a partir de los requisitos escritos en lenguaje natural Por otro lado para modelar el comportamiento existen
diversas teacutecnicas como las maacutequinas de estados finitos (FSM) Cadenas de Maacuterkov Tablas de decisiones
Diagramas de estados etc
En conclusioacuten modelar un sistema no es una tarea sencilla ya que requiere de habilidades teacutecnicas experiencia
e imaginacioacuten para construir un modelo que se comporte de la forma deseada Dicho modelo debe cumplir con
las siguientes propiedades [2]
bull Debe ser lo maacutes abstracto posible sin perder la informacioacuten importante
bull No debe contener informacioacuten que sea redundante o que no esteacute relacionada con el alcance de las
pruebas
bull Debe ser entendible para los ingenieros de pruebas incluso a expensas de la brevedad y abstraccioacuten del
mismo
bull Debe ser flexible y abierto para permitir cambios y antildeadir o eliminar nuevas funcionalidades
bull Debe considerar todos los detalles de implementacioacuten de las pruebas
2132 Generacioacuten de Casos de Prueba
Los casos de prueba seraacuten generados tras la construccioacuten previa del modelo del sistema Antes de la creacioacuten de
los casos de prueba los ingenieros de pruebas deben especificar o proveer informacioacuten sobre el criterio o
propoacutesito de los casos de prueba las entradas y en algunos casos las salidas esperadas del sistema
Destacar que generar las salidas esperadas correspondientes a unas determinadas entradas es maacutes complejo que
generar soacutelo las entradas Para ello se necesita un oraacuteculo que cree salidas vaacutelidas y las mapee a los casos de
prueba Crear el oraacuteculo es la tarea maacutes compleja
Las dificultades presentadas en esta fase dependeraacuten de si el modelo es complejo o simple y la efectividad de
los casos de prueba generados dependeraacute de lo completo y preciso que sea dicho modelo para poder generar
automaacuteticamente los casos de prueba
Cuando el sistema es complejo la cantidad de casos de test es muy grande e incluso infinita Por tanto evaluar
todos los casos de test resulta inviable y costoso En este caso para mejorar la calidad del sistema se necesita
seleccionar los casos de test que realmente puedan ayudar a localizar tantos fallos como sea posible con un coste
aceptable
Existen diferentes criterios de cobertura que permiten ayudar a controlar el proceso de generacioacuten de casos de
prueba Sin embargo se recomienda seleccionar maacutes de uno de estos criterios para lograr un mayor resultado en
la cobertura de pruebas
2133 Ejecucioacuten de Casos de Prueba
La ejecucioacuten de los casos de pruebas requiere la transformacioacuten de los mismos en una forma ejecutable Debido
a que los los scripts de pruebas ejecutables pueden ser reutilizados durante todo el tiempo empleado en la
validacioacuten del sistema estos deben ser escritos de una forma maacutes eficiente que permita que sean reutilizables e
incluso que frente a una modificacioacuten sean maacutes faacuteciles generarlos y ejecutarlos Por ello se crean scripts
ejecutables para los casos de prueba abstractos
El proceso de transformacioacuten en pruebas ejecutables seriacutea maacutes eficiente si es hecha de forma automaacutetica
Despueacutes de aplicar los casos de prueba ejecutables al sistema bajo pruebas se obtienen las salidas actuales del
sistema las cuales deberaacuten ser contrastadas con las salidas esperadas
36
2134 Anaacutelisis de los Resultados
Una vez ejecutados los casos de pruebas y obtenidas las salidas actuales del sistema se deben evaluar y analizar
los resultados obtenidos Para ello se debe comparar las salidas actuales obtenidas con las salidas esperadas
especificadas en los casos de prueba Esta tarea de comparacioacuten podriacutea realizarse idealmente de forma
automaacutetica lo cual dariacutea como resultados posibles
1 Pasa Cuando las salidas actuales se encuentran acordes con las salidas esperadas
2 Falla Cuando las salidas actuales no se encuentran acordes con las salidas esperadas
3 Inconcluso Cuando no se puede tomar una decisioacuten en el momento
Hay que destacar que puede darse el caso en el que si las salidas esperadas no estaacuten bien determinadas los
resultados obtenidos al contrastar dichas salidas con las actuales sean falsos dando lugar a resultados sin utilidad
y que pueden dar lugar a confusioacuten
Por este motivo la generacioacuten automaacutetica de las salidas esperadas es una tarea compleja e importante en todo el
proceso especialmente en sistemas complejos Por tanto el nivel de dificultad para encontrar un oraacuteculo de
pruebas depende del tamantildeo y complejidad del sistema Sin embargo la necesidad e importancia del oraacuteculo de
pruebas tambieacuten aumenta cuando el sistema es maacutes complejo
Tras obtener los resultados se debe determinar si se decide generar maacutes casos de prueba si se debe modificar el
modelo o si la fase de pruebas debe ser detenida y debe ponerse en marcha el software del sistema que se estaacute
probando
214 Consideraciones para la aplicacioacuten de Model Based Testing (MBT)
Son muchos los artiacuteculos que describen aspectos importantes a tener en cuenta durante el desarrollo o la
aplicacioacuten de esta teacutecnica Algunas de estas consideraciones a destacar seriacutean las siguientes [3]
1 El modelo que describe el comportamiento del sistema es el punto clave
El comportamiento del modelo debe ser desarrollado cuidadosamente Sus limitaciones y restricciones deben
ser respetadas durante el modelado del sistema bajo pruebas De esta forma si el modelo estaacute mal las pruebas
generadas tambieacuten lo estaraacuten Por tanto la exactitud del modelo es fundamental para pasar a la fase de
generacioacuten de casos de prueba
2 Las pruebas deben cubrir los criterios de control de flujo y datos
Los criterios de cobertura de las pruebas definen un conjunto de casos de prueba seleccionados para la misma
Estos casos de pruebas pueden ser generados a partir de dos fuentes criterios de flujo de control o de flujo
de datos En el caso de pruebas aplicadas a grandes sistemas es importante combinar ambos criterios para
incrementar la cobertura de las pruebas
3 El nivel de automatizacioacuten debe ser elevado
El nivel de automatizacioacuten es un factor importante para definir la factibilidad de uso de MBT Normalmente
suele haber un uacutenico paso no automatizado el modelado del comportamiento del sistema el cual es utilizado
como entrada para el proceso de generacioacuten de los casos de prueba Si hubiese otros pasos no automatizados
se incrementariacutea el esfuerzo los costes y la complejidad de su uso
4 Son fundamentales las herramientas que soportan la automatizacioacuten de las fases de MBT
Las herramientas usadas deben soportar la ejecucioacuten de los pasos automatizados Si no hay una herramienta
que soporte un determinado paso esta tarea podriacutea ser difiacutecil e inviable Por tanto una herramienta debe
soportar la integracioacuten entre los diferentes pasos no automatizados y automatizados
5 Los liacutederes del proyecto deben entender las habilidades requeridas y la complejidad para usar
MBT
Las personas encargadas de la fase de pruebas necesitan conocer ademaacutes de las teacutecnicas de pruebas los
lenguajes de modelado y algunos lenguajes de programacioacuten
37
6 El orden de los pasos a seguir mientras se usa un enfoque MBT
Es necesario respetar los pasos seguidos para la generacioacuten de los casos de prueba de forma que sean
respetados en la fase de ejecucioacuten de las pruebas siendo ejecutados en la misma secuencia en que fueron
definidos En caso contrario se podriacutean generar salidas erroacuteneas de dichas pruebas
7 Transferencia de la Tecnologiacutea
Las tecnologiacuteas usadas para la aplicacioacuten de la teacutecnica MBT se transfieren desde entornos acadeacutemicos o de
investigacioacuten para ser implementados en proyectos industriales Por este motivo necesitan ser analizados
cuidadosamente antes de ser usadas
215 Beneficios de Model Based Testing (MBT)
A continuacioacuten se definen diversos beneficios que proporciona la aplicacioacuten de Model Based Testing para la
fase de pruebas [1] [4]
1 Deteccioacuten de Fallos del Sistema Bajo Pruebas
El modelado del comportamiento del sistema bajo pruebas permite detectar errores ambiguumledades o lagunas
que pueden presenciarse en la toma de requisitos especificacioacuten y disentildeo del software Por tanto permite
una deteccioacuten temprana de errores
2 Reduccioacuten de costes y tiempo en la fase de pruebas
La aplicacioacuten de esta teacutecnica contribuye a que el tiempo coste y recursos empleados a la fase de pruebas
disminuya Sin embargo se requiere una mayor asignacioacuten de recursos para el modelado y mantenimiento
del sistema
3 Mejora de la calidad de las pruebas
Cuando las pruebas se desarrollan manualmente la calidad de las mismas es muy dependiente de los
desarrolladores que la implementan Ademaacutes el proceso de disentildeo no puede ser reproducido el criterio
racional aplicado para cada prueba normalmente no es recordado y el resultado de los casos de prueba no es
faacutecilmente interpretado ni contrastado con los requisitos originales del sistema
Model Based Testing es una teacutecnica capaz de mejorar mucho estos inconvenientes que se presentan sobre el
desarrollo de pruebas manuales gracias al generador automatizado de casos de prueba
4 Trazabilidad
Puede definirse como la habilidad para relacionar cada caso de prueba al modelo criterio de seleccioacuten e
incluso a los requisitos informales del sistema Esto ayuda a explicar los casos de prueba asiacute como justificar
por queacute fueron creados Los algoritmos aplicados para la generacioacuten de pruebas deben saber queacute partes del
modelo seraacuten empleadas en cada caso de prueba y las salidas esperadas
5 Evolucioacuten de los requisitos
Si los requisitos del sistema cambian con la aplicacioacuten de Model Based Testing bastariacutea con actualizar el
modelo y las pruebas seraacuten generadas de nuevo de forma automaacutetica Debido a que el modelo es usualmente
maacutes pequentildeo que el conjunto de pruebas del sistema requiere menos tiempo actualizar el modelo que
actualizar todos los casos de prueba Por tanto puede concluirse que se obtiene una respuesta maacutes raacutepida
frente a un cambio en los requisitos
6 Reusabilidad del modelo
El modelo contiene informacioacuten sobre el comportamiento del sistema bajo pruebas Por tanto este puede ser
reutilizado en futuras pruebas incluso cuando los requisitos cambian
38
216 Problemas y Limitaciones de Model Based Testing (MBT)
Una vez destacados los beneficios que aporta dicha teacutecnica tambieacuten es importante detallar algunos problemas
y limitaciones sobre su uso [1] [5]
2161 Problemas
bull Para abordar dicha teacutecnica es necesario que los ingenieros de pruebas tengan habilidades teacutecnicas sobre
la notacioacuten usada para el modelado del sistema Ademaacutes deberiacutean tener experiencia con herramientas
scripts y lenguajes de programacioacuten usados para ejecutar las tareas de Model Based Testing
bull Cuando dicha teacutecnica se pretende aplicar a sistemas complejos el modelado del sistema es maacutes
complejo y existe riesgo de producirse un desbordamiento de la cantidad de casos de prueba generados
a partir del modelo Por esta razoacuten es muy importante definir bien el conjunto de criterios para la
generacioacuten de las pruebas lo cual permite acotar la cobertura de pruebas de forma razonable
bull La automatizacioacuten de la generacioacuten del oraacuteculo de pruebas a partir del modelo es compleja
especialmente en sistemas complejos Cuando el tamantildeo del sistema aumenta la necesidad de
automatizacioacuten tambieacuten aumenta
bull Es necesario desarrollar un modelo de software especiacutefico para un dominio en concreto de aplicacioacuten
ya que existen diversas notaciones de modelado del sistema
bull Es necesario la especificacioacuten formal de los requisitos para obtener el modelo del sistema a partir de
estos La especificacioacuten informal o en lenguaje natural de los requisitos puede dar lugar a ambiguumledades
que dificultan la exactitud en el modelado
2162 Limitaciones
bull No es posible modelar todos los aspectos del comportamiento del sistema bajo pruebas Por tanto es
necesario el uso de otras notaciones de modelado que cubran dichos aspectos
bull Los proyectos software evolucionan continuamente surgiendo nuevos requisitos los cuales algunos
pueden quedar fuera de la fecha de planificacioacuten Si se ha comenzado con el modelado a partir de
requisitos antiguos se construiraacute un modelo erroacuteneo que no reflejaraacute los nuevos requisitos
contemplados lo cual daraacute lugar a errores en el sistema bajo pruebas o resultados no fiables
bull Cuando se produce un fallo en una prueba generada podriacutea resultar maacutes complejo determinar la causa
del fallo ya que la secuencia de pruebas generadas en Model Based Testing podriacutea ser maacutes compleja y
menos intuitiva que las disentildeadas manualmente
217 Cuando elegir Model Based Testing (MBT)
Finamente tras detallar los beneficios problemas y limitaciones sobre la teacutecnica bajo estudio se destacan
algunos puntos principales a tener en cuenta para la aplicacioacuten de dicha teacutecnica
bull Debe existir documentacioacuten lo suficientemente buena sobre el sistema para poder aplicarla
bull Si ya existe un modelo del sistema seriacutea un primer paso que facilitariacutea su aplicacioacuten
bull El manager del proyecto debe ser consciente que la fase de pruebas con Model Based Testing comienza
desde la toma de requisitos ya que se debe modelar el comportamiento del sistema bajo pruebas a partir
de estos Por tanto no se puede esperar que la fase de pruebas comience despueacutes del desarrollo Hacerlo
tras el desarrollo podriacutea significar la modificacioacuten de los requisitos y en consecuencia el desarrollo
39
22 Gestioacuten de Calidad Software
221 Introduccioacuten
En los uacuteltimos antildeos la creciente demanda de productos software principalmente de aplicaciones distribuidas
como los servicios Web provoca que diferentes empresas busquen soluciones software para satisfacer las
necesidades de los clientes Este conjunto de empresas forma un entorno competitivo en el que se intenta buscar
algunos factores para destacar sobre los demaacutes competidores respondiendo a las nuevas exigencias del mercado
Bajo este contexto se plantea la implantacioacuten de una direccioacuten basada en la calidad como la propuesta que
mejores resultados ha ofrecido No solo basta con desarrollar software acorde a los requisitos de los clientes y
las exigencias de los mismos sino que se trata de crear un producto que garantice su correcto funcionamiento
bajo el sustento de una garantiacutea de calidad razonable
El concepto de ldquocalidadrdquo siempre se ha relacionado con la inspeccioacuten de productos fiacutesicos Pero dicho teacutermino
ha ido expandiendo su contexto de una forma maacutes global y aplicable a cualquier tipo de servicio o producto
ofrecido a un cliente
222 Concepto de Calidad
Acorde a la definicioacuten ofrecida por la Real Academia Espantildeola (RAE) la calidad se define como ldquouna propiedad
o conjunto de propiedades inherente a algordquo ldquoAdecuacioacuten de un producto o servicio a las caracteriacutesticas
especificadasrdquo o ldquocondicioacuten o requisito que se pone en un contratordquo [6]
Por otro lado el instituto de Ingenieros Eleacutectricos y Electroacutenicos (IEEE) define la calidad como ldquoel grado con
el que un sistema componente o proceso cumple con los requisitos especificados y las necesidades o
expectativas del cliente o usuariordquo destacando que el eacutenfasis radica en los requisitos especiacuteficos del sistema y
en la buacutesqueda de la satisfaccioacuten del cliente [7]
Roger Pressmann define la Calidad del Software como ldquoConcordancia del software producido con los requisitos
expliacutecitamente establecidos con los estaacutendares de desarrollo prefijados y con los requisitos impliacutecitos no
establecidos formalmente que desea el cliente y en uacuteltima instancia el usuariordquo [8]
Una vez presentado el concepto de calidad su definicioacuten orientada al software se refiere al grado de desempentildeo
de las principales caracteriacutesticas con las que debe cumplir un sistema durante su ciclo de vida Estas
caracteriacutesticas son las que garantizan que el cliente cuente con un sistema confiable lo que permite un aumento
de la satisfaccioacuten frente a la funcionalidad y eficiencia del sistema construido
Figura 7 Concepto de Calidad
40
223 Modelos de Calidad de Software
Los modelos de calidad son aquellos documentos que integran la mayor parte de las mejores praacutecticas proponen
temas de administracioacuten en los que cada organizacioacuten debe hacer eacutenfasis integran diferentes praacutecticas dirigidas
a los procesos clave y permiten medir los avances en calidad
Bajo este contexto los modelos de calidad deben permitir la evaluacioacuten del sistema de forma cualitativa o
cuantitativa y de acuerdo con esta evaluacioacuten la organizacioacuten podraacute proponer implementar estrategias que
permitan la mejora continua en el resto de etapas del ciclo de vida como son las etapas de anaacutelisis disentildeo
desarrollo y pruebas software [7] Desde finales de los antildeos 70 se han ido desarrollando diversos modelos de
calidad del producto software con el fin de fijar una terminologiacutea y entender queacute concepto de calidad se estaacute
usando Asiacute mismo dichos modelos de calidad se clasifican de acuerdo con el enfoque de evaluacioacuten
contemplado ya sea a nivel de proceso producto o calidad de uso
2231 Calidad a Nivel de Proceso
Este enfoque de calidad de software describe que la calidad de un sistema software debe ser implementada desde
el inicio del proyecto y en cada etapa de su ciclo de vida debiendo permitir el control y seguimiento de los
aspectos de calidad para minimizar los riesgos y ofrecer un soporte continuo De esta forma se consigue
garantizar un nivel oacuteptimo de cumplimiento de los factores de calidad definidos teniendo en cuenta que si en
alguna etapa no se verifican dichos factores posiblemente disminuya el nivel de calidad no solo del proceso si
no tambieacuten del producto en desarrollo [7]
A continuacioacuten se muestra una liacutenea de tiempo de algunos modelos a nivel de proceso y se describen dos de los
que maacutes intereacutes presentan dentro del aacutembito de este proyecto
Figura 8 Liacutenea de tiempo de modelos a nivel de proceso
ITIL (Information Technology Infrastructure Library)
Desarrollado en el Reino Unido con el fin de fortalecer la gestioacuten gubernamental a partir de cinco elementos
fundamentales la perspectiva del negocio entrega del servicio soporte del servicio manejo de la infraestructura
y manejo de aplicaciones con el propoacutesito de ofrecer una estructura integral para prestar a la organizacioacuten un
servicio completo cubriendo necesidades de apoyo de instalacioacuten adecuacioacuten de redes comunicaciones
hardware servidores sistema operativo y software necesarios
Figura 9 Logo de ITIL
41
ISOIEC 20000
El objetivo principal de esta norma es avalar que la prestacioacuten de servicios de TI en una empresa cuenta con la
calidad necesaria para brindar dichos servicios a los clientes Esta norma engloba diferentes secciones dedicadas
a las especificaciones de dicha norma y a los coacutedigos de buenas praacutecticas
Figura 10 ISOIEC 20000
WebQEM
Web-site Quality Evaluation Method se trata de una metodologiacutea de evaluacioacuten de calidad de sitios Web en seis fases planificacioacuten y programacioacuten de la evaluacioacuten de la calidad definicioacuten y especificacioacuten de los requisitos de calidad establecidos definicioacuten e implementacioacuten de la evaluacioacuten elemental definicioacuten e implementacioacuten de la evaluacioacuten global anaacutelisis de resultados y evaluacioacuten de meacutetricas y finalmente conclusiones y documentacioacuten
Figura 11 Logo de WebQEM
42
2232 Calidad a Nivel de Producto
El enfoque de la calidad de software a nivel de producto tiene como objetivo especificar y evaluar el
cumplimiento de los criterios del producto Para ello se suelen definir y aplicar medidas o meacutetricas internas o
externas Por esta razoacuten muchas normas definen la calidad a nivel de producto de tipo interna externa y en uso
Esta uacuteltima se define como el conjunto de atributos relacionados con la aceptacioacuten por parte del usuario final y
seguridad
A continuacioacuten se muestra una liacutenea de tiempo de algunos modelos a nivel de proceso y se describen tres de los
que maacutes intereacutes presentan dentro del aacutembito de este proyecto
Figura 12 Liacutenea de tiempo de modelos a nivel de producto
ISO 9126
Este se basa en el modelo McCall el cual es uno de los modelos pioneros en la evaluacioacuten de la calidad de
software Desarrollado en 1991 es un marco normativo dirigido a desarrolladores aseguradores de calidad
evaluadores analistas y cualquier otro involucrado en el proceso de construccioacuten de software y la gestioacuten de
calidad del mismo Estaacute dividido en cuatro partes Modelo de Calidad Meacutetricas Externas Meacutetricas Internas y
Calidad de Meacutetricas en Uso
Esta norma busca la fiabilidad funcionalidad usabilidad eficiencia mantenibilidad y portabilidad en la
construccioacuten de productos software A continuacioacuten se muestra un esquema que resume dichas caracteriacutesticas
y subcaracteriacutesticas [8]
Figura 13 Esquema de ISO 9126
43
ISOIEC 25000
Basada en la norma ISO 9126 y adaptando parte del marco normativo a las necesidades del mercado actual Esta
norma tambieacuten conocida como SQuaRE (Software Product Quality Requirements and Evaluation) establece
un marco de trabajo comuacuten para evaluar la calidad de productos de Software
En dicha norma se definen los modelos teacuterminos y definiciones comunes para el resto de normas que componen
la serie 25000 La ISOIEC 25000 presenta diversas secciones entre las que se puede destacar [9]
ISOIEC 25010 Describe las caracteriacutesticas y subcaracteriacutesiticas de calidad que pueden ser evaluadas
en un producto software diferenciando entre calidad interna externa y de uso En la siguiente figura se
presenta un desglose de dichas caracteriacutesticas
ISOIEC 25040 Define el proceso de evaluacioacuten perioacutedico de la calidad del producto software
Figura 14 Esquema de ISOIEC 25000
44
224 Principales Ventajas e Inconvenientes de Modelos de Calidad anteriores
2241 A nivel de Proceso
Modelo Ventajas Inconvenientes
ITIL bull Mejor estructuracioacuten organizacioacuten y
claridad de los proyectos
bull Mayor control administrativo
bull Mayor eficacia y rapidez ante cambios
bull Incrementa la productividad del negocio y la
fiabilidad de los clientes
bull Tiempo y esfuerzo necesarios
bull Falta de conocimiento para apreciar la mejora
proporcionada
bull Involucracioacuten y compromiso de todo el
personal de la organizacioacuten
bull Frustracioacuten generada por expectativas a corto
plazo
bull No hay mejoriacutea si la inversioacuten asignada para
implantar el modelo es insuficiente
ISOIEC
20000 bull Reconocimiento internacional
bull Muy usado por las organizaciones
WebQUEM bull Calidad medida en fases y actividades de
forma cuantitativa con indicadores
bull Aplicaciones de Software centradas en la Web
son cada vez maacutes complejas provocan mayor
complejidad en su implantacioacuten
2242 A nivel de Producto
Modelo Ventajas Inconvenientes
ISO 9126 bull Determina queacute caracteriacutesticas y
subcaracteriacutesticas son importantes para el
producto
bull Define meacutetricas especiacuteficas para los
componentes Software
bull Define indicadores para las caracteriacutesticas de
calidad
bull Usabilidad tratada desde la perspectiva del
proceso no del producto
bull No tiene en cuenta la caracteriacutestica de ldquofacilidad
de aprendizajerdquo siendo esta recomendada por
otros estaacutendares
bull Meacutetricas complejas difiacutecilmente medibles
Requieren descomposicioacuten
ISOIEC
25000 bull Detecta objetivos del producto alineados con
necesidades reales de clientes finales
bull Evita ineficiencias y maximiza rentabilidad
y calidad del producto
bull El proceso de evaluacioacuten perioacutedica permite
la mejora continua
bull No establece niveles de calidad para cada
proyecto
bull No hace uso de meacutetricas o umbrales de calidad
225 Conclusiones
Una vez presentado el concepto de gestioacuten de calidad de software y los principales modelos y normas es
interesante destacar la diferencia entre calidad interna y externa La calidad interna se centra en las caracteriacutesticas
propias del producto software (disentildeo especificacioneshellip) mientras que la calidad externa lo hace con las
caracteriacutesticas dinaacutemicas del mismo es decir con el comportamiento Es por ello que el proceso de calidad
interna se inicia en las fases tempranas del ciclo de vida de un proyecto mientras la calidad externa se aplica
una vez se tiene un primer prototipo funcional del producto software desarrollado Por tanto se trataraacute de
automatizar el proceso de evaluacioacuten de la calidad externa del proyecto CHT Cloud Manager analizando
verificando y validando automaacuteticamente la aceptacioacuten de dicho producto
45
46
3 MARCO TEOacuteRICO PRUEBAS DE SOFTWARE
ras presentar el concepto de calidad y algunas de las normas y estaacutendares maacutes conocidos que describen
la aplicacioacuten de dicho concepto en el aacutembito del desarrollo de software se centraraacute el enfoque en el
papel del testeo y las pruebas de software Con ello se destacaraacuten algunos puntos principales para
llevar a cabo las pruebas de software el anaacutelisis disentildeo e implementacioacuten de dichas pruebas los diferentes tipos
y niveles de pruebas y las dificultades de la aplicacioacuten de pruebas de software sobre aplicaciones Web
31 Testing y Pruebas de Software
Habitualmente se tiene una percepcioacuten del testing de un producto como una tarea basada en la ejecucioacuten de
pruebas de forma repetitiva para la buacutesqueda de errores o problemas que puedan repercutir sobre la calidad del
mismo Pero el testing no solo se basa en la realizacioacuten de pruebas
Se deben identificar otras tareas que estaacuten relacionadas con el testing las cuales se llevan a cabo antes y despueacutes
de la ejecucioacuten de pruebas Estas tareas estaacuten relacionadas principalmente con la planificacioacuten y control del
proceso de pruebas el disentildeo de los diferentes casos de prueba o test cases y la posterior comprobacioacuten de los
resultados obtenidos tras llevar a cabo las pruebas Otras tareas podriacutean ser la propia evaluacioacuten de los diferentes
criterios de finalizacioacuten del proceso de pruebas el anaacutelisis de informes de resultados o la revisioacuten de la
documentacioacuten generada en la fase de pruebas
A continuacioacuten se citan algunas definiciones para explicar el concepto de pruebas de software
ldquoUna prueba es una actividad ejecutada para evaluar la calidad del producto software y mejorarlo mediante
la identificacioacuten de problemas errores o defectos en su funcionamiento [9]rdquo
ldquoLas pruebas de Software consisten en verificaciones dinaacutemicas del comportamiento del software bajo
pruebas mediante un conjunto finito de casos de prueba seleccionadas adecuadamente sobre un dominio
infinito de casos posibles [1]rdquo
Atendiendo a las definiciones presentadas las pruebas de software son dinaacutemicas porque se puede ejecutar el
software bajo pruebas con un conjunto de valores de entrada especiacuteficos para encontrar fallos en su
comportamiento Por otro lado la realizacioacuten de pruebas exhaustivas no es posible para la mayoriacutea de los
productos software reales debido a la gran cantidad de entradas posibles para cada operacioacuten entradas invaacutelidas
o no esperadas y las infinitas secuencias de operaciones posibles
Por estas razones para aplicar un proceso de pruebas de software razonable en cuanto a recursos y tiempo de un
proyecto es necesario seleccionar un conjunto abarcable de pruebas Debido a esto la clave estaacute en el criterio
de seleccioacuten de dichas pruebas Una vez ejecutadas las pruebas seleccionadas se debe decidir si el
comportamiento esperado del sistema falla o no Este es el llamado problema del oraacuteculo el cual es resuelto en
la mayoriacutea de los casos de forma manual mediante la inspeccioacuten de los resultados de la prueba
T
La tecnologiacutea no es nada Lo importante es que tengas feacute
en la gente que sean baacutesicamente buenas e inteligentes
y si les das herramientas haraacuten cosas maravillosas con
ellas
Steve Jobs
47
32 Principios de las Pruebas de Software
Una vez presentada la definicioacuten de pruebas de Software se han obtenido algunos detalles que encajan
perfectamente con una serie de principios que han sido establecidos para el testing de productos software seguacuten
ISTQB (International Software Testing Qualifications Board) [10]
Figura 15 Principios de las Pruebas de Software
1 Las pruebas demuestran la presencia de defectos no su ausencia Las pruebas pueden mostrar que
los defectos estaacuten presentes en el producto pero no pueden probar que no haya defectos Por tanto las
pruebas pueden reducir la probabilidad de existencia de defectos en el software pero incluso si no se
encuentran defectos las pruebas no son una garantiacutea total para afirmar la ausencia de defectos en el
producto final
2 Las pruebas exhaustivas son imposibles Probar todas las posibles combinaciones de entradas y
condiciones previas sobre una aplicacioacuten no es factible excepto en casos muy triviales En lugar de
intentar realizar pruebas exhaustivas se debe usar el anaacutelisis de riesgos las teacutecnicas de prueba y las
prioridades ademaacutes de la automatizacioacuten para enfocar los esfuerzos en la fase de pruebas
3 Las pruebas tempranas ahorran tiempo y dinero Para una deteccioacuten temprana de errores y defectos
las actividades de pruebas deben iniciarse lo antes posible en el ciclo de vida del desarrollo del software
De esta forma se consigue una reduccioacuten de costes ya que cuanto maacutes tarde se detecte un defecto maacutes
costoso y difiacutecil seraacute corregirlo
4 Los defectos se agrupan Generalmente una pequentildea parte del software desarrollado concentra la
mayor complejidad del mismo por lo que la mayoriacutea de los defectos detectados tienen una mayor
probabilidad de encontrarse en esos elementos maacutes complejos Por tanto la realizacioacuten de un buen
anaacutelisis de riesgos permite enfocar el esfuerzo de pruebas en las aacutereas del producto con mayor
probabilidad de presentar defectos
Aplicando el Principio de Pareto al control de calidad [11] el 80 de los errores y defectos estaacute causado
por un 20 del total del producto software desarrollado lo cual podriacutea ser un buen principio sobre el
que basar el anaacutelisis de riesgos
5 Cuidado con la paradoja del pesticida Si las mismas pruebas se repiten una y otra vez con el tiempo
los mismos casos de pruebas ya no encontraraacuten nuevos defectos lo cual no quiere decir que la aplicacioacuten
presente una ausencia completa de los mismos (Las pruebas ya no son eficaces para detectar defectos
al igual que los pesticidas ya no son eficaces para matar insectos despueacutes de un tiempo) Para detectar
nuevos defectos es necesario que las pruebas existentes y los datos de las pruebas deban cambiar
ademaacutes de surgir la necesidad de disentildear nuevas pruebas
48
6 Las pruebas dependen del contexto Cada empresa organizacioacuten o proyecto adaptaraacute el proceso de
pruebas a sus necesidades recursos disponibles o aacutereas de riesgo existentes
7 La ausencia de errores es una falacia Un producto software puede tener un 100 de casos de eacutexito
en su fase de pruebas pero esto solo indica que hay defectos que auacuten no han sido localizados e
identificados
33 Proceso de Pruebas de Software Anaacutelisis disentildeo e implementacioacuten
Partiendo de los principios detallados en la seccioacuten anterior se presentan las diferentes etapas del proceso de
pruebas de software asiacute como la documentacioacuten generada en cada etapa
331 Terminologiacutea
Previamente se presentaraacuten algunos teacuterminos y definiciones que convienen describir para una mejor
comprensioacuten de todo el proceso de pruebas [3]
Figura 16 Terminologiacutea para el proceso de pruebas
1 Condicioacuten de prueba Elemento o evento de un componente o sistema que puede ser verificado por
uno o maacutes casos de prueba Los diferentes requisitos que definen la funcionalidad de un sistema pueden
ser descompuestos en diferentes condiciones de prueba
2 Caso de prueba conjunto de valores de entrada precondiciones de ejecucioacuten y valores esperados
Estos son desarrollados para perseguir un objetivo particular por ejemplo una condicioacuten de prueba
3 Precondicioacuten Condiciones de entorno y estado que deben ser satisfechas antes de que un componente
o sistema pueda ser sometido a un caso de prueba o conjunto de estos
4 Abstraccioacuten de casos de prueba Consiste en la generalizacioacuten de los casos de prueba especiacuteficos sin
valores concretos para sus entradas condiciones de prueba o valores esperados En resumen no es maacutes
que llevar las condiciones de prueba a un caso general para cualquier valor de entrada
5 Script de pruebas Una vez disentildeados los casos de prueba estos pueden ser implementados y
ejecutados por una herramienta de automatizacioacuten Un script de pruebas puede contener varios casos
de prueba
6 Paquete de pruebas Consiste en la agrupacioacuten de casos de prueba relacionados en cuanto a la
funcionalidad que automatizan sobre el sistema
7 Programacioacuten de la ejecucioacuten de pruebas Describen el flujo de ejecucioacuten de los diferentes paquetes
de pruebas
49
332 Proceso de Pruebas de Software
No existe un proceso de pruebas universal pero existen conjuntos comunes de actividades de prueba sin las
cuales las pruebas disentildeadas e implementadas tendriacutean menos probabilidad de alcanzar sus objetivos
establecidos Estos conjuntos de actividades de prueba constituyen un proceso de pruebas
Como se ha mencionado en secciones anteriores el proceso de pruebas se debe iniciar en las fases maacutes iniciales
del ciclo de vida de un proyecto Por tanto las actividades del proceso de pruebas la manera en que se
implementan dichas actividades y cuaacutendo ocurren pueden ser discutidas en la estrategia de pruebas de una
organizacioacuten
A continuacioacuten se exponen las etapas fundamentales del proceso de pruebas detallando en cada una de ellas la
documentacioacuten generada y coacutemo contribuyen a la mejora de la calidad del producto con su aplicacioacuten en el ciclo
de vida de un proyecto [13]
Figura 17 Proceso de Pruebas de Software
3321 Planificacioacuten y Control de Pruebas
La planificacioacuten consiste en determinar los diferentes objetivos de las pruebas realizadas sobre el Sistema bajo
test las especificaciones y los recursos que se necesitaraacuten para llevar a cabo la fase de pruebas y cumplir con los
objetivos planteados
Es en este punto donde se define el alcance de las pruebas a realizar de forma que se selecciona lo que seraacute y
no seraacute testeado ademaacutes de indicar quieacuten haraacute cada prueba y como la llevaraacute a cabo Mediante los objetivos de
las pruebas se puede establecer un punto de finalizacioacuten del proceso
Como salida de la actividad de planificacioacuten se obtendriacutea el ldquoPlan de Pruebasrdquo el cual documenta la estrategia
y el alcance de las pruebas la prioridad en cuanto a su realizacioacuten y las estimaciones temporales para su
evaluacioacuten ademaacutes de los recursos materiales y humanos para llevarlas a cabo
Es crucial que dicho documento sea validado por el personal correspondiente del proyecto antes de continuar
con las siguientes etapas del proceso de pruebas
Por otro lado el control de pruebas es una actividad desarrollada durante todo el ciclo de vida del proceso de
pruebas el cual permite contrastar el progreso actual con el plan original trazado para la aplicacioacuten de dicho
proceso incluyendo informes y desviaciones
Cuando se produce una desviacioacuten del plan original que introduce cierto riesgo adicional puede hacerse
necesario modificar los objetivos fijados para asegurar la calidad del producto De ahiacute que sea sumamente
importante tener en consideracioacuten la documentacioacuten generada en antiguos proyectos
50
3322 Anaacutelisis y Disentildeo de Pruebas
Una vez planificado el alcance y objetivos de las pruebas se realiza una actividad de anaacutelisis donde se traducen
a condiciones de prueba y posteriormente se disentildean los casos de prueba de alto nivel a partir de la abstraccioacuten
de los casos de prueba
Por otro lado cabe destacar la necesidad de un mecanismo que garantice la trazabilidad con la finalidad de
mantener alineados en todo momento los casos de prueba con los objetivos de la misma incluso contemplando
la posibilidad de que los objetivos puedan cambiar en alguacuten momento del proceso de pruebas
El documento generado en esta actividad es conocido como ldquoespecificaciones de disentildeo de pruebasrdquo
3323 Implementacioacuten y Ejecucioacuten de Pruebas
Dicha etapa consiste en la implementacioacuten de los casos de prueba de alto nivel que cumplen con las
especificaciones de disentildeo de la etapa anterior Es en esta fase donde se haraacute uso de herramientas para la
implementacioacuten y ejecucioacuten de las pruebas
Cabe destacar que para llevar a cabo dicha etapa en cuanto a la verificacioacuten y validacioacuten funcional de un
proyecto es necesario que durante la etapa de desarrollo se haya creado un producto funcional sobre el cual
puedan ejecutarse las pruebas
Durante la ejecucioacuten de las pruebas los resultados obtenidos quedaraacuten documentados en un documento
denominado ldquoRegistro de Pruebasrdquo el cual contiene todas las pruebas realizadas y un ldquoReporte de Incidenterdquo
por cada resultado no esperado que se haya detectado
Una vez sean corregidos los incidentes se debe volver a ejecutar las pruebas con la finalidad de asegurar que
dicho incidente haya sido corregido ademaacutes de asegurar que la correccioacuten realizada no haya introducido otros
defectos o errores Esto es lo que se denomina ldquoPruebas de Regresioacutenrdquo
3324 Evaluacioacuten de los criterios de eacutexito y Elaboracioacuten de reportes e informes
Tras la ejecucioacuten de las pruebas se deben evaluar los criterios de eacutexito los cuales han sido definidos en la etapa
de planificacioacuten
El personal responsable e involucrado en el proyecto se reuniraacute y revisaraacute el cumplimiento de dichos criterios
el registro de pruebas obtenido y los reportes de incidentes que hayan podido ser abiertos en la etapa anterior
Finalmente como resultado de dicha actividad se elabora un ldquoSumario final de Pruebasrdquo
3325 Cierre de la fase de pruebas
Las actividades de cierre de la fase de pruebas se centran mayormente en asegurar que todo el ciclo de vida del
proceso de pruebas se ha cumplido ademaacutes de analizar las posibles mejoras y defectos en las fases llevadas a
cabo
Ademaacutes se lleva a cabo el cierre de los incidentes corregidos y la liberacioacuten de los entornos y recursos asignados
a la fase de pruebas
51
34 Clasificacioacuten de Pruebas de Software
Existen diversos tipos de pruebas las cuales pueden ser clasificadas en funcioacuten del objetivo de prueba para lo
cual hayan sido establecidos Cada tipo de prueba persigue unos objetivos especiacuteficos sobre el producto pero
todas ellas persiguen como objetivo comuacuten ofrecer un producto con garantiacutea de calidad al cliente o usuario final
Dichas pruebas pueden ser clasificadas en cuatro tipos
Figura 18 Clasificacioacuten de Pruebas de Software
341 Pruebas Funcionales
Tambieacuten conocidas como ldquoPruebas de caja Negrardquo En [14] la IEEE define este tipo de pruebas como
ldquoPruebas que ignoran los mecanismos internos de un sistema o componente y se enfocan
solamente en las salidas generadas como respuesta a las entradas seleccionadas y a las
condiciones de ejecucioacutenrdquo
Figura 19 Pruebas de Caja Negra
Atendiendo a la definicioacuten anterior el sistema o componente sujeto a pruebas debe realizar una funcioacuten
determinada Estaraacute descrita en las especificaciones funcionales y se pueden llevar a cabo a cualquier nivel
Dichas especificaciones funcionales describen el comportamiento del sistema sin revelar informacioacuten acerca de
su implementacioacuten interna
Un tipo especial de prueba funcional son las ldquoPruebas de Humordquo o ldquoSmoke Testsrdquo Este tipo de pruebas suele
realizarse en fases tardiacuteas del desarrollo y permiten asegurar que las funcionalidades baacutesicas del software
responden adecuadamente
Por tanto dichas pruebas pueden quedar lejos de ser pruebas exhaustivas aunque siacute permiten asegurar que el
producto entregado al cliente cumple con los requisitos de funcionamiento establecidos Este tipo de pruebas
son las que se han implementado y automatizado en el proyecto presente lo cual se detallaraacute en capiacutetulos
posteriores
52
342 Pruebas No Funcionales
Este tipo de pruebas estaacuten orientadas a verificar coacutemo de bien funciona el sistema bajo pruebas en lugar de la
funcionalidad que ofrece Por ello pueden ser agrupadas tambieacuten dentro de la categoriacutea de pruebas de caja negra
Atendiendo al estaacutendar de evaluacioacuten del producto software ldquoISO 25000rdquo todas las caracteriacutesticas excepto la de
funcionalidad definen caracteriacutesticas de calidad no funcionales de un producto software Estas caracteriacutesticas de
calidad tienen su correspondiente tipo de prueba
3421 Pruebas de Rendimiento
Las pruebas de rendimiento son usadas para determinar la rapidez con la que se realiza una tarea en el sistema
bajo unas condiciones particulares de trabajo Estas pruebas tambieacuten pueden ser usadas para validar y verificar
otros atributos de calidad del sistema tales como la escalabilidad fiabilidad y uso de recursos
Figura 20 Pruebas de Rendimiento
3422 Pruebas de Carga
Este tipo de pruebas miden el rendimiento del sistema con una carga de trabajo manejable y conocida Se trata
de someter al sistema a cargas de trabajo controladas por el ingeniero de pruebas para validar prestaciones de
rendimiento sobre el sistema
Figura 21 Pruebas de Carga
3423 Pruebas de Estreacutes
Las pruebas de estreacutes ponen a prueba la robustez y confiabilidad del sistema sometieacutendolo a condiciones de uso
extremas Entre estas condiciones se incluyen el enviacuteo masivo de peticiones y la ejecucioacuten en condiciones de
hardware limitadas Dichas condiciones van maacutes allaacute de los liacutemites de operacioacuten considerados en el disentildeo
Figura 22 Pruebas de Estreacutes
53
3424 Pruebas de Usabilidad
Estas pruebas se centran en encontrar problemas de la interfaz de usuario que podriacutean hacer que el software sea
difiacutecil de utilizar o podriacutean causar que los usuarios mal interpreten las salidas Por tanto permiten medir coacutemo
de atractivo resulta un producto software basaacutendose en la facilidad de adaptacioacuten y uso por parte de los clientes
Figura 23 Pruebas de Usabilidad
3425 Pruebas de Fiabilidad
Prueban el rendimiento del sistema ante un determinado nuacutemero de operaciones o tras cierto periodo de
tiempo
3426 Pruebas de Instalacioacuten
Las pruebas de instalacioacuten tienen dos propoacutesitos El primero es asegurar que el sistema puede ser instalado
en todas las configuraciones posibles tales como nuevas instalaciones actualizaciones instalaciones
completas o personalizadas y bajo condiciones normales o anormales estas uacuteltimas incluyen insuficiente
espacio en disco falta de privilegios para algunas tareas etc
El segundo propoacutesito es verificar que una vez instalado el sistema opera correctamente Esto usualmente
implica ejecutar un nuacutemero significativo de pruebas de Funcionalidad
Por tanto miden coacutemo de sencillo resulta instalar la aplicacioacuten en distintas plataformas o entornos
3427 Pruebas de Portabilidad
Miden coacutemo de sencillo resulta migrar una aplicacioacuten de una plataforma a otra
Figura 24 Pruebas de Portabilidad
54
343 Pruebas Estructurales
Este tipo de pruebas son tambieacuten conocidas como ldquoPruebas de Caja Blancardquo En [14] la IEEE define este tipo
de pruebas como
ldquoPruebas que tienen en cuenta los mecanismos internos de un sistema o componenterdquo
Figura 25 Pruebas de Caja Blanca
Atendiendo a dicha definicioacuten estas pruebas tienen en cuenta la estructura del coacutedigo fuente del software a partir
del cual se seleccionan los diferentes casos de prueba guiaacutendose por la existencia de sentencias condicionales
bucles etc
Por tanto los casos de prueba son desarrollados usando criterios de cobertura para el coacutedigo del programa De
esta forma el sistema bajo pruebas se trata como una caja de cristal que permite ver su estructura
El criterio de cobertura hace referencia a cada miacutenima unidad de coacutedigo que puede ser probada de forma
independiente Es frecuente usar este tipo de pruebas en los niveles de prueba maacutes bajos como por ejemplo en
las ldquoPruebas Unitariasrdquo o las ldquoPruebas de Componenterdquo
344 Pruebas debidas a Cambios
Finalmente en el proceso de pruebas tras ejecutar las pruebas y encontrar un defecto o error en el sistema bajo
pruebas este se corrige pero es necesario validar la correccioacuten realizada para confirmar que el fallo no se
reproduce A este proceso se le denomina ldquoPrueba de confirmacioacuten o re-testingrdquo
Ademaacutes las correcciones pueden ser validadas pero tambieacuten es necesario asegurar que los cambios introducidos
para corregir dicho fallo no han provocado maacutes defectos Por tanto puede concluirse que es necesario volver a
realizar pruebas sobre el resto del sistema Estas son las ldquoPruebas de Regresioacutenrdquo
35 Niveles de Prueba
El proceso de pruebas es una etapa del ciclo de vida de un proyecto cuyas actividades estaacuten completamente
relacionadas con las actividades del proceso de desarrollo Existen diversos modelos que describen las fases y
actividades del proceso de desarrollo de software En esta seccioacuten se detallaraacute el uso del ldquoModelo de desarrollo
en Vrdquo
Este modelo describe las diferentes fases del proceso de desarrollo y sugiere la realizacioacuten de pruebas en cada
una de ellas Estas pruebas seraacuten ejecutadas posteriormente en orden ascendente Por tanto para cada fase existen
unos objetivos a cumplir los cuales deben ser probados para medir la integridad del trabajo realizado
55
A continuacioacuten se detallaraacuten los diferentes niveles de prueba para cada etapa del desarrollo software atendiendo
al modelo de desarrollo en V
Figura 26 Modelo de desarrollo en V
351 Pruebas a Nivel de Componente
Tambieacuten llamadas ldquoPruebas Unitariasrdquo El objetivo de estas pruebas es el de cubrir la unidad miacutenima funcional
que compone el software Estos componentes suelen tener una uacutenica funcioacuten especiacutefica la cual seraacute usada por
el resto del Sistema A menudo son realizadas por los propios desarrolladores haciendo uso de la metodologiacutea
de desarrollo guiado por prueba o Test-Driven-Development (TDD)
352 Pruebas a Nivel de Integracioacuten
Son aquellas pruebas realizadas en el aacutembito del desarrollo software una vez validadas las pruebas unitarias
Estas pruebas verifican que todos los elementos unitarios que componen el software funcionan en conjunto de
forma correcta Se centran principalmente en probar la comunicacioacuten entre los diferentes componentes del
sistema
353 Pruebas a Nivel de Aceptacioacuten
Este uacuteltimo nivel se centra en las necesidades del usuario requisitos y procesos de negocio con el fin de
determinar si el sistema satisface los criterios de aceptacioacuten acordados con el cliente en un contrato o acuerdo
de nivel de servicio en caso de ser un software de uso interno dentro de una compantildeiacutea
Ejemplos de este tipo de pruebas pueden ser las ldquoPruebas Alfa y Betardquo
Como se ha detallado anteriormente las pruebas desarrolladas y automatizadas en este Proyecto son ldquoPruebas
de humordquo o Smoke Tests Estas pruebas se centran en la verificacioacuten y validacioacuten de las especificaciones de uso
de un Sistema en este caso de la plataforma Web de gestioacuten Galgus CHT Manager
56
36 Dificultades de pruebas en aplicaciones Web e impacto
La complejidad antildeadida de las aplicaciones y servicios Web frente a otros tipos de aplicaciones recae sobre el
uso de muacuteltiples tecnologiacuteas de vanguardia que permiten la construccioacuten de sistemas distribuidos con un amplio
grado de escalabilidad accesibilidad disponibilidad interoperabilidad e independencia del hardware
Como consecuencia del incremento de la complejidad de las aplicaciones surgen nuevos paradigmas como la
Arquitectura Orientada a Servicios (SOA) la cual permite interoperabilidad y flexibilidad de las aplicaciones
distribuidas
Todo ello conlleva a plantearse queacute se deberiacutea hacer para garantizar que una aplicacioacuten Web puesta en marcha
funciona de acuerdo a los requisitos definidos y acordados con el cliente Podriacutean optimizarse y mejorarse los
diferentes procesos dentro del ciclo de vida de un proyecto pero siempre la fase de pruebas termina siendo la
fase previa a la puesta en marcha de la aplicacioacuten con lo que resulta siendo la uacuteltima oportunidad para detectar
posibles fallos que puedan terminar en ocasiones en peacuterdidas econoacutemicas de prestigio de fiabilidad y de
credibilidad por parte de los clientes
Realizar pruebas en una aplicacioacuten Web no es tarea faacutecil ya que son muchos los factores que influyen en el
testeo del sistema para abarcar y contemplar el maacuteximo de flujos posibles que se pueden llevar a cabo durante
el uso de la aplicacioacuten
Hoy en diacutea las aplicaciones Web pueden ser construidas con componentes implementados en diferentes
lenguajes y arquitecturas basaacutendose en diferentes modelos de programacioacuten y pudiendo ejecutarse en diferentes
plataformas de hardware y software
Esto incrementa la complejidad de las pruebas a realizar sobre un sistema de este tipo por lo que seriacutea interesante
plantearse la posibilidad de usar herramientas que permitan una abstraccioacuten de dicha complejidad ademaacutes de la
automatizacioacuten de la fase de pruebas En el caso de las pruebas a nivel de aceptacioacuten en este proyecto se
propondraacute el uso de herramientas que persiguen dichos fines
Figura 27 Dificultades de pruebas en aplicaciones Web e impacto
57
58
4 SISTEMA GALGUS CHT CLOUD MANAGER
ras realizar un estudio del arte sobre una teacutecnica que puede ser de gran utilidad para optimizar y
perfeccionar las teacutecnicas de automatizacioacuten para el proceso de pruebas sobre un sistema se han puesto
en contexto los diferentes tipos de pruebas que pueden realizarse sobre un sistema ademaacutes de definir
el proceso de pruebas Una vez llegados a este punto en primer lugar se realizaraacute una descripcioacuten del sistema
bajo pruebas sobre el cual se plantearaacute una solucioacuten para la fase de pruebas y su automatizacioacuten Maacutes
concretamente para la realizacioacuten de las pruebas a nivel de aceptacioacuten
41 Arquitectura y Descripcioacuten del Sistema
CHT Cloud Manager es un proyecto de la empresa Galgus el cual ofrece una plataforma Web de gestioacuten
configuracioacuten y monitorizacioacuten de redes WiFi Maacutes concretamente dicha plataforma permite gestionar un
conjunto de puntos de acceso desplegados con un conjunto de algoritmos definidos por software los cuales
permiten la optimizacioacuten de los recursos de red inalaacutembricos ofreciendo mayores prestaciones y una mayor
calidad de servicio al usuario Ademaacutes dicho software embebido ofrece otros servicios al cliente como la
localizacioacuten de estaciones dentro de la zona de alcance de la red WiFi o la deteccioacuten de intrusos y ataques de
suplantacioacuten de identidad
A este conjunto de algoritmos se le conoce bajo el nombre Cognitive Hostpot Technology (CHT) Este software
implementado en lenguaje C y preparado para sistemas embebidos como los puntos de acceso presenta una
estructura modular donde cada moacutedulo se encarga de una tarea determinada o de ejecutar un algoritmo
determinado
Figura 28 Logo de Galgus
Para permitir la comunicacioacuten con la plataforma Web CHT implementa un moacutedulo denominado MGR el cual
permite la conexioacuten con un broacuteker de eventos o intermediario para permitir el enviacuteo y la recepcioacuten de eventos
desde dicha plataforma
T
La simplicidad llevada al extremo se convierte en
elegancia
Jon Franklin
59
En la siguiente figura se muestra la arquitectura orientada a servicios para CHT Cloud Manager
Figura 29 Arquitectura de CHT Cloud Manager
Puede observarse que dicha plataforma estaacute formada por diferentes microservicios desplegados en la nube Cada
uno de ellos realiza una serie de tareas bien definidas e interactuacutean entre ellos enviando y recibiendo mensajes
haciendo uso de diferentes protocolos y modelos de comunicacioacuten
De esta forma se consigue mantener actualizado el estado de la informacioacuten de los diferentes elementos en
tiempo real sobre los diferentes eventos que puedan ocurrir en el sistema Dichos eventos proceden en su gran
mayoriacutea del conjunto de puntos de acceso que conforma una red de Galgus la cual pretende ser gestionada desde
la plataforma en cuestioacuten
A continuacioacuten se detallaraacuten los diferentes microservicios que conforman dicha plataforma ademaacutes de describir
a los puntos de acceso con la tecnologiacutea CHT como elementos a gestionar desde dicha plataforma
60
411 Puntos de Acceso (OpenWRT + CHT)
4111 OpenWRT
Los puntos de acceso WiFi de Galgus son sistemas embebidos de diferentes modelos en funcioacuten de las
especificaciones hardware que ofrezcan (nuacutemero de streams espaciales nuacutemero de antenas de exterior de
interior etc)
Todos ellos tienen en comuacuten el uso de OpenWRT como sistema operativo Este se trata de un sistema operativo
open source basado en Linux y usado para sistemas de red embebidos Todos los componentes de dicho sistema
han sido optimizados para dispositivos con limitaciones de hardware y este permite configurarlos mediante
interfaz de liacutenea de comandos o mediante una interfaz Web (LuCI) [15]
Partiendo de dicho sistema operativo Galgus desarrolla CHT como producto software que dota a los puntos de
acceso de una serie de prestaciones en una serie de moacutedulos Dicho producto es ofrecido al cliente mediante
licencias las cuales son gestionadas desde un servidor de licencias y obtenidas por los puntos de acceso de
forma automaacutetica Todo ello se detallaraacute maacutes adelante
4112 CHT
CHT tambieacuten ofrece su propia interfaz de liacutenea de comandos denominada CHT_CLI Esta herramienta permite
configurar los distintos moacutedulos de los que se compone CHT y obtener informacioacuten tanto de la configuracioacuten
como del funcionamiento de los algoritmos CHT
A continuacioacuten se presenta la interfaz y algunos de los comandos que se pueden utilizar
Figura 30 CHT_CLI
CHT_CLI es fundamental tanto en el desarrollo como en el testeo de CHT y CHT Cloud Manager ya que nos
permite acceder a paraacutemetros de configuracioacuten que no estaacuten accesibles desde la interfaz graacutefica LuCI Desde
CHT_CLI se controlan todos los moacutedulos de CHT entre los que se pueden destacar los siguientes Load Balance
(LB) Smart Roaming (SR) Power Control (POWER) Localization (LOC) Traffic Congestion Management
(TCM) Smart Band Steering (SB) y el moacutedulo Manager (MGR)
En este caso es de intereacutes resaltar el moacutedulo que permite la comunicacioacuten con la plataforma de gestioacuten CHT
Cloud Manager Dicho moacutedulo conocido bajo el nombre de MGR implementa un cliente AMQP para
establecer la comunicacioacuten con el broacuteker de eventos usado como intermediario para permitir la comunicacioacuten
entre los puntos de acceso y la plataforma de gestioacuten CHT Cloud Manager
Ademaacutes implementa una serie de estructuras de datos que son enviados a traveacutes de dicho intermediario basadas
en FlatBuffers como plataforma eficiente de serializacioacuten cruzada de datos ofrecida por Google Esta
herramienta permite crear un modelo de datos bajo la sintaxis ofrecida por FlatBuffers para posteriormente
generar dichas estructuras de datos en diferentes lenguajes de programacioacuten como por ejemplo C++ C C
Go Java JavaScript etc
Con esto se consigue generar estructuras de datos con una compatibilidad absoluta que se intercambiaraacuten entre
la plataforma de gestioacuten en lenguaje Java y los puntos de acceso en lenguaje C
61
412 Broacuteker de Eventos AMQP (RabbitMQ)
Este microservicio implementa un broacuteker de eventos que actuacutea como intermediario entre los puntos de acceso
WiFi y algunos microservicios que componen la plataforma Web de gestioacuten Se basa en el protocolo AMQP el
cual sigue el patroacuten publicadorsuscriptor como paradigma de comunicacioacuten indirecta
Estaacute involucrado en la entrega de mensajes entre los diferentes dispositivos embebidos con CHT y sus
respectivos servicios de gestioacuten en la plataforma Web de forma que los agentes que publican y consumen
eventos en el broacuteker no necesitan conocer al destinatario si no que el broacuteker es el que se encarga de publicar los
eventos para los destinatarios suscritos a eacutel En la siguiente figura se muestra la interfaz graacutefica de gestioacuten de
RabbitMQ [16]
Figura 31 Plataforma de Gestioacuten de RabbitMQ
Un broacuteker de eventos es un elemento del patroacuten PublicadorSuscriptor que recibe y mensajes de un conjunto de
elementos de red que quieren comunicarse ejecutan mecanismos de filtrado y permite la entrega correcta de los
diferentes mensajes a los consumidores correspondientes Por tanto el broacuteker de eventos permite ofrecer un
desacoplamiento entre emisores y receptores de la informacioacuten siendo este responsable de las tareas de
encaminamiento y reenvioacute de mensajes En conclusioacuten es responsable de coordinar la comunicacioacuten
proporcionando transparencia de acceso y localizacioacuten permitiendo la localizacioacuten de emisores y receptores
mediante un sistema de identificadores uacutenicos
Figura 32 Patroacuten PublicadorSuscriptor
62
413 Frontend
El Frontend de la plataforma Web estaacute implementado con Angular 6 HTML5 y CSS3 Su finalidad es ofrecer
una interfaz graacutefica al usuario final la cual permite mostrar el estado de los diferentes Zone Managers ademaacutes
de permitir el acceso a estos y gestionar el conjunto de puntos de acceso registrados en ellos de forma raacutepida e
intuitiva
Este microservicio recibe informacioacuten proporcionada por MoMap y los diferentes Zone Managers La
aplicacioacuten se sirve mediante un servidor Apache el cual proporciona una comunicacioacuten fiable con HTTPS
implementando una capa de transporte segura mediante el protocolo TLS
414 Zone Manager
Microservicio responsable de gestionar un conjunto de puntos de acceso CHT los cuales forman un despliegue
de red WiFi de Galgus para un cliente determinado Este microservicio estaacute formado por un servicio Web REST
implementado con Java Spring Framework desplegado en un servidor Jetty embebido y cuya persistencia se ha
implementado a traveacutes de Hybernate con el uso de Postgress SQL como gestor de bases de datos relacional
Un Zone Manager ofrece todas las tareas y acciones necesarias para configurar un conjunto de puntos de acceso
y consultar datos estadiacutesticos de usuarios conectados a dichos puntos de acceso entre otras Cabe destacar en
este punto la importancia que tiene el uso de FlatBuffers para garantizar la compatibilidad de datos enviados y
recibidos entre los puntos de acceso y el Zone Manager ambos implementados en tecnologiacuteas totalmente
diferentes
Figura 33 Ejemplo de Interfaz Graacutefica de un Zone Manager
63
415 MoMap
Dicho microservicio implementado en NodeJS gestiona y administra toda la infraestructura que conforma la
plataforma Web Establece y mantiene todas las conexiones y relaciones entre los diferentes puntos de acceso
con CHT y los Zone Managers (ZMB) que los gestiona
Ademaacutes este microservicio implementa una serie de maacutequinas de estado que permiten controlar el estado de
todos los Zone Managers y puntos de acceso CHT alertando sobre los eventos de error conexioacuten o desconexioacuten
en tiempo real a los usuarios finales a traveacutes del Frontend El soporte a la persistencia para dicho microservicio
se proporciona mediante MongoDB
Por tanto el microservicio MoMap actuacutea como proxy inverso HTTP2 Cuando un usuario intenta acceder a
traveacutes del Frontend de la plataforma Web puede gestionar y administrar un conjunto de Zone Managers o
administrar usuarios y asignar roles y permisos Tambieacuten se permite la creacioacuten eliminacioacuten y conexioacuten con un
Zone Manager redirigiendo las peticiones hacia el mismo
Cuando ocurre un evento de conexioacuten con un Zone Manager desde el microservicio MoMap se recupera y
enviacutea la informacioacuten necesaria para mostrar toda la informacioacuten correspondiente a ese Zone Manager en el
Frontend para el usuario final En la siguiente figura se muestra la interfaz graacutefica ofrecida por el servicio
MoMap a traveacutes del Frontend
Figura 34 Ejemplo de Interfaz Graacutefica de MoMap
64
416 Servidor de Licencias
El objetivo principal de este servicio es proporcionar una aplicacioacuten con una gestioacuten y control centralizado de
las licencias de todos los Puntos de Acceso desplegados con CHT Este servidor desplegado con Jetty de forma
embebida almacena el registro de un conjunto de Puntos de Acceso CHT para un conjunto de Clientes y
proyectos determinados Proporciona una API REST implementada con Java Spring Framework que permite
el registro de dichos dispositivos y la asignacioacuten de licencias CHT para habilitar los diferentes moacutedulos de dicha
aplicacioacuten embebida sobre los Puntos de Acceso Ademaacutes proporciona una interfaz Web de usuario
implementada con Angular 6 HTML5 y CSS3
En la siguiente figura se muestra un ejemplo de dicha interfaz graacutefica
Figura 35 Interfaz Graacutefica del Servidor de Licencias
4161 Zero-Touch Provisioning (ZTP)
En el contexto de la automatizacioacuten de redes WiFi el aprovisionamiento sin contacto es una caracteriacutestica
que permite que los puntos de acceso de una red se configuren automaacuteticamente evitando la intervencioacuten
humana para su configuracioacuten La configuracioacuten manual de dispositivos y conmutadores es costosa y
requiere lo que a menudo puede ser una gran cantidad de tiempo y esfuerzo dependiendo del tamantildeo de la
red [17]
Con el uso de sistemas automaacuteticos de aprovisionamiento y configuracioacuten se consigue reducir la carga de
trabajo y el esfuerzo que normalmente se requiere cuando se instalan y configuran nuevos dispositivos
Figura 36 Zero-Touch Provisioning (ZTP)
65
Haciendo uso de esta caracteriacutestica Galgus implementa en su infraestructura orientada a microservicios
un acceso directo de los Puntos de Acceso al servidor para que soliciten su licencia de CHT
automaacuteticamente de forma que cuando el usuario final vaya a instalar un Punto de Acceso CHT dicho
dispositivo obtendraacute su licencia de forma segura a traveacutes de la API REST del servidor de licencias siempre
y cuando esteacute registrado en el mismo y disponga de licencia sin necesidad de que el usuario intervenga en
dicho proceso
La comunicacioacuten entre los puntos de acceso y el resto de la infraestructura se realiza a traveacutes de un broacuteker
de eventos AMQP con su implementacioacuten en RabbitMQ Debido a esto cuando se crea y asigna licencia
a un dispositivo en el servidor de licencias dicho servidor crea un usuario en RabbitMQ de forma que el
punto de acceso en el momento que obtiene su licencia intentaraacute establecer conexioacuten con el broacuteker para
permitir el intercambio de eventos con los microservicios que lo gestionaraacuten mediante la plataforma CHT
Cloud Manager
Una vez el punto de acceso establece conexioacuten con el broacuteker de eventos este podraacute ser descubierto por el
Zone Manager que lo gestionaraacute El microservicio MoMap se encarga de establecer el descubrimiento de
los puntos de acceso comprobando si el punto de acceso estaacute registrado en el servidor de licencias con
licencia asignada y verificando que el punto de acceso estaacute operativo con conexioacuten a internet
42 Alcance y Objetivos de las pruebas sobre el sistema planteado
Una vez presentada y descrita toda la arquitectura de la plataforma Web ofrecida por Galgus se procederaacute a
detallar los principales objetivos del proceso de pruebas que se pretenderaacute conseguir sobre dicha aplicacioacuten Para
ello inicialmente se presentaraacute en queacute punto se encontraba el proceso de pruebas inicialmente
En este proyecto se ha centrado la atencioacuten en el conjunto de pruebas funcionales realizadas a la aplicacioacuten maacutes
concretamente las pruebas a nivel de aceptacioacuten
Dentro de las pruebas a nivel de aceptacioacuten los ingenieros de prueba hasta ahora habiacutean disentildeado un plan de
pruebas de aceptacioacuten o tests End-to-End los cuales se ejecutaban verificaban y validaban manualmente por
los ingenieros de QA Dicho plan de pruebas estaacute formado por una bateriacutea de casos de prueba a realizar sobre
las diferentes funcionalidades del sistema A continuacioacuten se muestra un fragmento de dicho plan de pruebas
Figura 37 Test Plan de CHT Cloud Manager
Como puede observarse en la figura anterior dicho plan de pruebas contiene un conjunto de casos de prueba
cada uno de ellos con un identificador uacutenico una descripcioacuten algunas especificaciones o detalles necesarios un
indicador de eacutexito o fallo y finalmente la descripcioacuten de los resultados obtenidos
Ademaacutes en dicho test plan se incluye una cabecera y una leyenda para clasificar los distintos resultados
obtenidos en la ejecucioacuten de las pruebas registrar algunos datos de relevancia y tener archivado dicho plan de
pruebas con las versiones de los diferentes microservicios que componen la plataforma Web
66
Figura 38 Leyenda del Test Plan
Figura 39 Control de Versiones del Test Plan
Una vez presentado el estado actual del proceso de pruebas a nivel de aceptacioacuten el nuevo equipo encargado de
evaluar la calidad de la plataforma Web planteoacute la oportunidad de automatizar dicho plan de pruebas Por tanto
el principal objetivo de este proyecto ha sido el de automatizar las actividades de ejecucioacuten y generacioacuten de
reportes de las pruebas de aceptacioacuten automatizadas sobre la aplicacioacuten
Sin embargo las actividades de planificacioacuten disentildeo e implementacioacuten de los diferentes casos de prueba se
realizaraacuten de forma manual haciendo uso de un conjunto de tecnologiacuteas que se usaraacuten para desarrollar la
automatizacioacuten de dichas pruebas Dichas tecnologiacuteas principalmente son Robot Framework Selenium y
Python las cuales se detallaraacuten maacutes adelante
En este punto es donde podriacutea entrar en juego la aplicacioacuten de Model-Based-Testing (MBT) detallado en la
seccioacuten 2 de este proyecto como teacutecnica que permite la abstraccioacuten de la actividad de implementacioacuten del plan
de pruebas mejorando el proceso de pruebas e independizando este de las actividades de desarrollo
En este proyecto queda fuera del alcance la aplicacioacuten de dicha teacutecnica debido a la necesidad de disponer de un
disentildeo completo y detallado de la plataforma Web para permitir la generacioacuten de los casos de prueba abstractos
y su posterior generacioacuten automaacutetica de los casos de prueba ejecutables Es de intereacutes destacar que a lo largo
del desarrollo del proyecto han ido surgiendo otros objetivos de intereacutes para mejorar el proceso de pruebas los
cuales permiten agilizar dicho proceso y ampliar su alcance
Entre estos objetivos se encuentran la generacioacuten automaacutetica de documentacioacuten del plan de pruebas la
implementacioacuten de un entorno de UAT (User Acceptance Testing) con Docker la integracioacuten de las pruebas a
nivel de aceptacioacuten en el proceso de integracioacuten continua del proyecto o la creacioacuten de un Docker que permita
ejecutar todo el plan de pruebas Todos estos objetivos se iraacuten detallando maacutes adelante
67
43 Arquitectura de la Solucioacuten Entorno de UAT para el proceso de pruebas (User Acceptance Test)
Hasta ahora dentro del proceso de desarrollo de la plataforma Web existiacutean las siguientes fases etapas o
entornos Desarrollo Preproduccioacuten y Produccioacuten
Bajo este contexto las actividades del proceso de pruebas eran realizadas sobre la fase de Preproduccioacuten Esto
provocaba una dependencia directa del cierre de la mayoriacutea de actividades de desarrollo para el despliegue en la
fase de Preproduccioacuten Como consecuencia la fase de pruebas a nivel de aceptacioacuten se podriacutea ver perjudicada
por esta metodologiacutea provocando en muchas ocasiones el retraso en el feedback necesario por los ingenieros de
desarrollo de los reportes e informes generados al ejecutar las pruebas de aceptacioacuten Para mejorar este proceso
se ha disentildeado un nuevo entorno de UAT en el proceso de desarrollo que permita disminuir la dependencia del
proceso de pruebas y desarrollo La inclusioacuten de este nuevo entorno ha sido posible gracias a la mejora del
proceso de integracioacuten continuacutea implementado en el desarrollo de la plataforma
Dentro de este proceso de integracioacuten continua se realiza la generacioacuten automaacutetica de los Docker que contienen
los diferentes microservicios de la plataforma Web en cualquier etapa del proceso de desarrollo Ademaacutes dentro
del proceso de integracioacuten continua se ha automatizado por parte de los ingenieros de desarrollo la ejecucioacuten
de pruebas unitarias y de integracioacuten que garantizan una miacutenima garantiacutea de estabilidad funcional de la
plataforma necesaria para el proceso de pruebas Partiendo de este punto el equipo de calidad ha disentildeado un
entorno de UAT con Docker el cual se muestra de forma graacutefica en la siguiente figura
Figura 40 Entorno de UAT con Docker (Anexo B)
68
69
5 TECNOLOGIacuteAS Y HERRAMIENTAS USADAS
na vez descrito el sistema bajo pruebas y presentada la arquitectura de la solucioacuten para el escenario de
pruebas con Docker se expondraacute a continuacioacuten el conjunto de tecnologiacuteas y herramientas usadas para
llevar a cabo el desarrollo de las pruebas automatizadas de aceptacioacuten o pruebas End-to-End Con este
conjunto de herramientas se pretende conseguir la implementacioacuten de los diferentes scripts de pruebas que
automaticen las acciones e interacciones necesarias con la plataforma Web CHT Cloud Manager como si de
una persona se tratase
51 Selenium
Selenium es una herramienta de coacutedigo abierto utilizada para la automatizacioacuten de pruebas en navegadores web
Dicha herramienta posee una enorme popularidad en el mundo de las pruebas de software debido a que
Presenta compatibilidad con diferentes lenguajes de programacioacuten para la implementacioacuten de scripts de
pruebas ofreciendo libreriacuteas en Java Python C PHP Ruby Perl y Net
Es multiplataforma permitiendo el lanzamiento de los scripts de pruebas en diversos sistemas
operativos como Windows Mac o Linux y en diferentes navegadores como Mozilla Firefox Internet
Explorer Google Chrome Safari y Opera
Soporta la integracioacuten con otras herramientas como TestNG o JUnit
Permite la integracioacuten continua con Maven Jenkins gitlab CICD y Docker
Sin embargo presenta una serie de inconvenientes que se deben mencionar
bull Solo permite probar aplicaciones Web
bull No hay soporte garantizado desde Selenium Muchas de las soluciones a problemas de la herramienta
han sido generadas por la comunidad
bull No es posible realizar pruebas en imaacutegenes Para ello es necesaria la integracioacuten con otras herramientas
bull No tiene capacidad nativa para generar informes o reportes de los resultados de las pruebas Para ello
se requiere el uso de un framework como puede ser el Robot Framework
Centrando la atencioacuten en el enfoque de dicho proyecto se haraacute uso de la libreriacutea Selenium para Python y la
facilidad de Robot Framework tanto para abstraer la posible complejidad antildeadida del lenguaje de programacioacuten
usado para la implementacioacuten de los scripts de prueba como para permitir la generacioacuten automaacutetica de informes
y reportes de resultados
Realmente Selenium estaacute formado por un conjunto de herramientas las cuales son Selenium RC Selenium
IDE Selenium Grid y Selenium Webdriver Dichas herramientas permiten desde la realizacioacuten de pruebas en
maacutequinas remotas a la ejecucioacuten de pruebas en diferentes maacutequinas con diferentes navegadores cada una
Con el lanzamiento de Selenium 2 en 2008 se antildeadieron nuevas funcionalidades de Selenium RC y Webdriver
en una misma herramienta aunque es frecuente mantener la nomenclatura de WebDriver a la hora de referirse
a la misma En este proyecto se centraraacute la atencioacuten en la herramienta WebDriver de Selenium
U
El disentildeo es el alma de todo lo creado por el hombre
Steve Jobs
70
52 Selenium WebDriver
Esta herramienta de Selenium ofrece una interfaz para ejecutar los casos de prueba descritos en los scripts
de prueba A traveacutes de esta API WebDriver se comunica directamente con el controlador del navegador
donde corre la aplicacioacuten Para ello seraacute necesario el uso de controladores para los diferentes navegadores
Web desde los que se validan las pruebas automaacuteticas
Todas las implementaciones de WebDriver que se comunican con el navegador usan un protocolo punto a
punto comuacuten Este protocolo define un servicio RESTfull usando JSON sobre HTTP Cada operacioacuten
realizada por WebDriver se mapea en un meacutetodo HTTP que se comunica con el navegador Las respuestas
a dichas operaciones seraacuten devueltas en mensajes HTTP de respuesta
Existen diversas implementaciones de Selenium para diferentes entornos tal y como se muestra en la
siguiente figura
Figura 41 Implementaciones disponibles de Selenium y Navegadores Web Compatibles
Para la ejecucioacuten de las pruebas implementadas en este proyecto se ha hecho uso de los controladores Gecko
Driver y Chromedriver para los navegadores Web Firefox y Google Chrome
521 Elementos del Navegador
Una vez tenemos una viacutea de comunicacioacuten con el navegador planteamos la pregunta iquesty coacutemo le indico al
navegador con queacute componente quiero interactuar
La cantidad de componentes que existen es muy amplia cajas de texto botones imaacutegenes hiperviacutenculos
botones de radio check boxes aacutereas de texto mensajes de error desplegables tablas frames etc Todos
estos elementos tienen una serie de propiedades que pueden ser uacutenicas o no en toda la paacutegina Por ejemplo
un identificador (ID) debe distinguir de manera uniacutevoca a un elemento Este identificador es lo que se
denomina un localizador Existen 8 tipos distintos de localizadores diferentes
bull Id Name Class Name Tag Name Link Text Partial Link Text CSS Xpath
71
Se podraacuten implementar las interacciones con el navegador mediante la llamada a un meacutetodo (accioacuten) que
se aplicaraacute sobre el elemento que nosotros indiquemos A continuacioacuten se muestra el diagrama de bloques
y la implementacioacuten de un ejemplo simple del inicio de sesioacuten usando Python y la libreriacutea de Selenium
Figura 42 Coacutedigo de ejemplo con Python y Selenium
La implementacioacuten anterior permite abrir un navegador Web Chrome en pantalla completa y acceder a la
plataforma Web Galgus CHT Cloud Manager Una vez ha sido posible el acceso y la paacutegina Web estaacute
disponible se realiza el inicio de sesioacuten en la plataforma con las credenciales correspondientes esperando que
dicho inicio de sesioacuten se haya realizado con eacutexito Finalmente se cierran todas las instancias de navegadores
Web abiertas por Selenium en la automatizacioacuten de dicha prueba de concepto
72
53 Robot Framework (RF)
Para la automatizacioacuten del testeo de la aplicacioacuten se ha hecho uso de este framework como herramienta
para dicha finalidad Robot Framework es un framework geneacuterico de automatizacioacuten de pruebas de coacutedigo
abierto desarrolla do por Pekka Klaumlrck en el antildeo 2005
Este framework sigue el enfoque Keyword-Driven Testing y es un candidato idoacuteneo debido a su alto nivel
de abstraccioacuten para pruebas de aceptacioacuten y desarrollo guiado por pruebas de aceptacioacuten o Acceptance
Test-Driven Development (ATDD) Las capacidades de pruebas pueden ser ampliadas con nuevas libreriacuteas
implementadas tanto en Python como en Java y los usuarios pueden crear nuevas keywords a partir de las
existentes usando la misma sintaxis que para los casos de prueba [18]
Robot Framework es independiente del sistema operativo y de la aplicacioacuten El nuacutecleo del framework estaacute
implementado en Python soportando tanto Python 2 como Python 3
Se ha decidido utilizar este framework por la disponibilidad de un amplio conjunto de libreriacuteas de propoacutesito
general y la integracioacuten con libreriacuteas externas como Selenium2Library Entre otras prestaciones permite el
uso de variables que aportan mayor flexibilidad a la hora de disentildear y controlar los scripts de prueba
permite el etiquetado para poder identificar y ejecutar los casos de prueba por separado proporciona una
faacutecil integracioacuten con Jenkins y Maven y proporciona un sistema de reporte de informes de resultados
detallados y de faacutecil lectura Ademaacutes hay que destacar la faacutecil abstraccioacuten que ofrece al poder utlizar
keywords de alto nivel permitiendo el uso del estilo de representacioacuten Given-When-Then para los casos
de prueba A continuacioacuten se describe dicho estilo de representacioacuten
531 Estilo de representacioacuten Given-When-Then
Dicho estilo ofrecido por Robot Framework es uno de los puntos fuertes de este framework Esta caracteriacutestica
permite el uso del siguiente estilo de representacioacuten para los casos de prueba
Figura 43 Estilo de representacioacuten Given-When-Then
bull Given Define las precondiciones necesarias para llevar a cabo la accioacuten asiacute como el actor de la
misma
bull When Accioacuten llevada a cabo por el actor definido en la claacuteusula Given
bull Then Es el comportamiento esperado o la salida del sistema esperada ante una entrada
determinada
bull And Claacuteusula auxiliar que se usa de forma combinada con las anteriores
73
Como ejemplo de aplicacioacuten de este estilo de representacioacuten supongamos que tenemos unos requisitos de
aceptacioacuten establecidos en un documento entre los que se encuentran el inicio y cierre de sesioacuten mediante
usuario y contrasentildea a la plataforma Galgus CHT Cloud Manager En la siguiente tabla se muestran los
criterios de aceptacioacuten definidos en el documento de requisitos para dicha funcionalidad
1 Un usuario no identificado puede iniciar sesioacuten desde la vista principal de la plataforma Web
2 Un usuario no identificado debe insertar un usuario y contrasentildea vaacutelidos para el inicio de sesioacuten
A continuacioacuten se muestra coacutemo se llevariacutea a cabo la implementacioacuten de los scripts de pruebas abstractos
asociados a las especificaciones anteriores haciendo uso del estilo de representacioacuten Given-When-Then
Es complicado implementar todos los casos de prueba posibles principalmente cuando el requisito de
aceptacioacuten requiere de una funcionalidad compleja En este caso se muestran tres casos de prueba
abstractos los cuales han sido implementados en el proyecto para validar el inicio y cierre de sesioacuten
Caso de Prueba 1 Inicio de Sesioacuten en Galgus CHT Cloud Manager
Claacuteusula Keyword
Given Navegacioacuten a la paacutegina principal de Galgus CHT Cloud Manager
When Insertar nombre de usuario vaacutelido
And Insertar contrasentildea vaacutelida
Then Iniciar sesioacuten con eacutexito
Caso de Prueba 2 Intento de Inicio de sesioacuten con usuario no vaacutelido
Claacuteusula Keyword
Given Navegacioacuten a la paacutegina principal de Galgus CHT Cloud Manager
When Insertar nombre de usuario invaacutelido
And Insertar contrasentildea vaacutelida
Then No es posible el inicio de sesioacuten Se muestra mensaje de error
Caso de Prueba 3 Intento de Inicio de sesioacuten con contrasentildea no vaacutelida
Claacuteusula Keyword
Given Navegacioacuten a la paacutegina principal de Galgus CHT Cloud Manager
When Insertar nombre de usuario vaacutelido
And Insertar contrasentildea invaacutelida
Then No es posible el inicio de sesioacuten Se muestra mensaje de error
74
En la siguiente figura se muestra la implementacioacuten de dichas pruebas con Robot Framework donde cada
Keyword implementada permite la abstraccioacuten de toda la funcionalidad necesaria para realizar las pruebas
Figura 44 Implementacioacuten de Pruebas en para el inicio de sesioacuten de CHT Cloud Manager
75
532 Reportes
A continuacioacuten se muestra un ejemplo de los reportes obtenidos tras la ejecucioacuten del primer caso de prueba de
los anteriores donde pueden identificarse las diversas keywords necesarias para implementar cada caso de
prueba asiacute como otras adicionales que ayudan a crear el contexto (precondiciones) Tambieacuten se incluyen
estadiacutesticas sobre el tiempo de ejecucioacuten nuacutemero de tests total nuacutemero de tests que han fallado o que han pasado
con eacutexito [18]
Figura 45 Ejemplo de reporte de pruebas automatizadas con Robot Framework
76
533 Libreriacuteas
Robot Framework permite el uso de Selenium mediante la libreriacutea de pruebas Web SeleniumLibrary Dicha
libreriacutea es compatible con las versiones de Selenium 2536 y sucesivas y con Python 27 y Python 3 Ademaacutes
del inteacuterprete por defecto de Python esta libreriacutea funciona tambieacuten con PyPy y Jython [18]
Esta libreriacutea estaacute compuesta entre otras muchas por una serie de archivos de Python (py) que implementan
las clases que contienen las diversas keywords que pueden ser usadas en nuestro framework La estructura de
estos archivos se presenta en la siguiente tabla
Archivo de Clase Funcioacuten
Alertpy Interacciones con mensajes de alerta
Browsermanagementpy Apertura cierre y cambio de navegadores
Cookiepy Manipulacioacuten de cookies del navegador
Elementpy Interaccioacuten con elementos y sus atributos
Formelementpy Interaccioacuten con elementos en formularios
Framespy Manejo de frames y su contenido
Javascriptpy Facilidades para inyectar coacutedigo javascript
Runonfailurepy Uso de funcionalidades en caso de fallo
Screenshotpy Manejo de capturas de pantalla
Selectelementpy Manejo de elementos en listas
Tableelementpy Manejo de elementos en tablas
Waitingpy Manejo de temporizadores de espera para
transiciones en una paacutegina
Webdrivertoolspy Interaccioacuten directa con el controlador del navegador
Windowpy Manejo de ventanas del navegador
Estas libreriacuteas fueron desarrolladas en sus oriacutegenes por el ingeniero finlandeacutes Tatu Aalto y posteriormente
mejoradas por toda la comunidad de expertos en automatizacioacuten de pruebas Sin embargo Robot Framework
mediante el uso de Python con Selenium permite la implementacioacuten de libreriacuteas propias o funcionalidades
desarrolladas en Python que pueden ser integradas en Robot Framework En este proyecto se hace uso de Python
con Selenium para desarrollar algunas funcionalidades avanzadas que permiten probar ciertos criterios de la
aplicacioacuten muy especiacuteficos y avanzados de la plataforma Web para los cuales las libreriacuteas ofrecidas por Robot
Framework no proporcionan la funcionalidad requerida
Ademaacutes se ha hecho uso de otras libreriacuteas como BuiltIn para el uso de bucles condicionales y otras keywords
String y Collections para el tratamiento de cadenas de caracteres y colecciones de datos SSHLibrary para usar
un cliente ssh Process para la ejecucioacuten de subprocesos haciendo uso la libreriacutea subprocess de python y
OperatingSystem para realizar algunas tareas sobre el sistema operativo
77
534 Documentacioacuten
La documentacioacuten de los diferentes casos de pruebas implementados con Robot Framework es muy redundante
y una tarea la cual seriacutea deseable de poder automatizar Dicho framework ofrece esta posibilidad a traveacutes de dos
herramientas para crear documentacioacuten basada en las pruebas y libreriacuteas implementadas para dichas pruebas
Libdoc y Testdoc [18]
5341 Libdoc
Libdoc es una herramienta ofrecida por Robot Framework para construir documentacioacuten sobre las keywords
implementadas para los casos de prueba Dicha documentacioacuten es generada en formato HTML y XML
Se puede crear documentacioacuten para bibliotecas implementadas con Python o Java y para las propias libreriacuteas
implementadas con Robot Framework A continuacioacuten se muestra un ejemplo de la documentacioacuten generada
para la libreriacutea implementada para los casos de prueba de inicio y cierre de sesioacuten de Galgus CHT Cloud
Manager
Figura 46 Ejemplo de documentacioacuten generada con Libdoc
5342 Testdoc
Testdoc es una herramienta para generar documentacioacuten de alto nivel basada en los casos de prueba de Robot
Framework Dicha documentacioacuten es generada en formato HTML e incluye el nombre la documentacioacuten y
otros metadatos de cada conjunto de pruebas y casos de prueba asiacute como las keywords de alto nivel y sus
argumentos
A continuacioacuten se muestra un ejemplo de la documentacioacuten generada para el conjunto de casos de prueba que
validan el inicio y cierre de sesioacuten de Galgus CHT Cloud Manager
Figura 47 Ejemplo de documentacioacuten generada con Testdoc
78
54 Pycharm (IDE)
Esta herramienta proporciona un entorno de desarrollo integrado (IDE) el cual ha sido usado para programar en
lenguaje Python por lo que es idoacuteneo tambieacuten para el desarrollo de pruebas con Robot Framework Esta
desarrollado por la empresa JetBrains Ademaacutes proporciona entre otras muchas herramientas el anaacutelisis de
coacutedigo un depurador graacutefico integracioacuten con sistemas de control de versiones y es multiplataforma
55 GitGitlab
551 Git
Git es un software de control de versiones disentildeado por Linux Torvalds pensando en la eficiencia y la
confiabilidad del mantenimiento de versiones de aplicaciones cuando eacutestas tienen un gran nuacutemero de archivos
de coacutedigo fuente Al principio Git se pensoacute como un motor de bajo nivel sobre el cual otros pudieran escribir la
interfaz de usuario como Cogito o StGIT Sin embargo Git se ha convertido desde entonces en un sistema de
control de versiones con funcionalidad plena Hay algunos proyectos de mucha relevancia que ya usan Git en
particular el grupo de programacioacuten del nuacutecleo Linux Ademaacutes cabe destacar que se ha hecho uso de
GitKraken como interfaz graacutefica de git para llevar a cabo el control de versiones de una forma maacutes intuitiva
552 Gitlab
Gitlab es un servicio Web de control de versiones y desarrollo de software colaborativo basado en Git Fue
implementado por los desarrolladores ucranianos Dimitry Zaporozhets y Valey Sizov en el lenguaje de
programacioacuten Ruby Este proyecto cuenta con un equipo de 150 miembros y maacutes de 1400 usuarios y es usado
por empresas como la NASA el CERN IBM o Sony [19]
Ademaacutes de gestor de repositorios tambieacuten ofrece la posibilidad de alojar documentacioacuten y un sistema de
seguimiento de errores Tambieacuten es de gran importancia destacar que esta herramienta proporciona su propia
herramienta de Integracioacuten Continua sin necesidad de usar otra herramienta externa
Se ha hecho uso de estas herramientas para tener un control de versiones sobre nuestro proyecto y una gestioacuten
centralizada de todos los repositorios de la empresa de forma que asiacute podemos tener un control de versiones de
todos los cambios realizados en el coacutedigo con posibilidad de contrastarlos con versiones anteriores y recuperar
dichos cambios Ademaacutes se hace uso tambieacuten de gitlab CICD para implementar procesos de Integracioacuten
continua sobre los diferentes proyectos En el caso particular de este proyecto para generar la documentacioacuten
de los casos de test y libreriacuteas y para generar un Docker con toda la bateriacutea de pruebas y dependencias necesarias
para lanzarlas
56 Redmine
Redmine es una herramienta para la gestioacuten de proyectos que ofrece un conjunto de funcionalidades que
permiten a los usuarios de diferentes proyectos realizar el seguimiento y organizacioacuten de los mismos Incluye
un sistema de seguimiento de incidentes Otras herramientas que incluye son un calendario de actividades
diagramas de Gantt una wiki para almacenar documentacioacuten control del flujo de trabajo basado en roles
integracioacuten con correo electroacutenico etc
Esta herramienta se usa para la gestioacuten del proyecto Galgus CHT Cloud Manager donde se integra como
subproyecto la automatizacioacuten del proceso de pruebas para la plataforma Web desarrollada
A continuacioacuten se muestra un ejemplo del flujo de trabajo implantado en la metodologiacutea de trabajo dentro del
proyecto donde cada historia puede contener un conjunto de tareas las cuales pueden pasar por diferentes
estados hasta ser completadas por el desarrollador o el ingeniero de pruebas
79
Figura 48 Ejemplo de Flujo de Trabajo en Redmine para Galgus CHT Cloud Manager
561 Uso en el Proyecto Galgus CHT Cloud Manager (Metodologiacutea Scrum)
Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas praacutecticas para trabajar
colaborativamente en equipo y obtener el mejor resultado posible de un proyecto Estas praacutecticas se apoyan
unas a otras y su seleccioacuten tiene origen en un estudio de la manera de trabajar de equipos altamente productivos
Esta metodologiacutea divide el trabajo en una lista de pequentildeas funcionalidades ordenadas por prioridad y estimadas
en esfuerzo Estas pequentildeas tareas son abordadas en iteraciones cortas de longitud fija denominadas Sprints de
1 a 4 semanas (en este caso se ha optado por iteraciones de 3 o 4 semanas) obteniendo coacutedigo potencialmente
entregable siendo demostrado al final de cada iteracioacuten Una vez decidido por el equipo de gestioacuten de proyectos
el alcance y conjunto de actividades a realizar dentro del sprint se transmite al resto del equipo que forma parte
del proyecto procediendo a la asignacioacuten de tareas mediante Redmine como herramienta de gestioacuten usada
Durante el sprint se va realizando un seguimiento perioacutedico del estado del proyecto y de la situacioacuten de cada
integrante mediante una actividad previa diaria de unos 15 minutos para situar el punto de partida de trabajo
diario que seriacutean reuniones diarias de apenas 15 minutos denominadas ldquoDaylisrdquo
Figura 49 Esquema Graacutefico de Metodologiacutea Scrum
80
La planificacioacuten que se pretende seguir en cada sprint es la siguiente
1 Semana 1 y 2 Realizacioacuten de tareas por parte del equipo de desarrollo incluyendo en estas tareas
nuevos desarrollos modificacioacuten de funcionalidades y verificacioacuten de las mismas mediante pruebas
unitarias y de integracioacuten
2 Semana 3 Realizacioacuten de pruebas de aceptacioacuten manuales por parte del equipo de pruebas y posterior
automatizacioacuten de dichas pruebas Para ello se usaraacute el entorno de UAT como escenario de pruebas
Ademaacutes el equipo de desarrollo iraacute corrigiendo todos aquellos errores o defectos encontrados
3 Semana 4 El jefe de proyecto realiza la fusioacuten de todos los desarrollos y actualiza las versiones en el
entorno de Preproduccioacuten incluyendo todas las actividades realizadas y validadas por el equipo de
desarrollo y de pruebas El equipo de pruebas realizaraacute la ejecucioacuten de todas las pruebas End-to-End
sobre el entorno de Preproduccioacuten para verificar y validar la nueva versioacuten que incluye todas las
funcionalidades Estas pruebas son denominadas pruebas de regresioacuten las cuales verifican que los
nuevos desarrollos no han provocado defectos o errores sobre funcionalidades que hasta ahora habiacutean
funcionado correctamente Finalmente el jefe de proyecto realiza el despliegue en produccioacuten
81
82
6 EXPERIMENTOS
na vez descrito el sistema bajo pruebas el proceso de pruebas y las herramientas que se usaraacuten para
automatizar las pruebas de aceptacioacuten sobre la plataforma de gestioacuten Galgus CHT Cloud Manager
solo queda presentar la forma en la que se ha puesto en praacutectica y el proceso seguido paso a paso
Dado que el objetivo es conseguir una bateriacutea de casos de pruebas End-to-End automatizadas se implementaraacuten
dichos casos de prueba de forma que permitan detectar el incorrecto funcionamiento de cada funcionalidad con
la mayor rapidez posible cubriendo los principales escenarios donde puedan surgir los mayores errores Por
tanto dichos casos de prueba seraacuten elegidos en base al riesgo que puedan introducir
Estos casos de prueba seraacuten definidos mediante un conjunto de criterios de aceptacioacuten descritos a traveacutes de
diagramas de flujo y agrupados seguacuten la funcionalidad de la aplicacioacuten que abarquen las cuales son
1 Vista de Gestioacuten Principal (Coud Tab) Esta seccioacuten de la Web estaacute destinada a la administracioacuten de
usuarios administracioacuten de los diferentes Zone Managers y finalmente incluye un Mapa con la
ubicacioacuten de cada Zone Manager
2 Vista de Configuracioacuten (Configuration Tab) En esta pestantildea se ofrece la gestioacuten de grupos de puntos
de acceso gestioacuten de backups y restauracioacuten gestioacuten de firmwares zonas CHT etc
3 Vista de Red (Network Tab) La pestantildea de red engloba toda la configuracioacuten de red de los puntos de
acceso siendo esta la pestantildea con mayor funcionalidad complejidad y por ello potencial de riesgo de
errores de la plataforma Web
Figura 50 Logo de Galgus CHT Cloud Manager
U
La uacutenica parte donde el ldquoeacutexitordquo aparece antes que el trabajo es en el diccionario
Vidal Sasoon
83
61 Estructura del Proyecto
La clasificacioacuten funcional anterior seraacute tomada de la misma forma para organizar la estructura del proyecto de
pruebas automatizadas con Robot Framework para un desarrollo ordenado y loacutegico de todo el conjunto de casos
de prueba A continuacioacuten se muestra un ejemplo de la estructura del proyecto el cual se encuentra en desarrollo
y continua mejora
Figura 51 Estructura del Proyecto
Para una mayor modularidad y limpieza en el desarrollo de los casos de Test se han centralizado todos los
localizadores en un archivo llamado ldquoSelectorpyrdquo En la siguiente figura se muestra un fragmento de dicho
fichero
Figura 52 Fragmento del fichero ldquoSelectorpyrdquo
A la hora de obtener los localizadores de los elementos que seraacuten comprobados o usados en los scripts de pruebas
se han usado las herramientas de desarrollador que incluye Google Chrome Para ello basta con navegar a la
paacutegina de la plataforma Web en cualquier navegador y pulsar la tecla F12 Esto mostraraacute las herramientas de
desarrolladores donde encontramos una pestantildea llamada ldquoElementosrdquo donde se puede inspeccionar el
documento ldquoHTMLrdquo de la paacutegina Una vez abierta dicha herramienta seraacute sencillo obtener propiedades de los
diversos elementos que nos permitiraacuten hacer referencia a los mismos en nuestro script de pruebas
Los ldquoXpathrdquo absolutos seraacuten lo usados praacutecticamente en toda la Suite de pruebas El beneficio de los
identificadores uacutenicos es que permiten seleccionar elementos sin que sea necesario hacer referencia a su posicioacuten
dentro del documento HTML Esto evita cualquier problema en caso de que las rutas de un elemento dentro del
citado documento cambien debido a mejoras o despistes por parte de los desarrolladores En cambio usar
selectores basados en la ruta del elemento dentro del documento HTML puede propiciar falsos fallos en el
escenario anterior debido a que no puedan encontrarse en la Web a pesar de que realmente sigan estando
presentes y totalmente funcionales
Por otro lado se han agrupado todas aquellas ldquokeywordsrdquo que puedan ser usadas por otras secciones en la
implementacioacuten de los casos de prueba mediante ficheros nombrados como ldquotab_common_keywords robotrdquo
84
Siguiendo esta jerarquiacutea se ha incluido un fichero llamado ldquoCommon_Keywordsrobotrdquo general en el que se
incluyen las principales ldquokeywordsrdquo que pueden ser usadas en todo el proyecto A continuacioacuten se muestra un
fragmento de este fichero
Figura 53 Fragmento del fichero ldquoCommon_Keywordsrobotrdquo
Tambieacuten se incluye el fichero ldquoConfigurationrobotrdquo para agrupar definiciones de variables que seraacuten
usadas en todo el proyecto ademaacutes de realizar la inclusioacuten de las libreriacuteas a usar Se muestra otra figura
con un fragmento del fichero ldquoConfigurationrobotrdquo
Figura 54 Fragmento del fichero de Configuracioacuten de pruebas ldquoConfigurationrobotrdquo
85
A continuacioacuten se muestra un diagrama que muestra las dependencias de los diferentes archivos y la estructura
seguida por el proyecto
Figura 55 Diagrama de paquetes del proyecto de pruebas
Tras introducir la estructura del proyecto y las diferentes funcionalidades de la plataforma Web Galgus CHT
Cloud Manager a continuacioacuten se mostraraacuten algunos criterios de aceptacioacuten de cada funcionalidad a probar
con diagramas de flujo y scripts de pruebas haciendo uso del estilo de representacioacuten Given-When-Then
Ademaacutes se mostraraacuten algunos detalles de implementacioacuten sobre las pruebas Por otro lado la ejecucioacuten de los
casos de prueba de ejemplo y el reporterevisioacuten de resultados se incluiraacute en la seccioacuten de Anexos
Cada una de las siguientes subsecciones dentro de cada funcionalidad principal de la aplicacioacuten o vista principal
tendraacute su correspondiente Suite de pruebas con un conjunto de casos de Test Todas estas Suites seguiraacuten la
siguiente estructura comuacuten para los casos de Test
Figura 56 Estructura de una Suite de Pruebas
86
Todas las Suites comienzan con una seccioacuten de documentacioacuten para describir el contenido de las pruebas de forma geneacuterica y varias secciones para importar los recursos necesarios para las pruebas (Resource)
Las secciones ldquoSuite Setuprdquo y ldquoSuite Teardownrdquo permiten la ejecucioacuten automaacutetica antes y despueacutes de la bateriacutea de pruebas y las secciones ldquoTest Setuprdquo y ldquoTest Teardownrdquo permiten la ejecucioacuten automaacutetica antes y despueacutes de cada caso de prueba
Un uso tiacutepico de ldquoSuite Setuprdquo es abrir un navegador Web y comprobar la disponibilidad de la Web a probar mientras que el cierre del navegador se realiza con ldquoSuite Teardownrdquo De este modo sea cual sea el resultado de la ejecucioacuten no se quedaraacuten abiertas ventanas gastando recursos de la maacutequina
Por otro lado el uso por defecto de ldquoTest Setuprdquo en este proyecto ha sido el inicio de sesioacuten en la Web CHT Cloud Manager mientras que ldquoTest Teardownrdquo ha sido usado para cerrar tambieacuten el navegador Web Sin embargo la mayoriacutea de las pruebas implementadas necesitan una serie de precondiciones previas a la ejecucioacuten del Test y un conjunto de postcondiciones necesarias para no provocar inconsistencias entre la ejecucioacuten de diferentes pruebas Por este motivo se ha hecho uso de las etiquetas [Setup] y [Teardown] para modificar la ejecucioacuten por defecto de ldquoTest Setuprdquo y ldquoTest Teardownrdquo en cada caso de prueba cuando sea necesario
Cabe destacar que la loacutegica implementada dentro de estas claacuteusulas no requiere que sea validada puesto que su uacutenico objetivo es preparar el entorno de pruebas para ejecutar una prueba sin que esta falle por causas ajenas al aacutembito y objetivo de la prueba evitando de esta forma los falsos positivos Por este motivo se hace uso de la Keyword ldquoRun Keyword And Ignore Errorrdquo ofrecida por la libreriacutea ldquoBuiltInrdquo para ignorar los errores en la ejecucioacuten de [Setup] y [Teardown] En la siguiente figura se muestra un ejemplo de dicha teacutecnica
Figura 57 Ejemplo de ldquoTest Setuprdquo personalizado para un caso de prueba
Finalmente la implementacioacuten de las ldquokeywordsrdquo usadas mediante la nomenclatura Given-When-Then seraacuten agrupadas en el correspondiente fichero ldquoTab_common_keywordsrobotrdquo para conseguir una abstraccioacuten de la loacutegica necesaria para la automatizacioacuten de las pruebas En las pruebas seleccionadas para describir en esta seccioacuten se detallaraacute la implementacioacuten de algunas keywords que se usaraacuten
87
62 Vista de Gestioacuten Principal (Cloud Tab)
En la siguiente figura se muestra la vista de Gestioacuten Principal de Galgus CHT Cloud Manager
Figura 58 Vista de Gestioacuten Principal (Cloud Tab)
Sobre esta vista se han automatizado un conjunto de Suites de pruebas que validan toda la funcionalidad
contenida en las pestantildeas MAP List of Zone Managers y Administration ademaacutes de toda la loacutegica ofrecida para
gestionar un conjunto de fabricantes
621 Administration
Comenzando con la pestantildea de administracioacuten se puede observar la existencia de cuatro flujos de navegacioacuten
principales en la siguiente figura
Figura 59 Pestantildea ldquoAdministrationrdquo
Una vez conocida la vista de administracioacuten de la Web se han realizado un total de 22 casos de prueba de los
cuales detallaremos el caso de prueba identificado con la etiqueta U0027
6211 Criterios de Aceptacioacuten
La pestantildea de administracioacuten permite la gestioacuten de los usuarios y roles que tienen acceso a la plataforma Web
ademaacutes de la configuracioacuten de los detalles de los fabricantes seleccionados A continuacioacuten se detallan los
criterios de aceptacioacuten del caso de prueba seleccionado
U0027 Un usuario con permisos de Super Usuario puede editar la informacioacuten de un fabricante
1 Un usuario con permisos de Super Usuario puede ver y acceder a la pestantildea de administracioacuten
2 Un usuario con permisos de Super Usuario puede editar la informacioacuten de un fabricante correctamente
88
6212 Diagramas de Flujo
A continuacioacuten se muestran los diagramas de flujo implementados para los dos casos de prueba analizados
Figura 60 Diagramas de Flujo de Casos de Prueba U0025 y U0027
6213 Script de Pruebas
Una vez establecidos los criterios de aceptacioacuten de ambos casos de prueba se mostraraacuten los scripts de pruebas
realizados
Figura 61 Script de Pruebas U0025
Entre las ldquokeywordsrdquo usadas en el caso de test anterior se puede destacar por ejemplo la implementacioacuten de
ldquoEdit Fieldsrdquo la cual permite editar los campos de un fabricante y verificar que han sido editados tras guardar
los cambios
Figura 62 Keyword ldquoEdit Fieldsrdquo
89
622 List
En la pestantildea de gestioacuten de los diferentes Zone Managers se puede observar una lista de los diferentes Zone
Managers disponibles y se pueden realizar un conjunto de acciones como la creacioacuten de nuevos Zone Managers
y edicioacuten o eliminacioacuten de los existentes entre otras
Figura 63 Pestantildea ldquoList of Zone Managersrdquo
Sobre esta vista se han realizado un total de 7 casos de prueba de los cuales detallaremos el caso de prueba
identificado con la etiqueta U0023 el cual permite validar la creacioacuten y eliminacioacuten de un Zone Manager
6221 Criterios de Aceptacioacuten
A continuacioacuten se detallan los criterios de aceptacioacuten del caso de prueba seleccionado
U0023 Verificar que un Usuario puede Crear y Eliminar un Zone Manager
1 Un usuario con permisos de Super Usuario puede Navegar a la pestantildea List Of Zone Managers
2 El usuario puede crear un Zone Manager correctamente
3 El usuario puede eliminar un Zone Manager correctamente
6222 Diagramas de Flujo
A continuacioacuten se muestra el diagrama de flujo implementado para el caso de prueba analizado
Figura 64 Diagrama de flujo de Caso de Prueba U0023
90
6223 Script de Pruebas
Una vez establecidos los criterios de aceptacioacuten se mostraraacute el script de pruebas realizado a partir del diagrama
de flujo anterior
Figura 65 Script de Prueba U0023
Cabe destacar la implementacioacuten de la Keyword ldquoZone Manager is Registered Successfullyrdquo la cual comprueba
que el Zone Manager registrado pasa a un estado ldquoOnlinerdquo tras un tiempo considerado como aceptable para que
la instancia de dicho Zone Manager este disponible en Cloud CHT Manager
Figura 66 Keyword ldquoZone Manager is registered successfullyrdquo
623 Manufacturer
La vista de gestioacuten principal ofrece una seccioacuten que permite la gestioacuten de los diferentes fabricantes permitiendo
su creacioacuten edicioacuten eliminacioacuten y bloqueo En la siguiente figura se muestra un ejemplo de la seccioacuten de
fabricantes
Figura 67 Seccioacuten de Fabricantes
Para validar el correcto funcionamiento de dicha seccioacuten se han realizado un total de 9 casos de prueba de los
cuales se detallaraacuten los casos de prueba identificados con las etiquetas U0009 Estos permiten validar que los
fabricantes pueden ser creados editados y eliminados correctamente y que todos los fabricantes disponibles son
mostrados correctamente
91
6231 Criterios de Aceptacioacuten
A continuacioacuten se detallan los criterios de aceptacioacuten de los casos de prueba seleccionados
U0009 Verificar que un Usuario con permisos de Super usuario puede ver correctamente todos los
fabricantes existentes
1 Un usuario con permisos de Super Usuario puede Navegar a la pestantildea de Administracioacuten
2 El usuario puede visualizar todos los fabricantes existentes
6232 Diagrama de Flujo
Figura 68 Diagrama de flujo de Caso de Prueba U0009
6233 Script de Pruebas
Una vez establecidos los criterios de aceptacioacuten se mostraraacuten los scripts de pruebas realizados a partir de los
diagramas de flujo anteriores
Figura 69 Script de Prueba U0009
En este punto cabe destacar la finalidad de la Keyword ldquoCorrectly Createrdquo la cual se usa en la mayoriacutea de las
pruebas para verificar que una operacioacuten se ha realizado con eacutexito en la plataforma Galgus CHT Cloud Manager
Esta Keyword verifica que tras realizar alguacuten tipo de operacioacuten en la plataforma Web ocurre un evento sobre la
Web que indica que dicha operacioacuten se ha realizado con eacutexito de la siguiente forma
92
Figura 70 Toast Success
Figura 71 Keyword ldquoCorrectly Createrdquo
Finalmente se muestra la implementacioacuten de las keywords usadas en [Setup] y [Teardown] del caso de prueba
U0009 las cuales preparan el escenario de pruebas creando un conjunto de fabricantes acotado y los elimina
tras la finalizacioacuten de la prueba
Figura 72 Setup amp Teardown de U0008
624 MAP
La plataforma Galgus CHT Cloud Manager ofrece una pestantildea ldquoMAPrdquo que contiene un mapa con la ubicacioacuten
asignada a cada uno de los Zone Managers disponibles por el usuario mostrando en su ubicacioacuten un icono con
el estado de dicho Zone Manager el cual cambia de color seguacuten su estado (offline online unsynchronized)
Figura 73 Mapa de Zone Managers
93
A traveacutes de dicho icono se puede realizar una serie de acciones entre ellas acceder a un Zone Manager
realizando doble click sobre el icono del mismo Sin embargo para automatizar este conjunto de acciones el
equipo de pruebas ha encontrado dificultades haciendo uso de Robot Framework ya que las libreriacuteas disponibles
permiten la interaccioacuten con elementos de la Web pero en este caso los iconos de los diferentes Zone Managers
son renderizados dentro del Mapa con ldquoOpen Street Mapsrdquo antes de ser mostrado en la vista Web de la
aplicacioacuten Por esta razoacuten el mapa es localizado en el DOM como un uacutenico elemento Web lo que imposibilita
localizar a priori el icono de cada Zone Manager dentro del Mapa
Para resolver este impedimento el equipo de pruebas tuvo que analizar con profundidad la libreriacutea de ldquoOpen
Street Maprdquo implementada en Javascript Esta ha sido usada en el Frontend para encontrar alguna funcioacuten que
permitiese obtener desde la consola del navegador Web los piacutexeles en los que cada Zone Manager ha sido
renderizado dentro del Mapa Dicha funcioacuten es ldquogetPixelsFromCoordinate(coordinate)rdquo la cual a traveacutes de las
coordenadas de [Latitud Longitud] de cada Zone Manager se obtienen los piacutexeles del mismo en la pantalla A
traveacutes del siguiente fragmento de coacutedigo en el frontend implementado con Angular 6 en typescript se consigue
obtener los piacutexeles de cada Zone Manager e imprimirlo en la consola del navegador Web
Figura 74 Funcioacuten que dibuja los ZM en el Mapa y obtiene los piacutexeles en pantalla
Para llevar a cabo la implementacioacuten de las pruebas sobre el mapa se ha hecho uso en su gran mayoriacutea de Scripts
con Python Selenium y otras libreriacuteas necesarias en lugar de Robot Framework debido a la necesidad de
realizar varias tareas simultaneas ademaacutes de tratarse de pruebas muy especiacuteficas y personalizadas A
continuacioacuten se muestra la prueba implementada para poder realizar doble click sobre un Zone manager en el
mapa e iniciar sesioacuten en el mismo (U0007)
6241 Criterios de Aceptacioacuten
U0007 Verificar que un Usuario acceder a un Zone Manager desde el Mapa
1 Un usuario con permisos de Super Usuario puede Navegar a la pestantildea MAP
2 El usuario puede hacer doble click en el Zone Manager e iniciar sesioacuten
94
6242 Diagrama de Flujo
Figura 75 Diagrama de Flujo de Caso de Prueba U0007
6243 Script de Pruebas
Para la implementacioacuten de este tipo de casos de prueba se ha hecho uso de la libreriacutea ldquoHtmlTestRunnerrdquo para
obtener un reporte similar al ofrecido por Robot Framework en la ejecucioacuten de la prueba Para obtener un reporte
de la prueba la implementacioacuten de la misma debe seguir una estructura determinada a la que ademaacutes se ha
incluido a traveacutes de la libreriacutea ldquomultiprocessingrdquo la ejecucioacuten simultaacutenea de los dos procesos descritos en el
diagrama de flujo anterior Es necesaria la ejecucioacuten de varios procesos para leer la consola del navegador Web
y obtener los piacutexeles de los Zone Manager para posteriormente hacer doble click
En la Seccioacuten A3 de los anexos puede encontrarse la implementacioacuten del script de pruebas para el caso de
prueba U0007
95
63 Vista de Configuracioacuten (Configuration Tab)
En esta vista se ha automatizado un conjunto de Suites de prueba que validan toda la funcionalidad contenida
en las pestantildeas Groups CHT Zones BackupRestore y Firmware
631 Groups
La pestantildea de grupos permite el descubrimiento de los puntos de acceso a traveacutes de su direccioacuten MAC quedando
estos registrados en base de datos y mostrando al usuario en una tabla los puntos de acceso registrados ademaacutes
del estado de los mismos y otros datos como el modelo o grupo al que pertenecen
Figura 76 Pestantildea ldquoGroupsrdquo
Sobre esta funcionalidad de la plataforma se han realizado un total de 19 casos de prueba de los cuales
detallaremos el caso de prueba identificado con la etiqueta U0119
6311 Criterios de Aceptacioacuten
U0119 Verificar que al descubrir dos puntos de acceso en grupos diferentes ambos son antildeadidos en el
grupo correcto
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Configuracioacuten
3 El usuario puede Navegar a la pestantildea de Grupos
4 El usuario puede descubrir un punto de acceso en el grupo ldquorootrdquo correctamente
5 El usuario puede crear un subgrupo predecesor del grupo ldquorootrdquo correctamente
6 El usuario puede navegar al subgrupo creado correctamente
7 El usuario puede descubrir un punto de acceso en el subgrupo correctamente
96
6312 Diagramas de Flujo
Figura 77 Diagrama de flujo de Caso de Prueba U0119
97
6313 Script de Pruebas
Una vez establecidos los criterios de aceptacioacuten el script de prueba realizado a partir del diagrama de flujo
anterior es el siguiente
Figura 78 Script de Prueba U0119
Entre las keywords implementadas para esta prueba cabe destacar la implementacioacuten de ldquoVerify if AP is
registered Succesfully on grouprdquo la cual permite validar si un punto de acceso ha sido asignado al grupo
correcto
Figura 79 Keyword ldquoVerify if AP is registered Succesfully on grouprdquo
Puede observarse como en primer lugar se obtiene la fila de la tabla que contiene el punto de acceso en cuestioacuten
para posteriormente comprobar si el grupo al que pertenece es el esperado
Observando dicha implementacioacuten cabe destacar el uso de la Keyword ldquoInput Into Text Fieldrdquo la cual ha sido
implementada para vaciar el contenido de campos de texto ya que mediante la Keyword ldquoClear Element Textrdquo
de la libreriacutea Selenium2Library no se conseguiacutea borrar ciertos campos de texto
Figura 80 Keywords Input Into Text Field y Clear Field Of Characters
98
632 CHT Zones
En la pestantildea de gestioacuten de las diferentes Zonas CHT se puede observar una lista de los puntos de acceso
disponibles y se pueden realizar un conjunto de acciones sobre ellos como la creacioacuten eliminacioacuten y asociacioacuten
de zonas CHT
En este punto es conveniente explicar el concepto de zona CHT el cual se refiere a un grupo IP Multicast a
traveacutes del cual un conjunto de Puntos de Acceso establece comunicacioacuten de forma colaborativa Esta
comunicacioacuten es necesaria para el funcionamiento de algunos de los algoritmos que ofrece CHT como por
ejemplo la asignacioacuten automaacutetica de canal (ACA)
Figura 81 Pestantildea ldquoCHT Zonesrdquo
Sobre esta vista se han realizado un total de 6 casos de prueba de los cuales detallaremos el caso de prueba
identificado con la etiqueta U0204 Este caso de prueba permite validar la asignacioacuten de zonas CHT a los Puntos
de Acceso
6321 Criterios de Aceptacioacuten
U0204 Verificar que un usuario puede asignar una Zona CHT a un punto de acceso correctamente
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Configuracioacuten
3 El usuario puede Navegar a la pestantildea de Grupos
4 El usuario puede asignar una Zona CHT existente a un punto de acceso registrado correctamente
99
6322 Diagramas de Flujo
Figura 82 Diagrama de Flujo de Caso de Prueba U0204
6323 Script de Pruebas
Tras presentar los criterios de aceptacioacuten y su correspondiente diagrama de flujo el script de pruebas
implementado para la automatizacioacuten de dicha prueba es el siguiente
Figura 83 Scripts de Prueba U0204
Figura 84 Keyword Add Zone CHT to AP
100
633 BackupRestore
En esta pestantildea se permite la gestioacuten de copias de seguridad y restauracioacuten de los puntos de acceso registrados
en un Zone Manager Se puede observar en esta vista una tabla con los puntos de acceso registrados y otra tabla
con las copias de seguridad realizadas sobre los puntos de acceso
Figura 85 Pestantildea BackupRestore
Partiendo de la representacioacuten funcional de esta vista se han realizado un total de 8 casos de prueba de los
cuales detallaremos el caso de prueba identificado con la etiqueta U0401 el cual permite verificar de forma
automaacutetica la realizacioacuten de un backup sobre un punto de acceso y su posterior restauracioacuten
6331 Criterios de Aceptacioacuten
U0401 Verificar que un usuario puede realizar un BackupRestore correctamente sobre un punto de
acceso previamente registrado
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Configuracioacuten
3 El usuario puede Navegar a la pestantildea de BackupRestore
4 El usuario puede realizar un Backup sobre un punto de acceso existente
5 La tabla de Backups contiene la copia de seguridad realizada
6 El usuario puede restaurar un punto de acceso correctamente
101
6332 Diagramas de Flujo
Figura 86 Diagrama de Flujo de Caso de Prueba U0401
6333 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 87 Script de Prueba U0401
Cabe destacar la implementacioacuten de la Keyword ldquoRestore for AP have done successfullyrdquo la cual verifica que
el punto de acceso ha sido restaurado correctamente esperando que el punto de acceso vuelva a estar en estado
ldquoonlinerdquo durante un tiempo aceptable Si pasado dicho tiempo no recupera dicho estado la prueba se dariacutea por
erroacutenea
Figura 88 Keyword Restore For AP hace done successfully
634 Firmware
Esta uacuteltima pestantildea de la vista principal de configuracioacuten proporciona al usuario la posibilidad de subir los
firmwares de los diferentes modelos de puntos de acceso en sus diferentes versiones del software CHT de forma
que es posible la actualizacioacuten del firmware de los puntos de acceso desde la plataforma Se puede observar en
esta vista una tabla con los puntos de acceso registrados y otra tabla con los firmwares subidos a la plataforma
102
Figura 89 Pestantildea ldquoFirmwarerdquo
Partiendo de la representacioacuten funcional de esta vista se han realizado un total de 7 casos de prueba de los
cuales detallaremos el caso de prueba identificado con la etiqueta U0303 el cual permite verificar de forma
automaacutetica la actualizacioacuten del firmware de un punto de acceso
6341 Criterios de Aceptacioacuten
U0303 Verificar que un usuario puede realizar correctamente la actualizacioacuten del firmware de un punto
de acceso
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Configuracioacuten
3 El usuario puede Navegar a la pestantildea de Firmware
4 El usuario puede subir un firmware correctamente
5 La tabla de Firmwares contiene la imagen de CHT subida a la plataforma
6 El usuario puede realizar la actualizacioacuten del firmware sobre un punto de acceso correctamente
Destacar que el firmware que se desea aplicar sobre un punto de acceso debe ser del modelo correspondiente al
punto de acceso usado ya que cada punto de acceso tiene una imagen de CHT compilada para una arquitectura
hardware determinada Las imaacutegenes son proporcionadas por un servidor interno de la empresa
103
6342 Diagramas de Flujo
Figura 90 Diagrama de Flujo de Caso de Prueba U0303
6343 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 91 Script de Prueba U0303
Cabe destacar la implementacioacuten de la Keyword ldquoFlash APrdquo la cual realiza la actualizacioacuten del firmware de un
punto de acceso verificando que este ha concluido correctamente Para ello espera un tiempo aceptable a que el
punto de acceso vuelva al estado ldquoonlinerdquo
Figura 92 Keyword Flash AP
104
64 Vista de Red (Network Tab)
La uacuteltima vista principal sobre la que se han automatizado pruebas es la vista de Red la cual ofrece al usuario
la gestioacuten y configuracioacuten de su red formada por un conjunto de puntos de acceso previamente registrados
Entre las funcionalidades ofrecidas se encuentran la creacioacuten de VLANS SSIDs Portales Cautivos Perfiles
Radius Activacioacuten de algoritmos CHT y la configuracioacuten de puntos de acceso en tiempo real desde la
plataforma Web
Para describir el proceso de automatizacioacuten se comenzaraacute detallando en primer lugar la creacioacuten de VLANS
Brigdes y SSIDs para posteriormente aplicar dichos paraacutemetros a puntos de acceso desde las pestantildeas ldquoGeneralrdquo
y ldquoAP Networkrdquo Finalmente se mostraraacuten algunos ejemplos sobre otras configuraciones maacutes avanzadas como
la creacioacuten y aplicacioacuten de perfiles radius y portales cautivos ademaacutes de la activacioacuten de algoritmos
641 VLANS amp Bridges
Comenzando con la pestantildea de VLANS amp Bridges se puede observar la existencia de una tabla para cada
elemento de dicha vista
Figura 93 Pestantildea ldquoVLAN amp Bridgesrdquo
Para cada elemento se han automatizado un conjunto de pruebas formado por 6 casos de prueba de los cuales
detallaremos el caso de prueba identificado con la etiqueta U0527 Este caso de prueba permite validar de forma
automaacutetica la creacioacuten y eliminacioacuten de VLANs De forma ideacutentica se procederiacutea para validar la creacioacuten y
eliminacioacuten de Bridges
6411 Criterios de Aceptacioacuten
A continuacioacuten se detallan los criterios de aceptacioacuten del caso de prueba seleccionado
U0527 Verificar que un usuario puede crear y eliminar una VLAN correctamente
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Network
3 El usuario puede Navegar a la pestantildea de VLANS amp Bridges
4 El usuario puede crear una VLAN correctamente
5 El usuario puede eliminar una VLAN correctamente
105
6412 Diagramas de Flujo
Figura 94 Diagrama de Flujo de Caso de Prueba U0527
6413 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 95 Script de Prueba U0527
Cabe destacar la implementacioacuten de la Keyword ldquoGo and Create VLANrdquo la cual permite crear una VLAN en
funcioacuten de los paraacutemetros de entrada deseados para configurar dicha VLAN como por ejemplo el ldquoIDrdquo de la
VLAN y alias o si se desea que dicha VLAN sea de tipo dinaacutemica
Figura 96 Keyword Go And Create VLAN
106
642 SSIDs
Esta pestantildea proporciona una tabla que permite registrar SSIDs con diferentes configuraciones posibles
Figura 97 Pestantildea SSIDs
Para cada funcionalidad de dicha pestantildea se han automatizado un conjunto de pruebas formado por 5 casos de
prueba de los cuales detallaremos el caso de prueba identificado con la etiqueta U0530 Este caso de prueba
permite validar de forma automaacutetica la creacioacuten y eliminacioacuten de SSIDS
6421 Criterios de Aceptacioacuten
A continuacioacuten se detallan los criterios de aceptacioacuten de los dos casos de prueba seleccionados
U0530 Verificar que un usuario puede crear y eliminar una SSID correctamente
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Network
3 El usuario puede Navegar a la pestantildea de SSIDs
4 El usuario puede crear una SSID correctamente
5 El usuario puede eliminar una SSID correctamente
6422 Diagramas de Flujo
Figura 98 Diagrama de Flujo de Caso de Prueba U0530
107
6423 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 99 Script de Prueba U0530
Cabe destacar la implementacioacuten de la Keyword ldquoGo and Create SSIDrdquo la cual permite crear una SSID en
funcioacuten de los paraacutemetros de entradas deseado para configurar dicha SSID como por ejemplo tipo de
encriptacioacuten de la contrasentildea modo oculto o habilitacioacuten de los algoritmos Load Balancing (LB) Smart
roaming (SR) o PRE
Figura 100 Keyword Go And Create SSID
108
643 CHT
Esta funcionalidad permite activar el algoritmo que permite la seleccioacuten automaacutetica de canal entre un conjunto
de puntos de acceso (ACA) Cuando se activa desde la plataforma Web todos los puntos de acceso
pertenecientes a un Zone Manager activan dicho algoritmo el cual se trata de un algoritmo colaborativo
mediante el cual los puntos de acceso acuerdan cual es el mejor canal para la comunicacioacuten WiFi con los clientes
que se conecten tanto en la banda de 24 GHz como en la de 5 GHz En la siguiente figura se muestra la vista
de la plataforma Web para activar el algoritmo en cuestioacuten
Figura 101 Pestantildea ldquoCHTrdquo
Dado que se trata de una funcionalidad en la que solo se debe comprobar si el algoritmo estaacute en el mismo estado
tanto en la plataforma Web como en los puntos de acceso registrados se ha implementado un uacutenico caso de
prueba identificado con la etiqueta U539 Este caso de prueba realiza la conexioacuten a los puntos de acceso para
verificar que dicho algoritmo presenta el mismo estado que en la plataforma
6431 Criterios de Aceptacioacuten
U0537 Verificar que un usuario puede Activar o Desactivar el algoritmo ACA correctamente
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Network
3 El usuario puede Navegar a la pestantildea de CHT
4 El usuario puede ActivarDesactivar el algoritmo ldquoACA ldquocorrectamente
5 Los APs recibieron las oacuterdenes para ActivarDesactivar el algoritmo ldquoACArdquo correctamente
109
6432 Diagramas de Flujo
Figura 102 Diagrama de Flujo de Caso de Prueba U0539
6433 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 103 Script de Prueba U0539
En cuanto a la implementacioacuten de dicho caso de prueba cabe destacar la implementacioacuten de la Keyword ldquoACA
Is Workingrdquo las cual se muestra en la siguiente figura
Figura 104 Keyword ACA Is Working
Puede observarse como en funcioacuten de si el algoritmo ACA esta activado o desactivado en la plataforma Web
(ENABLE DISABLE) se ejecuta la Keyword ldquoChanges On CLIrdquo con diferentes paraacutemetros Esta Keyword
permite la conexioacuten viacutea ldquoSSHrdquo con un punto de acceso para la ejecucioacuten de un comando sobre el mismo y la
posterior comparacioacuten del resultado obtenido por dicho comando con la salida deseada proporcionada tambieacuten
como paraacutemetro de la Keyword
110
En la siguiente figura se muestra la implementacioacuten de dicha Keyword
Figura 105 Keyword Changes On CLI
Para este caso de prueba el comando ejecutado de forma remota sobre el punto de acceso permite obtener de
forma automaacutetica el estado del algoritmo ldquoACArdquo de la siguiente forma
Figura 106 Comando CHT para obtener el estado del moacutedulo ACA en el punto de acceso
644 Radius
Esta pestantildea proporciona una tabla que permite registrar perfiles Radius con diferentes configuraciones posibles
Figura 107 Pestantildea ldquoRadiusrdquo
ldquoRadiusrdquo se define como un protocolo de autenticacioacuten y autorizacioacuten para aplicaciones de acceso a la red o
movilidad IP De esta forma los puntos de acceso mediante la existencia de un servidor radius permiten que los
usuarios que se quieran conectar por WiFi necesiten ser autenticados con credenciales Dicha autenticacioacuten seraacute
redirigida por el punto de acceso al servidor radius el cual autoriza al punto de acceso para que permita la
conexioacuten del cliente
Ademaacutes el uso de este servicio junto con la configuracioacuten mediante VLAN dinaacutemicas permite que diferentes
usuarios accedan al servicio de red con diferentes credenciales de forma que seguacuten el tipo de cliente su traacutefico
viajaraacute por una VLAN u otra Esto permite la separacioacuten del traacutefico a nivel de enlace ofreciendo la posibilidad
de establecer reglas de control de traacutefico y ofrece una QoS miacutenima en funcioacuten del tipo de cliente
Figura 108 Escenario de Funcionamiento de Servidor Radius
111
Para cada funcionalidad de dicha pestantildea se han automatizado un conjunto de pruebas formado por 7 casos de
prueba de los cuales detallaremos el caso de prueba identificado con la etiqueta U0601 Este caso de prueba
permite validar de forma automaacutetica la creacioacuten edicioacuten y borrado de un perfil radius en la plataforma Web
6441 Criterios de Aceptacioacuten
U0601 Verificar que un usuario puede crear editar y borrar un perfil Radius correctamente
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Network
3 El usuario puede Navegar a la pestantildea de Radius
4 El usuario puede Crear un perfil Radius correctamente
5 El usuario puede Editar un perfil Radius correctamente
6 El usuario puede Eliminar un perfil Radius correctamente
6442 Diagramas de Flujo
Figura 109 Diagrama de Flujo de Caso de Prueba U0601
6443 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 110 Script de Prueba U0601
En cuanto a la implementacioacuten de dicho caso de prueba puede destacarse por ejemplo la implementacioacuten de
la Keyword ldquoCreate Radius Profilerdquo la cual permite crear un perfil ldquoRadiusrdquo a partir de un conjunto de
paraacutemetros de entrada
112
Figura 111 Keyword Create Radius Profile
645 Captive Portal
Esta pestantildea proporciona una tabla que permite registrar perfiles de Portales Cautivos con diferentes
configuraciones posibles
Figura 112 Pestantildea Captive Portals
Un portal cautivo es un servicio que permite el control del traacutefico HTTP y fuerza a los usuarios de una red a la
autenticacioacuten mediante una paacutegina Web para tener acceso a Internet Dicho portal permite controlar paraacutemetros
como el tiempo de conexioacuten de un cliente a la red ancho de banda ofrecido a cada cliente etc
Figura 113 Escenario de Funcionamiento de un Portal Cautivo
Para cada funcionalidad de dicha pestantildea se han automatizado un conjunto de pruebas formado por 5 casos de
prueba de los cuales detallaremos el caso de prueba identificado con la etiqueta U0701 Este caso de prueba
permite validar de forma automaacutetica la creacioacuten edicioacuten y borrado de un perfil de portal cautivo en la plataforma
Web
113
6451 Criterios de Aceptacioacuten
U0701 Verificar que un usuario puede crear editar y borrar un perfil de Portal Cautivo correctamente
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Network
3 El usuario puede Navegar a la pestantildea de Captive Portals
4 El usuario puede Crear un perfil de Portal Cautivo correctamente
5 El usuario puede Editar un perfil de Portal Cautivo correctamente
6 El usuario puede Eliminar un perfil de Portal Cautivo correctamente
6452 Diagramas de Flujo
Figura 114 Diagrama de Flujo de Caso de Prueba U0701
6453 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 115 Script de Prueba U0701
114
En cuanto a la implementacioacuten de dicho caso de prueba puede destacarse por ejemplo la implementacioacuten de
la Keyword ldquoEdit or delete Captive Portal Profilerdquo la cual permite editar o eliminar un perfil de Portal Cautivo
a partir de un conjunto de paraacutemetros de entrada
Figura 116 Keyword Edit or Delete Captive Portal Profile
115
646 General
Esta pestantildea muestra la vista general de la pestantildea ldquoNetworkrdquo En esta pestantildea se agrupa el conjunto de puntos
de acceso actualmente registrados en el Zone Manager con un resumen de su configuracioacuten de red actual el
estado en el que se encuentran y nuacutemero de clientes conectados Ademaacutes dicha vista proporciona un acceso
directo a la pestantildea ldquoAP Networkrdquo seleccionando uno o varios puntos de acceso de un mismo modelo En la
siguiente seccioacuten se explica la funcionalidad de dicha pestantildea
Figura 117 Pestantildea General
Para cada elemento se han automatizado un conjunto de pruebas formado por 9 casos de prueba de los cuales
detallaremos el caso de prueba identificado con la etiqueta U0522 Este caso de prueba se permite validar de
forma automaacutetica la conexioacuten de clientes a un punto de acceso con una SSID asignada de forma que el nuacutemero
de clientes conectados que se muestra en la plataforma Web sea correcto
6461 Criterios de Aceptacioacuten
U0522 Conectar clientes y verificar que el nuacutemero de clientes conectados es correcto
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Network
3 El usuario puede Navegar a la pestantildea General
4 El usuario tiene disponible un punto de acceso en el Zone Manager con una SSID asignada
5 El usuario conecta un cliente al punto de acceso por WiFi a la SSID asignada
6 El usuario verifica que el nuacutemero de clientes conectados incrementa en una unidad
116
6462 Diagramas de Flujo
Figura 118 Diagrama de Flujo de Caso de Prueba U0522
6463 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de prueba automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 119 Script de Prueba U0522
En cuanto a la implementacioacuten de dicho caso de prueba puede destacarse por ejemplo la implementacioacuten de
la Keyword ldquoCheck Number of Clients Increasesrdquo la cual permite comprobar que el nuacutemero de clientes conectados incrementa al conectar un cliente a un punto de acceso
Figura 120 Keyword Check Number of Clients Increases
117
647 AP Network
Esta pestantildea muestra la vista principal de la pestantildea ldquoAP Networkrdquo La funcionalidad que proporciona engloba
todos los posibles paraacutemetros de configuracioacuten para un punto de acceso que ha sido seleccionado previamente
desde la pestantildea General Cualquier configuracioacuten aplicada sobre esta vista seraacute enviada al punto de acceso
desde la plataforma Web permitiendo configurar los puntos de acceso de Galgus
Desde el punto de vista de la plataforma Web esta vista abarca un conjunto de funcionalidades consideradas
como maacutes complejas que se ofrecen en la plataforma Web por lo que es en esta vista donde puede encontrarse
una de las mayores aacutereas de riesgo de la plataforma Entre las funcionalidades que se ofrecen estaacuten la
configuracioacuten de las radios de un punto de acceso (Potencia Ancho de banda Canal etc) asignacioacuten de SSIDs
a las interfaces inalaacutembricas y configuracioacuten de reglas de control de traacutefico (TC Rules) asignacioacuten de puertos a
las diferentes subredes virtuales de aacuterea local (VLANS) o configuracioacuten de Portal Cautivo
Figura 121 Pestantildea AP Network
Para cada elemento se han automatizado un conjunto de pruebas formado por 28 casos de prueba los cuales la
mayoriacutea han requerido un amplio esfuerzo de implementacioacuten para conseguir su automatizacioacuten ya que son
pruebas cuya secuencia de acciones es larga ademaacutes de requerir en muchas ocasiones la verificacioacuten de la
configuracioacuten en los puntos de acceso viacutea ldquosshrdquo Para ello se ha hecho uso entre otras de la libreriacutea
ldquoSSHLibraryrdquo proporcionada por Robot Framework
Figura 122 Libreriacutea SSH para Robot Framework
118
Del conjunto de casos de prueba que validan la funcionalidad de dicha pestantildea se va a detallar el caso de prueba
identificado con la etiqueta U0511 Este caso de prueba permite validar de forma automaacutetica que se pueden
aplicar reglas de control de traacutefico ldquoTCsrdquo a una SSID asignada a las interfaces inalaacutembricas de un punto de
acceso desde la plataforma Web
Figura 123 Ventana de Configuracioacuten de TC Rules
6471 Criterios de Aceptacioacuten
U0511 Asignar ldquoTC Rulesrdquo a una SSID asociada a un Punto de Acceso correctamente
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Network
3 El usuario puede Navegar a la pestantildea General
4 El usuario tiene disponible un punto de acceso en el Zone Manager
5 El usuario puede seleccionar un punto de acceso
6 El usuario puede Navegar a la pestantildea AP Network para el punto de acceso seleccionado
7 El usuario puede asignar a las interfaces inalaacutembricas una SSID existente y crear ldquoTC Rulesrdquo sobre
esa SSID
8 El usuario puede aplicar la configuracioacuten
9 El punto de acceso aplica su configuracioacuten correctamente
10 El punto de acceso pasa al estado ldquoOnlinerdquo en la plataforma Web y su configuracioacuten estaacute alineada
119
6472 Diagramas de Flujo
Figura 124 Diagrama de Flujo de Caso de Prueba U0511
120
6473 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 125 Script de Prueba U0511
En cuanto a la implementacioacuten de dicho caso de prueba puede destacarse por ejemplo la implementacioacuten de
la Keyword ldquoWait Timerrdquo la cual permite verificar que no se produce ninguacuten error al aplicar una configuracioacuten
determinada desde la plataforma Web durante un tiempo determinado
Figura 126 Keyword Wait Timer
Destacar tambieacuten la implementacioacuten de la Keyword ldquoCheck On CLIrdquo la cual permite contrastar que la
configuracioacuten aplicada desde la plataforma sobre un punto de acceso es la esperada En este caso se comprueba
que las ldquoTC Rulesrdquo han sido correctamente aplicadas para una SSID determinada en un punto de acceso de
forma remota mediante el uso de la libreriacutea ldquoSSHrdquo para Robot Framework
Figura 127 Keyword Check On CLI
121
122
7 LINEAS DE MEJORA Y CONCLUSIONES
n este uacuteltimo capiacutetulo se analizaraacuten resultados y conclusiones obtenidas sobre el uso de pruebas
automatizadas para la verificacioacuten y validacioacuten de una plataforma Web como la de Galgus Se
detallaraacuten algunas ventajas e inconvenientes encontrados y se plantearaacuten algunas liacuteneas de mejora
futuras sobre el proyecto desarrollado Con estas mejoras se busca como objetivo enriquecer el proceso de
automatizacioacuten de pruebas ademaacutes de hacerlo maacutes efectivo y metoacutedico en todos sus aspectos ya que siempre
hay algo que se puede mejorar para conseguir una herramienta maacutes completa y uacutetil
Se detallaraacuten tambieacuten aspectos de aprendizaje opiniones experiencias y en definitiva todas las conclusiones
sacadas sobre este proyecto incluyendo tambieacuten las dificultades encontradas para el desarrollo del mismo
71 Liacuteneas de Mejora Futuras
El estudio y puesta en marcha de este Proyecto de automatizacioacuten de pruebas de Software ha hecho uso de una
amplia cantidad de herramientas ofrecido por Selenium y Robot Framework ademaacutes de otras herramientas que
han permitido enriquecer el mismo con mayores funcionalidades ofrecidas al equipo de Proyecto Si bien se ha
logrado conseguir un paquete de pruebas con una capacidad de detectar defectos en un producto Web existen
diversas ampliaciones de dicho Proyecto que podriacutean aumentar de manera considerable el desempentildeo de las
herramientas de automatizacioacuten a lo largo del ciclo de vida del proyecto
A continuacioacuten se muestran algunas de las maacutes importantes
bull Uso de Integracioacuten Continua Robot Framework es faacutecilmente integrable principalmente con Jenkins
aunque tambieacuten ofrece la posibilidad de integrarlo con Gitlab CICD Esto permitiriacutea programar la
ejecucioacuten de pruebas automaacuteticamente para diferentes versiones del proyecto Galgus CHT Cloud
Manager o en diferentes fases del mismo Con esta caracteriacutestica se detectariacutean con mayor facilidad los
problemas relacionados con la configuracioacuten del entorno de trabajo y se podriacutea notificar por email a
los responsables de equipo ante los eventuales incidentes encontrados De este modo no seriacutea necesario
estar supervisando el proceso de ejecucioacuten para estar al tanto de un fallo en el sistema En este aspecto
se ha trabajado para conseguir estos objetivos con la creacioacuten de un Docker de Robot Framework que
permita la ejecucioacuten de las pruebas en el mismo para poder usarla en el entorno de integracioacuten continua
correspondiente Tambieacuten se ha implementado un primer un script que permita la ejecucioacuten de paquetes
de pruebas en dicho entorno
bull Selenium Grid El caso praacutectico descrito tiene un inconveniente y es que solo hace uso de Chrome
Suele ser frecuente que ciertos defectos en una aplicacioacuten Web solo aparezcan en determinados
navegadores Con herramientas como Selenium Grid permitiriacutean la ejecucioacuten en paralelo de las pruebas
en maacutequinas con diferentes sistemas operativos y navegadores Asiacute se podriacutea evaluar de manera
independiente la compatibilidad del producto en entornos multiplataforma Ademaacutes esta herramienta
es totalmente compatible con Jenkins o Gitlab CICD con las ventajas que esto supone
bull Headless browser Esto hace referencia al uso de navegadores sin interfaz graacutefica de usuario La mayor
parte del tiempo durante una ejecucioacuten es destinada a esperar a que el navegador renderice el contenido
Si se elimina este factor de la foacutermula y se accede directamente al DOM de la Web se consigue una
reduccioacuten en el tiempo de ejecucioacuten de las pruebas Durante el desarrollo de este proyecto se ha
trabajado en este aspecto ofrecieacutendose la posibilidad de ejecutar las pruebas en dos entornos diferentes
una primera de depuracioacuten de pruebas que realiza el renderizado del navegador y otra opcioacuten que
E
La tecnologiacutea por siacute sola no basta Tambieacuten tenemos que poner el corazoacuten
Jane Goodall
123
permite la ejecucioacuten de pruebas sin renderizado del navegador (Modo Headless)
bull Buenas praacutecticas en la localizacioacuten de elementos en el DOM de la Web La aplicacioacuten de este tipo
de buenas praacutecticas permitiriacutean una mejor y maacutes eficiente localizacioacuten de los elementos en el DOM
reduciendo la posibilidad de que las pruebas generen falsos errores Esto es lo que ha causado la mayor
parte de los problemas de implementacioacuten y ejecucioacuten de las pruebas automaacuteticas Actualmente la
herramienta de automatizacioacuten de pruebas se encuentra en un proceso de mejora continua en el que se
estaacute abordando una refactorizacioacuten para la aplicacioacuten de estas buenas praacutecticas Para ello se estaacuten
haciendo uso de selectores avanzados basados en rutas (Xpaths) relativas en el DOM de la Web las
cuales realizan la mayoriacutea de las buacutesquedas por contenido y no por ruta absoluta como se veniacutea
haciendo hasta ahora
bull Aplicacioacuten de Model Based Testing (MBT) Como estudio del arte se ha presentado una teacutecnica que
permite dar un paso maacutes en la automatizacioacuten de pruebas Como se ha detallado en el proyecto esta
teacutecnica permite ascender en el nivel de abstraccioacuten de las pruebas basando las mismas en el disentildeo y
modelado de la aplicacioacuten Dicha teacutecnica se encuentra principalmente en proceso de investigacioacuten lo
cual hace difiacutecil aplicarla aunque seriacutea de gran intereacutes conseguir su implantacioacuten
72 Conclusiones Finales
En el desarrollo del presente Proyecto se ha analizado una pequentildea extensioacuten del inmenso mundo de la gestioacuten
de calidad Esta ha ido tomando fuerza con el paso de los antildeos en el mercado actual introducieacutendose en todos
los aacutembitos incluido en el software La gestioacuten de calidad se ha profesionalizado de tal forma que el papel del
ingeniero de calidad en los proyectos de software es imprescindible en cualquier empresa que quiera hacerse un
hueco en el mercado como garantiacutea de calidad
La elevada exigencia del mercado del software provocada por la gran demanda de clientes y usuarios finales
para recibir un producto en el menor tiempo posible hace que en muchos casos las empresas centren su esfuerzo
en sacar un producto lo antes posible reduciendo los esfuerzos destinados a los procesos de calidad de dicho
producto software Originalmente las pruebas de software realizadas sobre un producto se realizaban de forma
manual por un ingeniero de calidad pero con el avance de las tecnologiacuteas la automatizacioacuten de las mismas
supone un elevado esfuerzo inicial pero una reduccioacuten de los mismos a medio plazo
En este proyecto se ha desarrollado una herramienta que permite la automatizacioacuten de pruebas funcionales sobre
una plataforma Web concretamente pruebas de aceptacioacuten sobre Galgus CHT Cloud Manager Las pruebas de
automatizacioacuten elaboradas reflejan que existen tecnologiacuteas muy asequibles en teacuterminos de coste compatibilidad
y facilidad de uso para iniciarse en el mundo de las pruebas funcionales de sistemas Algo muy presente en el
mundo laboral actual es la creciente demanda de expertos en automatizacioacuten en todas las principales
plataformas Web Moacutevil y Escritorio Muchos de estos profesionales vienen del mundo del testing manual por
lo que conociendo ya la nomenclatura y el funcionamiento de los procesos de calidad solo necesitan dar el paso
hacia el uso de este tipo de herramientas Sea con Selenium o con cualquier otra herramienta los conceptos
teoacutericos presentados en este proyecto son igualmente vaacutelidos
Por otra parte debe destacarse la dificultad encontrada a la hora de establecer unos criterios de aceptacioacuten de las
funcionalidades de la plataforma Web bajo pruebas Esto se debe al desarrollo de una herramienta de
automatizacioacuten de pruebas que se ha iniciado en una fase avanzada del desarrollo del proyecto con lo cual en
muchas ocasiones surgiacutean dudas sobre el disentildeo del proyecto Adicionalmente la propia estructura y tecnologiacuteas
usadas en la Web dificultaron al inicio la localizacioacuten de elementos A esta causa de une tambieacuten la ausencia de
identificadores uacutenicos en los elementos que componen la misma Esto se tradujo en el uso de selectores basados
en la ruta del elemento pudiendo acarrear la aparicioacuten de posibles falsos errores debidos a cambios en el coacutedigo
fuente de la plataforma Web La solucioacuten adoptada para tal problema no fue maacutes que analizar meticulosamente
aquellas ejecuciones fallidas para descartar errores reales y en caso de que sean debidas a los selectores aplicar
la debida actualizacioacuten de los mismos
En este uacuteltimo aspecto cabe destacar que el proyecto de automatizacioacuten de pruebas se encuentra actualmente
en una fase de mejora continua en la que se estaacuten adoptando teacutecnicas basadas en el uso de selectores avanzados
basados en rutas relativas y nombres que permitan reducir el impacto del problema presentado en este punto
124
A modo de resumen se plantean algunas ventajas en el uso de SeleniumRobot Framework para la
automatizacioacuten de pruebas
Facilidad de configuracioacuten y uso Su instalacioacuten requiere un esfuerzo miacutenimo y el poder de
abstraccioacuten ofrecido por Robot Framework hace posible la lectura y entendimiento de los paquetes de
pruebas y reportes a todos los miembros del equipo
Cantidad de documentacioacuten disponible La comunidad respalda ambos proyectos y es por ello que
encontramos soluciones de todo tipo adaptadas a las necesidades de cada uno
Soporte para la mayoriacutea de navegadores con el mismo script Ejecutar el script de pruebas
desarrollado para su automatizacioacuten en otro navegador requiere simplemente la instalacioacuten del
controlador deseado y usar un determinado paraacutemetro para indicar el uso de dicho controlador en la
llamada de la Keyword encargada de la apertura del navegador
De la misma forma se pueden destacar algunas desventajas
Selenium soacutelo es compatible con productos Web Cualquier software moacutevil o de escritorio requiere
del uso de otros frameworks o herramientas lo cual puede ser un punto negativo para empresas que
tengan productos multiplataforma Sin embargo Robot Framework si proporciona soporte
multiplataforma con la integracioacuten de otras herramientas o framework para su desarrollo
Tecnologiacuteas no optimizadas para pruebas de rendimiento En este punto cabe destacar el esfuerzo
de la comunidad para desarrollar herramientas que permitan la automatizacioacuten de este tipo de pruebas
con Robot Framework como por ejemplo ldquorfswarmrdquo
Compatibilidad de versiones de paquetes de Software Es frecuente usar determinadas
combinaciones de versiones de paquetes para lograr un framework estable y robusto Esto a veces puede
convertirse en una tarea tediosa donde cuestan encajar piezas Por suerte es algo que se estaacute teniendo
en cuenta con las uacuteltimas versiones de Selenium
Puede concluirse que durante el desarrollo de este proyecto se ha conseguido la creacioacuten de una herramienta
sencilla de usar y entender para la automatizacioacuten de pruebas funcionales sobre una plataforma Web ademaacutes
de preparar dicha herramienta para integrarla en el proceso de integracioacuten continua implantado para dicha
aplicacioacuten Web con Gitlab mediante Docker Ademaacutes se ha realizar un estudio del arte de una teacutecnica conocida
bajo el nombre de Model Based Testing (MBT) que permitiriacutea mejorar el proceso de automatizacioacuten y la
herramienta desarrollada para tal fin
Con todo ello he aprendido multitud de conceptos tecnologiacuteas y herramienta que hasta ahora desconociacutea cuaacutel
era su finalidad o funcionamiento como por ejemplo Robot Framework Para ello he necesitado gran cantidad
de formacioacuten previa antes de comenzar a ponerlo en praacutectica para el desarrollo de la herramienta de
automatizacioacuten
Son muchos los errores cometidos hasta conseguir los objetivos y metas propuestas los cuales creo que son los
sucesos maacutes importantes pues de ellos se aprende y son los que nos hacen avanzar cuando los resolvemos
Finalmente destacar que este proyecto me ha dado la oportunidad de abrir mi conocimiento en un campo de las
tecnologiacuteas de la informacioacuten el cual resulta de intereacutes Dar las Gracias a mis tutores Pablo Aguilera Bonet y
Daniel Gutieacuterrez Reina ademaacutes de mi responsable en Galgus Joseacute Antonio Delgado Alfonso por brindarme
esta oportunidad ademaacutes de ayudarme y asesorarme estando siempre disponible y con dedicacioacuten hacia este
proyecto para que haya podido llevarse a cabo
125
126
REFERENCIAS
[1] M Utting Bruno Legeard Practical Model-based Testing sl Elsevier 2007
[2] Ibrahim K El-Far Enjoying the perks of model-based testing In Proceedings of the Software Testing
Analysis and Review Conference
[3] A C Dias Neto Rajesh Subramanyan Marlon Vieirab Characterization of Model-based Software
[4] Model-based Testing Next Generation Functional Software Testing Legeard Bruno Dagstuhl Seminar
Proceedings 10111 Vol httpdropsdagstuhldeopusvolltexte20102620
[5] Perspectives of Model-Based Testing Ed Brinksma Wolfgang Grieskamp and Jan Tretmans IBFI
Schloss Dagstuhl Germany sn 2005 Dagstuhl Seminar Proceedings
[6] Definicioacuten de Calidad httpsdleraeesid=6nVpk8P|6nXVL1Z
[7] Modelos de calidad del software httpswwwresearchgatenetpublication316674475
[8] Calidad del Software ldquoEl camino al exitordquo LI Alma Delia Chaacutevez Rojas
[9] IEEE Software Engineering Book of Knowledge IEEE sl IEEE 2004
[10] Principios de pruebas software httpsmediumcomatejedaccsprincipios-del-testing-722323e16e76
[11] httpwwwsstqbesw3docsGLOSARIO_V00110pdf
[12] httpsepdfpubsoftware-testing-an-istqb-iseb-foundation-guidehtml
[14] IEEE standard glossary of software engineering terminology F Jay RMayer 1990 paacuteg IEEE Std 610
[15] Openwrt httpsopenwrtorgsupported_devices
[16] RabbitMQ httpswwwrabbitmqcom
[17] Zero Touch Provisioning httpssearchdatacentertechtargetcomesdefinicionAprovisionamiento-de-
cero-toque-ZTP-o-zero-touch-provisioning
[18] Robot Framework User Guide
httpsrobotframeworkorgrobotframeworklatestRobotFrameworkUserGuidehtml
[19] Gitlab httpsdocsgitlabcom
[20] httpswwwfederico-toledocomcuando-automatizar-una-prueba
127
128
ANEXO A PREPARACIOacuteN DEL ENTORNO DE
TRABAJO Y EJECUCIOacuteN DE PRUEBAS
A1 Preparacioacuten del entorno de trabajo
Para el desarrollo de las preubas automaacuteticas se ha hecho uso del sistema operative Linux con la distribucioacuten
Ubuntu El motivo de su uso es el amplio abanico de herramientas de coacutedigo libre que existen para esta
distribucioacuten asiacute como la enorme contribucioacuten que hace la comunidad de usuarios para mejorarla Sobre este
sistema operativo se ha hecho uso de un conjunto de herramientas para el montaje de un entorno de pruebas
automatizado basado en Python A continuacioacuten se detallaraacuten dichas herramientas
A11 Pip
Pip es un sistema de gestioacuten de paquetes que se utiliza para la instalacioacuten de los paquetes software
implementados en Python que se usaraacuten posteriormente La instalacioacuten de un paquete se realiza mediante la
ejecucioacuten del siguiente comando
A12 Virtualenv Entorno Virtual
Dado que cada proyecto basado en Python puede requerir la instalacioacuten de diferentes conjuntos de paquetes es
comuacuten usar la creacioacuten de entornos virtuales que nos permitan administrar cada proyecto de manera
independiente pudiendo tener otros proyectos haciendo uso de los mismos paquetes con otras versiones La
instalacioacuten se realiza mediante la herramienta ldquoPiprdquo a traveacutes del siguiente comando
Una vez instalado se puede crear un entorno virtual asociado a un proyecto de la siguiente forma
En este punto se creariacutea un entorno virtual para el proyecto deseado Ahora solo quedariacutea activarlo o iniciarlo
pip install nombre-del-paquete
pip install virtualenv
cd carpeta-del-proyecto
virtualenv ndashp usrbinpython27 mi-proyecto
source mi-proyectobinactivate
129
A13 Selenium y Chromedriver
La instalacioacuten de Selenium se realiza de la misma forma que el resto de paquetes con la herramienta ldquoPiprdquo
Por otra parte el controlador para el navegador Chrome Chromedriver puede ser descargado desde el
repositorio oficial httpschromedriverchromiumorg Ademaacutes Chromedriver debe ser accessible para
Selenium de cara a configurar el PATH
A14 Robot Framework y SeleniumLibrary
A continuacioacuten se realizariacutea la instalacioacuten de Robot Framework
Posteriormente se realizariacutea la instalacioacuten del paquete ldquoSelenium2Libraryrdquo el cual contiene la implementacioacuten
en python de las libreriacuteas necesarias para utilizar Robot Framework en Python
Llegados a este punto listando todos los paquetes instalados se deberiacutea tener algo similar a la siguiente figura
Con esta configuracioacuten del entorno este estariacutea preparado para elaborar los casos de prueba automatizados con
Robot Framework y Selenium
pip install selenium
export PATH=$PATHabsolute_path_of_chromedriver_file
pip install robotframework
pip install robotframework-selenium2library
130
A15 Otras dependencias
Para el desarrollo de pruebas que requieren otro tipo de herramientas como la transferencia de ficheros con el
servicio ldquoSCPrdquo o la conexioacuten remota a traveacutes del servicio ldquoSSHrdquo se require la instalacioacuten de los siguientes
paquetes
Ademaacutes para la realizacioacuten de pruebas avanzadas en Python para la gestioacuten del Mapa de la platform Web CHT
Cloud Manager se ha hecho uso de la librariacutea ldquohtml-testRunnerrdquo para ofrecer un reporte de la ejecucioacuten de
pruebas muy similar al ofrecido por Robot Framework
A2 Ejecucioacuten de Pruebas
Tras la implementacioacuten de las pruebas siguiendo el procedimiento indicado en la seccioacuten de Experimentos
ejecutar un script de pruebas se realiza mediante el uso del siguiente comando
Mediante el uso de la variable ldquoENVIROMENTrdquo puede seleccionarse el entorno en el que se desea ejecutar las
pruebas Con el entorno de ldquodebugrdquo las pruebas se ejecutariacutean de forma graacutefica mientras que el el entorno de
ldquodockerrdquo permite la ejecucioacuten de pruebas sin interfaz graacutefica Este uacuteltimo entorno seriacutea usado para la ejecucioacuten
de pruebas con el docker de Robot Framework que se ha implementado el cual se detallaraacute maacutes adelante
Por otro lado existen otras opciones para el comando anterio como por ejemplo
Las opciones ldquo-irdquo y ldquo-erdquo permiten ejecutar o excluir un caso de preuba en la ejecucioacuten de una Suite de pruebas
Por otro lado el uacuteltimo comando permite lanzar la ejcucioacuten de una Suite de pruebas y ejecutar soacutelo aquellos
casos de prueba que hayan fallado en la ejecucioacuten anterior
pip install robotframework-sshlibrary
pip install robotframework-scplibrary
pip install html-testRunner
robot --variable ENVIROMENTdebug_or_docker suite_filerobot
robot --variable ENVIROMENTdebug_or_docker ndashi U0000 suite_filerobot
robot --variable ENVIROMENTdebug_or_docker ndashe U0000 suite_filerobot
robot --rerunfailed outrerunfailedxml --output out2xml suite_filerobot
131
A continuacioacuten se muestra un ejemplo de ejecucioacuten de pruebas con Robot Framwork
132
A3 Script de Prueba U007 (MAP)
from selenium import webdriver
from seleniumwebdrivercommonby import By
from seleniumwebdriversupportui import WebDriverWait
from seleniumwebdriversupport import expected_conditions as EC
from seleniumwebdrivercommondesired_capabilities import DesiredCapabilities
from seleniumwebdrivercommonaction_chains import ActionChains
from seleniumcommonexceptions import TimeoutException
import math json multiprocessing time re
import sys
import unittest
import HtmlTestRunner
U0007 Double-click on Zone Manager and look if the Backend tab opens
class DClickZM(unittestTestCase)
driver = 0
canvas = 0
waitTime = 20
username = franciscodiaz
password = ahipeo8829g
classmethodg
def setUp(cls)
Enviroment Management
chrome_options = webdriverChromeOptions()
if sysargv[2] == docker
chrome_optionsadd_argument(--headless)
chrome_optionsadd_argument(--disable-extensions)
chrome_optionsadd_argument(--disable-gpu)
chrome_optionsadd_argument(--no-sandbox)
enable browser logging
d = DesiredCapabilitiesCHROME
d[loggingPrefs] = browser DEBUG
clsdriver = webdriverChrome(chrome_options=chrome_options desired_capabilities=d)
clsdrivermaximize_window()
clsdriverset_window_size(1920 1080)
load the desired webpage
clsdriverget(httpdevcloudgalgusnet)
def test_double_click_ZM(self)
loggin in the page
userNameBox = WebDriverWait(selfdriver 1)until(
ECpresence_of_element_located((ByXPATH [id=username])))
userNameBoxsend_keys(selfusername)
passwordBox = WebDriverWait(selfdriver selfwaitTime)until(
ECpresence_of_element_located((ByXPATH [id=password])))
passwordBoxsend_keys(selfpassword)
133
loginButton = WebDriverWait(selfdriver selfwaitTime)until(
ECpresence_of_element_located((ByXPATH
[id=myModalLabel]divdivformdiv[3]input)))
loginButtonclick() Tab General appears
selfcanvas = WebDriverWait(selfdriver selfwaitTime)
until(ECpresence_of_element_located((ByXPATH
htmlbodyappdivmaindivregister-
managersdivtabsetdivtab[1]aol-mapdivdivcanvas)))
timesleep(15)
action = ActionChains(selfdriver)
Manage Process
manager = multiprocessingManager()
return_dict = managerdict()
We create a Process
p_get_pixels_zm = multiprocessingProcess(target=selfGet_Pixels_ZM args=(return_dict selfdriver))
We create another Process
p_double_click_on_zm = multiprocessingProcess(target=selfDouble_Click_On_ZM args=(return_dict selfcanvas
action selfdriver))
We start the process and we block for 5 seconds
p_get_pixels_zmstart()
p_get_pixels_zmjoin(timeout=10)
p_double_click_on_zmstart()
p_double_click_on_zmjoin(timeout=10)
We terminate the process
p_get_pixels_zmterminate()
p_double_click_on_zmterminate()
try
Tab General appears
WebDriverWait(selfdriver 20)until(ECpresence_of_element_located(
(ByXPATH [id=app-sections]networktabsetulli[1]a)))
except TimeoutException
raise Exception(Cant Login in Zone Manager)
classmethod
def tearDown(cls)
clsdriverquit()
staticmethod
def Get_Pixels_ZM(return_dict driver)
return_dict[0] = 0
return_dict[1] = 0
regex = r(lt=c[-gt]cs)[wW]+(=)
while True
for entry in driverget_log(browser)
message = entry[message]
matches = refinditer(regex message reMULTILINE)
134
for matchNum match in enumerate(matches start=1)
try
p = matchgroup()replace( )
my_json = jsonloads(p)
if my_json[ZM] == Hotel MampM
return_dict[0] = my_json[top]
return_dict[1] = my_json[left]
break
except
pass
if return_dict[0] = 0 and return_dict[1] = 0
break
staticmethod
def Double_Click_On_ZM(return_dict canvasaction driver)
width = int(mathceil(float(return_dict[0])))
height = int(mathceil(float(return_dict[1])))
actionmove_to_element_with_offset(canvas width height)
actiondouble_click()
actionperform()
actiondouble_click()
actionperform()
driversave_screenshot(screenshot1png)
timesleep(5)
if __name__ == __main__
unittestmain(testRunner=HtmlTestRunnerHTMLTestRunner())
135
136
ANEXO B DOCKER DE ROBOT FRAMEWORK Y
ENTORNO DE UAT DOCKERIZADO
B1 Docker de Robot Framework
Para el entorno de UAT que se va a desarrollar se ha hecho uso de diferentes contenedores que han sido creados
por el equipo de desarrollo donde cada contenedor aloja un microservicio diferente de la plataforma
Para crear cada contenedor se ha hecho uso de Docker Esta herramienta permite crear contenedores ligeros y
portables para diferentes servicios que puedan ejecutarse en cualquier maacutequina con Docker instalado
independientemente del sistema operativo de la maacutequina que lo ejecute facilitando asi los despliegues
Mediante un fichero llamado ldquoDockerfilerdquo se definen los siguientes contenedores de servicios entre los cuales
se destacaraacute el fichero que define la creacioacuten del docker de Robot Framework el cual ha sido desarrollado por
el autor de este proyecto
Este contenedor ha sido creado sobre una imagen de Docker con el inteacuterprete de Python instalado Partiendo de
137
esta imagen se realiza la instalacioacuten de Robot Framework y las diferentes libreriacuteas y herramientas que se usaraacuten
en el proyecto para poder lanzar los Tests End-to-End
Ademaacutes se realiza la instalacioacuten de Google Chrome y Mozilla Firefox y la descarga de Chromedriver y
Geckodriver para poder lanzar los tests con dichos navegadores en modo headless Para el lanzamiento de los
test en modo headless se haraacute uso de la variable de entorno ldquoENVIROMENTrdquo definida en el anexo anterior
Finalmente se antildeade el proyecto de pruebas desarrollado para tener disponible las pruebas aumaacuteticas en el
contenedor
B2 Entorno de UAT Dockerizado
Para automatizar el despliegue de la plataforma Galgus CHT Cloud Manager con Docker se ha hecho uso de la
herramienta ldquodocker-composerdquo Esta herramienta permite simplificar el uso de Docker generando scripts que
facilitan el disentildeo y la construccion de servicios Con Docker Compose se pueden crear diferentes contenedores
y al mismo tiempo en cada contenedor diferentes servicios En la siguientefigura se muestra el fichero que
define el entorno de UAT con docker-compose
138
139
140
ANEXO C REVISIOacuteN DE REPORTES Y LOGS
C1 Reporte de Logs ofrecido por Robot Framework
Selenium no teniacutea la capacidad nativa de generar informes Este es uno de los motivos por el que se decidioacute
utilizar Robot Framework
Robot Framework genera tres archivos tras la ejecucioacuten de los scripts de pruebas A partir de la informacioacuten
contenida en el fichero ldquooutputxmlrdquo se rellenan las plantillas ldquohtmlrdquo del ldquologrdquo y del reporte El reporte permite
aplicar filtros a los resultados mientras que el ldquologrdquo contiene todos los detalles de la ejecucioacuten
A continuacioacuten se adjuntan las capturas de logs generados por los diferentes paquetes de pruebas desarrollados
C2 Cloud Tab
C21 Administration
141
142
C22 List
143
C23 Manufacturers
144
C24 MAP
145
C3 Configuration Tab
C31 BackupRestore
146
C32 CHT Zones
147
C33 Firmware
148
C34 Groups
149
150
C4 Network Tab
C41 General
151
C42 SSID
C43 CHT
152
C44 VLAN
153
C45 Radius
154
C46 Captive Portal
155
C47 AP Network
156
Como se ha visto reflejado en el conjunto de logs el tiempo total invertido en la ejecucioacuten ha sido de 1 hora 20
minutos y 22 segundos Dichas pruebas realizadas por una persona de forma manual hubiesen requerido como
miacutenimo el doble de tiempo Ya ni mencionar si se aplicase concurrencia en la ejecucioacuten de pruebas
157
ANEXO D DIAGRAMA DE GANTT
6
7
A mi familia
A mis maestros
A mis amigos
8
9
Agradecimientos
10
11
Resumen
La revolucioacuten tecnoloacutegica que vivimos hoy diacutea enfocada principalmente en el mundo de Internet y aplicaciones
Web estaacute permitiendo que todas las herramientas que tenemos a nuestro alrededor se encuentren en un proceso
de tremenda evolucioacuten y cambio continuo
En este proyecto se ha realizado un estudio del arte sobre una teacutecnica que permite mejorar el proceso de
automatizacioacuten de pruebas sobre una aplicacioacuten Web basaacutendose en el modelado de la aplicacioacuten para
proporcionar una abstraccioacuten en la implementacioacuten de las pruebas Tambiacuteeacuten se ha realizado una revisioacuten de los
diferentes modelos de calidad normativas y tipos de prueba de Software Finalmente se ha desarrollado una
herramienta de test comprendida por un conjunto de pruebas de aceptacioacuten automaacuteticas que permiten la
verificacioacuten y validacioacuten de la funcionalidad de la plataforma Web Galgus CHT Cloud Manager
Galgus CHT Cloud Manager es la plataforma Web distribuida ofrecida por Galgus para la gestioacuten de redes
compuestas por puntos de acceso Wifi Estas redes se encuentran instaladas en los diferentes clientes que hacen
uso de los servicios que ofrece Galgus los cuales se basan en la optimizacioacuten del rendimiento y las prestaciones
de las redes Wifi en entornos de alta densidad de usuarios Esto se consigue mediante un software embebido
patentado por Galgus conocido bajo el nombre de Cognitive Hostpot Technology (CHT) el cual es instalado
en los puntos de acceso Dicho software implementa un conjunto de algoritmos y caracteriacutescas colaborativas
para conseguir los objetivos planteados en redes Wifi
Como resultado del trabjo podemos proporcionar a los ingenieros de pruebas una herramienta con la que poder
automatizar el testeo de una plataforma Web De esta forma se consigue agilizar el proceso de pruebas y reducir
costes y esfuerzos en tareas repetitivas que anteriormente se haciacutean de forma manual
12
13
Abstract
The technological revolution we are living today focused mainly on the Internet world and therewith the Web
applications is allowing all the tools we have around us to be in a process of continuous evolution and change
In this project we have made a study of the art on a technique that allows to improve the process of automation
of testing on a Web application based on the modelling of the application to provide an abstraction in the
implementation of testing A review of the different quality models standards and types of software testing has
also been carried out Finally a tool comprised of a set of automated acceptance tests has been developed to
allow verification and validation of the functionality of the Galgus CHT Cloud Manager Web platform
Galgus CHT Cloud Manager is the distributed web platform offered by Galgus for the management of
networks composed by Wifi access points These networks are installed in the different clients that make
use of the services offered by Galgus which are based on the optimization of the performance and features
of Wifi networks in high user density environments This is achieved through an embedded software
patented by Galgus known as Cognitive Hostpot Technology (CHT) which is installed in the access points
This software implements a set of algorithms and collaborative features to achieve the objectives set in Wifi
networks
This allows us to provide quality assurance engineers with a tool to automate the testing of a Web platform In
this way the testing process is streamlined and costs and efforts are reduced in repetitive tasks that previously
used to be done manually
14
15
Iacutendice
Agradecimientos 9
Resumen 11
Abstract 13
Iacutendice 15
Iacutendice de Figuras 19
Glosario 24
1 Introduccioacuten 27 11 Motivacioacuten 28 12 Alcance y Objetivos 29 13 Estructura de la memoria 30
2 Estudio del Arte y Revisioacuten 32 21 Model Based Testing (MBT) 32
211 Introduccioacuten 32 212 iquestQueacute es Model Based Testing 33 213 iquestCoacutemo funciona Model Based Testing 33 214 Consideraciones para la aplicacioacuten de Model Based Testing (MBT) 36 215 Beneficios de Model Based Testing (MBT) 37 216 Problemas y Limitaciones de Model Based Testing (MBT) 38 217 Cuando elegir Model Based Testing (MBT) 38
22 Gestioacuten de Calidad Software 39 221 Introduccioacuten 39 222 Concepto de Calidad 39 223 Modelos de Calidad de Software 40 224 Principales Ventajas e Inconvenientes de Modelos de Calidad anteriores 44 225 Conclusiones 44
3 Marco Teoacuterico Pruebas de Software 46 31 Testing y Pruebas de Software 46 32 Principios de las Pruebas de Software 47 33 Proceso de Pruebas de Software Anaacutelisis disentildeo e implementacioacuten 48
331 Terminologiacutea 48 332 Proceso de Pruebas de Software 49
34 Clasificacioacuten de Pruebas de Software 51 341 Pruebas Funcionales 51 342 Pruebas No Funcionales 52 343 Pruebas Estructurales 54 344 Pruebas debidas a Cambios 54
35 Niveles de Prueba 54 351 Pruebas a Nivel de Componente 55 352 Pruebas a Nivel de Integracioacuten 55 353 Pruebas a Nivel de Aceptacioacuten 55
16
36 Dificultades de pruebas en aplicaciones Web e impacto 56
4 Sistema Galgus CHT Cloud Manager 58 41 Arquitectura y Descripcioacuten del Sistema 58
411 Puntos de Acceso (OpenWRT + CHT) 60 412 Broacuteker de Eventos AMQP (RabbitMQ) 61 413 Frontend 62 414 Zone Manager 62 415 MoMap 63 416 Servidor de Licencias 64
42 Alcance y Objetivos de las pruebas sobre el sistema planteado 65 43 Arquitectura de la Solucioacuten Entorno de UAT para el proceso de pruebas (User Acceptance Test) 67
5 Tecnologiacuteas y Herramientas Usadas 69 51 Selenium 69 52 Selenium WebDriver 70
521 Elementos del Navegador 70 53 Robot Framework (RF) 72
531 Estilo de representacioacuten Given-When-Then 72 532 Reportes 75 533 Libreriacuteas 76 534 Documentacioacuten 77
54 Pycharm (IDE) 78 55 GitGitlab 78
551 Git 78 552 Gitlab 78
56 Redmine 78 561 Uso en el Proyecto Galgus CHT Cloud Manager (Metodologiacutea Scrum) 79
6 Experimentos 82 61 Estructura del Proyecto 83 62 Vista de Gestioacuten Principal (Cloud Tab) 87
621 Administration 87 622 List 89 623 Manufacturer 90 624 MAP 92
63 Vista de Configuracioacuten (Configuration Tab) 95 631 Groups 95 632 CHT Zones 98 633 BackupRestore 100 634 Firmware 101
64 Vista de Red (Network Tab) 104 641 VLANS amp Bridges 104 642 SSIDs 106 643 CHT 108 644 Radius 110 645 Captive Portal 112 646 General 115 647 AP Network 117
7 Lineas de Mejora y Conclusiones 122 71 Liacuteneas de Mejora Futuras 122 72 Conclusiones Finales 123
Referencias 126
17
Anexo A Preparacioacuten del Entorno de Trabajo y Ejecucioacuten de Pruebas 128 A1 Preparacioacuten del entorno de trabajo 128
A11 Pip 128 A12 Virtualenv Entorno Virtual 128 A13 Selenium y Chromedriver 129 A14 Robot Framework y SeleniumLibrary 129 A15 Otras dependencias 130
A2 Ejecucioacuten de Pruebas 130 A3 Script de Prueba U007 (MAP) 132
Anexo B Docker de Robot Framework y Entorno de UAT Dockerizado 136 B1 Docker de Robot Framework 136 B2 Entorno de UAT Dockerizado 137
Anexo C Revisioacuten de Reportes y Logs 140 C1 Reporte de Logs ofrecido por Robot Framework 140 C2 Cloud Tab 140
C21 Administration 140 C22 List 142 C23 Manufacturers 143 C24 MAP 144
C3 Configuration Tab 145 C31 BackupRestore 145 C32 CHT Zones 146 C33 Firmware 147 C34 Groups 148
C4 Network Tab 150 C41 General 150 C42 SSID 151 C43 CHT 151 C44 VLAN 152 C45 Radius 153 C46 Captive Portal 154 C47 AP Network 155
Anexo D Diagrama de Gantt 157
18
19
IacuteNDICE DE FIGURAS
Figura 1 Fuente de datos Morgan Stanley 27
Figura 2 Manual Testing vs Automated Testing [20] 28
Figura 3 Fase de Pruebas y Validacioacuten 32
Figura 4 Esquema baacutesico de Model Based Testing 33
Figura 5 Proceso detallado de Model Based Testing (MBT) 34
Figura 6 Construccioacuten del Modelo 34
Figura 7 Concepto de Calidad 39
Figura 8 Liacutenea de tiempo de modelos a nivel de proceso 40
Figura 9 Logo de ITIL 40
Figura 10 ISOIEC 20000 41
Figura 11 Logo de WebQEM 41
Figura 12 Liacutenea de tiempo de modelos a nivel de producto 42
Figura 13 Esquema de ISO 9126 42
Figura 14 Esquema de ISOIEC 25000 43
Figura 15 Principios de las Pruebas de Software 47
Figura 16 Terminologiacutea para el proceso de pruebas 48
Figura 17 Proceso de Pruebas de Software 49
Figura 18 Clasificacioacuten de Pruebas de Software 51
Figura 19 Pruebas de Caja Negra 51
Figura 20 Pruebas de Rendimiento 52
Figura 21 Pruebas de Carga 52
Figura 22 Pruebas de Estreacutes 52
Figura 23 Pruebas de Usabilidad 53
Figura 24 Pruebas de Portabilidad 53
Figura 25 Pruebas de Caja Blanca 54
Figura 26 Modelo de desarrollo en V 55
Figura 27 Dificultades de pruebas en aplicaciones Web e impacto 56
Figura 28 Logo de Galgus 58
Figura 29 Arquitectura de CHT Cloud Manager 59
Figura 30 CHT_CLI 60
Figura 31 Plataforma de Gestioacuten de RabbitMQ 61
Figura 32 Patroacuten PublicadorSuscriptor 61
Figura 33 Ejemplo de Interfaz Graacutefica de un Zone Manager 62
Figura 34 Ejemplo de Interfaz Graacutefica de MoMap 63
20
Figura 35 Interfaz Graacutefica del Servidor de Licencias 64
Figura 36 Zero-Touch Provisioning (ZTP) 64
Figura 37 Test Plan de CHT Cloud Manager 65
Figura 38 Leyenda del Test Plan 66
Figura 39 Control de Versiones del Test Plan 66
Figura 40 Entorno de UAT con Docker (Anexo B) 67
Figura 41 Implementaciones disponibles de Selenium y Navegadores Web Compatibles 70
Figura 42 Coacutedigo de ejemplo con Python y Selenium 71
Figura 43 Estilo de representacioacuten Given-When-Then 72
Figura 44 Implementacioacuten de Pruebas en para el inicio de sesioacuten de CHT Cloud Manager 74
Figura 45 Ejemplo de reporte de pruebas automatizadas con Robot Framework 75
Figura 46 Ejemplo de documentacioacuten generada con Libdoc 77
Figura 47 Ejemplo de documentacioacuten generada con Testdoc 77
Figura 48 Ejemplo de Flujo de Trabajo en Redmine para Galgus CHT Cloud Manager 79
Figura 49 Esquema Graacutefico de Metodologiacutea Scrum 79
Figura 50 Logo de Galgus CHT Cloud Manager 82
Figura 51 Estructura del Proyecto 83
Figura 52 Fragmento del fichero ldquoSelectorpyrdquo 83
Figura 53 Fragmento del fichero ldquoCommon_Keywordsrobotrdquo 84
Figura 54 Fragmento del fichero de Configuracioacuten de pruebas ldquoConfigurationrobotrdquo 84
Figura 55 Diagrama de paquetes del proyecto de pruebas 85
Figura 56 Estructura de una Suite de Pruebas 85
Figura 57 Ejemplo de ldquoTest Setuprdquo personalizado para un caso de prueba 86
Figura 58 Vista de Gestioacuten Principal (Cloud Tab) 87
Figura 59 Pestantildea ldquoAdministrationrdquo 87
Figura 60 Diagramas de Flujo de Casos de Prueba U0025 y U0027 88
Figura 61 Script de Pruebas U0025 88
Figura 62 Keyword ldquoEdit Fieldsrdquo 88
Figura 63 Pestantildea ldquoList of Zone Managersrdquo 89
Figura 64 Diagrama de flujo de Caso de Prueba U0023 89
Figura 65 Script de Prueba U0023 90
Figura 66 Keyword ldquoZone Manager is registered successfullyrdquo 90
Figura 67 Seccioacuten de Fabricantes 90
Figura 68 Diagrama de flujo de Caso de Prueba U0009 91
Figura 69 Script de Prueba U0009 91
Figura 70 Toast Success 92
Figura 71 Keyword ldquoCorrectly Createrdquo 92
Figura 72 Setup amp Teardown de U0008 92
21
Figura 73 Mapa de Zone Managers 92
Figura 74 Funcioacuten que dibuja los ZM en el Mapa y obtiene los piacutexeles en pantalla 93
Figura 75 Diagrama de Flujo de Caso de Prueba U0007 94
Figura 76 Pestantildea ldquoGroupsrdquo 95
Figura 77 Diagrama de flujo de Caso de Prueba U0119 96
Figura 78 Script de Prueba U0119 97
Figura 79 Keyword ldquoVerify if AP is registered Succesfully on grouprdquo 97
Figura 80 Keywords Input Into Text Field y Clear Field Of Characters 97
Figura 81 Pestantildea ldquoCHT Zonesrdquo 98
Figura 82 Diagrama de Flujo de Caso de Prueba U0204 99
Figura 83 Scripts de Prueba U0204 99
Figura 84 Keyword Add Zone CHT to AP 99
Figura 85 Pestantildea BackupRestore 100
Figura 86 Diagrama de Flujo de Caso de Prueba U0401 101
Figura 87 Script de Prueba U0401 101
Figura 88 Keyword Restore For AP hace done successfully 101
Figura 89 Pestantildea ldquoFirmwarerdquo 102
Figura 90 Diagrama de Flujo de Caso de Prueba U0303 103
Figura 91 Script de Prueba U0303 103
Figura 92 Keyword Flash AP 103
Figura 93 Pestantildea ldquoVLAN amp Bridgesrdquo 104
Figura 94 Diagrama de Flujo de Caso de Prueba U0527 105
Figura 95 Script de Prueba U0527 105
Figura 96 Keyword Go And Create VLAN 105
Figura 97 Pestantildea SSIDs 106
Figura 98 Diagrama de Flujo de Caso de Prueba U0530 106
Figura 99 Script de Prueba U0530 107
Figura 100 Keyword Go And Create SSID 107
Figura 101 Pestantildea ldquoCHTrdquo 108
Figura 102 Diagrama de Flujo de Caso de Prueba U0539 109
Figura 103 Script de Prueba U0539 109
Figura 104 Keyword ACA Is Working 109
Figura 105 Keyword Changes On CLI 110
Figura 106 Comando CHT para obtener el estado del moacutedulo ACA en el punto de acceso 110
Figura 107 Pestantildea ldquoRadiusrdquo 110
Figura 108 Escenario de Funcionamiento de Servidor Radius 110
Figura 109 Diagrama de Flujo de Caso de Prueba U0601 111
Figura 110 Script de Prueba U0601 111
Figura 111 Keyword Create Radius Profile 112
22
Figura 112 Pestantildea Captive Portals 112
Figura 113 Escenario de Funcionamiento de un Portal Cautivo 112
Figura 114 Diagrama de Flujo de Caso de Prueba U0701 113
Figura 115 Script de Prueba U0701 113
Figura 116 Keyword Edit or Delete Captive Portal Profile 114
Figura 117 Pestantildea General 115
Figura 118 Diagrama de Flujo de Caso de Prueba U0522 116
Figura 119 Script de Prueba U0522 116
Figura 120 Keyword Check Number of Clients Increases 116
Figura 121 Pestantildea AP Network 117
Figura 122 Libreriacutea SSH para Robot Framework 117
Figura 123 Ventana de Configuracioacuten de TC Rules 118
Figura 124 Diagrama de Flujo de Caso de Prueba U0511 119
Figura 125 Script de Prueba U0511 120
Figura 126 Keyword Wait Timer 120
Figura 127 Keyword Check On CLI 120
23
24
GLOSARIO
CHT Cognitive Hostpot Technology
BDD Behaviour-Driven Development
MBT Model Based Testing
API Application Programing Interface
UAT User Acceptance Testing
SUT System Under Test
UML Unified Modeling Language
FSM Finite State Machine
RAE Real Academia Espantildeola
IEEE Institute of Electronical and Electronics Engineers
ITIL Information Technology Infrastructure Library
ISO International Organization for Standardization
WebQEM Web-site Quality Evaluation method
ISTQB International Software Testing Qualifications Board
TDD Test-Driven Development
SOA Service Oriented Architecture
WiFi Wireless Fidelity
MGR Manager Module
SB Smart Band Steering Module
TCM Traffic Congestion Management Module
LOC Localization Module
POWER Power Control Module
SR Smart Roaming Module
LB Load Balancing Module
AMQP Advance Message Queuing Protocol
HTML HyperText Markup Language
CSS Cascading Style Sheets
HTTPS HyperText Transfer Protocol Secure
TLS Transport Layer Security
REST REpresentational State Transfer
JSON JavaScript Object Notation
DOM Document Object Model
SQL Structure Query Language
ZMB Zone Manager Backend
ZTP Zero-Touch Provisioning
25
RF Robot Framework
CICD Continuous IntegrationContinuous Delivery
SSH Secure SHell
SCP Secure Copy ProtocolSimple Communication Protocol
26
27
1 INTRODUCCIOacuteN
ctualmente el desarrollo software se encuentra en un proceso revolucionario cuyo principal objetivo y
tendencia es la implantacioacuten y desarrollo de software distribuido donde se marcan como principales
objetivos la disponibilidad usabilidad y funcionalidad de cualquier aplicacioacuten a traveacutes de internet Es
aquiacute donde entran en juego entre otros el desarrollo de aplicaciones o servicios Web sustituyendo en gran
medida al desarrollo de aplicaciones y servicios de escritorio
Figura 1 Fuente de datos Morgan Stanley
Muchos son los aspectos a tener en cuenta entre los que cabe destacar la eficiencia la velocidad de respuesta y
de navegacioacuten los cuales para algunos servicios Web son excelentes pero para otros auacuten se encuentran en un
proceso de mejora Esto es debido a que gran cantidad de aplicaciones requieren de un buen disentildeo donde se
optimicen el uso de los recursos disponibles como el ancho de banda memoria carga del servidor respaldo
seguridad etc
A
Hemos establecido la civilizacioacuten de manera que los
maacutes cruciales elementos dependen de la ciencia y la
tecnologiacutea
Carl Sagan
28
11 Motivacioacuten
La gran demanda de servicios y aplicaciones Web distribuidas que permitan gestionar agilizar y simplificar
cualquier aacutembito de negocio hace que cada vez maacutes que dichas aplicaciones contemplen un mayor
conjunto de requisitos solicitados por los clientes lo cual se traduce en un mayor nuacutemero de funcionalidades
y casos de uso contemplados en dichas aplicaciones
Ademaacutes dichas aplicaciones se necesitan cada vez en un menor tiempo lo cual conlleva a reducir los
periodos en las diversas fases por las que pasa un proyecto software desde la fase de disentildeo hasta la de
pruebas Es en esta uacuteltima donde antes de ser entregada al cliente como un producto se detectan los
posibles errores e incluso se puede evaluar si la funcionalidad ofrecida por la aplicacioacuten esta alineada con
los requisitos demandados por el cliente
Los fallos o errores en las aplicaciones Web mal probadas bien por falta de asignacioacuten de tiempo o recursos
a la fase de pruebas tienen una mayor repercusioacuten teniendo el potencial de generar una gran cantidad de
quejas e insatisfaccioacuten por parte de los clientes casi inmediatamente En el caso de las aplicaciones Web
no soacutelo se trata de peacuterdidas econoacutemicas sino tambieacuten de peacuterdida de prestigio fiabilidad y credibilidad por
parte de nuestros usuarios o clientes Los consumidores de hoy demandan una tecnologiacutea intuitiva y de
confianza en un mercado en continuo crecimiento donde un pequentildeo error puede acarrear falta de
satisfaccioacuten en un usuario peacuterdidas millonarias a una empresa o incluso dantildeos humanos Y es en este tipo
de ciclos iterativos y raacutepidamente cambiantes donde la automatizacioacuten de pruebas juega un papel decisivo
iquestY cuaacutel es la causa de estos problemas Para ello debemos tener en cuenta que estos sistemas son disentildeados
por el ser humano el cual comete fallos ya sea por presioacuten en los plazos de trabajo por la complejidad del
coacutedigo o de la infraestructura por cambios de tecnologiacuteas o por cualquier otra interaccioacuten con el sistema
Como ha quedado reflejado un proceso riguroso de control de sistemas y documentacioacuten permiten
bull Ayudar a reducir el riesgo de los posibles fallos y Mejora la calidad de los sistemas a la hora de ser
usados
bull Un correcto mantenimiento del producto a lo largo del ciclo de desarrollo
bull Un cumplimiento de requisitos legales (normas nacionales e internacionales ordenanzas
municipales etc)
bull Una adecuacioacuten de un sistema a los requisitos contractuales
bull Una adaptacioacuten de estaacutendars especiacuteficos de la industria
La forma en la que se logre y las herramientas empleadas variaraacuten en funcioacuten de factores como la
envergadura y tipo de proyecto den cuanto a los riesgos tecnoloacutegicos de seguridad o de negocio asiacute como
del presupuesto y tiempo disponible
Figura 2 Manual Testing vs Automated Testing [20]
29
12 Alcance y Objetivos
Las pruebas de software o software testing pueden llevarse a la praacutectica de muacuteltiples maneras pero el
presente proyecto se centra en el componente funcional del producto enfocado en lo que hace el sistema y
no coacutemo primando la aceptacioacuten por parte de los usuarios en base a los requisitos de disentildeo originales Es
decir el punto de mira estaacute en cumplir los requisitos establecidos por el cliente dejando fuera del alcance
del proyecto la estructura del coacutedigo fuente implementado
Bajo este contexto se plantea la automatizacioacuten de la fase de pruebas de una aplicacioacuten Web distribuida
centrando el enfoque de este proyecto en la automatizacioacuten de pruebas funcionales maacutes concretamente
pruebas de humo or smoke tests y aceptacioacuten Hasta ahora dichas pruebas se realizaban manualmente por
un ingeniero de pruebas lo cual permitiacutea evaluar la calidad del producto que seriacutea entregado al cliente
Ademaacutes se realizaraacute un marco teoacuterico donde se resumiraacuten una clasificacioacuten de los diferentes tipos de
pruebas software que pueden realizarse sobre una aplicacioacuten
Concretamente la solucioacuten abordada en esta memoria se cintildee al mantenimiento de un producto Web como
es la plataforma Galgus CHT Cloud Manager Para ello se cubriraacuten un gran conjunto de funcionalidades
ofrecidas por dicha aplicacioacuten Web como por ejemplo inicio y cierre de sesioacuten flujos de navegacioacuten
comprobacioacuten de los elementos mostrados y uso de la caja de buacutesquedas Sin llegar a ser exhaustivos este
tipo de pruebas conocidas como smoke tests son faacutecilmente automatizables y permiten detectar las primeras
sentildeales de que un sistema no funciona de manera correcta Por tanto es necesario traducir los requisitos
funcionales a instrucciones de alto nivel faacutecilmente entendibles por personas con poca formacioacuten teacutecnica
dado que seraacute el el resultado mostrado de las pruebas realizadas (informes de pruebas) Estas instrucciones
usaraacuten Behaviour-Driven Development (BDD) para describir interacciones entre el usuario y el sistema
definiendo actor accioacuten y comportamiento esperado del sistema Robot Framework es la herramienta que
se usa para este punto
Una vez tenemos dichas instrucciones se deben traducir de nuevo a un lenguaje de menor nivel como es
Python para implementar los test scripts Estos scripts seraacuten los que Selenium Webdriver procese y traduzca
para comunicarse con el controlador del navegador Web Chrome en nuestro caso a traveacutes de una API
Posteriormente el navegador se encargaraacute de ejecutar los comandos de accioacuten y de devolver la informacioacuten
de estado de vuelta Finalmente Robot Framework elaboraraacute un informe en formato html detallando las
pruebas realizadas resultados de las interacciones tiempos de ejecucioacuten y espera errores producidos etc
Tambieacuten se realizaraacute un estudio del arte sobre una teacutecnica conocida como Model Based Testing (MBT)
Dicha teacutecnica permite la generacioacuten automaacutetica de las pruebas a realizar sobre un sistema partiendo del
modelado del comportamiento de dicho sistema Ademaacutes esta teacutecnica tambieacuten abarca la traduccioacuten de las
pruebas generadas en scripts ejecutables para aplicar dichas pruebas sobre el sistema dando tambiacuteeacuten la
posibilidad de evaluar los resultados Esto proporciona muchas ventajas sobre la fase de pruebas pero a la
vez tambieacuten requiere un mayor esfuerzo en la fase de disentildeo y una presencia continua de la fase de pruebas
en otras etapas del ciclo de vida del proyecto Tambieacuten se presentaraacute un conjunto de normativas que regula
y normaliza la gestioacuten de calidad software
Posteriormente se describiraacute el sistema sobre el cual se basa la aplicacioacuten bajo pruebas llamada CHT
Cloud Manager Se presentaraacute la arquitectura de la aplicacioacuten y posteriormente se destacaraacuten los objetivos
de automatizacioacuten de testeo sobre la misma proponiendo el entorno de UAT planteado para someter la
aplicacioacuten a las pruebas automaacuteticas desarrolladas Se dedicaraacute una seccioacuten a analizar las tecnologiacuteas y
herramientas usadas donde se centraraacute la atencioacuten en Robot Framework Selenium y Python como las
tecnologiacuteas usadas para automatizar el testeo Ademaacutes se destacaraacute la integracioacuten del entorno de UAT
como fase de la integracioacuten continua de la aplicacioacuten ademaacutes de la metodologiacutea de trabajo llevada a cabo
Finalmente se presentaraacuten algunos experimentos y demostraciones de uso de la herramienta desarrollada
se describiraacuten algunas liacuteneas de mejora y conclusiones y se incluiraacuten algunos posibles anexos para la puesta
en marcha de la aplicacioacuten y reportes de algunas pruebas entre otros
30
13 Estructura de la memoria
El siguiente esquema resume de forma geneacuterica los puntos tratados en esta memoria para que el lector pueda
tener una idea orientativa de la organizacioacuten de este documento
1 Introduccioacuten En este punto se abordan temas geneacutericos como los objetivos motivacioacuten y alcance de
forma que pueda adquirirse una breve aproximacioacuten a los detalles del proyecto
2 Estudio del Arte y Revisioacuten A lo largo de esta seccioacuten se presentaraacute un estudio sobre la teacutecnica
conocida como Model Based Testing la cual permitiriacutea mejorar el proceso de automatizacioacuten de
pruebas Ademaacutes se realiza una revisioacuten sobre la gestioacuten de Calidad Software presentado algunos
modelos existentes en la actualidad
3 Marco Teoacuterico Consta de un estudio sobre el proceso de pruebas en un proyecto Software y los
principales tipos de pruebas Software existentes
4 Sistema En este punto se presenta la arquitectura del sistema sobre el que se van a automatizar las
pruebas de aceptacioacuten o Smoke Tests Ademaacutes se describe el alcance y objetivos de dichas pruebas y
se presenta la arquitectura de la solucioacuten planteada como escenario de pruebas haciendo uso de Docker
como tecnologiacutea de automatizacioacuten en el despliegue de aplicaciones software alojadas en contenedores
de software
5 Tecnologiacuteas y Herramientas usadas Consta del conjunto de tecnologiacuteas usadas para la
implementacioacuten de las pruebas de aceptacioacuten automatizadas y las herramientas para utilizar dichas
pruebas y para gestionar el trabajo del equipo de desarrollo y calidad responsable de este proyecto
6 Experimentos Consta de un detalle sobre la funcionalidad de un conjunto de pruebas que han sido
implementadas para verificar y validar el funcionamiento esperado del sistema Para cada prueba se
definen criterios de aceptacioacuten diagramas de flujo y scripts de implementacioacuten detallando algunas de
las implementaciones clave
7 Liacuteneas de Mejora y Conclusiones Se incluye una seccioacuten conclusiones finales tras la realizacioacuten del
proyecto y una valoracioacuten del mismo a nivel general y personal Ademaacutes se destacaraacuten algunas liacuteneas
de mejora futuras relacionadas principalmente con la aplicacioacuten de Model Based Testing (MBT) y otros
aspectos sobre la implementacioacuten actual de la herramienta de automatizacioacuten
Ademaacutes se realizaraacute una seccioacuten de anexos en el que se trataraacuten puntos adicionales sobre el proyecto
bull Anexo A Preparacioacuten del Entorno de Trabajo y Ejecucioacuten de Pruebas
bull Anexo B Docker de Robot Framework y Entorno de UAT Dockerizado
bull Anexo C Revisioacuten de Reportes y Logs
31
32
2 ESTUDIO DEL ARTE Y REVISIOacuteN
n este punto se realizaraacute un estudio sobre el marco teoacuterico de una de las teacutecnicas existentes que permite
la generacioacuten y ejecucioacuten automaacutetica de casos de test a partir del modelado de un sistema para la fase
de pruebas de una aplicacioacuten Esta teacutecnica es conocida como Model Based Testing (MBT) Ademaacutes
se realizaraacute una revisioacuten de la normativa relacionada con la gestioacuten de calidad software analizando la familia de
normas ISOIEC 25000
21 Model Based Testing (MBT)
211 Introduccioacuten
Dada la rapidez con la que se demandan los servicios contratados por los clientes en muchas ocasiones la
mayoriacutea del tiempo y esfuerzo asignado para la realizacioacuten de proyectos de software van destinados a la
labor de desarrollo dedicando menos esfuerzos en otras fases del ciclo de vida de un proyecto como las
fases de disentildeo o de pruebas Esto puede conllevar a que el proyecto no se desarrolle de acuerdo con los
requisitos demandados por los clientes y que el nuacutemero de puntos de fallo del producto software aumente
La fase de testeo o prueba de un producto software durante su ciclo de vida es una etapa fundamental para
validar la calidad del producto desarrollado y ofrecido a un cliente para conseguir un grado de satisfaccioacuten
aceptable de forma que se cumpla con los requisitos demandados y con el menor grado de error posible
Figura 3 Fase de Pruebas y Validacioacuten
Uno de los factores por los que en ocasiones no se emplean suficientes recursos a la fase de pruebas es la
gran cantidad de casos de pruebas que se deben realizar para validar un sistema Por cada caso de prueba
se deben asignar recursos relacionados con la planificacioacuten disentildeo y ejecucioacuten del mismo
Por tanto en este punto cabe plantearse la idea de automatizar no solo los casos de pruebas que validan un
sistema sino la generacioacuten de los casos de prueba Esto puede permitir reducir de forma considerable el
coste y esfuerzos en la fase de pruebas En este contexto surge el concepto de Model Based Testing (MBT)
E
La tecnologiacutea no es en siacute el fin sino el medio entre la
sociedad del conocimiento y el desarrollo mundial
Anoacutenimo
33
212 iquestQueacute es Model Based Testing
Este se trata de un meacutetodo capaz de controlar la calidad del software durante su ciclo de vida permitiendo
la generacioacuten automaacutetica de los casos de prueba e incluso la ejecucioacuten y evaluacioacuten automaacutetica de
resultados Para ello se requiere de un modelado y disentildeo correcto del sistema bajo pruebas como base
para la aplicacioacuten de esta teacutecnica
Figura 4 Esquema baacutesico de Model Based Testing
MBT permite crear un modelo del comportamiento esperado por el sistema a traveacutes del cual permite la
aplicacioacuten de diferentes teacutecnicas para la generacioacuten de casos de prueba [1]
bull Generacioacuten de casos de pruebas con datos de entrada sobre un modelo de dominio del sistema bull Generacioacuten de casos de pruebas de un modelo de entorno bull Generacioacuten de casos de prueba con predicciones del comportamiento del modelo bull Generacioacuten de scripts de prueba a partir de pruebas abstractas
213 iquestCoacutemo funciona Model Based Testing
En primer lugar se requiere del disentildeo de un modelo del sistema bajo test el cual debe tener al menos dos
caracteriacutesticas principales debe ser pequentildeo en relacioacuten al tamantildeo del sistema de forma que no requiera
un coste elevado pero debe ser lo suficientemente detallado para describir completamente las
caracteriacutesticas que se quieran probar sobre el sistema
Una vez implementado el modelo del sistema a probar se procederiacutea a la utilizacioacuten de herramientas
basadas en la teacutecnica MBT para generar automaacuteticamente el banco de pruebas a partir del modelo del
sistema bajo test (SUT) Estos bancos de pruebas generados seraacuten un conjunto de pruebas abstractas cada
una de las cuales define la secuencia de operaciones a realizar para probar una funcionalidad determinada
con sus respectivos valores o datos de entrada necesarios y las salidas o respuestas del sistema que se
esperan
A partir del banco de pruebas abstractas se deben transformar en scripts de pruebas ejecutables lo cual
puede realizarse con herramientas basadas en la teacutecnica MBT Estos scripts podriacutean ser ejecutados para la
deteccioacuten de errores sobre el sistema bajo test y esta ejecucioacuten podriacutea ser controlada y monitorizada por
alguna herramienta de ejecucioacuten de pruebas
En el siguiente diagrama se muestra el proceso de aplicacioacuten de este meacutetodo donde se propone dividir el
proceso en cinco fases principales [1]
1 Modelado Modelar el sistema bajo test y su entorno 2 Generacioacuten Generar las pruebas abstractas a partir del modelo planteado en la fase anterior 3 Concretizado Concretizar o adaptar las pruebas abstractas para transformarlas en ejecutables 4 Ejecucioacuten Ejecutar las pruebas sobre el sistema bajo test y definir decisiones o veredictos para las
mismas de forma que se pueda determinar el correcto funcionamiento del sistema bajo test 5 Anaacutelisis Analizar los resultados obtenidos a partir de la ejecucioacuten de los casos de prueba
34
Destacar que para el generador de casos de prueba y el script de pruebas se suelen usar herramientas de pruebas
especiales Por este motivo se encuentran resaltados en negrita
Figura 5 Proceso detallado de Model Based Testing (MBT)
Una vez presentado el proceso o metodologiacutea para llevar a cabo dicha teacutecnica se describiraacuten las principales
fases
2131 Construccioacuten del Modelo
Dicha fase consiste en la construccioacuten de un modelo que represente el comportamiento detallado del sistema
bajo pruebas yo su entorno a partir de los requisitos de disentildeo del mismo y el plan de pruebas desarrollado para
cumplir con estos requisitos
Este es el paso maacutes importante en la aplicacioacuten de la teacutecnica Model Based Testing ya que el resto de fases
dependeraacute siempre del modelo del sistema bajo pruebas Cuanto maacutes completo sea el modelo maacutes efectivos
seraacuten los casos de prueba generados a partir de este
Figura 6 Construccioacuten del Modelo
35
Para llevar a cabo el modelo del comportamiento de la aplicacioacuten se requiere conocer exactamente el
comportamiento esperado de la misma lo cual lleva a estudiar y analizar en profundidad el sistema y su entorno
previamente
Existen diversas especificaciones formales para el modelado a partir de los requisitos como por ejemplo los
diagramas UML Estos ayudan a que el modelado sea una tarea algo maacutes sencilla de realizar que si se llevara a
cabo a partir de los requisitos escritos en lenguaje natural Por otro lado para modelar el comportamiento existen
diversas teacutecnicas como las maacutequinas de estados finitos (FSM) Cadenas de Maacuterkov Tablas de decisiones
Diagramas de estados etc
En conclusioacuten modelar un sistema no es una tarea sencilla ya que requiere de habilidades teacutecnicas experiencia
e imaginacioacuten para construir un modelo que se comporte de la forma deseada Dicho modelo debe cumplir con
las siguientes propiedades [2]
bull Debe ser lo maacutes abstracto posible sin perder la informacioacuten importante
bull No debe contener informacioacuten que sea redundante o que no esteacute relacionada con el alcance de las
pruebas
bull Debe ser entendible para los ingenieros de pruebas incluso a expensas de la brevedad y abstraccioacuten del
mismo
bull Debe ser flexible y abierto para permitir cambios y antildeadir o eliminar nuevas funcionalidades
bull Debe considerar todos los detalles de implementacioacuten de las pruebas
2132 Generacioacuten de Casos de Prueba
Los casos de prueba seraacuten generados tras la construccioacuten previa del modelo del sistema Antes de la creacioacuten de
los casos de prueba los ingenieros de pruebas deben especificar o proveer informacioacuten sobre el criterio o
propoacutesito de los casos de prueba las entradas y en algunos casos las salidas esperadas del sistema
Destacar que generar las salidas esperadas correspondientes a unas determinadas entradas es maacutes complejo que
generar soacutelo las entradas Para ello se necesita un oraacuteculo que cree salidas vaacutelidas y las mapee a los casos de
prueba Crear el oraacuteculo es la tarea maacutes compleja
Las dificultades presentadas en esta fase dependeraacuten de si el modelo es complejo o simple y la efectividad de
los casos de prueba generados dependeraacute de lo completo y preciso que sea dicho modelo para poder generar
automaacuteticamente los casos de prueba
Cuando el sistema es complejo la cantidad de casos de test es muy grande e incluso infinita Por tanto evaluar
todos los casos de test resulta inviable y costoso En este caso para mejorar la calidad del sistema se necesita
seleccionar los casos de test que realmente puedan ayudar a localizar tantos fallos como sea posible con un coste
aceptable
Existen diferentes criterios de cobertura que permiten ayudar a controlar el proceso de generacioacuten de casos de
prueba Sin embargo se recomienda seleccionar maacutes de uno de estos criterios para lograr un mayor resultado en
la cobertura de pruebas
2133 Ejecucioacuten de Casos de Prueba
La ejecucioacuten de los casos de pruebas requiere la transformacioacuten de los mismos en una forma ejecutable Debido
a que los los scripts de pruebas ejecutables pueden ser reutilizados durante todo el tiempo empleado en la
validacioacuten del sistema estos deben ser escritos de una forma maacutes eficiente que permita que sean reutilizables e
incluso que frente a una modificacioacuten sean maacutes faacuteciles generarlos y ejecutarlos Por ello se crean scripts
ejecutables para los casos de prueba abstractos
El proceso de transformacioacuten en pruebas ejecutables seriacutea maacutes eficiente si es hecha de forma automaacutetica
Despueacutes de aplicar los casos de prueba ejecutables al sistema bajo pruebas se obtienen las salidas actuales del
sistema las cuales deberaacuten ser contrastadas con las salidas esperadas
36
2134 Anaacutelisis de los Resultados
Una vez ejecutados los casos de pruebas y obtenidas las salidas actuales del sistema se deben evaluar y analizar
los resultados obtenidos Para ello se debe comparar las salidas actuales obtenidas con las salidas esperadas
especificadas en los casos de prueba Esta tarea de comparacioacuten podriacutea realizarse idealmente de forma
automaacutetica lo cual dariacutea como resultados posibles
1 Pasa Cuando las salidas actuales se encuentran acordes con las salidas esperadas
2 Falla Cuando las salidas actuales no se encuentran acordes con las salidas esperadas
3 Inconcluso Cuando no se puede tomar una decisioacuten en el momento
Hay que destacar que puede darse el caso en el que si las salidas esperadas no estaacuten bien determinadas los
resultados obtenidos al contrastar dichas salidas con las actuales sean falsos dando lugar a resultados sin utilidad
y que pueden dar lugar a confusioacuten
Por este motivo la generacioacuten automaacutetica de las salidas esperadas es una tarea compleja e importante en todo el
proceso especialmente en sistemas complejos Por tanto el nivel de dificultad para encontrar un oraacuteculo de
pruebas depende del tamantildeo y complejidad del sistema Sin embargo la necesidad e importancia del oraacuteculo de
pruebas tambieacuten aumenta cuando el sistema es maacutes complejo
Tras obtener los resultados se debe determinar si se decide generar maacutes casos de prueba si se debe modificar el
modelo o si la fase de pruebas debe ser detenida y debe ponerse en marcha el software del sistema que se estaacute
probando
214 Consideraciones para la aplicacioacuten de Model Based Testing (MBT)
Son muchos los artiacuteculos que describen aspectos importantes a tener en cuenta durante el desarrollo o la
aplicacioacuten de esta teacutecnica Algunas de estas consideraciones a destacar seriacutean las siguientes [3]
1 El modelo que describe el comportamiento del sistema es el punto clave
El comportamiento del modelo debe ser desarrollado cuidadosamente Sus limitaciones y restricciones deben
ser respetadas durante el modelado del sistema bajo pruebas De esta forma si el modelo estaacute mal las pruebas
generadas tambieacuten lo estaraacuten Por tanto la exactitud del modelo es fundamental para pasar a la fase de
generacioacuten de casos de prueba
2 Las pruebas deben cubrir los criterios de control de flujo y datos
Los criterios de cobertura de las pruebas definen un conjunto de casos de prueba seleccionados para la misma
Estos casos de pruebas pueden ser generados a partir de dos fuentes criterios de flujo de control o de flujo
de datos En el caso de pruebas aplicadas a grandes sistemas es importante combinar ambos criterios para
incrementar la cobertura de las pruebas
3 El nivel de automatizacioacuten debe ser elevado
El nivel de automatizacioacuten es un factor importante para definir la factibilidad de uso de MBT Normalmente
suele haber un uacutenico paso no automatizado el modelado del comportamiento del sistema el cual es utilizado
como entrada para el proceso de generacioacuten de los casos de prueba Si hubiese otros pasos no automatizados
se incrementariacutea el esfuerzo los costes y la complejidad de su uso
4 Son fundamentales las herramientas que soportan la automatizacioacuten de las fases de MBT
Las herramientas usadas deben soportar la ejecucioacuten de los pasos automatizados Si no hay una herramienta
que soporte un determinado paso esta tarea podriacutea ser difiacutecil e inviable Por tanto una herramienta debe
soportar la integracioacuten entre los diferentes pasos no automatizados y automatizados
5 Los liacutederes del proyecto deben entender las habilidades requeridas y la complejidad para usar
MBT
Las personas encargadas de la fase de pruebas necesitan conocer ademaacutes de las teacutecnicas de pruebas los
lenguajes de modelado y algunos lenguajes de programacioacuten
37
6 El orden de los pasos a seguir mientras se usa un enfoque MBT
Es necesario respetar los pasos seguidos para la generacioacuten de los casos de prueba de forma que sean
respetados en la fase de ejecucioacuten de las pruebas siendo ejecutados en la misma secuencia en que fueron
definidos En caso contrario se podriacutean generar salidas erroacuteneas de dichas pruebas
7 Transferencia de la Tecnologiacutea
Las tecnologiacuteas usadas para la aplicacioacuten de la teacutecnica MBT se transfieren desde entornos acadeacutemicos o de
investigacioacuten para ser implementados en proyectos industriales Por este motivo necesitan ser analizados
cuidadosamente antes de ser usadas
215 Beneficios de Model Based Testing (MBT)
A continuacioacuten se definen diversos beneficios que proporciona la aplicacioacuten de Model Based Testing para la
fase de pruebas [1] [4]
1 Deteccioacuten de Fallos del Sistema Bajo Pruebas
El modelado del comportamiento del sistema bajo pruebas permite detectar errores ambiguumledades o lagunas
que pueden presenciarse en la toma de requisitos especificacioacuten y disentildeo del software Por tanto permite
una deteccioacuten temprana de errores
2 Reduccioacuten de costes y tiempo en la fase de pruebas
La aplicacioacuten de esta teacutecnica contribuye a que el tiempo coste y recursos empleados a la fase de pruebas
disminuya Sin embargo se requiere una mayor asignacioacuten de recursos para el modelado y mantenimiento
del sistema
3 Mejora de la calidad de las pruebas
Cuando las pruebas se desarrollan manualmente la calidad de las mismas es muy dependiente de los
desarrolladores que la implementan Ademaacutes el proceso de disentildeo no puede ser reproducido el criterio
racional aplicado para cada prueba normalmente no es recordado y el resultado de los casos de prueba no es
faacutecilmente interpretado ni contrastado con los requisitos originales del sistema
Model Based Testing es una teacutecnica capaz de mejorar mucho estos inconvenientes que se presentan sobre el
desarrollo de pruebas manuales gracias al generador automatizado de casos de prueba
4 Trazabilidad
Puede definirse como la habilidad para relacionar cada caso de prueba al modelo criterio de seleccioacuten e
incluso a los requisitos informales del sistema Esto ayuda a explicar los casos de prueba asiacute como justificar
por queacute fueron creados Los algoritmos aplicados para la generacioacuten de pruebas deben saber queacute partes del
modelo seraacuten empleadas en cada caso de prueba y las salidas esperadas
5 Evolucioacuten de los requisitos
Si los requisitos del sistema cambian con la aplicacioacuten de Model Based Testing bastariacutea con actualizar el
modelo y las pruebas seraacuten generadas de nuevo de forma automaacutetica Debido a que el modelo es usualmente
maacutes pequentildeo que el conjunto de pruebas del sistema requiere menos tiempo actualizar el modelo que
actualizar todos los casos de prueba Por tanto puede concluirse que se obtiene una respuesta maacutes raacutepida
frente a un cambio en los requisitos
6 Reusabilidad del modelo
El modelo contiene informacioacuten sobre el comportamiento del sistema bajo pruebas Por tanto este puede ser
reutilizado en futuras pruebas incluso cuando los requisitos cambian
38
216 Problemas y Limitaciones de Model Based Testing (MBT)
Una vez destacados los beneficios que aporta dicha teacutecnica tambieacuten es importante detallar algunos problemas
y limitaciones sobre su uso [1] [5]
2161 Problemas
bull Para abordar dicha teacutecnica es necesario que los ingenieros de pruebas tengan habilidades teacutecnicas sobre
la notacioacuten usada para el modelado del sistema Ademaacutes deberiacutean tener experiencia con herramientas
scripts y lenguajes de programacioacuten usados para ejecutar las tareas de Model Based Testing
bull Cuando dicha teacutecnica se pretende aplicar a sistemas complejos el modelado del sistema es maacutes
complejo y existe riesgo de producirse un desbordamiento de la cantidad de casos de prueba generados
a partir del modelo Por esta razoacuten es muy importante definir bien el conjunto de criterios para la
generacioacuten de las pruebas lo cual permite acotar la cobertura de pruebas de forma razonable
bull La automatizacioacuten de la generacioacuten del oraacuteculo de pruebas a partir del modelo es compleja
especialmente en sistemas complejos Cuando el tamantildeo del sistema aumenta la necesidad de
automatizacioacuten tambieacuten aumenta
bull Es necesario desarrollar un modelo de software especiacutefico para un dominio en concreto de aplicacioacuten
ya que existen diversas notaciones de modelado del sistema
bull Es necesario la especificacioacuten formal de los requisitos para obtener el modelo del sistema a partir de
estos La especificacioacuten informal o en lenguaje natural de los requisitos puede dar lugar a ambiguumledades
que dificultan la exactitud en el modelado
2162 Limitaciones
bull No es posible modelar todos los aspectos del comportamiento del sistema bajo pruebas Por tanto es
necesario el uso de otras notaciones de modelado que cubran dichos aspectos
bull Los proyectos software evolucionan continuamente surgiendo nuevos requisitos los cuales algunos
pueden quedar fuera de la fecha de planificacioacuten Si se ha comenzado con el modelado a partir de
requisitos antiguos se construiraacute un modelo erroacuteneo que no reflejaraacute los nuevos requisitos
contemplados lo cual daraacute lugar a errores en el sistema bajo pruebas o resultados no fiables
bull Cuando se produce un fallo en una prueba generada podriacutea resultar maacutes complejo determinar la causa
del fallo ya que la secuencia de pruebas generadas en Model Based Testing podriacutea ser maacutes compleja y
menos intuitiva que las disentildeadas manualmente
217 Cuando elegir Model Based Testing (MBT)
Finamente tras detallar los beneficios problemas y limitaciones sobre la teacutecnica bajo estudio se destacan
algunos puntos principales a tener en cuenta para la aplicacioacuten de dicha teacutecnica
bull Debe existir documentacioacuten lo suficientemente buena sobre el sistema para poder aplicarla
bull Si ya existe un modelo del sistema seriacutea un primer paso que facilitariacutea su aplicacioacuten
bull El manager del proyecto debe ser consciente que la fase de pruebas con Model Based Testing comienza
desde la toma de requisitos ya que se debe modelar el comportamiento del sistema bajo pruebas a partir
de estos Por tanto no se puede esperar que la fase de pruebas comience despueacutes del desarrollo Hacerlo
tras el desarrollo podriacutea significar la modificacioacuten de los requisitos y en consecuencia el desarrollo
39
22 Gestioacuten de Calidad Software
221 Introduccioacuten
En los uacuteltimos antildeos la creciente demanda de productos software principalmente de aplicaciones distribuidas
como los servicios Web provoca que diferentes empresas busquen soluciones software para satisfacer las
necesidades de los clientes Este conjunto de empresas forma un entorno competitivo en el que se intenta buscar
algunos factores para destacar sobre los demaacutes competidores respondiendo a las nuevas exigencias del mercado
Bajo este contexto se plantea la implantacioacuten de una direccioacuten basada en la calidad como la propuesta que
mejores resultados ha ofrecido No solo basta con desarrollar software acorde a los requisitos de los clientes y
las exigencias de los mismos sino que se trata de crear un producto que garantice su correcto funcionamiento
bajo el sustento de una garantiacutea de calidad razonable
El concepto de ldquocalidadrdquo siempre se ha relacionado con la inspeccioacuten de productos fiacutesicos Pero dicho teacutermino
ha ido expandiendo su contexto de una forma maacutes global y aplicable a cualquier tipo de servicio o producto
ofrecido a un cliente
222 Concepto de Calidad
Acorde a la definicioacuten ofrecida por la Real Academia Espantildeola (RAE) la calidad se define como ldquouna propiedad
o conjunto de propiedades inherente a algordquo ldquoAdecuacioacuten de un producto o servicio a las caracteriacutesticas
especificadasrdquo o ldquocondicioacuten o requisito que se pone en un contratordquo [6]
Por otro lado el instituto de Ingenieros Eleacutectricos y Electroacutenicos (IEEE) define la calidad como ldquoel grado con
el que un sistema componente o proceso cumple con los requisitos especificados y las necesidades o
expectativas del cliente o usuariordquo destacando que el eacutenfasis radica en los requisitos especiacuteficos del sistema y
en la buacutesqueda de la satisfaccioacuten del cliente [7]
Roger Pressmann define la Calidad del Software como ldquoConcordancia del software producido con los requisitos
expliacutecitamente establecidos con los estaacutendares de desarrollo prefijados y con los requisitos impliacutecitos no
establecidos formalmente que desea el cliente y en uacuteltima instancia el usuariordquo [8]
Una vez presentado el concepto de calidad su definicioacuten orientada al software se refiere al grado de desempentildeo
de las principales caracteriacutesticas con las que debe cumplir un sistema durante su ciclo de vida Estas
caracteriacutesticas son las que garantizan que el cliente cuente con un sistema confiable lo que permite un aumento
de la satisfaccioacuten frente a la funcionalidad y eficiencia del sistema construido
Figura 7 Concepto de Calidad
40
223 Modelos de Calidad de Software
Los modelos de calidad son aquellos documentos que integran la mayor parte de las mejores praacutecticas proponen
temas de administracioacuten en los que cada organizacioacuten debe hacer eacutenfasis integran diferentes praacutecticas dirigidas
a los procesos clave y permiten medir los avances en calidad
Bajo este contexto los modelos de calidad deben permitir la evaluacioacuten del sistema de forma cualitativa o
cuantitativa y de acuerdo con esta evaluacioacuten la organizacioacuten podraacute proponer implementar estrategias que
permitan la mejora continua en el resto de etapas del ciclo de vida como son las etapas de anaacutelisis disentildeo
desarrollo y pruebas software [7] Desde finales de los antildeos 70 se han ido desarrollando diversos modelos de
calidad del producto software con el fin de fijar una terminologiacutea y entender queacute concepto de calidad se estaacute
usando Asiacute mismo dichos modelos de calidad se clasifican de acuerdo con el enfoque de evaluacioacuten
contemplado ya sea a nivel de proceso producto o calidad de uso
2231 Calidad a Nivel de Proceso
Este enfoque de calidad de software describe que la calidad de un sistema software debe ser implementada desde
el inicio del proyecto y en cada etapa de su ciclo de vida debiendo permitir el control y seguimiento de los
aspectos de calidad para minimizar los riesgos y ofrecer un soporte continuo De esta forma se consigue
garantizar un nivel oacuteptimo de cumplimiento de los factores de calidad definidos teniendo en cuenta que si en
alguna etapa no se verifican dichos factores posiblemente disminuya el nivel de calidad no solo del proceso si
no tambieacuten del producto en desarrollo [7]
A continuacioacuten se muestra una liacutenea de tiempo de algunos modelos a nivel de proceso y se describen dos de los
que maacutes intereacutes presentan dentro del aacutembito de este proyecto
Figura 8 Liacutenea de tiempo de modelos a nivel de proceso
ITIL (Information Technology Infrastructure Library)
Desarrollado en el Reino Unido con el fin de fortalecer la gestioacuten gubernamental a partir de cinco elementos
fundamentales la perspectiva del negocio entrega del servicio soporte del servicio manejo de la infraestructura
y manejo de aplicaciones con el propoacutesito de ofrecer una estructura integral para prestar a la organizacioacuten un
servicio completo cubriendo necesidades de apoyo de instalacioacuten adecuacioacuten de redes comunicaciones
hardware servidores sistema operativo y software necesarios
Figura 9 Logo de ITIL
41
ISOIEC 20000
El objetivo principal de esta norma es avalar que la prestacioacuten de servicios de TI en una empresa cuenta con la
calidad necesaria para brindar dichos servicios a los clientes Esta norma engloba diferentes secciones dedicadas
a las especificaciones de dicha norma y a los coacutedigos de buenas praacutecticas
Figura 10 ISOIEC 20000
WebQEM
Web-site Quality Evaluation Method se trata de una metodologiacutea de evaluacioacuten de calidad de sitios Web en seis fases planificacioacuten y programacioacuten de la evaluacioacuten de la calidad definicioacuten y especificacioacuten de los requisitos de calidad establecidos definicioacuten e implementacioacuten de la evaluacioacuten elemental definicioacuten e implementacioacuten de la evaluacioacuten global anaacutelisis de resultados y evaluacioacuten de meacutetricas y finalmente conclusiones y documentacioacuten
Figura 11 Logo de WebQEM
42
2232 Calidad a Nivel de Producto
El enfoque de la calidad de software a nivel de producto tiene como objetivo especificar y evaluar el
cumplimiento de los criterios del producto Para ello se suelen definir y aplicar medidas o meacutetricas internas o
externas Por esta razoacuten muchas normas definen la calidad a nivel de producto de tipo interna externa y en uso
Esta uacuteltima se define como el conjunto de atributos relacionados con la aceptacioacuten por parte del usuario final y
seguridad
A continuacioacuten se muestra una liacutenea de tiempo de algunos modelos a nivel de proceso y se describen tres de los
que maacutes intereacutes presentan dentro del aacutembito de este proyecto
Figura 12 Liacutenea de tiempo de modelos a nivel de producto
ISO 9126
Este se basa en el modelo McCall el cual es uno de los modelos pioneros en la evaluacioacuten de la calidad de
software Desarrollado en 1991 es un marco normativo dirigido a desarrolladores aseguradores de calidad
evaluadores analistas y cualquier otro involucrado en el proceso de construccioacuten de software y la gestioacuten de
calidad del mismo Estaacute dividido en cuatro partes Modelo de Calidad Meacutetricas Externas Meacutetricas Internas y
Calidad de Meacutetricas en Uso
Esta norma busca la fiabilidad funcionalidad usabilidad eficiencia mantenibilidad y portabilidad en la
construccioacuten de productos software A continuacioacuten se muestra un esquema que resume dichas caracteriacutesticas
y subcaracteriacutesticas [8]
Figura 13 Esquema de ISO 9126
43
ISOIEC 25000
Basada en la norma ISO 9126 y adaptando parte del marco normativo a las necesidades del mercado actual Esta
norma tambieacuten conocida como SQuaRE (Software Product Quality Requirements and Evaluation) establece
un marco de trabajo comuacuten para evaluar la calidad de productos de Software
En dicha norma se definen los modelos teacuterminos y definiciones comunes para el resto de normas que componen
la serie 25000 La ISOIEC 25000 presenta diversas secciones entre las que se puede destacar [9]
ISOIEC 25010 Describe las caracteriacutesticas y subcaracteriacutesiticas de calidad que pueden ser evaluadas
en un producto software diferenciando entre calidad interna externa y de uso En la siguiente figura se
presenta un desglose de dichas caracteriacutesticas
ISOIEC 25040 Define el proceso de evaluacioacuten perioacutedico de la calidad del producto software
Figura 14 Esquema de ISOIEC 25000
44
224 Principales Ventajas e Inconvenientes de Modelos de Calidad anteriores
2241 A nivel de Proceso
Modelo Ventajas Inconvenientes
ITIL bull Mejor estructuracioacuten organizacioacuten y
claridad de los proyectos
bull Mayor control administrativo
bull Mayor eficacia y rapidez ante cambios
bull Incrementa la productividad del negocio y la
fiabilidad de los clientes
bull Tiempo y esfuerzo necesarios
bull Falta de conocimiento para apreciar la mejora
proporcionada
bull Involucracioacuten y compromiso de todo el
personal de la organizacioacuten
bull Frustracioacuten generada por expectativas a corto
plazo
bull No hay mejoriacutea si la inversioacuten asignada para
implantar el modelo es insuficiente
ISOIEC
20000 bull Reconocimiento internacional
bull Muy usado por las organizaciones
WebQUEM bull Calidad medida en fases y actividades de
forma cuantitativa con indicadores
bull Aplicaciones de Software centradas en la Web
son cada vez maacutes complejas provocan mayor
complejidad en su implantacioacuten
2242 A nivel de Producto
Modelo Ventajas Inconvenientes
ISO 9126 bull Determina queacute caracteriacutesticas y
subcaracteriacutesticas son importantes para el
producto
bull Define meacutetricas especiacuteficas para los
componentes Software
bull Define indicadores para las caracteriacutesticas de
calidad
bull Usabilidad tratada desde la perspectiva del
proceso no del producto
bull No tiene en cuenta la caracteriacutestica de ldquofacilidad
de aprendizajerdquo siendo esta recomendada por
otros estaacutendares
bull Meacutetricas complejas difiacutecilmente medibles
Requieren descomposicioacuten
ISOIEC
25000 bull Detecta objetivos del producto alineados con
necesidades reales de clientes finales
bull Evita ineficiencias y maximiza rentabilidad
y calidad del producto
bull El proceso de evaluacioacuten perioacutedica permite
la mejora continua
bull No establece niveles de calidad para cada
proyecto
bull No hace uso de meacutetricas o umbrales de calidad
225 Conclusiones
Una vez presentado el concepto de gestioacuten de calidad de software y los principales modelos y normas es
interesante destacar la diferencia entre calidad interna y externa La calidad interna se centra en las caracteriacutesticas
propias del producto software (disentildeo especificacioneshellip) mientras que la calidad externa lo hace con las
caracteriacutesticas dinaacutemicas del mismo es decir con el comportamiento Es por ello que el proceso de calidad
interna se inicia en las fases tempranas del ciclo de vida de un proyecto mientras la calidad externa se aplica
una vez se tiene un primer prototipo funcional del producto software desarrollado Por tanto se trataraacute de
automatizar el proceso de evaluacioacuten de la calidad externa del proyecto CHT Cloud Manager analizando
verificando y validando automaacuteticamente la aceptacioacuten de dicho producto
45
46
3 MARCO TEOacuteRICO PRUEBAS DE SOFTWARE
ras presentar el concepto de calidad y algunas de las normas y estaacutendares maacutes conocidos que describen
la aplicacioacuten de dicho concepto en el aacutembito del desarrollo de software se centraraacute el enfoque en el
papel del testeo y las pruebas de software Con ello se destacaraacuten algunos puntos principales para
llevar a cabo las pruebas de software el anaacutelisis disentildeo e implementacioacuten de dichas pruebas los diferentes tipos
y niveles de pruebas y las dificultades de la aplicacioacuten de pruebas de software sobre aplicaciones Web
31 Testing y Pruebas de Software
Habitualmente se tiene una percepcioacuten del testing de un producto como una tarea basada en la ejecucioacuten de
pruebas de forma repetitiva para la buacutesqueda de errores o problemas que puedan repercutir sobre la calidad del
mismo Pero el testing no solo se basa en la realizacioacuten de pruebas
Se deben identificar otras tareas que estaacuten relacionadas con el testing las cuales se llevan a cabo antes y despueacutes
de la ejecucioacuten de pruebas Estas tareas estaacuten relacionadas principalmente con la planificacioacuten y control del
proceso de pruebas el disentildeo de los diferentes casos de prueba o test cases y la posterior comprobacioacuten de los
resultados obtenidos tras llevar a cabo las pruebas Otras tareas podriacutean ser la propia evaluacioacuten de los diferentes
criterios de finalizacioacuten del proceso de pruebas el anaacutelisis de informes de resultados o la revisioacuten de la
documentacioacuten generada en la fase de pruebas
A continuacioacuten se citan algunas definiciones para explicar el concepto de pruebas de software
ldquoUna prueba es una actividad ejecutada para evaluar la calidad del producto software y mejorarlo mediante
la identificacioacuten de problemas errores o defectos en su funcionamiento [9]rdquo
ldquoLas pruebas de Software consisten en verificaciones dinaacutemicas del comportamiento del software bajo
pruebas mediante un conjunto finito de casos de prueba seleccionadas adecuadamente sobre un dominio
infinito de casos posibles [1]rdquo
Atendiendo a las definiciones presentadas las pruebas de software son dinaacutemicas porque se puede ejecutar el
software bajo pruebas con un conjunto de valores de entrada especiacuteficos para encontrar fallos en su
comportamiento Por otro lado la realizacioacuten de pruebas exhaustivas no es posible para la mayoriacutea de los
productos software reales debido a la gran cantidad de entradas posibles para cada operacioacuten entradas invaacutelidas
o no esperadas y las infinitas secuencias de operaciones posibles
Por estas razones para aplicar un proceso de pruebas de software razonable en cuanto a recursos y tiempo de un
proyecto es necesario seleccionar un conjunto abarcable de pruebas Debido a esto la clave estaacute en el criterio
de seleccioacuten de dichas pruebas Una vez ejecutadas las pruebas seleccionadas se debe decidir si el
comportamiento esperado del sistema falla o no Este es el llamado problema del oraacuteculo el cual es resuelto en
la mayoriacutea de los casos de forma manual mediante la inspeccioacuten de los resultados de la prueba
T
La tecnologiacutea no es nada Lo importante es que tengas feacute
en la gente que sean baacutesicamente buenas e inteligentes
y si les das herramientas haraacuten cosas maravillosas con
ellas
Steve Jobs
47
32 Principios de las Pruebas de Software
Una vez presentada la definicioacuten de pruebas de Software se han obtenido algunos detalles que encajan
perfectamente con una serie de principios que han sido establecidos para el testing de productos software seguacuten
ISTQB (International Software Testing Qualifications Board) [10]
Figura 15 Principios de las Pruebas de Software
1 Las pruebas demuestran la presencia de defectos no su ausencia Las pruebas pueden mostrar que
los defectos estaacuten presentes en el producto pero no pueden probar que no haya defectos Por tanto las
pruebas pueden reducir la probabilidad de existencia de defectos en el software pero incluso si no se
encuentran defectos las pruebas no son una garantiacutea total para afirmar la ausencia de defectos en el
producto final
2 Las pruebas exhaustivas son imposibles Probar todas las posibles combinaciones de entradas y
condiciones previas sobre una aplicacioacuten no es factible excepto en casos muy triviales En lugar de
intentar realizar pruebas exhaustivas se debe usar el anaacutelisis de riesgos las teacutecnicas de prueba y las
prioridades ademaacutes de la automatizacioacuten para enfocar los esfuerzos en la fase de pruebas
3 Las pruebas tempranas ahorran tiempo y dinero Para una deteccioacuten temprana de errores y defectos
las actividades de pruebas deben iniciarse lo antes posible en el ciclo de vida del desarrollo del software
De esta forma se consigue una reduccioacuten de costes ya que cuanto maacutes tarde se detecte un defecto maacutes
costoso y difiacutecil seraacute corregirlo
4 Los defectos se agrupan Generalmente una pequentildea parte del software desarrollado concentra la
mayor complejidad del mismo por lo que la mayoriacutea de los defectos detectados tienen una mayor
probabilidad de encontrarse en esos elementos maacutes complejos Por tanto la realizacioacuten de un buen
anaacutelisis de riesgos permite enfocar el esfuerzo de pruebas en las aacutereas del producto con mayor
probabilidad de presentar defectos
Aplicando el Principio de Pareto al control de calidad [11] el 80 de los errores y defectos estaacute causado
por un 20 del total del producto software desarrollado lo cual podriacutea ser un buen principio sobre el
que basar el anaacutelisis de riesgos
5 Cuidado con la paradoja del pesticida Si las mismas pruebas se repiten una y otra vez con el tiempo
los mismos casos de pruebas ya no encontraraacuten nuevos defectos lo cual no quiere decir que la aplicacioacuten
presente una ausencia completa de los mismos (Las pruebas ya no son eficaces para detectar defectos
al igual que los pesticidas ya no son eficaces para matar insectos despueacutes de un tiempo) Para detectar
nuevos defectos es necesario que las pruebas existentes y los datos de las pruebas deban cambiar
ademaacutes de surgir la necesidad de disentildear nuevas pruebas
48
6 Las pruebas dependen del contexto Cada empresa organizacioacuten o proyecto adaptaraacute el proceso de
pruebas a sus necesidades recursos disponibles o aacutereas de riesgo existentes
7 La ausencia de errores es una falacia Un producto software puede tener un 100 de casos de eacutexito
en su fase de pruebas pero esto solo indica que hay defectos que auacuten no han sido localizados e
identificados
33 Proceso de Pruebas de Software Anaacutelisis disentildeo e implementacioacuten
Partiendo de los principios detallados en la seccioacuten anterior se presentan las diferentes etapas del proceso de
pruebas de software asiacute como la documentacioacuten generada en cada etapa
331 Terminologiacutea
Previamente se presentaraacuten algunos teacuterminos y definiciones que convienen describir para una mejor
comprensioacuten de todo el proceso de pruebas [3]
Figura 16 Terminologiacutea para el proceso de pruebas
1 Condicioacuten de prueba Elemento o evento de un componente o sistema que puede ser verificado por
uno o maacutes casos de prueba Los diferentes requisitos que definen la funcionalidad de un sistema pueden
ser descompuestos en diferentes condiciones de prueba
2 Caso de prueba conjunto de valores de entrada precondiciones de ejecucioacuten y valores esperados
Estos son desarrollados para perseguir un objetivo particular por ejemplo una condicioacuten de prueba
3 Precondicioacuten Condiciones de entorno y estado que deben ser satisfechas antes de que un componente
o sistema pueda ser sometido a un caso de prueba o conjunto de estos
4 Abstraccioacuten de casos de prueba Consiste en la generalizacioacuten de los casos de prueba especiacuteficos sin
valores concretos para sus entradas condiciones de prueba o valores esperados En resumen no es maacutes
que llevar las condiciones de prueba a un caso general para cualquier valor de entrada
5 Script de pruebas Una vez disentildeados los casos de prueba estos pueden ser implementados y
ejecutados por una herramienta de automatizacioacuten Un script de pruebas puede contener varios casos
de prueba
6 Paquete de pruebas Consiste en la agrupacioacuten de casos de prueba relacionados en cuanto a la
funcionalidad que automatizan sobre el sistema
7 Programacioacuten de la ejecucioacuten de pruebas Describen el flujo de ejecucioacuten de los diferentes paquetes
de pruebas
49
332 Proceso de Pruebas de Software
No existe un proceso de pruebas universal pero existen conjuntos comunes de actividades de prueba sin las
cuales las pruebas disentildeadas e implementadas tendriacutean menos probabilidad de alcanzar sus objetivos
establecidos Estos conjuntos de actividades de prueba constituyen un proceso de pruebas
Como se ha mencionado en secciones anteriores el proceso de pruebas se debe iniciar en las fases maacutes iniciales
del ciclo de vida de un proyecto Por tanto las actividades del proceso de pruebas la manera en que se
implementan dichas actividades y cuaacutendo ocurren pueden ser discutidas en la estrategia de pruebas de una
organizacioacuten
A continuacioacuten se exponen las etapas fundamentales del proceso de pruebas detallando en cada una de ellas la
documentacioacuten generada y coacutemo contribuyen a la mejora de la calidad del producto con su aplicacioacuten en el ciclo
de vida de un proyecto [13]
Figura 17 Proceso de Pruebas de Software
3321 Planificacioacuten y Control de Pruebas
La planificacioacuten consiste en determinar los diferentes objetivos de las pruebas realizadas sobre el Sistema bajo
test las especificaciones y los recursos que se necesitaraacuten para llevar a cabo la fase de pruebas y cumplir con los
objetivos planteados
Es en este punto donde se define el alcance de las pruebas a realizar de forma que se selecciona lo que seraacute y
no seraacute testeado ademaacutes de indicar quieacuten haraacute cada prueba y como la llevaraacute a cabo Mediante los objetivos de
las pruebas se puede establecer un punto de finalizacioacuten del proceso
Como salida de la actividad de planificacioacuten se obtendriacutea el ldquoPlan de Pruebasrdquo el cual documenta la estrategia
y el alcance de las pruebas la prioridad en cuanto a su realizacioacuten y las estimaciones temporales para su
evaluacioacuten ademaacutes de los recursos materiales y humanos para llevarlas a cabo
Es crucial que dicho documento sea validado por el personal correspondiente del proyecto antes de continuar
con las siguientes etapas del proceso de pruebas
Por otro lado el control de pruebas es una actividad desarrollada durante todo el ciclo de vida del proceso de
pruebas el cual permite contrastar el progreso actual con el plan original trazado para la aplicacioacuten de dicho
proceso incluyendo informes y desviaciones
Cuando se produce una desviacioacuten del plan original que introduce cierto riesgo adicional puede hacerse
necesario modificar los objetivos fijados para asegurar la calidad del producto De ahiacute que sea sumamente
importante tener en consideracioacuten la documentacioacuten generada en antiguos proyectos
50
3322 Anaacutelisis y Disentildeo de Pruebas
Una vez planificado el alcance y objetivos de las pruebas se realiza una actividad de anaacutelisis donde se traducen
a condiciones de prueba y posteriormente se disentildean los casos de prueba de alto nivel a partir de la abstraccioacuten
de los casos de prueba
Por otro lado cabe destacar la necesidad de un mecanismo que garantice la trazabilidad con la finalidad de
mantener alineados en todo momento los casos de prueba con los objetivos de la misma incluso contemplando
la posibilidad de que los objetivos puedan cambiar en alguacuten momento del proceso de pruebas
El documento generado en esta actividad es conocido como ldquoespecificaciones de disentildeo de pruebasrdquo
3323 Implementacioacuten y Ejecucioacuten de Pruebas
Dicha etapa consiste en la implementacioacuten de los casos de prueba de alto nivel que cumplen con las
especificaciones de disentildeo de la etapa anterior Es en esta fase donde se haraacute uso de herramientas para la
implementacioacuten y ejecucioacuten de las pruebas
Cabe destacar que para llevar a cabo dicha etapa en cuanto a la verificacioacuten y validacioacuten funcional de un
proyecto es necesario que durante la etapa de desarrollo se haya creado un producto funcional sobre el cual
puedan ejecutarse las pruebas
Durante la ejecucioacuten de las pruebas los resultados obtenidos quedaraacuten documentados en un documento
denominado ldquoRegistro de Pruebasrdquo el cual contiene todas las pruebas realizadas y un ldquoReporte de Incidenterdquo
por cada resultado no esperado que se haya detectado
Una vez sean corregidos los incidentes se debe volver a ejecutar las pruebas con la finalidad de asegurar que
dicho incidente haya sido corregido ademaacutes de asegurar que la correccioacuten realizada no haya introducido otros
defectos o errores Esto es lo que se denomina ldquoPruebas de Regresioacutenrdquo
3324 Evaluacioacuten de los criterios de eacutexito y Elaboracioacuten de reportes e informes
Tras la ejecucioacuten de las pruebas se deben evaluar los criterios de eacutexito los cuales han sido definidos en la etapa
de planificacioacuten
El personal responsable e involucrado en el proyecto se reuniraacute y revisaraacute el cumplimiento de dichos criterios
el registro de pruebas obtenido y los reportes de incidentes que hayan podido ser abiertos en la etapa anterior
Finalmente como resultado de dicha actividad se elabora un ldquoSumario final de Pruebasrdquo
3325 Cierre de la fase de pruebas
Las actividades de cierre de la fase de pruebas se centran mayormente en asegurar que todo el ciclo de vida del
proceso de pruebas se ha cumplido ademaacutes de analizar las posibles mejoras y defectos en las fases llevadas a
cabo
Ademaacutes se lleva a cabo el cierre de los incidentes corregidos y la liberacioacuten de los entornos y recursos asignados
a la fase de pruebas
51
34 Clasificacioacuten de Pruebas de Software
Existen diversos tipos de pruebas las cuales pueden ser clasificadas en funcioacuten del objetivo de prueba para lo
cual hayan sido establecidos Cada tipo de prueba persigue unos objetivos especiacuteficos sobre el producto pero
todas ellas persiguen como objetivo comuacuten ofrecer un producto con garantiacutea de calidad al cliente o usuario final
Dichas pruebas pueden ser clasificadas en cuatro tipos
Figura 18 Clasificacioacuten de Pruebas de Software
341 Pruebas Funcionales
Tambieacuten conocidas como ldquoPruebas de caja Negrardquo En [14] la IEEE define este tipo de pruebas como
ldquoPruebas que ignoran los mecanismos internos de un sistema o componente y se enfocan
solamente en las salidas generadas como respuesta a las entradas seleccionadas y a las
condiciones de ejecucioacutenrdquo
Figura 19 Pruebas de Caja Negra
Atendiendo a la definicioacuten anterior el sistema o componente sujeto a pruebas debe realizar una funcioacuten
determinada Estaraacute descrita en las especificaciones funcionales y se pueden llevar a cabo a cualquier nivel
Dichas especificaciones funcionales describen el comportamiento del sistema sin revelar informacioacuten acerca de
su implementacioacuten interna
Un tipo especial de prueba funcional son las ldquoPruebas de Humordquo o ldquoSmoke Testsrdquo Este tipo de pruebas suele
realizarse en fases tardiacuteas del desarrollo y permiten asegurar que las funcionalidades baacutesicas del software
responden adecuadamente
Por tanto dichas pruebas pueden quedar lejos de ser pruebas exhaustivas aunque siacute permiten asegurar que el
producto entregado al cliente cumple con los requisitos de funcionamiento establecidos Este tipo de pruebas
son las que se han implementado y automatizado en el proyecto presente lo cual se detallaraacute en capiacutetulos
posteriores
52
342 Pruebas No Funcionales
Este tipo de pruebas estaacuten orientadas a verificar coacutemo de bien funciona el sistema bajo pruebas en lugar de la
funcionalidad que ofrece Por ello pueden ser agrupadas tambieacuten dentro de la categoriacutea de pruebas de caja negra
Atendiendo al estaacutendar de evaluacioacuten del producto software ldquoISO 25000rdquo todas las caracteriacutesticas excepto la de
funcionalidad definen caracteriacutesticas de calidad no funcionales de un producto software Estas caracteriacutesticas de
calidad tienen su correspondiente tipo de prueba
3421 Pruebas de Rendimiento
Las pruebas de rendimiento son usadas para determinar la rapidez con la que se realiza una tarea en el sistema
bajo unas condiciones particulares de trabajo Estas pruebas tambieacuten pueden ser usadas para validar y verificar
otros atributos de calidad del sistema tales como la escalabilidad fiabilidad y uso de recursos
Figura 20 Pruebas de Rendimiento
3422 Pruebas de Carga
Este tipo de pruebas miden el rendimiento del sistema con una carga de trabajo manejable y conocida Se trata
de someter al sistema a cargas de trabajo controladas por el ingeniero de pruebas para validar prestaciones de
rendimiento sobre el sistema
Figura 21 Pruebas de Carga
3423 Pruebas de Estreacutes
Las pruebas de estreacutes ponen a prueba la robustez y confiabilidad del sistema sometieacutendolo a condiciones de uso
extremas Entre estas condiciones se incluyen el enviacuteo masivo de peticiones y la ejecucioacuten en condiciones de
hardware limitadas Dichas condiciones van maacutes allaacute de los liacutemites de operacioacuten considerados en el disentildeo
Figura 22 Pruebas de Estreacutes
53
3424 Pruebas de Usabilidad
Estas pruebas se centran en encontrar problemas de la interfaz de usuario que podriacutean hacer que el software sea
difiacutecil de utilizar o podriacutean causar que los usuarios mal interpreten las salidas Por tanto permiten medir coacutemo
de atractivo resulta un producto software basaacutendose en la facilidad de adaptacioacuten y uso por parte de los clientes
Figura 23 Pruebas de Usabilidad
3425 Pruebas de Fiabilidad
Prueban el rendimiento del sistema ante un determinado nuacutemero de operaciones o tras cierto periodo de
tiempo
3426 Pruebas de Instalacioacuten
Las pruebas de instalacioacuten tienen dos propoacutesitos El primero es asegurar que el sistema puede ser instalado
en todas las configuraciones posibles tales como nuevas instalaciones actualizaciones instalaciones
completas o personalizadas y bajo condiciones normales o anormales estas uacuteltimas incluyen insuficiente
espacio en disco falta de privilegios para algunas tareas etc
El segundo propoacutesito es verificar que una vez instalado el sistema opera correctamente Esto usualmente
implica ejecutar un nuacutemero significativo de pruebas de Funcionalidad
Por tanto miden coacutemo de sencillo resulta instalar la aplicacioacuten en distintas plataformas o entornos
3427 Pruebas de Portabilidad
Miden coacutemo de sencillo resulta migrar una aplicacioacuten de una plataforma a otra
Figura 24 Pruebas de Portabilidad
54
343 Pruebas Estructurales
Este tipo de pruebas son tambieacuten conocidas como ldquoPruebas de Caja Blancardquo En [14] la IEEE define este tipo
de pruebas como
ldquoPruebas que tienen en cuenta los mecanismos internos de un sistema o componenterdquo
Figura 25 Pruebas de Caja Blanca
Atendiendo a dicha definicioacuten estas pruebas tienen en cuenta la estructura del coacutedigo fuente del software a partir
del cual se seleccionan los diferentes casos de prueba guiaacutendose por la existencia de sentencias condicionales
bucles etc
Por tanto los casos de prueba son desarrollados usando criterios de cobertura para el coacutedigo del programa De
esta forma el sistema bajo pruebas se trata como una caja de cristal que permite ver su estructura
El criterio de cobertura hace referencia a cada miacutenima unidad de coacutedigo que puede ser probada de forma
independiente Es frecuente usar este tipo de pruebas en los niveles de prueba maacutes bajos como por ejemplo en
las ldquoPruebas Unitariasrdquo o las ldquoPruebas de Componenterdquo
344 Pruebas debidas a Cambios
Finalmente en el proceso de pruebas tras ejecutar las pruebas y encontrar un defecto o error en el sistema bajo
pruebas este se corrige pero es necesario validar la correccioacuten realizada para confirmar que el fallo no se
reproduce A este proceso se le denomina ldquoPrueba de confirmacioacuten o re-testingrdquo
Ademaacutes las correcciones pueden ser validadas pero tambieacuten es necesario asegurar que los cambios introducidos
para corregir dicho fallo no han provocado maacutes defectos Por tanto puede concluirse que es necesario volver a
realizar pruebas sobre el resto del sistema Estas son las ldquoPruebas de Regresioacutenrdquo
35 Niveles de Prueba
El proceso de pruebas es una etapa del ciclo de vida de un proyecto cuyas actividades estaacuten completamente
relacionadas con las actividades del proceso de desarrollo Existen diversos modelos que describen las fases y
actividades del proceso de desarrollo de software En esta seccioacuten se detallaraacute el uso del ldquoModelo de desarrollo
en Vrdquo
Este modelo describe las diferentes fases del proceso de desarrollo y sugiere la realizacioacuten de pruebas en cada
una de ellas Estas pruebas seraacuten ejecutadas posteriormente en orden ascendente Por tanto para cada fase existen
unos objetivos a cumplir los cuales deben ser probados para medir la integridad del trabajo realizado
55
A continuacioacuten se detallaraacuten los diferentes niveles de prueba para cada etapa del desarrollo software atendiendo
al modelo de desarrollo en V
Figura 26 Modelo de desarrollo en V
351 Pruebas a Nivel de Componente
Tambieacuten llamadas ldquoPruebas Unitariasrdquo El objetivo de estas pruebas es el de cubrir la unidad miacutenima funcional
que compone el software Estos componentes suelen tener una uacutenica funcioacuten especiacutefica la cual seraacute usada por
el resto del Sistema A menudo son realizadas por los propios desarrolladores haciendo uso de la metodologiacutea
de desarrollo guiado por prueba o Test-Driven-Development (TDD)
352 Pruebas a Nivel de Integracioacuten
Son aquellas pruebas realizadas en el aacutembito del desarrollo software una vez validadas las pruebas unitarias
Estas pruebas verifican que todos los elementos unitarios que componen el software funcionan en conjunto de
forma correcta Se centran principalmente en probar la comunicacioacuten entre los diferentes componentes del
sistema
353 Pruebas a Nivel de Aceptacioacuten
Este uacuteltimo nivel se centra en las necesidades del usuario requisitos y procesos de negocio con el fin de
determinar si el sistema satisface los criterios de aceptacioacuten acordados con el cliente en un contrato o acuerdo
de nivel de servicio en caso de ser un software de uso interno dentro de una compantildeiacutea
Ejemplos de este tipo de pruebas pueden ser las ldquoPruebas Alfa y Betardquo
Como se ha detallado anteriormente las pruebas desarrolladas y automatizadas en este Proyecto son ldquoPruebas
de humordquo o Smoke Tests Estas pruebas se centran en la verificacioacuten y validacioacuten de las especificaciones de uso
de un Sistema en este caso de la plataforma Web de gestioacuten Galgus CHT Manager
56
36 Dificultades de pruebas en aplicaciones Web e impacto
La complejidad antildeadida de las aplicaciones y servicios Web frente a otros tipos de aplicaciones recae sobre el
uso de muacuteltiples tecnologiacuteas de vanguardia que permiten la construccioacuten de sistemas distribuidos con un amplio
grado de escalabilidad accesibilidad disponibilidad interoperabilidad e independencia del hardware
Como consecuencia del incremento de la complejidad de las aplicaciones surgen nuevos paradigmas como la
Arquitectura Orientada a Servicios (SOA) la cual permite interoperabilidad y flexibilidad de las aplicaciones
distribuidas
Todo ello conlleva a plantearse queacute se deberiacutea hacer para garantizar que una aplicacioacuten Web puesta en marcha
funciona de acuerdo a los requisitos definidos y acordados con el cliente Podriacutean optimizarse y mejorarse los
diferentes procesos dentro del ciclo de vida de un proyecto pero siempre la fase de pruebas termina siendo la
fase previa a la puesta en marcha de la aplicacioacuten con lo que resulta siendo la uacuteltima oportunidad para detectar
posibles fallos que puedan terminar en ocasiones en peacuterdidas econoacutemicas de prestigio de fiabilidad y de
credibilidad por parte de los clientes
Realizar pruebas en una aplicacioacuten Web no es tarea faacutecil ya que son muchos los factores que influyen en el
testeo del sistema para abarcar y contemplar el maacuteximo de flujos posibles que se pueden llevar a cabo durante
el uso de la aplicacioacuten
Hoy en diacutea las aplicaciones Web pueden ser construidas con componentes implementados en diferentes
lenguajes y arquitecturas basaacutendose en diferentes modelos de programacioacuten y pudiendo ejecutarse en diferentes
plataformas de hardware y software
Esto incrementa la complejidad de las pruebas a realizar sobre un sistema de este tipo por lo que seriacutea interesante
plantearse la posibilidad de usar herramientas que permitan una abstraccioacuten de dicha complejidad ademaacutes de la
automatizacioacuten de la fase de pruebas En el caso de las pruebas a nivel de aceptacioacuten en este proyecto se
propondraacute el uso de herramientas que persiguen dichos fines
Figura 27 Dificultades de pruebas en aplicaciones Web e impacto
57
58
4 SISTEMA GALGUS CHT CLOUD MANAGER
ras realizar un estudio del arte sobre una teacutecnica que puede ser de gran utilidad para optimizar y
perfeccionar las teacutecnicas de automatizacioacuten para el proceso de pruebas sobre un sistema se han puesto
en contexto los diferentes tipos de pruebas que pueden realizarse sobre un sistema ademaacutes de definir
el proceso de pruebas Una vez llegados a este punto en primer lugar se realizaraacute una descripcioacuten del sistema
bajo pruebas sobre el cual se plantearaacute una solucioacuten para la fase de pruebas y su automatizacioacuten Maacutes
concretamente para la realizacioacuten de las pruebas a nivel de aceptacioacuten
41 Arquitectura y Descripcioacuten del Sistema
CHT Cloud Manager es un proyecto de la empresa Galgus el cual ofrece una plataforma Web de gestioacuten
configuracioacuten y monitorizacioacuten de redes WiFi Maacutes concretamente dicha plataforma permite gestionar un
conjunto de puntos de acceso desplegados con un conjunto de algoritmos definidos por software los cuales
permiten la optimizacioacuten de los recursos de red inalaacutembricos ofreciendo mayores prestaciones y una mayor
calidad de servicio al usuario Ademaacutes dicho software embebido ofrece otros servicios al cliente como la
localizacioacuten de estaciones dentro de la zona de alcance de la red WiFi o la deteccioacuten de intrusos y ataques de
suplantacioacuten de identidad
A este conjunto de algoritmos se le conoce bajo el nombre Cognitive Hostpot Technology (CHT) Este software
implementado en lenguaje C y preparado para sistemas embebidos como los puntos de acceso presenta una
estructura modular donde cada moacutedulo se encarga de una tarea determinada o de ejecutar un algoritmo
determinado
Figura 28 Logo de Galgus
Para permitir la comunicacioacuten con la plataforma Web CHT implementa un moacutedulo denominado MGR el cual
permite la conexioacuten con un broacuteker de eventos o intermediario para permitir el enviacuteo y la recepcioacuten de eventos
desde dicha plataforma
T
La simplicidad llevada al extremo se convierte en
elegancia
Jon Franklin
59
En la siguiente figura se muestra la arquitectura orientada a servicios para CHT Cloud Manager
Figura 29 Arquitectura de CHT Cloud Manager
Puede observarse que dicha plataforma estaacute formada por diferentes microservicios desplegados en la nube Cada
uno de ellos realiza una serie de tareas bien definidas e interactuacutean entre ellos enviando y recibiendo mensajes
haciendo uso de diferentes protocolos y modelos de comunicacioacuten
De esta forma se consigue mantener actualizado el estado de la informacioacuten de los diferentes elementos en
tiempo real sobre los diferentes eventos que puedan ocurrir en el sistema Dichos eventos proceden en su gran
mayoriacutea del conjunto de puntos de acceso que conforma una red de Galgus la cual pretende ser gestionada desde
la plataforma en cuestioacuten
A continuacioacuten se detallaraacuten los diferentes microservicios que conforman dicha plataforma ademaacutes de describir
a los puntos de acceso con la tecnologiacutea CHT como elementos a gestionar desde dicha plataforma
60
411 Puntos de Acceso (OpenWRT + CHT)
4111 OpenWRT
Los puntos de acceso WiFi de Galgus son sistemas embebidos de diferentes modelos en funcioacuten de las
especificaciones hardware que ofrezcan (nuacutemero de streams espaciales nuacutemero de antenas de exterior de
interior etc)
Todos ellos tienen en comuacuten el uso de OpenWRT como sistema operativo Este se trata de un sistema operativo
open source basado en Linux y usado para sistemas de red embebidos Todos los componentes de dicho sistema
han sido optimizados para dispositivos con limitaciones de hardware y este permite configurarlos mediante
interfaz de liacutenea de comandos o mediante una interfaz Web (LuCI) [15]
Partiendo de dicho sistema operativo Galgus desarrolla CHT como producto software que dota a los puntos de
acceso de una serie de prestaciones en una serie de moacutedulos Dicho producto es ofrecido al cliente mediante
licencias las cuales son gestionadas desde un servidor de licencias y obtenidas por los puntos de acceso de
forma automaacutetica Todo ello se detallaraacute maacutes adelante
4112 CHT
CHT tambieacuten ofrece su propia interfaz de liacutenea de comandos denominada CHT_CLI Esta herramienta permite
configurar los distintos moacutedulos de los que se compone CHT y obtener informacioacuten tanto de la configuracioacuten
como del funcionamiento de los algoritmos CHT
A continuacioacuten se presenta la interfaz y algunos de los comandos que se pueden utilizar
Figura 30 CHT_CLI
CHT_CLI es fundamental tanto en el desarrollo como en el testeo de CHT y CHT Cloud Manager ya que nos
permite acceder a paraacutemetros de configuracioacuten que no estaacuten accesibles desde la interfaz graacutefica LuCI Desde
CHT_CLI se controlan todos los moacutedulos de CHT entre los que se pueden destacar los siguientes Load Balance
(LB) Smart Roaming (SR) Power Control (POWER) Localization (LOC) Traffic Congestion Management
(TCM) Smart Band Steering (SB) y el moacutedulo Manager (MGR)
En este caso es de intereacutes resaltar el moacutedulo que permite la comunicacioacuten con la plataforma de gestioacuten CHT
Cloud Manager Dicho moacutedulo conocido bajo el nombre de MGR implementa un cliente AMQP para
establecer la comunicacioacuten con el broacuteker de eventos usado como intermediario para permitir la comunicacioacuten
entre los puntos de acceso y la plataforma de gestioacuten CHT Cloud Manager
Ademaacutes implementa una serie de estructuras de datos que son enviados a traveacutes de dicho intermediario basadas
en FlatBuffers como plataforma eficiente de serializacioacuten cruzada de datos ofrecida por Google Esta
herramienta permite crear un modelo de datos bajo la sintaxis ofrecida por FlatBuffers para posteriormente
generar dichas estructuras de datos en diferentes lenguajes de programacioacuten como por ejemplo C++ C C
Go Java JavaScript etc
Con esto se consigue generar estructuras de datos con una compatibilidad absoluta que se intercambiaraacuten entre
la plataforma de gestioacuten en lenguaje Java y los puntos de acceso en lenguaje C
61
412 Broacuteker de Eventos AMQP (RabbitMQ)
Este microservicio implementa un broacuteker de eventos que actuacutea como intermediario entre los puntos de acceso
WiFi y algunos microservicios que componen la plataforma Web de gestioacuten Se basa en el protocolo AMQP el
cual sigue el patroacuten publicadorsuscriptor como paradigma de comunicacioacuten indirecta
Estaacute involucrado en la entrega de mensajes entre los diferentes dispositivos embebidos con CHT y sus
respectivos servicios de gestioacuten en la plataforma Web de forma que los agentes que publican y consumen
eventos en el broacuteker no necesitan conocer al destinatario si no que el broacuteker es el que se encarga de publicar los
eventos para los destinatarios suscritos a eacutel En la siguiente figura se muestra la interfaz graacutefica de gestioacuten de
RabbitMQ [16]
Figura 31 Plataforma de Gestioacuten de RabbitMQ
Un broacuteker de eventos es un elemento del patroacuten PublicadorSuscriptor que recibe y mensajes de un conjunto de
elementos de red que quieren comunicarse ejecutan mecanismos de filtrado y permite la entrega correcta de los
diferentes mensajes a los consumidores correspondientes Por tanto el broacuteker de eventos permite ofrecer un
desacoplamiento entre emisores y receptores de la informacioacuten siendo este responsable de las tareas de
encaminamiento y reenvioacute de mensajes En conclusioacuten es responsable de coordinar la comunicacioacuten
proporcionando transparencia de acceso y localizacioacuten permitiendo la localizacioacuten de emisores y receptores
mediante un sistema de identificadores uacutenicos
Figura 32 Patroacuten PublicadorSuscriptor
62
413 Frontend
El Frontend de la plataforma Web estaacute implementado con Angular 6 HTML5 y CSS3 Su finalidad es ofrecer
una interfaz graacutefica al usuario final la cual permite mostrar el estado de los diferentes Zone Managers ademaacutes
de permitir el acceso a estos y gestionar el conjunto de puntos de acceso registrados en ellos de forma raacutepida e
intuitiva
Este microservicio recibe informacioacuten proporcionada por MoMap y los diferentes Zone Managers La
aplicacioacuten se sirve mediante un servidor Apache el cual proporciona una comunicacioacuten fiable con HTTPS
implementando una capa de transporte segura mediante el protocolo TLS
414 Zone Manager
Microservicio responsable de gestionar un conjunto de puntos de acceso CHT los cuales forman un despliegue
de red WiFi de Galgus para un cliente determinado Este microservicio estaacute formado por un servicio Web REST
implementado con Java Spring Framework desplegado en un servidor Jetty embebido y cuya persistencia se ha
implementado a traveacutes de Hybernate con el uso de Postgress SQL como gestor de bases de datos relacional
Un Zone Manager ofrece todas las tareas y acciones necesarias para configurar un conjunto de puntos de acceso
y consultar datos estadiacutesticos de usuarios conectados a dichos puntos de acceso entre otras Cabe destacar en
este punto la importancia que tiene el uso de FlatBuffers para garantizar la compatibilidad de datos enviados y
recibidos entre los puntos de acceso y el Zone Manager ambos implementados en tecnologiacuteas totalmente
diferentes
Figura 33 Ejemplo de Interfaz Graacutefica de un Zone Manager
63
415 MoMap
Dicho microservicio implementado en NodeJS gestiona y administra toda la infraestructura que conforma la
plataforma Web Establece y mantiene todas las conexiones y relaciones entre los diferentes puntos de acceso
con CHT y los Zone Managers (ZMB) que los gestiona
Ademaacutes este microservicio implementa una serie de maacutequinas de estado que permiten controlar el estado de
todos los Zone Managers y puntos de acceso CHT alertando sobre los eventos de error conexioacuten o desconexioacuten
en tiempo real a los usuarios finales a traveacutes del Frontend El soporte a la persistencia para dicho microservicio
se proporciona mediante MongoDB
Por tanto el microservicio MoMap actuacutea como proxy inverso HTTP2 Cuando un usuario intenta acceder a
traveacutes del Frontend de la plataforma Web puede gestionar y administrar un conjunto de Zone Managers o
administrar usuarios y asignar roles y permisos Tambieacuten se permite la creacioacuten eliminacioacuten y conexioacuten con un
Zone Manager redirigiendo las peticiones hacia el mismo
Cuando ocurre un evento de conexioacuten con un Zone Manager desde el microservicio MoMap se recupera y
enviacutea la informacioacuten necesaria para mostrar toda la informacioacuten correspondiente a ese Zone Manager en el
Frontend para el usuario final En la siguiente figura se muestra la interfaz graacutefica ofrecida por el servicio
MoMap a traveacutes del Frontend
Figura 34 Ejemplo de Interfaz Graacutefica de MoMap
64
416 Servidor de Licencias
El objetivo principal de este servicio es proporcionar una aplicacioacuten con una gestioacuten y control centralizado de
las licencias de todos los Puntos de Acceso desplegados con CHT Este servidor desplegado con Jetty de forma
embebida almacena el registro de un conjunto de Puntos de Acceso CHT para un conjunto de Clientes y
proyectos determinados Proporciona una API REST implementada con Java Spring Framework que permite
el registro de dichos dispositivos y la asignacioacuten de licencias CHT para habilitar los diferentes moacutedulos de dicha
aplicacioacuten embebida sobre los Puntos de Acceso Ademaacutes proporciona una interfaz Web de usuario
implementada con Angular 6 HTML5 y CSS3
En la siguiente figura se muestra un ejemplo de dicha interfaz graacutefica
Figura 35 Interfaz Graacutefica del Servidor de Licencias
4161 Zero-Touch Provisioning (ZTP)
En el contexto de la automatizacioacuten de redes WiFi el aprovisionamiento sin contacto es una caracteriacutestica
que permite que los puntos de acceso de una red se configuren automaacuteticamente evitando la intervencioacuten
humana para su configuracioacuten La configuracioacuten manual de dispositivos y conmutadores es costosa y
requiere lo que a menudo puede ser una gran cantidad de tiempo y esfuerzo dependiendo del tamantildeo de la
red [17]
Con el uso de sistemas automaacuteticos de aprovisionamiento y configuracioacuten se consigue reducir la carga de
trabajo y el esfuerzo que normalmente se requiere cuando se instalan y configuran nuevos dispositivos
Figura 36 Zero-Touch Provisioning (ZTP)
65
Haciendo uso de esta caracteriacutestica Galgus implementa en su infraestructura orientada a microservicios
un acceso directo de los Puntos de Acceso al servidor para que soliciten su licencia de CHT
automaacuteticamente de forma que cuando el usuario final vaya a instalar un Punto de Acceso CHT dicho
dispositivo obtendraacute su licencia de forma segura a traveacutes de la API REST del servidor de licencias siempre
y cuando esteacute registrado en el mismo y disponga de licencia sin necesidad de que el usuario intervenga en
dicho proceso
La comunicacioacuten entre los puntos de acceso y el resto de la infraestructura se realiza a traveacutes de un broacuteker
de eventos AMQP con su implementacioacuten en RabbitMQ Debido a esto cuando se crea y asigna licencia
a un dispositivo en el servidor de licencias dicho servidor crea un usuario en RabbitMQ de forma que el
punto de acceso en el momento que obtiene su licencia intentaraacute establecer conexioacuten con el broacuteker para
permitir el intercambio de eventos con los microservicios que lo gestionaraacuten mediante la plataforma CHT
Cloud Manager
Una vez el punto de acceso establece conexioacuten con el broacuteker de eventos este podraacute ser descubierto por el
Zone Manager que lo gestionaraacute El microservicio MoMap se encarga de establecer el descubrimiento de
los puntos de acceso comprobando si el punto de acceso estaacute registrado en el servidor de licencias con
licencia asignada y verificando que el punto de acceso estaacute operativo con conexioacuten a internet
42 Alcance y Objetivos de las pruebas sobre el sistema planteado
Una vez presentada y descrita toda la arquitectura de la plataforma Web ofrecida por Galgus se procederaacute a
detallar los principales objetivos del proceso de pruebas que se pretenderaacute conseguir sobre dicha aplicacioacuten Para
ello inicialmente se presentaraacute en queacute punto se encontraba el proceso de pruebas inicialmente
En este proyecto se ha centrado la atencioacuten en el conjunto de pruebas funcionales realizadas a la aplicacioacuten maacutes
concretamente las pruebas a nivel de aceptacioacuten
Dentro de las pruebas a nivel de aceptacioacuten los ingenieros de prueba hasta ahora habiacutean disentildeado un plan de
pruebas de aceptacioacuten o tests End-to-End los cuales se ejecutaban verificaban y validaban manualmente por
los ingenieros de QA Dicho plan de pruebas estaacute formado por una bateriacutea de casos de prueba a realizar sobre
las diferentes funcionalidades del sistema A continuacioacuten se muestra un fragmento de dicho plan de pruebas
Figura 37 Test Plan de CHT Cloud Manager
Como puede observarse en la figura anterior dicho plan de pruebas contiene un conjunto de casos de prueba
cada uno de ellos con un identificador uacutenico una descripcioacuten algunas especificaciones o detalles necesarios un
indicador de eacutexito o fallo y finalmente la descripcioacuten de los resultados obtenidos
Ademaacutes en dicho test plan se incluye una cabecera y una leyenda para clasificar los distintos resultados
obtenidos en la ejecucioacuten de las pruebas registrar algunos datos de relevancia y tener archivado dicho plan de
pruebas con las versiones de los diferentes microservicios que componen la plataforma Web
66
Figura 38 Leyenda del Test Plan
Figura 39 Control de Versiones del Test Plan
Una vez presentado el estado actual del proceso de pruebas a nivel de aceptacioacuten el nuevo equipo encargado de
evaluar la calidad de la plataforma Web planteoacute la oportunidad de automatizar dicho plan de pruebas Por tanto
el principal objetivo de este proyecto ha sido el de automatizar las actividades de ejecucioacuten y generacioacuten de
reportes de las pruebas de aceptacioacuten automatizadas sobre la aplicacioacuten
Sin embargo las actividades de planificacioacuten disentildeo e implementacioacuten de los diferentes casos de prueba se
realizaraacuten de forma manual haciendo uso de un conjunto de tecnologiacuteas que se usaraacuten para desarrollar la
automatizacioacuten de dichas pruebas Dichas tecnologiacuteas principalmente son Robot Framework Selenium y
Python las cuales se detallaraacuten maacutes adelante
En este punto es donde podriacutea entrar en juego la aplicacioacuten de Model-Based-Testing (MBT) detallado en la
seccioacuten 2 de este proyecto como teacutecnica que permite la abstraccioacuten de la actividad de implementacioacuten del plan
de pruebas mejorando el proceso de pruebas e independizando este de las actividades de desarrollo
En este proyecto queda fuera del alcance la aplicacioacuten de dicha teacutecnica debido a la necesidad de disponer de un
disentildeo completo y detallado de la plataforma Web para permitir la generacioacuten de los casos de prueba abstractos
y su posterior generacioacuten automaacutetica de los casos de prueba ejecutables Es de intereacutes destacar que a lo largo
del desarrollo del proyecto han ido surgiendo otros objetivos de intereacutes para mejorar el proceso de pruebas los
cuales permiten agilizar dicho proceso y ampliar su alcance
Entre estos objetivos se encuentran la generacioacuten automaacutetica de documentacioacuten del plan de pruebas la
implementacioacuten de un entorno de UAT (User Acceptance Testing) con Docker la integracioacuten de las pruebas a
nivel de aceptacioacuten en el proceso de integracioacuten continua del proyecto o la creacioacuten de un Docker que permita
ejecutar todo el plan de pruebas Todos estos objetivos se iraacuten detallando maacutes adelante
67
43 Arquitectura de la Solucioacuten Entorno de UAT para el proceso de pruebas (User Acceptance Test)
Hasta ahora dentro del proceso de desarrollo de la plataforma Web existiacutean las siguientes fases etapas o
entornos Desarrollo Preproduccioacuten y Produccioacuten
Bajo este contexto las actividades del proceso de pruebas eran realizadas sobre la fase de Preproduccioacuten Esto
provocaba una dependencia directa del cierre de la mayoriacutea de actividades de desarrollo para el despliegue en la
fase de Preproduccioacuten Como consecuencia la fase de pruebas a nivel de aceptacioacuten se podriacutea ver perjudicada
por esta metodologiacutea provocando en muchas ocasiones el retraso en el feedback necesario por los ingenieros de
desarrollo de los reportes e informes generados al ejecutar las pruebas de aceptacioacuten Para mejorar este proceso
se ha disentildeado un nuevo entorno de UAT en el proceso de desarrollo que permita disminuir la dependencia del
proceso de pruebas y desarrollo La inclusioacuten de este nuevo entorno ha sido posible gracias a la mejora del
proceso de integracioacuten continuacutea implementado en el desarrollo de la plataforma
Dentro de este proceso de integracioacuten continua se realiza la generacioacuten automaacutetica de los Docker que contienen
los diferentes microservicios de la plataforma Web en cualquier etapa del proceso de desarrollo Ademaacutes dentro
del proceso de integracioacuten continua se ha automatizado por parte de los ingenieros de desarrollo la ejecucioacuten
de pruebas unitarias y de integracioacuten que garantizan una miacutenima garantiacutea de estabilidad funcional de la
plataforma necesaria para el proceso de pruebas Partiendo de este punto el equipo de calidad ha disentildeado un
entorno de UAT con Docker el cual se muestra de forma graacutefica en la siguiente figura
Figura 40 Entorno de UAT con Docker (Anexo B)
68
69
5 TECNOLOGIacuteAS Y HERRAMIENTAS USADAS
na vez descrito el sistema bajo pruebas y presentada la arquitectura de la solucioacuten para el escenario de
pruebas con Docker se expondraacute a continuacioacuten el conjunto de tecnologiacuteas y herramientas usadas para
llevar a cabo el desarrollo de las pruebas automatizadas de aceptacioacuten o pruebas End-to-End Con este
conjunto de herramientas se pretende conseguir la implementacioacuten de los diferentes scripts de pruebas que
automaticen las acciones e interacciones necesarias con la plataforma Web CHT Cloud Manager como si de
una persona se tratase
51 Selenium
Selenium es una herramienta de coacutedigo abierto utilizada para la automatizacioacuten de pruebas en navegadores web
Dicha herramienta posee una enorme popularidad en el mundo de las pruebas de software debido a que
Presenta compatibilidad con diferentes lenguajes de programacioacuten para la implementacioacuten de scripts de
pruebas ofreciendo libreriacuteas en Java Python C PHP Ruby Perl y Net
Es multiplataforma permitiendo el lanzamiento de los scripts de pruebas en diversos sistemas
operativos como Windows Mac o Linux y en diferentes navegadores como Mozilla Firefox Internet
Explorer Google Chrome Safari y Opera
Soporta la integracioacuten con otras herramientas como TestNG o JUnit
Permite la integracioacuten continua con Maven Jenkins gitlab CICD y Docker
Sin embargo presenta una serie de inconvenientes que se deben mencionar
bull Solo permite probar aplicaciones Web
bull No hay soporte garantizado desde Selenium Muchas de las soluciones a problemas de la herramienta
han sido generadas por la comunidad
bull No es posible realizar pruebas en imaacutegenes Para ello es necesaria la integracioacuten con otras herramientas
bull No tiene capacidad nativa para generar informes o reportes de los resultados de las pruebas Para ello
se requiere el uso de un framework como puede ser el Robot Framework
Centrando la atencioacuten en el enfoque de dicho proyecto se haraacute uso de la libreriacutea Selenium para Python y la
facilidad de Robot Framework tanto para abstraer la posible complejidad antildeadida del lenguaje de programacioacuten
usado para la implementacioacuten de los scripts de prueba como para permitir la generacioacuten automaacutetica de informes
y reportes de resultados
Realmente Selenium estaacute formado por un conjunto de herramientas las cuales son Selenium RC Selenium
IDE Selenium Grid y Selenium Webdriver Dichas herramientas permiten desde la realizacioacuten de pruebas en
maacutequinas remotas a la ejecucioacuten de pruebas en diferentes maacutequinas con diferentes navegadores cada una
Con el lanzamiento de Selenium 2 en 2008 se antildeadieron nuevas funcionalidades de Selenium RC y Webdriver
en una misma herramienta aunque es frecuente mantener la nomenclatura de WebDriver a la hora de referirse
a la misma En este proyecto se centraraacute la atencioacuten en la herramienta WebDriver de Selenium
U
El disentildeo es el alma de todo lo creado por el hombre
Steve Jobs
70
52 Selenium WebDriver
Esta herramienta de Selenium ofrece una interfaz para ejecutar los casos de prueba descritos en los scripts
de prueba A traveacutes de esta API WebDriver se comunica directamente con el controlador del navegador
donde corre la aplicacioacuten Para ello seraacute necesario el uso de controladores para los diferentes navegadores
Web desde los que se validan las pruebas automaacuteticas
Todas las implementaciones de WebDriver que se comunican con el navegador usan un protocolo punto a
punto comuacuten Este protocolo define un servicio RESTfull usando JSON sobre HTTP Cada operacioacuten
realizada por WebDriver se mapea en un meacutetodo HTTP que se comunica con el navegador Las respuestas
a dichas operaciones seraacuten devueltas en mensajes HTTP de respuesta
Existen diversas implementaciones de Selenium para diferentes entornos tal y como se muestra en la
siguiente figura
Figura 41 Implementaciones disponibles de Selenium y Navegadores Web Compatibles
Para la ejecucioacuten de las pruebas implementadas en este proyecto se ha hecho uso de los controladores Gecko
Driver y Chromedriver para los navegadores Web Firefox y Google Chrome
521 Elementos del Navegador
Una vez tenemos una viacutea de comunicacioacuten con el navegador planteamos la pregunta iquesty coacutemo le indico al
navegador con queacute componente quiero interactuar
La cantidad de componentes que existen es muy amplia cajas de texto botones imaacutegenes hiperviacutenculos
botones de radio check boxes aacutereas de texto mensajes de error desplegables tablas frames etc Todos
estos elementos tienen una serie de propiedades que pueden ser uacutenicas o no en toda la paacutegina Por ejemplo
un identificador (ID) debe distinguir de manera uniacutevoca a un elemento Este identificador es lo que se
denomina un localizador Existen 8 tipos distintos de localizadores diferentes
bull Id Name Class Name Tag Name Link Text Partial Link Text CSS Xpath
71
Se podraacuten implementar las interacciones con el navegador mediante la llamada a un meacutetodo (accioacuten) que
se aplicaraacute sobre el elemento que nosotros indiquemos A continuacioacuten se muestra el diagrama de bloques
y la implementacioacuten de un ejemplo simple del inicio de sesioacuten usando Python y la libreriacutea de Selenium
Figura 42 Coacutedigo de ejemplo con Python y Selenium
La implementacioacuten anterior permite abrir un navegador Web Chrome en pantalla completa y acceder a la
plataforma Web Galgus CHT Cloud Manager Una vez ha sido posible el acceso y la paacutegina Web estaacute
disponible se realiza el inicio de sesioacuten en la plataforma con las credenciales correspondientes esperando que
dicho inicio de sesioacuten se haya realizado con eacutexito Finalmente se cierran todas las instancias de navegadores
Web abiertas por Selenium en la automatizacioacuten de dicha prueba de concepto
72
53 Robot Framework (RF)
Para la automatizacioacuten del testeo de la aplicacioacuten se ha hecho uso de este framework como herramienta
para dicha finalidad Robot Framework es un framework geneacuterico de automatizacioacuten de pruebas de coacutedigo
abierto desarrolla do por Pekka Klaumlrck en el antildeo 2005
Este framework sigue el enfoque Keyword-Driven Testing y es un candidato idoacuteneo debido a su alto nivel
de abstraccioacuten para pruebas de aceptacioacuten y desarrollo guiado por pruebas de aceptacioacuten o Acceptance
Test-Driven Development (ATDD) Las capacidades de pruebas pueden ser ampliadas con nuevas libreriacuteas
implementadas tanto en Python como en Java y los usuarios pueden crear nuevas keywords a partir de las
existentes usando la misma sintaxis que para los casos de prueba [18]
Robot Framework es independiente del sistema operativo y de la aplicacioacuten El nuacutecleo del framework estaacute
implementado en Python soportando tanto Python 2 como Python 3
Se ha decidido utilizar este framework por la disponibilidad de un amplio conjunto de libreriacuteas de propoacutesito
general y la integracioacuten con libreriacuteas externas como Selenium2Library Entre otras prestaciones permite el
uso de variables que aportan mayor flexibilidad a la hora de disentildear y controlar los scripts de prueba
permite el etiquetado para poder identificar y ejecutar los casos de prueba por separado proporciona una
faacutecil integracioacuten con Jenkins y Maven y proporciona un sistema de reporte de informes de resultados
detallados y de faacutecil lectura Ademaacutes hay que destacar la faacutecil abstraccioacuten que ofrece al poder utlizar
keywords de alto nivel permitiendo el uso del estilo de representacioacuten Given-When-Then para los casos
de prueba A continuacioacuten se describe dicho estilo de representacioacuten
531 Estilo de representacioacuten Given-When-Then
Dicho estilo ofrecido por Robot Framework es uno de los puntos fuertes de este framework Esta caracteriacutestica
permite el uso del siguiente estilo de representacioacuten para los casos de prueba
Figura 43 Estilo de representacioacuten Given-When-Then
bull Given Define las precondiciones necesarias para llevar a cabo la accioacuten asiacute como el actor de la
misma
bull When Accioacuten llevada a cabo por el actor definido en la claacuteusula Given
bull Then Es el comportamiento esperado o la salida del sistema esperada ante una entrada
determinada
bull And Claacuteusula auxiliar que se usa de forma combinada con las anteriores
73
Como ejemplo de aplicacioacuten de este estilo de representacioacuten supongamos que tenemos unos requisitos de
aceptacioacuten establecidos en un documento entre los que se encuentran el inicio y cierre de sesioacuten mediante
usuario y contrasentildea a la plataforma Galgus CHT Cloud Manager En la siguiente tabla se muestran los
criterios de aceptacioacuten definidos en el documento de requisitos para dicha funcionalidad
1 Un usuario no identificado puede iniciar sesioacuten desde la vista principal de la plataforma Web
2 Un usuario no identificado debe insertar un usuario y contrasentildea vaacutelidos para el inicio de sesioacuten
A continuacioacuten se muestra coacutemo se llevariacutea a cabo la implementacioacuten de los scripts de pruebas abstractos
asociados a las especificaciones anteriores haciendo uso del estilo de representacioacuten Given-When-Then
Es complicado implementar todos los casos de prueba posibles principalmente cuando el requisito de
aceptacioacuten requiere de una funcionalidad compleja En este caso se muestran tres casos de prueba
abstractos los cuales han sido implementados en el proyecto para validar el inicio y cierre de sesioacuten
Caso de Prueba 1 Inicio de Sesioacuten en Galgus CHT Cloud Manager
Claacuteusula Keyword
Given Navegacioacuten a la paacutegina principal de Galgus CHT Cloud Manager
When Insertar nombre de usuario vaacutelido
And Insertar contrasentildea vaacutelida
Then Iniciar sesioacuten con eacutexito
Caso de Prueba 2 Intento de Inicio de sesioacuten con usuario no vaacutelido
Claacuteusula Keyword
Given Navegacioacuten a la paacutegina principal de Galgus CHT Cloud Manager
When Insertar nombre de usuario invaacutelido
And Insertar contrasentildea vaacutelida
Then No es posible el inicio de sesioacuten Se muestra mensaje de error
Caso de Prueba 3 Intento de Inicio de sesioacuten con contrasentildea no vaacutelida
Claacuteusula Keyword
Given Navegacioacuten a la paacutegina principal de Galgus CHT Cloud Manager
When Insertar nombre de usuario vaacutelido
And Insertar contrasentildea invaacutelida
Then No es posible el inicio de sesioacuten Se muestra mensaje de error
74
En la siguiente figura se muestra la implementacioacuten de dichas pruebas con Robot Framework donde cada
Keyword implementada permite la abstraccioacuten de toda la funcionalidad necesaria para realizar las pruebas
Figura 44 Implementacioacuten de Pruebas en para el inicio de sesioacuten de CHT Cloud Manager
75
532 Reportes
A continuacioacuten se muestra un ejemplo de los reportes obtenidos tras la ejecucioacuten del primer caso de prueba de
los anteriores donde pueden identificarse las diversas keywords necesarias para implementar cada caso de
prueba asiacute como otras adicionales que ayudan a crear el contexto (precondiciones) Tambieacuten se incluyen
estadiacutesticas sobre el tiempo de ejecucioacuten nuacutemero de tests total nuacutemero de tests que han fallado o que han pasado
con eacutexito [18]
Figura 45 Ejemplo de reporte de pruebas automatizadas con Robot Framework
76
533 Libreriacuteas
Robot Framework permite el uso de Selenium mediante la libreriacutea de pruebas Web SeleniumLibrary Dicha
libreriacutea es compatible con las versiones de Selenium 2536 y sucesivas y con Python 27 y Python 3 Ademaacutes
del inteacuterprete por defecto de Python esta libreriacutea funciona tambieacuten con PyPy y Jython [18]
Esta libreriacutea estaacute compuesta entre otras muchas por una serie de archivos de Python (py) que implementan
las clases que contienen las diversas keywords que pueden ser usadas en nuestro framework La estructura de
estos archivos se presenta en la siguiente tabla
Archivo de Clase Funcioacuten
Alertpy Interacciones con mensajes de alerta
Browsermanagementpy Apertura cierre y cambio de navegadores
Cookiepy Manipulacioacuten de cookies del navegador
Elementpy Interaccioacuten con elementos y sus atributos
Formelementpy Interaccioacuten con elementos en formularios
Framespy Manejo de frames y su contenido
Javascriptpy Facilidades para inyectar coacutedigo javascript
Runonfailurepy Uso de funcionalidades en caso de fallo
Screenshotpy Manejo de capturas de pantalla
Selectelementpy Manejo de elementos en listas
Tableelementpy Manejo de elementos en tablas
Waitingpy Manejo de temporizadores de espera para
transiciones en una paacutegina
Webdrivertoolspy Interaccioacuten directa con el controlador del navegador
Windowpy Manejo de ventanas del navegador
Estas libreriacuteas fueron desarrolladas en sus oriacutegenes por el ingeniero finlandeacutes Tatu Aalto y posteriormente
mejoradas por toda la comunidad de expertos en automatizacioacuten de pruebas Sin embargo Robot Framework
mediante el uso de Python con Selenium permite la implementacioacuten de libreriacuteas propias o funcionalidades
desarrolladas en Python que pueden ser integradas en Robot Framework En este proyecto se hace uso de Python
con Selenium para desarrollar algunas funcionalidades avanzadas que permiten probar ciertos criterios de la
aplicacioacuten muy especiacuteficos y avanzados de la plataforma Web para los cuales las libreriacuteas ofrecidas por Robot
Framework no proporcionan la funcionalidad requerida
Ademaacutes se ha hecho uso de otras libreriacuteas como BuiltIn para el uso de bucles condicionales y otras keywords
String y Collections para el tratamiento de cadenas de caracteres y colecciones de datos SSHLibrary para usar
un cliente ssh Process para la ejecucioacuten de subprocesos haciendo uso la libreriacutea subprocess de python y
OperatingSystem para realizar algunas tareas sobre el sistema operativo
77
534 Documentacioacuten
La documentacioacuten de los diferentes casos de pruebas implementados con Robot Framework es muy redundante
y una tarea la cual seriacutea deseable de poder automatizar Dicho framework ofrece esta posibilidad a traveacutes de dos
herramientas para crear documentacioacuten basada en las pruebas y libreriacuteas implementadas para dichas pruebas
Libdoc y Testdoc [18]
5341 Libdoc
Libdoc es una herramienta ofrecida por Robot Framework para construir documentacioacuten sobre las keywords
implementadas para los casos de prueba Dicha documentacioacuten es generada en formato HTML y XML
Se puede crear documentacioacuten para bibliotecas implementadas con Python o Java y para las propias libreriacuteas
implementadas con Robot Framework A continuacioacuten se muestra un ejemplo de la documentacioacuten generada
para la libreriacutea implementada para los casos de prueba de inicio y cierre de sesioacuten de Galgus CHT Cloud
Manager
Figura 46 Ejemplo de documentacioacuten generada con Libdoc
5342 Testdoc
Testdoc es una herramienta para generar documentacioacuten de alto nivel basada en los casos de prueba de Robot
Framework Dicha documentacioacuten es generada en formato HTML e incluye el nombre la documentacioacuten y
otros metadatos de cada conjunto de pruebas y casos de prueba asiacute como las keywords de alto nivel y sus
argumentos
A continuacioacuten se muestra un ejemplo de la documentacioacuten generada para el conjunto de casos de prueba que
validan el inicio y cierre de sesioacuten de Galgus CHT Cloud Manager
Figura 47 Ejemplo de documentacioacuten generada con Testdoc
78
54 Pycharm (IDE)
Esta herramienta proporciona un entorno de desarrollo integrado (IDE) el cual ha sido usado para programar en
lenguaje Python por lo que es idoacuteneo tambieacuten para el desarrollo de pruebas con Robot Framework Esta
desarrollado por la empresa JetBrains Ademaacutes proporciona entre otras muchas herramientas el anaacutelisis de
coacutedigo un depurador graacutefico integracioacuten con sistemas de control de versiones y es multiplataforma
55 GitGitlab
551 Git
Git es un software de control de versiones disentildeado por Linux Torvalds pensando en la eficiencia y la
confiabilidad del mantenimiento de versiones de aplicaciones cuando eacutestas tienen un gran nuacutemero de archivos
de coacutedigo fuente Al principio Git se pensoacute como un motor de bajo nivel sobre el cual otros pudieran escribir la
interfaz de usuario como Cogito o StGIT Sin embargo Git se ha convertido desde entonces en un sistema de
control de versiones con funcionalidad plena Hay algunos proyectos de mucha relevancia que ya usan Git en
particular el grupo de programacioacuten del nuacutecleo Linux Ademaacutes cabe destacar que se ha hecho uso de
GitKraken como interfaz graacutefica de git para llevar a cabo el control de versiones de una forma maacutes intuitiva
552 Gitlab
Gitlab es un servicio Web de control de versiones y desarrollo de software colaborativo basado en Git Fue
implementado por los desarrolladores ucranianos Dimitry Zaporozhets y Valey Sizov en el lenguaje de
programacioacuten Ruby Este proyecto cuenta con un equipo de 150 miembros y maacutes de 1400 usuarios y es usado
por empresas como la NASA el CERN IBM o Sony [19]
Ademaacutes de gestor de repositorios tambieacuten ofrece la posibilidad de alojar documentacioacuten y un sistema de
seguimiento de errores Tambieacuten es de gran importancia destacar que esta herramienta proporciona su propia
herramienta de Integracioacuten Continua sin necesidad de usar otra herramienta externa
Se ha hecho uso de estas herramientas para tener un control de versiones sobre nuestro proyecto y una gestioacuten
centralizada de todos los repositorios de la empresa de forma que asiacute podemos tener un control de versiones de
todos los cambios realizados en el coacutedigo con posibilidad de contrastarlos con versiones anteriores y recuperar
dichos cambios Ademaacutes se hace uso tambieacuten de gitlab CICD para implementar procesos de Integracioacuten
continua sobre los diferentes proyectos En el caso particular de este proyecto para generar la documentacioacuten
de los casos de test y libreriacuteas y para generar un Docker con toda la bateriacutea de pruebas y dependencias necesarias
para lanzarlas
56 Redmine
Redmine es una herramienta para la gestioacuten de proyectos que ofrece un conjunto de funcionalidades que
permiten a los usuarios de diferentes proyectos realizar el seguimiento y organizacioacuten de los mismos Incluye
un sistema de seguimiento de incidentes Otras herramientas que incluye son un calendario de actividades
diagramas de Gantt una wiki para almacenar documentacioacuten control del flujo de trabajo basado en roles
integracioacuten con correo electroacutenico etc
Esta herramienta se usa para la gestioacuten del proyecto Galgus CHT Cloud Manager donde se integra como
subproyecto la automatizacioacuten del proceso de pruebas para la plataforma Web desarrollada
A continuacioacuten se muestra un ejemplo del flujo de trabajo implantado en la metodologiacutea de trabajo dentro del
proyecto donde cada historia puede contener un conjunto de tareas las cuales pueden pasar por diferentes
estados hasta ser completadas por el desarrollador o el ingeniero de pruebas
79
Figura 48 Ejemplo de Flujo de Trabajo en Redmine para Galgus CHT Cloud Manager
561 Uso en el Proyecto Galgus CHT Cloud Manager (Metodologiacutea Scrum)
Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas praacutecticas para trabajar
colaborativamente en equipo y obtener el mejor resultado posible de un proyecto Estas praacutecticas se apoyan
unas a otras y su seleccioacuten tiene origen en un estudio de la manera de trabajar de equipos altamente productivos
Esta metodologiacutea divide el trabajo en una lista de pequentildeas funcionalidades ordenadas por prioridad y estimadas
en esfuerzo Estas pequentildeas tareas son abordadas en iteraciones cortas de longitud fija denominadas Sprints de
1 a 4 semanas (en este caso se ha optado por iteraciones de 3 o 4 semanas) obteniendo coacutedigo potencialmente
entregable siendo demostrado al final de cada iteracioacuten Una vez decidido por el equipo de gestioacuten de proyectos
el alcance y conjunto de actividades a realizar dentro del sprint se transmite al resto del equipo que forma parte
del proyecto procediendo a la asignacioacuten de tareas mediante Redmine como herramienta de gestioacuten usada
Durante el sprint se va realizando un seguimiento perioacutedico del estado del proyecto y de la situacioacuten de cada
integrante mediante una actividad previa diaria de unos 15 minutos para situar el punto de partida de trabajo
diario que seriacutean reuniones diarias de apenas 15 minutos denominadas ldquoDaylisrdquo
Figura 49 Esquema Graacutefico de Metodologiacutea Scrum
80
La planificacioacuten que se pretende seguir en cada sprint es la siguiente
1 Semana 1 y 2 Realizacioacuten de tareas por parte del equipo de desarrollo incluyendo en estas tareas
nuevos desarrollos modificacioacuten de funcionalidades y verificacioacuten de las mismas mediante pruebas
unitarias y de integracioacuten
2 Semana 3 Realizacioacuten de pruebas de aceptacioacuten manuales por parte del equipo de pruebas y posterior
automatizacioacuten de dichas pruebas Para ello se usaraacute el entorno de UAT como escenario de pruebas
Ademaacutes el equipo de desarrollo iraacute corrigiendo todos aquellos errores o defectos encontrados
3 Semana 4 El jefe de proyecto realiza la fusioacuten de todos los desarrollos y actualiza las versiones en el
entorno de Preproduccioacuten incluyendo todas las actividades realizadas y validadas por el equipo de
desarrollo y de pruebas El equipo de pruebas realizaraacute la ejecucioacuten de todas las pruebas End-to-End
sobre el entorno de Preproduccioacuten para verificar y validar la nueva versioacuten que incluye todas las
funcionalidades Estas pruebas son denominadas pruebas de regresioacuten las cuales verifican que los
nuevos desarrollos no han provocado defectos o errores sobre funcionalidades que hasta ahora habiacutean
funcionado correctamente Finalmente el jefe de proyecto realiza el despliegue en produccioacuten
81
82
6 EXPERIMENTOS
na vez descrito el sistema bajo pruebas el proceso de pruebas y las herramientas que se usaraacuten para
automatizar las pruebas de aceptacioacuten sobre la plataforma de gestioacuten Galgus CHT Cloud Manager
solo queda presentar la forma en la que se ha puesto en praacutectica y el proceso seguido paso a paso
Dado que el objetivo es conseguir una bateriacutea de casos de pruebas End-to-End automatizadas se implementaraacuten
dichos casos de prueba de forma que permitan detectar el incorrecto funcionamiento de cada funcionalidad con
la mayor rapidez posible cubriendo los principales escenarios donde puedan surgir los mayores errores Por
tanto dichos casos de prueba seraacuten elegidos en base al riesgo que puedan introducir
Estos casos de prueba seraacuten definidos mediante un conjunto de criterios de aceptacioacuten descritos a traveacutes de
diagramas de flujo y agrupados seguacuten la funcionalidad de la aplicacioacuten que abarquen las cuales son
1 Vista de Gestioacuten Principal (Coud Tab) Esta seccioacuten de la Web estaacute destinada a la administracioacuten de
usuarios administracioacuten de los diferentes Zone Managers y finalmente incluye un Mapa con la
ubicacioacuten de cada Zone Manager
2 Vista de Configuracioacuten (Configuration Tab) En esta pestantildea se ofrece la gestioacuten de grupos de puntos
de acceso gestioacuten de backups y restauracioacuten gestioacuten de firmwares zonas CHT etc
3 Vista de Red (Network Tab) La pestantildea de red engloba toda la configuracioacuten de red de los puntos de
acceso siendo esta la pestantildea con mayor funcionalidad complejidad y por ello potencial de riesgo de
errores de la plataforma Web
Figura 50 Logo de Galgus CHT Cloud Manager
U
La uacutenica parte donde el ldquoeacutexitordquo aparece antes que el trabajo es en el diccionario
Vidal Sasoon
83
61 Estructura del Proyecto
La clasificacioacuten funcional anterior seraacute tomada de la misma forma para organizar la estructura del proyecto de
pruebas automatizadas con Robot Framework para un desarrollo ordenado y loacutegico de todo el conjunto de casos
de prueba A continuacioacuten se muestra un ejemplo de la estructura del proyecto el cual se encuentra en desarrollo
y continua mejora
Figura 51 Estructura del Proyecto
Para una mayor modularidad y limpieza en el desarrollo de los casos de Test se han centralizado todos los
localizadores en un archivo llamado ldquoSelectorpyrdquo En la siguiente figura se muestra un fragmento de dicho
fichero
Figura 52 Fragmento del fichero ldquoSelectorpyrdquo
A la hora de obtener los localizadores de los elementos que seraacuten comprobados o usados en los scripts de pruebas
se han usado las herramientas de desarrollador que incluye Google Chrome Para ello basta con navegar a la
paacutegina de la plataforma Web en cualquier navegador y pulsar la tecla F12 Esto mostraraacute las herramientas de
desarrolladores donde encontramos una pestantildea llamada ldquoElementosrdquo donde se puede inspeccionar el
documento ldquoHTMLrdquo de la paacutegina Una vez abierta dicha herramienta seraacute sencillo obtener propiedades de los
diversos elementos que nos permitiraacuten hacer referencia a los mismos en nuestro script de pruebas
Los ldquoXpathrdquo absolutos seraacuten lo usados praacutecticamente en toda la Suite de pruebas El beneficio de los
identificadores uacutenicos es que permiten seleccionar elementos sin que sea necesario hacer referencia a su posicioacuten
dentro del documento HTML Esto evita cualquier problema en caso de que las rutas de un elemento dentro del
citado documento cambien debido a mejoras o despistes por parte de los desarrolladores En cambio usar
selectores basados en la ruta del elemento dentro del documento HTML puede propiciar falsos fallos en el
escenario anterior debido a que no puedan encontrarse en la Web a pesar de que realmente sigan estando
presentes y totalmente funcionales
Por otro lado se han agrupado todas aquellas ldquokeywordsrdquo que puedan ser usadas por otras secciones en la
implementacioacuten de los casos de prueba mediante ficheros nombrados como ldquotab_common_keywords robotrdquo
84
Siguiendo esta jerarquiacutea se ha incluido un fichero llamado ldquoCommon_Keywordsrobotrdquo general en el que se
incluyen las principales ldquokeywordsrdquo que pueden ser usadas en todo el proyecto A continuacioacuten se muestra un
fragmento de este fichero
Figura 53 Fragmento del fichero ldquoCommon_Keywordsrobotrdquo
Tambieacuten se incluye el fichero ldquoConfigurationrobotrdquo para agrupar definiciones de variables que seraacuten
usadas en todo el proyecto ademaacutes de realizar la inclusioacuten de las libreriacuteas a usar Se muestra otra figura
con un fragmento del fichero ldquoConfigurationrobotrdquo
Figura 54 Fragmento del fichero de Configuracioacuten de pruebas ldquoConfigurationrobotrdquo
85
A continuacioacuten se muestra un diagrama que muestra las dependencias de los diferentes archivos y la estructura
seguida por el proyecto
Figura 55 Diagrama de paquetes del proyecto de pruebas
Tras introducir la estructura del proyecto y las diferentes funcionalidades de la plataforma Web Galgus CHT
Cloud Manager a continuacioacuten se mostraraacuten algunos criterios de aceptacioacuten de cada funcionalidad a probar
con diagramas de flujo y scripts de pruebas haciendo uso del estilo de representacioacuten Given-When-Then
Ademaacutes se mostraraacuten algunos detalles de implementacioacuten sobre las pruebas Por otro lado la ejecucioacuten de los
casos de prueba de ejemplo y el reporterevisioacuten de resultados se incluiraacute en la seccioacuten de Anexos
Cada una de las siguientes subsecciones dentro de cada funcionalidad principal de la aplicacioacuten o vista principal
tendraacute su correspondiente Suite de pruebas con un conjunto de casos de Test Todas estas Suites seguiraacuten la
siguiente estructura comuacuten para los casos de Test
Figura 56 Estructura de una Suite de Pruebas
86
Todas las Suites comienzan con una seccioacuten de documentacioacuten para describir el contenido de las pruebas de forma geneacuterica y varias secciones para importar los recursos necesarios para las pruebas (Resource)
Las secciones ldquoSuite Setuprdquo y ldquoSuite Teardownrdquo permiten la ejecucioacuten automaacutetica antes y despueacutes de la bateriacutea de pruebas y las secciones ldquoTest Setuprdquo y ldquoTest Teardownrdquo permiten la ejecucioacuten automaacutetica antes y despueacutes de cada caso de prueba
Un uso tiacutepico de ldquoSuite Setuprdquo es abrir un navegador Web y comprobar la disponibilidad de la Web a probar mientras que el cierre del navegador se realiza con ldquoSuite Teardownrdquo De este modo sea cual sea el resultado de la ejecucioacuten no se quedaraacuten abiertas ventanas gastando recursos de la maacutequina
Por otro lado el uso por defecto de ldquoTest Setuprdquo en este proyecto ha sido el inicio de sesioacuten en la Web CHT Cloud Manager mientras que ldquoTest Teardownrdquo ha sido usado para cerrar tambieacuten el navegador Web Sin embargo la mayoriacutea de las pruebas implementadas necesitan una serie de precondiciones previas a la ejecucioacuten del Test y un conjunto de postcondiciones necesarias para no provocar inconsistencias entre la ejecucioacuten de diferentes pruebas Por este motivo se ha hecho uso de las etiquetas [Setup] y [Teardown] para modificar la ejecucioacuten por defecto de ldquoTest Setuprdquo y ldquoTest Teardownrdquo en cada caso de prueba cuando sea necesario
Cabe destacar que la loacutegica implementada dentro de estas claacuteusulas no requiere que sea validada puesto que su uacutenico objetivo es preparar el entorno de pruebas para ejecutar una prueba sin que esta falle por causas ajenas al aacutembito y objetivo de la prueba evitando de esta forma los falsos positivos Por este motivo se hace uso de la Keyword ldquoRun Keyword And Ignore Errorrdquo ofrecida por la libreriacutea ldquoBuiltInrdquo para ignorar los errores en la ejecucioacuten de [Setup] y [Teardown] En la siguiente figura se muestra un ejemplo de dicha teacutecnica
Figura 57 Ejemplo de ldquoTest Setuprdquo personalizado para un caso de prueba
Finalmente la implementacioacuten de las ldquokeywordsrdquo usadas mediante la nomenclatura Given-When-Then seraacuten agrupadas en el correspondiente fichero ldquoTab_common_keywordsrobotrdquo para conseguir una abstraccioacuten de la loacutegica necesaria para la automatizacioacuten de las pruebas En las pruebas seleccionadas para describir en esta seccioacuten se detallaraacute la implementacioacuten de algunas keywords que se usaraacuten
87
62 Vista de Gestioacuten Principal (Cloud Tab)
En la siguiente figura se muestra la vista de Gestioacuten Principal de Galgus CHT Cloud Manager
Figura 58 Vista de Gestioacuten Principal (Cloud Tab)
Sobre esta vista se han automatizado un conjunto de Suites de pruebas que validan toda la funcionalidad
contenida en las pestantildeas MAP List of Zone Managers y Administration ademaacutes de toda la loacutegica ofrecida para
gestionar un conjunto de fabricantes
621 Administration
Comenzando con la pestantildea de administracioacuten se puede observar la existencia de cuatro flujos de navegacioacuten
principales en la siguiente figura
Figura 59 Pestantildea ldquoAdministrationrdquo
Una vez conocida la vista de administracioacuten de la Web se han realizado un total de 22 casos de prueba de los
cuales detallaremos el caso de prueba identificado con la etiqueta U0027
6211 Criterios de Aceptacioacuten
La pestantildea de administracioacuten permite la gestioacuten de los usuarios y roles que tienen acceso a la plataforma Web
ademaacutes de la configuracioacuten de los detalles de los fabricantes seleccionados A continuacioacuten se detallan los
criterios de aceptacioacuten del caso de prueba seleccionado
U0027 Un usuario con permisos de Super Usuario puede editar la informacioacuten de un fabricante
1 Un usuario con permisos de Super Usuario puede ver y acceder a la pestantildea de administracioacuten
2 Un usuario con permisos de Super Usuario puede editar la informacioacuten de un fabricante correctamente
88
6212 Diagramas de Flujo
A continuacioacuten se muestran los diagramas de flujo implementados para los dos casos de prueba analizados
Figura 60 Diagramas de Flujo de Casos de Prueba U0025 y U0027
6213 Script de Pruebas
Una vez establecidos los criterios de aceptacioacuten de ambos casos de prueba se mostraraacuten los scripts de pruebas
realizados
Figura 61 Script de Pruebas U0025
Entre las ldquokeywordsrdquo usadas en el caso de test anterior se puede destacar por ejemplo la implementacioacuten de
ldquoEdit Fieldsrdquo la cual permite editar los campos de un fabricante y verificar que han sido editados tras guardar
los cambios
Figura 62 Keyword ldquoEdit Fieldsrdquo
89
622 List
En la pestantildea de gestioacuten de los diferentes Zone Managers se puede observar una lista de los diferentes Zone
Managers disponibles y se pueden realizar un conjunto de acciones como la creacioacuten de nuevos Zone Managers
y edicioacuten o eliminacioacuten de los existentes entre otras
Figura 63 Pestantildea ldquoList of Zone Managersrdquo
Sobre esta vista se han realizado un total de 7 casos de prueba de los cuales detallaremos el caso de prueba
identificado con la etiqueta U0023 el cual permite validar la creacioacuten y eliminacioacuten de un Zone Manager
6221 Criterios de Aceptacioacuten
A continuacioacuten se detallan los criterios de aceptacioacuten del caso de prueba seleccionado
U0023 Verificar que un Usuario puede Crear y Eliminar un Zone Manager
1 Un usuario con permisos de Super Usuario puede Navegar a la pestantildea List Of Zone Managers
2 El usuario puede crear un Zone Manager correctamente
3 El usuario puede eliminar un Zone Manager correctamente
6222 Diagramas de Flujo
A continuacioacuten se muestra el diagrama de flujo implementado para el caso de prueba analizado
Figura 64 Diagrama de flujo de Caso de Prueba U0023
90
6223 Script de Pruebas
Una vez establecidos los criterios de aceptacioacuten se mostraraacute el script de pruebas realizado a partir del diagrama
de flujo anterior
Figura 65 Script de Prueba U0023
Cabe destacar la implementacioacuten de la Keyword ldquoZone Manager is Registered Successfullyrdquo la cual comprueba
que el Zone Manager registrado pasa a un estado ldquoOnlinerdquo tras un tiempo considerado como aceptable para que
la instancia de dicho Zone Manager este disponible en Cloud CHT Manager
Figura 66 Keyword ldquoZone Manager is registered successfullyrdquo
623 Manufacturer
La vista de gestioacuten principal ofrece una seccioacuten que permite la gestioacuten de los diferentes fabricantes permitiendo
su creacioacuten edicioacuten eliminacioacuten y bloqueo En la siguiente figura se muestra un ejemplo de la seccioacuten de
fabricantes
Figura 67 Seccioacuten de Fabricantes
Para validar el correcto funcionamiento de dicha seccioacuten se han realizado un total de 9 casos de prueba de los
cuales se detallaraacuten los casos de prueba identificados con las etiquetas U0009 Estos permiten validar que los
fabricantes pueden ser creados editados y eliminados correctamente y que todos los fabricantes disponibles son
mostrados correctamente
91
6231 Criterios de Aceptacioacuten
A continuacioacuten se detallan los criterios de aceptacioacuten de los casos de prueba seleccionados
U0009 Verificar que un Usuario con permisos de Super usuario puede ver correctamente todos los
fabricantes existentes
1 Un usuario con permisos de Super Usuario puede Navegar a la pestantildea de Administracioacuten
2 El usuario puede visualizar todos los fabricantes existentes
6232 Diagrama de Flujo
Figura 68 Diagrama de flujo de Caso de Prueba U0009
6233 Script de Pruebas
Una vez establecidos los criterios de aceptacioacuten se mostraraacuten los scripts de pruebas realizados a partir de los
diagramas de flujo anteriores
Figura 69 Script de Prueba U0009
En este punto cabe destacar la finalidad de la Keyword ldquoCorrectly Createrdquo la cual se usa en la mayoriacutea de las
pruebas para verificar que una operacioacuten se ha realizado con eacutexito en la plataforma Galgus CHT Cloud Manager
Esta Keyword verifica que tras realizar alguacuten tipo de operacioacuten en la plataforma Web ocurre un evento sobre la
Web que indica que dicha operacioacuten se ha realizado con eacutexito de la siguiente forma
92
Figura 70 Toast Success
Figura 71 Keyword ldquoCorrectly Createrdquo
Finalmente se muestra la implementacioacuten de las keywords usadas en [Setup] y [Teardown] del caso de prueba
U0009 las cuales preparan el escenario de pruebas creando un conjunto de fabricantes acotado y los elimina
tras la finalizacioacuten de la prueba
Figura 72 Setup amp Teardown de U0008
624 MAP
La plataforma Galgus CHT Cloud Manager ofrece una pestantildea ldquoMAPrdquo que contiene un mapa con la ubicacioacuten
asignada a cada uno de los Zone Managers disponibles por el usuario mostrando en su ubicacioacuten un icono con
el estado de dicho Zone Manager el cual cambia de color seguacuten su estado (offline online unsynchronized)
Figura 73 Mapa de Zone Managers
93
A traveacutes de dicho icono se puede realizar una serie de acciones entre ellas acceder a un Zone Manager
realizando doble click sobre el icono del mismo Sin embargo para automatizar este conjunto de acciones el
equipo de pruebas ha encontrado dificultades haciendo uso de Robot Framework ya que las libreriacuteas disponibles
permiten la interaccioacuten con elementos de la Web pero en este caso los iconos de los diferentes Zone Managers
son renderizados dentro del Mapa con ldquoOpen Street Mapsrdquo antes de ser mostrado en la vista Web de la
aplicacioacuten Por esta razoacuten el mapa es localizado en el DOM como un uacutenico elemento Web lo que imposibilita
localizar a priori el icono de cada Zone Manager dentro del Mapa
Para resolver este impedimento el equipo de pruebas tuvo que analizar con profundidad la libreriacutea de ldquoOpen
Street Maprdquo implementada en Javascript Esta ha sido usada en el Frontend para encontrar alguna funcioacuten que
permitiese obtener desde la consola del navegador Web los piacutexeles en los que cada Zone Manager ha sido
renderizado dentro del Mapa Dicha funcioacuten es ldquogetPixelsFromCoordinate(coordinate)rdquo la cual a traveacutes de las
coordenadas de [Latitud Longitud] de cada Zone Manager se obtienen los piacutexeles del mismo en la pantalla A
traveacutes del siguiente fragmento de coacutedigo en el frontend implementado con Angular 6 en typescript se consigue
obtener los piacutexeles de cada Zone Manager e imprimirlo en la consola del navegador Web
Figura 74 Funcioacuten que dibuja los ZM en el Mapa y obtiene los piacutexeles en pantalla
Para llevar a cabo la implementacioacuten de las pruebas sobre el mapa se ha hecho uso en su gran mayoriacutea de Scripts
con Python Selenium y otras libreriacuteas necesarias en lugar de Robot Framework debido a la necesidad de
realizar varias tareas simultaneas ademaacutes de tratarse de pruebas muy especiacuteficas y personalizadas A
continuacioacuten se muestra la prueba implementada para poder realizar doble click sobre un Zone manager en el
mapa e iniciar sesioacuten en el mismo (U0007)
6241 Criterios de Aceptacioacuten
U0007 Verificar que un Usuario acceder a un Zone Manager desde el Mapa
1 Un usuario con permisos de Super Usuario puede Navegar a la pestantildea MAP
2 El usuario puede hacer doble click en el Zone Manager e iniciar sesioacuten
94
6242 Diagrama de Flujo
Figura 75 Diagrama de Flujo de Caso de Prueba U0007
6243 Script de Pruebas
Para la implementacioacuten de este tipo de casos de prueba se ha hecho uso de la libreriacutea ldquoHtmlTestRunnerrdquo para
obtener un reporte similar al ofrecido por Robot Framework en la ejecucioacuten de la prueba Para obtener un reporte
de la prueba la implementacioacuten de la misma debe seguir una estructura determinada a la que ademaacutes se ha
incluido a traveacutes de la libreriacutea ldquomultiprocessingrdquo la ejecucioacuten simultaacutenea de los dos procesos descritos en el
diagrama de flujo anterior Es necesaria la ejecucioacuten de varios procesos para leer la consola del navegador Web
y obtener los piacutexeles de los Zone Manager para posteriormente hacer doble click
En la Seccioacuten A3 de los anexos puede encontrarse la implementacioacuten del script de pruebas para el caso de
prueba U0007
95
63 Vista de Configuracioacuten (Configuration Tab)
En esta vista se ha automatizado un conjunto de Suites de prueba que validan toda la funcionalidad contenida
en las pestantildeas Groups CHT Zones BackupRestore y Firmware
631 Groups
La pestantildea de grupos permite el descubrimiento de los puntos de acceso a traveacutes de su direccioacuten MAC quedando
estos registrados en base de datos y mostrando al usuario en una tabla los puntos de acceso registrados ademaacutes
del estado de los mismos y otros datos como el modelo o grupo al que pertenecen
Figura 76 Pestantildea ldquoGroupsrdquo
Sobre esta funcionalidad de la plataforma se han realizado un total de 19 casos de prueba de los cuales
detallaremos el caso de prueba identificado con la etiqueta U0119
6311 Criterios de Aceptacioacuten
U0119 Verificar que al descubrir dos puntos de acceso en grupos diferentes ambos son antildeadidos en el
grupo correcto
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Configuracioacuten
3 El usuario puede Navegar a la pestantildea de Grupos
4 El usuario puede descubrir un punto de acceso en el grupo ldquorootrdquo correctamente
5 El usuario puede crear un subgrupo predecesor del grupo ldquorootrdquo correctamente
6 El usuario puede navegar al subgrupo creado correctamente
7 El usuario puede descubrir un punto de acceso en el subgrupo correctamente
96
6312 Diagramas de Flujo
Figura 77 Diagrama de flujo de Caso de Prueba U0119
97
6313 Script de Pruebas
Una vez establecidos los criterios de aceptacioacuten el script de prueba realizado a partir del diagrama de flujo
anterior es el siguiente
Figura 78 Script de Prueba U0119
Entre las keywords implementadas para esta prueba cabe destacar la implementacioacuten de ldquoVerify if AP is
registered Succesfully on grouprdquo la cual permite validar si un punto de acceso ha sido asignado al grupo
correcto
Figura 79 Keyword ldquoVerify if AP is registered Succesfully on grouprdquo
Puede observarse como en primer lugar se obtiene la fila de la tabla que contiene el punto de acceso en cuestioacuten
para posteriormente comprobar si el grupo al que pertenece es el esperado
Observando dicha implementacioacuten cabe destacar el uso de la Keyword ldquoInput Into Text Fieldrdquo la cual ha sido
implementada para vaciar el contenido de campos de texto ya que mediante la Keyword ldquoClear Element Textrdquo
de la libreriacutea Selenium2Library no se conseguiacutea borrar ciertos campos de texto
Figura 80 Keywords Input Into Text Field y Clear Field Of Characters
98
632 CHT Zones
En la pestantildea de gestioacuten de las diferentes Zonas CHT se puede observar una lista de los puntos de acceso
disponibles y se pueden realizar un conjunto de acciones sobre ellos como la creacioacuten eliminacioacuten y asociacioacuten
de zonas CHT
En este punto es conveniente explicar el concepto de zona CHT el cual se refiere a un grupo IP Multicast a
traveacutes del cual un conjunto de Puntos de Acceso establece comunicacioacuten de forma colaborativa Esta
comunicacioacuten es necesaria para el funcionamiento de algunos de los algoritmos que ofrece CHT como por
ejemplo la asignacioacuten automaacutetica de canal (ACA)
Figura 81 Pestantildea ldquoCHT Zonesrdquo
Sobre esta vista se han realizado un total de 6 casos de prueba de los cuales detallaremos el caso de prueba
identificado con la etiqueta U0204 Este caso de prueba permite validar la asignacioacuten de zonas CHT a los Puntos
de Acceso
6321 Criterios de Aceptacioacuten
U0204 Verificar que un usuario puede asignar una Zona CHT a un punto de acceso correctamente
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Configuracioacuten
3 El usuario puede Navegar a la pestantildea de Grupos
4 El usuario puede asignar una Zona CHT existente a un punto de acceso registrado correctamente
99
6322 Diagramas de Flujo
Figura 82 Diagrama de Flujo de Caso de Prueba U0204
6323 Script de Pruebas
Tras presentar los criterios de aceptacioacuten y su correspondiente diagrama de flujo el script de pruebas
implementado para la automatizacioacuten de dicha prueba es el siguiente
Figura 83 Scripts de Prueba U0204
Figura 84 Keyword Add Zone CHT to AP
100
633 BackupRestore
En esta pestantildea se permite la gestioacuten de copias de seguridad y restauracioacuten de los puntos de acceso registrados
en un Zone Manager Se puede observar en esta vista una tabla con los puntos de acceso registrados y otra tabla
con las copias de seguridad realizadas sobre los puntos de acceso
Figura 85 Pestantildea BackupRestore
Partiendo de la representacioacuten funcional de esta vista se han realizado un total de 8 casos de prueba de los
cuales detallaremos el caso de prueba identificado con la etiqueta U0401 el cual permite verificar de forma
automaacutetica la realizacioacuten de un backup sobre un punto de acceso y su posterior restauracioacuten
6331 Criterios de Aceptacioacuten
U0401 Verificar que un usuario puede realizar un BackupRestore correctamente sobre un punto de
acceso previamente registrado
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Configuracioacuten
3 El usuario puede Navegar a la pestantildea de BackupRestore
4 El usuario puede realizar un Backup sobre un punto de acceso existente
5 La tabla de Backups contiene la copia de seguridad realizada
6 El usuario puede restaurar un punto de acceso correctamente
101
6332 Diagramas de Flujo
Figura 86 Diagrama de Flujo de Caso de Prueba U0401
6333 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 87 Script de Prueba U0401
Cabe destacar la implementacioacuten de la Keyword ldquoRestore for AP have done successfullyrdquo la cual verifica que
el punto de acceso ha sido restaurado correctamente esperando que el punto de acceso vuelva a estar en estado
ldquoonlinerdquo durante un tiempo aceptable Si pasado dicho tiempo no recupera dicho estado la prueba se dariacutea por
erroacutenea
Figura 88 Keyword Restore For AP hace done successfully
634 Firmware
Esta uacuteltima pestantildea de la vista principal de configuracioacuten proporciona al usuario la posibilidad de subir los
firmwares de los diferentes modelos de puntos de acceso en sus diferentes versiones del software CHT de forma
que es posible la actualizacioacuten del firmware de los puntos de acceso desde la plataforma Se puede observar en
esta vista una tabla con los puntos de acceso registrados y otra tabla con los firmwares subidos a la plataforma
102
Figura 89 Pestantildea ldquoFirmwarerdquo
Partiendo de la representacioacuten funcional de esta vista se han realizado un total de 7 casos de prueba de los
cuales detallaremos el caso de prueba identificado con la etiqueta U0303 el cual permite verificar de forma
automaacutetica la actualizacioacuten del firmware de un punto de acceso
6341 Criterios de Aceptacioacuten
U0303 Verificar que un usuario puede realizar correctamente la actualizacioacuten del firmware de un punto
de acceso
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Configuracioacuten
3 El usuario puede Navegar a la pestantildea de Firmware
4 El usuario puede subir un firmware correctamente
5 La tabla de Firmwares contiene la imagen de CHT subida a la plataforma
6 El usuario puede realizar la actualizacioacuten del firmware sobre un punto de acceso correctamente
Destacar que el firmware que se desea aplicar sobre un punto de acceso debe ser del modelo correspondiente al
punto de acceso usado ya que cada punto de acceso tiene una imagen de CHT compilada para una arquitectura
hardware determinada Las imaacutegenes son proporcionadas por un servidor interno de la empresa
103
6342 Diagramas de Flujo
Figura 90 Diagrama de Flujo de Caso de Prueba U0303
6343 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 91 Script de Prueba U0303
Cabe destacar la implementacioacuten de la Keyword ldquoFlash APrdquo la cual realiza la actualizacioacuten del firmware de un
punto de acceso verificando que este ha concluido correctamente Para ello espera un tiempo aceptable a que el
punto de acceso vuelva al estado ldquoonlinerdquo
Figura 92 Keyword Flash AP
104
64 Vista de Red (Network Tab)
La uacuteltima vista principal sobre la que se han automatizado pruebas es la vista de Red la cual ofrece al usuario
la gestioacuten y configuracioacuten de su red formada por un conjunto de puntos de acceso previamente registrados
Entre las funcionalidades ofrecidas se encuentran la creacioacuten de VLANS SSIDs Portales Cautivos Perfiles
Radius Activacioacuten de algoritmos CHT y la configuracioacuten de puntos de acceso en tiempo real desde la
plataforma Web
Para describir el proceso de automatizacioacuten se comenzaraacute detallando en primer lugar la creacioacuten de VLANS
Brigdes y SSIDs para posteriormente aplicar dichos paraacutemetros a puntos de acceso desde las pestantildeas ldquoGeneralrdquo
y ldquoAP Networkrdquo Finalmente se mostraraacuten algunos ejemplos sobre otras configuraciones maacutes avanzadas como
la creacioacuten y aplicacioacuten de perfiles radius y portales cautivos ademaacutes de la activacioacuten de algoritmos
641 VLANS amp Bridges
Comenzando con la pestantildea de VLANS amp Bridges se puede observar la existencia de una tabla para cada
elemento de dicha vista
Figura 93 Pestantildea ldquoVLAN amp Bridgesrdquo
Para cada elemento se han automatizado un conjunto de pruebas formado por 6 casos de prueba de los cuales
detallaremos el caso de prueba identificado con la etiqueta U0527 Este caso de prueba permite validar de forma
automaacutetica la creacioacuten y eliminacioacuten de VLANs De forma ideacutentica se procederiacutea para validar la creacioacuten y
eliminacioacuten de Bridges
6411 Criterios de Aceptacioacuten
A continuacioacuten se detallan los criterios de aceptacioacuten del caso de prueba seleccionado
U0527 Verificar que un usuario puede crear y eliminar una VLAN correctamente
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Network
3 El usuario puede Navegar a la pestantildea de VLANS amp Bridges
4 El usuario puede crear una VLAN correctamente
5 El usuario puede eliminar una VLAN correctamente
105
6412 Diagramas de Flujo
Figura 94 Diagrama de Flujo de Caso de Prueba U0527
6413 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 95 Script de Prueba U0527
Cabe destacar la implementacioacuten de la Keyword ldquoGo and Create VLANrdquo la cual permite crear una VLAN en
funcioacuten de los paraacutemetros de entrada deseados para configurar dicha VLAN como por ejemplo el ldquoIDrdquo de la
VLAN y alias o si se desea que dicha VLAN sea de tipo dinaacutemica
Figura 96 Keyword Go And Create VLAN
106
642 SSIDs
Esta pestantildea proporciona una tabla que permite registrar SSIDs con diferentes configuraciones posibles
Figura 97 Pestantildea SSIDs
Para cada funcionalidad de dicha pestantildea se han automatizado un conjunto de pruebas formado por 5 casos de
prueba de los cuales detallaremos el caso de prueba identificado con la etiqueta U0530 Este caso de prueba
permite validar de forma automaacutetica la creacioacuten y eliminacioacuten de SSIDS
6421 Criterios de Aceptacioacuten
A continuacioacuten se detallan los criterios de aceptacioacuten de los dos casos de prueba seleccionados
U0530 Verificar que un usuario puede crear y eliminar una SSID correctamente
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Network
3 El usuario puede Navegar a la pestantildea de SSIDs
4 El usuario puede crear una SSID correctamente
5 El usuario puede eliminar una SSID correctamente
6422 Diagramas de Flujo
Figura 98 Diagrama de Flujo de Caso de Prueba U0530
107
6423 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 99 Script de Prueba U0530
Cabe destacar la implementacioacuten de la Keyword ldquoGo and Create SSIDrdquo la cual permite crear una SSID en
funcioacuten de los paraacutemetros de entradas deseado para configurar dicha SSID como por ejemplo tipo de
encriptacioacuten de la contrasentildea modo oculto o habilitacioacuten de los algoritmos Load Balancing (LB) Smart
roaming (SR) o PRE
Figura 100 Keyword Go And Create SSID
108
643 CHT
Esta funcionalidad permite activar el algoritmo que permite la seleccioacuten automaacutetica de canal entre un conjunto
de puntos de acceso (ACA) Cuando se activa desde la plataforma Web todos los puntos de acceso
pertenecientes a un Zone Manager activan dicho algoritmo el cual se trata de un algoritmo colaborativo
mediante el cual los puntos de acceso acuerdan cual es el mejor canal para la comunicacioacuten WiFi con los clientes
que se conecten tanto en la banda de 24 GHz como en la de 5 GHz En la siguiente figura se muestra la vista
de la plataforma Web para activar el algoritmo en cuestioacuten
Figura 101 Pestantildea ldquoCHTrdquo
Dado que se trata de una funcionalidad en la que solo se debe comprobar si el algoritmo estaacute en el mismo estado
tanto en la plataforma Web como en los puntos de acceso registrados se ha implementado un uacutenico caso de
prueba identificado con la etiqueta U539 Este caso de prueba realiza la conexioacuten a los puntos de acceso para
verificar que dicho algoritmo presenta el mismo estado que en la plataforma
6431 Criterios de Aceptacioacuten
U0537 Verificar que un usuario puede Activar o Desactivar el algoritmo ACA correctamente
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Network
3 El usuario puede Navegar a la pestantildea de CHT
4 El usuario puede ActivarDesactivar el algoritmo ldquoACA ldquocorrectamente
5 Los APs recibieron las oacuterdenes para ActivarDesactivar el algoritmo ldquoACArdquo correctamente
109
6432 Diagramas de Flujo
Figura 102 Diagrama de Flujo de Caso de Prueba U0539
6433 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 103 Script de Prueba U0539
En cuanto a la implementacioacuten de dicho caso de prueba cabe destacar la implementacioacuten de la Keyword ldquoACA
Is Workingrdquo las cual se muestra en la siguiente figura
Figura 104 Keyword ACA Is Working
Puede observarse como en funcioacuten de si el algoritmo ACA esta activado o desactivado en la plataforma Web
(ENABLE DISABLE) se ejecuta la Keyword ldquoChanges On CLIrdquo con diferentes paraacutemetros Esta Keyword
permite la conexioacuten viacutea ldquoSSHrdquo con un punto de acceso para la ejecucioacuten de un comando sobre el mismo y la
posterior comparacioacuten del resultado obtenido por dicho comando con la salida deseada proporcionada tambieacuten
como paraacutemetro de la Keyword
110
En la siguiente figura se muestra la implementacioacuten de dicha Keyword
Figura 105 Keyword Changes On CLI
Para este caso de prueba el comando ejecutado de forma remota sobre el punto de acceso permite obtener de
forma automaacutetica el estado del algoritmo ldquoACArdquo de la siguiente forma
Figura 106 Comando CHT para obtener el estado del moacutedulo ACA en el punto de acceso
644 Radius
Esta pestantildea proporciona una tabla que permite registrar perfiles Radius con diferentes configuraciones posibles
Figura 107 Pestantildea ldquoRadiusrdquo
ldquoRadiusrdquo se define como un protocolo de autenticacioacuten y autorizacioacuten para aplicaciones de acceso a la red o
movilidad IP De esta forma los puntos de acceso mediante la existencia de un servidor radius permiten que los
usuarios que se quieran conectar por WiFi necesiten ser autenticados con credenciales Dicha autenticacioacuten seraacute
redirigida por el punto de acceso al servidor radius el cual autoriza al punto de acceso para que permita la
conexioacuten del cliente
Ademaacutes el uso de este servicio junto con la configuracioacuten mediante VLAN dinaacutemicas permite que diferentes
usuarios accedan al servicio de red con diferentes credenciales de forma que seguacuten el tipo de cliente su traacutefico
viajaraacute por una VLAN u otra Esto permite la separacioacuten del traacutefico a nivel de enlace ofreciendo la posibilidad
de establecer reglas de control de traacutefico y ofrece una QoS miacutenima en funcioacuten del tipo de cliente
Figura 108 Escenario de Funcionamiento de Servidor Radius
111
Para cada funcionalidad de dicha pestantildea se han automatizado un conjunto de pruebas formado por 7 casos de
prueba de los cuales detallaremos el caso de prueba identificado con la etiqueta U0601 Este caso de prueba
permite validar de forma automaacutetica la creacioacuten edicioacuten y borrado de un perfil radius en la plataforma Web
6441 Criterios de Aceptacioacuten
U0601 Verificar que un usuario puede crear editar y borrar un perfil Radius correctamente
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Network
3 El usuario puede Navegar a la pestantildea de Radius
4 El usuario puede Crear un perfil Radius correctamente
5 El usuario puede Editar un perfil Radius correctamente
6 El usuario puede Eliminar un perfil Radius correctamente
6442 Diagramas de Flujo
Figura 109 Diagrama de Flujo de Caso de Prueba U0601
6443 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 110 Script de Prueba U0601
En cuanto a la implementacioacuten de dicho caso de prueba puede destacarse por ejemplo la implementacioacuten de
la Keyword ldquoCreate Radius Profilerdquo la cual permite crear un perfil ldquoRadiusrdquo a partir de un conjunto de
paraacutemetros de entrada
112
Figura 111 Keyword Create Radius Profile
645 Captive Portal
Esta pestantildea proporciona una tabla que permite registrar perfiles de Portales Cautivos con diferentes
configuraciones posibles
Figura 112 Pestantildea Captive Portals
Un portal cautivo es un servicio que permite el control del traacutefico HTTP y fuerza a los usuarios de una red a la
autenticacioacuten mediante una paacutegina Web para tener acceso a Internet Dicho portal permite controlar paraacutemetros
como el tiempo de conexioacuten de un cliente a la red ancho de banda ofrecido a cada cliente etc
Figura 113 Escenario de Funcionamiento de un Portal Cautivo
Para cada funcionalidad de dicha pestantildea se han automatizado un conjunto de pruebas formado por 5 casos de
prueba de los cuales detallaremos el caso de prueba identificado con la etiqueta U0701 Este caso de prueba
permite validar de forma automaacutetica la creacioacuten edicioacuten y borrado de un perfil de portal cautivo en la plataforma
Web
113
6451 Criterios de Aceptacioacuten
U0701 Verificar que un usuario puede crear editar y borrar un perfil de Portal Cautivo correctamente
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Network
3 El usuario puede Navegar a la pestantildea de Captive Portals
4 El usuario puede Crear un perfil de Portal Cautivo correctamente
5 El usuario puede Editar un perfil de Portal Cautivo correctamente
6 El usuario puede Eliminar un perfil de Portal Cautivo correctamente
6452 Diagramas de Flujo
Figura 114 Diagrama de Flujo de Caso de Prueba U0701
6453 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 115 Script de Prueba U0701
114
En cuanto a la implementacioacuten de dicho caso de prueba puede destacarse por ejemplo la implementacioacuten de
la Keyword ldquoEdit or delete Captive Portal Profilerdquo la cual permite editar o eliminar un perfil de Portal Cautivo
a partir de un conjunto de paraacutemetros de entrada
Figura 116 Keyword Edit or Delete Captive Portal Profile
115
646 General
Esta pestantildea muestra la vista general de la pestantildea ldquoNetworkrdquo En esta pestantildea se agrupa el conjunto de puntos
de acceso actualmente registrados en el Zone Manager con un resumen de su configuracioacuten de red actual el
estado en el que se encuentran y nuacutemero de clientes conectados Ademaacutes dicha vista proporciona un acceso
directo a la pestantildea ldquoAP Networkrdquo seleccionando uno o varios puntos de acceso de un mismo modelo En la
siguiente seccioacuten se explica la funcionalidad de dicha pestantildea
Figura 117 Pestantildea General
Para cada elemento se han automatizado un conjunto de pruebas formado por 9 casos de prueba de los cuales
detallaremos el caso de prueba identificado con la etiqueta U0522 Este caso de prueba se permite validar de
forma automaacutetica la conexioacuten de clientes a un punto de acceso con una SSID asignada de forma que el nuacutemero
de clientes conectados que se muestra en la plataforma Web sea correcto
6461 Criterios de Aceptacioacuten
U0522 Conectar clientes y verificar que el nuacutemero de clientes conectados es correcto
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Network
3 El usuario puede Navegar a la pestantildea General
4 El usuario tiene disponible un punto de acceso en el Zone Manager con una SSID asignada
5 El usuario conecta un cliente al punto de acceso por WiFi a la SSID asignada
6 El usuario verifica que el nuacutemero de clientes conectados incrementa en una unidad
116
6462 Diagramas de Flujo
Figura 118 Diagrama de Flujo de Caso de Prueba U0522
6463 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de prueba automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 119 Script de Prueba U0522
En cuanto a la implementacioacuten de dicho caso de prueba puede destacarse por ejemplo la implementacioacuten de
la Keyword ldquoCheck Number of Clients Increasesrdquo la cual permite comprobar que el nuacutemero de clientes conectados incrementa al conectar un cliente a un punto de acceso
Figura 120 Keyword Check Number of Clients Increases
117
647 AP Network
Esta pestantildea muestra la vista principal de la pestantildea ldquoAP Networkrdquo La funcionalidad que proporciona engloba
todos los posibles paraacutemetros de configuracioacuten para un punto de acceso que ha sido seleccionado previamente
desde la pestantildea General Cualquier configuracioacuten aplicada sobre esta vista seraacute enviada al punto de acceso
desde la plataforma Web permitiendo configurar los puntos de acceso de Galgus
Desde el punto de vista de la plataforma Web esta vista abarca un conjunto de funcionalidades consideradas
como maacutes complejas que se ofrecen en la plataforma Web por lo que es en esta vista donde puede encontrarse
una de las mayores aacutereas de riesgo de la plataforma Entre las funcionalidades que se ofrecen estaacuten la
configuracioacuten de las radios de un punto de acceso (Potencia Ancho de banda Canal etc) asignacioacuten de SSIDs
a las interfaces inalaacutembricas y configuracioacuten de reglas de control de traacutefico (TC Rules) asignacioacuten de puertos a
las diferentes subredes virtuales de aacuterea local (VLANS) o configuracioacuten de Portal Cautivo
Figura 121 Pestantildea AP Network
Para cada elemento se han automatizado un conjunto de pruebas formado por 28 casos de prueba los cuales la
mayoriacutea han requerido un amplio esfuerzo de implementacioacuten para conseguir su automatizacioacuten ya que son
pruebas cuya secuencia de acciones es larga ademaacutes de requerir en muchas ocasiones la verificacioacuten de la
configuracioacuten en los puntos de acceso viacutea ldquosshrdquo Para ello se ha hecho uso entre otras de la libreriacutea
ldquoSSHLibraryrdquo proporcionada por Robot Framework
Figura 122 Libreriacutea SSH para Robot Framework
118
Del conjunto de casos de prueba que validan la funcionalidad de dicha pestantildea se va a detallar el caso de prueba
identificado con la etiqueta U0511 Este caso de prueba permite validar de forma automaacutetica que se pueden
aplicar reglas de control de traacutefico ldquoTCsrdquo a una SSID asignada a las interfaces inalaacutembricas de un punto de
acceso desde la plataforma Web
Figura 123 Ventana de Configuracioacuten de TC Rules
6471 Criterios de Aceptacioacuten
U0511 Asignar ldquoTC Rulesrdquo a una SSID asociada a un Punto de Acceso correctamente
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Network
3 El usuario puede Navegar a la pestantildea General
4 El usuario tiene disponible un punto de acceso en el Zone Manager
5 El usuario puede seleccionar un punto de acceso
6 El usuario puede Navegar a la pestantildea AP Network para el punto de acceso seleccionado
7 El usuario puede asignar a las interfaces inalaacutembricas una SSID existente y crear ldquoTC Rulesrdquo sobre
esa SSID
8 El usuario puede aplicar la configuracioacuten
9 El punto de acceso aplica su configuracioacuten correctamente
10 El punto de acceso pasa al estado ldquoOnlinerdquo en la plataforma Web y su configuracioacuten estaacute alineada
119
6472 Diagramas de Flujo
Figura 124 Diagrama de Flujo de Caso de Prueba U0511
120
6473 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 125 Script de Prueba U0511
En cuanto a la implementacioacuten de dicho caso de prueba puede destacarse por ejemplo la implementacioacuten de
la Keyword ldquoWait Timerrdquo la cual permite verificar que no se produce ninguacuten error al aplicar una configuracioacuten
determinada desde la plataforma Web durante un tiempo determinado
Figura 126 Keyword Wait Timer
Destacar tambieacuten la implementacioacuten de la Keyword ldquoCheck On CLIrdquo la cual permite contrastar que la
configuracioacuten aplicada desde la plataforma sobre un punto de acceso es la esperada En este caso se comprueba
que las ldquoTC Rulesrdquo han sido correctamente aplicadas para una SSID determinada en un punto de acceso de
forma remota mediante el uso de la libreriacutea ldquoSSHrdquo para Robot Framework
Figura 127 Keyword Check On CLI
121
122
7 LINEAS DE MEJORA Y CONCLUSIONES
n este uacuteltimo capiacutetulo se analizaraacuten resultados y conclusiones obtenidas sobre el uso de pruebas
automatizadas para la verificacioacuten y validacioacuten de una plataforma Web como la de Galgus Se
detallaraacuten algunas ventajas e inconvenientes encontrados y se plantearaacuten algunas liacuteneas de mejora
futuras sobre el proyecto desarrollado Con estas mejoras se busca como objetivo enriquecer el proceso de
automatizacioacuten de pruebas ademaacutes de hacerlo maacutes efectivo y metoacutedico en todos sus aspectos ya que siempre
hay algo que se puede mejorar para conseguir una herramienta maacutes completa y uacutetil
Se detallaraacuten tambieacuten aspectos de aprendizaje opiniones experiencias y en definitiva todas las conclusiones
sacadas sobre este proyecto incluyendo tambieacuten las dificultades encontradas para el desarrollo del mismo
71 Liacuteneas de Mejora Futuras
El estudio y puesta en marcha de este Proyecto de automatizacioacuten de pruebas de Software ha hecho uso de una
amplia cantidad de herramientas ofrecido por Selenium y Robot Framework ademaacutes de otras herramientas que
han permitido enriquecer el mismo con mayores funcionalidades ofrecidas al equipo de Proyecto Si bien se ha
logrado conseguir un paquete de pruebas con una capacidad de detectar defectos en un producto Web existen
diversas ampliaciones de dicho Proyecto que podriacutean aumentar de manera considerable el desempentildeo de las
herramientas de automatizacioacuten a lo largo del ciclo de vida del proyecto
A continuacioacuten se muestran algunas de las maacutes importantes
bull Uso de Integracioacuten Continua Robot Framework es faacutecilmente integrable principalmente con Jenkins
aunque tambieacuten ofrece la posibilidad de integrarlo con Gitlab CICD Esto permitiriacutea programar la
ejecucioacuten de pruebas automaacuteticamente para diferentes versiones del proyecto Galgus CHT Cloud
Manager o en diferentes fases del mismo Con esta caracteriacutestica se detectariacutean con mayor facilidad los
problemas relacionados con la configuracioacuten del entorno de trabajo y se podriacutea notificar por email a
los responsables de equipo ante los eventuales incidentes encontrados De este modo no seriacutea necesario
estar supervisando el proceso de ejecucioacuten para estar al tanto de un fallo en el sistema En este aspecto
se ha trabajado para conseguir estos objetivos con la creacioacuten de un Docker de Robot Framework que
permita la ejecucioacuten de las pruebas en el mismo para poder usarla en el entorno de integracioacuten continua
correspondiente Tambieacuten se ha implementado un primer un script que permita la ejecucioacuten de paquetes
de pruebas en dicho entorno
bull Selenium Grid El caso praacutectico descrito tiene un inconveniente y es que solo hace uso de Chrome
Suele ser frecuente que ciertos defectos en una aplicacioacuten Web solo aparezcan en determinados
navegadores Con herramientas como Selenium Grid permitiriacutean la ejecucioacuten en paralelo de las pruebas
en maacutequinas con diferentes sistemas operativos y navegadores Asiacute se podriacutea evaluar de manera
independiente la compatibilidad del producto en entornos multiplataforma Ademaacutes esta herramienta
es totalmente compatible con Jenkins o Gitlab CICD con las ventajas que esto supone
bull Headless browser Esto hace referencia al uso de navegadores sin interfaz graacutefica de usuario La mayor
parte del tiempo durante una ejecucioacuten es destinada a esperar a que el navegador renderice el contenido
Si se elimina este factor de la foacutermula y se accede directamente al DOM de la Web se consigue una
reduccioacuten en el tiempo de ejecucioacuten de las pruebas Durante el desarrollo de este proyecto se ha
trabajado en este aspecto ofrecieacutendose la posibilidad de ejecutar las pruebas en dos entornos diferentes
una primera de depuracioacuten de pruebas que realiza el renderizado del navegador y otra opcioacuten que
E
La tecnologiacutea por siacute sola no basta Tambieacuten tenemos que poner el corazoacuten
Jane Goodall
123
permite la ejecucioacuten de pruebas sin renderizado del navegador (Modo Headless)
bull Buenas praacutecticas en la localizacioacuten de elementos en el DOM de la Web La aplicacioacuten de este tipo
de buenas praacutecticas permitiriacutean una mejor y maacutes eficiente localizacioacuten de los elementos en el DOM
reduciendo la posibilidad de que las pruebas generen falsos errores Esto es lo que ha causado la mayor
parte de los problemas de implementacioacuten y ejecucioacuten de las pruebas automaacuteticas Actualmente la
herramienta de automatizacioacuten de pruebas se encuentra en un proceso de mejora continua en el que se
estaacute abordando una refactorizacioacuten para la aplicacioacuten de estas buenas praacutecticas Para ello se estaacuten
haciendo uso de selectores avanzados basados en rutas (Xpaths) relativas en el DOM de la Web las
cuales realizan la mayoriacutea de las buacutesquedas por contenido y no por ruta absoluta como se veniacutea
haciendo hasta ahora
bull Aplicacioacuten de Model Based Testing (MBT) Como estudio del arte se ha presentado una teacutecnica que
permite dar un paso maacutes en la automatizacioacuten de pruebas Como se ha detallado en el proyecto esta
teacutecnica permite ascender en el nivel de abstraccioacuten de las pruebas basando las mismas en el disentildeo y
modelado de la aplicacioacuten Dicha teacutecnica se encuentra principalmente en proceso de investigacioacuten lo
cual hace difiacutecil aplicarla aunque seriacutea de gran intereacutes conseguir su implantacioacuten
72 Conclusiones Finales
En el desarrollo del presente Proyecto se ha analizado una pequentildea extensioacuten del inmenso mundo de la gestioacuten
de calidad Esta ha ido tomando fuerza con el paso de los antildeos en el mercado actual introducieacutendose en todos
los aacutembitos incluido en el software La gestioacuten de calidad se ha profesionalizado de tal forma que el papel del
ingeniero de calidad en los proyectos de software es imprescindible en cualquier empresa que quiera hacerse un
hueco en el mercado como garantiacutea de calidad
La elevada exigencia del mercado del software provocada por la gran demanda de clientes y usuarios finales
para recibir un producto en el menor tiempo posible hace que en muchos casos las empresas centren su esfuerzo
en sacar un producto lo antes posible reduciendo los esfuerzos destinados a los procesos de calidad de dicho
producto software Originalmente las pruebas de software realizadas sobre un producto se realizaban de forma
manual por un ingeniero de calidad pero con el avance de las tecnologiacuteas la automatizacioacuten de las mismas
supone un elevado esfuerzo inicial pero una reduccioacuten de los mismos a medio plazo
En este proyecto se ha desarrollado una herramienta que permite la automatizacioacuten de pruebas funcionales sobre
una plataforma Web concretamente pruebas de aceptacioacuten sobre Galgus CHT Cloud Manager Las pruebas de
automatizacioacuten elaboradas reflejan que existen tecnologiacuteas muy asequibles en teacuterminos de coste compatibilidad
y facilidad de uso para iniciarse en el mundo de las pruebas funcionales de sistemas Algo muy presente en el
mundo laboral actual es la creciente demanda de expertos en automatizacioacuten en todas las principales
plataformas Web Moacutevil y Escritorio Muchos de estos profesionales vienen del mundo del testing manual por
lo que conociendo ya la nomenclatura y el funcionamiento de los procesos de calidad solo necesitan dar el paso
hacia el uso de este tipo de herramientas Sea con Selenium o con cualquier otra herramienta los conceptos
teoacutericos presentados en este proyecto son igualmente vaacutelidos
Por otra parte debe destacarse la dificultad encontrada a la hora de establecer unos criterios de aceptacioacuten de las
funcionalidades de la plataforma Web bajo pruebas Esto se debe al desarrollo de una herramienta de
automatizacioacuten de pruebas que se ha iniciado en una fase avanzada del desarrollo del proyecto con lo cual en
muchas ocasiones surgiacutean dudas sobre el disentildeo del proyecto Adicionalmente la propia estructura y tecnologiacuteas
usadas en la Web dificultaron al inicio la localizacioacuten de elementos A esta causa de une tambieacuten la ausencia de
identificadores uacutenicos en los elementos que componen la misma Esto se tradujo en el uso de selectores basados
en la ruta del elemento pudiendo acarrear la aparicioacuten de posibles falsos errores debidos a cambios en el coacutedigo
fuente de la plataforma Web La solucioacuten adoptada para tal problema no fue maacutes que analizar meticulosamente
aquellas ejecuciones fallidas para descartar errores reales y en caso de que sean debidas a los selectores aplicar
la debida actualizacioacuten de los mismos
En este uacuteltimo aspecto cabe destacar que el proyecto de automatizacioacuten de pruebas se encuentra actualmente
en una fase de mejora continua en la que se estaacuten adoptando teacutecnicas basadas en el uso de selectores avanzados
basados en rutas relativas y nombres que permitan reducir el impacto del problema presentado en este punto
124
A modo de resumen se plantean algunas ventajas en el uso de SeleniumRobot Framework para la
automatizacioacuten de pruebas
Facilidad de configuracioacuten y uso Su instalacioacuten requiere un esfuerzo miacutenimo y el poder de
abstraccioacuten ofrecido por Robot Framework hace posible la lectura y entendimiento de los paquetes de
pruebas y reportes a todos los miembros del equipo
Cantidad de documentacioacuten disponible La comunidad respalda ambos proyectos y es por ello que
encontramos soluciones de todo tipo adaptadas a las necesidades de cada uno
Soporte para la mayoriacutea de navegadores con el mismo script Ejecutar el script de pruebas
desarrollado para su automatizacioacuten en otro navegador requiere simplemente la instalacioacuten del
controlador deseado y usar un determinado paraacutemetro para indicar el uso de dicho controlador en la
llamada de la Keyword encargada de la apertura del navegador
De la misma forma se pueden destacar algunas desventajas
Selenium soacutelo es compatible con productos Web Cualquier software moacutevil o de escritorio requiere
del uso de otros frameworks o herramientas lo cual puede ser un punto negativo para empresas que
tengan productos multiplataforma Sin embargo Robot Framework si proporciona soporte
multiplataforma con la integracioacuten de otras herramientas o framework para su desarrollo
Tecnologiacuteas no optimizadas para pruebas de rendimiento En este punto cabe destacar el esfuerzo
de la comunidad para desarrollar herramientas que permitan la automatizacioacuten de este tipo de pruebas
con Robot Framework como por ejemplo ldquorfswarmrdquo
Compatibilidad de versiones de paquetes de Software Es frecuente usar determinadas
combinaciones de versiones de paquetes para lograr un framework estable y robusto Esto a veces puede
convertirse en una tarea tediosa donde cuestan encajar piezas Por suerte es algo que se estaacute teniendo
en cuenta con las uacuteltimas versiones de Selenium
Puede concluirse que durante el desarrollo de este proyecto se ha conseguido la creacioacuten de una herramienta
sencilla de usar y entender para la automatizacioacuten de pruebas funcionales sobre una plataforma Web ademaacutes
de preparar dicha herramienta para integrarla en el proceso de integracioacuten continua implantado para dicha
aplicacioacuten Web con Gitlab mediante Docker Ademaacutes se ha realizar un estudio del arte de una teacutecnica conocida
bajo el nombre de Model Based Testing (MBT) que permitiriacutea mejorar el proceso de automatizacioacuten y la
herramienta desarrollada para tal fin
Con todo ello he aprendido multitud de conceptos tecnologiacuteas y herramienta que hasta ahora desconociacutea cuaacutel
era su finalidad o funcionamiento como por ejemplo Robot Framework Para ello he necesitado gran cantidad
de formacioacuten previa antes de comenzar a ponerlo en praacutectica para el desarrollo de la herramienta de
automatizacioacuten
Son muchos los errores cometidos hasta conseguir los objetivos y metas propuestas los cuales creo que son los
sucesos maacutes importantes pues de ellos se aprende y son los que nos hacen avanzar cuando los resolvemos
Finalmente destacar que este proyecto me ha dado la oportunidad de abrir mi conocimiento en un campo de las
tecnologiacuteas de la informacioacuten el cual resulta de intereacutes Dar las Gracias a mis tutores Pablo Aguilera Bonet y
Daniel Gutieacuterrez Reina ademaacutes de mi responsable en Galgus Joseacute Antonio Delgado Alfonso por brindarme
esta oportunidad ademaacutes de ayudarme y asesorarme estando siempre disponible y con dedicacioacuten hacia este
proyecto para que haya podido llevarse a cabo
125
126
REFERENCIAS
[1] M Utting Bruno Legeard Practical Model-based Testing sl Elsevier 2007
[2] Ibrahim K El-Far Enjoying the perks of model-based testing In Proceedings of the Software Testing
Analysis and Review Conference
[3] A C Dias Neto Rajesh Subramanyan Marlon Vieirab Characterization of Model-based Software
[4] Model-based Testing Next Generation Functional Software Testing Legeard Bruno Dagstuhl Seminar
Proceedings 10111 Vol httpdropsdagstuhldeopusvolltexte20102620
[5] Perspectives of Model-Based Testing Ed Brinksma Wolfgang Grieskamp and Jan Tretmans IBFI
Schloss Dagstuhl Germany sn 2005 Dagstuhl Seminar Proceedings
[6] Definicioacuten de Calidad httpsdleraeesid=6nVpk8P|6nXVL1Z
[7] Modelos de calidad del software httpswwwresearchgatenetpublication316674475
[8] Calidad del Software ldquoEl camino al exitordquo LI Alma Delia Chaacutevez Rojas
[9] IEEE Software Engineering Book of Knowledge IEEE sl IEEE 2004
[10] Principios de pruebas software httpsmediumcomatejedaccsprincipios-del-testing-722323e16e76
[11] httpwwwsstqbesw3docsGLOSARIO_V00110pdf
[12] httpsepdfpubsoftware-testing-an-istqb-iseb-foundation-guidehtml
[14] IEEE standard glossary of software engineering terminology F Jay RMayer 1990 paacuteg IEEE Std 610
[15] Openwrt httpsopenwrtorgsupported_devices
[16] RabbitMQ httpswwwrabbitmqcom
[17] Zero Touch Provisioning httpssearchdatacentertechtargetcomesdefinicionAprovisionamiento-de-
cero-toque-ZTP-o-zero-touch-provisioning
[18] Robot Framework User Guide
httpsrobotframeworkorgrobotframeworklatestRobotFrameworkUserGuidehtml
[19] Gitlab httpsdocsgitlabcom
[20] httpswwwfederico-toledocomcuando-automatizar-una-prueba
127
128
ANEXO A PREPARACIOacuteN DEL ENTORNO DE
TRABAJO Y EJECUCIOacuteN DE PRUEBAS
A1 Preparacioacuten del entorno de trabajo
Para el desarrollo de las preubas automaacuteticas se ha hecho uso del sistema operative Linux con la distribucioacuten
Ubuntu El motivo de su uso es el amplio abanico de herramientas de coacutedigo libre que existen para esta
distribucioacuten asiacute como la enorme contribucioacuten que hace la comunidad de usuarios para mejorarla Sobre este
sistema operativo se ha hecho uso de un conjunto de herramientas para el montaje de un entorno de pruebas
automatizado basado en Python A continuacioacuten se detallaraacuten dichas herramientas
A11 Pip
Pip es un sistema de gestioacuten de paquetes que se utiliza para la instalacioacuten de los paquetes software
implementados en Python que se usaraacuten posteriormente La instalacioacuten de un paquete se realiza mediante la
ejecucioacuten del siguiente comando
A12 Virtualenv Entorno Virtual
Dado que cada proyecto basado en Python puede requerir la instalacioacuten de diferentes conjuntos de paquetes es
comuacuten usar la creacioacuten de entornos virtuales que nos permitan administrar cada proyecto de manera
independiente pudiendo tener otros proyectos haciendo uso de los mismos paquetes con otras versiones La
instalacioacuten se realiza mediante la herramienta ldquoPiprdquo a traveacutes del siguiente comando
Una vez instalado se puede crear un entorno virtual asociado a un proyecto de la siguiente forma
En este punto se creariacutea un entorno virtual para el proyecto deseado Ahora solo quedariacutea activarlo o iniciarlo
pip install nombre-del-paquete
pip install virtualenv
cd carpeta-del-proyecto
virtualenv ndashp usrbinpython27 mi-proyecto
source mi-proyectobinactivate
129
A13 Selenium y Chromedriver
La instalacioacuten de Selenium se realiza de la misma forma que el resto de paquetes con la herramienta ldquoPiprdquo
Por otra parte el controlador para el navegador Chrome Chromedriver puede ser descargado desde el
repositorio oficial httpschromedriverchromiumorg Ademaacutes Chromedriver debe ser accessible para
Selenium de cara a configurar el PATH
A14 Robot Framework y SeleniumLibrary
A continuacioacuten se realizariacutea la instalacioacuten de Robot Framework
Posteriormente se realizariacutea la instalacioacuten del paquete ldquoSelenium2Libraryrdquo el cual contiene la implementacioacuten
en python de las libreriacuteas necesarias para utilizar Robot Framework en Python
Llegados a este punto listando todos los paquetes instalados se deberiacutea tener algo similar a la siguiente figura
Con esta configuracioacuten del entorno este estariacutea preparado para elaborar los casos de prueba automatizados con
Robot Framework y Selenium
pip install selenium
export PATH=$PATHabsolute_path_of_chromedriver_file
pip install robotframework
pip install robotframework-selenium2library
130
A15 Otras dependencias
Para el desarrollo de pruebas que requieren otro tipo de herramientas como la transferencia de ficheros con el
servicio ldquoSCPrdquo o la conexioacuten remota a traveacutes del servicio ldquoSSHrdquo se require la instalacioacuten de los siguientes
paquetes
Ademaacutes para la realizacioacuten de pruebas avanzadas en Python para la gestioacuten del Mapa de la platform Web CHT
Cloud Manager se ha hecho uso de la librariacutea ldquohtml-testRunnerrdquo para ofrecer un reporte de la ejecucioacuten de
pruebas muy similar al ofrecido por Robot Framework
A2 Ejecucioacuten de Pruebas
Tras la implementacioacuten de las pruebas siguiendo el procedimiento indicado en la seccioacuten de Experimentos
ejecutar un script de pruebas se realiza mediante el uso del siguiente comando
Mediante el uso de la variable ldquoENVIROMENTrdquo puede seleccionarse el entorno en el que se desea ejecutar las
pruebas Con el entorno de ldquodebugrdquo las pruebas se ejecutariacutean de forma graacutefica mientras que el el entorno de
ldquodockerrdquo permite la ejecucioacuten de pruebas sin interfaz graacutefica Este uacuteltimo entorno seriacutea usado para la ejecucioacuten
de pruebas con el docker de Robot Framework que se ha implementado el cual se detallaraacute maacutes adelante
Por otro lado existen otras opciones para el comando anterio como por ejemplo
Las opciones ldquo-irdquo y ldquo-erdquo permiten ejecutar o excluir un caso de preuba en la ejecucioacuten de una Suite de pruebas
Por otro lado el uacuteltimo comando permite lanzar la ejcucioacuten de una Suite de pruebas y ejecutar soacutelo aquellos
casos de prueba que hayan fallado en la ejecucioacuten anterior
pip install robotframework-sshlibrary
pip install robotframework-scplibrary
pip install html-testRunner
robot --variable ENVIROMENTdebug_or_docker suite_filerobot
robot --variable ENVIROMENTdebug_or_docker ndashi U0000 suite_filerobot
robot --variable ENVIROMENTdebug_or_docker ndashe U0000 suite_filerobot
robot --rerunfailed outrerunfailedxml --output out2xml suite_filerobot
131
A continuacioacuten se muestra un ejemplo de ejecucioacuten de pruebas con Robot Framwork
132
A3 Script de Prueba U007 (MAP)
from selenium import webdriver
from seleniumwebdrivercommonby import By
from seleniumwebdriversupportui import WebDriverWait
from seleniumwebdriversupport import expected_conditions as EC
from seleniumwebdrivercommondesired_capabilities import DesiredCapabilities
from seleniumwebdrivercommonaction_chains import ActionChains
from seleniumcommonexceptions import TimeoutException
import math json multiprocessing time re
import sys
import unittest
import HtmlTestRunner
U0007 Double-click on Zone Manager and look if the Backend tab opens
class DClickZM(unittestTestCase)
driver = 0
canvas = 0
waitTime = 20
username = franciscodiaz
password = ahipeo8829g
classmethodg
def setUp(cls)
Enviroment Management
chrome_options = webdriverChromeOptions()
if sysargv[2] == docker
chrome_optionsadd_argument(--headless)
chrome_optionsadd_argument(--disable-extensions)
chrome_optionsadd_argument(--disable-gpu)
chrome_optionsadd_argument(--no-sandbox)
enable browser logging
d = DesiredCapabilitiesCHROME
d[loggingPrefs] = browser DEBUG
clsdriver = webdriverChrome(chrome_options=chrome_options desired_capabilities=d)
clsdrivermaximize_window()
clsdriverset_window_size(1920 1080)
load the desired webpage
clsdriverget(httpdevcloudgalgusnet)
def test_double_click_ZM(self)
loggin in the page
userNameBox = WebDriverWait(selfdriver 1)until(
ECpresence_of_element_located((ByXPATH [id=username])))
userNameBoxsend_keys(selfusername)
passwordBox = WebDriverWait(selfdriver selfwaitTime)until(
ECpresence_of_element_located((ByXPATH [id=password])))
passwordBoxsend_keys(selfpassword)
133
loginButton = WebDriverWait(selfdriver selfwaitTime)until(
ECpresence_of_element_located((ByXPATH
[id=myModalLabel]divdivformdiv[3]input)))
loginButtonclick() Tab General appears
selfcanvas = WebDriverWait(selfdriver selfwaitTime)
until(ECpresence_of_element_located((ByXPATH
htmlbodyappdivmaindivregister-
managersdivtabsetdivtab[1]aol-mapdivdivcanvas)))
timesleep(15)
action = ActionChains(selfdriver)
Manage Process
manager = multiprocessingManager()
return_dict = managerdict()
We create a Process
p_get_pixels_zm = multiprocessingProcess(target=selfGet_Pixels_ZM args=(return_dict selfdriver))
We create another Process
p_double_click_on_zm = multiprocessingProcess(target=selfDouble_Click_On_ZM args=(return_dict selfcanvas
action selfdriver))
We start the process and we block for 5 seconds
p_get_pixels_zmstart()
p_get_pixels_zmjoin(timeout=10)
p_double_click_on_zmstart()
p_double_click_on_zmjoin(timeout=10)
We terminate the process
p_get_pixels_zmterminate()
p_double_click_on_zmterminate()
try
Tab General appears
WebDriverWait(selfdriver 20)until(ECpresence_of_element_located(
(ByXPATH [id=app-sections]networktabsetulli[1]a)))
except TimeoutException
raise Exception(Cant Login in Zone Manager)
classmethod
def tearDown(cls)
clsdriverquit()
staticmethod
def Get_Pixels_ZM(return_dict driver)
return_dict[0] = 0
return_dict[1] = 0
regex = r(lt=c[-gt]cs)[wW]+(=)
while True
for entry in driverget_log(browser)
message = entry[message]
matches = refinditer(regex message reMULTILINE)
134
for matchNum match in enumerate(matches start=1)
try
p = matchgroup()replace( )
my_json = jsonloads(p)
if my_json[ZM] == Hotel MampM
return_dict[0] = my_json[top]
return_dict[1] = my_json[left]
break
except
pass
if return_dict[0] = 0 and return_dict[1] = 0
break
staticmethod
def Double_Click_On_ZM(return_dict canvasaction driver)
width = int(mathceil(float(return_dict[0])))
height = int(mathceil(float(return_dict[1])))
actionmove_to_element_with_offset(canvas width height)
actiondouble_click()
actionperform()
actiondouble_click()
actionperform()
driversave_screenshot(screenshot1png)
timesleep(5)
if __name__ == __main__
unittestmain(testRunner=HtmlTestRunnerHTMLTestRunner())
135
136
ANEXO B DOCKER DE ROBOT FRAMEWORK Y
ENTORNO DE UAT DOCKERIZADO
B1 Docker de Robot Framework
Para el entorno de UAT que se va a desarrollar se ha hecho uso de diferentes contenedores que han sido creados
por el equipo de desarrollo donde cada contenedor aloja un microservicio diferente de la plataforma
Para crear cada contenedor se ha hecho uso de Docker Esta herramienta permite crear contenedores ligeros y
portables para diferentes servicios que puedan ejecutarse en cualquier maacutequina con Docker instalado
independientemente del sistema operativo de la maacutequina que lo ejecute facilitando asi los despliegues
Mediante un fichero llamado ldquoDockerfilerdquo se definen los siguientes contenedores de servicios entre los cuales
se destacaraacute el fichero que define la creacioacuten del docker de Robot Framework el cual ha sido desarrollado por
el autor de este proyecto
Este contenedor ha sido creado sobre una imagen de Docker con el inteacuterprete de Python instalado Partiendo de
137
esta imagen se realiza la instalacioacuten de Robot Framework y las diferentes libreriacuteas y herramientas que se usaraacuten
en el proyecto para poder lanzar los Tests End-to-End
Ademaacutes se realiza la instalacioacuten de Google Chrome y Mozilla Firefox y la descarga de Chromedriver y
Geckodriver para poder lanzar los tests con dichos navegadores en modo headless Para el lanzamiento de los
test en modo headless se haraacute uso de la variable de entorno ldquoENVIROMENTrdquo definida en el anexo anterior
Finalmente se antildeade el proyecto de pruebas desarrollado para tener disponible las pruebas aumaacuteticas en el
contenedor
B2 Entorno de UAT Dockerizado
Para automatizar el despliegue de la plataforma Galgus CHT Cloud Manager con Docker se ha hecho uso de la
herramienta ldquodocker-composerdquo Esta herramienta permite simplificar el uso de Docker generando scripts que
facilitan el disentildeo y la construccion de servicios Con Docker Compose se pueden crear diferentes contenedores
y al mismo tiempo en cada contenedor diferentes servicios En la siguientefigura se muestra el fichero que
define el entorno de UAT con docker-compose
138
139
140
ANEXO C REVISIOacuteN DE REPORTES Y LOGS
C1 Reporte de Logs ofrecido por Robot Framework
Selenium no teniacutea la capacidad nativa de generar informes Este es uno de los motivos por el que se decidioacute
utilizar Robot Framework
Robot Framework genera tres archivos tras la ejecucioacuten de los scripts de pruebas A partir de la informacioacuten
contenida en el fichero ldquooutputxmlrdquo se rellenan las plantillas ldquohtmlrdquo del ldquologrdquo y del reporte El reporte permite
aplicar filtros a los resultados mientras que el ldquologrdquo contiene todos los detalles de la ejecucioacuten
A continuacioacuten se adjuntan las capturas de logs generados por los diferentes paquetes de pruebas desarrollados
C2 Cloud Tab
C21 Administration
141
142
C22 List
143
C23 Manufacturers
144
C24 MAP
145
C3 Configuration Tab
C31 BackupRestore
146
C32 CHT Zones
147
C33 Firmware
148
C34 Groups
149
150
C4 Network Tab
C41 General
151
C42 SSID
C43 CHT
152
C44 VLAN
153
C45 Radius
154
C46 Captive Portal
155
C47 AP Network
156
Como se ha visto reflejado en el conjunto de logs el tiempo total invertido en la ejecucioacuten ha sido de 1 hora 20
minutos y 22 segundos Dichas pruebas realizadas por una persona de forma manual hubiesen requerido como
miacutenimo el doble de tiempo Ya ni mencionar si se aplicase concurrencia en la ejecucioacuten de pruebas
157
ANEXO D DIAGRAMA DE GANTT
7
A mi familia
A mis maestros
A mis amigos
8
9
Agradecimientos
10
11
Resumen
La revolucioacuten tecnoloacutegica que vivimos hoy diacutea enfocada principalmente en el mundo de Internet y aplicaciones
Web estaacute permitiendo que todas las herramientas que tenemos a nuestro alrededor se encuentren en un proceso
de tremenda evolucioacuten y cambio continuo
En este proyecto se ha realizado un estudio del arte sobre una teacutecnica que permite mejorar el proceso de
automatizacioacuten de pruebas sobre una aplicacioacuten Web basaacutendose en el modelado de la aplicacioacuten para
proporcionar una abstraccioacuten en la implementacioacuten de las pruebas Tambiacuteeacuten se ha realizado una revisioacuten de los
diferentes modelos de calidad normativas y tipos de prueba de Software Finalmente se ha desarrollado una
herramienta de test comprendida por un conjunto de pruebas de aceptacioacuten automaacuteticas que permiten la
verificacioacuten y validacioacuten de la funcionalidad de la plataforma Web Galgus CHT Cloud Manager
Galgus CHT Cloud Manager es la plataforma Web distribuida ofrecida por Galgus para la gestioacuten de redes
compuestas por puntos de acceso Wifi Estas redes se encuentran instaladas en los diferentes clientes que hacen
uso de los servicios que ofrece Galgus los cuales se basan en la optimizacioacuten del rendimiento y las prestaciones
de las redes Wifi en entornos de alta densidad de usuarios Esto se consigue mediante un software embebido
patentado por Galgus conocido bajo el nombre de Cognitive Hostpot Technology (CHT) el cual es instalado
en los puntos de acceso Dicho software implementa un conjunto de algoritmos y caracteriacutescas colaborativas
para conseguir los objetivos planteados en redes Wifi
Como resultado del trabjo podemos proporcionar a los ingenieros de pruebas una herramienta con la que poder
automatizar el testeo de una plataforma Web De esta forma se consigue agilizar el proceso de pruebas y reducir
costes y esfuerzos en tareas repetitivas que anteriormente se haciacutean de forma manual
12
13
Abstract
The technological revolution we are living today focused mainly on the Internet world and therewith the Web
applications is allowing all the tools we have around us to be in a process of continuous evolution and change
In this project we have made a study of the art on a technique that allows to improve the process of automation
of testing on a Web application based on the modelling of the application to provide an abstraction in the
implementation of testing A review of the different quality models standards and types of software testing has
also been carried out Finally a tool comprised of a set of automated acceptance tests has been developed to
allow verification and validation of the functionality of the Galgus CHT Cloud Manager Web platform
Galgus CHT Cloud Manager is the distributed web platform offered by Galgus for the management of
networks composed by Wifi access points These networks are installed in the different clients that make
use of the services offered by Galgus which are based on the optimization of the performance and features
of Wifi networks in high user density environments This is achieved through an embedded software
patented by Galgus known as Cognitive Hostpot Technology (CHT) which is installed in the access points
This software implements a set of algorithms and collaborative features to achieve the objectives set in Wifi
networks
This allows us to provide quality assurance engineers with a tool to automate the testing of a Web platform In
this way the testing process is streamlined and costs and efforts are reduced in repetitive tasks that previously
used to be done manually
14
15
Iacutendice
Agradecimientos 9
Resumen 11
Abstract 13
Iacutendice 15
Iacutendice de Figuras 19
Glosario 24
1 Introduccioacuten 27 11 Motivacioacuten 28 12 Alcance y Objetivos 29 13 Estructura de la memoria 30
2 Estudio del Arte y Revisioacuten 32 21 Model Based Testing (MBT) 32
211 Introduccioacuten 32 212 iquestQueacute es Model Based Testing 33 213 iquestCoacutemo funciona Model Based Testing 33 214 Consideraciones para la aplicacioacuten de Model Based Testing (MBT) 36 215 Beneficios de Model Based Testing (MBT) 37 216 Problemas y Limitaciones de Model Based Testing (MBT) 38 217 Cuando elegir Model Based Testing (MBT) 38
22 Gestioacuten de Calidad Software 39 221 Introduccioacuten 39 222 Concepto de Calidad 39 223 Modelos de Calidad de Software 40 224 Principales Ventajas e Inconvenientes de Modelos de Calidad anteriores 44 225 Conclusiones 44
3 Marco Teoacuterico Pruebas de Software 46 31 Testing y Pruebas de Software 46 32 Principios de las Pruebas de Software 47 33 Proceso de Pruebas de Software Anaacutelisis disentildeo e implementacioacuten 48
331 Terminologiacutea 48 332 Proceso de Pruebas de Software 49
34 Clasificacioacuten de Pruebas de Software 51 341 Pruebas Funcionales 51 342 Pruebas No Funcionales 52 343 Pruebas Estructurales 54 344 Pruebas debidas a Cambios 54
35 Niveles de Prueba 54 351 Pruebas a Nivel de Componente 55 352 Pruebas a Nivel de Integracioacuten 55 353 Pruebas a Nivel de Aceptacioacuten 55
16
36 Dificultades de pruebas en aplicaciones Web e impacto 56
4 Sistema Galgus CHT Cloud Manager 58 41 Arquitectura y Descripcioacuten del Sistema 58
411 Puntos de Acceso (OpenWRT + CHT) 60 412 Broacuteker de Eventos AMQP (RabbitMQ) 61 413 Frontend 62 414 Zone Manager 62 415 MoMap 63 416 Servidor de Licencias 64
42 Alcance y Objetivos de las pruebas sobre el sistema planteado 65 43 Arquitectura de la Solucioacuten Entorno de UAT para el proceso de pruebas (User Acceptance Test) 67
5 Tecnologiacuteas y Herramientas Usadas 69 51 Selenium 69 52 Selenium WebDriver 70
521 Elementos del Navegador 70 53 Robot Framework (RF) 72
531 Estilo de representacioacuten Given-When-Then 72 532 Reportes 75 533 Libreriacuteas 76 534 Documentacioacuten 77
54 Pycharm (IDE) 78 55 GitGitlab 78
551 Git 78 552 Gitlab 78
56 Redmine 78 561 Uso en el Proyecto Galgus CHT Cloud Manager (Metodologiacutea Scrum) 79
6 Experimentos 82 61 Estructura del Proyecto 83 62 Vista de Gestioacuten Principal (Cloud Tab) 87
621 Administration 87 622 List 89 623 Manufacturer 90 624 MAP 92
63 Vista de Configuracioacuten (Configuration Tab) 95 631 Groups 95 632 CHT Zones 98 633 BackupRestore 100 634 Firmware 101
64 Vista de Red (Network Tab) 104 641 VLANS amp Bridges 104 642 SSIDs 106 643 CHT 108 644 Radius 110 645 Captive Portal 112 646 General 115 647 AP Network 117
7 Lineas de Mejora y Conclusiones 122 71 Liacuteneas de Mejora Futuras 122 72 Conclusiones Finales 123
Referencias 126
17
Anexo A Preparacioacuten del Entorno de Trabajo y Ejecucioacuten de Pruebas 128 A1 Preparacioacuten del entorno de trabajo 128
A11 Pip 128 A12 Virtualenv Entorno Virtual 128 A13 Selenium y Chromedriver 129 A14 Robot Framework y SeleniumLibrary 129 A15 Otras dependencias 130
A2 Ejecucioacuten de Pruebas 130 A3 Script de Prueba U007 (MAP) 132
Anexo B Docker de Robot Framework y Entorno de UAT Dockerizado 136 B1 Docker de Robot Framework 136 B2 Entorno de UAT Dockerizado 137
Anexo C Revisioacuten de Reportes y Logs 140 C1 Reporte de Logs ofrecido por Robot Framework 140 C2 Cloud Tab 140
C21 Administration 140 C22 List 142 C23 Manufacturers 143 C24 MAP 144
C3 Configuration Tab 145 C31 BackupRestore 145 C32 CHT Zones 146 C33 Firmware 147 C34 Groups 148
C4 Network Tab 150 C41 General 150 C42 SSID 151 C43 CHT 151 C44 VLAN 152 C45 Radius 153 C46 Captive Portal 154 C47 AP Network 155
Anexo D Diagrama de Gantt 157
18
19
IacuteNDICE DE FIGURAS
Figura 1 Fuente de datos Morgan Stanley 27
Figura 2 Manual Testing vs Automated Testing [20] 28
Figura 3 Fase de Pruebas y Validacioacuten 32
Figura 4 Esquema baacutesico de Model Based Testing 33
Figura 5 Proceso detallado de Model Based Testing (MBT) 34
Figura 6 Construccioacuten del Modelo 34
Figura 7 Concepto de Calidad 39
Figura 8 Liacutenea de tiempo de modelos a nivel de proceso 40
Figura 9 Logo de ITIL 40
Figura 10 ISOIEC 20000 41
Figura 11 Logo de WebQEM 41
Figura 12 Liacutenea de tiempo de modelos a nivel de producto 42
Figura 13 Esquema de ISO 9126 42
Figura 14 Esquema de ISOIEC 25000 43
Figura 15 Principios de las Pruebas de Software 47
Figura 16 Terminologiacutea para el proceso de pruebas 48
Figura 17 Proceso de Pruebas de Software 49
Figura 18 Clasificacioacuten de Pruebas de Software 51
Figura 19 Pruebas de Caja Negra 51
Figura 20 Pruebas de Rendimiento 52
Figura 21 Pruebas de Carga 52
Figura 22 Pruebas de Estreacutes 52
Figura 23 Pruebas de Usabilidad 53
Figura 24 Pruebas de Portabilidad 53
Figura 25 Pruebas de Caja Blanca 54
Figura 26 Modelo de desarrollo en V 55
Figura 27 Dificultades de pruebas en aplicaciones Web e impacto 56
Figura 28 Logo de Galgus 58
Figura 29 Arquitectura de CHT Cloud Manager 59
Figura 30 CHT_CLI 60
Figura 31 Plataforma de Gestioacuten de RabbitMQ 61
Figura 32 Patroacuten PublicadorSuscriptor 61
Figura 33 Ejemplo de Interfaz Graacutefica de un Zone Manager 62
Figura 34 Ejemplo de Interfaz Graacutefica de MoMap 63
20
Figura 35 Interfaz Graacutefica del Servidor de Licencias 64
Figura 36 Zero-Touch Provisioning (ZTP) 64
Figura 37 Test Plan de CHT Cloud Manager 65
Figura 38 Leyenda del Test Plan 66
Figura 39 Control de Versiones del Test Plan 66
Figura 40 Entorno de UAT con Docker (Anexo B) 67
Figura 41 Implementaciones disponibles de Selenium y Navegadores Web Compatibles 70
Figura 42 Coacutedigo de ejemplo con Python y Selenium 71
Figura 43 Estilo de representacioacuten Given-When-Then 72
Figura 44 Implementacioacuten de Pruebas en para el inicio de sesioacuten de CHT Cloud Manager 74
Figura 45 Ejemplo de reporte de pruebas automatizadas con Robot Framework 75
Figura 46 Ejemplo de documentacioacuten generada con Libdoc 77
Figura 47 Ejemplo de documentacioacuten generada con Testdoc 77
Figura 48 Ejemplo de Flujo de Trabajo en Redmine para Galgus CHT Cloud Manager 79
Figura 49 Esquema Graacutefico de Metodologiacutea Scrum 79
Figura 50 Logo de Galgus CHT Cloud Manager 82
Figura 51 Estructura del Proyecto 83
Figura 52 Fragmento del fichero ldquoSelectorpyrdquo 83
Figura 53 Fragmento del fichero ldquoCommon_Keywordsrobotrdquo 84
Figura 54 Fragmento del fichero de Configuracioacuten de pruebas ldquoConfigurationrobotrdquo 84
Figura 55 Diagrama de paquetes del proyecto de pruebas 85
Figura 56 Estructura de una Suite de Pruebas 85
Figura 57 Ejemplo de ldquoTest Setuprdquo personalizado para un caso de prueba 86
Figura 58 Vista de Gestioacuten Principal (Cloud Tab) 87
Figura 59 Pestantildea ldquoAdministrationrdquo 87
Figura 60 Diagramas de Flujo de Casos de Prueba U0025 y U0027 88
Figura 61 Script de Pruebas U0025 88
Figura 62 Keyword ldquoEdit Fieldsrdquo 88
Figura 63 Pestantildea ldquoList of Zone Managersrdquo 89
Figura 64 Diagrama de flujo de Caso de Prueba U0023 89
Figura 65 Script de Prueba U0023 90
Figura 66 Keyword ldquoZone Manager is registered successfullyrdquo 90
Figura 67 Seccioacuten de Fabricantes 90
Figura 68 Diagrama de flujo de Caso de Prueba U0009 91
Figura 69 Script de Prueba U0009 91
Figura 70 Toast Success 92
Figura 71 Keyword ldquoCorrectly Createrdquo 92
Figura 72 Setup amp Teardown de U0008 92
21
Figura 73 Mapa de Zone Managers 92
Figura 74 Funcioacuten que dibuja los ZM en el Mapa y obtiene los piacutexeles en pantalla 93
Figura 75 Diagrama de Flujo de Caso de Prueba U0007 94
Figura 76 Pestantildea ldquoGroupsrdquo 95
Figura 77 Diagrama de flujo de Caso de Prueba U0119 96
Figura 78 Script de Prueba U0119 97
Figura 79 Keyword ldquoVerify if AP is registered Succesfully on grouprdquo 97
Figura 80 Keywords Input Into Text Field y Clear Field Of Characters 97
Figura 81 Pestantildea ldquoCHT Zonesrdquo 98
Figura 82 Diagrama de Flujo de Caso de Prueba U0204 99
Figura 83 Scripts de Prueba U0204 99
Figura 84 Keyword Add Zone CHT to AP 99
Figura 85 Pestantildea BackupRestore 100
Figura 86 Diagrama de Flujo de Caso de Prueba U0401 101
Figura 87 Script de Prueba U0401 101
Figura 88 Keyword Restore For AP hace done successfully 101
Figura 89 Pestantildea ldquoFirmwarerdquo 102
Figura 90 Diagrama de Flujo de Caso de Prueba U0303 103
Figura 91 Script de Prueba U0303 103
Figura 92 Keyword Flash AP 103
Figura 93 Pestantildea ldquoVLAN amp Bridgesrdquo 104
Figura 94 Diagrama de Flujo de Caso de Prueba U0527 105
Figura 95 Script de Prueba U0527 105
Figura 96 Keyword Go And Create VLAN 105
Figura 97 Pestantildea SSIDs 106
Figura 98 Diagrama de Flujo de Caso de Prueba U0530 106
Figura 99 Script de Prueba U0530 107
Figura 100 Keyword Go And Create SSID 107
Figura 101 Pestantildea ldquoCHTrdquo 108
Figura 102 Diagrama de Flujo de Caso de Prueba U0539 109
Figura 103 Script de Prueba U0539 109
Figura 104 Keyword ACA Is Working 109
Figura 105 Keyword Changes On CLI 110
Figura 106 Comando CHT para obtener el estado del moacutedulo ACA en el punto de acceso 110
Figura 107 Pestantildea ldquoRadiusrdquo 110
Figura 108 Escenario de Funcionamiento de Servidor Radius 110
Figura 109 Diagrama de Flujo de Caso de Prueba U0601 111
Figura 110 Script de Prueba U0601 111
Figura 111 Keyword Create Radius Profile 112
22
Figura 112 Pestantildea Captive Portals 112
Figura 113 Escenario de Funcionamiento de un Portal Cautivo 112
Figura 114 Diagrama de Flujo de Caso de Prueba U0701 113
Figura 115 Script de Prueba U0701 113
Figura 116 Keyword Edit or Delete Captive Portal Profile 114
Figura 117 Pestantildea General 115
Figura 118 Diagrama de Flujo de Caso de Prueba U0522 116
Figura 119 Script de Prueba U0522 116
Figura 120 Keyword Check Number of Clients Increases 116
Figura 121 Pestantildea AP Network 117
Figura 122 Libreriacutea SSH para Robot Framework 117
Figura 123 Ventana de Configuracioacuten de TC Rules 118
Figura 124 Diagrama de Flujo de Caso de Prueba U0511 119
Figura 125 Script de Prueba U0511 120
Figura 126 Keyword Wait Timer 120
Figura 127 Keyword Check On CLI 120
23
24
GLOSARIO
CHT Cognitive Hostpot Technology
BDD Behaviour-Driven Development
MBT Model Based Testing
API Application Programing Interface
UAT User Acceptance Testing
SUT System Under Test
UML Unified Modeling Language
FSM Finite State Machine
RAE Real Academia Espantildeola
IEEE Institute of Electronical and Electronics Engineers
ITIL Information Technology Infrastructure Library
ISO International Organization for Standardization
WebQEM Web-site Quality Evaluation method
ISTQB International Software Testing Qualifications Board
TDD Test-Driven Development
SOA Service Oriented Architecture
WiFi Wireless Fidelity
MGR Manager Module
SB Smart Band Steering Module
TCM Traffic Congestion Management Module
LOC Localization Module
POWER Power Control Module
SR Smart Roaming Module
LB Load Balancing Module
AMQP Advance Message Queuing Protocol
HTML HyperText Markup Language
CSS Cascading Style Sheets
HTTPS HyperText Transfer Protocol Secure
TLS Transport Layer Security
REST REpresentational State Transfer
JSON JavaScript Object Notation
DOM Document Object Model
SQL Structure Query Language
ZMB Zone Manager Backend
ZTP Zero-Touch Provisioning
25
RF Robot Framework
CICD Continuous IntegrationContinuous Delivery
SSH Secure SHell
SCP Secure Copy ProtocolSimple Communication Protocol
26
27
1 INTRODUCCIOacuteN
ctualmente el desarrollo software se encuentra en un proceso revolucionario cuyo principal objetivo y
tendencia es la implantacioacuten y desarrollo de software distribuido donde se marcan como principales
objetivos la disponibilidad usabilidad y funcionalidad de cualquier aplicacioacuten a traveacutes de internet Es
aquiacute donde entran en juego entre otros el desarrollo de aplicaciones o servicios Web sustituyendo en gran
medida al desarrollo de aplicaciones y servicios de escritorio
Figura 1 Fuente de datos Morgan Stanley
Muchos son los aspectos a tener en cuenta entre los que cabe destacar la eficiencia la velocidad de respuesta y
de navegacioacuten los cuales para algunos servicios Web son excelentes pero para otros auacuten se encuentran en un
proceso de mejora Esto es debido a que gran cantidad de aplicaciones requieren de un buen disentildeo donde se
optimicen el uso de los recursos disponibles como el ancho de banda memoria carga del servidor respaldo
seguridad etc
A
Hemos establecido la civilizacioacuten de manera que los
maacutes cruciales elementos dependen de la ciencia y la
tecnologiacutea
Carl Sagan
28
11 Motivacioacuten
La gran demanda de servicios y aplicaciones Web distribuidas que permitan gestionar agilizar y simplificar
cualquier aacutembito de negocio hace que cada vez maacutes que dichas aplicaciones contemplen un mayor
conjunto de requisitos solicitados por los clientes lo cual se traduce en un mayor nuacutemero de funcionalidades
y casos de uso contemplados en dichas aplicaciones
Ademaacutes dichas aplicaciones se necesitan cada vez en un menor tiempo lo cual conlleva a reducir los
periodos en las diversas fases por las que pasa un proyecto software desde la fase de disentildeo hasta la de
pruebas Es en esta uacuteltima donde antes de ser entregada al cliente como un producto se detectan los
posibles errores e incluso se puede evaluar si la funcionalidad ofrecida por la aplicacioacuten esta alineada con
los requisitos demandados por el cliente
Los fallos o errores en las aplicaciones Web mal probadas bien por falta de asignacioacuten de tiempo o recursos
a la fase de pruebas tienen una mayor repercusioacuten teniendo el potencial de generar una gran cantidad de
quejas e insatisfaccioacuten por parte de los clientes casi inmediatamente En el caso de las aplicaciones Web
no soacutelo se trata de peacuterdidas econoacutemicas sino tambieacuten de peacuterdida de prestigio fiabilidad y credibilidad por
parte de nuestros usuarios o clientes Los consumidores de hoy demandan una tecnologiacutea intuitiva y de
confianza en un mercado en continuo crecimiento donde un pequentildeo error puede acarrear falta de
satisfaccioacuten en un usuario peacuterdidas millonarias a una empresa o incluso dantildeos humanos Y es en este tipo
de ciclos iterativos y raacutepidamente cambiantes donde la automatizacioacuten de pruebas juega un papel decisivo
iquestY cuaacutel es la causa de estos problemas Para ello debemos tener en cuenta que estos sistemas son disentildeados
por el ser humano el cual comete fallos ya sea por presioacuten en los plazos de trabajo por la complejidad del
coacutedigo o de la infraestructura por cambios de tecnologiacuteas o por cualquier otra interaccioacuten con el sistema
Como ha quedado reflejado un proceso riguroso de control de sistemas y documentacioacuten permiten
bull Ayudar a reducir el riesgo de los posibles fallos y Mejora la calidad de los sistemas a la hora de ser
usados
bull Un correcto mantenimiento del producto a lo largo del ciclo de desarrollo
bull Un cumplimiento de requisitos legales (normas nacionales e internacionales ordenanzas
municipales etc)
bull Una adecuacioacuten de un sistema a los requisitos contractuales
bull Una adaptacioacuten de estaacutendars especiacuteficos de la industria
La forma en la que se logre y las herramientas empleadas variaraacuten en funcioacuten de factores como la
envergadura y tipo de proyecto den cuanto a los riesgos tecnoloacutegicos de seguridad o de negocio asiacute como
del presupuesto y tiempo disponible
Figura 2 Manual Testing vs Automated Testing [20]
29
12 Alcance y Objetivos
Las pruebas de software o software testing pueden llevarse a la praacutectica de muacuteltiples maneras pero el
presente proyecto se centra en el componente funcional del producto enfocado en lo que hace el sistema y
no coacutemo primando la aceptacioacuten por parte de los usuarios en base a los requisitos de disentildeo originales Es
decir el punto de mira estaacute en cumplir los requisitos establecidos por el cliente dejando fuera del alcance
del proyecto la estructura del coacutedigo fuente implementado
Bajo este contexto se plantea la automatizacioacuten de la fase de pruebas de una aplicacioacuten Web distribuida
centrando el enfoque de este proyecto en la automatizacioacuten de pruebas funcionales maacutes concretamente
pruebas de humo or smoke tests y aceptacioacuten Hasta ahora dichas pruebas se realizaban manualmente por
un ingeniero de pruebas lo cual permitiacutea evaluar la calidad del producto que seriacutea entregado al cliente
Ademaacutes se realizaraacute un marco teoacuterico donde se resumiraacuten una clasificacioacuten de los diferentes tipos de
pruebas software que pueden realizarse sobre una aplicacioacuten
Concretamente la solucioacuten abordada en esta memoria se cintildee al mantenimiento de un producto Web como
es la plataforma Galgus CHT Cloud Manager Para ello se cubriraacuten un gran conjunto de funcionalidades
ofrecidas por dicha aplicacioacuten Web como por ejemplo inicio y cierre de sesioacuten flujos de navegacioacuten
comprobacioacuten de los elementos mostrados y uso de la caja de buacutesquedas Sin llegar a ser exhaustivos este
tipo de pruebas conocidas como smoke tests son faacutecilmente automatizables y permiten detectar las primeras
sentildeales de que un sistema no funciona de manera correcta Por tanto es necesario traducir los requisitos
funcionales a instrucciones de alto nivel faacutecilmente entendibles por personas con poca formacioacuten teacutecnica
dado que seraacute el el resultado mostrado de las pruebas realizadas (informes de pruebas) Estas instrucciones
usaraacuten Behaviour-Driven Development (BDD) para describir interacciones entre el usuario y el sistema
definiendo actor accioacuten y comportamiento esperado del sistema Robot Framework es la herramienta que
se usa para este punto
Una vez tenemos dichas instrucciones se deben traducir de nuevo a un lenguaje de menor nivel como es
Python para implementar los test scripts Estos scripts seraacuten los que Selenium Webdriver procese y traduzca
para comunicarse con el controlador del navegador Web Chrome en nuestro caso a traveacutes de una API
Posteriormente el navegador se encargaraacute de ejecutar los comandos de accioacuten y de devolver la informacioacuten
de estado de vuelta Finalmente Robot Framework elaboraraacute un informe en formato html detallando las
pruebas realizadas resultados de las interacciones tiempos de ejecucioacuten y espera errores producidos etc
Tambieacuten se realizaraacute un estudio del arte sobre una teacutecnica conocida como Model Based Testing (MBT)
Dicha teacutecnica permite la generacioacuten automaacutetica de las pruebas a realizar sobre un sistema partiendo del
modelado del comportamiento de dicho sistema Ademaacutes esta teacutecnica tambieacuten abarca la traduccioacuten de las
pruebas generadas en scripts ejecutables para aplicar dichas pruebas sobre el sistema dando tambiacuteeacuten la
posibilidad de evaluar los resultados Esto proporciona muchas ventajas sobre la fase de pruebas pero a la
vez tambieacuten requiere un mayor esfuerzo en la fase de disentildeo y una presencia continua de la fase de pruebas
en otras etapas del ciclo de vida del proyecto Tambieacuten se presentaraacute un conjunto de normativas que regula
y normaliza la gestioacuten de calidad software
Posteriormente se describiraacute el sistema sobre el cual se basa la aplicacioacuten bajo pruebas llamada CHT
Cloud Manager Se presentaraacute la arquitectura de la aplicacioacuten y posteriormente se destacaraacuten los objetivos
de automatizacioacuten de testeo sobre la misma proponiendo el entorno de UAT planteado para someter la
aplicacioacuten a las pruebas automaacuteticas desarrolladas Se dedicaraacute una seccioacuten a analizar las tecnologiacuteas y
herramientas usadas donde se centraraacute la atencioacuten en Robot Framework Selenium y Python como las
tecnologiacuteas usadas para automatizar el testeo Ademaacutes se destacaraacute la integracioacuten del entorno de UAT
como fase de la integracioacuten continua de la aplicacioacuten ademaacutes de la metodologiacutea de trabajo llevada a cabo
Finalmente se presentaraacuten algunos experimentos y demostraciones de uso de la herramienta desarrollada
se describiraacuten algunas liacuteneas de mejora y conclusiones y se incluiraacuten algunos posibles anexos para la puesta
en marcha de la aplicacioacuten y reportes de algunas pruebas entre otros
30
13 Estructura de la memoria
El siguiente esquema resume de forma geneacuterica los puntos tratados en esta memoria para que el lector pueda
tener una idea orientativa de la organizacioacuten de este documento
1 Introduccioacuten En este punto se abordan temas geneacutericos como los objetivos motivacioacuten y alcance de
forma que pueda adquirirse una breve aproximacioacuten a los detalles del proyecto
2 Estudio del Arte y Revisioacuten A lo largo de esta seccioacuten se presentaraacute un estudio sobre la teacutecnica
conocida como Model Based Testing la cual permitiriacutea mejorar el proceso de automatizacioacuten de
pruebas Ademaacutes se realiza una revisioacuten sobre la gestioacuten de Calidad Software presentado algunos
modelos existentes en la actualidad
3 Marco Teoacuterico Consta de un estudio sobre el proceso de pruebas en un proyecto Software y los
principales tipos de pruebas Software existentes
4 Sistema En este punto se presenta la arquitectura del sistema sobre el que se van a automatizar las
pruebas de aceptacioacuten o Smoke Tests Ademaacutes se describe el alcance y objetivos de dichas pruebas y
se presenta la arquitectura de la solucioacuten planteada como escenario de pruebas haciendo uso de Docker
como tecnologiacutea de automatizacioacuten en el despliegue de aplicaciones software alojadas en contenedores
de software
5 Tecnologiacuteas y Herramientas usadas Consta del conjunto de tecnologiacuteas usadas para la
implementacioacuten de las pruebas de aceptacioacuten automatizadas y las herramientas para utilizar dichas
pruebas y para gestionar el trabajo del equipo de desarrollo y calidad responsable de este proyecto
6 Experimentos Consta de un detalle sobre la funcionalidad de un conjunto de pruebas que han sido
implementadas para verificar y validar el funcionamiento esperado del sistema Para cada prueba se
definen criterios de aceptacioacuten diagramas de flujo y scripts de implementacioacuten detallando algunas de
las implementaciones clave
7 Liacuteneas de Mejora y Conclusiones Se incluye una seccioacuten conclusiones finales tras la realizacioacuten del
proyecto y una valoracioacuten del mismo a nivel general y personal Ademaacutes se destacaraacuten algunas liacuteneas
de mejora futuras relacionadas principalmente con la aplicacioacuten de Model Based Testing (MBT) y otros
aspectos sobre la implementacioacuten actual de la herramienta de automatizacioacuten
Ademaacutes se realizaraacute una seccioacuten de anexos en el que se trataraacuten puntos adicionales sobre el proyecto
bull Anexo A Preparacioacuten del Entorno de Trabajo y Ejecucioacuten de Pruebas
bull Anexo B Docker de Robot Framework y Entorno de UAT Dockerizado
bull Anexo C Revisioacuten de Reportes y Logs
31
32
2 ESTUDIO DEL ARTE Y REVISIOacuteN
n este punto se realizaraacute un estudio sobre el marco teoacuterico de una de las teacutecnicas existentes que permite
la generacioacuten y ejecucioacuten automaacutetica de casos de test a partir del modelado de un sistema para la fase
de pruebas de una aplicacioacuten Esta teacutecnica es conocida como Model Based Testing (MBT) Ademaacutes
se realizaraacute una revisioacuten de la normativa relacionada con la gestioacuten de calidad software analizando la familia de
normas ISOIEC 25000
21 Model Based Testing (MBT)
211 Introduccioacuten
Dada la rapidez con la que se demandan los servicios contratados por los clientes en muchas ocasiones la
mayoriacutea del tiempo y esfuerzo asignado para la realizacioacuten de proyectos de software van destinados a la
labor de desarrollo dedicando menos esfuerzos en otras fases del ciclo de vida de un proyecto como las
fases de disentildeo o de pruebas Esto puede conllevar a que el proyecto no se desarrolle de acuerdo con los
requisitos demandados por los clientes y que el nuacutemero de puntos de fallo del producto software aumente
La fase de testeo o prueba de un producto software durante su ciclo de vida es una etapa fundamental para
validar la calidad del producto desarrollado y ofrecido a un cliente para conseguir un grado de satisfaccioacuten
aceptable de forma que se cumpla con los requisitos demandados y con el menor grado de error posible
Figura 3 Fase de Pruebas y Validacioacuten
Uno de los factores por los que en ocasiones no se emplean suficientes recursos a la fase de pruebas es la
gran cantidad de casos de pruebas que se deben realizar para validar un sistema Por cada caso de prueba
se deben asignar recursos relacionados con la planificacioacuten disentildeo y ejecucioacuten del mismo
Por tanto en este punto cabe plantearse la idea de automatizar no solo los casos de pruebas que validan un
sistema sino la generacioacuten de los casos de prueba Esto puede permitir reducir de forma considerable el
coste y esfuerzos en la fase de pruebas En este contexto surge el concepto de Model Based Testing (MBT)
E
La tecnologiacutea no es en siacute el fin sino el medio entre la
sociedad del conocimiento y el desarrollo mundial
Anoacutenimo
33
212 iquestQueacute es Model Based Testing
Este se trata de un meacutetodo capaz de controlar la calidad del software durante su ciclo de vida permitiendo
la generacioacuten automaacutetica de los casos de prueba e incluso la ejecucioacuten y evaluacioacuten automaacutetica de
resultados Para ello se requiere de un modelado y disentildeo correcto del sistema bajo pruebas como base
para la aplicacioacuten de esta teacutecnica
Figura 4 Esquema baacutesico de Model Based Testing
MBT permite crear un modelo del comportamiento esperado por el sistema a traveacutes del cual permite la
aplicacioacuten de diferentes teacutecnicas para la generacioacuten de casos de prueba [1]
bull Generacioacuten de casos de pruebas con datos de entrada sobre un modelo de dominio del sistema bull Generacioacuten de casos de pruebas de un modelo de entorno bull Generacioacuten de casos de prueba con predicciones del comportamiento del modelo bull Generacioacuten de scripts de prueba a partir de pruebas abstractas
213 iquestCoacutemo funciona Model Based Testing
En primer lugar se requiere del disentildeo de un modelo del sistema bajo test el cual debe tener al menos dos
caracteriacutesticas principales debe ser pequentildeo en relacioacuten al tamantildeo del sistema de forma que no requiera
un coste elevado pero debe ser lo suficientemente detallado para describir completamente las
caracteriacutesticas que se quieran probar sobre el sistema
Una vez implementado el modelo del sistema a probar se procederiacutea a la utilizacioacuten de herramientas
basadas en la teacutecnica MBT para generar automaacuteticamente el banco de pruebas a partir del modelo del
sistema bajo test (SUT) Estos bancos de pruebas generados seraacuten un conjunto de pruebas abstractas cada
una de las cuales define la secuencia de operaciones a realizar para probar una funcionalidad determinada
con sus respectivos valores o datos de entrada necesarios y las salidas o respuestas del sistema que se
esperan
A partir del banco de pruebas abstractas se deben transformar en scripts de pruebas ejecutables lo cual
puede realizarse con herramientas basadas en la teacutecnica MBT Estos scripts podriacutean ser ejecutados para la
deteccioacuten de errores sobre el sistema bajo test y esta ejecucioacuten podriacutea ser controlada y monitorizada por
alguna herramienta de ejecucioacuten de pruebas
En el siguiente diagrama se muestra el proceso de aplicacioacuten de este meacutetodo donde se propone dividir el
proceso en cinco fases principales [1]
1 Modelado Modelar el sistema bajo test y su entorno 2 Generacioacuten Generar las pruebas abstractas a partir del modelo planteado en la fase anterior 3 Concretizado Concretizar o adaptar las pruebas abstractas para transformarlas en ejecutables 4 Ejecucioacuten Ejecutar las pruebas sobre el sistema bajo test y definir decisiones o veredictos para las
mismas de forma que se pueda determinar el correcto funcionamiento del sistema bajo test 5 Anaacutelisis Analizar los resultados obtenidos a partir de la ejecucioacuten de los casos de prueba
34
Destacar que para el generador de casos de prueba y el script de pruebas se suelen usar herramientas de pruebas
especiales Por este motivo se encuentran resaltados en negrita
Figura 5 Proceso detallado de Model Based Testing (MBT)
Una vez presentado el proceso o metodologiacutea para llevar a cabo dicha teacutecnica se describiraacuten las principales
fases
2131 Construccioacuten del Modelo
Dicha fase consiste en la construccioacuten de un modelo que represente el comportamiento detallado del sistema
bajo pruebas yo su entorno a partir de los requisitos de disentildeo del mismo y el plan de pruebas desarrollado para
cumplir con estos requisitos
Este es el paso maacutes importante en la aplicacioacuten de la teacutecnica Model Based Testing ya que el resto de fases
dependeraacute siempre del modelo del sistema bajo pruebas Cuanto maacutes completo sea el modelo maacutes efectivos
seraacuten los casos de prueba generados a partir de este
Figura 6 Construccioacuten del Modelo
35
Para llevar a cabo el modelo del comportamiento de la aplicacioacuten se requiere conocer exactamente el
comportamiento esperado de la misma lo cual lleva a estudiar y analizar en profundidad el sistema y su entorno
previamente
Existen diversas especificaciones formales para el modelado a partir de los requisitos como por ejemplo los
diagramas UML Estos ayudan a que el modelado sea una tarea algo maacutes sencilla de realizar que si se llevara a
cabo a partir de los requisitos escritos en lenguaje natural Por otro lado para modelar el comportamiento existen
diversas teacutecnicas como las maacutequinas de estados finitos (FSM) Cadenas de Maacuterkov Tablas de decisiones
Diagramas de estados etc
En conclusioacuten modelar un sistema no es una tarea sencilla ya que requiere de habilidades teacutecnicas experiencia
e imaginacioacuten para construir un modelo que se comporte de la forma deseada Dicho modelo debe cumplir con
las siguientes propiedades [2]
bull Debe ser lo maacutes abstracto posible sin perder la informacioacuten importante
bull No debe contener informacioacuten que sea redundante o que no esteacute relacionada con el alcance de las
pruebas
bull Debe ser entendible para los ingenieros de pruebas incluso a expensas de la brevedad y abstraccioacuten del
mismo
bull Debe ser flexible y abierto para permitir cambios y antildeadir o eliminar nuevas funcionalidades
bull Debe considerar todos los detalles de implementacioacuten de las pruebas
2132 Generacioacuten de Casos de Prueba
Los casos de prueba seraacuten generados tras la construccioacuten previa del modelo del sistema Antes de la creacioacuten de
los casos de prueba los ingenieros de pruebas deben especificar o proveer informacioacuten sobre el criterio o
propoacutesito de los casos de prueba las entradas y en algunos casos las salidas esperadas del sistema
Destacar que generar las salidas esperadas correspondientes a unas determinadas entradas es maacutes complejo que
generar soacutelo las entradas Para ello se necesita un oraacuteculo que cree salidas vaacutelidas y las mapee a los casos de
prueba Crear el oraacuteculo es la tarea maacutes compleja
Las dificultades presentadas en esta fase dependeraacuten de si el modelo es complejo o simple y la efectividad de
los casos de prueba generados dependeraacute de lo completo y preciso que sea dicho modelo para poder generar
automaacuteticamente los casos de prueba
Cuando el sistema es complejo la cantidad de casos de test es muy grande e incluso infinita Por tanto evaluar
todos los casos de test resulta inviable y costoso En este caso para mejorar la calidad del sistema se necesita
seleccionar los casos de test que realmente puedan ayudar a localizar tantos fallos como sea posible con un coste
aceptable
Existen diferentes criterios de cobertura que permiten ayudar a controlar el proceso de generacioacuten de casos de
prueba Sin embargo se recomienda seleccionar maacutes de uno de estos criterios para lograr un mayor resultado en
la cobertura de pruebas
2133 Ejecucioacuten de Casos de Prueba
La ejecucioacuten de los casos de pruebas requiere la transformacioacuten de los mismos en una forma ejecutable Debido
a que los los scripts de pruebas ejecutables pueden ser reutilizados durante todo el tiempo empleado en la
validacioacuten del sistema estos deben ser escritos de una forma maacutes eficiente que permita que sean reutilizables e
incluso que frente a una modificacioacuten sean maacutes faacuteciles generarlos y ejecutarlos Por ello se crean scripts
ejecutables para los casos de prueba abstractos
El proceso de transformacioacuten en pruebas ejecutables seriacutea maacutes eficiente si es hecha de forma automaacutetica
Despueacutes de aplicar los casos de prueba ejecutables al sistema bajo pruebas se obtienen las salidas actuales del
sistema las cuales deberaacuten ser contrastadas con las salidas esperadas
36
2134 Anaacutelisis de los Resultados
Una vez ejecutados los casos de pruebas y obtenidas las salidas actuales del sistema se deben evaluar y analizar
los resultados obtenidos Para ello se debe comparar las salidas actuales obtenidas con las salidas esperadas
especificadas en los casos de prueba Esta tarea de comparacioacuten podriacutea realizarse idealmente de forma
automaacutetica lo cual dariacutea como resultados posibles
1 Pasa Cuando las salidas actuales se encuentran acordes con las salidas esperadas
2 Falla Cuando las salidas actuales no se encuentran acordes con las salidas esperadas
3 Inconcluso Cuando no se puede tomar una decisioacuten en el momento
Hay que destacar que puede darse el caso en el que si las salidas esperadas no estaacuten bien determinadas los
resultados obtenidos al contrastar dichas salidas con las actuales sean falsos dando lugar a resultados sin utilidad
y que pueden dar lugar a confusioacuten
Por este motivo la generacioacuten automaacutetica de las salidas esperadas es una tarea compleja e importante en todo el
proceso especialmente en sistemas complejos Por tanto el nivel de dificultad para encontrar un oraacuteculo de
pruebas depende del tamantildeo y complejidad del sistema Sin embargo la necesidad e importancia del oraacuteculo de
pruebas tambieacuten aumenta cuando el sistema es maacutes complejo
Tras obtener los resultados se debe determinar si se decide generar maacutes casos de prueba si se debe modificar el
modelo o si la fase de pruebas debe ser detenida y debe ponerse en marcha el software del sistema que se estaacute
probando
214 Consideraciones para la aplicacioacuten de Model Based Testing (MBT)
Son muchos los artiacuteculos que describen aspectos importantes a tener en cuenta durante el desarrollo o la
aplicacioacuten de esta teacutecnica Algunas de estas consideraciones a destacar seriacutean las siguientes [3]
1 El modelo que describe el comportamiento del sistema es el punto clave
El comportamiento del modelo debe ser desarrollado cuidadosamente Sus limitaciones y restricciones deben
ser respetadas durante el modelado del sistema bajo pruebas De esta forma si el modelo estaacute mal las pruebas
generadas tambieacuten lo estaraacuten Por tanto la exactitud del modelo es fundamental para pasar a la fase de
generacioacuten de casos de prueba
2 Las pruebas deben cubrir los criterios de control de flujo y datos
Los criterios de cobertura de las pruebas definen un conjunto de casos de prueba seleccionados para la misma
Estos casos de pruebas pueden ser generados a partir de dos fuentes criterios de flujo de control o de flujo
de datos En el caso de pruebas aplicadas a grandes sistemas es importante combinar ambos criterios para
incrementar la cobertura de las pruebas
3 El nivel de automatizacioacuten debe ser elevado
El nivel de automatizacioacuten es un factor importante para definir la factibilidad de uso de MBT Normalmente
suele haber un uacutenico paso no automatizado el modelado del comportamiento del sistema el cual es utilizado
como entrada para el proceso de generacioacuten de los casos de prueba Si hubiese otros pasos no automatizados
se incrementariacutea el esfuerzo los costes y la complejidad de su uso
4 Son fundamentales las herramientas que soportan la automatizacioacuten de las fases de MBT
Las herramientas usadas deben soportar la ejecucioacuten de los pasos automatizados Si no hay una herramienta
que soporte un determinado paso esta tarea podriacutea ser difiacutecil e inviable Por tanto una herramienta debe
soportar la integracioacuten entre los diferentes pasos no automatizados y automatizados
5 Los liacutederes del proyecto deben entender las habilidades requeridas y la complejidad para usar
MBT
Las personas encargadas de la fase de pruebas necesitan conocer ademaacutes de las teacutecnicas de pruebas los
lenguajes de modelado y algunos lenguajes de programacioacuten
37
6 El orden de los pasos a seguir mientras se usa un enfoque MBT
Es necesario respetar los pasos seguidos para la generacioacuten de los casos de prueba de forma que sean
respetados en la fase de ejecucioacuten de las pruebas siendo ejecutados en la misma secuencia en que fueron
definidos En caso contrario se podriacutean generar salidas erroacuteneas de dichas pruebas
7 Transferencia de la Tecnologiacutea
Las tecnologiacuteas usadas para la aplicacioacuten de la teacutecnica MBT se transfieren desde entornos acadeacutemicos o de
investigacioacuten para ser implementados en proyectos industriales Por este motivo necesitan ser analizados
cuidadosamente antes de ser usadas
215 Beneficios de Model Based Testing (MBT)
A continuacioacuten se definen diversos beneficios que proporciona la aplicacioacuten de Model Based Testing para la
fase de pruebas [1] [4]
1 Deteccioacuten de Fallos del Sistema Bajo Pruebas
El modelado del comportamiento del sistema bajo pruebas permite detectar errores ambiguumledades o lagunas
que pueden presenciarse en la toma de requisitos especificacioacuten y disentildeo del software Por tanto permite
una deteccioacuten temprana de errores
2 Reduccioacuten de costes y tiempo en la fase de pruebas
La aplicacioacuten de esta teacutecnica contribuye a que el tiempo coste y recursos empleados a la fase de pruebas
disminuya Sin embargo se requiere una mayor asignacioacuten de recursos para el modelado y mantenimiento
del sistema
3 Mejora de la calidad de las pruebas
Cuando las pruebas se desarrollan manualmente la calidad de las mismas es muy dependiente de los
desarrolladores que la implementan Ademaacutes el proceso de disentildeo no puede ser reproducido el criterio
racional aplicado para cada prueba normalmente no es recordado y el resultado de los casos de prueba no es
faacutecilmente interpretado ni contrastado con los requisitos originales del sistema
Model Based Testing es una teacutecnica capaz de mejorar mucho estos inconvenientes que se presentan sobre el
desarrollo de pruebas manuales gracias al generador automatizado de casos de prueba
4 Trazabilidad
Puede definirse como la habilidad para relacionar cada caso de prueba al modelo criterio de seleccioacuten e
incluso a los requisitos informales del sistema Esto ayuda a explicar los casos de prueba asiacute como justificar
por queacute fueron creados Los algoritmos aplicados para la generacioacuten de pruebas deben saber queacute partes del
modelo seraacuten empleadas en cada caso de prueba y las salidas esperadas
5 Evolucioacuten de los requisitos
Si los requisitos del sistema cambian con la aplicacioacuten de Model Based Testing bastariacutea con actualizar el
modelo y las pruebas seraacuten generadas de nuevo de forma automaacutetica Debido a que el modelo es usualmente
maacutes pequentildeo que el conjunto de pruebas del sistema requiere menos tiempo actualizar el modelo que
actualizar todos los casos de prueba Por tanto puede concluirse que se obtiene una respuesta maacutes raacutepida
frente a un cambio en los requisitos
6 Reusabilidad del modelo
El modelo contiene informacioacuten sobre el comportamiento del sistema bajo pruebas Por tanto este puede ser
reutilizado en futuras pruebas incluso cuando los requisitos cambian
38
216 Problemas y Limitaciones de Model Based Testing (MBT)
Una vez destacados los beneficios que aporta dicha teacutecnica tambieacuten es importante detallar algunos problemas
y limitaciones sobre su uso [1] [5]
2161 Problemas
bull Para abordar dicha teacutecnica es necesario que los ingenieros de pruebas tengan habilidades teacutecnicas sobre
la notacioacuten usada para el modelado del sistema Ademaacutes deberiacutean tener experiencia con herramientas
scripts y lenguajes de programacioacuten usados para ejecutar las tareas de Model Based Testing
bull Cuando dicha teacutecnica se pretende aplicar a sistemas complejos el modelado del sistema es maacutes
complejo y existe riesgo de producirse un desbordamiento de la cantidad de casos de prueba generados
a partir del modelo Por esta razoacuten es muy importante definir bien el conjunto de criterios para la
generacioacuten de las pruebas lo cual permite acotar la cobertura de pruebas de forma razonable
bull La automatizacioacuten de la generacioacuten del oraacuteculo de pruebas a partir del modelo es compleja
especialmente en sistemas complejos Cuando el tamantildeo del sistema aumenta la necesidad de
automatizacioacuten tambieacuten aumenta
bull Es necesario desarrollar un modelo de software especiacutefico para un dominio en concreto de aplicacioacuten
ya que existen diversas notaciones de modelado del sistema
bull Es necesario la especificacioacuten formal de los requisitos para obtener el modelo del sistema a partir de
estos La especificacioacuten informal o en lenguaje natural de los requisitos puede dar lugar a ambiguumledades
que dificultan la exactitud en el modelado
2162 Limitaciones
bull No es posible modelar todos los aspectos del comportamiento del sistema bajo pruebas Por tanto es
necesario el uso de otras notaciones de modelado que cubran dichos aspectos
bull Los proyectos software evolucionan continuamente surgiendo nuevos requisitos los cuales algunos
pueden quedar fuera de la fecha de planificacioacuten Si se ha comenzado con el modelado a partir de
requisitos antiguos se construiraacute un modelo erroacuteneo que no reflejaraacute los nuevos requisitos
contemplados lo cual daraacute lugar a errores en el sistema bajo pruebas o resultados no fiables
bull Cuando se produce un fallo en una prueba generada podriacutea resultar maacutes complejo determinar la causa
del fallo ya que la secuencia de pruebas generadas en Model Based Testing podriacutea ser maacutes compleja y
menos intuitiva que las disentildeadas manualmente
217 Cuando elegir Model Based Testing (MBT)
Finamente tras detallar los beneficios problemas y limitaciones sobre la teacutecnica bajo estudio se destacan
algunos puntos principales a tener en cuenta para la aplicacioacuten de dicha teacutecnica
bull Debe existir documentacioacuten lo suficientemente buena sobre el sistema para poder aplicarla
bull Si ya existe un modelo del sistema seriacutea un primer paso que facilitariacutea su aplicacioacuten
bull El manager del proyecto debe ser consciente que la fase de pruebas con Model Based Testing comienza
desde la toma de requisitos ya que se debe modelar el comportamiento del sistema bajo pruebas a partir
de estos Por tanto no se puede esperar que la fase de pruebas comience despueacutes del desarrollo Hacerlo
tras el desarrollo podriacutea significar la modificacioacuten de los requisitos y en consecuencia el desarrollo
39
22 Gestioacuten de Calidad Software
221 Introduccioacuten
En los uacuteltimos antildeos la creciente demanda de productos software principalmente de aplicaciones distribuidas
como los servicios Web provoca que diferentes empresas busquen soluciones software para satisfacer las
necesidades de los clientes Este conjunto de empresas forma un entorno competitivo en el que se intenta buscar
algunos factores para destacar sobre los demaacutes competidores respondiendo a las nuevas exigencias del mercado
Bajo este contexto se plantea la implantacioacuten de una direccioacuten basada en la calidad como la propuesta que
mejores resultados ha ofrecido No solo basta con desarrollar software acorde a los requisitos de los clientes y
las exigencias de los mismos sino que se trata de crear un producto que garantice su correcto funcionamiento
bajo el sustento de una garantiacutea de calidad razonable
El concepto de ldquocalidadrdquo siempre se ha relacionado con la inspeccioacuten de productos fiacutesicos Pero dicho teacutermino
ha ido expandiendo su contexto de una forma maacutes global y aplicable a cualquier tipo de servicio o producto
ofrecido a un cliente
222 Concepto de Calidad
Acorde a la definicioacuten ofrecida por la Real Academia Espantildeola (RAE) la calidad se define como ldquouna propiedad
o conjunto de propiedades inherente a algordquo ldquoAdecuacioacuten de un producto o servicio a las caracteriacutesticas
especificadasrdquo o ldquocondicioacuten o requisito que se pone en un contratordquo [6]
Por otro lado el instituto de Ingenieros Eleacutectricos y Electroacutenicos (IEEE) define la calidad como ldquoel grado con
el que un sistema componente o proceso cumple con los requisitos especificados y las necesidades o
expectativas del cliente o usuariordquo destacando que el eacutenfasis radica en los requisitos especiacuteficos del sistema y
en la buacutesqueda de la satisfaccioacuten del cliente [7]
Roger Pressmann define la Calidad del Software como ldquoConcordancia del software producido con los requisitos
expliacutecitamente establecidos con los estaacutendares de desarrollo prefijados y con los requisitos impliacutecitos no
establecidos formalmente que desea el cliente y en uacuteltima instancia el usuariordquo [8]
Una vez presentado el concepto de calidad su definicioacuten orientada al software se refiere al grado de desempentildeo
de las principales caracteriacutesticas con las que debe cumplir un sistema durante su ciclo de vida Estas
caracteriacutesticas son las que garantizan que el cliente cuente con un sistema confiable lo que permite un aumento
de la satisfaccioacuten frente a la funcionalidad y eficiencia del sistema construido
Figura 7 Concepto de Calidad
40
223 Modelos de Calidad de Software
Los modelos de calidad son aquellos documentos que integran la mayor parte de las mejores praacutecticas proponen
temas de administracioacuten en los que cada organizacioacuten debe hacer eacutenfasis integran diferentes praacutecticas dirigidas
a los procesos clave y permiten medir los avances en calidad
Bajo este contexto los modelos de calidad deben permitir la evaluacioacuten del sistema de forma cualitativa o
cuantitativa y de acuerdo con esta evaluacioacuten la organizacioacuten podraacute proponer implementar estrategias que
permitan la mejora continua en el resto de etapas del ciclo de vida como son las etapas de anaacutelisis disentildeo
desarrollo y pruebas software [7] Desde finales de los antildeos 70 se han ido desarrollando diversos modelos de
calidad del producto software con el fin de fijar una terminologiacutea y entender queacute concepto de calidad se estaacute
usando Asiacute mismo dichos modelos de calidad se clasifican de acuerdo con el enfoque de evaluacioacuten
contemplado ya sea a nivel de proceso producto o calidad de uso
2231 Calidad a Nivel de Proceso
Este enfoque de calidad de software describe que la calidad de un sistema software debe ser implementada desde
el inicio del proyecto y en cada etapa de su ciclo de vida debiendo permitir el control y seguimiento de los
aspectos de calidad para minimizar los riesgos y ofrecer un soporte continuo De esta forma se consigue
garantizar un nivel oacuteptimo de cumplimiento de los factores de calidad definidos teniendo en cuenta que si en
alguna etapa no se verifican dichos factores posiblemente disminuya el nivel de calidad no solo del proceso si
no tambieacuten del producto en desarrollo [7]
A continuacioacuten se muestra una liacutenea de tiempo de algunos modelos a nivel de proceso y se describen dos de los
que maacutes intereacutes presentan dentro del aacutembito de este proyecto
Figura 8 Liacutenea de tiempo de modelos a nivel de proceso
ITIL (Information Technology Infrastructure Library)
Desarrollado en el Reino Unido con el fin de fortalecer la gestioacuten gubernamental a partir de cinco elementos
fundamentales la perspectiva del negocio entrega del servicio soporte del servicio manejo de la infraestructura
y manejo de aplicaciones con el propoacutesito de ofrecer una estructura integral para prestar a la organizacioacuten un
servicio completo cubriendo necesidades de apoyo de instalacioacuten adecuacioacuten de redes comunicaciones
hardware servidores sistema operativo y software necesarios
Figura 9 Logo de ITIL
41
ISOIEC 20000
El objetivo principal de esta norma es avalar que la prestacioacuten de servicios de TI en una empresa cuenta con la
calidad necesaria para brindar dichos servicios a los clientes Esta norma engloba diferentes secciones dedicadas
a las especificaciones de dicha norma y a los coacutedigos de buenas praacutecticas
Figura 10 ISOIEC 20000
WebQEM
Web-site Quality Evaluation Method se trata de una metodologiacutea de evaluacioacuten de calidad de sitios Web en seis fases planificacioacuten y programacioacuten de la evaluacioacuten de la calidad definicioacuten y especificacioacuten de los requisitos de calidad establecidos definicioacuten e implementacioacuten de la evaluacioacuten elemental definicioacuten e implementacioacuten de la evaluacioacuten global anaacutelisis de resultados y evaluacioacuten de meacutetricas y finalmente conclusiones y documentacioacuten
Figura 11 Logo de WebQEM
42
2232 Calidad a Nivel de Producto
El enfoque de la calidad de software a nivel de producto tiene como objetivo especificar y evaluar el
cumplimiento de los criterios del producto Para ello se suelen definir y aplicar medidas o meacutetricas internas o
externas Por esta razoacuten muchas normas definen la calidad a nivel de producto de tipo interna externa y en uso
Esta uacuteltima se define como el conjunto de atributos relacionados con la aceptacioacuten por parte del usuario final y
seguridad
A continuacioacuten se muestra una liacutenea de tiempo de algunos modelos a nivel de proceso y se describen tres de los
que maacutes intereacutes presentan dentro del aacutembito de este proyecto
Figura 12 Liacutenea de tiempo de modelos a nivel de producto
ISO 9126
Este se basa en el modelo McCall el cual es uno de los modelos pioneros en la evaluacioacuten de la calidad de
software Desarrollado en 1991 es un marco normativo dirigido a desarrolladores aseguradores de calidad
evaluadores analistas y cualquier otro involucrado en el proceso de construccioacuten de software y la gestioacuten de
calidad del mismo Estaacute dividido en cuatro partes Modelo de Calidad Meacutetricas Externas Meacutetricas Internas y
Calidad de Meacutetricas en Uso
Esta norma busca la fiabilidad funcionalidad usabilidad eficiencia mantenibilidad y portabilidad en la
construccioacuten de productos software A continuacioacuten se muestra un esquema que resume dichas caracteriacutesticas
y subcaracteriacutesticas [8]
Figura 13 Esquema de ISO 9126
43
ISOIEC 25000
Basada en la norma ISO 9126 y adaptando parte del marco normativo a las necesidades del mercado actual Esta
norma tambieacuten conocida como SQuaRE (Software Product Quality Requirements and Evaluation) establece
un marco de trabajo comuacuten para evaluar la calidad de productos de Software
En dicha norma se definen los modelos teacuterminos y definiciones comunes para el resto de normas que componen
la serie 25000 La ISOIEC 25000 presenta diversas secciones entre las que se puede destacar [9]
ISOIEC 25010 Describe las caracteriacutesticas y subcaracteriacutesiticas de calidad que pueden ser evaluadas
en un producto software diferenciando entre calidad interna externa y de uso En la siguiente figura se
presenta un desglose de dichas caracteriacutesticas
ISOIEC 25040 Define el proceso de evaluacioacuten perioacutedico de la calidad del producto software
Figura 14 Esquema de ISOIEC 25000
44
224 Principales Ventajas e Inconvenientes de Modelos de Calidad anteriores
2241 A nivel de Proceso
Modelo Ventajas Inconvenientes
ITIL bull Mejor estructuracioacuten organizacioacuten y
claridad de los proyectos
bull Mayor control administrativo
bull Mayor eficacia y rapidez ante cambios
bull Incrementa la productividad del negocio y la
fiabilidad de los clientes
bull Tiempo y esfuerzo necesarios
bull Falta de conocimiento para apreciar la mejora
proporcionada
bull Involucracioacuten y compromiso de todo el
personal de la organizacioacuten
bull Frustracioacuten generada por expectativas a corto
plazo
bull No hay mejoriacutea si la inversioacuten asignada para
implantar el modelo es insuficiente
ISOIEC
20000 bull Reconocimiento internacional
bull Muy usado por las organizaciones
WebQUEM bull Calidad medida en fases y actividades de
forma cuantitativa con indicadores
bull Aplicaciones de Software centradas en la Web
son cada vez maacutes complejas provocan mayor
complejidad en su implantacioacuten
2242 A nivel de Producto
Modelo Ventajas Inconvenientes
ISO 9126 bull Determina queacute caracteriacutesticas y
subcaracteriacutesticas son importantes para el
producto
bull Define meacutetricas especiacuteficas para los
componentes Software
bull Define indicadores para las caracteriacutesticas de
calidad
bull Usabilidad tratada desde la perspectiva del
proceso no del producto
bull No tiene en cuenta la caracteriacutestica de ldquofacilidad
de aprendizajerdquo siendo esta recomendada por
otros estaacutendares
bull Meacutetricas complejas difiacutecilmente medibles
Requieren descomposicioacuten
ISOIEC
25000 bull Detecta objetivos del producto alineados con
necesidades reales de clientes finales
bull Evita ineficiencias y maximiza rentabilidad
y calidad del producto
bull El proceso de evaluacioacuten perioacutedica permite
la mejora continua
bull No establece niveles de calidad para cada
proyecto
bull No hace uso de meacutetricas o umbrales de calidad
225 Conclusiones
Una vez presentado el concepto de gestioacuten de calidad de software y los principales modelos y normas es
interesante destacar la diferencia entre calidad interna y externa La calidad interna se centra en las caracteriacutesticas
propias del producto software (disentildeo especificacioneshellip) mientras que la calidad externa lo hace con las
caracteriacutesticas dinaacutemicas del mismo es decir con el comportamiento Es por ello que el proceso de calidad
interna se inicia en las fases tempranas del ciclo de vida de un proyecto mientras la calidad externa se aplica
una vez se tiene un primer prototipo funcional del producto software desarrollado Por tanto se trataraacute de
automatizar el proceso de evaluacioacuten de la calidad externa del proyecto CHT Cloud Manager analizando
verificando y validando automaacuteticamente la aceptacioacuten de dicho producto
45
46
3 MARCO TEOacuteRICO PRUEBAS DE SOFTWARE
ras presentar el concepto de calidad y algunas de las normas y estaacutendares maacutes conocidos que describen
la aplicacioacuten de dicho concepto en el aacutembito del desarrollo de software se centraraacute el enfoque en el
papel del testeo y las pruebas de software Con ello se destacaraacuten algunos puntos principales para
llevar a cabo las pruebas de software el anaacutelisis disentildeo e implementacioacuten de dichas pruebas los diferentes tipos
y niveles de pruebas y las dificultades de la aplicacioacuten de pruebas de software sobre aplicaciones Web
31 Testing y Pruebas de Software
Habitualmente se tiene una percepcioacuten del testing de un producto como una tarea basada en la ejecucioacuten de
pruebas de forma repetitiva para la buacutesqueda de errores o problemas que puedan repercutir sobre la calidad del
mismo Pero el testing no solo se basa en la realizacioacuten de pruebas
Se deben identificar otras tareas que estaacuten relacionadas con el testing las cuales se llevan a cabo antes y despueacutes
de la ejecucioacuten de pruebas Estas tareas estaacuten relacionadas principalmente con la planificacioacuten y control del
proceso de pruebas el disentildeo de los diferentes casos de prueba o test cases y la posterior comprobacioacuten de los
resultados obtenidos tras llevar a cabo las pruebas Otras tareas podriacutean ser la propia evaluacioacuten de los diferentes
criterios de finalizacioacuten del proceso de pruebas el anaacutelisis de informes de resultados o la revisioacuten de la
documentacioacuten generada en la fase de pruebas
A continuacioacuten se citan algunas definiciones para explicar el concepto de pruebas de software
ldquoUna prueba es una actividad ejecutada para evaluar la calidad del producto software y mejorarlo mediante
la identificacioacuten de problemas errores o defectos en su funcionamiento [9]rdquo
ldquoLas pruebas de Software consisten en verificaciones dinaacutemicas del comportamiento del software bajo
pruebas mediante un conjunto finito de casos de prueba seleccionadas adecuadamente sobre un dominio
infinito de casos posibles [1]rdquo
Atendiendo a las definiciones presentadas las pruebas de software son dinaacutemicas porque se puede ejecutar el
software bajo pruebas con un conjunto de valores de entrada especiacuteficos para encontrar fallos en su
comportamiento Por otro lado la realizacioacuten de pruebas exhaustivas no es posible para la mayoriacutea de los
productos software reales debido a la gran cantidad de entradas posibles para cada operacioacuten entradas invaacutelidas
o no esperadas y las infinitas secuencias de operaciones posibles
Por estas razones para aplicar un proceso de pruebas de software razonable en cuanto a recursos y tiempo de un
proyecto es necesario seleccionar un conjunto abarcable de pruebas Debido a esto la clave estaacute en el criterio
de seleccioacuten de dichas pruebas Una vez ejecutadas las pruebas seleccionadas se debe decidir si el
comportamiento esperado del sistema falla o no Este es el llamado problema del oraacuteculo el cual es resuelto en
la mayoriacutea de los casos de forma manual mediante la inspeccioacuten de los resultados de la prueba
T
La tecnologiacutea no es nada Lo importante es que tengas feacute
en la gente que sean baacutesicamente buenas e inteligentes
y si les das herramientas haraacuten cosas maravillosas con
ellas
Steve Jobs
47
32 Principios de las Pruebas de Software
Una vez presentada la definicioacuten de pruebas de Software se han obtenido algunos detalles que encajan
perfectamente con una serie de principios que han sido establecidos para el testing de productos software seguacuten
ISTQB (International Software Testing Qualifications Board) [10]
Figura 15 Principios de las Pruebas de Software
1 Las pruebas demuestran la presencia de defectos no su ausencia Las pruebas pueden mostrar que
los defectos estaacuten presentes en el producto pero no pueden probar que no haya defectos Por tanto las
pruebas pueden reducir la probabilidad de existencia de defectos en el software pero incluso si no se
encuentran defectos las pruebas no son una garantiacutea total para afirmar la ausencia de defectos en el
producto final
2 Las pruebas exhaustivas son imposibles Probar todas las posibles combinaciones de entradas y
condiciones previas sobre una aplicacioacuten no es factible excepto en casos muy triviales En lugar de
intentar realizar pruebas exhaustivas se debe usar el anaacutelisis de riesgos las teacutecnicas de prueba y las
prioridades ademaacutes de la automatizacioacuten para enfocar los esfuerzos en la fase de pruebas
3 Las pruebas tempranas ahorran tiempo y dinero Para una deteccioacuten temprana de errores y defectos
las actividades de pruebas deben iniciarse lo antes posible en el ciclo de vida del desarrollo del software
De esta forma se consigue una reduccioacuten de costes ya que cuanto maacutes tarde se detecte un defecto maacutes
costoso y difiacutecil seraacute corregirlo
4 Los defectos se agrupan Generalmente una pequentildea parte del software desarrollado concentra la
mayor complejidad del mismo por lo que la mayoriacutea de los defectos detectados tienen una mayor
probabilidad de encontrarse en esos elementos maacutes complejos Por tanto la realizacioacuten de un buen
anaacutelisis de riesgos permite enfocar el esfuerzo de pruebas en las aacutereas del producto con mayor
probabilidad de presentar defectos
Aplicando el Principio de Pareto al control de calidad [11] el 80 de los errores y defectos estaacute causado
por un 20 del total del producto software desarrollado lo cual podriacutea ser un buen principio sobre el
que basar el anaacutelisis de riesgos
5 Cuidado con la paradoja del pesticida Si las mismas pruebas se repiten una y otra vez con el tiempo
los mismos casos de pruebas ya no encontraraacuten nuevos defectos lo cual no quiere decir que la aplicacioacuten
presente una ausencia completa de los mismos (Las pruebas ya no son eficaces para detectar defectos
al igual que los pesticidas ya no son eficaces para matar insectos despueacutes de un tiempo) Para detectar
nuevos defectos es necesario que las pruebas existentes y los datos de las pruebas deban cambiar
ademaacutes de surgir la necesidad de disentildear nuevas pruebas
48
6 Las pruebas dependen del contexto Cada empresa organizacioacuten o proyecto adaptaraacute el proceso de
pruebas a sus necesidades recursos disponibles o aacutereas de riesgo existentes
7 La ausencia de errores es una falacia Un producto software puede tener un 100 de casos de eacutexito
en su fase de pruebas pero esto solo indica que hay defectos que auacuten no han sido localizados e
identificados
33 Proceso de Pruebas de Software Anaacutelisis disentildeo e implementacioacuten
Partiendo de los principios detallados en la seccioacuten anterior se presentan las diferentes etapas del proceso de
pruebas de software asiacute como la documentacioacuten generada en cada etapa
331 Terminologiacutea
Previamente se presentaraacuten algunos teacuterminos y definiciones que convienen describir para una mejor
comprensioacuten de todo el proceso de pruebas [3]
Figura 16 Terminologiacutea para el proceso de pruebas
1 Condicioacuten de prueba Elemento o evento de un componente o sistema que puede ser verificado por
uno o maacutes casos de prueba Los diferentes requisitos que definen la funcionalidad de un sistema pueden
ser descompuestos en diferentes condiciones de prueba
2 Caso de prueba conjunto de valores de entrada precondiciones de ejecucioacuten y valores esperados
Estos son desarrollados para perseguir un objetivo particular por ejemplo una condicioacuten de prueba
3 Precondicioacuten Condiciones de entorno y estado que deben ser satisfechas antes de que un componente
o sistema pueda ser sometido a un caso de prueba o conjunto de estos
4 Abstraccioacuten de casos de prueba Consiste en la generalizacioacuten de los casos de prueba especiacuteficos sin
valores concretos para sus entradas condiciones de prueba o valores esperados En resumen no es maacutes
que llevar las condiciones de prueba a un caso general para cualquier valor de entrada
5 Script de pruebas Una vez disentildeados los casos de prueba estos pueden ser implementados y
ejecutados por una herramienta de automatizacioacuten Un script de pruebas puede contener varios casos
de prueba
6 Paquete de pruebas Consiste en la agrupacioacuten de casos de prueba relacionados en cuanto a la
funcionalidad que automatizan sobre el sistema
7 Programacioacuten de la ejecucioacuten de pruebas Describen el flujo de ejecucioacuten de los diferentes paquetes
de pruebas
49
332 Proceso de Pruebas de Software
No existe un proceso de pruebas universal pero existen conjuntos comunes de actividades de prueba sin las
cuales las pruebas disentildeadas e implementadas tendriacutean menos probabilidad de alcanzar sus objetivos
establecidos Estos conjuntos de actividades de prueba constituyen un proceso de pruebas
Como se ha mencionado en secciones anteriores el proceso de pruebas se debe iniciar en las fases maacutes iniciales
del ciclo de vida de un proyecto Por tanto las actividades del proceso de pruebas la manera en que se
implementan dichas actividades y cuaacutendo ocurren pueden ser discutidas en la estrategia de pruebas de una
organizacioacuten
A continuacioacuten se exponen las etapas fundamentales del proceso de pruebas detallando en cada una de ellas la
documentacioacuten generada y coacutemo contribuyen a la mejora de la calidad del producto con su aplicacioacuten en el ciclo
de vida de un proyecto [13]
Figura 17 Proceso de Pruebas de Software
3321 Planificacioacuten y Control de Pruebas
La planificacioacuten consiste en determinar los diferentes objetivos de las pruebas realizadas sobre el Sistema bajo
test las especificaciones y los recursos que se necesitaraacuten para llevar a cabo la fase de pruebas y cumplir con los
objetivos planteados
Es en este punto donde se define el alcance de las pruebas a realizar de forma que se selecciona lo que seraacute y
no seraacute testeado ademaacutes de indicar quieacuten haraacute cada prueba y como la llevaraacute a cabo Mediante los objetivos de
las pruebas se puede establecer un punto de finalizacioacuten del proceso
Como salida de la actividad de planificacioacuten se obtendriacutea el ldquoPlan de Pruebasrdquo el cual documenta la estrategia
y el alcance de las pruebas la prioridad en cuanto a su realizacioacuten y las estimaciones temporales para su
evaluacioacuten ademaacutes de los recursos materiales y humanos para llevarlas a cabo
Es crucial que dicho documento sea validado por el personal correspondiente del proyecto antes de continuar
con las siguientes etapas del proceso de pruebas
Por otro lado el control de pruebas es una actividad desarrollada durante todo el ciclo de vida del proceso de
pruebas el cual permite contrastar el progreso actual con el plan original trazado para la aplicacioacuten de dicho
proceso incluyendo informes y desviaciones
Cuando se produce una desviacioacuten del plan original que introduce cierto riesgo adicional puede hacerse
necesario modificar los objetivos fijados para asegurar la calidad del producto De ahiacute que sea sumamente
importante tener en consideracioacuten la documentacioacuten generada en antiguos proyectos
50
3322 Anaacutelisis y Disentildeo de Pruebas
Una vez planificado el alcance y objetivos de las pruebas se realiza una actividad de anaacutelisis donde se traducen
a condiciones de prueba y posteriormente se disentildean los casos de prueba de alto nivel a partir de la abstraccioacuten
de los casos de prueba
Por otro lado cabe destacar la necesidad de un mecanismo que garantice la trazabilidad con la finalidad de
mantener alineados en todo momento los casos de prueba con los objetivos de la misma incluso contemplando
la posibilidad de que los objetivos puedan cambiar en alguacuten momento del proceso de pruebas
El documento generado en esta actividad es conocido como ldquoespecificaciones de disentildeo de pruebasrdquo
3323 Implementacioacuten y Ejecucioacuten de Pruebas
Dicha etapa consiste en la implementacioacuten de los casos de prueba de alto nivel que cumplen con las
especificaciones de disentildeo de la etapa anterior Es en esta fase donde se haraacute uso de herramientas para la
implementacioacuten y ejecucioacuten de las pruebas
Cabe destacar que para llevar a cabo dicha etapa en cuanto a la verificacioacuten y validacioacuten funcional de un
proyecto es necesario que durante la etapa de desarrollo se haya creado un producto funcional sobre el cual
puedan ejecutarse las pruebas
Durante la ejecucioacuten de las pruebas los resultados obtenidos quedaraacuten documentados en un documento
denominado ldquoRegistro de Pruebasrdquo el cual contiene todas las pruebas realizadas y un ldquoReporte de Incidenterdquo
por cada resultado no esperado que se haya detectado
Una vez sean corregidos los incidentes se debe volver a ejecutar las pruebas con la finalidad de asegurar que
dicho incidente haya sido corregido ademaacutes de asegurar que la correccioacuten realizada no haya introducido otros
defectos o errores Esto es lo que se denomina ldquoPruebas de Regresioacutenrdquo
3324 Evaluacioacuten de los criterios de eacutexito y Elaboracioacuten de reportes e informes
Tras la ejecucioacuten de las pruebas se deben evaluar los criterios de eacutexito los cuales han sido definidos en la etapa
de planificacioacuten
El personal responsable e involucrado en el proyecto se reuniraacute y revisaraacute el cumplimiento de dichos criterios
el registro de pruebas obtenido y los reportes de incidentes que hayan podido ser abiertos en la etapa anterior
Finalmente como resultado de dicha actividad se elabora un ldquoSumario final de Pruebasrdquo
3325 Cierre de la fase de pruebas
Las actividades de cierre de la fase de pruebas se centran mayormente en asegurar que todo el ciclo de vida del
proceso de pruebas se ha cumplido ademaacutes de analizar las posibles mejoras y defectos en las fases llevadas a
cabo
Ademaacutes se lleva a cabo el cierre de los incidentes corregidos y la liberacioacuten de los entornos y recursos asignados
a la fase de pruebas
51
34 Clasificacioacuten de Pruebas de Software
Existen diversos tipos de pruebas las cuales pueden ser clasificadas en funcioacuten del objetivo de prueba para lo
cual hayan sido establecidos Cada tipo de prueba persigue unos objetivos especiacuteficos sobre el producto pero
todas ellas persiguen como objetivo comuacuten ofrecer un producto con garantiacutea de calidad al cliente o usuario final
Dichas pruebas pueden ser clasificadas en cuatro tipos
Figura 18 Clasificacioacuten de Pruebas de Software
341 Pruebas Funcionales
Tambieacuten conocidas como ldquoPruebas de caja Negrardquo En [14] la IEEE define este tipo de pruebas como
ldquoPruebas que ignoran los mecanismos internos de un sistema o componente y se enfocan
solamente en las salidas generadas como respuesta a las entradas seleccionadas y a las
condiciones de ejecucioacutenrdquo
Figura 19 Pruebas de Caja Negra
Atendiendo a la definicioacuten anterior el sistema o componente sujeto a pruebas debe realizar una funcioacuten
determinada Estaraacute descrita en las especificaciones funcionales y se pueden llevar a cabo a cualquier nivel
Dichas especificaciones funcionales describen el comportamiento del sistema sin revelar informacioacuten acerca de
su implementacioacuten interna
Un tipo especial de prueba funcional son las ldquoPruebas de Humordquo o ldquoSmoke Testsrdquo Este tipo de pruebas suele
realizarse en fases tardiacuteas del desarrollo y permiten asegurar que las funcionalidades baacutesicas del software
responden adecuadamente
Por tanto dichas pruebas pueden quedar lejos de ser pruebas exhaustivas aunque siacute permiten asegurar que el
producto entregado al cliente cumple con los requisitos de funcionamiento establecidos Este tipo de pruebas
son las que se han implementado y automatizado en el proyecto presente lo cual se detallaraacute en capiacutetulos
posteriores
52
342 Pruebas No Funcionales
Este tipo de pruebas estaacuten orientadas a verificar coacutemo de bien funciona el sistema bajo pruebas en lugar de la
funcionalidad que ofrece Por ello pueden ser agrupadas tambieacuten dentro de la categoriacutea de pruebas de caja negra
Atendiendo al estaacutendar de evaluacioacuten del producto software ldquoISO 25000rdquo todas las caracteriacutesticas excepto la de
funcionalidad definen caracteriacutesticas de calidad no funcionales de un producto software Estas caracteriacutesticas de
calidad tienen su correspondiente tipo de prueba
3421 Pruebas de Rendimiento
Las pruebas de rendimiento son usadas para determinar la rapidez con la que se realiza una tarea en el sistema
bajo unas condiciones particulares de trabajo Estas pruebas tambieacuten pueden ser usadas para validar y verificar
otros atributos de calidad del sistema tales como la escalabilidad fiabilidad y uso de recursos
Figura 20 Pruebas de Rendimiento
3422 Pruebas de Carga
Este tipo de pruebas miden el rendimiento del sistema con una carga de trabajo manejable y conocida Se trata
de someter al sistema a cargas de trabajo controladas por el ingeniero de pruebas para validar prestaciones de
rendimiento sobre el sistema
Figura 21 Pruebas de Carga
3423 Pruebas de Estreacutes
Las pruebas de estreacutes ponen a prueba la robustez y confiabilidad del sistema sometieacutendolo a condiciones de uso
extremas Entre estas condiciones se incluyen el enviacuteo masivo de peticiones y la ejecucioacuten en condiciones de
hardware limitadas Dichas condiciones van maacutes allaacute de los liacutemites de operacioacuten considerados en el disentildeo
Figura 22 Pruebas de Estreacutes
53
3424 Pruebas de Usabilidad
Estas pruebas se centran en encontrar problemas de la interfaz de usuario que podriacutean hacer que el software sea
difiacutecil de utilizar o podriacutean causar que los usuarios mal interpreten las salidas Por tanto permiten medir coacutemo
de atractivo resulta un producto software basaacutendose en la facilidad de adaptacioacuten y uso por parte de los clientes
Figura 23 Pruebas de Usabilidad
3425 Pruebas de Fiabilidad
Prueban el rendimiento del sistema ante un determinado nuacutemero de operaciones o tras cierto periodo de
tiempo
3426 Pruebas de Instalacioacuten
Las pruebas de instalacioacuten tienen dos propoacutesitos El primero es asegurar que el sistema puede ser instalado
en todas las configuraciones posibles tales como nuevas instalaciones actualizaciones instalaciones
completas o personalizadas y bajo condiciones normales o anormales estas uacuteltimas incluyen insuficiente
espacio en disco falta de privilegios para algunas tareas etc
El segundo propoacutesito es verificar que una vez instalado el sistema opera correctamente Esto usualmente
implica ejecutar un nuacutemero significativo de pruebas de Funcionalidad
Por tanto miden coacutemo de sencillo resulta instalar la aplicacioacuten en distintas plataformas o entornos
3427 Pruebas de Portabilidad
Miden coacutemo de sencillo resulta migrar una aplicacioacuten de una plataforma a otra
Figura 24 Pruebas de Portabilidad
54
343 Pruebas Estructurales
Este tipo de pruebas son tambieacuten conocidas como ldquoPruebas de Caja Blancardquo En [14] la IEEE define este tipo
de pruebas como
ldquoPruebas que tienen en cuenta los mecanismos internos de un sistema o componenterdquo
Figura 25 Pruebas de Caja Blanca
Atendiendo a dicha definicioacuten estas pruebas tienen en cuenta la estructura del coacutedigo fuente del software a partir
del cual se seleccionan los diferentes casos de prueba guiaacutendose por la existencia de sentencias condicionales
bucles etc
Por tanto los casos de prueba son desarrollados usando criterios de cobertura para el coacutedigo del programa De
esta forma el sistema bajo pruebas se trata como una caja de cristal que permite ver su estructura
El criterio de cobertura hace referencia a cada miacutenima unidad de coacutedigo que puede ser probada de forma
independiente Es frecuente usar este tipo de pruebas en los niveles de prueba maacutes bajos como por ejemplo en
las ldquoPruebas Unitariasrdquo o las ldquoPruebas de Componenterdquo
344 Pruebas debidas a Cambios
Finalmente en el proceso de pruebas tras ejecutar las pruebas y encontrar un defecto o error en el sistema bajo
pruebas este se corrige pero es necesario validar la correccioacuten realizada para confirmar que el fallo no se
reproduce A este proceso se le denomina ldquoPrueba de confirmacioacuten o re-testingrdquo
Ademaacutes las correcciones pueden ser validadas pero tambieacuten es necesario asegurar que los cambios introducidos
para corregir dicho fallo no han provocado maacutes defectos Por tanto puede concluirse que es necesario volver a
realizar pruebas sobre el resto del sistema Estas son las ldquoPruebas de Regresioacutenrdquo
35 Niveles de Prueba
El proceso de pruebas es una etapa del ciclo de vida de un proyecto cuyas actividades estaacuten completamente
relacionadas con las actividades del proceso de desarrollo Existen diversos modelos que describen las fases y
actividades del proceso de desarrollo de software En esta seccioacuten se detallaraacute el uso del ldquoModelo de desarrollo
en Vrdquo
Este modelo describe las diferentes fases del proceso de desarrollo y sugiere la realizacioacuten de pruebas en cada
una de ellas Estas pruebas seraacuten ejecutadas posteriormente en orden ascendente Por tanto para cada fase existen
unos objetivos a cumplir los cuales deben ser probados para medir la integridad del trabajo realizado
55
A continuacioacuten se detallaraacuten los diferentes niveles de prueba para cada etapa del desarrollo software atendiendo
al modelo de desarrollo en V
Figura 26 Modelo de desarrollo en V
351 Pruebas a Nivel de Componente
Tambieacuten llamadas ldquoPruebas Unitariasrdquo El objetivo de estas pruebas es el de cubrir la unidad miacutenima funcional
que compone el software Estos componentes suelen tener una uacutenica funcioacuten especiacutefica la cual seraacute usada por
el resto del Sistema A menudo son realizadas por los propios desarrolladores haciendo uso de la metodologiacutea
de desarrollo guiado por prueba o Test-Driven-Development (TDD)
352 Pruebas a Nivel de Integracioacuten
Son aquellas pruebas realizadas en el aacutembito del desarrollo software una vez validadas las pruebas unitarias
Estas pruebas verifican que todos los elementos unitarios que componen el software funcionan en conjunto de
forma correcta Se centran principalmente en probar la comunicacioacuten entre los diferentes componentes del
sistema
353 Pruebas a Nivel de Aceptacioacuten
Este uacuteltimo nivel se centra en las necesidades del usuario requisitos y procesos de negocio con el fin de
determinar si el sistema satisface los criterios de aceptacioacuten acordados con el cliente en un contrato o acuerdo
de nivel de servicio en caso de ser un software de uso interno dentro de una compantildeiacutea
Ejemplos de este tipo de pruebas pueden ser las ldquoPruebas Alfa y Betardquo
Como se ha detallado anteriormente las pruebas desarrolladas y automatizadas en este Proyecto son ldquoPruebas
de humordquo o Smoke Tests Estas pruebas se centran en la verificacioacuten y validacioacuten de las especificaciones de uso
de un Sistema en este caso de la plataforma Web de gestioacuten Galgus CHT Manager
56
36 Dificultades de pruebas en aplicaciones Web e impacto
La complejidad antildeadida de las aplicaciones y servicios Web frente a otros tipos de aplicaciones recae sobre el
uso de muacuteltiples tecnologiacuteas de vanguardia que permiten la construccioacuten de sistemas distribuidos con un amplio
grado de escalabilidad accesibilidad disponibilidad interoperabilidad e independencia del hardware
Como consecuencia del incremento de la complejidad de las aplicaciones surgen nuevos paradigmas como la
Arquitectura Orientada a Servicios (SOA) la cual permite interoperabilidad y flexibilidad de las aplicaciones
distribuidas
Todo ello conlleva a plantearse queacute se deberiacutea hacer para garantizar que una aplicacioacuten Web puesta en marcha
funciona de acuerdo a los requisitos definidos y acordados con el cliente Podriacutean optimizarse y mejorarse los
diferentes procesos dentro del ciclo de vida de un proyecto pero siempre la fase de pruebas termina siendo la
fase previa a la puesta en marcha de la aplicacioacuten con lo que resulta siendo la uacuteltima oportunidad para detectar
posibles fallos que puedan terminar en ocasiones en peacuterdidas econoacutemicas de prestigio de fiabilidad y de
credibilidad por parte de los clientes
Realizar pruebas en una aplicacioacuten Web no es tarea faacutecil ya que son muchos los factores que influyen en el
testeo del sistema para abarcar y contemplar el maacuteximo de flujos posibles que se pueden llevar a cabo durante
el uso de la aplicacioacuten
Hoy en diacutea las aplicaciones Web pueden ser construidas con componentes implementados en diferentes
lenguajes y arquitecturas basaacutendose en diferentes modelos de programacioacuten y pudiendo ejecutarse en diferentes
plataformas de hardware y software
Esto incrementa la complejidad de las pruebas a realizar sobre un sistema de este tipo por lo que seriacutea interesante
plantearse la posibilidad de usar herramientas que permitan una abstraccioacuten de dicha complejidad ademaacutes de la
automatizacioacuten de la fase de pruebas En el caso de las pruebas a nivel de aceptacioacuten en este proyecto se
propondraacute el uso de herramientas que persiguen dichos fines
Figura 27 Dificultades de pruebas en aplicaciones Web e impacto
57
58
4 SISTEMA GALGUS CHT CLOUD MANAGER
ras realizar un estudio del arte sobre una teacutecnica que puede ser de gran utilidad para optimizar y
perfeccionar las teacutecnicas de automatizacioacuten para el proceso de pruebas sobre un sistema se han puesto
en contexto los diferentes tipos de pruebas que pueden realizarse sobre un sistema ademaacutes de definir
el proceso de pruebas Una vez llegados a este punto en primer lugar se realizaraacute una descripcioacuten del sistema
bajo pruebas sobre el cual se plantearaacute una solucioacuten para la fase de pruebas y su automatizacioacuten Maacutes
concretamente para la realizacioacuten de las pruebas a nivel de aceptacioacuten
41 Arquitectura y Descripcioacuten del Sistema
CHT Cloud Manager es un proyecto de la empresa Galgus el cual ofrece una plataforma Web de gestioacuten
configuracioacuten y monitorizacioacuten de redes WiFi Maacutes concretamente dicha plataforma permite gestionar un
conjunto de puntos de acceso desplegados con un conjunto de algoritmos definidos por software los cuales
permiten la optimizacioacuten de los recursos de red inalaacutembricos ofreciendo mayores prestaciones y una mayor
calidad de servicio al usuario Ademaacutes dicho software embebido ofrece otros servicios al cliente como la
localizacioacuten de estaciones dentro de la zona de alcance de la red WiFi o la deteccioacuten de intrusos y ataques de
suplantacioacuten de identidad
A este conjunto de algoritmos se le conoce bajo el nombre Cognitive Hostpot Technology (CHT) Este software
implementado en lenguaje C y preparado para sistemas embebidos como los puntos de acceso presenta una
estructura modular donde cada moacutedulo se encarga de una tarea determinada o de ejecutar un algoritmo
determinado
Figura 28 Logo de Galgus
Para permitir la comunicacioacuten con la plataforma Web CHT implementa un moacutedulo denominado MGR el cual
permite la conexioacuten con un broacuteker de eventos o intermediario para permitir el enviacuteo y la recepcioacuten de eventos
desde dicha plataforma
T
La simplicidad llevada al extremo se convierte en
elegancia
Jon Franklin
59
En la siguiente figura se muestra la arquitectura orientada a servicios para CHT Cloud Manager
Figura 29 Arquitectura de CHT Cloud Manager
Puede observarse que dicha plataforma estaacute formada por diferentes microservicios desplegados en la nube Cada
uno de ellos realiza una serie de tareas bien definidas e interactuacutean entre ellos enviando y recibiendo mensajes
haciendo uso de diferentes protocolos y modelos de comunicacioacuten
De esta forma se consigue mantener actualizado el estado de la informacioacuten de los diferentes elementos en
tiempo real sobre los diferentes eventos que puedan ocurrir en el sistema Dichos eventos proceden en su gran
mayoriacutea del conjunto de puntos de acceso que conforma una red de Galgus la cual pretende ser gestionada desde
la plataforma en cuestioacuten
A continuacioacuten se detallaraacuten los diferentes microservicios que conforman dicha plataforma ademaacutes de describir
a los puntos de acceso con la tecnologiacutea CHT como elementos a gestionar desde dicha plataforma
60
411 Puntos de Acceso (OpenWRT + CHT)
4111 OpenWRT
Los puntos de acceso WiFi de Galgus son sistemas embebidos de diferentes modelos en funcioacuten de las
especificaciones hardware que ofrezcan (nuacutemero de streams espaciales nuacutemero de antenas de exterior de
interior etc)
Todos ellos tienen en comuacuten el uso de OpenWRT como sistema operativo Este se trata de un sistema operativo
open source basado en Linux y usado para sistemas de red embebidos Todos los componentes de dicho sistema
han sido optimizados para dispositivos con limitaciones de hardware y este permite configurarlos mediante
interfaz de liacutenea de comandos o mediante una interfaz Web (LuCI) [15]
Partiendo de dicho sistema operativo Galgus desarrolla CHT como producto software que dota a los puntos de
acceso de una serie de prestaciones en una serie de moacutedulos Dicho producto es ofrecido al cliente mediante
licencias las cuales son gestionadas desde un servidor de licencias y obtenidas por los puntos de acceso de
forma automaacutetica Todo ello se detallaraacute maacutes adelante
4112 CHT
CHT tambieacuten ofrece su propia interfaz de liacutenea de comandos denominada CHT_CLI Esta herramienta permite
configurar los distintos moacutedulos de los que se compone CHT y obtener informacioacuten tanto de la configuracioacuten
como del funcionamiento de los algoritmos CHT
A continuacioacuten se presenta la interfaz y algunos de los comandos que se pueden utilizar
Figura 30 CHT_CLI
CHT_CLI es fundamental tanto en el desarrollo como en el testeo de CHT y CHT Cloud Manager ya que nos
permite acceder a paraacutemetros de configuracioacuten que no estaacuten accesibles desde la interfaz graacutefica LuCI Desde
CHT_CLI se controlan todos los moacutedulos de CHT entre los que se pueden destacar los siguientes Load Balance
(LB) Smart Roaming (SR) Power Control (POWER) Localization (LOC) Traffic Congestion Management
(TCM) Smart Band Steering (SB) y el moacutedulo Manager (MGR)
En este caso es de intereacutes resaltar el moacutedulo que permite la comunicacioacuten con la plataforma de gestioacuten CHT
Cloud Manager Dicho moacutedulo conocido bajo el nombre de MGR implementa un cliente AMQP para
establecer la comunicacioacuten con el broacuteker de eventos usado como intermediario para permitir la comunicacioacuten
entre los puntos de acceso y la plataforma de gestioacuten CHT Cloud Manager
Ademaacutes implementa una serie de estructuras de datos que son enviados a traveacutes de dicho intermediario basadas
en FlatBuffers como plataforma eficiente de serializacioacuten cruzada de datos ofrecida por Google Esta
herramienta permite crear un modelo de datos bajo la sintaxis ofrecida por FlatBuffers para posteriormente
generar dichas estructuras de datos en diferentes lenguajes de programacioacuten como por ejemplo C++ C C
Go Java JavaScript etc
Con esto se consigue generar estructuras de datos con una compatibilidad absoluta que se intercambiaraacuten entre
la plataforma de gestioacuten en lenguaje Java y los puntos de acceso en lenguaje C
61
412 Broacuteker de Eventos AMQP (RabbitMQ)
Este microservicio implementa un broacuteker de eventos que actuacutea como intermediario entre los puntos de acceso
WiFi y algunos microservicios que componen la plataforma Web de gestioacuten Se basa en el protocolo AMQP el
cual sigue el patroacuten publicadorsuscriptor como paradigma de comunicacioacuten indirecta
Estaacute involucrado en la entrega de mensajes entre los diferentes dispositivos embebidos con CHT y sus
respectivos servicios de gestioacuten en la plataforma Web de forma que los agentes que publican y consumen
eventos en el broacuteker no necesitan conocer al destinatario si no que el broacuteker es el que se encarga de publicar los
eventos para los destinatarios suscritos a eacutel En la siguiente figura se muestra la interfaz graacutefica de gestioacuten de
RabbitMQ [16]
Figura 31 Plataforma de Gestioacuten de RabbitMQ
Un broacuteker de eventos es un elemento del patroacuten PublicadorSuscriptor que recibe y mensajes de un conjunto de
elementos de red que quieren comunicarse ejecutan mecanismos de filtrado y permite la entrega correcta de los
diferentes mensajes a los consumidores correspondientes Por tanto el broacuteker de eventos permite ofrecer un
desacoplamiento entre emisores y receptores de la informacioacuten siendo este responsable de las tareas de
encaminamiento y reenvioacute de mensajes En conclusioacuten es responsable de coordinar la comunicacioacuten
proporcionando transparencia de acceso y localizacioacuten permitiendo la localizacioacuten de emisores y receptores
mediante un sistema de identificadores uacutenicos
Figura 32 Patroacuten PublicadorSuscriptor
62
413 Frontend
El Frontend de la plataforma Web estaacute implementado con Angular 6 HTML5 y CSS3 Su finalidad es ofrecer
una interfaz graacutefica al usuario final la cual permite mostrar el estado de los diferentes Zone Managers ademaacutes
de permitir el acceso a estos y gestionar el conjunto de puntos de acceso registrados en ellos de forma raacutepida e
intuitiva
Este microservicio recibe informacioacuten proporcionada por MoMap y los diferentes Zone Managers La
aplicacioacuten se sirve mediante un servidor Apache el cual proporciona una comunicacioacuten fiable con HTTPS
implementando una capa de transporte segura mediante el protocolo TLS
414 Zone Manager
Microservicio responsable de gestionar un conjunto de puntos de acceso CHT los cuales forman un despliegue
de red WiFi de Galgus para un cliente determinado Este microservicio estaacute formado por un servicio Web REST
implementado con Java Spring Framework desplegado en un servidor Jetty embebido y cuya persistencia se ha
implementado a traveacutes de Hybernate con el uso de Postgress SQL como gestor de bases de datos relacional
Un Zone Manager ofrece todas las tareas y acciones necesarias para configurar un conjunto de puntos de acceso
y consultar datos estadiacutesticos de usuarios conectados a dichos puntos de acceso entre otras Cabe destacar en
este punto la importancia que tiene el uso de FlatBuffers para garantizar la compatibilidad de datos enviados y
recibidos entre los puntos de acceso y el Zone Manager ambos implementados en tecnologiacuteas totalmente
diferentes
Figura 33 Ejemplo de Interfaz Graacutefica de un Zone Manager
63
415 MoMap
Dicho microservicio implementado en NodeJS gestiona y administra toda la infraestructura que conforma la
plataforma Web Establece y mantiene todas las conexiones y relaciones entre los diferentes puntos de acceso
con CHT y los Zone Managers (ZMB) que los gestiona
Ademaacutes este microservicio implementa una serie de maacutequinas de estado que permiten controlar el estado de
todos los Zone Managers y puntos de acceso CHT alertando sobre los eventos de error conexioacuten o desconexioacuten
en tiempo real a los usuarios finales a traveacutes del Frontend El soporte a la persistencia para dicho microservicio
se proporciona mediante MongoDB
Por tanto el microservicio MoMap actuacutea como proxy inverso HTTP2 Cuando un usuario intenta acceder a
traveacutes del Frontend de la plataforma Web puede gestionar y administrar un conjunto de Zone Managers o
administrar usuarios y asignar roles y permisos Tambieacuten se permite la creacioacuten eliminacioacuten y conexioacuten con un
Zone Manager redirigiendo las peticiones hacia el mismo
Cuando ocurre un evento de conexioacuten con un Zone Manager desde el microservicio MoMap se recupera y
enviacutea la informacioacuten necesaria para mostrar toda la informacioacuten correspondiente a ese Zone Manager en el
Frontend para el usuario final En la siguiente figura se muestra la interfaz graacutefica ofrecida por el servicio
MoMap a traveacutes del Frontend
Figura 34 Ejemplo de Interfaz Graacutefica de MoMap
64
416 Servidor de Licencias
El objetivo principal de este servicio es proporcionar una aplicacioacuten con una gestioacuten y control centralizado de
las licencias de todos los Puntos de Acceso desplegados con CHT Este servidor desplegado con Jetty de forma
embebida almacena el registro de un conjunto de Puntos de Acceso CHT para un conjunto de Clientes y
proyectos determinados Proporciona una API REST implementada con Java Spring Framework que permite
el registro de dichos dispositivos y la asignacioacuten de licencias CHT para habilitar los diferentes moacutedulos de dicha
aplicacioacuten embebida sobre los Puntos de Acceso Ademaacutes proporciona una interfaz Web de usuario
implementada con Angular 6 HTML5 y CSS3
En la siguiente figura se muestra un ejemplo de dicha interfaz graacutefica
Figura 35 Interfaz Graacutefica del Servidor de Licencias
4161 Zero-Touch Provisioning (ZTP)
En el contexto de la automatizacioacuten de redes WiFi el aprovisionamiento sin contacto es una caracteriacutestica
que permite que los puntos de acceso de una red se configuren automaacuteticamente evitando la intervencioacuten
humana para su configuracioacuten La configuracioacuten manual de dispositivos y conmutadores es costosa y
requiere lo que a menudo puede ser una gran cantidad de tiempo y esfuerzo dependiendo del tamantildeo de la
red [17]
Con el uso de sistemas automaacuteticos de aprovisionamiento y configuracioacuten se consigue reducir la carga de
trabajo y el esfuerzo que normalmente se requiere cuando se instalan y configuran nuevos dispositivos
Figura 36 Zero-Touch Provisioning (ZTP)
65
Haciendo uso de esta caracteriacutestica Galgus implementa en su infraestructura orientada a microservicios
un acceso directo de los Puntos de Acceso al servidor para que soliciten su licencia de CHT
automaacuteticamente de forma que cuando el usuario final vaya a instalar un Punto de Acceso CHT dicho
dispositivo obtendraacute su licencia de forma segura a traveacutes de la API REST del servidor de licencias siempre
y cuando esteacute registrado en el mismo y disponga de licencia sin necesidad de que el usuario intervenga en
dicho proceso
La comunicacioacuten entre los puntos de acceso y el resto de la infraestructura se realiza a traveacutes de un broacuteker
de eventos AMQP con su implementacioacuten en RabbitMQ Debido a esto cuando se crea y asigna licencia
a un dispositivo en el servidor de licencias dicho servidor crea un usuario en RabbitMQ de forma que el
punto de acceso en el momento que obtiene su licencia intentaraacute establecer conexioacuten con el broacuteker para
permitir el intercambio de eventos con los microservicios que lo gestionaraacuten mediante la plataforma CHT
Cloud Manager
Una vez el punto de acceso establece conexioacuten con el broacuteker de eventos este podraacute ser descubierto por el
Zone Manager que lo gestionaraacute El microservicio MoMap se encarga de establecer el descubrimiento de
los puntos de acceso comprobando si el punto de acceso estaacute registrado en el servidor de licencias con
licencia asignada y verificando que el punto de acceso estaacute operativo con conexioacuten a internet
42 Alcance y Objetivos de las pruebas sobre el sistema planteado
Una vez presentada y descrita toda la arquitectura de la plataforma Web ofrecida por Galgus se procederaacute a
detallar los principales objetivos del proceso de pruebas que se pretenderaacute conseguir sobre dicha aplicacioacuten Para
ello inicialmente se presentaraacute en queacute punto se encontraba el proceso de pruebas inicialmente
En este proyecto se ha centrado la atencioacuten en el conjunto de pruebas funcionales realizadas a la aplicacioacuten maacutes
concretamente las pruebas a nivel de aceptacioacuten
Dentro de las pruebas a nivel de aceptacioacuten los ingenieros de prueba hasta ahora habiacutean disentildeado un plan de
pruebas de aceptacioacuten o tests End-to-End los cuales se ejecutaban verificaban y validaban manualmente por
los ingenieros de QA Dicho plan de pruebas estaacute formado por una bateriacutea de casos de prueba a realizar sobre
las diferentes funcionalidades del sistema A continuacioacuten se muestra un fragmento de dicho plan de pruebas
Figura 37 Test Plan de CHT Cloud Manager
Como puede observarse en la figura anterior dicho plan de pruebas contiene un conjunto de casos de prueba
cada uno de ellos con un identificador uacutenico una descripcioacuten algunas especificaciones o detalles necesarios un
indicador de eacutexito o fallo y finalmente la descripcioacuten de los resultados obtenidos
Ademaacutes en dicho test plan se incluye una cabecera y una leyenda para clasificar los distintos resultados
obtenidos en la ejecucioacuten de las pruebas registrar algunos datos de relevancia y tener archivado dicho plan de
pruebas con las versiones de los diferentes microservicios que componen la plataforma Web
66
Figura 38 Leyenda del Test Plan
Figura 39 Control de Versiones del Test Plan
Una vez presentado el estado actual del proceso de pruebas a nivel de aceptacioacuten el nuevo equipo encargado de
evaluar la calidad de la plataforma Web planteoacute la oportunidad de automatizar dicho plan de pruebas Por tanto
el principal objetivo de este proyecto ha sido el de automatizar las actividades de ejecucioacuten y generacioacuten de
reportes de las pruebas de aceptacioacuten automatizadas sobre la aplicacioacuten
Sin embargo las actividades de planificacioacuten disentildeo e implementacioacuten de los diferentes casos de prueba se
realizaraacuten de forma manual haciendo uso de un conjunto de tecnologiacuteas que se usaraacuten para desarrollar la
automatizacioacuten de dichas pruebas Dichas tecnologiacuteas principalmente son Robot Framework Selenium y
Python las cuales se detallaraacuten maacutes adelante
En este punto es donde podriacutea entrar en juego la aplicacioacuten de Model-Based-Testing (MBT) detallado en la
seccioacuten 2 de este proyecto como teacutecnica que permite la abstraccioacuten de la actividad de implementacioacuten del plan
de pruebas mejorando el proceso de pruebas e independizando este de las actividades de desarrollo
En este proyecto queda fuera del alcance la aplicacioacuten de dicha teacutecnica debido a la necesidad de disponer de un
disentildeo completo y detallado de la plataforma Web para permitir la generacioacuten de los casos de prueba abstractos
y su posterior generacioacuten automaacutetica de los casos de prueba ejecutables Es de intereacutes destacar que a lo largo
del desarrollo del proyecto han ido surgiendo otros objetivos de intereacutes para mejorar el proceso de pruebas los
cuales permiten agilizar dicho proceso y ampliar su alcance
Entre estos objetivos se encuentran la generacioacuten automaacutetica de documentacioacuten del plan de pruebas la
implementacioacuten de un entorno de UAT (User Acceptance Testing) con Docker la integracioacuten de las pruebas a
nivel de aceptacioacuten en el proceso de integracioacuten continua del proyecto o la creacioacuten de un Docker que permita
ejecutar todo el plan de pruebas Todos estos objetivos se iraacuten detallando maacutes adelante
67
43 Arquitectura de la Solucioacuten Entorno de UAT para el proceso de pruebas (User Acceptance Test)
Hasta ahora dentro del proceso de desarrollo de la plataforma Web existiacutean las siguientes fases etapas o
entornos Desarrollo Preproduccioacuten y Produccioacuten
Bajo este contexto las actividades del proceso de pruebas eran realizadas sobre la fase de Preproduccioacuten Esto
provocaba una dependencia directa del cierre de la mayoriacutea de actividades de desarrollo para el despliegue en la
fase de Preproduccioacuten Como consecuencia la fase de pruebas a nivel de aceptacioacuten se podriacutea ver perjudicada
por esta metodologiacutea provocando en muchas ocasiones el retraso en el feedback necesario por los ingenieros de
desarrollo de los reportes e informes generados al ejecutar las pruebas de aceptacioacuten Para mejorar este proceso
se ha disentildeado un nuevo entorno de UAT en el proceso de desarrollo que permita disminuir la dependencia del
proceso de pruebas y desarrollo La inclusioacuten de este nuevo entorno ha sido posible gracias a la mejora del
proceso de integracioacuten continuacutea implementado en el desarrollo de la plataforma
Dentro de este proceso de integracioacuten continua se realiza la generacioacuten automaacutetica de los Docker que contienen
los diferentes microservicios de la plataforma Web en cualquier etapa del proceso de desarrollo Ademaacutes dentro
del proceso de integracioacuten continua se ha automatizado por parte de los ingenieros de desarrollo la ejecucioacuten
de pruebas unitarias y de integracioacuten que garantizan una miacutenima garantiacutea de estabilidad funcional de la
plataforma necesaria para el proceso de pruebas Partiendo de este punto el equipo de calidad ha disentildeado un
entorno de UAT con Docker el cual se muestra de forma graacutefica en la siguiente figura
Figura 40 Entorno de UAT con Docker (Anexo B)
68
69
5 TECNOLOGIacuteAS Y HERRAMIENTAS USADAS
na vez descrito el sistema bajo pruebas y presentada la arquitectura de la solucioacuten para el escenario de
pruebas con Docker se expondraacute a continuacioacuten el conjunto de tecnologiacuteas y herramientas usadas para
llevar a cabo el desarrollo de las pruebas automatizadas de aceptacioacuten o pruebas End-to-End Con este
conjunto de herramientas se pretende conseguir la implementacioacuten de los diferentes scripts de pruebas que
automaticen las acciones e interacciones necesarias con la plataforma Web CHT Cloud Manager como si de
una persona se tratase
51 Selenium
Selenium es una herramienta de coacutedigo abierto utilizada para la automatizacioacuten de pruebas en navegadores web
Dicha herramienta posee una enorme popularidad en el mundo de las pruebas de software debido a que
Presenta compatibilidad con diferentes lenguajes de programacioacuten para la implementacioacuten de scripts de
pruebas ofreciendo libreriacuteas en Java Python C PHP Ruby Perl y Net
Es multiplataforma permitiendo el lanzamiento de los scripts de pruebas en diversos sistemas
operativos como Windows Mac o Linux y en diferentes navegadores como Mozilla Firefox Internet
Explorer Google Chrome Safari y Opera
Soporta la integracioacuten con otras herramientas como TestNG o JUnit
Permite la integracioacuten continua con Maven Jenkins gitlab CICD y Docker
Sin embargo presenta una serie de inconvenientes que se deben mencionar
bull Solo permite probar aplicaciones Web
bull No hay soporte garantizado desde Selenium Muchas de las soluciones a problemas de la herramienta
han sido generadas por la comunidad
bull No es posible realizar pruebas en imaacutegenes Para ello es necesaria la integracioacuten con otras herramientas
bull No tiene capacidad nativa para generar informes o reportes de los resultados de las pruebas Para ello
se requiere el uso de un framework como puede ser el Robot Framework
Centrando la atencioacuten en el enfoque de dicho proyecto se haraacute uso de la libreriacutea Selenium para Python y la
facilidad de Robot Framework tanto para abstraer la posible complejidad antildeadida del lenguaje de programacioacuten
usado para la implementacioacuten de los scripts de prueba como para permitir la generacioacuten automaacutetica de informes
y reportes de resultados
Realmente Selenium estaacute formado por un conjunto de herramientas las cuales son Selenium RC Selenium
IDE Selenium Grid y Selenium Webdriver Dichas herramientas permiten desde la realizacioacuten de pruebas en
maacutequinas remotas a la ejecucioacuten de pruebas en diferentes maacutequinas con diferentes navegadores cada una
Con el lanzamiento de Selenium 2 en 2008 se antildeadieron nuevas funcionalidades de Selenium RC y Webdriver
en una misma herramienta aunque es frecuente mantener la nomenclatura de WebDriver a la hora de referirse
a la misma En este proyecto se centraraacute la atencioacuten en la herramienta WebDriver de Selenium
U
El disentildeo es el alma de todo lo creado por el hombre
Steve Jobs
70
52 Selenium WebDriver
Esta herramienta de Selenium ofrece una interfaz para ejecutar los casos de prueba descritos en los scripts
de prueba A traveacutes de esta API WebDriver se comunica directamente con el controlador del navegador
donde corre la aplicacioacuten Para ello seraacute necesario el uso de controladores para los diferentes navegadores
Web desde los que se validan las pruebas automaacuteticas
Todas las implementaciones de WebDriver que se comunican con el navegador usan un protocolo punto a
punto comuacuten Este protocolo define un servicio RESTfull usando JSON sobre HTTP Cada operacioacuten
realizada por WebDriver se mapea en un meacutetodo HTTP que se comunica con el navegador Las respuestas
a dichas operaciones seraacuten devueltas en mensajes HTTP de respuesta
Existen diversas implementaciones de Selenium para diferentes entornos tal y como se muestra en la
siguiente figura
Figura 41 Implementaciones disponibles de Selenium y Navegadores Web Compatibles
Para la ejecucioacuten de las pruebas implementadas en este proyecto se ha hecho uso de los controladores Gecko
Driver y Chromedriver para los navegadores Web Firefox y Google Chrome
521 Elementos del Navegador
Una vez tenemos una viacutea de comunicacioacuten con el navegador planteamos la pregunta iquesty coacutemo le indico al
navegador con queacute componente quiero interactuar
La cantidad de componentes que existen es muy amplia cajas de texto botones imaacutegenes hiperviacutenculos
botones de radio check boxes aacutereas de texto mensajes de error desplegables tablas frames etc Todos
estos elementos tienen una serie de propiedades que pueden ser uacutenicas o no en toda la paacutegina Por ejemplo
un identificador (ID) debe distinguir de manera uniacutevoca a un elemento Este identificador es lo que se
denomina un localizador Existen 8 tipos distintos de localizadores diferentes
bull Id Name Class Name Tag Name Link Text Partial Link Text CSS Xpath
71
Se podraacuten implementar las interacciones con el navegador mediante la llamada a un meacutetodo (accioacuten) que
se aplicaraacute sobre el elemento que nosotros indiquemos A continuacioacuten se muestra el diagrama de bloques
y la implementacioacuten de un ejemplo simple del inicio de sesioacuten usando Python y la libreriacutea de Selenium
Figura 42 Coacutedigo de ejemplo con Python y Selenium
La implementacioacuten anterior permite abrir un navegador Web Chrome en pantalla completa y acceder a la
plataforma Web Galgus CHT Cloud Manager Una vez ha sido posible el acceso y la paacutegina Web estaacute
disponible se realiza el inicio de sesioacuten en la plataforma con las credenciales correspondientes esperando que
dicho inicio de sesioacuten se haya realizado con eacutexito Finalmente se cierran todas las instancias de navegadores
Web abiertas por Selenium en la automatizacioacuten de dicha prueba de concepto
72
53 Robot Framework (RF)
Para la automatizacioacuten del testeo de la aplicacioacuten se ha hecho uso de este framework como herramienta
para dicha finalidad Robot Framework es un framework geneacuterico de automatizacioacuten de pruebas de coacutedigo
abierto desarrolla do por Pekka Klaumlrck en el antildeo 2005
Este framework sigue el enfoque Keyword-Driven Testing y es un candidato idoacuteneo debido a su alto nivel
de abstraccioacuten para pruebas de aceptacioacuten y desarrollo guiado por pruebas de aceptacioacuten o Acceptance
Test-Driven Development (ATDD) Las capacidades de pruebas pueden ser ampliadas con nuevas libreriacuteas
implementadas tanto en Python como en Java y los usuarios pueden crear nuevas keywords a partir de las
existentes usando la misma sintaxis que para los casos de prueba [18]
Robot Framework es independiente del sistema operativo y de la aplicacioacuten El nuacutecleo del framework estaacute
implementado en Python soportando tanto Python 2 como Python 3
Se ha decidido utilizar este framework por la disponibilidad de un amplio conjunto de libreriacuteas de propoacutesito
general y la integracioacuten con libreriacuteas externas como Selenium2Library Entre otras prestaciones permite el
uso de variables que aportan mayor flexibilidad a la hora de disentildear y controlar los scripts de prueba
permite el etiquetado para poder identificar y ejecutar los casos de prueba por separado proporciona una
faacutecil integracioacuten con Jenkins y Maven y proporciona un sistema de reporte de informes de resultados
detallados y de faacutecil lectura Ademaacutes hay que destacar la faacutecil abstraccioacuten que ofrece al poder utlizar
keywords de alto nivel permitiendo el uso del estilo de representacioacuten Given-When-Then para los casos
de prueba A continuacioacuten se describe dicho estilo de representacioacuten
531 Estilo de representacioacuten Given-When-Then
Dicho estilo ofrecido por Robot Framework es uno de los puntos fuertes de este framework Esta caracteriacutestica
permite el uso del siguiente estilo de representacioacuten para los casos de prueba
Figura 43 Estilo de representacioacuten Given-When-Then
bull Given Define las precondiciones necesarias para llevar a cabo la accioacuten asiacute como el actor de la
misma
bull When Accioacuten llevada a cabo por el actor definido en la claacuteusula Given
bull Then Es el comportamiento esperado o la salida del sistema esperada ante una entrada
determinada
bull And Claacuteusula auxiliar que se usa de forma combinada con las anteriores
73
Como ejemplo de aplicacioacuten de este estilo de representacioacuten supongamos que tenemos unos requisitos de
aceptacioacuten establecidos en un documento entre los que se encuentran el inicio y cierre de sesioacuten mediante
usuario y contrasentildea a la plataforma Galgus CHT Cloud Manager En la siguiente tabla se muestran los
criterios de aceptacioacuten definidos en el documento de requisitos para dicha funcionalidad
1 Un usuario no identificado puede iniciar sesioacuten desde la vista principal de la plataforma Web
2 Un usuario no identificado debe insertar un usuario y contrasentildea vaacutelidos para el inicio de sesioacuten
A continuacioacuten se muestra coacutemo se llevariacutea a cabo la implementacioacuten de los scripts de pruebas abstractos
asociados a las especificaciones anteriores haciendo uso del estilo de representacioacuten Given-When-Then
Es complicado implementar todos los casos de prueba posibles principalmente cuando el requisito de
aceptacioacuten requiere de una funcionalidad compleja En este caso se muestran tres casos de prueba
abstractos los cuales han sido implementados en el proyecto para validar el inicio y cierre de sesioacuten
Caso de Prueba 1 Inicio de Sesioacuten en Galgus CHT Cloud Manager
Claacuteusula Keyword
Given Navegacioacuten a la paacutegina principal de Galgus CHT Cloud Manager
When Insertar nombre de usuario vaacutelido
And Insertar contrasentildea vaacutelida
Then Iniciar sesioacuten con eacutexito
Caso de Prueba 2 Intento de Inicio de sesioacuten con usuario no vaacutelido
Claacuteusula Keyword
Given Navegacioacuten a la paacutegina principal de Galgus CHT Cloud Manager
When Insertar nombre de usuario invaacutelido
And Insertar contrasentildea vaacutelida
Then No es posible el inicio de sesioacuten Se muestra mensaje de error
Caso de Prueba 3 Intento de Inicio de sesioacuten con contrasentildea no vaacutelida
Claacuteusula Keyword
Given Navegacioacuten a la paacutegina principal de Galgus CHT Cloud Manager
When Insertar nombre de usuario vaacutelido
And Insertar contrasentildea invaacutelida
Then No es posible el inicio de sesioacuten Se muestra mensaje de error
74
En la siguiente figura se muestra la implementacioacuten de dichas pruebas con Robot Framework donde cada
Keyword implementada permite la abstraccioacuten de toda la funcionalidad necesaria para realizar las pruebas
Figura 44 Implementacioacuten de Pruebas en para el inicio de sesioacuten de CHT Cloud Manager
75
532 Reportes
A continuacioacuten se muestra un ejemplo de los reportes obtenidos tras la ejecucioacuten del primer caso de prueba de
los anteriores donde pueden identificarse las diversas keywords necesarias para implementar cada caso de
prueba asiacute como otras adicionales que ayudan a crear el contexto (precondiciones) Tambieacuten se incluyen
estadiacutesticas sobre el tiempo de ejecucioacuten nuacutemero de tests total nuacutemero de tests que han fallado o que han pasado
con eacutexito [18]
Figura 45 Ejemplo de reporte de pruebas automatizadas con Robot Framework
76
533 Libreriacuteas
Robot Framework permite el uso de Selenium mediante la libreriacutea de pruebas Web SeleniumLibrary Dicha
libreriacutea es compatible con las versiones de Selenium 2536 y sucesivas y con Python 27 y Python 3 Ademaacutes
del inteacuterprete por defecto de Python esta libreriacutea funciona tambieacuten con PyPy y Jython [18]
Esta libreriacutea estaacute compuesta entre otras muchas por una serie de archivos de Python (py) que implementan
las clases que contienen las diversas keywords que pueden ser usadas en nuestro framework La estructura de
estos archivos se presenta en la siguiente tabla
Archivo de Clase Funcioacuten
Alertpy Interacciones con mensajes de alerta
Browsermanagementpy Apertura cierre y cambio de navegadores
Cookiepy Manipulacioacuten de cookies del navegador
Elementpy Interaccioacuten con elementos y sus atributos
Formelementpy Interaccioacuten con elementos en formularios
Framespy Manejo de frames y su contenido
Javascriptpy Facilidades para inyectar coacutedigo javascript
Runonfailurepy Uso de funcionalidades en caso de fallo
Screenshotpy Manejo de capturas de pantalla
Selectelementpy Manejo de elementos en listas
Tableelementpy Manejo de elementos en tablas
Waitingpy Manejo de temporizadores de espera para
transiciones en una paacutegina
Webdrivertoolspy Interaccioacuten directa con el controlador del navegador
Windowpy Manejo de ventanas del navegador
Estas libreriacuteas fueron desarrolladas en sus oriacutegenes por el ingeniero finlandeacutes Tatu Aalto y posteriormente
mejoradas por toda la comunidad de expertos en automatizacioacuten de pruebas Sin embargo Robot Framework
mediante el uso de Python con Selenium permite la implementacioacuten de libreriacuteas propias o funcionalidades
desarrolladas en Python que pueden ser integradas en Robot Framework En este proyecto se hace uso de Python
con Selenium para desarrollar algunas funcionalidades avanzadas que permiten probar ciertos criterios de la
aplicacioacuten muy especiacuteficos y avanzados de la plataforma Web para los cuales las libreriacuteas ofrecidas por Robot
Framework no proporcionan la funcionalidad requerida
Ademaacutes se ha hecho uso de otras libreriacuteas como BuiltIn para el uso de bucles condicionales y otras keywords
String y Collections para el tratamiento de cadenas de caracteres y colecciones de datos SSHLibrary para usar
un cliente ssh Process para la ejecucioacuten de subprocesos haciendo uso la libreriacutea subprocess de python y
OperatingSystem para realizar algunas tareas sobre el sistema operativo
77
534 Documentacioacuten
La documentacioacuten de los diferentes casos de pruebas implementados con Robot Framework es muy redundante
y una tarea la cual seriacutea deseable de poder automatizar Dicho framework ofrece esta posibilidad a traveacutes de dos
herramientas para crear documentacioacuten basada en las pruebas y libreriacuteas implementadas para dichas pruebas
Libdoc y Testdoc [18]
5341 Libdoc
Libdoc es una herramienta ofrecida por Robot Framework para construir documentacioacuten sobre las keywords
implementadas para los casos de prueba Dicha documentacioacuten es generada en formato HTML y XML
Se puede crear documentacioacuten para bibliotecas implementadas con Python o Java y para las propias libreriacuteas
implementadas con Robot Framework A continuacioacuten se muestra un ejemplo de la documentacioacuten generada
para la libreriacutea implementada para los casos de prueba de inicio y cierre de sesioacuten de Galgus CHT Cloud
Manager
Figura 46 Ejemplo de documentacioacuten generada con Libdoc
5342 Testdoc
Testdoc es una herramienta para generar documentacioacuten de alto nivel basada en los casos de prueba de Robot
Framework Dicha documentacioacuten es generada en formato HTML e incluye el nombre la documentacioacuten y
otros metadatos de cada conjunto de pruebas y casos de prueba asiacute como las keywords de alto nivel y sus
argumentos
A continuacioacuten se muestra un ejemplo de la documentacioacuten generada para el conjunto de casos de prueba que
validan el inicio y cierre de sesioacuten de Galgus CHT Cloud Manager
Figura 47 Ejemplo de documentacioacuten generada con Testdoc
78
54 Pycharm (IDE)
Esta herramienta proporciona un entorno de desarrollo integrado (IDE) el cual ha sido usado para programar en
lenguaje Python por lo que es idoacuteneo tambieacuten para el desarrollo de pruebas con Robot Framework Esta
desarrollado por la empresa JetBrains Ademaacutes proporciona entre otras muchas herramientas el anaacutelisis de
coacutedigo un depurador graacutefico integracioacuten con sistemas de control de versiones y es multiplataforma
55 GitGitlab
551 Git
Git es un software de control de versiones disentildeado por Linux Torvalds pensando en la eficiencia y la
confiabilidad del mantenimiento de versiones de aplicaciones cuando eacutestas tienen un gran nuacutemero de archivos
de coacutedigo fuente Al principio Git se pensoacute como un motor de bajo nivel sobre el cual otros pudieran escribir la
interfaz de usuario como Cogito o StGIT Sin embargo Git se ha convertido desde entonces en un sistema de
control de versiones con funcionalidad plena Hay algunos proyectos de mucha relevancia que ya usan Git en
particular el grupo de programacioacuten del nuacutecleo Linux Ademaacutes cabe destacar que se ha hecho uso de
GitKraken como interfaz graacutefica de git para llevar a cabo el control de versiones de una forma maacutes intuitiva
552 Gitlab
Gitlab es un servicio Web de control de versiones y desarrollo de software colaborativo basado en Git Fue
implementado por los desarrolladores ucranianos Dimitry Zaporozhets y Valey Sizov en el lenguaje de
programacioacuten Ruby Este proyecto cuenta con un equipo de 150 miembros y maacutes de 1400 usuarios y es usado
por empresas como la NASA el CERN IBM o Sony [19]
Ademaacutes de gestor de repositorios tambieacuten ofrece la posibilidad de alojar documentacioacuten y un sistema de
seguimiento de errores Tambieacuten es de gran importancia destacar que esta herramienta proporciona su propia
herramienta de Integracioacuten Continua sin necesidad de usar otra herramienta externa
Se ha hecho uso de estas herramientas para tener un control de versiones sobre nuestro proyecto y una gestioacuten
centralizada de todos los repositorios de la empresa de forma que asiacute podemos tener un control de versiones de
todos los cambios realizados en el coacutedigo con posibilidad de contrastarlos con versiones anteriores y recuperar
dichos cambios Ademaacutes se hace uso tambieacuten de gitlab CICD para implementar procesos de Integracioacuten
continua sobre los diferentes proyectos En el caso particular de este proyecto para generar la documentacioacuten
de los casos de test y libreriacuteas y para generar un Docker con toda la bateriacutea de pruebas y dependencias necesarias
para lanzarlas
56 Redmine
Redmine es una herramienta para la gestioacuten de proyectos que ofrece un conjunto de funcionalidades que
permiten a los usuarios de diferentes proyectos realizar el seguimiento y organizacioacuten de los mismos Incluye
un sistema de seguimiento de incidentes Otras herramientas que incluye son un calendario de actividades
diagramas de Gantt una wiki para almacenar documentacioacuten control del flujo de trabajo basado en roles
integracioacuten con correo electroacutenico etc
Esta herramienta se usa para la gestioacuten del proyecto Galgus CHT Cloud Manager donde se integra como
subproyecto la automatizacioacuten del proceso de pruebas para la plataforma Web desarrollada
A continuacioacuten se muestra un ejemplo del flujo de trabajo implantado en la metodologiacutea de trabajo dentro del
proyecto donde cada historia puede contener un conjunto de tareas las cuales pueden pasar por diferentes
estados hasta ser completadas por el desarrollador o el ingeniero de pruebas
79
Figura 48 Ejemplo de Flujo de Trabajo en Redmine para Galgus CHT Cloud Manager
561 Uso en el Proyecto Galgus CHT Cloud Manager (Metodologiacutea Scrum)
Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas praacutecticas para trabajar
colaborativamente en equipo y obtener el mejor resultado posible de un proyecto Estas praacutecticas se apoyan
unas a otras y su seleccioacuten tiene origen en un estudio de la manera de trabajar de equipos altamente productivos
Esta metodologiacutea divide el trabajo en una lista de pequentildeas funcionalidades ordenadas por prioridad y estimadas
en esfuerzo Estas pequentildeas tareas son abordadas en iteraciones cortas de longitud fija denominadas Sprints de
1 a 4 semanas (en este caso se ha optado por iteraciones de 3 o 4 semanas) obteniendo coacutedigo potencialmente
entregable siendo demostrado al final de cada iteracioacuten Una vez decidido por el equipo de gestioacuten de proyectos
el alcance y conjunto de actividades a realizar dentro del sprint se transmite al resto del equipo que forma parte
del proyecto procediendo a la asignacioacuten de tareas mediante Redmine como herramienta de gestioacuten usada
Durante el sprint se va realizando un seguimiento perioacutedico del estado del proyecto y de la situacioacuten de cada
integrante mediante una actividad previa diaria de unos 15 minutos para situar el punto de partida de trabajo
diario que seriacutean reuniones diarias de apenas 15 minutos denominadas ldquoDaylisrdquo
Figura 49 Esquema Graacutefico de Metodologiacutea Scrum
80
La planificacioacuten que se pretende seguir en cada sprint es la siguiente
1 Semana 1 y 2 Realizacioacuten de tareas por parte del equipo de desarrollo incluyendo en estas tareas
nuevos desarrollos modificacioacuten de funcionalidades y verificacioacuten de las mismas mediante pruebas
unitarias y de integracioacuten
2 Semana 3 Realizacioacuten de pruebas de aceptacioacuten manuales por parte del equipo de pruebas y posterior
automatizacioacuten de dichas pruebas Para ello se usaraacute el entorno de UAT como escenario de pruebas
Ademaacutes el equipo de desarrollo iraacute corrigiendo todos aquellos errores o defectos encontrados
3 Semana 4 El jefe de proyecto realiza la fusioacuten de todos los desarrollos y actualiza las versiones en el
entorno de Preproduccioacuten incluyendo todas las actividades realizadas y validadas por el equipo de
desarrollo y de pruebas El equipo de pruebas realizaraacute la ejecucioacuten de todas las pruebas End-to-End
sobre el entorno de Preproduccioacuten para verificar y validar la nueva versioacuten que incluye todas las
funcionalidades Estas pruebas son denominadas pruebas de regresioacuten las cuales verifican que los
nuevos desarrollos no han provocado defectos o errores sobre funcionalidades que hasta ahora habiacutean
funcionado correctamente Finalmente el jefe de proyecto realiza el despliegue en produccioacuten
81
82
6 EXPERIMENTOS
na vez descrito el sistema bajo pruebas el proceso de pruebas y las herramientas que se usaraacuten para
automatizar las pruebas de aceptacioacuten sobre la plataforma de gestioacuten Galgus CHT Cloud Manager
solo queda presentar la forma en la que se ha puesto en praacutectica y el proceso seguido paso a paso
Dado que el objetivo es conseguir una bateriacutea de casos de pruebas End-to-End automatizadas se implementaraacuten
dichos casos de prueba de forma que permitan detectar el incorrecto funcionamiento de cada funcionalidad con
la mayor rapidez posible cubriendo los principales escenarios donde puedan surgir los mayores errores Por
tanto dichos casos de prueba seraacuten elegidos en base al riesgo que puedan introducir
Estos casos de prueba seraacuten definidos mediante un conjunto de criterios de aceptacioacuten descritos a traveacutes de
diagramas de flujo y agrupados seguacuten la funcionalidad de la aplicacioacuten que abarquen las cuales son
1 Vista de Gestioacuten Principal (Coud Tab) Esta seccioacuten de la Web estaacute destinada a la administracioacuten de
usuarios administracioacuten de los diferentes Zone Managers y finalmente incluye un Mapa con la
ubicacioacuten de cada Zone Manager
2 Vista de Configuracioacuten (Configuration Tab) En esta pestantildea se ofrece la gestioacuten de grupos de puntos
de acceso gestioacuten de backups y restauracioacuten gestioacuten de firmwares zonas CHT etc
3 Vista de Red (Network Tab) La pestantildea de red engloba toda la configuracioacuten de red de los puntos de
acceso siendo esta la pestantildea con mayor funcionalidad complejidad y por ello potencial de riesgo de
errores de la plataforma Web
Figura 50 Logo de Galgus CHT Cloud Manager
U
La uacutenica parte donde el ldquoeacutexitordquo aparece antes que el trabajo es en el diccionario
Vidal Sasoon
83
61 Estructura del Proyecto
La clasificacioacuten funcional anterior seraacute tomada de la misma forma para organizar la estructura del proyecto de
pruebas automatizadas con Robot Framework para un desarrollo ordenado y loacutegico de todo el conjunto de casos
de prueba A continuacioacuten se muestra un ejemplo de la estructura del proyecto el cual se encuentra en desarrollo
y continua mejora
Figura 51 Estructura del Proyecto
Para una mayor modularidad y limpieza en el desarrollo de los casos de Test se han centralizado todos los
localizadores en un archivo llamado ldquoSelectorpyrdquo En la siguiente figura se muestra un fragmento de dicho
fichero
Figura 52 Fragmento del fichero ldquoSelectorpyrdquo
A la hora de obtener los localizadores de los elementos que seraacuten comprobados o usados en los scripts de pruebas
se han usado las herramientas de desarrollador que incluye Google Chrome Para ello basta con navegar a la
paacutegina de la plataforma Web en cualquier navegador y pulsar la tecla F12 Esto mostraraacute las herramientas de
desarrolladores donde encontramos una pestantildea llamada ldquoElementosrdquo donde se puede inspeccionar el
documento ldquoHTMLrdquo de la paacutegina Una vez abierta dicha herramienta seraacute sencillo obtener propiedades de los
diversos elementos que nos permitiraacuten hacer referencia a los mismos en nuestro script de pruebas
Los ldquoXpathrdquo absolutos seraacuten lo usados praacutecticamente en toda la Suite de pruebas El beneficio de los
identificadores uacutenicos es que permiten seleccionar elementos sin que sea necesario hacer referencia a su posicioacuten
dentro del documento HTML Esto evita cualquier problema en caso de que las rutas de un elemento dentro del
citado documento cambien debido a mejoras o despistes por parte de los desarrolladores En cambio usar
selectores basados en la ruta del elemento dentro del documento HTML puede propiciar falsos fallos en el
escenario anterior debido a que no puedan encontrarse en la Web a pesar de que realmente sigan estando
presentes y totalmente funcionales
Por otro lado se han agrupado todas aquellas ldquokeywordsrdquo que puedan ser usadas por otras secciones en la
implementacioacuten de los casos de prueba mediante ficheros nombrados como ldquotab_common_keywords robotrdquo
84
Siguiendo esta jerarquiacutea se ha incluido un fichero llamado ldquoCommon_Keywordsrobotrdquo general en el que se
incluyen las principales ldquokeywordsrdquo que pueden ser usadas en todo el proyecto A continuacioacuten se muestra un
fragmento de este fichero
Figura 53 Fragmento del fichero ldquoCommon_Keywordsrobotrdquo
Tambieacuten se incluye el fichero ldquoConfigurationrobotrdquo para agrupar definiciones de variables que seraacuten
usadas en todo el proyecto ademaacutes de realizar la inclusioacuten de las libreriacuteas a usar Se muestra otra figura
con un fragmento del fichero ldquoConfigurationrobotrdquo
Figura 54 Fragmento del fichero de Configuracioacuten de pruebas ldquoConfigurationrobotrdquo
85
A continuacioacuten se muestra un diagrama que muestra las dependencias de los diferentes archivos y la estructura
seguida por el proyecto
Figura 55 Diagrama de paquetes del proyecto de pruebas
Tras introducir la estructura del proyecto y las diferentes funcionalidades de la plataforma Web Galgus CHT
Cloud Manager a continuacioacuten se mostraraacuten algunos criterios de aceptacioacuten de cada funcionalidad a probar
con diagramas de flujo y scripts de pruebas haciendo uso del estilo de representacioacuten Given-When-Then
Ademaacutes se mostraraacuten algunos detalles de implementacioacuten sobre las pruebas Por otro lado la ejecucioacuten de los
casos de prueba de ejemplo y el reporterevisioacuten de resultados se incluiraacute en la seccioacuten de Anexos
Cada una de las siguientes subsecciones dentro de cada funcionalidad principal de la aplicacioacuten o vista principal
tendraacute su correspondiente Suite de pruebas con un conjunto de casos de Test Todas estas Suites seguiraacuten la
siguiente estructura comuacuten para los casos de Test
Figura 56 Estructura de una Suite de Pruebas
86
Todas las Suites comienzan con una seccioacuten de documentacioacuten para describir el contenido de las pruebas de forma geneacuterica y varias secciones para importar los recursos necesarios para las pruebas (Resource)
Las secciones ldquoSuite Setuprdquo y ldquoSuite Teardownrdquo permiten la ejecucioacuten automaacutetica antes y despueacutes de la bateriacutea de pruebas y las secciones ldquoTest Setuprdquo y ldquoTest Teardownrdquo permiten la ejecucioacuten automaacutetica antes y despueacutes de cada caso de prueba
Un uso tiacutepico de ldquoSuite Setuprdquo es abrir un navegador Web y comprobar la disponibilidad de la Web a probar mientras que el cierre del navegador se realiza con ldquoSuite Teardownrdquo De este modo sea cual sea el resultado de la ejecucioacuten no se quedaraacuten abiertas ventanas gastando recursos de la maacutequina
Por otro lado el uso por defecto de ldquoTest Setuprdquo en este proyecto ha sido el inicio de sesioacuten en la Web CHT Cloud Manager mientras que ldquoTest Teardownrdquo ha sido usado para cerrar tambieacuten el navegador Web Sin embargo la mayoriacutea de las pruebas implementadas necesitan una serie de precondiciones previas a la ejecucioacuten del Test y un conjunto de postcondiciones necesarias para no provocar inconsistencias entre la ejecucioacuten de diferentes pruebas Por este motivo se ha hecho uso de las etiquetas [Setup] y [Teardown] para modificar la ejecucioacuten por defecto de ldquoTest Setuprdquo y ldquoTest Teardownrdquo en cada caso de prueba cuando sea necesario
Cabe destacar que la loacutegica implementada dentro de estas claacuteusulas no requiere que sea validada puesto que su uacutenico objetivo es preparar el entorno de pruebas para ejecutar una prueba sin que esta falle por causas ajenas al aacutembito y objetivo de la prueba evitando de esta forma los falsos positivos Por este motivo se hace uso de la Keyword ldquoRun Keyword And Ignore Errorrdquo ofrecida por la libreriacutea ldquoBuiltInrdquo para ignorar los errores en la ejecucioacuten de [Setup] y [Teardown] En la siguiente figura se muestra un ejemplo de dicha teacutecnica
Figura 57 Ejemplo de ldquoTest Setuprdquo personalizado para un caso de prueba
Finalmente la implementacioacuten de las ldquokeywordsrdquo usadas mediante la nomenclatura Given-When-Then seraacuten agrupadas en el correspondiente fichero ldquoTab_common_keywordsrobotrdquo para conseguir una abstraccioacuten de la loacutegica necesaria para la automatizacioacuten de las pruebas En las pruebas seleccionadas para describir en esta seccioacuten se detallaraacute la implementacioacuten de algunas keywords que se usaraacuten
87
62 Vista de Gestioacuten Principal (Cloud Tab)
En la siguiente figura se muestra la vista de Gestioacuten Principal de Galgus CHT Cloud Manager
Figura 58 Vista de Gestioacuten Principal (Cloud Tab)
Sobre esta vista se han automatizado un conjunto de Suites de pruebas que validan toda la funcionalidad
contenida en las pestantildeas MAP List of Zone Managers y Administration ademaacutes de toda la loacutegica ofrecida para
gestionar un conjunto de fabricantes
621 Administration
Comenzando con la pestantildea de administracioacuten se puede observar la existencia de cuatro flujos de navegacioacuten
principales en la siguiente figura
Figura 59 Pestantildea ldquoAdministrationrdquo
Una vez conocida la vista de administracioacuten de la Web se han realizado un total de 22 casos de prueba de los
cuales detallaremos el caso de prueba identificado con la etiqueta U0027
6211 Criterios de Aceptacioacuten
La pestantildea de administracioacuten permite la gestioacuten de los usuarios y roles que tienen acceso a la plataforma Web
ademaacutes de la configuracioacuten de los detalles de los fabricantes seleccionados A continuacioacuten se detallan los
criterios de aceptacioacuten del caso de prueba seleccionado
U0027 Un usuario con permisos de Super Usuario puede editar la informacioacuten de un fabricante
1 Un usuario con permisos de Super Usuario puede ver y acceder a la pestantildea de administracioacuten
2 Un usuario con permisos de Super Usuario puede editar la informacioacuten de un fabricante correctamente
88
6212 Diagramas de Flujo
A continuacioacuten se muestran los diagramas de flujo implementados para los dos casos de prueba analizados
Figura 60 Diagramas de Flujo de Casos de Prueba U0025 y U0027
6213 Script de Pruebas
Una vez establecidos los criterios de aceptacioacuten de ambos casos de prueba se mostraraacuten los scripts de pruebas
realizados
Figura 61 Script de Pruebas U0025
Entre las ldquokeywordsrdquo usadas en el caso de test anterior se puede destacar por ejemplo la implementacioacuten de
ldquoEdit Fieldsrdquo la cual permite editar los campos de un fabricante y verificar que han sido editados tras guardar
los cambios
Figura 62 Keyword ldquoEdit Fieldsrdquo
89
622 List
En la pestantildea de gestioacuten de los diferentes Zone Managers se puede observar una lista de los diferentes Zone
Managers disponibles y se pueden realizar un conjunto de acciones como la creacioacuten de nuevos Zone Managers
y edicioacuten o eliminacioacuten de los existentes entre otras
Figura 63 Pestantildea ldquoList of Zone Managersrdquo
Sobre esta vista se han realizado un total de 7 casos de prueba de los cuales detallaremos el caso de prueba
identificado con la etiqueta U0023 el cual permite validar la creacioacuten y eliminacioacuten de un Zone Manager
6221 Criterios de Aceptacioacuten
A continuacioacuten se detallan los criterios de aceptacioacuten del caso de prueba seleccionado
U0023 Verificar que un Usuario puede Crear y Eliminar un Zone Manager
1 Un usuario con permisos de Super Usuario puede Navegar a la pestantildea List Of Zone Managers
2 El usuario puede crear un Zone Manager correctamente
3 El usuario puede eliminar un Zone Manager correctamente
6222 Diagramas de Flujo
A continuacioacuten se muestra el diagrama de flujo implementado para el caso de prueba analizado
Figura 64 Diagrama de flujo de Caso de Prueba U0023
90
6223 Script de Pruebas
Una vez establecidos los criterios de aceptacioacuten se mostraraacute el script de pruebas realizado a partir del diagrama
de flujo anterior
Figura 65 Script de Prueba U0023
Cabe destacar la implementacioacuten de la Keyword ldquoZone Manager is Registered Successfullyrdquo la cual comprueba
que el Zone Manager registrado pasa a un estado ldquoOnlinerdquo tras un tiempo considerado como aceptable para que
la instancia de dicho Zone Manager este disponible en Cloud CHT Manager
Figura 66 Keyword ldquoZone Manager is registered successfullyrdquo
623 Manufacturer
La vista de gestioacuten principal ofrece una seccioacuten que permite la gestioacuten de los diferentes fabricantes permitiendo
su creacioacuten edicioacuten eliminacioacuten y bloqueo En la siguiente figura se muestra un ejemplo de la seccioacuten de
fabricantes
Figura 67 Seccioacuten de Fabricantes
Para validar el correcto funcionamiento de dicha seccioacuten se han realizado un total de 9 casos de prueba de los
cuales se detallaraacuten los casos de prueba identificados con las etiquetas U0009 Estos permiten validar que los
fabricantes pueden ser creados editados y eliminados correctamente y que todos los fabricantes disponibles son
mostrados correctamente
91
6231 Criterios de Aceptacioacuten
A continuacioacuten se detallan los criterios de aceptacioacuten de los casos de prueba seleccionados
U0009 Verificar que un Usuario con permisos de Super usuario puede ver correctamente todos los
fabricantes existentes
1 Un usuario con permisos de Super Usuario puede Navegar a la pestantildea de Administracioacuten
2 El usuario puede visualizar todos los fabricantes existentes
6232 Diagrama de Flujo
Figura 68 Diagrama de flujo de Caso de Prueba U0009
6233 Script de Pruebas
Una vez establecidos los criterios de aceptacioacuten se mostraraacuten los scripts de pruebas realizados a partir de los
diagramas de flujo anteriores
Figura 69 Script de Prueba U0009
En este punto cabe destacar la finalidad de la Keyword ldquoCorrectly Createrdquo la cual se usa en la mayoriacutea de las
pruebas para verificar que una operacioacuten se ha realizado con eacutexito en la plataforma Galgus CHT Cloud Manager
Esta Keyword verifica que tras realizar alguacuten tipo de operacioacuten en la plataforma Web ocurre un evento sobre la
Web que indica que dicha operacioacuten se ha realizado con eacutexito de la siguiente forma
92
Figura 70 Toast Success
Figura 71 Keyword ldquoCorrectly Createrdquo
Finalmente se muestra la implementacioacuten de las keywords usadas en [Setup] y [Teardown] del caso de prueba
U0009 las cuales preparan el escenario de pruebas creando un conjunto de fabricantes acotado y los elimina
tras la finalizacioacuten de la prueba
Figura 72 Setup amp Teardown de U0008
624 MAP
La plataforma Galgus CHT Cloud Manager ofrece una pestantildea ldquoMAPrdquo que contiene un mapa con la ubicacioacuten
asignada a cada uno de los Zone Managers disponibles por el usuario mostrando en su ubicacioacuten un icono con
el estado de dicho Zone Manager el cual cambia de color seguacuten su estado (offline online unsynchronized)
Figura 73 Mapa de Zone Managers
93
A traveacutes de dicho icono se puede realizar una serie de acciones entre ellas acceder a un Zone Manager
realizando doble click sobre el icono del mismo Sin embargo para automatizar este conjunto de acciones el
equipo de pruebas ha encontrado dificultades haciendo uso de Robot Framework ya que las libreriacuteas disponibles
permiten la interaccioacuten con elementos de la Web pero en este caso los iconos de los diferentes Zone Managers
son renderizados dentro del Mapa con ldquoOpen Street Mapsrdquo antes de ser mostrado en la vista Web de la
aplicacioacuten Por esta razoacuten el mapa es localizado en el DOM como un uacutenico elemento Web lo que imposibilita
localizar a priori el icono de cada Zone Manager dentro del Mapa
Para resolver este impedimento el equipo de pruebas tuvo que analizar con profundidad la libreriacutea de ldquoOpen
Street Maprdquo implementada en Javascript Esta ha sido usada en el Frontend para encontrar alguna funcioacuten que
permitiese obtener desde la consola del navegador Web los piacutexeles en los que cada Zone Manager ha sido
renderizado dentro del Mapa Dicha funcioacuten es ldquogetPixelsFromCoordinate(coordinate)rdquo la cual a traveacutes de las
coordenadas de [Latitud Longitud] de cada Zone Manager se obtienen los piacutexeles del mismo en la pantalla A
traveacutes del siguiente fragmento de coacutedigo en el frontend implementado con Angular 6 en typescript se consigue
obtener los piacutexeles de cada Zone Manager e imprimirlo en la consola del navegador Web
Figura 74 Funcioacuten que dibuja los ZM en el Mapa y obtiene los piacutexeles en pantalla
Para llevar a cabo la implementacioacuten de las pruebas sobre el mapa se ha hecho uso en su gran mayoriacutea de Scripts
con Python Selenium y otras libreriacuteas necesarias en lugar de Robot Framework debido a la necesidad de
realizar varias tareas simultaneas ademaacutes de tratarse de pruebas muy especiacuteficas y personalizadas A
continuacioacuten se muestra la prueba implementada para poder realizar doble click sobre un Zone manager en el
mapa e iniciar sesioacuten en el mismo (U0007)
6241 Criterios de Aceptacioacuten
U0007 Verificar que un Usuario acceder a un Zone Manager desde el Mapa
1 Un usuario con permisos de Super Usuario puede Navegar a la pestantildea MAP
2 El usuario puede hacer doble click en el Zone Manager e iniciar sesioacuten
94
6242 Diagrama de Flujo
Figura 75 Diagrama de Flujo de Caso de Prueba U0007
6243 Script de Pruebas
Para la implementacioacuten de este tipo de casos de prueba se ha hecho uso de la libreriacutea ldquoHtmlTestRunnerrdquo para
obtener un reporte similar al ofrecido por Robot Framework en la ejecucioacuten de la prueba Para obtener un reporte
de la prueba la implementacioacuten de la misma debe seguir una estructura determinada a la que ademaacutes se ha
incluido a traveacutes de la libreriacutea ldquomultiprocessingrdquo la ejecucioacuten simultaacutenea de los dos procesos descritos en el
diagrama de flujo anterior Es necesaria la ejecucioacuten de varios procesos para leer la consola del navegador Web
y obtener los piacutexeles de los Zone Manager para posteriormente hacer doble click
En la Seccioacuten A3 de los anexos puede encontrarse la implementacioacuten del script de pruebas para el caso de
prueba U0007
95
63 Vista de Configuracioacuten (Configuration Tab)
En esta vista se ha automatizado un conjunto de Suites de prueba que validan toda la funcionalidad contenida
en las pestantildeas Groups CHT Zones BackupRestore y Firmware
631 Groups
La pestantildea de grupos permite el descubrimiento de los puntos de acceso a traveacutes de su direccioacuten MAC quedando
estos registrados en base de datos y mostrando al usuario en una tabla los puntos de acceso registrados ademaacutes
del estado de los mismos y otros datos como el modelo o grupo al que pertenecen
Figura 76 Pestantildea ldquoGroupsrdquo
Sobre esta funcionalidad de la plataforma se han realizado un total de 19 casos de prueba de los cuales
detallaremos el caso de prueba identificado con la etiqueta U0119
6311 Criterios de Aceptacioacuten
U0119 Verificar que al descubrir dos puntos de acceso en grupos diferentes ambos son antildeadidos en el
grupo correcto
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Configuracioacuten
3 El usuario puede Navegar a la pestantildea de Grupos
4 El usuario puede descubrir un punto de acceso en el grupo ldquorootrdquo correctamente
5 El usuario puede crear un subgrupo predecesor del grupo ldquorootrdquo correctamente
6 El usuario puede navegar al subgrupo creado correctamente
7 El usuario puede descubrir un punto de acceso en el subgrupo correctamente
96
6312 Diagramas de Flujo
Figura 77 Diagrama de flujo de Caso de Prueba U0119
97
6313 Script de Pruebas
Una vez establecidos los criterios de aceptacioacuten el script de prueba realizado a partir del diagrama de flujo
anterior es el siguiente
Figura 78 Script de Prueba U0119
Entre las keywords implementadas para esta prueba cabe destacar la implementacioacuten de ldquoVerify if AP is
registered Succesfully on grouprdquo la cual permite validar si un punto de acceso ha sido asignado al grupo
correcto
Figura 79 Keyword ldquoVerify if AP is registered Succesfully on grouprdquo
Puede observarse como en primer lugar se obtiene la fila de la tabla que contiene el punto de acceso en cuestioacuten
para posteriormente comprobar si el grupo al que pertenece es el esperado
Observando dicha implementacioacuten cabe destacar el uso de la Keyword ldquoInput Into Text Fieldrdquo la cual ha sido
implementada para vaciar el contenido de campos de texto ya que mediante la Keyword ldquoClear Element Textrdquo
de la libreriacutea Selenium2Library no se conseguiacutea borrar ciertos campos de texto
Figura 80 Keywords Input Into Text Field y Clear Field Of Characters
98
632 CHT Zones
En la pestantildea de gestioacuten de las diferentes Zonas CHT se puede observar una lista de los puntos de acceso
disponibles y se pueden realizar un conjunto de acciones sobre ellos como la creacioacuten eliminacioacuten y asociacioacuten
de zonas CHT
En este punto es conveniente explicar el concepto de zona CHT el cual se refiere a un grupo IP Multicast a
traveacutes del cual un conjunto de Puntos de Acceso establece comunicacioacuten de forma colaborativa Esta
comunicacioacuten es necesaria para el funcionamiento de algunos de los algoritmos que ofrece CHT como por
ejemplo la asignacioacuten automaacutetica de canal (ACA)
Figura 81 Pestantildea ldquoCHT Zonesrdquo
Sobre esta vista se han realizado un total de 6 casos de prueba de los cuales detallaremos el caso de prueba
identificado con la etiqueta U0204 Este caso de prueba permite validar la asignacioacuten de zonas CHT a los Puntos
de Acceso
6321 Criterios de Aceptacioacuten
U0204 Verificar que un usuario puede asignar una Zona CHT a un punto de acceso correctamente
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Configuracioacuten
3 El usuario puede Navegar a la pestantildea de Grupos
4 El usuario puede asignar una Zona CHT existente a un punto de acceso registrado correctamente
99
6322 Diagramas de Flujo
Figura 82 Diagrama de Flujo de Caso de Prueba U0204
6323 Script de Pruebas
Tras presentar los criterios de aceptacioacuten y su correspondiente diagrama de flujo el script de pruebas
implementado para la automatizacioacuten de dicha prueba es el siguiente
Figura 83 Scripts de Prueba U0204
Figura 84 Keyword Add Zone CHT to AP
100
633 BackupRestore
En esta pestantildea se permite la gestioacuten de copias de seguridad y restauracioacuten de los puntos de acceso registrados
en un Zone Manager Se puede observar en esta vista una tabla con los puntos de acceso registrados y otra tabla
con las copias de seguridad realizadas sobre los puntos de acceso
Figura 85 Pestantildea BackupRestore
Partiendo de la representacioacuten funcional de esta vista se han realizado un total de 8 casos de prueba de los
cuales detallaremos el caso de prueba identificado con la etiqueta U0401 el cual permite verificar de forma
automaacutetica la realizacioacuten de un backup sobre un punto de acceso y su posterior restauracioacuten
6331 Criterios de Aceptacioacuten
U0401 Verificar que un usuario puede realizar un BackupRestore correctamente sobre un punto de
acceso previamente registrado
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Configuracioacuten
3 El usuario puede Navegar a la pestantildea de BackupRestore
4 El usuario puede realizar un Backup sobre un punto de acceso existente
5 La tabla de Backups contiene la copia de seguridad realizada
6 El usuario puede restaurar un punto de acceso correctamente
101
6332 Diagramas de Flujo
Figura 86 Diagrama de Flujo de Caso de Prueba U0401
6333 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 87 Script de Prueba U0401
Cabe destacar la implementacioacuten de la Keyword ldquoRestore for AP have done successfullyrdquo la cual verifica que
el punto de acceso ha sido restaurado correctamente esperando que el punto de acceso vuelva a estar en estado
ldquoonlinerdquo durante un tiempo aceptable Si pasado dicho tiempo no recupera dicho estado la prueba se dariacutea por
erroacutenea
Figura 88 Keyword Restore For AP hace done successfully
634 Firmware
Esta uacuteltima pestantildea de la vista principal de configuracioacuten proporciona al usuario la posibilidad de subir los
firmwares de los diferentes modelos de puntos de acceso en sus diferentes versiones del software CHT de forma
que es posible la actualizacioacuten del firmware de los puntos de acceso desde la plataforma Se puede observar en
esta vista una tabla con los puntos de acceso registrados y otra tabla con los firmwares subidos a la plataforma
102
Figura 89 Pestantildea ldquoFirmwarerdquo
Partiendo de la representacioacuten funcional de esta vista se han realizado un total de 7 casos de prueba de los
cuales detallaremos el caso de prueba identificado con la etiqueta U0303 el cual permite verificar de forma
automaacutetica la actualizacioacuten del firmware de un punto de acceso
6341 Criterios de Aceptacioacuten
U0303 Verificar que un usuario puede realizar correctamente la actualizacioacuten del firmware de un punto
de acceso
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Configuracioacuten
3 El usuario puede Navegar a la pestantildea de Firmware
4 El usuario puede subir un firmware correctamente
5 La tabla de Firmwares contiene la imagen de CHT subida a la plataforma
6 El usuario puede realizar la actualizacioacuten del firmware sobre un punto de acceso correctamente
Destacar que el firmware que se desea aplicar sobre un punto de acceso debe ser del modelo correspondiente al
punto de acceso usado ya que cada punto de acceso tiene una imagen de CHT compilada para una arquitectura
hardware determinada Las imaacutegenes son proporcionadas por un servidor interno de la empresa
103
6342 Diagramas de Flujo
Figura 90 Diagrama de Flujo de Caso de Prueba U0303
6343 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 91 Script de Prueba U0303
Cabe destacar la implementacioacuten de la Keyword ldquoFlash APrdquo la cual realiza la actualizacioacuten del firmware de un
punto de acceso verificando que este ha concluido correctamente Para ello espera un tiempo aceptable a que el
punto de acceso vuelva al estado ldquoonlinerdquo
Figura 92 Keyword Flash AP
104
64 Vista de Red (Network Tab)
La uacuteltima vista principal sobre la que se han automatizado pruebas es la vista de Red la cual ofrece al usuario
la gestioacuten y configuracioacuten de su red formada por un conjunto de puntos de acceso previamente registrados
Entre las funcionalidades ofrecidas se encuentran la creacioacuten de VLANS SSIDs Portales Cautivos Perfiles
Radius Activacioacuten de algoritmos CHT y la configuracioacuten de puntos de acceso en tiempo real desde la
plataforma Web
Para describir el proceso de automatizacioacuten se comenzaraacute detallando en primer lugar la creacioacuten de VLANS
Brigdes y SSIDs para posteriormente aplicar dichos paraacutemetros a puntos de acceso desde las pestantildeas ldquoGeneralrdquo
y ldquoAP Networkrdquo Finalmente se mostraraacuten algunos ejemplos sobre otras configuraciones maacutes avanzadas como
la creacioacuten y aplicacioacuten de perfiles radius y portales cautivos ademaacutes de la activacioacuten de algoritmos
641 VLANS amp Bridges
Comenzando con la pestantildea de VLANS amp Bridges se puede observar la existencia de una tabla para cada
elemento de dicha vista
Figura 93 Pestantildea ldquoVLAN amp Bridgesrdquo
Para cada elemento se han automatizado un conjunto de pruebas formado por 6 casos de prueba de los cuales
detallaremos el caso de prueba identificado con la etiqueta U0527 Este caso de prueba permite validar de forma
automaacutetica la creacioacuten y eliminacioacuten de VLANs De forma ideacutentica se procederiacutea para validar la creacioacuten y
eliminacioacuten de Bridges
6411 Criterios de Aceptacioacuten
A continuacioacuten se detallan los criterios de aceptacioacuten del caso de prueba seleccionado
U0527 Verificar que un usuario puede crear y eliminar una VLAN correctamente
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Network
3 El usuario puede Navegar a la pestantildea de VLANS amp Bridges
4 El usuario puede crear una VLAN correctamente
5 El usuario puede eliminar una VLAN correctamente
105
6412 Diagramas de Flujo
Figura 94 Diagrama de Flujo de Caso de Prueba U0527
6413 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 95 Script de Prueba U0527
Cabe destacar la implementacioacuten de la Keyword ldquoGo and Create VLANrdquo la cual permite crear una VLAN en
funcioacuten de los paraacutemetros de entrada deseados para configurar dicha VLAN como por ejemplo el ldquoIDrdquo de la
VLAN y alias o si se desea que dicha VLAN sea de tipo dinaacutemica
Figura 96 Keyword Go And Create VLAN
106
642 SSIDs
Esta pestantildea proporciona una tabla que permite registrar SSIDs con diferentes configuraciones posibles
Figura 97 Pestantildea SSIDs
Para cada funcionalidad de dicha pestantildea se han automatizado un conjunto de pruebas formado por 5 casos de
prueba de los cuales detallaremos el caso de prueba identificado con la etiqueta U0530 Este caso de prueba
permite validar de forma automaacutetica la creacioacuten y eliminacioacuten de SSIDS
6421 Criterios de Aceptacioacuten
A continuacioacuten se detallan los criterios de aceptacioacuten de los dos casos de prueba seleccionados
U0530 Verificar que un usuario puede crear y eliminar una SSID correctamente
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Network
3 El usuario puede Navegar a la pestantildea de SSIDs
4 El usuario puede crear una SSID correctamente
5 El usuario puede eliminar una SSID correctamente
6422 Diagramas de Flujo
Figura 98 Diagrama de Flujo de Caso de Prueba U0530
107
6423 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 99 Script de Prueba U0530
Cabe destacar la implementacioacuten de la Keyword ldquoGo and Create SSIDrdquo la cual permite crear una SSID en
funcioacuten de los paraacutemetros de entradas deseado para configurar dicha SSID como por ejemplo tipo de
encriptacioacuten de la contrasentildea modo oculto o habilitacioacuten de los algoritmos Load Balancing (LB) Smart
roaming (SR) o PRE
Figura 100 Keyword Go And Create SSID
108
643 CHT
Esta funcionalidad permite activar el algoritmo que permite la seleccioacuten automaacutetica de canal entre un conjunto
de puntos de acceso (ACA) Cuando se activa desde la plataforma Web todos los puntos de acceso
pertenecientes a un Zone Manager activan dicho algoritmo el cual se trata de un algoritmo colaborativo
mediante el cual los puntos de acceso acuerdan cual es el mejor canal para la comunicacioacuten WiFi con los clientes
que se conecten tanto en la banda de 24 GHz como en la de 5 GHz En la siguiente figura se muestra la vista
de la plataforma Web para activar el algoritmo en cuestioacuten
Figura 101 Pestantildea ldquoCHTrdquo
Dado que se trata de una funcionalidad en la que solo se debe comprobar si el algoritmo estaacute en el mismo estado
tanto en la plataforma Web como en los puntos de acceso registrados se ha implementado un uacutenico caso de
prueba identificado con la etiqueta U539 Este caso de prueba realiza la conexioacuten a los puntos de acceso para
verificar que dicho algoritmo presenta el mismo estado que en la plataforma
6431 Criterios de Aceptacioacuten
U0537 Verificar que un usuario puede Activar o Desactivar el algoritmo ACA correctamente
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Network
3 El usuario puede Navegar a la pestantildea de CHT
4 El usuario puede ActivarDesactivar el algoritmo ldquoACA ldquocorrectamente
5 Los APs recibieron las oacuterdenes para ActivarDesactivar el algoritmo ldquoACArdquo correctamente
109
6432 Diagramas de Flujo
Figura 102 Diagrama de Flujo de Caso de Prueba U0539
6433 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 103 Script de Prueba U0539
En cuanto a la implementacioacuten de dicho caso de prueba cabe destacar la implementacioacuten de la Keyword ldquoACA
Is Workingrdquo las cual se muestra en la siguiente figura
Figura 104 Keyword ACA Is Working
Puede observarse como en funcioacuten de si el algoritmo ACA esta activado o desactivado en la plataforma Web
(ENABLE DISABLE) se ejecuta la Keyword ldquoChanges On CLIrdquo con diferentes paraacutemetros Esta Keyword
permite la conexioacuten viacutea ldquoSSHrdquo con un punto de acceso para la ejecucioacuten de un comando sobre el mismo y la
posterior comparacioacuten del resultado obtenido por dicho comando con la salida deseada proporcionada tambieacuten
como paraacutemetro de la Keyword
110
En la siguiente figura se muestra la implementacioacuten de dicha Keyword
Figura 105 Keyword Changes On CLI
Para este caso de prueba el comando ejecutado de forma remota sobre el punto de acceso permite obtener de
forma automaacutetica el estado del algoritmo ldquoACArdquo de la siguiente forma
Figura 106 Comando CHT para obtener el estado del moacutedulo ACA en el punto de acceso
644 Radius
Esta pestantildea proporciona una tabla que permite registrar perfiles Radius con diferentes configuraciones posibles
Figura 107 Pestantildea ldquoRadiusrdquo
ldquoRadiusrdquo se define como un protocolo de autenticacioacuten y autorizacioacuten para aplicaciones de acceso a la red o
movilidad IP De esta forma los puntos de acceso mediante la existencia de un servidor radius permiten que los
usuarios que se quieran conectar por WiFi necesiten ser autenticados con credenciales Dicha autenticacioacuten seraacute
redirigida por el punto de acceso al servidor radius el cual autoriza al punto de acceso para que permita la
conexioacuten del cliente
Ademaacutes el uso de este servicio junto con la configuracioacuten mediante VLAN dinaacutemicas permite que diferentes
usuarios accedan al servicio de red con diferentes credenciales de forma que seguacuten el tipo de cliente su traacutefico
viajaraacute por una VLAN u otra Esto permite la separacioacuten del traacutefico a nivel de enlace ofreciendo la posibilidad
de establecer reglas de control de traacutefico y ofrece una QoS miacutenima en funcioacuten del tipo de cliente
Figura 108 Escenario de Funcionamiento de Servidor Radius
111
Para cada funcionalidad de dicha pestantildea se han automatizado un conjunto de pruebas formado por 7 casos de
prueba de los cuales detallaremos el caso de prueba identificado con la etiqueta U0601 Este caso de prueba
permite validar de forma automaacutetica la creacioacuten edicioacuten y borrado de un perfil radius en la plataforma Web
6441 Criterios de Aceptacioacuten
U0601 Verificar que un usuario puede crear editar y borrar un perfil Radius correctamente
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Network
3 El usuario puede Navegar a la pestantildea de Radius
4 El usuario puede Crear un perfil Radius correctamente
5 El usuario puede Editar un perfil Radius correctamente
6 El usuario puede Eliminar un perfil Radius correctamente
6442 Diagramas de Flujo
Figura 109 Diagrama de Flujo de Caso de Prueba U0601
6443 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 110 Script de Prueba U0601
En cuanto a la implementacioacuten de dicho caso de prueba puede destacarse por ejemplo la implementacioacuten de
la Keyword ldquoCreate Radius Profilerdquo la cual permite crear un perfil ldquoRadiusrdquo a partir de un conjunto de
paraacutemetros de entrada
112
Figura 111 Keyword Create Radius Profile
645 Captive Portal
Esta pestantildea proporciona una tabla que permite registrar perfiles de Portales Cautivos con diferentes
configuraciones posibles
Figura 112 Pestantildea Captive Portals
Un portal cautivo es un servicio que permite el control del traacutefico HTTP y fuerza a los usuarios de una red a la
autenticacioacuten mediante una paacutegina Web para tener acceso a Internet Dicho portal permite controlar paraacutemetros
como el tiempo de conexioacuten de un cliente a la red ancho de banda ofrecido a cada cliente etc
Figura 113 Escenario de Funcionamiento de un Portal Cautivo
Para cada funcionalidad de dicha pestantildea se han automatizado un conjunto de pruebas formado por 5 casos de
prueba de los cuales detallaremos el caso de prueba identificado con la etiqueta U0701 Este caso de prueba
permite validar de forma automaacutetica la creacioacuten edicioacuten y borrado de un perfil de portal cautivo en la plataforma
Web
113
6451 Criterios de Aceptacioacuten
U0701 Verificar que un usuario puede crear editar y borrar un perfil de Portal Cautivo correctamente
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Network
3 El usuario puede Navegar a la pestantildea de Captive Portals
4 El usuario puede Crear un perfil de Portal Cautivo correctamente
5 El usuario puede Editar un perfil de Portal Cautivo correctamente
6 El usuario puede Eliminar un perfil de Portal Cautivo correctamente
6452 Diagramas de Flujo
Figura 114 Diagrama de Flujo de Caso de Prueba U0701
6453 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 115 Script de Prueba U0701
114
En cuanto a la implementacioacuten de dicho caso de prueba puede destacarse por ejemplo la implementacioacuten de
la Keyword ldquoEdit or delete Captive Portal Profilerdquo la cual permite editar o eliminar un perfil de Portal Cautivo
a partir de un conjunto de paraacutemetros de entrada
Figura 116 Keyword Edit or Delete Captive Portal Profile
115
646 General
Esta pestantildea muestra la vista general de la pestantildea ldquoNetworkrdquo En esta pestantildea se agrupa el conjunto de puntos
de acceso actualmente registrados en el Zone Manager con un resumen de su configuracioacuten de red actual el
estado en el que se encuentran y nuacutemero de clientes conectados Ademaacutes dicha vista proporciona un acceso
directo a la pestantildea ldquoAP Networkrdquo seleccionando uno o varios puntos de acceso de un mismo modelo En la
siguiente seccioacuten se explica la funcionalidad de dicha pestantildea
Figura 117 Pestantildea General
Para cada elemento se han automatizado un conjunto de pruebas formado por 9 casos de prueba de los cuales
detallaremos el caso de prueba identificado con la etiqueta U0522 Este caso de prueba se permite validar de
forma automaacutetica la conexioacuten de clientes a un punto de acceso con una SSID asignada de forma que el nuacutemero
de clientes conectados que se muestra en la plataforma Web sea correcto
6461 Criterios de Aceptacioacuten
U0522 Conectar clientes y verificar que el nuacutemero de clientes conectados es correcto
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Network
3 El usuario puede Navegar a la pestantildea General
4 El usuario tiene disponible un punto de acceso en el Zone Manager con una SSID asignada
5 El usuario conecta un cliente al punto de acceso por WiFi a la SSID asignada
6 El usuario verifica que el nuacutemero de clientes conectados incrementa en una unidad
116
6462 Diagramas de Flujo
Figura 118 Diagrama de Flujo de Caso de Prueba U0522
6463 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de prueba automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 119 Script de Prueba U0522
En cuanto a la implementacioacuten de dicho caso de prueba puede destacarse por ejemplo la implementacioacuten de
la Keyword ldquoCheck Number of Clients Increasesrdquo la cual permite comprobar que el nuacutemero de clientes conectados incrementa al conectar un cliente a un punto de acceso
Figura 120 Keyword Check Number of Clients Increases
117
647 AP Network
Esta pestantildea muestra la vista principal de la pestantildea ldquoAP Networkrdquo La funcionalidad que proporciona engloba
todos los posibles paraacutemetros de configuracioacuten para un punto de acceso que ha sido seleccionado previamente
desde la pestantildea General Cualquier configuracioacuten aplicada sobre esta vista seraacute enviada al punto de acceso
desde la plataforma Web permitiendo configurar los puntos de acceso de Galgus
Desde el punto de vista de la plataforma Web esta vista abarca un conjunto de funcionalidades consideradas
como maacutes complejas que se ofrecen en la plataforma Web por lo que es en esta vista donde puede encontrarse
una de las mayores aacutereas de riesgo de la plataforma Entre las funcionalidades que se ofrecen estaacuten la
configuracioacuten de las radios de un punto de acceso (Potencia Ancho de banda Canal etc) asignacioacuten de SSIDs
a las interfaces inalaacutembricas y configuracioacuten de reglas de control de traacutefico (TC Rules) asignacioacuten de puertos a
las diferentes subredes virtuales de aacuterea local (VLANS) o configuracioacuten de Portal Cautivo
Figura 121 Pestantildea AP Network
Para cada elemento se han automatizado un conjunto de pruebas formado por 28 casos de prueba los cuales la
mayoriacutea han requerido un amplio esfuerzo de implementacioacuten para conseguir su automatizacioacuten ya que son
pruebas cuya secuencia de acciones es larga ademaacutes de requerir en muchas ocasiones la verificacioacuten de la
configuracioacuten en los puntos de acceso viacutea ldquosshrdquo Para ello se ha hecho uso entre otras de la libreriacutea
ldquoSSHLibraryrdquo proporcionada por Robot Framework
Figura 122 Libreriacutea SSH para Robot Framework
118
Del conjunto de casos de prueba que validan la funcionalidad de dicha pestantildea se va a detallar el caso de prueba
identificado con la etiqueta U0511 Este caso de prueba permite validar de forma automaacutetica que se pueden
aplicar reglas de control de traacutefico ldquoTCsrdquo a una SSID asignada a las interfaces inalaacutembricas de un punto de
acceso desde la plataforma Web
Figura 123 Ventana de Configuracioacuten de TC Rules
6471 Criterios de Aceptacioacuten
U0511 Asignar ldquoTC Rulesrdquo a una SSID asociada a un Punto de Acceso correctamente
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Network
3 El usuario puede Navegar a la pestantildea General
4 El usuario tiene disponible un punto de acceso en el Zone Manager
5 El usuario puede seleccionar un punto de acceso
6 El usuario puede Navegar a la pestantildea AP Network para el punto de acceso seleccionado
7 El usuario puede asignar a las interfaces inalaacutembricas una SSID existente y crear ldquoTC Rulesrdquo sobre
esa SSID
8 El usuario puede aplicar la configuracioacuten
9 El punto de acceso aplica su configuracioacuten correctamente
10 El punto de acceso pasa al estado ldquoOnlinerdquo en la plataforma Web y su configuracioacuten estaacute alineada
119
6472 Diagramas de Flujo
Figura 124 Diagrama de Flujo de Caso de Prueba U0511
120
6473 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 125 Script de Prueba U0511
En cuanto a la implementacioacuten de dicho caso de prueba puede destacarse por ejemplo la implementacioacuten de
la Keyword ldquoWait Timerrdquo la cual permite verificar que no se produce ninguacuten error al aplicar una configuracioacuten
determinada desde la plataforma Web durante un tiempo determinado
Figura 126 Keyword Wait Timer
Destacar tambieacuten la implementacioacuten de la Keyword ldquoCheck On CLIrdquo la cual permite contrastar que la
configuracioacuten aplicada desde la plataforma sobre un punto de acceso es la esperada En este caso se comprueba
que las ldquoTC Rulesrdquo han sido correctamente aplicadas para una SSID determinada en un punto de acceso de
forma remota mediante el uso de la libreriacutea ldquoSSHrdquo para Robot Framework
Figura 127 Keyword Check On CLI
121
122
7 LINEAS DE MEJORA Y CONCLUSIONES
n este uacuteltimo capiacutetulo se analizaraacuten resultados y conclusiones obtenidas sobre el uso de pruebas
automatizadas para la verificacioacuten y validacioacuten de una plataforma Web como la de Galgus Se
detallaraacuten algunas ventajas e inconvenientes encontrados y se plantearaacuten algunas liacuteneas de mejora
futuras sobre el proyecto desarrollado Con estas mejoras se busca como objetivo enriquecer el proceso de
automatizacioacuten de pruebas ademaacutes de hacerlo maacutes efectivo y metoacutedico en todos sus aspectos ya que siempre
hay algo que se puede mejorar para conseguir una herramienta maacutes completa y uacutetil
Se detallaraacuten tambieacuten aspectos de aprendizaje opiniones experiencias y en definitiva todas las conclusiones
sacadas sobre este proyecto incluyendo tambieacuten las dificultades encontradas para el desarrollo del mismo
71 Liacuteneas de Mejora Futuras
El estudio y puesta en marcha de este Proyecto de automatizacioacuten de pruebas de Software ha hecho uso de una
amplia cantidad de herramientas ofrecido por Selenium y Robot Framework ademaacutes de otras herramientas que
han permitido enriquecer el mismo con mayores funcionalidades ofrecidas al equipo de Proyecto Si bien se ha
logrado conseguir un paquete de pruebas con una capacidad de detectar defectos en un producto Web existen
diversas ampliaciones de dicho Proyecto que podriacutean aumentar de manera considerable el desempentildeo de las
herramientas de automatizacioacuten a lo largo del ciclo de vida del proyecto
A continuacioacuten se muestran algunas de las maacutes importantes
bull Uso de Integracioacuten Continua Robot Framework es faacutecilmente integrable principalmente con Jenkins
aunque tambieacuten ofrece la posibilidad de integrarlo con Gitlab CICD Esto permitiriacutea programar la
ejecucioacuten de pruebas automaacuteticamente para diferentes versiones del proyecto Galgus CHT Cloud
Manager o en diferentes fases del mismo Con esta caracteriacutestica se detectariacutean con mayor facilidad los
problemas relacionados con la configuracioacuten del entorno de trabajo y se podriacutea notificar por email a
los responsables de equipo ante los eventuales incidentes encontrados De este modo no seriacutea necesario
estar supervisando el proceso de ejecucioacuten para estar al tanto de un fallo en el sistema En este aspecto
se ha trabajado para conseguir estos objetivos con la creacioacuten de un Docker de Robot Framework que
permita la ejecucioacuten de las pruebas en el mismo para poder usarla en el entorno de integracioacuten continua
correspondiente Tambieacuten se ha implementado un primer un script que permita la ejecucioacuten de paquetes
de pruebas en dicho entorno
bull Selenium Grid El caso praacutectico descrito tiene un inconveniente y es que solo hace uso de Chrome
Suele ser frecuente que ciertos defectos en una aplicacioacuten Web solo aparezcan en determinados
navegadores Con herramientas como Selenium Grid permitiriacutean la ejecucioacuten en paralelo de las pruebas
en maacutequinas con diferentes sistemas operativos y navegadores Asiacute se podriacutea evaluar de manera
independiente la compatibilidad del producto en entornos multiplataforma Ademaacutes esta herramienta
es totalmente compatible con Jenkins o Gitlab CICD con las ventajas que esto supone
bull Headless browser Esto hace referencia al uso de navegadores sin interfaz graacutefica de usuario La mayor
parte del tiempo durante una ejecucioacuten es destinada a esperar a que el navegador renderice el contenido
Si se elimina este factor de la foacutermula y se accede directamente al DOM de la Web se consigue una
reduccioacuten en el tiempo de ejecucioacuten de las pruebas Durante el desarrollo de este proyecto se ha
trabajado en este aspecto ofrecieacutendose la posibilidad de ejecutar las pruebas en dos entornos diferentes
una primera de depuracioacuten de pruebas que realiza el renderizado del navegador y otra opcioacuten que
E
La tecnologiacutea por siacute sola no basta Tambieacuten tenemos que poner el corazoacuten
Jane Goodall
123
permite la ejecucioacuten de pruebas sin renderizado del navegador (Modo Headless)
bull Buenas praacutecticas en la localizacioacuten de elementos en el DOM de la Web La aplicacioacuten de este tipo
de buenas praacutecticas permitiriacutean una mejor y maacutes eficiente localizacioacuten de los elementos en el DOM
reduciendo la posibilidad de que las pruebas generen falsos errores Esto es lo que ha causado la mayor
parte de los problemas de implementacioacuten y ejecucioacuten de las pruebas automaacuteticas Actualmente la
herramienta de automatizacioacuten de pruebas se encuentra en un proceso de mejora continua en el que se
estaacute abordando una refactorizacioacuten para la aplicacioacuten de estas buenas praacutecticas Para ello se estaacuten
haciendo uso de selectores avanzados basados en rutas (Xpaths) relativas en el DOM de la Web las
cuales realizan la mayoriacutea de las buacutesquedas por contenido y no por ruta absoluta como se veniacutea
haciendo hasta ahora
bull Aplicacioacuten de Model Based Testing (MBT) Como estudio del arte se ha presentado una teacutecnica que
permite dar un paso maacutes en la automatizacioacuten de pruebas Como se ha detallado en el proyecto esta
teacutecnica permite ascender en el nivel de abstraccioacuten de las pruebas basando las mismas en el disentildeo y
modelado de la aplicacioacuten Dicha teacutecnica se encuentra principalmente en proceso de investigacioacuten lo
cual hace difiacutecil aplicarla aunque seriacutea de gran intereacutes conseguir su implantacioacuten
72 Conclusiones Finales
En el desarrollo del presente Proyecto se ha analizado una pequentildea extensioacuten del inmenso mundo de la gestioacuten
de calidad Esta ha ido tomando fuerza con el paso de los antildeos en el mercado actual introducieacutendose en todos
los aacutembitos incluido en el software La gestioacuten de calidad se ha profesionalizado de tal forma que el papel del
ingeniero de calidad en los proyectos de software es imprescindible en cualquier empresa que quiera hacerse un
hueco en el mercado como garantiacutea de calidad
La elevada exigencia del mercado del software provocada por la gran demanda de clientes y usuarios finales
para recibir un producto en el menor tiempo posible hace que en muchos casos las empresas centren su esfuerzo
en sacar un producto lo antes posible reduciendo los esfuerzos destinados a los procesos de calidad de dicho
producto software Originalmente las pruebas de software realizadas sobre un producto se realizaban de forma
manual por un ingeniero de calidad pero con el avance de las tecnologiacuteas la automatizacioacuten de las mismas
supone un elevado esfuerzo inicial pero una reduccioacuten de los mismos a medio plazo
En este proyecto se ha desarrollado una herramienta que permite la automatizacioacuten de pruebas funcionales sobre
una plataforma Web concretamente pruebas de aceptacioacuten sobre Galgus CHT Cloud Manager Las pruebas de
automatizacioacuten elaboradas reflejan que existen tecnologiacuteas muy asequibles en teacuterminos de coste compatibilidad
y facilidad de uso para iniciarse en el mundo de las pruebas funcionales de sistemas Algo muy presente en el
mundo laboral actual es la creciente demanda de expertos en automatizacioacuten en todas las principales
plataformas Web Moacutevil y Escritorio Muchos de estos profesionales vienen del mundo del testing manual por
lo que conociendo ya la nomenclatura y el funcionamiento de los procesos de calidad solo necesitan dar el paso
hacia el uso de este tipo de herramientas Sea con Selenium o con cualquier otra herramienta los conceptos
teoacutericos presentados en este proyecto son igualmente vaacutelidos
Por otra parte debe destacarse la dificultad encontrada a la hora de establecer unos criterios de aceptacioacuten de las
funcionalidades de la plataforma Web bajo pruebas Esto se debe al desarrollo de una herramienta de
automatizacioacuten de pruebas que se ha iniciado en una fase avanzada del desarrollo del proyecto con lo cual en
muchas ocasiones surgiacutean dudas sobre el disentildeo del proyecto Adicionalmente la propia estructura y tecnologiacuteas
usadas en la Web dificultaron al inicio la localizacioacuten de elementos A esta causa de une tambieacuten la ausencia de
identificadores uacutenicos en los elementos que componen la misma Esto se tradujo en el uso de selectores basados
en la ruta del elemento pudiendo acarrear la aparicioacuten de posibles falsos errores debidos a cambios en el coacutedigo
fuente de la plataforma Web La solucioacuten adoptada para tal problema no fue maacutes que analizar meticulosamente
aquellas ejecuciones fallidas para descartar errores reales y en caso de que sean debidas a los selectores aplicar
la debida actualizacioacuten de los mismos
En este uacuteltimo aspecto cabe destacar que el proyecto de automatizacioacuten de pruebas se encuentra actualmente
en una fase de mejora continua en la que se estaacuten adoptando teacutecnicas basadas en el uso de selectores avanzados
basados en rutas relativas y nombres que permitan reducir el impacto del problema presentado en este punto
124
A modo de resumen se plantean algunas ventajas en el uso de SeleniumRobot Framework para la
automatizacioacuten de pruebas
Facilidad de configuracioacuten y uso Su instalacioacuten requiere un esfuerzo miacutenimo y el poder de
abstraccioacuten ofrecido por Robot Framework hace posible la lectura y entendimiento de los paquetes de
pruebas y reportes a todos los miembros del equipo
Cantidad de documentacioacuten disponible La comunidad respalda ambos proyectos y es por ello que
encontramos soluciones de todo tipo adaptadas a las necesidades de cada uno
Soporte para la mayoriacutea de navegadores con el mismo script Ejecutar el script de pruebas
desarrollado para su automatizacioacuten en otro navegador requiere simplemente la instalacioacuten del
controlador deseado y usar un determinado paraacutemetro para indicar el uso de dicho controlador en la
llamada de la Keyword encargada de la apertura del navegador
De la misma forma se pueden destacar algunas desventajas
Selenium soacutelo es compatible con productos Web Cualquier software moacutevil o de escritorio requiere
del uso de otros frameworks o herramientas lo cual puede ser un punto negativo para empresas que
tengan productos multiplataforma Sin embargo Robot Framework si proporciona soporte
multiplataforma con la integracioacuten de otras herramientas o framework para su desarrollo
Tecnologiacuteas no optimizadas para pruebas de rendimiento En este punto cabe destacar el esfuerzo
de la comunidad para desarrollar herramientas que permitan la automatizacioacuten de este tipo de pruebas
con Robot Framework como por ejemplo ldquorfswarmrdquo
Compatibilidad de versiones de paquetes de Software Es frecuente usar determinadas
combinaciones de versiones de paquetes para lograr un framework estable y robusto Esto a veces puede
convertirse en una tarea tediosa donde cuestan encajar piezas Por suerte es algo que se estaacute teniendo
en cuenta con las uacuteltimas versiones de Selenium
Puede concluirse que durante el desarrollo de este proyecto se ha conseguido la creacioacuten de una herramienta
sencilla de usar y entender para la automatizacioacuten de pruebas funcionales sobre una plataforma Web ademaacutes
de preparar dicha herramienta para integrarla en el proceso de integracioacuten continua implantado para dicha
aplicacioacuten Web con Gitlab mediante Docker Ademaacutes se ha realizar un estudio del arte de una teacutecnica conocida
bajo el nombre de Model Based Testing (MBT) que permitiriacutea mejorar el proceso de automatizacioacuten y la
herramienta desarrollada para tal fin
Con todo ello he aprendido multitud de conceptos tecnologiacuteas y herramienta que hasta ahora desconociacutea cuaacutel
era su finalidad o funcionamiento como por ejemplo Robot Framework Para ello he necesitado gran cantidad
de formacioacuten previa antes de comenzar a ponerlo en praacutectica para el desarrollo de la herramienta de
automatizacioacuten
Son muchos los errores cometidos hasta conseguir los objetivos y metas propuestas los cuales creo que son los
sucesos maacutes importantes pues de ellos se aprende y son los que nos hacen avanzar cuando los resolvemos
Finalmente destacar que este proyecto me ha dado la oportunidad de abrir mi conocimiento en un campo de las
tecnologiacuteas de la informacioacuten el cual resulta de intereacutes Dar las Gracias a mis tutores Pablo Aguilera Bonet y
Daniel Gutieacuterrez Reina ademaacutes de mi responsable en Galgus Joseacute Antonio Delgado Alfonso por brindarme
esta oportunidad ademaacutes de ayudarme y asesorarme estando siempre disponible y con dedicacioacuten hacia este
proyecto para que haya podido llevarse a cabo
125
126
REFERENCIAS
[1] M Utting Bruno Legeard Practical Model-based Testing sl Elsevier 2007
[2] Ibrahim K El-Far Enjoying the perks of model-based testing In Proceedings of the Software Testing
Analysis and Review Conference
[3] A C Dias Neto Rajesh Subramanyan Marlon Vieirab Characterization of Model-based Software
[4] Model-based Testing Next Generation Functional Software Testing Legeard Bruno Dagstuhl Seminar
Proceedings 10111 Vol httpdropsdagstuhldeopusvolltexte20102620
[5] Perspectives of Model-Based Testing Ed Brinksma Wolfgang Grieskamp and Jan Tretmans IBFI
Schloss Dagstuhl Germany sn 2005 Dagstuhl Seminar Proceedings
[6] Definicioacuten de Calidad httpsdleraeesid=6nVpk8P|6nXVL1Z
[7] Modelos de calidad del software httpswwwresearchgatenetpublication316674475
[8] Calidad del Software ldquoEl camino al exitordquo LI Alma Delia Chaacutevez Rojas
[9] IEEE Software Engineering Book of Knowledge IEEE sl IEEE 2004
[10] Principios de pruebas software httpsmediumcomatejedaccsprincipios-del-testing-722323e16e76
[11] httpwwwsstqbesw3docsGLOSARIO_V00110pdf
[12] httpsepdfpubsoftware-testing-an-istqb-iseb-foundation-guidehtml
[14] IEEE standard glossary of software engineering terminology F Jay RMayer 1990 paacuteg IEEE Std 610
[15] Openwrt httpsopenwrtorgsupported_devices
[16] RabbitMQ httpswwwrabbitmqcom
[17] Zero Touch Provisioning httpssearchdatacentertechtargetcomesdefinicionAprovisionamiento-de-
cero-toque-ZTP-o-zero-touch-provisioning
[18] Robot Framework User Guide
httpsrobotframeworkorgrobotframeworklatestRobotFrameworkUserGuidehtml
[19] Gitlab httpsdocsgitlabcom
[20] httpswwwfederico-toledocomcuando-automatizar-una-prueba
127
128
ANEXO A PREPARACIOacuteN DEL ENTORNO DE
TRABAJO Y EJECUCIOacuteN DE PRUEBAS
A1 Preparacioacuten del entorno de trabajo
Para el desarrollo de las preubas automaacuteticas se ha hecho uso del sistema operative Linux con la distribucioacuten
Ubuntu El motivo de su uso es el amplio abanico de herramientas de coacutedigo libre que existen para esta
distribucioacuten asiacute como la enorme contribucioacuten que hace la comunidad de usuarios para mejorarla Sobre este
sistema operativo se ha hecho uso de un conjunto de herramientas para el montaje de un entorno de pruebas
automatizado basado en Python A continuacioacuten se detallaraacuten dichas herramientas
A11 Pip
Pip es un sistema de gestioacuten de paquetes que se utiliza para la instalacioacuten de los paquetes software
implementados en Python que se usaraacuten posteriormente La instalacioacuten de un paquete se realiza mediante la
ejecucioacuten del siguiente comando
A12 Virtualenv Entorno Virtual
Dado que cada proyecto basado en Python puede requerir la instalacioacuten de diferentes conjuntos de paquetes es
comuacuten usar la creacioacuten de entornos virtuales que nos permitan administrar cada proyecto de manera
independiente pudiendo tener otros proyectos haciendo uso de los mismos paquetes con otras versiones La
instalacioacuten se realiza mediante la herramienta ldquoPiprdquo a traveacutes del siguiente comando
Una vez instalado se puede crear un entorno virtual asociado a un proyecto de la siguiente forma
En este punto se creariacutea un entorno virtual para el proyecto deseado Ahora solo quedariacutea activarlo o iniciarlo
pip install nombre-del-paquete
pip install virtualenv
cd carpeta-del-proyecto
virtualenv ndashp usrbinpython27 mi-proyecto
source mi-proyectobinactivate
129
A13 Selenium y Chromedriver
La instalacioacuten de Selenium se realiza de la misma forma que el resto de paquetes con la herramienta ldquoPiprdquo
Por otra parte el controlador para el navegador Chrome Chromedriver puede ser descargado desde el
repositorio oficial httpschromedriverchromiumorg Ademaacutes Chromedriver debe ser accessible para
Selenium de cara a configurar el PATH
A14 Robot Framework y SeleniumLibrary
A continuacioacuten se realizariacutea la instalacioacuten de Robot Framework
Posteriormente se realizariacutea la instalacioacuten del paquete ldquoSelenium2Libraryrdquo el cual contiene la implementacioacuten
en python de las libreriacuteas necesarias para utilizar Robot Framework en Python
Llegados a este punto listando todos los paquetes instalados se deberiacutea tener algo similar a la siguiente figura
Con esta configuracioacuten del entorno este estariacutea preparado para elaborar los casos de prueba automatizados con
Robot Framework y Selenium
pip install selenium
export PATH=$PATHabsolute_path_of_chromedriver_file
pip install robotframework
pip install robotframework-selenium2library
130
A15 Otras dependencias
Para el desarrollo de pruebas que requieren otro tipo de herramientas como la transferencia de ficheros con el
servicio ldquoSCPrdquo o la conexioacuten remota a traveacutes del servicio ldquoSSHrdquo se require la instalacioacuten de los siguientes
paquetes
Ademaacutes para la realizacioacuten de pruebas avanzadas en Python para la gestioacuten del Mapa de la platform Web CHT
Cloud Manager se ha hecho uso de la librariacutea ldquohtml-testRunnerrdquo para ofrecer un reporte de la ejecucioacuten de
pruebas muy similar al ofrecido por Robot Framework
A2 Ejecucioacuten de Pruebas
Tras la implementacioacuten de las pruebas siguiendo el procedimiento indicado en la seccioacuten de Experimentos
ejecutar un script de pruebas se realiza mediante el uso del siguiente comando
Mediante el uso de la variable ldquoENVIROMENTrdquo puede seleccionarse el entorno en el que se desea ejecutar las
pruebas Con el entorno de ldquodebugrdquo las pruebas se ejecutariacutean de forma graacutefica mientras que el el entorno de
ldquodockerrdquo permite la ejecucioacuten de pruebas sin interfaz graacutefica Este uacuteltimo entorno seriacutea usado para la ejecucioacuten
de pruebas con el docker de Robot Framework que se ha implementado el cual se detallaraacute maacutes adelante
Por otro lado existen otras opciones para el comando anterio como por ejemplo
Las opciones ldquo-irdquo y ldquo-erdquo permiten ejecutar o excluir un caso de preuba en la ejecucioacuten de una Suite de pruebas
Por otro lado el uacuteltimo comando permite lanzar la ejcucioacuten de una Suite de pruebas y ejecutar soacutelo aquellos
casos de prueba que hayan fallado en la ejecucioacuten anterior
pip install robotframework-sshlibrary
pip install robotframework-scplibrary
pip install html-testRunner
robot --variable ENVIROMENTdebug_or_docker suite_filerobot
robot --variable ENVIROMENTdebug_or_docker ndashi U0000 suite_filerobot
robot --variable ENVIROMENTdebug_or_docker ndashe U0000 suite_filerobot
robot --rerunfailed outrerunfailedxml --output out2xml suite_filerobot
131
A continuacioacuten se muestra un ejemplo de ejecucioacuten de pruebas con Robot Framwork
132
A3 Script de Prueba U007 (MAP)
from selenium import webdriver
from seleniumwebdrivercommonby import By
from seleniumwebdriversupportui import WebDriverWait
from seleniumwebdriversupport import expected_conditions as EC
from seleniumwebdrivercommondesired_capabilities import DesiredCapabilities
from seleniumwebdrivercommonaction_chains import ActionChains
from seleniumcommonexceptions import TimeoutException
import math json multiprocessing time re
import sys
import unittest
import HtmlTestRunner
U0007 Double-click on Zone Manager and look if the Backend tab opens
class DClickZM(unittestTestCase)
driver = 0
canvas = 0
waitTime = 20
username = franciscodiaz
password = ahipeo8829g
classmethodg
def setUp(cls)
Enviroment Management
chrome_options = webdriverChromeOptions()
if sysargv[2] == docker
chrome_optionsadd_argument(--headless)
chrome_optionsadd_argument(--disable-extensions)
chrome_optionsadd_argument(--disable-gpu)
chrome_optionsadd_argument(--no-sandbox)
enable browser logging
d = DesiredCapabilitiesCHROME
d[loggingPrefs] = browser DEBUG
clsdriver = webdriverChrome(chrome_options=chrome_options desired_capabilities=d)
clsdrivermaximize_window()
clsdriverset_window_size(1920 1080)
load the desired webpage
clsdriverget(httpdevcloudgalgusnet)
def test_double_click_ZM(self)
loggin in the page
userNameBox = WebDriverWait(selfdriver 1)until(
ECpresence_of_element_located((ByXPATH [id=username])))
userNameBoxsend_keys(selfusername)
passwordBox = WebDriverWait(selfdriver selfwaitTime)until(
ECpresence_of_element_located((ByXPATH [id=password])))
passwordBoxsend_keys(selfpassword)
133
loginButton = WebDriverWait(selfdriver selfwaitTime)until(
ECpresence_of_element_located((ByXPATH
[id=myModalLabel]divdivformdiv[3]input)))
loginButtonclick() Tab General appears
selfcanvas = WebDriverWait(selfdriver selfwaitTime)
until(ECpresence_of_element_located((ByXPATH
htmlbodyappdivmaindivregister-
managersdivtabsetdivtab[1]aol-mapdivdivcanvas)))
timesleep(15)
action = ActionChains(selfdriver)
Manage Process
manager = multiprocessingManager()
return_dict = managerdict()
We create a Process
p_get_pixels_zm = multiprocessingProcess(target=selfGet_Pixels_ZM args=(return_dict selfdriver))
We create another Process
p_double_click_on_zm = multiprocessingProcess(target=selfDouble_Click_On_ZM args=(return_dict selfcanvas
action selfdriver))
We start the process and we block for 5 seconds
p_get_pixels_zmstart()
p_get_pixels_zmjoin(timeout=10)
p_double_click_on_zmstart()
p_double_click_on_zmjoin(timeout=10)
We terminate the process
p_get_pixels_zmterminate()
p_double_click_on_zmterminate()
try
Tab General appears
WebDriverWait(selfdriver 20)until(ECpresence_of_element_located(
(ByXPATH [id=app-sections]networktabsetulli[1]a)))
except TimeoutException
raise Exception(Cant Login in Zone Manager)
classmethod
def tearDown(cls)
clsdriverquit()
staticmethod
def Get_Pixels_ZM(return_dict driver)
return_dict[0] = 0
return_dict[1] = 0
regex = r(lt=c[-gt]cs)[wW]+(=)
while True
for entry in driverget_log(browser)
message = entry[message]
matches = refinditer(regex message reMULTILINE)
134
for matchNum match in enumerate(matches start=1)
try
p = matchgroup()replace( )
my_json = jsonloads(p)
if my_json[ZM] == Hotel MampM
return_dict[0] = my_json[top]
return_dict[1] = my_json[left]
break
except
pass
if return_dict[0] = 0 and return_dict[1] = 0
break
staticmethod
def Double_Click_On_ZM(return_dict canvasaction driver)
width = int(mathceil(float(return_dict[0])))
height = int(mathceil(float(return_dict[1])))
actionmove_to_element_with_offset(canvas width height)
actiondouble_click()
actionperform()
actiondouble_click()
actionperform()
driversave_screenshot(screenshot1png)
timesleep(5)
if __name__ == __main__
unittestmain(testRunner=HtmlTestRunnerHTMLTestRunner())
135
136
ANEXO B DOCKER DE ROBOT FRAMEWORK Y
ENTORNO DE UAT DOCKERIZADO
B1 Docker de Robot Framework
Para el entorno de UAT que se va a desarrollar se ha hecho uso de diferentes contenedores que han sido creados
por el equipo de desarrollo donde cada contenedor aloja un microservicio diferente de la plataforma
Para crear cada contenedor se ha hecho uso de Docker Esta herramienta permite crear contenedores ligeros y
portables para diferentes servicios que puedan ejecutarse en cualquier maacutequina con Docker instalado
independientemente del sistema operativo de la maacutequina que lo ejecute facilitando asi los despliegues
Mediante un fichero llamado ldquoDockerfilerdquo se definen los siguientes contenedores de servicios entre los cuales
se destacaraacute el fichero que define la creacioacuten del docker de Robot Framework el cual ha sido desarrollado por
el autor de este proyecto
Este contenedor ha sido creado sobre una imagen de Docker con el inteacuterprete de Python instalado Partiendo de
137
esta imagen se realiza la instalacioacuten de Robot Framework y las diferentes libreriacuteas y herramientas que se usaraacuten
en el proyecto para poder lanzar los Tests End-to-End
Ademaacutes se realiza la instalacioacuten de Google Chrome y Mozilla Firefox y la descarga de Chromedriver y
Geckodriver para poder lanzar los tests con dichos navegadores en modo headless Para el lanzamiento de los
test en modo headless se haraacute uso de la variable de entorno ldquoENVIROMENTrdquo definida en el anexo anterior
Finalmente se antildeade el proyecto de pruebas desarrollado para tener disponible las pruebas aumaacuteticas en el
contenedor
B2 Entorno de UAT Dockerizado
Para automatizar el despliegue de la plataforma Galgus CHT Cloud Manager con Docker se ha hecho uso de la
herramienta ldquodocker-composerdquo Esta herramienta permite simplificar el uso de Docker generando scripts que
facilitan el disentildeo y la construccion de servicios Con Docker Compose se pueden crear diferentes contenedores
y al mismo tiempo en cada contenedor diferentes servicios En la siguientefigura se muestra el fichero que
define el entorno de UAT con docker-compose
138
139
140
ANEXO C REVISIOacuteN DE REPORTES Y LOGS
C1 Reporte de Logs ofrecido por Robot Framework
Selenium no teniacutea la capacidad nativa de generar informes Este es uno de los motivos por el que se decidioacute
utilizar Robot Framework
Robot Framework genera tres archivos tras la ejecucioacuten de los scripts de pruebas A partir de la informacioacuten
contenida en el fichero ldquooutputxmlrdquo se rellenan las plantillas ldquohtmlrdquo del ldquologrdquo y del reporte El reporte permite
aplicar filtros a los resultados mientras que el ldquologrdquo contiene todos los detalles de la ejecucioacuten
A continuacioacuten se adjuntan las capturas de logs generados por los diferentes paquetes de pruebas desarrollados
C2 Cloud Tab
C21 Administration
141
142
C22 List
143
C23 Manufacturers
144
C24 MAP
145
C3 Configuration Tab
C31 BackupRestore
146
C32 CHT Zones
147
C33 Firmware
148
C34 Groups
149
150
C4 Network Tab
C41 General
151
C42 SSID
C43 CHT
152
C44 VLAN
153
C45 Radius
154
C46 Captive Portal
155
C47 AP Network
156
Como se ha visto reflejado en el conjunto de logs el tiempo total invertido en la ejecucioacuten ha sido de 1 hora 20
minutos y 22 segundos Dichas pruebas realizadas por una persona de forma manual hubiesen requerido como
miacutenimo el doble de tiempo Ya ni mencionar si se aplicase concurrencia en la ejecucioacuten de pruebas
157
ANEXO D DIAGRAMA DE GANTT
8
9
Agradecimientos
10
11
Resumen
La revolucioacuten tecnoloacutegica que vivimos hoy diacutea enfocada principalmente en el mundo de Internet y aplicaciones
Web estaacute permitiendo que todas las herramientas que tenemos a nuestro alrededor se encuentren en un proceso
de tremenda evolucioacuten y cambio continuo
En este proyecto se ha realizado un estudio del arte sobre una teacutecnica que permite mejorar el proceso de
automatizacioacuten de pruebas sobre una aplicacioacuten Web basaacutendose en el modelado de la aplicacioacuten para
proporcionar una abstraccioacuten en la implementacioacuten de las pruebas Tambiacuteeacuten se ha realizado una revisioacuten de los
diferentes modelos de calidad normativas y tipos de prueba de Software Finalmente se ha desarrollado una
herramienta de test comprendida por un conjunto de pruebas de aceptacioacuten automaacuteticas que permiten la
verificacioacuten y validacioacuten de la funcionalidad de la plataforma Web Galgus CHT Cloud Manager
Galgus CHT Cloud Manager es la plataforma Web distribuida ofrecida por Galgus para la gestioacuten de redes
compuestas por puntos de acceso Wifi Estas redes se encuentran instaladas en los diferentes clientes que hacen
uso de los servicios que ofrece Galgus los cuales se basan en la optimizacioacuten del rendimiento y las prestaciones
de las redes Wifi en entornos de alta densidad de usuarios Esto se consigue mediante un software embebido
patentado por Galgus conocido bajo el nombre de Cognitive Hostpot Technology (CHT) el cual es instalado
en los puntos de acceso Dicho software implementa un conjunto de algoritmos y caracteriacutescas colaborativas
para conseguir los objetivos planteados en redes Wifi
Como resultado del trabjo podemos proporcionar a los ingenieros de pruebas una herramienta con la que poder
automatizar el testeo de una plataforma Web De esta forma se consigue agilizar el proceso de pruebas y reducir
costes y esfuerzos en tareas repetitivas que anteriormente se haciacutean de forma manual
12
13
Abstract
The technological revolution we are living today focused mainly on the Internet world and therewith the Web
applications is allowing all the tools we have around us to be in a process of continuous evolution and change
In this project we have made a study of the art on a technique that allows to improve the process of automation
of testing on a Web application based on the modelling of the application to provide an abstraction in the
implementation of testing A review of the different quality models standards and types of software testing has
also been carried out Finally a tool comprised of a set of automated acceptance tests has been developed to
allow verification and validation of the functionality of the Galgus CHT Cloud Manager Web platform
Galgus CHT Cloud Manager is the distributed web platform offered by Galgus for the management of
networks composed by Wifi access points These networks are installed in the different clients that make
use of the services offered by Galgus which are based on the optimization of the performance and features
of Wifi networks in high user density environments This is achieved through an embedded software
patented by Galgus known as Cognitive Hostpot Technology (CHT) which is installed in the access points
This software implements a set of algorithms and collaborative features to achieve the objectives set in Wifi
networks
This allows us to provide quality assurance engineers with a tool to automate the testing of a Web platform In
this way the testing process is streamlined and costs and efforts are reduced in repetitive tasks that previously
used to be done manually
14
15
Iacutendice
Agradecimientos 9
Resumen 11
Abstract 13
Iacutendice 15
Iacutendice de Figuras 19
Glosario 24
1 Introduccioacuten 27 11 Motivacioacuten 28 12 Alcance y Objetivos 29 13 Estructura de la memoria 30
2 Estudio del Arte y Revisioacuten 32 21 Model Based Testing (MBT) 32
211 Introduccioacuten 32 212 iquestQueacute es Model Based Testing 33 213 iquestCoacutemo funciona Model Based Testing 33 214 Consideraciones para la aplicacioacuten de Model Based Testing (MBT) 36 215 Beneficios de Model Based Testing (MBT) 37 216 Problemas y Limitaciones de Model Based Testing (MBT) 38 217 Cuando elegir Model Based Testing (MBT) 38
22 Gestioacuten de Calidad Software 39 221 Introduccioacuten 39 222 Concepto de Calidad 39 223 Modelos de Calidad de Software 40 224 Principales Ventajas e Inconvenientes de Modelos de Calidad anteriores 44 225 Conclusiones 44
3 Marco Teoacuterico Pruebas de Software 46 31 Testing y Pruebas de Software 46 32 Principios de las Pruebas de Software 47 33 Proceso de Pruebas de Software Anaacutelisis disentildeo e implementacioacuten 48
331 Terminologiacutea 48 332 Proceso de Pruebas de Software 49
34 Clasificacioacuten de Pruebas de Software 51 341 Pruebas Funcionales 51 342 Pruebas No Funcionales 52 343 Pruebas Estructurales 54 344 Pruebas debidas a Cambios 54
35 Niveles de Prueba 54 351 Pruebas a Nivel de Componente 55 352 Pruebas a Nivel de Integracioacuten 55 353 Pruebas a Nivel de Aceptacioacuten 55
16
36 Dificultades de pruebas en aplicaciones Web e impacto 56
4 Sistema Galgus CHT Cloud Manager 58 41 Arquitectura y Descripcioacuten del Sistema 58
411 Puntos de Acceso (OpenWRT + CHT) 60 412 Broacuteker de Eventos AMQP (RabbitMQ) 61 413 Frontend 62 414 Zone Manager 62 415 MoMap 63 416 Servidor de Licencias 64
42 Alcance y Objetivos de las pruebas sobre el sistema planteado 65 43 Arquitectura de la Solucioacuten Entorno de UAT para el proceso de pruebas (User Acceptance Test) 67
5 Tecnologiacuteas y Herramientas Usadas 69 51 Selenium 69 52 Selenium WebDriver 70
521 Elementos del Navegador 70 53 Robot Framework (RF) 72
531 Estilo de representacioacuten Given-When-Then 72 532 Reportes 75 533 Libreriacuteas 76 534 Documentacioacuten 77
54 Pycharm (IDE) 78 55 GitGitlab 78
551 Git 78 552 Gitlab 78
56 Redmine 78 561 Uso en el Proyecto Galgus CHT Cloud Manager (Metodologiacutea Scrum) 79
6 Experimentos 82 61 Estructura del Proyecto 83 62 Vista de Gestioacuten Principal (Cloud Tab) 87
621 Administration 87 622 List 89 623 Manufacturer 90 624 MAP 92
63 Vista de Configuracioacuten (Configuration Tab) 95 631 Groups 95 632 CHT Zones 98 633 BackupRestore 100 634 Firmware 101
64 Vista de Red (Network Tab) 104 641 VLANS amp Bridges 104 642 SSIDs 106 643 CHT 108 644 Radius 110 645 Captive Portal 112 646 General 115 647 AP Network 117
7 Lineas de Mejora y Conclusiones 122 71 Liacuteneas de Mejora Futuras 122 72 Conclusiones Finales 123
Referencias 126
17
Anexo A Preparacioacuten del Entorno de Trabajo y Ejecucioacuten de Pruebas 128 A1 Preparacioacuten del entorno de trabajo 128
A11 Pip 128 A12 Virtualenv Entorno Virtual 128 A13 Selenium y Chromedriver 129 A14 Robot Framework y SeleniumLibrary 129 A15 Otras dependencias 130
A2 Ejecucioacuten de Pruebas 130 A3 Script de Prueba U007 (MAP) 132
Anexo B Docker de Robot Framework y Entorno de UAT Dockerizado 136 B1 Docker de Robot Framework 136 B2 Entorno de UAT Dockerizado 137
Anexo C Revisioacuten de Reportes y Logs 140 C1 Reporte de Logs ofrecido por Robot Framework 140 C2 Cloud Tab 140
C21 Administration 140 C22 List 142 C23 Manufacturers 143 C24 MAP 144
C3 Configuration Tab 145 C31 BackupRestore 145 C32 CHT Zones 146 C33 Firmware 147 C34 Groups 148
C4 Network Tab 150 C41 General 150 C42 SSID 151 C43 CHT 151 C44 VLAN 152 C45 Radius 153 C46 Captive Portal 154 C47 AP Network 155
Anexo D Diagrama de Gantt 157
18
19
IacuteNDICE DE FIGURAS
Figura 1 Fuente de datos Morgan Stanley 27
Figura 2 Manual Testing vs Automated Testing [20] 28
Figura 3 Fase de Pruebas y Validacioacuten 32
Figura 4 Esquema baacutesico de Model Based Testing 33
Figura 5 Proceso detallado de Model Based Testing (MBT) 34
Figura 6 Construccioacuten del Modelo 34
Figura 7 Concepto de Calidad 39
Figura 8 Liacutenea de tiempo de modelos a nivel de proceso 40
Figura 9 Logo de ITIL 40
Figura 10 ISOIEC 20000 41
Figura 11 Logo de WebQEM 41
Figura 12 Liacutenea de tiempo de modelos a nivel de producto 42
Figura 13 Esquema de ISO 9126 42
Figura 14 Esquema de ISOIEC 25000 43
Figura 15 Principios de las Pruebas de Software 47
Figura 16 Terminologiacutea para el proceso de pruebas 48
Figura 17 Proceso de Pruebas de Software 49
Figura 18 Clasificacioacuten de Pruebas de Software 51
Figura 19 Pruebas de Caja Negra 51
Figura 20 Pruebas de Rendimiento 52
Figura 21 Pruebas de Carga 52
Figura 22 Pruebas de Estreacutes 52
Figura 23 Pruebas de Usabilidad 53
Figura 24 Pruebas de Portabilidad 53
Figura 25 Pruebas de Caja Blanca 54
Figura 26 Modelo de desarrollo en V 55
Figura 27 Dificultades de pruebas en aplicaciones Web e impacto 56
Figura 28 Logo de Galgus 58
Figura 29 Arquitectura de CHT Cloud Manager 59
Figura 30 CHT_CLI 60
Figura 31 Plataforma de Gestioacuten de RabbitMQ 61
Figura 32 Patroacuten PublicadorSuscriptor 61
Figura 33 Ejemplo de Interfaz Graacutefica de un Zone Manager 62
Figura 34 Ejemplo de Interfaz Graacutefica de MoMap 63
20
Figura 35 Interfaz Graacutefica del Servidor de Licencias 64
Figura 36 Zero-Touch Provisioning (ZTP) 64
Figura 37 Test Plan de CHT Cloud Manager 65
Figura 38 Leyenda del Test Plan 66
Figura 39 Control de Versiones del Test Plan 66
Figura 40 Entorno de UAT con Docker (Anexo B) 67
Figura 41 Implementaciones disponibles de Selenium y Navegadores Web Compatibles 70
Figura 42 Coacutedigo de ejemplo con Python y Selenium 71
Figura 43 Estilo de representacioacuten Given-When-Then 72
Figura 44 Implementacioacuten de Pruebas en para el inicio de sesioacuten de CHT Cloud Manager 74
Figura 45 Ejemplo de reporte de pruebas automatizadas con Robot Framework 75
Figura 46 Ejemplo de documentacioacuten generada con Libdoc 77
Figura 47 Ejemplo de documentacioacuten generada con Testdoc 77
Figura 48 Ejemplo de Flujo de Trabajo en Redmine para Galgus CHT Cloud Manager 79
Figura 49 Esquema Graacutefico de Metodologiacutea Scrum 79
Figura 50 Logo de Galgus CHT Cloud Manager 82
Figura 51 Estructura del Proyecto 83
Figura 52 Fragmento del fichero ldquoSelectorpyrdquo 83
Figura 53 Fragmento del fichero ldquoCommon_Keywordsrobotrdquo 84
Figura 54 Fragmento del fichero de Configuracioacuten de pruebas ldquoConfigurationrobotrdquo 84
Figura 55 Diagrama de paquetes del proyecto de pruebas 85
Figura 56 Estructura de una Suite de Pruebas 85
Figura 57 Ejemplo de ldquoTest Setuprdquo personalizado para un caso de prueba 86
Figura 58 Vista de Gestioacuten Principal (Cloud Tab) 87
Figura 59 Pestantildea ldquoAdministrationrdquo 87
Figura 60 Diagramas de Flujo de Casos de Prueba U0025 y U0027 88
Figura 61 Script de Pruebas U0025 88
Figura 62 Keyword ldquoEdit Fieldsrdquo 88
Figura 63 Pestantildea ldquoList of Zone Managersrdquo 89
Figura 64 Diagrama de flujo de Caso de Prueba U0023 89
Figura 65 Script de Prueba U0023 90
Figura 66 Keyword ldquoZone Manager is registered successfullyrdquo 90
Figura 67 Seccioacuten de Fabricantes 90
Figura 68 Diagrama de flujo de Caso de Prueba U0009 91
Figura 69 Script de Prueba U0009 91
Figura 70 Toast Success 92
Figura 71 Keyword ldquoCorrectly Createrdquo 92
Figura 72 Setup amp Teardown de U0008 92
21
Figura 73 Mapa de Zone Managers 92
Figura 74 Funcioacuten que dibuja los ZM en el Mapa y obtiene los piacutexeles en pantalla 93
Figura 75 Diagrama de Flujo de Caso de Prueba U0007 94
Figura 76 Pestantildea ldquoGroupsrdquo 95
Figura 77 Diagrama de flujo de Caso de Prueba U0119 96
Figura 78 Script de Prueba U0119 97
Figura 79 Keyword ldquoVerify if AP is registered Succesfully on grouprdquo 97
Figura 80 Keywords Input Into Text Field y Clear Field Of Characters 97
Figura 81 Pestantildea ldquoCHT Zonesrdquo 98
Figura 82 Diagrama de Flujo de Caso de Prueba U0204 99
Figura 83 Scripts de Prueba U0204 99
Figura 84 Keyword Add Zone CHT to AP 99
Figura 85 Pestantildea BackupRestore 100
Figura 86 Diagrama de Flujo de Caso de Prueba U0401 101
Figura 87 Script de Prueba U0401 101
Figura 88 Keyword Restore For AP hace done successfully 101
Figura 89 Pestantildea ldquoFirmwarerdquo 102
Figura 90 Diagrama de Flujo de Caso de Prueba U0303 103
Figura 91 Script de Prueba U0303 103
Figura 92 Keyword Flash AP 103
Figura 93 Pestantildea ldquoVLAN amp Bridgesrdquo 104
Figura 94 Diagrama de Flujo de Caso de Prueba U0527 105
Figura 95 Script de Prueba U0527 105
Figura 96 Keyword Go And Create VLAN 105
Figura 97 Pestantildea SSIDs 106
Figura 98 Diagrama de Flujo de Caso de Prueba U0530 106
Figura 99 Script de Prueba U0530 107
Figura 100 Keyword Go And Create SSID 107
Figura 101 Pestantildea ldquoCHTrdquo 108
Figura 102 Diagrama de Flujo de Caso de Prueba U0539 109
Figura 103 Script de Prueba U0539 109
Figura 104 Keyword ACA Is Working 109
Figura 105 Keyword Changes On CLI 110
Figura 106 Comando CHT para obtener el estado del moacutedulo ACA en el punto de acceso 110
Figura 107 Pestantildea ldquoRadiusrdquo 110
Figura 108 Escenario de Funcionamiento de Servidor Radius 110
Figura 109 Diagrama de Flujo de Caso de Prueba U0601 111
Figura 110 Script de Prueba U0601 111
Figura 111 Keyword Create Radius Profile 112
22
Figura 112 Pestantildea Captive Portals 112
Figura 113 Escenario de Funcionamiento de un Portal Cautivo 112
Figura 114 Diagrama de Flujo de Caso de Prueba U0701 113
Figura 115 Script de Prueba U0701 113
Figura 116 Keyword Edit or Delete Captive Portal Profile 114
Figura 117 Pestantildea General 115
Figura 118 Diagrama de Flujo de Caso de Prueba U0522 116
Figura 119 Script de Prueba U0522 116
Figura 120 Keyword Check Number of Clients Increases 116
Figura 121 Pestantildea AP Network 117
Figura 122 Libreriacutea SSH para Robot Framework 117
Figura 123 Ventana de Configuracioacuten de TC Rules 118
Figura 124 Diagrama de Flujo de Caso de Prueba U0511 119
Figura 125 Script de Prueba U0511 120
Figura 126 Keyword Wait Timer 120
Figura 127 Keyword Check On CLI 120
23
24
GLOSARIO
CHT Cognitive Hostpot Technology
BDD Behaviour-Driven Development
MBT Model Based Testing
API Application Programing Interface
UAT User Acceptance Testing
SUT System Under Test
UML Unified Modeling Language
FSM Finite State Machine
RAE Real Academia Espantildeola
IEEE Institute of Electronical and Electronics Engineers
ITIL Information Technology Infrastructure Library
ISO International Organization for Standardization
WebQEM Web-site Quality Evaluation method
ISTQB International Software Testing Qualifications Board
TDD Test-Driven Development
SOA Service Oriented Architecture
WiFi Wireless Fidelity
MGR Manager Module
SB Smart Band Steering Module
TCM Traffic Congestion Management Module
LOC Localization Module
POWER Power Control Module
SR Smart Roaming Module
LB Load Balancing Module
AMQP Advance Message Queuing Protocol
HTML HyperText Markup Language
CSS Cascading Style Sheets
HTTPS HyperText Transfer Protocol Secure
TLS Transport Layer Security
REST REpresentational State Transfer
JSON JavaScript Object Notation
DOM Document Object Model
SQL Structure Query Language
ZMB Zone Manager Backend
ZTP Zero-Touch Provisioning
25
RF Robot Framework
CICD Continuous IntegrationContinuous Delivery
SSH Secure SHell
SCP Secure Copy ProtocolSimple Communication Protocol
26
27
1 INTRODUCCIOacuteN
ctualmente el desarrollo software se encuentra en un proceso revolucionario cuyo principal objetivo y
tendencia es la implantacioacuten y desarrollo de software distribuido donde se marcan como principales
objetivos la disponibilidad usabilidad y funcionalidad de cualquier aplicacioacuten a traveacutes de internet Es
aquiacute donde entran en juego entre otros el desarrollo de aplicaciones o servicios Web sustituyendo en gran
medida al desarrollo de aplicaciones y servicios de escritorio
Figura 1 Fuente de datos Morgan Stanley
Muchos son los aspectos a tener en cuenta entre los que cabe destacar la eficiencia la velocidad de respuesta y
de navegacioacuten los cuales para algunos servicios Web son excelentes pero para otros auacuten se encuentran en un
proceso de mejora Esto es debido a que gran cantidad de aplicaciones requieren de un buen disentildeo donde se
optimicen el uso de los recursos disponibles como el ancho de banda memoria carga del servidor respaldo
seguridad etc
A
Hemos establecido la civilizacioacuten de manera que los
maacutes cruciales elementos dependen de la ciencia y la
tecnologiacutea
Carl Sagan
28
11 Motivacioacuten
La gran demanda de servicios y aplicaciones Web distribuidas que permitan gestionar agilizar y simplificar
cualquier aacutembito de negocio hace que cada vez maacutes que dichas aplicaciones contemplen un mayor
conjunto de requisitos solicitados por los clientes lo cual se traduce en un mayor nuacutemero de funcionalidades
y casos de uso contemplados en dichas aplicaciones
Ademaacutes dichas aplicaciones se necesitan cada vez en un menor tiempo lo cual conlleva a reducir los
periodos en las diversas fases por las que pasa un proyecto software desde la fase de disentildeo hasta la de
pruebas Es en esta uacuteltima donde antes de ser entregada al cliente como un producto se detectan los
posibles errores e incluso se puede evaluar si la funcionalidad ofrecida por la aplicacioacuten esta alineada con
los requisitos demandados por el cliente
Los fallos o errores en las aplicaciones Web mal probadas bien por falta de asignacioacuten de tiempo o recursos
a la fase de pruebas tienen una mayor repercusioacuten teniendo el potencial de generar una gran cantidad de
quejas e insatisfaccioacuten por parte de los clientes casi inmediatamente En el caso de las aplicaciones Web
no soacutelo se trata de peacuterdidas econoacutemicas sino tambieacuten de peacuterdida de prestigio fiabilidad y credibilidad por
parte de nuestros usuarios o clientes Los consumidores de hoy demandan una tecnologiacutea intuitiva y de
confianza en un mercado en continuo crecimiento donde un pequentildeo error puede acarrear falta de
satisfaccioacuten en un usuario peacuterdidas millonarias a una empresa o incluso dantildeos humanos Y es en este tipo
de ciclos iterativos y raacutepidamente cambiantes donde la automatizacioacuten de pruebas juega un papel decisivo
iquestY cuaacutel es la causa de estos problemas Para ello debemos tener en cuenta que estos sistemas son disentildeados
por el ser humano el cual comete fallos ya sea por presioacuten en los plazos de trabajo por la complejidad del
coacutedigo o de la infraestructura por cambios de tecnologiacuteas o por cualquier otra interaccioacuten con el sistema
Como ha quedado reflejado un proceso riguroso de control de sistemas y documentacioacuten permiten
bull Ayudar a reducir el riesgo de los posibles fallos y Mejora la calidad de los sistemas a la hora de ser
usados
bull Un correcto mantenimiento del producto a lo largo del ciclo de desarrollo
bull Un cumplimiento de requisitos legales (normas nacionales e internacionales ordenanzas
municipales etc)
bull Una adecuacioacuten de un sistema a los requisitos contractuales
bull Una adaptacioacuten de estaacutendars especiacuteficos de la industria
La forma en la que se logre y las herramientas empleadas variaraacuten en funcioacuten de factores como la
envergadura y tipo de proyecto den cuanto a los riesgos tecnoloacutegicos de seguridad o de negocio asiacute como
del presupuesto y tiempo disponible
Figura 2 Manual Testing vs Automated Testing [20]
29
12 Alcance y Objetivos
Las pruebas de software o software testing pueden llevarse a la praacutectica de muacuteltiples maneras pero el
presente proyecto se centra en el componente funcional del producto enfocado en lo que hace el sistema y
no coacutemo primando la aceptacioacuten por parte de los usuarios en base a los requisitos de disentildeo originales Es
decir el punto de mira estaacute en cumplir los requisitos establecidos por el cliente dejando fuera del alcance
del proyecto la estructura del coacutedigo fuente implementado
Bajo este contexto se plantea la automatizacioacuten de la fase de pruebas de una aplicacioacuten Web distribuida
centrando el enfoque de este proyecto en la automatizacioacuten de pruebas funcionales maacutes concretamente
pruebas de humo or smoke tests y aceptacioacuten Hasta ahora dichas pruebas se realizaban manualmente por
un ingeniero de pruebas lo cual permitiacutea evaluar la calidad del producto que seriacutea entregado al cliente
Ademaacutes se realizaraacute un marco teoacuterico donde se resumiraacuten una clasificacioacuten de los diferentes tipos de
pruebas software que pueden realizarse sobre una aplicacioacuten
Concretamente la solucioacuten abordada en esta memoria se cintildee al mantenimiento de un producto Web como
es la plataforma Galgus CHT Cloud Manager Para ello se cubriraacuten un gran conjunto de funcionalidades
ofrecidas por dicha aplicacioacuten Web como por ejemplo inicio y cierre de sesioacuten flujos de navegacioacuten
comprobacioacuten de los elementos mostrados y uso de la caja de buacutesquedas Sin llegar a ser exhaustivos este
tipo de pruebas conocidas como smoke tests son faacutecilmente automatizables y permiten detectar las primeras
sentildeales de que un sistema no funciona de manera correcta Por tanto es necesario traducir los requisitos
funcionales a instrucciones de alto nivel faacutecilmente entendibles por personas con poca formacioacuten teacutecnica
dado que seraacute el el resultado mostrado de las pruebas realizadas (informes de pruebas) Estas instrucciones
usaraacuten Behaviour-Driven Development (BDD) para describir interacciones entre el usuario y el sistema
definiendo actor accioacuten y comportamiento esperado del sistema Robot Framework es la herramienta que
se usa para este punto
Una vez tenemos dichas instrucciones se deben traducir de nuevo a un lenguaje de menor nivel como es
Python para implementar los test scripts Estos scripts seraacuten los que Selenium Webdriver procese y traduzca
para comunicarse con el controlador del navegador Web Chrome en nuestro caso a traveacutes de una API
Posteriormente el navegador se encargaraacute de ejecutar los comandos de accioacuten y de devolver la informacioacuten
de estado de vuelta Finalmente Robot Framework elaboraraacute un informe en formato html detallando las
pruebas realizadas resultados de las interacciones tiempos de ejecucioacuten y espera errores producidos etc
Tambieacuten se realizaraacute un estudio del arte sobre una teacutecnica conocida como Model Based Testing (MBT)
Dicha teacutecnica permite la generacioacuten automaacutetica de las pruebas a realizar sobre un sistema partiendo del
modelado del comportamiento de dicho sistema Ademaacutes esta teacutecnica tambieacuten abarca la traduccioacuten de las
pruebas generadas en scripts ejecutables para aplicar dichas pruebas sobre el sistema dando tambiacuteeacuten la
posibilidad de evaluar los resultados Esto proporciona muchas ventajas sobre la fase de pruebas pero a la
vez tambieacuten requiere un mayor esfuerzo en la fase de disentildeo y una presencia continua de la fase de pruebas
en otras etapas del ciclo de vida del proyecto Tambieacuten se presentaraacute un conjunto de normativas que regula
y normaliza la gestioacuten de calidad software
Posteriormente se describiraacute el sistema sobre el cual se basa la aplicacioacuten bajo pruebas llamada CHT
Cloud Manager Se presentaraacute la arquitectura de la aplicacioacuten y posteriormente se destacaraacuten los objetivos
de automatizacioacuten de testeo sobre la misma proponiendo el entorno de UAT planteado para someter la
aplicacioacuten a las pruebas automaacuteticas desarrolladas Se dedicaraacute una seccioacuten a analizar las tecnologiacuteas y
herramientas usadas donde se centraraacute la atencioacuten en Robot Framework Selenium y Python como las
tecnologiacuteas usadas para automatizar el testeo Ademaacutes se destacaraacute la integracioacuten del entorno de UAT
como fase de la integracioacuten continua de la aplicacioacuten ademaacutes de la metodologiacutea de trabajo llevada a cabo
Finalmente se presentaraacuten algunos experimentos y demostraciones de uso de la herramienta desarrollada
se describiraacuten algunas liacuteneas de mejora y conclusiones y se incluiraacuten algunos posibles anexos para la puesta
en marcha de la aplicacioacuten y reportes de algunas pruebas entre otros
30
13 Estructura de la memoria
El siguiente esquema resume de forma geneacuterica los puntos tratados en esta memoria para que el lector pueda
tener una idea orientativa de la organizacioacuten de este documento
1 Introduccioacuten En este punto se abordan temas geneacutericos como los objetivos motivacioacuten y alcance de
forma que pueda adquirirse una breve aproximacioacuten a los detalles del proyecto
2 Estudio del Arte y Revisioacuten A lo largo de esta seccioacuten se presentaraacute un estudio sobre la teacutecnica
conocida como Model Based Testing la cual permitiriacutea mejorar el proceso de automatizacioacuten de
pruebas Ademaacutes se realiza una revisioacuten sobre la gestioacuten de Calidad Software presentado algunos
modelos existentes en la actualidad
3 Marco Teoacuterico Consta de un estudio sobre el proceso de pruebas en un proyecto Software y los
principales tipos de pruebas Software existentes
4 Sistema En este punto se presenta la arquitectura del sistema sobre el que se van a automatizar las
pruebas de aceptacioacuten o Smoke Tests Ademaacutes se describe el alcance y objetivos de dichas pruebas y
se presenta la arquitectura de la solucioacuten planteada como escenario de pruebas haciendo uso de Docker
como tecnologiacutea de automatizacioacuten en el despliegue de aplicaciones software alojadas en contenedores
de software
5 Tecnologiacuteas y Herramientas usadas Consta del conjunto de tecnologiacuteas usadas para la
implementacioacuten de las pruebas de aceptacioacuten automatizadas y las herramientas para utilizar dichas
pruebas y para gestionar el trabajo del equipo de desarrollo y calidad responsable de este proyecto
6 Experimentos Consta de un detalle sobre la funcionalidad de un conjunto de pruebas que han sido
implementadas para verificar y validar el funcionamiento esperado del sistema Para cada prueba se
definen criterios de aceptacioacuten diagramas de flujo y scripts de implementacioacuten detallando algunas de
las implementaciones clave
7 Liacuteneas de Mejora y Conclusiones Se incluye una seccioacuten conclusiones finales tras la realizacioacuten del
proyecto y una valoracioacuten del mismo a nivel general y personal Ademaacutes se destacaraacuten algunas liacuteneas
de mejora futuras relacionadas principalmente con la aplicacioacuten de Model Based Testing (MBT) y otros
aspectos sobre la implementacioacuten actual de la herramienta de automatizacioacuten
Ademaacutes se realizaraacute una seccioacuten de anexos en el que se trataraacuten puntos adicionales sobre el proyecto
bull Anexo A Preparacioacuten del Entorno de Trabajo y Ejecucioacuten de Pruebas
bull Anexo B Docker de Robot Framework y Entorno de UAT Dockerizado
bull Anexo C Revisioacuten de Reportes y Logs
31
32
2 ESTUDIO DEL ARTE Y REVISIOacuteN
n este punto se realizaraacute un estudio sobre el marco teoacuterico de una de las teacutecnicas existentes que permite
la generacioacuten y ejecucioacuten automaacutetica de casos de test a partir del modelado de un sistema para la fase
de pruebas de una aplicacioacuten Esta teacutecnica es conocida como Model Based Testing (MBT) Ademaacutes
se realizaraacute una revisioacuten de la normativa relacionada con la gestioacuten de calidad software analizando la familia de
normas ISOIEC 25000
21 Model Based Testing (MBT)
211 Introduccioacuten
Dada la rapidez con la que se demandan los servicios contratados por los clientes en muchas ocasiones la
mayoriacutea del tiempo y esfuerzo asignado para la realizacioacuten de proyectos de software van destinados a la
labor de desarrollo dedicando menos esfuerzos en otras fases del ciclo de vida de un proyecto como las
fases de disentildeo o de pruebas Esto puede conllevar a que el proyecto no se desarrolle de acuerdo con los
requisitos demandados por los clientes y que el nuacutemero de puntos de fallo del producto software aumente
La fase de testeo o prueba de un producto software durante su ciclo de vida es una etapa fundamental para
validar la calidad del producto desarrollado y ofrecido a un cliente para conseguir un grado de satisfaccioacuten
aceptable de forma que se cumpla con los requisitos demandados y con el menor grado de error posible
Figura 3 Fase de Pruebas y Validacioacuten
Uno de los factores por los que en ocasiones no se emplean suficientes recursos a la fase de pruebas es la
gran cantidad de casos de pruebas que se deben realizar para validar un sistema Por cada caso de prueba
se deben asignar recursos relacionados con la planificacioacuten disentildeo y ejecucioacuten del mismo
Por tanto en este punto cabe plantearse la idea de automatizar no solo los casos de pruebas que validan un
sistema sino la generacioacuten de los casos de prueba Esto puede permitir reducir de forma considerable el
coste y esfuerzos en la fase de pruebas En este contexto surge el concepto de Model Based Testing (MBT)
E
La tecnologiacutea no es en siacute el fin sino el medio entre la
sociedad del conocimiento y el desarrollo mundial
Anoacutenimo
33
212 iquestQueacute es Model Based Testing
Este se trata de un meacutetodo capaz de controlar la calidad del software durante su ciclo de vida permitiendo
la generacioacuten automaacutetica de los casos de prueba e incluso la ejecucioacuten y evaluacioacuten automaacutetica de
resultados Para ello se requiere de un modelado y disentildeo correcto del sistema bajo pruebas como base
para la aplicacioacuten de esta teacutecnica
Figura 4 Esquema baacutesico de Model Based Testing
MBT permite crear un modelo del comportamiento esperado por el sistema a traveacutes del cual permite la
aplicacioacuten de diferentes teacutecnicas para la generacioacuten de casos de prueba [1]
bull Generacioacuten de casos de pruebas con datos de entrada sobre un modelo de dominio del sistema bull Generacioacuten de casos de pruebas de un modelo de entorno bull Generacioacuten de casos de prueba con predicciones del comportamiento del modelo bull Generacioacuten de scripts de prueba a partir de pruebas abstractas
213 iquestCoacutemo funciona Model Based Testing
En primer lugar se requiere del disentildeo de un modelo del sistema bajo test el cual debe tener al menos dos
caracteriacutesticas principales debe ser pequentildeo en relacioacuten al tamantildeo del sistema de forma que no requiera
un coste elevado pero debe ser lo suficientemente detallado para describir completamente las
caracteriacutesticas que se quieran probar sobre el sistema
Una vez implementado el modelo del sistema a probar se procederiacutea a la utilizacioacuten de herramientas
basadas en la teacutecnica MBT para generar automaacuteticamente el banco de pruebas a partir del modelo del
sistema bajo test (SUT) Estos bancos de pruebas generados seraacuten un conjunto de pruebas abstractas cada
una de las cuales define la secuencia de operaciones a realizar para probar una funcionalidad determinada
con sus respectivos valores o datos de entrada necesarios y las salidas o respuestas del sistema que se
esperan
A partir del banco de pruebas abstractas se deben transformar en scripts de pruebas ejecutables lo cual
puede realizarse con herramientas basadas en la teacutecnica MBT Estos scripts podriacutean ser ejecutados para la
deteccioacuten de errores sobre el sistema bajo test y esta ejecucioacuten podriacutea ser controlada y monitorizada por
alguna herramienta de ejecucioacuten de pruebas
En el siguiente diagrama se muestra el proceso de aplicacioacuten de este meacutetodo donde se propone dividir el
proceso en cinco fases principales [1]
1 Modelado Modelar el sistema bajo test y su entorno 2 Generacioacuten Generar las pruebas abstractas a partir del modelo planteado en la fase anterior 3 Concretizado Concretizar o adaptar las pruebas abstractas para transformarlas en ejecutables 4 Ejecucioacuten Ejecutar las pruebas sobre el sistema bajo test y definir decisiones o veredictos para las
mismas de forma que se pueda determinar el correcto funcionamiento del sistema bajo test 5 Anaacutelisis Analizar los resultados obtenidos a partir de la ejecucioacuten de los casos de prueba
34
Destacar que para el generador de casos de prueba y el script de pruebas se suelen usar herramientas de pruebas
especiales Por este motivo se encuentran resaltados en negrita
Figura 5 Proceso detallado de Model Based Testing (MBT)
Una vez presentado el proceso o metodologiacutea para llevar a cabo dicha teacutecnica se describiraacuten las principales
fases
2131 Construccioacuten del Modelo
Dicha fase consiste en la construccioacuten de un modelo que represente el comportamiento detallado del sistema
bajo pruebas yo su entorno a partir de los requisitos de disentildeo del mismo y el plan de pruebas desarrollado para
cumplir con estos requisitos
Este es el paso maacutes importante en la aplicacioacuten de la teacutecnica Model Based Testing ya que el resto de fases
dependeraacute siempre del modelo del sistema bajo pruebas Cuanto maacutes completo sea el modelo maacutes efectivos
seraacuten los casos de prueba generados a partir de este
Figura 6 Construccioacuten del Modelo
35
Para llevar a cabo el modelo del comportamiento de la aplicacioacuten se requiere conocer exactamente el
comportamiento esperado de la misma lo cual lleva a estudiar y analizar en profundidad el sistema y su entorno
previamente
Existen diversas especificaciones formales para el modelado a partir de los requisitos como por ejemplo los
diagramas UML Estos ayudan a que el modelado sea una tarea algo maacutes sencilla de realizar que si se llevara a
cabo a partir de los requisitos escritos en lenguaje natural Por otro lado para modelar el comportamiento existen
diversas teacutecnicas como las maacutequinas de estados finitos (FSM) Cadenas de Maacuterkov Tablas de decisiones
Diagramas de estados etc
En conclusioacuten modelar un sistema no es una tarea sencilla ya que requiere de habilidades teacutecnicas experiencia
e imaginacioacuten para construir un modelo que se comporte de la forma deseada Dicho modelo debe cumplir con
las siguientes propiedades [2]
bull Debe ser lo maacutes abstracto posible sin perder la informacioacuten importante
bull No debe contener informacioacuten que sea redundante o que no esteacute relacionada con el alcance de las
pruebas
bull Debe ser entendible para los ingenieros de pruebas incluso a expensas de la brevedad y abstraccioacuten del
mismo
bull Debe ser flexible y abierto para permitir cambios y antildeadir o eliminar nuevas funcionalidades
bull Debe considerar todos los detalles de implementacioacuten de las pruebas
2132 Generacioacuten de Casos de Prueba
Los casos de prueba seraacuten generados tras la construccioacuten previa del modelo del sistema Antes de la creacioacuten de
los casos de prueba los ingenieros de pruebas deben especificar o proveer informacioacuten sobre el criterio o
propoacutesito de los casos de prueba las entradas y en algunos casos las salidas esperadas del sistema
Destacar que generar las salidas esperadas correspondientes a unas determinadas entradas es maacutes complejo que
generar soacutelo las entradas Para ello se necesita un oraacuteculo que cree salidas vaacutelidas y las mapee a los casos de
prueba Crear el oraacuteculo es la tarea maacutes compleja
Las dificultades presentadas en esta fase dependeraacuten de si el modelo es complejo o simple y la efectividad de
los casos de prueba generados dependeraacute de lo completo y preciso que sea dicho modelo para poder generar
automaacuteticamente los casos de prueba
Cuando el sistema es complejo la cantidad de casos de test es muy grande e incluso infinita Por tanto evaluar
todos los casos de test resulta inviable y costoso En este caso para mejorar la calidad del sistema se necesita
seleccionar los casos de test que realmente puedan ayudar a localizar tantos fallos como sea posible con un coste
aceptable
Existen diferentes criterios de cobertura que permiten ayudar a controlar el proceso de generacioacuten de casos de
prueba Sin embargo se recomienda seleccionar maacutes de uno de estos criterios para lograr un mayor resultado en
la cobertura de pruebas
2133 Ejecucioacuten de Casos de Prueba
La ejecucioacuten de los casos de pruebas requiere la transformacioacuten de los mismos en una forma ejecutable Debido
a que los los scripts de pruebas ejecutables pueden ser reutilizados durante todo el tiempo empleado en la
validacioacuten del sistema estos deben ser escritos de una forma maacutes eficiente que permita que sean reutilizables e
incluso que frente a una modificacioacuten sean maacutes faacuteciles generarlos y ejecutarlos Por ello se crean scripts
ejecutables para los casos de prueba abstractos
El proceso de transformacioacuten en pruebas ejecutables seriacutea maacutes eficiente si es hecha de forma automaacutetica
Despueacutes de aplicar los casos de prueba ejecutables al sistema bajo pruebas se obtienen las salidas actuales del
sistema las cuales deberaacuten ser contrastadas con las salidas esperadas
36
2134 Anaacutelisis de los Resultados
Una vez ejecutados los casos de pruebas y obtenidas las salidas actuales del sistema se deben evaluar y analizar
los resultados obtenidos Para ello se debe comparar las salidas actuales obtenidas con las salidas esperadas
especificadas en los casos de prueba Esta tarea de comparacioacuten podriacutea realizarse idealmente de forma
automaacutetica lo cual dariacutea como resultados posibles
1 Pasa Cuando las salidas actuales se encuentran acordes con las salidas esperadas
2 Falla Cuando las salidas actuales no se encuentran acordes con las salidas esperadas
3 Inconcluso Cuando no se puede tomar una decisioacuten en el momento
Hay que destacar que puede darse el caso en el que si las salidas esperadas no estaacuten bien determinadas los
resultados obtenidos al contrastar dichas salidas con las actuales sean falsos dando lugar a resultados sin utilidad
y que pueden dar lugar a confusioacuten
Por este motivo la generacioacuten automaacutetica de las salidas esperadas es una tarea compleja e importante en todo el
proceso especialmente en sistemas complejos Por tanto el nivel de dificultad para encontrar un oraacuteculo de
pruebas depende del tamantildeo y complejidad del sistema Sin embargo la necesidad e importancia del oraacuteculo de
pruebas tambieacuten aumenta cuando el sistema es maacutes complejo
Tras obtener los resultados se debe determinar si se decide generar maacutes casos de prueba si se debe modificar el
modelo o si la fase de pruebas debe ser detenida y debe ponerse en marcha el software del sistema que se estaacute
probando
214 Consideraciones para la aplicacioacuten de Model Based Testing (MBT)
Son muchos los artiacuteculos que describen aspectos importantes a tener en cuenta durante el desarrollo o la
aplicacioacuten de esta teacutecnica Algunas de estas consideraciones a destacar seriacutean las siguientes [3]
1 El modelo que describe el comportamiento del sistema es el punto clave
El comportamiento del modelo debe ser desarrollado cuidadosamente Sus limitaciones y restricciones deben
ser respetadas durante el modelado del sistema bajo pruebas De esta forma si el modelo estaacute mal las pruebas
generadas tambieacuten lo estaraacuten Por tanto la exactitud del modelo es fundamental para pasar a la fase de
generacioacuten de casos de prueba
2 Las pruebas deben cubrir los criterios de control de flujo y datos
Los criterios de cobertura de las pruebas definen un conjunto de casos de prueba seleccionados para la misma
Estos casos de pruebas pueden ser generados a partir de dos fuentes criterios de flujo de control o de flujo
de datos En el caso de pruebas aplicadas a grandes sistemas es importante combinar ambos criterios para
incrementar la cobertura de las pruebas
3 El nivel de automatizacioacuten debe ser elevado
El nivel de automatizacioacuten es un factor importante para definir la factibilidad de uso de MBT Normalmente
suele haber un uacutenico paso no automatizado el modelado del comportamiento del sistema el cual es utilizado
como entrada para el proceso de generacioacuten de los casos de prueba Si hubiese otros pasos no automatizados
se incrementariacutea el esfuerzo los costes y la complejidad de su uso
4 Son fundamentales las herramientas que soportan la automatizacioacuten de las fases de MBT
Las herramientas usadas deben soportar la ejecucioacuten de los pasos automatizados Si no hay una herramienta
que soporte un determinado paso esta tarea podriacutea ser difiacutecil e inviable Por tanto una herramienta debe
soportar la integracioacuten entre los diferentes pasos no automatizados y automatizados
5 Los liacutederes del proyecto deben entender las habilidades requeridas y la complejidad para usar
MBT
Las personas encargadas de la fase de pruebas necesitan conocer ademaacutes de las teacutecnicas de pruebas los
lenguajes de modelado y algunos lenguajes de programacioacuten
37
6 El orden de los pasos a seguir mientras se usa un enfoque MBT
Es necesario respetar los pasos seguidos para la generacioacuten de los casos de prueba de forma que sean
respetados en la fase de ejecucioacuten de las pruebas siendo ejecutados en la misma secuencia en que fueron
definidos En caso contrario se podriacutean generar salidas erroacuteneas de dichas pruebas
7 Transferencia de la Tecnologiacutea
Las tecnologiacuteas usadas para la aplicacioacuten de la teacutecnica MBT se transfieren desde entornos acadeacutemicos o de
investigacioacuten para ser implementados en proyectos industriales Por este motivo necesitan ser analizados
cuidadosamente antes de ser usadas
215 Beneficios de Model Based Testing (MBT)
A continuacioacuten se definen diversos beneficios que proporciona la aplicacioacuten de Model Based Testing para la
fase de pruebas [1] [4]
1 Deteccioacuten de Fallos del Sistema Bajo Pruebas
El modelado del comportamiento del sistema bajo pruebas permite detectar errores ambiguumledades o lagunas
que pueden presenciarse en la toma de requisitos especificacioacuten y disentildeo del software Por tanto permite
una deteccioacuten temprana de errores
2 Reduccioacuten de costes y tiempo en la fase de pruebas
La aplicacioacuten de esta teacutecnica contribuye a que el tiempo coste y recursos empleados a la fase de pruebas
disminuya Sin embargo se requiere una mayor asignacioacuten de recursos para el modelado y mantenimiento
del sistema
3 Mejora de la calidad de las pruebas
Cuando las pruebas se desarrollan manualmente la calidad de las mismas es muy dependiente de los
desarrolladores que la implementan Ademaacutes el proceso de disentildeo no puede ser reproducido el criterio
racional aplicado para cada prueba normalmente no es recordado y el resultado de los casos de prueba no es
faacutecilmente interpretado ni contrastado con los requisitos originales del sistema
Model Based Testing es una teacutecnica capaz de mejorar mucho estos inconvenientes que se presentan sobre el
desarrollo de pruebas manuales gracias al generador automatizado de casos de prueba
4 Trazabilidad
Puede definirse como la habilidad para relacionar cada caso de prueba al modelo criterio de seleccioacuten e
incluso a los requisitos informales del sistema Esto ayuda a explicar los casos de prueba asiacute como justificar
por queacute fueron creados Los algoritmos aplicados para la generacioacuten de pruebas deben saber queacute partes del
modelo seraacuten empleadas en cada caso de prueba y las salidas esperadas
5 Evolucioacuten de los requisitos
Si los requisitos del sistema cambian con la aplicacioacuten de Model Based Testing bastariacutea con actualizar el
modelo y las pruebas seraacuten generadas de nuevo de forma automaacutetica Debido a que el modelo es usualmente
maacutes pequentildeo que el conjunto de pruebas del sistema requiere menos tiempo actualizar el modelo que
actualizar todos los casos de prueba Por tanto puede concluirse que se obtiene una respuesta maacutes raacutepida
frente a un cambio en los requisitos
6 Reusabilidad del modelo
El modelo contiene informacioacuten sobre el comportamiento del sistema bajo pruebas Por tanto este puede ser
reutilizado en futuras pruebas incluso cuando los requisitos cambian
38
216 Problemas y Limitaciones de Model Based Testing (MBT)
Una vez destacados los beneficios que aporta dicha teacutecnica tambieacuten es importante detallar algunos problemas
y limitaciones sobre su uso [1] [5]
2161 Problemas
bull Para abordar dicha teacutecnica es necesario que los ingenieros de pruebas tengan habilidades teacutecnicas sobre
la notacioacuten usada para el modelado del sistema Ademaacutes deberiacutean tener experiencia con herramientas
scripts y lenguajes de programacioacuten usados para ejecutar las tareas de Model Based Testing
bull Cuando dicha teacutecnica se pretende aplicar a sistemas complejos el modelado del sistema es maacutes
complejo y existe riesgo de producirse un desbordamiento de la cantidad de casos de prueba generados
a partir del modelo Por esta razoacuten es muy importante definir bien el conjunto de criterios para la
generacioacuten de las pruebas lo cual permite acotar la cobertura de pruebas de forma razonable
bull La automatizacioacuten de la generacioacuten del oraacuteculo de pruebas a partir del modelo es compleja
especialmente en sistemas complejos Cuando el tamantildeo del sistema aumenta la necesidad de
automatizacioacuten tambieacuten aumenta
bull Es necesario desarrollar un modelo de software especiacutefico para un dominio en concreto de aplicacioacuten
ya que existen diversas notaciones de modelado del sistema
bull Es necesario la especificacioacuten formal de los requisitos para obtener el modelo del sistema a partir de
estos La especificacioacuten informal o en lenguaje natural de los requisitos puede dar lugar a ambiguumledades
que dificultan la exactitud en el modelado
2162 Limitaciones
bull No es posible modelar todos los aspectos del comportamiento del sistema bajo pruebas Por tanto es
necesario el uso de otras notaciones de modelado que cubran dichos aspectos
bull Los proyectos software evolucionan continuamente surgiendo nuevos requisitos los cuales algunos
pueden quedar fuera de la fecha de planificacioacuten Si se ha comenzado con el modelado a partir de
requisitos antiguos se construiraacute un modelo erroacuteneo que no reflejaraacute los nuevos requisitos
contemplados lo cual daraacute lugar a errores en el sistema bajo pruebas o resultados no fiables
bull Cuando se produce un fallo en una prueba generada podriacutea resultar maacutes complejo determinar la causa
del fallo ya que la secuencia de pruebas generadas en Model Based Testing podriacutea ser maacutes compleja y
menos intuitiva que las disentildeadas manualmente
217 Cuando elegir Model Based Testing (MBT)
Finamente tras detallar los beneficios problemas y limitaciones sobre la teacutecnica bajo estudio se destacan
algunos puntos principales a tener en cuenta para la aplicacioacuten de dicha teacutecnica
bull Debe existir documentacioacuten lo suficientemente buena sobre el sistema para poder aplicarla
bull Si ya existe un modelo del sistema seriacutea un primer paso que facilitariacutea su aplicacioacuten
bull El manager del proyecto debe ser consciente que la fase de pruebas con Model Based Testing comienza
desde la toma de requisitos ya que se debe modelar el comportamiento del sistema bajo pruebas a partir
de estos Por tanto no se puede esperar que la fase de pruebas comience despueacutes del desarrollo Hacerlo
tras el desarrollo podriacutea significar la modificacioacuten de los requisitos y en consecuencia el desarrollo
39
22 Gestioacuten de Calidad Software
221 Introduccioacuten
En los uacuteltimos antildeos la creciente demanda de productos software principalmente de aplicaciones distribuidas
como los servicios Web provoca que diferentes empresas busquen soluciones software para satisfacer las
necesidades de los clientes Este conjunto de empresas forma un entorno competitivo en el que se intenta buscar
algunos factores para destacar sobre los demaacutes competidores respondiendo a las nuevas exigencias del mercado
Bajo este contexto se plantea la implantacioacuten de una direccioacuten basada en la calidad como la propuesta que
mejores resultados ha ofrecido No solo basta con desarrollar software acorde a los requisitos de los clientes y
las exigencias de los mismos sino que se trata de crear un producto que garantice su correcto funcionamiento
bajo el sustento de una garantiacutea de calidad razonable
El concepto de ldquocalidadrdquo siempre se ha relacionado con la inspeccioacuten de productos fiacutesicos Pero dicho teacutermino
ha ido expandiendo su contexto de una forma maacutes global y aplicable a cualquier tipo de servicio o producto
ofrecido a un cliente
222 Concepto de Calidad
Acorde a la definicioacuten ofrecida por la Real Academia Espantildeola (RAE) la calidad se define como ldquouna propiedad
o conjunto de propiedades inherente a algordquo ldquoAdecuacioacuten de un producto o servicio a las caracteriacutesticas
especificadasrdquo o ldquocondicioacuten o requisito que se pone en un contratordquo [6]
Por otro lado el instituto de Ingenieros Eleacutectricos y Electroacutenicos (IEEE) define la calidad como ldquoel grado con
el que un sistema componente o proceso cumple con los requisitos especificados y las necesidades o
expectativas del cliente o usuariordquo destacando que el eacutenfasis radica en los requisitos especiacuteficos del sistema y
en la buacutesqueda de la satisfaccioacuten del cliente [7]
Roger Pressmann define la Calidad del Software como ldquoConcordancia del software producido con los requisitos
expliacutecitamente establecidos con los estaacutendares de desarrollo prefijados y con los requisitos impliacutecitos no
establecidos formalmente que desea el cliente y en uacuteltima instancia el usuariordquo [8]
Una vez presentado el concepto de calidad su definicioacuten orientada al software se refiere al grado de desempentildeo
de las principales caracteriacutesticas con las que debe cumplir un sistema durante su ciclo de vida Estas
caracteriacutesticas son las que garantizan que el cliente cuente con un sistema confiable lo que permite un aumento
de la satisfaccioacuten frente a la funcionalidad y eficiencia del sistema construido
Figura 7 Concepto de Calidad
40
223 Modelos de Calidad de Software
Los modelos de calidad son aquellos documentos que integran la mayor parte de las mejores praacutecticas proponen
temas de administracioacuten en los que cada organizacioacuten debe hacer eacutenfasis integran diferentes praacutecticas dirigidas
a los procesos clave y permiten medir los avances en calidad
Bajo este contexto los modelos de calidad deben permitir la evaluacioacuten del sistema de forma cualitativa o
cuantitativa y de acuerdo con esta evaluacioacuten la organizacioacuten podraacute proponer implementar estrategias que
permitan la mejora continua en el resto de etapas del ciclo de vida como son las etapas de anaacutelisis disentildeo
desarrollo y pruebas software [7] Desde finales de los antildeos 70 se han ido desarrollando diversos modelos de
calidad del producto software con el fin de fijar una terminologiacutea y entender queacute concepto de calidad se estaacute
usando Asiacute mismo dichos modelos de calidad se clasifican de acuerdo con el enfoque de evaluacioacuten
contemplado ya sea a nivel de proceso producto o calidad de uso
2231 Calidad a Nivel de Proceso
Este enfoque de calidad de software describe que la calidad de un sistema software debe ser implementada desde
el inicio del proyecto y en cada etapa de su ciclo de vida debiendo permitir el control y seguimiento de los
aspectos de calidad para minimizar los riesgos y ofrecer un soporte continuo De esta forma se consigue
garantizar un nivel oacuteptimo de cumplimiento de los factores de calidad definidos teniendo en cuenta que si en
alguna etapa no se verifican dichos factores posiblemente disminuya el nivel de calidad no solo del proceso si
no tambieacuten del producto en desarrollo [7]
A continuacioacuten se muestra una liacutenea de tiempo de algunos modelos a nivel de proceso y se describen dos de los
que maacutes intereacutes presentan dentro del aacutembito de este proyecto
Figura 8 Liacutenea de tiempo de modelos a nivel de proceso
ITIL (Information Technology Infrastructure Library)
Desarrollado en el Reino Unido con el fin de fortalecer la gestioacuten gubernamental a partir de cinco elementos
fundamentales la perspectiva del negocio entrega del servicio soporte del servicio manejo de la infraestructura
y manejo de aplicaciones con el propoacutesito de ofrecer una estructura integral para prestar a la organizacioacuten un
servicio completo cubriendo necesidades de apoyo de instalacioacuten adecuacioacuten de redes comunicaciones
hardware servidores sistema operativo y software necesarios
Figura 9 Logo de ITIL
41
ISOIEC 20000
El objetivo principal de esta norma es avalar que la prestacioacuten de servicios de TI en una empresa cuenta con la
calidad necesaria para brindar dichos servicios a los clientes Esta norma engloba diferentes secciones dedicadas
a las especificaciones de dicha norma y a los coacutedigos de buenas praacutecticas
Figura 10 ISOIEC 20000
WebQEM
Web-site Quality Evaluation Method se trata de una metodologiacutea de evaluacioacuten de calidad de sitios Web en seis fases planificacioacuten y programacioacuten de la evaluacioacuten de la calidad definicioacuten y especificacioacuten de los requisitos de calidad establecidos definicioacuten e implementacioacuten de la evaluacioacuten elemental definicioacuten e implementacioacuten de la evaluacioacuten global anaacutelisis de resultados y evaluacioacuten de meacutetricas y finalmente conclusiones y documentacioacuten
Figura 11 Logo de WebQEM
42
2232 Calidad a Nivel de Producto
El enfoque de la calidad de software a nivel de producto tiene como objetivo especificar y evaluar el
cumplimiento de los criterios del producto Para ello se suelen definir y aplicar medidas o meacutetricas internas o
externas Por esta razoacuten muchas normas definen la calidad a nivel de producto de tipo interna externa y en uso
Esta uacuteltima se define como el conjunto de atributos relacionados con la aceptacioacuten por parte del usuario final y
seguridad
A continuacioacuten se muestra una liacutenea de tiempo de algunos modelos a nivel de proceso y se describen tres de los
que maacutes intereacutes presentan dentro del aacutembito de este proyecto
Figura 12 Liacutenea de tiempo de modelos a nivel de producto
ISO 9126
Este se basa en el modelo McCall el cual es uno de los modelos pioneros en la evaluacioacuten de la calidad de
software Desarrollado en 1991 es un marco normativo dirigido a desarrolladores aseguradores de calidad
evaluadores analistas y cualquier otro involucrado en el proceso de construccioacuten de software y la gestioacuten de
calidad del mismo Estaacute dividido en cuatro partes Modelo de Calidad Meacutetricas Externas Meacutetricas Internas y
Calidad de Meacutetricas en Uso
Esta norma busca la fiabilidad funcionalidad usabilidad eficiencia mantenibilidad y portabilidad en la
construccioacuten de productos software A continuacioacuten se muestra un esquema que resume dichas caracteriacutesticas
y subcaracteriacutesticas [8]
Figura 13 Esquema de ISO 9126
43
ISOIEC 25000
Basada en la norma ISO 9126 y adaptando parte del marco normativo a las necesidades del mercado actual Esta
norma tambieacuten conocida como SQuaRE (Software Product Quality Requirements and Evaluation) establece
un marco de trabajo comuacuten para evaluar la calidad de productos de Software
En dicha norma se definen los modelos teacuterminos y definiciones comunes para el resto de normas que componen
la serie 25000 La ISOIEC 25000 presenta diversas secciones entre las que se puede destacar [9]
ISOIEC 25010 Describe las caracteriacutesticas y subcaracteriacutesiticas de calidad que pueden ser evaluadas
en un producto software diferenciando entre calidad interna externa y de uso En la siguiente figura se
presenta un desglose de dichas caracteriacutesticas
ISOIEC 25040 Define el proceso de evaluacioacuten perioacutedico de la calidad del producto software
Figura 14 Esquema de ISOIEC 25000
44
224 Principales Ventajas e Inconvenientes de Modelos de Calidad anteriores
2241 A nivel de Proceso
Modelo Ventajas Inconvenientes
ITIL bull Mejor estructuracioacuten organizacioacuten y
claridad de los proyectos
bull Mayor control administrativo
bull Mayor eficacia y rapidez ante cambios
bull Incrementa la productividad del negocio y la
fiabilidad de los clientes
bull Tiempo y esfuerzo necesarios
bull Falta de conocimiento para apreciar la mejora
proporcionada
bull Involucracioacuten y compromiso de todo el
personal de la organizacioacuten
bull Frustracioacuten generada por expectativas a corto
plazo
bull No hay mejoriacutea si la inversioacuten asignada para
implantar el modelo es insuficiente
ISOIEC
20000 bull Reconocimiento internacional
bull Muy usado por las organizaciones
WebQUEM bull Calidad medida en fases y actividades de
forma cuantitativa con indicadores
bull Aplicaciones de Software centradas en la Web
son cada vez maacutes complejas provocan mayor
complejidad en su implantacioacuten
2242 A nivel de Producto
Modelo Ventajas Inconvenientes
ISO 9126 bull Determina queacute caracteriacutesticas y
subcaracteriacutesticas son importantes para el
producto
bull Define meacutetricas especiacuteficas para los
componentes Software
bull Define indicadores para las caracteriacutesticas de
calidad
bull Usabilidad tratada desde la perspectiva del
proceso no del producto
bull No tiene en cuenta la caracteriacutestica de ldquofacilidad
de aprendizajerdquo siendo esta recomendada por
otros estaacutendares
bull Meacutetricas complejas difiacutecilmente medibles
Requieren descomposicioacuten
ISOIEC
25000 bull Detecta objetivos del producto alineados con
necesidades reales de clientes finales
bull Evita ineficiencias y maximiza rentabilidad
y calidad del producto
bull El proceso de evaluacioacuten perioacutedica permite
la mejora continua
bull No establece niveles de calidad para cada
proyecto
bull No hace uso de meacutetricas o umbrales de calidad
225 Conclusiones
Una vez presentado el concepto de gestioacuten de calidad de software y los principales modelos y normas es
interesante destacar la diferencia entre calidad interna y externa La calidad interna se centra en las caracteriacutesticas
propias del producto software (disentildeo especificacioneshellip) mientras que la calidad externa lo hace con las
caracteriacutesticas dinaacutemicas del mismo es decir con el comportamiento Es por ello que el proceso de calidad
interna se inicia en las fases tempranas del ciclo de vida de un proyecto mientras la calidad externa se aplica
una vez se tiene un primer prototipo funcional del producto software desarrollado Por tanto se trataraacute de
automatizar el proceso de evaluacioacuten de la calidad externa del proyecto CHT Cloud Manager analizando
verificando y validando automaacuteticamente la aceptacioacuten de dicho producto
45
46
3 MARCO TEOacuteRICO PRUEBAS DE SOFTWARE
ras presentar el concepto de calidad y algunas de las normas y estaacutendares maacutes conocidos que describen
la aplicacioacuten de dicho concepto en el aacutembito del desarrollo de software se centraraacute el enfoque en el
papel del testeo y las pruebas de software Con ello se destacaraacuten algunos puntos principales para
llevar a cabo las pruebas de software el anaacutelisis disentildeo e implementacioacuten de dichas pruebas los diferentes tipos
y niveles de pruebas y las dificultades de la aplicacioacuten de pruebas de software sobre aplicaciones Web
31 Testing y Pruebas de Software
Habitualmente se tiene una percepcioacuten del testing de un producto como una tarea basada en la ejecucioacuten de
pruebas de forma repetitiva para la buacutesqueda de errores o problemas que puedan repercutir sobre la calidad del
mismo Pero el testing no solo se basa en la realizacioacuten de pruebas
Se deben identificar otras tareas que estaacuten relacionadas con el testing las cuales se llevan a cabo antes y despueacutes
de la ejecucioacuten de pruebas Estas tareas estaacuten relacionadas principalmente con la planificacioacuten y control del
proceso de pruebas el disentildeo de los diferentes casos de prueba o test cases y la posterior comprobacioacuten de los
resultados obtenidos tras llevar a cabo las pruebas Otras tareas podriacutean ser la propia evaluacioacuten de los diferentes
criterios de finalizacioacuten del proceso de pruebas el anaacutelisis de informes de resultados o la revisioacuten de la
documentacioacuten generada en la fase de pruebas
A continuacioacuten se citan algunas definiciones para explicar el concepto de pruebas de software
ldquoUna prueba es una actividad ejecutada para evaluar la calidad del producto software y mejorarlo mediante
la identificacioacuten de problemas errores o defectos en su funcionamiento [9]rdquo
ldquoLas pruebas de Software consisten en verificaciones dinaacutemicas del comportamiento del software bajo
pruebas mediante un conjunto finito de casos de prueba seleccionadas adecuadamente sobre un dominio
infinito de casos posibles [1]rdquo
Atendiendo a las definiciones presentadas las pruebas de software son dinaacutemicas porque se puede ejecutar el
software bajo pruebas con un conjunto de valores de entrada especiacuteficos para encontrar fallos en su
comportamiento Por otro lado la realizacioacuten de pruebas exhaustivas no es posible para la mayoriacutea de los
productos software reales debido a la gran cantidad de entradas posibles para cada operacioacuten entradas invaacutelidas
o no esperadas y las infinitas secuencias de operaciones posibles
Por estas razones para aplicar un proceso de pruebas de software razonable en cuanto a recursos y tiempo de un
proyecto es necesario seleccionar un conjunto abarcable de pruebas Debido a esto la clave estaacute en el criterio
de seleccioacuten de dichas pruebas Una vez ejecutadas las pruebas seleccionadas se debe decidir si el
comportamiento esperado del sistema falla o no Este es el llamado problema del oraacuteculo el cual es resuelto en
la mayoriacutea de los casos de forma manual mediante la inspeccioacuten de los resultados de la prueba
T
La tecnologiacutea no es nada Lo importante es que tengas feacute
en la gente que sean baacutesicamente buenas e inteligentes
y si les das herramientas haraacuten cosas maravillosas con
ellas
Steve Jobs
47
32 Principios de las Pruebas de Software
Una vez presentada la definicioacuten de pruebas de Software se han obtenido algunos detalles que encajan
perfectamente con una serie de principios que han sido establecidos para el testing de productos software seguacuten
ISTQB (International Software Testing Qualifications Board) [10]
Figura 15 Principios de las Pruebas de Software
1 Las pruebas demuestran la presencia de defectos no su ausencia Las pruebas pueden mostrar que
los defectos estaacuten presentes en el producto pero no pueden probar que no haya defectos Por tanto las
pruebas pueden reducir la probabilidad de existencia de defectos en el software pero incluso si no se
encuentran defectos las pruebas no son una garantiacutea total para afirmar la ausencia de defectos en el
producto final
2 Las pruebas exhaustivas son imposibles Probar todas las posibles combinaciones de entradas y
condiciones previas sobre una aplicacioacuten no es factible excepto en casos muy triviales En lugar de
intentar realizar pruebas exhaustivas se debe usar el anaacutelisis de riesgos las teacutecnicas de prueba y las
prioridades ademaacutes de la automatizacioacuten para enfocar los esfuerzos en la fase de pruebas
3 Las pruebas tempranas ahorran tiempo y dinero Para una deteccioacuten temprana de errores y defectos
las actividades de pruebas deben iniciarse lo antes posible en el ciclo de vida del desarrollo del software
De esta forma se consigue una reduccioacuten de costes ya que cuanto maacutes tarde se detecte un defecto maacutes
costoso y difiacutecil seraacute corregirlo
4 Los defectos se agrupan Generalmente una pequentildea parte del software desarrollado concentra la
mayor complejidad del mismo por lo que la mayoriacutea de los defectos detectados tienen una mayor
probabilidad de encontrarse en esos elementos maacutes complejos Por tanto la realizacioacuten de un buen
anaacutelisis de riesgos permite enfocar el esfuerzo de pruebas en las aacutereas del producto con mayor
probabilidad de presentar defectos
Aplicando el Principio de Pareto al control de calidad [11] el 80 de los errores y defectos estaacute causado
por un 20 del total del producto software desarrollado lo cual podriacutea ser un buen principio sobre el
que basar el anaacutelisis de riesgos
5 Cuidado con la paradoja del pesticida Si las mismas pruebas se repiten una y otra vez con el tiempo
los mismos casos de pruebas ya no encontraraacuten nuevos defectos lo cual no quiere decir que la aplicacioacuten
presente una ausencia completa de los mismos (Las pruebas ya no son eficaces para detectar defectos
al igual que los pesticidas ya no son eficaces para matar insectos despueacutes de un tiempo) Para detectar
nuevos defectos es necesario que las pruebas existentes y los datos de las pruebas deban cambiar
ademaacutes de surgir la necesidad de disentildear nuevas pruebas
48
6 Las pruebas dependen del contexto Cada empresa organizacioacuten o proyecto adaptaraacute el proceso de
pruebas a sus necesidades recursos disponibles o aacutereas de riesgo existentes
7 La ausencia de errores es una falacia Un producto software puede tener un 100 de casos de eacutexito
en su fase de pruebas pero esto solo indica que hay defectos que auacuten no han sido localizados e
identificados
33 Proceso de Pruebas de Software Anaacutelisis disentildeo e implementacioacuten
Partiendo de los principios detallados en la seccioacuten anterior se presentan las diferentes etapas del proceso de
pruebas de software asiacute como la documentacioacuten generada en cada etapa
331 Terminologiacutea
Previamente se presentaraacuten algunos teacuterminos y definiciones que convienen describir para una mejor
comprensioacuten de todo el proceso de pruebas [3]
Figura 16 Terminologiacutea para el proceso de pruebas
1 Condicioacuten de prueba Elemento o evento de un componente o sistema que puede ser verificado por
uno o maacutes casos de prueba Los diferentes requisitos que definen la funcionalidad de un sistema pueden
ser descompuestos en diferentes condiciones de prueba
2 Caso de prueba conjunto de valores de entrada precondiciones de ejecucioacuten y valores esperados
Estos son desarrollados para perseguir un objetivo particular por ejemplo una condicioacuten de prueba
3 Precondicioacuten Condiciones de entorno y estado que deben ser satisfechas antes de que un componente
o sistema pueda ser sometido a un caso de prueba o conjunto de estos
4 Abstraccioacuten de casos de prueba Consiste en la generalizacioacuten de los casos de prueba especiacuteficos sin
valores concretos para sus entradas condiciones de prueba o valores esperados En resumen no es maacutes
que llevar las condiciones de prueba a un caso general para cualquier valor de entrada
5 Script de pruebas Una vez disentildeados los casos de prueba estos pueden ser implementados y
ejecutados por una herramienta de automatizacioacuten Un script de pruebas puede contener varios casos
de prueba
6 Paquete de pruebas Consiste en la agrupacioacuten de casos de prueba relacionados en cuanto a la
funcionalidad que automatizan sobre el sistema
7 Programacioacuten de la ejecucioacuten de pruebas Describen el flujo de ejecucioacuten de los diferentes paquetes
de pruebas
49
332 Proceso de Pruebas de Software
No existe un proceso de pruebas universal pero existen conjuntos comunes de actividades de prueba sin las
cuales las pruebas disentildeadas e implementadas tendriacutean menos probabilidad de alcanzar sus objetivos
establecidos Estos conjuntos de actividades de prueba constituyen un proceso de pruebas
Como se ha mencionado en secciones anteriores el proceso de pruebas se debe iniciar en las fases maacutes iniciales
del ciclo de vida de un proyecto Por tanto las actividades del proceso de pruebas la manera en que se
implementan dichas actividades y cuaacutendo ocurren pueden ser discutidas en la estrategia de pruebas de una
organizacioacuten
A continuacioacuten se exponen las etapas fundamentales del proceso de pruebas detallando en cada una de ellas la
documentacioacuten generada y coacutemo contribuyen a la mejora de la calidad del producto con su aplicacioacuten en el ciclo
de vida de un proyecto [13]
Figura 17 Proceso de Pruebas de Software
3321 Planificacioacuten y Control de Pruebas
La planificacioacuten consiste en determinar los diferentes objetivos de las pruebas realizadas sobre el Sistema bajo
test las especificaciones y los recursos que se necesitaraacuten para llevar a cabo la fase de pruebas y cumplir con los
objetivos planteados
Es en este punto donde se define el alcance de las pruebas a realizar de forma que se selecciona lo que seraacute y
no seraacute testeado ademaacutes de indicar quieacuten haraacute cada prueba y como la llevaraacute a cabo Mediante los objetivos de
las pruebas se puede establecer un punto de finalizacioacuten del proceso
Como salida de la actividad de planificacioacuten se obtendriacutea el ldquoPlan de Pruebasrdquo el cual documenta la estrategia
y el alcance de las pruebas la prioridad en cuanto a su realizacioacuten y las estimaciones temporales para su
evaluacioacuten ademaacutes de los recursos materiales y humanos para llevarlas a cabo
Es crucial que dicho documento sea validado por el personal correspondiente del proyecto antes de continuar
con las siguientes etapas del proceso de pruebas
Por otro lado el control de pruebas es una actividad desarrollada durante todo el ciclo de vida del proceso de
pruebas el cual permite contrastar el progreso actual con el plan original trazado para la aplicacioacuten de dicho
proceso incluyendo informes y desviaciones
Cuando se produce una desviacioacuten del plan original que introduce cierto riesgo adicional puede hacerse
necesario modificar los objetivos fijados para asegurar la calidad del producto De ahiacute que sea sumamente
importante tener en consideracioacuten la documentacioacuten generada en antiguos proyectos
50
3322 Anaacutelisis y Disentildeo de Pruebas
Una vez planificado el alcance y objetivos de las pruebas se realiza una actividad de anaacutelisis donde se traducen
a condiciones de prueba y posteriormente se disentildean los casos de prueba de alto nivel a partir de la abstraccioacuten
de los casos de prueba
Por otro lado cabe destacar la necesidad de un mecanismo que garantice la trazabilidad con la finalidad de
mantener alineados en todo momento los casos de prueba con los objetivos de la misma incluso contemplando
la posibilidad de que los objetivos puedan cambiar en alguacuten momento del proceso de pruebas
El documento generado en esta actividad es conocido como ldquoespecificaciones de disentildeo de pruebasrdquo
3323 Implementacioacuten y Ejecucioacuten de Pruebas
Dicha etapa consiste en la implementacioacuten de los casos de prueba de alto nivel que cumplen con las
especificaciones de disentildeo de la etapa anterior Es en esta fase donde se haraacute uso de herramientas para la
implementacioacuten y ejecucioacuten de las pruebas
Cabe destacar que para llevar a cabo dicha etapa en cuanto a la verificacioacuten y validacioacuten funcional de un
proyecto es necesario que durante la etapa de desarrollo se haya creado un producto funcional sobre el cual
puedan ejecutarse las pruebas
Durante la ejecucioacuten de las pruebas los resultados obtenidos quedaraacuten documentados en un documento
denominado ldquoRegistro de Pruebasrdquo el cual contiene todas las pruebas realizadas y un ldquoReporte de Incidenterdquo
por cada resultado no esperado que se haya detectado
Una vez sean corregidos los incidentes se debe volver a ejecutar las pruebas con la finalidad de asegurar que
dicho incidente haya sido corregido ademaacutes de asegurar que la correccioacuten realizada no haya introducido otros
defectos o errores Esto es lo que se denomina ldquoPruebas de Regresioacutenrdquo
3324 Evaluacioacuten de los criterios de eacutexito y Elaboracioacuten de reportes e informes
Tras la ejecucioacuten de las pruebas se deben evaluar los criterios de eacutexito los cuales han sido definidos en la etapa
de planificacioacuten
El personal responsable e involucrado en el proyecto se reuniraacute y revisaraacute el cumplimiento de dichos criterios
el registro de pruebas obtenido y los reportes de incidentes que hayan podido ser abiertos en la etapa anterior
Finalmente como resultado de dicha actividad se elabora un ldquoSumario final de Pruebasrdquo
3325 Cierre de la fase de pruebas
Las actividades de cierre de la fase de pruebas se centran mayormente en asegurar que todo el ciclo de vida del
proceso de pruebas se ha cumplido ademaacutes de analizar las posibles mejoras y defectos en las fases llevadas a
cabo
Ademaacutes se lleva a cabo el cierre de los incidentes corregidos y la liberacioacuten de los entornos y recursos asignados
a la fase de pruebas
51
34 Clasificacioacuten de Pruebas de Software
Existen diversos tipos de pruebas las cuales pueden ser clasificadas en funcioacuten del objetivo de prueba para lo
cual hayan sido establecidos Cada tipo de prueba persigue unos objetivos especiacuteficos sobre el producto pero
todas ellas persiguen como objetivo comuacuten ofrecer un producto con garantiacutea de calidad al cliente o usuario final
Dichas pruebas pueden ser clasificadas en cuatro tipos
Figura 18 Clasificacioacuten de Pruebas de Software
341 Pruebas Funcionales
Tambieacuten conocidas como ldquoPruebas de caja Negrardquo En [14] la IEEE define este tipo de pruebas como
ldquoPruebas que ignoran los mecanismos internos de un sistema o componente y se enfocan
solamente en las salidas generadas como respuesta a las entradas seleccionadas y a las
condiciones de ejecucioacutenrdquo
Figura 19 Pruebas de Caja Negra
Atendiendo a la definicioacuten anterior el sistema o componente sujeto a pruebas debe realizar una funcioacuten
determinada Estaraacute descrita en las especificaciones funcionales y se pueden llevar a cabo a cualquier nivel
Dichas especificaciones funcionales describen el comportamiento del sistema sin revelar informacioacuten acerca de
su implementacioacuten interna
Un tipo especial de prueba funcional son las ldquoPruebas de Humordquo o ldquoSmoke Testsrdquo Este tipo de pruebas suele
realizarse en fases tardiacuteas del desarrollo y permiten asegurar que las funcionalidades baacutesicas del software
responden adecuadamente
Por tanto dichas pruebas pueden quedar lejos de ser pruebas exhaustivas aunque siacute permiten asegurar que el
producto entregado al cliente cumple con los requisitos de funcionamiento establecidos Este tipo de pruebas
son las que se han implementado y automatizado en el proyecto presente lo cual se detallaraacute en capiacutetulos
posteriores
52
342 Pruebas No Funcionales
Este tipo de pruebas estaacuten orientadas a verificar coacutemo de bien funciona el sistema bajo pruebas en lugar de la
funcionalidad que ofrece Por ello pueden ser agrupadas tambieacuten dentro de la categoriacutea de pruebas de caja negra
Atendiendo al estaacutendar de evaluacioacuten del producto software ldquoISO 25000rdquo todas las caracteriacutesticas excepto la de
funcionalidad definen caracteriacutesticas de calidad no funcionales de un producto software Estas caracteriacutesticas de
calidad tienen su correspondiente tipo de prueba
3421 Pruebas de Rendimiento
Las pruebas de rendimiento son usadas para determinar la rapidez con la que se realiza una tarea en el sistema
bajo unas condiciones particulares de trabajo Estas pruebas tambieacuten pueden ser usadas para validar y verificar
otros atributos de calidad del sistema tales como la escalabilidad fiabilidad y uso de recursos
Figura 20 Pruebas de Rendimiento
3422 Pruebas de Carga
Este tipo de pruebas miden el rendimiento del sistema con una carga de trabajo manejable y conocida Se trata
de someter al sistema a cargas de trabajo controladas por el ingeniero de pruebas para validar prestaciones de
rendimiento sobre el sistema
Figura 21 Pruebas de Carga
3423 Pruebas de Estreacutes
Las pruebas de estreacutes ponen a prueba la robustez y confiabilidad del sistema sometieacutendolo a condiciones de uso
extremas Entre estas condiciones se incluyen el enviacuteo masivo de peticiones y la ejecucioacuten en condiciones de
hardware limitadas Dichas condiciones van maacutes allaacute de los liacutemites de operacioacuten considerados en el disentildeo
Figura 22 Pruebas de Estreacutes
53
3424 Pruebas de Usabilidad
Estas pruebas se centran en encontrar problemas de la interfaz de usuario que podriacutean hacer que el software sea
difiacutecil de utilizar o podriacutean causar que los usuarios mal interpreten las salidas Por tanto permiten medir coacutemo
de atractivo resulta un producto software basaacutendose en la facilidad de adaptacioacuten y uso por parte de los clientes
Figura 23 Pruebas de Usabilidad
3425 Pruebas de Fiabilidad
Prueban el rendimiento del sistema ante un determinado nuacutemero de operaciones o tras cierto periodo de
tiempo
3426 Pruebas de Instalacioacuten
Las pruebas de instalacioacuten tienen dos propoacutesitos El primero es asegurar que el sistema puede ser instalado
en todas las configuraciones posibles tales como nuevas instalaciones actualizaciones instalaciones
completas o personalizadas y bajo condiciones normales o anormales estas uacuteltimas incluyen insuficiente
espacio en disco falta de privilegios para algunas tareas etc
El segundo propoacutesito es verificar que una vez instalado el sistema opera correctamente Esto usualmente
implica ejecutar un nuacutemero significativo de pruebas de Funcionalidad
Por tanto miden coacutemo de sencillo resulta instalar la aplicacioacuten en distintas plataformas o entornos
3427 Pruebas de Portabilidad
Miden coacutemo de sencillo resulta migrar una aplicacioacuten de una plataforma a otra
Figura 24 Pruebas de Portabilidad
54
343 Pruebas Estructurales
Este tipo de pruebas son tambieacuten conocidas como ldquoPruebas de Caja Blancardquo En [14] la IEEE define este tipo
de pruebas como
ldquoPruebas que tienen en cuenta los mecanismos internos de un sistema o componenterdquo
Figura 25 Pruebas de Caja Blanca
Atendiendo a dicha definicioacuten estas pruebas tienen en cuenta la estructura del coacutedigo fuente del software a partir
del cual se seleccionan los diferentes casos de prueba guiaacutendose por la existencia de sentencias condicionales
bucles etc
Por tanto los casos de prueba son desarrollados usando criterios de cobertura para el coacutedigo del programa De
esta forma el sistema bajo pruebas se trata como una caja de cristal que permite ver su estructura
El criterio de cobertura hace referencia a cada miacutenima unidad de coacutedigo que puede ser probada de forma
independiente Es frecuente usar este tipo de pruebas en los niveles de prueba maacutes bajos como por ejemplo en
las ldquoPruebas Unitariasrdquo o las ldquoPruebas de Componenterdquo
344 Pruebas debidas a Cambios
Finalmente en el proceso de pruebas tras ejecutar las pruebas y encontrar un defecto o error en el sistema bajo
pruebas este se corrige pero es necesario validar la correccioacuten realizada para confirmar que el fallo no se
reproduce A este proceso se le denomina ldquoPrueba de confirmacioacuten o re-testingrdquo
Ademaacutes las correcciones pueden ser validadas pero tambieacuten es necesario asegurar que los cambios introducidos
para corregir dicho fallo no han provocado maacutes defectos Por tanto puede concluirse que es necesario volver a
realizar pruebas sobre el resto del sistema Estas son las ldquoPruebas de Regresioacutenrdquo
35 Niveles de Prueba
El proceso de pruebas es una etapa del ciclo de vida de un proyecto cuyas actividades estaacuten completamente
relacionadas con las actividades del proceso de desarrollo Existen diversos modelos que describen las fases y
actividades del proceso de desarrollo de software En esta seccioacuten se detallaraacute el uso del ldquoModelo de desarrollo
en Vrdquo
Este modelo describe las diferentes fases del proceso de desarrollo y sugiere la realizacioacuten de pruebas en cada
una de ellas Estas pruebas seraacuten ejecutadas posteriormente en orden ascendente Por tanto para cada fase existen
unos objetivos a cumplir los cuales deben ser probados para medir la integridad del trabajo realizado
55
A continuacioacuten se detallaraacuten los diferentes niveles de prueba para cada etapa del desarrollo software atendiendo
al modelo de desarrollo en V
Figura 26 Modelo de desarrollo en V
351 Pruebas a Nivel de Componente
Tambieacuten llamadas ldquoPruebas Unitariasrdquo El objetivo de estas pruebas es el de cubrir la unidad miacutenima funcional
que compone el software Estos componentes suelen tener una uacutenica funcioacuten especiacutefica la cual seraacute usada por
el resto del Sistema A menudo son realizadas por los propios desarrolladores haciendo uso de la metodologiacutea
de desarrollo guiado por prueba o Test-Driven-Development (TDD)
352 Pruebas a Nivel de Integracioacuten
Son aquellas pruebas realizadas en el aacutembito del desarrollo software una vez validadas las pruebas unitarias
Estas pruebas verifican que todos los elementos unitarios que componen el software funcionan en conjunto de
forma correcta Se centran principalmente en probar la comunicacioacuten entre los diferentes componentes del
sistema
353 Pruebas a Nivel de Aceptacioacuten
Este uacuteltimo nivel se centra en las necesidades del usuario requisitos y procesos de negocio con el fin de
determinar si el sistema satisface los criterios de aceptacioacuten acordados con el cliente en un contrato o acuerdo
de nivel de servicio en caso de ser un software de uso interno dentro de una compantildeiacutea
Ejemplos de este tipo de pruebas pueden ser las ldquoPruebas Alfa y Betardquo
Como se ha detallado anteriormente las pruebas desarrolladas y automatizadas en este Proyecto son ldquoPruebas
de humordquo o Smoke Tests Estas pruebas se centran en la verificacioacuten y validacioacuten de las especificaciones de uso
de un Sistema en este caso de la plataforma Web de gestioacuten Galgus CHT Manager
56
36 Dificultades de pruebas en aplicaciones Web e impacto
La complejidad antildeadida de las aplicaciones y servicios Web frente a otros tipos de aplicaciones recae sobre el
uso de muacuteltiples tecnologiacuteas de vanguardia que permiten la construccioacuten de sistemas distribuidos con un amplio
grado de escalabilidad accesibilidad disponibilidad interoperabilidad e independencia del hardware
Como consecuencia del incremento de la complejidad de las aplicaciones surgen nuevos paradigmas como la
Arquitectura Orientada a Servicios (SOA) la cual permite interoperabilidad y flexibilidad de las aplicaciones
distribuidas
Todo ello conlleva a plantearse queacute se deberiacutea hacer para garantizar que una aplicacioacuten Web puesta en marcha
funciona de acuerdo a los requisitos definidos y acordados con el cliente Podriacutean optimizarse y mejorarse los
diferentes procesos dentro del ciclo de vida de un proyecto pero siempre la fase de pruebas termina siendo la
fase previa a la puesta en marcha de la aplicacioacuten con lo que resulta siendo la uacuteltima oportunidad para detectar
posibles fallos que puedan terminar en ocasiones en peacuterdidas econoacutemicas de prestigio de fiabilidad y de
credibilidad por parte de los clientes
Realizar pruebas en una aplicacioacuten Web no es tarea faacutecil ya que son muchos los factores que influyen en el
testeo del sistema para abarcar y contemplar el maacuteximo de flujos posibles que se pueden llevar a cabo durante
el uso de la aplicacioacuten
Hoy en diacutea las aplicaciones Web pueden ser construidas con componentes implementados en diferentes
lenguajes y arquitecturas basaacutendose en diferentes modelos de programacioacuten y pudiendo ejecutarse en diferentes
plataformas de hardware y software
Esto incrementa la complejidad de las pruebas a realizar sobre un sistema de este tipo por lo que seriacutea interesante
plantearse la posibilidad de usar herramientas que permitan una abstraccioacuten de dicha complejidad ademaacutes de la
automatizacioacuten de la fase de pruebas En el caso de las pruebas a nivel de aceptacioacuten en este proyecto se
propondraacute el uso de herramientas que persiguen dichos fines
Figura 27 Dificultades de pruebas en aplicaciones Web e impacto
57
58
4 SISTEMA GALGUS CHT CLOUD MANAGER
ras realizar un estudio del arte sobre una teacutecnica que puede ser de gran utilidad para optimizar y
perfeccionar las teacutecnicas de automatizacioacuten para el proceso de pruebas sobre un sistema se han puesto
en contexto los diferentes tipos de pruebas que pueden realizarse sobre un sistema ademaacutes de definir
el proceso de pruebas Una vez llegados a este punto en primer lugar se realizaraacute una descripcioacuten del sistema
bajo pruebas sobre el cual se plantearaacute una solucioacuten para la fase de pruebas y su automatizacioacuten Maacutes
concretamente para la realizacioacuten de las pruebas a nivel de aceptacioacuten
41 Arquitectura y Descripcioacuten del Sistema
CHT Cloud Manager es un proyecto de la empresa Galgus el cual ofrece una plataforma Web de gestioacuten
configuracioacuten y monitorizacioacuten de redes WiFi Maacutes concretamente dicha plataforma permite gestionar un
conjunto de puntos de acceso desplegados con un conjunto de algoritmos definidos por software los cuales
permiten la optimizacioacuten de los recursos de red inalaacutembricos ofreciendo mayores prestaciones y una mayor
calidad de servicio al usuario Ademaacutes dicho software embebido ofrece otros servicios al cliente como la
localizacioacuten de estaciones dentro de la zona de alcance de la red WiFi o la deteccioacuten de intrusos y ataques de
suplantacioacuten de identidad
A este conjunto de algoritmos se le conoce bajo el nombre Cognitive Hostpot Technology (CHT) Este software
implementado en lenguaje C y preparado para sistemas embebidos como los puntos de acceso presenta una
estructura modular donde cada moacutedulo se encarga de una tarea determinada o de ejecutar un algoritmo
determinado
Figura 28 Logo de Galgus
Para permitir la comunicacioacuten con la plataforma Web CHT implementa un moacutedulo denominado MGR el cual
permite la conexioacuten con un broacuteker de eventos o intermediario para permitir el enviacuteo y la recepcioacuten de eventos
desde dicha plataforma
T
La simplicidad llevada al extremo se convierte en
elegancia
Jon Franklin
59
En la siguiente figura se muestra la arquitectura orientada a servicios para CHT Cloud Manager
Figura 29 Arquitectura de CHT Cloud Manager
Puede observarse que dicha plataforma estaacute formada por diferentes microservicios desplegados en la nube Cada
uno de ellos realiza una serie de tareas bien definidas e interactuacutean entre ellos enviando y recibiendo mensajes
haciendo uso de diferentes protocolos y modelos de comunicacioacuten
De esta forma se consigue mantener actualizado el estado de la informacioacuten de los diferentes elementos en
tiempo real sobre los diferentes eventos que puedan ocurrir en el sistema Dichos eventos proceden en su gran
mayoriacutea del conjunto de puntos de acceso que conforma una red de Galgus la cual pretende ser gestionada desde
la plataforma en cuestioacuten
A continuacioacuten se detallaraacuten los diferentes microservicios que conforman dicha plataforma ademaacutes de describir
a los puntos de acceso con la tecnologiacutea CHT como elementos a gestionar desde dicha plataforma
60
411 Puntos de Acceso (OpenWRT + CHT)
4111 OpenWRT
Los puntos de acceso WiFi de Galgus son sistemas embebidos de diferentes modelos en funcioacuten de las
especificaciones hardware que ofrezcan (nuacutemero de streams espaciales nuacutemero de antenas de exterior de
interior etc)
Todos ellos tienen en comuacuten el uso de OpenWRT como sistema operativo Este se trata de un sistema operativo
open source basado en Linux y usado para sistemas de red embebidos Todos los componentes de dicho sistema
han sido optimizados para dispositivos con limitaciones de hardware y este permite configurarlos mediante
interfaz de liacutenea de comandos o mediante una interfaz Web (LuCI) [15]
Partiendo de dicho sistema operativo Galgus desarrolla CHT como producto software que dota a los puntos de
acceso de una serie de prestaciones en una serie de moacutedulos Dicho producto es ofrecido al cliente mediante
licencias las cuales son gestionadas desde un servidor de licencias y obtenidas por los puntos de acceso de
forma automaacutetica Todo ello se detallaraacute maacutes adelante
4112 CHT
CHT tambieacuten ofrece su propia interfaz de liacutenea de comandos denominada CHT_CLI Esta herramienta permite
configurar los distintos moacutedulos de los que se compone CHT y obtener informacioacuten tanto de la configuracioacuten
como del funcionamiento de los algoritmos CHT
A continuacioacuten se presenta la interfaz y algunos de los comandos que se pueden utilizar
Figura 30 CHT_CLI
CHT_CLI es fundamental tanto en el desarrollo como en el testeo de CHT y CHT Cloud Manager ya que nos
permite acceder a paraacutemetros de configuracioacuten que no estaacuten accesibles desde la interfaz graacutefica LuCI Desde
CHT_CLI se controlan todos los moacutedulos de CHT entre los que se pueden destacar los siguientes Load Balance
(LB) Smart Roaming (SR) Power Control (POWER) Localization (LOC) Traffic Congestion Management
(TCM) Smart Band Steering (SB) y el moacutedulo Manager (MGR)
En este caso es de intereacutes resaltar el moacutedulo que permite la comunicacioacuten con la plataforma de gestioacuten CHT
Cloud Manager Dicho moacutedulo conocido bajo el nombre de MGR implementa un cliente AMQP para
establecer la comunicacioacuten con el broacuteker de eventos usado como intermediario para permitir la comunicacioacuten
entre los puntos de acceso y la plataforma de gestioacuten CHT Cloud Manager
Ademaacutes implementa una serie de estructuras de datos que son enviados a traveacutes de dicho intermediario basadas
en FlatBuffers como plataforma eficiente de serializacioacuten cruzada de datos ofrecida por Google Esta
herramienta permite crear un modelo de datos bajo la sintaxis ofrecida por FlatBuffers para posteriormente
generar dichas estructuras de datos en diferentes lenguajes de programacioacuten como por ejemplo C++ C C
Go Java JavaScript etc
Con esto se consigue generar estructuras de datos con una compatibilidad absoluta que se intercambiaraacuten entre
la plataforma de gestioacuten en lenguaje Java y los puntos de acceso en lenguaje C
61
412 Broacuteker de Eventos AMQP (RabbitMQ)
Este microservicio implementa un broacuteker de eventos que actuacutea como intermediario entre los puntos de acceso
WiFi y algunos microservicios que componen la plataforma Web de gestioacuten Se basa en el protocolo AMQP el
cual sigue el patroacuten publicadorsuscriptor como paradigma de comunicacioacuten indirecta
Estaacute involucrado en la entrega de mensajes entre los diferentes dispositivos embebidos con CHT y sus
respectivos servicios de gestioacuten en la plataforma Web de forma que los agentes que publican y consumen
eventos en el broacuteker no necesitan conocer al destinatario si no que el broacuteker es el que se encarga de publicar los
eventos para los destinatarios suscritos a eacutel En la siguiente figura se muestra la interfaz graacutefica de gestioacuten de
RabbitMQ [16]
Figura 31 Plataforma de Gestioacuten de RabbitMQ
Un broacuteker de eventos es un elemento del patroacuten PublicadorSuscriptor que recibe y mensajes de un conjunto de
elementos de red que quieren comunicarse ejecutan mecanismos de filtrado y permite la entrega correcta de los
diferentes mensajes a los consumidores correspondientes Por tanto el broacuteker de eventos permite ofrecer un
desacoplamiento entre emisores y receptores de la informacioacuten siendo este responsable de las tareas de
encaminamiento y reenvioacute de mensajes En conclusioacuten es responsable de coordinar la comunicacioacuten
proporcionando transparencia de acceso y localizacioacuten permitiendo la localizacioacuten de emisores y receptores
mediante un sistema de identificadores uacutenicos
Figura 32 Patroacuten PublicadorSuscriptor
62
413 Frontend
El Frontend de la plataforma Web estaacute implementado con Angular 6 HTML5 y CSS3 Su finalidad es ofrecer
una interfaz graacutefica al usuario final la cual permite mostrar el estado de los diferentes Zone Managers ademaacutes
de permitir el acceso a estos y gestionar el conjunto de puntos de acceso registrados en ellos de forma raacutepida e
intuitiva
Este microservicio recibe informacioacuten proporcionada por MoMap y los diferentes Zone Managers La
aplicacioacuten se sirve mediante un servidor Apache el cual proporciona una comunicacioacuten fiable con HTTPS
implementando una capa de transporte segura mediante el protocolo TLS
414 Zone Manager
Microservicio responsable de gestionar un conjunto de puntos de acceso CHT los cuales forman un despliegue
de red WiFi de Galgus para un cliente determinado Este microservicio estaacute formado por un servicio Web REST
implementado con Java Spring Framework desplegado en un servidor Jetty embebido y cuya persistencia se ha
implementado a traveacutes de Hybernate con el uso de Postgress SQL como gestor de bases de datos relacional
Un Zone Manager ofrece todas las tareas y acciones necesarias para configurar un conjunto de puntos de acceso
y consultar datos estadiacutesticos de usuarios conectados a dichos puntos de acceso entre otras Cabe destacar en
este punto la importancia que tiene el uso de FlatBuffers para garantizar la compatibilidad de datos enviados y
recibidos entre los puntos de acceso y el Zone Manager ambos implementados en tecnologiacuteas totalmente
diferentes
Figura 33 Ejemplo de Interfaz Graacutefica de un Zone Manager
63
415 MoMap
Dicho microservicio implementado en NodeJS gestiona y administra toda la infraestructura que conforma la
plataforma Web Establece y mantiene todas las conexiones y relaciones entre los diferentes puntos de acceso
con CHT y los Zone Managers (ZMB) que los gestiona
Ademaacutes este microservicio implementa una serie de maacutequinas de estado que permiten controlar el estado de
todos los Zone Managers y puntos de acceso CHT alertando sobre los eventos de error conexioacuten o desconexioacuten
en tiempo real a los usuarios finales a traveacutes del Frontend El soporte a la persistencia para dicho microservicio
se proporciona mediante MongoDB
Por tanto el microservicio MoMap actuacutea como proxy inverso HTTP2 Cuando un usuario intenta acceder a
traveacutes del Frontend de la plataforma Web puede gestionar y administrar un conjunto de Zone Managers o
administrar usuarios y asignar roles y permisos Tambieacuten se permite la creacioacuten eliminacioacuten y conexioacuten con un
Zone Manager redirigiendo las peticiones hacia el mismo
Cuando ocurre un evento de conexioacuten con un Zone Manager desde el microservicio MoMap se recupera y
enviacutea la informacioacuten necesaria para mostrar toda la informacioacuten correspondiente a ese Zone Manager en el
Frontend para el usuario final En la siguiente figura se muestra la interfaz graacutefica ofrecida por el servicio
MoMap a traveacutes del Frontend
Figura 34 Ejemplo de Interfaz Graacutefica de MoMap
64
416 Servidor de Licencias
El objetivo principal de este servicio es proporcionar una aplicacioacuten con una gestioacuten y control centralizado de
las licencias de todos los Puntos de Acceso desplegados con CHT Este servidor desplegado con Jetty de forma
embebida almacena el registro de un conjunto de Puntos de Acceso CHT para un conjunto de Clientes y
proyectos determinados Proporciona una API REST implementada con Java Spring Framework que permite
el registro de dichos dispositivos y la asignacioacuten de licencias CHT para habilitar los diferentes moacutedulos de dicha
aplicacioacuten embebida sobre los Puntos de Acceso Ademaacutes proporciona una interfaz Web de usuario
implementada con Angular 6 HTML5 y CSS3
En la siguiente figura se muestra un ejemplo de dicha interfaz graacutefica
Figura 35 Interfaz Graacutefica del Servidor de Licencias
4161 Zero-Touch Provisioning (ZTP)
En el contexto de la automatizacioacuten de redes WiFi el aprovisionamiento sin contacto es una caracteriacutestica
que permite que los puntos de acceso de una red se configuren automaacuteticamente evitando la intervencioacuten
humana para su configuracioacuten La configuracioacuten manual de dispositivos y conmutadores es costosa y
requiere lo que a menudo puede ser una gran cantidad de tiempo y esfuerzo dependiendo del tamantildeo de la
red [17]
Con el uso de sistemas automaacuteticos de aprovisionamiento y configuracioacuten se consigue reducir la carga de
trabajo y el esfuerzo que normalmente se requiere cuando se instalan y configuran nuevos dispositivos
Figura 36 Zero-Touch Provisioning (ZTP)
65
Haciendo uso de esta caracteriacutestica Galgus implementa en su infraestructura orientada a microservicios
un acceso directo de los Puntos de Acceso al servidor para que soliciten su licencia de CHT
automaacuteticamente de forma que cuando el usuario final vaya a instalar un Punto de Acceso CHT dicho
dispositivo obtendraacute su licencia de forma segura a traveacutes de la API REST del servidor de licencias siempre
y cuando esteacute registrado en el mismo y disponga de licencia sin necesidad de que el usuario intervenga en
dicho proceso
La comunicacioacuten entre los puntos de acceso y el resto de la infraestructura se realiza a traveacutes de un broacuteker
de eventos AMQP con su implementacioacuten en RabbitMQ Debido a esto cuando se crea y asigna licencia
a un dispositivo en el servidor de licencias dicho servidor crea un usuario en RabbitMQ de forma que el
punto de acceso en el momento que obtiene su licencia intentaraacute establecer conexioacuten con el broacuteker para
permitir el intercambio de eventos con los microservicios que lo gestionaraacuten mediante la plataforma CHT
Cloud Manager
Una vez el punto de acceso establece conexioacuten con el broacuteker de eventos este podraacute ser descubierto por el
Zone Manager que lo gestionaraacute El microservicio MoMap se encarga de establecer el descubrimiento de
los puntos de acceso comprobando si el punto de acceso estaacute registrado en el servidor de licencias con
licencia asignada y verificando que el punto de acceso estaacute operativo con conexioacuten a internet
42 Alcance y Objetivos de las pruebas sobre el sistema planteado
Una vez presentada y descrita toda la arquitectura de la plataforma Web ofrecida por Galgus se procederaacute a
detallar los principales objetivos del proceso de pruebas que se pretenderaacute conseguir sobre dicha aplicacioacuten Para
ello inicialmente se presentaraacute en queacute punto se encontraba el proceso de pruebas inicialmente
En este proyecto se ha centrado la atencioacuten en el conjunto de pruebas funcionales realizadas a la aplicacioacuten maacutes
concretamente las pruebas a nivel de aceptacioacuten
Dentro de las pruebas a nivel de aceptacioacuten los ingenieros de prueba hasta ahora habiacutean disentildeado un plan de
pruebas de aceptacioacuten o tests End-to-End los cuales se ejecutaban verificaban y validaban manualmente por
los ingenieros de QA Dicho plan de pruebas estaacute formado por una bateriacutea de casos de prueba a realizar sobre
las diferentes funcionalidades del sistema A continuacioacuten se muestra un fragmento de dicho plan de pruebas
Figura 37 Test Plan de CHT Cloud Manager
Como puede observarse en la figura anterior dicho plan de pruebas contiene un conjunto de casos de prueba
cada uno de ellos con un identificador uacutenico una descripcioacuten algunas especificaciones o detalles necesarios un
indicador de eacutexito o fallo y finalmente la descripcioacuten de los resultados obtenidos
Ademaacutes en dicho test plan se incluye una cabecera y una leyenda para clasificar los distintos resultados
obtenidos en la ejecucioacuten de las pruebas registrar algunos datos de relevancia y tener archivado dicho plan de
pruebas con las versiones de los diferentes microservicios que componen la plataforma Web
66
Figura 38 Leyenda del Test Plan
Figura 39 Control de Versiones del Test Plan
Una vez presentado el estado actual del proceso de pruebas a nivel de aceptacioacuten el nuevo equipo encargado de
evaluar la calidad de la plataforma Web planteoacute la oportunidad de automatizar dicho plan de pruebas Por tanto
el principal objetivo de este proyecto ha sido el de automatizar las actividades de ejecucioacuten y generacioacuten de
reportes de las pruebas de aceptacioacuten automatizadas sobre la aplicacioacuten
Sin embargo las actividades de planificacioacuten disentildeo e implementacioacuten de los diferentes casos de prueba se
realizaraacuten de forma manual haciendo uso de un conjunto de tecnologiacuteas que se usaraacuten para desarrollar la
automatizacioacuten de dichas pruebas Dichas tecnologiacuteas principalmente son Robot Framework Selenium y
Python las cuales se detallaraacuten maacutes adelante
En este punto es donde podriacutea entrar en juego la aplicacioacuten de Model-Based-Testing (MBT) detallado en la
seccioacuten 2 de este proyecto como teacutecnica que permite la abstraccioacuten de la actividad de implementacioacuten del plan
de pruebas mejorando el proceso de pruebas e independizando este de las actividades de desarrollo
En este proyecto queda fuera del alcance la aplicacioacuten de dicha teacutecnica debido a la necesidad de disponer de un
disentildeo completo y detallado de la plataforma Web para permitir la generacioacuten de los casos de prueba abstractos
y su posterior generacioacuten automaacutetica de los casos de prueba ejecutables Es de intereacutes destacar que a lo largo
del desarrollo del proyecto han ido surgiendo otros objetivos de intereacutes para mejorar el proceso de pruebas los
cuales permiten agilizar dicho proceso y ampliar su alcance
Entre estos objetivos se encuentran la generacioacuten automaacutetica de documentacioacuten del plan de pruebas la
implementacioacuten de un entorno de UAT (User Acceptance Testing) con Docker la integracioacuten de las pruebas a
nivel de aceptacioacuten en el proceso de integracioacuten continua del proyecto o la creacioacuten de un Docker que permita
ejecutar todo el plan de pruebas Todos estos objetivos se iraacuten detallando maacutes adelante
67
43 Arquitectura de la Solucioacuten Entorno de UAT para el proceso de pruebas (User Acceptance Test)
Hasta ahora dentro del proceso de desarrollo de la plataforma Web existiacutean las siguientes fases etapas o
entornos Desarrollo Preproduccioacuten y Produccioacuten
Bajo este contexto las actividades del proceso de pruebas eran realizadas sobre la fase de Preproduccioacuten Esto
provocaba una dependencia directa del cierre de la mayoriacutea de actividades de desarrollo para el despliegue en la
fase de Preproduccioacuten Como consecuencia la fase de pruebas a nivel de aceptacioacuten se podriacutea ver perjudicada
por esta metodologiacutea provocando en muchas ocasiones el retraso en el feedback necesario por los ingenieros de
desarrollo de los reportes e informes generados al ejecutar las pruebas de aceptacioacuten Para mejorar este proceso
se ha disentildeado un nuevo entorno de UAT en el proceso de desarrollo que permita disminuir la dependencia del
proceso de pruebas y desarrollo La inclusioacuten de este nuevo entorno ha sido posible gracias a la mejora del
proceso de integracioacuten continuacutea implementado en el desarrollo de la plataforma
Dentro de este proceso de integracioacuten continua se realiza la generacioacuten automaacutetica de los Docker que contienen
los diferentes microservicios de la plataforma Web en cualquier etapa del proceso de desarrollo Ademaacutes dentro
del proceso de integracioacuten continua se ha automatizado por parte de los ingenieros de desarrollo la ejecucioacuten
de pruebas unitarias y de integracioacuten que garantizan una miacutenima garantiacutea de estabilidad funcional de la
plataforma necesaria para el proceso de pruebas Partiendo de este punto el equipo de calidad ha disentildeado un
entorno de UAT con Docker el cual se muestra de forma graacutefica en la siguiente figura
Figura 40 Entorno de UAT con Docker (Anexo B)
68
69
5 TECNOLOGIacuteAS Y HERRAMIENTAS USADAS
na vez descrito el sistema bajo pruebas y presentada la arquitectura de la solucioacuten para el escenario de
pruebas con Docker se expondraacute a continuacioacuten el conjunto de tecnologiacuteas y herramientas usadas para
llevar a cabo el desarrollo de las pruebas automatizadas de aceptacioacuten o pruebas End-to-End Con este
conjunto de herramientas se pretende conseguir la implementacioacuten de los diferentes scripts de pruebas que
automaticen las acciones e interacciones necesarias con la plataforma Web CHT Cloud Manager como si de
una persona se tratase
51 Selenium
Selenium es una herramienta de coacutedigo abierto utilizada para la automatizacioacuten de pruebas en navegadores web
Dicha herramienta posee una enorme popularidad en el mundo de las pruebas de software debido a que
Presenta compatibilidad con diferentes lenguajes de programacioacuten para la implementacioacuten de scripts de
pruebas ofreciendo libreriacuteas en Java Python C PHP Ruby Perl y Net
Es multiplataforma permitiendo el lanzamiento de los scripts de pruebas en diversos sistemas
operativos como Windows Mac o Linux y en diferentes navegadores como Mozilla Firefox Internet
Explorer Google Chrome Safari y Opera
Soporta la integracioacuten con otras herramientas como TestNG o JUnit
Permite la integracioacuten continua con Maven Jenkins gitlab CICD y Docker
Sin embargo presenta una serie de inconvenientes que se deben mencionar
bull Solo permite probar aplicaciones Web
bull No hay soporte garantizado desde Selenium Muchas de las soluciones a problemas de la herramienta
han sido generadas por la comunidad
bull No es posible realizar pruebas en imaacutegenes Para ello es necesaria la integracioacuten con otras herramientas
bull No tiene capacidad nativa para generar informes o reportes de los resultados de las pruebas Para ello
se requiere el uso de un framework como puede ser el Robot Framework
Centrando la atencioacuten en el enfoque de dicho proyecto se haraacute uso de la libreriacutea Selenium para Python y la
facilidad de Robot Framework tanto para abstraer la posible complejidad antildeadida del lenguaje de programacioacuten
usado para la implementacioacuten de los scripts de prueba como para permitir la generacioacuten automaacutetica de informes
y reportes de resultados
Realmente Selenium estaacute formado por un conjunto de herramientas las cuales son Selenium RC Selenium
IDE Selenium Grid y Selenium Webdriver Dichas herramientas permiten desde la realizacioacuten de pruebas en
maacutequinas remotas a la ejecucioacuten de pruebas en diferentes maacutequinas con diferentes navegadores cada una
Con el lanzamiento de Selenium 2 en 2008 se antildeadieron nuevas funcionalidades de Selenium RC y Webdriver
en una misma herramienta aunque es frecuente mantener la nomenclatura de WebDriver a la hora de referirse
a la misma En este proyecto se centraraacute la atencioacuten en la herramienta WebDriver de Selenium
U
El disentildeo es el alma de todo lo creado por el hombre
Steve Jobs
70
52 Selenium WebDriver
Esta herramienta de Selenium ofrece una interfaz para ejecutar los casos de prueba descritos en los scripts
de prueba A traveacutes de esta API WebDriver se comunica directamente con el controlador del navegador
donde corre la aplicacioacuten Para ello seraacute necesario el uso de controladores para los diferentes navegadores
Web desde los que se validan las pruebas automaacuteticas
Todas las implementaciones de WebDriver que se comunican con el navegador usan un protocolo punto a
punto comuacuten Este protocolo define un servicio RESTfull usando JSON sobre HTTP Cada operacioacuten
realizada por WebDriver se mapea en un meacutetodo HTTP que se comunica con el navegador Las respuestas
a dichas operaciones seraacuten devueltas en mensajes HTTP de respuesta
Existen diversas implementaciones de Selenium para diferentes entornos tal y como se muestra en la
siguiente figura
Figura 41 Implementaciones disponibles de Selenium y Navegadores Web Compatibles
Para la ejecucioacuten de las pruebas implementadas en este proyecto se ha hecho uso de los controladores Gecko
Driver y Chromedriver para los navegadores Web Firefox y Google Chrome
521 Elementos del Navegador
Una vez tenemos una viacutea de comunicacioacuten con el navegador planteamos la pregunta iquesty coacutemo le indico al
navegador con queacute componente quiero interactuar
La cantidad de componentes que existen es muy amplia cajas de texto botones imaacutegenes hiperviacutenculos
botones de radio check boxes aacutereas de texto mensajes de error desplegables tablas frames etc Todos
estos elementos tienen una serie de propiedades que pueden ser uacutenicas o no en toda la paacutegina Por ejemplo
un identificador (ID) debe distinguir de manera uniacutevoca a un elemento Este identificador es lo que se
denomina un localizador Existen 8 tipos distintos de localizadores diferentes
bull Id Name Class Name Tag Name Link Text Partial Link Text CSS Xpath
71
Se podraacuten implementar las interacciones con el navegador mediante la llamada a un meacutetodo (accioacuten) que
se aplicaraacute sobre el elemento que nosotros indiquemos A continuacioacuten se muestra el diagrama de bloques
y la implementacioacuten de un ejemplo simple del inicio de sesioacuten usando Python y la libreriacutea de Selenium
Figura 42 Coacutedigo de ejemplo con Python y Selenium
La implementacioacuten anterior permite abrir un navegador Web Chrome en pantalla completa y acceder a la
plataforma Web Galgus CHT Cloud Manager Una vez ha sido posible el acceso y la paacutegina Web estaacute
disponible se realiza el inicio de sesioacuten en la plataforma con las credenciales correspondientes esperando que
dicho inicio de sesioacuten se haya realizado con eacutexito Finalmente se cierran todas las instancias de navegadores
Web abiertas por Selenium en la automatizacioacuten de dicha prueba de concepto
72
53 Robot Framework (RF)
Para la automatizacioacuten del testeo de la aplicacioacuten se ha hecho uso de este framework como herramienta
para dicha finalidad Robot Framework es un framework geneacuterico de automatizacioacuten de pruebas de coacutedigo
abierto desarrolla do por Pekka Klaumlrck en el antildeo 2005
Este framework sigue el enfoque Keyword-Driven Testing y es un candidato idoacuteneo debido a su alto nivel
de abstraccioacuten para pruebas de aceptacioacuten y desarrollo guiado por pruebas de aceptacioacuten o Acceptance
Test-Driven Development (ATDD) Las capacidades de pruebas pueden ser ampliadas con nuevas libreriacuteas
implementadas tanto en Python como en Java y los usuarios pueden crear nuevas keywords a partir de las
existentes usando la misma sintaxis que para los casos de prueba [18]
Robot Framework es independiente del sistema operativo y de la aplicacioacuten El nuacutecleo del framework estaacute
implementado en Python soportando tanto Python 2 como Python 3
Se ha decidido utilizar este framework por la disponibilidad de un amplio conjunto de libreriacuteas de propoacutesito
general y la integracioacuten con libreriacuteas externas como Selenium2Library Entre otras prestaciones permite el
uso de variables que aportan mayor flexibilidad a la hora de disentildear y controlar los scripts de prueba
permite el etiquetado para poder identificar y ejecutar los casos de prueba por separado proporciona una
faacutecil integracioacuten con Jenkins y Maven y proporciona un sistema de reporte de informes de resultados
detallados y de faacutecil lectura Ademaacutes hay que destacar la faacutecil abstraccioacuten que ofrece al poder utlizar
keywords de alto nivel permitiendo el uso del estilo de representacioacuten Given-When-Then para los casos
de prueba A continuacioacuten se describe dicho estilo de representacioacuten
531 Estilo de representacioacuten Given-When-Then
Dicho estilo ofrecido por Robot Framework es uno de los puntos fuertes de este framework Esta caracteriacutestica
permite el uso del siguiente estilo de representacioacuten para los casos de prueba
Figura 43 Estilo de representacioacuten Given-When-Then
bull Given Define las precondiciones necesarias para llevar a cabo la accioacuten asiacute como el actor de la
misma
bull When Accioacuten llevada a cabo por el actor definido en la claacuteusula Given
bull Then Es el comportamiento esperado o la salida del sistema esperada ante una entrada
determinada
bull And Claacuteusula auxiliar que se usa de forma combinada con las anteriores
73
Como ejemplo de aplicacioacuten de este estilo de representacioacuten supongamos que tenemos unos requisitos de
aceptacioacuten establecidos en un documento entre los que se encuentran el inicio y cierre de sesioacuten mediante
usuario y contrasentildea a la plataforma Galgus CHT Cloud Manager En la siguiente tabla se muestran los
criterios de aceptacioacuten definidos en el documento de requisitos para dicha funcionalidad
1 Un usuario no identificado puede iniciar sesioacuten desde la vista principal de la plataforma Web
2 Un usuario no identificado debe insertar un usuario y contrasentildea vaacutelidos para el inicio de sesioacuten
A continuacioacuten se muestra coacutemo se llevariacutea a cabo la implementacioacuten de los scripts de pruebas abstractos
asociados a las especificaciones anteriores haciendo uso del estilo de representacioacuten Given-When-Then
Es complicado implementar todos los casos de prueba posibles principalmente cuando el requisito de
aceptacioacuten requiere de una funcionalidad compleja En este caso se muestran tres casos de prueba
abstractos los cuales han sido implementados en el proyecto para validar el inicio y cierre de sesioacuten
Caso de Prueba 1 Inicio de Sesioacuten en Galgus CHT Cloud Manager
Claacuteusula Keyword
Given Navegacioacuten a la paacutegina principal de Galgus CHT Cloud Manager
When Insertar nombre de usuario vaacutelido
And Insertar contrasentildea vaacutelida
Then Iniciar sesioacuten con eacutexito
Caso de Prueba 2 Intento de Inicio de sesioacuten con usuario no vaacutelido
Claacuteusula Keyword
Given Navegacioacuten a la paacutegina principal de Galgus CHT Cloud Manager
When Insertar nombre de usuario invaacutelido
And Insertar contrasentildea vaacutelida
Then No es posible el inicio de sesioacuten Se muestra mensaje de error
Caso de Prueba 3 Intento de Inicio de sesioacuten con contrasentildea no vaacutelida
Claacuteusula Keyword
Given Navegacioacuten a la paacutegina principal de Galgus CHT Cloud Manager
When Insertar nombre de usuario vaacutelido
And Insertar contrasentildea invaacutelida
Then No es posible el inicio de sesioacuten Se muestra mensaje de error
74
En la siguiente figura se muestra la implementacioacuten de dichas pruebas con Robot Framework donde cada
Keyword implementada permite la abstraccioacuten de toda la funcionalidad necesaria para realizar las pruebas
Figura 44 Implementacioacuten de Pruebas en para el inicio de sesioacuten de CHT Cloud Manager
75
532 Reportes
A continuacioacuten se muestra un ejemplo de los reportes obtenidos tras la ejecucioacuten del primer caso de prueba de
los anteriores donde pueden identificarse las diversas keywords necesarias para implementar cada caso de
prueba asiacute como otras adicionales que ayudan a crear el contexto (precondiciones) Tambieacuten se incluyen
estadiacutesticas sobre el tiempo de ejecucioacuten nuacutemero de tests total nuacutemero de tests que han fallado o que han pasado
con eacutexito [18]
Figura 45 Ejemplo de reporte de pruebas automatizadas con Robot Framework
76
533 Libreriacuteas
Robot Framework permite el uso de Selenium mediante la libreriacutea de pruebas Web SeleniumLibrary Dicha
libreriacutea es compatible con las versiones de Selenium 2536 y sucesivas y con Python 27 y Python 3 Ademaacutes
del inteacuterprete por defecto de Python esta libreriacutea funciona tambieacuten con PyPy y Jython [18]
Esta libreriacutea estaacute compuesta entre otras muchas por una serie de archivos de Python (py) que implementan
las clases que contienen las diversas keywords que pueden ser usadas en nuestro framework La estructura de
estos archivos se presenta en la siguiente tabla
Archivo de Clase Funcioacuten
Alertpy Interacciones con mensajes de alerta
Browsermanagementpy Apertura cierre y cambio de navegadores
Cookiepy Manipulacioacuten de cookies del navegador
Elementpy Interaccioacuten con elementos y sus atributos
Formelementpy Interaccioacuten con elementos en formularios
Framespy Manejo de frames y su contenido
Javascriptpy Facilidades para inyectar coacutedigo javascript
Runonfailurepy Uso de funcionalidades en caso de fallo
Screenshotpy Manejo de capturas de pantalla
Selectelementpy Manejo de elementos en listas
Tableelementpy Manejo de elementos en tablas
Waitingpy Manejo de temporizadores de espera para
transiciones en una paacutegina
Webdrivertoolspy Interaccioacuten directa con el controlador del navegador
Windowpy Manejo de ventanas del navegador
Estas libreriacuteas fueron desarrolladas en sus oriacutegenes por el ingeniero finlandeacutes Tatu Aalto y posteriormente
mejoradas por toda la comunidad de expertos en automatizacioacuten de pruebas Sin embargo Robot Framework
mediante el uso de Python con Selenium permite la implementacioacuten de libreriacuteas propias o funcionalidades
desarrolladas en Python que pueden ser integradas en Robot Framework En este proyecto se hace uso de Python
con Selenium para desarrollar algunas funcionalidades avanzadas que permiten probar ciertos criterios de la
aplicacioacuten muy especiacuteficos y avanzados de la plataforma Web para los cuales las libreriacuteas ofrecidas por Robot
Framework no proporcionan la funcionalidad requerida
Ademaacutes se ha hecho uso de otras libreriacuteas como BuiltIn para el uso de bucles condicionales y otras keywords
String y Collections para el tratamiento de cadenas de caracteres y colecciones de datos SSHLibrary para usar
un cliente ssh Process para la ejecucioacuten de subprocesos haciendo uso la libreriacutea subprocess de python y
OperatingSystem para realizar algunas tareas sobre el sistema operativo
77
534 Documentacioacuten
La documentacioacuten de los diferentes casos de pruebas implementados con Robot Framework es muy redundante
y una tarea la cual seriacutea deseable de poder automatizar Dicho framework ofrece esta posibilidad a traveacutes de dos
herramientas para crear documentacioacuten basada en las pruebas y libreriacuteas implementadas para dichas pruebas
Libdoc y Testdoc [18]
5341 Libdoc
Libdoc es una herramienta ofrecida por Robot Framework para construir documentacioacuten sobre las keywords
implementadas para los casos de prueba Dicha documentacioacuten es generada en formato HTML y XML
Se puede crear documentacioacuten para bibliotecas implementadas con Python o Java y para las propias libreriacuteas
implementadas con Robot Framework A continuacioacuten se muestra un ejemplo de la documentacioacuten generada
para la libreriacutea implementada para los casos de prueba de inicio y cierre de sesioacuten de Galgus CHT Cloud
Manager
Figura 46 Ejemplo de documentacioacuten generada con Libdoc
5342 Testdoc
Testdoc es una herramienta para generar documentacioacuten de alto nivel basada en los casos de prueba de Robot
Framework Dicha documentacioacuten es generada en formato HTML e incluye el nombre la documentacioacuten y
otros metadatos de cada conjunto de pruebas y casos de prueba asiacute como las keywords de alto nivel y sus
argumentos
A continuacioacuten se muestra un ejemplo de la documentacioacuten generada para el conjunto de casos de prueba que
validan el inicio y cierre de sesioacuten de Galgus CHT Cloud Manager
Figura 47 Ejemplo de documentacioacuten generada con Testdoc
78
54 Pycharm (IDE)
Esta herramienta proporciona un entorno de desarrollo integrado (IDE) el cual ha sido usado para programar en
lenguaje Python por lo que es idoacuteneo tambieacuten para el desarrollo de pruebas con Robot Framework Esta
desarrollado por la empresa JetBrains Ademaacutes proporciona entre otras muchas herramientas el anaacutelisis de
coacutedigo un depurador graacutefico integracioacuten con sistemas de control de versiones y es multiplataforma
55 GitGitlab
551 Git
Git es un software de control de versiones disentildeado por Linux Torvalds pensando en la eficiencia y la
confiabilidad del mantenimiento de versiones de aplicaciones cuando eacutestas tienen un gran nuacutemero de archivos
de coacutedigo fuente Al principio Git se pensoacute como un motor de bajo nivel sobre el cual otros pudieran escribir la
interfaz de usuario como Cogito o StGIT Sin embargo Git se ha convertido desde entonces en un sistema de
control de versiones con funcionalidad plena Hay algunos proyectos de mucha relevancia que ya usan Git en
particular el grupo de programacioacuten del nuacutecleo Linux Ademaacutes cabe destacar que se ha hecho uso de
GitKraken como interfaz graacutefica de git para llevar a cabo el control de versiones de una forma maacutes intuitiva
552 Gitlab
Gitlab es un servicio Web de control de versiones y desarrollo de software colaborativo basado en Git Fue
implementado por los desarrolladores ucranianos Dimitry Zaporozhets y Valey Sizov en el lenguaje de
programacioacuten Ruby Este proyecto cuenta con un equipo de 150 miembros y maacutes de 1400 usuarios y es usado
por empresas como la NASA el CERN IBM o Sony [19]
Ademaacutes de gestor de repositorios tambieacuten ofrece la posibilidad de alojar documentacioacuten y un sistema de
seguimiento de errores Tambieacuten es de gran importancia destacar que esta herramienta proporciona su propia
herramienta de Integracioacuten Continua sin necesidad de usar otra herramienta externa
Se ha hecho uso de estas herramientas para tener un control de versiones sobre nuestro proyecto y una gestioacuten
centralizada de todos los repositorios de la empresa de forma que asiacute podemos tener un control de versiones de
todos los cambios realizados en el coacutedigo con posibilidad de contrastarlos con versiones anteriores y recuperar
dichos cambios Ademaacutes se hace uso tambieacuten de gitlab CICD para implementar procesos de Integracioacuten
continua sobre los diferentes proyectos En el caso particular de este proyecto para generar la documentacioacuten
de los casos de test y libreriacuteas y para generar un Docker con toda la bateriacutea de pruebas y dependencias necesarias
para lanzarlas
56 Redmine
Redmine es una herramienta para la gestioacuten de proyectos que ofrece un conjunto de funcionalidades que
permiten a los usuarios de diferentes proyectos realizar el seguimiento y organizacioacuten de los mismos Incluye
un sistema de seguimiento de incidentes Otras herramientas que incluye son un calendario de actividades
diagramas de Gantt una wiki para almacenar documentacioacuten control del flujo de trabajo basado en roles
integracioacuten con correo electroacutenico etc
Esta herramienta se usa para la gestioacuten del proyecto Galgus CHT Cloud Manager donde se integra como
subproyecto la automatizacioacuten del proceso de pruebas para la plataforma Web desarrollada
A continuacioacuten se muestra un ejemplo del flujo de trabajo implantado en la metodologiacutea de trabajo dentro del
proyecto donde cada historia puede contener un conjunto de tareas las cuales pueden pasar por diferentes
estados hasta ser completadas por el desarrollador o el ingeniero de pruebas
79
Figura 48 Ejemplo de Flujo de Trabajo en Redmine para Galgus CHT Cloud Manager
561 Uso en el Proyecto Galgus CHT Cloud Manager (Metodologiacutea Scrum)
Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas praacutecticas para trabajar
colaborativamente en equipo y obtener el mejor resultado posible de un proyecto Estas praacutecticas se apoyan
unas a otras y su seleccioacuten tiene origen en un estudio de la manera de trabajar de equipos altamente productivos
Esta metodologiacutea divide el trabajo en una lista de pequentildeas funcionalidades ordenadas por prioridad y estimadas
en esfuerzo Estas pequentildeas tareas son abordadas en iteraciones cortas de longitud fija denominadas Sprints de
1 a 4 semanas (en este caso se ha optado por iteraciones de 3 o 4 semanas) obteniendo coacutedigo potencialmente
entregable siendo demostrado al final de cada iteracioacuten Una vez decidido por el equipo de gestioacuten de proyectos
el alcance y conjunto de actividades a realizar dentro del sprint se transmite al resto del equipo que forma parte
del proyecto procediendo a la asignacioacuten de tareas mediante Redmine como herramienta de gestioacuten usada
Durante el sprint se va realizando un seguimiento perioacutedico del estado del proyecto y de la situacioacuten de cada
integrante mediante una actividad previa diaria de unos 15 minutos para situar el punto de partida de trabajo
diario que seriacutean reuniones diarias de apenas 15 minutos denominadas ldquoDaylisrdquo
Figura 49 Esquema Graacutefico de Metodologiacutea Scrum
80
La planificacioacuten que se pretende seguir en cada sprint es la siguiente
1 Semana 1 y 2 Realizacioacuten de tareas por parte del equipo de desarrollo incluyendo en estas tareas
nuevos desarrollos modificacioacuten de funcionalidades y verificacioacuten de las mismas mediante pruebas
unitarias y de integracioacuten
2 Semana 3 Realizacioacuten de pruebas de aceptacioacuten manuales por parte del equipo de pruebas y posterior
automatizacioacuten de dichas pruebas Para ello se usaraacute el entorno de UAT como escenario de pruebas
Ademaacutes el equipo de desarrollo iraacute corrigiendo todos aquellos errores o defectos encontrados
3 Semana 4 El jefe de proyecto realiza la fusioacuten de todos los desarrollos y actualiza las versiones en el
entorno de Preproduccioacuten incluyendo todas las actividades realizadas y validadas por el equipo de
desarrollo y de pruebas El equipo de pruebas realizaraacute la ejecucioacuten de todas las pruebas End-to-End
sobre el entorno de Preproduccioacuten para verificar y validar la nueva versioacuten que incluye todas las
funcionalidades Estas pruebas son denominadas pruebas de regresioacuten las cuales verifican que los
nuevos desarrollos no han provocado defectos o errores sobre funcionalidades que hasta ahora habiacutean
funcionado correctamente Finalmente el jefe de proyecto realiza el despliegue en produccioacuten
81
82
6 EXPERIMENTOS
na vez descrito el sistema bajo pruebas el proceso de pruebas y las herramientas que se usaraacuten para
automatizar las pruebas de aceptacioacuten sobre la plataforma de gestioacuten Galgus CHT Cloud Manager
solo queda presentar la forma en la que se ha puesto en praacutectica y el proceso seguido paso a paso
Dado que el objetivo es conseguir una bateriacutea de casos de pruebas End-to-End automatizadas se implementaraacuten
dichos casos de prueba de forma que permitan detectar el incorrecto funcionamiento de cada funcionalidad con
la mayor rapidez posible cubriendo los principales escenarios donde puedan surgir los mayores errores Por
tanto dichos casos de prueba seraacuten elegidos en base al riesgo que puedan introducir
Estos casos de prueba seraacuten definidos mediante un conjunto de criterios de aceptacioacuten descritos a traveacutes de
diagramas de flujo y agrupados seguacuten la funcionalidad de la aplicacioacuten que abarquen las cuales son
1 Vista de Gestioacuten Principal (Coud Tab) Esta seccioacuten de la Web estaacute destinada a la administracioacuten de
usuarios administracioacuten de los diferentes Zone Managers y finalmente incluye un Mapa con la
ubicacioacuten de cada Zone Manager
2 Vista de Configuracioacuten (Configuration Tab) En esta pestantildea se ofrece la gestioacuten de grupos de puntos
de acceso gestioacuten de backups y restauracioacuten gestioacuten de firmwares zonas CHT etc
3 Vista de Red (Network Tab) La pestantildea de red engloba toda la configuracioacuten de red de los puntos de
acceso siendo esta la pestantildea con mayor funcionalidad complejidad y por ello potencial de riesgo de
errores de la plataforma Web
Figura 50 Logo de Galgus CHT Cloud Manager
U
La uacutenica parte donde el ldquoeacutexitordquo aparece antes que el trabajo es en el diccionario
Vidal Sasoon
83
61 Estructura del Proyecto
La clasificacioacuten funcional anterior seraacute tomada de la misma forma para organizar la estructura del proyecto de
pruebas automatizadas con Robot Framework para un desarrollo ordenado y loacutegico de todo el conjunto de casos
de prueba A continuacioacuten se muestra un ejemplo de la estructura del proyecto el cual se encuentra en desarrollo
y continua mejora
Figura 51 Estructura del Proyecto
Para una mayor modularidad y limpieza en el desarrollo de los casos de Test se han centralizado todos los
localizadores en un archivo llamado ldquoSelectorpyrdquo En la siguiente figura se muestra un fragmento de dicho
fichero
Figura 52 Fragmento del fichero ldquoSelectorpyrdquo
A la hora de obtener los localizadores de los elementos que seraacuten comprobados o usados en los scripts de pruebas
se han usado las herramientas de desarrollador que incluye Google Chrome Para ello basta con navegar a la
paacutegina de la plataforma Web en cualquier navegador y pulsar la tecla F12 Esto mostraraacute las herramientas de
desarrolladores donde encontramos una pestantildea llamada ldquoElementosrdquo donde se puede inspeccionar el
documento ldquoHTMLrdquo de la paacutegina Una vez abierta dicha herramienta seraacute sencillo obtener propiedades de los
diversos elementos que nos permitiraacuten hacer referencia a los mismos en nuestro script de pruebas
Los ldquoXpathrdquo absolutos seraacuten lo usados praacutecticamente en toda la Suite de pruebas El beneficio de los
identificadores uacutenicos es que permiten seleccionar elementos sin que sea necesario hacer referencia a su posicioacuten
dentro del documento HTML Esto evita cualquier problema en caso de que las rutas de un elemento dentro del
citado documento cambien debido a mejoras o despistes por parte de los desarrolladores En cambio usar
selectores basados en la ruta del elemento dentro del documento HTML puede propiciar falsos fallos en el
escenario anterior debido a que no puedan encontrarse en la Web a pesar de que realmente sigan estando
presentes y totalmente funcionales
Por otro lado se han agrupado todas aquellas ldquokeywordsrdquo que puedan ser usadas por otras secciones en la
implementacioacuten de los casos de prueba mediante ficheros nombrados como ldquotab_common_keywords robotrdquo
84
Siguiendo esta jerarquiacutea se ha incluido un fichero llamado ldquoCommon_Keywordsrobotrdquo general en el que se
incluyen las principales ldquokeywordsrdquo que pueden ser usadas en todo el proyecto A continuacioacuten se muestra un
fragmento de este fichero
Figura 53 Fragmento del fichero ldquoCommon_Keywordsrobotrdquo
Tambieacuten se incluye el fichero ldquoConfigurationrobotrdquo para agrupar definiciones de variables que seraacuten
usadas en todo el proyecto ademaacutes de realizar la inclusioacuten de las libreriacuteas a usar Se muestra otra figura
con un fragmento del fichero ldquoConfigurationrobotrdquo
Figura 54 Fragmento del fichero de Configuracioacuten de pruebas ldquoConfigurationrobotrdquo
85
A continuacioacuten se muestra un diagrama que muestra las dependencias de los diferentes archivos y la estructura
seguida por el proyecto
Figura 55 Diagrama de paquetes del proyecto de pruebas
Tras introducir la estructura del proyecto y las diferentes funcionalidades de la plataforma Web Galgus CHT
Cloud Manager a continuacioacuten se mostraraacuten algunos criterios de aceptacioacuten de cada funcionalidad a probar
con diagramas de flujo y scripts de pruebas haciendo uso del estilo de representacioacuten Given-When-Then
Ademaacutes se mostraraacuten algunos detalles de implementacioacuten sobre las pruebas Por otro lado la ejecucioacuten de los
casos de prueba de ejemplo y el reporterevisioacuten de resultados se incluiraacute en la seccioacuten de Anexos
Cada una de las siguientes subsecciones dentro de cada funcionalidad principal de la aplicacioacuten o vista principal
tendraacute su correspondiente Suite de pruebas con un conjunto de casos de Test Todas estas Suites seguiraacuten la
siguiente estructura comuacuten para los casos de Test
Figura 56 Estructura de una Suite de Pruebas
86
Todas las Suites comienzan con una seccioacuten de documentacioacuten para describir el contenido de las pruebas de forma geneacuterica y varias secciones para importar los recursos necesarios para las pruebas (Resource)
Las secciones ldquoSuite Setuprdquo y ldquoSuite Teardownrdquo permiten la ejecucioacuten automaacutetica antes y despueacutes de la bateriacutea de pruebas y las secciones ldquoTest Setuprdquo y ldquoTest Teardownrdquo permiten la ejecucioacuten automaacutetica antes y despueacutes de cada caso de prueba
Un uso tiacutepico de ldquoSuite Setuprdquo es abrir un navegador Web y comprobar la disponibilidad de la Web a probar mientras que el cierre del navegador se realiza con ldquoSuite Teardownrdquo De este modo sea cual sea el resultado de la ejecucioacuten no se quedaraacuten abiertas ventanas gastando recursos de la maacutequina
Por otro lado el uso por defecto de ldquoTest Setuprdquo en este proyecto ha sido el inicio de sesioacuten en la Web CHT Cloud Manager mientras que ldquoTest Teardownrdquo ha sido usado para cerrar tambieacuten el navegador Web Sin embargo la mayoriacutea de las pruebas implementadas necesitan una serie de precondiciones previas a la ejecucioacuten del Test y un conjunto de postcondiciones necesarias para no provocar inconsistencias entre la ejecucioacuten de diferentes pruebas Por este motivo se ha hecho uso de las etiquetas [Setup] y [Teardown] para modificar la ejecucioacuten por defecto de ldquoTest Setuprdquo y ldquoTest Teardownrdquo en cada caso de prueba cuando sea necesario
Cabe destacar que la loacutegica implementada dentro de estas claacuteusulas no requiere que sea validada puesto que su uacutenico objetivo es preparar el entorno de pruebas para ejecutar una prueba sin que esta falle por causas ajenas al aacutembito y objetivo de la prueba evitando de esta forma los falsos positivos Por este motivo se hace uso de la Keyword ldquoRun Keyword And Ignore Errorrdquo ofrecida por la libreriacutea ldquoBuiltInrdquo para ignorar los errores en la ejecucioacuten de [Setup] y [Teardown] En la siguiente figura se muestra un ejemplo de dicha teacutecnica
Figura 57 Ejemplo de ldquoTest Setuprdquo personalizado para un caso de prueba
Finalmente la implementacioacuten de las ldquokeywordsrdquo usadas mediante la nomenclatura Given-When-Then seraacuten agrupadas en el correspondiente fichero ldquoTab_common_keywordsrobotrdquo para conseguir una abstraccioacuten de la loacutegica necesaria para la automatizacioacuten de las pruebas En las pruebas seleccionadas para describir en esta seccioacuten se detallaraacute la implementacioacuten de algunas keywords que se usaraacuten
87
62 Vista de Gestioacuten Principal (Cloud Tab)
En la siguiente figura se muestra la vista de Gestioacuten Principal de Galgus CHT Cloud Manager
Figura 58 Vista de Gestioacuten Principal (Cloud Tab)
Sobre esta vista se han automatizado un conjunto de Suites de pruebas que validan toda la funcionalidad
contenida en las pestantildeas MAP List of Zone Managers y Administration ademaacutes de toda la loacutegica ofrecida para
gestionar un conjunto de fabricantes
621 Administration
Comenzando con la pestantildea de administracioacuten se puede observar la existencia de cuatro flujos de navegacioacuten
principales en la siguiente figura
Figura 59 Pestantildea ldquoAdministrationrdquo
Una vez conocida la vista de administracioacuten de la Web se han realizado un total de 22 casos de prueba de los
cuales detallaremos el caso de prueba identificado con la etiqueta U0027
6211 Criterios de Aceptacioacuten
La pestantildea de administracioacuten permite la gestioacuten de los usuarios y roles que tienen acceso a la plataforma Web
ademaacutes de la configuracioacuten de los detalles de los fabricantes seleccionados A continuacioacuten se detallan los
criterios de aceptacioacuten del caso de prueba seleccionado
U0027 Un usuario con permisos de Super Usuario puede editar la informacioacuten de un fabricante
1 Un usuario con permisos de Super Usuario puede ver y acceder a la pestantildea de administracioacuten
2 Un usuario con permisos de Super Usuario puede editar la informacioacuten de un fabricante correctamente
88
6212 Diagramas de Flujo
A continuacioacuten se muestran los diagramas de flujo implementados para los dos casos de prueba analizados
Figura 60 Diagramas de Flujo de Casos de Prueba U0025 y U0027
6213 Script de Pruebas
Una vez establecidos los criterios de aceptacioacuten de ambos casos de prueba se mostraraacuten los scripts de pruebas
realizados
Figura 61 Script de Pruebas U0025
Entre las ldquokeywordsrdquo usadas en el caso de test anterior se puede destacar por ejemplo la implementacioacuten de
ldquoEdit Fieldsrdquo la cual permite editar los campos de un fabricante y verificar que han sido editados tras guardar
los cambios
Figura 62 Keyword ldquoEdit Fieldsrdquo
89
622 List
En la pestantildea de gestioacuten de los diferentes Zone Managers se puede observar una lista de los diferentes Zone
Managers disponibles y se pueden realizar un conjunto de acciones como la creacioacuten de nuevos Zone Managers
y edicioacuten o eliminacioacuten de los existentes entre otras
Figura 63 Pestantildea ldquoList of Zone Managersrdquo
Sobre esta vista se han realizado un total de 7 casos de prueba de los cuales detallaremos el caso de prueba
identificado con la etiqueta U0023 el cual permite validar la creacioacuten y eliminacioacuten de un Zone Manager
6221 Criterios de Aceptacioacuten
A continuacioacuten se detallan los criterios de aceptacioacuten del caso de prueba seleccionado
U0023 Verificar que un Usuario puede Crear y Eliminar un Zone Manager
1 Un usuario con permisos de Super Usuario puede Navegar a la pestantildea List Of Zone Managers
2 El usuario puede crear un Zone Manager correctamente
3 El usuario puede eliminar un Zone Manager correctamente
6222 Diagramas de Flujo
A continuacioacuten se muestra el diagrama de flujo implementado para el caso de prueba analizado
Figura 64 Diagrama de flujo de Caso de Prueba U0023
90
6223 Script de Pruebas
Una vez establecidos los criterios de aceptacioacuten se mostraraacute el script de pruebas realizado a partir del diagrama
de flujo anterior
Figura 65 Script de Prueba U0023
Cabe destacar la implementacioacuten de la Keyword ldquoZone Manager is Registered Successfullyrdquo la cual comprueba
que el Zone Manager registrado pasa a un estado ldquoOnlinerdquo tras un tiempo considerado como aceptable para que
la instancia de dicho Zone Manager este disponible en Cloud CHT Manager
Figura 66 Keyword ldquoZone Manager is registered successfullyrdquo
623 Manufacturer
La vista de gestioacuten principal ofrece una seccioacuten que permite la gestioacuten de los diferentes fabricantes permitiendo
su creacioacuten edicioacuten eliminacioacuten y bloqueo En la siguiente figura se muestra un ejemplo de la seccioacuten de
fabricantes
Figura 67 Seccioacuten de Fabricantes
Para validar el correcto funcionamiento de dicha seccioacuten se han realizado un total de 9 casos de prueba de los
cuales se detallaraacuten los casos de prueba identificados con las etiquetas U0009 Estos permiten validar que los
fabricantes pueden ser creados editados y eliminados correctamente y que todos los fabricantes disponibles son
mostrados correctamente
91
6231 Criterios de Aceptacioacuten
A continuacioacuten se detallan los criterios de aceptacioacuten de los casos de prueba seleccionados
U0009 Verificar que un Usuario con permisos de Super usuario puede ver correctamente todos los
fabricantes existentes
1 Un usuario con permisos de Super Usuario puede Navegar a la pestantildea de Administracioacuten
2 El usuario puede visualizar todos los fabricantes existentes
6232 Diagrama de Flujo
Figura 68 Diagrama de flujo de Caso de Prueba U0009
6233 Script de Pruebas
Una vez establecidos los criterios de aceptacioacuten se mostraraacuten los scripts de pruebas realizados a partir de los
diagramas de flujo anteriores
Figura 69 Script de Prueba U0009
En este punto cabe destacar la finalidad de la Keyword ldquoCorrectly Createrdquo la cual se usa en la mayoriacutea de las
pruebas para verificar que una operacioacuten se ha realizado con eacutexito en la plataforma Galgus CHT Cloud Manager
Esta Keyword verifica que tras realizar alguacuten tipo de operacioacuten en la plataforma Web ocurre un evento sobre la
Web que indica que dicha operacioacuten se ha realizado con eacutexito de la siguiente forma
92
Figura 70 Toast Success
Figura 71 Keyword ldquoCorrectly Createrdquo
Finalmente se muestra la implementacioacuten de las keywords usadas en [Setup] y [Teardown] del caso de prueba
U0009 las cuales preparan el escenario de pruebas creando un conjunto de fabricantes acotado y los elimina
tras la finalizacioacuten de la prueba
Figura 72 Setup amp Teardown de U0008
624 MAP
La plataforma Galgus CHT Cloud Manager ofrece una pestantildea ldquoMAPrdquo que contiene un mapa con la ubicacioacuten
asignada a cada uno de los Zone Managers disponibles por el usuario mostrando en su ubicacioacuten un icono con
el estado de dicho Zone Manager el cual cambia de color seguacuten su estado (offline online unsynchronized)
Figura 73 Mapa de Zone Managers
93
A traveacutes de dicho icono se puede realizar una serie de acciones entre ellas acceder a un Zone Manager
realizando doble click sobre el icono del mismo Sin embargo para automatizar este conjunto de acciones el
equipo de pruebas ha encontrado dificultades haciendo uso de Robot Framework ya que las libreriacuteas disponibles
permiten la interaccioacuten con elementos de la Web pero en este caso los iconos de los diferentes Zone Managers
son renderizados dentro del Mapa con ldquoOpen Street Mapsrdquo antes de ser mostrado en la vista Web de la
aplicacioacuten Por esta razoacuten el mapa es localizado en el DOM como un uacutenico elemento Web lo que imposibilita
localizar a priori el icono de cada Zone Manager dentro del Mapa
Para resolver este impedimento el equipo de pruebas tuvo que analizar con profundidad la libreriacutea de ldquoOpen
Street Maprdquo implementada en Javascript Esta ha sido usada en el Frontend para encontrar alguna funcioacuten que
permitiese obtener desde la consola del navegador Web los piacutexeles en los que cada Zone Manager ha sido
renderizado dentro del Mapa Dicha funcioacuten es ldquogetPixelsFromCoordinate(coordinate)rdquo la cual a traveacutes de las
coordenadas de [Latitud Longitud] de cada Zone Manager se obtienen los piacutexeles del mismo en la pantalla A
traveacutes del siguiente fragmento de coacutedigo en el frontend implementado con Angular 6 en typescript se consigue
obtener los piacutexeles de cada Zone Manager e imprimirlo en la consola del navegador Web
Figura 74 Funcioacuten que dibuja los ZM en el Mapa y obtiene los piacutexeles en pantalla
Para llevar a cabo la implementacioacuten de las pruebas sobre el mapa se ha hecho uso en su gran mayoriacutea de Scripts
con Python Selenium y otras libreriacuteas necesarias en lugar de Robot Framework debido a la necesidad de
realizar varias tareas simultaneas ademaacutes de tratarse de pruebas muy especiacuteficas y personalizadas A
continuacioacuten se muestra la prueba implementada para poder realizar doble click sobre un Zone manager en el
mapa e iniciar sesioacuten en el mismo (U0007)
6241 Criterios de Aceptacioacuten
U0007 Verificar que un Usuario acceder a un Zone Manager desde el Mapa
1 Un usuario con permisos de Super Usuario puede Navegar a la pestantildea MAP
2 El usuario puede hacer doble click en el Zone Manager e iniciar sesioacuten
94
6242 Diagrama de Flujo
Figura 75 Diagrama de Flujo de Caso de Prueba U0007
6243 Script de Pruebas
Para la implementacioacuten de este tipo de casos de prueba se ha hecho uso de la libreriacutea ldquoHtmlTestRunnerrdquo para
obtener un reporte similar al ofrecido por Robot Framework en la ejecucioacuten de la prueba Para obtener un reporte
de la prueba la implementacioacuten de la misma debe seguir una estructura determinada a la que ademaacutes se ha
incluido a traveacutes de la libreriacutea ldquomultiprocessingrdquo la ejecucioacuten simultaacutenea de los dos procesos descritos en el
diagrama de flujo anterior Es necesaria la ejecucioacuten de varios procesos para leer la consola del navegador Web
y obtener los piacutexeles de los Zone Manager para posteriormente hacer doble click
En la Seccioacuten A3 de los anexos puede encontrarse la implementacioacuten del script de pruebas para el caso de
prueba U0007
95
63 Vista de Configuracioacuten (Configuration Tab)
En esta vista se ha automatizado un conjunto de Suites de prueba que validan toda la funcionalidad contenida
en las pestantildeas Groups CHT Zones BackupRestore y Firmware
631 Groups
La pestantildea de grupos permite el descubrimiento de los puntos de acceso a traveacutes de su direccioacuten MAC quedando
estos registrados en base de datos y mostrando al usuario en una tabla los puntos de acceso registrados ademaacutes
del estado de los mismos y otros datos como el modelo o grupo al que pertenecen
Figura 76 Pestantildea ldquoGroupsrdquo
Sobre esta funcionalidad de la plataforma se han realizado un total de 19 casos de prueba de los cuales
detallaremos el caso de prueba identificado con la etiqueta U0119
6311 Criterios de Aceptacioacuten
U0119 Verificar que al descubrir dos puntos de acceso en grupos diferentes ambos son antildeadidos en el
grupo correcto
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Configuracioacuten
3 El usuario puede Navegar a la pestantildea de Grupos
4 El usuario puede descubrir un punto de acceso en el grupo ldquorootrdquo correctamente
5 El usuario puede crear un subgrupo predecesor del grupo ldquorootrdquo correctamente
6 El usuario puede navegar al subgrupo creado correctamente
7 El usuario puede descubrir un punto de acceso en el subgrupo correctamente
96
6312 Diagramas de Flujo
Figura 77 Diagrama de flujo de Caso de Prueba U0119
97
6313 Script de Pruebas
Una vez establecidos los criterios de aceptacioacuten el script de prueba realizado a partir del diagrama de flujo
anterior es el siguiente
Figura 78 Script de Prueba U0119
Entre las keywords implementadas para esta prueba cabe destacar la implementacioacuten de ldquoVerify if AP is
registered Succesfully on grouprdquo la cual permite validar si un punto de acceso ha sido asignado al grupo
correcto
Figura 79 Keyword ldquoVerify if AP is registered Succesfully on grouprdquo
Puede observarse como en primer lugar se obtiene la fila de la tabla que contiene el punto de acceso en cuestioacuten
para posteriormente comprobar si el grupo al que pertenece es el esperado
Observando dicha implementacioacuten cabe destacar el uso de la Keyword ldquoInput Into Text Fieldrdquo la cual ha sido
implementada para vaciar el contenido de campos de texto ya que mediante la Keyword ldquoClear Element Textrdquo
de la libreriacutea Selenium2Library no se conseguiacutea borrar ciertos campos de texto
Figura 80 Keywords Input Into Text Field y Clear Field Of Characters
98
632 CHT Zones
En la pestantildea de gestioacuten de las diferentes Zonas CHT se puede observar una lista de los puntos de acceso
disponibles y se pueden realizar un conjunto de acciones sobre ellos como la creacioacuten eliminacioacuten y asociacioacuten
de zonas CHT
En este punto es conveniente explicar el concepto de zona CHT el cual se refiere a un grupo IP Multicast a
traveacutes del cual un conjunto de Puntos de Acceso establece comunicacioacuten de forma colaborativa Esta
comunicacioacuten es necesaria para el funcionamiento de algunos de los algoritmos que ofrece CHT como por
ejemplo la asignacioacuten automaacutetica de canal (ACA)
Figura 81 Pestantildea ldquoCHT Zonesrdquo
Sobre esta vista se han realizado un total de 6 casos de prueba de los cuales detallaremos el caso de prueba
identificado con la etiqueta U0204 Este caso de prueba permite validar la asignacioacuten de zonas CHT a los Puntos
de Acceso
6321 Criterios de Aceptacioacuten
U0204 Verificar que un usuario puede asignar una Zona CHT a un punto de acceso correctamente
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Configuracioacuten
3 El usuario puede Navegar a la pestantildea de Grupos
4 El usuario puede asignar una Zona CHT existente a un punto de acceso registrado correctamente
99
6322 Diagramas de Flujo
Figura 82 Diagrama de Flujo de Caso de Prueba U0204
6323 Script de Pruebas
Tras presentar los criterios de aceptacioacuten y su correspondiente diagrama de flujo el script de pruebas
implementado para la automatizacioacuten de dicha prueba es el siguiente
Figura 83 Scripts de Prueba U0204
Figura 84 Keyword Add Zone CHT to AP
100
633 BackupRestore
En esta pestantildea se permite la gestioacuten de copias de seguridad y restauracioacuten de los puntos de acceso registrados
en un Zone Manager Se puede observar en esta vista una tabla con los puntos de acceso registrados y otra tabla
con las copias de seguridad realizadas sobre los puntos de acceso
Figura 85 Pestantildea BackupRestore
Partiendo de la representacioacuten funcional de esta vista se han realizado un total de 8 casos de prueba de los
cuales detallaremos el caso de prueba identificado con la etiqueta U0401 el cual permite verificar de forma
automaacutetica la realizacioacuten de un backup sobre un punto de acceso y su posterior restauracioacuten
6331 Criterios de Aceptacioacuten
U0401 Verificar que un usuario puede realizar un BackupRestore correctamente sobre un punto de
acceso previamente registrado
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Configuracioacuten
3 El usuario puede Navegar a la pestantildea de BackupRestore
4 El usuario puede realizar un Backup sobre un punto de acceso existente
5 La tabla de Backups contiene la copia de seguridad realizada
6 El usuario puede restaurar un punto de acceso correctamente
101
6332 Diagramas de Flujo
Figura 86 Diagrama de Flujo de Caso de Prueba U0401
6333 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 87 Script de Prueba U0401
Cabe destacar la implementacioacuten de la Keyword ldquoRestore for AP have done successfullyrdquo la cual verifica que
el punto de acceso ha sido restaurado correctamente esperando que el punto de acceso vuelva a estar en estado
ldquoonlinerdquo durante un tiempo aceptable Si pasado dicho tiempo no recupera dicho estado la prueba se dariacutea por
erroacutenea
Figura 88 Keyword Restore For AP hace done successfully
634 Firmware
Esta uacuteltima pestantildea de la vista principal de configuracioacuten proporciona al usuario la posibilidad de subir los
firmwares de los diferentes modelos de puntos de acceso en sus diferentes versiones del software CHT de forma
que es posible la actualizacioacuten del firmware de los puntos de acceso desde la plataforma Se puede observar en
esta vista una tabla con los puntos de acceso registrados y otra tabla con los firmwares subidos a la plataforma
102
Figura 89 Pestantildea ldquoFirmwarerdquo
Partiendo de la representacioacuten funcional de esta vista se han realizado un total de 7 casos de prueba de los
cuales detallaremos el caso de prueba identificado con la etiqueta U0303 el cual permite verificar de forma
automaacutetica la actualizacioacuten del firmware de un punto de acceso
6341 Criterios de Aceptacioacuten
U0303 Verificar que un usuario puede realizar correctamente la actualizacioacuten del firmware de un punto
de acceso
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Configuracioacuten
3 El usuario puede Navegar a la pestantildea de Firmware
4 El usuario puede subir un firmware correctamente
5 La tabla de Firmwares contiene la imagen de CHT subida a la plataforma
6 El usuario puede realizar la actualizacioacuten del firmware sobre un punto de acceso correctamente
Destacar que el firmware que se desea aplicar sobre un punto de acceso debe ser del modelo correspondiente al
punto de acceso usado ya que cada punto de acceso tiene una imagen de CHT compilada para una arquitectura
hardware determinada Las imaacutegenes son proporcionadas por un servidor interno de la empresa
103
6342 Diagramas de Flujo
Figura 90 Diagrama de Flujo de Caso de Prueba U0303
6343 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 91 Script de Prueba U0303
Cabe destacar la implementacioacuten de la Keyword ldquoFlash APrdquo la cual realiza la actualizacioacuten del firmware de un
punto de acceso verificando que este ha concluido correctamente Para ello espera un tiempo aceptable a que el
punto de acceso vuelva al estado ldquoonlinerdquo
Figura 92 Keyword Flash AP
104
64 Vista de Red (Network Tab)
La uacuteltima vista principal sobre la que se han automatizado pruebas es la vista de Red la cual ofrece al usuario
la gestioacuten y configuracioacuten de su red formada por un conjunto de puntos de acceso previamente registrados
Entre las funcionalidades ofrecidas se encuentran la creacioacuten de VLANS SSIDs Portales Cautivos Perfiles
Radius Activacioacuten de algoritmos CHT y la configuracioacuten de puntos de acceso en tiempo real desde la
plataforma Web
Para describir el proceso de automatizacioacuten se comenzaraacute detallando en primer lugar la creacioacuten de VLANS
Brigdes y SSIDs para posteriormente aplicar dichos paraacutemetros a puntos de acceso desde las pestantildeas ldquoGeneralrdquo
y ldquoAP Networkrdquo Finalmente se mostraraacuten algunos ejemplos sobre otras configuraciones maacutes avanzadas como
la creacioacuten y aplicacioacuten de perfiles radius y portales cautivos ademaacutes de la activacioacuten de algoritmos
641 VLANS amp Bridges
Comenzando con la pestantildea de VLANS amp Bridges se puede observar la existencia de una tabla para cada
elemento de dicha vista
Figura 93 Pestantildea ldquoVLAN amp Bridgesrdquo
Para cada elemento se han automatizado un conjunto de pruebas formado por 6 casos de prueba de los cuales
detallaremos el caso de prueba identificado con la etiqueta U0527 Este caso de prueba permite validar de forma
automaacutetica la creacioacuten y eliminacioacuten de VLANs De forma ideacutentica se procederiacutea para validar la creacioacuten y
eliminacioacuten de Bridges
6411 Criterios de Aceptacioacuten
A continuacioacuten se detallan los criterios de aceptacioacuten del caso de prueba seleccionado
U0527 Verificar que un usuario puede crear y eliminar una VLAN correctamente
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Network
3 El usuario puede Navegar a la pestantildea de VLANS amp Bridges
4 El usuario puede crear una VLAN correctamente
5 El usuario puede eliminar una VLAN correctamente
105
6412 Diagramas de Flujo
Figura 94 Diagrama de Flujo de Caso de Prueba U0527
6413 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 95 Script de Prueba U0527
Cabe destacar la implementacioacuten de la Keyword ldquoGo and Create VLANrdquo la cual permite crear una VLAN en
funcioacuten de los paraacutemetros de entrada deseados para configurar dicha VLAN como por ejemplo el ldquoIDrdquo de la
VLAN y alias o si se desea que dicha VLAN sea de tipo dinaacutemica
Figura 96 Keyword Go And Create VLAN
106
642 SSIDs
Esta pestantildea proporciona una tabla que permite registrar SSIDs con diferentes configuraciones posibles
Figura 97 Pestantildea SSIDs
Para cada funcionalidad de dicha pestantildea se han automatizado un conjunto de pruebas formado por 5 casos de
prueba de los cuales detallaremos el caso de prueba identificado con la etiqueta U0530 Este caso de prueba
permite validar de forma automaacutetica la creacioacuten y eliminacioacuten de SSIDS
6421 Criterios de Aceptacioacuten
A continuacioacuten se detallan los criterios de aceptacioacuten de los dos casos de prueba seleccionados
U0530 Verificar que un usuario puede crear y eliminar una SSID correctamente
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Network
3 El usuario puede Navegar a la pestantildea de SSIDs
4 El usuario puede crear una SSID correctamente
5 El usuario puede eliminar una SSID correctamente
6422 Diagramas de Flujo
Figura 98 Diagrama de Flujo de Caso de Prueba U0530
107
6423 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 99 Script de Prueba U0530
Cabe destacar la implementacioacuten de la Keyword ldquoGo and Create SSIDrdquo la cual permite crear una SSID en
funcioacuten de los paraacutemetros de entradas deseado para configurar dicha SSID como por ejemplo tipo de
encriptacioacuten de la contrasentildea modo oculto o habilitacioacuten de los algoritmos Load Balancing (LB) Smart
roaming (SR) o PRE
Figura 100 Keyword Go And Create SSID
108
643 CHT
Esta funcionalidad permite activar el algoritmo que permite la seleccioacuten automaacutetica de canal entre un conjunto
de puntos de acceso (ACA) Cuando se activa desde la plataforma Web todos los puntos de acceso
pertenecientes a un Zone Manager activan dicho algoritmo el cual se trata de un algoritmo colaborativo
mediante el cual los puntos de acceso acuerdan cual es el mejor canal para la comunicacioacuten WiFi con los clientes
que se conecten tanto en la banda de 24 GHz como en la de 5 GHz En la siguiente figura se muestra la vista
de la plataforma Web para activar el algoritmo en cuestioacuten
Figura 101 Pestantildea ldquoCHTrdquo
Dado que se trata de una funcionalidad en la que solo se debe comprobar si el algoritmo estaacute en el mismo estado
tanto en la plataforma Web como en los puntos de acceso registrados se ha implementado un uacutenico caso de
prueba identificado con la etiqueta U539 Este caso de prueba realiza la conexioacuten a los puntos de acceso para
verificar que dicho algoritmo presenta el mismo estado que en la plataforma
6431 Criterios de Aceptacioacuten
U0537 Verificar que un usuario puede Activar o Desactivar el algoritmo ACA correctamente
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Network
3 El usuario puede Navegar a la pestantildea de CHT
4 El usuario puede ActivarDesactivar el algoritmo ldquoACA ldquocorrectamente
5 Los APs recibieron las oacuterdenes para ActivarDesactivar el algoritmo ldquoACArdquo correctamente
109
6432 Diagramas de Flujo
Figura 102 Diagrama de Flujo de Caso de Prueba U0539
6433 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 103 Script de Prueba U0539
En cuanto a la implementacioacuten de dicho caso de prueba cabe destacar la implementacioacuten de la Keyword ldquoACA
Is Workingrdquo las cual se muestra en la siguiente figura
Figura 104 Keyword ACA Is Working
Puede observarse como en funcioacuten de si el algoritmo ACA esta activado o desactivado en la plataforma Web
(ENABLE DISABLE) se ejecuta la Keyword ldquoChanges On CLIrdquo con diferentes paraacutemetros Esta Keyword
permite la conexioacuten viacutea ldquoSSHrdquo con un punto de acceso para la ejecucioacuten de un comando sobre el mismo y la
posterior comparacioacuten del resultado obtenido por dicho comando con la salida deseada proporcionada tambieacuten
como paraacutemetro de la Keyword
110
En la siguiente figura se muestra la implementacioacuten de dicha Keyword
Figura 105 Keyword Changes On CLI
Para este caso de prueba el comando ejecutado de forma remota sobre el punto de acceso permite obtener de
forma automaacutetica el estado del algoritmo ldquoACArdquo de la siguiente forma
Figura 106 Comando CHT para obtener el estado del moacutedulo ACA en el punto de acceso
644 Radius
Esta pestantildea proporciona una tabla que permite registrar perfiles Radius con diferentes configuraciones posibles
Figura 107 Pestantildea ldquoRadiusrdquo
ldquoRadiusrdquo se define como un protocolo de autenticacioacuten y autorizacioacuten para aplicaciones de acceso a la red o
movilidad IP De esta forma los puntos de acceso mediante la existencia de un servidor radius permiten que los
usuarios que se quieran conectar por WiFi necesiten ser autenticados con credenciales Dicha autenticacioacuten seraacute
redirigida por el punto de acceso al servidor radius el cual autoriza al punto de acceso para que permita la
conexioacuten del cliente
Ademaacutes el uso de este servicio junto con la configuracioacuten mediante VLAN dinaacutemicas permite que diferentes
usuarios accedan al servicio de red con diferentes credenciales de forma que seguacuten el tipo de cliente su traacutefico
viajaraacute por una VLAN u otra Esto permite la separacioacuten del traacutefico a nivel de enlace ofreciendo la posibilidad
de establecer reglas de control de traacutefico y ofrece una QoS miacutenima en funcioacuten del tipo de cliente
Figura 108 Escenario de Funcionamiento de Servidor Radius
111
Para cada funcionalidad de dicha pestantildea se han automatizado un conjunto de pruebas formado por 7 casos de
prueba de los cuales detallaremos el caso de prueba identificado con la etiqueta U0601 Este caso de prueba
permite validar de forma automaacutetica la creacioacuten edicioacuten y borrado de un perfil radius en la plataforma Web
6441 Criterios de Aceptacioacuten
U0601 Verificar que un usuario puede crear editar y borrar un perfil Radius correctamente
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Network
3 El usuario puede Navegar a la pestantildea de Radius
4 El usuario puede Crear un perfil Radius correctamente
5 El usuario puede Editar un perfil Radius correctamente
6 El usuario puede Eliminar un perfil Radius correctamente
6442 Diagramas de Flujo
Figura 109 Diagrama de Flujo de Caso de Prueba U0601
6443 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 110 Script de Prueba U0601
En cuanto a la implementacioacuten de dicho caso de prueba puede destacarse por ejemplo la implementacioacuten de
la Keyword ldquoCreate Radius Profilerdquo la cual permite crear un perfil ldquoRadiusrdquo a partir de un conjunto de
paraacutemetros de entrada
112
Figura 111 Keyword Create Radius Profile
645 Captive Portal
Esta pestantildea proporciona una tabla que permite registrar perfiles de Portales Cautivos con diferentes
configuraciones posibles
Figura 112 Pestantildea Captive Portals
Un portal cautivo es un servicio que permite el control del traacutefico HTTP y fuerza a los usuarios de una red a la
autenticacioacuten mediante una paacutegina Web para tener acceso a Internet Dicho portal permite controlar paraacutemetros
como el tiempo de conexioacuten de un cliente a la red ancho de banda ofrecido a cada cliente etc
Figura 113 Escenario de Funcionamiento de un Portal Cautivo
Para cada funcionalidad de dicha pestantildea se han automatizado un conjunto de pruebas formado por 5 casos de
prueba de los cuales detallaremos el caso de prueba identificado con la etiqueta U0701 Este caso de prueba
permite validar de forma automaacutetica la creacioacuten edicioacuten y borrado de un perfil de portal cautivo en la plataforma
Web
113
6451 Criterios de Aceptacioacuten
U0701 Verificar que un usuario puede crear editar y borrar un perfil de Portal Cautivo correctamente
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Network
3 El usuario puede Navegar a la pestantildea de Captive Portals
4 El usuario puede Crear un perfil de Portal Cautivo correctamente
5 El usuario puede Editar un perfil de Portal Cautivo correctamente
6 El usuario puede Eliminar un perfil de Portal Cautivo correctamente
6452 Diagramas de Flujo
Figura 114 Diagrama de Flujo de Caso de Prueba U0701
6453 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 115 Script de Prueba U0701
114
En cuanto a la implementacioacuten de dicho caso de prueba puede destacarse por ejemplo la implementacioacuten de
la Keyword ldquoEdit or delete Captive Portal Profilerdquo la cual permite editar o eliminar un perfil de Portal Cautivo
a partir de un conjunto de paraacutemetros de entrada
Figura 116 Keyword Edit or Delete Captive Portal Profile
115
646 General
Esta pestantildea muestra la vista general de la pestantildea ldquoNetworkrdquo En esta pestantildea se agrupa el conjunto de puntos
de acceso actualmente registrados en el Zone Manager con un resumen de su configuracioacuten de red actual el
estado en el que se encuentran y nuacutemero de clientes conectados Ademaacutes dicha vista proporciona un acceso
directo a la pestantildea ldquoAP Networkrdquo seleccionando uno o varios puntos de acceso de un mismo modelo En la
siguiente seccioacuten se explica la funcionalidad de dicha pestantildea
Figura 117 Pestantildea General
Para cada elemento se han automatizado un conjunto de pruebas formado por 9 casos de prueba de los cuales
detallaremos el caso de prueba identificado con la etiqueta U0522 Este caso de prueba se permite validar de
forma automaacutetica la conexioacuten de clientes a un punto de acceso con una SSID asignada de forma que el nuacutemero
de clientes conectados que se muestra en la plataforma Web sea correcto
6461 Criterios de Aceptacioacuten
U0522 Conectar clientes y verificar que el nuacutemero de clientes conectados es correcto
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Network
3 El usuario puede Navegar a la pestantildea General
4 El usuario tiene disponible un punto de acceso en el Zone Manager con una SSID asignada
5 El usuario conecta un cliente al punto de acceso por WiFi a la SSID asignada
6 El usuario verifica que el nuacutemero de clientes conectados incrementa en una unidad
116
6462 Diagramas de Flujo
Figura 118 Diagrama de Flujo de Caso de Prueba U0522
6463 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de prueba automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 119 Script de Prueba U0522
En cuanto a la implementacioacuten de dicho caso de prueba puede destacarse por ejemplo la implementacioacuten de
la Keyword ldquoCheck Number of Clients Increasesrdquo la cual permite comprobar que el nuacutemero de clientes conectados incrementa al conectar un cliente a un punto de acceso
Figura 120 Keyword Check Number of Clients Increases
117
647 AP Network
Esta pestantildea muestra la vista principal de la pestantildea ldquoAP Networkrdquo La funcionalidad que proporciona engloba
todos los posibles paraacutemetros de configuracioacuten para un punto de acceso que ha sido seleccionado previamente
desde la pestantildea General Cualquier configuracioacuten aplicada sobre esta vista seraacute enviada al punto de acceso
desde la plataforma Web permitiendo configurar los puntos de acceso de Galgus
Desde el punto de vista de la plataforma Web esta vista abarca un conjunto de funcionalidades consideradas
como maacutes complejas que se ofrecen en la plataforma Web por lo que es en esta vista donde puede encontrarse
una de las mayores aacutereas de riesgo de la plataforma Entre las funcionalidades que se ofrecen estaacuten la
configuracioacuten de las radios de un punto de acceso (Potencia Ancho de banda Canal etc) asignacioacuten de SSIDs
a las interfaces inalaacutembricas y configuracioacuten de reglas de control de traacutefico (TC Rules) asignacioacuten de puertos a
las diferentes subredes virtuales de aacuterea local (VLANS) o configuracioacuten de Portal Cautivo
Figura 121 Pestantildea AP Network
Para cada elemento se han automatizado un conjunto de pruebas formado por 28 casos de prueba los cuales la
mayoriacutea han requerido un amplio esfuerzo de implementacioacuten para conseguir su automatizacioacuten ya que son
pruebas cuya secuencia de acciones es larga ademaacutes de requerir en muchas ocasiones la verificacioacuten de la
configuracioacuten en los puntos de acceso viacutea ldquosshrdquo Para ello se ha hecho uso entre otras de la libreriacutea
ldquoSSHLibraryrdquo proporcionada por Robot Framework
Figura 122 Libreriacutea SSH para Robot Framework
118
Del conjunto de casos de prueba que validan la funcionalidad de dicha pestantildea se va a detallar el caso de prueba
identificado con la etiqueta U0511 Este caso de prueba permite validar de forma automaacutetica que se pueden
aplicar reglas de control de traacutefico ldquoTCsrdquo a una SSID asignada a las interfaces inalaacutembricas de un punto de
acceso desde la plataforma Web
Figura 123 Ventana de Configuracioacuten de TC Rules
6471 Criterios de Aceptacioacuten
U0511 Asignar ldquoTC Rulesrdquo a una SSID asociada a un Punto de Acceso correctamente
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Network
3 El usuario puede Navegar a la pestantildea General
4 El usuario tiene disponible un punto de acceso en el Zone Manager
5 El usuario puede seleccionar un punto de acceso
6 El usuario puede Navegar a la pestantildea AP Network para el punto de acceso seleccionado
7 El usuario puede asignar a las interfaces inalaacutembricas una SSID existente y crear ldquoTC Rulesrdquo sobre
esa SSID
8 El usuario puede aplicar la configuracioacuten
9 El punto de acceso aplica su configuracioacuten correctamente
10 El punto de acceso pasa al estado ldquoOnlinerdquo en la plataforma Web y su configuracioacuten estaacute alineada
119
6472 Diagramas de Flujo
Figura 124 Diagrama de Flujo de Caso de Prueba U0511
120
6473 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 125 Script de Prueba U0511
En cuanto a la implementacioacuten de dicho caso de prueba puede destacarse por ejemplo la implementacioacuten de
la Keyword ldquoWait Timerrdquo la cual permite verificar que no se produce ninguacuten error al aplicar una configuracioacuten
determinada desde la plataforma Web durante un tiempo determinado
Figura 126 Keyword Wait Timer
Destacar tambieacuten la implementacioacuten de la Keyword ldquoCheck On CLIrdquo la cual permite contrastar que la
configuracioacuten aplicada desde la plataforma sobre un punto de acceso es la esperada En este caso se comprueba
que las ldquoTC Rulesrdquo han sido correctamente aplicadas para una SSID determinada en un punto de acceso de
forma remota mediante el uso de la libreriacutea ldquoSSHrdquo para Robot Framework
Figura 127 Keyword Check On CLI
121
122
7 LINEAS DE MEJORA Y CONCLUSIONES
n este uacuteltimo capiacutetulo se analizaraacuten resultados y conclusiones obtenidas sobre el uso de pruebas
automatizadas para la verificacioacuten y validacioacuten de una plataforma Web como la de Galgus Se
detallaraacuten algunas ventajas e inconvenientes encontrados y se plantearaacuten algunas liacuteneas de mejora
futuras sobre el proyecto desarrollado Con estas mejoras se busca como objetivo enriquecer el proceso de
automatizacioacuten de pruebas ademaacutes de hacerlo maacutes efectivo y metoacutedico en todos sus aspectos ya que siempre
hay algo que se puede mejorar para conseguir una herramienta maacutes completa y uacutetil
Se detallaraacuten tambieacuten aspectos de aprendizaje opiniones experiencias y en definitiva todas las conclusiones
sacadas sobre este proyecto incluyendo tambieacuten las dificultades encontradas para el desarrollo del mismo
71 Liacuteneas de Mejora Futuras
El estudio y puesta en marcha de este Proyecto de automatizacioacuten de pruebas de Software ha hecho uso de una
amplia cantidad de herramientas ofrecido por Selenium y Robot Framework ademaacutes de otras herramientas que
han permitido enriquecer el mismo con mayores funcionalidades ofrecidas al equipo de Proyecto Si bien se ha
logrado conseguir un paquete de pruebas con una capacidad de detectar defectos en un producto Web existen
diversas ampliaciones de dicho Proyecto que podriacutean aumentar de manera considerable el desempentildeo de las
herramientas de automatizacioacuten a lo largo del ciclo de vida del proyecto
A continuacioacuten se muestran algunas de las maacutes importantes
bull Uso de Integracioacuten Continua Robot Framework es faacutecilmente integrable principalmente con Jenkins
aunque tambieacuten ofrece la posibilidad de integrarlo con Gitlab CICD Esto permitiriacutea programar la
ejecucioacuten de pruebas automaacuteticamente para diferentes versiones del proyecto Galgus CHT Cloud
Manager o en diferentes fases del mismo Con esta caracteriacutestica se detectariacutean con mayor facilidad los
problemas relacionados con la configuracioacuten del entorno de trabajo y se podriacutea notificar por email a
los responsables de equipo ante los eventuales incidentes encontrados De este modo no seriacutea necesario
estar supervisando el proceso de ejecucioacuten para estar al tanto de un fallo en el sistema En este aspecto
se ha trabajado para conseguir estos objetivos con la creacioacuten de un Docker de Robot Framework que
permita la ejecucioacuten de las pruebas en el mismo para poder usarla en el entorno de integracioacuten continua
correspondiente Tambieacuten se ha implementado un primer un script que permita la ejecucioacuten de paquetes
de pruebas en dicho entorno
bull Selenium Grid El caso praacutectico descrito tiene un inconveniente y es que solo hace uso de Chrome
Suele ser frecuente que ciertos defectos en una aplicacioacuten Web solo aparezcan en determinados
navegadores Con herramientas como Selenium Grid permitiriacutean la ejecucioacuten en paralelo de las pruebas
en maacutequinas con diferentes sistemas operativos y navegadores Asiacute se podriacutea evaluar de manera
independiente la compatibilidad del producto en entornos multiplataforma Ademaacutes esta herramienta
es totalmente compatible con Jenkins o Gitlab CICD con las ventajas que esto supone
bull Headless browser Esto hace referencia al uso de navegadores sin interfaz graacutefica de usuario La mayor
parte del tiempo durante una ejecucioacuten es destinada a esperar a que el navegador renderice el contenido
Si se elimina este factor de la foacutermula y se accede directamente al DOM de la Web se consigue una
reduccioacuten en el tiempo de ejecucioacuten de las pruebas Durante el desarrollo de este proyecto se ha
trabajado en este aspecto ofrecieacutendose la posibilidad de ejecutar las pruebas en dos entornos diferentes
una primera de depuracioacuten de pruebas que realiza el renderizado del navegador y otra opcioacuten que
E
La tecnologiacutea por siacute sola no basta Tambieacuten tenemos que poner el corazoacuten
Jane Goodall
123
permite la ejecucioacuten de pruebas sin renderizado del navegador (Modo Headless)
bull Buenas praacutecticas en la localizacioacuten de elementos en el DOM de la Web La aplicacioacuten de este tipo
de buenas praacutecticas permitiriacutean una mejor y maacutes eficiente localizacioacuten de los elementos en el DOM
reduciendo la posibilidad de que las pruebas generen falsos errores Esto es lo que ha causado la mayor
parte de los problemas de implementacioacuten y ejecucioacuten de las pruebas automaacuteticas Actualmente la
herramienta de automatizacioacuten de pruebas se encuentra en un proceso de mejora continua en el que se
estaacute abordando una refactorizacioacuten para la aplicacioacuten de estas buenas praacutecticas Para ello se estaacuten
haciendo uso de selectores avanzados basados en rutas (Xpaths) relativas en el DOM de la Web las
cuales realizan la mayoriacutea de las buacutesquedas por contenido y no por ruta absoluta como se veniacutea
haciendo hasta ahora
bull Aplicacioacuten de Model Based Testing (MBT) Como estudio del arte se ha presentado una teacutecnica que
permite dar un paso maacutes en la automatizacioacuten de pruebas Como se ha detallado en el proyecto esta
teacutecnica permite ascender en el nivel de abstraccioacuten de las pruebas basando las mismas en el disentildeo y
modelado de la aplicacioacuten Dicha teacutecnica se encuentra principalmente en proceso de investigacioacuten lo
cual hace difiacutecil aplicarla aunque seriacutea de gran intereacutes conseguir su implantacioacuten
72 Conclusiones Finales
En el desarrollo del presente Proyecto se ha analizado una pequentildea extensioacuten del inmenso mundo de la gestioacuten
de calidad Esta ha ido tomando fuerza con el paso de los antildeos en el mercado actual introducieacutendose en todos
los aacutembitos incluido en el software La gestioacuten de calidad se ha profesionalizado de tal forma que el papel del
ingeniero de calidad en los proyectos de software es imprescindible en cualquier empresa que quiera hacerse un
hueco en el mercado como garantiacutea de calidad
La elevada exigencia del mercado del software provocada por la gran demanda de clientes y usuarios finales
para recibir un producto en el menor tiempo posible hace que en muchos casos las empresas centren su esfuerzo
en sacar un producto lo antes posible reduciendo los esfuerzos destinados a los procesos de calidad de dicho
producto software Originalmente las pruebas de software realizadas sobre un producto se realizaban de forma
manual por un ingeniero de calidad pero con el avance de las tecnologiacuteas la automatizacioacuten de las mismas
supone un elevado esfuerzo inicial pero una reduccioacuten de los mismos a medio plazo
En este proyecto se ha desarrollado una herramienta que permite la automatizacioacuten de pruebas funcionales sobre
una plataforma Web concretamente pruebas de aceptacioacuten sobre Galgus CHT Cloud Manager Las pruebas de
automatizacioacuten elaboradas reflejan que existen tecnologiacuteas muy asequibles en teacuterminos de coste compatibilidad
y facilidad de uso para iniciarse en el mundo de las pruebas funcionales de sistemas Algo muy presente en el
mundo laboral actual es la creciente demanda de expertos en automatizacioacuten en todas las principales
plataformas Web Moacutevil y Escritorio Muchos de estos profesionales vienen del mundo del testing manual por
lo que conociendo ya la nomenclatura y el funcionamiento de los procesos de calidad solo necesitan dar el paso
hacia el uso de este tipo de herramientas Sea con Selenium o con cualquier otra herramienta los conceptos
teoacutericos presentados en este proyecto son igualmente vaacutelidos
Por otra parte debe destacarse la dificultad encontrada a la hora de establecer unos criterios de aceptacioacuten de las
funcionalidades de la plataforma Web bajo pruebas Esto se debe al desarrollo de una herramienta de
automatizacioacuten de pruebas que se ha iniciado en una fase avanzada del desarrollo del proyecto con lo cual en
muchas ocasiones surgiacutean dudas sobre el disentildeo del proyecto Adicionalmente la propia estructura y tecnologiacuteas
usadas en la Web dificultaron al inicio la localizacioacuten de elementos A esta causa de une tambieacuten la ausencia de
identificadores uacutenicos en los elementos que componen la misma Esto se tradujo en el uso de selectores basados
en la ruta del elemento pudiendo acarrear la aparicioacuten de posibles falsos errores debidos a cambios en el coacutedigo
fuente de la plataforma Web La solucioacuten adoptada para tal problema no fue maacutes que analizar meticulosamente
aquellas ejecuciones fallidas para descartar errores reales y en caso de que sean debidas a los selectores aplicar
la debida actualizacioacuten de los mismos
En este uacuteltimo aspecto cabe destacar que el proyecto de automatizacioacuten de pruebas se encuentra actualmente
en una fase de mejora continua en la que se estaacuten adoptando teacutecnicas basadas en el uso de selectores avanzados
basados en rutas relativas y nombres que permitan reducir el impacto del problema presentado en este punto
124
A modo de resumen se plantean algunas ventajas en el uso de SeleniumRobot Framework para la
automatizacioacuten de pruebas
Facilidad de configuracioacuten y uso Su instalacioacuten requiere un esfuerzo miacutenimo y el poder de
abstraccioacuten ofrecido por Robot Framework hace posible la lectura y entendimiento de los paquetes de
pruebas y reportes a todos los miembros del equipo
Cantidad de documentacioacuten disponible La comunidad respalda ambos proyectos y es por ello que
encontramos soluciones de todo tipo adaptadas a las necesidades de cada uno
Soporte para la mayoriacutea de navegadores con el mismo script Ejecutar el script de pruebas
desarrollado para su automatizacioacuten en otro navegador requiere simplemente la instalacioacuten del
controlador deseado y usar un determinado paraacutemetro para indicar el uso de dicho controlador en la
llamada de la Keyword encargada de la apertura del navegador
De la misma forma se pueden destacar algunas desventajas
Selenium soacutelo es compatible con productos Web Cualquier software moacutevil o de escritorio requiere
del uso de otros frameworks o herramientas lo cual puede ser un punto negativo para empresas que
tengan productos multiplataforma Sin embargo Robot Framework si proporciona soporte
multiplataforma con la integracioacuten de otras herramientas o framework para su desarrollo
Tecnologiacuteas no optimizadas para pruebas de rendimiento En este punto cabe destacar el esfuerzo
de la comunidad para desarrollar herramientas que permitan la automatizacioacuten de este tipo de pruebas
con Robot Framework como por ejemplo ldquorfswarmrdquo
Compatibilidad de versiones de paquetes de Software Es frecuente usar determinadas
combinaciones de versiones de paquetes para lograr un framework estable y robusto Esto a veces puede
convertirse en una tarea tediosa donde cuestan encajar piezas Por suerte es algo que se estaacute teniendo
en cuenta con las uacuteltimas versiones de Selenium
Puede concluirse que durante el desarrollo de este proyecto se ha conseguido la creacioacuten de una herramienta
sencilla de usar y entender para la automatizacioacuten de pruebas funcionales sobre una plataforma Web ademaacutes
de preparar dicha herramienta para integrarla en el proceso de integracioacuten continua implantado para dicha
aplicacioacuten Web con Gitlab mediante Docker Ademaacutes se ha realizar un estudio del arte de una teacutecnica conocida
bajo el nombre de Model Based Testing (MBT) que permitiriacutea mejorar el proceso de automatizacioacuten y la
herramienta desarrollada para tal fin
Con todo ello he aprendido multitud de conceptos tecnologiacuteas y herramienta que hasta ahora desconociacutea cuaacutel
era su finalidad o funcionamiento como por ejemplo Robot Framework Para ello he necesitado gran cantidad
de formacioacuten previa antes de comenzar a ponerlo en praacutectica para el desarrollo de la herramienta de
automatizacioacuten
Son muchos los errores cometidos hasta conseguir los objetivos y metas propuestas los cuales creo que son los
sucesos maacutes importantes pues de ellos se aprende y son los que nos hacen avanzar cuando los resolvemos
Finalmente destacar que este proyecto me ha dado la oportunidad de abrir mi conocimiento en un campo de las
tecnologiacuteas de la informacioacuten el cual resulta de intereacutes Dar las Gracias a mis tutores Pablo Aguilera Bonet y
Daniel Gutieacuterrez Reina ademaacutes de mi responsable en Galgus Joseacute Antonio Delgado Alfonso por brindarme
esta oportunidad ademaacutes de ayudarme y asesorarme estando siempre disponible y con dedicacioacuten hacia este
proyecto para que haya podido llevarse a cabo
125
126
REFERENCIAS
[1] M Utting Bruno Legeard Practical Model-based Testing sl Elsevier 2007
[2] Ibrahim K El-Far Enjoying the perks of model-based testing In Proceedings of the Software Testing
Analysis and Review Conference
[3] A C Dias Neto Rajesh Subramanyan Marlon Vieirab Characterization of Model-based Software
[4] Model-based Testing Next Generation Functional Software Testing Legeard Bruno Dagstuhl Seminar
Proceedings 10111 Vol httpdropsdagstuhldeopusvolltexte20102620
[5] Perspectives of Model-Based Testing Ed Brinksma Wolfgang Grieskamp and Jan Tretmans IBFI
Schloss Dagstuhl Germany sn 2005 Dagstuhl Seminar Proceedings
[6] Definicioacuten de Calidad httpsdleraeesid=6nVpk8P|6nXVL1Z
[7] Modelos de calidad del software httpswwwresearchgatenetpublication316674475
[8] Calidad del Software ldquoEl camino al exitordquo LI Alma Delia Chaacutevez Rojas
[9] IEEE Software Engineering Book of Knowledge IEEE sl IEEE 2004
[10] Principios de pruebas software httpsmediumcomatejedaccsprincipios-del-testing-722323e16e76
[11] httpwwwsstqbesw3docsGLOSARIO_V00110pdf
[12] httpsepdfpubsoftware-testing-an-istqb-iseb-foundation-guidehtml
[14] IEEE standard glossary of software engineering terminology F Jay RMayer 1990 paacuteg IEEE Std 610
[15] Openwrt httpsopenwrtorgsupported_devices
[16] RabbitMQ httpswwwrabbitmqcom
[17] Zero Touch Provisioning httpssearchdatacentertechtargetcomesdefinicionAprovisionamiento-de-
cero-toque-ZTP-o-zero-touch-provisioning
[18] Robot Framework User Guide
httpsrobotframeworkorgrobotframeworklatestRobotFrameworkUserGuidehtml
[19] Gitlab httpsdocsgitlabcom
[20] httpswwwfederico-toledocomcuando-automatizar-una-prueba
127
128
ANEXO A PREPARACIOacuteN DEL ENTORNO DE
TRABAJO Y EJECUCIOacuteN DE PRUEBAS
A1 Preparacioacuten del entorno de trabajo
Para el desarrollo de las preubas automaacuteticas se ha hecho uso del sistema operative Linux con la distribucioacuten
Ubuntu El motivo de su uso es el amplio abanico de herramientas de coacutedigo libre que existen para esta
distribucioacuten asiacute como la enorme contribucioacuten que hace la comunidad de usuarios para mejorarla Sobre este
sistema operativo se ha hecho uso de un conjunto de herramientas para el montaje de un entorno de pruebas
automatizado basado en Python A continuacioacuten se detallaraacuten dichas herramientas
A11 Pip
Pip es un sistema de gestioacuten de paquetes que se utiliza para la instalacioacuten de los paquetes software
implementados en Python que se usaraacuten posteriormente La instalacioacuten de un paquete se realiza mediante la
ejecucioacuten del siguiente comando
A12 Virtualenv Entorno Virtual
Dado que cada proyecto basado en Python puede requerir la instalacioacuten de diferentes conjuntos de paquetes es
comuacuten usar la creacioacuten de entornos virtuales que nos permitan administrar cada proyecto de manera
independiente pudiendo tener otros proyectos haciendo uso de los mismos paquetes con otras versiones La
instalacioacuten se realiza mediante la herramienta ldquoPiprdquo a traveacutes del siguiente comando
Una vez instalado se puede crear un entorno virtual asociado a un proyecto de la siguiente forma
En este punto se creariacutea un entorno virtual para el proyecto deseado Ahora solo quedariacutea activarlo o iniciarlo
pip install nombre-del-paquete
pip install virtualenv
cd carpeta-del-proyecto
virtualenv ndashp usrbinpython27 mi-proyecto
source mi-proyectobinactivate
129
A13 Selenium y Chromedriver
La instalacioacuten de Selenium se realiza de la misma forma que el resto de paquetes con la herramienta ldquoPiprdquo
Por otra parte el controlador para el navegador Chrome Chromedriver puede ser descargado desde el
repositorio oficial httpschromedriverchromiumorg Ademaacutes Chromedriver debe ser accessible para
Selenium de cara a configurar el PATH
A14 Robot Framework y SeleniumLibrary
A continuacioacuten se realizariacutea la instalacioacuten de Robot Framework
Posteriormente se realizariacutea la instalacioacuten del paquete ldquoSelenium2Libraryrdquo el cual contiene la implementacioacuten
en python de las libreriacuteas necesarias para utilizar Robot Framework en Python
Llegados a este punto listando todos los paquetes instalados se deberiacutea tener algo similar a la siguiente figura
Con esta configuracioacuten del entorno este estariacutea preparado para elaborar los casos de prueba automatizados con
Robot Framework y Selenium
pip install selenium
export PATH=$PATHabsolute_path_of_chromedriver_file
pip install robotframework
pip install robotframework-selenium2library
130
A15 Otras dependencias
Para el desarrollo de pruebas que requieren otro tipo de herramientas como la transferencia de ficheros con el
servicio ldquoSCPrdquo o la conexioacuten remota a traveacutes del servicio ldquoSSHrdquo se require la instalacioacuten de los siguientes
paquetes
Ademaacutes para la realizacioacuten de pruebas avanzadas en Python para la gestioacuten del Mapa de la platform Web CHT
Cloud Manager se ha hecho uso de la librariacutea ldquohtml-testRunnerrdquo para ofrecer un reporte de la ejecucioacuten de
pruebas muy similar al ofrecido por Robot Framework
A2 Ejecucioacuten de Pruebas
Tras la implementacioacuten de las pruebas siguiendo el procedimiento indicado en la seccioacuten de Experimentos
ejecutar un script de pruebas se realiza mediante el uso del siguiente comando
Mediante el uso de la variable ldquoENVIROMENTrdquo puede seleccionarse el entorno en el que se desea ejecutar las
pruebas Con el entorno de ldquodebugrdquo las pruebas se ejecutariacutean de forma graacutefica mientras que el el entorno de
ldquodockerrdquo permite la ejecucioacuten de pruebas sin interfaz graacutefica Este uacuteltimo entorno seriacutea usado para la ejecucioacuten
de pruebas con el docker de Robot Framework que se ha implementado el cual se detallaraacute maacutes adelante
Por otro lado existen otras opciones para el comando anterio como por ejemplo
Las opciones ldquo-irdquo y ldquo-erdquo permiten ejecutar o excluir un caso de preuba en la ejecucioacuten de una Suite de pruebas
Por otro lado el uacuteltimo comando permite lanzar la ejcucioacuten de una Suite de pruebas y ejecutar soacutelo aquellos
casos de prueba que hayan fallado en la ejecucioacuten anterior
pip install robotframework-sshlibrary
pip install robotframework-scplibrary
pip install html-testRunner
robot --variable ENVIROMENTdebug_or_docker suite_filerobot
robot --variable ENVIROMENTdebug_or_docker ndashi U0000 suite_filerobot
robot --variable ENVIROMENTdebug_or_docker ndashe U0000 suite_filerobot
robot --rerunfailed outrerunfailedxml --output out2xml suite_filerobot
131
A continuacioacuten se muestra un ejemplo de ejecucioacuten de pruebas con Robot Framwork
132
A3 Script de Prueba U007 (MAP)
from selenium import webdriver
from seleniumwebdrivercommonby import By
from seleniumwebdriversupportui import WebDriverWait
from seleniumwebdriversupport import expected_conditions as EC
from seleniumwebdrivercommondesired_capabilities import DesiredCapabilities
from seleniumwebdrivercommonaction_chains import ActionChains
from seleniumcommonexceptions import TimeoutException
import math json multiprocessing time re
import sys
import unittest
import HtmlTestRunner
U0007 Double-click on Zone Manager and look if the Backend tab opens
class DClickZM(unittestTestCase)
driver = 0
canvas = 0
waitTime = 20
username = franciscodiaz
password = ahipeo8829g
classmethodg
def setUp(cls)
Enviroment Management
chrome_options = webdriverChromeOptions()
if sysargv[2] == docker
chrome_optionsadd_argument(--headless)
chrome_optionsadd_argument(--disable-extensions)
chrome_optionsadd_argument(--disable-gpu)
chrome_optionsadd_argument(--no-sandbox)
enable browser logging
d = DesiredCapabilitiesCHROME
d[loggingPrefs] = browser DEBUG
clsdriver = webdriverChrome(chrome_options=chrome_options desired_capabilities=d)
clsdrivermaximize_window()
clsdriverset_window_size(1920 1080)
load the desired webpage
clsdriverget(httpdevcloudgalgusnet)
def test_double_click_ZM(self)
loggin in the page
userNameBox = WebDriverWait(selfdriver 1)until(
ECpresence_of_element_located((ByXPATH [id=username])))
userNameBoxsend_keys(selfusername)
passwordBox = WebDriverWait(selfdriver selfwaitTime)until(
ECpresence_of_element_located((ByXPATH [id=password])))
passwordBoxsend_keys(selfpassword)
133
loginButton = WebDriverWait(selfdriver selfwaitTime)until(
ECpresence_of_element_located((ByXPATH
[id=myModalLabel]divdivformdiv[3]input)))
loginButtonclick() Tab General appears
selfcanvas = WebDriverWait(selfdriver selfwaitTime)
until(ECpresence_of_element_located((ByXPATH
htmlbodyappdivmaindivregister-
managersdivtabsetdivtab[1]aol-mapdivdivcanvas)))
timesleep(15)
action = ActionChains(selfdriver)
Manage Process
manager = multiprocessingManager()
return_dict = managerdict()
We create a Process
p_get_pixels_zm = multiprocessingProcess(target=selfGet_Pixels_ZM args=(return_dict selfdriver))
We create another Process
p_double_click_on_zm = multiprocessingProcess(target=selfDouble_Click_On_ZM args=(return_dict selfcanvas
action selfdriver))
We start the process and we block for 5 seconds
p_get_pixels_zmstart()
p_get_pixels_zmjoin(timeout=10)
p_double_click_on_zmstart()
p_double_click_on_zmjoin(timeout=10)
We terminate the process
p_get_pixels_zmterminate()
p_double_click_on_zmterminate()
try
Tab General appears
WebDriverWait(selfdriver 20)until(ECpresence_of_element_located(
(ByXPATH [id=app-sections]networktabsetulli[1]a)))
except TimeoutException
raise Exception(Cant Login in Zone Manager)
classmethod
def tearDown(cls)
clsdriverquit()
staticmethod
def Get_Pixels_ZM(return_dict driver)
return_dict[0] = 0
return_dict[1] = 0
regex = r(lt=c[-gt]cs)[wW]+(=)
while True
for entry in driverget_log(browser)
message = entry[message]
matches = refinditer(regex message reMULTILINE)
134
for matchNum match in enumerate(matches start=1)
try
p = matchgroup()replace( )
my_json = jsonloads(p)
if my_json[ZM] == Hotel MampM
return_dict[0] = my_json[top]
return_dict[1] = my_json[left]
break
except
pass
if return_dict[0] = 0 and return_dict[1] = 0
break
staticmethod
def Double_Click_On_ZM(return_dict canvasaction driver)
width = int(mathceil(float(return_dict[0])))
height = int(mathceil(float(return_dict[1])))
actionmove_to_element_with_offset(canvas width height)
actiondouble_click()
actionperform()
actiondouble_click()
actionperform()
driversave_screenshot(screenshot1png)
timesleep(5)
if __name__ == __main__
unittestmain(testRunner=HtmlTestRunnerHTMLTestRunner())
135
136
ANEXO B DOCKER DE ROBOT FRAMEWORK Y
ENTORNO DE UAT DOCKERIZADO
B1 Docker de Robot Framework
Para el entorno de UAT que se va a desarrollar se ha hecho uso de diferentes contenedores que han sido creados
por el equipo de desarrollo donde cada contenedor aloja un microservicio diferente de la plataforma
Para crear cada contenedor se ha hecho uso de Docker Esta herramienta permite crear contenedores ligeros y
portables para diferentes servicios que puedan ejecutarse en cualquier maacutequina con Docker instalado
independientemente del sistema operativo de la maacutequina que lo ejecute facilitando asi los despliegues
Mediante un fichero llamado ldquoDockerfilerdquo se definen los siguientes contenedores de servicios entre los cuales
se destacaraacute el fichero que define la creacioacuten del docker de Robot Framework el cual ha sido desarrollado por
el autor de este proyecto
Este contenedor ha sido creado sobre una imagen de Docker con el inteacuterprete de Python instalado Partiendo de
137
esta imagen se realiza la instalacioacuten de Robot Framework y las diferentes libreriacuteas y herramientas que se usaraacuten
en el proyecto para poder lanzar los Tests End-to-End
Ademaacutes se realiza la instalacioacuten de Google Chrome y Mozilla Firefox y la descarga de Chromedriver y
Geckodriver para poder lanzar los tests con dichos navegadores en modo headless Para el lanzamiento de los
test en modo headless se haraacute uso de la variable de entorno ldquoENVIROMENTrdquo definida en el anexo anterior
Finalmente se antildeade el proyecto de pruebas desarrollado para tener disponible las pruebas aumaacuteticas en el
contenedor
B2 Entorno de UAT Dockerizado
Para automatizar el despliegue de la plataforma Galgus CHT Cloud Manager con Docker se ha hecho uso de la
herramienta ldquodocker-composerdquo Esta herramienta permite simplificar el uso de Docker generando scripts que
facilitan el disentildeo y la construccion de servicios Con Docker Compose se pueden crear diferentes contenedores
y al mismo tiempo en cada contenedor diferentes servicios En la siguientefigura se muestra el fichero que
define el entorno de UAT con docker-compose
138
139
140
ANEXO C REVISIOacuteN DE REPORTES Y LOGS
C1 Reporte de Logs ofrecido por Robot Framework
Selenium no teniacutea la capacidad nativa de generar informes Este es uno de los motivos por el que se decidioacute
utilizar Robot Framework
Robot Framework genera tres archivos tras la ejecucioacuten de los scripts de pruebas A partir de la informacioacuten
contenida en el fichero ldquooutputxmlrdquo se rellenan las plantillas ldquohtmlrdquo del ldquologrdquo y del reporte El reporte permite
aplicar filtros a los resultados mientras que el ldquologrdquo contiene todos los detalles de la ejecucioacuten
A continuacioacuten se adjuntan las capturas de logs generados por los diferentes paquetes de pruebas desarrollados
C2 Cloud Tab
C21 Administration
141
142
C22 List
143
C23 Manufacturers
144
C24 MAP
145
C3 Configuration Tab
C31 BackupRestore
146
C32 CHT Zones
147
C33 Firmware
148
C34 Groups
149
150
C4 Network Tab
C41 General
151
C42 SSID
C43 CHT
152
C44 VLAN
153
C45 Radius
154
C46 Captive Portal
155
C47 AP Network
156
Como se ha visto reflejado en el conjunto de logs el tiempo total invertido en la ejecucioacuten ha sido de 1 hora 20
minutos y 22 segundos Dichas pruebas realizadas por una persona de forma manual hubiesen requerido como
miacutenimo el doble de tiempo Ya ni mencionar si se aplicase concurrencia en la ejecucioacuten de pruebas
157
ANEXO D DIAGRAMA DE GANTT
9
Agradecimientos
10
11
Resumen
La revolucioacuten tecnoloacutegica que vivimos hoy diacutea enfocada principalmente en el mundo de Internet y aplicaciones
Web estaacute permitiendo que todas las herramientas que tenemos a nuestro alrededor se encuentren en un proceso
de tremenda evolucioacuten y cambio continuo
En este proyecto se ha realizado un estudio del arte sobre una teacutecnica que permite mejorar el proceso de
automatizacioacuten de pruebas sobre una aplicacioacuten Web basaacutendose en el modelado de la aplicacioacuten para
proporcionar una abstraccioacuten en la implementacioacuten de las pruebas Tambiacuteeacuten se ha realizado una revisioacuten de los
diferentes modelos de calidad normativas y tipos de prueba de Software Finalmente se ha desarrollado una
herramienta de test comprendida por un conjunto de pruebas de aceptacioacuten automaacuteticas que permiten la
verificacioacuten y validacioacuten de la funcionalidad de la plataforma Web Galgus CHT Cloud Manager
Galgus CHT Cloud Manager es la plataforma Web distribuida ofrecida por Galgus para la gestioacuten de redes
compuestas por puntos de acceso Wifi Estas redes se encuentran instaladas en los diferentes clientes que hacen
uso de los servicios que ofrece Galgus los cuales se basan en la optimizacioacuten del rendimiento y las prestaciones
de las redes Wifi en entornos de alta densidad de usuarios Esto se consigue mediante un software embebido
patentado por Galgus conocido bajo el nombre de Cognitive Hostpot Technology (CHT) el cual es instalado
en los puntos de acceso Dicho software implementa un conjunto de algoritmos y caracteriacutescas colaborativas
para conseguir los objetivos planteados en redes Wifi
Como resultado del trabjo podemos proporcionar a los ingenieros de pruebas una herramienta con la que poder
automatizar el testeo de una plataforma Web De esta forma se consigue agilizar el proceso de pruebas y reducir
costes y esfuerzos en tareas repetitivas que anteriormente se haciacutean de forma manual
12
13
Abstract
The technological revolution we are living today focused mainly on the Internet world and therewith the Web
applications is allowing all the tools we have around us to be in a process of continuous evolution and change
In this project we have made a study of the art on a technique that allows to improve the process of automation
of testing on a Web application based on the modelling of the application to provide an abstraction in the
implementation of testing A review of the different quality models standards and types of software testing has
also been carried out Finally a tool comprised of a set of automated acceptance tests has been developed to
allow verification and validation of the functionality of the Galgus CHT Cloud Manager Web platform
Galgus CHT Cloud Manager is the distributed web platform offered by Galgus for the management of
networks composed by Wifi access points These networks are installed in the different clients that make
use of the services offered by Galgus which are based on the optimization of the performance and features
of Wifi networks in high user density environments This is achieved through an embedded software
patented by Galgus known as Cognitive Hostpot Technology (CHT) which is installed in the access points
This software implements a set of algorithms and collaborative features to achieve the objectives set in Wifi
networks
This allows us to provide quality assurance engineers with a tool to automate the testing of a Web platform In
this way the testing process is streamlined and costs and efforts are reduced in repetitive tasks that previously
used to be done manually
14
15
Iacutendice
Agradecimientos 9
Resumen 11
Abstract 13
Iacutendice 15
Iacutendice de Figuras 19
Glosario 24
1 Introduccioacuten 27 11 Motivacioacuten 28 12 Alcance y Objetivos 29 13 Estructura de la memoria 30
2 Estudio del Arte y Revisioacuten 32 21 Model Based Testing (MBT) 32
211 Introduccioacuten 32 212 iquestQueacute es Model Based Testing 33 213 iquestCoacutemo funciona Model Based Testing 33 214 Consideraciones para la aplicacioacuten de Model Based Testing (MBT) 36 215 Beneficios de Model Based Testing (MBT) 37 216 Problemas y Limitaciones de Model Based Testing (MBT) 38 217 Cuando elegir Model Based Testing (MBT) 38
22 Gestioacuten de Calidad Software 39 221 Introduccioacuten 39 222 Concepto de Calidad 39 223 Modelos de Calidad de Software 40 224 Principales Ventajas e Inconvenientes de Modelos de Calidad anteriores 44 225 Conclusiones 44
3 Marco Teoacuterico Pruebas de Software 46 31 Testing y Pruebas de Software 46 32 Principios de las Pruebas de Software 47 33 Proceso de Pruebas de Software Anaacutelisis disentildeo e implementacioacuten 48
331 Terminologiacutea 48 332 Proceso de Pruebas de Software 49
34 Clasificacioacuten de Pruebas de Software 51 341 Pruebas Funcionales 51 342 Pruebas No Funcionales 52 343 Pruebas Estructurales 54 344 Pruebas debidas a Cambios 54
35 Niveles de Prueba 54 351 Pruebas a Nivel de Componente 55 352 Pruebas a Nivel de Integracioacuten 55 353 Pruebas a Nivel de Aceptacioacuten 55
16
36 Dificultades de pruebas en aplicaciones Web e impacto 56
4 Sistema Galgus CHT Cloud Manager 58 41 Arquitectura y Descripcioacuten del Sistema 58
411 Puntos de Acceso (OpenWRT + CHT) 60 412 Broacuteker de Eventos AMQP (RabbitMQ) 61 413 Frontend 62 414 Zone Manager 62 415 MoMap 63 416 Servidor de Licencias 64
42 Alcance y Objetivos de las pruebas sobre el sistema planteado 65 43 Arquitectura de la Solucioacuten Entorno de UAT para el proceso de pruebas (User Acceptance Test) 67
5 Tecnologiacuteas y Herramientas Usadas 69 51 Selenium 69 52 Selenium WebDriver 70
521 Elementos del Navegador 70 53 Robot Framework (RF) 72
531 Estilo de representacioacuten Given-When-Then 72 532 Reportes 75 533 Libreriacuteas 76 534 Documentacioacuten 77
54 Pycharm (IDE) 78 55 GitGitlab 78
551 Git 78 552 Gitlab 78
56 Redmine 78 561 Uso en el Proyecto Galgus CHT Cloud Manager (Metodologiacutea Scrum) 79
6 Experimentos 82 61 Estructura del Proyecto 83 62 Vista de Gestioacuten Principal (Cloud Tab) 87
621 Administration 87 622 List 89 623 Manufacturer 90 624 MAP 92
63 Vista de Configuracioacuten (Configuration Tab) 95 631 Groups 95 632 CHT Zones 98 633 BackupRestore 100 634 Firmware 101
64 Vista de Red (Network Tab) 104 641 VLANS amp Bridges 104 642 SSIDs 106 643 CHT 108 644 Radius 110 645 Captive Portal 112 646 General 115 647 AP Network 117
7 Lineas de Mejora y Conclusiones 122 71 Liacuteneas de Mejora Futuras 122 72 Conclusiones Finales 123
Referencias 126
17
Anexo A Preparacioacuten del Entorno de Trabajo y Ejecucioacuten de Pruebas 128 A1 Preparacioacuten del entorno de trabajo 128
A11 Pip 128 A12 Virtualenv Entorno Virtual 128 A13 Selenium y Chromedriver 129 A14 Robot Framework y SeleniumLibrary 129 A15 Otras dependencias 130
A2 Ejecucioacuten de Pruebas 130 A3 Script de Prueba U007 (MAP) 132
Anexo B Docker de Robot Framework y Entorno de UAT Dockerizado 136 B1 Docker de Robot Framework 136 B2 Entorno de UAT Dockerizado 137
Anexo C Revisioacuten de Reportes y Logs 140 C1 Reporte de Logs ofrecido por Robot Framework 140 C2 Cloud Tab 140
C21 Administration 140 C22 List 142 C23 Manufacturers 143 C24 MAP 144
C3 Configuration Tab 145 C31 BackupRestore 145 C32 CHT Zones 146 C33 Firmware 147 C34 Groups 148
C4 Network Tab 150 C41 General 150 C42 SSID 151 C43 CHT 151 C44 VLAN 152 C45 Radius 153 C46 Captive Portal 154 C47 AP Network 155
Anexo D Diagrama de Gantt 157
18
19
IacuteNDICE DE FIGURAS
Figura 1 Fuente de datos Morgan Stanley 27
Figura 2 Manual Testing vs Automated Testing [20] 28
Figura 3 Fase de Pruebas y Validacioacuten 32
Figura 4 Esquema baacutesico de Model Based Testing 33
Figura 5 Proceso detallado de Model Based Testing (MBT) 34
Figura 6 Construccioacuten del Modelo 34
Figura 7 Concepto de Calidad 39
Figura 8 Liacutenea de tiempo de modelos a nivel de proceso 40
Figura 9 Logo de ITIL 40
Figura 10 ISOIEC 20000 41
Figura 11 Logo de WebQEM 41
Figura 12 Liacutenea de tiempo de modelos a nivel de producto 42
Figura 13 Esquema de ISO 9126 42
Figura 14 Esquema de ISOIEC 25000 43
Figura 15 Principios de las Pruebas de Software 47
Figura 16 Terminologiacutea para el proceso de pruebas 48
Figura 17 Proceso de Pruebas de Software 49
Figura 18 Clasificacioacuten de Pruebas de Software 51
Figura 19 Pruebas de Caja Negra 51
Figura 20 Pruebas de Rendimiento 52
Figura 21 Pruebas de Carga 52
Figura 22 Pruebas de Estreacutes 52
Figura 23 Pruebas de Usabilidad 53
Figura 24 Pruebas de Portabilidad 53
Figura 25 Pruebas de Caja Blanca 54
Figura 26 Modelo de desarrollo en V 55
Figura 27 Dificultades de pruebas en aplicaciones Web e impacto 56
Figura 28 Logo de Galgus 58
Figura 29 Arquitectura de CHT Cloud Manager 59
Figura 30 CHT_CLI 60
Figura 31 Plataforma de Gestioacuten de RabbitMQ 61
Figura 32 Patroacuten PublicadorSuscriptor 61
Figura 33 Ejemplo de Interfaz Graacutefica de un Zone Manager 62
Figura 34 Ejemplo de Interfaz Graacutefica de MoMap 63
20
Figura 35 Interfaz Graacutefica del Servidor de Licencias 64
Figura 36 Zero-Touch Provisioning (ZTP) 64
Figura 37 Test Plan de CHT Cloud Manager 65
Figura 38 Leyenda del Test Plan 66
Figura 39 Control de Versiones del Test Plan 66
Figura 40 Entorno de UAT con Docker (Anexo B) 67
Figura 41 Implementaciones disponibles de Selenium y Navegadores Web Compatibles 70
Figura 42 Coacutedigo de ejemplo con Python y Selenium 71
Figura 43 Estilo de representacioacuten Given-When-Then 72
Figura 44 Implementacioacuten de Pruebas en para el inicio de sesioacuten de CHT Cloud Manager 74
Figura 45 Ejemplo de reporte de pruebas automatizadas con Robot Framework 75
Figura 46 Ejemplo de documentacioacuten generada con Libdoc 77
Figura 47 Ejemplo de documentacioacuten generada con Testdoc 77
Figura 48 Ejemplo de Flujo de Trabajo en Redmine para Galgus CHT Cloud Manager 79
Figura 49 Esquema Graacutefico de Metodologiacutea Scrum 79
Figura 50 Logo de Galgus CHT Cloud Manager 82
Figura 51 Estructura del Proyecto 83
Figura 52 Fragmento del fichero ldquoSelectorpyrdquo 83
Figura 53 Fragmento del fichero ldquoCommon_Keywordsrobotrdquo 84
Figura 54 Fragmento del fichero de Configuracioacuten de pruebas ldquoConfigurationrobotrdquo 84
Figura 55 Diagrama de paquetes del proyecto de pruebas 85
Figura 56 Estructura de una Suite de Pruebas 85
Figura 57 Ejemplo de ldquoTest Setuprdquo personalizado para un caso de prueba 86
Figura 58 Vista de Gestioacuten Principal (Cloud Tab) 87
Figura 59 Pestantildea ldquoAdministrationrdquo 87
Figura 60 Diagramas de Flujo de Casos de Prueba U0025 y U0027 88
Figura 61 Script de Pruebas U0025 88
Figura 62 Keyword ldquoEdit Fieldsrdquo 88
Figura 63 Pestantildea ldquoList of Zone Managersrdquo 89
Figura 64 Diagrama de flujo de Caso de Prueba U0023 89
Figura 65 Script de Prueba U0023 90
Figura 66 Keyword ldquoZone Manager is registered successfullyrdquo 90
Figura 67 Seccioacuten de Fabricantes 90
Figura 68 Diagrama de flujo de Caso de Prueba U0009 91
Figura 69 Script de Prueba U0009 91
Figura 70 Toast Success 92
Figura 71 Keyword ldquoCorrectly Createrdquo 92
Figura 72 Setup amp Teardown de U0008 92
21
Figura 73 Mapa de Zone Managers 92
Figura 74 Funcioacuten que dibuja los ZM en el Mapa y obtiene los piacutexeles en pantalla 93
Figura 75 Diagrama de Flujo de Caso de Prueba U0007 94
Figura 76 Pestantildea ldquoGroupsrdquo 95
Figura 77 Diagrama de flujo de Caso de Prueba U0119 96
Figura 78 Script de Prueba U0119 97
Figura 79 Keyword ldquoVerify if AP is registered Succesfully on grouprdquo 97
Figura 80 Keywords Input Into Text Field y Clear Field Of Characters 97
Figura 81 Pestantildea ldquoCHT Zonesrdquo 98
Figura 82 Diagrama de Flujo de Caso de Prueba U0204 99
Figura 83 Scripts de Prueba U0204 99
Figura 84 Keyword Add Zone CHT to AP 99
Figura 85 Pestantildea BackupRestore 100
Figura 86 Diagrama de Flujo de Caso de Prueba U0401 101
Figura 87 Script de Prueba U0401 101
Figura 88 Keyword Restore For AP hace done successfully 101
Figura 89 Pestantildea ldquoFirmwarerdquo 102
Figura 90 Diagrama de Flujo de Caso de Prueba U0303 103
Figura 91 Script de Prueba U0303 103
Figura 92 Keyword Flash AP 103
Figura 93 Pestantildea ldquoVLAN amp Bridgesrdquo 104
Figura 94 Diagrama de Flujo de Caso de Prueba U0527 105
Figura 95 Script de Prueba U0527 105
Figura 96 Keyword Go And Create VLAN 105
Figura 97 Pestantildea SSIDs 106
Figura 98 Diagrama de Flujo de Caso de Prueba U0530 106
Figura 99 Script de Prueba U0530 107
Figura 100 Keyword Go And Create SSID 107
Figura 101 Pestantildea ldquoCHTrdquo 108
Figura 102 Diagrama de Flujo de Caso de Prueba U0539 109
Figura 103 Script de Prueba U0539 109
Figura 104 Keyword ACA Is Working 109
Figura 105 Keyword Changes On CLI 110
Figura 106 Comando CHT para obtener el estado del moacutedulo ACA en el punto de acceso 110
Figura 107 Pestantildea ldquoRadiusrdquo 110
Figura 108 Escenario de Funcionamiento de Servidor Radius 110
Figura 109 Diagrama de Flujo de Caso de Prueba U0601 111
Figura 110 Script de Prueba U0601 111
Figura 111 Keyword Create Radius Profile 112
22
Figura 112 Pestantildea Captive Portals 112
Figura 113 Escenario de Funcionamiento de un Portal Cautivo 112
Figura 114 Diagrama de Flujo de Caso de Prueba U0701 113
Figura 115 Script de Prueba U0701 113
Figura 116 Keyword Edit or Delete Captive Portal Profile 114
Figura 117 Pestantildea General 115
Figura 118 Diagrama de Flujo de Caso de Prueba U0522 116
Figura 119 Script de Prueba U0522 116
Figura 120 Keyword Check Number of Clients Increases 116
Figura 121 Pestantildea AP Network 117
Figura 122 Libreriacutea SSH para Robot Framework 117
Figura 123 Ventana de Configuracioacuten de TC Rules 118
Figura 124 Diagrama de Flujo de Caso de Prueba U0511 119
Figura 125 Script de Prueba U0511 120
Figura 126 Keyword Wait Timer 120
Figura 127 Keyword Check On CLI 120
23
24
GLOSARIO
CHT Cognitive Hostpot Technology
BDD Behaviour-Driven Development
MBT Model Based Testing
API Application Programing Interface
UAT User Acceptance Testing
SUT System Under Test
UML Unified Modeling Language
FSM Finite State Machine
RAE Real Academia Espantildeola
IEEE Institute of Electronical and Electronics Engineers
ITIL Information Technology Infrastructure Library
ISO International Organization for Standardization
WebQEM Web-site Quality Evaluation method
ISTQB International Software Testing Qualifications Board
TDD Test-Driven Development
SOA Service Oriented Architecture
WiFi Wireless Fidelity
MGR Manager Module
SB Smart Band Steering Module
TCM Traffic Congestion Management Module
LOC Localization Module
POWER Power Control Module
SR Smart Roaming Module
LB Load Balancing Module
AMQP Advance Message Queuing Protocol
HTML HyperText Markup Language
CSS Cascading Style Sheets
HTTPS HyperText Transfer Protocol Secure
TLS Transport Layer Security
REST REpresentational State Transfer
JSON JavaScript Object Notation
DOM Document Object Model
SQL Structure Query Language
ZMB Zone Manager Backend
ZTP Zero-Touch Provisioning
25
RF Robot Framework
CICD Continuous IntegrationContinuous Delivery
SSH Secure SHell
SCP Secure Copy ProtocolSimple Communication Protocol
26
27
1 INTRODUCCIOacuteN
ctualmente el desarrollo software se encuentra en un proceso revolucionario cuyo principal objetivo y
tendencia es la implantacioacuten y desarrollo de software distribuido donde se marcan como principales
objetivos la disponibilidad usabilidad y funcionalidad de cualquier aplicacioacuten a traveacutes de internet Es
aquiacute donde entran en juego entre otros el desarrollo de aplicaciones o servicios Web sustituyendo en gran
medida al desarrollo de aplicaciones y servicios de escritorio
Figura 1 Fuente de datos Morgan Stanley
Muchos son los aspectos a tener en cuenta entre los que cabe destacar la eficiencia la velocidad de respuesta y
de navegacioacuten los cuales para algunos servicios Web son excelentes pero para otros auacuten se encuentran en un
proceso de mejora Esto es debido a que gran cantidad de aplicaciones requieren de un buen disentildeo donde se
optimicen el uso de los recursos disponibles como el ancho de banda memoria carga del servidor respaldo
seguridad etc
A
Hemos establecido la civilizacioacuten de manera que los
maacutes cruciales elementos dependen de la ciencia y la
tecnologiacutea
Carl Sagan
28
11 Motivacioacuten
La gran demanda de servicios y aplicaciones Web distribuidas que permitan gestionar agilizar y simplificar
cualquier aacutembito de negocio hace que cada vez maacutes que dichas aplicaciones contemplen un mayor
conjunto de requisitos solicitados por los clientes lo cual se traduce en un mayor nuacutemero de funcionalidades
y casos de uso contemplados en dichas aplicaciones
Ademaacutes dichas aplicaciones se necesitan cada vez en un menor tiempo lo cual conlleva a reducir los
periodos en las diversas fases por las que pasa un proyecto software desde la fase de disentildeo hasta la de
pruebas Es en esta uacuteltima donde antes de ser entregada al cliente como un producto se detectan los
posibles errores e incluso se puede evaluar si la funcionalidad ofrecida por la aplicacioacuten esta alineada con
los requisitos demandados por el cliente
Los fallos o errores en las aplicaciones Web mal probadas bien por falta de asignacioacuten de tiempo o recursos
a la fase de pruebas tienen una mayor repercusioacuten teniendo el potencial de generar una gran cantidad de
quejas e insatisfaccioacuten por parte de los clientes casi inmediatamente En el caso de las aplicaciones Web
no soacutelo se trata de peacuterdidas econoacutemicas sino tambieacuten de peacuterdida de prestigio fiabilidad y credibilidad por
parte de nuestros usuarios o clientes Los consumidores de hoy demandan una tecnologiacutea intuitiva y de
confianza en un mercado en continuo crecimiento donde un pequentildeo error puede acarrear falta de
satisfaccioacuten en un usuario peacuterdidas millonarias a una empresa o incluso dantildeos humanos Y es en este tipo
de ciclos iterativos y raacutepidamente cambiantes donde la automatizacioacuten de pruebas juega un papel decisivo
iquestY cuaacutel es la causa de estos problemas Para ello debemos tener en cuenta que estos sistemas son disentildeados
por el ser humano el cual comete fallos ya sea por presioacuten en los plazos de trabajo por la complejidad del
coacutedigo o de la infraestructura por cambios de tecnologiacuteas o por cualquier otra interaccioacuten con el sistema
Como ha quedado reflejado un proceso riguroso de control de sistemas y documentacioacuten permiten
bull Ayudar a reducir el riesgo de los posibles fallos y Mejora la calidad de los sistemas a la hora de ser
usados
bull Un correcto mantenimiento del producto a lo largo del ciclo de desarrollo
bull Un cumplimiento de requisitos legales (normas nacionales e internacionales ordenanzas
municipales etc)
bull Una adecuacioacuten de un sistema a los requisitos contractuales
bull Una adaptacioacuten de estaacutendars especiacuteficos de la industria
La forma en la que se logre y las herramientas empleadas variaraacuten en funcioacuten de factores como la
envergadura y tipo de proyecto den cuanto a los riesgos tecnoloacutegicos de seguridad o de negocio asiacute como
del presupuesto y tiempo disponible
Figura 2 Manual Testing vs Automated Testing [20]
29
12 Alcance y Objetivos
Las pruebas de software o software testing pueden llevarse a la praacutectica de muacuteltiples maneras pero el
presente proyecto se centra en el componente funcional del producto enfocado en lo que hace el sistema y
no coacutemo primando la aceptacioacuten por parte de los usuarios en base a los requisitos de disentildeo originales Es
decir el punto de mira estaacute en cumplir los requisitos establecidos por el cliente dejando fuera del alcance
del proyecto la estructura del coacutedigo fuente implementado
Bajo este contexto se plantea la automatizacioacuten de la fase de pruebas de una aplicacioacuten Web distribuida
centrando el enfoque de este proyecto en la automatizacioacuten de pruebas funcionales maacutes concretamente
pruebas de humo or smoke tests y aceptacioacuten Hasta ahora dichas pruebas se realizaban manualmente por
un ingeniero de pruebas lo cual permitiacutea evaluar la calidad del producto que seriacutea entregado al cliente
Ademaacutes se realizaraacute un marco teoacuterico donde se resumiraacuten una clasificacioacuten de los diferentes tipos de
pruebas software que pueden realizarse sobre una aplicacioacuten
Concretamente la solucioacuten abordada en esta memoria se cintildee al mantenimiento de un producto Web como
es la plataforma Galgus CHT Cloud Manager Para ello se cubriraacuten un gran conjunto de funcionalidades
ofrecidas por dicha aplicacioacuten Web como por ejemplo inicio y cierre de sesioacuten flujos de navegacioacuten
comprobacioacuten de los elementos mostrados y uso de la caja de buacutesquedas Sin llegar a ser exhaustivos este
tipo de pruebas conocidas como smoke tests son faacutecilmente automatizables y permiten detectar las primeras
sentildeales de que un sistema no funciona de manera correcta Por tanto es necesario traducir los requisitos
funcionales a instrucciones de alto nivel faacutecilmente entendibles por personas con poca formacioacuten teacutecnica
dado que seraacute el el resultado mostrado de las pruebas realizadas (informes de pruebas) Estas instrucciones
usaraacuten Behaviour-Driven Development (BDD) para describir interacciones entre el usuario y el sistema
definiendo actor accioacuten y comportamiento esperado del sistema Robot Framework es la herramienta que
se usa para este punto
Una vez tenemos dichas instrucciones se deben traducir de nuevo a un lenguaje de menor nivel como es
Python para implementar los test scripts Estos scripts seraacuten los que Selenium Webdriver procese y traduzca
para comunicarse con el controlador del navegador Web Chrome en nuestro caso a traveacutes de una API
Posteriormente el navegador se encargaraacute de ejecutar los comandos de accioacuten y de devolver la informacioacuten
de estado de vuelta Finalmente Robot Framework elaboraraacute un informe en formato html detallando las
pruebas realizadas resultados de las interacciones tiempos de ejecucioacuten y espera errores producidos etc
Tambieacuten se realizaraacute un estudio del arte sobre una teacutecnica conocida como Model Based Testing (MBT)
Dicha teacutecnica permite la generacioacuten automaacutetica de las pruebas a realizar sobre un sistema partiendo del
modelado del comportamiento de dicho sistema Ademaacutes esta teacutecnica tambieacuten abarca la traduccioacuten de las
pruebas generadas en scripts ejecutables para aplicar dichas pruebas sobre el sistema dando tambiacuteeacuten la
posibilidad de evaluar los resultados Esto proporciona muchas ventajas sobre la fase de pruebas pero a la
vez tambieacuten requiere un mayor esfuerzo en la fase de disentildeo y una presencia continua de la fase de pruebas
en otras etapas del ciclo de vida del proyecto Tambieacuten se presentaraacute un conjunto de normativas que regula
y normaliza la gestioacuten de calidad software
Posteriormente se describiraacute el sistema sobre el cual se basa la aplicacioacuten bajo pruebas llamada CHT
Cloud Manager Se presentaraacute la arquitectura de la aplicacioacuten y posteriormente se destacaraacuten los objetivos
de automatizacioacuten de testeo sobre la misma proponiendo el entorno de UAT planteado para someter la
aplicacioacuten a las pruebas automaacuteticas desarrolladas Se dedicaraacute una seccioacuten a analizar las tecnologiacuteas y
herramientas usadas donde se centraraacute la atencioacuten en Robot Framework Selenium y Python como las
tecnologiacuteas usadas para automatizar el testeo Ademaacutes se destacaraacute la integracioacuten del entorno de UAT
como fase de la integracioacuten continua de la aplicacioacuten ademaacutes de la metodologiacutea de trabajo llevada a cabo
Finalmente se presentaraacuten algunos experimentos y demostraciones de uso de la herramienta desarrollada
se describiraacuten algunas liacuteneas de mejora y conclusiones y se incluiraacuten algunos posibles anexos para la puesta
en marcha de la aplicacioacuten y reportes de algunas pruebas entre otros
30
13 Estructura de la memoria
El siguiente esquema resume de forma geneacuterica los puntos tratados en esta memoria para que el lector pueda
tener una idea orientativa de la organizacioacuten de este documento
1 Introduccioacuten En este punto se abordan temas geneacutericos como los objetivos motivacioacuten y alcance de
forma que pueda adquirirse una breve aproximacioacuten a los detalles del proyecto
2 Estudio del Arte y Revisioacuten A lo largo de esta seccioacuten se presentaraacute un estudio sobre la teacutecnica
conocida como Model Based Testing la cual permitiriacutea mejorar el proceso de automatizacioacuten de
pruebas Ademaacutes se realiza una revisioacuten sobre la gestioacuten de Calidad Software presentado algunos
modelos existentes en la actualidad
3 Marco Teoacuterico Consta de un estudio sobre el proceso de pruebas en un proyecto Software y los
principales tipos de pruebas Software existentes
4 Sistema En este punto se presenta la arquitectura del sistema sobre el que se van a automatizar las
pruebas de aceptacioacuten o Smoke Tests Ademaacutes se describe el alcance y objetivos de dichas pruebas y
se presenta la arquitectura de la solucioacuten planteada como escenario de pruebas haciendo uso de Docker
como tecnologiacutea de automatizacioacuten en el despliegue de aplicaciones software alojadas en contenedores
de software
5 Tecnologiacuteas y Herramientas usadas Consta del conjunto de tecnologiacuteas usadas para la
implementacioacuten de las pruebas de aceptacioacuten automatizadas y las herramientas para utilizar dichas
pruebas y para gestionar el trabajo del equipo de desarrollo y calidad responsable de este proyecto
6 Experimentos Consta de un detalle sobre la funcionalidad de un conjunto de pruebas que han sido
implementadas para verificar y validar el funcionamiento esperado del sistema Para cada prueba se
definen criterios de aceptacioacuten diagramas de flujo y scripts de implementacioacuten detallando algunas de
las implementaciones clave
7 Liacuteneas de Mejora y Conclusiones Se incluye una seccioacuten conclusiones finales tras la realizacioacuten del
proyecto y una valoracioacuten del mismo a nivel general y personal Ademaacutes se destacaraacuten algunas liacuteneas
de mejora futuras relacionadas principalmente con la aplicacioacuten de Model Based Testing (MBT) y otros
aspectos sobre la implementacioacuten actual de la herramienta de automatizacioacuten
Ademaacutes se realizaraacute una seccioacuten de anexos en el que se trataraacuten puntos adicionales sobre el proyecto
bull Anexo A Preparacioacuten del Entorno de Trabajo y Ejecucioacuten de Pruebas
bull Anexo B Docker de Robot Framework y Entorno de UAT Dockerizado
bull Anexo C Revisioacuten de Reportes y Logs
31
32
2 ESTUDIO DEL ARTE Y REVISIOacuteN
n este punto se realizaraacute un estudio sobre el marco teoacuterico de una de las teacutecnicas existentes que permite
la generacioacuten y ejecucioacuten automaacutetica de casos de test a partir del modelado de un sistema para la fase
de pruebas de una aplicacioacuten Esta teacutecnica es conocida como Model Based Testing (MBT) Ademaacutes
se realizaraacute una revisioacuten de la normativa relacionada con la gestioacuten de calidad software analizando la familia de
normas ISOIEC 25000
21 Model Based Testing (MBT)
211 Introduccioacuten
Dada la rapidez con la que se demandan los servicios contratados por los clientes en muchas ocasiones la
mayoriacutea del tiempo y esfuerzo asignado para la realizacioacuten de proyectos de software van destinados a la
labor de desarrollo dedicando menos esfuerzos en otras fases del ciclo de vida de un proyecto como las
fases de disentildeo o de pruebas Esto puede conllevar a que el proyecto no se desarrolle de acuerdo con los
requisitos demandados por los clientes y que el nuacutemero de puntos de fallo del producto software aumente
La fase de testeo o prueba de un producto software durante su ciclo de vida es una etapa fundamental para
validar la calidad del producto desarrollado y ofrecido a un cliente para conseguir un grado de satisfaccioacuten
aceptable de forma que se cumpla con los requisitos demandados y con el menor grado de error posible
Figura 3 Fase de Pruebas y Validacioacuten
Uno de los factores por los que en ocasiones no se emplean suficientes recursos a la fase de pruebas es la
gran cantidad de casos de pruebas que se deben realizar para validar un sistema Por cada caso de prueba
se deben asignar recursos relacionados con la planificacioacuten disentildeo y ejecucioacuten del mismo
Por tanto en este punto cabe plantearse la idea de automatizar no solo los casos de pruebas que validan un
sistema sino la generacioacuten de los casos de prueba Esto puede permitir reducir de forma considerable el
coste y esfuerzos en la fase de pruebas En este contexto surge el concepto de Model Based Testing (MBT)
E
La tecnologiacutea no es en siacute el fin sino el medio entre la
sociedad del conocimiento y el desarrollo mundial
Anoacutenimo
33
212 iquestQueacute es Model Based Testing
Este se trata de un meacutetodo capaz de controlar la calidad del software durante su ciclo de vida permitiendo
la generacioacuten automaacutetica de los casos de prueba e incluso la ejecucioacuten y evaluacioacuten automaacutetica de
resultados Para ello se requiere de un modelado y disentildeo correcto del sistema bajo pruebas como base
para la aplicacioacuten de esta teacutecnica
Figura 4 Esquema baacutesico de Model Based Testing
MBT permite crear un modelo del comportamiento esperado por el sistema a traveacutes del cual permite la
aplicacioacuten de diferentes teacutecnicas para la generacioacuten de casos de prueba [1]
bull Generacioacuten de casos de pruebas con datos de entrada sobre un modelo de dominio del sistema bull Generacioacuten de casos de pruebas de un modelo de entorno bull Generacioacuten de casos de prueba con predicciones del comportamiento del modelo bull Generacioacuten de scripts de prueba a partir de pruebas abstractas
213 iquestCoacutemo funciona Model Based Testing
En primer lugar se requiere del disentildeo de un modelo del sistema bajo test el cual debe tener al menos dos
caracteriacutesticas principales debe ser pequentildeo en relacioacuten al tamantildeo del sistema de forma que no requiera
un coste elevado pero debe ser lo suficientemente detallado para describir completamente las
caracteriacutesticas que se quieran probar sobre el sistema
Una vez implementado el modelo del sistema a probar se procederiacutea a la utilizacioacuten de herramientas
basadas en la teacutecnica MBT para generar automaacuteticamente el banco de pruebas a partir del modelo del
sistema bajo test (SUT) Estos bancos de pruebas generados seraacuten un conjunto de pruebas abstractas cada
una de las cuales define la secuencia de operaciones a realizar para probar una funcionalidad determinada
con sus respectivos valores o datos de entrada necesarios y las salidas o respuestas del sistema que se
esperan
A partir del banco de pruebas abstractas se deben transformar en scripts de pruebas ejecutables lo cual
puede realizarse con herramientas basadas en la teacutecnica MBT Estos scripts podriacutean ser ejecutados para la
deteccioacuten de errores sobre el sistema bajo test y esta ejecucioacuten podriacutea ser controlada y monitorizada por
alguna herramienta de ejecucioacuten de pruebas
En el siguiente diagrama se muestra el proceso de aplicacioacuten de este meacutetodo donde se propone dividir el
proceso en cinco fases principales [1]
1 Modelado Modelar el sistema bajo test y su entorno 2 Generacioacuten Generar las pruebas abstractas a partir del modelo planteado en la fase anterior 3 Concretizado Concretizar o adaptar las pruebas abstractas para transformarlas en ejecutables 4 Ejecucioacuten Ejecutar las pruebas sobre el sistema bajo test y definir decisiones o veredictos para las
mismas de forma que se pueda determinar el correcto funcionamiento del sistema bajo test 5 Anaacutelisis Analizar los resultados obtenidos a partir de la ejecucioacuten de los casos de prueba
34
Destacar que para el generador de casos de prueba y el script de pruebas se suelen usar herramientas de pruebas
especiales Por este motivo se encuentran resaltados en negrita
Figura 5 Proceso detallado de Model Based Testing (MBT)
Una vez presentado el proceso o metodologiacutea para llevar a cabo dicha teacutecnica se describiraacuten las principales
fases
2131 Construccioacuten del Modelo
Dicha fase consiste en la construccioacuten de un modelo que represente el comportamiento detallado del sistema
bajo pruebas yo su entorno a partir de los requisitos de disentildeo del mismo y el plan de pruebas desarrollado para
cumplir con estos requisitos
Este es el paso maacutes importante en la aplicacioacuten de la teacutecnica Model Based Testing ya que el resto de fases
dependeraacute siempre del modelo del sistema bajo pruebas Cuanto maacutes completo sea el modelo maacutes efectivos
seraacuten los casos de prueba generados a partir de este
Figura 6 Construccioacuten del Modelo
35
Para llevar a cabo el modelo del comportamiento de la aplicacioacuten se requiere conocer exactamente el
comportamiento esperado de la misma lo cual lleva a estudiar y analizar en profundidad el sistema y su entorno
previamente
Existen diversas especificaciones formales para el modelado a partir de los requisitos como por ejemplo los
diagramas UML Estos ayudan a que el modelado sea una tarea algo maacutes sencilla de realizar que si se llevara a
cabo a partir de los requisitos escritos en lenguaje natural Por otro lado para modelar el comportamiento existen
diversas teacutecnicas como las maacutequinas de estados finitos (FSM) Cadenas de Maacuterkov Tablas de decisiones
Diagramas de estados etc
En conclusioacuten modelar un sistema no es una tarea sencilla ya que requiere de habilidades teacutecnicas experiencia
e imaginacioacuten para construir un modelo que se comporte de la forma deseada Dicho modelo debe cumplir con
las siguientes propiedades [2]
bull Debe ser lo maacutes abstracto posible sin perder la informacioacuten importante
bull No debe contener informacioacuten que sea redundante o que no esteacute relacionada con el alcance de las
pruebas
bull Debe ser entendible para los ingenieros de pruebas incluso a expensas de la brevedad y abstraccioacuten del
mismo
bull Debe ser flexible y abierto para permitir cambios y antildeadir o eliminar nuevas funcionalidades
bull Debe considerar todos los detalles de implementacioacuten de las pruebas
2132 Generacioacuten de Casos de Prueba
Los casos de prueba seraacuten generados tras la construccioacuten previa del modelo del sistema Antes de la creacioacuten de
los casos de prueba los ingenieros de pruebas deben especificar o proveer informacioacuten sobre el criterio o
propoacutesito de los casos de prueba las entradas y en algunos casos las salidas esperadas del sistema
Destacar que generar las salidas esperadas correspondientes a unas determinadas entradas es maacutes complejo que
generar soacutelo las entradas Para ello se necesita un oraacuteculo que cree salidas vaacutelidas y las mapee a los casos de
prueba Crear el oraacuteculo es la tarea maacutes compleja
Las dificultades presentadas en esta fase dependeraacuten de si el modelo es complejo o simple y la efectividad de
los casos de prueba generados dependeraacute de lo completo y preciso que sea dicho modelo para poder generar
automaacuteticamente los casos de prueba
Cuando el sistema es complejo la cantidad de casos de test es muy grande e incluso infinita Por tanto evaluar
todos los casos de test resulta inviable y costoso En este caso para mejorar la calidad del sistema se necesita
seleccionar los casos de test que realmente puedan ayudar a localizar tantos fallos como sea posible con un coste
aceptable
Existen diferentes criterios de cobertura que permiten ayudar a controlar el proceso de generacioacuten de casos de
prueba Sin embargo se recomienda seleccionar maacutes de uno de estos criterios para lograr un mayor resultado en
la cobertura de pruebas
2133 Ejecucioacuten de Casos de Prueba
La ejecucioacuten de los casos de pruebas requiere la transformacioacuten de los mismos en una forma ejecutable Debido
a que los los scripts de pruebas ejecutables pueden ser reutilizados durante todo el tiempo empleado en la
validacioacuten del sistema estos deben ser escritos de una forma maacutes eficiente que permita que sean reutilizables e
incluso que frente a una modificacioacuten sean maacutes faacuteciles generarlos y ejecutarlos Por ello se crean scripts
ejecutables para los casos de prueba abstractos
El proceso de transformacioacuten en pruebas ejecutables seriacutea maacutes eficiente si es hecha de forma automaacutetica
Despueacutes de aplicar los casos de prueba ejecutables al sistema bajo pruebas se obtienen las salidas actuales del
sistema las cuales deberaacuten ser contrastadas con las salidas esperadas
36
2134 Anaacutelisis de los Resultados
Una vez ejecutados los casos de pruebas y obtenidas las salidas actuales del sistema se deben evaluar y analizar
los resultados obtenidos Para ello se debe comparar las salidas actuales obtenidas con las salidas esperadas
especificadas en los casos de prueba Esta tarea de comparacioacuten podriacutea realizarse idealmente de forma
automaacutetica lo cual dariacutea como resultados posibles
1 Pasa Cuando las salidas actuales se encuentran acordes con las salidas esperadas
2 Falla Cuando las salidas actuales no se encuentran acordes con las salidas esperadas
3 Inconcluso Cuando no se puede tomar una decisioacuten en el momento
Hay que destacar que puede darse el caso en el que si las salidas esperadas no estaacuten bien determinadas los
resultados obtenidos al contrastar dichas salidas con las actuales sean falsos dando lugar a resultados sin utilidad
y que pueden dar lugar a confusioacuten
Por este motivo la generacioacuten automaacutetica de las salidas esperadas es una tarea compleja e importante en todo el
proceso especialmente en sistemas complejos Por tanto el nivel de dificultad para encontrar un oraacuteculo de
pruebas depende del tamantildeo y complejidad del sistema Sin embargo la necesidad e importancia del oraacuteculo de
pruebas tambieacuten aumenta cuando el sistema es maacutes complejo
Tras obtener los resultados se debe determinar si se decide generar maacutes casos de prueba si se debe modificar el
modelo o si la fase de pruebas debe ser detenida y debe ponerse en marcha el software del sistema que se estaacute
probando
214 Consideraciones para la aplicacioacuten de Model Based Testing (MBT)
Son muchos los artiacuteculos que describen aspectos importantes a tener en cuenta durante el desarrollo o la
aplicacioacuten de esta teacutecnica Algunas de estas consideraciones a destacar seriacutean las siguientes [3]
1 El modelo que describe el comportamiento del sistema es el punto clave
El comportamiento del modelo debe ser desarrollado cuidadosamente Sus limitaciones y restricciones deben
ser respetadas durante el modelado del sistema bajo pruebas De esta forma si el modelo estaacute mal las pruebas
generadas tambieacuten lo estaraacuten Por tanto la exactitud del modelo es fundamental para pasar a la fase de
generacioacuten de casos de prueba
2 Las pruebas deben cubrir los criterios de control de flujo y datos
Los criterios de cobertura de las pruebas definen un conjunto de casos de prueba seleccionados para la misma
Estos casos de pruebas pueden ser generados a partir de dos fuentes criterios de flujo de control o de flujo
de datos En el caso de pruebas aplicadas a grandes sistemas es importante combinar ambos criterios para
incrementar la cobertura de las pruebas
3 El nivel de automatizacioacuten debe ser elevado
El nivel de automatizacioacuten es un factor importante para definir la factibilidad de uso de MBT Normalmente
suele haber un uacutenico paso no automatizado el modelado del comportamiento del sistema el cual es utilizado
como entrada para el proceso de generacioacuten de los casos de prueba Si hubiese otros pasos no automatizados
se incrementariacutea el esfuerzo los costes y la complejidad de su uso
4 Son fundamentales las herramientas que soportan la automatizacioacuten de las fases de MBT
Las herramientas usadas deben soportar la ejecucioacuten de los pasos automatizados Si no hay una herramienta
que soporte un determinado paso esta tarea podriacutea ser difiacutecil e inviable Por tanto una herramienta debe
soportar la integracioacuten entre los diferentes pasos no automatizados y automatizados
5 Los liacutederes del proyecto deben entender las habilidades requeridas y la complejidad para usar
MBT
Las personas encargadas de la fase de pruebas necesitan conocer ademaacutes de las teacutecnicas de pruebas los
lenguajes de modelado y algunos lenguajes de programacioacuten
37
6 El orden de los pasos a seguir mientras se usa un enfoque MBT
Es necesario respetar los pasos seguidos para la generacioacuten de los casos de prueba de forma que sean
respetados en la fase de ejecucioacuten de las pruebas siendo ejecutados en la misma secuencia en que fueron
definidos En caso contrario se podriacutean generar salidas erroacuteneas de dichas pruebas
7 Transferencia de la Tecnologiacutea
Las tecnologiacuteas usadas para la aplicacioacuten de la teacutecnica MBT se transfieren desde entornos acadeacutemicos o de
investigacioacuten para ser implementados en proyectos industriales Por este motivo necesitan ser analizados
cuidadosamente antes de ser usadas
215 Beneficios de Model Based Testing (MBT)
A continuacioacuten se definen diversos beneficios que proporciona la aplicacioacuten de Model Based Testing para la
fase de pruebas [1] [4]
1 Deteccioacuten de Fallos del Sistema Bajo Pruebas
El modelado del comportamiento del sistema bajo pruebas permite detectar errores ambiguumledades o lagunas
que pueden presenciarse en la toma de requisitos especificacioacuten y disentildeo del software Por tanto permite
una deteccioacuten temprana de errores
2 Reduccioacuten de costes y tiempo en la fase de pruebas
La aplicacioacuten de esta teacutecnica contribuye a que el tiempo coste y recursos empleados a la fase de pruebas
disminuya Sin embargo se requiere una mayor asignacioacuten de recursos para el modelado y mantenimiento
del sistema
3 Mejora de la calidad de las pruebas
Cuando las pruebas se desarrollan manualmente la calidad de las mismas es muy dependiente de los
desarrolladores que la implementan Ademaacutes el proceso de disentildeo no puede ser reproducido el criterio
racional aplicado para cada prueba normalmente no es recordado y el resultado de los casos de prueba no es
faacutecilmente interpretado ni contrastado con los requisitos originales del sistema
Model Based Testing es una teacutecnica capaz de mejorar mucho estos inconvenientes que se presentan sobre el
desarrollo de pruebas manuales gracias al generador automatizado de casos de prueba
4 Trazabilidad
Puede definirse como la habilidad para relacionar cada caso de prueba al modelo criterio de seleccioacuten e
incluso a los requisitos informales del sistema Esto ayuda a explicar los casos de prueba asiacute como justificar
por queacute fueron creados Los algoritmos aplicados para la generacioacuten de pruebas deben saber queacute partes del
modelo seraacuten empleadas en cada caso de prueba y las salidas esperadas
5 Evolucioacuten de los requisitos
Si los requisitos del sistema cambian con la aplicacioacuten de Model Based Testing bastariacutea con actualizar el
modelo y las pruebas seraacuten generadas de nuevo de forma automaacutetica Debido a que el modelo es usualmente
maacutes pequentildeo que el conjunto de pruebas del sistema requiere menos tiempo actualizar el modelo que
actualizar todos los casos de prueba Por tanto puede concluirse que se obtiene una respuesta maacutes raacutepida
frente a un cambio en los requisitos
6 Reusabilidad del modelo
El modelo contiene informacioacuten sobre el comportamiento del sistema bajo pruebas Por tanto este puede ser
reutilizado en futuras pruebas incluso cuando los requisitos cambian
38
216 Problemas y Limitaciones de Model Based Testing (MBT)
Una vez destacados los beneficios que aporta dicha teacutecnica tambieacuten es importante detallar algunos problemas
y limitaciones sobre su uso [1] [5]
2161 Problemas
bull Para abordar dicha teacutecnica es necesario que los ingenieros de pruebas tengan habilidades teacutecnicas sobre
la notacioacuten usada para el modelado del sistema Ademaacutes deberiacutean tener experiencia con herramientas
scripts y lenguajes de programacioacuten usados para ejecutar las tareas de Model Based Testing
bull Cuando dicha teacutecnica se pretende aplicar a sistemas complejos el modelado del sistema es maacutes
complejo y existe riesgo de producirse un desbordamiento de la cantidad de casos de prueba generados
a partir del modelo Por esta razoacuten es muy importante definir bien el conjunto de criterios para la
generacioacuten de las pruebas lo cual permite acotar la cobertura de pruebas de forma razonable
bull La automatizacioacuten de la generacioacuten del oraacuteculo de pruebas a partir del modelo es compleja
especialmente en sistemas complejos Cuando el tamantildeo del sistema aumenta la necesidad de
automatizacioacuten tambieacuten aumenta
bull Es necesario desarrollar un modelo de software especiacutefico para un dominio en concreto de aplicacioacuten
ya que existen diversas notaciones de modelado del sistema
bull Es necesario la especificacioacuten formal de los requisitos para obtener el modelo del sistema a partir de
estos La especificacioacuten informal o en lenguaje natural de los requisitos puede dar lugar a ambiguumledades
que dificultan la exactitud en el modelado
2162 Limitaciones
bull No es posible modelar todos los aspectos del comportamiento del sistema bajo pruebas Por tanto es
necesario el uso de otras notaciones de modelado que cubran dichos aspectos
bull Los proyectos software evolucionan continuamente surgiendo nuevos requisitos los cuales algunos
pueden quedar fuera de la fecha de planificacioacuten Si se ha comenzado con el modelado a partir de
requisitos antiguos se construiraacute un modelo erroacuteneo que no reflejaraacute los nuevos requisitos
contemplados lo cual daraacute lugar a errores en el sistema bajo pruebas o resultados no fiables
bull Cuando se produce un fallo en una prueba generada podriacutea resultar maacutes complejo determinar la causa
del fallo ya que la secuencia de pruebas generadas en Model Based Testing podriacutea ser maacutes compleja y
menos intuitiva que las disentildeadas manualmente
217 Cuando elegir Model Based Testing (MBT)
Finamente tras detallar los beneficios problemas y limitaciones sobre la teacutecnica bajo estudio se destacan
algunos puntos principales a tener en cuenta para la aplicacioacuten de dicha teacutecnica
bull Debe existir documentacioacuten lo suficientemente buena sobre el sistema para poder aplicarla
bull Si ya existe un modelo del sistema seriacutea un primer paso que facilitariacutea su aplicacioacuten
bull El manager del proyecto debe ser consciente que la fase de pruebas con Model Based Testing comienza
desde la toma de requisitos ya que se debe modelar el comportamiento del sistema bajo pruebas a partir
de estos Por tanto no se puede esperar que la fase de pruebas comience despueacutes del desarrollo Hacerlo
tras el desarrollo podriacutea significar la modificacioacuten de los requisitos y en consecuencia el desarrollo
39
22 Gestioacuten de Calidad Software
221 Introduccioacuten
En los uacuteltimos antildeos la creciente demanda de productos software principalmente de aplicaciones distribuidas
como los servicios Web provoca que diferentes empresas busquen soluciones software para satisfacer las
necesidades de los clientes Este conjunto de empresas forma un entorno competitivo en el que se intenta buscar
algunos factores para destacar sobre los demaacutes competidores respondiendo a las nuevas exigencias del mercado
Bajo este contexto se plantea la implantacioacuten de una direccioacuten basada en la calidad como la propuesta que
mejores resultados ha ofrecido No solo basta con desarrollar software acorde a los requisitos de los clientes y
las exigencias de los mismos sino que se trata de crear un producto que garantice su correcto funcionamiento
bajo el sustento de una garantiacutea de calidad razonable
El concepto de ldquocalidadrdquo siempre se ha relacionado con la inspeccioacuten de productos fiacutesicos Pero dicho teacutermino
ha ido expandiendo su contexto de una forma maacutes global y aplicable a cualquier tipo de servicio o producto
ofrecido a un cliente
222 Concepto de Calidad
Acorde a la definicioacuten ofrecida por la Real Academia Espantildeola (RAE) la calidad se define como ldquouna propiedad
o conjunto de propiedades inherente a algordquo ldquoAdecuacioacuten de un producto o servicio a las caracteriacutesticas
especificadasrdquo o ldquocondicioacuten o requisito que se pone en un contratordquo [6]
Por otro lado el instituto de Ingenieros Eleacutectricos y Electroacutenicos (IEEE) define la calidad como ldquoel grado con
el que un sistema componente o proceso cumple con los requisitos especificados y las necesidades o
expectativas del cliente o usuariordquo destacando que el eacutenfasis radica en los requisitos especiacuteficos del sistema y
en la buacutesqueda de la satisfaccioacuten del cliente [7]
Roger Pressmann define la Calidad del Software como ldquoConcordancia del software producido con los requisitos
expliacutecitamente establecidos con los estaacutendares de desarrollo prefijados y con los requisitos impliacutecitos no
establecidos formalmente que desea el cliente y en uacuteltima instancia el usuariordquo [8]
Una vez presentado el concepto de calidad su definicioacuten orientada al software se refiere al grado de desempentildeo
de las principales caracteriacutesticas con las que debe cumplir un sistema durante su ciclo de vida Estas
caracteriacutesticas son las que garantizan que el cliente cuente con un sistema confiable lo que permite un aumento
de la satisfaccioacuten frente a la funcionalidad y eficiencia del sistema construido
Figura 7 Concepto de Calidad
40
223 Modelos de Calidad de Software
Los modelos de calidad son aquellos documentos que integran la mayor parte de las mejores praacutecticas proponen
temas de administracioacuten en los que cada organizacioacuten debe hacer eacutenfasis integran diferentes praacutecticas dirigidas
a los procesos clave y permiten medir los avances en calidad
Bajo este contexto los modelos de calidad deben permitir la evaluacioacuten del sistema de forma cualitativa o
cuantitativa y de acuerdo con esta evaluacioacuten la organizacioacuten podraacute proponer implementar estrategias que
permitan la mejora continua en el resto de etapas del ciclo de vida como son las etapas de anaacutelisis disentildeo
desarrollo y pruebas software [7] Desde finales de los antildeos 70 se han ido desarrollando diversos modelos de
calidad del producto software con el fin de fijar una terminologiacutea y entender queacute concepto de calidad se estaacute
usando Asiacute mismo dichos modelos de calidad se clasifican de acuerdo con el enfoque de evaluacioacuten
contemplado ya sea a nivel de proceso producto o calidad de uso
2231 Calidad a Nivel de Proceso
Este enfoque de calidad de software describe que la calidad de un sistema software debe ser implementada desde
el inicio del proyecto y en cada etapa de su ciclo de vida debiendo permitir el control y seguimiento de los
aspectos de calidad para minimizar los riesgos y ofrecer un soporte continuo De esta forma se consigue
garantizar un nivel oacuteptimo de cumplimiento de los factores de calidad definidos teniendo en cuenta que si en
alguna etapa no se verifican dichos factores posiblemente disminuya el nivel de calidad no solo del proceso si
no tambieacuten del producto en desarrollo [7]
A continuacioacuten se muestra una liacutenea de tiempo de algunos modelos a nivel de proceso y se describen dos de los
que maacutes intereacutes presentan dentro del aacutembito de este proyecto
Figura 8 Liacutenea de tiempo de modelos a nivel de proceso
ITIL (Information Technology Infrastructure Library)
Desarrollado en el Reino Unido con el fin de fortalecer la gestioacuten gubernamental a partir de cinco elementos
fundamentales la perspectiva del negocio entrega del servicio soporte del servicio manejo de la infraestructura
y manejo de aplicaciones con el propoacutesito de ofrecer una estructura integral para prestar a la organizacioacuten un
servicio completo cubriendo necesidades de apoyo de instalacioacuten adecuacioacuten de redes comunicaciones
hardware servidores sistema operativo y software necesarios
Figura 9 Logo de ITIL
41
ISOIEC 20000
El objetivo principal de esta norma es avalar que la prestacioacuten de servicios de TI en una empresa cuenta con la
calidad necesaria para brindar dichos servicios a los clientes Esta norma engloba diferentes secciones dedicadas
a las especificaciones de dicha norma y a los coacutedigos de buenas praacutecticas
Figura 10 ISOIEC 20000
WebQEM
Web-site Quality Evaluation Method se trata de una metodologiacutea de evaluacioacuten de calidad de sitios Web en seis fases planificacioacuten y programacioacuten de la evaluacioacuten de la calidad definicioacuten y especificacioacuten de los requisitos de calidad establecidos definicioacuten e implementacioacuten de la evaluacioacuten elemental definicioacuten e implementacioacuten de la evaluacioacuten global anaacutelisis de resultados y evaluacioacuten de meacutetricas y finalmente conclusiones y documentacioacuten
Figura 11 Logo de WebQEM
42
2232 Calidad a Nivel de Producto
El enfoque de la calidad de software a nivel de producto tiene como objetivo especificar y evaluar el
cumplimiento de los criterios del producto Para ello se suelen definir y aplicar medidas o meacutetricas internas o
externas Por esta razoacuten muchas normas definen la calidad a nivel de producto de tipo interna externa y en uso
Esta uacuteltima se define como el conjunto de atributos relacionados con la aceptacioacuten por parte del usuario final y
seguridad
A continuacioacuten se muestra una liacutenea de tiempo de algunos modelos a nivel de proceso y se describen tres de los
que maacutes intereacutes presentan dentro del aacutembito de este proyecto
Figura 12 Liacutenea de tiempo de modelos a nivel de producto
ISO 9126
Este se basa en el modelo McCall el cual es uno de los modelos pioneros en la evaluacioacuten de la calidad de
software Desarrollado en 1991 es un marco normativo dirigido a desarrolladores aseguradores de calidad
evaluadores analistas y cualquier otro involucrado en el proceso de construccioacuten de software y la gestioacuten de
calidad del mismo Estaacute dividido en cuatro partes Modelo de Calidad Meacutetricas Externas Meacutetricas Internas y
Calidad de Meacutetricas en Uso
Esta norma busca la fiabilidad funcionalidad usabilidad eficiencia mantenibilidad y portabilidad en la
construccioacuten de productos software A continuacioacuten se muestra un esquema que resume dichas caracteriacutesticas
y subcaracteriacutesticas [8]
Figura 13 Esquema de ISO 9126
43
ISOIEC 25000
Basada en la norma ISO 9126 y adaptando parte del marco normativo a las necesidades del mercado actual Esta
norma tambieacuten conocida como SQuaRE (Software Product Quality Requirements and Evaluation) establece
un marco de trabajo comuacuten para evaluar la calidad de productos de Software
En dicha norma se definen los modelos teacuterminos y definiciones comunes para el resto de normas que componen
la serie 25000 La ISOIEC 25000 presenta diversas secciones entre las que se puede destacar [9]
ISOIEC 25010 Describe las caracteriacutesticas y subcaracteriacutesiticas de calidad que pueden ser evaluadas
en un producto software diferenciando entre calidad interna externa y de uso En la siguiente figura se
presenta un desglose de dichas caracteriacutesticas
ISOIEC 25040 Define el proceso de evaluacioacuten perioacutedico de la calidad del producto software
Figura 14 Esquema de ISOIEC 25000
44
224 Principales Ventajas e Inconvenientes de Modelos de Calidad anteriores
2241 A nivel de Proceso
Modelo Ventajas Inconvenientes
ITIL bull Mejor estructuracioacuten organizacioacuten y
claridad de los proyectos
bull Mayor control administrativo
bull Mayor eficacia y rapidez ante cambios
bull Incrementa la productividad del negocio y la
fiabilidad de los clientes
bull Tiempo y esfuerzo necesarios
bull Falta de conocimiento para apreciar la mejora
proporcionada
bull Involucracioacuten y compromiso de todo el
personal de la organizacioacuten
bull Frustracioacuten generada por expectativas a corto
plazo
bull No hay mejoriacutea si la inversioacuten asignada para
implantar el modelo es insuficiente
ISOIEC
20000 bull Reconocimiento internacional
bull Muy usado por las organizaciones
WebQUEM bull Calidad medida en fases y actividades de
forma cuantitativa con indicadores
bull Aplicaciones de Software centradas en la Web
son cada vez maacutes complejas provocan mayor
complejidad en su implantacioacuten
2242 A nivel de Producto
Modelo Ventajas Inconvenientes
ISO 9126 bull Determina queacute caracteriacutesticas y
subcaracteriacutesticas son importantes para el
producto
bull Define meacutetricas especiacuteficas para los
componentes Software
bull Define indicadores para las caracteriacutesticas de
calidad
bull Usabilidad tratada desde la perspectiva del
proceso no del producto
bull No tiene en cuenta la caracteriacutestica de ldquofacilidad
de aprendizajerdquo siendo esta recomendada por
otros estaacutendares
bull Meacutetricas complejas difiacutecilmente medibles
Requieren descomposicioacuten
ISOIEC
25000 bull Detecta objetivos del producto alineados con
necesidades reales de clientes finales
bull Evita ineficiencias y maximiza rentabilidad
y calidad del producto
bull El proceso de evaluacioacuten perioacutedica permite
la mejora continua
bull No establece niveles de calidad para cada
proyecto
bull No hace uso de meacutetricas o umbrales de calidad
225 Conclusiones
Una vez presentado el concepto de gestioacuten de calidad de software y los principales modelos y normas es
interesante destacar la diferencia entre calidad interna y externa La calidad interna se centra en las caracteriacutesticas
propias del producto software (disentildeo especificacioneshellip) mientras que la calidad externa lo hace con las
caracteriacutesticas dinaacutemicas del mismo es decir con el comportamiento Es por ello que el proceso de calidad
interna se inicia en las fases tempranas del ciclo de vida de un proyecto mientras la calidad externa se aplica
una vez se tiene un primer prototipo funcional del producto software desarrollado Por tanto se trataraacute de
automatizar el proceso de evaluacioacuten de la calidad externa del proyecto CHT Cloud Manager analizando
verificando y validando automaacuteticamente la aceptacioacuten de dicho producto
45
46
3 MARCO TEOacuteRICO PRUEBAS DE SOFTWARE
ras presentar el concepto de calidad y algunas de las normas y estaacutendares maacutes conocidos que describen
la aplicacioacuten de dicho concepto en el aacutembito del desarrollo de software se centraraacute el enfoque en el
papel del testeo y las pruebas de software Con ello se destacaraacuten algunos puntos principales para
llevar a cabo las pruebas de software el anaacutelisis disentildeo e implementacioacuten de dichas pruebas los diferentes tipos
y niveles de pruebas y las dificultades de la aplicacioacuten de pruebas de software sobre aplicaciones Web
31 Testing y Pruebas de Software
Habitualmente se tiene una percepcioacuten del testing de un producto como una tarea basada en la ejecucioacuten de
pruebas de forma repetitiva para la buacutesqueda de errores o problemas que puedan repercutir sobre la calidad del
mismo Pero el testing no solo se basa en la realizacioacuten de pruebas
Se deben identificar otras tareas que estaacuten relacionadas con el testing las cuales se llevan a cabo antes y despueacutes
de la ejecucioacuten de pruebas Estas tareas estaacuten relacionadas principalmente con la planificacioacuten y control del
proceso de pruebas el disentildeo de los diferentes casos de prueba o test cases y la posterior comprobacioacuten de los
resultados obtenidos tras llevar a cabo las pruebas Otras tareas podriacutean ser la propia evaluacioacuten de los diferentes
criterios de finalizacioacuten del proceso de pruebas el anaacutelisis de informes de resultados o la revisioacuten de la
documentacioacuten generada en la fase de pruebas
A continuacioacuten se citan algunas definiciones para explicar el concepto de pruebas de software
ldquoUna prueba es una actividad ejecutada para evaluar la calidad del producto software y mejorarlo mediante
la identificacioacuten de problemas errores o defectos en su funcionamiento [9]rdquo
ldquoLas pruebas de Software consisten en verificaciones dinaacutemicas del comportamiento del software bajo
pruebas mediante un conjunto finito de casos de prueba seleccionadas adecuadamente sobre un dominio
infinito de casos posibles [1]rdquo
Atendiendo a las definiciones presentadas las pruebas de software son dinaacutemicas porque se puede ejecutar el
software bajo pruebas con un conjunto de valores de entrada especiacuteficos para encontrar fallos en su
comportamiento Por otro lado la realizacioacuten de pruebas exhaustivas no es posible para la mayoriacutea de los
productos software reales debido a la gran cantidad de entradas posibles para cada operacioacuten entradas invaacutelidas
o no esperadas y las infinitas secuencias de operaciones posibles
Por estas razones para aplicar un proceso de pruebas de software razonable en cuanto a recursos y tiempo de un
proyecto es necesario seleccionar un conjunto abarcable de pruebas Debido a esto la clave estaacute en el criterio
de seleccioacuten de dichas pruebas Una vez ejecutadas las pruebas seleccionadas se debe decidir si el
comportamiento esperado del sistema falla o no Este es el llamado problema del oraacuteculo el cual es resuelto en
la mayoriacutea de los casos de forma manual mediante la inspeccioacuten de los resultados de la prueba
T
La tecnologiacutea no es nada Lo importante es que tengas feacute
en la gente que sean baacutesicamente buenas e inteligentes
y si les das herramientas haraacuten cosas maravillosas con
ellas
Steve Jobs
47
32 Principios de las Pruebas de Software
Una vez presentada la definicioacuten de pruebas de Software se han obtenido algunos detalles que encajan
perfectamente con una serie de principios que han sido establecidos para el testing de productos software seguacuten
ISTQB (International Software Testing Qualifications Board) [10]
Figura 15 Principios de las Pruebas de Software
1 Las pruebas demuestran la presencia de defectos no su ausencia Las pruebas pueden mostrar que
los defectos estaacuten presentes en el producto pero no pueden probar que no haya defectos Por tanto las
pruebas pueden reducir la probabilidad de existencia de defectos en el software pero incluso si no se
encuentran defectos las pruebas no son una garantiacutea total para afirmar la ausencia de defectos en el
producto final
2 Las pruebas exhaustivas son imposibles Probar todas las posibles combinaciones de entradas y
condiciones previas sobre una aplicacioacuten no es factible excepto en casos muy triviales En lugar de
intentar realizar pruebas exhaustivas se debe usar el anaacutelisis de riesgos las teacutecnicas de prueba y las
prioridades ademaacutes de la automatizacioacuten para enfocar los esfuerzos en la fase de pruebas
3 Las pruebas tempranas ahorran tiempo y dinero Para una deteccioacuten temprana de errores y defectos
las actividades de pruebas deben iniciarse lo antes posible en el ciclo de vida del desarrollo del software
De esta forma se consigue una reduccioacuten de costes ya que cuanto maacutes tarde se detecte un defecto maacutes
costoso y difiacutecil seraacute corregirlo
4 Los defectos se agrupan Generalmente una pequentildea parte del software desarrollado concentra la
mayor complejidad del mismo por lo que la mayoriacutea de los defectos detectados tienen una mayor
probabilidad de encontrarse en esos elementos maacutes complejos Por tanto la realizacioacuten de un buen
anaacutelisis de riesgos permite enfocar el esfuerzo de pruebas en las aacutereas del producto con mayor
probabilidad de presentar defectos
Aplicando el Principio de Pareto al control de calidad [11] el 80 de los errores y defectos estaacute causado
por un 20 del total del producto software desarrollado lo cual podriacutea ser un buen principio sobre el
que basar el anaacutelisis de riesgos
5 Cuidado con la paradoja del pesticida Si las mismas pruebas se repiten una y otra vez con el tiempo
los mismos casos de pruebas ya no encontraraacuten nuevos defectos lo cual no quiere decir que la aplicacioacuten
presente una ausencia completa de los mismos (Las pruebas ya no son eficaces para detectar defectos
al igual que los pesticidas ya no son eficaces para matar insectos despueacutes de un tiempo) Para detectar
nuevos defectos es necesario que las pruebas existentes y los datos de las pruebas deban cambiar
ademaacutes de surgir la necesidad de disentildear nuevas pruebas
48
6 Las pruebas dependen del contexto Cada empresa organizacioacuten o proyecto adaptaraacute el proceso de
pruebas a sus necesidades recursos disponibles o aacutereas de riesgo existentes
7 La ausencia de errores es una falacia Un producto software puede tener un 100 de casos de eacutexito
en su fase de pruebas pero esto solo indica que hay defectos que auacuten no han sido localizados e
identificados
33 Proceso de Pruebas de Software Anaacutelisis disentildeo e implementacioacuten
Partiendo de los principios detallados en la seccioacuten anterior se presentan las diferentes etapas del proceso de
pruebas de software asiacute como la documentacioacuten generada en cada etapa
331 Terminologiacutea
Previamente se presentaraacuten algunos teacuterminos y definiciones que convienen describir para una mejor
comprensioacuten de todo el proceso de pruebas [3]
Figura 16 Terminologiacutea para el proceso de pruebas
1 Condicioacuten de prueba Elemento o evento de un componente o sistema que puede ser verificado por
uno o maacutes casos de prueba Los diferentes requisitos que definen la funcionalidad de un sistema pueden
ser descompuestos en diferentes condiciones de prueba
2 Caso de prueba conjunto de valores de entrada precondiciones de ejecucioacuten y valores esperados
Estos son desarrollados para perseguir un objetivo particular por ejemplo una condicioacuten de prueba
3 Precondicioacuten Condiciones de entorno y estado que deben ser satisfechas antes de que un componente
o sistema pueda ser sometido a un caso de prueba o conjunto de estos
4 Abstraccioacuten de casos de prueba Consiste en la generalizacioacuten de los casos de prueba especiacuteficos sin
valores concretos para sus entradas condiciones de prueba o valores esperados En resumen no es maacutes
que llevar las condiciones de prueba a un caso general para cualquier valor de entrada
5 Script de pruebas Una vez disentildeados los casos de prueba estos pueden ser implementados y
ejecutados por una herramienta de automatizacioacuten Un script de pruebas puede contener varios casos
de prueba
6 Paquete de pruebas Consiste en la agrupacioacuten de casos de prueba relacionados en cuanto a la
funcionalidad que automatizan sobre el sistema
7 Programacioacuten de la ejecucioacuten de pruebas Describen el flujo de ejecucioacuten de los diferentes paquetes
de pruebas
49
332 Proceso de Pruebas de Software
No existe un proceso de pruebas universal pero existen conjuntos comunes de actividades de prueba sin las
cuales las pruebas disentildeadas e implementadas tendriacutean menos probabilidad de alcanzar sus objetivos
establecidos Estos conjuntos de actividades de prueba constituyen un proceso de pruebas
Como se ha mencionado en secciones anteriores el proceso de pruebas se debe iniciar en las fases maacutes iniciales
del ciclo de vida de un proyecto Por tanto las actividades del proceso de pruebas la manera en que se
implementan dichas actividades y cuaacutendo ocurren pueden ser discutidas en la estrategia de pruebas de una
organizacioacuten
A continuacioacuten se exponen las etapas fundamentales del proceso de pruebas detallando en cada una de ellas la
documentacioacuten generada y coacutemo contribuyen a la mejora de la calidad del producto con su aplicacioacuten en el ciclo
de vida de un proyecto [13]
Figura 17 Proceso de Pruebas de Software
3321 Planificacioacuten y Control de Pruebas
La planificacioacuten consiste en determinar los diferentes objetivos de las pruebas realizadas sobre el Sistema bajo
test las especificaciones y los recursos que se necesitaraacuten para llevar a cabo la fase de pruebas y cumplir con los
objetivos planteados
Es en este punto donde se define el alcance de las pruebas a realizar de forma que se selecciona lo que seraacute y
no seraacute testeado ademaacutes de indicar quieacuten haraacute cada prueba y como la llevaraacute a cabo Mediante los objetivos de
las pruebas se puede establecer un punto de finalizacioacuten del proceso
Como salida de la actividad de planificacioacuten se obtendriacutea el ldquoPlan de Pruebasrdquo el cual documenta la estrategia
y el alcance de las pruebas la prioridad en cuanto a su realizacioacuten y las estimaciones temporales para su
evaluacioacuten ademaacutes de los recursos materiales y humanos para llevarlas a cabo
Es crucial que dicho documento sea validado por el personal correspondiente del proyecto antes de continuar
con las siguientes etapas del proceso de pruebas
Por otro lado el control de pruebas es una actividad desarrollada durante todo el ciclo de vida del proceso de
pruebas el cual permite contrastar el progreso actual con el plan original trazado para la aplicacioacuten de dicho
proceso incluyendo informes y desviaciones
Cuando se produce una desviacioacuten del plan original que introduce cierto riesgo adicional puede hacerse
necesario modificar los objetivos fijados para asegurar la calidad del producto De ahiacute que sea sumamente
importante tener en consideracioacuten la documentacioacuten generada en antiguos proyectos
50
3322 Anaacutelisis y Disentildeo de Pruebas
Una vez planificado el alcance y objetivos de las pruebas se realiza una actividad de anaacutelisis donde se traducen
a condiciones de prueba y posteriormente se disentildean los casos de prueba de alto nivel a partir de la abstraccioacuten
de los casos de prueba
Por otro lado cabe destacar la necesidad de un mecanismo que garantice la trazabilidad con la finalidad de
mantener alineados en todo momento los casos de prueba con los objetivos de la misma incluso contemplando
la posibilidad de que los objetivos puedan cambiar en alguacuten momento del proceso de pruebas
El documento generado en esta actividad es conocido como ldquoespecificaciones de disentildeo de pruebasrdquo
3323 Implementacioacuten y Ejecucioacuten de Pruebas
Dicha etapa consiste en la implementacioacuten de los casos de prueba de alto nivel que cumplen con las
especificaciones de disentildeo de la etapa anterior Es en esta fase donde se haraacute uso de herramientas para la
implementacioacuten y ejecucioacuten de las pruebas
Cabe destacar que para llevar a cabo dicha etapa en cuanto a la verificacioacuten y validacioacuten funcional de un
proyecto es necesario que durante la etapa de desarrollo se haya creado un producto funcional sobre el cual
puedan ejecutarse las pruebas
Durante la ejecucioacuten de las pruebas los resultados obtenidos quedaraacuten documentados en un documento
denominado ldquoRegistro de Pruebasrdquo el cual contiene todas las pruebas realizadas y un ldquoReporte de Incidenterdquo
por cada resultado no esperado que se haya detectado
Una vez sean corregidos los incidentes se debe volver a ejecutar las pruebas con la finalidad de asegurar que
dicho incidente haya sido corregido ademaacutes de asegurar que la correccioacuten realizada no haya introducido otros
defectos o errores Esto es lo que se denomina ldquoPruebas de Regresioacutenrdquo
3324 Evaluacioacuten de los criterios de eacutexito y Elaboracioacuten de reportes e informes
Tras la ejecucioacuten de las pruebas se deben evaluar los criterios de eacutexito los cuales han sido definidos en la etapa
de planificacioacuten
El personal responsable e involucrado en el proyecto se reuniraacute y revisaraacute el cumplimiento de dichos criterios
el registro de pruebas obtenido y los reportes de incidentes que hayan podido ser abiertos en la etapa anterior
Finalmente como resultado de dicha actividad se elabora un ldquoSumario final de Pruebasrdquo
3325 Cierre de la fase de pruebas
Las actividades de cierre de la fase de pruebas se centran mayormente en asegurar que todo el ciclo de vida del
proceso de pruebas se ha cumplido ademaacutes de analizar las posibles mejoras y defectos en las fases llevadas a
cabo
Ademaacutes se lleva a cabo el cierre de los incidentes corregidos y la liberacioacuten de los entornos y recursos asignados
a la fase de pruebas
51
34 Clasificacioacuten de Pruebas de Software
Existen diversos tipos de pruebas las cuales pueden ser clasificadas en funcioacuten del objetivo de prueba para lo
cual hayan sido establecidos Cada tipo de prueba persigue unos objetivos especiacuteficos sobre el producto pero
todas ellas persiguen como objetivo comuacuten ofrecer un producto con garantiacutea de calidad al cliente o usuario final
Dichas pruebas pueden ser clasificadas en cuatro tipos
Figura 18 Clasificacioacuten de Pruebas de Software
341 Pruebas Funcionales
Tambieacuten conocidas como ldquoPruebas de caja Negrardquo En [14] la IEEE define este tipo de pruebas como
ldquoPruebas que ignoran los mecanismos internos de un sistema o componente y se enfocan
solamente en las salidas generadas como respuesta a las entradas seleccionadas y a las
condiciones de ejecucioacutenrdquo
Figura 19 Pruebas de Caja Negra
Atendiendo a la definicioacuten anterior el sistema o componente sujeto a pruebas debe realizar una funcioacuten
determinada Estaraacute descrita en las especificaciones funcionales y se pueden llevar a cabo a cualquier nivel
Dichas especificaciones funcionales describen el comportamiento del sistema sin revelar informacioacuten acerca de
su implementacioacuten interna
Un tipo especial de prueba funcional son las ldquoPruebas de Humordquo o ldquoSmoke Testsrdquo Este tipo de pruebas suele
realizarse en fases tardiacuteas del desarrollo y permiten asegurar que las funcionalidades baacutesicas del software
responden adecuadamente
Por tanto dichas pruebas pueden quedar lejos de ser pruebas exhaustivas aunque siacute permiten asegurar que el
producto entregado al cliente cumple con los requisitos de funcionamiento establecidos Este tipo de pruebas
son las que se han implementado y automatizado en el proyecto presente lo cual se detallaraacute en capiacutetulos
posteriores
52
342 Pruebas No Funcionales
Este tipo de pruebas estaacuten orientadas a verificar coacutemo de bien funciona el sistema bajo pruebas en lugar de la
funcionalidad que ofrece Por ello pueden ser agrupadas tambieacuten dentro de la categoriacutea de pruebas de caja negra
Atendiendo al estaacutendar de evaluacioacuten del producto software ldquoISO 25000rdquo todas las caracteriacutesticas excepto la de
funcionalidad definen caracteriacutesticas de calidad no funcionales de un producto software Estas caracteriacutesticas de
calidad tienen su correspondiente tipo de prueba
3421 Pruebas de Rendimiento
Las pruebas de rendimiento son usadas para determinar la rapidez con la que se realiza una tarea en el sistema
bajo unas condiciones particulares de trabajo Estas pruebas tambieacuten pueden ser usadas para validar y verificar
otros atributos de calidad del sistema tales como la escalabilidad fiabilidad y uso de recursos
Figura 20 Pruebas de Rendimiento
3422 Pruebas de Carga
Este tipo de pruebas miden el rendimiento del sistema con una carga de trabajo manejable y conocida Se trata
de someter al sistema a cargas de trabajo controladas por el ingeniero de pruebas para validar prestaciones de
rendimiento sobre el sistema
Figura 21 Pruebas de Carga
3423 Pruebas de Estreacutes
Las pruebas de estreacutes ponen a prueba la robustez y confiabilidad del sistema sometieacutendolo a condiciones de uso
extremas Entre estas condiciones se incluyen el enviacuteo masivo de peticiones y la ejecucioacuten en condiciones de
hardware limitadas Dichas condiciones van maacutes allaacute de los liacutemites de operacioacuten considerados en el disentildeo
Figura 22 Pruebas de Estreacutes
53
3424 Pruebas de Usabilidad
Estas pruebas se centran en encontrar problemas de la interfaz de usuario que podriacutean hacer que el software sea
difiacutecil de utilizar o podriacutean causar que los usuarios mal interpreten las salidas Por tanto permiten medir coacutemo
de atractivo resulta un producto software basaacutendose en la facilidad de adaptacioacuten y uso por parte de los clientes
Figura 23 Pruebas de Usabilidad
3425 Pruebas de Fiabilidad
Prueban el rendimiento del sistema ante un determinado nuacutemero de operaciones o tras cierto periodo de
tiempo
3426 Pruebas de Instalacioacuten
Las pruebas de instalacioacuten tienen dos propoacutesitos El primero es asegurar que el sistema puede ser instalado
en todas las configuraciones posibles tales como nuevas instalaciones actualizaciones instalaciones
completas o personalizadas y bajo condiciones normales o anormales estas uacuteltimas incluyen insuficiente
espacio en disco falta de privilegios para algunas tareas etc
El segundo propoacutesito es verificar que una vez instalado el sistema opera correctamente Esto usualmente
implica ejecutar un nuacutemero significativo de pruebas de Funcionalidad
Por tanto miden coacutemo de sencillo resulta instalar la aplicacioacuten en distintas plataformas o entornos
3427 Pruebas de Portabilidad
Miden coacutemo de sencillo resulta migrar una aplicacioacuten de una plataforma a otra
Figura 24 Pruebas de Portabilidad
54
343 Pruebas Estructurales
Este tipo de pruebas son tambieacuten conocidas como ldquoPruebas de Caja Blancardquo En [14] la IEEE define este tipo
de pruebas como
ldquoPruebas que tienen en cuenta los mecanismos internos de un sistema o componenterdquo
Figura 25 Pruebas de Caja Blanca
Atendiendo a dicha definicioacuten estas pruebas tienen en cuenta la estructura del coacutedigo fuente del software a partir
del cual se seleccionan los diferentes casos de prueba guiaacutendose por la existencia de sentencias condicionales
bucles etc
Por tanto los casos de prueba son desarrollados usando criterios de cobertura para el coacutedigo del programa De
esta forma el sistema bajo pruebas se trata como una caja de cristal que permite ver su estructura
El criterio de cobertura hace referencia a cada miacutenima unidad de coacutedigo que puede ser probada de forma
independiente Es frecuente usar este tipo de pruebas en los niveles de prueba maacutes bajos como por ejemplo en
las ldquoPruebas Unitariasrdquo o las ldquoPruebas de Componenterdquo
344 Pruebas debidas a Cambios
Finalmente en el proceso de pruebas tras ejecutar las pruebas y encontrar un defecto o error en el sistema bajo
pruebas este se corrige pero es necesario validar la correccioacuten realizada para confirmar que el fallo no se
reproduce A este proceso se le denomina ldquoPrueba de confirmacioacuten o re-testingrdquo
Ademaacutes las correcciones pueden ser validadas pero tambieacuten es necesario asegurar que los cambios introducidos
para corregir dicho fallo no han provocado maacutes defectos Por tanto puede concluirse que es necesario volver a
realizar pruebas sobre el resto del sistema Estas son las ldquoPruebas de Regresioacutenrdquo
35 Niveles de Prueba
El proceso de pruebas es una etapa del ciclo de vida de un proyecto cuyas actividades estaacuten completamente
relacionadas con las actividades del proceso de desarrollo Existen diversos modelos que describen las fases y
actividades del proceso de desarrollo de software En esta seccioacuten se detallaraacute el uso del ldquoModelo de desarrollo
en Vrdquo
Este modelo describe las diferentes fases del proceso de desarrollo y sugiere la realizacioacuten de pruebas en cada
una de ellas Estas pruebas seraacuten ejecutadas posteriormente en orden ascendente Por tanto para cada fase existen
unos objetivos a cumplir los cuales deben ser probados para medir la integridad del trabajo realizado
55
A continuacioacuten se detallaraacuten los diferentes niveles de prueba para cada etapa del desarrollo software atendiendo
al modelo de desarrollo en V
Figura 26 Modelo de desarrollo en V
351 Pruebas a Nivel de Componente
Tambieacuten llamadas ldquoPruebas Unitariasrdquo El objetivo de estas pruebas es el de cubrir la unidad miacutenima funcional
que compone el software Estos componentes suelen tener una uacutenica funcioacuten especiacutefica la cual seraacute usada por
el resto del Sistema A menudo son realizadas por los propios desarrolladores haciendo uso de la metodologiacutea
de desarrollo guiado por prueba o Test-Driven-Development (TDD)
352 Pruebas a Nivel de Integracioacuten
Son aquellas pruebas realizadas en el aacutembito del desarrollo software una vez validadas las pruebas unitarias
Estas pruebas verifican que todos los elementos unitarios que componen el software funcionan en conjunto de
forma correcta Se centran principalmente en probar la comunicacioacuten entre los diferentes componentes del
sistema
353 Pruebas a Nivel de Aceptacioacuten
Este uacuteltimo nivel se centra en las necesidades del usuario requisitos y procesos de negocio con el fin de
determinar si el sistema satisface los criterios de aceptacioacuten acordados con el cliente en un contrato o acuerdo
de nivel de servicio en caso de ser un software de uso interno dentro de una compantildeiacutea
Ejemplos de este tipo de pruebas pueden ser las ldquoPruebas Alfa y Betardquo
Como se ha detallado anteriormente las pruebas desarrolladas y automatizadas en este Proyecto son ldquoPruebas
de humordquo o Smoke Tests Estas pruebas se centran en la verificacioacuten y validacioacuten de las especificaciones de uso
de un Sistema en este caso de la plataforma Web de gestioacuten Galgus CHT Manager
56
36 Dificultades de pruebas en aplicaciones Web e impacto
La complejidad antildeadida de las aplicaciones y servicios Web frente a otros tipos de aplicaciones recae sobre el
uso de muacuteltiples tecnologiacuteas de vanguardia que permiten la construccioacuten de sistemas distribuidos con un amplio
grado de escalabilidad accesibilidad disponibilidad interoperabilidad e independencia del hardware
Como consecuencia del incremento de la complejidad de las aplicaciones surgen nuevos paradigmas como la
Arquitectura Orientada a Servicios (SOA) la cual permite interoperabilidad y flexibilidad de las aplicaciones
distribuidas
Todo ello conlleva a plantearse queacute se deberiacutea hacer para garantizar que una aplicacioacuten Web puesta en marcha
funciona de acuerdo a los requisitos definidos y acordados con el cliente Podriacutean optimizarse y mejorarse los
diferentes procesos dentro del ciclo de vida de un proyecto pero siempre la fase de pruebas termina siendo la
fase previa a la puesta en marcha de la aplicacioacuten con lo que resulta siendo la uacuteltima oportunidad para detectar
posibles fallos que puedan terminar en ocasiones en peacuterdidas econoacutemicas de prestigio de fiabilidad y de
credibilidad por parte de los clientes
Realizar pruebas en una aplicacioacuten Web no es tarea faacutecil ya que son muchos los factores que influyen en el
testeo del sistema para abarcar y contemplar el maacuteximo de flujos posibles que se pueden llevar a cabo durante
el uso de la aplicacioacuten
Hoy en diacutea las aplicaciones Web pueden ser construidas con componentes implementados en diferentes
lenguajes y arquitecturas basaacutendose en diferentes modelos de programacioacuten y pudiendo ejecutarse en diferentes
plataformas de hardware y software
Esto incrementa la complejidad de las pruebas a realizar sobre un sistema de este tipo por lo que seriacutea interesante
plantearse la posibilidad de usar herramientas que permitan una abstraccioacuten de dicha complejidad ademaacutes de la
automatizacioacuten de la fase de pruebas En el caso de las pruebas a nivel de aceptacioacuten en este proyecto se
propondraacute el uso de herramientas que persiguen dichos fines
Figura 27 Dificultades de pruebas en aplicaciones Web e impacto
57
58
4 SISTEMA GALGUS CHT CLOUD MANAGER
ras realizar un estudio del arte sobre una teacutecnica que puede ser de gran utilidad para optimizar y
perfeccionar las teacutecnicas de automatizacioacuten para el proceso de pruebas sobre un sistema se han puesto
en contexto los diferentes tipos de pruebas que pueden realizarse sobre un sistema ademaacutes de definir
el proceso de pruebas Una vez llegados a este punto en primer lugar se realizaraacute una descripcioacuten del sistema
bajo pruebas sobre el cual se plantearaacute una solucioacuten para la fase de pruebas y su automatizacioacuten Maacutes
concretamente para la realizacioacuten de las pruebas a nivel de aceptacioacuten
41 Arquitectura y Descripcioacuten del Sistema
CHT Cloud Manager es un proyecto de la empresa Galgus el cual ofrece una plataforma Web de gestioacuten
configuracioacuten y monitorizacioacuten de redes WiFi Maacutes concretamente dicha plataforma permite gestionar un
conjunto de puntos de acceso desplegados con un conjunto de algoritmos definidos por software los cuales
permiten la optimizacioacuten de los recursos de red inalaacutembricos ofreciendo mayores prestaciones y una mayor
calidad de servicio al usuario Ademaacutes dicho software embebido ofrece otros servicios al cliente como la
localizacioacuten de estaciones dentro de la zona de alcance de la red WiFi o la deteccioacuten de intrusos y ataques de
suplantacioacuten de identidad
A este conjunto de algoritmos se le conoce bajo el nombre Cognitive Hostpot Technology (CHT) Este software
implementado en lenguaje C y preparado para sistemas embebidos como los puntos de acceso presenta una
estructura modular donde cada moacutedulo se encarga de una tarea determinada o de ejecutar un algoritmo
determinado
Figura 28 Logo de Galgus
Para permitir la comunicacioacuten con la plataforma Web CHT implementa un moacutedulo denominado MGR el cual
permite la conexioacuten con un broacuteker de eventos o intermediario para permitir el enviacuteo y la recepcioacuten de eventos
desde dicha plataforma
T
La simplicidad llevada al extremo se convierte en
elegancia
Jon Franklin
59
En la siguiente figura se muestra la arquitectura orientada a servicios para CHT Cloud Manager
Figura 29 Arquitectura de CHT Cloud Manager
Puede observarse que dicha plataforma estaacute formada por diferentes microservicios desplegados en la nube Cada
uno de ellos realiza una serie de tareas bien definidas e interactuacutean entre ellos enviando y recibiendo mensajes
haciendo uso de diferentes protocolos y modelos de comunicacioacuten
De esta forma se consigue mantener actualizado el estado de la informacioacuten de los diferentes elementos en
tiempo real sobre los diferentes eventos que puedan ocurrir en el sistema Dichos eventos proceden en su gran
mayoriacutea del conjunto de puntos de acceso que conforma una red de Galgus la cual pretende ser gestionada desde
la plataforma en cuestioacuten
A continuacioacuten se detallaraacuten los diferentes microservicios que conforman dicha plataforma ademaacutes de describir
a los puntos de acceso con la tecnologiacutea CHT como elementos a gestionar desde dicha plataforma
60
411 Puntos de Acceso (OpenWRT + CHT)
4111 OpenWRT
Los puntos de acceso WiFi de Galgus son sistemas embebidos de diferentes modelos en funcioacuten de las
especificaciones hardware que ofrezcan (nuacutemero de streams espaciales nuacutemero de antenas de exterior de
interior etc)
Todos ellos tienen en comuacuten el uso de OpenWRT como sistema operativo Este se trata de un sistema operativo
open source basado en Linux y usado para sistemas de red embebidos Todos los componentes de dicho sistema
han sido optimizados para dispositivos con limitaciones de hardware y este permite configurarlos mediante
interfaz de liacutenea de comandos o mediante una interfaz Web (LuCI) [15]
Partiendo de dicho sistema operativo Galgus desarrolla CHT como producto software que dota a los puntos de
acceso de una serie de prestaciones en una serie de moacutedulos Dicho producto es ofrecido al cliente mediante
licencias las cuales son gestionadas desde un servidor de licencias y obtenidas por los puntos de acceso de
forma automaacutetica Todo ello se detallaraacute maacutes adelante
4112 CHT
CHT tambieacuten ofrece su propia interfaz de liacutenea de comandos denominada CHT_CLI Esta herramienta permite
configurar los distintos moacutedulos de los que se compone CHT y obtener informacioacuten tanto de la configuracioacuten
como del funcionamiento de los algoritmos CHT
A continuacioacuten se presenta la interfaz y algunos de los comandos que se pueden utilizar
Figura 30 CHT_CLI
CHT_CLI es fundamental tanto en el desarrollo como en el testeo de CHT y CHT Cloud Manager ya que nos
permite acceder a paraacutemetros de configuracioacuten que no estaacuten accesibles desde la interfaz graacutefica LuCI Desde
CHT_CLI se controlan todos los moacutedulos de CHT entre los que se pueden destacar los siguientes Load Balance
(LB) Smart Roaming (SR) Power Control (POWER) Localization (LOC) Traffic Congestion Management
(TCM) Smart Band Steering (SB) y el moacutedulo Manager (MGR)
En este caso es de intereacutes resaltar el moacutedulo que permite la comunicacioacuten con la plataforma de gestioacuten CHT
Cloud Manager Dicho moacutedulo conocido bajo el nombre de MGR implementa un cliente AMQP para
establecer la comunicacioacuten con el broacuteker de eventos usado como intermediario para permitir la comunicacioacuten
entre los puntos de acceso y la plataforma de gestioacuten CHT Cloud Manager
Ademaacutes implementa una serie de estructuras de datos que son enviados a traveacutes de dicho intermediario basadas
en FlatBuffers como plataforma eficiente de serializacioacuten cruzada de datos ofrecida por Google Esta
herramienta permite crear un modelo de datos bajo la sintaxis ofrecida por FlatBuffers para posteriormente
generar dichas estructuras de datos en diferentes lenguajes de programacioacuten como por ejemplo C++ C C
Go Java JavaScript etc
Con esto se consigue generar estructuras de datos con una compatibilidad absoluta que se intercambiaraacuten entre
la plataforma de gestioacuten en lenguaje Java y los puntos de acceso en lenguaje C
61
412 Broacuteker de Eventos AMQP (RabbitMQ)
Este microservicio implementa un broacuteker de eventos que actuacutea como intermediario entre los puntos de acceso
WiFi y algunos microservicios que componen la plataforma Web de gestioacuten Se basa en el protocolo AMQP el
cual sigue el patroacuten publicadorsuscriptor como paradigma de comunicacioacuten indirecta
Estaacute involucrado en la entrega de mensajes entre los diferentes dispositivos embebidos con CHT y sus
respectivos servicios de gestioacuten en la plataforma Web de forma que los agentes que publican y consumen
eventos en el broacuteker no necesitan conocer al destinatario si no que el broacuteker es el que se encarga de publicar los
eventos para los destinatarios suscritos a eacutel En la siguiente figura se muestra la interfaz graacutefica de gestioacuten de
RabbitMQ [16]
Figura 31 Plataforma de Gestioacuten de RabbitMQ
Un broacuteker de eventos es un elemento del patroacuten PublicadorSuscriptor que recibe y mensajes de un conjunto de
elementos de red que quieren comunicarse ejecutan mecanismos de filtrado y permite la entrega correcta de los
diferentes mensajes a los consumidores correspondientes Por tanto el broacuteker de eventos permite ofrecer un
desacoplamiento entre emisores y receptores de la informacioacuten siendo este responsable de las tareas de
encaminamiento y reenvioacute de mensajes En conclusioacuten es responsable de coordinar la comunicacioacuten
proporcionando transparencia de acceso y localizacioacuten permitiendo la localizacioacuten de emisores y receptores
mediante un sistema de identificadores uacutenicos
Figura 32 Patroacuten PublicadorSuscriptor
62
413 Frontend
El Frontend de la plataforma Web estaacute implementado con Angular 6 HTML5 y CSS3 Su finalidad es ofrecer
una interfaz graacutefica al usuario final la cual permite mostrar el estado de los diferentes Zone Managers ademaacutes
de permitir el acceso a estos y gestionar el conjunto de puntos de acceso registrados en ellos de forma raacutepida e
intuitiva
Este microservicio recibe informacioacuten proporcionada por MoMap y los diferentes Zone Managers La
aplicacioacuten se sirve mediante un servidor Apache el cual proporciona una comunicacioacuten fiable con HTTPS
implementando una capa de transporte segura mediante el protocolo TLS
414 Zone Manager
Microservicio responsable de gestionar un conjunto de puntos de acceso CHT los cuales forman un despliegue
de red WiFi de Galgus para un cliente determinado Este microservicio estaacute formado por un servicio Web REST
implementado con Java Spring Framework desplegado en un servidor Jetty embebido y cuya persistencia se ha
implementado a traveacutes de Hybernate con el uso de Postgress SQL como gestor de bases de datos relacional
Un Zone Manager ofrece todas las tareas y acciones necesarias para configurar un conjunto de puntos de acceso
y consultar datos estadiacutesticos de usuarios conectados a dichos puntos de acceso entre otras Cabe destacar en
este punto la importancia que tiene el uso de FlatBuffers para garantizar la compatibilidad de datos enviados y
recibidos entre los puntos de acceso y el Zone Manager ambos implementados en tecnologiacuteas totalmente
diferentes
Figura 33 Ejemplo de Interfaz Graacutefica de un Zone Manager
63
415 MoMap
Dicho microservicio implementado en NodeJS gestiona y administra toda la infraestructura que conforma la
plataforma Web Establece y mantiene todas las conexiones y relaciones entre los diferentes puntos de acceso
con CHT y los Zone Managers (ZMB) que los gestiona
Ademaacutes este microservicio implementa una serie de maacutequinas de estado que permiten controlar el estado de
todos los Zone Managers y puntos de acceso CHT alertando sobre los eventos de error conexioacuten o desconexioacuten
en tiempo real a los usuarios finales a traveacutes del Frontend El soporte a la persistencia para dicho microservicio
se proporciona mediante MongoDB
Por tanto el microservicio MoMap actuacutea como proxy inverso HTTP2 Cuando un usuario intenta acceder a
traveacutes del Frontend de la plataforma Web puede gestionar y administrar un conjunto de Zone Managers o
administrar usuarios y asignar roles y permisos Tambieacuten se permite la creacioacuten eliminacioacuten y conexioacuten con un
Zone Manager redirigiendo las peticiones hacia el mismo
Cuando ocurre un evento de conexioacuten con un Zone Manager desde el microservicio MoMap se recupera y
enviacutea la informacioacuten necesaria para mostrar toda la informacioacuten correspondiente a ese Zone Manager en el
Frontend para el usuario final En la siguiente figura se muestra la interfaz graacutefica ofrecida por el servicio
MoMap a traveacutes del Frontend
Figura 34 Ejemplo de Interfaz Graacutefica de MoMap
64
416 Servidor de Licencias
El objetivo principal de este servicio es proporcionar una aplicacioacuten con una gestioacuten y control centralizado de
las licencias de todos los Puntos de Acceso desplegados con CHT Este servidor desplegado con Jetty de forma
embebida almacena el registro de un conjunto de Puntos de Acceso CHT para un conjunto de Clientes y
proyectos determinados Proporciona una API REST implementada con Java Spring Framework que permite
el registro de dichos dispositivos y la asignacioacuten de licencias CHT para habilitar los diferentes moacutedulos de dicha
aplicacioacuten embebida sobre los Puntos de Acceso Ademaacutes proporciona una interfaz Web de usuario
implementada con Angular 6 HTML5 y CSS3
En la siguiente figura se muestra un ejemplo de dicha interfaz graacutefica
Figura 35 Interfaz Graacutefica del Servidor de Licencias
4161 Zero-Touch Provisioning (ZTP)
En el contexto de la automatizacioacuten de redes WiFi el aprovisionamiento sin contacto es una caracteriacutestica
que permite que los puntos de acceso de una red se configuren automaacuteticamente evitando la intervencioacuten
humana para su configuracioacuten La configuracioacuten manual de dispositivos y conmutadores es costosa y
requiere lo que a menudo puede ser una gran cantidad de tiempo y esfuerzo dependiendo del tamantildeo de la
red [17]
Con el uso de sistemas automaacuteticos de aprovisionamiento y configuracioacuten se consigue reducir la carga de
trabajo y el esfuerzo que normalmente se requiere cuando se instalan y configuran nuevos dispositivos
Figura 36 Zero-Touch Provisioning (ZTP)
65
Haciendo uso de esta caracteriacutestica Galgus implementa en su infraestructura orientada a microservicios
un acceso directo de los Puntos de Acceso al servidor para que soliciten su licencia de CHT
automaacuteticamente de forma que cuando el usuario final vaya a instalar un Punto de Acceso CHT dicho
dispositivo obtendraacute su licencia de forma segura a traveacutes de la API REST del servidor de licencias siempre
y cuando esteacute registrado en el mismo y disponga de licencia sin necesidad de que el usuario intervenga en
dicho proceso
La comunicacioacuten entre los puntos de acceso y el resto de la infraestructura se realiza a traveacutes de un broacuteker
de eventos AMQP con su implementacioacuten en RabbitMQ Debido a esto cuando se crea y asigna licencia
a un dispositivo en el servidor de licencias dicho servidor crea un usuario en RabbitMQ de forma que el
punto de acceso en el momento que obtiene su licencia intentaraacute establecer conexioacuten con el broacuteker para
permitir el intercambio de eventos con los microservicios que lo gestionaraacuten mediante la plataforma CHT
Cloud Manager
Una vez el punto de acceso establece conexioacuten con el broacuteker de eventos este podraacute ser descubierto por el
Zone Manager que lo gestionaraacute El microservicio MoMap se encarga de establecer el descubrimiento de
los puntos de acceso comprobando si el punto de acceso estaacute registrado en el servidor de licencias con
licencia asignada y verificando que el punto de acceso estaacute operativo con conexioacuten a internet
42 Alcance y Objetivos de las pruebas sobre el sistema planteado
Una vez presentada y descrita toda la arquitectura de la plataforma Web ofrecida por Galgus se procederaacute a
detallar los principales objetivos del proceso de pruebas que se pretenderaacute conseguir sobre dicha aplicacioacuten Para
ello inicialmente se presentaraacute en queacute punto se encontraba el proceso de pruebas inicialmente
En este proyecto se ha centrado la atencioacuten en el conjunto de pruebas funcionales realizadas a la aplicacioacuten maacutes
concretamente las pruebas a nivel de aceptacioacuten
Dentro de las pruebas a nivel de aceptacioacuten los ingenieros de prueba hasta ahora habiacutean disentildeado un plan de
pruebas de aceptacioacuten o tests End-to-End los cuales se ejecutaban verificaban y validaban manualmente por
los ingenieros de QA Dicho plan de pruebas estaacute formado por una bateriacutea de casos de prueba a realizar sobre
las diferentes funcionalidades del sistema A continuacioacuten se muestra un fragmento de dicho plan de pruebas
Figura 37 Test Plan de CHT Cloud Manager
Como puede observarse en la figura anterior dicho plan de pruebas contiene un conjunto de casos de prueba
cada uno de ellos con un identificador uacutenico una descripcioacuten algunas especificaciones o detalles necesarios un
indicador de eacutexito o fallo y finalmente la descripcioacuten de los resultados obtenidos
Ademaacutes en dicho test plan se incluye una cabecera y una leyenda para clasificar los distintos resultados
obtenidos en la ejecucioacuten de las pruebas registrar algunos datos de relevancia y tener archivado dicho plan de
pruebas con las versiones de los diferentes microservicios que componen la plataforma Web
66
Figura 38 Leyenda del Test Plan
Figura 39 Control de Versiones del Test Plan
Una vez presentado el estado actual del proceso de pruebas a nivel de aceptacioacuten el nuevo equipo encargado de
evaluar la calidad de la plataforma Web planteoacute la oportunidad de automatizar dicho plan de pruebas Por tanto
el principal objetivo de este proyecto ha sido el de automatizar las actividades de ejecucioacuten y generacioacuten de
reportes de las pruebas de aceptacioacuten automatizadas sobre la aplicacioacuten
Sin embargo las actividades de planificacioacuten disentildeo e implementacioacuten de los diferentes casos de prueba se
realizaraacuten de forma manual haciendo uso de un conjunto de tecnologiacuteas que se usaraacuten para desarrollar la
automatizacioacuten de dichas pruebas Dichas tecnologiacuteas principalmente son Robot Framework Selenium y
Python las cuales se detallaraacuten maacutes adelante
En este punto es donde podriacutea entrar en juego la aplicacioacuten de Model-Based-Testing (MBT) detallado en la
seccioacuten 2 de este proyecto como teacutecnica que permite la abstraccioacuten de la actividad de implementacioacuten del plan
de pruebas mejorando el proceso de pruebas e independizando este de las actividades de desarrollo
En este proyecto queda fuera del alcance la aplicacioacuten de dicha teacutecnica debido a la necesidad de disponer de un
disentildeo completo y detallado de la plataforma Web para permitir la generacioacuten de los casos de prueba abstractos
y su posterior generacioacuten automaacutetica de los casos de prueba ejecutables Es de intereacutes destacar que a lo largo
del desarrollo del proyecto han ido surgiendo otros objetivos de intereacutes para mejorar el proceso de pruebas los
cuales permiten agilizar dicho proceso y ampliar su alcance
Entre estos objetivos se encuentran la generacioacuten automaacutetica de documentacioacuten del plan de pruebas la
implementacioacuten de un entorno de UAT (User Acceptance Testing) con Docker la integracioacuten de las pruebas a
nivel de aceptacioacuten en el proceso de integracioacuten continua del proyecto o la creacioacuten de un Docker que permita
ejecutar todo el plan de pruebas Todos estos objetivos se iraacuten detallando maacutes adelante
67
43 Arquitectura de la Solucioacuten Entorno de UAT para el proceso de pruebas (User Acceptance Test)
Hasta ahora dentro del proceso de desarrollo de la plataforma Web existiacutean las siguientes fases etapas o
entornos Desarrollo Preproduccioacuten y Produccioacuten
Bajo este contexto las actividades del proceso de pruebas eran realizadas sobre la fase de Preproduccioacuten Esto
provocaba una dependencia directa del cierre de la mayoriacutea de actividades de desarrollo para el despliegue en la
fase de Preproduccioacuten Como consecuencia la fase de pruebas a nivel de aceptacioacuten se podriacutea ver perjudicada
por esta metodologiacutea provocando en muchas ocasiones el retraso en el feedback necesario por los ingenieros de
desarrollo de los reportes e informes generados al ejecutar las pruebas de aceptacioacuten Para mejorar este proceso
se ha disentildeado un nuevo entorno de UAT en el proceso de desarrollo que permita disminuir la dependencia del
proceso de pruebas y desarrollo La inclusioacuten de este nuevo entorno ha sido posible gracias a la mejora del
proceso de integracioacuten continuacutea implementado en el desarrollo de la plataforma
Dentro de este proceso de integracioacuten continua se realiza la generacioacuten automaacutetica de los Docker que contienen
los diferentes microservicios de la plataforma Web en cualquier etapa del proceso de desarrollo Ademaacutes dentro
del proceso de integracioacuten continua se ha automatizado por parte de los ingenieros de desarrollo la ejecucioacuten
de pruebas unitarias y de integracioacuten que garantizan una miacutenima garantiacutea de estabilidad funcional de la
plataforma necesaria para el proceso de pruebas Partiendo de este punto el equipo de calidad ha disentildeado un
entorno de UAT con Docker el cual se muestra de forma graacutefica en la siguiente figura
Figura 40 Entorno de UAT con Docker (Anexo B)
68
69
5 TECNOLOGIacuteAS Y HERRAMIENTAS USADAS
na vez descrito el sistema bajo pruebas y presentada la arquitectura de la solucioacuten para el escenario de
pruebas con Docker se expondraacute a continuacioacuten el conjunto de tecnologiacuteas y herramientas usadas para
llevar a cabo el desarrollo de las pruebas automatizadas de aceptacioacuten o pruebas End-to-End Con este
conjunto de herramientas se pretende conseguir la implementacioacuten de los diferentes scripts de pruebas que
automaticen las acciones e interacciones necesarias con la plataforma Web CHT Cloud Manager como si de
una persona se tratase
51 Selenium
Selenium es una herramienta de coacutedigo abierto utilizada para la automatizacioacuten de pruebas en navegadores web
Dicha herramienta posee una enorme popularidad en el mundo de las pruebas de software debido a que
Presenta compatibilidad con diferentes lenguajes de programacioacuten para la implementacioacuten de scripts de
pruebas ofreciendo libreriacuteas en Java Python C PHP Ruby Perl y Net
Es multiplataforma permitiendo el lanzamiento de los scripts de pruebas en diversos sistemas
operativos como Windows Mac o Linux y en diferentes navegadores como Mozilla Firefox Internet
Explorer Google Chrome Safari y Opera
Soporta la integracioacuten con otras herramientas como TestNG o JUnit
Permite la integracioacuten continua con Maven Jenkins gitlab CICD y Docker
Sin embargo presenta una serie de inconvenientes que se deben mencionar
bull Solo permite probar aplicaciones Web
bull No hay soporte garantizado desde Selenium Muchas de las soluciones a problemas de la herramienta
han sido generadas por la comunidad
bull No es posible realizar pruebas en imaacutegenes Para ello es necesaria la integracioacuten con otras herramientas
bull No tiene capacidad nativa para generar informes o reportes de los resultados de las pruebas Para ello
se requiere el uso de un framework como puede ser el Robot Framework
Centrando la atencioacuten en el enfoque de dicho proyecto se haraacute uso de la libreriacutea Selenium para Python y la
facilidad de Robot Framework tanto para abstraer la posible complejidad antildeadida del lenguaje de programacioacuten
usado para la implementacioacuten de los scripts de prueba como para permitir la generacioacuten automaacutetica de informes
y reportes de resultados
Realmente Selenium estaacute formado por un conjunto de herramientas las cuales son Selenium RC Selenium
IDE Selenium Grid y Selenium Webdriver Dichas herramientas permiten desde la realizacioacuten de pruebas en
maacutequinas remotas a la ejecucioacuten de pruebas en diferentes maacutequinas con diferentes navegadores cada una
Con el lanzamiento de Selenium 2 en 2008 se antildeadieron nuevas funcionalidades de Selenium RC y Webdriver
en una misma herramienta aunque es frecuente mantener la nomenclatura de WebDriver a la hora de referirse
a la misma En este proyecto se centraraacute la atencioacuten en la herramienta WebDriver de Selenium
U
El disentildeo es el alma de todo lo creado por el hombre
Steve Jobs
70
52 Selenium WebDriver
Esta herramienta de Selenium ofrece una interfaz para ejecutar los casos de prueba descritos en los scripts
de prueba A traveacutes de esta API WebDriver se comunica directamente con el controlador del navegador
donde corre la aplicacioacuten Para ello seraacute necesario el uso de controladores para los diferentes navegadores
Web desde los que se validan las pruebas automaacuteticas
Todas las implementaciones de WebDriver que se comunican con el navegador usan un protocolo punto a
punto comuacuten Este protocolo define un servicio RESTfull usando JSON sobre HTTP Cada operacioacuten
realizada por WebDriver se mapea en un meacutetodo HTTP que se comunica con el navegador Las respuestas
a dichas operaciones seraacuten devueltas en mensajes HTTP de respuesta
Existen diversas implementaciones de Selenium para diferentes entornos tal y como se muestra en la
siguiente figura
Figura 41 Implementaciones disponibles de Selenium y Navegadores Web Compatibles
Para la ejecucioacuten de las pruebas implementadas en este proyecto se ha hecho uso de los controladores Gecko
Driver y Chromedriver para los navegadores Web Firefox y Google Chrome
521 Elementos del Navegador
Una vez tenemos una viacutea de comunicacioacuten con el navegador planteamos la pregunta iquesty coacutemo le indico al
navegador con queacute componente quiero interactuar
La cantidad de componentes que existen es muy amplia cajas de texto botones imaacutegenes hiperviacutenculos
botones de radio check boxes aacutereas de texto mensajes de error desplegables tablas frames etc Todos
estos elementos tienen una serie de propiedades que pueden ser uacutenicas o no en toda la paacutegina Por ejemplo
un identificador (ID) debe distinguir de manera uniacutevoca a un elemento Este identificador es lo que se
denomina un localizador Existen 8 tipos distintos de localizadores diferentes
bull Id Name Class Name Tag Name Link Text Partial Link Text CSS Xpath
71
Se podraacuten implementar las interacciones con el navegador mediante la llamada a un meacutetodo (accioacuten) que
se aplicaraacute sobre el elemento que nosotros indiquemos A continuacioacuten se muestra el diagrama de bloques
y la implementacioacuten de un ejemplo simple del inicio de sesioacuten usando Python y la libreriacutea de Selenium
Figura 42 Coacutedigo de ejemplo con Python y Selenium
La implementacioacuten anterior permite abrir un navegador Web Chrome en pantalla completa y acceder a la
plataforma Web Galgus CHT Cloud Manager Una vez ha sido posible el acceso y la paacutegina Web estaacute
disponible se realiza el inicio de sesioacuten en la plataforma con las credenciales correspondientes esperando que
dicho inicio de sesioacuten se haya realizado con eacutexito Finalmente se cierran todas las instancias de navegadores
Web abiertas por Selenium en la automatizacioacuten de dicha prueba de concepto
72
53 Robot Framework (RF)
Para la automatizacioacuten del testeo de la aplicacioacuten se ha hecho uso de este framework como herramienta
para dicha finalidad Robot Framework es un framework geneacuterico de automatizacioacuten de pruebas de coacutedigo
abierto desarrolla do por Pekka Klaumlrck en el antildeo 2005
Este framework sigue el enfoque Keyword-Driven Testing y es un candidato idoacuteneo debido a su alto nivel
de abstraccioacuten para pruebas de aceptacioacuten y desarrollo guiado por pruebas de aceptacioacuten o Acceptance
Test-Driven Development (ATDD) Las capacidades de pruebas pueden ser ampliadas con nuevas libreriacuteas
implementadas tanto en Python como en Java y los usuarios pueden crear nuevas keywords a partir de las
existentes usando la misma sintaxis que para los casos de prueba [18]
Robot Framework es independiente del sistema operativo y de la aplicacioacuten El nuacutecleo del framework estaacute
implementado en Python soportando tanto Python 2 como Python 3
Se ha decidido utilizar este framework por la disponibilidad de un amplio conjunto de libreriacuteas de propoacutesito
general y la integracioacuten con libreriacuteas externas como Selenium2Library Entre otras prestaciones permite el
uso de variables que aportan mayor flexibilidad a la hora de disentildear y controlar los scripts de prueba
permite el etiquetado para poder identificar y ejecutar los casos de prueba por separado proporciona una
faacutecil integracioacuten con Jenkins y Maven y proporciona un sistema de reporte de informes de resultados
detallados y de faacutecil lectura Ademaacutes hay que destacar la faacutecil abstraccioacuten que ofrece al poder utlizar
keywords de alto nivel permitiendo el uso del estilo de representacioacuten Given-When-Then para los casos
de prueba A continuacioacuten se describe dicho estilo de representacioacuten
531 Estilo de representacioacuten Given-When-Then
Dicho estilo ofrecido por Robot Framework es uno de los puntos fuertes de este framework Esta caracteriacutestica
permite el uso del siguiente estilo de representacioacuten para los casos de prueba
Figura 43 Estilo de representacioacuten Given-When-Then
bull Given Define las precondiciones necesarias para llevar a cabo la accioacuten asiacute como el actor de la
misma
bull When Accioacuten llevada a cabo por el actor definido en la claacuteusula Given
bull Then Es el comportamiento esperado o la salida del sistema esperada ante una entrada
determinada
bull And Claacuteusula auxiliar que se usa de forma combinada con las anteriores
73
Como ejemplo de aplicacioacuten de este estilo de representacioacuten supongamos que tenemos unos requisitos de
aceptacioacuten establecidos en un documento entre los que se encuentran el inicio y cierre de sesioacuten mediante
usuario y contrasentildea a la plataforma Galgus CHT Cloud Manager En la siguiente tabla se muestran los
criterios de aceptacioacuten definidos en el documento de requisitos para dicha funcionalidad
1 Un usuario no identificado puede iniciar sesioacuten desde la vista principal de la plataforma Web
2 Un usuario no identificado debe insertar un usuario y contrasentildea vaacutelidos para el inicio de sesioacuten
A continuacioacuten se muestra coacutemo se llevariacutea a cabo la implementacioacuten de los scripts de pruebas abstractos
asociados a las especificaciones anteriores haciendo uso del estilo de representacioacuten Given-When-Then
Es complicado implementar todos los casos de prueba posibles principalmente cuando el requisito de
aceptacioacuten requiere de una funcionalidad compleja En este caso se muestran tres casos de prueba
abstractos los cuales han sido implementados en el proyecto para validar el inicio y cierre de sesioacuten
Caso de Prueba 1 Inicio de Sesioacuten en Galgus CHT Cloud Manager
Claacuteusula Keyword
Given Navegacioacuten a la paacutegina principal de Galgus CHT Cloud Manager
When Insertar nombre de usuario vaacutelido
And Insertar contrasentildea vaacutelida
Then Iniciar sesioacuten con eacutexito
Caso de Prueba 2 Intento de Inicio de sesioacuten con usuario no vaacutelido
Claacuteusula Keyword
Given Navegacioacuten a la paacutegina principal de Galgus CHT Cloud Manager
When Insertar nombre de usuario invaacutelido
And Insertar contrasentildea vaacutelida
Then No es posible el inicio de sesioacuten Se muestra mensaje de error
Caso de Prueba 3 Intento de Inicio de sesioacuten con contrasentildea no vaacutelida
Claacuteusula Keyword
Given Navegacioacuten a la paacutegina principal de Galgus CHT Cloud Manager
When Insertar nombre de usuario vaacutelido
And Insertar contrasentildea invaacutelida
Then No es posible el inicio de sesioacuten Se muestra mensaje de error
74
En la siguiente figura se muestra la implementacioacuten de dichas pruebas con Robot Framework donde cada
Keyword implementada permite la abstraccioacuten de toda la funcionalidad necesaria para realizar las pruebas
Figura 44 Implementacioacuten de Pruebas en para el inicio de sesioacuten de CHT Cloud Manager
75
532 Reportes
A continuacioacuten se muestra un ejemplo de los reportes obtenidos tras la ejecucioacuten del primer caso de prueba de
los anteriores donde pueden identificarse las diversas keywords necesarias para implementar cada caso de
prueba asiacute como otras adicionales que ayudan a crear el contexto (precondiciones) Tambieacuten se incluyen
estadiacutesticas sobre el tiempo de ejecucioacuten nuacutemero de tests total nuacutemero de tests que han fallado o que han pasado
con eacutexito [18]
Figura 45 Ejemplo de reporte de pruebas automatizadas con Robot Framework
76
533 Libreriacuteas
Robot Framework permite el uso de Selenium mediante la libreriacutea de pruebas Web SeleniumLibrary Dicha
libreriacutea es compatible con las versiones de Selenium 2536 y sucesivas y con Python 27 y Python 3 Ademaacutes
del inteacuterprete por defecto de Python esta libreriacutea funciona tambieacuten con PyPy y Jython [18]
Esta libreriacutea estaacute compuesta entre otras muchas por una serie de archivos de Python (py) que implementan
las clases que contienen las diversas keywords que pueden ser usadas en nuestro framework La estructura de
estos archivos se presenta en la siguiente tabla
Archivo de Clase Funcioacuten
Alertpy Interacciones con mensajes de alerta
Browsermanagementpy Apertura cierre y cambio de navegadores
Cookiepy Manipulacioacuten de cookies del navegador
Elementpy Interaccioacuten con elementos y sus atributos
Formelementpy Interaccioacuten con elementos en formularios
Framespy Manejo de frames y su contenido
Javascriptpy Facilidades para inyectar coacutedigo javascript
Runonfailurepy Uso de funcionalidades en caso de fallo
Screenshotpy Manejo de capturas de pantalla
Selectelementpy Manejo de elementos en listas
Tableelementpy Manejo de elementos en tablas
Waitingpy Manejo de temporizadores de espera para
transiciones en una paacutegina
Webdrivertoolspy Interaccioacuten directa con el controlador del navegador
Windowpy Manejo de ventanas del navegador
Estas libreriacuteas fueron desarrolladas en sus oriacutegenes por el ingeniero finlandeacutes Tatu Aalto y posteriormente
mejoradas por toda la comunidad de expertos en automatizacioacuten de pruebas Sin embargo Robot Framework
mediante el uso de Python con Selenium permite la implementacioacuten de libreriacuteas propias o funcionalidades
desarrolladas en Python que pueden ser integradas en Robot Framework En este proyecto se hace uso de Python
con Selenium para desarrollar algunas funcionalidades avanzadas que permiten probar ciertos criterios de la
aplicacioacuten muy especiacuteficos y avanzados de la plataforma Web para los cuales las libreriacuteas ofrecidas por Robot
Framework no proporcionan la funcionalidad requerida
Ademaacutes se ha hecho uso de otras libreriacuteas como BuiltIn para el uso de bucles condicionales y otras keywords
String y Collections para el tratamiento de cadenas de caracteres y colecciones de datos SSHLibrary para usar
un cliente ssh Process para la ejecucioacuten de subprocesos haciendo uso la libreriacutea subprocess de python y
OperatingSystem para realizar algunas tareas sobre el sistema operativo
77
534 Documentacioacuten
La documentacioacuten de los diferentes casos de pruebas implementados con Robot Framework es muy redundante
y una tarea la cual seriacutea deseable de poder automatizar Dicho framework ofrece esta posibilidad a traveacutes de dos
herramientas para crear documentacioacuten basada en las pruebas y libreriacuteas implementadas para dichas pruebas
Libdoc y Testdoc [18]
5341 Libdoc
Libdoc es una herramienta ofrecida por Robot Framework para construir documentacioacuten sobre las keywords
implementadas para los casos de prueba Dicha documentacioacuten es generada en formato HTML y XML
Se puede crear documentacioacuten para bibliotecas implementadas con Python o Java y para las propias libreriacuteas
implementadas con Robot Framework A continuacioacuten se muestra un ejemplo de la documentacioacuten generada
para la libreriacutea implementada para los casos de prueba de inicio y cierre de sesioacuten de Galgus CHT Cloud
Manager
Figura 46 Ejemplo de documentacioacuten generada con Libdoc
5342 Testdoc
Testdoc es una herramienta para generar documentacioacuten de alto nivel basada en los casos de prueba de Robot
Framework Dicha documentacioacuten es generada en formato HTML e incluye el nombre la documentacioacuten y
otros metadatos de cada conjunto de pruebas y casos de prueba asiacute como las keywords de alto nivel y sus
argumentos
A continuacioacuten se muestra un ejemplo de la documentacioacuten generada para el conjunto de casos de prueba que
validan el inicio y cierre de sesioacuten de Galgus CHT Cloud Manager
Figura 47 Ejemplo de documentacioacuten generada con Testdoc
78
54 Pycharm (IDE)
Esta herramienta proporciona un entorno de desarrollo integrado (IDE) el cual ha sido usado para programar en
lenguaje Python por lo que es idoacuteneo tambieacuten para el desarrollo de pruebas con Robot Framework Esta
desarrollado por la empresa JetBrains Ademaacutes proporciona entre otras muchas herramientas el anaacutelisis de
coacutedigo un depurador graacutefico integracioacuten con sistemas de control de versiones y es multiplataforma
55 GitGitlab
551 Git
Git es un software de control de versiones disentildeado por Linux Torvalds pensando en la eficiencia y la
confiabilidad del mantenimiento de versiones de aplicaciones cuando eacutestas tienen un gran nuacutemero de archivos
de coacutedigo fuente Al principio Git se pensoacute como un motor de bajo nivel sobre el cual otros pudieran escribir la
interfaz de usuario como Cogito o StGIT Sin embargo Git se ha convertido desde entonces en un sistema de
control de versiones con funcionalidad plena Hay algunos proyectos de mucha relevancia que ya usan Git en
particular el grupo de programacioacuten del nuacutecleo Linux Ademaacutes cabe destacar que se ha hecho uso de
GitKraken como interfaz graacutefica de git para llevar a cabo el control de versiones de una forma maacutes intuitiva
552 Gitlab
Gitlab es un servicio Web de control de versiones y desarrollo de software colaborativo basado en Git Fue
implementado por los desarrolladores ucranianos Dimitry Zaporozhets y Valey Sizov en el lenguaje de
programacioacuten Ruby Este proyecto cuenta con un equipo de 150 miembros y maacutes de 1400 usuarios y es usado
por empresas como la NASA el CERN IBM o Sony [19]
Ademaacutes de gestor de repositorios tambieacuten ofrece la posibilidad de alojar documentacioacuten y un sistema de
seguimiento de errores Tambieacuten es de gran importancia destacar que esta herramienta proporciona su propia
herramienta de Integracioacuten Continua sin necesidad de usar otra herramienta externa
Se ha hecho uso de estas herramientas para tener un control de versiones sobre nuestro proyecto y una gestioacuten
centralizada de todos los repositorios de la empresa de forma que asiacute podemos tener un control de versiones de
todos los cambios realizados en el coacutedigo con posibilidad de contrastarlos con versiones anteriores y recuperar
dichos cambios Ademaacutes se hace uso tambieacuten de gitlab CICD para implementar procesos de Integracioacuten
continua sobre los diferentes proyectos En el caso particular de este proyecto para generar la documentacioacuten
de los casos de test y libreriacuteas y para generar un Docker con toda la bateriacutea de pruebas y dependencias necesarias
para lanzarlas
56 Redmine
Redmine es una herramienta para la gestioacuten de proyectos que ofrece un conjunto de funcionalidades que
permiten a los usuarios de diferentes proyectos realizar el seguimiento y organizacioacuten de los mismos Incluye
un sistema de seguimiento de incidentes Otras herramientas que incluye son un calendario de actividades
diagramas de Gantt una wiki para almacenar documentacioacuten control del flujo de trabajo basado en roles
integracioacuten con correo electroacutenico etc
Esta herramienta se usa para la gestioacuten del proyecto Galgus CHT Cloud Manager donde se integra como
subproyecto la automatizacioacuten del proceso de pruebas para la plataforma Web desarrollada
A continuacioacuten se muestra un ejemplo del flujo de trabajo implantado en la metodologiacutea de trabajo dentro del
proyecto donde cada historia puede contener un conjunto de tareas las cuales pueden pasar por diferentes
estados hasta ser completadas por el desarrollador o el ingeniero de pruebas
79
Figura 48 Ejemplo de Flujo de Trabajo en Redmine para Galgus CHT Cloud Manager
561 Uso en el Proyecto Galgus CHT Cloud Manager (Metodologiacutea Scrum)
Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas praacutecticas para trabajar
colaborativamente en equipo y obtener el mejor resultado posible de un proyecto Estas praacutecticas se apoyan
unas a otras y su seleccioacuten tiene origen en un estudio de la manera de trabajar de equipos altamente productivos
Esta metodologiacutea divide el trabajo en una lista de pequentildeas funcionalidades ordenadas por prioridad y estimadas
en esfuerzo Estas pequentildeas tareas son abordadas en iteraciones cortas de longitud fija denominadas Sprints de
1 a 4 semanas (en este caso se ha optado por iteraciones de 3 o 4 semanas) obteniendo coacutedigo potencialmente
entregable siendo demostrado al final de cada iteracioacuten Una vez decidido por el equipo de gestioacuten de proyectos
el alcance y conjunto de actividades a realizar dentro del sprint se transmite al resto del equipo que forma parte
del proyecto procediendo a la asignacioacuten de tareas mediante Redmine como herramienta de gestioacuten usada
Durante el sprint se va realizando un seguimiento perioacutedico del estado del proyecto y de la situacioacuten de cada
integrante mediante una actividad previa diaria de unos 15 minutos para situar el punto de partida de trabajo
diario que seriacutean reuniones diarias de apenas 15 minutos denominadas ldquoDaylisrdquo
Figura 49 Esquema Graacutefico de Metodologiacutea Scrum
80
La planificacioacuten que se pretende seguir en cada sprint es la siguiente
1 Semana 1 y 2 Realizacioacuten de tareas por parte del equipo de desarrollo incluyendo en estas tareas
nuevos desarrollos modificacioacuten de funcionalidades y verificacioacuten de las mismas mediante pruebas
unitarias y de integracioacuten
2 Semana 3 Realizacioacuten de pruebas de aceptacioacuten manuales por parte del equipo de pruebas y posterior
automatizacioacuten de dichas pruebas Para ello se usaraacute el entorno de UAT como escenario de pruebas
Ademaacutes el equipo de desarrollo iraacute corrigiendo todos aquellos errores o defectos encontrados
3 Semana 4 El jefe de proyecto realiza la fusioacuten de todos los desarrollos y actualiza las versiones en el
entorno de Preproduccioacuten incluyendo todas las actividades realizadas y validadas por el equipo de
desarrollo y de pruebas El equipo de pruebas realizaraacute la ejecucioacuten de todas las pruebas End-to-End
sobre el entorno de Preproduccioacuten para verificar y validar la nueva versioacuten que incluye todas las
funcionalidades Estas pruebas son denominadas pruebas de regresioacuten las cuales verifican que los
nuevos desarrollos no han provocado defectos o errores sobre funcionalidades que hasta ahora habiacutean
funcionado correctamente Finalmente el jefe de proyecto realiza el despliegue en produccioacuten
81
82
6 EXPERIMENTOS
na vez descrito el sistema bajo pruebas el proceso de pruebas y las herramientas que se usaraacuten para
automatizar las pruebas de aceptacioacuten sobre la plataforma de gestioacuten Galgus CHT Cloud Manager
solo queda presentar la forma en la que se ha puesto en praacutectica y el proceso seguido paso a paso
Dado que el objetivo es conseguir una bateriacutea de casos de pruebas End-to-End automatizadas se implementaraacuten
dichos casos de prueba de forma que permitan detectar el incorrecto funcionamiento de cada funcionalidad con
la mayor rapidez posible cubriendo los principales escenarios donde puedan surgir los mayores errores Por
tanto dichos casos de prueba seraacuten elegidos en base al riesgo que puedan introducir
Estos casos de prueba seraacuten definidos mediante un conjunto de criterios de aceptacioacuten descritos a traveacutes de
diagramas de flujo y agrupados seguacuten la funcionalidad de la aplicacioacuten que abarquen las cuales son
1 Vista de Gestioacuten Principal (Coud Tab) Esta seccioacuten de la Web estaacute destinada a la administracioacuten de
usuarios administracioacuten de los diferentes Zone Managers y finalmente incluye un Mapa con la
ubicacioacuten de cada Zone Manager
2 Vista de Configuracioacuten (Configuration Tab) En esta pestantildea se ofrece la gestioacuten de grupos de puntos
de acceso gestioacuten de backups y restauracioacuten gestioacuten de firmwares zonas CHT etc
3 Vista de Red (Network Tab) La pestantildea de red engloba toda la configuracioacuten de red de los puntos de
acceso siendo esta la pestantildea con mayor funcionalidad complejidad y por ello potencial de riesgo de
errores de la plataforma Web
Figura 50 Logo de Galgus CHT Cloud Manager
U
La uacutenica parte donde el ldquoeacutexitordquo aparece antes que el trabajo es en el diccionario
Vidal Sasoon
83
61 Estructura del Proyecto
La clasificacioacuten funcional anterior seraacute tomada de la misma forma para organizar la estructura del proyecto de
pruebas automatizadas con Robot Framework para un desarrollo ordenado y loacutegico de todo el conjunto de casos
de prueba A continuacioacuten se muestra un ejemplo de la estructura del proyecto el cual se encuentra en desarrollo
y continua mejora
Figura 51 Estructura del Proyecto
Para una mayor modularidad y limpieza en el desarrollo de los casos de Test se han centralizado todos los
localizadores en un archivo llamado ldquoSelectorpyrdquo En la siguiente figura se muestra un fragmento de dicho
fichero
Figura 52 Fragmento del fichero ldquoSelectorpyrdquo
A la hora de obtener los localizadores de los elementos que seraacuten comprobados o usados en los scripts de pruebas
se han usado las herramientas de desarrollador que incluye Google Chrome Para ello basta con navegar a la
paacutegina de la plataforma Web en cualquier navegador y pulsar la tecla F12 Esto mostraraacute las herramientas de
desarrolladores donde encontramos una pestantildea llamada ldquoElementosrdquo donde se puede inspeccionar el
documento ldquoHTMLrdquo de la paacutegina Una vez abierta dicha herramienta seraacute sencillo obtener propiedades de los
diversos elementos que nos permitiraacuten hacer referencia a los mismos en nuestro script de pruebas
Los ldquoXpathrdquo absolutos seraacuten lo usados praacutecticamente en toda la Suite de pruebas El beneficio de los
identificadores uacutenicos es que permiten seleccionar elementos sin que sea necesario hacer referencia a su posicioacuten
dentro del documento HTML Esto evita cualquier problema en caso de que las rutas de un elemento dentro del
citado documento cambien debido a mejoras o despistes por parte de los desarrolladores En cambio usar
selectores basados en la ruta del elemento dentro del documento HTML puede propiciar falsos fallos en el
escenario anterior debido a que no puedan encontrarse en la Web a pesar de que realmente sigan estando
presentes y totalmente funcionales
Por otro lado se han agrupado todas aquellas ldquokeywordsrdquo que puedan ser usadas por otras secciones en la
implementacioacuten de los casos de prueba mediante ficheros nombrados como ldquotab_common_keywords robotrdquo
84
Siguiendo esta jerarquiacutea se ha incluido un fichero llamado ldquoCommon_Keywordsrobotrdquo general en el que se
incluyen las principales ldquokeywordsrdquo que pueden ser usadas en todo el proyecto A continuacioacuten se muestra un
fragmento de este fichero
Figura 53 Fragmento del fichero ldquoCommon_Keywordsrobotrdquo
Tambieacuten se incluye el fichero ldquoConfigurationrobotrdquo para agrupar definiciones de variables que seraacuten
usadas en todo el proyecto ademaacutes de realizar la inclusioacuten de las libreriacuteas a usar Se muestra otra figura
con un fragmento del fichero ldquoConfigurationrobotrdquo
Figura 54 Fragmento del fichero de Configuracioacuten de pruebas ldquoConfigurationrobotrdquo
85
A continuacioacuten se muestra un diagrama que muestra las dependencias de los diferentes archivos y la estructura
seguida por el proyecto
Figura 55 Diagrama de paquetes del proyecto de pruebas
Tras introducir la estructura del proyecto y las diferentes funcionalidades de la plataforma Web Galgus CHT
Cloud Manager a continuacioacuten se mostraraacuten algunos criterios de aceptacioacuten de cada funcionalidad a probar
con diagramas de flujo y scripts de pruebas haciendo uso del estilo de representacioacuten Given-When-Then
Ademaacutes se mostraraacuten algunos detalles de implementacioacuten sobre las pruebas Por otro lado la ejecucioacuten de los
casos de prueba de ejemplo y el reporterevisioacuten de resultados se incluiraacute en la seccioacuten de Anexos
Cada una de las siguientes subsecciones dentro de cada funcionalidad principal de la aplicacioacuten o vista principal
tendraacute su correspondiente Suite de pruebas con un conjunto de casos de Test Todas estas Suites seguiraacuten la
siguiente estructura comuacuten para los casos de Test
Figura 56 Estructura de una Suite de Pruebas
86
Todas las Suites comienzan con una seccioacuten de documentacioacuten para describir el contenido de las pruebas de forma geneacuterica y varias secciones para importar los recursos necesarios para las pruebas (Resource)
Las secciones ldquoSuite Setuprdquo y ldquoSuite Teardownrdquo permiten la ejecucioacuten automaacutetica antes y despueacutes de la bateriacutea de pruebas y las secciones ldquoTest Setuprdquo y ldquoTest Teardownrdquo permiten la ejecucioacuten automaacutetica antes y despueacutes de cada caso de prueba
Un uso tiacutepico de ldquoSuite Setuprdquo es abrir un navegador Web y comprobar la disponibilidad de la Web a probar mientras que el cierre del navegador se realiza con ldquoSuite Teardownrdquo De este modo sea cual sea el resultado de la ejecucioacuten no se quedaraacuten abiertas ventanas gastando recursos de la maacutequina
Por otro lado el uso por defecto de ldquoTest Setuprdquo en este proyecto ha sido el inicio de sesioacuten en la Web CHT Cloud Manager mientras que ldquoTest Teardownrdquo ha sido usado para cerrar tambieacuten el navegador Web Sin embargo la mayoriacutea de las pruebas implementadas necesitan una serie de precondiciones previas a la ejecucioacuten del Test y un conjunto de postcondiciones necesarias para no provocar inconsistencias entre la ejecucioacuten de diferentes pruebas Por este motivo se ha hecho uso de las etiquetas [Setup] y [Teardown] para modificar la ejecucioacuten por defecto de ldquoTest Setuprdquo y ldquoTest Teardownrdquo en cada caso de prueba cuando sea necesario
Cabe destacar que la loacutegica implementada dentro de estas claacuteusulas no requiere que sea validada puesto que su uacutenico objetivo es preparar el entorno de pruebas para ejecutar una prueba sin que esta falle por causas ajenas al aacutembito y objetivo de la prueba evitando de esta forma los falsos positivos Por este motivo se hace uso de la Keyword ldquoRun Keyword And Ignore Errorrdquo ofrecida por la libreriacutea ldquoBuiltInrdquo para ignorar los errores en la ejecucioacuten de [Setup] y [Teardown] En la siguiente figura se muestra un ejemplo de dicha teacutecnica
Figura 57 Ejemplo de ldquoTest Setuprdquo personalizado para un caso de prueba
Finalmente la implementacioacuten de las ldquokeywordsrdquo usadas mediante la nomenclatura Given-When-Then seraacuten agrupadas en el correspondiente fichero ldquoTab_common_keywordsrobotrdquo para conseguir una abstraccioacuten de la loacutegica necesaria para la automatizacioacuten de las pruebas En las pruebas seleccionadas para describir en esta seccioacuten se detallaraacute la implementacioacuten de algunas keywords que se usaraacuten
87
62 Vista de Gestioacuten Principal (Cloud Tab)
En la siguiente figura se muestra la vista de Gestioacuten Principal de Galgus CHT Cloud Manager
Figura 58 Vista de Gestioacuten Principal (Cloud Tab)
Sobre esta vista se han automatizado un conjunto de Suites de pruebas que validan toda la funcionalidad
contenida en las pestantildeas MAP List of Zone Managers y Administration ademaacutes de toda la loacutegica ofrecida para
gestionar un conjunto de fabricantes
621 Administration
Comenzando con la pestantildea de administracioacuten se puede observar la existencia de cuatro flujos de navegacioacuten
principales en la siguiente figura
Figura 59 Pestantildea ldquoAdministrationrdquo
Una vez conocida la vista de administracioacuten de la Web se han realizado un total de 22 casos de prueba de los
cuales detallaremos el caso de prueba identificado con la etiqueta U0027
6211 Criterios de Aceptacioacuten
La pestantildea de administracioacuten permite la gestioacuten de los usuarios y roles que tienen acceso a la plataforma Web
ademaacutes de la configuracioacuten de los detalles de los fabricantes seleccionados A continuacioacuten se detallan los
criterios de aceptacioacuten del caso de prueba seleccionado
U0027 Un usuario con permisos de Super Usuario puede editar la informacioacuten de un fabricante
1 Un usuario con permisos de Super Usuario puede ver y acceder a la pestantildea de administracioacuten
2 Un usuario con permisos de Super Usuario puede editar la informacioacuten de un fabricante correctamente
88
6212 Diagramas de Flujo
A continuacioacuten se muestran los diagramas de flujo implementados para los dos casos de prueba analizados
Figura 60 Diagramas de Flujo de Casos de Prueba U0025 y U0027
6213 Script de Pruebas
Una vez establecidos los criterios de aceptacioacuten de ambos casos de prueba se mostraraacuten los scripts de pruebas
realizados
Figura 61 Script de Pruebas U0025
Entre las ldquokeywordsrdquo usadas en el caso de test anterior se puede destacar por ejemplo la implementacioacuten de
ldquoEdit Fieldsrdquo la cual permite editar los campos de un fabricante y verificar que han sido editados tras guardar
los cambios
Figura 62 Keyword ldquoEdit Fieldsrdquo
89
622 List
En la pestantildea de gestioacuten de los diferentes Zone Managers se puede observar una lista de los diferentes Zone
Managers disponibles y se pueden realizar un conjunto de acciones como la creacioacuten de nuevos Zone Managers
y edicioacuten o eliminacioacuten de los existentes entre otras
Figura 63 Pestantildea ldquoList of Zone Managersrdquo
Sobre esta vista se han realizado un total de 7 casos de prueba de los cuales detallaremos el caso de prueba
identificado con la etiqueta U0023 el cual permite validar la creacioacuten y eliminacioacuten de un Zone Manager
6221 Criterios de Aceptacioacuten
A continuacioacuten se detallan los criterios de aceptacioacuten del caso de prueba seleccionado
U0023 Verificar que un Usuario puede Crear y Eliminar un Zone Manager
1 Un usuario con permisos de Super Usuario puede Navegar a la pestantildea List Of Zone Managers
2 El usuario puede crear un Zone Manager correctamente
3 El usuario puede eliminar un Zone Manager correctamente
6222 Diagramas de Flujo
A continuacioacuten se muestra el diagrama de flujo implementado para el caso de prueba analizado
Figura 64 Diagrama de flujo de Caso de Prueba U0023
90
6223 Script de Pruebas
Una vez establecidos los criterios de aceptacioacuten se mostraraacute el script de pruebas realizado a partir del diagrama
de flujo anterior
Figura 65 Script de Prueba U0023
Cabe destacar la implementacioacuten de la Keyword ldquoZone Manager is Registered Successfullyrdquo la cual comprueba
que el Zone Manager registrado pasa a un estado ldquoOnlinerdquo tras un tiempo considerado como aceptable para que
la instancia de dicho Zone Manager este disponible en Cloud CHT Manager
Figura 66 Keyword ldquoZone Manager is registered successfullyrdquo
623 Manufacturer
La vista de gestioacuten principal ofrece una seccioacuten que permite la gestioacuten de los diferentes fabricantes permitiendo
su creacioacuten edicioacuten eliminacioacuten y bloqueo En la siguiente figura se muestra un ejemplo de la seccioacuten de
fabricantes
Figura 67 Seccioacuten de Fabricantes
Para validar el correcto funcionamiento de dicha seccioacuten se han realizado un total de 9 casos de prueba de los
cuales se detallaraacuten los casos de prueba identificados con las etiquetas U0009 Estos permiten validar que los
fabricantes pueden ser creados editados y eliminados correctamente y que todos los fabricantes disponibles son
mostrados correctamente
91
6231 Criterios de Aceptacioacuten
A continuacioacuten se detallan los criterios de aceptacioacuten de los casos de prueba seleccionados
U0009 Verificar que un Usuario con permisos de Super usuario puede ver correctamente todos los
fabricantes existentes
1 Un usuario con permisos de Super Usuario puede Navegar a la pestantildea de Administracioacuten
2 El usuario puede visualizar todos los fabricantes existentes
6232 Diagrama de Flujo
Figura 68 Diagrama de flujo de Caso de Prueba U0009
6233 Script de Pruebas
Una vez establecidos los criterios de aceptacioacuten se mostraraacuten los scripts de pruebas realizados a partir de los
diagramas de flujo anteriores
Figura 69 Script de Prueba U0009
En este punto cabe destacar la finalidad de la Keyword ldquoCorrectly Createrdquo la cual se usa en la mayoriacutea de las
pruebas para verificar que una operacioacuten se ha realizado con eacutexito en la plataforma Galgus CHT Cloud Manager
Esta Keyword verifica que tras realizar alguacuten tipo de operacioacuten en la plataforma Web ocurre un evento sobre la
Web que indica que dicha operacioacuten se ha realizado con eacutexito de la siguiente forma
92
Figura 70 Toast Success
Figura 71 Keyword ldquoCorrectly Createrdquo
Finalmente se muestra la implementacioacuten de las keywords usadas en [Setup] y [Teardown] del caso de prueba
U0009 las cuales preparan el escenario de pruebas creando un conjunto de fabricantes acotado y los elimina
tras la finalizacioacuten de la prueba
Figura 72 Setup amp Teardown de U0008
624 MAP
La plataforma Galgus CHT Cloud Manager ofrece una pestantildea ldquoMAPrdquo que contiene un mapa con la ubicacioacuten
asignada a cada uno de los Zone Managers disponibles por el usuario mostrando en su ubicacioacuten un icono con
el estado de dicho Zone Manager el cual cambia de color seguacuten su estado (offline online unsynchronized)
Figura 73 Mapa de Zone Managers
93
A traveacutes de dicho icono se puede realizar una serie de acciones entre ellas acceder a un Zone Manager
realizando doble click sobre el icono del mismo Sin embargo para automatizar este conjunto de acciones el
equipo de pruebas ha encontrado dificultades haciendo uso de Robot Framework ya que las libreriacuteas disponibles
permiten la interaccioacuten con elementos de la Web pero en este caso los iconos de los diferentes Zone Managers
son renderizados dentro del Mapa con ldquoOpen Street Mapsrdquo antes de ser mostrado en la vista Web de la
aplicacioacuten Por esta razoacuten el mapa es localizado en el DOM como un uacutenico elemento Web lo que imposibilita
localizar a priori el icono de cada Zone Manager dentro del Mapa
Para resolver este impedimento el equipo de pruebas tuvo que analizar con profundidad la libreriacutea de ldquoOpen
Street Maprdquo implementada en Javascript Esta ha sido usada en el Frontend para encontrar alguna funcioacuten que
permitiese obtener desde la consola del navegador Web los piacutexeles en los que cada Zone Manager ha sido
renderizado dentro del Mapa Dicha funcioacuten es ldquogetPixelsFromCoordinate(coordinate)rdquo la cual a traveacutes de las
coordenadas de [Latitud Longitud] de cada Zone Manager se obtienen los piacutexeles del mismo en la pantalla A
traveacutes del siguiente fragmento de coacutedigo en el frontend implementado con Angular 6 en typescript se consigue
obtener los piacutexeles de cada Zone Manager e imprimirlo en la consola del navegador Web
Figura 74 Funcioacuten que dibuja los ZM en el Mapa y obtiene los piacutexeles en pantalla
Para llevar a cabo la implementacioacuten de las pruebas sobre el mapa se ha hecho uso en su gran mayoriacutea de Scripts
con Python Selenium y otras libreriacuteas necesarias en lugar de Robot Framework debido a la necesidad de
realizar varias tareas simultaneas ademaacutes de tratarse de pruebas muy especiacuteficas y personalizadas A
continuacioacuten se muestra la prueba implementada para poder realizar doble click sobre un Zone manager en el
mapa e iniciar sesioacuten en el mismo (U0007)
6241 Criterios de Aceptacioacuten
U0007 Verificar que un Usuario acceder a un Zone Manager desde el Mapa
1 Un usuario con permisos de Super Usuario puede Navegar a la pestantildea MAP
2 El usuario puede hacer doble click en el Zone Manager e iniciar sesioacuten
94
6242 Diagrama de Flujo
Figura 75 Diagrama de Flujo de Caso de Prueba U0007
6243 Script de Pruebas
Para la implementacioacuten de este tipo de casos de prueba se ha hecho uso de la libreriacutea ldquoHtmlTestRunnerrdquo para
obtener un reporte similar al ofrecido por Robot Framework en la ejecucioacuten de la prueba Para obtener un reporte
de la prueba la implementacioacuten de la misma debe seguir una estructura determinada a la que ademaacutes se ha
incluido a traveacutes de la libreriacutea ldquomultiprocessingrdquo la ejecucioacuten simultaacutenea de los dos procesos descritos en el
diagrama de flujo anterior Es necesaria la ejecucioacuten de varios procesos para leer la consola del navegador Web
y obtener los piacutexeles de los Zone Manager para posteriormente hacer doble click
En la Seccioacuten A3 de los anexos puede encontrarse la implementacioacuten del script de pruebas para el caso de
prueba U0007
95
63 Vista de Configuracioacuten (Configuration Tab)
En esta vista se ha automatizado un conjunto de Suites de prueba que validan toda la funcionalidad contenida
en las pestantildeas Groups CHT Zones BackupRestore y Firmware
631 Groups
La pestantildea de grupos permite el descubrimiento de los puntos de acceso a traveacutes de su direccioacuten MAC quedando
estos registrados en base de datos y mostrando al usuario en una tabla los puntos de acceso registrados ademaacutes
del estado de los mismos y otros datos como el modelo o grupo al que pertenecen
Figura 76 Pestantildea ldquoGroupsrdquo
Sobre esta funcionalidad de la plataforma se han realizado un total de 19 casos de prueba de los cuales
detallaremos el caso de prueba identificado con la etiqueta U0119
6311 Criterios de Aceptacioacuten
U0119 Verificar que al descubrir dos puntos de acceso en grupos diferentes ambos son antildeadidos en el
grupo correcto
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Configuracioacuten
3 El usuario puede Navegar a la pestantildea de Grupos
4 El usuario puede descubrir un punto de acceso en el grupo ldquorootrdquo correctamente
5 El usuario puede crear un subgrupo predecesor del grupo ldquorootrdquo correctamente
6 El usuario puede navegar al subgrupo creado correctamente
7 El usuario puede descubrir un punto de acceso en el subgrupo correctamente
96
6312 Diagramas de Flujo
Figura 77 Diagrama de flujo de Caso de Prueba U0119
97
6313 Script de Pruebas
Una vez establecidos los criterios de aceptacioacuten el script de prueba realizado a partir del diagrama de flujo
anterior es el siguiente
Figura 78 Script de Prueba U0119
Entre las keywords implementadas para esta prueba cabe destacar la implementacioacuten de ldquoVerify if AP is
registered Succesfully on grouprdquo la cual permite validar si un punto de acceso ha sido asignado al grupo
correcto
Figura 79 Keyword ldquoVerify if AP is registered Succesfully on grouprdquo
Puede observarse como en primer lugar se obtiene la fila de la tabla que contiene el punto de acceso en cuestioacuten
para posteriormente comprobar si el grupo al que pertenece es el esperado
Observando dicha implementacioacuten cabe destacar el uso de la Keyword ldquoInput Into Text Fieldrdquo la cual ha sido
implementada para vaciar el contenido de campos de texto ya que mediante la Keyword ldquoClear Element Textrdquo
de la libreriacutea Selenium2Library no se conseguiacutea borrar ciertos campos de texto
Figura 80 Keywords Input Into Text Field y Clear Field Of Characters
98
632 CHT Zones
En la pestantildea de gestioacuten de las diferentes Zonas CHT se puede observar una lista de los puntos de acceso
disponibles y se pueden realizar un conjunto de acciones sobre ellos como la creacioacuten eliminacioacuten y asociacioacuten
de zonas CHT
En este punto es conveniente explicar el concepto de zona CHT el cual se refiere a un grupo IP Multicast a
traveacutes del cual un conjunto de Puntos de Acceso establece comunicacioacuten de forma colaborativa Esta
comunicacioacuten es necesaria para el funcionamiento de algunos de los algoritmos que ofrece CHT como por
ejemplo la asignacioacuten automaacutetica de canal (ACA)
Figura 81 Pestantildea ldquoCHT Zonesrdquo
Sobre esta vista se han realizado un total de 6 casos de prueba de los cuales detallaremos el caso de prueba
identificado con la etiqueta U0204 Este caso de prueba permite validar la asignacioacuten de zonas CHT a los Puntos
de Acceso
6321 Criterios de Aceptacioacuten
U0204 Verificar que un usuario puede asignar una Zona CHT a un punto de acceso correctamente
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Configuracioacuten
3 El usuario puede Navegar a la pestantildea de Grupos
4 El usuario puede asignar una Zona CHT existente a un punto de acceso registrado correctamente
99
6322 Diagramas de Flujo
Figura 82 Diagrama de Flujo de Caso de Prueba U0204
6323 Script de Pruebas
Tras presentar los criterios de aceptacioacuten y su correspondiente diagrama de flujo el script de pruebas
implementado para la automatizacioacuten de dicha prueba es el siguiente
Figura 83 Scripts de Prueba U0204
Figura 84 Keyword Add Zone CHT to AP
100
633 BackupRestore
En esta pestantildea se permite la gestioacuten de copias de seguridad y restauracioacuten de los puntos de acceso registrados
en un Zone Manager Se puede observar en esta vista una tabla con los puntos de acceso registrados y otra tabla
con las copias de seguridad realizadas sobre los puntos de acceso
Figura 85 Pestantildea BackupRestore
Partiendo de la representacioacuten funcional de esta vista se han realizado un total de 8 casos de prueba de los
cuales detallaremos el caso de prueba identificado con la etiqueta U0401 el cual permite verificar de forma
automaacutetica la realizacioacuten de un backup sobre un punto de acceso y su posterior restauracioacuten
6331 Criterios de Aceptacioacuten
U0401 Verificar que un usuario puede realizar un BackupRestore correctamente sobre un punto de
acceso previamente registrado
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Configuracioacuten
3 El usuario puede Navegar a la pestantildea de BackupRestore
4 El usuario puede realizar un Backup sobre un punto de acceso existente
5 La tabla de Backups contiene la copia de seguridad realizada
6 El usuario puede restaurar un punto de acceso correctamente
101
6332 Diagramas de Flujo
Figura 86 Diagrama de Flujo de Caso de Prueba U0401
6333 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 87 Script de Prueba U0401
Cabe destacar la implementacioacuten de la Keyword ldquoRestore for AP have done successfullyrdquo la cual verifica que
el punto de acceso ha sido restaurado correctamente esperando que el punto de acceso vuelva a estar en estado
ldquoonlinerdquo durante un tiempo aceptable Si pasado dicho tiempo no recupera dicho estado la prueba se dariacutea por
erroacutenea
Figura 88 Keyword Restore For AP hace done successfully
634 Firmware
Esta uacuteltima pestantildea de la vista principal de configuracioacuten proporciona al usuario la posibilidad de subir los
firmwares de los diferentes modelos de puntos de acceso en sus diferentes versiones del software CHT de forma
que es posible la actualizacioacuten del firmware de los puntos de acceso desde la plataforma Se puede observar en
esta vista una tabla con los puntos de acceso registrados y otra tabla con los firmwares subidos a la plataforma
102
Figura 89 Pestantildea ldquoFirmwarerdquo
Partiendo de la representacioacuten funcional de esta vista se han realizado un total de 7 casos de prueba de los
cuales detallaremos el caso de prueba identificado con la etiqueta U0303 el cual permite verificar de forma
automaacutetica la actualizacioacuten del firmware de un punto de acceso
6341 Criterios de Aceptacioacuten
U0303 Verificar que un usuario puede realizar correctamente la actualizacioacuten del firmware de un punto
de acceso
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Configuracioacuten
3 El usuario puede Navegar a la pestantildea de Firmware
4 El usuario puede subir un firmware correctamente
5 La tabla de Firmwares contiene la imagen de CHT subida a la plataforma
6 El usuario puede realizar la actualizacioacuten del firmware sobre un punto de acceso correctamente
Destacar que el firmware que se desea aplicar sobre un punto de acceso debe ser del modelo correspondiente al
punto de acceso usado ya que cada punto de acceso tiene una imagen de CHT compilada para una arquitectura
hardware determinada Las imaacutegenes son proporcionadas por un servidor interno de la empresa
103
6342 Diagramas de Flujo
Figura 90 Diagrama de Flujo de Caso de Prueba U0303
6343 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 91 Script de Prueba U0303
Cabe destacar la implementacioacuten de la Keyword ldquoFlash APrdquo la cual realiza la actualizacioacuten del firmware de un
punto de acceso verificando que este ha concluido correctamente Para ello espera un tiempo aceptable a que el
punto de acceso vuelva al estado ldquoonlinerdquo
Figura 92 Keyword Flash AP
104
64 Vista de Red (Network Tab)
La uacuteltima vista principal sobre la que se han automatizado pruebas es la vista de Red la cual ofrece al usuario
la gestioacuten y configuracioacuten de su red formada por un conjunto de puntos de acceso previamente registrados
Entre las funcionalidades ofrecidas se encuentran la creacioacuten de VLANS SSIDs Portales Cautivos Perfiles
Radius Activacioacuten de algoritmos CHT y la configuracioacuten de puntos de acceso en tiempo real desde la
plataforma Web
Para describir el proceso de automatizacioacuten se comenzaraacute detallando en primer lugar la creacioacuten de VLANS
Brigdes y SSIDs para posteriormente aplicar dichos paraacutemetros a puntos de acceso desde las pestantildeas ldquoGeneralrdquo
y ldquoAP Networkrdquo Finalmente se mostraraacuten algunos ejemplos sobre otras configuraciones maacutes avanzadas como
la creacioacuten y aplicacioacuten de perfiles radius y portales cautivos ademaacutes de la activacioacuten de algoritmos
641 VLANS amp Bridges
Comenzando con la pestantildea de VLANS amp Bridges se puede observar la existencia de una tabla para cada
elemento de dicha vista
Figura 93 Pestantildea ldquoVLAN amp Bridgesrdquo
Para cada elemento se han automatizado un conjunto de pruebas formado por 6 casos de prueba de los cuales
detallaremos el caso de prueba identificado con la etiqueta U0527 Este caso de prueba permite validar de forma
automaacutetica la creacioacuten y eliminacioacuten de VLANs De forma ideacutentica se procederiacutea para validar la creacioacuten y
eliminacioacuten de Bridges
6411 Criterios de Aceptacioacuten
A continuacioacuten se detallan los criterios de aceptacioacuten del caso de prueba seleccionado
U0527 Verificar que un usuario puede crear y eliminar una VLAN correctamente
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Network
3 El usuario puede Navegar a la pestantildea de VLANS amp Bridges
4 El usuario puede crear una VLAN correctamente
5 El usuario puede eliminar una VLAN correctamente
105
6412 Diagramas de Flujo
Figura 94 Diagrama de Flujo de Caso de Prueba U0527
6413 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 95 Script de Prueba U0527
Cabe destacar la implementacioacuten de la Keyword ldquoGo and Create VLANrdquo la cual permite crear una VLAN en
funcioacuten de los paraacutemetros de entrada deseados para configurar dicha VLAN como por ejemplo el ldquoIDrdquo de la
VLAN y alias o si se desea que dicha VLAN sea de tipo dinaacutemica
Figura 96 Keyword Go And Create VLAN
106
642 SSIDs
Esta pestantildea proporciona una tabla que permite registrar SSIDs con diferentes configuraciones posibles
Figura 97 Pestantildea SSIDs
Para cada funcionalidad de dicha pestantildea se han automatizado un conjunto de pruebas formado por 5 casos de
prueba de los cuales detallaremos el caso de prueba identificado con la etiqueta U0530 Este caso de prueba
permite validar de forma automaacutetica la creacioacuten y eliminacioacuten de SSIDS
6421 Criterios de Aceptacioacuten
A continuacioacuten se detallan los criterios de aceptacioacuten de los dos casos de prueba seleccionados
U0530 Verificar que un usuario puede crear y eliminar una SSID correctamente
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Network
3 El usuario puede Navegar a la pestantildea de SSIDs
4 El usuario puede crear una SSID correctamente
5 El usuario puede eliminar una SSID correctamente
6422 Diagramas de Flujo
Figura 98 Diagrama de Flujo de Caso de Prueba U0530
107
6423 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 99 Script de Prueba U0530
Cabe destacar la implementacioacuten de la Keyword ldquoGo and Create SSIDrdquo la cual permite crear una SSID en
funcioacuten de los paraacutemetros de entradas deseado para configurar dicha SSID como por ejemplo tipo de
encriptacioacuten de la contrasentildea modo oculto o habilitacioacuten de los algoritmos Load Balancing (LB) Smart
roaming (SR) o PRE
Figura 100 Keyword Go And Create SSID
108
643 CHT
Esta funcionalidad permite activar el algoritmo que permite la seleccioacuten automaacutetica de canal entre un conjunto
de puntos de acceso (ACA) Cuando se activa desde la plataforma Web todos los puntos de acceso
pertenecientes a un Zone Manager activan dicho algoritmo el cual se trata de un algoritmo colaborativo
mediante el cual los puntos de acceso acuerdan cual es el mejor canal para la comunicacioacuten WiFi con los clientes
que se conecten tanto en la banda de 24 GHz como en la de 5 GHz En la siguiente figura se muestra la vista
de la plataforma Web para activar el algoritmo en cuestioacuten
Figura 101 Pestantildea ldquoCHTrdquo
Dado que se trata de una funcionalidad en la que solo se debe comprobar si el algoritmo estaacute en el mismo estado
tanto en la plataforma Web como en los puntos de acceso registrados se ha implementado un uacutenico caso de
prueba identificado con la etiqueta U539 Este caso de prueba realiza la conexioacuten a los puntos de acceso para
verificar que dicho algoritmo presenta el mismo estado que en la plataforma
6431 Criterios de Aceptacioacuten
U0537 Verificar que un usuario puede Activar o Desactivar el algoritmo ACA correctamente
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Network
3 El usuario puede Navegar a la pestantildea de CHT
4 El usuario puede ActivarDesactivar el algoritmo ldquoACA ldquocorrectamente
5 Los APs recibieron las oacuterdenes para ActivarDesactivar el algoritmo ldquoACArdquo correctamente
109
6432 Diagramas de Flujo
Figura 102 Diagrama de Flujo de Caso de Prueba U0539
6433 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 103 Script de Prueba U0539
En cuanto a la implementacioacuten de dicho caso de prueba cabe destacar la implementacioacuten de la Keyword ldquoACA
Is Workingrdquo las cual se muestra en la siguiente figura
Figura 104 Keyword ACA Is Working
Puede observarse como en funcioacuten de si el algoritmo ACA esta activado o desactivado en la plataforma Web
(ENABLE DISABLE) se ejecuta la Keyword ldquoChanges On CLIrdquo con diferentes paraacutemetros Esta Keyword
permite la conexioacuten viacutea ldquoSSHrdquo con un punto de acceso para la ejecucioacuten de un comando sobre el mismo y la
posterior comparacioacuten del resultado obtenido por dicho comando con la salida deseada proporcionada tambieacuten
como paraacutemetro de la Keyword
110
En la siguiente figura se muestra la implementacioacuten de dicha Keyword
Figura 105 Keyword Changes On CLI
Para este caso de prueba el comando ejecutado de forma remota sobre el punto de acceso permite obtener de
forma automaacutetica el estado del algoritmo ldquoACArdquo de la siguiente forma
Figura 106 Comando CHT para obtener el estado del moacutedulo ACA en el punto de acceso
644 Radius
Esta pestantildea proporciona una tabla que permite registrar perfiles Radius con diferentes configuraciones posibles
Figura 107 Pestantildea ldquoRadiusrdquo
ldquoRadiusrdquo se define como un protocolo de autenticacioacuten y autorizacioacuten para aplicaciones de acceso a la red o
movilidad IP De esta forma los puntos de acceso mediante la existencia de un servidor radius permiten que los
usuarios que se quieran conectar por WiFi necesiten ser autenticados con credenciales Dicha autenticacioacuten seraacute
redirigida por el punto de acceso al servidor radius el cual autoriza al punto de acceso para que permita la
conexioacuten del cliente
Ademaacutes el uso de este servicio junto con la configuracioacuten mediante VLAN dinaacutemicas permite que diferentes
usuarios accedan al servicio de red con diferentes credenciales de forma que seguacuten el tipo de cliente su traacutefico
viajaraacute por una VLAN u otra Esto permite la separacioacuten del traacutefico a nivel de enlace ofreciendo la posibilidad
de establecer reglas de control de traacutefico y ofrece una QoS miacutenima en funcioacuten del tipo de cliente
Figura 108 Escenario de Funcionamiento de Servidor Radius
111
Para cada funcionalidad de dicha pestantildea se han automatizado un conjunto de pruebas formado por 7 casos de
prueba de los cuales detallaremos el caso de prueba identificado con la etiqueta U0601 Este caso de prueba
permite validar de forma automaacutetica la creacioacuten edicioacuten y borrado de un perfil radius en la plataforma Web
6441 Criterios de Aceptacioacuten
U0601 Verificar que un usuario puede crear editar y borrar un perfil Radius correctamente
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Network
3 El usuario puede Navegar a la pestantildea de Radius
4 El usuario puede Crear un perfil Radius correctamente
5 El usuario puede Editar un perfil Radius correctamente
6 El usuario puede Eliminar un perfil Radius correctamente
6442 Diagramas de Flujo
Figura 109 Diagrama de Flujo de Caso de Prueba U0601
6443 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 110 Script de Prueba U0601
En cuanto a la implementacioacuten de dicho caso de prueba puede destacarse por ejemplo la implementacioacuten de
la Keyword ldquoCreate Radius Profilerdquo la cual permite crear un perfil ldquoRadiusrdquo a partir de un conjunto de
paraacutemetros de entrada
112
Figura 111 Keyword Create Radius Profile
645 Captive Portal
Esta pestantildea proporciona una tabla que permite registrar perfiles de Portales Cautivos con diferentes
configuraciones posibles
Figura 112 Pestantildea Captive Portals
Un portal cautivo es un servicio que permite el control del traacutefico HTTP y fuerza a los usuarios de una red a la
autenticacioacuten mediante una paacutegina Web para tener acceso a Internet Dicho portal permite controlar paraacutemetros
como el tiempo de conexioacuten de un cliente a la red ancho de banda ofrecido a cada cliente etc
Figura 113 Escenario de Funcionamiento de un Portal Cautivo
Para cada funcionalidad de dicha pestantildea se han automatizado un conjunto de pruebas formado por 5 casos de
prueba de los cuales detallaremos el caso de prueba identificado con la etiqueta U0701 Este caso de prueba
permite validar de forma automaacutetica la creacioacuten edicioacuten y borrado de un perfil de portal cautivo en la plataforma
Web
113
6451 Criterios de Aceptacioacuten
U0701 Verificar que un usuario puede crear editar y borrar un perfil de Portal Cautivo correctamente
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Network
3 El usuario puede Navegar a la pestantildea de Captive Portals
4 El usuario puede Crear un perfil de Portal Cautivo correctamente
5 El usuario puede Editar un perfil de Portal Cautivo correctamente
6 El usuario puede Eliminar un perfil de Portal Cautivo correctamente
6452 Diagramas de Flujo
Figura 114 Diagrama de Flujo de Caso de Prueba U0701
6453 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 115 Script de Prueba U0701
114
En cuanto a la implementacioacuten de dicho caso de prueba puede destacarse por ejemplo la implementacioacuten de
la Keyword ldquoEdit or delete Captive Portal Profilerdquo la cual permite editar o eliminar un perfil de Portal Cautivo
a partir de un conjunto de paraacutemetros de entrada
Figura 116 Keyword Edit or Delete Captive Portal Profile
115
646 General
Esta pestantildea muestra la vista general de la pestantildea ldquoNetworkrdquo En esta pestantildea se agrupa el conjunto de puntos
de acceso actualmente registrados en el Zone Manager con un resumen de su configuracioacuten de red actual el
estado en el que se encuentran y nuacutemero de clientes conectados Ademaacutes dicha vista proporciona un acceso
directo a la pestantildea ldquoAP Networkrdquo seleccionando uno o varios puntos de acceso de un mismo modelo En la
siguiente seccioacuten se explica la funcionalidad de dicha pestantildea
Figura 117 Pestantildea General
Para cada elemento se han automatizado un conjunto de pruebas formado por 9 casos de prueba de los cuales
detallaremos el caso de prueba identificado con la etiqueta U0522 Este caso de prueba se permite validar de
forma automaacutetica la conexioacuten de clientes a un punto de acceso con una SSID asignada de forma que el nuacutemero
de clientes conectados que se muestra en la plataforma Web sea correcto
6461 Criterios de Aceptacioacuten
U0522 Conectar clientes y verificar que el nuacutemero de clientes conectados es correcto
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Network
3 El usuario puede Navegar a la pestantildea General
4 El usuario tiene disponible un punto de acceso en el Zone Manager con una SSID asignada
5 El usuario conecta un cliente al punto de acceso por WiFi a la SSID asignada
6 El usuario verifica que el nuacutemero de clientes conectados incrementa en una unidad
116
6462 Diagramas de Flujo
Figura 118 Diagrama de Flujo de Caso de Prueba U0522
6463 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de prueba automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 119 Script de Prueba U0522
En cuanto a la implementacioacuten de dicho caso de prueba puede destacarse por ejemplo la implementacioacuten de
la Keyword ldquoCheck Number of Clients Increasesrdquo la cual permite comprobar que el nuacutemero de clientes conectados incrementa al conectar un cliente a un punto de acceso
Figura 120 Keyword Check Number of Clients Increases
117
647 AP Network
Esta pestantildea muestra la vista principal de la pestantildea ldquoAP Networkrdquo La funcionalidad que proporciona engloba
todos los posibles paraacutemetros de configuracioacuten para un punto de acceso que ha sido seleccionado previamente
desde la pestantildea General Cualquier configuracioacuten aplicada sobre esta vista seraacute enviada al punto de acceso
desde la plataforma Web permitiendo configurar los puntos de acceso de Galgus
Desde el punto de vista de la plataforma Web esta vista abarca un conjunto de funcionalidades consideradas
como maacutes complejas que se ofrecen en la plataforma Web por lo que es en esta vista donde puede encontrarse
una de las mayores aacutereas de riesgo de la plataforma Entre las funcionalidades que se ofrecen estaacuten la
configuracioacuten de las radios de un punto de acceso (Potencia Ancho de banda Canal etc) asignacioacuten de SSIDs
a las interfaces inalaacutembricas y configuracioacuten de reglas de control de traacutefico (TC Rules) asignacioacuten de puertos a
las diferentes subredes virtuales de aacuterea local (VLANS) o configuracioacuten de Portal Cautivo
Figura 121 Pestantildea AP Network
Para cada elemento se han automatizado un conjunto de pruebas formado por 28 casos de prueba los cuales la
mayoriacutea han requerido un amplio esfuerzo de implementacioacuten para conseguir su automatizacioacuten ya que son
pruebas cuya secuencia de acciones es larga ademaacutes de requerir en muchas ocasiones la verificacioacuten de la
configuracioacuten en los puntos de acceso viacutea ldquosshrdquo Para ello se ha hecho uso entre otras de la libreriacutea
ldquoSSHLibraryrdquo proporcionada por Robot Framework
Figura 122 Libreriacutea SSH para Robot Framework
118
Del conjunto de casos de prueba que validan la funcionalidad de dicha pestantildea se va a detallar el caso de prueba
identificado con la etiqueta U0511 Este caso de prueba permite validar de forma automaacutetica que se pueden
aplicar reglas de control de traacutefico ldquoTCsrdquo a una SSID asignada a las interfaces inalaacutembricas de un punto de
acceso desde la plataforma Web
Figura 123 Ventana de Configuracioacuten de TC Rules
6471 Criterios de Aceptacioacuten
U0511 Asignar ldquoTC Rulesrdquo a una SSID asociada a un Punto de Acceso correctamente
1 Un usuario con permisos de Super Usuario puede Navegar a un Zone Manager Existente
2 El usuario puede Navegar a la pestantildea de Network
3 El usuario puede Navegar a la pestantildea General
4 El usuario tiene disponible un punto de acceso en el Zone Manager
5 El usuario puede seleccionar un punto de acceso
6 El usuario puede Navegar a la pestantildea AP Network para el punto de acceso seleccionado
7 El usuario puede asignar a las interfaces inalaacutembricas una SSID existente y crear ldquoTC Rulesrdquo sobre
esa SSID
8 El usuario puede aplicar la configuracioacuten
9 El punto de acceso aplica su configuracioacuten correctamente
10 El punto de acceso pasa al estado ldquoOnlinerdquo en la plataforma Web y su configuracioacuten estaacute alineada
119
6472 Diagramas de Flujo
Figura 124 Diagrama de Flujo de Caso de Prueba U0511
120
6473 Script de Pruebas
En la siguiente figura se muestra la implementacioacuten del script de pruebas automatizado el cual cumple con los
criterios de aceptacioacuten planteados
Figura 125 Script de Prueba U0511
En cuanto a la implementacioacuten de dicho caso de prueba puede destacarse por ejemplo la implementacioacuten de
la Keyword ldquoWait Timerrdquo la cual permite verificar que no se produce ninguacuten error al aplicar una configuracioacuten
determinada desde la plataforma Web durante un tiempo determinado
Figura 126 Keyword Wait Timer
Destacar tambieacuten la implementacioacuten de la Keyword ldquoCheck On CLIrdquo la cual permite contrastar que la
configuracioacuten aplicada desde la plataforma sobre un punto de acceso es la esperada En este caso se comprueba
que las ldquoTC Rulesrdquo han sido correctamente aplicadas para una SSID determinada en un punto de acceso de
forma remota mediante el uso de la libreriacutea ldquoSSHrdquo para Robot Framework
Figura 127 Keyword Check On CLI
121
122
7 LINEAS DE MEJORA Y CONCLUSIONES
n este uacuteltimo capiacutetulo se analizaraacuten resultados y conclusiones obtenidas sobre el uso de pruebas
automatizadas para la verificacioacuten y validacioacuten de una plataforma Web como la de Galgus Se
detallaraacuten algunas ventajas e inconvenientes encontrados y se plantearaacuten algunas liacuteneas de mejora
futuras sobre el proyecto desarrollado Con estas mejoras se busca como objetivo enriquecer el proceso de
automatizacioacuten de pruebas ademaacutes de hacerlo maacutes efectivo y metoacutedico en todos sus aspectos ya que siempre
hay algo que se puede mejorar para conseguir una herramienta maacutes completa y uacutetil
Se detallaraacuten tambieacuten aspectos de aprendizaje opiniones experiencias y en definitiva todas las conclusiones
sacadas sobre este proyecto incluyendo tambieacuten las dificultades encontradas para el desarrollo del mismo
71 Liacuteneas de Mejora Futuras
El estudio y puesta en marcha de este Proyecto de automatizacioacuten de pruebas de Software ha hecho uso de una
amplia cantidad de herramientas ofrecido por Selenium y Robot Framework ademaacutes de otras herramientas que
han permitido enriquecer el mismo con mayores funcionalidades ofrecidas al equipo de Proyecto Si bien se ha
logrado conseguir un paquete de pruebas con una capacidad de detectar defectos en un producto Web existen
diversas ampliaciones de dicho Proyecto que podriacutean aumentar de manera considerable el desempentildeo de las
herramientas de automatizacioacuten a lo largo del ciclo de vida del proyecto
A continuacioacuten se muestran algunas de las maacutes importantes
bull Uso de Integracioacuten Continua Robot Framework es faacutecilmente integrable principalmente con Jenkins
aunque tambieacuten ofrece la posibilidad de integrarlo con Gitlab CICD Esto permitiriacutea programar la
ejecucioacuten de pruebas automaacuteticamente para diferentes versiones del proyecto Galgus CHT Cloud
Manager o en diferentes fases del mismo Con esta caracteriacutestica se detectariacutean con mayor facilidad los
problemas relacionados con la configuracioacuten del entorno de trabajo y se podriacutea notificar por email a
los responsables de equipo ante los eventuales incidentes encontrados De este modo no seriacutea necesario
estar supervisando el proceso de ejecucioacuten para estar al tanto de un fallo en el sistema En este aspecto
se ha trabajado para conseguir estos objetivos con la creacioacuten de un Docker de Robot Framework que
permita la ejecucioacuten de las pruebas en el mismo para poder usarla en el entorno de integracioacuten continua
correspondiente Tambieacuten se ha implementado un primer un script que permita la ejecucioacuten de paquetes
de pruebas en dicho entorno
bull Selenium Grid El caso praacutectico descrito tiene un inconveniente y es que solo hace uso de Chrome
Suele ser frecuente que ciertos defectos en una aplicacioacuten Web solo aparezcan en determinados
navegadores Con herramientas como Selenium Grid permitiriacutean la ejecucioacuten en paralelo de las pruebas
en maacutequinas con diferentes sistemas operativos y navegadores Asiacute se podriacutea evaluar de manera
independiente la compatibilidad del producto en entornos multiplataforma Ademaacutes esta herramienta
es totalmente compatible con Jenkins o Gitlab CICD con las ventajas que esto supone
bull Headless browser Esto hace referencia al uso de navegadores sin interfaz graacutefica de usuario La mayor
parte del tiempo durante una ejecucioacuten es destinada a esperar a que el navegador renderice el contenido
Si se elimina este factor de la foacutermula y se accede directamente al DOM de la Web se consigue una
reduccioacuten en el tiempo de ejecucioacuten de las pruebas Durante el desarrollo de este proyecto se ha
trabajado en este aspecto ofrecieacutendose la posibilidad de ejecutar las pruebas en dos entornos diferentes
una primera de depuracioacuten de pruebas que realiza el renderizado del navegador y otra opcioacuten que
E
La tecnologiacutea por siacute sola no basta Tambieacuten tenemos que poner el corazoacuten
Jane Goodall
123
permite la ejecucioacuten de pruebas sin renderizado del navegador (Modo Headless)
bull Buenas praacutecticas en la localizacioacuten de elementos en el DOM de la Web La aplicacioacuten de este tipo
de buenas praacutecticas permitiriacutean una mejor y maacutes eficiente localizacioacuten de los elementos en el DOM
reduciendo la posibilidad de que las pruebas generen falsos errores Esto es lo que ha causado la mayor
parte de los problemas de implementacioacuten y ejecucioacuten de las pruebas automaacuteticas Actualmente la
herramienta de automatizacioacuten de pruebas se encuentra en un proceso de mejora continua en el que se
estaacute abordando una refactorizacioacuten para la aplicacioacuten de estas buenas praacutecticas Para ello se estaacuten
haciendo uso de selectores avanzados basados en rutas (Xpaths) relativas en el DOM de la Web las
cuales realizan la mayoriacutea de las buacutesquedas por contenido y no por ruta absoluta como se veniacutea
haciendo hasta ahora
bull Aplicacioacuten de Model Based Testing (MBT) Como estudio del arte se ha presentado una teacutecnica que
permite dar un paso maacutes en la automatizacioacuten de pruebas Como se ha detallado en el proyecto esta
teacutecnica permite ascender en el nivel de abstraccioacuten de las pruebas basando las mismas en el disentildeo y
modelado de la aplicacioacuten Dicha teacutecnica se encuentra principalmente en proceso de investigacioacuten lo
cual hace difiacutecil aplicarla aunque seriacutea de gran intereacutes conseguir su implantacioacuten
72 Conclusiones Finales
En el desarrollo del presente Proyecto se ha analizado una pequentildea extensioacuten del inmenso mundo de la gestioacuten
de calidad Esta ha ido tomando fuerza con el paso de los antildeos en el mercado actual introducieacutendose en todos
los aacutembitos incluido en el software La gestioacuten de calidad se ha profesionalizado de tal forma que el papel del
ingeniero de calidad en los proyectos de software es imprescindible en cualquier empresa que quiera hacerse un
hueco en el mercado como garantiacutea de calidad
La elevada exigencia del mercado del software provocada por la gran demanda de clientes y usuarios finales
para recibir un producto en el menor tiempo posible hace que en muchos casos las empresas centren su esfuerzo
en sacar un producto lo antes posible reduciendo los esfuerzos destinados a los procesos de calidad de dicho
producto software Originalmente las pruebas de software realizadas sobre un producto se realizaban de forma
manual por un ingeniero de calidad pero con el avance de las tecnologiacuteas la automatizacioacuten de las mismas
supone un elevado esfuerzo inicial pero una reduccioacuten de los mismos a medio plazo
En este proyecto se ha desarrollado una herramienta que permite la automatizacioacuten de pruebas funcionales sobre
una plataforma Web concretamente pruebas de aceptacioacuten sobre Galgus CHT Cloud Manager Las pruebas de
automatizacioacuten elaboradas reflejan que existen tecnologiacuteas muy asequibles en teacuterminos de coste compatibilidad
y facilidad de uso para iniciarse en el mundo de las pruebas funcionales de sistemas Algo muy presente en el
mundo laboral actual es la creciente demanda de expertos en automatizacioacuten en todas las principales
plataformas Web Moacutevil y Escritorio Muchos de estos profesionales vienen del mundo del testing manual por
lo que conociendo ya la nomenclatura y el funcionamiento de los procesos de calidad solo necesitan dar el paso
hacia el uso de este tipo de herramientas Sea con Selenium o con cualquier otra herramienta los conceptos
teoacutericos presentados en este proyecto son igualmente vaacutelidos
Por otra parte debe destacarse la dificultad encontrada a la hora de establecer unos criterios de aceptacioacuten de las
funcionalidades de la plataforma Web bajo pruebas Esto se debe al desarrollo de una herramienta de
automatizacioacuten de pruebas que se ha iniciado en una fase avanzada del desarrollo del proyecto con lo cual en
muchas ocasiones surgiacutean dudas sobre el disentildeo del proyecto Adicionalmente la propia estructura y tecnologiacuteas
usadas en la Web dificultaron al inicio la localizacioacuten de elementos A esta causa de une tambieacuten la ausencia de
identificadores uacutenicos en los elementos que componen la misma Esto se tradujo en el uso de selectores basados
en la ruta del elemento pudiendo acarrear la aparicioacuten de posibles falsos errores debidos a cambios en el coacutedigo
fuente de la plataforma Web La solucioacuten adoptada para tal problema no fue maacutes que analizar meticulosamente
aquellas ejecuciones fallidas para descartar errores reales y en caso de que sean debidas a los selectores aplicar
la debida actualizacioacuten de los mismos
En este uacuteltimo aspecto cabe destacar que el proyecto de automatizacioacuten de pruebas se encuentra actualmente
en una fase de mejora continua en la que se estaacuten adoptando teacutecnicas basadas en el uso de selectores avanzados
basados en rutas relativas y nombres que permitan reducir el impacto del problema presentado en este punto
124
A modo de resumen se plantean algunas ventajas en el uso de SeleniumRobot Framework para la
automatizacioacuten de pruebas
Facilidad de configuracioacuten y uso Su instalacioacuten requiere un esfuerzo miacutenimo y el poder de
abstraccioacuten ofrecido por Robot Framework hace posible la lectura y entendimiento de los paquetes de
pruebas y reportes a todos los miembros del equipo
Cantidad de documentacioacuten disponible La comunidad respalda ambos proyectos y es por ello que
encontramos soluciones de todo tipo adaptadas a las necesidades de cada uno
Soporte para la mayoriacutea de navegadores con el mismo script Ejecutar el script de pruebas
desarrollado para su automatizacioacuten en otro navegador requiere simplemente la instalacioacuten del
controlador deseado y usar un determinado paraacutemetro para indicar el uso de dicho controlador en la
llamada de la Keyword encargada de la apertura del navegador
De la misma forma se pueden destacar algunas desventajas
Selenium soacutelo es compatible con productos Web Cualquier software moacutevil o de escritorio requiere
del uso de otros frameworks o herramientas lo cual puede ser un punto negativo para empresas que
tengan productos multiplataforma Sin embargo Robot Framework si proporciona soporte
multiplataforma con la integracioacuten de otras herramientas o framework para su desarrollo
Tecnologiacuteas no optimizadas para pruebas de rendimiento En este punto cabe destacar el esfuerzo
de la comunidad para desarrollar herramientas que permitan la automatizacioacuten de este tipo de pruebas
con Robot Framework como por ejemplo ldquorfswarmrdquo
Compatibilidad de versiones de paquetes de Software Es frecuente usar determinadas
combinaciones de versiones de paquetes para lograr un framework estable y robusto Esto a veces puede
convertirse en una tarea tediosa donde cuestan encajar piezas Por suerte es algo que se estaacute teniendo
en cuenta con las uacuteltimas versiones de Selenium
Puede concluirse que durante el desarrollo de este proyecto se ha conseguido la creacioacuten de una herramienta
sencilla de usar y entender para la automatizacioacuten de pruebas funcionales sobre una plataforma Web ademaacutes
de preparar dicha herramienta para integrarla en el proceso de integracioacuten continua implantado para dicha
aplicacioacuten Web con Gitlab mediante Docker Ademaacutes se ha realizar un estudio del arte de una teacutecnica conocida
bajo el nombre de Model Based Testing (MBT) que permitiriacutea mejorar el proceso de automatizacioacuten y la
herramienta desarrollada para tal fin
Con todo ello he aprendido multitud de conceptos tecnologiacuteas y herramienta que hasta ahora desconociacutea cuaacutel
era su finalidad o funcionamiento como por ejemplo Robot Framework Para ello he necesitado gran cantidad
de formacioacuten previa antes de comenzar a ponerlo en praacutectica para el desarrollo de la herramienta de
automatizacioacuten
Son muchos los errores cometidos hasta conseguir los objetivos y metas propuestas los cuales creo que son los
sucesos maacutes importantes pues de ellos se aprende y son los que nos hacen avanzar cuando los resolvemos
Finalmente destacar que este proyecto me ha dado la oportunidad de abrir mi conocimiento en un campo de las
tecnologiacuteas de la informacioacuten el cual resulta de intereacutes Dar las Gracias a mis tutores Pablo Aguilera Bonet y
Daniel Gutieacuterrez Reina ademaacutes de mi responsable en Galgus Joseacute Antonio Delgado Alfonso por brindarme
esta oportunidad ademaacutes de ayudarme y asesorarme estando siempre disponible y con dedicacioacuten hacia este
proyecto para que haya podido llevarse a cabo
125
126
REFERENCIAS
[1] M Utting Bruno Legeard Practical Model-based Testing sl Elsevier 2007
[2] Ibrahim K El-Far Enjoying the perks of model-based testing In Proceedings of the Software Testing
Analysis and Review Conference
[3] A C Dias Neto Rajesh Subramanyan Marlon Vieirab Characterization of Model-based Software
[4] Model-based Testing Next Generation Functional Software Testing Legeard Bruno Dagstuhl Seminar
Proceedings 10111 Vol httpdropsdagstuhldeopusvolltexte20102620
[5] Perspectives of Model-Based Testing Ed Brinksma Wolfgang Grieskamp and Jan Tretmans IBFI
Schloss Dagstuhl Germany sn 2005 Dagstuhl Seminar Proceedings
[6] Definicioacuten de Calidad httpsdleraeesid=6nVpk8P|6nXVL1Z
[7] Modelos de calidad del software httpswwwresearchgatenetpublication316674475
[8] Calidad del Software ldquoEl camino al exitordquo LI Alma Delia Chaacutevez Rojas
[9] IEEE Software Engineering Book of Knowledge IEEE sl IEEE 2004
[10] Principios de pruebas software httpsmediumcomatejedaccsprincipios-del-testing-722323e16e76
[11] httpwwwsstqbesw3docsGLOSARIO_V00110pdf
[12] httpsepdfpubsoftware-testing-an-istqb-iseb-foundation-guidehtml
[14] IEEE standard glossary of software engineering terminology F Jay RMayer 1990 paacuteg IEEE Std 610
[15] Openwrt httpsopenwrtorgsupported_devices
[16] RabbitMQ httpswwwrabbitmqcom
[17] Zero Touch Provisioning httpssearchdatacentertechtargetcomesdefinicionAprovisionamiento-de-
cero-toque-ZTP-o-zero-touch-provisioning
[18] Robot Framework User Guide
httpsrobotframeworkorgrobotframeworklatestRobotFrameworkUserGuidehtml
[19] Gitlab httpsdocsgitlabcom
[20] httpswwwfederico-toledocomcuando-automatizar-una-prueba
127
128
ANEXO A PREPARACIOacuteN DEL ENTORNO DE
TRABAJO Y EJECUCIOacuteN DE PRUEBAS
A1 Preparacioacuten del entorno de trabajo
Para el desarrollo de las preubas automaacuteticas se ha hecho uso del sistema operative Linux con la distribucioacuten
Ubuntu El motivo de su uso es el amplio abanico de herramientas de coacutedigo libre que existen para esta
distribucioacuten asiacute como la enorme contribucioacuten que hace la comunidad de usuarios para mejorarla Sobre este
sistema operativo se ha hecho uso de un conjunto de herramientas para el montaje de un entorno de pruebas
automatizado basado en Python A continuacioacuten se detallaraacuten dichas herramientas
A11 Pip
Pip es un sistema de gestioacuten de paquetes que se utiliza para la instalacioacuten de los paquetes software
implementados en Python que se usaraacuten posteriormente La instalacioacuten de un paquete se realiza mediante la
ejecucioacuten del siguiente comando
A12 Virtualenv Entorno Virtual
Dado que cada proyecto basado en Python puede requerir la instalacioacuten de diferentes conjuntos de paquetes es
comuacuten usar la creacioacuten de entornos virtuales que nos permitan administrar cada proyecto de manera
independiente pudiendo tener otros proyectos haciendo uso de los mismos paquetes con otras versiones La
instalacioacuten se realiza mediante la herramienta ldquoPiprdquo a traveacutes del siguiente comando
Una vez instalado se puede crear un entorno virtual asociado a un proyecto de la siguiente forma
En este punto se creariacutea un entorno virtual para el proyecto deseado Ahora solo quedariacutea activarlo o iniciarlo
pip install nombre-del-paquete
pip install virtualenv
cd carpeta-del-proyecto
virtualenv ndashp usrbinpython27 mi-proyecto
source mi-proyectobinactivate
129
A13 Selenium y Chromedriver
La instalacioacuten de Selenium se realiza de la misma forma que el resto de paquetes con la herramienta ldquoPiprdquo
Por otra parte el controlador para el navegador Chrome Chromedriver puede ser descargado desde el
repositorio oficial httpschromedriverchromiumorg Ademaacutes Chromedriver debe ser accessible para
Selenium de cara a configurar el PATH
A14 Robot Framework y SeleniumLibrary
A continuacioacuten se realizariacutea la instalacioacuten de Robot Framework
Posteriormente se realizariacutea la instalacioacuten del paquete ldquoSelenium2Libraryrdquo el cual contiene la implementacioacuten
en python de las libreriacuteas necesarias para utilizar Robot Framework en Python
Llegados a este punto listando todos los paquetes instalados se deberiacutea tener algo similar a la siguiente figura
Con esta configuracioacuten del entorno este estariacutea preparado para elaborar los casos de prueba automatizados con
Robot Framework y Selenium
pip install selenium
export PATH=$PATHabsolute_path_of_chromedriver_file
pip install robotframework
pip install robotframework-selenium2library
130
A15 Otras dependencias
Para el desarrollo de pruebas que requieren otro tipo de herramientas como la transferencia de ficheros con el
servicio ldquoSCPrdquo o la conexioacuten remota a traveacutes del servicio ldquoSSHrdquo se require la instalacioacuten de los siguientes
paquetes
Ademaacutes para la realizacioacuten de pruebas avanzadas en Python para la gestioacuten del Mapa de la platform Web CHT
Cloud Manager se ha hecho uso de la librariacutea ldquohtml-testRunnerrdquo para ofrecer un reporte de la ejecucioacuten de
pruebas muy similar al ofrecido por Robot Framework
A2 Ejecucioacuten de Pruebas
Tras la implementacioacuten de las pruebas siguiendo el procedimiento indicado en la seccioacuten de Experimentos
ejecutar un script de pruebas se realiza mediante el uso del siguiente comando
Mediante el uso de la variable ldquoENVIROMENTrdquo puede seleccionarse el entorno en el que se desea ejecutar las
pruebas Con el entorno de ldquodebugrdquo las pruebas se ejecutariacutean de forma graacutefica mientras que el el entorno de
ldquodockerrdquo permite la ejecucioacuten de pruebas sin interfaz graacutefica Este uacuteltimo entorno seriacutea usado para la ejecucioacuten
de pruebas con el docker de Robot Framework que se ha implementado el cual se detallaraacute maacutes adelante
Por otro lado existen otras opciones para el comando anterio como por ejemplo
Las opciones ldquo-irdquo y ldquo-erdquo permiten ejecutar o excluir un caso de preuba en la ejecucioacuten de una Suite de pruebas
Por otro lado el uacuteltimo comando permite lanzar la ejcucioacuten de una Suite de pruebas y ejecutar soacutelo aquellos
casos de prueba que hayan fallado en la ejecucioacuten anterior
pip install robotframework-sshlibrary
pip install robotframework-scplibrary
pip install html-testRunner
robot --variable ENVIROMENTdebug_or_docker suite_filerobot
robot --variable ENVIROMENTdebug_or_docker ndashi U0000 suite_filerobot
robot --variable ENVIROMENTdebug_or_docker ndashe U0000 suite_filerobot
robot --rerunfailed outrerunfailedxml --output out2xml suite_filerobot
131
A continuacioacuten se muestra un ejemplo de ejecucioacuten de pruebas con Robot Framwork
132
A3 Script de Prueba U007 (MAP)
from selenium import webdriver
from seleniumwebdrivercommonby import By
from seleniumwebdriversupportui import WebDriverWait
from seleniumwebdriversupport import expected_conditions as EC
from seleniumwebdrivercommondesired_capabilities import DesiredCapabilities
from seleniumwebdrivercommonaction_chains import ActionChains
from seleniumcommonexceptions import TimeoutException
import math json multiprocessing time re
import sys
import unittest
import HtmlTestRunner
U0007 Double-click on Zone Manager and look if the Backend tab opens
class DClickZM(unittestTestCase)
driver = 0
canvas = 0
waitTime = 20
username = franciscodiaz
password = ahipeo8829g
classmethodg
def setUp(cls)
Enviroment Management
chrome_options = webdriverChromeOptions()
if sysargv[2] == docker
chrome_optionsadd_argument(--headless)
chrome_optionsadd_argument(--disable-extensions)
chrome_optionsadd_argument(--disable-gpu)
chrome_optionsadd_argument(--no-sandbox)
enable browser logging
d = DesiredCapabilitiesCHROME
d[loggingPrefs] = browser DEBUG
clsdriver = webdriverChrome(chrome_options=chrome_options desired_capabilities=d)
clsdrivermaximize_window()
clsdriverset_window_size(1920 1080)
load the desired webpage
clsdriverget(httpdevcloudgalgusnet)
def test_double_click_ZM(self)
loggin in the page
userNameBox = WebDriverWait(selfdriver 1)until(
ECpresence_of_element_located((ByXPATH [id=username])))
userNameBoxsend_keys(selfusername)
passwordBox = WebDriverWait(selfdriver selfwaitTime)until(
ECpresence_of_element_located((ByXPATH [id=password])))
passwordBoxsend_keys(selfpassword)
133
loginButton = WebDriverWait(selfdriver selfwaitTime)until(
ECpresence_of_element_located((ByXPATH
[id=myModalLabel]divdivformdiv[3]input)))
loginButtonclick() Tab General appears
selfcanvas = WebDriverWait(selfdriver selfwaitTime)
until(ECpresence_of_element_located((ByXPATH
htmlbodyappdivmaindivregister-
managersdivtabsetdivtab[1]aol-mapdivdivcanvas)))
timesleep(15)
action = ActionChains(selfdriver)
Manage Process
manager = multiprocessingManager()
return_dict = managerdict()
We create a Process
p_get_pixels_zm = multiprocessingProcess(target=selfGet_Pixels_ZM args=(return_dict selfdriver))
We create another Process
p_double_click_on_zm = multiprocessingProcess(target=selfDouble_Click_On_ZM args=(return_dict selfcanvas
action selfdriver))
We start the process and we block for 5 seconds
p_get_pixels_zmstart()
p_get_pixels_zmjoin(timeout=10)
p_double_click_on_zmstart()
p_double_click_on_zmjoin(timeout=10)
We terminate the process
p_get_pixels_zmterminate()
p_double_click_on_zmterminate()
try
Tab General appears
WebDriverWait(selfdriver 20)until(ECpresence_of_element_located(
(ByXPATH [id=app-sections]networktabsetulli[1]a)))
except TimeoutException
raise Exception(Cant Login in Zone Manager)
classmethod
def tearDown(cls)
clsdriverquit()
staticmethod
def Get_Pixels_ZM(return_dict driver)
return_dict[0] = 0
return_dict[1] = 0
regex = r(lt=c[-gt]cs)[wW]+(=)
while True
for entry in driverget_log(browser)
message = entry[message]
matches = refinditer(regex message reMULTILINE)
134
for matchNum match in enumerate(matches start=1)
try
p = matchgroup()replace( )
my_json = jsonloads(p)
if my_json[ZM] == Hotel MampM
return_dict[0] = my_json[top]
return_dict[1] = my_json[left]
break
except
pass
if return_dict[0] = 0 and return_dict[1] = 0
break
staticmethod
def Double_Click_On_ZM(return_dict canvasaction driver)
width = int(mathceil(float(return_dict[0])))
height = int(mathceil(float(return_dict[1])))
actionmove_to_element_with_offset(canvas width height)
actiondouble_click()
actionperform()
actiondouble_click()
actionperform()
driversave_screenshot(screenshot1png)
timesleep(5)
if __name__ == __main__
unittestmain(testRunner=HtmlTestRunnerHTMLTestRunner())
135
136
ANEXO B DOCKER DE ROBOT FRAMEWORK Y
ENTORNO DE UAT DOCKERIZADO
B1 Docker de Robot Framework
Para el entorno de UAT que se va a desarrollar se ha hecho uso de diferentes contenedores que han sido creados
por el equipo de desarrollo donde cada contenedor aloja un microservicio diferente de la plataforma
Para crear cada contenedor se ha hecho uso de Docker Esta herramienta permite crear contenedores ligeros y
portables para diferentes servicios que puedan ejecutarse en cualquier maacutequina con Docker instalado
independientemente del sistema operativo de la maacutequina que lo ejecute facilitando asi los despliegues
Mediante un fichero llamado ldquoDockerfilerdquo se definen los siguientes contenedores de servicios entre los cuales
se destacaraacute el fichero que define la creacioacuten del docker de Robot Framework el cual ha sido desarrollado por
el autor de este proyecto
Este contenedor ha sido creado sobre una imagen de Docker con el inteacuterprete de Python instalado Partiendo de
137
esta imagen se realiza la instalacioacuten de Robot Framework y las diferentes libreriacuteas y herramientas que se usaraacuten
en el proyecto para poder lanzar los Tests End-to-End
Ademaacutes se realiza la instalacioacuten de Google Chrome y Mozilla Firefox y la descarga de Chromedriver y
Geckodriver para poder lanzar los tests con dichos navegadores en modo headless Para el lanzamiento de los
test en modo headless se haraacute uso de la variable de entorno ldquoENVIROMENTrdquo definida en el anexo anterior
Finalmente se antildeade el proyecto de pruebas desarrollado para tener disponible las pruebas aumaacuteticas en el
contenedor
B2 Entorno de UAT Dockerizado
Para automatizar el despliegue de la plataforma Galgus CHT Cloud Manager con Docker se ha hecho uso de la
herramienta ldquodocker-composerdquo Esta herramienta permite simplificar el uso de Docker generando scripts que
facilitan el disentildeo y la construccion de servicios Con Docker Compose se pueden crear diferentes contenedores
y al mismo tiempo en cada contenedor diferentes servicios En la siguientefigura se muestra el fichero que
define el entorno de UAT con docker-compose
138
139
140
ANEXO C REVISIOacuteN DE REPORTES Y LOGS
C1 Reporte de Logs ofrecido por Robot Framework
Selenium no teniacutea la capacidad nativa de generar informes Este es uno de los motivos por el que se decidioacute
utilizar Robot Framework
Robot Framework genera tres archivos tras la ejecucioacuten de los scripts de pruebas A partir de la informacioacuten
contenida en el fichero ldquooutputxmlrdquo se rellenan las plantillas ldquohtmlrdquo del ldquologrdquo y del reporte El reporte permite
aplicar filtros a los resultados mientras que el ldquologrdquo contiene todos los detalles de la ejecucioacuten
A continuacioacuten se adjuntan las capturas de logs generados por los diferentes paquetes de pruebas desarrollados
C2 Cloud Tab
C21 Administration
141
142
C22 List
143
C23 Manufacturers
144
C24 MAP
145
C3 Configuration Tab
C31 BackupRestore
146
C32 CHT Zones
147
C33 Firmware
148
C34 Groups
149
150
C4 Network Tab
C41 General
151
C42 SSID
C43 CHT
152
C44 VLAN
153
C45 Radius
154
C46 Captive Portal
155
C47 AP Network
156
Como se ha visto reflejado en el conjunto de logs el tiempo total invertido en la ejecucioacuten ha sido de 1 hora 20
minutos y 22 segundos Dichas pruebas realizadas por una persona de forma manual hubiesen requerido como
miacutenimo el doble de tiempo Ya ni mencionar si se aplicase concurrencia en la ejecucioacuten de pruebas
157
ANEXO D DIAGRAMA DE GANTT
