• Like
Estrategias de Pruebas de Software
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Estrategias de Pruebas de Software

  • 23,648 views
Published

Presentación referente a lo tipos de pruebas que existen para los software convencionales u Orientados a Objetos.

Presentación referente a lo tipos de pruebas que existen para los software convencionales u Orientados a Objetos.

Published in Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
23,648
On SlideShare
0
From Embeds
0
Number of Embeds
4

Actions

Shares
Downloads
835
Comments
0
Likes
5

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Álvarez, David Gasperin, Lucía Herrera, Jorge Rivas, Edixson Rodríguez, Ronald Seijas, Fanny
  • 2. Prueba según el DICCIONARIO DE LA LENGUA ESPAÑOLA - Vigésima segunda edición Acción y efecto de probar. Razón, argumento, Análisis médico. instrumento u otro medio con que se pretende mostrar y hacer patente la Indicio, señal o verdad o falsedad de algo. muestra que se da de algo. Examen que se hace para demostrar o comprobar Ensayo o experimento que los conocimientos o se hace de algo, para saber aptitudes de alguien. cómo resultará en su forma definitiva. Muestra, cantidad pequeña de un alimento destinada a examinar su calidad.
  • 3. Según IEEE ERROR DEFECTO FALLA
  • 4. Según Cem Kaner Resultados esperados ¿Cómo sabemos que paso o fallo las pruebas?
  • 5. Testers: ¿Quién hace las pruebas? Cubrimiento: Evaluación: ¿Qué estamos probando? Criterio para evaluar. Riesgo: Actividades: ¿Qué estamos probando? ¿Cómo probamos?
  • 6. Motivación Las pruebas son incómodas La pruebas son aburridas “Estoy seguro de que lo he codificado bien” Probar todo junto, al final – Big-Bang Falla por todas partes Muy difícil diagnosticar las causas de los fallos Muy costoso de arreglar Resultado productos finales defectuosos
  • 7. “Encontrar Errores” Algunos autores como Krutchen, Pressman, “Propiciar la calidad en el Pfleger, Cardoso y Sommerville afirman Software” que el proceso de ejecución de Pruebas debe ser considerado durante todo el ciclo de vida de un proyecto, para así obtener un Según Gonzáles, Javier. (2002), el producto de alta calidad. Su éxito aseguramiento de la calidad toma dependerá del seguimiento de una en cuenta todas aquellas acciones Estrategia de Prueba adecuada. planificadas y sistemáticas necesarias para proporcionar la Requerimientos del Software confianza de que un producto o servicio satisfaga los requisitos de Según Sommerville, Bosch, Dromey, Pressman calidad establecidos. entre otros, los requerimientos del software se clasifican en:  Requerimientos Funcionales (RF) y  Requerimientos No Funcionales (RNF). Requisitos del usuario Sistema software Proceso de desarrollo de Software
  • 8. Doc. Requisitos Análisis P. validación Diseño P. integración Doc. Diseño Codificación P. unidades Cod. Módulos Integración Cód. Completo Mantenimiento
  • 9. “La estrategias de Prueba permiten identificar las Características de Calidad que deben ser evaluadas en un software:” • Fiabilidad • Usabilidad Convencional • Eficiencia • Mantenibilidad • Portabilidad. • Localización • Encapsulamiento • Ocultamiento de O.O. información • Herencia • Técnicas de abstracción de objetos. Ortega, M. Pérez, M. & Rojas, T. (2003). Construction of a Sistemic Quality Model for Evaluating a Software Product. Software Quality Journal, 11, 219-242.
  • 10. Barry Boehm: divide en 4 sectores  definición de objetivos, PROGRESO restricciones del producto y DETERMINAR OBJETIVOS, A TRAVÉS DE LAS ITERACIONES EVALUAR ALTERNATIVAS, proceso, plan de ALTERNATIVAS Y RESTRICCIONES IDENTIFICAR Y RESOLVER RIESGOS administración,... Análisis de riesgos  evaluación y reducción de Análisis de riesgos riesgos (por ejemplo, mejor Análisis de riesgos definición de requerimientos Prototipo operativo An. mediante prototipos) Riesgo. Proto- - Prototipo 2 Prototipo 3 REVISIÓN tipo 1  Simulaciones, modelos, desarrollo y validación: Plan de . requerimientos Concepto de pruebas comparativas operación elección de un modelo para Plan de ciclo de vida Requerimientos de software el desarrollo Plan de Validación de Diseño del producto Diseño detallado desarrollo requerimientos  planificación: el proyecto se Plan de integración Diseño de validación Codificar y prueba revisa y se decide si se PLANIFICAR SIGUIENTE y verificación Prueba de unidad FASE continúa con el siguiente Prueba de Prueba de integración ciclo. si es así, se planifica - Explotación aceptación DESARROLLAR, VERIFICAR la siguiente fase PRODUCTO DE SIGUIENTE NIVEL
  • 11. Laboratorio de Investigación de Sistemas de Información (LISI) Departamento de Procesos y Sistemas, Universidad Simón Bolívar Anna. C Grimán, María Pérez, Luis. E Mendoza La formulación de la Estrategia de Prueba para Software aquí propuesta contempló cinco pasos:  Identificación de las Etapas del Proceso de Pruebas,  Propuesta del Instrumento de Medición: Las Listas de Chequeo,  El Diseño y Registro de Casos de Prueba, y  Establecimiento de Pautas para Procesar los Resultados y  Diseño Final de la EPSOO. Identificación de las Etapas del Proceso de Pruebas: Se inspiró en las Actividades Clásicas del Proceso de Desarrollo (ACPD), es decir: Análisis, Diseño e Implantación; ya que las mismas se encuentran actualmente presentes, a manera de disciplinas, en la mayoría de los procesos de desarrollo.
  • 12. Sub Características Objetivo Técnicas que Aplican Madurez. Evaluar la capacidad que tiene el Prueba Negativa: Hacer que el sistema falle intencionalmente software para evitar fallas para medir su capacidad de respuesta frente a un error. Tolerancia a Verificar la capacidad del oftware Prueba de Valores Límites: Evaluar valores frontera; es decir, para mantener un nivel de los valores mínimo y máximo que la unidad puede aceptar. Fallas rendimiento específico ante un Prueba Bajo Stress: Evaluar la habilidad del sistema para seguir error, es decir, la capacidad de operando apropiadamente ante bajos recursos o continuar procesando en caso de competencias para los recursos. Ejecutar el sistema de falla. manera que demande recursos en cantidad, frecuencia o volúmenes anormales. Prueba Negativa: Hacer que el sistema falle intencionalmente para medir su capacidad de continuar su ejecución a pesar de la falla. Prueba de Volumen: Someter al software a una gran cantidad de datos para determinar si los límites alcanzados hacen que este falle. Recuperabilidad Verificar que el proceso de Prueba de Recuperación: Exponer al software a condiciones recuperación del sistema restaura extremas y verificar que la recuperación se realiza apropiadamente la base de datos, correctamente. la aplicación y el sistema a un estado conocido o deseado Correctitud 1) Evaluar la capacidad de Prueba Estructural: Verificar que las formas estructurales de cómputo. las clases sean completas. 2) Comprobar la completitud de Prueba de Ejecución: La capacidad de cómputo esperada se las formas estructurales y del puede evaluar durante la ejecución del software en software como un todo. aquellos módulos en donde se apliquen cálculos. 3) Evaluar la consistencia. Prueba de Carga: Probar diferentes cargas para evaluar la capacidad de cómputo. Estructurado Que siga las reglas de Prueba Estructural: Esta técnica permite evaluar los valores de Programación las variables, las constantes y los tipos de datos y si éstos Estructurada. son usados en el contexto en que se definieron. Encapsulado. Verificar que sea encapsulado, Prueba Estructural: Esta técnica permite evaluar los valores de las variables, las constantes y los tipos de datos y si éstos son usados en el contexto en que se definieron.
  • 13. Son el proceso de revisión que el sistema de software producido cumple con las especificaciones y que cumple su cometido. Se trata de evaluar el sistema o parte de este durante o al final del desarrollo para determinar si satisface los requisitos iniciales. La validación es el proceso de comprobar lo que se ha especificado es lo que e usuario realmente quería. Utiliza técnicas tales como evaluaciones, inspecciones, y tutoriales. Como en otras etapas de la prueba, la validación permite descubrir errores, pero su enfoque Las expectativas razonables están definidas en está en el nivel de requisitos - la Especificación de Requisitos del Software, sobre cosas que son necesarias contenidas en una sección denominada para el usuario final. Criterios de validación http://es.wikipedia.org/wiki/Pruebas:_de_validaci%C3%B3n (Presuman, Roger…5ta Edición Pag 316)
  • 14. Condiciones en cada caso de prueba:  Las características de funcionamiento o de rendimiento están de acuerdo con las especificaciones y son aceptables.  Se descubre una desviación de las especificaciones y se crea una lista de deficiencias. Revisión de la configuración La intención de la revisión es asegurarse de que todos los elementos de la configuración del software se han desarrollado apropiadamente, a veces denominada auditoria. Pruebas Alfa y Beta Es virtualmente imposible que un desarrollador de software pueda prever cómo utilizará el usuario realmente el programa.
  • 15. Objetivo: Buscar discrepancia entre el software y sus objetivos originales (Requerimientos funcionales y no funcionales). Las Funciones del sistemas o del programa completo no son probadas en esta parte ya que implicaría una Redundancia con las Pruebas Funcionales. Procurar demostrar como el producto (software, sistema, aplicación) no resuelves sus objetivos o requerimientos planteados por los usuarios. Principales tipos de Pruebas: Recuperación: Forza al fallo del software y verifica que la recuperación se lleva a cabo apropiadamente. Usabilidad: Verifica el sistema por medio de las interacciones realizadas por un grupo de usuarios. Rendimiento: Verifica el rendimiento del sistema (tiempo de respuesta) para realizar una tarea en situaciones particulares . (Cargas, Estrés, Estabilidad, Picos) Seguridad: Verifica que un usuario solo puede tener acceso a datos y funciones autorizadas.
  • 16. Elementos de una Prueba:  Interacciones entre el Sistema y la Prueba (Propósito)  Valores de Prueba (Pasos de ejecución)  Resultados Esperados. Los dos primeros permiten realizar la prueba y el ultimo evaluar si la prueba se supero o no. Fases de una Prueba: (Métodos y Herramientas) Análisis y Diseños de pruebas Codificación Ejecución Análisis de Resultados
  • 17. La prueba, es el proceso mediante el cual se detecta inicialmente el error. Obtención de salida incorrecta Realización de operaciones fuera de lo normal No finalización del programa (ciclos infinitos) Caídas del programa Es el proceso de identificar la raíz de un error y corregirlo.
  • 18. Bradley describe el enfoque de la depuración de la siguiente forma: Fuerza Bruta Es probablemente la más común y menos eficiente a la hora de aislar la causa del error en el software. Se aplica cuando todo lo demás falla. Mediante una filosofía de «dejar que la computadora encuentre el error», se hacen volcados de memoria, trazas de ejecución y se cargan multitud de sentencias Mostrar en el programa. Vuelta Atrás Se puede usar con éxito para pequeños programas. Partiendo del lugar donde se descubre el síntoma, se recorre hacia atrás (manualmente) el código fuente hasta que se llega a la posición de error. A medida que aumenta el número de líneas del código, el número de posibles caminos de vuelta se hace difícilmente manejable. Eliminación de Causas Se manifiesta mediante inducción o deducción. Se llega a una «hipótesis de causa» y se usan los datos anteriores para probar o revocar la hipótesis.
  • 19. Estabiliza el • Debes hallar un caso de prueba que produzca error el error y debe ser lo más simple posible. Localiza la • Observar el comportamiento bajo fuente del error condiciones controladas • Errores de Programación Corrige el error • Errores de Sintaxis Prueba la • Con el caso de prueba y otras hipótesis corrección Busca errores • Verifica si existen otras partes del programa similares donde pusiese presentar el mismo error. http://www.galeon.com/neoprogramadores/howdebug.htm, Charles Connell . Escrito por J. F. Díaz. Consultado el 01/05/2010..
  • 20. • Comprende el • Cambia el problema antes código solamente de corregirlo por buenas • Relájate razones • Comprende el programa, no • Guarda una • Haz un cambio a sólo el problema copia del código la vez • Confirma la original • Verifica tu diagnosis del • Corrige el corrección error problema, no los • Observa errores síntomas similares
  • 21. http://www.galeon.com/neoprogramadores/citas001.html