Está en la página 1de 51

Universidad Politcnica del Oeste Mariscal Sucre

INGENIERIA DE SOFTWARE II

Fuentes:
Pressman, Roger. Ingeniera de Software. Un Enfoque Prctico. Captulo 16. V Edicin. McGraw Hill. 1997. Sommerville, Ian. "Ingeniera del Software", Captulo 23. 7 Edicin, Pearson-Addison Wesley, 2005.

Ingeniera de Software II. Trayecto III. Trimestre III. Mdulo: Pruebas y Validacin de Software. Unidad 1. Tcnicas de Prueba

Universidad Politcnica del Oeste Mariscal Sucre

CONTENIDO
UNIDAD 1. TECNICAS DE PRUEBA 1) Objetivos y Principios de las Pruebas. 2) Tipos de Fallas. 3) Estrategias de Prueba 4) Pruebas de Desarrollos WEB 5) Tcnicas de Construccin de Pruebas 6) Inspecciones y Revisiones. 7) Instrumentos y Herramientas para pruebas.

Ingeniera de Software II. Trayecto III. Trimestre III. Mdulo: Pruebas y Validacin de Software. Unidad 1. Tcnicas de Prueba

Universidad Politcnica del Oeste Mariscal Sucre

OBJETIVOS DE LAS PRUEBAS La prueba es un proceso de ejecucin con la intencin de descubrir errores. Tiene los siguientes objetivos:
Asegurar una probabilidad muy alta de descubrir un nuevo error.

Una prueba no asegura la ausencia de errores,  Un caso de prueba no debe ser redundante. slo puede demostrar que pruebas de propsito similar.  Debe ser el mejor de un conjunto deestos existen  No debe ser ni muy sencillo ni excesivamente complejo: es mejor realizar cada prueba de forma separada si se quiere probar diferentes casos.
Descubrir errores no detectados hasta entonces.

Ingeniera de Software II. Trayecto III. Trimestre III. Mdulo: Pruebas y Validacin de Software. Unidad 1. Tcnicas de Prueba

Universidad Politcnica del Oeste Mariscal Sucre

PRINCIPIOS DE LAS PRUEBAS


Se debe hacer un seguimiento hasta ver si se cumplen los requisitos del cliente. Las pruebas debern planificarse mucho antes de que empiecen. El principio de Pareto es aplicable a la prueba del software.
 El 80% de los errores est en el 20% de los mdulos.  Hay que identificar esos mdulos y probarlos muy bien

Empezar por lo pequeo y progresar hacia lo grande. No son posibles las pruebas exhaustivas. Son ms eficientes las pruebas dirigidas por un equipo independiente.

Ingeniera de Software II. Trayecto III. Trimestre III. Mdulo: Pruebas y Validacin de Software. Unidad 1. Tcnicas de Prueba

Universidad Politcnica del Oeste Mariscal Sucre

TECNICAS DE PRUEBA
1. Facilitan una gua sistemtica para disear pruebas con el fin de:
Comprobar la lgica interna de los componentes del software. Verificar los dominios de entradas y salidas de los programas con el fin de descubrir errores en la funcionalidad, comportamiento y rendimiento.

2. Son realizadas por el Ingeniero de Software, se van incorporando personal con experticias en prueba a medida que avanza el proceso. 3. Son importantes porque permite encontrar y corregir los errores antes de entregar el software al cliente. 4. Existen dos perspectivas diferentes para aplicarlas: Lgica Interna (Caja Blanca) y comprobacin de los requisitos funcionales (Caja Negra) 5. Debemos ser disciplinados al aplicarlas.

Ingeniera de Software II. Trayecto III. Trimestre III. Mdulo: Pruebas y Validacin de Software. Unidad 1. Tcnicas de Prueba

Universidad Politcnica del Oeste Mariscal Sucre

PORQUE PROBAR?
Las fallas de software ocasionan graves prdidas econmicas; stos son 100 a 1000 veces ms costosos de encontrar y reparar despus de la construccin. Evitar plazos y presupuestos incumplidos, insatisfaccin del usuario, escasa productividad y mala calidad en el software producido y finalmente la prdida de clientes. Automatizar el proceso de pruebas consigue reducciones de hasta un 75% en el costo de la fase de mantenimiento.

Ingeniera de Software II. Trayecto III. Trimestre III. Mdulo: Pruebas y Validacin de Software. Unidad 1. Tcnicas de Prueba

Universidad Politcnica del Oeste Mariscal Sucre

FACILIDAD DE PRUEBA

La facilidad de prueba del software es simplemente la facilidad con la que se puede probar un programa de computadora. (James Bach, 1994.
comp.software-en)

Desarrollar con la facilidad de prueba en mente

