Calidad del software cap3
-
Upload
julio-c-alsina-a -
Category
Education
-
view
2.907 -
download
0
Transcript of 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
Ingeniería de Software
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)
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
Si el Ing.Sw. no encuentra los errores ¡ El cliente si lo hará !...
Ingeniería de Software
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
Ingeniería de Software
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
Ingeniería de Software
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
OperacionesOperaciones
CLASE 2CLASE 2
AtributosAtributos
OperacionesOperaciones
CLASE 3CLASE 3
++
PruebasPruebas … Pruebas de Regresión
Ingeniería de Software
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”
Ingeniería de Software
Pruebas de UnidadPruebas de Unidad
MóduloMóduloa sera ser
probadoprobado
Casos de Casos de PruebaPrueba
ResultadosResultados
Ingeniero deIngeniero deSoftwareSoftware
Ingeniería de Software
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
Ingeniería de Software
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
Ingeniería de Software
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.
Ingeniería de Software
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
Ingeniería de Software
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”
Ingeniería de Software
Estrategias de Pruebas de IntegraciónEstrategias de Pruebas de Integración
Opciones:• el enfoque “big bang” • una estrategia de construcción incremental
Ingeniería de Software
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.
Ingeniería de Software
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
Ingeniería de Software
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
Ingeniería de Software
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
Ingeniería de Software
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!!
Ingeniería de Software
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.
Ingeniería de Software
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.
Ingeniería de Software
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
Ingeniería de Software
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.
Ingeniería de Software
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.
Ingeniería de Software
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.
Ingeniería de Software
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!!
Ingeniería de Software
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
Ingeniería de Software
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
Ingeniería de Software
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
Ingeniería de Software
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.
Ingeniería de Software
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
Ingeniería de Software
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!
Ingeniería de Software
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.