calidad del software cap2
TRANSCRIPT
Ingeniería de Software
CAPITULO 2CAPITULO 2
Fundamentos de las pruebas del software
Técnicas de Prueba del SoftwareTécnicas de Prueba del Software
Por Julio C. Alsina
Ingeniería de Software
Pruebas de SoftwarePruebas de Software
Probar es el proceso de ejercitar un programa con el objetivo específico de encontrar errores antes de entregarlo al usuario final
Ingeniería de Software
Caracteristicas para la Facilidad de Caracteristicas para la Facilidad de Pruebas de SoftwarePruebas de Software
• Operabilidad – cuanto mejor funcione, con mayor eficacia podrá probarse
• Observación – lo que se ve es lo que se prueba, los estados y las variables pueden consultarse durante la ejecución, identificando salidas inconsistentes
• Controlabilidad – el grado al cual la prueba puede ser automatizada y optimizada
• Descomponibilidad – el SW se construye con modulos independientes que tambien se prueban independientemente
• Simplicidad – reducir arquitecturas complejas y lógicas para simplificar las pruebas
• Estabilidad – a menos cambios, menos alteracion en pruebas• Comprensión – del diseño de arq.y dependencia de
componentes internos y externos
Ingeniería de Software
Características de una Buena PruebaCaracterísticas de una Buena Prueba
• Una buena prueba tiene una elevada probabilidad de encontrar un error. El responsable de aplicar la prueba debe comprender correctamente el Sw
• Una buena prueba no es redundante. Los recursos son limitados y no hay razón para realizar una prueba que tenga el mismo propósito que otra
• Una buena prueba debe ser “la mejor de su clase”. Usar aquella que tiene la mayor probabilidad de descubrir un tipo completo de errores
• Una buena prueba no debe ser ni muy simple ni demasiado compleja. Cada prueba debe ejecutarse por separado
Ingeniería de Software
Qué muestran las pruebasQué muestran las pruebas
errorserrors
requirements conformancerequirements conformance
performanceperformance
an indicationan indicationof qualityof quality
ErroresConformidad de requerimientos
Rendimiento
Indicador de calidad
Ingeniería de Software
Quien prueba el Software?Quien prueba el Software?
DesarrolladorDesarrollador Pruebas independientesPruebas independientes
Entiende el sistema pero probará “suavemente” y está guiado por la “entrega”
Debe aprender acerca del sistema, pero intentará romperlo y está guiado por la calidad
Ingeniería de Software
Pruebas exhaustivasPruebas exhaustivas
loop < 20 Xloop < 20 XExisten 1014 caminos posibles! Si ejecutamos una prueba cada milisegundo, tomaría años probar este programa!!!
Ingeniería de Software
Pruebas selectivasPruebas selectivas
loop < 20 Xloop < 20 X
Selected pathSelected pathCamino seleccionado
Ingeniería de Software
Pruebas de SoftwarePruebas de Software
Métodos
Estrategias
Métodos deCaja Blanca
Métodos deCaja Negra
Basado en un exámen del detalle procedimental. Prueba las rutas
lógicas del SW y la colaboración entre componentes
Se aplican sobre la interfaz del SW. Examina el aspecto
funcional sin analizar estructura lógica interna
Ingeniería de Software
Diseño del caso de Diseño del caso de pruebaprueba
OBJETIVOOBJETIVO
CRITERIOCRITERIO
LIMITACIONESLIMITACIONES
Descubrir erroresDescubrir errores
De una manera completaDe una manera completa
En mínimo tiempo y esfuerzoEn mínimo tiempo y esfuerzo
Ingeniería de Software
Pruebas de Caja Pruebas de Caja BlancaBlanca
… nuestros objetivos son: • Asegurar que todas las declaraciones y condiciones han sido ejectuadas por lo menos una vez• Ejercitar lado verdadero y falso de todas las decisiones• Ejecutar todos los bucles en sus limites y dentro de limites operac.• Ejercitar estructuras de datos internos para asegurar su validez
Ingeniería de Software
Por qué cubrir?Por qué cubrir?
• Errores lógicos e interpretaciones incorrectas son inversamente proporcionales a la probabilidad de ejecución de un camino
• A menudo creemos que un camino probablemente no será ejecutado; de hecho, la realidad es que a menudo es intuitivo
• Los errores tipográficos son al azar; es probable que un camino no probado contendrá algunos
Ingeniería de Software
Prueba de Camino de Prueba de Camino de BaseBase
Primero, calculamos la complejidad ciclomática:
Nro. de decisiones simples + 1O
Nro. de áreas incluídas + 1
En ese caso, V(G) = 4
Complejidad Ciclomatica: es una métrica de Sw que proporciona una medida cuantitativa de la complejidad lógica de un programa
Ingeniería de Software
Complejidad CiclomáticaComplejidad Ciclomática
Los módulos en este rango son mas propensos a los errores
V(G)
Módulos
Un número de estudios de la industria han indicado que cuanto mas alto el V(G), mas alta será la probabilidad de errores.
Ingeniería de Software
11
22
3344
55 66
77
88
Prueba de Camino de BasePrueba de Camino de Base
Para continuar, derivamos los caminos independientes:
Dado que V(G) = 4, hay cuatro caminos
Camino 1: 1,2,3,6,7,8Camino 2: 1,2,3,5,7,8Camino 3: 1,2,4,7,8Camino 4: 1,2,4,7,2,4,…7,8
Finalmente, derivamos los casos de prueba para ejercitar estos caminos garantizando que se ejecuta cada instrucc.al menos una vez.
Ingeniería de Software
Prueba de Camino de Prueba de Camino de BaseBase
• No es necesario un diagrama de flujo, pero el diagrama ayudará cuando se tracen los caminos de programa
• Contar cada prueba lógica simple, componer pruebas de 2 o mas
• Prueba de camino de base debería aplicarse a los módulos críticos
Ingeniería de Software
Pruebas de Estructuras de ControlPruebas de Estructuras de Control
• Prueba de Condición: intenta ejercitar las condiciones lógicas contenidas en un modulo de programa.
• Prueba de Flujo de Datos: selecciona rutas de prueba de un programa de acuerdo a ubicación de las definiciones y uso de variables del programa.
• Prueba de Bucles: se concentra en la validez de la construccion de los bucles o ciclos.
Ingeniería de Software
Pruebas de BuclesPruebas de Bucles
BucleBucle AnidadoAnidado
Bucles Bucles ConcatenadosConcatenados Bucles no Bucles no
estructuradosestructurados
BucleBucleSimple Simple
Ingeniería de Software
Pruebas de Bucles: Bucles SimplesPruebas de Bucles: Bucles Simples
Condiciones SimplesCondiciones Simples
1.1. Saltar el bucle completoSaltar el bucle completo2.2. Solo uno pasa a través del bucleSolo uno pasa a través del bucle3.3. Dos pasan a través del bucleDos pasan a través del bucle4.4. m pasa a través del bucle m < nm pasa a través del bucle m < n5.5. (n-1), n y (n+1) pasan a través del bucle(n-1), n y (n+1) pasan a través del bucle
donde n es el número máximo de pasadas aceptablesdonde n es el número máximo de pasadas aceptables
Ingeniería de Software
Pruebas de Bucles: Bucles AnidadosPruebas de Bucles: Bucles Anidados
Bucles Anidados1. Comenzar en el bucle mas interno. Poner todos los demás bucles
externos a sus mínimos valores de iteración.2. Probar el mínimo + 1, el valor típico, máximo + 1 y el máximo para
el bucle mas interior, mientras se mantienen los bucles externos a sus mínimos valores
3. Descartar un bucle y volver al como en el paso 2, manteniendo todos los otros bucles en sus valores típicos. Continuar este paso hasta que el bucle mas externo haya sido probado
Bucles ConcatenadosSi los bucles son independientes de otro, entonces tratarlos como un bucle simple, de lo contrario, tratarlos como bucles anidados.Por ejemplo: el valor final del contador del bucle 1 es utilizado para inicializar el bucle 2
Ingeniería de Software
Prueba de la Caja NegraPrueba de la Caja Negra
RequerimientosRequerimientos
EventosEventosEntradaEntrada
SalidaSalida
… nuestro objetivo es:
• Derivar conjuntos de condiciones de entrada que ejercitarán por completo todos los requisitos funcionales de un programa
Ingeniería de Software
Partición EquivalentePartición Equivalente
ConsultasConsultasdedeusuariousuario Picos dePicos de
ratónratón
FormatosFormatosdedesalidasalida
EntradasEntradasporporpantallapantalla
EntradaEntradaFKFK
datosdatos
… divide el dominio de entrada del programa en clases de datos a partir de los cuales pueden derivarse casos de prueba
Ingeniería de Software
Ejemplo de Clases de EquivalenciaEjemplo de Clases de Equivalencia
Datos Válidos• Comandos proveídos por el usuario• Respuestas a pedidos del sistema• Nombres de Archivo• Datos computacionales
Parámetros Físicos Valores de Límites Valores de inicialización
• Formato de datos de salida• Respuestas a mensajes de error• Datos gráficos (por ej. Picos de ratón)
Datos Inválidos•Datos fuera de los límites del programa•Datos físicamente imposibles•El valor correcto dado en un lugar incorrecto
Ingeniería de Software
Análisis de Valor LímiteAnálisis de Valor Límite
Dominio deDominio deSalidaSalidaDominio de EntradaDominio de Entrada
ConsultasConsultasdedeusuariousuario Picos dePicos de
ratónratón
FormatosFormatosdedesalidasalida
EntradasEntradasporporpantallapantalla
EntradaEntradaFKFK
datosdatos
““Alto % de los errores se presentan en límites de entrada”Alto % de los errores se presentan en límites de entrada”
Ingeniería de Software
Otras Técnicas de Caja NegraOtras Técnicas de Caja Negra
• Métodos de Adivinamiento de Errores
• Técnicas de Tablas de Decisión• Graficamiento causa-efecto
Ingeniería de Software
Pruebas de Entornos EspecializadosPruebas de Entornos Especializados
Pruebas de Interfaces Graficas de Usuario (GUI) Han crecido en su complejidad. Debido a que muchas de las GUI
modernas tienen aspecto y modo de uso similares, es posible derivar una serie de pruebas estándar. Existen herramientas para prueba GUI
Prueba de Arquitecturas Cliente/Servidor La naturaleza distribuida, el desempeño relacionado con el proceso
de transacción, posibilidad de variadas plataformas de Hw, complejidad de la comunicación de red; son aspectos a considerar.
Pruebas de la Documentación y Funciones de Ayuda Errores de documentación y ayuda al usuario son devastadores para
la aceptación del Sw, si no coinciden entre sí
Pruebas de Sistemas de Tiempo Real Se deben probar el manejo de eventos, la temporización de los datos
y el paralelismo entre procesos que manejan los datos.
Ingeniería de Software
Pruebas de Software - ResumenPruebas de Software - Resumen
Ingeniería de Software
Métodos de Pruebas Orientadas a ObjetosMétodos de Pruebas Orientadas a Objetos
CLASECLASE
AtributosAtributos
OperacionesOperaciones
… probar un Sistema OO en diferentes niveles para descubrir errores que ocurren a medida que las clases colaboran entre si
Ingeniería de Software
Implicaciones del Concepto Orientado a ObjetosImplicaciones del Concepto Orientado a Objetos
• Debido a que los atributos y las operaciones están encapsulados, las operaciones de prueba fuera de la clase suelen ser improductivas
• La herencia plantea desafíos adicionales debido a que cada nuevo contexto de uso requiere una nueva prueba
• Es posible usar el conjunto de casos de prueba derivado de la superclase cuando se prueba la subclase
• Sin embargo si ésta se emplea en un contexto completamente nuevo, los casos de prueba de la superclase no serán aplicables y será necesario diseñar nuevas pruebas
• Los métodos de prueba de Caja Blanca pueden ser aplicados a las operaciones definidas de una clase
• Los métodos de prueba de Caja Negra son tan apropiados para los sistemas OO como los que se desarrollan para métodos convencionales
Ingeniería de Software
Pruebas Orientadas a ObjetosPruebas Orientadas a Objetos
• Prueba basada en fallas: el responsable busca aspectos de la implementación del sistema que generen defectos. Esto requiere diseñar casos de prueba que revisen el diseño o el código. Pueden encontrarse 3 tipos de fallas: resultado inesperado, operación incorrecta e invocación incorrecta.
• Prueba basada en escenarios: se concentra en lo que hace el usuario, no el producto. Debe capturar las tareas que el usuario tiene que realizar y luego aplicarlas junto con sus variantes, como pruebas.
Ingeniería de Software
Pruebas Aplicables a Nivel de ClasePruebas Aplicables a Nivel de Clase
• Prueba Aleatoria a Nivel de Clase: definir el historial de comportamiento mínimo de una instancia de la clase. Ej. Clase CUENTA, abrir.configurar.depositar.retirar.cerrar Es posible generar al azar varias secuencias diferentes de operaciones. Ejercitar cada una de ellas.
• Prueba de Partición al Nivel de Clase: ejercita la clase de manera parecida a la Partición Equivalente. Pueden ser: Basada en Estado (ordena las operaciones de clase basada en su capacidad para cambiar el estado de la clase), Basada en Atributos (ordena las operaciones de clase basada en los atributos que utilizan) y Basada en Categorías (ordena las operaciones de clase en base a la función genérica que cada una realiza).
Ingeniería de Software
Pruebas de InterclasePruebas de Interclase
La prueba de colaboración entre clases se lleva a cabo al aplicar métodos aleatorios y de partición, además de pruebas basadas en el escenario y de comportamiento
• Prueba de Clases Múltiples: generar varios casos de prueba aleatorios de clases múltiples en base a la lista de operaciones de clase, a la clase colaboradora, los mensajes que transmiten y las operaciones invocadas por estos.
• Prueba Derivadas de Modelos de Comportamiento: el diagrama de estado de una clase ayuda a derivar una secuencia de pruebas que revisa el comportamiento dinámico de la clase y aquellas que colaboran con ella.
Ingeniería de Software
ResumenResumen
• El objetivo del diseño de casos de prueba consiste en derivar conjuntos de prueba que tenga la mayor probabilidad de descubrir errores en el software
• Las pruebas de Caja Blanca se concentran en la estructura de control del programa
• Las pruebas de Caja Negra validan requisitos funcionales sin importar el funcionamiento interno del programa
• Los métodos de prueba de Entornos Especializados abarcan una amplia serie de opciones de software y áreas de aplicación.
• Aunque el objetivo general de la Prueba OO es idéntico a la del Sw. Convencional las tácticas difieren un poco.