Este documento presenta información sobre pruebas de software. Explica diferentes tipos de pruebas como pruebas unitarias, de integración, de validación y de sistema. También define conceptos clave como verificación y validación y describe el proceso general de pruebas de software para garantizar el correcto funcionamiento de un sistema.

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. PRUEBA DE SOFTWARE
Fundamentos de Ingeniería de
Software

3. DEFINICIÓN
Es un conjunto de actividades que se planean con
anticipación y se realizan de manera sistemática. Por
tanto, se debe definir una plantilla para las pruebas del
software (un conjunto de pasos en que se puedan incluir
técnicas y métodos específicos del diseño de casos de
prueba.)
.

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. Proceso de Fase de Pruebas
Para asegurar el correcto funcionamiento de un
sistema de software completo y garantizar la
satisfacción del cliente se debe implementar una
estrategia de pruebas que incluya:
 Pruebas unitarias
 Pruebas de integración
 Pruebas de validación
 Pruebas de sistema
 Pruebas de aceptación

6. Pruebas
Unitarias
Sistema Requisitos del
Especificación Funcional Otros requisitos cliente Entorno del
del Diseño (requisitos) de software (especificación) cliente
Pruebas
Unitarias
Pruebas de
Pruebas de Pruebas Pruebas de Pruebas de
Eficiencia,
Inteligencia Funcionales aceptación instalación
carga, etc.
Pruebas
Unitarias Módulos Sistema Verificado Sistema Sistema
Integrados Funcionando y Validado aceptado en uso
Pruebas
Unitarias

7. Pruebas de Unidad o Unitarias
Las pruebas unitarias tienen como objetivo verificar la
funcionalidad y estructura de cada componente
individualmente una vez que ha sido codificado.
Las pruebas de unidad es un proceso para probar los
subprogramas, las subrutinas, los procedimientos
individuales o las clases en un programa.

8. Primera, las pruebas de unidad son una manera de
manejar los elementos de prueba combinados, puesto que
se centra la atención inicialmente en unidades más
pequeñas del programa
En segundo lugar, la prueba de una unidad facilita la tarea
de eliminar errores (el proceso de establecer claramente y
de corregir un error descubierto), puesto que, cuando se
encuentra un error, se sabe que existe en un módulo
particular.

9. Finalmente, las pruebas de unidad introducen
paralelismo en el proceso de pruebas del software
presentándose la oportunidad de probar los múltiples
módulos simultáneamente.

10. Las pruebas de unidad son en gran parte
orientadas a caja blanca.
Una razón es que como en pruebas de entidades
más grandes tales como programas enteros (es el
caso para los procesos de prueba
subsecuentes), la prueba de caja blanca llega a
ser menos factible.

11. Errores
• interfaces entre módulos
• interfaces entrada/salida
• estructuras de datos locales
• cálculos
• flujo de control
• caminos de procesamiento de errores

12. Técnicas de Pruebas Basadas
en Código
Prueba 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. Técnicas de Pruebas Basadas
en Código
Prueba 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. Tipos de pruebas Unidad
Pruebas Top-Down.
El primer componente que se desarrolla y prueba es el
primero de la jerarquía (A). Los componentes de nivel más
bajo se sustituyen por componentes auxiliares para simular
a los componentes invocados.
Ventaja: una de las ventajas de aplicar esta estrategia es
que las interfaces entre los distintos componentes se
prueban en una fase temprana y con frecuencia.

15. Tipos de pruebas Unidad
Estrategias combinadas.
A menudo es útil aplicar las estrategias anteriores
conjuntamente. De este modo, se desarrollan partes del
sistema con un enfoque "top-down", mientras que los
componentes más críticos en el nivel más bajo se
desarrollan siguiendo un enfoque "bottom-up". En este
caso es necesaria una planificación cuidadosa y
coordinada de modo que los componentes individuales se
encuentren en el centro.

16. Prueba de Integración
El objetivo de las pruebas de integración es verificar el
correcto ensamblaje entre los distintos componentes una
vez que han sido probados unitariamente con el fin de
comprobar que interactúan correctamente a través de sus
interfaces, tanto internas como externas, cubren la
funcionalidad establecida y se ajustan a los requisitos no
funcionales especificados en las verificaciones
correspondientes.

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. 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. Verificación y Validación
Verificación es el conjunto de actividades que aseguran
que el software implemente correctamente una funcion
especifica.
Validación es un conjunto diferente de actividades que
aseguran que el software construido corresponde con los
requisitos del cliente.
La verificación y la validación abarcan una amplia lista de
actividades se aseguramiento de la calidad del software:
revisiones técnicas formales, auditorias de calidad y de
configuración, monitoreo del
desempeño, simulación, factibilidad, revisión de la
documentación y base de datos etc.

20. Verificación vs Validación
• Validación: ¿Estamos construyendo el sistema correcto?
Proceso de evaluación de un sistema o componente
durante o al final del proceso de desarrollo para comprar si se
satisfacen 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. Prueba de Sistemas

22. Prueba de Sistemas
Las pruebas de sistema buscan discrepancias entre el
programa y sus objetivos o requerimientos, enfocándose
en los errores hechos durante la transición del proceso al
diseñar la especificación funcional. Esto hace a las
pruebas de sistema un proceso vital de pruebas, ya que en
términos del producto, número de errores hechos, y
severidad de esos errores, es un paso en el ciclo de
desarrollo generalmente propenso a la mayoría de los
errores.

23. Prueba de Sistemas
Las pruebas del sistema tienen un propósito particular:
para comparar el sistema o el programa con sus objetivos
originales (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. Prueba de Sistemas
Las pruebas de sistema tienen como objetivo ejercitar
profundamente el sistema comprobando la integración del
sistema de información globalmente, verificando el
funcionamiento correcto de las interfaces entre los distintos
subsistemas que lo componen y con el resto de sistemas
de información con los que se comunica
Son pruebas de integración del sistema de información
completo, y permiten probar el sistema en su conjunto y
con otros sistemas con los que se relaciona para verificar
que las especificaciones funcionales y técnicas se
cumplen. Dan una visión muy similar a su comportamiento
en el entorno de producción.

25. Prueba de Sistemas
Existen 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. Prueba de Aceptación
Pruebas 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. 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. Mayores Informes.
http://200.69.103.48/comunidad/grupos/arquisoft/fileadmin/Estudiantes/Prue
bas/HTML%20-%20Pruebas%20de%20software/node55.html
http://lsi.ugr.es/~ig1/docis/pruso.pdf