Permite disear casos de prueba ms fcilmente

Ingeniera de Software II. Trayecto III. Trimestre III. Mdulo: Pruebas y Validacin de Software. Unidad 1. Tcnicas de Prueba

Universidad Politcnica del Oeste Mariscal Sucre

FACILIDAD DE PRUEBA (2)


Caractersticas que hacen un software fcil de probar: Operatividad. Cuanto mejor funcione, ms Eficientemente se puede probar. Observabilidad. Lo que ves es lo que pruebas. Controlabilidad.
Cuanto mejor podamos controlar el software, ms se puede automatizar y optimizar. Controlando el mbito de las pruebas, podemos aislar ms rpidamente los problemas y llevar a cabo mejores pruebas de regresin.

Capacidad de descomposicin.

Simplicidad. Cuanto menos haya que probar, ms rpidamente podremos probarlo. Estabilidad. Cuanto menos cambios, menos interrupciones a las pruebas. Facilidad de Comprensin:
sern las pruebas. Cunta ms informacin tengamos, ms inteligentes

Ingeniera de Software II. Trayecto III. Trimestre III. Mdulo: Pruebas y Validacin de Software. Unidad 1. Tcnicas de Prueba

Universidad Politcnica del Oeste Mariscal Sucre

DEFINICIONES (1)
Prueba (test): Actividad en la cual se somete a un sistema o uno de sus componentes a una evaluacin de los resultados que arroja en base a la ejecucin de ste en condiciones especificadas. Caso de Prueba (test case): Conjunto de atributos a los cuales se les asignan valores especficos de acuerdo con una serie de condiciones dadas ante un escenario, y se ha identificado un resultado esperado una vez que han sido procesados por el sistema. Son la esencia de la prueba. Escenarios de Prueba: Es una coleccin de condiciones que poseen un conjunto de datos procesados por el sistema para verificar su comportamiento. Se pueden derivar diferentes casos de prueba para un mismo escenario

Ingeniera de Software II. Trayecto III. Trimestre III. Mdulo: Pruebas y Validacin de Software. Unidad 1. Tcnicas de Prueba

Universidad Politcnica del Oeste Mariscal Sucre

DEFINICIONES (2)

Responsable: Daniela Prez Mdulo: Ventas Pantalla: Facturacin

Situacin 1

CONDICIONES
Caso 1 Caso 2

Antigedad del Monto de Status del Cliente > 2 la Venta Producto Aos >10.000
3 3 12000 5000 Promocin Promocin

Resultado Esperado
Descuento 10% Sin Descuento

Resultado Obtenido
Descuento 10% Descuento 10%

Error
No S

Ingeniera de Software II. Trayecto III. Trimestre III. Mdulo: Pruebas y Validacin de Software. Unidad 1. Tcnicas de Prueba

Universidad Politcnica del Oeste Mariscal Sucre

DEFINICIONES (3)
Guiones (scripts): Elemento que contiene la secuencia de pasos o tareas que se deben realizar para ejecutar la prueba. Puede funcionar para diferentes escenarios, dependiendo de las condiciones especificadas y de la operatividad del sistema. Error: Accin humana que produce o genera un resultado incorrecto. Defecto: Es la manifestacin de un error en el software. Un defecto es encontrado porque causa una FALLA, la cul es una desviacin del servicio o resultado esperado. Criterios de Aceptacin: Es la definicin de los resultados que esperan obtener los usuarios en los procesos realizados por el sistema. Deben ser diseados y aprobados por los usuarios antes de ejecutar las pruebas, sirven de base para el diseo de los casos de prueba.
Ingeniera de Software II. Trayecto III. Trimestre III. Mdulo: Pruebas y Validacin de Software. Unidad 1. Tcnicas de Prueba

Universidad Politcnica del Oeste Mariscal Sucre

DEFINICIONES (4)
Verificacin: Determinar si los productos de una fase dada satisfacen las condiciones impuestas al inicio de la fase. Consiste en responder la pregunta: Estamos construyendo correctamente el producto?. El cdigo que estamos construyendo debe estar en armona con la especificacin que hemos tomado del usuario. El resultado final del desarrollo software debe concordar con la especificacin (requisitos) del sistema, por lo que debemos asegurarnos que el desarrollo final coincida con dicha especificacin

Ingeniera de Software II. Trayecto III. Trimestre III. Mdulo: Pruebas y Validacin de Software. Unidad 1. Tcnicas de Prueba

Universidad Politcnica del Oeste Mariscal Sucre

DEFINICIONES (5)

