Diseño de Un Framework de Automatizacion de Control de Calidad para Páginas Web

UNIVERSIDAD MAYOR DE SAN SIMON
FACULTAD DE CIENCIAS Y TECNOLOGIA

DIRECCIÓN DE POSGRADO
“MONOGRAFIA”
DISEÑO DE UN FRAMEWORK DE AUTOMATIZACIÓN DE CONTROL DE CALIDAD

PARA “PAGINAS WEB”
.
POSTULANTE : ENAYDA CECILIA QUISPE

GUARACHI
TUTOR : ING. LUIS MARCELO GARAY
CHOQUERIBE.
Cochabamba – Bolivia 2018

ÍNDICE
INTRODUCCIÓN ............................................................................................................ 7
1.1. ANTECEDENTES.................................................................................................... 7
1.2. OBJETIVO GENERAL ............................................................................................. 8
1.3. OBJETIVOS ESPECÍFICOS .................................................................................... 8
1.4. DEFINICIÓN DEL PROBLEMA ............................................................................... 8
1.5. FORMULACIÓN DEL PROBLEMA .......................................................................... 9
MARCO TEÓRICO ....................................................................................................... 10
2.1. CALIDAD ............................................................................................................... 11

2.2. CALIDAD DEL PRODUCTO SOFTWARE ............................................................. 12
2.3. PRUEBAS DE SOFTWARE .................................................................................. 13
2.4. EVOLUCIÓN DE LAS PRUEBAS .......................................................................... 15
2.5. MODELOS DE DESARROLLO DE PRUEBAS (TESTING) ................................... 16
MODELO CASCADA ...................................................................................... 16

MODELO V .................................................................................................... 17
MODELO ESPIRAL ........................................................................................ 18
MODELO ÁGIL ............................................................................................... 19
MODELO DE DESARROLLO RÁPIDO DE APLICACIONES (RAD) ............... 19
2.6. NIVELES DE PRUEBAS........................................................................................ 20
ETAPA DE DESARROLLO DE LA PRUEBA .................................................. 20
2.6.1.1. PRUEBAS UNITARIAS (UNIT TESTING)................................................ 20

2.6.1.2. PRUEBAS DE INTEGRACIÓN (INTEGRATION TESTING) .................... 20
2.6.1.3. PRUEBAS DE SISTEMA (SYSTEM TESTING) ....................................... 21
2.6.1.4. PRUEBAS DE ACEPTACIÓN O PRUEBAS DE VALIDACIÓN
(ACCEPTANCE TESTING) ...................................................................................... 22
OBJETIVO DE LAS PRUEBAS ...................................................................... 23
2.6.2.1. PRUEBAS DE REGRESIÓN ................................................................... 23

2.6.2.2. PRUEBAS ALFA ..................................................................................... 24
2.6.2.3. PRUEBAS BETA ..................................................................................... 24
2.7. RESUMEN DE LOS NIVELES DE PRUEBAS ....................................................... 25
ANÁLISIS DE LAS PRUEBAS ...................................................................................... 26
3.1. PRUEBAS DE CAJA NEGRA (BLACK-BOX) ........................................................ 26

3.2. PRUEBAS DE CAJA BLANCA (WHITE-BOX) ....................................................... 27
3.3. EVALUACIÓN DE HERRAMIENTAS SEGÚN EL TIPO DE PRUEBA ................... 27
1
HERRAMIENTAS PARA PRUEBAS DE ACEPTACIÓN ................................. 27
HERRAMIENTAS PARA PRUEBAS ESTÁTICAS DE CÓDIGO ..................... 28
HERRAMIENTAS PARA PRUEBAS UNITARIAS ........................................... 29
HERRAMIENTAS PARA PRUEBAS FUNCIONALES ..................................... 29
3.3.4.1. HERRAMIENTAS QUE VERIFICAN ENLACES ...................................... 29

3.3.4.2. HERRAMIENTAS DE FUNCIONALIDAD ................................................ 30
HERRAMIENTAS PARA PRUEBAS DE RENDIMIENTO ............................... 32

HERRAMIENTAS PARA PRUEBAS DE DESEMPEÑO ................................. 33
HERRAMIENTAS PARA PRUEBAS EN BASES DE DATOS ......................... 34
HERRAMIENTAS PARA PRUEBAS DE LINKS Y HTML ................................ 35
HERRAMIENTAS PARA PRUEBAS DE SERVICIOS HTML .......................... 36
HERRAMIENTAS PARA PRUEBAS DE SEGURIDAD ................................... 36
HERRAMIENTAS PARA CONTROL DE DEFECTOS .................................... 36
HERRAMIENTAS PARA LA GESTIÓN DE LAS PRUEBAS ........................... 37
HERRAMIENTAS PARA PRUEBAS DE COMUNICACIONES ....................... 38
HERRAMIENTAS PARA GESTIÓN DE REQUISITOS ................................... 39
OTRAS HERRAMIENTAS .............................................................................. 39
3.4. VENTAJAS Y DESVENTAJAS DE LAS HERRAMIENTAS.................................... 40
HERRAMIENTAS PARA PRUEBAS DE ACEPTACION ................................. 40

HERRAMIENTAS PARA PRUEBAS ESTÁTICAS DE CÓDIGO ..................... 41
HERRAMIENTAS PARA PRUEBAS UNITARIAS ........................................... 42
HERRAMIENTAS PARA PRUEBAS FUNCIONALES-FUNCIONALIDAD ....... 43
4. DISEÑO DE LAS PRUEBAS (TESTING) ...................................................................... 44
4.1. MEJORES PRÁCTICAS Y ENFOQUE DE DISEÑO .............................................. 44
LOS CINCO PRINCIPIOS BÁSICOS DE PROGRAMACIÓN ORIENTADA A

OBJETOS 45
4.1.1.1. S (SRP) PRINCIPIO DE RESPONSABILIDAD ÚNICA: ........................... 45

4.1.1.2. O (OCP) PRINCIPIO DE ABIERTO/CERRADO: ..................................... 47
4.1.1.3. L (LSP) – PRINCIPIO DE SUSTITUCIÓN DE LISKOV: ........................... 49
4.1.1.4. I (ISP) PRINCIPIO DE SEGREGACIÓN DE LA INTERFAZ:.................... 50
4.1.1.5. D (DIP) PRINCIPIO DE INVERSIÓN DE LA DEPENDENCIA: ................ 50
4.2. PATRONES DE DISEÑO DE SOFTWARE............................................................ 51
SINGLETON ................................................................................................... 51
FACTORY ...................................................................................................... 53
4.3. AUTOMATIZACIÓN DE PRUEBAS ....................................................................... 56

4.4. SEGMENTANDO UN FRAMEWORK .................................................................... 56
LOCATORS/SELECTORS FIELDS MAPPING ............................................... 56
2
4.4.1.1. PAGE OBJECT ....................................................................................... 57
4.4.1.2. DATA SETS ............................................................................................ 61
4.4.1.3. TEST SUITES ......................................................................................... 62
4.4.1.4. CONFIGURACIÓN DE REGRESIONES ................................................. 65
4.4.1.5. LOGS DE EJECUCIÓN ........................................................................... 65
MANTENIMIENTO.......................................................................................... 66
4.5. TIPOS DE AUTOMATIZACIÓN DE FRAMEWORKS ............................................. 66
DATA-DRIVEN TESTING (DDT) .................................................................... 66

MODULARITY-DRIVEN TESTING (MDT) ...................................................... 67
KEYWORD-DRIVEN TESTING (KDT) ............................................................ 68
HYBRID-DRIVEN TESTING ........................................................................... 69
4.6. HERRAMIENTAS DE AUTOMATIZACIÓN PARA UTILIZAR ................................ 69

4.7. OPEN SOURCE O PROPIETARY. ........................................................................ 69
4.8. OPTIMIZACIÓN DE LA VELOCIDAD, EFICIENCIA Y CALIDAD DEL SUT ........... 69
4.9. MAYOR RETORNO A LA INVERSIÓN (ROI) ........................................................ 69
5. CONCLUSIONES Y RECOMENDACIONES ................................................................ 70
PRUEBA MANUAL ................................................................................................... 72

PRUEBAS AUTOMATIZADAS .................................................................................. 72
6. BIBLIOGRAFÍA ............................................................................................................. 76
3
ÍNDICE DE FIGURAS
Figura 1: Evolución del Software .............................................................................................. 10

Figura 2: Evolución de las Pruebas........................................................................................... 15
Figura 3: Etapas del Modelo Cascada ...................................................................................... 17
Figura 4: Modelo V ................................................................................................................... 18
Figura 5: Modelo espiral ........................................................................................................... 19
Figura 6: Diagrama "Mensajero" ............................................................................................... 45
Figura 7: Diagrama "Mensajero (SRP)"..................................................................................... 46
Figura 8: Diagrama "Mensajero (OCP)" .................................................................................... 47
Figura 9:Diagrama "Mensajero (interfaz)" ................................................................................. 48
Figura 10: Diagrama "Fábrica" .................................................................................................. 49
Figura 11: Diagrama OMT de Singleton .................................................................................... 51
Figura 12: Estructura de patrón de diseño Factory Method ....................................................... 53
Figura 13: Diagrama de secuencia del patrón de Diseño Fartory Method ................................. 54
Figura 14: Flujo de Ejecución del Patrón de Diseño Factory Method ........................................ 55
Figura 15: Proceso de PageObject ........................................................................................... 57
Figura 16: Clase "Básica" ......................................................................................................... 58
Figura 17: Creación de PageObject .......................................................................................... 58
Figura 18: Pagina Ingresar Sesión ............................................................................................ 59
Figura 19: Proceso de Test Suite .............................................................................................. 63
Figura 20: Resultado de Test Suite ........................................................................................... 65
Figura 21: Proceso de Data-Driven Testing .............................................................................. 66
Figura 22: Modulary-Driven Testing .......................................................................................... 68
Figura 23: Hibrid-Driven Testing ............................................................................................... 69
Figura 24:Mitigación de Riesgos ............................................................................................... 72
Figura 25: P. Automatizadas vs P. Manuales "1" ...................................................................... 74
Figura 26: P. Automatizadas vs P. Manuales “2” ...................................................................... 74
4
ÍNDICE DE TABLAS
Tabla 1 Requisitos de Cada Nivel de Pruebas .......................................................................... 25

Tabla 2: Alcance de Cada Nivel de Pruebas ............................................................................. 25
Tabla 3: Método de Cada Nivel de Pruebas.............................................................................. 26
Tabla 4: Herramientas para probar código fuente ..................................................................... 29
Tabla 5: Herramientas para Pruebas Funcionales .................................................................... 32
Tabla 6: Herramientas para Pruebas de Desempeño ............................................................... 34
Tabla 7: Herramientas para Pruebas en Base de Datos ........................................................... 35
Tabla 8: Herramientas para Pruebas de Links y HTML ............................................................. 35
Tabla 9: Herramientas para Servicios de HTML ........................................................................ 36
Tabla 10: Herramientas para Pruebas de Seguridad ................................................................ 36
Tabla 11: Herramientas para Control de Defectos .................................................................... 37
Tabla 12: Herramientas para la Gestión de las Pruebas ........................................................... 38
Tabla 13: Herramienta para Pruebas de Comunicaciones ........................................................ 38
Tabla 14: Herramientas para Gestión de Requisitos ................................................................. 39
Tabla 15: Otras Herramientas ................................................................................................... 39
Tabla 16: Comparación entre Herramientas de Aceptación ...................................................... 40
Tabla 17: Ventajas y Desventajas de Herramientas de Pruebas de Aceptación ....................... 41
Tabla 18: Comparación entre Herramientas para Pruebas Estáticas de Código ....................... 41
Tabla 19:Ventajas y Desventajas de herramientas para Pruebas Estáticas de código.............. 42
Tabla 20: Comparación entre Herramientas de Pruebas Unitarias............................................ 42
Tabla 21: Ventajas y Desventajas de Herramientas para Pruebas Unitarias ............................. 43
Tabla 22: Comparación de Herramientas para Pruebas Funcionales-Funcionalidad ................ 43
Tabla 23: Ventajas y Desventajas de Herramientas para Pruebas Funcionales-Funcionalidad 44
Tabla 24: Ventajas y Desventajas del Patrón de Diseño Singleton ........................................... 53
Tabla 25: Ventajas y Desventajas del Patrón de Diseño Factory .............................................. 56
Tabla 26: Pruebas Manuales Vs Pruebas Automatizadas ......................................................... 73
5
RESUMEN
Este documento sirve como base de conocimientos, para la aplicación de un proceso de pruebas
automatizadas para páginas web, que asegure la calidad de los productos de software. El centro
del proyecto es el diseño de framework automatizado que propone el proceso desde el punto de
vista teórico y práctico y además funciona como repositorio de conocimientos para permitir ser
llevada a la realidad de los proyectos que incluyan pruebas de software, tanto en el ámbito
empresarial como académico.
Por otro medio de la utilización de este framework se tendrá una amplia visión de lo que las
pruebas de software implican. Como se plantea en el transcurso de este documento, la idea
central es tener una amplia gama de conocimientos que permitan el aprendizaje y la realización
de procesos involucrados en las pruebas de software automatizadas para el desarrollo de un
framework a medida, logrando así la uniformidad de las posibles soluciones.
6
INTRODUCCIÓN
En la actualidad, los escenarios de pruebas en el entorno de desarrollo de software han adquirido

mayor relevancia en lo que desarrollo de software se refiere, ya que se ha hecho evidente su
importancia por el ahorro que representa detectar tempranamente los errores del software.
En ese sentido, los desarrollos tecnológicos pueden ayudar a las empresas a lograr un
mejoramiento de procesos, una clara reducción de costos, y el siempre deseado incremento de
la riqueza de las acciones de dicha empresa. Así, el software desarrollado colabora en cada una
de las actividades importantes del negocio. Siendo la calidad del software un conjunto de
cualidades que lo caracterizan y que determinan su utilidad y existencia, sinónimo de eficacia,
flexibilidad, corrección, confiabilidad, mantenibilidad, portabilidad, usabilidad, seguridad e
integridad. Lograr un alto nivel de calidad de un producto o servicio es el objetivo de la mayoría
de las organizaciones que desarrollan software. Se ha comprobado que el desarrollo de software
está en tendencia de crecimiento en el área de control de calidad de pruebas; satisfaciendo las
necesidades del cliente con un cumplimento de alta calidad. Por lo que se puede analizar la
variedad de tipos y técnicas de pruebas, dada esta situación se considera la complejidad que a
medida van existiendo distintos lenguajes de programación, sistemas operativos tanto en
aplicaciones como en programa de escritorio o Web [1].
1.1. ANTECEDENTES
De acuerdo con la terminología de la IEEE, la calidad de un sistema componente o proceso de

desarrollo de software, se obtiene en función del cumplimiento de los requerimientos iniciales
especificados por el cliente o usuario final [2].
En la actualidad existen un gran número de empresas que consideran que la calidad en el

desarrollo de software no es un aporte, sino un gasto de control de calidad, mencionado por la
empresa “KIBERNUM”, expresado por el Jefe de Área de Calidad Técnico, Víctor Gómez [3]. Por
lo tanto, dicha empresa considera que debe existir una gestión de cambio en la mentalidad de los
que toman decisiones, para que puedan ver los beneficios que llevan las actividades de la Calidad
que, a largo plazo, se puede ver en la disminución de costos asociados a la corrección de
defectos, errores, fallas, aumento de inversión y de la satisfacción del cliente.
“De acuerdo con Gartner, Estados Unidos gasta US $59 billones de dólares en pruebas en calidad
del software. De este total, US $13 billones de dólares se invierten en outsourcing en los países
asiáticos. Dada la reputación de India, como país TI, un 70%, representado en US $9.1 billones
7
de dólares, se obtuvo por servicios de TI en pruebas de software externalizadas. Además, se
estima que la India necesitará cerca de 18.000 profesionales en pruebas en calidad del software
cada año durante los próximos tres años para satisfacer la demanda del mercado de las pruebas
de software” [4].
Cuando se trabaja en proyectos de desarrollo, muchas de las operaciones que se realizan en

esencia son repetitivas pese a ser proyectos diferentes. Hay muchas operaciones que son
comunes. Si el proyecto se organiza mediante el uso de herramientas creadas a tal efecto, este
proyecto va a buscar la manera más eficiente de organizar los proyectos y una vez conseguido
esto, diseñar y crear herramientas que permitan una generación automática de código, con el fin
de ahorrar tiempo de desarrollo y obtener el control automático de las pruebas del software.
1.2. OBJETIVO GENERAL
Diseñar un framework de automatización para el control de calidad en “paginas web” para

empresas de desarrollo de software.
1.3. OBJETIVOS ESPECÍFICOS
1. Adoptar una metodología de desarrollo.

