Diseño y Realización de Pruebas en el Desarrollo de Software

BIENVENIDA

THE E-LEARNING COURSE DISEÑO Y REALIZACIÓN DE ENTORNOS DE DESARROLL O PRUEBAS Profesora: Lucía Madrero Nieto

DISEÑO Y REALIZACIÓN DE PRUEBAS

Sumario

1. Introducción.
2. Procedimientos de pruebas y casos de prueba.
3. Casos de prueba.
4. Creación de casos de prueba
5. Codificación y ejecución de las pruebas.
6. Tipos de pruebas: funcionales, estructurales y regresión.
7. Pruebas estructurales.
8. Pruebas de Caja Blanca
9. Pruebas de regresión.

1 de 16UD 3 - DISEÑO Y REALIZACIÓN DE PRUEBAS

Introducción a las Pruebas de Software

A continuación vamos a describir algunos términos que usaremos en la presente unidad didáctica:

1. Caso de prueba -> Conjunto de entradas, condiciones de ejecución y salidas esperadas diseñadas para un objetivo concreto. Los casos de prueba forman parte de las pruebas a un software.
2. Fiabilidad -> Probabilidad de que un software cumpla con su función sin errores durante un tiempo determinado. Se busca que el software sea lo más fiable posible.
3. MD5 (message digest algorithm 5, algoritmo de reducción criptográfico) o Función hash -> Se utiliza para saber si algún dato, archivo o información ha sido modificado.
4. Prueba de regresión -> Prueba automatizada que puede servir para corroborar, tras la modificación de un software, que todo va a funcionar como debería.
5. Release -> Versión definitiva de un software que puede comercializarse o distribuirse.
6. RTF (revisión técnica formal) -> Revisión realizada por el auditor y el desarrollador de software a un programa o sistema.
7. SQA (Software Quality Assurance) -> Control de Calidad.
8. Tester o ingeniero de pruebas -> Profesional independiente del equipo de desarrollo, que suele ser programador y poseer amplios conocimientos en informática. Su función es participar en la fase de pruebas de un sistema.
9. Versión alfa -> Primera fase de la versión de un software. Cuando está en fase alfa, el software se prueba en un entorno y características determinadas y controladas por el desarrollador. No es la versión definitiva.
10. Versión beta -> Versión próxima a la versión definitiva. El software no se prueba en el entorno de desarrollo como en la versión alfa, sino que puede probarlo el cliente en su ubicación. La versión beta sirve para detectar anomalías no detectadas durante las pruebas de la versión alfa. Una versión beta puede probarse por muchas personas (pueden llegar a ser miles), mientras que una alfa se prueba solamente por un grupo reducido de personas. Tras probar la versión beta y corregir los errores, se liberará una release o versión definitiva.

Siendo realistas, es prácticamente imposible realizar pruebas exhaustivas a un programa, porque sería demasiado costoso. Salvo que el programa sea tan importante como para realizarlas, lo que se hace es llegar a un punto intermedio en el cual se garantiza que no va a 2 de 16UD 3 - DISEÑO Y REALIZACIÓN DE PRUEBAS haber defectos importantes o muchos defectos y la aplicación está completamente operativa con un funcionamiento aceptable.

El objetivo de las pruebas es convencer, tanto a los usuarios como a los propios desarrolladores, de que el software es lo suficientemente robusto como para poder trabajar con él de forma productiva.

Cuando un software supera unas pruebas exhaustivas, las probabilidades de que se software de problemas en producción se atenuan y, por tanto, su fiabilidad aumenta.

Podemos asegurar que las pruebas resultan fundamentales para garantizar la calidad, fiabilidad y rendimiento de nuestras aplicaciones antes de que el software llegue a los usuarios finales. Algunas de sus ventajas son las siguientes:

• Detección de errores: Las pruebas ayudan a identificar y corregir problemas en las etapas iniciales del desarrollo, lo que reduce los costos asociados con la resolución de errores en fases más avanzadas.
• Aseguramiento de la calidad: Las pruebas contribuyen a la creación de software de alta calidad al garantizar que cumpla con los requisitos especificados y funcione de manera esperada.
• Confiabilidad: Al realizar pruebas exhaustivas, se aumenta la fiabilidad del software, disminuyendo la probabilidad de fallos inesperados en entornos de producción.
• Optimización del rendimiento: Las pruebas de rendimiento identifican posibles cuellos de botella y problemas de eficiencia, permitiendo ajustes para mejorar el rendimiento general del software.
• Mantenimiento más sencillo: Ya que podemos dar por supuesto que los módulos ya existentes funcionan correctamente.
• Cumplimiento de requisitos: Ya que aseguran que el software cumpla con los requisitos especificados, garantizando así que satisfaga las necesidades y expectativas de los usuarios.

Procedimientos de Pruebas y Casos de Prueba

Un procedimiento de prueba es la definición del objetivo que desea conseguirse con las pruebas, qué es lo que va a probarse y cómo.

El objetivo de las pruebas no siempre es detectar errores. Muchas veces lo que quiere conseguirse ese que el sistema ofrezca un rendimiento determinado, que la interfaz tenga una apariencia y cumpla unas características determinadas, etc ...

3 de 16UD 3 - DISEÑO Y REALIZACIÓN DE PRUEBAS Por lo tanto, la ausencia de errores en las pruebas nunca significa que el software las supere, pues hay muchos parámetros en juego.

Cuando se diseñan los procedimientos, se deciden las personas que hacen las pruebas y bajo qué parámetros van a realizarse.

No siempre tienen que ser los programadores los que hacen las pruebas. No obstante, siempre tiene que haber personal externo al equipo de desarrollo, puesto que los propios programadores solo prueban las cosas que funcionan (si supieran dónde están los errores, los corregirían).

