Este documento presenta información sobre pruebas de software, incluyendo diferentes tipos de pruebas como pruebas unitarias, de integración, de sistema y de aceptación. También describe técnicas de prueba como caja blanca y caja negra, y procesos como el diseño de casos de prueba y la ejecución y seguimiento de resultados de las pruebas. El documento provee una guía detallada para la planificación y ejecución efectiva de pruebas de software.

1. Unidad 4: INTRODUCCION A LAS
ARQUITECTURASWEB
4.3 N-capas
4.4 Pruebas Unitarias
Plataformas de Desarrollo 1
Modalidad de estudios: Presencial
Mg. Luis Fernando Aguas Bucheli
+593 984015184
@Aguaszoft
Laguas@uisrael.edu.ec
Lfabsoft2019@gmail.com

2. Objetivos del encuentro:
1. Adquirir los conceptos básicos relacionados con NET.
2. Reconocer las características de .NET.
3. Conocer la historia de .NET
Semana Nro. 16

3. Frase Motivacional
“Si no sueltas el pasado, ¿con qué
mano agarras el futuro?.”

4. 4
Pruebas de Programas
• Pruebas de programas es el proceso de ejecutar programas con el
propósito de encontrar errores
• Se puede mostrar la presencia de un error pero no la ausencia
[Dijkstra]
• Debería ser visto como el último recurso para encontrar errores

5. 5
Preparar Casos
de Prueba
Ejecutar Casos
de Prueba
Seleccionar y Priorizar los
errores para corrección
Corregir
Congelar versión del
Sw para Pruebas
Errors
Detectados?
Version
Acceptada
NO
SI
Verificar Correcciones Congelar versión
corregida del Sw
Hacer Pruebas Totales o
parciales de Regresión
Proceso de Pruebas de Programas

6. 6
Proceso de Pruebas de Programas:
Depuración
Diagnosticar
Error
Planificar Cambios
Actualizar Diseño Arquitec.
Actualizar Diseño Detallado
Actualizar
código
Actualizar Requerimientos
Probar los
Cambios
Seleccionar casos de
prueba para probar
los cambios
Selecionar casos de
Prueba para Pruebas de
Regresión
Pruebas de Regresión
?

7. 7
Definición de Requerimientos
Análisis Requirementos
Diseño Arquitectura
Diseño Detallado
Programación
Pruebas
Unitarias
Preparacion
Pruebas Unit.
Pruebas
Integración
Preparación
Integración
Pruebas
SIstema
Preparación
Pruebas Sistema
Preparación
Pruebas Aceptación
Pruebas
Aceptación
Ciclo en V

8. 8
Técnicas de Prueba
• Caja blanca o pruebas estructurales
• El conocimiento del diseño interno del software se usa para desarrollar los
casos de pruebas
• Caja negra o pruebas funcionales
• Los casos de prueba son diseñados basados sólo en la especificación externa
del software
• Pruebas basadas en escenarios o casos de uso
• Actuar como un usuario final y crear escenarios reales para detectar errores

9. 9
Técnicas de Prueba (2)
• Pruebas Selectivas
• Generar más casos de prueba para las funciones o componentes que son más
usados
• Probar más rigurosamente las funciones o componentes más críticos
• Generar mas casos de prueba para las funciones o componentes más
complejos

10. 10
Pruebas Unitarias (1)
• Descripción
• Su propósito es encontrar errores en la lógica, datos o algoritmos en
componentes o subsistemas individuales
• Realizado por los desarrolladores del componente
• Técnica de prueba: Caja blanca

11. 11
Pruebas Unitarias (2)
• Guías para generar casos de prueba
• Tratar de detectar errores en los algoritmos y la lógica
• Tratar de detectar errores en la manipulación de las estructuras de datos
• Tratar de detectar errores en el llamado a otros módulos
• Identificar todos los caminos posibles del módulo y tratar de hacer casos de
prueba que los cubran
• Tratar de detectar errores usando datos límites

12. 12
Pruebas de Integración
• Descripción
• Su propósito es encontrar errores en las interfaces entre los módulos
• Realizado por los desarrolladores de los módulos que serán integrados
• Técnica de Prueba: Caja negra basado en las especificaciones de las interfaces

13. 13
Pruebas de Integración (2)
• Guías para generar casos de prueba
• Tratar de detectar errores en los formatos de intercambio de datos
• Tratar de detectar errores en en el orden en que interactúan los módulos, la
sincronización y los tiempos de respuesta

14. 14
Pruebas de Sistema
• Descripción
• Su propósito es encontrar errores en el comportamiento del sistema de
acuerdo con la especificación de requerimientos
• Realizado por un grupo diferente al de desarrollo
• Técnica de Prueba: Caja negra basado en los requerimientos y en escenarios
reales

