Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Estrategias de Pruebas de Software

No description
by

Natux Lopez

on 15 September 2015

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Estrategias de Pruebas de Software

Verificación y Validación
Estrategias de Pruebas de Software
Enfoque Estratégico Para La Prueba de Software
Prueba Efectiva => Revisiones Tecnicas Efectivas
Componentes => Integración
Prueba != Depuración
Pruebas Bajo Nivel
Pruebas Alto Nivel
Estrategias de Prueba para Software Convencional
En un extremo realizar pruebas para todo el sistema
En el otro extremo realizar pruebas diariamente
Aspectos Estratégicos
Que Es
PorQue es Importante
Cual es el Producto Final
Como me aseguro de que lo hice bien
Organizacion de las Pruebas de Software
Estrategia de Prueba del Software. Vision General
Criterios para Completar las Pruebas
Prueba de Unidad
Pruebas de Integración
Consideraciones de las Pruebas de Unidad
Procedimientos
Integracion Incremental Descendente
Integración Incremental Ascendente
Producto de Trabajo
Prueba de Humo
Opciones Estratégicas
Prueba de Regresión
Estrategias de Prueba para Software Orientado a Objetos
Pruebas de Unidad en el contexto O.O.
Pruebas de Integración
en el Contexto OO
Estrategia de Pruebas para WebApps
Pruebas del Sistema
El Arte de la Depuracion
Conclusión
Criterios de pruebas de validación
Revisión de la Configuración
La intención es garantizar que todos los elementos de la configuración del Software se desarrollaron de manera adecuada
Pruebas Alfa y Beta
Cuando se construye software a la medida para un cliente, se realiza una serie de pruebas de aceptación a fin de permitir al cliente validar todos los requerimientos
Pruebas de Validación
Pruebas de Recuperación
Pruebas de Seguridad
Pruebas de Esfuerzo
¿Cuanto podemos doblar esto antes que se rompa?
Pruebas de Rendimiento
* Para Sistemas de Tiempo Real y Sistemas Embebidos, el Software que proporcione la función requerida, pero no se adecue a los rendimientos, es inaceptable
* Requieren instrumentación de Hardware y de Software, con frecuencia es necesario medir los recursos
Pruebas de Despliegue
El Software debe ejecutarse en varias plataformas y bajo mas de un entorno de sistemas operativos
Examina todos los procedimientos de instalación y el Software de instalación especializado
Ejercitar por Completo el Sistema
El Proceso de Depuración
Consideraciones Psicologicas
Estrategias de Depuración
Corrección del Error
El desarrollador de software no debe hacer pruebas
El software debe ponerse tras una pared
Quienes realicen las pruebas deben involucrarse con el proyecto sólo cuando los pasos de las pruebas estén por comenzar
Estrategia de Software
Especifican los requerimientos del producto en forma cuantificable mucho antes de comenzar
con las pruebas.
Establecen de manera explícita los objetivos de las pruebas.
Entienden a los usuarios del
software y desarrollan un
perfil para cada categoría
de usuario.
Desarrollan un plan de
prueba que enfatice
“pruebas de ciclo rápido”
Construyen software “robusto”
que esté diseñado para
probarse a sí mismo
Usan revisiones técnicas efectivas
como filtro previo a las pruebas.
Realizan revisiones técnicas
para valorar la estrategia de
prueba y los casos de prueba
Desarrollan un enfoque de
mejora continuo para el
proceso de prueba
La selección de una estrategia de integración depende de las características del software y, en ocasiones, del calendario del proyecto. En general, un enfoque combinado (a veces llamado prueba sándwich), que usa pruebas descendentes para niveles superiores de la estructura del programa acopladas con pruebas ascendentes para niveles subordinados, puede ser el mejor arreglo.
Especificación de pruebas.
Integridad de interfaz.
Validez funcional.
Contenido de la información.
Rendimiento.
Puesto que muchas webapps evolucionan continuamente, el proceso de prueba es una actividad siempre en marcha, y se realiza para apoyar al personal que usa pruebas de regresión derivadas de las pruebas desarrolladas cuando se elaboró por primera vez la webapp
La recuperación es una prueba del sistema que fuerza al software a fallar en varias formas y que verifica que la recuperación se realice de manera adecuada.
La depuración ocurre como consecuencia de las pruebas exitosas.
Desde el punto de vista procedural
¿Que hacer ?
Integración no incremental
Integración incremental
Primero en profundidad
Primero en anchura
Pruebas especiales
Ejecutar casos de prueba
Diseñar casos de prueba
Prueba de sensibilidad
Encontrar y corregir la causa de un error o defecto del sistema
Caracteristicas de una estrategia de prueba de Software
Clase encapsulada es el foco de la prueba de unidad.
La prueba de software es un elemento de un tema más amplio que usualmente se conoce como verificación y validación (V&V)
"No se puede probar la calidad. Si no esta ahí antes de comenzar las pruebas, no estará cuando termine de probar"
Verificación ¿Construimos el producto correctamente?
Validación ¿Construimos el producto correcto?
Boehm:
¿Cuando terminan las pruebas?
¿Como se sabe que se ha probado lo suficiente?
Entre los potenciales errores que deben ponerse a prueba cuando se evalúa el manejo errores están:
1) La descripción de error ininteligible
2) El error indicado no corresponde con el error que se encuentra
3) La condición del error causa la intervención del sistema antes de manejar el error
4) El procesamiento excepcional-condición es incorrecto
5) La descripción del error no proporciona suficiente información para auxiliar en la localización de la causa de error.
Es una importante estrategia para reducir "efectos colaterales". Corra pruebas de regresión cada vez que se realiza un cambio importante al Software.
Es comúnmente utilizado cuando se a desarrollado un producto de software EMPAQUETADO.Es diseñado como un mecanismo para proyectos críticos por tiempo, permitiendo que el equipo de software valore su proyecto sobre una base solida
Beneficios de la prueba de humo cuando se aplica sobre proyectos de Software complejos y cruciales en el tiempo:
* Se minimiza el riesgo de integración
* La calidad del producto final mejora
* El diagnóstico y la corrección de errores se simplifican
* El progreso es mas fácil de valorar


