Calidad del software cap2

4,800 views

Published on

Published in: Education
1 Comment
2 Likes
Statistics
Notes
No Downloads
Views
Total views
4,800
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
288
Comments
1
Likes
2
Embeds 0
No embeds

No notes for slide

Calidad del software cap2

  1. 1. CAPITULO 2 <ul><li>Fundamentos de las pruebas del software </li></ul>Técnicas de Prueba del Software Por Julio C. Alsina
  2. 2. Pruebas de Software Probar es el proceso de ejercitar un programa con el objetivo específico de encontrar errores antes de entregarlo al usuario final
  3. 3. Caracteristicas para la Facilidad de Pruebas de Software <ul><li>Operabilidad – cuanto mejor funcione, con mayor eficacia podrá probarse </li></ul><ul><li>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 </li></ul><ul><li>Controlabilidad – el grado al cual la prueba puede ser automatizada y optimizada </li></ul><ul><li>Descomponibilidad – el SW se construye con modulos independientes que tambien se prueban independientemente </li></ul><ul><li>Simplicidad – reducir arquitecturas complejas y lógicas para simplificar las pruebas </li></ul><ul><li>Estabilidad – a menos cambios, menos alteracion en pruebas </li></ul><ul><li>Comprensión – del diseño de arq.y dependencia de componentes internos y externos </li></ul>
  4. 4. Características de una Buena Prueba <ul><li>Una buena prueba tiene una elevada probabilidad de encontrar un error. El responsable de aplicar la prueba debe comprender correctamente el Sw </li></ul><ul><li>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 </li></ul><ul><li>Una buena prueba debe ser “ la mejor de su clase ”. Usar aquella que tiene la mayor probabilidad de descubrir un tipo completo de errores </li></ul><ul><li>Una buena prueba no debe ser ni muy simple ni demasiado compleja. Cada prueba debe ejecutarse por separado </li></ul>
  5. 5. Qué muestran las pruebas errors requirements conformance performance an indication of quality Errores Conformidad de requerimientos Rendimiento Indicador de calidad
  6. 6. Quien prueba el Software? Desarrollador Pruebas 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
  7. 7. Pruebas exhaustivas Existen 10 14 caminos posibles! Si ejecutamos una prueba cada milisegundo, tomaría años probar este programa!!! loop < 20 X
  8. 8. Pruebas selectivas loop < 20 X Selected path Camino seleccionado
  9. 9. Pruebas de Software Métodos Estrategias Métodos de Caja Blanca Métodos de Caja 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
  10. 10. Diseño del caso de prueba OBJETIVO CRITERIO LIMITACIONES Descubrir errores De una manera completa En mínimo tiempo y esfuerzo
  11. 11. Pruebas de Caja Blanca <ul><li>… nuestros objetivos son: </li></ul><ul><li>Asegurar que todas las declaraciones y condiciones han sido ejectuadas por lo menos una vez </li></ul><ul><li>Ejercitar lado verdadero y falso de todas las decisiones </li></ul><ul><li>Ejecutar todos los bucles en sus limites y dentro de limites operac. </li></ul><ul><li>Ejercitar estructuras de datos internos para asegurar su validez </li></ul>
  12. 12. Por qué cubrir? <ul><li>Errores lógicos e interpretaciones incorrectas son inversamente proporcionales a la probabilidad de ejecución de un camino </li></ul><ul><li>A menudo creemos que un camino probablemente no será ejecutado; de hecho, la realidad es que a menudo es intuitivo </li></ul><ul><li>Los errores tipográficos son al azar; es probable que un camino no probado contendrá algunos </li></ul>
  13. 13. Prueba de Camino de Base Primero, calculamos la complejidad ciclomática: Nro. de decisiones simples + 1 O 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
  14. 14. Complejidad Ciclomática Los módulos en este rango son mas propensos a los errores Un número de estudios de la industria han indicado que cuanto mas alto el V(G), mas alta será la probabilidad de errores. V(G) Módulos
  15. 15. Prueba 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,8 Camino 2: 1,2,3,5,7,8 Camino 3: 1,2,4,7,8 Camino 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. 1 2 3 4 5 6 7 8
  16. 16. Prueba de Camino de Base <ul><li>No es necesario un diagrama de flujo, pero el diagrama ayudará cuando se tracen los caminos de programa </li></ul><ul><li>Contar cada prueba lógica simple, componer pruebas de 2 o mas </li></ul><ul><li>Prueba de camino de base debería aplicarse a los módulos críticos </li></ul>
  17. 17. Pruebas de Estructuras de Control <ul><li>Prueba de Condición : intenta ejercitar las condiciones lógicas contenidas en un modulo de programa. </li></ul><ul><li>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. </li></ul><ul><li>Prueba de Bucles : se concentra en la validez de la construccion de los bucles o ciclos. </li></ul>
  18. 18. Pruebas de Bucles Bucle Anidado Bucles Concatenados Bucles no estructurados Bucle Simple
  19. 19. Pruebas de Bucles: Bucles Simples <ul><li>Condiciones Simples </li></ul><ul><li>Saltar el bucle completo </li></ul><ul><li>Solo uno pasa a través del bucle </li></ul><ul><li>Dos pasan a través del bucle </li></ul><ul><li>m pasa a través del bucle m < n </li></ul><ul><li>(n-1), n y (n+1) pasan a través del bucle </li></ul><ul><li>donde n es el número máximo de pasadas aceptables </li></ul>
  20. 20. Pruebas de Bucles: Bucles Anidados <ul><li>Bucles Anidados </li></ul><ul><li>Comenzar en el bucle mas interno. Poner todos los demás bucles externos a sus mínimos valores de iteración. </li></ul><ul><li>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 </li></ul><ul><li>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 </li></ul>Bucles Concatenados Si 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
  21. 21. Prueba de la Caja Negra Requerimientos Eventos Entrada Salida <ul><li>… nuestro objetivo es: </li></ul><ul><li>Derivar conjuntos de condiciones de entrada que ejercitarán por completo todos los requisitos funcionales de un programa </li></ul>
  22. 22. Partición Equivalente Consultas de usuario Picos de ratón Formatos de salida Entradas por pantalla Entrada FK datos … divide el dominio de entrada del programa en clases de datos a partir de los cuales pueden derivarse casos de prueba
  23. 23. Ejemplo de Clases de Equivalencia <ul><li>Datos Válidos </li></ul><ul><li>Comandos proveídos por el usuario </li></ul><ul><li>Respuestas a pedidos del sistema </li></ul><ul><li>Nombres de Archivo </li></ul><ul><li>Datos computacionales </li></ul><ul><ul><li>Parámetros Físicos </li></ul></ul><ul><ul><li>Valores de Límites </li></ul></ul><ul><ul><li>Valores de inicialización </li></ul></ul><ul><li>Formato de datos de salida </li></ul><ul><li>Respuestas a mensajes de error </li></ul><ul><li>Datos gráficos (por ej. Picos de ratón) </li></ul><ul><li>Datos Inválidos </li></ul><ul><li>Datos fuera de los límites del programa </li></ul><ul><li>Datos físicamente imposibles </li></ul><ul><li>El valor correcto dado en un lugar incorrecto </li></ul>
  24. 24. Análisis de Valor Límite Dominio de Salida Dominio de Entrada Consultas de usuario Picos de ratón Formatos de salida Entradas por pantalla Entrada FK datos “ Alto % de los errores se presentan en límites de entrada”
  25. 25. Otras Técnicas de Caja Negra <ul><li>Métodos de Adivinamiento de Errores </li></ul><ul><li>Técnicas de Tablas de Decisión </li></ul><ul><li>Graficamiento causa-efecto </li></ul>
  26. 26. Pruebas de Entornos Especializados <ul><li>Pruebas de Interfaces Graficas de Usuario (GUI) </li></ul><ul><li>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 </li></ul><ul><li>Prueba de Arquitecturas Cliente/Servidor </li></ul><ul><li>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. </li></ul><ul><li>Pruebas de la Documentación y Funciones de Ayuda </li></ul><ul><li>Errores de documentación y ayuda al usuario son devastadores para la aceptación del Sw, si no coinciden entre sí </li></ul><ul><li>Pruebas de Sistemas de Tiempo Real </li></ul><ul><li>Se deben probar el manejo de eventos, la temporización de los datos y el paralelismo entre procesos que manejan los datos. </li></ul>
  27. 27. Pruebas de Software - Resumen
  28. 28. Métodos de Pruebas Orientadas a Objetos CLASE Atributos Operaciones … probar un Sistema OO en diferentes niveles para descubrir errores que ocurren a medida que las clases colaboran entre si
  29. 29. Implicaciones del Concepto Orientado a Objetos <ul><li>Debido a que los atributos y las operaciones están encapsulados, las operaciones de prueba fuera de la clase suelen ser improductivas </li></ul><ul><li>La herencia plantea desafíos adicionales debido a que cada nuevo contexto de uso requiere una nueva prueba </li></ul><ul><li>Es posible usar el conjunto de casos de prueba derivado de la superclase cuando se prueba la subclase </li></ul><ul><li>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 </li></ul><ul><li>Los métodos de prueba de Caja Blanca pueden ser aplicados a las operaciones definidas de una clase </li></ul><ul><li>Los métodos de prueba de Caja Negra son tan apropiados para los sistemas OO como los que se desarrollan para métodos convencionales </li></ul>
  30. 30. Pruebas Orientadas a Objetos <ul><li>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. </li></ul><ul><li>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. </li></ul>
  31. 31. Pruebas Aplicables a Nivel de Clase <ul><li>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. </li></ul><ul><li>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). </li></ul>
  32. 32. Pruebas de Interclase <ul><li>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 </li></ul><ul><li>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. </li></ul><ul><li>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. </li></ul>
  33. 33. Resumen <ul><li>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 </li></ul><ul><li>Las pruebas de Caja Blanca se concentran en la estructura de control del programa </li></ul><ul><li>Las pruebas de Caja Negra validan requisitos funcionales sin importar el funcionamiento interno del programa </li></ul><ul><li>Los métodos de prueba de Entornos Especializados abarcan una amplia serie de opciones de software y áreas de aplicación. </li></ul><ul><li>Aunque el objetivo general de la Prueba OO es idéntico a la del Sw. Convencional las tácticas difieren un poco. </li></ul>

×