Prubea de software

2,272 views

Published on

Published in: Technology
0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,272
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
151
Comments
0
Likes
5
Embeds 0
No embeds

No notes for slide

Prubea de software

  1. 1. UNIVERSIDAD JUAREZ AUITONOMA DE TABASCO DIVISION ACADEMICA DE INFORMATICA Y SISTEMAS NOMBRE DE LA EXPOSICION: Prueba de Software MATERIA: Fundamento de Ingeniería de Software PROFESOR: Julián Alejandro González Arellano ALUMNOS: Lucio Alejandro Pimienta Pineda Miguel Ángel López Luna Antolín Arias Solís
  2. 2. PRUEBA DE SOFTWARE Fundamentos de Ingeniería de Software
  3. 3. DEFINICIÓNEs un conjunto de actividades que se planean conanticipación y se realizan de manera sistemática. Portanto, se debe definir una plantilla para las pruebas delsoftware (un conjunto de pasos en que se puedan incluirtécnicas y métodos específicos del diseño de casos deprueba.).
  4. 4. Pruebas vs Depuración• Pruebas es el proceso de demostrar la presencia de fallos en el software. El defecto o error es una imperfección en el software, que se manifiesta en un fallo de ejecución• Depuración es el proceso de localizar errores y el subsecuente arreglo de los mismos.
  5. 5. Proceso de Fase de PruebasPara asegurar el correcto funcionamiento de unsistema de software completo y garantizar lasatisfacción del cliente se debe implementar unaestrategia de pruebas que incluya: Pruebas unitarias Pruebas de integración Pruebas de validación Pruebas de sistema Pruebas de aceptación
  6. 6. PruebasUnitarias Sistema Requisitos del Especificación Funcional Otros requisitos cliente Entorno del del Diseño (requisitos) de software (especificación) clientePruebasUnitarias Pruebas de Pruebas de Pruebas Pruebas de Pruebas de Eficiencia, Inteligencia Funcionales aceptación instalación carga, etc.PruebasUnitarias Módulos Sistema Verificado Sistema Sistema Integrados Funcionando y Validado aceptado en usoPruebasUnitarias
  7. 7. Pruebas de Unidad o UnitariasLas pruebas unitarias tienen como objetivo verificar lafuncionalidad y estructura de cada componenteindividualmente una vez que ha sido codificado.Las pruebas de unidad es un proceso para probar lossubprogramas, las subrutinas, los procedimientosindividuales o las clases en un programa.
  8. 8. Primera, las pruebas de unidad son una manera demanejar los elementos de prueba combinados, puesto quese centra la atención inicialmente en unidades máspequeñas del programaEn segundo lugar, la prueba de una unidad facilita la tareade eliminar errores (el proceso de establecer claramente yde corregir un error descubierto), puesto que, cuando seencuentra un error, se sabe que existe en un móduloparticular.
  9. 9. Finalmente, las pruebas de unidad introducenparalelismo en el proceso de pruebas del softwarepresentándose la oportunidad de probar los múltiplesmódulos simultáneamente.
  10. 10. Las pruebas de unidad son en gran parteorientadas a caja blanca.Una razón es que como en pruebas de entidadesmás grandes tales como programas enteros (es elcaso para los procesos de pruebasubsecuentes), la prueba de caja blanca llega aser menos factible.
  11. 11. Errores• interfaces entre módulos• interfaces entrada/salida• estructuras de datos locales• cálculos• flujo de control• caminos de procesamiento de errores
  12. 12. Técnicas de Pruebas Basadas en CódigoPrueba de Caja Negra Basadas en el flujo de datos Se Usan cuando se quiere probar lo que hace el software pero no como lo hace y pueden hacer  Dinámicas  Estáticas
  13. 13. Técnicas de Pruebas Basadas en CódigoPrueba de Caja Blanca Basadas en el flujo de control . Son pruebas unitarias que se usan cuando se conoce la estructura interna y el funcionamiento del código a probar y pueden ser  Dinámicas  Estáticas
  14. 14. Tipos de pruebas UnidadPruebas Top-Down.El primer componente que se desarrolla y prueba es elprimero de la jerarquía (A). Los componentes de nivel másbajo se sustituyen por componentes auxiliares para simulara los componentes invocados.Ventaja: una de las ventajas de aplicar esta estrategia esque las interfaces entre los distintos componentes seprueban en una fase temprana y con frecuencia.
  15. 15. Tipos de pruebas UnidadEstrategias combinadas.A menudo es útil aplicar las estrategias anterioresconjuntamente. De este modo, se desarrollan partes delsistema con un enfoque "top-down", mientras que loscomponentes más críticos en el nivel más bajo sedesarrollan siguiendo un enfoque "bottom-up". En estecaso es necesaria una planificación cuidadosa ycoordinada de modo que los componentes individuales seencuentren en el centro.
  16. 16. Prueba de IntegraciónEl objetivo de las pruebas de integración es verificar elcorrecto ensamblaje entre los distintos componentes unavez que han sido probados unitariamente con el fin decomprobar que interactúan correctamente a través de susinterfaces, tanto internas como externas, cubren lafuncionalidad establecida y se ajustan a los requisitos nofuncionales especificados en las verificacionescorrespondientes.
  17. 17. Errores• comunicación a través de la interface• efectos colaterales perniciosos• acumulación notable de errores de cálculo• acceso incoherente a estructuras de datos• globales• tiempos de respuesta
  18. 18. Los tipos fundamentales de integración son los siguientes: Integración incremental: se combina el siguiente componente que se debe probar con el conjunto de componentes que ya están probados y se va incrementando progresivamente el número de componentes a probar. Integración no incremental: se prueba cada componente por separado y posteriormente se integran todos de una vez realizando las pruebas pertinentes.
  19. 19. Verificación y ValidaciónVerificación es el conjunto de actividades que aseguranque el software implemente correctamente una funcionespecifica.Validación es un conjunto diferente de actividades queaseguran que el software construido corresponde con losrequisitos del cliente.La verificación y la validación abarcan una amplia lista deactividades se aseguramiento de la calidad del software:revisiones técnicas formales, auditorias de calidad y deconfiguración, monitoreo deldesempeño, simulación, factibilidad, revisión de ladocumentación y base de datos etc.
  20. 20. Verificación vs Validación• Validación: ¿Estamos construyendo el sistema correcto? Proceso de evaluación de un sistema o componentedurante o al final del proceso de desarrollo para comprar si sesatisfacen los requisitos especificados (IEE std610.12-1990)• Verificación: ¿Estamos construyendo correctamente el sistema? - Proceso de evaluar un sistema o componente para determinar si los productos obtenidos en una determinada fase de desarrollo satisfacen las condiciones impuestas al comienzo de dicha fase. -Evaluación de la calidad de la implementación
  21. 21. Prueba de Sistemas
  22. 22. Prueba de SistemasLas pruebas de sistema buscan discrepancias entre elprograma y sus objetivos o requerimientos, enfocándoseen los errores hechos durante la transición del proceso aldiseñar la especificación funcional. Esto hace a laspruebas de sistema un proceso vital de pruebas, ya que entérminos del producto, número de errores hechos, yseveridad de esos errores, es un paso en el ciclo dedesarrollo generalmente propenso a la mayoría de loserrores.
  23. 23. Prueba de SistemasLas pruebas del sistema tienen un propósito particular:para comparar el sistema o el programa con sus objetivosoriginales (Requerimientos funcionales y no funcionales).Dado este propósito, se presentan dos implicaciones:• Las pruebas de sistema no se limitan a los sistemas. Si el producto es un programa, la prueba del sistema es el proceso de procurar demostrar cómo el programa, en su totalidad, no resuelve sus objetivos o requerimientos.• Las pruebas de sistema, por definición, son imposibles si no están los requerimientos por escrito, mensurables para el producto.
  24. 24. Prueba de SistemasLas pruebas de sistema tienen como objetivo ejercitarprofundamente el sistema comprobando la integración delsistema de información globalmente, verificando elfuncionamiento correcto de las interfaces entre los distintossubsistemas que lo componen y con el resto de sistemasde información con los que se comunicaSon pruebas de integración del sistema de informacióncompleto, y permiten probar el sistema en su conjunto ycon otros sistemas con los que se relaciona para verificarque las especificaciones funcionales y técnicas secumplen. Dan una visión muy similar a su comportamientoen el entorno de producción.
  25. 25. Prueba de SistemasExisten diferentes muchos tipos de pruebas: De Comunicaciones De Rendimiento  De Seguridad De Recuperación  De Usabilidad De Volumen  De Almacenamiento De Sobrecarga  De Configuración De Tensión  De Instalación De Disponibilidad de datos  De Documentación De Facilidad de Uso De Operación De Entorno
  26. 26. Prueba de AceptaciónPruebas de Aceptación.• El objetivo de las pruebas de aceptación es validar que un sistema cumple con el funcionamiento esperado y permitir al usuario de dicho sistema que determine su aceptación, desde el punto de vista de su funcionalidad y rendimiento.• Las pruebas de aceptación son definidas por el usuario del sistema y preparadas por el equipo de desarrollo, aunque la ejecución y aprobación final corresponden al usuario.
  27. 27. Prueba de Aceptación• La validación del sistema se consigue mediante la realización de pruebas de caja negra que demuestran la conformidad con los requisitos y que se recogen en el plan de pruebas, el cual define las verificaciones a realizar y los casos de prueba asociados. Dicho plan está diseñado para asegurar que se satisfacen todos los requisitos funcionales especificados por el usuario teniendo en cuenta también los requisitos no funcionales relacionados con el rendimiento, seguridad de acceso al sistema, a los datos y procesos, así como a los distintos recursos del sistema.
  28. 28. Mayores Informes.http://200.69.103.48/comunidad/grupos/arquisoft/fileadmin/Estudiantes/Pruebas/HTML%20-%20Pruebas%20de%20software/node55.htmlhttp://lsi.ugr.es/~ig1/docis/pruso.pdf

×