Este documento presenta un modelo de pruebas de software. Explica conceptos clave como fallas, faltas y errores. Describe los fundamentos, objetivos y principios de las pruebas de software, así como los tipos de pruebas como pruebas de unidad, integración y sistema. Finalmente, detalla el proceso de pruebas, incluyendo la planeación, construcción y ejecución de pruebas.

1. INGENIERIA DE SISTEMAS
MODELO DE PRUEBAS DE
SOFTWARE
DARWIN JIMENEZ
CARLOS EDUARDO AGUIRRE

2. CONTENIDO
1. Definición de conceptos
2. Fundamentos de las pruebas de software
3. Objetivos de la prueba
4. Principios de la prueba
5. Facilidad de la prueba
6. Tipos de Pruebas
7. Proceso de Pruebas

3. CONTENIDO
8. Enfoques de pruebas
• Prueba de la caja blanca
• Prueba del camino básico
• Prueba de la estructura de control
• Prueba de la caja negra

4. 1. DEFINICIONES DE
CONCEPTOS
1. Falla (failure): Ocurre cuando un programa no
se comporta de manera adecuada.
2. Falta (fault): Tiene lugar en el código del
programa. La existencia de una falta en el
programa puede generar una falla en el
sistema.

5. 1. Definiciones de Conceptos
3. Error: Es una acción humana que provoca que
un software contenga una falta. Un error
puede significar la existencia de una falta en
el programa, lo cual hace que el sistema
falle.

6. 1. Definiciones de Conceptos
No se puede garantizar ni probar
que un sistema jamás falle, si no
que sólo se puede demostrar que
contiene faltas. No encontrar
faltas no significa que la prueba
haya sido exitosa. Solo lo es si se
han encontrado faltas.

7. 2. Fundamentos de las
pruebas de Software
• El ingeniero intenta construir el
software partiendo de un concepto
abstracto y llegando a una
implementación tangible.
• El ingeniero crea una serie de casos de
prueba que intentan “demoler “ el
software construido.

8. 3. Objetivos de las pruebas
• La prueba es un proceso de ejecución de un
programa con la intención de descubrir un
error.
• Un buen caso de prueba es aquel que tiene
una alta probabilidad de mostrar un error no
descubierto hasta entonces.
• Una prueba tiene éxito si descubre un error
no detectado hasta entonces.

9. 4. Principios de la Prueba
• A todas las pruebas se les debería poder hacer
un seguimiento has los requisitos del cliente.
• Las pruebas debería planificarse mucho antes
de su inicio.
• El principio de Pareto es aplicable a la prueba
del Software: el 80% de todos los errores
descubiertos durante las pruebas surgen al
hacer un seguimiento de sólo el 20% de todos
los módulos del programa.

10. 4. Principios de la Prueba
• Las pruebas deberían empezar por lo
pequeño y progresar hacia lo grande.
• No son posible las pruebas exhaustivas.
• Para ser más efectivas, las pruebas deberían
ser conducidas por un equipo independiente.

11. 5. Facilidad de Prueba
• Es simplemente lo fácil que se puede probar
un programa de computadora. Como la
prueba es tan profundamente difícil, merece
la pena saber que puede hacer para hacerlo
más sencillo.
Debe existir una lista de comprobación
que proporcione un conjunto de
características que llevan a un
software fácil de probar.

12. 5. Facilidad de Prueba
• Principios:
• Operatividad: Cuanto mejor funcione más
eficientemente se pude probar.
• Observabilidad: Lo que ves es lo que pruebas.
• Controlabilidad: Cuanto mejor podamos
controlar el software, más se puede
automatizar y optimizar.

13. 5. Facilidad de Prueba
• Principios:
• Capacidad de Descomposición: Controlando
el ámbito de las pruebas, podemos aislar más
rápidamente los problemas y llevar a cabo
mejores pruebas de regresión.
• Simplicidad: Cuanto menos haya que probar,
más rápidamente podremos probarlo.

14. 5. Facilidad de Prueba
• Principios:
• Estabilidad: Cuanto menos cambios, menos
interrupciones a las pruebas.
• Facilidad de comprensión: Cuanta más
información tengamos, más inteligentes serán
las pruebas.

15. 6. Tipos de Prueba
Pruebas de Verificación: Se revisa si el resultado
corresponde a la especificación del sistema,
es decir, si se está construyendo el sistema
de manera correcta.
Pruebas de Validación: Se revisa si el resultado
es realmente lo que el cliente quería.

16. 6.1 Técnicas de Pruebas
Pruebas de Regresión: Tiene como propósito
verificar el sistema luego, de haberle
introducido cambios, por ejemplo después
de corregir una falta, de manera que se
mantenga la funcionalidad especificada.
Pruebas de Operación: Su objetivo es verificar el
sistema en operación por un largo período
bajo condiciones normales de uso.

