PRUEBAS ESTRUCTURALES FUNCIONALES

Views:
 
Category: Entertainment
     
 

Presentation Description

TECNICAS AUTOMATIZABLES, MANUALES, ESTRUCTURALES FUNCIONALES.

Comments

By: coke1980 (137 month(s) ago)

excelente informacion me sirvio de mucho, muchas gracias

By: jasonarj (137 month(s) ago)

Bueno quien desee la presentación me dice no problem

By: yeison9375 (138 month(s) ago)

Hola yo tambien quiero la presenatacion, por favor me la puedes enviar ([email protected]) Gracias. Necesito saber de algun software para hacer los casos de pruebas, me podrias decir de alguno que no sea muy comlicado

By: yeison9375 (138 month(s) ago)

muy buena la presentacion

By: jasonarj (155 month(s) ago)

pues si quieres la presetación me escribes a mi correo y yo te la hago llegar, [email protected] y Listo

See all

Presentation Transcript

Slide 1: 

EXPONENETES MARYI LORENA SOLORZANO DIAZ YEISON ADRIAN RUBIO JARA

TECNICAS DE VERIFICACIÓN Y VALIDACIÓN : 

TECNICAS DE VERIFICACIÓN Y VALIDACIÓN Automatizables y Manuales Estructurales (Pruebas de Caja Blanca) y Funcionales (Pruebas de Caja negra)

¿ QUE ES VERIFICACIÓN Y VALIDACIÓN ? : 

¿ QUE ES VERIFICACIÓN Y VALIDACIÓN ? Verificación: ¿Estamos construyendo el producto correctamente? Se comprueba que el software cumple los requisitos funcionales y no funcionales de su especificación. Validación: ¿Estamos construyendo el producto correcto? Comprueba que el software cumple las expectativas que el cliente espera.

INTRODUCCIÓN PROCESO DE PUEBA : 

INTRODUCCIÓN PROCESO DE PUEBA

PRUEBAS AUTOMATIZABLES : 

PRUEBAS AUTOMATIZABLES Se usa un determinado software para sistematizar las pruebas y obtener los resultados de las mismas (P. ej.- verificar un método de ordenación).

PRUEBAS AUTOMATIZABLES : 

PRUEBAS AUTOMATIZABLES (Rice 2002) enumera y explica los diez retos más importantes en la automatización del proceso de pruebas. De acuerdo con este autor, éstos son los siguientes: Falta de herramientas, debida fundamentalmente a su elevado precio o a que las existentes no se ajusten al propósito o entorno para el que se necesitan. La primera razón parece deberse a la no mucha importancia que habitualmente se le da a la fase de pruebas, y eso que el costo de corregir un error puede, en muchos casos, superar al de la licencia de uso. Sería conveniente evaluar el coste de corrección de defectos del software entregado y compararlo con el de la licencia de la herramienta de pruebas.

PRUEBAS AUTOMATIZABLES : 

PRUEBAS AUTOMATIZABLES Falta de compatibilidad e interoperabilidad entre herramientas. Falta de proceso de gestión de la configuración. Igual que las diferentes versiones del código fuente, las pruebas, especialmente las de regresión, deben someterse a un control de versiones. Recuérdese que el proceso de Gestión de la Configuración es uno de los procesos de soporte del estándar ISO/IEC 12207 (ISO/IEC 1995), que debería utilizarse en la ejecución de los procesos principales, y muy especialmente en los de Desarrollo y Mantenimiento.

PRUEBAS AUTOMATIZABLES : 

PRUEBAS AUTOMATIZABLES Falta de un proceso básico de pruebas y de conocimiento de qué es lo que se debe probar. Falta de uso de las herramientas de prueba que ya se poseen, bien por su dificultad de uso, por falta de tiempo para aprender a manejarla, por falta de soporte técnico, obsolescencia, etc. Formación inadecuada en el uso de la herramienta.

PRUEBAS AUTOMATIZABLES : 

PRUEBAS AUTOMATIZABLES La herramienta no cubre todos los tipos de prueba que se desean (corrección, fiabilidad, seguridad, rendimiento, etc.). Obviamente, a la hora de elegir la herramienta, deberían tenerse priorizados los tipos de pruebas, y entonces hacer la elección de la herramienta basados en esto. A veces también es necesario utilizar no una, sino varias herramientas de pruebas, así como tener en cuenta que es imposible automatizar el 100% de las pruebas. Falta de soporte o comprensión por parte de los jefes, debido otra vez a la escasa importancia que habitualmente se le da a la fase de pruebas. Organización inadecuada del equipo de pruebas. Adquisición de una herramienta inadecuada.

PRUEBAS MANUALES : 

PRUEBAS MANUALES Son las que se hacen normalmente al programar o las que ejecuta una persona con la documentación generada durante la codificación (P. ej.- comprobar cómo se visualiza el contenido de una página web en dos navegadores diferentes).

PRUEBAS ESTRUCTURALES O DE CAJA BLANCA : 