Validacin: Evaluacin de un sistema o uno de sus componentes durante o al final de su desarrollo para determinar si satisface los requisitos. Responde a la pregunta: Estamos construyendo el producto correcto? El resultado final del desarrollo software se debe ajustar a lo que el usuario quera (sus necesidades)? En la mayora de las ocasiones el producto desarrollado no casa con la ideas del cliente, normalmente porque a ste suele faltarle capacidad tcnica de expresin.

Ingeniera de Software II. Trayecto III. Trimestre III. Mdulo: Pruebas y Validacin de Software. Unidad 1. Tcnicas de Prueba

Universidad Politcnica del Oeste Mariscal Sucre

DEFINICIONES (6)

Completitud: Nos da una idea del grado de fiabilidad de las pruebas y por consiguiente la fiabilidad del software. Depuracin: Ejecucin controlada del software que nos permite corregir un error (Ejemplo: Usar el debugger de un
determinado lenguaje, uso de policias).

Ingeniera de Software II. Trayecto III. Trimestre III. Mdulo: Pruebas y Validacin de Software. Unidad 1. Tcnicas de Prueba

Universidad Politcnica del Oeste Mariscal Sucre

TIPOS DE PRUEBA (1)


En funcin de qu conocemos:

Pruebas de Caja Negra: No conocemos la implementacin del cdigo, slo la interfaz. Tan slo podemos probar dando distintos valores a las entradas y salidas. Pruebas de Caja Blanca: Conocemos el cdigo (la implementacin de ste) que se va a ejecutar y podemos definir las pruebas que cubran todos los posibles caminos del cdigo.

Ingeniera de Software II. Trayecto III. Trimestre III. Mdulo: Pruebas y Validacin de Software. Unidad 1. Tcnicas de Prueba

Universidad Politcnica del Oeste Mariscal Sucre

TIPOS DE PRUEBA (2)


Segn el Grado de Automatizacin:

Pruebas Manuales: son las que se hacen normalmente al programar o las que ejecuta una persona con la documentacin generada durante la codificacin (Ejemplo: Comprobar cmo se visualiza el
contenido de una pgina web en dos navegadores diferentes).

Pruebas Automticas: se usa un determinado software para sistematizar las pruebas y obtener los resultados de las mismas
(Ejemplo: Verificar un mtodo de bsqueda).

Ingeniera de Software II. Trayecto III. Trimestre III. Mdulo: Pruebas y Validacin de Software. Unidad 1. Tcnicas de Prueba

Universidad Politcnica del Oeste Mariscal Sucre

TIPOS DE PRUEBA (3)


En funcin de qu se prueba: Pruebas Unitarias: Se aplican a un componente del software. Podemos considerar como componente (elemento indivisible) a una funcin, una clase, una librera, etc. Pruebas de Integracin: Consiste en construir el sistema a partir de los distintos componentes y probarlo con todos integrados. Estas pruebas deben realizarse progresivamente. Busca determinar como el software convive con su homlogos, es decir, evala el flujo de informacin a travs de las aplicaciones con las cuales el sistema debe intercambiar informacin. Pruebas Funcionales: Son aquellas que se aplican sobre el sistema funcionando a fin de comprobar si se cumple con la especificacin (normalmente a travs de los casos de uso).
COMPRUEBAN LA EFICACIA DEL SISTEMA
Ingeniera de Software II. Trayecto III. Trimestre III. Mdulo: Pruebas y Validacin de Software. Unidad 1. Tcnicas de Prueba

Universidad Politcnica del Oeste Mariscal Sucre

TIPOS DE PRUEBA (4)


En funcin de qu se prueba:

Pruebas de Regresin: Consiste en volver a aplicar pruebas que se haban superado anteriormente (Ejemplo: Pruebas de integracin). Pruebas de Aceptacin: Son realizadas por los usuarios, todas las anteriores las lleva a cabo el equipo de desarrollo. Podemos distinguir entre dos pruebas:
- Pruebas Alfa: las realiza el usuario en presencia del los desarrolladores del proyecto haciendo uso de una mquina preparada para tal fin. - Pruebas Beta: Las realiza el usuario despus que el equipo de desarrollo les entregue una versin casi definitiva del producto.

Ingeniera de Software II. Trayecto III. Trimestre III. Mdulo: Pruebas y Validacin de Software. Unidad 1. Tcnicas de Prueba

Universidad Politcnica del Oeste Mariscal Sucre

TIPOS DE PRUEBA (5)