15. 15
Pruebas de Sistema (2)
• Guías para generar casos de prueba
• Verificar que la funcionalidad del sistema es correcta y completa
• Verificar que el sistema tiene la capacidad volumétrica, de robustez y que se
comporta bien ante fallas

16. 16
Pruebas de Aceptación
• Descripción
• Su propósito es verificar que el sistema satisface los requerimientos del
cliente (en el sitio del cliente)
• Realizado por un grupo de usuarios finales
• Técnicas de Prueba: Caja negra basado en los requerimientos y en escenarios
reales
• Guías para generar casos de prueba
• Similar a pruebas del sistema

17. 17
Pruebas de Regresión
• Descripción
• Su propósito es verificar que, después de un cambio, las partes no cambiadas
del sistema se siguen comportanto igual (no hay efectos de borde)
• Están asociadas al mantenimiento de Software

18. 18
Conceptos
• Espacio de Prueba
• Conjunto de todos los posibles casos de Prueba
• Pruebas de subdominios
• Subconjuntos del espacio de Prueba
• Línea de Prueba (Test Suite)
• Conjunto de casos de prueba que serán ejecutados en una fase

19. 19
Conceptos (2)
• Testbed/Test Harness
• Software adicional desarrollado para soportar la ejecución de los casos de
prueba
• Prueba de Cubrimiento
• Grado en el cual los casos de prueba “pasan” por el código siendo probado

20. 20
Estructura del Espacio de Pruebas
• Taxonomia de los Casos de Prueba
• Pruebas Funcionales: considerar solamente entradas válidas al sistema y
condiciones normales de operación.
• Pruebas de Robustez: considerar datos de entrada inválidos, secuencias
invalidas de comandos/acciones, etc.
• Pruebas de Frontera: considerar valores/tamaños mínimos y máximos para
datos de entrada, carga del sistema mínima y máxima, etc.

21. 21
Estructura del Espacio de Pruebas (2)
• Taxonomia de los Casos de Prueba
• Pruebas de tolerancia a fallas: considerar condiciones anormales de
operación, fallas hardware y software de la plataforma computacional sobre
la que funciona el software en prueba.

22. 22
Diseño de los Casos de Prueba
• Hacer una lista de los propósitos de Prueba
• Usar la taxonomía de los casos de prueba como guía

23. 23
Diseño de los Casos de Prueba (2)
• Por cada propósito de Prueba, hacer una lista de casos de prueba
• Construir una versión preliminar de la lista de casos de prueba a partir de los
escenarios típicos relacionados con el propósito de prueba
• Enriquecer la lista de casos de prueba, analizando las posibles variaciones o
casos especiales de los escenarios considerados
• Complementar la lista de casos de prueba, analizando posibles casos que
puedan revelar errores, usando como guía la siguiente lista de chequeo:

24. 24
Diseño de los Casos de Prueba (3)
• Cuales son los errores típicos encontrados en productos similares probados
en el pasado, y que casos de prueba se usaron para revelarlos?
• En pruebas del sistema y pruebas de aceptación, qué casos es probable que
los desarrolladores hubieran pasado por alto (desde el punto de vista del
experto del negocio o dominio de aplicación)?
• En pruebas de unidad y pruebas de integración, qué características complejas
del diseño pudieron haber sido implementadas de forma incorrecta?

25. 25
Diseño de los Casos de Prueba (4)
• En pruebas del sistema y pruebas de aceptación, qué aspectos complejos
acerca de los requerimientos pudieron haber sido mal interpretados por los
desarrolladores?
• Qué casos triviales pudieran haber sido no tenidos en cuenta en la
implementación?

26. 26
Diseño de los Casos de Prueba (5)
• Para cada caso de prueba, especificar los pasos para realizar la prueba
y los criterios de aceptación de la prueba, tal como se indica en el
formato:

27. 27
Diseño de los Casos de Prueba (6)
• Caso de uso
• Procedimiento
• Criterios de aceptación
• Procedimiento
• Criterios de aceptación
• ...
• Caso de uso
• ...
• ...

28. 28
Diseño de los Casos de Prueba (7)
• Para cada caso de prueba se debe especificar
• Instrucciones de prueba: lista de pasos a seguir por los usuarios encargados
de ejecutar la prueba.
• Criterios de aceptación: lista de condiciones (predicados) que deben
satisfacerse para determinar el éxito de la prueba, incluyendo restricciones
sobre los datos de salida esperados, y condiciones que deben cumplirse en el
estado interno del sistema (ej. valores de algunas tablas) después de ejecutar
el caso de prueba.

29. Direccionamiento actividades de aprendizaje
Actividades:
• Revisar el aula virtual
• Realizar las actividades y tareas planteadas.
Se recomienda describir por ejemplo:
• Tomar apuntes esenciales, revisar el material de clases

30. Bibliografía

31. GRACIAS