Capítulo 18 Pressman * Prueba de aplicaciones convencionales.
-
Upload
miguel-ramos-coronel -
Category
Documents
-
view
398 -
download
11
Transcript of Capítulo 18 Pressman * Prueba de aplicaciones convencionales.
Capítulo 18 Pressman
*Prueba de aplicaciones convencionales
*Tabla de Contenido
*Fundamentos de las pruebas de software.
*Pruebas de caja negra y caja blanca.
*Pruebas de caja blanca.
*Prueba de la ruta básica.
*Prueba de estructura de control
*Prueba de caja negra.
*Métodos de pruebas orientadas a objetos.
*Métodos de prueba aplicables al nivel de clase.
*Diseño de caso de prueba de interclase.
*Pruebas de entornos especializados: arquitectura y aplicaciones.
*Patrones de prueba.
*Importancia de las pruebas
*Las pruebas del software son un elemento crítico para la garantía de calidad del software.
*El costo asociado a un fallo del sistema es el principal aliciente para realizar pruebas.
*Antes de iniciar las pruebas se deben establecer los criterios de aceptación, para demostrar que se satisfacen las necesidades de la organización. *Si no se tienen, la evaluación puede ser subjetiva y el
resultado puede fallar
*Definiciones
*Probar NO ES demostrar que no existen errores en un programa.
*Prueba ES el proceso de ejecutar un programa con el fin de encontrar errores. (√)
*Caso de prueba (test case): «es un conjunto de entradas, condiciones de ejecución y resultados esperados desarrollados para un objetivo particular»
*Objetivos de las pruebas
1. El principal es sacar a la luz diferentes clases de errores, minimizando la cantidad de tiempo y esfuerzo invertido
2. Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrar un error no descubierto hasta entonces.
3. Una prueba tiene éxito si descubre un error no detectado hasta entonces.
*Principios de las pruebas
A todas las pruebas se les debe poder dar seguimiento hasta los requerimientos
Las pruebas se deben planificar mucho antes de que empiecen (antes de generar código)
El principio de Pareto (80/20) es aplicable a las pruebas (80% de los errores se encuentra en un 20% de todos los módulos del programa)
Deben comenzar por lo pequeño y progresar hacia lo grande.
No son posibles pruebas exhaustivasPara ser más eficaces, deben ser realizadas por un
equipo independiente
*Fundamentos de las pruebas de software
* Comprobabilidad es la facilidad con que se puede probar un software. Las siguientes características conducen a que el software sea comprobable:
1. Operatividad: “Mientras mejor funcione, más eficientemente se puede probar” Esto permite trabajar sin interrupciones
2. Observabilidad: “Lo que ves es lo que pruebas”. Los estados y variables son visibles, se pueden consultar durante la ejecución. La salida incorrecta se identifica fácilmente.
3. Controlabilidad: “Mientras más se pueda controlar, más se puede automatizar y optimizar las pruebas “ Se pueden generar posibles salidas a través de combinaciones de entradas y los formatos de entrada/salida son consistentes. Las pruebas se pueden reproducir y automatizar
*Fundamentos de las pruebas(cont)
4. Descomponibilidad: El sistema se construye a partir de módulos independientes que se pueden probar de manera independiente
5. Simplicidad: El software debe tener simplicidad funcional ( características mínimas necesarias para satisfacer los requerimientos), simplicidad estructural (arquitectura modular para evitar propagación de fallos), simplicidad de código (adoptar estándar de codificación para facilitar inspección y mantenimiento)
6. Estabilidad: Pocos cambios deben solicitarse durante las pruebas. “Cuanto menos cambios, menos interrupciones a las pruebas”
7. Comprensibilidad: “Cuanto más información tengamos, más inteligentes serán las pruebas” Comprensión y acceso a la documentación del diseño.
* Probando el software
Métodos
Estrategias
MétodoCaja blanca
(visión interna)
MétodoCaja negra(visión externa)
Visión interna
*Diseño de casos de prueba
*“Existe una sola regla para el diseño de casos de prueba, cubrir todas las posibilidades, sin hacer demasiados casos de prueba.” Tsuneo Yamaura
*Hay dos enfoques:
*Caja Blanca : Centrarse en la estructura de control del programa.
*Caja Negra: Centrarse en el comportamiento del programa.
Diseño de casos de prueba: enfoques
Funcional
Estructural Tomado de [2]
* Diseño de casos de prueba: enfoques
*Caja negra*Se conoce la función específica para la que fue
diseñado el producto
*Se llevan a cabo pruebas que demuestran que cada función es completamente operativa y al mismo tiempo busca errores en cada función
*Caja blanca*Conociendo el funcionamiento del producto se
desarrollan pruebas que aseguren que todo encaja, que la operación interna se ajusta a las operaciones y que todos los componentes internos se han probado adecuadamente
*Enfoque: Pruebas de Caja-Blanca
…la meta es asegurar que todas las sentencias y condiciones se hayan ejecutado al menos una vez
• Se examinan los detalles procedimentales
• Se comprueban los caminos lógicos
proponiendo casos de pruebas que ejerciten conjuntos específicos de condiciones y/o bucles
* Enfoque: Pruebas tipo Caja Blanca (cont.)
Mediante los casos de prueba de Caja Blanca se logra:1. Garantizar que todos los caminos independientes de
cada módulo se revisaron al menos una vez.2. Ejercitar todas las decisiones lógicas en sus lados
verdaderos y falsos.3. Ejecutar todos los ciclos en sus límites y dentro de sus
límites operativos.4. Revisar las estructuras internas de datos para asegurar
su validez.
* Enfoque: Pruebas de Caja-Blanca Pruebas Exhaustivas
Hay 10 posibles caminos! Si ejecutamos un caso de prueba por milisegundo, podría tomar 3,170 años probar este programa!!
14
Loop < 20 X
* Enfoque: Pruebas de Caja-Blanca Pruebas Selectivas
Loop < 20 X
Camino seleccionado
Las pruebas de caja blanca no se deben desechar como poco prácticas. Se pueden elegir y ejercitar una serie de caminos lógicos importantes
1. Crear grafo de flujo a partir del código a probar:
Cada nodo representa una o más sentencias procedimentales. Las aristas representan el flujo de control y deben terminar siempre en un nodo.
2. Determinar la complejidad ciclomática V(G) utilizando la siguiente fórmula:
V(G)= A-N+2. El resultado es el número de caminos independientes de la estructura de control del programa.
A = # de aristas del grafo de flujoN = # de nodos del grafo de flujo
Notación de gráfico o grafo de flujo: Pasos a seguir
Ejemplo de Creación deGrafo tomandocomo base el procedimientoMedia
Notación de gráfico o grafo de flujo: Pasos a seguir
1
2
3
4
5
6
7
8
9
10
1112
13
Grafo correspondiente al código del procedimientoMedia
i = 1;total, entrada = total, valido=0;Do while
Valor[i] <> -999
total entrada < 100
Incrementar totalentrada en 1
If valor[i] >= minimo
Valor[i] <= maximo
Then incrementar total.valido en 1
suma=suma+valor[i]
Else ignorarEndif
Incrementar I en 1
ENDDO
If total valido > 0
Then media = suma/total.valido;
Else media = -999
endif
Notación de gráfico o grafo de flujo: Pasos a seguir
Paso 3:Determinar un conjunto básico de caminos independientes:
Camino 1: 1-2-10-11-13Camino 2: 1-2-10-12-13Camino 3: 1-2-3-10-11-13Camino 4: 1-2-3-4-5-8-2-2…Camino 5: 1-2-3-4-5-6-8-9-2…Camino 6: 1-2-3-4-5-6-7-8-9-2…
Notación de gráfico o grafo de flujo: Pasos a seguir
*Paso 4:
*Preparar los casos de prueba que forzarán la ejecución de cada camino del conjunto básico:
*Camino 1:
*Valor (k) = entrada válida, donde k < i definida a continuación: Valor (i) = -999, donde 2 <= i <= 100
*Resultados esperado: media correcta sobre los k valores y totales adecuados.
Notación de gráfico o grafo de flujo: Pasos a seguir
*Matrices de gráficas
*El procedimiento para determina r el gráfico de flujo o determinar las rutas básicas es sensible a la automatización
*Una matriz cuadrada cuyo tamaño (# de filas y columnas) es igual al número de nodos en la gráfica de flujo. *Cada fila y columna corresponde a un nodo identificado, y las entradas de
la matriz corresponden a las conexiones (una arista) entre nodos.
*La matriz es solo una representación tabular de un gráfico, pero al agregar un enlace ponderado a cada entrada de matriz, la matriz se convierte en una herramienta poderosa para evaluar la estructura de control del programa durante las pruebas.
*En su forma más simple el enlace puede ser 1 o 0 (si existe o no) pero se les puede asignar valores más interesantes como:* Probabilidad de que un enlace se ejecutará, tiempo de procesamiento que
se emplea durante el recorrido de un enlace, memoria requerida durante el recorrido de un enlace, recursos requeridos durante el recorrido de un enlace
*Matrices de gráficas (cont.)
a
d b
c f
g e
Matriz de gráficaGráfica de flujo
1
a
Conectado al nodo
Nodo 1 2 3 4 5
1
2
3
4
5
3
4
2
5
b
c
d
e
f
g
* Otras pruebas tipo Caja Blanca
Prueba de condición◦Ejercita cada una de las condiciones lógicas del programa.
Los tipos de errores de una condición pueden ser: Error en operador, Error en variable, Error en paréntesis, Error
en expresión aritmética
◦Se han propuesto una serie de estrategias de pruebas de condiciones: Prueba de ramificaciones Prueba del dominio Prueba del operador relacional y de ramificación
* Otras pruebas tipo Caja Blanca
*Prueba del flujo de datos
*Selecciona caminos de prueba de acuerdo a la ubicación de las definiciones y los usos de las variables.
*Prueba de bucles
*Se centra en la validez de las construcciones de bucles: simples, anidados, concatenados y no estructurados
* Prueba de Bucles
BucleAnidado
BucleConcatenado Bucle
No estructurado
Bucle Simple
* Prueba de Bucles (cont.)Bucle simple (donde n es el número máximo de pasos
permitidos por el bucle)1. Pasar por alto totalmente el bucle2. Pasar una sola vez por el bucle3. Pasar dos veces por el bucle4. Hacer m pasos por el bucle, con m < n5. Hacer n-1, n, y n+1 pasos por el bucle
Bucles anidados:6. Comenzar por el bucle más interior7. Realizar pruebas de bucles simples para el bucle más
interno mientras mantiene los bucles externos en sus valores mínimos de parámetro de iteración
8. Procesar hacia fuera, manteniendo los bucles externos en sus valores mínimos, y probar los valores min+1, min-1, y los valores típicos.
.
*Prueba de Bucles (cont.)
*Bucles concatenados:
*Si los bucles son independientes se utiliza el enfoque de los bucles simples, sino se usa el enfoque de los bucles anidados.
*Bucles no estructurados:
*Se deben de evitar, y en caso de que aparezcan es necesario rediseñarlos.
* Pruebas de Caja Negra
Requerimientos
EventosEntradas
Salidas
*Pruebas Caja Negra*No son una alternativa, complementan las de Caja
Blanca *Intenta encontrar errores en:
1. Funciones incorrectas o faltantes2. Errores de interfaz3. Errores en las estructuras de datos o en el acceso a BD
externas4. Errores de comportamiento o rendimiento5. Errores de inicialización y terminación
*Pruebas Caja Negra
*Las pruebas se diseñan para responder a preguntas como:*Cómo se prueba la validez funcional?*Cómo se prueba el comportamiento y
rendimiento?*Qué clases de entrada harán buenos casos de
prueba?*El sistema es particularmente sensible a ciertos
valores de entrada?*Cómo se aislan las fronteras de una clase de
datos?*Qué tasas y volúmen de datos puede tolerar el
sistema?*Qué efecto tendrá sobre la operación algunas
combinaciones de datos?
*Pruebas tipo Caja Negra (cont.)
* Hay diversas técnicas:1. Métodos gráficos de prueba
2. Partición de equivalencia
3. Análisis de valores de límite
4. Prueba de la tabla ortogonal
*1. Métodos gráficos de prueba
1. Se modelan los objetos del sistema y las relaciones entre ellos mediante un grafo.
2. El siguiente paso es definir una serie de pruebas que verifiquen que todos los objetos tienen las relaciones esperadas entre ellos
3. Se ejercitan todos los objetos y sus relaciones para descubrir errores
*1. Métodos gráficos de prueba (cont.)
Objeto 1
Objeto 3
Enlace dirigido
Peso del enlace
Enlace no dirigido Enlaces paralelos
Peso del nodoObjeto 2
Representación del grafo
Ejemplo: Creación de un nuevo archivo en un procesador de texto.
1. Métodos gráficos de prueba(cont.)
Nuevo Archivo
Texto de documento
La selección del menú genera
(tiempo de generación <1.0 seg)
Se reperesenta como Contiene
Atributos:
Dimensiones de inicio:
Configuración o preferencias predeterminadas.
Color de fondo: blanco
Color de texto: color o preferencias predeterminadas
Ventana Documento
Permite la edición de
Una selección del menú en Nuevo Archivo genera una ventana del documento. El peso del nodo de Ventana Documento proporciona una lista de atributos de la Ventana, que se esperan cuando se genera una ventana. El peso del enlace indica que la ventana se tiene que generar en menos de 1.0 segundos.
*1. Métodos gráficos de prueba(cont.)
*Métodos de prueba de comportamiento que usan gráficas: *Modelado del flujo de transacción: nodos
representan pasos y los enlaces conexiones lógicas
*Modelado de estado finito: nodos representan estados y los enlaces transiciones.
*Modelado de flujo de datos: nodos representan objetos de datos y los enlaces transformaciones
*Modelado relacionado con el tiempo: nodos representan objetos del programa y los enlaces conexiones secuenciales
* 2. Método de Partición equivalente
*Divide las entradas de un programa en clases de datos (clases equivalentes) de los que se pueden derivar casos de prueba y en donde cada caso de prueba permite descubrir una clase de errores, lo que reduce el número total de casos de prueba que hay que desarrollar.
*Las clases equivalentes representan un conjunto de estados válidos o no válidos para la condición de entrada.
* 2. Ejemplo de particiones equivalentes
Tomado de [2]
* 2. Ejemplo de particiones equivalentes
“Estimación de inflación entre 15% Y 20%”, “capital entre $65M y $100M” y “tasa de interés entre 0% y 5%”
Tomado de [2]
*3. Método de Análisis de valores límite
*Es un complemento de la técnica de partición equivalente.
*En general se llega a Particiones equivalentes mediante la investigación de Valores límite que limitan las variables dentro de la aplicación
*Toma el conjunto de datos de entrada y examina solo en los límites, ya que ahí es donde es más probable que se produzcan los errores*Es decir, se eligen casos de prueba para
ejercitar los valores límite.
*En lugar de centrarse solo en las condiciones de entrada, se obtienen también casos de prueba para el campo de salida
41
*3. Método de Análisis de valores límite
Tomado de Braude pág. 400
Intervalo
Dentro del intervalo
En lo límites del intervalo
Fuera del intervalo
*3. Directrices Análisis de valores límite (cont.)
1.Si una entrada tiene un rango entre a y b, se diseñan casos de prueba para lo valores a y b, y para los que están por debajo y por encima de a y b.
2.Si una entrada especifica un número de valores, diseñar casos de prueba que ejerciten los valores máximo y mínimo y para los que están por debajo y por encima de ellos.
3.Aplicar las directrices 1 y 2 a los datos de salida.
4.Si hay estructuras de datos con límites preestablecidos diseñar casos de prueba que ejerciten la estructura de datos en sus límites
*4. Método de Prueba de Tabla Ortogonal
*Se aplica en problemas donde el dominio de entrada (número de parámetros) y la cantidad de valores que pueden tomar dichas entradas es relativamente pequeño, pero demasiado grande para posibilitar pruebas exhaustivas. *Detecta:
*Fallas de Modalidad Simple
*Fallas de Modalidad Doble
*Fallas Multimodales
*Es útil para encontrar errores asociados a fallos localizados (errores asociados con defectos de lógica dentro de un componente de software) causado por un parámetro o la interacción de 2 o más.
* 4. Método de Prueba de Tabla Ortogonal
*Por ej:*Programa con 3 parámetros de entrada tomando 4 valores diferentes. Se pueden considerar todas las permutaciones
(34 = 81) pero el esfuerzo requerido es relativamente alto.
*Solución: Crear tabla ortogonal L9*Los casos de prueba están uniformemente
dispersos por todo el dominio de prueba.
*4. Método de Prueba de Tabla Ortogonal (Cont.)
Caso de prueba
Parámetros de prueba
P1 P2 P3 P4
1 1 1 1 12 1 2 2 23 1 3 3 34 2 1 2 35 2 2 3 16 2 3 1 27 3 1 3 28 3 2 1 39 3 3 2 1
Tabla ortogonal L9
*Pruebas basadas en modelo
*Técnica de caja negra que usa la información del modelo de requerimientos (diagramas de estados) para generar casos de pruebas:1. Analiza un modelo de comportamiento existente
(evalúa casos de uso para entender interacción, identifica eventos, crea una secuencia y construye diagrama de estados)
2. Recorre el modelo de comportamiento y especifica entradas que forzarán a realizar la transición de estados
3. Revisa el modelo y observa las salidas esperadas
4. Ejecuta los casos de pruebas
5. Compara resultados
*Prueba de Entornos Especializados:
Arquitecturas y Aplicaciones
*Pruebas de interfaces gráficas de usuario
*Como los componente reutilizables son parte del desarrollo GUI el trabajo de diseño es más fáciles, pero la complejidad de las GUI ha crecido lo que conduce a más dificultad en el diseño y la ejecución de los casos de prueba
*Debido a que muchas GUI tienen la misma apariencia pueden derivarse una serie de pruebas estándar. Es posible usar gráficas de modelado de estado finito (ver filmina anterior)
*En la actualidad se hacen por medio de herramientas automatizadas
*Prueba de Entornos Especializados: Arquitecturas
y Aplicaciones (cont.)* Prueba de arquitectura cliente/servidor
* Desempeño durante la transacción, presencia de distintas plataformas, complejidad de comunicación en red, entre otras, complica probar el software
* La prueba se da en 3 niveles:
1. Cliente se prueba en modalidad “desconectada”
2. Cliente y servidor se prueban juntas, pero operaciones de red no se ejercitan de manera explícita
3. Se prueba todo, incluso operación y desempeño de la red
*Prueba de Entornos Especializados: Arquitecturas
y Aplicaciones (cont.)
* Suelen usarse los siguientes enfoques de prueba:* Pruebas de funcionalidad de la
aplicación
* Pruebas de servidor
* Pruebas de base de datos
* Pruebas de transacción
* Pruebas de comunicación de red
*Prueba de Entornos Especializados: Arquitecturas y
Aplicaciones (cont.)
*Prueba de la documentación y las funciones de ayuda
*Se aborda en 2 fases:
* revisión e inspección: examina claridad del documento
*Prueba en vivo: se emplea la documentación junto al programa
*Prueba de Entornos Especializados: Arquitecturas y
Aplicaciones (cont.)* Prueba de sistemas de tiempo real* Se deben tomar en cuenta casos de prueba de
manejo de eventos (procesamiento de interrupciones), temporización de datos y paralelismo entre tareas
* Se recomienda seguir los siguientes pasos:1. Prueba de tareas: Se prueba cada tarea de manera
independiente.
2. Prueba de comportamiento: Simula el comportamiento del sistema en tiempo real
3. Prueba de intertareas: Se prueban las tareas asíncrónicas, las que se comunican por medio de la cola de mensajes o el almacén de datos.
4. Prueba del sistema: Trata de descubrir errores en la interfaz software/hardware aplicando un rango completo de pruebas del sistema.
*Patrones de Prueba
*Describen bloques de construcción o situaciones frecuentes y que los responsables de probar el software pueden reutilizar al afrontar la prueba de un sistema nuevo o revisado
*Proporcionan además:*Terminología a los encargados de la resolución
de problemas
*Concentran la atención en las fuerzas que se encuentran detrás del problema
*Estimulan el razonamiento iterativo
*Referencias
[1] Pressman, Roger S. “Ingeniería de Software: Un enfoque práctico”, sexta edición, McGraw-Hill, 2005.
[2] Braud, Eric.”Ingeniería de Software – Una perspectiva Orientada a Objetos”, Alfaomega, 2003.