PRUEBAS ESTRUCTURALES O DE CAJA BLANCA Permite evaluar los valores de las variables, las constantes y los tipos de datos y si éstos son usados en el contexto en que se definieron es decir toda la implementación del código que se va a ejecutar y podemos definir las pruebas que cubran todos los posibles caminos de este.

PRUEBAS ESTRUCTURALES O DE CAJA BLANCA : 

PRUEBAS ESTRUCTURALES O DE CAJA BLANCA Es una metodología de prueba que se basa en las estructuras de control del diseño procedimental para generar los casos de prueba que: Garanticen que se recorren por lo menos una vez todos los caminos independientes de cada módulo. Se ejecutan todas las decisiones lógicas en su parte verdadera y en su parte falsa. Se recorren todos los bucles. Se utilizan las estructuras de datos internas para garantizar su validez.

PRUEBAS ESTRUCTURALES O DE CAJA BLANCA : 

PRUEBAS ESTRUCTURALES O DE CAJA BLANCA Se invierte tiempo y esfuerzo en los detalles de control debido a que: Los errores suelen estar en situaciones fuera de las normales. A menudo caminos que pensamos que tienen pocas posibilidades de recorrerse, son recorridos regularmente. Los errores tipográficos son aleatorios. Puede que no sean detectados por los procesadores de la sintaxis del lenguaje particular y estar presentes en cualquier camino lógico.

PRUEBAS ESTRUCTURALES O DE CAJA BLANCA : 

PRUEBAS ESTRUCTURALES O DE CAJA BLANCA Cuando se pasan casos de prueba al programa que se está probando, es conveniente conocer qué porcentaje del programa se ha ejecutado, de manera que estemos próximos a asegurar que todo él es correcto (evidentemente, es imposible alcanzar una certeza del 100%). Existen varias formas de medir la cobertura lograda en el programa por los casos de prueba, algunas de las cuales se presentan en el siguiente epígrafe.

PRUEBAS ESTRUCTURALES O DE CAJA BLANCA : 

PRUEBAS ESTRUCTURALES O DE CAJA BLANCA Cobertura de sentencias “Comprueba el número de sentencias ejecutables ” Cobertura de decisiones “Número de decisiones ejecutadas ” Cobertura de condiciones “Número de condiciones ejecutadas ” Cobertura de condiciones múltiples “Número condiciones múltiples ejecutadas ” Cobertura de condiciones/decisiones “Que se han ejecutado” Cobertura de caminos Cobertura de funciones Cobertura de llamadas Cubrimiento de bucles Cubrimiento de carrera Cobertura de operadores relacionales Cobertura de tablas

PRUEBAS ESTRUCTURALES O DE CAJA BLANCA : 

PRUEBAS ESTRUCTURALES O DE CAJA BLANCA Sirve para representar el flujo de control lógico. Se basa en la representación del código a probar a través de círculos y arcos que indican el flujo de control. Cada círculo representa una o más sentencias. Las estructuras en forma de grafo de flujo son: COBERTURA DE CAMINOS “Grafo de flujo”

PRUEBAS ESTRUCTURALES O DE CAJA BLANCA : 

PRUEBAS ESTRUCTURALES O DE CAJA BLANCA UN GRAFO DE FLUJO está compuesto por: Nodos: una o más sentencias. Aristas: representan el flujo de control. Una arista debe terminar en un nodo. Regiones: áreas delimitadas por aristas y nodos. Cualquier representación del diseño procedimental se puede traducir en un grafo de flujo, partiendo de la descripción del código a probar en forma de un diagrama de flujo, en pseudocódigo o incluso en un determinado lenguaje de programación.

PRUEBAS ESTRUCTURALES O DE CAJA BLANCA : 

PRUEBAS ESTRUCTURALES O DE CAJA BLANCA UN GRAFO DE FLUJO está compuesto por: Cuando existen condiciones compuestas se crea un nodo por cada condición simple y se diseña el grafo de flujo de acuerdo a la lógica de control de la condición compuesta. Si por ejemplo existen dos condiciones simples ligadas por el operador and, se refleja en el grafo de flujo el hecho de que si una de las condiciones es falsa se ejecutará la siguiente instrucción. Cada nodo que contiene una condición se denomina nodo predicado y se caracteriza porque de él salen dos o más aristas. Una de las características para comprobar si un grafo de flujo esta bien diseñado es que los únicos nodos de los que pueden partir dos aristas son los nodos predicados.

PRUEBAS ESTRUCTURALES O DE CAJA BLANCA : 

PRUEBAS ESTRUCTURALES O DE CAJA BLANCA COMO DIBUJAR UN GRAFO DE FLUJO: Señalar sobre el código cada condición de cada decisión tanto en sentencias If-then y Case-of como en los bucles While o Until. Agrupar el resto de las sentencias en secuencias situadas entre cada dos condiciones . Numerar tanto las condiciones como los grupos de sentencias, de manera que se les asigne un identificador único

PRUEBAS ESTRUCTURALES O DE CAJA BLANCA : 

PRUEBAS ESTRUCTURALES O DE CAJA BLANCA GRAFO DE FLUJO

