El documento describe diferentes estrategias y tipos de pruebas de software. Explica que las pruebas de software son actividades planificadas y sistemáticas para evaluar si un software se comporta de acuerdo a su especificación. Detalla las pruebas de unidad, integración, validación y sistema, así como estrategias para software convencional y orientado a objetos.

1. Pruebas de Software
Facilitdor: Ing. Neris Alfonzo

2. "Es un conjunto de actividades que pueden planearse
por adelantado y realizarse de manera sistemática."
(Pressman, 2010, p. 388)
"...consiste en someter al producto de software (o una
parte del mismo) a una evaluación para conocer si se
comporta de acuerdo con una especificación tomada
como referencia." (León, 1996 , p. 151)
Qué es la Prueba

3. Pasos para realizar la
Prueba
Descripción de la
Prueba
En ella se debe indicar el
propósito de la prueba, el
componente de software
sobre el que se realiza, los
datos de prueba que se van
a entregar y los resultados
esperados.
Ejecución de la
Prueba
Si es de código, se debe
realizar la ejecución en un
entorno controlado , es
probable que el sistema
final ni el resto del
producto estén
terminados y deban
simularse.
Valoración de los
Resultados
Obtenidos
Una vez finalizada la
prueba los resultados
deben compararse
con otros
considerados como
referencia.
(León 1996, p. 151)

4. ESTRATEGIAS
DE PRUEBAS
Existen muchas estrategias de pruebas,
alguna se realizan una vez completado
totalmente el software, otras son
efectuadas periódicamente mientras se
va construyendo el software. Esta última
se enfoca hacia "...una visión incremental
comenzando con las unidades de
programas individuales, avanza hacia
pruebas diseñadas para facilitar la
integración de las unidades y culmina
con pruebas que ejercitan el sistema
construido." (Pressman, 2010, p. 389)

5. Estrategias de Pruebas en
Software Convencional
PRUEBA DE UNIDAD
Enfoca los esfuerzos de verificación en la unidad
más pequeña del diseño del software.
Estructura de
datos locales
Para asegurarse
de que los datos
almacenados de
forma temporal
mantienen su
integridad.
(Pressman 2010, p. 390)
Interfaz
Para garantizar
que la
información fluya
de forma
adecuada hacia y
desde la unidad
de software.
Condiciones de
frontera
Para asegurar que
el módulo opera
adecuadamente en
las fronteras
establecidas.
Rutas
Se prueban todas
las rutas para el
manejo de errores.

6. Estrategias de Pruebas en
Software Convencional
PRUEBA DE INTEGRACIÓN
Son una técnica sistemática para construir arquitectura del
software mientras se llevan a cabo pruebas para descubrir
errores asociados con la interfaz.
Descendente
Es un enfoque
incremental, los
módulos se
integran al
moverse hacia
abajo a través de
la jerarquía de
control.
(Pressman 2010, p. 391)
Incremental
El programa se
construye y se
prueba en
pequeños
incrementos,
donde los errores
son más fáciles
de aislar.
Ascendente
Comienza la
construcción y la
prueba en
componentes
inferiores dentro de
la estructura del
programa.
Regresión
Es la nueva
ejecución de algún
subconjunto de
pruebas ya
realizadas para
verificar que no
hubo otro efecto no
deseado.

7. Estrategias de Pruebas en Software
Orientado a Objeto
PRUEBA DE UNIDAD
Cambia el concepto de unidad, la encapsulación
determina la definición de clases y objetos. Cada clase
encapsula y cada instancia de una clase empaqueta
los atributos (datos) y sus operaciones.
Una clase encapsulada es el foco de la prueba de
unidad. Ya no es posible probar una sola operación en
aislamiento sino más bien como parte de una clase.
(Pressman 2010, p. 397)

8. Estrategias de Pruebas en Software
Orientado a Objeto
PRUEBA DE INTEGRACIÓN
Un sistema orientado a objeto no tiene estructura de
control jerárquico, por tanto realiza:
(Pressman 2010, p. 397)
Primera prueba basada en hebras, la cual integra el conjunto de clases
requeridas para responder a una entrada o evento para el sistema. Cada
hebra se integra y se prueba de manera individual.
Una segunda prueba basada en uso, comienza la construcción del
sistema probando las clases en capas dependientes e independientes del
servidor de forma continua hasta la construcción total del sistema.

9. El modelo de contenido para las webapps se revisa para descubrir
errores.
Se revisa el modelo de interfaz para garantizar que todos los casos de
uso pueden adecuarse.
El modelo de diseño se revisa para descubrir errores de navegación.
La interfaz de usuario se prueba para errores en los mecanismos de
presentación y/o navegación.
A cada componente funcional se le aplica una prueba de unidad .
1.
2.
3.
4.
5.
Estrategias de Pruebas en Software
Orientado a Objeto Para las webapps se adoptan los
principios básicos para todas las
pruebas de software y utiliza tácticas
empleadas para sistemas orientados a
objetos. A continuación se presentan
algunas de ellas

10. 8. Las pruebas de seguridad se realizan con la intención de explotar
vulnerabilidades en la webapps o dentro de su ambiente.
9. Se realiza prueba de rendimiento.
10. La webapps se prueba mediante una población de usuarios finales
controlada y monitoreada.
Estrategias de Pruebas en Software
Orientado a Objeto 6. Se prueba la navegación a lo largo
de toda la arquitectura.
7.La webapps se implementa en
varias configuraciones ambientales
diferentes y se prueba en su
compatibilidad.

11. Estas pruebas inician con la culminación de las pruebas
de integración y el software está completamente
ensamblado como un paquete.
La validación es exitosa cuando el software funciona en
una forma que cumpla con las expectativas razonables
del cliente. (Pressman, 2010, p. 399)
Pruebas de
Validación

12. Serie de diferentes pruebas cuyo propósito principal es
ejercitar por completo el sistema, y verificar que todos
los elementos se hayan integrado de manera adecuada
y que realice las funciones adecuadas.
(Pressman, 2010, p. 401)
Pruebas de
Sistemas

13. Referencias
SOMMERVILLE IAN
Ingeniería del Software. 7ma Edición.Pearson Addison Wesley. Madrid 2005
PRESSMAN ROGER S
Ingeniería del Software. 7a. Edición. McGraw-Hill, 2010
LEÓN SERRANO GONZALO
Ingeniería del Software. 1a. Edición. Madrid. Isdefe. 1996

14. Autor: Ing. Neris Alfonzo