PRUEBAS

1. Introducción
Las pruebas de software consisten en verificar y validar un producto puesta en marcha. Constituyen una de las etapas del
desarrollo de software, básicamente consiste en probar la aplicación construida. Involucra las siguientes fases:
 Planificación pruebas
 Diseño
 Construcción de los casos
 Ejecución de prueba
 Registro de resultado
 Depuración de errores e informe de los resultados

Son:

- Principio 1: Demuestran la presencia de errores, pero no su ausencia

- Principio 2: Las pruebas completas no existen
- Principio 3: Las pruebas se iniciarán lo antes posible en el ciclo de vida del software
- Principio 4: La mayor parte de los errores suelen concentrar en un número reducido de módulos
- Principio 5: Los casos de pruebas deben ser examinados y revisados periódicamente
- Principio 6: Deben adaptarse a las necesidades específicas del contexto
- Principio 7: Un software puede haber pasado todas las pruebas, pero no significa que esté libre de errores

2. Pruebas de caja blanca

Se basan en el examen de los detalles procedimentales del código de la aplicación. Mediante esta técnica se puede
obtener casos de pruebas que:

 Garanticen que se ejecuta al menos una vez todos los caminos

 Ejecuten todas las sentencias al menos una vez
 Ejecuten todas las decisiones lógicas en su parte delantera y su parte falsa
 Ejecutan todos los bucles en sus límites
 Utilicen todas las estructuras de datos internas para asegurar su validez

Una de las técnicas más utilizadas es la prueba del camino básico.

3. Pruebas de caja negra

Se llevan a cabo sobre la interfaz del software, no hace falta conocer la estructura interna del programa ni su
funcionamiento. Se pretende obtener casos de pruebas que demuestren que las funciones del software son operativas.
Se les llama prueba de comportamiento, se considera una caja negra a la que solo se le puede determinar con las entradas
y las salidas que devuelven en función de las entradas suministradas.

Categoría de errores:
 Funcionalidades incorrectas o ausentes
 Errores de interfaz
 Errores de estructuras de datos o en accesos a bases de datos externos
 Errores de rendimiento
 Errores de inicialización y finalización

Algunas técnicas son clases de equivalencia, análisis de valores límite, métodos basados en grafos, pruebas de
comparación.
4. Estrategias de prueba del software:
 Prueba de unidad

Se enfoca en probar de manera aislada los componentes más pequeños y fundamentales del software, como
funciones, métodos y clases individuales, para asegurarse de que funcionen correctamente y cumplan con los
requisitos. Utiliza técnicas de caja negra y caja blanca. Se realizan pruebas sobre:
o La interfaz del módulo, para que la información fluya
o Las estructuras de datos locales, para asegurar que mantienen su integridad
o Las condiciones límite, para asegurar que funcione correctamente en los límites establecidos durante el
proceso.
o Todos los caminos independientes de la estructura de control, con el fin de asegurar que todas las sentencias
se ejecutan al menos una vez.
o Todos los caminos de manejo de errores.

Algunas herramientas son: JUnit, CPPUnit , PHPUnit…

 Prueba de integración

Se observan como interaccionan los distintos módulos, hay que comprobar si los módulos funcionan juntos. Hay dos
enfoques:
o Integración no incremental o big bang: Se prueba cada módulo por separado y luego se combina todo y
se prueba el programa completo. Hay muchos errores y la corrección es difícil.

o Integración incremental: Va construyendo y probando en pequeños segmentos, los errores son más fáciles
de localizar. Ascendentes ( empiezan por los niveles más bajos) Descendente (Comienza en el módulo main
y se mueve hacia abajo)

 Prueba de validación

Se consigue cuando el software funciona de acuerdo con las expectativas del cliente definidas en el documento. Se
lleva a cabo una serie de pruebas de caja negra que demuestran la conformidad con los requisitos. Las técnicas son:

o Prueba alfa: El cliente utiliza el software de forma natural bajo la observación del desarrollador que
registrará los errores y problemas de uso.

o Prueba beta: Se lleva a cabo por los usuarios finales del software. El desarrollador no está presente. El
usuario registra todos los problemas.

 Prueba del sistema

Su misión es ejercitar profundamente el software. Son:

o Prueba de recuperación: Se fuerza al fallo del software y se verifica que la recuperación se lleva a cabo
apropiadamente.
o Prueba de seguridad: Intenta verificar que el sistema está protegido contra accesos ilegales
o Prueba de resistencia: Enfrentar el sistema con situaciones que demandan gran cantidad de recursos.

5. Pruebas de código
 Complejidad Ciclomática
La idea es acotar el número de caminos aparece, para indicar el número de caminos independientes que existen en un
grafo. Proporciona el límite superior del número necesario de casos de prueba para garantizar que al menos se
ejecute una vez.

La complejidad ciclomática se representa por V (G), hacer las 3 formas: (todas tienen que dar el mismo resultado)
o V (G)= aristas – nodos + 2
o V (G) = regiones cerradas del grafo
o V (G) = Nodos predicados +1
  Conjunto de caminos independientes
o Camino 1: 1,2,9
o Camino 2: 1,2,5,4,9
o …

Ejemplo:

V(G) = 4
V(G) = 11-9-2 = 4
V(G) = 3+1 = 4

Camino 1: 1,9
Camino 2: 1,2,4,8,1,9
Camino 3: 1,2,3,6,7,8,1,9
Camino 4: 1,2,3,5,7,8,1,9

 Casos de pruebas
Construir los casos que fuerzan la ejecución de cada camino con el fin de comprobar cada uno.

o Prueba de bucles:
Es una técnica de prueba de caja blanca, que se centra en la validez de las construcciones de bucle:
 Simples
 Concatenados
 Anidados
 No estructurados

6. Partición equivalente
La partición equivalente es un método de prueba caja negra que divide el conjunto de entradas de un sistema en grupos o
particiones, de modo que cada partición sea representativa de un conjunto de entradas que se espera que tengan un
comportamiento similar por parte del sistema.

El objetivo de esta técnica es reducir la cantidad de casos de prueba necesarios para verificar todas las posibles
combinaciones de entradas, sin perder la capacidad de detectar errores importantes en el software. En lugar de probar
todas las combinaciones posibles, se prueban solo algunos casos de cada partición, ya que se espera que los casos dentro
de cada partición tengan un comportamiento similar.

Para identificarlas se examina cada condición de entrada y se divide en dos o más grupos:
 Clases válidas valores de entrada válidos
 Clases no válidas: valores de entrada no válidos

7. JUNIT
Es una herramienta para realizar pruebas unitarias automatizadas. Está integrada en eclipse. Se realizan sobre una clase
para probar su comportamiento de modo aislado independientemente del resto de clases de aplicación. Aunque una clase
a veces depende de otras clases para poder llevar a cabo su función.