Existen dos estrategias diferentes
prueba basada
en hebras
prueba basada
en uso
"Trate a la construcción diaria como el latido del proyecto. Si no hay latido, el proyecto esta muerto"
Ejecuta un sistema que demanda recursos en cantidad, frecuencia y volumenes anormales.
Fuerza bruta:
-Probablemente es el método mas común y menos eficiente para aislar a la causa de un error de software.
-Se aplicado cuando todo lo demás falla "Deje que el ordenador encuentre el error"
Vuelta atras (backtracking)
Eliminacion de causas
Van Vleck: suguiere tres preguntas que tenemos que hacernos antes de hacer la "corrección"
1) ¿La causa del error se reproducirá en otra parte del programa?
2) ¿Qué "siguiente error" puede introducirse con la corrección que está a punto de realizar?
3) ¿Que debió hacerse para evitar este error desde el principio?
La prueba es generalmente considerada costosa y molesta. Pero como hemos acabamos de ver, es una molestia necesaria. La meta para la mayoría de las compañías debería ser hacer el mejor trabajo de prueba posible y minimizar los costos. Similarmente, entre más se pruebe el software, mayor cantidad de errores serán encontrados
Estrategias de Depuración
Encontrar y corregir la causa de un error o defecto del sistema
Vuelta atrás (backtracking):
-Enfoque de depuración bastante común que puede usarse exitosamente en programas pequeños.
-Comenzar en el sitio donde se descubrió un síntoma, el código fuente se rastrea hacia atrás (de manera manual) hasta que se encuentre la causa --> el numero de rutas potenciales hacia atrás puede volverse inmanejable.
Estrategias de Depuración
Encontrar y corregir la causa de un error o defecto del sistema
Eliminación de causas:
-Los datos relacionados con la ocurrencia del error se organizan para aislar las causas potenciales .
- Se hace una lista de las posible causas y se realizan pruebas para eliminar cada una.
. si una hipótesis de causa particular se muestra prometedora, los datos se refinan con la intención de aislar el error.
Validación del Software-->(diseño) - Plan de prueba
--> (generando) Casos de prueba Específicos --> Para Garantizar que:
Se satisfacen todos lo requerimientos de funcionamiento.
Se logran todas las características de comportamiento.
Todo el contenido es preciso y se presenta de manera adecuada.
Se logran todos lo requerimientos de rendimiento.
La documentación es correcta y se satisfacen la facilidad de uso y otros requerimientos.
Full transcript