El documento describe los conceptos clave de la estrategia de prueba de software. Explica que la prueba de software es importante para encontrar errores de manera sistemática y evitar su desperdicio de tiempo y esfuerzo. Detalla los cuatro pasos clave de la prueba: prueba de unidad, prueba de integración, prueba de validación y prueba del sistema. Además, cubre conceptos como pruebas de caja blanca, pruebas orientadas a objetos y los tipos de pruebas alfa y beta.

1. PROGRAMA INGENIERÍA DE SISTEMAS
Estrategia de prueba de software

2. ¿Qué es estrategia de prueba de software?
• El software se prueba para descubrir errores que se
cometieron de manera inadvertida conforme se diseñó y
construyó.

3. ¿Por qué es importante?
• Con frecuencia, la prueba requiere más esfuerzo que cualquiera otra acción de
ingeniería del software. Si se realiza sin orden, se desperdicia tiempo, se
emplea esfuerzo innecesario y, todavía peor, es posible que algunos errores
pasen desapercibidos.
• Por tanto, parecería razonable establecer una estrategia sistemática para
probar el software.

4. ¿Qué es lo que busca la prueba?
• La prueba comienza “por lo pequeño” y avanza “hacia lo grande”.
• Es decir que las primeras etapas de prueba se enfocan sobre un solo componente o un pequeño grupo de
componentes relacionados y se aplican pruebas para descubrir errores en los datos y en la lógica de
procesamiento que se encapsularon en los componentes.
• Después de probar éstos, deben integrarse hasta que se construya el sistema completo. En este punto, se
ejecuta una serie de pruebas de orden superior para descubrir errores en la satisfacción de los
requerimientos del cliente. Conforme se descubren, los errores deben diagnosticarse y corregirse usando un
proceso que se llama depuración.

5. ¿Cuáles son los pasos?
Si consideramos el proceso desde el punto de vista procedimental, la prueba, en el contexto de la
ingeniería del software, realmente es una serie de cuatro pasos que se llevan a cabo secuencialmente:
• Prueba de unidad: el componente o módulo de software.
• La prueba de integración: Es una técnica sistemática para construir la arquitectura del software
mientras, al mismo tiempo, se aplican las pruebas para descubrir errores asociados con la interfaz.
• La prueba de validación: El software funciona en una forma que cumpla con las expectativas
razonables del cliente.

6. Pruebas de aplicaciones convencionales
• Pruebas en el software
 Se requiere que el desarrollador deseche nociones preconcebidas sobre lo
“correcto” para diseñar casos de prueba a fin de “romper” el software.
 La meta de probar es encontrar errores.

7. • Mientras mejor funcione, se
puede afirmar su eficiencia.
Operatividad
• Hace referencia a lo que se puede
ver para así probarlo.
Observabilidad
• Mientras mejor se pueda controlar
el software, se podrá automatizar
y optimizar las pruebas.
Controlabilidad
Comprobabilidad del software

8. Comprobabilidad del software
• Al controlar el ámbito de las pruebas, es
posible aislar más rápidamente los
problemas y realizar pruebas nuevas y
más inteligentes.
Descomponibilidad
• Mientras haya menos que verificar, se
puede probar más rápidamente.
Simplicidad
• Mientras hayan menos cambios se
presentarán menos perturbaciones para
probar el producto.
Estabilidad

9. Atributos de una buena prueba
Alta probabilidad de encontrar
error
No ser redundante
No debe ser demasiado simple
o compleja.

10. Pruebas de caja blanca
 La prueba de caja blanca del software se basa en el examen cercano de los detalles de
procedimiento. Las rutas lógicas a través del software y las colaboraciones entre componentes.
Características
Garantizar que
todas las rutas
independientes
dentro de un
módulo se
revisaron al
menos una vez.
Revisar todas las
decisiones
lógicas en su
lado verdadero y
falso.
Ejecutar todos
los bucles en sus
fronteras y dentro
de las operativas.
Revisar
estructuras de
datos internas
para garantizar
su validez.

11. Prueba de ruta básica
 Permite al diseñador de casos de prueba definir un conjunto básico de rutas de ejecución.
 Los casos de prueba obtenidos, tienen la garantía de ejecutar todo en el programa, al menos una
vez durante la prueba.
Notación de gráfico o grafo de lujo
 Es una forma de representar los procesos y el flujo de control lógico, dentro de la ejecución de un
programa.

12. PREUBA DE APLICACIONES
ORIENTADAS A OBJETOS
Son las menos estudiadas y comprendidas,
por lo cual son las más evitadas. Por ello,
ocasiones son reemplazadas por pruebas en
el sistema poco antes de la entrega de final
del software.
Se enfocan en la interacciones entre las
unidades suponiendo que cada unidad ya fue
probada a nivel individual, para
posteriormente mezclar aspectos
estructurales.

13. Tipos de problemas.
Tiempo
tardío de
ejecución
Uso y manejo de
objetos y funciones
Polimorfismo
Problemas en la configuración.
Funciones faltantes,
traslapadas o con conflictos.
Uso incorrecto de archivos.
Llamado a métodos
equivocados.
Variación de las condiciones
del servidor.
T
I
P
O
S

14. PRUEBA DE SISTEMA
Son importantes en la conclusión de la implementación
del producto de las pruebas en.
 Rendimiento.
 Seguridad.
 Instalación, entre otros.
Buscan satisfacer los requerimientos del cliente, para
ello se dividen en ALFA Y BETA.

15. Document
os de
requisitos
del
software.
Caso de
prueba
para los
requisitos.
Equipo de
prueba del
software
Matriz de
trazabilida
d para
garantizar
registros.
Lista de la
versión de
prueba.
Versión
Beta del
software.
Herramienta
para
capturas de
fallas en
tiempo real.
Pruebas
internas
para
detención
de errores.
Pruebas
limitadas
para
adquirir
comentarios
del cliente.

16. ALFA BETA
Mejora la perspectiva de la
confiabilidad.
Reduce el riesgo de falla del
producto por la validación del
cliente.
Simula el comportamiento del
usuario en tiempo real.
Prueba de la infraestructura
posterior al lanzamiento.
Detecta mayor cantidad de
errores.
Mejora la calidad del producto
por los comentarios.
Detecta errores al principio del
diseño y funcionalidad.
Crea voluntad en los clientes y
aumenta la satisfacción.