RA3 · verificado

RA3 de Entornos de Desarrollo · DAM

Verifica el funcionamiento de programas diseñando y realizando pruebas.

Contenido verificado asociado a este RA

Fundamentos de las Pruebas de Software y Tipos de Pruebas

Esta unidad introduce la importancia de las pruebas en el ciclo de vida del desarrollo de software, diferenciando entre verificación y validación. Se exploran los distintos tipos de pruebas, como unitarias, de integración, de sistema y de aceptación, clasificándolas por su alcance y enfoque.

Diseño de Casos de Prueba y Gestión de Incidencias

Esta unidad aborda la metodología para definir casos de prueba efectivos, utilizando técnicas como el particionamiento por equivalencia y el análisis de valores límite. También se cubre la importancia y el procedimiento para documentar adecuadamente las incidencias detectadas durante las pruebas.

Depuración de Aplicaciones con el Entorno de Desarrollo (IDE)

Esta unidad explora las herramientas de depuración integradas en los Entornos de Desarrollo Integrados (IDE). Se aprenderá a utilizar puntos de ruptura para pausar la ejecución, seguir el flujo del programa paso a paso y examinar/modificar el estado de las variables en tiempo de ejecución para diagnosticar y corregir errores.

Pruebas Unitarias Automatizadas

Esta unidad se centra en la implementación de pruebas unitarias para clases y funciones, utilizando frameworks de testing. Se aborda la creación de pruebas automáticas que verifican el comportamiento esperado del código, mejorando la fiabilidad y facilitando la refactorización.

Conceptos clave

VerificaciónValidaciónPruebas unitariasPruebas de integraciónPruebas de sistemaPruebas de aceptaciónPruebas de caja blancaPruebas de caja negraCaso de pruebaPrecondicionesPasos de ejecuciónResultado esperadoParticionamiento por equivalenciaAnálisis de valores límiteIncidencia (bug)SeveridadPrioridadPasos para reproducir

Errores que conviene evitar

No realizar pruebas unitarias: Causa una detección tardía de errores, haciendo su corrección más costosa. Corrección: Integrar las pruebas unitarias como parte del proceso de desarrollo diario.
Confundir pruebas de integración con pruebas de sistema: Causa una cobertura de pruebas deficiente en las interfaces entre módulos. Corrección: Entender que las pruebas de integración se centran en la comunicación entre componentes, mientras que las de sistema validan el comportamiento global del software.
Casos de prueba ambiguos o incompletos: Causa resultados de prueba inconsistentes y dificultad para determinar si un error es real. Corrección: Asegurarse de que cada caso de prueba tenga un resultado esperado claro y pasos de ejecución detallados.
Documentación de incidencias sin pasos de reproducción: Causa frustración en los desarrolladores y retrasos en la corrección. Corrección: Siempre incluir pasos claros y concisos para reproducir el error, verificándolos antes de reportar.
No usar puntos de ruptura condicionales: Causa una depuración ineficiente, deteniéndose en cada iteración de un bucle grande. Corrección: Aprender a usar condiciones para los puntos de ruptura para enfocarse en el caso problemático.
Ignorar la pila de llamadas: Causa dificultad para entender el flujo de ejecución que llevó a un error. Corrección: Revisar la pila de llamadas para identificar la secuencia de funciones que se invocaron hasta el punto de ruptura.
Escribir pruebas unitarias demasiado complejas: Causa pruebas difíciles de entender y mantener. Corrección: Cada prueba debe enfocarse en una única funcionalidad y ser lo más simple posible.
No mantener las pruebas actualizadas: Causa que las pruebas se vuelvan obsoletas y den falsos positivos o negativos. Corrección: Las pruebas deben refactorizarse y actualizarse junto con el código de producción.

Qué se evalúa en este RA

CE a

Se han identificado los diferentes tipos de pruebas.

CE b

Se han definido casos de prueba.

CE c

Se han identificado las herramientas de depuración y prueba de aplicaciones ofrecidas por el entorno de desarrollo.

CE d

Se han utilizado herramientas de depuración para definir puntos de ruptura y seguimiento.

CE e

Se han utilizado las herramientas de depuración para examinar y modificar el comportamiento de un programa en tiempo de ejecución.

CE f

Se han efectuado pruebas unitarias de clases y funciones.

CE g

Se han implementado pruebas automáticas.

CE h

Se han documentado las incidencias detectadas.