Pruebas
1
1. Descripción y objetivos 9 Las pruebas son prácticas a realizar en diversos momentos de la vida del sistema de información para verificar: 8 El correcto funcionamiento de los componentes del sistema. 8 El correcto ensamblaje entre los distintos componentes. 8 El funcionamiento correcto de las interfaces entre los distintos subsistemas que lo componen y con el resto de sistemas de información con los que se comunica. 8 El funcionamiento f ncionamiento correcto del sistema integrado de hardware y software en el entorno de operación. 8 Que el sistema cumple con el funcionamiento esperado y permite al usuario de dicho sistema que determine su aceptación, desde el punto de vista de su funcionalidad y rendimiento. Que los cambios sobre un componente p de un sistema de 8 Q información, no introducen un comportamiento no deseado o errores adicionales en otros componentes no modificados.
2
1. Descripción y objetivos 9 El diseño de casos de prueba para la verificación del software puede significar un esfuerzo considerable (cerca del 40% del tiempo total de desarrollo) 9 Verificación y Validación 8 Verificación: V ifi ió ⌂ ¿estamos construyendo el producto correctamente?
8 Validación: ⌂ ¿estamos construyendo el producto correcto?
9 Recursos: http://www.aptest.com/resources.html 3
2. Tipologías. 9Pruebas 9 9Pruebas b 9Pruebas Pruebas 9Pruebas 9Pruebas 9Pruebas
Unitarias. d Integración. de del Sistema. de Implantación. de Aceptación. de Regresión. Regresión
4
2. Tipologías. Unitarias 9 Las pruebas unitarias constituyen la prueba inicial de un sistema y las demás pruebas d b apoyarse sobre deben b ellas. ll 9 Tipologías: 8E Enfoque f estructural t t l o de d caja j blanca. bl S verifica Se ifi la estructura interna del componente con independencia de la funcionalidad establecida para el mismo. Por tanto, no se comprueba la corrección de los resultados si éstos se p producen. 8 Enfoque funcional o de caja negra. Se comprueba el correcto funcionamiento de los componentes del sistema de información, información analizando las entradas y salidas y verificando que el resultado es el esperado. 5
2. Tipologías. Integración 9El objetivo de las pruebas de integración es verificar el correcto ensamblaje entre los distintos componentes una vez que han sido probados unitariamente con el fin de comprobar que interactúan correctamente a través de sus interfaces, tanto internas como externas, externas cubren la funcionalidad establecida y se ajustan a los requisitos no funcionales especificados en las verificaciones correspondientes. 6
2. Tipolog铆as. Del Sistema. 9Las pruebas del sistema tienen como objetivo ejercitar profundamente el sistema comprobando la integraci贸n del sistema de informaci贸n globalmente,, g verificando el funcionamiento correcto de las interfaces entre los distintos subsistemas que lo componen y con el resto de sistemas de informaci贸n con los que se comunica. 7
2. Tipologías. Del Sistema. 9 9 9 9 9 9 9
9 9 9
Pruebas funcionales. Dirigidas a asegurar que el SI realiza correctamente todas las funciones que se han detallado en las especificaciones dadas por el usuario del sistema. Pruebas de comunicaciones. Determinan que las interfaces entre los componentes del p remotos,, como locales. sistema funcionan adecuadamente,, tanto a través de dispositivos Asimismo, se han de probar las interfaces hombre/máquina. Pruebas de rendimiento. Determinar que los tiempos de respuesta están dentro de los intervalos establecidos en las especificaciones del sistema. Pruebas de volumen. Examinar el funcionamiento del sistema cuando está trabajando con grandes volúmenes de datos, datos simulando las cargas de trabajo esperadas. esperadas Pruebas de sobrecarga. Comprobar el funcionamiento del sistema en el umbral límite de los recursos, sometiéndole a cargas masivas. El objetivo es establecer los puntos extremos en los cuales el sistema empieza a operar por debajo de los requisitos establecidos. p de datos. Consisten en demostrar q que el sistema p puede Pruebas de disponibilidad recuperarse ante fallos, tanto de equipo físico como lógico, sin comprometer la integridad de los datos. Pruebas de facilidad de uso. Consisten en comprobar la adaptabilidad del sistema a las necesidades de los usuarios, tanto para asegurar que se acomoda a su modo habitual de trabajo como para determinar las facilidades que aporta al introducir datos en el sistema y trabajo, obtener los resultados. Pruebas de operación. Consisten en comprobar la correcta implementación de los procedimientos de operación, incluyendo la planificación y control de trabajos, arranque y rearranque del sistema, etc. P Pruebas b d entorno. de t V ifi Verificar l las i t interacciones i d l sistema del i t con otros t sistemas i t d t del dentro d l mismo entorno. Pruebas de seguridad. Consisten en verificar los mecanismos de control de acceso al sistema para evitar alteraciones indebidas en los datos.
8
2. Tipolog铆as. De Implantaci贸n. 9El objetivo es comprobar el funcionamiento correcto del sistema integrado de hardware y software en el entorno de operaci贸n, y permitir al que,, desde el p punto de vista de usuario q operaci贸n, revise el sistema en base al cumplimiento de los requisitos no funcionales especificados.
9
2. Tipolog铆as. De Aceptaci贸n. 9El 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, p , desde el punto de vista de su funcionalidad y rendimiento. rendimiento
10
2. Tipologías. De Regresión. 9El objetivo de las pruebas de regresión es eliminar el efecto onda, onda es decir, decir comprobar que los cambios sobre un componente de un sistema de no introducen un información,, comportamiento no deseado o errores adicionales en otros componentes no modificados 9(R 9(Repetición i ió de d casos de d prueba) b )
11
3. Pruebas de Caja Blanca 9 Objetivo: Probar el funcionamiento de la estructura de control de las unidades de programaci贸n. 8 Garantizan que se ejecutan una vez por lo menos todos los caminos independientes de cada m贸dulo. m贸dulo 8 Prueban todas las decisiones l贸gicas en sus vertientes i verdadera d d y falsa. f l 8 Ejecutan todos los bucles. 8 Ejecutan todas las estructuras internas.
12
3. Pruebas de Caja Blanca 9Pruebas Caja Blanca: 8 Prueba P b d dell Camino C i Bá i Básico 8 Prueba de la Estructura de Control. ⌂ Prueba de condición ⌂ Prueba de flujo de datos ⌂ Prueba de bucles
13
3. Pruebas de Caja Blanca. Camino Básico 9 Propuesta por Tom McCabe (1976) 9 Objetivo: Definir un conjunto básico de caminos de ejecución. 9 Pasos: 8 A partir del diseño o del código fuente, dibujar el grafo de flujo g j asociado 8 Se calcula la complejidad ciclomática del grafo 8 Se determina un conjunto j básico de caminos independientes 8 Se preparan los casos de prueba que obliguen a la ejecución de cada camino del conjunto básico
14
3. Pruebas de Caja Blanca. Camino Bรกsico Secuencia While
If Case
Until
15
3. Pruebas de Caja Blanca. Camino Básico 9Complejidad ciclomática de un grafo de flujo V(G) establece el número de caminos independientes 9P d 9Puede calcularse l l d de t tres f formas alternativas: 8 El número de regiones del grafo de flujo 8 V(G) = A - N + 2, ⌂ donde A es el número de aristas y N es el número de nodos
8 V(G) = P + 1, 1 ⌂ donde P es el número de nodos predicado 16
3. Pruebas de Caja Blanca. Camino Bรกsico 9V(G) = 4
11
2, 3
4, 4, 55
66
77
88 99 10 10
9El El grafo de la figura tiene cuatro regiones. 911 aristas i t - 9 nodos d + 2 =4 93 nodos predicado + 1 = 4
11 11
17
3. Pruebas de Caja Blanca. Camino Bรกsico 1 2 4 5
3
6 7 8
9
Camino 1: 1-9 Camino 2: 1-2-3-8-1-9 Camino 3: 1-2-4-5-7-8-1-9 Camino 4: 1-2-4-6-7-8-1-9 18
3. Pruebas de Caja Blanca.
Estructuras de Control
Bucles anidados Bucles simples
Bucles concatenados Bucles no estructurados
19
3. Pruebas de Caja Blanca.
Estructuras de Control
9 Prueba de Bucles. 8 Objetivo: Validar las construcciones de bucles. 8 Tipos: ⌂ Simples. – Aplicar, siendo n el número máximo de pasos permitidos: 1. 2. 3. 4 4. 5.
Saltarse el bucle. Ejecutarlo sólo una vez. Pasar dos veces. Hacer m pasadas, pasadas siendo m<n. m<n Hacer n-1 y n+1 pasos en el bucle.
⌂ Concatenados 1.Comenzar por el bucle más interno. 2. Probarlo como un bucle simple. 3. Progresar hacia fuera, manteniendo los bucles internos en sus valores típicos. 4. Continuar hasta probarlos todos.
⌂ Anidados – Si el contador del primer bucle no se utiliza como valor inicial del segundo bucle, pueden probarse como bucles simples. – Si no es así deberá aplicarse el enfoque de anidados.
20
4. Pruebas de Caja Negra. 9 Las pruebas de caja negra se centran en los requisitos funcionales del software 9 Comprobar que la funcionalidad del programa o sistema es completamente operativa. 9 Que Q l entrada la t d se acepta t de d forma f adecuada d d y la l salida es correcta. 9 Verificar que la integridad de la informaci贸n interna se mantiene. 9 Errores t铆picos encontrados: 8 8 8 8 8
Funciones incorrectas o ausentes Errores de interfase Errores de estructura de datos o acceso a BD externas Errores de rendimiento Errores de inicializaci贸n y de terminaci贸n 21
4. Pruebas de Caja Negra. 9Algunas técnicas que se basan en la filosofía de la caja negra son: 8 Partición Equivalente 8 Análisis de Valores Límite Causa-Efecto Efecto 8 Grafos de Causa 8 Pruebas de Comparación
22
4. Pruebas de Caja Negra.
Partición Equivalente
9 Método que divide el campo de entrada de un programa en clases de datos 9 Una condición de entrada es un valor numérico específico, específico un rango de valores, valores un miembro de un conjunto de valores o lógica 9 Una U clase l d equivalencia de i l i representa un conjunto de estados válidos y no válidos para una condición di ió de d entrada d 9 La prueba de partición equivalente se basa en evaluar las clases de equivalencia para una condición de entrada 23
4. Pruebas de Caja Negra. Condición de Entrada
Tipo
Partición equivalente.
Clase Equivalencia Válida
Códi banco Código b Lógica Ló i ((puede d 1: 1 En E blanco bl estar o no) Si está 2: 100<= Código banco <= 999 es Rango
Clase Equivalencia No Válida
33: Un U valor l no numérico éi 4: Código banco < 100 5: Código banco > 999
Código Códi sucursal
R Rango
6 0 <= Código 6: Códi sucursall <= 7: 7 Código Códi sucursall < 1000 9999 8: Código sucursal >= 9999
Nº Cuenta
Valor
9: Cualquier número de cinco 10: Número de más de cinco dígitos dígitos 11: Número de menos de cinco dígitos
Clave
Valor
12:
Orden
Conjunto, con 15: “” comportamiento 16: “Transferencia” di ti t distinto 17 “Retroceso” 17: “R t ”
Cualquier cadena de 13: Cadena de menos de 5 caracteres alfanuméricos posiciones de 5 posiciones 14: Cadena de más de 5 posiciones i i 18: Cadena distinta de blanco y de las válidas
24
4. Pruebas de Caja Negra.
Valores límite
9 La técnica de Análisis de Valores Límites selecciona casos de prueba que ejerciten los valores l l límite 9 Complementa l l la prueba b d de partición i i equivalente. En lugar de realizar la prueba con cualquier elemento de la partición equivalente, se escogen los valores en los bordes de la clase 9 Se derivan tanto casos de prueba a partir de l las condiciones di i d entrada de d como con las l d de salida 25
26