En funcin de qu se prueba: Pruebas de Volumen o Rendimiento: Se ejecutan para evaluar la capacidad de respuesta y rendimiento del sistema ante la ejecucin de varios procesos ejecutados concurrentemente por varios usuarios, con la finalidad de determinar si es necesario la optimizacin de algn componente. Utiliza una cantidad de datos mayor que las pruebas anteriores, simulando la participacin de varios usuarios en un ambiente de trabajo real. Pruebas de Carga y Stress: Son parecidas a las de volumen, la diferencia radica en que utilizan una mayor cantidad de datos para su ejecucin, su finalidad es evaluar al mximo el rendimiento del sistema. Crea condiciones exageradas de procesamiento. Permiten desarrollar planes de contingencia y pronosticar futuras actualizaciones.
Ingeniera de Software II. Trayecto III. Trimestre III. Mdulo: Pruebas y Validacin de Software. Unidad 1. Tcnicas de Prueba

Universidad Politcnica del Oeste Mariscal Sucre

TIPOS DE PRUEBA (6)


En funcin de qu se prueba: Pruebas de Falla del Sistema: En estas pruebas lo que se busca es determinar cmo es el comportamiento del sistema ante posibles fallas, bien sean internas (propias del software) o externas (fallas elctricas, sistema operativo, problemas de hardware, entre otras). Lo importante es lograr que el sistema pueda recuperarse luego de cualquier falla de la mejor manera posible y seguir funcionando normalmente.

Ingeniera de Software II. Trayecto III. Trimestre III. Mdulo: Pruebas y Validacin de Software. Unidad 1. Tcnicas de Prueba

Universidad Politcnica del Oeste Mariscal Sucre

PRUEBAS UNITARIAS (1)


Razones para hacerlas

Son exhaustivas: Implica hacer pruebas por clase, funcin, etc., es decir, por la unidad mnima que se haya considerado. Permiten probar parte del cdigo sin esperar el desarrollo completo: Lo que permite la aplicacin del desarrollo interactivo. Proporcionan ms confianza para modificar el cdigo: Se pierde el miedo a hacer modificaciones y volver inconsistente el sistema. Mejoran la API: Podemos darnos cuenta de fallos en la interfaz de la clase en pasos prematuros, evitando as el costo que supone una modificacin en fases ms avanzadas. Sirven como documentacin de ejemplos de uso de la clase. Motivan: Cuando se ve que el cdigo pasa todas las pruebas.

Ingeniera de Software II. Trayecto III. Trimestre III. Mdulo: Pruebas y Validacin de Software. Unidad 1. Tcnicas de Prueba

Universidad Politcnica del Oeste Mariscal Sucre

PRUEBAS UNITARIAS (2)


Qu se busca probar? Segn el tipo de componente: Funciones individuales o mtodos de objeto: probar las entradas y las salidas y comprobar que los valores obtenidos son los esperados. Clases de objetos:
Hacer pruebas aisladas de operaciones Probar tambin las secuencias de las operaciones. Se tratan igual que una clase de objeto Hay que tener en cuenta si son distribuidos.

Componentes

Ingeniera de Software II. Trayecto III. Trimestre III. Mdulo: Pruebas y Validacin de Software. Unidad 1. Tcnicas de Prueba

Universidad Politcnica del Oeste Mariscal Sucre

PRUEBAS UNITARIAS (3)


Qu se busca probar? Segn el aspecto en que nos centremos: Pruebas unitarias de cdigo aislado:
Independientes del resto del sistema. Se implementan sustituyendo componentes por mocks, debido a que en la prctica las clases interactan entre s la mayora de las veces.

Pruebas unitarias de integracin:


Se prueba cada componente, pero dentro del todo de la aplicacin, no como elemento aislado

Ingeniera de Software II. Trayecto III. Trimestre III. Mdulo: Pruebas y Validacin de Software. Unidad 1. Tcnicas de Prueba

Universidad Politcnica del Oeste Mariscal Sucre

PRUEBAS UNITARIAS (4)


Tipos Pruebas Estructurales: Son pruebas de caja blanca. Pruebas de Particiones: Son pruebas de caja negra. Consisten en dividir las posibles entradas y salidas en conjuntos de caractersticas similares, identificando los casos especiales. Al probar valores debe considerarse lo siguiente:
Probar siempre los lmites. Cuando tenemos listas, vectores, tablas:  Probar listas de un solo valor y listas vacas.  Probar siempre distintos tamaos.  Comprobar primer elemento, el elemento central y el ltimo elemento. Pasar null en vez del objeto.

Ingeniera de Software II. Trayecto III. Trimestre III. Mdulo: Pruebas y Validacin de Software. Unidad 1. Tcnicas de Prueba

Universidad Politcnica del Oeste Mariscal Sucre

PRUEBAS UNITARIAS (5)


Desarrollo Conducido por Pruebas (TDD Test-Drive Development)

Ingeniera de Software II. Trayecto III. Trimestre III. Mdulo: Pruebas y Validacin de Software. Unidad 1. Tcnicas de Prueba