17. 6.1 Técnicas de Pruebas
Pruebas de Escala Completa: Trata de verificar el sistema
en su carga máxima mediante de los parámetros a su
valor límite y la interconexión del sistema con un
máximo de equipos y usuarios simultáneos.
Pruebas de Rendimiento: Tiene como propósito medir la
capacidad de procesamiento del sistema bajo
diferentes cargas, incluyendo espacio de
almacenamiento y utilización de la unidad de
procesamiento.

18. 6.1 Técnicas de Pruebas
Pruebas de Sobrecarga: Pretende observar como se
comparta el sistema cuando se le aplica una
sobrecarga, más allá de las pruebas de escala
completa y rendimiento.
Pruebas negativa: Tiene como propósito medir el estrés
del sistema en situaciones inesperadas, como casos
de uso que normalmente no serían utilizados de
manera simultánea.

19. 6.1 Técnicas de Pruebas
Pruebas basada en requisitos o prueba de casos de uso:
Intenta llevar a cabo pruebas basadas directamente
en la especificación de requisitos.
Pruebas ergonómicas: Tienen como propósito probar los
aspectos ergonómicos del sistema, en otras
palabras, las interfaces hombre-máquina en el caso
de que éstas existan. Ejemplo: Si los menús son
lógicos y legibles, si los mensajes del sistema son
visibles, si se puede entender los mensajes de falla,
etc.

20. 6.1 Técnicas de Pruebas
Pruebas de documentación de usuario: Tiene como
propósito probar la documentación de usuario,
incluyendo el manual de éste y la documentación de
mantenimiento y servicio.
Pruebas de aceptación o de validación: Pretende lograr
una revisión final por parte de la organización que
solicitó el sistema, lo cual, a menudo, significa
validación del sistema. Llamado Prueba Alfa o
Prueba Beta.

21. 6.1 Técnicas de Pruebas
Pruebas de documentación de usuario: Tiene como
propósito probar la documentación de usuario,
incluyendo el manual de éste y la documentación de
mantenimiento y servicio.
Pruebas de aceptación o de validación: Pretende lograr
una revisión final por parte de la organización que
solicitó el sistema, lo cual, a menudo, significa
validación del sistema. Llamado Prueba Alfa o
Prueba Beta.

22. 6.2 Nivel de Pruebas
Pruebas de unidad: Mediante esta prueba sólo una
unidad es probada como tal, como una clase, u
paquete de servicio o un subsistema.
Pruebas de Integración: En ella se verifica que las
unidades trabajen juntas correctamente.
Pruebas de Sistema: Verifica el sistema completo o su
aplicación como tal. Se toma el punto de vista del
usuario final y los casos de uso de pruebas.