PRUEBAS FUNCIONALES O DE CAJA NEGRA : 

PRUEBAS FUNCIONALES O DE CAJA NEGRA No conocemos la implementación del código, sólo la interfaz. Tan sólo podemos probar dando distintos valores a las entradas y salidas.

PRUEBAS FUNCIONALES O DE CAJA NEGRA : 

PRUEBAS FUNCIONALES O DE CAJA NEGRA OBJETIVO: Se asegura la trabajo apropiado de los requisitos funcionales, incluyendo la navegación, entrada de datos, procesamiento y obtención de resultados. METAS: Verificar el procesamiento, recuperación e implementación adecuada de las reglas del negocio. Verificar la apropiada aceptación de datos. ENFOQUE Los requisitos funcionales (Casos de Uso) y las reglas del negocio.

PRUEBAS FUNCIONALES O DE CAJA NEGRA : 

PRUEBAS FUNCIONALES O DE CAJA NEGRA Se ejecuta cada caso de uso, flujo de caso de uso, o función, usando datos válidos e inválidos, para verificar lo siguiente: Que se aplique apropiadamente cada regla de negocio. Que los resultados esperados ocurran cuando se usen datos válidos. Que sean desplegados los mensajes apropiados de error y precaución cuando se usan datos inválidos.

PRUEBAS FUNCIONALES O DE CAJA NEGRA : 

PRUEBAS FUNCIONALES O DE CAJA NEGRA PARTICIONES O CLASES DE EQUIVALENCIA Las cualidades que definen un buen caso de prueba: Cada caso debe cubrir el máximo número de entradas Debe tratarse el dominio de valores de entrada dividido en un número finito de clases de equivalencia que cumplan la siguiente propiedad: la prueba de un valor representativo de una clase permite suponer «razonablemente» que el resultado obtenido (existan defectos o no) será el mismo que el obtenido probando cualquier otro valor de la clase.

PRUEBAS FUNCIONALES O DE CAJA NEGRA : 

PRUEBAS FUNCIONALES O DE CAJA NEGRA IDENTIFICACIÓN DE LAS CLASES DE EQUIVALENCIA Identificar las restricciones al formato y contenido de los datos de las entradas Identificar las clases de equivalencia: De datos Válidos De Datos no Válidos o Erróneos

PRUEBAS FUNCIONALES O DE CAJA NEGRA : 

PRUEBAS FUNCIONALES O DE CAJA NEGRA EJEMPLO: ESPECIFICACIÓN: Código área: número de 3 dígitos que no empieza ni por 0, ni por 1. Nombre de identificación: 6 caracteres. Ordenes posibles: "cheque", "depósito", "pago factura", "retirada de fondos".

PRUEBAS FUNCIONALES O DE CAJA NEGRA : 

PRUEBAS FUNCIONALES O DE CAJA NEGRA

PRUEBAS FUNCIONALES O DE CAJA NEGRA : 

PRUEBAS FUNCIONALES O DE CAJA NEGRA

PRUEBAS FUNCIONALES O DE CAJA NEGRA : 

PRUEBAS FUNCIONALES O DE CAJA NEGRA ANÁLISIS DE VALORES LÍMITES (AVL) Exploran las condiciones límites de un programa. Técnica Complementaria a las Clases de Equivalencia. Diferencias: Más que elegir «cualquier» elemento como representativo de una clase de equivalencia, se requiere la selección de uno o más elementos tal que los márgenes se sometan a prueba. Más que concentrarse únicamente en el dominio de entrada (condiciones de entrada), los casos de prueba se generan considerando también el espacio de salida

PRUEBAS FUNCIONALES O DE CAJA NEGRA : 

PRUEBAS FUNCIONALES O DE CAJA NEGRA REGLAS: Si una condición de entrada especifica un rango de valores, se deben generar casos para los extremos del rango y casos no válidos para situaciones justo más allá de los extremos. Si la condición de entrada especifica un número de valores, hay que escribir casos para los números máximo, mínimo, uno más del máximo y uno menos del mínimo de valores

PRUEBAS FUNCIONALES O DE CAJA NEGRA : 

PRUEBAS FUNCIONALES O DE CAJA NEGRA Usar la regla 1 para la condición de salida. Usar la regla 2 para cada condición de salida En esta regla 3 y 4, debe recordarse que: los valores límite de entrada no generan necesariamente los valores límite de salida. No siempre se pueden generar resultados fuera del rango de salida (pero es interesante considerarlo) Si la entrada o la salida de un programa es un conjunto ordenado (por ejemplo, una tabla, un archivo secuencial, ...), los casos deben concentrarse en el primero y en el último elemento.

GRACIAS POR LA ATENCIÓN PRESTADA : 

GRACIAS POR LA ATENCIÓN PRESTADA

PREGUNTAS : 

PREGUNTAS ¿A que es igual Caja Negra? ¿A que es igual Caja Blanca? ¿Mencione 3 criterios de cobertura? ¿A que hace referencia las técnicas Estructurales? ¿A que hace referencia las técnicas Funcionales?

authorStream Live Help