El documento describe los diferentes tipos y procesos de pruebas de software. Explica que la prueba de unidades valida el código individual, la integración prueba la interacción de módulos, y la validación/verificación comprueba que el producto cumple los requisitos. También cubre técnicas como caja blanca, negra y de sistema para probar la recuperación, seguridad y resistencia. Concluye que aunque existen herramientas, un experto humano es necesario para dirigir efectivamente las pruebas.

2. INTRODUCCION
La fase de pruebas es una de las más costosas
del ciclo de vida software.
En sentido estricto, deben realizarse pruebas de
todos los artefactos generados durante la
construcción de un producto, lo que incluye
especificaciones de requisitos, casos de uso,
diagramas de diversos tipos y, por supuesto, el
código fuente y el resto de productos que forman
parte de la aplicación (la base de datos).
Obviamente, se aplican diferentes técnicas de
prueba a cada tipo de producto software.

3. QUE ES PRUEBA DE
PROGRAMAS?
Es la ejecución de un programa con la intención de
descubrir errores.
Probar un programa es ejercitarlo con la peor
intención a fin de encontrarle fallos. Por poner un
ejemplo duro, probar un programa es equivalente a la
actividad de ciertos profesores para los que examinar
a un alumno consiste en poner en evidencia todo lo
que no sabe. Esto es penoso cuando se aplica a
personas; pero es exactamente lo que hay que hacerle
a los programas.

4. PROCESO DE PRUEBAS DE
SOFTWARE
Se identifican tres grupos de procesos en el
ciclo de vida software:
- Procesos principales: grupo en el que incluye
los procesos de adquisición, suministro,
desarrollo, operación y mantenimiento.
- Procesos de la organización: en donde se
encuentran los procesos de gestión, mejora,
infraestructura y formación.

5. PROCESO DE PRUEBAS DE
SOFTWARE
-Procesos de soporte o auxiliares: en donde
están los procesos de documentación, gestión
de la configuración, auditoría, resolución de
problemas, revisión conjunta, aseguramiento
de la calidad, verificación, validación.
No define como vemos, un proceso de Pruebas
como tal, sino que aconseja, durante la
ejecución de los procesos principales o de la
organización, utilizar los procesos de soporte.

6. PROCESO DE PRUEBAS DE
SOFTWARE
Entre éstos se encuentran los procesos de
Validación y de Verificación.
- Proceso de Validación: tiene como objetivo
determinar si los requisitos y el sistema final
cumplen los objetivos para los que se
construyó el producto, respondiendo así a la
pregunta ¿el producto es correcto?.

7. PROCESO DE PRUEBAS DE
SOFTWARE
- Proceso de Verificación: intenta determinar si
los productos software de una actividad se
ajustan a los requisitos o a las condiciones
impuestas en actividades anteriores. De este
modo, la pregunta a la que responde este
proceso es ¿se está construyendo el producto
correctamente?.

8. TIPOS DE PRUEBAS
 PRUEBA DE UNIDAD: es una prueba (automatizada a
menudo) de la cual valida que las unidades
individuales código de fuente están trabajando
correctamente.
-Caja blanca: En estas pruebas estamos siempre observando
el código, que las pruebas se dedican a ejecutar con ánimo
de "probarlo todo". Esta noción de prueba total se
formaliza en lo que se llama "cobertura" y no es sino una
medida porcentual de ¿cuánto código hemos cubierto?.

9. Los tipos de cobertura en la caja blanca son:
-Cobertura de segmentos.
-Cobertura de ramas.
-Cobertura de condición/decisión.
-Cobertura de bucles.
-Caja negra: Las pruebas de caja negra se centran en lo
que se espera de un módulo, es decir, intentan
encontrar casos en que el módulo no se atiene a su
especificación. Por ello se denominan pruebas
funcionales, y el probador se limita a suministrarle
datos como entrada y estudiar la salida, sin
preocuparse de lo que pueda estar haciendo el módulo
por dentro.

10.  PRUEBAS DE INTEGRACION: La prueba
de integración es una técnica sistemática para
construir la estructura del programa mientras al
mismo tiempo, se lleva a cabo pruebas para
detectar errores asociados con la interacción. El
objetivo es tomar los módulos probados en
unidad y estructurar un programa que esté de
acuerdo con el que dicta el diseño.

11. Los tipos de prueba de integración son:
-Integración descendente: es una estrategia de
integración incremental a la construcción de la
estructura de programas, en el cual se integran los
módulos moviéndose en dirección hacia abajo por la
jerarquía comenzando por el control principal
(Programa principal).
-Integración ascendente: es donde la construcción del
diseño empieza desde los módulos más bajos hacia
arriba (módulo principal).

12.  PRUEBA DE VALIDACION Y VERIFICACION:
La definición de verificación validación envuelve lo
que se conoce como calidad del software. Las
revisiones técnicas formales ayudan a asegurar la
calidad de los productos, a lo largo del proceso la
medición y l control se aplica sobre cada elemento de
una construcción del software. La prueba construye
un elemento importante desde el que se puede evaluar
la calidad y, de forma más practica, de cubrir los
errores.

13.  PRUEBA DE SISTEMAS: La prueba del sistema se
basa en otras técnicas de pruebas, aunque la finalidad
de cada prueba es distinta, sirven para verificar que se
hayan integrado correctamente cada uno de los
elementos del sistema:
-Prueba de Recuperación: es una prueba que se hace
al sistema forzando a que produzca fallas de software
de muchas maneras y verificando que la recuperación
se lleve a cabo, ya sea automáticamente o manual,
tomando en cuenta los recursos que se requieran para
efectuar la recuperación.

14. -Prueba de Seguridad: intenta verificar la aplicación de
los mecanismos de protección incorporados en el
sistema. Durante la prueba el encargado desempeña el
papel de intruso tratando de violar la seguridad del
sistema, intentando obtener las claves de acceso por
cualquier medio externo; debe bloquear el sistema
negando así el servicio a otras personas a demás de
producir errores a propósito en el sistema o debe
curiosear los datos públicos intentando encontrar una
clave de acceso al sistema.

15. -Prueba de Resistencia: esta diseñada para
enfrentar a los problemas en situaciones
anormales, es decir ejecutar el sistema en
forma que demande recursos en cantidad,
frecuencia o volúmenes anormales. El
encargado de la prueba debe intentar tirar el
sistema.

16. TECNICAS DE PRUEBAS
 Ayudan a definir conjuntos de casos de prueba
aplicando un cierto criterio.
 Los casos de prueba quedarán determinados
por los valores a asignar a las entradas en su
ejecución.
 Técnicas de caja blanca.
 Técnicas de caja negra.

17. CONCLUSIONES
 Probar es buscarle los fallos a un programa.
 Aunque se han desarrollado miles de herramientas de
soporte de esta fase, todas han limitado su éxito a entornos
muy concretos, frecuentemente sólo sirviendo para el
producto para el que se desarrollaron. Sólo herramientas
muy generales como analizadores de complejidad,
sistemas de ejecución simbólica y medidores de cobertura
han mostrado su utilidad en un marco más amplio. Pero al
final sigue siendo imprescindible un artista humano que
sepa manejarlas.