Ud3 Contornos - Adriano

Descargar como pdf o txt
Descargar como pdf o txt
Está en la página 1de 6

DISEÑO Y REALIZACIÓN DE PRUEBAS

1. PLANIFICACIÓN DE LAS PRUEBAS


Durante todo el proceso de desarrollo de software, es necesario realizar un conjunto
de pruebas que permitan verificar que el software que se está creando, es correcto
y cumple con las especificaciones impuestas por el usuario.
Mediante la realización de pruebas se software, se van a realizar las tareas de
verificación y validación.
- Verificación: comprobación que un sistema o parte de un sistema cumple
con las condiciones impuestas.
- Validación: proceso de evaluación del sistema o uno de sus componentes
para determinar si satisface los requisitos especificados.
Para llevar a cabo el proceso de pruebas, de manera eficiente, es necesario
implementar una estrategia de pruebas.

2. TIPOS DE PRUEBA
Pruebas de Caja Negra: programa probado usando su interfaz externa, siendo
fundamental la comprobación de que los resultados de la ejecución son los
esperados.
Pruebas de Caja Blanca: se prueba la aplicación desde dentro, usando la lógica de
la misma.
Tipos de pruebas de software:
- Pruebas de unidad: se prueba el correcto funcionamiento de un módulo de
código.
- Pruebas de carga: evalúa el rendimiento de una aplicación bajo la carga
esperada de usuarios concurrentes y transacciones, revelando los tiempos de
respuesta y posibles cuellos de botella.
- Prueba de estrés: se utiliza para evaluar la resistencia de una aplicación
aumentando gradualmente el número de usuarios hasta que se rompe,
revelando su capacidad bajo cargas extremas y ayudando a prever su
rendimiento en situaciones de carga real.
- Prueba de estabilidad: determina si la aplicación puede aguantar una carga
esperada de manera continua.
- Prueba de picos: observa el comportamiento del sistema variando
drásticamente el número de usuarios conectados.
- Prueba estructural: se centra en la estructura interna del programa.
- Prueba funcional: se centra en las funciones, entradas y salidas que recibe
y produce un módulo de código
- Pruebas aleatorias: utiliza modelos que representen las posibles entradas al
programa y a partir de ellos crea los casos de prueba.
- Pruebas de regresión: detectan errores causados por cambios recientes en
el software que no existían previamente.

2.1 PRUEBAS FUNCIONALES


Su principal cometido, va a consistir, en comprobar el correcto funcionamiento de los
componentes de la aplicación informática. Para realizar este tipo de pruebas, se
deben analizar las entradas y las salidas de cada componente, verificando que el
resultado es el esperado. Solo se van a considerar las entradas y salidas del sistema,
sin preocuparnos por la estructura interna del mismo.
Dentro de las pruebas funcionales, podemos indicar tres tipos de pruebas:
- Particiones equivalentes: se reducen casos de prueba al mínimo al
representar varias entradas con un solo caso que se extrapola a toda la clase
de equivalencia, simplificando la verificación de errores.
- Análisis de valores límite: se seleccionan valores de entrada en los límites
de las clases de equivalencia para garantizar la cobertura exhaustiva de casos
críticos.
- Pruebas aleatorias: Se generan entradas al azar mediante generadores de
prueba para simular diversas condiciones de entrada.

2.2 PRUEBAS ESTRUCTURALES


Las pruebas estructurales, también conocidas como pruebas de caja blanca,
verifican la estructura interna de cada componente de la aplicación, asegurando la
ejecución de todas las instrucciones del programa y validando los caminos lógicos,
sin evaluar la corrección de los resultados.
Los criterios de cobertura que se siguen son:
- Cobertura de sentencias: garantiza que cada instrucción del programa se
ejecute al menos una vez mediante casos de prueba adecuados.
- Cobertura de decisiones: asegura que cada resultado posible de pruebas
lógicas se evalúe al menos una vez como verdadero y otra como falso.
- Cobertura de condiciones: verifica que cada elemento de una condición se
evalúe al menos una vez como falso y otra como verdadero.
- Cobertura de condiciones y decisiones: cumple simultáneamente con los
criterios de cobertura de decisiones y condiciones.
- Cobertura de caminos: garantiza que cada secuencia de sentencias desde
el inicio hasta el final del programa se ejecute al menos una vez.
- Cobertura del camino de prueba: incluye variantes que sugieren ejecutar
cada bucle solo una vez o tres veces: sin entrar, una vez, y dos veces, para
una prueba más efectiva.

2.3 PRUEBAS DE REGRESIÓN


Las pruebas de regresión aseguran que los cambios en un componente de una
aplicación no causen nuevos errores o comportamientos no deseados en otros
componentes no modificados.
Estas pruebas deben realizarse cada vez que se modifica el sistema, no solo para
validar los cambios específicos, sino también para prevenir efectos negativos en
otros componentes y garantizar la integridad del sistema.
Las pruebas de regresión implican repetir pruebas anteriores para evitar la
introducción de errores que puedan afectar componentes no modificados y confirmar
el correcto funcionamiento del sistema después de implementar cambios.

3. PROCEDIMIENTOS Y CASOS DE PRUEBA