Universidad Politcnica del Oeste Mariscal Sucre

PRUEBAS DE CAJA BLANCA (1)


Se basa en un minucioso examen de las estructuras de control utilizadas en el diseo procedimental para obtener los casos de prueba, con el fin de:
Garantizar que se ejecuten al menos una vez todos los caminos independientes de cada mdulo. Ejecutar todas las decisiones lgicas (V/F). Ejecutar todos los bucles en sus lmites. Comprobar la validez de las estructuras de datos internas.

1. 2. 3.

Los errores son inversamente proporcionales a la posibilidad de que se ejecute un camino del programa. Un camino lgico puede ejecutarse de forma normal, aunque pensemos que tiene pocas posibilidades. Los errores tipogrficos son aleatorios

Ingeniera de Software II. Trayecto III. Trimestre III. Mdulo: Pruebas y Validacin de Software. Unidad 1. Tcnicas de Prueba

Universidad Politcnica del Oeste Mariscal Sucre

PRUEBA DE CAJA BLANCA (2)


Prueba del Camino Crtico Permite obtener una medida de la complejidad lgica de un diseo procedimental, con el objetivo de usar esa medida como gua para la definicin de un conjunto bsico de caminos de ejecucin. Pasos: 1. Generar el Grafo de Flujo a partir del cdigo. 2. Calcular la Complejidad Ciclomtica 3. Determinar un conjunto de caminos linealmente independientes 4. Generar Casos de Prueba

Ingeniera de Software II. Trayecto III. Trimestre III. Mdulo: Pruebas y Validacin de Software. Unidad 1. Tcnicas de Prueba

Universidad Politcnica del Oeste Mariscal Sucre

PRUEBAS DE CAJA BLANCA (3)


Prueba del Camino Crtico Grafo de Flujo Representa el flujo de control de un programa Notacin:

Secuencia Condicin IF Bucle (While) Bucle (Hasta) Seleccin Multiple (Case)

   

Cada crculo (NODO) representa una o ms instrucciones, sin bifurcaciones. Cada Flecha se denomina ARISTA. Una arista debe terminar en un nodo. Las reas delimitadas por aristas y nodos se denominan regiones.
Ingeniera de Software II. Trayecto III. Trimestre III. Mdulo: Pruebas y Validacin de Software. Unidad 1. Tcnicas de Prueba

Universidad Politcnica del Oeste Mariscal Sucre

PRUEBA DE CAJA BLANCA (3)


Prueba del Camino Crtico Grafo de Flujo. Representa el flujo de control lgico Ejemplo:
Aristas
1 2,3 2 6 3 7 4 8 9 10 5 10 1

Regin 2
8

4,5

Regin 1
9

Regin 3

6 7

Regin 4
11

11

Ingeniera de Software II. Trayecto III. Trimestre III. Mdulo: Pruebas y Validacin de Software. Unidad 1. Tcnicas de Prueba

Universidad Politcnica del Oeste Mariscal Sucre

PRUEBA DE CAJA BLANCA (4)


Prueba del Camino Crtico Complejidad Ciclomtica. Es una mtrica que proporciona una medicin cuantitativa de la complejidad lgica de un programa. Define el nmero de CAMINOS INDEPENDIENTES del conjunto bsico de un programa, a fin de determinar el lmite superior para el nmero de pruebas que deben realizarse. Est basada en la teora de grafos. Se puede calcular de tres formas.

Ingeniera de Software II. Trayecto III. Trimestre III. Mdulo: Pruebas y Validacin de Software. Unidad 1. Tcnicas de Prueba

Universidad Politcnica del Oeste Mariscal Sucre

PRUEBA DE CAJA BLANCA (5)


Prueba del Camino Crtico Complejidad Ciclomtica. Formas de Clculo 1. V(G) = NR donde NR es el Nmero de Regiones del grafo. 2. V(G) = A N + 2 donde A es el nmero de aristas del grafo y N es el nmero de nodos. 3. V(G)= P + 1 donde P es el nmero de nodos predicado que contiene el grafo (Un nodo predicado es cada nodo que contiene una condicin)

Ingeniera de Software II. Trayecto III. Trimestre III. Mdulo: Pruebas y Validacin de Software. Unidad 1. Tcnicas de Prueba

Universidad Politcnica del Oeste Mariscal Sucre

PRUEBA DE CAJA BLANCA (5)


Prueba de Condicin Se centra en la prueba de cada una de la las condiciones de un programa. Existen 2 tipo de condiciones. Simples y Compuestas. Condicin Simple Es una variable lgica o una expresin relacional, posiblemente precedida por el operador lgico NOT. Tiene la siguiente forma: E1 <Operador Relacional> E2
donde E1 y E2 son Variables, Constantes o Expresiones Aritmeticas y Operador Relacional puede ser uno de los siguientes: >, >=, <, <=, =, <>