23. PRUEBA DE UNIDAD
Pruebas de procedimientos o subrutinas. En
un sistema orientado a objetos se aplican en
un nivel más alto, a partir de las clases.
Una prueba de unidad consiste en una
prueba estructural (o caja blanca), lo cual
requiere conocer el diseño interno de la
unidad, y una prueba de especificación(de
caja negra, basada sólo en la especificación
del comportamiento externamente visible de
la unidad.

24. PRUEBA DE UNIDAD
Prueba de Especificación o de Caja Negra: Tiene como
propósito verificar las relaciones de entrada y salida
de una unidad. Su objetivo es verificar que hace la
unidad, pero sin averiguar como lo hace.
Prueba basada en estado: Verifica las interacciones entre
operaciones de una clase según cambios en los
atributos de un objeto. Es necesario hacer pruebas
del objeto de acuerdo con su ciclo de vida.
Prueba Estructural o de Caja Blanca: Verifica que la
estructura interna de la unidad sea correcta.

25. PRUEBA DE INTEGRACION
Después de haber probado todas las
unidades, éstas deben ser integradas en
unidades más grandes hasta generar el
sistema completo.
El propósito de la prueba de integración es
probar que las diferentes unidades trabajen
juntas de manera apropiada.

26. 7. Proceso de Pruebas
El proceso de pruebas involucra consideraciones
similares al del proceso de desarrollo, incluyendo
estrategias, actividades y métodos, los cuales
deben ser aplicados de manera concurrente con el
proceso de desarrollo de software.
1. ESTRATEGIA DE LA PRUEBA:
• Orden de Pruebas: Tienen como propósito definir en que
momento y en que orden se aplicarán las pruebas. Diseño,
implementación y operación del sistema.

27. 7. Proceso de Pruebas
ESTRATEGIA DE LA PRUEBA:
• Orden de Pruebas: Existen dos enfoques generales para el
orden en que se efectuarán las pruebas:
 De arriba hacia abajo: Se deben desarrollar inicialmente las
interfaces entre subsistemas, para probar protocolos de
alto nivel antes de ir a probar los niveles inferiores.
 De abajo hacia arriba: Certificar primero las unidades de
bajo nivel y luego las interfaces entre ellos.

28. 7. Proceso de Pruebas
1. ESTRATEGIA DE LA PRUEBA:
• Alcance de pruebas: Tiene como propósito identificar el tipo,
número y casos de pruebas que se aplicarán para revisar los
diferentes aspectos del sistema
• Automatización de la Prueba: Tiene como propósito reducir
el esfuerzo y costo de las pruebas mediante automatización
del proceso o aspectos de él.

29. 7. Proceso de Pruebas
2. PLANEACION DE LA PRUEBA:
Comienza con el establecimiento de las estrategias
de pruebas, lo que incluye la cuestión si estás se
harán automática o manualmente y si existen
programas y datos de prueba que puedan ser
usados, posiblemente modificados o desarrollados
de nueva cuenta
 Estrategia de la prueba
 Alcance de la prueba
 Recursos

30. 7. Proceso de Pruebas
3. CONSTRUCCION DE LA PRUEBA:
Se describe cada prueba y su propósito de manera
general y detallada. Se debe describir exactamente
cómo se deberá ejecutar el caso de prueba, de
manera que personas no familiarizadas con la
aplicación puedan ejecutar el caso.
 Ambiente de desarrollo o real
 Tipo de software
 Tipo de hardware
 Equipo de prueba
 Versión del sistema

31. 7. Proceso de Pruebas
3. EJECUCION DE LA PRUEBA:
Durante esta etapa se utiliza la especificación del diseño de
prueba y los reportes de ésta.
La estrategia es aplicar de manera paralela el mayor caso de
pruebas posibles.
Se Ejecutan las pruebas automáticas y manuales de manera
correspondiente y se indican los resultados esperados.
Si alguna prueba falla, se interrumpe su aplicación y se anota el
resultado para luego analizar el defecto y corregirlo.

32. PRUEBA DE LA ESTRUCTURA DE CONTROL
• Las pruebas son de gran importancia en la
garantía de la calidad del software.
• Estas variantes amplían la cobertura de la
prueba y mejoran la calidad de la prueba de
caja blanca.
– Prueba de Condición
– Prueba de Flujo de Datos
– Prueba de Bucles

33. Prueba de condición
• Método de diseño de casos de prueba que
ejercita las condiciones lógicas contenidas en el
módulo de un programa.
• Esta prueba asegura en que cada condición del
programa no contenga errores.
• Una condición simple es una variable lógica o
una expresión relacional.

34. • La expresión relacional adquiere la siguiente
forma: E1 <operador relacional>E2; donde E1 y E2
son expresiones aritméticas y <operador
relacional> puede ser “<, <=, =, >, >=, ≠”
• Una condición compuesta está formada por dos
o más condiciones simples, operadores lógicos
o paréntesis. Los operadores lógicos permitidos
en una condición compuesta incluye OR(|),
AND(&), NOT.
• Una condición sin expresiones relacionadas se
le denomina expresión lógica.

35. • Si una condición es incorrecta, entonces es
incorrecto al menos un componente de la
condición. Los errores de una condición
pueden ser:
– Error en operador lógico
– Error en variable lógica
– Error en paréntesis lógico
– Error en operador relacional
– Error en expresión aritmética

36. • Se han propuesto series de estrategias de
prueba de condiciones:
– Prueba de ramificaciones: Para una condición
compuesta C, es necesario ejecutar al menos una
vez las ramas verdadera y falsa de C y cada condición
simple de C.
– Prueba del dominio: Requiere la realización de 3 o 4
pruebas para una expresión relacional.
E1 <operador relacional> E2 se requieren tres
pruebas para comprobar que el valor de E1 es mayor,
igual o menor que el valor de E2. Por ejemplo si el
operador relacional es incorrecto y E1 y E2 son
correctos, entonces estas tres pruebas garantizan la
detección de un error del operador relacional.

37. Prueba de flujo de datos
• Selecciona caminos de prueba de un programa de
acuerdo con la ubicación de las definiciones y los
usos de las variables del programa.
• Las estrategias de prueba de flujo de datos son
útiles para seleccionar caminos de prueba de un
programa que contenga sentencias if o bucles
anidados.
• Necesitamos conocer la estructura de cada
condición o bloque (seleccionando un camino del
programa, determinamos si el camino es factible
para el programa)

38. Prueba de bucles
• Técnica de prueba de caja blanca que se
centra en la validez de las construcciones de
bucles.
• Se pueden definir 4 clases diferentes de
bucles:
– Simples,
– Concatenados,
– Anidados,
– No estructurados

39. Bucles
Bucles
anidados
Bucles
Bucles concatenados Bucles no
simples estructurados

40. Bucles simples:
• Se les debe aplicar el siguiente conjunto de
pruebas, donde n es el número máximo de
pasos permitidos por el bucle
1. Pasar por alto totalmente el bucle
2. Pasar una sola vez por el bucle
3. Pasar dos veces por el bucle
4. Hacer m pasos por el bucle con m<n
5. Hacer n-1 y n+1 pasos por el bucle

41. Bucles anidados:
• Si se extendiera el enfoque de los bucles
simples a los bucles anidados, el número de
posibles pruebas aumentaría geomé-
tricamente a medida que aumenta el nivel de
anidamiento. Esto llevaría a un número
imprescindible de pruebas.

42. • Se sugiere un enfoque que ayuda a reducir el
número de pruebas
1. Comenzar por el bucle más interior
2. Llevar a cabo las pruebas de bucles simples
3. Progresar hacia fuera, llevando a cabo pruebas
para el siguiente bucle
4. Continuar hasta que se hayan probado todos los
bucles

43. Bucles concatenados:
• Se pueden probar mediante el enfoque
definido para los bucles simples, mientras
cada uno de los bucles sea independiente del
resto.
Bucles no estructurados:
• Esta clase de bucles se debe rediseñar para
que se ajusten a las construcciones de
programación estructurada.

44. PRUEBA DE CAJA NEGRA
• Se centra en los requisitos funcionales del
software.
• Se trata de un enfoque complementario que
intenta descubrir diferentes tipos de errores
de los métodos de caja blanca.

45. • La prueba de caja negra intenta encontrar
errores de las siguientes categorías:
– Funciones incorrectas o ausentes
– Errores de interfaz
– Errores es estructura de datos o en accesos a
bases de datos externas
– Errores de rendimiento
– Errores de inicialización y de terminación

46. Método de prueba basados en grafos
• La prueba empieza creando un grafo de objetos
y sus relaciones y después diseñando una serie
de pruebas que cubran el grafo de manera que
se ejerciten todos los objetos y sus relaciones
para descubrir los errores.
• Estos casos de prueba están diseñados para
intentar encontrar errores en algunas de las
relaciones.
• El grafo ayudaría a identificar aquellos bucles
que hay que probar.

47. Partición equivalente
• Es un método de prueba de caja negra, se
dirige a la definición de casos de prueba que
descubran clases de errores, reduciendo así el
número total de casos de prueba que hay que
desarrollar.
• El objetivo de partición equivalente es reducir
el posible conjunto de casos de prueba en uno
más pequeño, un conjunto manejable que
evalúe bien el software.

48. • El diseño de casos de prueba para la partición
equivalente se basa en una evaluación de las
clases de equivalencia para una condición de
entrada.
• Una clase de equivalencia representa un
conjunto de estados válidos o no válidos para
condiciones de entrada (es un valor numérico
específico, un rango de valores, un conjunto
de valores relacionados o una condición
lógica).

49. Sitio alquiler de películas
• Rango de valores
– Alquiler para personas mayores 18 años
• Valor
– Nº de películas que se alquilan
• Conjunto de valores específico
– Películas (Acción, Comedia, Infantil, Intriga)
• Lógico
– ¿Es socio?

50. Análisis de Valores Límite (AVL)
• Es una técnica de diseño de casos de prueba
que complementa la prueba de Partición
Equivalente. En lugar de realizar la prueba con
cualquier elemento de la partición equivalente,
se escogen los valores en los extremos de la
clase.
• Por ejemplo: si una condición de entrada
especifica un rango delimitado por los valores
a y b, se deben diseñar casos de prueba para
los valores a y b y para los valores que se
encuentran por debajo y por encima.

51. Prueba de Comparación
• Aplicación en sistemas de alta fiabilidad
• Desarrollos paralelos
• Intercambio de casos de prueba
• Desarrollo del software, las versiones de la
aplicación se ejecutan en equipos
independientes, usando las mismas
especificaciones.
• Se deben probar todas las versiones con los
mismos datos, para asegurar que
proporcionan una salida idéntica.

52. PRUEBA DE ENTORNOS
Y APLICACIONES ESPECIALIZADAS
• Pruebas de interfaces gráficas de usuario
• Prueba de documentación y de ayuda
– Es importante para la aceptación del programa.
– Revisar la guía de usuario o funciones de ayuda en
línea.
• Prueba de sistemas de tiempo real
– Prueba de tareas
– Prueba de comportamiento
– Prueba intertareas
– Prueba del sistema

53. JTS 2008
V JORNADA DE TESTEO DE SOFTWARE 2008
2,3 Y 4 DE ABRIL DE 2008
VALENCIA ESPAÑA
VIDEO
BLOG DE LA JORNADA

54. BIBLIOGRAFIA
Ingenieria de Software Orientada a Objetos.-Alfredo
Weitzenfeld.- Editorial Thomson