Calidad del software cap3

Ingeniería de Software

CAPITULO 3CAPITULO 3

Un enfoque estratégico para las pruebas del software

ESTRATEGIAS DE PRUEBA DEL ESTRATEGIAS DE PRUEBA DEL SOFTWARESOFTWARE

Por Julio C. Alsina


Un Enfoque Estratégico para PruebasUn Enfoque Estratégico para Pruebas

Propuestas:Para realizar pruebas efectivas un equipo de Sw.debe efectuar RTF y efectivas. Esto eliminará muchos errores antes de las pruebas.La prueba comienza a nivel de componentes y trabaja “hacia fuera”, hacia la integración de todo el sistema de computo.Diferentes técnicas de prueba son apropiadas en diferentes momentosLa prueba la dirige el desarrollador del software y un grupo independiente de pruebas (proyectos grandes)La prueba y la depuración son actividades diferentes, pero la depuración debe incluirse en cualquier estrategia de prueba.Una estrategia de prueba debe incluir “pruebas de bajo nivel”(a nivel de código) y de “alto nivel” (funciones del sistema)


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

Si el Ing.Sw. no encuentra los errores ¡ El cliente si lo hará !...


Afirmaciones IncorrectasAfirmaciones Incorrectas

El responsable del desarrollo no debería participar en el proceso de pruebas

El software debe ponerse a salvo de extraños que lo prueben

Quienes aplican las pruebas sólo deben participar en el proyecto cuando vayan a darse los primeros pasos de esas pruebas


Estrategia de PruebasEstrategia de Pruebas

Pruebas de UnidadPruebas de Unidad Pruebas de IntegraciónPruebas de Integración

Pruebas de Pruebas de ValidaciónValidación

Pruebas dePruebas deSistemaSistema

CodigoCodigo DiseñoDiseño

Ing.de SistemaIng.de Sistema RequisitosRequisitos


Estrategia de Prueba de Sw Orientadas a ObjetosEstrategia de Prueba de Sw Orientadas a Objetos

CLASE 1CLASE 1

AtributosAtributos

OperacionesOperaciones

… Por último se prueba el sistema como un todo para asegurarse de que se descubran errores en los requisitos

...…...… AtributosAtributos


CLASE 2CLASE 2

AtributosAtributos


CLASE 3CLASE 3

++

PruebasPruebas … Pruebas de Regresión


Criterios para Completar la PruebaCriterios para Completar la Prueba

… Cada vez que el cliente o el usuario ejecutan el programa de computadora, este se esta probando.

Cuando Cuando terminamosterminamos las pruebas ? las pruebas ?

“… “… Nunca se termina de aplicar una prueba”Nunca se termina de aplicar una prueba”


Pruebas de UnidadPruebas de Unidad

MóduloMóduloa sera ser

probadoprobado

Casos de Casos de PruebaPrueba

ResultadosResultados

Ingeniero deIngeniero deSoftwareSoftware


Pruebas de UnidadPruebas de Unidad

Interfase (flujo de informacion hacia adentro/afuera del programa)

Estructuras locales de datos (datos locales mantíenen integridad durante la ejecucion del programa)

Condiciones de límites (modulo opera ok en los limites establecidos p/restrigir procesamiento)

Caminos independientes (asegurar que todos los caminos se ejecutan por lo menos una vez)

Caminos de manejo de errores (los errores probables tienen buen tratamiento y finalizacion adecuada)

Casos de prueba

MóduloMóduloa sera ser

probadoprobado


Que deben descubrir los casos de prueba?Que deben descubrir los casos de prueba?

Comparaciones entre diferentes tipos de datos. Operadores lógicos o precedencia de estos aplicada

incorrectamente. Expectativa de igualdad cuando los errores de

precisión son improbables Comparación incorrecta de variables. Terminación inapropiada de o inexistente de bucles. Falla de salida en iteración divergente Variables de bucle modificadas de manera inapropiada


Manejo Correcto de ErroresManejo Correcto de Errores

Debe tener cuidado de no cometer las sigtes. fallas:

La descripción del error es ininteligible. El error indicado no corresponde al encontrado. La condición de error causa la intervención del S.O.

antes de que se dispare el manejo de errores. El procesamiento de la condición de excepción es

incorrecto. La descripción del error no proporciona información

suficiente para ayudar a localizar la causa del error.


Ambiente de Pruebas de UnidadAmbiente de Pruebas de Unidad

MóduloMódulo

ResguardoResguardo

ControladorControlador

Resultados

Casos de Prueba

Interfase

Estructuras locales de datos

Condiciones de límites

Caminos independientes

Caminos de manejo de errores

ResguardoResguardo


Controladores y ResguardosControladores y Resguardos

Un Controlador no es más que un “programa principal” que acepta los datos del caso de prueba, pasa estos datos al componente que se está probando e imprime los resultados. Los Resguardos sirven para reemplazar módulos subordinados al componente que habrá de probarse (o llamados por éste). Los resguardos usan la interfaz del modulo subordinado, realizan una mínima manipulación de datos, proporcionan verificación de la entrada y devuelven el control al módulo en prueba.