2. Reducir los costos de recursos de software destinados a las pruebas de calidad de
software.
3. Reducir el tiempo de pruebas funcionales.
4. Diseñar un framework de automatización para pruebas automatizadas.
1.4. DEFINICIÓN DEL PROBLEMA
“National Institute of Standards & Technology (NIST), informa que los errores de software está
costando a la economía de Estados Unidos aproximadamente $59,5 billones de dólares cada
año, con más de la mitad de los gastos sufragados por los usuarios finales y el resto por los
desarrolladores y proveedores, y que las mejoras en las pruebas pueden reducir este costo en
cerca de un tercio, o $22,5 billones de dólares pero aun así no se puede garantizar que eliminen
todos los errores de software” [5].
Existen altas exigencias por parte de los clientes para implementar producción en el software que
se requiere. Hoy en día el software acapara gran parte de las actividades diarias de las personas
donde se puede llegar a manejar desde grandes sumas de dinero hasta vidas de personas, desde
8
el inicio del día hasta el final del día se puede ver, la continua usabilidad de aplicaciones de
software se puede ver en todo lado la tecnología.
Los desarrolladores son humanos y el humano comete errores, por lo que el 95% de incidencia
de seguridad de informática se deben a errores humanos, mencionado por el último informe de
los investigadores en seguridad de IBM [6].
La complejidad propia de software hace que sea susceptible de tener errores y un software que
no pase por un proceso de pruebas puede causar importantes pérdidas a nivel económico, daños
ambientales e incluso puede costar la vida de las personas. Sin embargo, a pesar de la
importancia de las pruebas en la calidad del software, y de los beneficios que tiene, no existe en
la actualidad un framework que reúna los procesos, las actividades, los roles involucrados, los
formatos requeridos que cubra el aspecto teórico y práctico de pruebas y que identifique los
distintos entregables o productos de trabajo en cada fase, que permitan asegurar un proceso
efectivo de pruebas en la calidad del software.
1.5. FORMULACIÓN DEL PROBLEMA
Frente a dicho problema, algunas organizaciones han optado por implementar scripts de
automatización de pruebas, aunque al principio arrojan resultados positivos, a largo plazo implica
alta mantenibilidad de los desarrollos realizados para dicho fin. De hecho, uno de los
impedimentos para implementar la automatización es el bajo reúso e inflexibilidad de los scripts
(Zhu, Zhou, Li y Gao, 2008).
Para mejorar la productividad del software desarrollado, actualmente las empresas invierten más
del 50% del costo total de un proyecto en la ejecución de pruebas (Alégroth, Feldt y Kolström,
2016), lo cual ha despertado interés en cómo mejorar el proceso global de pruebas a través de
la automatización.
El estándar IEEE 829-1998 es sumamente importante porque cubre los planes de prueba, los
diseños de pruebas, los casos de prueba, los registros de prueba, los informes de incidentes de
prueba, los informes de resumen de prueba y otros materiales (ULAKBIM UASL - MIDDLE EAST
TECHNICAL UNIVERSITY). Se podrá identificar un plan de prueba, su nivel y el nivel de software
con el que está relacionado. Preferiblemente, el nivel del plan de prueba será el mismo que el
nivel de software relacionado. El número también puede identificar si el plan de prueba es un plan
maestro, un plan de nivel, un plan de integración o cualquier nivel de plan que represente. Esto
9
es para ayudar a coordinar las versiones de software y software de pruebas dentro de la
administración de la configuración.
En la figura 1 se puede observar la oportunidad de negocio entre tecnologías que existe hoy en
día. Las aplicaciones web presentan la particularidad de disponer dos factores fundamentales, su
agilidad para el despliegue y una gran capacidad para saber adaptarse a los gustos de los
usuarios.
Mientras las aplicaciones de escritorio gozaban de casi todo el mercado, no tienen la capacidad
de hacer un despliegue ágil en comparación con otras tecnologías. Este factor, con el nivel de
competitividad, donde predomina el que primero coloque su producto resulta una desventaja
frente a la competencia.
Otra gran oportunidad de negocio son las aplicaciones que aún se desarrollan con tecnología
web 2.0 y aplicaciones destinadas a dispositivos móviles. Estas últimas en pleno auge [8].
Figura 1: Evolución del Software