Un caso de prueba es un conjunto de entradas, condiciones de ejecución y resultados
esperados, desarrollados para un objetivo particular.
En el diseño de los casos de prueba, siempre es necesario asegurar que con ellos se
obtiene un nivel aceptable de probabilidad de que se detectarán los errores
existentes.
Las pruebas deben buscar un compromiso entre la cantidad de recursos que se
consumirán en el proceso de prueba, y la probabilidad obtenida de que se detecten
los errores existentes.
Existen varios procedimientos para el diseño de los casos de prueba:
- Enfoque funcional o de caja negra: Centrado en verificar la entrada y salida
correcta del programa, sin considerar el proceso interno, asegurando la
integridad de la información externa.
- Enfoque estructural o caja blanca: Se enfoca en la implementación interna
del programa, probando todos los caminos posibles de ejecución para
garantizar que se ajusta a las especificaciones.
- Enfoque aleatorio: Genera casos de prueba estadísticamente para probar
las entradas del programa basado en modelos aleatorio.
4. HERRAMIENTAS DE DEPURACIÓN
Durante el desarrollo de software, se pueden producir dos tipos de errores: errores
de compilación (error que no permite la compilación del programa) y errores lógicos
(el código compila, pero el programa puede devolver resultados erróneos).
Los entornos de desarrollo cuentan con depuradores para supervisar la ejecución de
programas, identificar y corregir errores lógicos. Estos permiten analizar y modificar
variables, así como examinar resultados y valores durante la ejecución del programa.

4.1 PUNTOS DE RUPTURA


Los puntos de ruptura son marcadores en líneas de código ejecutable que, al
activarse durante la depuración, detienen la ejecución del programa en ese punto
para permitir la inspección de variables o el seguimiento paso a paso del código
desde allí.

4.2 TIPOS DE EJECUCIÓN


Para depurar un programa, se pueden utilizar diferentes métodos de ejecución, como
paso a paso por instrucción para verificar errores lógicos, paso a paso por
procedimiento para obtener resultados de métodos, ejecución hasta una instrucción
para detenerse en puntos específicos, y ejecución hasta el final del programa para
ejecutar todas las instrucciones sin interrupción.

5. VALIDACIONES
Hay que tener en cuenta, que estamos desarrollando una aplicación para terceros, y
que son estos los que deciden si la aplicación se ajusta a los requerimientos
establecidos en el análisis.
La validación del software se logra a través de pruebas de caja negra que
comprueban la conformidad con los requisitos establecidos. Un plan de prueba
define los tipos de pruebas necesarias, mientras que un procedimiento de prueba
detalla casos específicos para descubrir errores y asegurar el cumplimiento de
requisitos funcionales, de rendimiento y otros como portabilidad y mantenimiento.
Durante la validación del software, los casos de prueba pueden resultar en
características aceptables según las especificaciones o en la detección de
desviaciones, generando una lista de deficiencias que rara vez pueden corregirse
antes de la finalización planificada del proyecto.
6. PRUEBAS DE CÓDIGO
Una prueba de código implica ejecutar un programa bajo condiciones especificadas
para detectar errores, con resultados registrados y evaluados.
Se diseñan casos de prueba utilizando tres enfoques principales:
- Estructural (caja blanca), que analiza la estructura interna y los caminos de
ejecución.
- Funcional (caja negra), que se centra en las funciones y las entradas y
salidas.
- Aleatorio, que utiliza modelos para generar casos de prueba que simulan las
entradas habituales del programa.

6.1 CUBRIMIENTO
Con este tipo de prueba, lo que se pretende, es comprobar que todas las funciones,
sentencias, decisiones, y condiciones, se van a ejecutar.

6.2 VALORES LÍMITE


Esta técnica, se enfoca en seleccionar unos pocos valores en el límite del rango
aceptado por el componente a probar, en lugar de un conjunto completo.

6.3 CLASES DE EQUIVALENCIA


Las clases de equivalencia dividen los valores de entrada en un número finito de
clases. Cada clase cubre un conjunto representativo de entradas y se enfoca en
asegurar la representación de valores por debajo, dentro y por encima de un rango,
dentro o fuera de un conjunto, o en términos booleanos (sí o no), tanto para las
entradas como para las salidas esperadas.

8. PRUEBAS UNITARIAS
Las pruebas unitarias tienen como objetivo verificar el correcto funcionamiento de
módulos de código individualmente, asegurando que cada método se prueba de
manera independiente.
En el diseño de los casos de pruebas unitarias, habrá que tener en cuenta los
siguientes requisitos:
- Automatizable: sin intervención manual.
- Completas: deben cubrir la mayor cantidad de código.
- Repetibles: no se deben crear pruebas que sólo pueden ser ejecutadas una
sola vez.
- Independientes: la ejecución de una prueba no debe afectar a la ejecución
de otra.
- Profesionales: las pruebas deben ser consideradas igual que el código, con
la misma profesionalidad, documentación, etc.
Las pruebas individuales nos proporcionan cinco ventajas básicas:
- Fomentan el cambio.
- Simplifica la integración.
- Documenta el código.
- Separación de la interfaz y la implementación.
- Los errores están más acotados y son más fáciles de localizar.

También podría gustarte