advertisement

Presentacion Pruebas

33 %
67 %
advertisement
Information about Presentacion Pruebas

Published on October 6, 2008

Author: dajigar

Source: slideshare.net

advertisement

INGENIERIA DE SISTEMAS MODELO DE PRUEBAS DE SOFTWARE DARWIN JIMENEZ CARLOS EDUARDO AGUIRRE

CONTENIDO 1. Definición de conceptos 2. Fundamentos de las pruebas de software 3. Objetivos de la prueba 4. Principios de la prueba 5. Facilidad de la prueba 6. Tipos de Pruebas 7. Proceso de Pruebas

CONTENIDO 8. Enfoques de pruebas • Prueba de la caja blanca • Prueba del camino básico • Prueba de la estructura de control • Prueba de la caja negra

1. DEFINICIONES DE CONCEPTOS 1. Falla (failure): Ocurre cuando un programa no se comporta de manera adecuada. 2. Falta (fault): Tiene lugar en el código del programa. La existencia de una falta en el programa puede generar una falla en el sistema.

1. Definiciones de Conceptos 3. Error: Es una acción humana que provoca que un software contenga una falta. Un error puede significar la existencia de una falta en el programa, lo cual hace que el sistema falle.

1. Definiciones de Conceptos No se puede garantizar ni probar que un sistema jamás falle, si no que sólo se puede demostrar que contiene faltas. No encontrar faltas no significa que la prueba haya sido exitosa. Solo lo es si se han encontrado faltas.

2. Fundamentos de las pruebas de Software • El ingeniero intenta construir el software partiendo de un concepto abstracto y llegando a una implementación tangible. • El ingeniero crea una serie de casos de prueba que intentan “demoler “ el software construido.

3. Objetivos de las pruebas • La prueba es un proceso de ejecución de un programa con la intención de descubrir un error. • Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrar un error no descubierto hasta entonces. • Una prueba tiene éxito si descubre un error no detectado hasta entonces.

4. Principios de la Prueba • A todas las pruebas se les debería poder hacer un seguimiento has los requisitos del cliente. • Las pruebas debería planificarse mucho antes de su inicio. • El principio de Pareto es aplicable a la prueba del Software: el 80% de todos los errores descubiertos durante las pruebas surgen al hacer un seguimiento de sólo el 20% de todos los módulos del programa.

4. Principios de la Prueba • Las pruebas deberían empezar por lo pequeño y progresar hacia lo grande. • No son posible las pruebas exhaustivas. • Para ser más efectivas, las pruebas deberían ser conducidas por un equipo independiente.

5. Facilidad de Prueba • Es simplemente lo fácil que se puede probar un programa de computadora. Como la prueba es tan profundamente difícil, merece la pena saber que puede hacer para hacerlo más sencillo. Debe existir una lista de comprobación que proporcione un conjunto de características que llevan a un software fácil de probar.

5. Facilidad de Prueba • Principios: • Operatividad: Cuanto mejor funcione más eficientemente se pude probar. • Observabilidad: Lo que ves es lo que pruebas. • Controlabilidad: Cuanto mejor podamos controlar el software, más se puede automatizar y optimizar.

5. Facilidad de Prueba • Principios: • Capacidad de Descomposición: Controlando el ámbito de las pruebas, podemos aislar más rápidamente los problemas y llevar a cabo mejores pruebas de regresión. • Simplicidad: Cuanto menos haya que probar, más rápidamente podremos probarlo.

5. Facilidad de Prueba • Principios: • Estabilidad: Cuanto menos cambios, menos interrupciones a las pruebas. • Facilidad de comprensión: Cuanta más información tengamos, más inteligentes serán las pruebas.

6. Tipos de Prueba Pruebas de Verificación: Se revisa si el resultado corresponde a la especificación del sistema, es decir, si se está construyendo el sistema de manera correcta. Pruebas de Validación: Se revisa si el resultado es realmente lo que el cliente quería.