Hay que tener en cuenta que es imposible probar todo, la prueba exhaustiva no existe. Muchos errores del sistema saldrán en producción cuando el software ya esté implantado, pero siempre se intentará que sea el mínimo número de ellos.

En los planes de pruebas (es un documento que detalla en profundidad las pruebas que se vayan a realizar), generalmente, se cubren los siguientes aspectos:

1. Introducción. Breve introducción del sistema describiendo objetivos, estrategia, etc.
2. Módulos o partes del software por probar. Detallar cada una de estas partes o módulos.
3. Características del software por probar. Tanto individuales como conjunto de ellas.
4. Características del software que no ha de probarse.
5. Enfoque de las pruebas. En el que se detallan, entre otros, las personas responsables, la planificación, la duración, etc.
6. Criterios de validez o invalidez del software. En este apartado, se registra cuando el software puede darse como válido o como inválido especificando claramente los criterios.
7. Proceso de pruebas. Se especificará el proceso y los procedimientos de las pruebas por ejecutar.
8. Requerimientos del entorno. Incluyendo niveles de seguridad, comunicaciones, necesidades hardware y software, herramientas, etc.
9. Homologación o aprobación del plan. Este plan deberá estar firmado por los interesados o sus responsables.

4 de 16UD 3 - DISEÑO Y REALIZACIÓN DE PRUEBAS

Casos de Prueba en el Desarrollo de Software

Los casos de prueba son conjuntos de condiciones o variables bajo las cuales un tester determinará si una aplicación o sistema satisface los requisitos o funciona correctamente. En el desarrollo de software, los casos de prueba son una parte fundamental del proceso de aseguramiento de la calidad (QA) y del testing. Aquí hay algunos conceptos clave relacionados con los casos de prueba.

En la fase de pruebas, se diseñan y preparan los casos de prueba, que se crean con el objetivo de encontrar fallos.

Por experiencia, no hay que probar los programas de forma redundante. Si se prueba un software y funciona, la mayoría de las veces no hace falta probar lo mismo. Hay que crear otro tipo de pruebas, no repetirlas.

Hay que tener en cuenta que la prueba no debe ser muy sencilla ni muy compleja. Si es muy sencilla, no va a aportar nada y, si es muy compleja, quizá sea difícil encontrar el origen de los errores.

Probar es ejecutar casos de prueba uno a uno, pero que un software pase todos los casos de prueba no quiere decir que el programa esté exento de fallos.

Las pruebas solo encuentran o tratan de encontrar aquellos errores que van buscando, luego, es muy importante realizar un buen diseño de las pruebas con buenos casos de prueba, puesto que se aumenta de esta manera la probabilidad de encontrar fallos.

Imaginemos que tenemos una funcionalidad que permite el login de un usuario. Así tenga una caja de texto para recuperar el nombre de usuario y otra para capturar la contraseña. Además dispondrá de dos botones, uno para Aceptar el login y otro para cancelar. El diseño de su caso de pruebas sería:

• Objetivo: comprobar que un usuario correcto entra en el sistema y la fecha y la hora de entrada queda registrada.
• Entrada de datos: en el campo User (nombre de usuario) se introduce "myfpschool" y, en el campo Password se introduce "Alumno77".
• Condiciones: en la tabla Usuarios, existe el usuario myfpschool con la contraseña Alumno77 encriptada en MD5.
• Resultado: el usuario entra en el sistema y, en la tabla Log, deja un registro ("myfpschool", fecha, hora).
• Procedimiento de la prueba:

5 de 16UD 3 - DISEÑO Y REALIZACIÓN DE PRUEBAS

• Se comprueba en la tabla Usuarios que existe el usuario a introducir.
• Se comprueba que la contraseña esté codificada en MD5 correctamente.
• En los campos User y Password, se teclean los datos "myfpschool" y "Alumno77".
• Se pulsa Aceptar y se comprueba que se accede al sistema correctamente.
• Se revista la tabla Log y se comprueba que se ha registrado el usuario, la fecha y la hora actual.

Creación de Casos de Prueba Detallados

Para la creación de un caso de prueba, realizaremos una especificación detallada de una situación o condición que se va a probar, incluyendo la entrada, las condiciones iniciales (precondiciones), las acciones a realizar y los resultados esperados.

El principal objetivo de cada caso de prueba es verificar si una aplicación o sistema se comporta de la manera prevista. Durante la fase de testing, los casos de prueba se ejecutan para verificar el comportamiento real del software, y los resultados se comparan con los resultados esperados para identificar discrepancias o defectos.

La documentación de casos de prueba puede realizarse en diversas herramientas, como hojas de cálculo, herramientas de gestión de pruebas o directamente en el sistema de control de versiones, y contiene, al menos, los siguientes ítems:

1. Identificación del Caso de Prueba: Un número único o un identificador que permite referenciar y seguir cada caso de prueba de manera única.
2. Título del Caso de Prueba: Nombre descriptivo que indica la funcionalidad o la característica que se está probando.
3. Descripción: Propósito del caso de prueba y la funcionalidad que está siendo evaluada. Puede incluir detalles sobre las condiciones iniciales, acciones a realizar y resultados esperados.
4. Requisitos Asociados: Lista de los requisitos específicos que el caso de prueba está diseñado para validar. Proporciona un vínculo claro entre las pruebas y los requisitos del sistema.
5. Pasos de Ejecución: Lista detallada de los pasos específicos que el tester debe seguir para ejecutar el caso de prueba. Cada paso debe ser claro y conciso.
6. Datos de Entrada: Valores o datos necesarios para ejecutar el caso de prueba. Esto puede incluir información sobre la configuración inicial, entradas del usuario, datos de prueba, etc.

6 de 16