Fuente: (By Jeremy Chone, BritaSnow http//britesnow.com/blog)
MARCO TEÓRICO
Cuando se propone implementar un framework automatizado, se tiene que tomar en cuenta y

entender el contexto de lo que se quiere lograr, donde queremos llegar con la solución de pruebas
automatizadas y entender que es lo que se quiere automatizar, hacer un análisis de qué tipo de
aplicación es, sobre que plataforma funciona, como está desarrollada la aplicación, como se está
10
elaborando las pruebas manuales, cual es el proceso de ejecución de las pruebas manuales,
como son los procesos de desarrollo de la aplicación, que metodología se está usando, cada que
tiempo se tiene un solicitud de cambio, cual es el proceso actual de desarrollo de la aplicación.
2.1. CALIDAD
Una palabra clave que se ha convertido en un factor estratégico y diferenciador para las
organizaciones en búsqueda de esa tan valorada y esperada satisfacción de las necesidades y
expectativas del cliente “la calidad”. Las organizaciones y empresas de desarrollo de software se
han dado cuenta del importante beneficio que conlleva ofrecer productos y servicios de excelente
calidad, reflejados en su productividad, costos, participación en el mercado, competitividad,
motivación del personal y lealtad de los clientes (Sommerville “Ingeniería de Software 7ma. Ed.”).
El término “calidad” ha tomado tal importancia en estas últimas décadas que su aplicación está
más allá de algún tipo de organización en particular o de algún producto específico; el concepto
de calidad es una filosofía aplicable en todos los tipos de organizaciones y alcanza a tocar a cada
persona perteneciente a la organización; así pues, que la calidad tiene que ver con todo y con
todos, y es el factor que permite a las organizaciones asegurar su permanencia en el mercado
(ISO 9000, IEEE 730-2014).
Algunos reconocidos autores definen la calidad de la siguiente manera:
"La calidad no es otra cosa más que una serie de cuestionamientos hacia una mejora continua".
Edwards Deming
“La calidad es la adecuación para el uso, satisfaciendo las necesidades del cliente".
Dr. J. Juran
“La primera hipótesis errónea es que la calidad significa la bondad o elegancia. La palabra
"calidad" se utiliza a menudo para indicar el valor relativo de algo en frases tales como "buena
calidad", "mala calidad" y "calidad de vida", lo que significa algo diferente para cada persona.
Por lo tanto, la calidad debe ser definida como "la conformidad con los requisitos", si hemos de
gestionarla. En consecuencia, la no conformidad detectada es la falta de calidad, los problemas
en la calidad se convierten en problemas de no conformidad, y la calidad se convierte en
definible.”
Philip B. Crosby
11
2.2. CALIDAD DEL PRODUCTO SOFTWARE
La calidad que pueden alcanzar los productos software y en general cualquier producto, está
sometida a cómo se desarrolla cada una de las etapas de la vida del producto, partiendo por la
definición de la idea del producto hasta la entrega y mantención de este. Es importante hacer
énfasis en que la calidad se construye durante el proceso y no al final cuando el producto ya está
construido y que las pruebas se encargan de verificar y validar que el producto final satisface los
requerimientos de usuarios y uso deseado. Es decir, las pruebas no agregan calidad, ésta se
construye durante el proceso de desarrollo.
Así, la entrega de calidad a un producto considera actividades tales, como:
• Administración de los recursos, asegurando minimizar las diferencias entre los recursos
presupuestados y los recursos realmente utilizados en las distintas etapas. Dichos
recursos incluyen el staff, el equipamiento y tiempo de desarrollo.
• Uso de tecnología de Ingeniería de Software eficiente, considerando métodos de
desarrollo y herramientas.
• Aplicación de técnicas o metodologías formales de ingeniería de software a lo largo de
todo el proceso.
• Minimización de las variaciones entre los productos, disminuyendo las diferencias y
defectos entre versiones.
• Testeo exhaustivo en diferentes etapas del desarrollo.
• Control de la documentación, tanto de apoyo al desarrollo como la entregada al usuario
final, generado en cada etapa, y verificación de los posibles cambios y modificaciones
que pudiera sufrir.
• Correcta mantención y servicios de post-venta.
Existen varios modelos reconocidos mundialmente que sirven de guía para la gestión de la
calidad en relación con el software. Cada uno de ellos presenta un conjunto de buenas prácticas
para el ciclo de vida del software, enfocándose en los procesos de gestión y desarrollo de
proyectos (Sommerville “Ingeniería de Software 7ma. Ed.”).
Entre los más conocidos se encuentra el modelo CMMI®, que en una de sus últimas versiones
tiene el modelo CMMI-DEV V1.3 (CMMI for Development –CMMI para Desarrollo), el cual sirve
de apoyo a una organización o proyecto que desarrolle productos o servicios, enfocándose en la
administración, medición y monitoreo de los procesos de desarrollo [11].
12
Por otro lado, se encuentra la norma ISO/IEC 15504, que es un modelo para la mejora y
evaluación de los procesos de desarrollo y mantenimiento de sistemas y productos de software.
Además, el estándar ISO/IEC 9126 es un estándar internacional para la evaluación del software.
Está dividido en cuatro partes las cuales dirigen, respectivamente, lo siguiente: modelo de calidad,
métricas externas, métricas internas y métricas de calidad en uso [11].
El estándar ISO/IEC 29119 para las pruebas de Software, estándar relativo a revisiones, tiene
como objetivo proveer un estándar que capture vocabulario, procesos, documentación y técnicas
para todo el ciclo de pruebas de software [11].
Finalmente, ISO/IEC 12207 establece un sistema para los procesos del ciclo de vida del software.
Contiene procesos, actividades y tareas que se deben aplicar durante la adquisición de un
software [11].
2.3. PRUEBAS DE SOFTWARE

Las pruebas de software son una investigación realizada para informar sobre la calidad del
producto o servicio bajo prueba. Las pruebas de software también proporcionan una visión
objetiva e independiente del software para conocer y comprender los riesgos cuando se desarrolla
software.
Las pruebas de software se aplican a lo largo del proceso de desarrollo de software, su objetivo
es asegurar que el software cumpla con las especificaciones requeridas y eliminar los posibles
defectos que pudiera tener. Este proceso es llevado a cabo por un equipo de probadores de
software.
Las pruebas nunca podrán identificar todos los defectos en el software. En su lugar, realiza una
comparación entre el estado y el comportamiento del producto frente a los principios o
mecanismos por los cuales alguien podría reconocer que el software tiene un problema.
Las pruebas de software son un proceso de verificación y validación de este. Tiene tres propósitos
principales: verificar, validar y encontrar defectos:
• El proceso de verificación confirma que el software cumple con sus especificaciones

técnicas. Una especificación es una descripción de una función en términos de un valor
de salida medible dado un valor de entrada específico bajo condiciones específicas.
• El proceso de validación confirma que el software cumple con los requisitos del negocio y
con el uso previsto por el usuario.
13
• Finalmente, un defecto es una variación entre el resultado previsto y el real.
En un principio, la mayoría de las empresas de desarrollo contaban con una etapa de pruebas
demasiado informal, pero en la actualidad la prueba del software se ha convertido en una de las
etapas más críticas del ciclo de vida del desarrollo de software y esto se ha traducido en el origen
de diversas metodologías.
En la actualidad las pruebas, se hace más complicado ya que debe hacer frente a una gran
cantidad de metodologías de desarrollo, lenguajes de programación, sistemas operativos,
hardware, entre otros.
Para las pruebas del producto, lo recomendable es que el software se mantenga en un ambiente
aislado o separado del ambiente de desarrollo o de producción: lo ideal es preparar un ambiente
de pruebas lo más parecido a los ambientes que existen en producción para asegurar su correcto
funcionamiento en esa futura etapa. Se debe considerar adquirir un equipo de pruebas
especializado, conformado por “probadores de software” o analistas de pruebas con experiencia,
aunque en ocasiones, algunas empresas más informales utilizan a los futuros usuarios del
sistema como probadores de software, situación que puede traer una serie de problemas debido
a la poca experiencia que pueden tener los usuarios en la detección de errores y la falta de
formación en las pruebas para el software, además se obvian pruebas importantes como las
pruebas de esfuerzo o “de stress”; también se dejan de lado las pruebas unitarias o pruebas
modulares, las que deberían asegurar que cada módulo del sistema trabaje correctamente de
manera independiente.
En el software la confianza es un elemento importante ya que ciertas fallas pueden tener

consecuencias indeseables como pérdidas de dinero, de negocios, e incluso de vidas,
dependiendo de qué tan crítico sea el dominio en el cual el software interactúa. Las pruebas le
dan valor agregado a cada proyecto brindando confianza a los distintos actores [12].
Algunas definiciones de pruebas de software:
"El testing es una habilidad. Si bien esto puede ser una sorpresa para algunas personas es un
hecho simple."
Graham Fewster
"Realizarle pruebas a un producto es un proceso de aprendizaje."
Brian Marick
14
“Una investigación técnica de un producto bajo prueba con el fin de brindar información relativa
a la calidad del software, a los diferentes actores involucrados en un proyecto.”
Cem Kaner
"El testing puede probar la presencia de errores, pero no la ausencia de ellos."
E. W. Dijkstra
"Software Testing es el proceso de evaluar un Sistema o Componente de un Sistema de forma

manual o automática para verificar que satisface los requisitos esperados, o para identificar
diferencias entre los resultados esperados y los reales."
ISO/IEC/IEEE 29119
2.4. EVOLUCIÓN DE LAS PRUEBAS
Dave Gelperin y William C. Hetzel describieron en 1988 la evolución de las pruebas de software
como se puede observar en la Figura 2:
Figura 2: Evolución de las Pruebas

Fuente: Dave Gelperin y William C. Hetzel
Hasta 1956 fue el período orientado a la depuración, donde las pruebas eran asociadas a menudo
con la depuración, no había una clara diferencia entre uno y otro.
De 1957 a 1978 fue el período orientado a la demostración, en la cual la depuración y las pruebas
se distinguían uno del otro. En este período se empezó a mostrar que el software debía cumplir
con los requerimientos.
Entre 1979 y 1982 comienza el período orientado a la destrucción, donde la meta principal era
encontrar errores.
15
De 1983 a 1987 es el período orientado a la evaluación, donde la intención era que durante el
ciclo de vida del software se hacía una evaluación del producto y una medición de la calidad.
Desde 1988 comenzó un período orientado a la prevención, donde las pruebas se hacen para
demostrar que el software satisface las especificaciones, para detectar fallas y prevenir errores
[12]
.
2.5. MODELOS DE DESARROLLO DE PRUEBAS (TESTING)
Los modelos más comunes que acostumbran a utilizarse para desarrollar proyectos de pruebas,
y analizar si es posible utilizar alguno de ellas como modelo para la metodología de
automatización de pruebas para servicios web de la respectiva empresa. Las metodologías más
comunes que utilizan para el desarrollo de proyectos que son las siguientes:
• Modelo Cascada
• Modelo V
• Modelo Espiral
• Modelo Ágil
• RAD
MODELO CASCADA
El modelo en cascada es una metodología que se caracteriza porque no se avanza a la etapa

siguiente hasta que no se haya completado la etapa actual. Tampoco es posible volver a la etapa
anterior o ejecutar dos etapas al mismo tiempo. Además, este modelo en un principio no se
considera la iteración de las etapas. Esta metodología de pruebas está compuesta por estos
pasos:
1. Análisis de requisitos.
2. Diseño de los casos de prueba.
3. Implementación de los casos de prueba.
4. Ejecución y verificación de las pruebas.
5. Mantenimiento de las pruebas.
A pesar de ser una metodología muy simple tiene una deficiencia para aplicaciones web y es que
los fallos y errores del código no se pueden descubrir hasta que haya finalizado la implementación
de todas las pruebas de la aplicación. Es muy frecuente que las aplicaciones web estén
continuamente sujetas a cambios importantes de diseño, requisitos, etc. En consecuencia, el
proyecto de pruebas de una aplicación web también requerirá continuas adaptaciones: cambios
16
de etapa sin finalizar, saltos atrás, en definitiva, puede decirse que no se respetarían los principios
de este modelo [39] [40], [12].
Figura 3: Etapas del Modelo Cascada

Fuente: ISTQB
MODELO V
El modelo V se llama así porque el esquema que la representa tiene la forma de esa letra. La
mayor ventaja de esta metodología es que el desarrollo de la aplicación y el desarrollo de las
pruebas se van ejecutando paralelamente. Por ejemplo, cuando el equipo de desarrollo se
encuentra desarrollando el análisis de requisitos, el equipo de pruebas al mismo tiempo puede
comenzar a preparar las pruebas aceptación. Siguiendo este modelo, los retrasos se reducen al
mínimo [12].
En la siguiente figura se muestran las etapas de desarrollo del proyecto de una aplicación y el
nivel de las pruebas que se ejecutarán en esa etapa [40], [12].
17
Figura 4: Modelo V
Fuente: ISTQB
MODELO ESPIRAL
El modelo en espiral sigue un planteamiento en el que cada espiral es un ciclo que contiene todos
los pasos secuenciales del modelo de cascada. Una vez que el ciclo inicial se completa, un
análisis exhaustivo y la revisión del producto logrado o de salida se llevan a cabo. Si no está de
acuerdo con los requisitos establecidos o estándares esperados, un segundo ciclo siguiente, y
así sucesivamente. Esta metodología sigue un método iterativo y generalmente es adecuado para
proyectos muy grandes con requisitos complejos y en constante cambio [40], [41], [12].
18
Figura 5: Modelo espiral
Fuente: ISTQB
MODELO ÁGIL
El modelo ágil es una metodología que no sigue ni un enfoque puramente secuencial como
modelo cascada, ni un enfoque puramente iterativo como el modelo en espiral. Más bien puede
considerarse como una combinación entre estos dos enfoques y otros métodos de desarrollo
propios. El objetivo de este modelo es obtener resultados rápidamente, de manera práctica y que
sean visibles. La continua interacción con el cliente y la colaboración es una parte clave del
proceso de desarrollo [40], [12].
MODELO DE DESARROLLO RÁPIDO DE APLICACIONES (RAD)
Esta metodología, está diseñada para conseguir un desarrollo rápido del proyecto de pruebas.
Apenas conocer los requisitos de la aplicación, se prepara un prototipo rápido. Una vez elaborado
el prototipo y haberlo comentado con el cliente o el equipo de desarrollo, se hacen los cambios
necesarios y se continúa con el desarrollo. No es adecuado para proyectos grandes ni complejos,
más bien está pensado para proyectos sencillos donde las necesidades estén en constante
cambio [40], [12].
19
2.6. NIVELES DE PRUEBAS
Una prueba puede clasificarse en diferentes niveles según:

• La etapa en la que se desarrolla la prueba.
• El objetivo de la prueba.
En los subapartados siguientes se describen los niveles de cada grupo y el tipo de pruebas que
los componen. Más adelante, se especifica cuáles son los niveles de las pruebas que se van a
automatizar [12][9].
ETAPA DE DESARROLLO DE LA PRUEBA
Una breve descripción de los niveles de pruebas, organizados según la etapa del proyecto que
se quiere testear en la que se ejecutan. Para cada tipo de pruebas, hay tres características sobre
las que se hace especial énfasis. La primera es la opacidad del tipo de prueba, es decir, si es un
testeo de tipo caja blanca o caja negra. La segunda es el alcance del proyecto con el que se
corresponde la prueba. Puede ir desde una línea de código hasta toda la aplicación. Por último,
se define cual es el objetivo de las pruebas [12].
2.6.1.1. PRUEBAS UNITARIAS (UNIT TESTING)
• Opacidad: White box testing.

• Requisitos: Diseño bajo nivel y/o estructura del código
• Objetivo: verificar que las partes individuales son correctas aislándolas del resto del
programa.
Las pruebas unitarias son pruebas de unidades individuales o grupos de unidades individuales
relacionadas de software o hardware.
Este tipo de testeo puede describirse como la verificación a muy bajo nivel de que el código hace
lo que se espera que haga y para poder verificar las pruebas es necesario disponer del diseño y
la estructura del código.
Un ejemplo de prueba de este tipo sería la verificación que una función de la aplicación devuelve
el valor esperado [12][9].
2.6.1.2. PRUEBAS DE INTEGRACIÓN (INTEGRATION TESTING)
• Opacidad: Black-box y White-box testing

• Requisitos: Diseño a bajo y alto nivel
20
• Objetivo: verificar que los distintos módulos individuales testeados en las pruebas
unitarias funcionan como grupo.
La prueba de integración testea la interacción entre los componentes de software, hardware o
ambos. Este testeo casi siempre lo realiza el desarrollador del código. Usando las técnicas Black-
box y White-box el probador de software verifica la correcta unión entre las diferentes unidades
para construir el sistema [12][9].
Un ejemplo de problema de este tipo sería, por ejemplo, que los datos que debieran llegar a la
interfaz no lo hicieran. Esto podría suceder por dos razones distintas:
• Que no se hubieran mandado los datos correctamente a la interfaz y en ese caso el

probador de software tendría que conocer el diseño de la aplicación a bajo nivel para
buscar y arreglar el error.
• Que la interfaz no esté implementada correctamente y en ese caso el probador de

software requiere conocimientos de la aplicación a alto nivel.
2.6.1.3. PRUEBAS DE SISTEMA (SYSTEM TESTING)
• Opacidad: Black-box testing

• Requisitos: Diseño a alto nivel y especificación de los requisitos
• Objetivo: verificar que las funcionalidades definidas en la especificación de requisitos
de la aplicación se cumplen.
Mediante técnicas Black-box, el probador de software, evalúa el diseño a alto nivel y los
requerimientos de la especificación acordada con el cliente del software, con el objetivo de
planear las pruebas de software que deben llevarse a cabo, para comprobar que la aplicación
hace lo que se espera que haga.
Las pruebas de sistema consisten en probar la aplicación que se está desarrollando en diferentes
entornos, para verificar que el software funciona correctamente en los entornos más comunes
que los usuarios accederán a ella. Las pruebas de sistema tienen en cuenta las distintas
versiones, tipos de sistemas operativos y aplicaciones que intervienen al ejecutarse la aplicación.
Es más conveniente que las pruebas funcionales y las pruebas de sistema los lleven a cabo
personas que no hayan desarrollado ese código, puesto que aportan un punto de vista imparcial
e independiente al que tendrían los autores del código [12][9].
A continuación, se muestran algunos de las pruebas de sistema más importantes:
21
• Pruebas de funcionalidad: Las pruebas funcionales son una parte de las pruebas cuyo
objetivo es verificar que las funcionalidades definidas en la especificación de requisitos de
la aplicación se cumplen. Para verificar las funcionalidades de la aplicación se consideran
los datos de entrada que tras utilizarlos para testear esta funcionalidad devolverán otros
valores de salida. La verificación se obtiene comprobando que los datos de salida que se
[12]
obtienen son los esperados para los datos que hemos utilizado en la entrada .
• Pruebas de carga: este tipo de prueba consiste en llevar el sistema a los límites de la
especificación de requisitos. Por ejemplo, si una de las condiciones acordada con el cliente
sobre la web que se está desarrollando es que 1000 personas puedan autenticar al mismo
tiempo, el stress test de este requerimiento consistiría en comprobar que 1000 personas
pueden autenticar al mismo tiempo sin provocar ningún problema [12].
• Performance testing: este tipo de prueba verifica que se cumplen los requisitos de
ejecución acordados con el cliente. Continuando con el ejemplo anterior, si uno de los
requisitos acordados es que un cliente debe poder autenticar sin tener que esperar más de
5 segundos, el probador de software tendría que comprobar en cualquiera de los casos
posibles que puedan darse que cualquier usuario, tanto si se están autenticar de “0” a “999”
usuarios a la vez [12].
• Pruebas de usabilidad: es el tipo de pruebas que evalúa la medida en la que un usuario

puede aprender a utilizarlo de forma sencilla. Mientras que las pruebas tipo stress y
performance pueden automatizarse, las pruebas de usabilidad requieren una persona
especialista para evaluar la interacción de los usuarios con el software [12].
2.6.1.4. PRUEBAS DE ACEPTACIÓN O PRUEBAS DE VALIDACIÓN (ACCEPTANCE

TESTING)

• Requisitos: Especificación de requisitos
• Objetivo: verificar que la aplicación cumple con los requisitos iniciales durante su
desarrollo o tras finalizarla.
Tras la prueba funcional y las pruebas de sistema, el producto se entrega al cliente, basándose
en las expectativas de las funcionalidades que espera que su producto le ofrezca, el cliente
ejecutará las pruebas de aceptación del producto.
22
Este tipo de pruebas sencillamente verifica si el producto desarrollado satisface al cliente y si en
consecuencia aceptará o no aceptará el producto.
Estas pruebas pueden ser especificadas por el cliente y dados a los probadores de software para
llevarlos a cabo antes de entregar el producto. Si el software no pasa las pruebas de aceptación,
el cliente tiene el derecho de no aceptar el producto.
Un cliente generalmente no especifica una prueba completa de todo el sistema. Quizás especifica
un buen test para cada requerimiento, pero probablemente no sean suficientes. Para que el
software tenga la aceptación del cliente y no falle en el futuro, es recomendable hacer pruebas
de aceptación por cuenta propia de los probadores de software [12].
OBJETIVO DE LAS PRUEBAS
El otro modo de agrupar las pruebas es según el objetivo para el que se utilizan. En la
documentación y bibliografía consultada se consideran dos tipos: pruebas de regresión, pruebas
alfa y pruebas beta.
2.6.2.1. PRUEBAS DE REGRESIÓN
• Opacidad: Black-box y White-box testing

• Requisitos: Cualquier cambio en la documentación, diseño de alto nivel.
• Objetivo: hallar el origen de nuevos errores con respecto al comportamiento esperado de la

aplicación que puedan haberse producido tras la introducción de nuevos cambios en la
aplicación.
El IEEE define las pruebas de regresión como:
“Selective retesting of a system or component to verify that modifications have not caused
unintended effects and that the system or component still complies with its specified
requirements.” (IEEE 610.12-1990).
Es decir, las pruebas de regresión son aquellas cuyo objetivo es volver a testear el sistema para
verificar que las pruebas que antes tenían éxito, después de las modificaciones lo siguen
teniendo.
Las pruebas de regresión pueden considerarse como un subgrupo del conjunto de todos los
casos de prueba. Se ejecutan tras modificaciones significativas como errores resueltos o mejoras
en el sistema.
23
Dependiendo del tamaño del proyecto y de todas las pruebas que el sistema tiene que superar,
puede resultar poco práctico ejecutarlos todos cada vez que se hace una modificación. Las
pruebas de regresión se realizan durante todo el ciclo de desarrollo del proyecto con White-box
en los niveles de pruebas unitarios y de pruebas de integración y con Black-box en los niveles de
test de integración, funcionales, sistema y aceptación [12].
Tras llevar a cabo una modificación deben tenerse en cuenta los siguientes criterios para escoger
el grupo de pruebas a ejecutar:
• Pruebas relacionadas con los componentes o funciones que se han modificado.

• Pruebas relacionadas con las funcionalidades afectadas por las modificaciones.
• Pruebas representativo de las funcionalidades que ofrece el software.
Al grupo de pruebas escogido siguiendo estos criterios, se le llama suite de pruebas de software.
2.6.2.2. PRUEBAS ALFA

• Requisitos: ninguno
• Objetivo: hallar errores por un cliente dentro de la empresa de desarrollo.
Las pruebas alfa, es la prueba final antes de que el software se publique al usuario final, en
general. Tiene dos fases:
• En la primera fase de las pruebas alfa, el software es probado por los desarrolladores
internos. Utilizan software de depuración o depuradores asistidos por hardware. El
objetivo es atrapar insectos rápidamente.
• En la segunda fase de la prueba alfa, el software se entrega al personal de control de
calidad del software para realizar pruebas adicionales en un entorno similar al uso
previsto.
Las pruebas alfa son pruebas operativas simuladas o reales por usuarios / clientes potenciales o
un equipo de prueba independiente en el sitio de los desarrolladores. Las pruebas alfa a menudo
se emplean para software comercial como una forma de prueba de aceptación interna, antes de
que el software pase a la prueba beta [12].
2.6.2.3. PRUEBAS BETA

• Requisitos: Ninguno
24
• Objetivo: hallar errores ofreciendo la aplicación de prueba a los usuarios finales.
Cuando una versión avanzada o completa del software que se está desarrollando está disponible
para su uso, se puede realizar una prueba de tipo beta. Este tipo de prueba consiste en ofrecer
esta versión a algunos usuarios para que utilicen la aplicación y la prueben a condición de que
reporten al equipo de desarrolladores los errores que vayan detectando [12].
2.7. RESUMEN DE LOS NIVELES DE PRUEBAS
A continuación, se muestran unas tablas informativas que resumen los niveles de pruebas.
Nivel de Pruebas Requisitos
Unitario Diseño de Bajo Nivel / Código Actual
Integración Diseño de Bajo Nivel / Diseño de Alto Nivel
Funcional Diseño de Alto Nivel
Sistema Análisis de Requerimientos
Aceptación Análisis de Requerimientos
Beta Ad hoc
Regresión Cambios en la Documentación / Diseño de Alto Nivel
Tabla 1 Requisitos de Cada Nivel de Pruebas

Fuente: ISBQT
Nivel de Pruebas Alcance

Unitario Unidades de Código no Más Grandes que una Clase
Integración Múltiples Clases
Funcional Toda la Aplicación
Sistema Toda la Aplicación
Aceptación Toda la Aplicación
Beta Toda la Aplicación
Regresión Cualquiera de las Anteriores
Tabla 2: Alcance de Cada Nivel de Pruebas

Fuente: ISBQT
25
Nivel de Pruebas Método
Unitario Caja Blanca
Integración Caja Blanca / Caja Negra
Funcional Caja Negra
Sistema Caja Negra
Aceptación Caja Negra
Beta Caja Negra
Regresión Caja Blanca / Caja Negra
Tabla 3: Método de Cada Nivel de Pruebas

Fuente: ISBQT
ANÁLISIS DE LAS PRUEBAS
Se definen en primer lugar los dos grandes grupos en los que se separan las pruebas: caja negra
y caja blanca (ISBQT) [12].
A continuación, se caracterizan las pruebas por niveles. Para cada nivel se define los aspectos
[12]
que se tienen en cuenta a la hora de clasificar una prueba: opacidad, requisitos y objetivos .
3.1. PRUEBAS DE CAJA NEGRA (BLACK-BOX)
La estrategia de Black-Box, o caja negra, puede definirse en los términos que presenta el IEEE:
“Testing that ignores the internal mechanism of a system or component and focuses solely on
the outputs generated in response to selected inputs and execution conditions.”
(IEEE 610.12-1990).
Lo único que ha de hacerse es facilitar datos de entrada al programa y comprobar que los datos
de salida corresponden a los datos esperados. A esta estrategia también se le llama funcional.
En las pruebas de caja negra, es preciso diseñar casos de prueba en los que el programa no
actúe como está esperado que lo haga.
Si se desea utilizar este método para encontrar todos los errores en el programa, el factor
determinante es la prueba de entrada exhaustiva, esto es, utilizando todas las posibles entradas
como juego de pruebas [12].
26
3.2. PRUEBAS DE CAJA BLANCA (WHITE-BOX)
La estrategia White-box, o de caja blanca, queda definida como:
“White-box testing is testing that takes into account the internal mechanism of a system or
component”
(IEEE610.12-1990)
Su objetivo fundamental es asegurar el correcto funcionamiento del flujo de datos entre

componentes de una aplicación, examinando el modo como está implementado. Esta información
entre otras cosas incluye el conocimiento de los algoritmos y estructuras de datos con los que
está diseñado el programa.
Lo ideal sería probar todos los posibles puntos por los que puede pasar el programa según los
datos de entrada. A los caminos que puede tomar la ejecución del programa se le llama el flujo
del programa [12].
3.3. EVALUACIÓN DE HERRAMIENTAS SEGÚN EL TIPO DE PRUEBA
Existen varias herramientas similares, muchas propietarias, que no fueron analizadas en el

presente artículo [13] [14] [15]. Se han seleccionado aquellas de código abierto y con más popularidad,
mencionado por ISTQB [12].
HERRAMIENTAS PARA PRUEBAS DE ACEPTACIÓN
Este tipo de pruebas pueden realizarse con prototipos de la aplicación basados por la ISTQB [12],
diagramas de secuencia o casos de uso que se muestran al usuario para que valide los
requerimientos definidos, existen algunas herramientas que pueden ser útiles:
FitNesse: “SOFTWARE TESTING CLASS”, menciona que la herramienta permite a los usuarios,
equipos de pruebas y programadores aprender lo que debe hacer el software y comparar
automáticamente lo que realmente hace. Se pueden realizar pruebas de aceptación y pruebas
[16]
de reglas de negocio. Es una wiki que no requiere demasiadas configuraciones .
Avignon: “Soft112”, menciona que la herramienta es un framework para pruebas de aceptación

que permite a los usuarios expresar pruebas de aceptación de una forma no ambigua antes que
[17]
comience el desarrollo. Trabaja en conjunto con JUnit, HTTPUnit, JAXP y Xalan . Utiliza XML
para definir la sintaxis del lenguaje.
27
HERRAMIENTAS PARA PRUEBAS ESTÁTICAS DE CÓDIGO
En este tipo de prueba es muy importante la utilización de herramientas, dado que las mismas
facilitan las tareas del equipo de pruebas. Con su uso, es posible encontrar más fácilmente
errores tales como: código muerto, código fuente no documentado o mal finalizado, entre otros.
Se pueden utilizar las siguientes herramientas:
PHPLint: “Tutorial PHPLint”, expresa que la herramienta permite realizar pruebas de código
fuente, con esto se pueden mejorar las tareas de programación, ya sea comenzando la
codificación con esta herramienta o bien, mejorando código ya existente. Brinda buenas prácticas
que permiten dar seguridad en el código, errores de sintaxis, variables no utilizadas, código
muerto [18].
RATS: “MUNDO EN BITS”, menciona que la herramienta realiza chequeo de seguridad en el

código, determinando la criticidad de fallos, como así también una evaluación del código [19].
YASCA: “Michael Scovetta”, desarrollador de la herramienta. Esta permite encontrar

vulnerabilidades de seguridad, calidad en el código, rendimiento, etc. Aprovecha la funcionalidad
de los plugins FindBugs, PMD y Jlint[20].
PMD: “Marco de desarrollo de la Junta de Andalucia” menciona que la herramienta puede ser
integrado a varias herramientas: JDeveloper, Eclipse, JEdit, JBuilder, BlueJ, TextPad, Maven,
Ant, Gel, Jcreator, etc. Permite encontrar en el código errores en el manejo de excepciones,
código muerto, código sin optimizar, código duplicado [21].
FindBugs: “William Pugh”, desarrollador de la herramienta expresa que la herramienta puede

integrarse a Eclipse. Realiza un escaneo de código encontrando errores comunes, malas
[22]
prácticas de programación, código vulnerable, rendimiento, seguridad .
Producto Proveedor Descripción

BoundChecker Compuware Detección y depuración de errores Run-time para
desarrolladores de C++. Soporta C/C++, .net, ASP,
ASP.net.
Bullseye Coverage Bullseye Testing Cubrimiento de código para C/C++.
Technology
CodeCheck Abraxas Software Mide Mantenibilidad, portabilidad, complejidad y
cumplimiento de estándares de código en C y C++.
28
devAdvantage Anticipating Minds Crea estándares de codificación en C#. Detecta y corrige
para cumplir con las mejores prácticas de .NET.
LDRA Testbed LDRA Herramienta de análisis estático de código para C/C ++, C#,
Ada83, Ada95, Java, Visual Basic, Cobol, Coral66, Fortran,
Pascal, PL/Mx86, PL/1, Algol e Intel
Logiscope Telelogic Herramienta de análisis de código fuente.
McCabe TQ McCabe Software Ayuda a identificas, medir y reportar la complejidad del
código en la aplicación y a nivel de empresa.
Predictive Lite Ism Analizador de código que predice defectos en C, C++, Java
o C#, basándose en estándares de industria
Tabla 4: Herramientas para probar código fuente

Fuente: Universidad EAFIT Medellín-2010
HERRAMIENTAS PARA PRUEBAS UNITARIAS
En este tipo de prueba el uso de herramientas facilita tareas como probar una clase o un módulo
en particular. Las herramientas dependen del lenguaje utilizado. Algunas de ellas son:
JUnit: “Kent Beck”, desarrollador de la herramienta, menciona que es un framework para la

automatización de las pruebas unitarias y de integración. Provee clases y métodos que facilitan
la tarea de realizar pruebas en el sistema y así asegurar la consistencia y funcionalidad [23].
PHPUnit: “Sebastian Bergmann”, menciona que es un framework para PHP que permite crear y
ejecutar tests unitarios de manera simple. Está basado en el framework “JUnit” para java [24]
.
SimpleTest: Es un framework para pruebas de unidad en PHP y pruebas Web. Esta herramienta
cuenta con un navegador Web interno, lo que permite que las pruebas naveguen los sitios Web,
ingresen datos en formularios y páginas de prueba [25].
HERRAMIENTAS PARA PRUEBAS FUNCIONALES
Para este tipo de pruebas, se tiene varias herramientas, las cuales se dividen en distintas
“categorías”. Analizaremos las herramientas que verifican enlaces y de funcionalidad.
3.3.4.1. HERRAMIENTAS QUE VERIFICAN ENLACES
XENU: “Xenu’s link Sleut”, menciona que la herramienta, permite encontrar los enlaces rotos en
un análisis en profundidad (HTTP y HTTPS). Como resultado muestra un listado de los enlaces
(imágenes, .css, etc.) rotos en el sitio [26].
29
LINK Checker W3C: “Ville Skyttä”, expresa que una herramienta disponible On-Line. Permite
encontrar enlaces rotos, anclas mal definidas, advertir sobre redirecciones [27].
DRKSpider: “DRK Open Source Software”, menciona acerca de la herramienta, permite la

navegación por enlaces internos, externos; imágenes, .CSS y otros archivos. Genera como
resultado un árbol jerárquico con los enlaces del sitio en prueba, con información detallada [28].
Link Evaluator: Se integra a la interfaz del navegador. Se procesa sólo la página actual y no
realiza un análisis en profundidad, resaltando en distintos colores el estado de los enlaces [29].
3.3.4.2. HERRAMIENTAS DE FUNCIONALIDAD
Selenium IDE: “SeleniumHQ”, menciona que es una extensión para el navegador Web Firefox
entre otros. Permite grabar clicks, tipeo y otras acciones para realizar test. Estos scripts grabados,
luego pueden ser exportados en distintos lenguajes (PHP, JAVA, Ruby, C, etc.) para su posterior
adaptación y utilización [30].
HTTPUnit: “Russell Gold”, menciona que la herramienta se basa en la metodología Extreme

Programming. Se pueden realizar pruebas funcionales antes de que estén generadas las páginas
Web. No se basa en los controles que tenga la página, si no que se basa en los valores de entrada
que el usuario pueda ingresar [24], [31].
Badboy: Permite grabar y luego reproducir las acciones realizadas por los usuarios, luego este
script puede ser utilizado en otras herramientas, como ser JMeter. Se puede integrar al navegador
Web Internet Explorer [32].
SAHI: “SAHI”, menciona que la herramienta permite grabar y luego reproducir script. Tiene
soporte funciones realizadas en lenguaje JavaScript [33].

Automated Test AtYourSide Herramienta para crear test cases basándose en los
Designer Colsulting requerimientos funcionales la cual puede ser usada en un
ambiente colaborativo por todos los miembros del proyecto.
Ayuda gestionar cambios y requerimientos de cualquier tipo de
complejidad. Usa un algoritmo de una red neural optimizada para
generar el mínimo número de casos de pruebas para certificar el
100% de los requerimientos.
Auto Tester One Auto Tester Software para realizar pruebas funcionales de regresión y de
integración en Windows, Cliente-Servidor y Web. También
30
ofrece una versión mejorada para SAP, con un motor para
realizar pruebas de carga y de estrés.
GUITAR University of Herramienta libre que genera nuevos test cases basándose en
Maryland una tecnología que usa gráficos de flujo de eventos. El pre y
post-condiciones se usan para generar la respuesta esperada.
HoloDeck Security Simula el mundo real y los errores de una aplicación. Permite a
Innovations los testers y desarrolladores trabajar y depurar código en
ambientes complejos.
MITS.GUI Tiene una máquina de estados que toma decisiones en tiempo
real para navegar a través de una porción de GUI de una
aplicación sin Scripts. Los testers simplemente entran los datos
en una hoja de cálculo, y estos se usan para poblar los datos en
una hoja de cálculo, y estos se usan para poblar los objetos que
aparezcan en un escenario particular definido.
QACenter Compuware Herramienta para el desarrollo y ejecución de pruebas de GUI y
basadas en arquitectura cliente – servidor.
SAP Software Sucid El proveedor de herramientas y productos para aseguramiento
Quality de la calidad del software.
Assurance
Testing Tools
ScriptTech TMX Genera scripts ejecutables par WinRunner, TestPartner, SilkTest
y otras herramientas sin necesidad de entender el lenguaje de
programación.
Smalltalk Test SilverMark, Inc. Hermanitas de pruebas GUI y de objetivos para IBM.
Mentor
Squish Froglogic Framework para aplicaciones en C++. Permite hacer pruebas a
las aplicaciones usando scripts grabados o creados
manualmente en diferentes lenguajes.
TestArchitect LogiGear Framework para automatización que soporta la mayoría de las
plataformas existentes.
TestWorks Software Suite que integra Pruebas de Regresión Automatizadas y
Research Análisis de Cobertura para UNIX, Windows/2000/NT/XP con
múltiples reportes y scripts reutilizables en C, C++ y Java.
Unified Test Pro Software Una solución de “3ra generación” para pruebas de
Debelopment automatización que usa un enfoque basado en roles para el
Technologies diseño, construcción y ejecución de casos de pruebas.
WinRunner ® Mercury Graba y reproduce pruebas de GUI para aplicaciones Windows.
31
X-Unity MIIK Ltd Ambiente de pruebas unitarias para el Framework de Microsoft
.NET.
Astra Mercury Web site para testing funcional.
QuickTestTM
Auto Tester One Auto Tester Sirve para realizar pruebas funcionales de regresión e
integración de aplicaciones Windows, Cliente-Servidor o Web.
PerterCat PesterCat Herramienta de pruebas Web diseñado para realizar pruebas
funcionales sobre aplicaciones Web. Permite grabar scripts
usando cualquier navegador. Funciona en Linux, MAC, OSX y
Windows.
Ranorex Ranorex Framework de automatización para pruebas en Windows GUI y
Software C++, Python y los lenguajes .NET.
Rational Robot Rational Permite realizar pruebas funcionales de regresión y smoke test
Software en aplicaciones Web.
Selenium ThoghtWorks Herramienta de pruebas para aplicaciones Web. Se ejecuta
directamente en un navegador tal y como lo harían los usuarios
reales. Corre en Internet Explorer, Mozilla, Firefox y en Windows,
Linux y Macintosh.
TestWeb Original Software Soluciones de automatización para IBM iSeries, Microsoft y
Oracle.
QTP Mercury-HP El Quick Test Profesional es utilizado popularmente como
herramienta de automatización de pruebas de regresión.
Yawet InfoMatrix Herramienta Java para crear, ejecutar y depurar pruebas sobre
Web. Sirve para verificar HTML, PDF y XML.
Tabla 5: Herramientas para Pruebas Funcionales

HERRAMIENTAS PARA PRUEBAS DE RENDIMIENTO
Las herramientas, en este caso son útiles, por ejemplo, en las pruebas que necesitan tener
concurrencia de usuarios al servidor a probar. Algunas de ellas son:
JMeter: “THE APACHE SOFTWARE FUNDATION”, menciona que es utilizada para realizar
pruebas de rendimiento, de stress, de carga y de volumen, sobre recursos estáticos o dinámicos
[34]
(Servlets, scripts Perl, Objetos Java, BB.DD., Servidores de FTP).
OpenSTA: “OpeenSTA User Home”, expresa de la herramienta que se pueden crear script con
peticiones HTTP y HTTPS, para realizar pruebas de rendimiento. Permite captar las peticiones
32
del usuario generadas en un navegador Web, luego guardarlas, y poder editar para su posterior
uso [35].
Grinder: Es un framework escrito en Java, con el cual se pueden realizar pruebas de rendimiento,
[37]
a través de script escritos en lenguaje Jython . Permite grabar las peticiones del cliente sobre
un navegador Web para ser luego reproducido [36].
HERRAMIENTAS PARA PRUEBAS DE DESEMPEÑO
BugTimer BugStomper Aplicación que graba, muestra, guarda, ordena e imprime los
Software resultados de las pruebas de desempeño.
DB Stress DTM Aplicación para hacer pruebas de estrés sobre aplicaciones y
DBMSs.
IxLoad Ixia Herramientas para ejecutar pruebas de carga en clientes, servidores
y web.
SilkPerformer Segue Aplicación para ejecutar pruebas de desempeño que puede emular
millones de usuarios. Emula protocolos por HTTP, SSL, FTP, SMTP,
POP3, Streaming/VolP, IPSEC, PPPoX, entre otros.
ANTS Red Gate Para realizar pruebas de carga y escalabilidad en servicios Web de
.NET y en aplicaciones.
LoadTracer Trace Herramientas para pruebas de carga desempeño, estrés y
Technologies escalabilidad de aplicaciones Web. Simula múltiples instancias de
un cliente Web entrando aun servidor Web y es compatible con
internet Explorer y Netscape.
Microsoft Microsoft Diseñada para realizar pruebas de estrés en servicios Web y
Application analizar el desempeño de la aplicación, incluyendo páginas en ASP
Center Test y sus componentes. Soporta diferentes esquemas de autenticación
y el protocolo SSL, muy útil en pruebas de sitios seguros.
NeoLoad Neotys Simula cientos de usuarios virtuales en el sitio Web obteniendo
estadísticas de desempeño y resolviendo los errores que surgen de
las pruebas.
OpenSTA OpenSTA Software Open source para generar cargar realmente pesadas para
simular la actividad de miles de usuarios virtuales.
Proxy Sniffer Ing. Fischer Herramientas de pruebas de carga y estrés que permite analizar las
características de desempeño y la estabilidad de una aplicación bajo
diferentes condiciones de carga.
Siege Joe Dog Herramientas open source para pruebas en sistemas UNIX.
33
TestMaker PushToTest Framework open source para construir agentes de pruebas
inteligentes para probar servicios web (HTTP, HTTPS, SSL, Servlet,
JSP, EJB, ActiveX, SOAP, .NET). Creado en Java se puede ejecutar
en cualquier sistema que permita Java, incluyendo Windows, Linux,
Solaris, Macintosh y más.
Web Appliation Microsoft Herramienta que simula múltiples pedidos de diferentes páginas de
Stress Tool diferentes browsers.
Webload Radview Herramientas para hacer pruebas de desempeño en aplicaciones en
Software internet e intranet
Web Web Para realizar pruebas de desempeño Web en Windows y UNIX.
Performance Performance
Trainer
Web Server Paessler Aplicación para pruebas de carga en servicios Web.
Stress Tool
Load Gold ApTest Combina herramientas Open source con consultoría por parte de
expertos y transferencia de tecnología al equipo.
SiteStress WebMetrics Un completo servicio para generar transacciones que soporten
HTTP que crecen de cientos a miles.
WebStress Moniforce Servicio para realizar desempeño Web y pruebas de estrés.
Tabla 6: Herramientas para Pruebas de Desempeño

HERRAMIENTAS PARA PRUEBAS EN BASES DE DATOS
AETG Telcordia Sus algoritmos usas técnicas de diseño combinatorio para crear
sets de prueba mínimos que cubren todas las interacciones
entre los datos de entrada.
Data Generator DTM Sirve para generar datos, tablas (vistas, procedimientos, etc.)
para pruebas de base de datos.
Datatect Banner Sftware Genera datos de pruebas a archivos ASCII o directamente en
el RDBMS (sirve para Oracle, Sybase, SQL Server e Informix).
Jenny Herramienta gratuita similar a AETG y a ALLPAIRS. JENNY
indica la cantidad de test cases que se deben generar para
probar todas las características de la aplicación.
Jumpstart Talking Frog Herramienta de generación de base de datos para SQL Server.
Testlt TdgTeam Genera gran cantidad de datos de pruebas aleatorios, como

nombres, empresas, direcciones, ciudades, IDs, etc.
34
TurboData Canam Generador gratuito de datos de prueba bastante reales con las
Software foreing key resueltas. También genera los Select, Update, y
Delete en SQL.
utPLSQL Herramienta open source, para pruebas unitarias en Oracle
PL/SQL.
GenerateData.com Benjamin Keen Generador on-line gratuito de hasta 200 datos. Por ejemplo,
nombres, números telefónicos, direcciones de correo
electrónico, ciudades, estados, provincias, países, fechas,
direcciones, rangos de números, cadenas alfanuméricas, textos
Lorem Ipsum y más. Guardando los datos en formato HTML,
XML, Exel o SQL.
Tabla 7: Herramientas para Pruebas en Base de Datos

HERRAMIENTAS PARA PRUEBAS DE LINKS Y HTML

AccVerify/AccRepair HiSoftware Verifica, corrige, monitorea y gestiona el sitio Web y aplicaciones
basadas en web para cumplir con la W3C y la Selección 508.
CSE THML Al Internet Aplicación para chequear link, escrita y accesibilidad en HTML,
Validator Solutions XHTML y CSS.
Cyber Spyder Link Aman Programa para la gestión de contenidos Web, usado para verificar
Test Software las URLs del sitio y para análisis del contenido.
HTML Candy Anetto Software para la preparación de páginas HTML. Es capaz de
Software arreglar gran cantidad de los problemas con la sintaxis HTML,
incluyendo etiquetas, estilos, atributos, valores y elementos
obsoletos.
HTML PowerTools Talicom Suite de windows para revisión de HTML.
LinkSleuth Xenu Herramienta gratuita para detectar links rotos.
Tabla 8: Herramientas para Pruebas de Links y HTML

35
HERRAMIENTAS PARA PRUEBAS DE SERVICIOS HTML

Web Desing Group Herramienta gratuita on-line para revisar hojas de estilos.
CSSCheck
WDG Servicio on-line gratuito que sirve para validar documentos
HTML Validator
HTML.
HTML Vaidation W3C Servicio on-line que revisa documentos HTML para asegurar
Service que cumplen con las normas W3C HTML y XHTML.
LinkAlarm Servicio on-line para detectar links rotos.
Link Alarm
Monte Sano Servicio que ayuda a encontrar links rotos, etiquetas
NetMechanic
Software incorrectas y tiempos de respuestas del servidor.
Delorie Software Utilidad on-line que mapea una página a los estándares
Web Page Purifier
HTML 2.0, HTML 3.2, HTML 4.0, o WebTV 1,1.
Scholarly Aplicación que valida documentos XML.
XML Validation
Technology Group
Tabla 9: Herramientas para Servicios de HTML

HERRAMIENTAS PARA PRUEBAS DE SEGURIDAD
QA Inspect SPI Dynamics Incorpora pruebas de seguridad Web automatizadas en el proceso de
administración de pruebas en general. Los usuarios de Mercury pueden
gestionar tanto las pruebas funcionales como las pruebas de seguridad
desde una única plataforma.
Tabla 10: Herramientas para Pruebas de Seguridad

HERRAMIENTAS PARA CONTROL DE DEFECTOS

AceProject Websystems Software para el control de defectos, diseñado para gerentes de
proyectos y desarrolladores.
ADT Web Brodderwave Herramientas de control de defectos diseñada para compañías de
software pequeñas medianas y grandes. Permite hacer
seguimiento a los defectos y sugerencias por versión, por cliente,
etc.
36
BugAware.com Bugaware Solución para control de defectos que incluye notificación por
Email, base de conocimientos, reportes dinámicos, gestión del
equipo, hilos de distribución entre los usuarios, etc.
BugHost Active-X.COM BugHost es un sistema de control de defectos ideal para
compañas pequeñas y medianas que quieren usar un sistema
seguro y basado en Web.
BugRoster Codeca Corp Sistema multiusuario para el control de defectos de reportes.
Bug Tracker CrimsonLink Herramienta Web para el control de defectos, ayudando a

procesos de gestión de los mismos.
Bugvisor Softwarequality, Aplicación parametrizable para capturar, gestionar y comunicar
Inc. peticiones de cambios, reportar defectos y gestionar todo el flujo
de traba del proyecto.
Bugzilla Bugzilla.org Sistema open source para el control de los defectos desarrollado
por Mozilla.
Census MetaQuest Herramienta parametrizable para el control y monitoreo de
bugTrach defectos. Incluye integración con VSS, notificaciones, flujo de
trabajo, reportes e historial de cambios.
JIRA Atassian Herramienta para el control de defectos y gestión de proyectos
basada en J2EEE.
Jitterbug Samba Herramienta libre para el control de defectos.
Mantis Sistema open source liviano y simple, fácilmente modificable,

parametrizable y actualizable.
Tabla 11: Herramientas para Control de Defectos

HERRAMIENTAS PARA LA GESTIÓN DE LAS PRUEBAS
ApTest Manager ApTest Repositorio basado en Web, permite realizar la ejecución, la

generación de reportes, pruebas de regresión, control de acceso,
cronograma, reportes técnicos y para la gerencia, asignación de
pruebas a los testers y gestión de defectos.
QADirector Compuware Gestión de proceso de pruebas.
T-Plan T-Plan, Limited Herramienta para gestionar el proceso de pruebas.

Professional
TestDirector Mercury Sistema para la gestión de las pruebas.
37
HP Quality HP Gestiona y controla los procesos de calidad y automatiza las
Center pruebas de software en el entorno de las aplicaciones y TI.
SilkPlan Pro Seque Software Sistema para gestión de la calidad que permite la gestión de las
pruebas y un framework de colaboración diseñado para
aplicaciones de gran tamaño.
Tabla 12: Herramientas para la Gestión de las Pruebas

HERRAMIENTAS PARA PRUEBAS DE COMUNICACIONES
Proyecto Proveedor descripción

Chariot netlQ Herramienta para hacer pruebas en redes.
Cheetah Tollgrade Esta herramienta permite probar y monitorear el desempeño de
aplicaciones sobre VolP y VolD.
Emulation Comunication Ejecuta pruebas sofisticadas de desempeño, capacidad, escalabilidad y
Engine XT Machiney estrés de productos 802.11 y arquitectura wireless LAN.
Corporarion
Fault Factory ExtraData Permite reproducir errores relacionados con sockets o con fallas de
HTTP/SOAP.
iSoftTechTAS iSoftTech Ayuda a automatizar pruebas en redes.
LANTraffic Omnicor Permite generar automáticamente tráfico TCP, UDP, parametrizando la
carga.
NuStreams Omnicor Permite la realización de pruebas de LAN, WAN, en redes, switches,
2000 routers e IPs. Prueba, mide y certifica las redes y dispositivos.
Silvercreek Interworking Verifica le cumplimento de estándares, manejo de errores y excepciones,
SNMP Test Labs, Inc. condiciones límite y desempeño con cargas pesadas en la red
Suite
WAN Emulator Itheon Permite recrear redes con ambientes segmentados, por ejemplo, WAN,
WLAN, entre otros. Para probar aplicaciones incluyendo VolP, en fase de
desarrollo, de pruebas o antes del despliegue.
Tabla 13: Herramienta para Pruebas de Comunicaciones

38
HERRAMIENTAS PARA GESTIÓN DE REQUISITOS
Producto
Proveedor Descripción
Analyst Pro Goda Potente herramienta para gestión de requisitos, que incluye la
Software posibilidad de crear y modificar especificaciones y diagramas.
Caliber Borland Ayuda a los equipos a hacer seguimiento de cada etapa de proyecto
con bastante precisión. Tiene una interfaz intuitiva y soporta el proceso
de toma de decisiones.
RequisitePro IBM Herramienta de gestión de requisitos y casos de uso para equipos que
quieran mejorar la comunicación de las metas del proyecto, mejorar el
desarrollo colaborativo, reducir los riesgos del proyecto e incrementar
la calidad de las aplicaciones antes de ser puestas en producción.
SteelTrace SteelTrace Herramienta de captura de requisitos que permite a todos los
involucrados en el negocio trabajar colaborativamente para entender,
definir, comunicar y gestionar los requisitos del software.
Tabla 14: Herramientas para Gestión de Requisitos

OTRAS HERRAMIENTAS
Aprobe OC Systems Herramienta para depurar lo que recolecta y analiza datos

instrumentando el archivo ejecutable.
Bug Shot BugStomper Programa de captura de pantalla diseñado específicamente para
Software testers de software. Facilita el proceso de captura de imágenes de la
pantalla como parte del proceso de reporte de errores porque sirve para
capturar, guardar, editar, comentar e imprimir capturas de pantalla.
Exchange Aegis Simula pruebas entre diferentes fases de diferentes protocolos.
Simulator Software
Inspec ISM Sirve para gestionar el proceso de revisión y walkthrough en código
fuente.
KaNest KaSYS Software para hacer pruebas transaccionales y de comunicaciones
entre dos sistemas a nivel de aplicación.
LogStomper BugStomper Ayuda a automatización el proceso de revisión de logs.
Software
TestBench400 Original Automatización de pruebas en AS/400
Software
Tabla 15: Otras Herramientas

39
3.4. VENTAJAS Y DESVENTAJAS DE LAS HERRAMIENTAS
Las herramientas antes mencionadas, fueron analizadas y las siguientes tablas resumen las
características más destacadas de cada una de ellas. Esto permite contar con una guía que
permitirá evaluar su utilización dependiendo de la finalidad en la cual se van a utilizar.
HERRAMIENTAS PARA PRUEBAS DE ACEPTACION
Herramienta UI Licencia Plataforma Lenguaje Documentación
FitNesse WEB CPL Windows/ Java, C#, PHP, Guia de Usuario

Linux Ruby, .NET,
Delphi, Python.
Avignon GUI GPL Windows/ Java, .NET. Sin datos
Linux
Tabla 16: Comparación entre Herramientas de Aceptación

Fuente: Facultad de Informática Universidad de La Plata Buenos Aires, Argentina.
Las herramientas para pruebas de aceptación mencionadas en la tabla 16, considerando que son
herramientas open source favorece en su aprendizaje fácilmente sin necesidad de permisos o
adquisición para su manipulación, la herramienta Avignon tiene la manipulación de lenguajes
mínimos y definidos en la tabla, no se encuentra demasiada información de aplicaciones en
software de automatización, en comparación con FitNesse, tal herramienta tiene casi toda la
manipulación de lenguajes, tiene una dependencia de Maven Classpath, Ivy Classpath, Gradle
Classpath, tiene accesorios de aplicaciones web como Xebio (driver para selenium-IDE con
soporte de ida y vuelta), SeleNesse (criver para selenium), Azufre(driver para selenium, soporte
para todos los selectores de selenium).
VENTAJAS DESVENTAJAS
FitNesse Avignon FitNesse Avignon
Compara las Permite escribir pruebas No tiene guía de usuario
expectativas de los ejecutables en el o ayuda para la
clientes a los resultados lenguaje elegido. manipulación de la
reales herramienta.
Código abierto Código abierto. Los lenguajes
manipulables son java y
.NET
Es adaptable para todos Es adaptable con todos
los idiomas. los idiomas.
40
Cuando el proyecto está
escrito en Java, Python
o C#, se puede conectar
y puede automatizar el
proceso de prueba.
Tabla 17: Ventajas y Desventajas de Herramientas de Pruebas de Aceptación

Fuente: realizado por mi persona (ISTQB)
HERRAMIENTAS PARA PRUEBAS ESTÁTICAS DE CÓDIGO
Herramienta UI Licencia Plataforma Lenguaje Documentación
PHPLint GUI BSD Windows/ PHP 5, PHP7 Tutorial / Manual

Linux
RATS CLI GPL Windows/ C++, Perl, PHP y Sin datos
Linux Python
YASCA CLI GPL Windows/ Java, .NET, PHP, Manual
Linux HTML, CSS, etc.
PMD CLI BSD Windows/ Java Tutorial / Manual
Linux
FindBugs GUI/ GPL Windows/ Java Tutorial / Manual
CLI Linux
Tabla 18: Comparación entre Herramientas para Pruebas Estáticas de Código

La herramienta PHPLint; enfocado en lenguaje PHP, ejecuta las pruebas unitarias, detecta
variables no validas, código muerto, errores de sintaxis brindando seguridad en el código, en
comparación RATS; esta herramienta se aplica para software industrial, tiene más lenguajes con
los que pude trabajar para la identificación de errores de la funcionalidad en procesos de
ejecución y rendimiento del software y no existe un manual específico para su aprendizaje, en
comparación con YASCA encuentra errores en el código, tiene una manipulación más amplia en
cuanto a lenguajes de programación, comparando con PMD y FindBugs estos usan lenguaje java,
la diferencia entre tales herramientas es que unas funcionan con diversos lenguajes y otras son
para lenguajes específicos.
41
PHPLint RATS YASCA PMD FindBugs
Código abierto. Código Código abierto. Código abierto. Código

abierto. abierto.
Tiene tutorial Orientada al análisis de Analizador de
explicito para su Detecta fallas vulnerabilidad de código fuente. Licencia GNU.
aplicación. triviales en el seguridad y la calidad Con marcas
código fuente. del código fuente. registradas de
Disponible para
The University
todos los sistemas Auto detecta Permite la integración
of Maryland.
operativos. el tipo de con otras herramientas
lenguaje de de análisis de código
Convierte un
VENTAJAS
programación (findbugs, pmd, junit,

lenguaje poco tipado
del código phplint, RATS entre
como PHP en un
fuente. otros.)
lenguaje
fuertemente tipado.
Usa un lenguaje Tiene soporte Analiza código en los Es compatible Encuentra

especifico PHP. de 5 lenguajes Java, C/C++, con Java, errores en
lenguajes de HTML, JavaScript, ASP, JavaScript, código java.
LIMITACOINES
programación, ColdFusion, PHP, Salesforce.com

C, Perl, Ruby, COBOL, CSS, Visual Apex y
Python y php. Basic y .NET. Visualforce,
PLSQL, Apache
Velocity, XML,
XSL.
Tabla 19:Ventajas y Desventajas de herramientas para Pruebas Estáticas de código

HERRAMIENTAS PARA PRUEBAS UNITARIAS
Herramienta UI Licencia Integración Lenguaje Documentación
JUnit integrada CPL Eclipse Java CoockBook/Foro/FAQ

Netbeans
IntelliJ
PHPUnit CLI PHP No Aplica PHP Manual
SimpleTest CLI LGPL Eclipse PHP Tutorial/How to

IntelliJ
Tabla 20: Comparación entre Herramientas de Pruebas Unitarias

Herramientas con fácil manipulación de diversos lenguajes de progrmacion, se podría mencionar

que PHPUnit solo funciona con PHP y tampoco se puede hacer integración en cambio con
SimpleTest existen mayor manipulación de integración puesto que hoy en dia trabaja en el núcleo
de desde el inicio de desarrollo de desarrollo de Drupal 7.
42
JUnit PHPUnit SimpleTet
Se ejecutan datos de entrada (casos Tiene una extensión
Codigo abierto.
de prueba) para verificar que el eclipse para PHP 5.1
funcionamiento cumple los Tiene tutorial explicito para su (también conocido como
requisitos esperados. aplicación. antiguo).
Disponible para todos los
Posee la herramienta XUnit que sistemas operativos.
domina las pruebas unitarias para
diferentes lenguajes.
Convierte un lenguaje poco tipado
como PHP en un lenguaje
Sirve para realizar pruebas de fuertemente tipado.
regresión.
Funciona bien con todos los
VENTAJAS
servidores de integración
continua.
Se integra con otras herramientas

de desarrollo de PHP.
No permite identificar errores de No funciona con todos
Usa un lenguaje especifico PHP.
integración ni errores de desempeño los servidores de
DESVENTAJAS
del sistema de Software. integración continua.
Usa un lenguaje
especifico PHP.
Tabla 21: Ventajas y Desventajas de Herramientas para Pruebas Unitarias

Fuente: realizado por mi persona (ISBTQ)
HERRAMIENTAS PARA PRUEBAS FUNCIONALES-FUNCIONALIDAD
Herramienta UI Licencia Plataforma Documentación
Selenium GUI Apache Varios Tutorial /

Manual/Wiki
HTTPUnit WEB Propia Windows/ Manual/FAQ
Linux
Badboy WEB LGPL Windows Manual/Foro
Sahi GUI Apache Windows/ Manual/FAQ

Linux
Tabla 22: Comparación de Herramientas para Pruebas Funcionales-Funcionalidad

La herramienta Selenium permite probar y reproducir pruebas, considerando la manipulación de

diferentes plataformas y diferentes navegadores mediante webDriver, comparado con HTTUnit
basado en metodología XP, se enfoca en valores de entrada por el usuario, en comparación con
BadBoy el resultado de las pruebas que genera la herramienta, se puede utilizar en JMeter, se
puede integrar a Internet Explorer, no tiene mucha aceptación para su aplicación y por ultimo
43
SAHI tiene las mismas funcionalidades que los demás pero presenta problemas en su
implementación.
Selenium HTTPUnit Badboy Sahi
Conjunto de Código abierto. Diseñada para ayudar Soporta por defecto pas
herramientas con en la prueba y el aplicaciones web y la
enfoques diferentes Adaptado para ser desarrollo de automatización de API
para admitir la utilizado en aplicaciones REST.
automatización de combinación con dinámicas complejas.
pruebas. JUnit. Realiza pruebas entre
El usuario graba navegadores/navegadores
Tiene soporte para Ayuda en las pruebas fácilmente scripts de web 2.0 complejas con
ejecutas las pruebas de regresión. grado profesional y gran cantidad de AJAX y
en múltiples enviarlos contenido dinámico.
plataformas. directamente a
WatchMouse para Agrega soporte para
que se ejecuten como aplicaciones de escritorio
scripts supervisados de Windows(Win32, WPF,
en más de 25 WinForms, .NET,
estándares.
VENTAJAS
SilverLight, XBAP,
Universal Windows
platform, UWP)
Debido a su motor de La herramienta Se ejecuta en cualquier

automatización HTTPUunit es estable navegador moderno que
basado en JavaScript en sus respectivas ejecute javascript.
y las limitaciones de versiones, pero no se
seguridad que los les hace un
DESVENTAJAS
Desde v7.5.0 se desea

navegadores aplican seguimiento tan automatizar solo las
a JavaScript, es escrito y formal y aplicaciones de escritorio
imposible hacer generalmente solo (no las aplicaciones Web)
diferentes cosas. esta disponibles por por ahora se compra la
un tiempo relevante licencia de escritorio por
corto. separado.
Tabla 23: Ventajas y Desventajas de Herramientas para Pruebas Funcionales-Funcionalidad

4. DISEÑO DE LAS PRUEBAS (TESTING)
4.1. MEJORES PRÁCTICAS Y ENFOQUE DE DISEÑO
Con el fin de garantizar el éxito en los proyectos de automatización de pruebas, el ISTQB

(International Software Testing Qualifications Board) ha propuesto una serie de buenas prácticas
en el marco de la certificación en Automatización de Pruebas. Dichas prácticas son enfocadas
como criterios de éxito, además de una lista de lo que se debe y no se debe hacer en este tipo
de proyectos.
44
Como buenas prácticas se propone tener establecida una Arquitectura de Automatización de
Pruebas (TAA - Test Automation Architecture), teniendo en cuenta que la automatización de
pruebas es un proyecto de Software, y debe ser tratado como tal.
El SUT (Software Under Test) debe ser desarrollado para soportar pruebas automáticas, en
dónde el SUT debe desacoplar la interacción con la interfaz gráfica de los datos y su apariencia
visual. Esto se puede traducir en la creación de mecanismos para identificar de manera única
cada elemento visual presente en el Software Under Test.
LOS CINCO PRINCIPIOS BÁSICOS DE PROGRAMACIÓN ORIENTADA A OBJETOS
Los 5 principios básicos de la programación orientada a objetos son esenciales para construir
software que permitirá implementar una estrategia y se pueda conseguir software que funciona.
El principio SOLID cuando es aplicado, es capaz de escribir un código de mayor calidad, el

sistema creado es fácil de mantener, reusar, y extender en el tiempo.
El principio SOLID ayuda a los desarrolladores de software a conseguir escalabilidad y evitar que
el código se rompa cada vez que aparece un cambio [43].
4.1.1.1. S (SRP) PRINCIPIO DE RESPONSABILIDAD ÚNICA:
“Nunca debería haber más de una razón en una clase para cambiar”
Este principio dice que el módulo (clase) debería tener una sola razón para ser modificado.
Ejemplo: la clase Mensajero, de la figura 6, tiene dos responsabilidades: enviar correos y enviar
mensajes de texto.
Figura 6: Diagrama "Mensajero"

Fuente: Software Architect Oscar Blancarte Iturralde
45
Esta clase podría cambiar por varias razones:
• El mecanismo para enviar correos es diferente. Por ejemplo, antes se usaba un servidor
SMTP y ahora se requiere usar un API.
• Cambios en la plataforma de mensajes de texto.
• Aparición de una nueva forma de enviar mensajes.
Se puede ver 3 razones diferentes por las cuales la clase podría cambiar. Esto puede traer
problemas de mantenibilidad. De ahí la importancia de respetar este principio.
En el ejemplo anterior, se podría utilizar distintos patrones de diseño para resolver el problema.
En este caso en particular, se tiene que separar cada una de las formas de mandar mensajes en
clases diferentes, y luego, mediante un patrón de fachada podrá facilitar el consumo de cada una
de las funcionalidades.
Luego de los cambios, el diagrama de clases se vería así:
Figura 7: Diagrama "Mensajero (SRP)"

Fuente: Software Architect Oscar Blancate Iturralde
Así, cada clase tendría una única razón para cambiar. Por ejemplo, si en algún momento cambia
la plataforma de mensajes de texto, tendría que modificarse la clase EnvioSMS. Si en algún
momento se puede enviar correos con un servidor SMTP a un API de un tercero, solo impactara
la clase EnvioCorreo.
De esta forma, se cumple el principio de única responsabilidad.
46
4.1.1.2. O (OCP) PRINCIPIO DE ABIERTO/CERRADO:
“Entidades de Software (clases, módulos, funciones, entre otros.) han de estar abiertas para
extensiones, pero cerradas para modificaciones”
Este segundo principio dice que nuestro sistema debería estar cerrado a modificaciones, y abierto
a extensiones.
En pocas palabras: si se quiere añadir nuevo código, lo ideal sería poder construir sobre lo que
ya existe, sin tener que hacer modificaciones grandes.
Ejemplo: al enviar mensajes usando el chat corporativo de la empresa. Tal como quedó el refactor
del ejemplo anterior, serían necesarios los siguientes cambios:
• Crear una nueva clase llamada EnvioChat.
• Agregar un nuevo método en la clase Mensajero para enviar mensajes por chat.
• Crear una instancia de EnvioChat en la clase Mensajero.
Los cambios se verían así:
Figura 8: Diagrama "Mensajero (OCP)"

Esto no sería lo óptimo. Cada vez que se añade una nueva forma de envío, sería necesario
modificar la clase Mensajero. Además, habría que cambiar todos los lugares donde se llamen los
métodos de Mensajero para que tengan en cuenta la nueva forma de enviar mensajes.
Este es un ejemplo donde no estamos respetando el principio de abierto cerrado.
¿Cómo lo podemos mejorar?
47
Añadiendo mayor flexibilidad.
Flexibilidad que permita añadir nuevos mecanismos de forma fácil, sin tener que modificar lo que
ya funciona. Nuevamente, vienen los patrones al rescate.
Lo primero que se puede hacer es crear una interfaz que permita definir el comportamiento de
cualquier clase que sea capaz de enviar un mensaje. Luego, poner a cada una de las clases
especializadas en envíos a que la implementen.
Figura 9:Diagrama "Mensajero (interfaz)"

(Una nueva clase, Mensaje, que sirve para unificar los parámetros que recibe el método enviar).
Es algo muy similar al patrón adaptador, esto se ve en la figura 9. Cada clase está especializada
en conectarse con una forma diferente de enviar mensajes.
Se necesita quitar el conocimiento a la clase Mensajero de las distintas clases que envían
mensajes. Para esto, se implementa una fábrica.
48
Figura 10: Diagrama "Fábrica"
Teniendo la fábrica, la clase Mensajero ya no necesita métodos específicos por cada método de
envío. Solo necesita pedirle a la fábrica un objeto de tipo EnvioMensaje, e invocar sobre este el
método enviar.
4.1.1.3. L (LSP) – PRINCIPIO DE SUSTITUCIÓN DE LISKOV:
“Subtypes deben ser sustituidos por su tipo de base”

Este principio habla específicamente de la herencia. En pocas palabras, dice que siempre debe
poder reemplazar instancias de una clase padre por instancias de una clase hija, sin que haya
comportamientos no deseados.
Visto de otra manera, las clases hijas no deberían modificar o eliminar los comportamientos
definidos en el padre.
A diferencia de los principios anteriores, no hay algún patrón de diseño específico por aplicar
aquí. Sin embargo, tener a la mano patrones de diseño relacionados con la herencia pueden ser
muy útiles. Algunos ejemplos:
• Método plantilla.
• Composite.
• Estrategia.
• Estado.
49
4.1.1.4. I (ISP) PRINCIPIO DE SEGREGACIÓN DE LA INTERFAZ:
“Clases implementan interfaces, no deberían ser forzadas a implementar los métodos no

utilizados”
Se debe tener cuidado con definir interfaces con muchos métodos. De acuerdo con este
principio, es mejor tener interfaces pequeñas, con pocos métodos muy relacionados (alta
cohesión), en lugar de tener interfaces voluminosas que obligan a definir muchos métodos a quien
las implementa.
Aquí el principio de única responsabilidad resulta muy útil, para separar la interfaz de la mejor
manera.
Algunos patrones, especialmente los de comportamiento, pueden ser muy convenientes:
• Estrategia.
• Estado.
• Cadena de responsabilidad.
4.1.1.5. D (DIP) PRINCIPIO DE INVERSIÓN DE LA DEPENDENCIA:
“Módulos de altos modelos no deberían depender de niveles de módulos bajos, sino de

abstracciones. Abstracciones no deberían depender de detalles; sino los detalles de la
abstracción”
Este principio tiene dos ideas importantes:
• Los módulos de alto nivel no deberían depender de módulos de bajo nivel, sino de
abstracciones.
• Las abstracciones no deberían depender de los detalles. Los detalles deberían depender
de las abstracciones.
Una forma de lograr esto, es empleando la inyección de dependencias (un tipo de inversión de
control). Si bien no es uno de los patrones de diseño orientado a objetos, es una forma muy útil
de garantizar la dependencia con abstracciones.
En general todos los patrones que ayuden a abstraer nuestros módulos son útiles para lograr
este principio. En particular, es relevante mencionar:
• Fachada.
• Fábrica abstracta y método fabrica.
• Adaptador.
50
4.2. PATRONES DE DISEÑO DE SOFTWARE
Los patrones de diseño de software son formas “estandarizadas” de resolver problemas comunes
de diseño en el desarrollo de software amplio.
SINGLETON
Singleton es el más sencillo de los patrones que se presentan en el catálogo del GoF (disponible
en el libro Patrones de Diseño (GoF 95) y analizado previamente en "Patrones y Antipatrones:
una introducción" [Welicki05]). Es también uno de los patrones más conocidos y utilizados. Su
propósito es asegurar que sólo exista una instancia de una clase.
El patrón singleton garantiza que una clase solo tenga una instancia y proporciona un punto de
acceso global a esta instancia.
A continuación, se muestra una versión reducida de la pantalla de este patrón.
Figura 11: Diagrama OMT de Singleton

Fuente: libro del GoF.
Implementación:
Siempre que se crea un objeto nuevo (en Java, con la palabra reservada new) se invoca al
constructor del objeto para que cree una instancia. Por lo general, los constructores son públicos.
El Singleton lo que hace es convertir el constructor en privado, de manera que nadie lo pueda
instanciar.
Si el constructor es privado, ¿cómo se instancia el objeto? Pues a través de un método público y

estático de la clase. En este método se revisa si el objeto ha sido instanciado antes. Si no ha sido
instanciado, llama al constructor y guarda el objeto creado en una variable estática del objeto. Si
el objeto ya fue instanciado anteriormente, lo que hace este método es devolver la referencia al
estado creado anteriormente.
51
Hay que tener especial cuidado cuando el Singleton se utiliza en un ambiente multihilos, porque
puede crear problemas si no se implementa de la manera adecuada. En Java es posible que se
realice una "inicialización bajo demanda" para evitar problemas en este sentido. Concluyendo, la
idea central del Singleton es esa: asegurar de que exista tan solo una instancia del objeto en toda
la aplicación. Es un patrón muy aplicado en Java, aunque, como todos los patrones, se puede
implementar en cualquier lenguaje orientado a objetos.
Para realizar una buena implementación del patrón Singleton se recomienda:
• Ocultar el constructor de la clase Singleton, para que los clientes no puedan crear
instancias.
• Declarar en la clase Singleton una variable miembro privada que contenga la referencia a
la instancia única que se quiera gestionar.
• Proveer en la clase Singleton una función o propiedad que brinde acceso a la única
instancia gestionada por el Singleton. Los clientes acceden a la instancia a través de esta
función o propiedad.
Estas reglas se cumplen en todas las implementaciones del Singleton, independientemente de

los recaudos que deban tomarse para soportar la correcta ejecución en entornos multihilo.
Acceso controlado a la única instancia: encapsula Suele convertirse en un anti-patron, Ej. cuando se
su única instancia, puede tener un control estricto decide en un proyecto ya avanzado que si se
sobre como y cuando acceden a ella los clientes. requieren más instancias de una clase. Esto convierte
al código en algo inflexible.
Espacio de nombres reducido: es una mejora sobre
las variables globales. Evita contaminar el espacio de Dificultad para realizar testing: Un singleton es
nombres con variables globales que almacenan las como un valor de variable global. Lo global y la
instancias. orientación a objeto no son buenos amigos ya que
introduce un “estado persistente”, es decir valores
Permite el refinamiento de operaciones y la que es mantienen siempre dificultando el uso de
representación: se puede crear una subclase de la objetivo de reemplazo(mock) en test.
clase Singleton y es fácil configurar una aplicación
con una instancia de esta clase extendida, incluso en Promociona el alto acoplamiento: Si hay algo que
tiempo de ejecución. debe ser alto en la orientación a objetos es la
cohesión y no el acoplamiento. El Singleton es
Permite un numero variable de instancias: hace instanciado directamente desde su propia clase
que sea fácil permitir más de una instancia de clase. promocionando el uso de métodos privados y
52
Solo se necesitaría cambiar la operación que otorga estáticos. Esto acopia la clase que los use además de
acceso a la instancia del Singleton. impedir el uso adecuado de inyección de
dependencias.
Restricción de ejecuciones paralelas: aunque un

objetivo del singleton sea la gestión de un recurso
compartido esto restringe operar de forma paralela a
la aplicación y lo transforma en un cuello de botella de
operaciones seriales que no es recomendable
cuando la demanda es alta.
Tabla 24: Ventajas y Desventajas del Patrón de Diseño Singleton

FACTORY
Factory Method, permite la creación de objetos de un subtipo determinado a través de una clase
Factory. Esto es especialmente útil cuando no se conoce el tiempo de diseño, el subtipo que
utilizara o cuando se delega la lógica de creación de los objetos a una clase Factory. Utilizando
este patrón se puede crear instancias dinámicamente mediante la configuración, estableciendo
cual será la implementación para utilizar en un archivo de texto, XML, properties o mediante
cualquier otra estrategia.
Figura 12: Estructura de patrón de diseño Factory Method

Los componentes que conforman el patrón son los siguientes:
53
IProduct: Representa de forma abstracta el objeto que queremos crear, mediante esta interface
se definen la estructura que tendrá el objeto creado.
ConcreteProduct: Representa una implementación concreta de la interface IProduct, la cual es

creada a través del ConcreteFactory.
AbstractFactory: Este componente puede ser opcional, sin embargo, se recomienda la creación
de un AbstractFactory que define el comportamiento por default de los ConcreteFactory.
Concrete Factory: Representa una fábrica concreta la cual es utilizada para la creación de los
ConcreteProduct, esta clase hereda el comportamiento básico del AbstractFactory.
Figura 13: Diagrama de secuencia del patrón de Diseño Fartory Method

El cliente solicita al ConcreteFactory la creación del ProductA.

El ConcreteFactory localiza la implementación concreta de ProductA y crea una nueva
instancia.
El ConcreteFactory regresa el ConcreteProductA creado.
El cliente le solicita al ConcreteFactory la creación del ProductB.
El ConcreteFactory localiza la implementación concreta del ProductB y crea una nueva
instancia.
El ConcreteFactory regresa el ConcreteProductB creado.
EJEMPLO DEL MUNDO REAL
54
Mediante la implementación del patrón de diseño Factory Method se crea una aplicación que sea
capaz de conectarse a más de una base de datos, intercambiando de una a la otra, con tan solo
realizar una simple configuración y sin una sola línea de código adicional.
Figura 14: Flujo de Ejecución del Patrón de Diseño Factory Method

Encapsula la creación de objetos, y aísla las clases Soportar nuevos tipos de productos es complejo.
concretas del cliente.
Aumenta la complejidad de la aplicación, añadiendo
Permite intercambiar familias de productos de nuevos niveles de indirección. No obstante, al tratarse
manera sencilla. de un patrón conocido es fácil abstraerse de esta
complejidad.
Elimina la necesidad de instanciar de forma explícita
los objetos que se van a utilizar, lo que tiene ventajas Al delegar funciones puede ser más complejo
claras en el desacoplamiento e interdependencia de encontrar en primera instancia la mecánica de
las clases. funcionamiento de la aplicación.
Es fácilmente extendible ya que la arquitectura queda No se puede utilizar cuando el cliente no tiene claro
abierta a desarrollos horizontales con nuevas clases que tipo de objeto de la familia necesita.
que existiendan a factory method y a la familia de
productos. El uso no es adecuado en todos los casos: es
necesaria una familia de objetos sobre la que operar.
Permite encapsular en las clases factory method toda Si no existe este polimorfismo no se tiene por que
la lógica de creación de objetos, que pueden ser más caer en la tentación de hacer factorías de objetos para
complejas que realizar que realizar un simple new.
55
Es una buena forma de disponer de una solución en el futuro. Hay que analizar bien el problema al que se
la arquitectura de la aplicación que se entiende enfrenta para ver si encaja.
fácilmente con metáforas.
Tabla 25: Ventajas y Desventajas del Patrón de Diseño Factory

4.3. AUTOMATIZACIÓN DE PRUEBAS
La automatización de pruebas puede ser definida como “el uso de software para controlar la
ejecución de pruebas, la comparación de las salidas actuales con salidas predichas, la
configuración de las precondiciones, y otras funciones de control y reportes” [44].
Las pruebas automatizadas generan como resultado scripts que a su vez generan reportes sobre
la efectividad de las pruebas ejecutadas sobre el Software Bajo Prueba (Software Under Test
SUT).
El uso de la automatización de pruebas ayuda en gran medida al personal de Calidad. Por lo

general las organizaciones asumen que cuando un software pasa a la fase de pruebas, en dicha
fase serán detectados todos los bugs posibles, lo cual en la práctica es imposible, dado la
ausencia de los recursos necesarios para hacerlo. Por tanto, con el uso de pruebas automáticas
los probadores de software podrán dedicar más tiempo a escribir más casos de prueba para cubrir
más aspectos del sistema, y delegar todo el tema de validación y evaluación a los scripts de
prueba. De igual manera, el uso de scripts de prueba mejora la calidad de las pruebas, originado
por la mínima intervención humana que requieren durante su ejecución [44].
4.4. SEGMENTANDO UN FRAMEWORK

Conceptos para tomar en cuenta.
LOCATORS/SELECTORS FIELDS MAPPING
En cualquier herramienta para cualquier aplicación siempre está el concepto de ubicar los
campos, objetos de una pantalla para el uso de acciones sobre ellos.
Un framework debería tomar en cuenta el mapeo de estos teniendo como objetivo la
mantenibilidad.
Posibles formas de mapeo:
56
4.4.1.1. PAGE OBJECT
El enfoque de diseño más popular es el Page Object, el cual se encuentra dentro de la

clasificación de orientados por palabras clave. Dicha implementación permite que las pruebas
puedan acceder a funcionalidades del SUT a través de funciones sencillas de una clase, y dichos
métodos contienen a su vez las acciones que se deben realizar sobre la interfaz gráfica para logar
el objetivo de la función/método [10].
Page Object posee ciertas ventajas y desventajas en su implementación. Dentro de sus ventajas
se encuentra que cualquier cambio en el SUT (Software Under Test) solo requerirá modificación
de la clase que implementa el diseño y no de las pruebas. Por otra parte, presenta como
desventaja que requiere de probadores de software que tengan de cierto nivel de programación,
además de que su tiempo de mantenimiento incrementa de manera lineal cuando existen más de
dos aplicaciones con un promedio de 10 – 20 páginas [10].
A pesar de sus desventajas, Page Object hoy se ha convertido en la implementación más

extendida en varios frameworks reconocidos.
Al crear un PageObject, se crea una capa de abstracción entre el “¿Qué podemos hacer / ver en
la página?”, y el “Cómo” se realiza esta acción, simplificando enormemente la creación de
nuestras pruebas y reutilizando el código con el que interactuamos con la página en concreto. Y
a la vez, cualquier cambio que se produzca en la UI únicamente afectará al PageObject en
cuestión, no a las pruebas ya implementados.
Esto se debe a que una prueba nunca debe manipular directamente elementos de la página (UI),
si no que este manejo debe realizarse a través del PageObject correspondiente que representa
la página. Para entender, el PageObject se convierte en una API con la que fácilmente se puede
encontrar y manipular los datos de la página.
Figura 15: Proceso de PageObject

57
Se puede encontrar que una página corresponda a más de un PageObject, si se da el caso de
que algunas áreas de la página son lo suficientemente significativas. Por ejemplo, en una página
web, podemos tener un PageObject para el header y otro para el body.
Detalles de la implementación:
Una de las opciones de las que disponemos es crear, en primer lugar, una clase “básica”, que
posteriormente será la que extenderán cada uno de los distintos PageObjects que vayamos
implementando. Esta PageBase aporta la estructura básica y las propiedades generales que se
utiliza:
Figura 16: Clase "Básica"

Y una vez creada esta página, crear los PageObjects necesarios. Un ejemplo de una página de
“Login” podría ser:
Figura 17: Creación de PageObject

58
Lógicamente, si es conveniente se pode saltar la creación de la PageBase, y crear directamente
los distintos PageObjects con todas las propiedades y métodos necesarios.
Como se ve en este simple ejemplo, los métodos que interactúan con la página en sí,
normalmente o bien no devolven ningún parámetro, o bien serán de tipo sencillo, como boolean,
string, etc (ej. returnErrorMessage() devuelve un String con el mensaje de error de la página de
login). Pero cuando se trata de funciones de navegación entre páginas, estas devolven un nuevo
objeto PageObject del tipo correspondiente a la página de navegación. En el ejemplo superior,
si desde la página LoginPage se ejecuta el método loginAs, se realizará el login y
consecuentemente se devolverá un objeto de HomePage, que corresponde al PageObject de la
página principal.
Como consecuencia de este enfoque, será necesario crear métodos en los que la acción a
realizar acabe con éxito (ej: loginAs, que devuelve la HomePage), y otros en los que la acción no
sea correcta (ej: loginWithError, que se mantiene en la LoginPage).
Un ejemplo práctico:
Figura 18: Pagina Ingresar Sesión

Un ejemplo real: la página de Login de la web de GMail. El ejemplo a continuación se describe

como un ejemplo de Selenium, en Java, pero sería implementable perfectamente con otros
lenguajes.
59
PageObject: El GmailLoginPage, el PageObject que modela la página podría implementarse de
la siguiente forma:
En este código se está implementando algunos de los métodos para interactuar con la página
(introducir email, password, click en SignIn), en los que se enlazan los elementos de la página de
Gmail en si misma (ej. Código driver.findElement(…)).
Tests:
Un test sencillo que simplemente ejecute un login y verifique que se accede al “Inbox”
correctamente podría implementarse de la siguiente forma:
60
En esta prueba básica, se utiliza la función de loginAs que ofrece el PageObject de la página de
Login de GMail, así como el de getTitle de la página principal del EmailPage, para validar
posteriormente que se ha realizado el acceso de forma correcta.
Tal y como se puede ver, al utilizar el patrón de PageObjects, los test que se implementan son
sencillos y a la vez intuitivos y entendibles, y una vez realizado el esfuerzo inicial de desarrollar
los distintos métodos para interactuar con el objeto, la incorporación de nuevas pruebas se puede
realizar en un tiempo razonable [45].
4.4.1.2. DATA SETS
DATA SETS se aplica especialmente para data-driven frameworks pero para cualquier framework
en general es recomendable que la data de los test scripts no quede guardada hard-coded (mala
práctica en el desarrollo de software) dentro.
La recomendación es usar algún tipo de mapeo para los datos de prueba que puede estar
alineada o no con el mapeo de objetos.
Un DataSet representa un conjunto, completo de datos, incluyendo las tablas que contienen,
ordenan y restringen los datos, así como las relaciones entre las tablas.
61
Hay varias maneras de trabajar con un DataSet, que se pueden aplicar de forma independiente
o conjuntamente. Puede realizar lo siguiente:
• Crear mediante programación una DataTable, DataRelation y una Constraint en un DataSet

y rellenar las tablas con datos.
• Llenar el DataSet con tablas de datos de un origen de datos relacional existente mediante
DataAdapter.
• Cargar y hacer persistente el contenido de DataSet mediante XML. (Usar XML en un

conjunto de datos).
También se puede transportar un DataSet fuertemente tipado mediante un servicio Web XML. El
diseño del DataSet lo convierte en idóneo para el transporte de datos mediante servicios Web
XML.
4.4.1.3. TEST SUITES
Test Suites es un contenedor que tiene un conjunto de pruebas que ayuda a los evaluadores a
ejecutar e informar el estado de ejecución de la prueba. Puede tomar cualquiera de los tres
estados: Active, Inprogress y completado.
Se puede agregar un caso de prueba a múltiples suites de prueba y planes de prueba. Después
de crear un plan de prueba, se crean suites de prueba que a su vez pueden tener cualquier
número de pruebas.
Las suites de prueba se crean en función del ciclo o en función del alcance. Puede contener
cualquier tipo de pruebas, a saber, funcionales o no funcionales.
Tomar en cuenta en un framework los grupos de pruebas que ejecutan solos y conceptualmente
agrupados es fundamental.
Tener control sobre la agrupación de pruebas para la combinación de estas para hacer
regresiones hace más eficiente el proceso de pruebas.
62
Figura 19: Proceso de Test Suite
Fuente: Wikipedia
Ejemplo: Teniendo las siguientes pruebas:
PerroTest
package ar.com.ladooscurojava.model.test;
import org.junit.Assert;
import org.junit.Test;
public class PerroTest {
@Test
public void testTrue() {
Assert.assertTrue(true);
63
PersonaTest
package ar.com.ladooscurojava.model.test;
import org.junit.Assert;
import org.junit.Test;
public class PersonaTest {
@Test
public void testTrue() {
Assert.assertTrue(true);
Ahora generar el Test Suit.
TestSuite
package ar.com.ladooscurojava.model.test.suite;
import org.junit.runner.RunWith;
import org.junit.runners.Suite;
import ar.com.ladooscurojava.model.test.PerroTest;
import ar.com.ladooscurojava.model.test.PersonaTest;
@RunWith(Suite.class)
@Suite.SuiteClasses({ PerroTest.class, PersonaTest.class})
public class TestSuite {
Hay que prestarle mucha atención al @RunWith(Suite.class) con lo cual le estamos indicando
que se compilara con la clase Suite y luego al @Suite.SuiteClasses({ PerroTest.class,
PersonaTest.class}) con lo cual le decimos que va a compilar los test de PerroTest y PersonaTest
[46]
.
64
Resultado:
Figura 20: Resultado de Test Suite

Fuente: Wikipedia
4.4.1.4. CONFIGURACIÓN DE REGRESIONES
Usando el test suites definidas, poder definir agrupaciones para configurar regresiones a medida,
de forma eficiente es un factor a tomar en cuenta.
Puntos para considerar:
- Pruebas distribuidas.
- Pruebas sincronizadas con ciclos de desarrollo.
4.4.1.5. LOGS DE EJECUCIÓN
Muchas herramientas ya tienen un output de ejecución que es legible a la hora de ver el estado
de una ejecución.
Si no lo tiene para crearlo tomar en cuenta estos puntos:
- Descripción clara del flujo de prueba
- Mapeo de acciones con resultados
- Visibilidad clara de posibles anomalías/bugs en las ejecuciones.
- Mapeo de bugs conocidos con el reporte ya realizado en la herramienta correspondiente
de bug reporting.
- Complemento con imágenes de captura en momentos del flujo cruciales y/o errores.
- Reducir ruido de información extra irrelevante
- Que el propio log de ejecución muestre métricas de la ejecución
65
MANTENIMIENTO
Finalmente tener como principio fundamental el mantenimiento es importante.
Las pruebas y las aplicaciones cambian y poder reaccionar rápidamente a esos cambios hace
que las pruebas automatizadas mantengan su vigencia.
Enfocarse en que el mantenimiento sea lo más sencillo posible reduce los tiempos de
mantenimiento y a mediano largo plazo hace que la carga de trabajo se reduzca (aunque no lo
parezca en el corto plazo).
4.5. TIPOS DE AUTOMATIZACIÓN DE FRAMEWORKS
Para diferentes tipos de proyectos puede haber diferentes tipos de automatización frameworks
que vayan a medida de estos:
DATA-DRIVEN TESTING (DDT)
La prueba dirigida por datos (DDT) es una metodología, en la que la repetición iterativa de la
misma secuencia de pasos de prueba se realiza con la ayuda de una fuente de datos para
controlar los valores de entrada de esos pasos y/o los valores esperados, mientras que los pasos
de verificación son realizados La configuración del entorno y el control en el caso de las pruebas
basadas en datos no están codificados. En otras palabras, las pruebas dirigidas por datos son la
construcción de un script de prueba para ejecutarse junto con todos sus conjuntos de datos
relacionados en un marco, que hace uso de la lógica de prueba reutilizable. Las pruebas basadas
en datos proporcionan ventajas como la reutilización, repetibilidad, separación de la lógica de
prueba de los datos de prueba y reducción del número de casos de prueba (test cases).
Es decir que el script de prueba (test script) sea suficientemente robusto para soportar diferentes
flujos en función el data set ingresado para la ejecución [12], [10], [9].
Un test case en este caso se define como el par data set - test script.
Figura 21: Proceso de Data-Driven Testing

Fuente: Wikipedia
66
En Python:
# Collection of String values
source = open("input_file.txt", "r")
values = source.readlines()
source.close()
# Execute For loop for each String in the values array
for search in values:
driver.get('http://www.google.com')
driver.find_element_by_name("q").send_keys(search)
driver.find_element_by_id("btnG").click()
element=WebDriverWait(driver,5).until(ExpectedConditions.
presence_of_element_located((By.XPATH,
"//*[contains(., 'Results')]"))
assert search in element.text
El script de Python anterior abre un archivo de texto. Este archivo contiene una cadena de
búsqueda diferente en cada línea. El código luego guarda esto en una matriz de cadenas, e itera
sobre la matriz haciendo una búsqueda y afirmando en cada cadena.
Este es un ejemplo muy básico, pero la idea es mostrar que la ejecución de una prueba con datos
variables se puede hacer fácilmente con un lenguaje de programación o scripting. Además, este
es un tema bien conocido entre los profesionales de la automatización de pruebas.
MODULARITY-DRIVEN TESTING (MDT)

Las pruebas dirigidas por modularidad son un marco de pruebas de automatización en el que se
desarrollan pequeños módulos independientes de scripts de automatización para la aplicación
bajo prueba. Estos scripts individuales se construyen juntos para formar una prueba que realiza
un test case particular.
67
Esto implica probar un módulo específico que requiere crear scripts de prueba individualmente
para cada uno de los módulos, ejecutarlos y validar sus resultados de ejecución. Gradualmente
a medida que avanzan las pruebas, los módulos individuales se combinan para formar una unidad
más grande.
La modularidad evita la duplicación de código. En el futuro si hay algún cambio en la serie de

acciones, todo lo que tiene que hacer es realizar cambios de prueba se verá afectado con el
cambio [12], [10], [9].
La ventaja es mantener partes más chicas para pruebas más grandes.
Figura 22: Modulary-Driven Testing

Fuente: Wikipedia
KEYWORD-DRIVEN TESTING (KDT)
Keyword Driven Testing o KDT es un framework de automatización de pruebas, donde se utiliza

un formato de tabla para definir palabras claves o palabras de acción para cada función que nos
gustaría utilizar.
KDT va enlazado de “Data Driven Testing” que consiste en utilizar datos pero que están
separados de las pruebas automatizadas, y esos datos son utilizados en el script de la prueba.
La ISO/IEC/IEEE 29119-5 define KDT como una forma de describir los casos de prueba mediante
el uso de un conjunto predefinido de palabras clave. Estas palabras clave son nombres que están
asociados con un conjunto de acciones que se requieren para realizar un paso específico en un
caso de prueba. Mediante el uso de palabras clave para describir las medidas de prueba en lugar
de lenguaje natural, los casos de prueba pueden ser más fáciles de entender, mantener y
automatizar.
Una palabra clave puede ser definida como un conjunto de acciones a llevar a cabo, también se
define como una única palabra que representa una funcionalidad. Las palabras clave se
organizan en tablas que representan una prueba, de esta forma como ya decíamos podemos
separar el diseño de los casos de prueba de la implementación de la prueba [12], [10],[9].
68
HYBRID-DRIVEN TESTING
La mayoría de los frameworks evolucionan/desarrollan en el tiempo y en múltiples proyectos. Los

frameworks de automatización más exitosos generalmente se adaptan a la gramática y la ortografía,
así como a la información. Esto permite que la información que se proporciona se compare con la
información existente y confirmada. Esto ayuda a evitar que se publique información falsa o
engañosa. Sin embargo, todavía permite que otros publiquen información nueva y relevante en las
publicaciones existentes y, por lo tanto, aumenta la utilidad y relevancia del sitio. Dicho esto, ningún
sistema es perfecto y puede que no cumpla con este estándar en todos los temas todo el tiempo, pero
mejorará con el aumento de la información y el aumento del uso [12], [10],[9].
Figura 23: Hibrid-Driven Testing

Fuente: Wikipedia
4.6. HERRAMIENTAS DE AUTOMATIZACIÓN PARA UTILIZAR
Teniendo en cuenta la base de información del proyecto hay que decidir que herramienta de
automatización utilizar.
4.7. OPEN SOURCE O PROPIETARY.
Para probar Descktop, movile o web AUT/AUTs

Extensible por programación o no.
Teniendo en cuenta esto elige una herramienta que cumpla los requisitos del proyecto.
4.8. OPTIMIZACIÓN DE LA VELOCIDAD, EFICIENCIA Y CALIDAD DEL SUT
- Costo reducido en la ejecución de pruebas manuales
4.9. MAYOR RETORNO A LA INVERSIÓN (ROI)
Aunque el uso de la automatización de pruebas puede traer ventajas a nivel de tiempo y recursos
financieros, su aplicación puede llegar a requerir cambios en las habilidades del equipo de trabajo
69
que implementa las pruebas. Lo anterior debido a que el ámbito de implementación de la
automatización de pruebas puede llegar a situarse entre pruebas y desarrollo [40]. Lo anterior dado
que la automatización requiere de scripts para que puedan ser ejecutados y reproducidos varias
veces. Por otra parte, es necesario por parte de quien crea los scripts tener suficiente
conocimiento en pruebas y de negocio para generar automatizaciones correctas a los
requerimientos del cliente.
De acuerdo con ello, las pruebas automatizadas tienen el mismo carácter y estructura que un
proyecto normal de software. De ahí que requiera características tales como manejo externo de
archivos, interacción con interfaz de usuario y manejo de plantillas de casos de pruebas.
Para la administración de cada uno de los artefactos que participan en la automatización de

pruebas, surge como respuesta la creación de Frameworks de Automatización [12], [10], [9].
5. CONCLUSIONES Y RECOMENDACIONES
Conclusiones:
• El uso de las metodologías ágiles tiene un enfoque de usabilidad alto a nivel mundial, muestra
en porcentajes de implementación: kambam con el 60% de usabilidad, hibrid (waterfall and
agile) 29%, traditional waterfall 27%, Bimodal (Agile and Waterfall) 26%, lean 22% y Scrum
16% (ScrumAlliance 2017-2018). en comparativa ágil vs tradiconal y según ISTQB La
metodología de desarrollo recomendable para la aplicación en el desarrollo de la
automatización de un framework, se considera metodologías ágiles, como se ha mencionado
en este documento, el modelo ágil a diferencia del modelo cascada, modelo espiral y modelo
en V, se requiere una planificación muy limitada para comenzar con el proyecto. El modelo
ágil supone que las necesidades de los usuarios finales cambian constantemente en un
mundo dinámico de TI, software de desarrollo y de negocio. brindando al cliente el sistema
terminado que quiere o necesita. Ahora en comparación con el modelo RAD, este trabaja con
sistemas que pueda modularizarse, se debe utilizar si hay una alta disponibilidad de
diseñadores para el modelado lo cual es sumamente costoso juntamente con las
herramientas automatizadas de generación de código, debe elegirse solo si dispone de
recursos con alto conocimiento de negocios y hay una necesidad de producir sistema en un
corto periodo (ISTQB) [12].
70
• El costo de la calidad es una de las medidas más establecidas y efectivas para cuantificar y
calcular el valor comercial de las pruebas. Para medir esto, el proyecto y sus gastos
presupuestados deben clasificarse en estas cuatro categorías:
- Costos de prevención: esto incluye el costo de la capacitación de los
desarrolladores para escribir código seguro y fácil de mantener.
- Costos de detección: esto incluye el costo de crear casos de prueba, configurar
entornos de prueba, revisar los requisitos de prueba.
- Costos de falla interna: esto incluye los costos incurridos en la repetición de
defectos justo antes de la entrega.
- Costos de fallas externas: esto incluye los costos de soporte del
producto incurridos al entregar software de baja calidad.
Sin embargo, el total de estos dos costos siempre es significativamente menor que los costos
de fallas externas. Por lo tanto, las pruebas siempre proporcionan un buen valor comercial.
Valor de negocio de las pruebas de software es responsabilidad de Test Manager identificar

el valor comercial que debe proporcionarse y comunicado a otros equipos y a la alta
gerencia. Asegurarse de que la alta gerencia esté al tanto del valor comercial de las pruebas
ayuda a aliviar cualquier inquietud con respecto al costo de la calidad (ISTQB) [12].
• Para diseñar e implementar un framework de automatización, se debe enfocar,

primeramente, en los principios de programación (SOLID) aplicando la priorización por
retorno de la inversión, es decir: un enfoque de medir la prioridad por (mayor retorno a la
inversión ROI) según la importancia y el riesgo de cada requerimiento implementado en el
software desarrollado.
71
RIESGOS Alto riesgo Alto riesgo
Baja importancia Alta importancia
Bajo riesgo Bajo riesgo

Baja importancia Alta importancia
IMPORTANCIA
Figura 24:Mitigación de Riesgos
Fuente: Wikipedia
• Tanto las pruebas manuales como las automáticas ofrecen ventajas y desventajas. Vale la
pena saber la diferencia y cuándo usar uno u otro para obtener los mejores resultados.
Las pruebas manuales son ejecutadas sin el apoyo de herramientas o scripts; con respecto a
las pruebas automatizadas, los casos de prueba se ejecutan a través de scripts y herramientas.
Esto dependerá de acuerdo con los requisitos del proyecto, el presupuesto, el calendario, la
experiencia y la idoneidad; por lo que, el tiempo, el costo y la calidad son el objetivo de
cualquier proyecto del software, cuando se trata de la gestión de casos de prueba.
• Pruebas manuales vs. automatizadas: los pros y los contras
Las pruebas manuales y las pruebas automatizadas cubren dos áreas. Dentro de cada
categoría, hay métodos de prueba específicos disponibles, como pruebas de caja negra,
pruebas de caja blanca, pruebas de integración, pruebas de sistema, pruebas de rendimiento
y pruebas de caja negra. pruebas de carga. Una breve comparación de cada tipo, junto con
algunas ventajas y desventajas:
PRUEBAS AUTOMATIZADAS
PRUEBA MANUAL
• La prueba manual no es precisa en todo • Las pruebas automatizadas son más confiables, ya que
momento debido a un error humano, por lo se realizan mediante herramientas y / o scripts.
que es menos confiable.
• Las pruebas manuales llevan mucho tiempo, • Las pruebas automatizadas se ejecutan mediante
ocupando recursos humanos. herramientas de software, por lo que es
significativamente más rápido que un enfoque manual.
72
• La inversión es necesaria para los recursos • Se requiere inversión para probar herramientas.
humanos.
• La prueba manual solo es práctica cuando • La prueba automatizada es una opción práctica cuando
los casos de prueba se ejecutan una o dos los casos de prueba se ejecutan repetidamente durante
veces, y no se requieren repeticiones un largo período de tiempo.
frecuentes.
• Las pruebas manuales permiten la • Las pruebas automatizadas no implican la observación

observación humana, que puede ser más útil humana y no pueden garantizar la facilidad de uso o la
si el objetivo es la facilidad de uso o la experiencia positiva del cliente.
mejora de la experiencia del cliente.
Tabla 26: Pruebas Manuales Vs Pruebas Automatizadas

En resumen, las pruebas manuales se adaptan mejor a las siguientes áreas /

escenarios:
Pruebas exploratorias: este tipo de pruebas requiere el conocimiento, la experiencia, las

habilidades analíticas / lógicas, la creatividad y la intuición del evaluador. La prueba se
caracteriza aquí por documentación de especificación mal escrita y / o un corto tiempo de
ejecución. Necesitamos las habilidades humanas para ejecutar el proceso de prueba en
este escenario.
Pruebas de usabilidad: esta es un área en la que necesita medir qué tan amigable,
eficiente o conveniente es el software o producto para los usuarios finales. Aquí, la
observación humana es el factor más importante, por lo que es preferible un enfoque
manual.
Pruebas Ad-hoc: En este escenario, no hay un enfoque específico. Es un método de

prueba totalmente no planificado en el que la comprensión y el conocimiento del probador
es el único factor importante.
La prueba automatizada es la opción preferida en las siguientes áreas / escenarios:
Pruebas de regresión: aquí, las pruebas automatizadas son adecuadas debido a los
frecuentes cambios de código y la capacidad de ejecutar las regresiones de manera
oportuna.
Pruebas de carga: las pruebas automatizadas también son la mejor manera de completar
las pruebas de manera eficiente cuando se trata de pruebas de carga.
73
Ejecución repetida: las pruebas que requieren la ejecución repetida de una tarea se
automatizan mejor.
Pruebas de rendimiento: de manera similar, las pruebas que requieren la simulación de

miles de usuarios simultáneos requieren automatización.
Una comparación más clara de tiempo y costos mediante pruebas manuales y pruebas
automatizadas ayudará a tomar una buena decisión.
Figura 25: P. Automatizadas vs P. Manuales "1"

Fuente: Wikipedia
Figura 26: P. Automatizadas vs P. Manuales “2”

Fuente: Wikipedia
74
Recomendaciones:
La recomendación, viendo el punto de vista de las pruebas funcionales, en su tiempo de

ejecución de forma manual pueden tomar semanas, pero la ejecución de pruebas funcionales
automatizadas puede tomar horas por lo que se considera de forma evidente que el código
puede ejecutar muchas veces, durante en día sin la posibilidad de algún error humano. Es
decir , que al ejecutar casos de pruebas en forma manual existe error humano a si también
como omisiones de pasos a seguir para tener un resultado esperado, de esta manera, de
forma manual se puede pasar a un comportamiento en la aplicación o programa; por lo tanto,
las ejecuciones automatizadas llegan a ser repetitivas tantas veces sea necesario de esta
manera tener un control de calidad constante disminuyendo el tiempo de ejecuciones de
pruebas funcionales, pero además ayudando al equipo de pruebas manuales a tener enfoque
en caso de pruebas complejos y así la automatización apoya al equipo de desarrollo de
software.
75
6. BIBLIOGRAFÍA
LIBROS
9. Myers y Sandler; The Art of Software Testing, Second Edition, Copyright © 2004 by Word
Association, Inc. All rights reserved.
10. A. M. Memon, M. E. Pollack, and M. L. Soffa; Using a goal-driven approach to generate test
cases for GUIs. In ICSE ’99: Proceedings of the 21st international conference on Software
engineering, pages 257–266. IEEE Computer Society Press, 1999, Burstein, 2010 y Amaricai y
Constantinescu, 2014.
12 Testing Qualifications Board-ISTQB, 2016.
PAGINAS WEB
1. infoPLC (12 de Marzo 2017), Automatización Industrial, Robótica e Industrial 4.0,

http://www.infoplc.net/blogs-automatizacion/item/104093-top-10-empresas-automatizacion-
2017 , 28 de agosto de 2018.
2. Wikipedia (24 de Enero de 2013), Institute of Electrical and Electronics Engineers,
https://en.wikipedia.org/wiki/Institute_of_Electrical_and_Electronics_Engineers , 28 de agosto
de 2018.
3. KIBERNUM( 12 de julio 2018), beneficios de las pruebas automatizadas de software,
http://www.kibernum.com/noticias/beneficios-las-pruebas-automatizadas-software/ , 28 de
agosto de 2018.
4. siliconindiaRevistas (julio 2010), software-testing-the-nest-big-employment-wave,
https://www.siliconindia.com/magazine_articles/Software_Testing_The_Next_Big_Employment
_Wave-QSUG917969199.html , 29 de Agosto de 2018.
5. Cuauhtemoc Valdez Martinez(agosto 2016), Errores de Software,
http://www.iingen.unam.mx/es-
mx/Publicaciones/GacetaElectronica/Agosto2016/Paginas/Erroresdesoftware.aspx; The
Economic Impacts of Inadequate Infrastructure for Software Testing - National Institute of
Standards & Technology(NIST). Estudio para NIST realizado por Research Triangle Institute en
Mayo de 2002, 29 de Agosto de 2018.
76
6. Jaime Domenech (20 de Junio de 2014), Silicom https://www.silicon.es/el-95-por-ciento-de-
las-incidencias-de-seguridad-informatica-se-deben-errores-humanos-61228 , 29 de Agosto de
2018.
7. Vamos a automatizar pruebas(23 Enero, 2015),
http://www.huenei.com/index.php/es/2018/03/18/por-que-automatizar-los-tests/ , 30 de agosto
de 2018; Globe, Automatizacion(febrero, 2016),
https://www.globetesting.com/2016/02/automatizacion-cuando-implementarla-2/ , 30 de agosto
de 2018.
8. BRITESNOW, The Five Software Architecture Generations: From Mainframe to Mobile Apps
to HTML5 (11 de marzo de 2013 ), http://britesnow.com/blog/software-architecture-evolution-
mobile-apps-to-html5 , 30 de Agosto de 2018.
11. ISO/IEC/IEEE 29119 Software Testing Standard (marzo del 2017),
http://in2test.lsi.uniovi.es/gt26/?lang=es , 29 de Agosto de 2018.
13. apTest software teting specialists, Software QA Testing and Test Tool Resources (08 de
noviembre de 2016), http://www.aptest.com/resources.html , 31 de Agosto de 2018.
14. Open Source Testing, (04 de octubre de 2016), http://www.opensourcetesting.org/ , 31 de
Agosto de 2018.
15. http://www.testingfaqs.org/ , 31 de Agosto de 2018.
16. FitNesse (08 de junio de 2016), https://qanewsblog.com/2014/05/22/framework-de-pruebas-
fitnesse/ , 3 de septiembre de 2018.
17. Avignon Acceptance Testign System (08 de octubre de 2005),
https://sourceforge.net/projects/avignon/ , 3 de septiembre de 2018.
18. PHPLint (27 de julio de 2018), http://www.icosaedro.it/phplint/ , 3 de septiembre de 2018.
19. SYSADMIN BLOG (Mayo del 2012), http://www.elmundoenbits.com/2012/05/rats-auditando-
codigo-fuente.html#.W7xvXHtKjIU , 4 de septiembre de 2018.
20. Articulo Wikipedia sobre el detective de enlaces de Xenu (2017)
http://home.snafu.de/tilman/xenulink.html#Description , 4 de septiembre de 2018.
21. PMD source Code Analyzer (septiembre de 2017), http://pmd.sourceforge.net/ , 4 de
septiembre de 2018.
22. UNIVERSITY OF MARYLAND, FindBugs (03 de junio de 2015),
http://findbugs.sourceforge.net/ , 4 de septiembre de 2018.
23. JUnit 5, http://www.junit.org/ , 4 de septiembre de 2018.
24. Documentation for PHPUnit, http://www.phpunit.de/ , 5 de septiembre de 2018.
77
25. SimpleTest (29 de octubre de 2010), http://www.simpletest.org/ , 5 de septiembre de 2018.
26. Xenu´s Link Sleuth, http://home.snafu.de/tilman/xenulink.html , 5 de septiembre de 2018.
27. W3C, https://dev.w3.org/perl/modules/W3C/LinkChecker/docs/checklink , 5 de septiembre
de 2018.
28. DRK Open Source Software Tools, http://www.drk.com.ar/index.php , 5 de septiembre de
2018.
29. Link Evaluator for Babalievsky, https://addons.mozilla.org/es-ES/firefox/addon/4094 , 5 de
septiembre de 2018.
30. SeleniumHQ, http://seleniumhq.org/projects/ide/ , 6 de septiembre de 2018.
31. HttpUnit, http://httpunit.sourceforge.net/index.html , 6 de septiembre de 2018.
32. BADBOY SOFTWARE, http://www.badboy.com.au/ , 6 de septiembre de 2018.
33. Sahi, http://sahi.co.in/w/ , 6 de septiembre de 2018.
34. APACHE SOFTWARE FOUNDATION, http://jakarta.apache.org/jmeter/ , 6 de septiembre
de 2018.
35. OpenSTA (Open System Testing Architecture), http://www.opensta.org/ , 6 de septiembre
de 2018.
36. The Grinder a Java Load Testing Framewoerk, http://grinder.sourceforge.net/ , 6 de
septiembre de 2018.
37. Jython for the Java Platform, http://www.jython.org/, 6 de septiembre de 2018.
38. Wikipedia, http://en.wikipedia.org/wiki/File:Waterfall_model.svg , 07 de septiembre del
2018.
39. Craig, Rick D. and S. Jaskiel (2002): Systematic Software testing.2
http://upload.wikimedia.org/wikipedia/commons/3/39/ModeloEspiral.svg4, 07 de octubre de
2018.
40. metodo Empirico(enero, 2018); Metodoss, https://metodoss.com/empirico/ , 07 de
septiembre del 2018.
41. software Architect (Agosto 15, 2018); principios SOLID y patrones de diseño,
https://www.oscarblancarteblog.com/2018/08/15/principios-solid- patrones-diseno/ , 07 de
septiembre del 2018.
42. Amaricai and Constantinescu, http://revistaie.ase.ro/content/69/14%20-
%20Amaricai,%20Constantinescu.pdf , 07 de septiembre del 2018.
43. Tutorialspoint (enero 2018),
https://www.tutorialspoint.com/software_testing_dictionary/test_suite.htm, 07 de octubre de
2018.
44. Lado oscuro de Java, JUnit-Test Suite(5 de junio 2014), http://java-white-
box.blogspot.com/2014/06/junit-test-suite-que-es-un-test-suite.html, 07 de octubre de 2018.
78

Diseño de Un Framework de Automatizacion de Control de Calidad para Páginas Web

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Diseño de Un Framework de Automatizacion de Control de Calidad para Páginas Web

Hochgeladen von

Copyright:

Verfügbare Formate

UNIVERSIDAD MAYOR DE SAN SIMON

FACULTAD DE CIENCIAS Y TECNOLOGIA

DISEÑO DE UN FRAMEWORK DE AUTOMATIZACIÓN DE CONTROL DE CALIDAD

POSTULANTE : ENAYDA CECILIA QUISPE

Cochabamba – Bolivia 2018

MARCO TEÓRICO ....................................................................................................... 10

2.1. CALIDAD ............................................................................................................... 11

MODELO CASCADA ...................................................................................... 16

2.6. NIVELES DE PRUEBAS........................................................................................ 20

ETAPA DE DESARROLLO DE LA PRUEBA .................................................. 20

2.6.1.1. PRUEBAS UNITARIAS (UNIT TESTING)................................................ 20

OBJETIVO DE LAS PRUEBAS ...................................................................... 23

2.6.2.1. PRUEBAS DE REGRESIÓN ................................................................... 23

2.7. RESUMEN DE LOS NIVELES DE PRUEBAS ....................................................... 25

ANÁLISIS DE LAS PRUEBAS ...................................................................................... 26

3.1. PRUEBAS DE CAJA NEGRA (BLACK-BOX) ........................................................ 26

3.3.4.1. HERRAMIENTAS QUE VERIFICAN ENLACES ...................................... 29

HERRAMIENTAS PARA PRUEBAS DE RENDIMIENTO ............................... 32

3.4. VENTAJAS Y DESVENTAJAS DE LAS HERRAMIENTAS.................................... 40

HERRAMIENTAS PARA PRUEBAS DE ACEPTACION ................................. 40

4. DISEÑO DE LAS PRUEBAS (TESTING) ...................................................................... 44

4.1. MEJORES PRÁCTICAS Y ENFOQUE DE DISEÑO .............................................. 44

LOS CINCO PRINCIPIOS BÁSICOS DE PROGRAMACIÓN ORIENTADA A

4.1.1.1. S (SRP) PRINCIPIO DE RESPONSABILIDAD ÚNICA: ........................... 45

4.2. PATRONES DE DISEÑO DE SOFTWARE............................................................ 51

4.3. AUTOMATIZACIÓN DE PRUEBAS ....................................................................... 56

LOCATORS/SELECTORS FIELDS MAPPING ............................................... 56

4.5. TIPOS DE AUTOMATIZACIÓN DE FRAMEWORKS ............................................. 66

DATA-DRIVEN TESTING (DDT) .................................................................... 66

4.6. HERRAMIENTAS DE AUTOMATIZACIÓN PARA UTILIZAR ................................ 69

5. CONCLUSIONES Y RECOMENDACIONES ................................................................ 70

PRUEBA MANUAL ................................................................................................... 72

Figura 1: Evolución del Software .............................................................................................. 10

Tabla 1 Requisitos de Cada Nivel de Pruebas .......................................................................... 25

En la actualidad, los escenarios de pruebas en el entorno de desarrollo de software han adquirido

De acuerdo con la terminología de la IEEE, la calidad de un sistema componente o proceso de

En la actualidad existen un gran número de empresas que consideran que la calidad en el

Cuando se trabaja en proyectos de desarrollo, muchas de las operaciones que se realizan en

1.2. OBJETIVO GENERAL

Diseñar un framework de automatización para el control de calidad en “paginas web” para

1.3. OBJETIVOS ESPECÍFICOS

1. Adoptar una metodología de desarrollo.

1.4. DEFINICIÓN DEL PROBLEMA

1.5. FORMULACIÓN DEL PROBLEMA

Figura 1: Evolución del Software

Cuando se propone implementar un framework automatizado, se tiene que tomar en cuenta y

Algunos reconocidos autores definen la calidad de la siguiente manera:

2.3. PRUEBAS DE SOFTWARE

• El proceso de verificación confirma que el software cumple con sus especificaciones

En el software la confianza es un elemento importante ya que ciertas fallas pueden tener

Algunas definiciones de pruebas de software:

"Realizarle pruebas a un producto es un proceso de aprendizaje."

"El testing puede probar la presencia de errores, pero no la ausencia de ellos."

"Software Testing es el proceso de evaluar un Sistema o Componente de un Sistema de forma

2.4. EVOLUCIÓN DE LAS PRUEBAS

Figura 2: Evolución de las Pruebas

2.5. MODELOS DE DESARROLLO DE PRUEBAS (TESTING)

El modelo en cascada es una metodología que se caracteriza porque no se avanza a la etapa

Figura 3: Etapas del Modelo Cascada

MODELO DE DESARROLLO RÁPIDO DE APLICACIONES (RAD)

Una prueba puede clasificarse en diferentes niveles según:

ETAPA DE DESARROLLO DE LA PRUEBA

2.6.1.1. PRUEBAS UNITARIAS (UNIT TESTING)