6.1 Técnicas de Pruebas Pruebas de Regresión: Tiene como propósito verificar el sistema luego, de haberle introducido cambios, por ejemplo después de corregir una falta, de manera que se mantenga la funcionalidad especificada. Pruebas de Operación: Su objetivo es verificar el sistema en operación por un largo período bajo condiciones normales de uso.

6.1 Técnicas de Pruebas Pruebas de Escala Completa: Trata de verificar el sistema en su carga máxima mediante de los parámetros a su valor límite y la interconexión del sistema con un máximo de equipos y usuarios simultáneos. Pruebas de Rendimiento: Tiene como propósito medir la capacidad de procesamiento del sistema bajo diferentes cargas, incluyendo espacio de almacenamiento y utilización de la unidad de procesamiento.

6.1 Técnicas de Pruebas Pruebas de Sobrecarga: Pretende observar como se comparta el sistema cuando se le aplica una sobrecarga, más allá de las pruebas de escala completa y rendimiento. Pruebas negativa: Tiene como propósito medir el estrés del sistema en situaciones inesperadas, como casos de uso que normalmente no serían utilizados de manera simultánea.

6.1 Técnicas de Pruebas Pruebas basada en requisitos o prueba de casos de uso: Intenta llevar a cabo pruebas basadas directamente en la especificación de requisitos. Pruebas ergonómicas: Tienen como propósito probar los aspectos ergonómicos del sistema, en otras palabras, las interfaces hombre-máquina en el caso de que éstas existan. Ejemplo: Si los menús son lógicos y legibles, si los mensajes del sistema son visibles, si se puede entender los mensajes de falla, etc.

6.1 Técnicas de Pruebas Pruebas de documentación de usuario: Tiene como propósito probar la documentación de usuario, incluyendo el manual de éste y la documentación de mantenimiento y servicio. Pruebas de aceptación o de validación: Pretende lograr una revisión final por parte de la organización que solicitó el sistema, lo cual, a menudo, significa validación del sistema. Llamado Prueba Alfa o Prueba Beta.

6.1 Técnicas de Pruebas Pruebas de documentación de usuario: Tiene como propósito probar la documentación de usuario, incluyendo el manual de éste y la documentación de mantenimiento y servicio. Pruebas de aceptación o de validación: Pretende lograr una revisión final por parte de la organización que solicitó el sistema, lo cual, a menudo, significa validación del sistema. Llamado Prueba Alfa o Prueba Beta.

6.2 Nivel de Pruebas Pruebas de unidad: Mediante esta prueba sólo una unidad es probada como tal, como una clase, u paquete de servicio o un subsistema. Pruebas de Integración: En ella se verifica que las unidades trabajen juntas correctamente. Pruebas de Sistema: Verifica el sistema completo o su aplicación como tal. Se toma el punto de vista del usuario final y los casos de uso de pruebas.