“Representan sobrecarga de trabajo pues requieren construirse para realizar las pruebas, pero no se entregan con el producto final”


Estrategias de Pruebas de IntegraciónEstrategias de Pruebas de Integración

Opciones:• el enfoque “big bang” • una estrategia de construcción incremental


Pruebas de IntegraciónPruebas de Integración

Enfoque “big bang” implica combinar todos los componentes, probando el programa como un todo, lo cual puede generar caos al detectar múltiples errores que dificultan la corrección, debido a su extensión. La “integración incremental” sugiere construir y probar en pequeños incrementos, en los cuales resulta más fácil aislar y corregir errores, llegandose finalmente a probar la totalidad de los componentes y sus interfaces.


Integración de Arriba-AbajoIntegración de Arriba-Abajo

El módulo mas alto es probado con resguardos

AA

BB

CC

DD EE

FF GG

Los resguardos son reemplazados uno a la vez, “primero en profundidad” o “primero en anchura”

A medida que nuevos módulos se integran, algunos sub-grupos de pruebas se realizan nuevamente


Integración de Abajo-ArribaIntegración de Abajo-Arriba

AA

BB

CC

DD EE

FF GG

Grupo

Los controladores son reemplazados una a la vez, “el mas profundo primero”

Los módulos de trabajo están integrados y agrupados


Pruebas de SandwichPruebas de Sandwich

AA

BB

CC

DD EE

FF GG

Los módulos más altos son probados con resguardos

Los módulos de trabajo están integrados y agrupados

Grupo


Prueba de Regresion Prueba de Regresion

“Cada vez que se agrega un nuevo modulo como parte de una prueba de integración, el software cambia”

“… ejecutar nuevamente el mismo subconjunto de pruebas que ya se han aplicado para asegurarse de que los cambios no han propagado efectos indeseables”

El conjunto de pruebas de regresión contiene 3 casos dif. de prueba:• Muestra representativa de pruebas que ejercerán todas las func.del Sw• Pruebas adicionales centradas en las funciones afectadas por el cambio• Pruebas centradas en los componentes del Sw.que cambiaron

A medida que avanza la prueba de integración, la cantidad de pruebas de regresión llega a volverse muy grande!!


Estrategias de Prueba para Software OOEstrategias de Prueba para Software OO

• Al pensar en el Sw.OO cambia el concepto de unidad. Cada clase e instancia de una clase (objeto) empaqueta atributos y operaciones.• Sin embargo las unidades de prueba mas pequeñas son las operaciones dentro de la clase. Una clase puede contener varias operaciones y una operación puede existir en varias clases dif.• No es posible probar una sola operación en forma aislada, sino como parte de una clase.• A diferencia de la prueba de unidad del Sw. Convencional que se centra en el detalle algoritmico de un modulo, la prueba de clase para Sw.OO se orienta a las operaciones que encapsula y en el comportamiento de estado de la clase.


Prueba de Integracion en el Contexto OOPrueba de Integracion en el Contexto OO

• El Sw.OO no tiene una estrategia de control jerárquico. Por tanto no tiene sentido estrategias de integr.Ascend/Descend.

•Hay dos estrategias dif. para la prueba de Integr. de Sist.OO: Prueba basada en subprocesos: conjunto de clases requerido para responder a una entrada o un evento del sistema. Cada subproceso se integra y valida

individualmente. Prueba basada en el uso: se empieza la construcción del sistema con las pruebas de clases independientes. Luego se prueba la siguiente capa de clases llamadas

dependientes, usadas por las clases independientes. Se sigue esta secuencia de capas de prueba de clases dependientes hasta construir todo el sistema.


Pruebas de Alto Orden Pruebas de Alto Orden

Prueba de ValidaciónPrueba de Validación

Prueba Alfa y BetaPrueba Alfa y Beta

Pruebas de SistemaPruebas de Sistema

Otras pruebas especializadasOtras pruebas especializadas


Pruebas de Validacion Pruebas de Validacion

• Empiezan al culminar las pruebas de integración. En este nivel desaparece la distinción entre Sw. convencional y orientado a objetos.• La validación del Sw.se logra mediante una serie de pruebas que demuestran que se cumple con los requisitos.• Luego de dirigir cada caso de prueba de validación, existirá una de dos condiciones posibles:

La característica de funcionamiento o desempeño cumple con la especificación y se le aceptaSe descubre una desviación de la especificación y se crea una lista de deficiencias. La corrección de las deficiencias debe ser

negociada con el cliente.


Pruebas Alfa y Beta Pruebas Alfa y Beta

• Son conducidas por el usuario final, no por los Ing.Sw.• Pueden ir desde una prueba de manejo informal hasta una serie de pruebas planeadas y ejecutadas sistemáticamente.

Pruebas Alfa: se aplican en el lugar de trabajo del desarrollador. Se realizan en un entorno controlado. El desarrollador “mira sobre el hombro” de los usuarios y registra los errores y los problemas de uso.

Pruebas Beta: se aplican en el lugar de trabajo de los usuarios finales. Por lo general el desarrollador no esta. Es una aplicación en vivo del Sw. en un entorno no controlado por el desarrollador. El usuario registra todos los problemas encontrados y los informa al desarrollador.