Condicin Compuesta Est formada por 2 o ms condiciones simples, a travs de los operadores lgicos AND, OR, NOT y parntesis lgicos

Ingeniera de Software II. Trayecto III. Trimestre III. Mdulo: Pruebas y Validacin de Software. Unidad 1. Tcnicas de Prueba

Universidad Politcnica del Oeste Mariscal Sucre

PRUEBA DE CAJA BLANCA (5)


Prueba de Condicin Errores que se pueden presentar en una condicin: 1. Error en el operador lgico. 2. Error en la variable lgica. 3. Error en el parntesis lgico. 4. Error en el operador relacional. 5. Error en la expresin aritmtica.

Ingeniera de Software II. Trayecto III. Trimestre III. Mdulo: Pruebas y Validacin de Software. Unidad 1. Tcnicas de Prueba

Universidad Politcnica del Oeste Mariscal Sucre

PRUEBA DE CAJA BLANCA (5)


Prueba de Condicin. Estrategias 1. Prueba de Ramificaciones. 2. Prueba de Dominio.
Para una condicin compuesta C, se ejecuta al menos una vez las ramas V y F de C, as como cada condicin simple. Requiere la realizacin de 3 4 pruebas para una expresin relacional. Para un expresin con n variables, se deben realizar 2n pruebas posibles (n>0)

3. Prueba del operador relacional y de ramificacin (TAI). Tienen 2 ventajas: 1. La cobertura de la prueba de una condicin es sencilla. 2. La cobertura de la prueba de las condiciones de un programa da una orientacin para generar pruenas adicionales de tal programa.

Ingeniera de Software II. Trayecto III. Trimestre III. Mdulo: Pruebas y Validacin de Software. Unidad 1. Tcnicas de Prueba

Universidad Politcnica del Oeste Mariscal Sucre

PRUEBA DE CAJA BLANCA (6)


Prueba de Bucles Es una tcnica de prueba de caja blanca que se centra exclusivamente en la validez de las construcciones de bucles. Se pueden definir cuatro clases diferentes de bucles, tal como se ilustra en la figura 6.

Figura 6. Clases de Bucles


Ingeniera de Software II. Trayecto III. Trimestre III. Mdulo: Pruebas y Validacin de Software. Unidad 1. Tcnicas de Prueba

Universidad Politcnica del Oeste Mariscal Sucre

PRUEBA DE CAJA BLANCA (6)


Prueba de Bucles Bucles simples. A los bucles simples se les debe aplicar el siguiente conjunto de pruebas, donde n es el nmero mximo 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, n y n+1 pasos por el bucle

Ingeniera de Software II. Trayecto III. Trimestre III. Mdulo: Pruebas y Validacin de Software. Unidad 1. Tcnicas de Prueba

Universidad Politcnica del Oeste Mariscal Sucre

PRUEBA DE CAJA BLANCA (6)


Prueba de Bucles Bucles Anidados 1. Comenzar por el bucle ms interior. Establecer o configurar los dems bucles con sus valores mnimos. 2. Llevar a cabo las pruebas de bucles simples para el bucle ms interior, mientras se mantienen los parmetros de iteracin (por ejemplo, contador del bucle) de los bucles externos en sus valores mnimos. Aadir otras pruebas para valores fuera de rango o excluidos. 3. Progresar hacia fuera, llevando a cabo pruebas para el siguiente bucle, pero manteniendo todos los bucles externos en sus valores mnimos y los dems bucles anidados en sus valores tpicos. 4. Continuar hasta que se hayan probado todos los bucles.

Ingeniera de Software II. Trayecto III. Trimestre III. Mdulo: Pruebas y Validacin de Software. Unidad 1. Tcnicas de Prueba

Universidad Politcnica del Oeste Mariscal Sucre

PRUEBA DE CAJA BLANCA (6)


Prueba de Bucles Bucles concatenados. Se pueden probar como bucles simples, mientras cada uno de los bucles sea independiente del resto. Si hay dos bucles concatenados y se usa el controlador del bucle 1 como valor inicial del bucle 2, entonces los bucles no son independientes. Cuando los bucles no son independientes, se recomienda usar el enfoque aplicado para los bucles anidados.

Ingeniera de Software II. Trayecto III. Trimestre III. Mdulo: Pruebas y Validacin de Software. Unidad 1. Tcnicas de Prueba

Universidad Politcnica del Oeste Mariscal Sucre

PRUEBA DE CAJA BLANCA (6)