PRUEBA DE UNIDAD Pruebas de procedimientos o subrutinas. En un sistema orientado a objetos se aplican en un nivel más alto, a partir de las clases. Una prueba de unidad consiste en una prueba estructural (o caja blanca), lo cual requiere conocer el diseño interno de la unidad, y una prueba de especificación(de caja negra, basada sólo en la especificación del comportamiento externamente visible de la unidad.

PRUEBA DE UNIDAD Prueba de Especificación o de Caja Negra: Tiene como propósito verificar las relaciones de entrada y salida de una unidad. Su objetivo es verificar que hace la unidad, pero sin averiguar como lo hace. Prueba basada en estado: Verifica las interacciones entre operaciones de una clase según cambios en los atributos de un objeto. Es necesario hacer pruebas del objeto de acuerdo con su ciclo de vida. Prueba Estructural o de Caja Blanca: Verifica que la estructura interna de la unidad sea correcta.

PRUEBA DE INTEGRACION Después de haber probado todas las unidades, éstas deben ser integradas en unidades más grandes hasta generar el sistema completo. El propósito de la prueba de integración es probar que las diferentes unidades trabajen juntas de manera apropiada.

7. Proceso de Pruebas El proceso de pruebas involucra consideraciones similares al del proceso de desarrollo, incluyendo estrategias, actividades y métodos, los cuales deben ser aplicados de manera concurrente con el proceso de desarrollo de software. 1. ESTRATEGIA DE LA PRUEBA: • Orden de Pruebas: Tienen como propósito definir en que momento y en que orden se aplicarán las pruebas. Diseño, implementación y operación del sistema.

7. Proceso de Pruebas ESTRATEGIA DE LA PRUEBA: • Orden de Pruebas: Existen dos enfoques generales para el orden en que se efectuarán las pruebas:  De arriba hacia abajo: Se deben desarrollar inicialmente las interfaces entre subsistemas, para probar protocolos de alto nivel antes de ir a probar los niveles inferiores.  De abajo hacia arriba: Certificar primero las unidades de bajo nivel y luego las interfaces entre ellos.

7. Proceso de Pruebas 1. ESTRATEGIA DE LA PRUEBA: • Alcance de pruebas: Tiene como propósito identificar el tipo, número y casos de pruebas que se aplicarán para revisar los diferentes aspectos del sistema • Automatización de la Prueba: Tiene como propósito reducir el esfuerzo y costo de las pruebas mediante automatización del proceso o aspectos de él.

7. Proceso de Pruebas 2. PLANEACION DE LA PRUEBA: Comienza con el establecimiento de las estrategias de pruebas, lo que incluye la cuestión si estás se harán automática o manualmente y si existen programas y datos de prueba que puedan ser usados, posiblemente modificados o desarrollados de nueva cuenta  Estrategia de la prueba  Alcance de la prueba  Recursos

7. Proceso de Pruebas 3. CONSTRUCCION DE LA PRUEBA: Se describe cada prueba y su propósito de manera general y detallada. Se debe describir exactamente cómo se deberá ejecutar el caso de prueba, de manera que personas no familiarizadas con la aplicación puedan ejecutar el caso.  Ambiente de desarrollo o real  Tipo de software  Tipo de hardware  Equipo de prueba  Versión del sistema

7. Proceso de Pruebas 3. EJECUCION DE LA PRUEBA: Durante esta etapa se utiliza la especificación del diseño de prueba y los reportes de ésta. La estrategia es aplicar de manera paralela el mayor caso de pruebas posibles. Se Ejecutan las pruebas automáticas y manuales de manera correspondiente y se indican los resultados esperados. Si alguna prueba falla, se interrumpe su aplicación y se anota el resultado para luego analizar el defecto y corregirlo.

PRUEBA DE LA ESTRUCTURA DE CONTROL • Las pruebas son de gran importancia en la garantía de la calidad del software. • Estas variantes amplían la cobertura de la prueba y mejoran la calidad de la prueba de caja blanca. – Prueba de Condición – Prueba de Flujo de Datos – Prueba de Bucles

Prueba de condición • Método de diseño de casos de prueba que ejercita las condiciones lógicas contenidas en el módulo de un programa. • Esta prueba asegura en que cada condición del programa no contenga errores. • Una condición simple es una variable lógica o una expresión relacional.

• La expresión relacional adquiere la siguiente forma: E1 <operador relacional>E2; donde E1 y E2 son expresiones aritméticas y <operador relacional> puede ser “<, <=, =, >, >=, ≠” • Una condición compuesta está formada por dos o más condiciones simples, operadores lógicos o paréntesis. Los operadores lógicos permitidos en una condición compuesta incluye OR(|), AND(&), NOT. • Una condición sin expresiones relacionadas se le denomina expresión lógica.

• Si una condición es incorrecta, entonces es incorrecto al menos un componente de la condición. Los errores de una condición pueden ser: – Error en operador lógico – Error en variable lógica – Error en paréntesis lógico – Error en operador relacional – Error en expresión aritmética

• Se han propuesto series de estrategias de prueba de condiciones: – Prueba de ramificaciones: Para una condición compuesta C, es necesario ejecutar al menos una vez las ramas verdadera y falsa de C y cada condición simple de C. – Prueba del dominio: Requiere la realización de 3 o 4 pruebas para una expresión relacional. E1 <operador relacional> E2 se requieren tres pruebas para comprobar que el valor de E1 es mayor, igual o menor que el valor de E2. Por ejemplo si el operador relacional es incorrecto y E1 y E2 son correctos, entonces estas tres pruebas garantizan la detección de un error del operador relacional.

Prueba de flujo de datos • Selecciona caminos de prueba de un programa de acuerdo con la ubicación de las definiciones y los usos de las variables del programa. • Las estrategias de prueba de flujo de datos son útiles para seleccionar caminos de prueba de un programa que contenga sentencias if o bucles anidados. • Necesitamos conocer la estructura de cada condición o bloque (seleccionando un camino del programa, determinamos si el camino es factible para el programa)

Prueba de bucles • Técnica de prueba de caja blanca que se centra en la validez de las construcciones de bucles. • Se pueden definir 4 clases diferentes de bucles: – Simples, – Concatenados, – Anidados, – No estructurados

Bucles Bucles anidados Bucles Bucles concatenados Bucles no simples estructurados

Bucles simples: • Se les debe aplicar el siguiente conjunto de pruebas, donde n es el número máximo de pasos permitidos por el bucle 1. Pasar por alto totalmente el bucle 2. Pasar una sola vez por el bucle 3. Pasar dos veces por el bucle 4. Hacer m pasos por el bucle con m<n 5. Hacer n-1 y n+1 pasos por el bucle

Bucles anidados: • Si se extendiera el enfoque de los bucles simples a los bucles anidados, el número de posibles pruebas aumentaría geomé- tricamente a medida que aumenta el nivel de anidamiento. Esto llevaría a un número imprescindible de pruebas.

• Se sugiere un enfoque que ayuda a reducir el número de pruebas 1. Comenzar por el bucle más interior 2. Llevar a cabo las pruebas de bucles simples 3. Progresar hacia fuera, llevando a cabo pruebas para el siguiente bucle 4. Continuar hasta que se hayan probado todos los bucles

Bucles concatenados: • Se pueden probar mediante el enfoque definido para los bucles simples, mientras cada uno de los bucles sea independiente del resto. Bucles no estructurados: • Esta clase de bucles se debe rediseñar para que se ajusten a las construcciones de programación estructurada.

PRUEBA DE CAJA NEGRA • Se centra en los requisitos funcionales del software. • Se trata de un enfoque complementario que intenta descubrir diferentes tipos de errores de los métodos de caja blanca.

• La prueba de caja negra intenta encontrar errores de las siguientes categorías: – Funciones incorrectas o ausentes – Errores de interfaz – Errores es estructura de datos o en accesos a bases de datos externas – Errores de rendimiento – Errores de inicialización y de terminación

Método de prueba basados en grafos • La prueba empieza creando un grafo de objetos y sus relaciones y después diseñando una serie de pruebas que cubran el grafo de manera que se ejerciten todos los objetos y sus relaciones para descubrir los errores. • Estos casos de prueba están diseñados para intentar encontrar errores en algunas de las relaciones. • El grafo ayudaría a identificar aquellos bucles que hay que probar.

Partición equivalente • Es un método de prueba de caja negra, se dirige a la definición de casos de prueba que descubran clases de errores, reduciendo así el número total de casos de prueba que hay que desarrollar. • El objetivo de partición equivalente es reducir el posible conjunto de casos de prueba en uno más pequeño, un conjunto manejable que evalúe bien el software.

• El diseño de casos de prueba para la partición equivalente se basa en una evaluación de las clases de equivalencia para una condición de entrada. • Una clase de equivalencia representa un conjunto de estados válidos o no válidos para condiciones de entrada (es un valor numérico específico, un rango de valores, un conjunto de valores relacionados o una condición lógica).

Sitio alquiler de películas • Rango de valores – Alquiler para personas mayores 18 años • Valor – Nº de películas que se alquilan • Conjunto de valores específico – Películas (Acción, Comedia, Infantil, Intriga) • Lógico – ¿Es socio?

Análisis de Valores Límite (AVL) • Es una técnica de diseño de casos de prueba que complementa la prueba de Partición Equivalente. En lugar de realizar la prueba con cualquier elemento de la partición equivalente, se escogen los valores en los extremos de la clase. • Por ejemplo: si una condición de entrada especifica un rango delimitado por los valores a y b, se deben diseñar casos de prueba para los valores a y b y para los valores que se encuentran por debajo y por encima.

Prueba de Comparación • Aplicación en sistemas de alta fiabilidad • Desarrollos paralelos • Intercambio de casos de prueba • Desarrollo del software, las versiones de la aplicación se ejecutan en equipos independientes, usando las mismas especificaciones. • Se deben probar todas las versiones con los mismos datos, para asegurar que proporcionan una salida idéntica.

PRUEBA DE ENTORNOS Y APLICACIONES ESPECIALIZADAS • Pruebas de interfaces gráficas de usuario • Prueba de documentación y de ayuda – Es importante para la aceptación del programa. – Revisar la guía de usuario o funciones de ayuda en línea. • Prueba de sistemas de tiempo real – Prueba de tareas – Prueba de comportamiento – Prueba intertareas – Prueba del sistema

JTS 2008 V JORNADA DE TESTEO DE SOFTWARE 2008 2,3 Y 4 DE ABRIL DE 2008 VALENCIA ESPAÑA VIDEO BLOG DE LA JORNADA

BIBLIOGRAFIA Ingenieria de Software Orientada a Objetos.-Alfredo Weitzenfeld.- Editorial Thomson

Add a comment

Related pages

Presentación prueba - YouTube

Standard YouTube License; ... Los caracoles prueba de audio, imagenes y presentacion en vivo - Duration: 18:29. TheFidel1990 20,168 views. 18:29
Read more

Presentación pruebas - YouTube

Presentación pruebas Raquel B. Subscribe Subscribed Unsubscribe 0 0. Loading... Loading... Working... Add to. Want to watch this again later?
Read more

Presentación de prueba - Google Slides

Presentación de prueba Present Share. The version of the browser you are using is no longer supported. Please upgrade to a supported browser.Dismiss.
Read more

Presentación de la Prueba en Materia Penal - Monografias.com

Pruebas Valederas e Ilícitas. Efectos de la Prueba Ilícita. Orden de presentación de la prueba. Anticipos de prueba. Forma de presentar la prueba.
Read more

Presentacion en pdf repaso prueba me

El portal Aragonés de la Comunicación Aumentativa y Alternativa reune pictogramas, imágenes, materiales y software que facilitan la comunicación de ...
Read more

Presentacion en pdf repaso prueba me

Temas. ESPECIFICACIONES DE EXAMEN. Trate de presentarla bajo condiciones semejantes a las del día del examen. Al organizar la intervención en México, el ...
Read more

Fechas presentacion icfes 20

... publicación de los 23 Dic 2015 Fechas-Saber-11-2016-Icfes-calendario-presentacion-2. ... de presentacion de de las pruebas de estado ICFES ...
Read more

Presentación de prueba - Video Dailymotion

Presentación de prueba. 03:50 The Sea Beast. 00:48 Kapit. 02:40 Episode 3: Making of Paris d'amis: Fin de tournage. 00:23 Baalachi.mov. 00:30 ...
Read more