testing-120413131346-phpapp02
DESCRIPTION
proceso de testingTRANSCRIPT
![Page 1: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/1.jpg)
Testing de Software
Abril 2012
Cátedra: ProyectoProfesor: Mario BressanoUniversidad Tecnológica Nacional - FRRO
![Page 2: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/2.jpg)
Confidential // Neoris 2
Agenda
Lunes 9 de AbrilTestingFundamentos del TestingProceso Fundamental de TestingModelo de Desarrollo de Software: Modelo VNiveles de PruebaTipos de Prueba
Martes 10 de AbrilConceptos Teóricos finalizaciónEn la Practica
![Page 3: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/3.jpg)
Confidential // Neoris 3
¿Testing?
![Page 4: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/4.jpg)
Confidential // Neoris 4
Pruebas de Software - Testing
Las pruebas de software, en inglés “Testing” son los procesos que permiten verificar y revelar la calidad de un producto software. Son utilizadas para identificar posibles fallos de implementación, calidad, o usabilidad de un programa de ordenador o videojuego. Básicamente es una fase en el desarrollo de software consistente en probar las aplicaciones construidas.
“El testing puede probar la presencia de errores pero no la ausencia de ellos”. Edsger Wybe Dijkstra
Definición
![Page 5: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/5.jpg)
Confidential // Neoris 5
¿Por qué es necesario el Testing?
![Page 6: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/6.jpg)
Confidential // Neoris 6
Fundamentos del Testing
La importancia económica del software
Calidad del Software
Pruebas para la mejora de la calidad
El funcionamiento de maquinaria y equipamiento depende en gran medida del software.No es posible imaginar grandes sistemas, en el ámbito de las finanzas ni el control del tráfico automotor, entre otros, funcionando sin software.
Cada vez más, la calidad software se ha convertido en un factor determinante del éxito de sistemas y productos técnicos o comerciales.
Las pruebas y revisiones aseguran la mejora de la calidad de productos de software así como de la calidad del proceso de desarrollo en sí.
![Page 7: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/7.jpg)
Confidential // Neoris 7
Terminología
![Page 8: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/8.jpg)
Confidential // Neoris 8
Error Defecto Falla
![Page 9: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/9.jpg)
Confidential // Neoris 9
Definición
Error
Acción humana que produce un resultado incorrecto. Ej. Un error de programación.
Defecto
Desperfecto en un componente o sistema que puede causar que el componente o sistema falle en desempeñar las funciones requeridas. Ej: una sentencia o una definición de datos incorrecta.
Falla
Manifestación física o funcional de un defecto. Si un defecto es encontrado durante la ejecución de una aplicación puede producir un fallo.Desvío de un componente o sistema respecto del resultado esperado.
![Page 10: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/10.jpg)
Confidential // Neoris 10
Fundamentos del Testing
Grado en el cual un componente, sistema o proceso satisface requisitos especificados y/o necesidades y expectativas del usuario/cliente.
Calidad
![Page 11: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/11.jpg)
Confidential // Neoris 11
Calidad de Software
Atributos funcionales de calidad:
Funcionalidad: correctitud y completitud de los requisitos del usuario.
Atributos NO funcionales de calidad:
Fiabilidad: el sistema mantendrá su capacidad y funcionalidad a lo largo de un período de tiempo.
Usabilidad: fácil de usar, fácil de aprender, conforme a normas y uso intuitivo.
Portabilidad: fácil de instalar y desinstalar, y configurar parámetros.
![Page 12: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/12.jpg)
Confidential // Neoris 12
¿Cuánto Testing es necesario?
![Page 13: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/13.jpg)
Confidential // Neoris 13
Fundamentos del Testing
El testing exhaustivo es imposible.
Testear todas las combinaciones de entradas y precondiciones no es factible.
Para enfocar el testing nos debemos basar en Riesgos y Prioridades.
![Page 14: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/14.jpg)
Confidential // Neoris 14
¿Qué es testing?
![Page 15: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/15.jpg)
Confidential // Neoris 15
Consiste solamente en realizar pruebas.
Es ejecutar la aplicación.
Percepción común
Es fácil y cualquiera lo puede hacer.
![Page 16: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/16.jpg)
Confidential // Neoris 16
Las actividades de la prueba existen antes y después de la ejecución de la prueba.
Puede haber diferentes objetivos de prueba:
Realidad
Encontrar defectos. Ganar confianza sobre el nivel de calidad y proporcionar información. Prevenir defectos
![Page 17: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/17.jpg)
Confidential // Neoris 17
Proceso Fundamental de Testing
El proceso fundamental del Testing
Planificación y Control
Análisis y Diseño
Aplicación y Ejecución
Evaluación de los criterios de salida y Reportes
Actividades de cierre de
Pruebas
El proceso de prueba fundamental consiste de las siguientes actividades principales:
![Page 18: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/18.jpg)
Confidential // Neoris 18
Planificación y Control
Planificación y Control
Determinar el alcance y los riesgos, e identificar los objetivos de la prueba.
Implementar la estrategia de prueba.
Programar los análisis de prueba y las tareas de diseño.
Nos aseguramos de haber entendido las metas y objetivos del cliente, el proyecto y los riesgos de las tareas de testing.
![Page 19: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/19.jpg)
Confidential // Neoris 19
Análisis y Diseño
Análisis y DiseñoRevisión de los elementos básicos para las
pruebas (tales como los requerimientos, arquitectura de la aplicación, diseño, interfaces).
Identificar y priorizar las condiciones de las pruebas y datos de pruebas basado en el análisis anterior.
Actividad donde los objetivos generales de las pruebas se transforman en condiciones de prueba tangibles y casos de prueba.
Puesta a punto del entorno de pruebas y se determinan las herramientas necesarias
![Page 20: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/20.jpg)
Confidential // Neoris 20
Ejecución
Aplicación y Ejecución
Evaluación de los criterios de salida
y Reportes
Ejecutar las pruebas.
Registrar resultados, Comparar e Informar.
Repetir las pruebas.
![Page 21: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/21.jpg)
Confidential // Neoris 21
Implementación y ejecución de prueba La implementación y ejecución de prueba tienen las siguientes tareas principales:
Ejecutar los casos de prueba ya sea manualmente o mediante el uso de herramientas de ejecución de prueba, de acuerdo con la secuencia planeada.
Registrar el resultado de la ejecución de prueba y la versión del software bajo prueba, en una herramientas de prueba.
Comparar los resultados reales con los resultados esperados.
Informar discrepancias como incidentes.
Repetir las actividades de prueba después de las correcciones. Por ejemplo, la re-ejecución de una prueba que falló previamente para confirmar un arreglo (pruebas de confirmación), ejecución de pruebas para asegurarse que los defectos no han sido introducidos en áreas no cambiadas del software o que el arreglo del defecto no reveló otros defectos (pruebas de regresión).
![Page 22: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/22.jpg)
Confidential // Neoris 22
Evaluación de los criterios de salida y ReportesEvaluar los criterios de salida es la actividad donde la ejecución de prueba es evaluada contra los objetivos definidos. Esto debe hacerse para cada nivel de prueba.
Evaluar los criterios de prueba tiene las siguientes tareas principales: Comparar los registros de prueba contra los criterios de salida especificados en la
planificación de prueba.
Evaluar si se necesitan más pruebas.
Escribir un reporte de resumen de prueba para las partes interesadas.
![Page 23: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/23.jpg)
Confidential // Neoris 23
Actividades de cierre de Pruebas
Actividades de cierre de
Pruebas
Se recolecta la información de las actividades de prueba completadas para consolidar.
Verificar el entregable y que los defectos hayan sido corregidos.
Archivar todo el material generado en las pruebas para un futuro uso.
Evaluar como resultaron las actividades de testing y analizar las lecciones aprendidas.
![Page 24: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/24.jpg)
Confidential // Neoris 24
Psicología de PruebaEl modo de pensar a ser usado mientras se prueba y revisa es diferente al usado mientras se analiza o desarrolla.
La separación de esta responsabilidad hacia un probador es realizada típicamente para ayudar a enfocar el esfuerzo y para proporcionar beneficios adicionales, tales como una visión independiente.
Varios niveles de independencia pueden ser definidos:
Pruebas diseñadas por la(s) persona(s) que escribió (escribieron) el software bajo prueba.
Pruebas diseñadas por otra(s) persona(s) del equipo de desarrollo. (bajo nivel de independencia).
Pruebas diseñadas por una(s) persona(s) de un grupo organizacional diferente (por ejemplo, un grupo de prueba independiente.
Pruebas diseñadas por una(s) persona(s) de una organización o compañía diferente (es decir subcontratación o certificación por un organismo externo).
![Page 25: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/25.jpg)
Confidential // Neoris 25
Psicología de Prueba – continuación
Identificar fallas durante la prueba puede ser percibido como una crítica contra el producto y contra el autor. La prueba es, por lo tanto, a menudo vista como una actividad destructiva, aunque es muy constructiva en la gestión de riesgos del producto.
Buscar fallas en un sistema requiere curiosidad, pesimismo profesional, un ojo crítico, atención al detalle, buena comunicación con los pares de desarrollo y experiencia en que basar la conjetura de error.
Si los errores, defectos o fallas son comunicados en una forma constructiva, malos sentimientos entre los probadores y los analistas, diseñadores y desarrolladores pueden ser evitados.
![Page 26: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/26.jpg)
Confidential // Neoris 26
Modelos de desarrollo de Software
![Page 27: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/27.jpg)
Confidential // Neoris 27
Testing a través del ciclo de desarrollo del softwareLa prueba no existe en forma aislada; las actividades de prueba están relacionadas con las actividades de desarrollo de software. Los diferentes modelos de ciclo de vida de desarrollo necesitan diferentes enfoques hacia la prueba. Modelo-V Aunque existen variantes del Modelo-V, un tipo común de Modelo-V usa 4 niveles de prueba, correspondientes a 4 niveles de desarrollo. Los cuatro niveles usados en este programa son: Prueba de componente (unidad). Prueba de integración. Prueba de sistema. Prueba de aceptación.
En la práctica, un Modelo-V puede tener diferentes niveles de desarrollo y prueba, dependiendo del proyecto y del producto de software. Por ejemplo, puede existir prueba de integración de componentes después de las pruebas de componente y prueba de integración del sistema después de la prueba del sistema.
![Page 28: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/28.jpg)
Confidential // Neoris 28
Modelo V
Diseño Funcional del Sistema
Diseño Técnico del Sistema
Especif. de Componentes
Definición de Requisitos Pruebas de Aceptación
Pruebas de Sistema
Pruebas de Integración
Pruebas de Componentes
Programación
![Page 29: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/29.jpg)
Confidential // Neoris 29
Testing a través del ciclo de desarrollo del software
Niveles de Pruebas
Testing de Componentes
Testing de Integración
Testing del Sistema
Testing de Aceptación
![Page 30: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/30.jpg)
Confidential // Neoris 30
Testing de Componentes
Testing de Componentes
Definición
Prueba de cada componente tras su realización/construcción
Los componentes son referidos como módulos, clases o unidades
También denominadas pruebas de Desarrollador (developer’s test)
Alcance
Cada componente es probado de forma independiente
Descubrir fallos producidos por defectos internos
Los casos de prueba tienen 3 fuentes: especificaciones de componente, diseño, modelo de datos.
![Page 31: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/31.jpg)
Confidential // Neoris 31
Testing de Integración
Testing de Componentes
Testing de Integración
Definición
Comprueba la interacción entre elementos de software (componentes) tras la integración del sistema.
Comprueban las funciones externas.
Pueden ser ejecutadas por desarrolladores, testers o
ambos.
![Page 32: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/32.jpg)
Confidential // Neoris 32
Testing de Integración
Testing de Componentes
Testing de Integración
Estrategias
Incremental
Descendente
Ascendente
Ad-Hoc
No Incremental
![Page 33: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/33.jpg)
Confidential // Neoris 33
Estrategias – Tipos fundamentales de Integración Integración incremental. Se combina el siguiente módulo que se debe probar con el conjunto de módulos que ya han sido probados.
Ascendente.
Se combinan los módulos de bajo nivel en grupos que realicen una función o subfunción específica (o quizás si no es necesario, individualmente) -> de este modo reducimos el número de pasos de integración.
Se escribe para cada grupo un módulo impulsor o conductor -> de este modo permitimos simular la llamada a los módulos, introducir datos de prueba y recolectamos resultados.
Se prueba cada grupo mediante su impulsor. Se eliminan los módulos impulsores y se sustituyen por los módulos de nivel
superior en la jerarquía.
![Page 34: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/34.jpg)
Confidential // Neoris 34
Estrategias – Tipos fundamentales de Integración
Integración incremental.
Descendente. Se comienza por el módulo raíz.
Comienza por el módulo de control principal y va incorporando módulos subordinados progresivamente.
No hay un orden adecuado de integración, pero se recomienda lo siguiente:Si hay secciones críticas (especialmente complejas) se deben integrar lo antes posible.El orden de integración debe incorporar cuanto antes los módulos de entrada/salida para facilitar la ejecución de pruebas.
Integración NO incremental. Se prueba cada módulo por separado y luego se integran todos de una vez y se prueba el programa completo.
Ad-hoc: Los componentes serán probados, si fuera posible, inmediatamente después de haber sido finalizada su construcción y se hayan finalizado las pruebas de componente.
![Page 35: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/35.jpg)
Confidential // Neoris 35
COMPARACION DE LOS DISTINTOS TIPOS DE INTEGRACION PRUEBAS DEL SOFTWARE
Ventajas de la No incremental:
Requiere menos tiempo de máquina para las pruebas, ya que se prueba de una sola vez la combinación de los módulos.
Existen más oportunidades de probar módulos en paralelo.
Ventajas de la incremental:
Los defectos y errores en las interfaces se detectan antes, ya que se empieza antes a probar las uniones entre los módulos.
La depuración es mucho más fácil, ya que si se detectan los síntomas de un defecto en un paso de la integración hay que atribuirlo muy probablemente al último módulo incorporado.
Se examina con mayor detalle el programa, al ir comprobando cada interfaz poco a poco.
![Page 36: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/36.jpg)
Confidential // Neoris 36
ASCENDENTES DESCENDENTES
VENTAJAS VENTAJAS
Es un método ventajoso si aparecen grandes fallos en la parte inferior del programa, ya que se prueba antes.La entradas para las pruebas son más módulos inferiores.Es más fácil observar los resultados de la prueba, ya que es en los módulos inferiores donde se elaboran los datos (los superiores suelen ser módulos de control).
Es ventajosa si aparecen grandes defectos en los niveles superiores del programa, ya que se prueban antes.Permite ver antes una estructura previa del programa, lo que facilita el hacer demostraciones.
DESVENTAJAS DESVENTAJAS
Se requieren módulos impulsores, quedeben codificarse.El programa, como entidad, sóloaparece cuando se agrega el últimomódulo.
Las entradas para las pruebas pueden ser difíciles o imposibles de crear, puesto que, a menudo, se carece de los módulos inferiores que proporcionan los detalles de operación.Es más difícil observar la salida, ya que los resultados surgen de los módulos inferiores.
INCREMENTAL
![Page 37: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/37.jpg)
Confidential // Neoris 37
Testing de Sistema
Testing de Componentes
Testing de Integración
Testing de Sistema
Enfoques para las pruebas funcionales:
Basadas en Requisitos.
Basadas en Procesos de Negocio.
Basadas en Casos de Uso.
Los casos de prueba se derivan de la especificación de requisitos.El número de casos de prueba variará en función del tipo/profundidad de las pruebas basadas en la especificación de requisitos.
Cada proceso de negocio sirve como fuente para derivar/generar pruebas.El orden de relevancia de los procesos de negocio puede ser aplicado para asignar prioridades a los casos de prueba.
Los casos de prueba se derivan/generan a partir de las secuencias de usos esperados o razonables.Las secuencias utilizadas con mayor frecuencia reciben una prioridad más alta.
DefiniciónTiene que ver con el comportamiento de todo un sistema/producto, definida por el alcance de un proyecto de desarrollo o programa.
![Page 38: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/38.jpg)
Confidential // Neoris 38
Testing de Aceptación
Testing de Componentes
Testing de Integración
Testing del Sistema
Testing de AceptaciónDefinición
Pruebas formales llevadas a cabo con el objeto de verificar la conformidad del sistema con los requisitos.
El Objetivo de las pruebas de aceptación es validar que un sistema cumple con el funcionamiento esperado y permitir al usuario de dicho sistema que determine su aceptación, desde el punto de vista de su funcionalidad y rendimiento.
![Page 39: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/39.jpg)
Confidential // Neoris 39
Tipos de Pruebas
Testing relacionado a cambios
Testing Estructural
Tipos de pruebas: Objetivos del proceso de Pruebas
Testing Funcional
Testing No Funcional
![Page 40: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/40.jpg)
Confidential // Neoris 40
Tipos de Pruebas – Testing Funcional
Testing Funcional
Objetivo: La función del objeto de prueba.Las funciones, que un sistema, un subsistema o un componente realizará, pueden estar descritas en productos de trabajo tales como una especificación de requisitos, casos de uso o una especificación funcional, o podrían estar no documentados. Las funciones son “lo que” el sistema hace.
Las pruebas funcionales consideran el comportamiento externo del software (pruebas de caja negra).
Se pueden llevar a cabo en todos los niveles de pruebas
![Page 41: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/41.jpg)
Confidential // Neoris 41
Tipos de Pruebas – Testing No Funcional
Testing No Funcional
Pruebas de Performance
Pruebas de Volumen
Pruebas de Concurrencia
Objetivo: La finalidad de la prueba es saber “como” funciona el sistema.
El termino pruebas no funcionales describe las pruebas necesarias para medir las características de los sistemas y software que se puede cuantificar en una escala variable, tales como tiempos de respuesta para las pruebas de rendimiento.
![Page 42: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/42.jpg)
Confidential // Neoris 42
Tipos de Pruebas – Testing Estructural
Testing Estructural
Objetivo: La finalidad de las pruebas es medir el grado en el cual la estructura del objeto de prueba ha sido cubierto por los casos de prueba.Las pruebas estructurales (de caja blanca) pueden ser realizadas en todos los niveles de prueba, pero sobre todo en las pruebas de componentes (unit testing) y las pruebas de integración de componentes.
Las técnicas estructuradas son las mejores usadas después de las técnicas basadas en especificaciones.
![Page 43: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/43.jpg)
Confidential // Neoris 43
Tipos de Pruebas – Testing relacionado a cambios
Testing de confirmación/regresión
Objetivo: Repetir una prueba de funcionalidad que ha sido verificada previamente.
Confirmación: Cuando un defecto es detectado y arreglado, entonces el software debe ser probado de nuevo para confirmar que el defecto original ha sido retirado
exitosamente.
Regresión: son las pruebas repetidas de un programa ya testeado, después de una modificación, para descubrir cualquier error introducido o no descubierto como resultado del cambio(s). Estos errores pueden ser ya sea en el software que se está testeando, o en otro componente del software relacionado o no. Se lleva a cabo cuando el software, o su entorno, sufren cambios. El alcance de las pruebas de regresión esta basado en el riesgo de no encontrar errores en el software que estaba funcionando anteriormente.
![Page 44: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/44.jpg)
Confidential // Neoris 44
Pruebas de Mantenimiento
Las pruebas de mantenimiento se realizan en un sistema operativo existente, y es provocada por modificaciones, migración de datos, o la jubilación del software o sistema.
Las modificaciones incluyen cambios planificados, correctivos y cambios de emergencia, y cambios de ambiente, como el sistema operativo o base de datos prevista, actualizaciones o parches.
Además de verificar lo que se ha cambiado, las pruebas de mantenimiento incluyen extensivas pruebas de regresión a las partes del sistema que no han sido cambiadas.
La determinación de cómo el sistema actual puede verse afectado por los cambios se llama análisis de impacto, y es utilizado para ayudar a decidir la cantidad de pruebas de regresión a hacer.
Testing durante el mantenimiento
![Page 45: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/45.jpg)
Confidential // Neoris 45
Recapitulación
Error, defecto y falla.Proceso fundamental de testing.Ciclo de desarrollo de software: modelo V.
Niveles de pruebas: • Componente. • Integración.
• Incremental (asc o desc), No Incremental, Ad hoc.• Sistema. • Aceptación.
Tipos de Pruebas (a través de los distintos niveles)Testing FuncionalTesting No Funcional: carga, stress, volumen, etc.Testing Estructural: caja blancaTesting Relacionado a Cambios: confirmacion/regresión.Pruebas en el Mantenimiento.
![Page 46: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/46.jpg)
Confidential // Neoris 46
Preguntas?
![Page 47: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/47.jpg)
Confidential // Neoris 47
Martes 10 de AbrilDiseño de Pruebas
TécnicasCaja NegraCaja Blanca
En la PrácticaCiclo de Vida y TestingNiveles de PruebaServicios de TestingConsultoría de pruebasAutomatizaciónHerramientas
Agenda
![Page 48: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/48.jpg)
Confidential // Neoris 48
Diseño de Pruebas
![Page 49: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/49.jpg)
Confidential // Neoris 49
Terminología
![Page 50: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/50.jpg)
Confidential // Neoris 50
Caso de Prueba
Definición
Son un conjunto de condiciones o variables bajo las cuáles el analista determinará si el requisito de una aplicación es parcial o completamente satisfactorio.
Se pueden realizar muchos casos de prueba para determinar que un requisito es completamente satisfactorio. Debe haber al menos un caso de prueba para cada requisito.
Algunas metodologías como RUP recomiendan el crear por lo menos dos casos de prueba para cada requisito. Uno de ellos debe realizar la prueba positiva de los requisitos y el otro debe realizar la prueba negativa.
Lo que caracteriza un escrito formal de caso de prueba es que hay una entrada conocida y una salida esperada. La entrada conocida debe probar una precondición y la salida esperada debe probar una postcondición.
![Page 51: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/51.jpg)
Confidential // Neoris 51
Casos de Prueba - continuación
Objetivo
Descripción
Información general acerca de los Casos de Prueba:
Resultado Esperado
Creador
Versión
Identificador
![Page 52: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/52.jpg)
Confidential // Neoris 52
Caso de Prueba - continuación
Objetivo: Es el fin que se quiere alcanzar y al cual se dirige la acción. El objetivo debe estar alineado con el resultado esperado.
Ejemplo:
• Verificar que el sistema solicita confirmación para la eliminación.
Descripción: los pasos que debe seguir el tester para realizar la prueba y alcanzar el objetivo expuesto.
Ejemplo:
• Realizar una búsqueda que arroje resultados, seleccionar un elemento de la lista y seleccionar la opción “Eliminar”.
Resultado Esperado: Es la respuesta que esperamos de la aplicación testeada luego de ejecutar los pasos detallados en la descripción con el fin de alcanzar el objetivo.
Ejemplo:
• El sistema muestra un mensaje de confirmación.
![Page 53: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/53.jpg)
Confidential // Neoris 53
Técnicas de diseño de pruebas
![Page 54: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/54.jpg)
Confidential // Neoris 54
Representación Gráfica
CAJA BLANCA
El tester observa el objeto de pruebas como una caja negra.
Los casos de prueba se obtienen a partir del análisis de la especificación de un componente o sistema.
La funcionalidad es el foco de la atención.
Se realiza sobre las funciones internas de un módulo.
Los casos de prueba son seleccionados en base a la estructura interna del programa/código.
La estructura del programa es el foco de la atención.
CAJA NEGRA
![Page 55: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/55.jpg)
Confidential // Neoris 55
Técnicas de Caja Blanca
![Page 56: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/56.jpg)
Confidential // Neoris 56
Caja Blanca
Utiliza la estructura de control de diseño procedural para derivar casos de
pruebas que:
Garanticen que todos los caminos independientes dentro de un módulo han sido ejercitados por lo menos una vez.
Ejerciten todas las decisiones lógicas en sus lados verdaderos y falsos.Ejerciten estructuras de datos internas para asegurar su validez.
Distintos Métodos:
Cobertura de Camino Básico
Cobertura de Condición
Cobertura de Bucles
![Page 57: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/57.jpg)
Confidential // Neoris 57
Técnicas de caja negra
![Page 58: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/58.jpg)
Confidential // Neoris 58
Técnicas de diseño de pruebasLos métodos más utilizados son: Particiones de equivalenciasEs un proceso sistemático que identifica un conjunto de clases de prueba representativas de un conjunto de pruebas posibles, la idea es que el producto se comportará de la misma manera para todos los miembros de una clase. Consta de los siguientes pasos:
1. Identificar las clases de equivalencias: Por ejemplo: (si un contador puede ir de 1 a 999). Entonces tendríamos:Clases Válidas: (1 <= contador <= 999). Clases Inválidas: (contador < 1), (contador > 999)
2. Identificar los casos de pruebas: asignar un nro. único a cada clase, diseñar casos de pruebas hasta cubrir todas las clases válidas y clases inválidas.
Análisis de valores fronterasEs una variante del particiones de equivalencias, se seleccionan los bordes de una clase. Por cada clase válida hay que definir pruebas para las fronteras. Por ejemplo: número entre 3 y 8, probar para 2, 3, 8 y 9.
![Page 59: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/59.jpg)
Confidential // Neoris 59
ResumenCaso de Prueba: identificador, objetivo, descripción, resultado esperado,
etc.Técnicas
Caja Negra: Particiones de Equivalencias, Análisis de valores frontera.
Caja Blanca: Cobertura de camino Básico, de condición, de bucle.
Los métodos de caja negra y caja blanca son métodos dinámicos.
Solo se puede probar código existente.
Detecta el código muerto, pero no funciones faltantes.
Los métodos de caja blanca son utilizados en pruebas de bajo nivel como prueba de componente o pruebas de integración de componentes.
![Page 60: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/60.jpg)
Confidential // Neoris 60
EN LA PRACTICA
![Page 61: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/61.jpg)
Confidential // Neoris 61
Servicios de Testing
Permite evaluar y conocer los procesos y
actividades de testing que se realizan y
proponer una solución metodológica y
operativa de acuerdo a las oportunidades
identificadas.
Asegurar que el usuario final obtiene la
funcionalidad requerida a través de un
software bien construido
Pruebas Funcionales
Garantizar la máxima productividad del usuario final, evitando retrasos y otros impactos negativos en los negocios, a través de un buen tiempo de respuesta de las aplicaciones, validando su infraestructura y arquitectura
Automatización de Pruebas
Ahorrar tiempo y costo en las pruebas,
mediante el diseño, construcción y
ejecución de pruebas automatizadas
Pruebas de Stress
Testing Methodology
Consultoría de Testing
![Page 62: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/62.jpg)
Confidential // Neoris 62
En la Practica - Ciclo de VidaAnálisis Diseño
Desarrolloy Testing
ImplementaciónPropuesta
![Page 63: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/63.jpg)
Confidential // Neoris 63
Testing a través del ciclo de desarrollo del software
Nivel de Testing Tipo de Testing Breve Descripción
Testing de Unidad
Testing de UnidadVerifica que el código de cada componente trabaja de acuerdo a sus especificaciones y valida la lógica del programa. Se utiliza la estrategia de caja blanca
Testing de Integración
Testing de Integración de primer nivel
Verifica que las interfaces entre las componentes, entidades externas y la aplicación funcionan correctamente. Se pueden aplicar diferentes estrategias.
Testing de Integración de segundo nivel Verifica la integración funcional entre los diferentes casos de usos del sistema.
Testing de Sistema
Testing Funcional
Consiste en probar la funcionalidad del sistema, a partir de cumplir con los requerimientos, sin tener en cuenta la forma en cómo éste resuelve internamente las especificaciones. Se utiliza la estrategia de caja negra.
Testing No FuncionalConsiste en verificar el cumplimiento de los requerimientos no funcionales, por ejemplo: capacidad de instalación, usabilidad.
Testing de Regresión
Valida, ante un cambio en el sistema, que las partes del mismo, que no hayan cambiado continúen funcionando correctamente, luego de implementada la modificación. Se ejecutan casos de prueba seleccionados de entre los que se definieron para Testing Funcional y Testing No Funcional.
Testing de Aceptación
Testing de Aceptación
Valida el cumplimiento de los requerimientos a partir del punto de vista del usuario. Se ejecutan casos de prueba seleccionados de entre los que se definieron para Testing de Sistema.
Ejecutados por el Desarrollador
Ejecutados por el Tester
Ejecutado por el Cliente (opcional junto al tester)
![Page 64: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/64.jpg)
Confidential // Neoris 64
Preparación del Testing – Actividades
![Page 65: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/65.jpg)
Confidential // Neoris 65
Estimación del Testing
Tarea % tiempo insumido Detalle de Operaciones
Definición de casos 35% Lectura y análisis de documentación.Escritura de casos de Prueba.
Ejecución: 1er pasada 40% Ejecución de Casos de Prueba.Reporte de Errores.
Retesting 15% Reejecución de Casos.Actualización de Estados.
Otras tareas 10% Generación de Informes.Problemas con entornos.
Otros tiempos a tener en cuenta
Una vez que se tienen definidos los tiempos para los módulos, entran otras variables en juego, las cuales aumentan el volumen de horas:
• Distintos Navegadores y/o resoluciones de pantalla.• Cantidad de Idiomas.• Lugar donde se testea (Staging, Producción)
Consideraciones Generales
![Page 66: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/66.jpg)
Confidential // Neoris 66
Comunicación durante las pruebas
El testing se realizará en base a la documentación recibida y cualquier diferencia entre la Aplicación y la documentación será considerada una falla y reportado como tal.
El testing se realizará en base a la documentación recibida y cualquier diferencia entre la Aplicación y la documentación será considerada una falla y reportado como tal.
Asignación de Incidencias en la Herramienta.
Corrección de Incidencias y Registro en la Herramienta.
Actualización del Entorno de Testing.
Aviso Formal de la Liberación del Módulo para el Re-testing.
Asignación de Incidencias en la Herramienta.
Corrección de Incidencias y Registro en la Herramienta.
Actualización del Entorno de Testing.
Aviso Formal de la Liberación del Módulo para el Re-testing.
Tareas a Realizar
Consideraciones a Tener en Cuenta
Aviso Formal de la liberación de un Módulo al entorno de Testing.Aviso Formal de la liberación de un Módulo al entorno de Testing.
Documentación de Entrada
BD
Ejecución de los Casos de Prueba y Registración de Incidencias en la Herramienta.
Aviso Formal de Fin de Testing del Módulo.
Ejecución del Re-testing, y pruebas de Regresión.
Elaboración de Informe Final.
Ejecución de los Casos de Prueba y Registración de Incidencias en la Herramienta.
Aviso Formal de Fin de Testing del Módulo.
Ejecución del Re-testing, y pruebas de Regresión.
Elaboración de Informe Final.
Salida Generada
BD
![Page 67: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/67.jpg)
Confidential // Neoris 67
Consultoría de Testing
La consultoría consiste en conocer los procesos y actividades de testing que realiza la compañía internamente y/o a través de sus proveedores.
Y así poder detectar fortalezas y debilidades de dichos procesos y actividades.
Luego, en función de este trabajo, proponer una solución metodológica y operativa para mejorar las actividades de testing aplicables a los proyectos de software que lleve adelante la compañía.
Permite mejorar:• Gestión y mitigación de riesgos• Aplican mejores prácticas en la gestión de procesos de testing• Diseño y Mejoras en el proceso de Testing • Soporte de expertos de testing durante el período necesario• Trasferencia de conocimientos de testing a la organización
![Page 68: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/68.jpg)
Confidential // Neoris 68
Automatización de PruebasProcesoEl proceso general de automatización comienza por la evaluación de factibilidad de automatizar
los casos de prueba, posterior confección del plan de automatización, desarrollo de los scripts y validaciones, y por último, la ejecución de los mismos y generación de reportes. Dado que no todos los casos de prueba definidos para una solución pueden automatizarse, este proceso transcurre como un subproceso de testing dentro del ciclo de proyecto.
Como Optimización de muchos proyectos: Tareas repetitivas Generación de datos Múltiples regresiones Errores que se repiten demasiado Workflows largos necesarios para llegar a la funcionalidad a testear
Repetitividad
Impacto en el negocio
Complejidad
Qué debería ser automatizado primero?Test core del negocio / Test del mismo caso con diferentes datos
Test ejecutados con mucha frecuencia
![Page 69: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/69.jpg)
Confidential // Neoris 69
Herramientas utilizadas
QA Process Management permite a un usuario final realizar un procedimiento de Test sobre un Sistema
Team Foundation Server (TFS). Es un producto de Microsoft de control de versión, recolección de datos, informes y seguimiento de proyectos. V2008 y Beta 2010.
![Page 70: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/70.jpg)
Confidential // Neoris 70
Herramientas Utilizadas
![Page 71: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/71.jpg)
Confidential // Neoris 71
Comparación Herramientas AutomatizaciónSelenium 2 (Webdriver) QTP 11(última versión)
Open Source y gratuito. Herramienta paga, cada licencia cuesta 9000 mil dólares más 25% del costo por año en mantenimiento.
Funciona en todos los Sistemas Operativos. Funciona sólo en Windows.
Sólo para pruebas en aplicaciones Web. Pruebas en aplicaciones Web y Escritorio (Windows).
Funciona en todos los browsers. Funciona sólo con Firefox 3.5 e Internet Explorer (gran limitación para el testing Web).
Se codifica en cualquier lenguaje (C#, Java, Ruby, Python, PHP, Pearl, etc).
Sólo Visual Basic.
Record and Play no es 100% confiable, pero es útil (sólo se utiliza para quienes no sepan codificar y quieren automatizar).
Record and Play tiende a ser más sólido que en Selenium.
Selenium no se integra nativamente con QC, necesita algunas configuraciones, pero no de forma nativa. Existen múltiples formatos y herramientas de reporte que puede generar Selenium.
QTP se integra muy bien con Quality Center y TD.
Selenium tiene una gran comunidad online de soporte, pero no oficial. Hay empresas que cobran por dar soporte.
QTP tiene soporte telefónico, mail, y Web.
![Page 72: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/72.jpg)
Confidential // Neoris 72
Preguntas?
![Page 73: testing-120413131346-phpapp02](https://reader035.vdocuments.site/reader035/viewer/2022070412/55cf8f8a550346703b9d4bd9/html5/thumbnails/73.jpg)
Confidential // Neoris 73
A.U.S Gabriela Muñoz
MUCHAS GRACIAS!