Prueba de Bucles Bucles no estructurados. Siempre que sea posible, esta clase de bucles se deben redisear para que se ajusten a las construcciones de programacin estructurada.

Ingeniera de Software II. Trayecto III. Trimestre III. Mdulo: Pruebas y Validacin de Software. Unidad 1. Tcnicas de Prueba

Universidad Politcnica del Oeste Mariscal Sucre

PRUEBA DE CAJA NEGRA (1)

Tambin denominada prueba de comportamiento, se centran en los requisitos funcionales del software. Permite obtener un conjuntos de condiciones de entrada que ejerciten completamente todos los requisitos funcionales de un programa. Se de un enfoque complementario que intenta descubrir diferentes tipos de errores que los mtodos de caja blanca.

Ingeniera de Software II. Trayecto III. Trimestre III. Mdulo: Pruebas y Validacin de Software. Unidad 1. Tcnicas de Prueba

Universidad Politcnica del Oeste Mariscal Sucre

PRUEBA DE CAJA NEGRA (1)


Mtodos de prueba basados en grafos El primer paso en la prueba de caja negra es entender los objetos que se modelan en el software y las relaciones que conectan a estos objetos. Una vez que se ha llevado a cabo esto, el siguiente paso es definir una serie de pruebas que verifiquen que todos los objetos tienen entre ellos las relaciones esperadas En este mtodo: Se crea un grafo de objetos importantes y sus relaciones. Se disea una serie de pruebas que cubran el grafo de manera que se ejerciten todos los objetos y sus relaciones para descubrir errores.

Ingeniera de Software II. Trayecto III. Trimestre III. Mdulo: Pruebas y Validacin de Software. Unidad 1. Tcnicas de Prueba

Universidad Politcnica del Oeste Mariscal Sucre

PRUEBA DE CAJA NEGRA (1)


Mtodos de prueba basados en grafos Los nodos representan los pasos de alguna transaccin. Los nodos representan diferentes observables por el usuario. estados del
RM3

software

Los enlaces representan las conexiones lgicas entre los pasos. los enlaces representan las transiciones que ocurren para moverse de estado a estado Los nodos son objetos de programa y los enlaces son las conexiones secuenciales entre esos objetos. Los pesos de enlace se usan para especificar los tiempos de ejecucin requeridos al ejecutarse el programa.

Ingeniera de Software II. Trayecto III. Trimestre III. Mdulo: Pruebas y Validacin de Software. Unidad 1. Tcnicas de Prueba

Slide 42 RM3 por ejemplo, los pasos necesarios para una reserva en una lnea area usando un servicio en lnea
Rafael Matos, 1/10/2010

Universidad Politcnica del Oeste Mariscal Sucre

PRUEBA DE CAJA NEGRA (1)


Mtodos de Prueba Basados en Grafos. Ejemplo

Tomado de Ingenieria.del.Software.Un.Enfoque.Practico.-.Roger.S.Pressman.V.Edicion.McGraw-Hill

Ingeniera de Software II. Trayecto III. Trimestre III. Mdulo: Pruebas y Validacin de Software. Unidad 1. Tcnicas de Prueba

Universidad Politcnica del Oeste Mariscal Sucre

PRUEBA DE CAJA NEGRA (1)


Particin Equivalente Mtodo de prueba de Caja Negra que divide el dominio de entrada de un programa en un conjunto de clases de datos de los que se pueden derivar casos de prueba. Un caso de prueba ideal descubre de forma inmediata una clase de errores (por ejemplo, proceso incorrecto de todos los datos de carcter) que, de otro modo, requeriran la ejecucin de muchos casos antes de detectar el error genrico. La particin equivalente se dirige a la definicin de casos de prueba que descubran clases de errores, reduciendo as el nmero total de casos de prueba que hay que desarrollar.

Ingeniera de Software II. Trayecto III. Trimestre III. Mdulo: Pruebas y Validacin de Software. Unidad 1. Tcnicas de Prueba

Universidad Politcnica del Oeste Mariscal Sucre

PRUEBA DE CAJA NEGRA (1)


Particin Equivalente
1. Se identifican las clases de equivalencia. Las clases de equivalencia son identificadas tomando cada condicin de entrada (generalmente una oracin o una frase en la especificacin) y repartindola en dos o ms grupos. Las clases de equivalencia vlidas representan entradas vlidas al programa, y las clases de equivalencia invlidas que representan el resto de los estados posibles de la condicin (es decir, valores errneos de la entrada). 2. Se define los casos de prueba. El segundo paso es el uso de las clases de equivalencia para identificar los casos de prueba. El proceso es como sigue: se asigna un nmero nico a cada clase de equivalencia. Hasta que todas las clases de equivalencia vlidas han sido cubiertas por los casos de prueba, se escribe un nuevo caso de prueba que cubra la clase de equivalencia vlida. Y por ltimo hasta que los casos de prueba hallan cubierto todas las clases de equivalencia invlidas, se escribe un caso de la prueba que cubra una, y solamente una, de las clases de equivalencia invlidas descubiertas.