Pruebas de Pruebas de SistemaSistema

• Su propósito principal es ejercitar profundamente el sistema. Pruebas de Recuperación: obliga al Sw. A fallar de varias maneras

y a verificar que la recuperacion se realice apropiadamente. Considerar Re-inicializacion, Respaldo, Recup.Datos, NuevoArranque.

Pruebas de Seguridad: prueba que los mecanismos de proteccion integrados en el sistema realmente lo protejan de irrupciones inapropiadas (hackers por razones de diversión, empleados disgustados por venganza o busqueda ilícita de ganancias) .

Pruebas de Resistencia: ejecuta un sistema de tal manera que requiera una cantidad , una frecuencia o un volumen anormal de recursos. En esencia, se tratará de sobrecargar el programa. Se propone confrontar el programa con situaciones anormales.

Pruebas de Desempeño: esta diseñada para probar el desempeño del Sw.en tiempo de ejecución dentro del contexto de un sistema integrado. Solamente cuando estén totalmente integrados todos los elementos del sistema, será posible asegurar el verdadero desempeño del sistema. Con frecuencia suelen integrarse con pruebas de resistencia y suelen requerir instrumentación de Sw y Hw.


Depuración: un proceso de diagnósticoDepuración: un proceso de diagnóstico

Cuando un caso de prueba descubre un error, la depuración es la acción que lo elimina!!


El proceso de depuraciónEl proceso de depuración

Casos de pruebaCasos de prueba

ResultadosResultados

DepuraciónDepuración

Sospechas de CausasSospechas de Causas

Causas IdentificadasCausas Identificadas

CorreccionesCorrecciones

Pruebas de RegresiónPruebas de Regresión

Pruebas AdicionalesPruebas Adicionales

Ejecución de CasosEjecución de Casos


Esfuerzo de DepuraciónEsfuerzo de Depuración

Tiempo requerido para diagnosticar el síntoma y determinar la causaTiempo requerido

para corregir el error y conducir pruebas de regresión


Síntomas y CausasSíntomas y Causas

Síntoma y causa pueden estar Síntoma y causa pueden estar separados geográficamenteseparados geográficamente

El síntoma puede desaparecer cuando El síntoma puede desaparecer cuando se arregla otro problemase arregla otro problema

El sintoma podria deberse a un error El sintoma podria deberse a un error humano dificil de localizarhumano dificil de localizar

La causa puede deberse a un error La causa puede deberse a un error de sistema o de compiladorde sistema o de compilador

La causa puede deberse a supuestos La causa puede deberse a supuestos que todos creenque todos creen

El síntoma puede ser intermitenteEl síntoma puede ser intermitente

SíntomaCausa


Consecuencias de los ErroresConsecuencias de los Errores

Daño

suaveleve

disturbiosserio

extremocatastrófico

infeccioso

Tipo de Bug

Categorías de errores:Categorías de errores: errores de función, errores de errores de función, errores de sistema, errores de datos, errores de código, errores de sistema, errores de datos, errores de código, errores de diseño, de documentación, violaciones estándar, etc.diseño, de documentación, violaciones estándar, etc.


Técnicas de DepuraciónTécnicas de Depuración

Fuerza bruta / pruebasFuerza bruta / pruebas

Volver atrásVolver atrás

Eliminación de CausaEliminación de Causa

- Inducción o Deducción- Inducción o Deducción


Técnicas de DepuraciónTécnicas de Depuración

•Fuerza Bruta: método mas común y menos eficiente para aislar la causa de un error. Se hace descarga de memoria, se invocan señales en tiempo de ejecución, etc. En algún lugar del pantano de información producida se espera encontrar una pista que pueda conducir a la causa del error.•Rastreo hacia Atrás: empezando en el lugar donde se descubre el síntoma, se recorre hacia atrás el código fuente hasta hallar el sitio de la causa. Al aumentar las líneas de código, este método se vuelve inmanejable.•Eliminación de Causa: los datos relacionados con el error se organizan p/ aislar las causas posibles. Elabora una hipótesis de causa y se aprovechan los datos mencionados para probar o desechar la hipótesis. Se elabora una lista de causas posibles y con pruebas se busca eliminar cada una de ellas.•Depuración Automatizada: se cuenta con una amplia variedad de compiladores de depuración, ayudas dinámicas para la depuración (trazadores), generadores automáticos de casos de prueba y herramientas de correlación de referencias cruzadas. Sin embargo, las herramientas no son un sustituto de la evaluación cuidadosa basada en un modelo de diseño completo y un código fuente claro.

¡Cuando todo lo demás falle, pida ayuda!


Depuración: ConclusionesDepuración: Conclusiones

• Piense acerca del síntoma que está viendo• Utilice herramientas (por ej. Depurador

dinámico) para tener mayor detalle• Si está perdido, consiga ayuda• Esté absolutamente seguro de realizar

pruebas de regresión cuando se “arregla” el bug.

Calidad del software cap3

Education

Transcript of Calidad del software cap3