“Año de la Lucha contra
la Corrupción e
Impunidad”
ESCUELA PROFESIONAL INGENIERIA DE SISTEMAS
CURSO:
TECNOLOGÍA DE LA
PROGRAMACION II
DOCENTE:
Mg. VIDAL MELGAREJO, ZORAIDA
CICLO:
V
ALUMNOS:
AMAYA MONZÓN,Marjourie
CEVERA VASQUEZ, Estefany
MIRANDA SALAS, Baru
PINEGRO DIAZ,Jesús
ROJAS CUEVA, Anthony 2019
0
INTRODUCCIÓN
ÍNDICE
Taller de pruebas de software --------------------------------------------------------- Pág. 2
Pruebas estáticas --------------------------------------------------------------------------- Pág. 2
Pruebas dinámicas --------------------------------------------------------------------------- Pág. 2
Métodos de pruebas
Pruebas de Caja Blanca --------------------------------------------------------- Pág. 2
Pruebas de caja negra --------------------------------------------------------- Pág. 3
Testing aleatorio ------------------------------------------------------------------ Pág. 4
Clasificación de las pruebas según lo que verifican
Pruebas funcionales
Pruebas unitarias --------------------------------------------------------- Pág. 5
Pruebas de integración ------------------------------------------------ Pág. 5
Pruebas de sistema ----------------------------------------------------- Pág. 5
Pruebas de humo --------------------------------------------------------- Pág. 7
Pruebas alpha ----------------------------------------------------------- Pág. 7
Pruebas beta -------------------------------------------------------------- Pág. 7
Pruebas de aceptación ------------------------------------------------ Pág. 7
Pruebas de regresión --------------------------------------------------- Pág. 8
Niveles de prueba ------------------------------------------------------------------ Pág. 8
Pruebas no funcionales
Pruebas de compatibilidad -------------------------------------------- Pág. 9
Pruebas de seguridad ------------------------------------------------ Pág. 10
Pruebas de Stress ------------------------------------------------------ Pág. 11
Pruebas de usabilidad ------------------------------------------------ Pág. 12
Pruebas de rendimiento ------------------------------------------------ Pág. 12
Pruebas de internacionalización y localización ------------------- Pág. 12
Pruebas de escalabilidad ------------------------------------------------ Pág. 13
Pruebas de mantenibilidad -------------------------------------------- Pág. 13
Pruebas de instalabilidad ------------------------------------------------ Pág. 13
Pruebas de portabilidad ------------------------------------------------ Pág. 13
Herramientas para realizar pruebas de software
Herramientas Open Source ------------------------------------------------------ Pág. 14
Herramientas comerciales ------------------------------------------------------ Pág. 15
Bibliografía ------------------------------------------------------------------------- Pág. 17
1
2
INTRODUCCIÓN
- El sistema ya se ha desarrollado por completo
- ¿se acaba aquí el trabajo? NO
a. Pruebas del sistema
b. Implantación del sistema
c. Mantenimiento del sistema
TALLER DE PRUEBAS DE SOFTWARE
Las pruebas de software (en inglés software testing) son las investigaciones
empíricas y técnicas cuyo objetivo es proporcionar información objetiva e
independiente sobre la calidad del producto a la parte interesada. Es una actividad
más en el proceso de control de calidad.
Las pruebas son básicamente un conjunto de actividades dentro del desarrollo
de software. Dependiendo del tipo de pruebas, estas actividades podrán ser
implementadas en cualquier momento de dicho proceso de desarrollo. Existen
distintos modelos de desarrollo de software, así como modelos de pruebas. A cada
uno corresponde un nivel distinto de involucramiento en las actividades de
desarrollo.
Pruebas estáticas: Son el tipo de pruebas que se realizan sin ejecutar el código
de la aplicación. Puede referirse a la revisión de documentos, ya que no se hace
una ejecución de código. Esto se debe a que se pueden realizar "pruebas de
escritorio" con el objetivo de seguir los flujos de la aplicación.
Pruebas dinámicas: Todas aquellas pruebas que para su ejecución requieren la
ejecución de la aplicación. Las pruebas dinámicas permiten el uso de técnicas de
caja negra y caja blanca con mayor amplitud. Debido a la naturaleza dinámica de
la ejecución de pruebas es posible medir con mayor precisión el comportamiento
de la aplicación desarrollada.
3
Métodos de pruebas
Pruebas de Caja Blanca
Las pruebas de caja blanca (también conocidas como pruebas de caja de
cristal o pruebas estructurales) se centran en los detalles procedimentales del
software, por lo que su diseño está fuertemente ligado al código fuente. El
ingeniero de pruebas escoge distintos valores de entrada para examinar cada uno
de los posibles flujos de ejecución del programa y cerciorarse de que se devuelven
los valores de salida adecuados.
Al estar basadas en una implementación concreta, si ésta se modifica, por regla
general las pruebas también deberán rediseñarse.
Aunque las pruebas de caja blanca son aplicables a varios niveles —
unidad, integración y sistema—, habitualmente se aplican a las unidades de
software. Su cometido es comprobar los flujos de ejecución dentro de cada unidad
(función, clase, módulo, etc.) pero también pueden probar los flujos entre unidades
durante la integración, e incluso entre subsistemas, durante las pruebas de sistema.
A pesar de que este enfoque permite diseñar pruebas que cubran una amplia
variedad de casos de prueba, podría pasar por alto partes incompletas de
la especificación o requisitos faltantes, pese a garantizar la prueba exhaustiva de
todos los flujos de ejecución del código analizado.
Pruebas de caja negra
En teoría de sistemas y física, se denomina Caja Negra a aquel elemento que es
estudiado desde el punto de vista de las entradas que recibe y las salidas o
respuestas que produce, sin tener en cuenta su funcionamiento interno. En otras
palabras, de una caja negra nos interesará su forma de interactuar con el medio
que le rodea (en ocasiones, otros elementos que también podrían ser cajas negras)
entendiendo qué es lo que hace, pero sin dar importancia a cómo lo hace. Por
tanto, de una caja negra deben estar muy bien definidas sus entradas y salidas, es
decir, su interfaz; en cambio, no se precisa definir ni conocer los detalles internos
de su funcionamiento.
4
- Caja negra y programación modular
En programación modular, donde un programa (o un algoritmo) es dividido
en módulos, en la fase de diseño se buscará que cada módulo sea una caja
negra dentro del sistema global que es el programa que se pretende desarrollar, de
esta manera se consigue una independencia entre los módulos que facilita su
implementación separada por un equipo de trabajo donde cada miembro va a
encargarse de implementar una parte (un módulo) del programa global; el
implementador de un módulo concreto deberá conocer como es la comunicación
con los otros módulos (la interfaz), pero no necesitará conocer cómo trabajan esos
otros módulos internamente; en otras palabras, para el desarrollador de un módulo,
idealmente, el resto de módulos serán cajas negras.
- Pruebas de software
En pruebas de software, conociendo una función específica para la que fue
diseñado el producto, se pueden diseñar pruebas que demuestren que dicha función
está bien realizada. Dichas pruebas son llevadas a cabo sobre la interfaz del
software, es decir, de la función, actuando sobre ella como una caja negra,
proporcionando unas entradas y estudiando las salidas para ver si concuerdan con
las esperadas.
Testing aleatorio
En el desarrollo de software, el testing es una de las tareas más importantes, pero
también es compleja y no siempre adoptada correctamente. Las Prueba unitaria, de
carga, integración, funcionales y no funcionales son distintos tipos de testing, cada
uno con objetivos diferentes y aplicados en diferentes etapas del desarrollo del
software. En el testing de unidad se desarrollan pruebas individuales sobre
componentes de un sistema. En la codificación de dichas pruebas, se busca simular
el entorno de dicho componente y descubrir la presencia de errores o “bugs”. Más
allá del esfuerzo, las pruebas de unidad pueden probar la presencia de ciertos
errores, pero no pueden asegurar la ausencia de ellos.
5
Buscando ampliar el ámbito de las pruebas de unidad, se han aplicado diversas
técnicas que van desde la automatización de pasos o caminos de ejecución, con
valores fijos o componentes predefinidos (hard-coded) o estáticos, y condiciones
específicas, hasta los enfoques basados en la generación de objetos de manera
aleatoria, aplicados a la Programación Orientada a Objetos. El fundamento básico
de este enfoque propuesto es el testing aleatorio.
Tanto la generación de valores aleatorios para testing, como el testing aleatorio (RT
o random testing) en sí no son técnicas nuevas. Por ej., en el paradigma
funcional existe una herramienta para probar especificaciones sobre funciones
llamada QuickCheck. Esta herramienta (escrita en Haskell) y sus ideas subyacentes
son usadas como fundamento para algunas herramientas desarrolladas para RT en
POO.
Clasificación de las pruebas según lo que verifican
Pruebas funcionales: Una prueba funcional es una prueba basada en la
ejecución, revisión y retroalimentación de las funcionalidades previamente
diseñadas para el software (requisitos funcionales). Hay distintos tipos como,
por ejemplo:
Pruebas unitarias:
Se focaliza en ejecutar cada módulo (o unidad mínima a ser probada, ej. = una
clase) lo que provee un mejor modo de manejar la integración de las unidades en
componentes mayores.
Busca asegurar que el código funciona de acuerdo con las especificaciones y que
el módulo lógico es válido.
Pruebas de integración:
Identificar errores introducidos por la combinación de programas probados
unitariamente.
Determina cómo la base de datos de prueba será cargada.
Verificar que las interfaces entre las entidades externas (usuarios) y las aplicaciones
funcionan correctamente.
6
Verificar que las especificaciones de diseño sean alcanzadas.
Determina el enfoque para avanzar desde un nivel de integración de las
componentes al siguiente.
Pruebas de sistema:
Asegurar la apropiada navegación dentro del sistema, ingreso de datos,
procesamiento y recuperación.
Las pruebas del sistema deben enfocarse en requisitos que puedan ser tomados
directamente de casos de uso y reglas y funciones de negocios. El objetivo de
estas pruebas es verificar el ingreso, procesamiento y recuperación apropiado de
datos, y la implementación apropiada de las reglas de negocios. Este tipo de
pruebas se basan en técnicas de caja negra, esto es, verificar el sistema (y sus
procesos internos), la interacción con las aplicaciones que lo usan vía GUI y
analizar las salidas o resultados.
En esta prueba se determina qué pruebas de Sistema (usabilidad, volumen,
desempeño, etc.) asegurarán que la aplicación alcanzará sus objetivos de negocio.
La prueba de Sistema incluye:
Prueba de Usabilidad
Prueba de Performance
Prueba de Documentación y Procedimientos
Prueba de Seguridad y Controles
Prueba de Volumen
Prueba de Esfuerzo (Stress)
Prueba de recuperación
Prueba de múltiples sitios
Para sistemas web se recomienda especialmente realizar mínimo el siguiente grupo
de pruebas de sistema:
Humo.
7
Usabilidad
Performance
Funcionalidad
Para capitalizar el trabajo hasta ahora completado, los casos de prueba de las
pruebas previas realizadas pueden frecuentemente ser reorganizados y rehusados
durante la prueba de sistema. No obstante, deben ser desarrollados casos de
prueba adicionales para aquellos aspectos del sistema, tales como documentación,
procedimientos y desempeño que no han sido probados durante la prueba unitaria
y de integración.
La prueba de sistema es compleja porque intenta validar un número de
características al mismo tiempo, a diferencia de otras pruebas que sólo se centran
en uno o dos aspectos del sistema al mismo tiempo.
Pruebas de humo
Detectar los errores en realases tempranos y de manera fácil
Probar el sistema constantemente
Garantizar poco esfuerzo en la integración final del sistema
Asegurar los resultados de las pruebas unitarias
Se reducen los riesgos y a baja calidad.
Pruebas alpha
Prueba de aceptación para detectar errores en el sistema bajo un ambiente
controlado.
La verificación involucra la ejecución de partes o todo del sistema en ambientes
simulados, con el fin de encontrar errores.
La retroalimentación de esta fase produce cambios en el software para resolver los
errores y fallas que se descubren.
Pruebas beta
Realizar la validación del sistema por parte del usuario.
8
Prueba de aceptación donde La validación (o pruebas beta) involucra el uso del
software en un ambiente real.
Pruebas de aceptación
Determinación por parte del cliente de la aceptación o rechazo del sistema
desarrollado.
La prueba de aceptación es ejecutada antes de que la aplicación sea instalada
dentro de un ambiente de producción. La prueba de aceptación es generalmente
desarrollada y ejecutada por el cliente o un especialista de la aplicación y es
conducida a determinar como el sistema satisface sus criterios de aceptación
validando los requisitos que han sido levantados para el desarrollo, incluyendo a
documentación y procesos de negocio.
Basado en esta prueba el cliente determina si acepta o rechaza el sistema
Estas pruebas están destinadas a probar que el producto está listo para el uso
operativo. Suelen ser un subconjunto de las Pruebas de Sistema.
Sirve para que el usuario pueda validar si el producto final se ajusta a los
requisitos fijados, es decir, si el producto está listo para ser implantado para el uso
operativo en el entorno del usuario.
Pruebas de regresión
Determinar si los cambios recientes en una parte de la aplicación tienen efecto
adverso en otras partes.
En esta prueba se vuelve a probar el sistema a la luz de los cambios realizados
durante el debugging, mantenimiento o desarrollo de la nueva versión del sistema
buscando efectos adversos en otras partes.
Niveles de prueba
Podemos considerar el proceso de pruebas funcionales como un proceso donde se
va probando inicialmente lo de más bajo nivel y se van integrando y probando
paulatinamente componentes hasta lograr un sistema completo totalmente probado.
Por eso se dice que hay distintos niveles de prueba. Se empieza por las pruebas
9
unitarias, luego las pruebas de Integración, luego las de pruebas de sistema, las
de humo, las alpha, las beta y finalmente las de pruebas de aceptación.
Las pruebas de regresión se pueden considerar como la ejecución (normalmente
automática) de las pruebas ya realizadas hasta el momento.
Pruebas no funcionales
Una prueba no funcional es una prueba cuyo objetivo es la verificación de un
requisito que especifica criterios que pueden usarse para juzgar la operación de un
sistema (requisitos no funcionales) como por ejemplo la disponibilidad, accesibilidad,
usabilidad, mantenibilidad, seguridad, rendimiento. Podemos clasificar las pruebas no
funcionales según el tipo de requisito no funcional que abarcan:
Pruebas de compatibilidad
Buscar problemas de compatibilidad y conversión en los sistemas.
El propósito es demostrar que los objetivos de compatibilidad no han sido logrados
y que los procedimientos de conversión no funcionan.
La mayoría de los programas que se desarrollan no son completamente nuevos;
con frecuencia son reemplazos de partes deficientes, ya sea de sistemas de
procesamiento de datos, o sistemas manuales.
10
Como tales, los programas tienen a menudo objetivos específicos con respecto a su
compatibilidad y a sus procedimientos de conversión con el sistema existente.
Pruebas de seguridad
Nivel de seguridad de la aplicación: Verifica que un actor solo pueda acceder a las
funciones y datos que su usuario tiene permitido.
Nivel de Seguridad del Sistema: Verificar que solo los actores con acceso al
sistema y a la aplicación están habilitados para accederla.
Las pruebas de seguridad y control de acceso se centran en dos áreas claves de
seguridad:
Seguridad del sistema, incluyendo acceso a datos o Funciones de negocios y
Seguridad del sistema, incluyendo ingresos y accesos remotos al sistema.
Las pruebas de seguridad de la aplicación garantizan que, con base en la
seguridad deseada, los usuarios están restringidos a funciones específicas o su
acceso está limitado únicamente a los datos que está autorizado a acceder. Por
ejemplo, cada usuario puede estar autorizado a crear nuevas cuentas, pero sólo los
administradores pueden borrarlas. Si existe seguridad a nivel de datos, la prueba
garantiza que un usuario “típico” 1 puede ver toda la información de clientes,
incluyendo datos financieros; sin embargo, el usuario 2 solamente puede ver los
datos institucionales del mismo cliente.
Las pruebas de seguridad del sistema garantizan que solamente aquellos usuarios
autorizados a acceder al sistema son capaces de ejecutar las funciones del sistema
a través de los mecanismos apropiados.
Debido a la creciente preocupación de la sociedad por la privacidad de la
información, muchos programas tienen objetivos específicos de seguridad.
11
El objetivo de esta prueba es evaluar el funcionamiento correcto de los controles
de seguridad del sistema para asegurar la integridad y confidencialidad de los
datos. El foco principal es probar la vulnerabilidad del sistema frente a accesos o
manipulaciones no autorizadas. Una manera de encontrar esos casos de prueba es
estudiar problemas conocidos de seguridad en sistemas similares y tratar de
mostrar la existencia de problemas parecidos en el sistema que se examina.
Algunas consideraciones de prueba son:
Controles de acceso físico
Acceso a estructuras de datos específicas a través de los programas de
aplicación.
Seguridad en sitios remotos
Existencia de datos confidenciales en reportes y pantallas
Controles manuales, incluyendo aquellos para autorización y aprobación,
formularios, documentación numerada, transmisión de datos, balances y conversión
de datos.
Controles automáticos, incluyendo aquellos para edición de datos, chequeo
de máquinas, errores del operador, acceso a datos elementales y archivos, acceso
a funciones, auditoría, entre otros.
Pruebas de Stress
Verificar que el sistema funciona apropiadamente y sin errores, bajo estas
condiciones de stress:
Memoria baja o no disponible en el servidor.
Máximo número de clientes conectados o simulados (actuales o físicamente
posibles)
Múltiples usuarios desempeñando la misma transacción con los mismos
datos.
El peor caso de volumen de transacciones (ver pruebas de desempeño).
12
NOTAS: La meta de las pruebas de stress también es identificar y documentar
las condiciones bajo las cuales el sistema FALLA.
Las pruebas de stress se proponen encontrar errores debidos a recursos bajos o
completitud de recursos. Poca memoria o espacio en disco puede revelar defectos
en el sistema que no son aparentes bajo condiciones normales. Otros defectos
pueden resultar de incluir recursos compartidos, como bloqueos de base de datos
o ancho de banda de la red. Las pruebas de stress identifican la carga máxima que
el sistema puede manejar.
El objetivo de esta prueba es investigar el comportamiento del sistema bajo
condiciones que sobrecargan sus recursos. No debe confundirse con las pruebas de
volumen: un esfuerzo grande es un pico de volumen de datos que se presenta en
un corto período de tiempo.
Puesto que la prueba de esfuerzo involucra un elemento de tiempo, no resulta
aplicable a muchos programas, por ejemplo a un compilador o a una rutina de
pagos.
Es aplicable, sin embargo, a programas que trabajan bajo cargas variables,
interactivos, de tiempo real y de control de proceso.
Aunque muchas pruebas de esfuerzo representan condiciones que el programa
encontrará realmente durante su utilización, muchas otras serán en verdad
situaciones que nunca ocurrirán en la realidad. Esto no implica, sin embargo, que
estas pruebas no sean útiles.
Si se detectan errores durante estas condiciones “imposibles”, la prueba es valiosa
porque es de esperar que los mismos errores puedan presentarse en situaciones
reales, algo menos exigentes.
Pruebas de usabilidad
Determinar la usabilidad del sistema.
13
Determina cuán bien el usuario podrá usar y entender la aplicación. Identifica las
áreas de diseño que hacen al sistema de difícil uso para el usuario.
La prueba de usabilidad detecta problemas relacionados con la conveniencia y
practicidad del sistema desde el punto de vista del usuario.
Pruebas de rendimiento
En la ingeniería del software, las pruebas de rendimiento son las pruebas que se
realizan, desde una perspectiva, para determinar lo rápido que realiza una tarea un
sistema en condiciones particulares de trabajo. También puede servir para validar y
verificar otros atributos de la calidad del sistema, tales como
la escalabilidad, fiabilidad y uso de los recursos.
Pruebas de internacionalización y localización
La prueba de localización es un servicio de aseguramiento de calidad que consiste
en verificar que un producto se ajusta al mercado en el cual será comercializado.
El producto está analizado desde un punto de vista lingüístico, funcional y cultural.
Si lanza un producto que contiene un gran número de errores gramáticales y
funcionales, es más probable que esto afecte la experiencia de sus usuarios e
impida que su empresa entre en el mercado objetivo.
Las pruebas de localización deben realizarse cuando su producto está listo para el
lanzamiento al extranjero. Eso significa que el contenido debe estar completamente
traducido y técnicamente adaptado al país en el cual será comercializado.
Pruebas de escalabilidad
En informática, se conocen como pruebas de escalabilidad, a aquellas pruebas no
funcionales que permiten determinar el grado de escalabilidad que tiene un sistema.
Se entiende como escalable la capacidad que tiene el sistema para que, sin aplicar
cambios drásticos en su configuración, pueda soportar el incremento de demanda
en la operación.
14
Un ejemplo de escalabilidad es si el sistema soporta la agregación de un nodo
extra en su esquema de balanceo en la capa aplicativa o de base de datos, o un
incremento en la memoria RAM o CPU´s en su infraestructura.
Pruebas de mantenibilidad
Implantación de sistemas de integración continua, para realizar revisión estática de
código, con el objetivo de conocer la calidad intrínseca del mismo valorada en
términos de: métricas del código fuente, adecuación a estándares de lenguaje de
programación y cumplimiento de buenas prácticas.
Pruebas de instalabilidad
capacidad del producto software para ser instalado en un entorno especificado.
Pruebas de portabilidad
Se define como la característica que posee un software para ejecutarse en
diferentes plataformas, el código fuente del software es capaz de reutilizarse en vez
de crearse un nuevo código cuando el software pasa de una plataforma a otra (ver
la nota, a continuación de este párrafo). A mayor portabilidad menor es la
dependencia del software con respecto a la plataforma.
Herramientas para realizar pruebas de software
El control de la calidad de software lleva consigo aplicativos que permiten realizar
pruebas autónomas y masivas permitiendo así la verificación desde el punto de
vista estático y de caja blanca, es decir pruebas donde se analiza el software sin
ejecutar el software mediante el código fuente del mismo. Podemos encontrar
herramientas Open Source (libres) o Comerciales (de pago). Estas herramientas
podrán ser utilizadas para diferentes tipos de pruebas como:
1. Herramientas de gestión de pruebas
2. Herramientas para pruebas funcionales
3. Herramientas para pruebas de carga y rendimiento
15
Herramientas Open Source
1) Herramientas de gestión de pruebas
Bugzilla Testopia
FitNesse
qaManager
qaBook
RTH (open source)
Salome-tmf
Squash TM
Test Environment Toolkit
TestLink
Testitool
XQual Studio
Radi-testdir
Data Generator
2) Herramientas para pruebas funcionales
Selenium
Soapui
Watir
WatiN (Pruebas de aplicaciones web en .Net)
Capedit
Canoo WebTest
Solex
Imprimatur
SAMIE
ITP
WET
WebInject
16
3) Herramientas para pruebas de carga y rendimiento
JMeter
Gatling
FunkLoad
FWPTT load testing
loadUI
Herramientas comerciales
1) Herramientas de gestión de pruebas
HP Quality Center/ALM
Silk Central
QA Complete
qaBook
T-Plan Professional
SMARTS
[Link] Case Studio
PractiTest
SpiraTest
TestLog
ApTest Manager
Zephyr
2) Herramientas para pruebas funcionales
Ranorex
17
Silk Test
QuickTest Pro
Rational Robot
Sahi
SoapTest
Test Complete
QA Wizard
Squish
vTest
Internet Macros
3) Herramientas para pruebas de carga y rendimiento
HP LoadRunner
IBM Rational Performance Test (RPT)
LoadStorm
NeoLoad
WebLOAD Professional
Forecast
ANTS – Advanced .NET Testing System
Webserver Stress Tool
Load Impact
Silk Performer
18
BILIOGRAFÍA
Wikipedia. Wikipedia. [En línea] [Citado el: 20 de 04 de 2018.]
[Link]
Wikipedia. [En línea] [Citado el: 20 de 04 de 2018.]
[Link]
Wikipedia. [En línea] [Citado el: 20 de 04 de 2018.]
[Link]
Wikipedia. [En línea] [Citado el: 20 de 04 de 2018.]
[Link]
Wikipedia. [En línea] [Citado el: 20 de 04 de 2018.]
[Link]
Wikipedia. [En línea] [Citado el: 20 de 04 de 2018.]
[Link]
Wikipedia. [En línea] [Citado el: 20 de 04 de 2018.]
[Link]
Londoño, Jorge Abad. Blogspot. [En línea] [Citado el: 20 de 04 de 2018.]
[Link]
it-Mentor. [En línea] [Citado el: 20 de 04 de 2018.]
[Link]
Wikipedia. Wikipedia. [En línea] [Citado el: 20 de 04 de 2018.]
[Link]
smarter software testing. [En línea] [Citado el: 20 de 04 de 2018.]
[Link]
Instituto Tecnológico de Informática. [En línea] [Citado el: 20 de 04 de 2018.]
[Link]
19