Ingeniera de Software II. Trayecto III. Trimestre III. Mdulo: Pruebas y Validacin de Software. Unidad 1. Tcnicas de Prueba

Universidad Politcnica del Oeste Mariscal Sucre

PRUEBA DE CAJA NEGRA (1)


Particin Equivalente. Ejemplo Supongamos un cdigo formado por 2 partes, la primera un prefijo opcional de 3 dgitos, que empiece por 9 y la contrasea que sea una cadena de hasta 6 caracteres que empiece necesariamente por una letra y que puede contener letras, dgitos y el smbolo $ Prefijo Contrasea

Se pueden disear casos de prueba, cada uno de los cuales representa a un conjunto de casos de prueba

Ingeniera de Software II. Trayecto III. Trimestre III. Mdulo: Pruebas y Validacin de Software. Unidad 1. Tcnicas de Prueba

Universidad Politcnica del Oeste Mariscal Sucre

PRUEBA DE CAJA NEGRA (1)


Particin Equivalente
PREFIJO PUEDE SER: representa a entrada en blanco 743 representa a nmero <900 935 representa a nmero entre 900 y 999 1983 representa a nmero >999 8pW representa a cadena que contiene carcter no dgito CONTRASEA PUEDE SER: representa a entrada en blanco 4a2cd$ representa a cadena que empieza por dgito y que slo Contiene letras, dgitos y $ 4a;2c$ representa a cadena que empieza por dgito y que contiene algn carcter no letra, dgito o $ $ab4$b representa a cadena que no empieza por dgito y que slo contiene letras, dgitos y $ b$$;a5 representa a cadena que no empieza por dgito y que contiene algn carcter no letra, dgito o $
Ingeniera de Software II. Trayecto III. Trimestre III. Mdulo: Pruebas y Validacin de Software. Unidad 1. Tcnicas de Prueba

Universidad Politcnica del Oeste Mariscal Sucre

PRUEBA DE CAJA NEGRA (1)


Prueba de los Valores Lmite (PVL) Los errores suelen situarse en los lmites. Si la entrada se encuentra en el rango a..b entonces hay que probar con los valores a -1, a, a + 1, b - 1, b y b + 1. Si la entrada es un conjunto de valores entonces hay que probar con los valores max-1, max, max+1, min-1, min y min+1

Ingeniera de Software II. Trayecto III. Trimestre III. Mdulo: Pruebas y Validacin de Software. Unidad 1. Tcnicas de Prueba

Universidad Politcnica del Oeste Mariscal Sucre

PRUEBA DE CAJA NEGRA (1)


Prueba de los Valores Lmite (PVL) Condiciones sublmite. Las condiciones limite normales son las ms obvias de descubrir. Estas son definidas en la especificacin o son evidentes al momento de utilizar el software. Algunos limites, sin embargo , son internos al software, no son necesariamente aparentes al usuario final pero an as deben ser probadas por el probador. Estas son conocidas como condiciones sublmites o condiciones lmite internas. Una condicin sublmite comn es la tabla de caracteres ASCII, por ejemplo, si se est evaluando una caja de texto que acepta solamente los caracteres AZ y az, se debe incluir los valores en la particin invlida justo debajo de y encima de esos caracteres de la tabla ASCII,

Ingeniera de Software II. Trayecto III. Trimestre III. Mdulo: Pruebas y Validacin de Software. Unidad 1. Tcnicas de Prueba

Universidad Politcnica del Oeste Mariscal Sucre

ADIVINANDO EL ERROR
Dado un programa particular, se conjetura, por la intuicin y la experiencia, ciertos tipos probables de errores y entonces se escriben casos de prueba para exponer esos errores. Es difcil dar un procedimiento para esta tcnica puesto que es en gran parte un proceso intuitivo y ad hoc. La idea bsica es enumerar una lista de errores posibles o de situaciones propensas a error y despus escribir los casos de prueba basados en la lista. Por ejemplo, la presencia del valor 0 en la entrada de un programa es una situacin con tendencia a error. Por lo tanto, puede ser que se escriba los casos de prueba para los cuales los valores particulares de la entrada tienen valor 0 y para qu valores particulares de la salida se colocan de manera forzada a 0.

Ingeniera de Software II. Trayecto III. Trimestre III. Mdulo: Pruebas y Validacin de Software. Unidad 1. Tcnicas de Prueba