Calidad del software cap2

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


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


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


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


Qué muestran las pruebasQué muestran las pruebas

errorserrors

requirements conformancerequirements conformance

performanceperformance

an indicationan indicationof qualityof quality

ErroresConformidad de requerimientos

Rendimiento

Indicador de calidad


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


Pruebas exhaustivasPruebas exhaustivas

loop < 20 Xloop < 20 XExisten 1014 caminos posibles! Si ejecutamos una prueba cada milisegundo, tomaría años probar este programa!!!


Pruebas selectivasPruebas selectivas

loop < 20 Xloop < 20 X

Selected pathSelected pathCamino seleccionado


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


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


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


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


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


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.


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.


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


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.


Pruebas de BuclesPruebas de Bucles

BucleBucle AnidadoAnidado

Bucles Bucles ConcatenadosConcatenados Bucles no Bucles no

estructuradosestructurados

BucleBucleSimple Simple


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


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


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


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


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


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”


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


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.


Pruebas de Software - ResumenPruebas de Software - Resumen


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


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


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.


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).


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.


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.

Calidad del software cap2

Education

Transcript of Calidad del software cap2