Este documento contiene información sobre pruebas de software. Explica las diferentes fases y niveles de prueba como pruebas unitarias, de integración, de sistema y de aceptación. También describe las ventajas de automatizar las pruebas como mayor rapidez de ejecución y menos recursos necesarios.

1. Facultad de Ciencias Informáticas
Desarrollo de Aplicaciones Web
Unidad 2 Programación web en el
servidor
PhD(c). Luis Fernando Aguas Bucheli
+593 984015184
@Aguaszoft
luis.aguas@utm.edu.ec

2. Objetivos de Desarrollo Sostenible
Meta
4.7 De aquí a 2030, asegurar que todos los alumnos adquieran
los conocimientos teóricos y prácticos necesarios para promover
el desarrollo sostenible, entre otras cosas mediante la educación
para el desarrollo sostenible y los estilos de vida sostenibles, los
derechos humanos, la igualdad de género, la promoción de una
cultura de paz y no violencia, la ciudadanía mundial y la
valoración de la diversidad cultural y la contribución de la cultura
al desarrollo sostenible

3. El dinero no es la clave del éxito; la libertad para
poder crear lo es - Nelson Mandela

4. Resultado de Aprendizaje
• Diseñar un producto de
software en el que se
apliquen principios de
diseño, para que sea
robusto, fácil de mantener
y modificar
Contenido
• Unidad 2 Programación web en
el servidor
• 2.2.2 Test unitarios y de
integración
• 2.2.3 Control de sesiones y
autenticación

5. Introducción a las pruebas
Ariane 5.
Lanzado por primera vez el 4 de junio de
1996.
Motivo:
Fallo software. La programación no se había probado lo suficiente.
Ariane 5.
36.7 segundos después explotó.

6. Introducción a las pruebas
Sistemas software:
• Mayor tamaño.
• Mayor complejidad.
• Menor tiempo de desarrollo.
• Mayor calidad.
Pruebas:
• Más importancia y
protagonismo día a día.
• Garantizan la calidad del
software.
• Garantizan la satisfacción de los
requisitos.
• Ahorran tiempo y recurso en el
desarrollo.
• Su objetivo: localizar, para
subsanarlas, el mayor número
de deficiencias lo antes posible.
Un reto a la
Ingeniería de
Software.

7. Introducción a las pruebas
Verificación dinámica del
comportamiento del
software a partir de un
conjunto finito de casos de
prueba.
Definición de prueba:
Para probar un software
necesitamos ejecutar ese
software.

8. Introducción a las pruebas
Verificación dinámica del
comportamiento del software a
partir de un conjunto finito de
casos de prueba.
Definición de prueba:
Dos conceptos muy
relacionados:
Validación: proceso de evaluar un
sistema o componente durante o al
final del proceso de desarrollo para
determinar si satisface los requisitos
especificados.
1
2
Verificación: proceso de evaluar un
sistema o componente para
determinar si los productos de una
determinada fase satisfacen las
condiciones impuestas al comienzo
de la fase.

9. Introducción a las pruebas
Verificación dinámica del
comportamiento del
software a partir de un
conjunto finito de casos de
prueba.
Para probar un programa
tenemos que ejecutarlo.
La prueba tiene un límite.
No vale ejecutar el
programa de cualquier
manera.

10. Introducción a las pruebas
Configurar partida:
 El sistema muestra un formulario con todos los
valores configurables.
 El jugador introduce modifica los valores.
 El sistema comprueba la validez de los valores y
vuelve a la pantalla principal.
Acciones
Configuración:
Intentos = 5
Valores = 8
Repetidos = cierto
Valores del prueba Resultado
Una prueba consta, al
menos, de tres
elementos:

11. Introducción a las pruebas
¿Funciona el teléfono?.
Valores de
prueba
Acciones Resultado esperado
123-45-67-89 1. Descolgar auricular.
2. Marcar número de Pepote.
3. Esperar contestación.
(Pepote): “Digameee”.
Veamos un ejemplo sencillo:

12. Introducción a las pruebas
¿Me está bien esta camisa?
Valores de
prueba
Acciones Resultado esperado
Mi cuerpo. 1. Ponerme la camisa.
2. Abrochármela.
3. Moverme un poco.
4. Mirarme al espejo.
Cuidado con la etiqueta o con arrugarla
por si hay que devolverla
Elegancia y confort.
Veamos otro ejemplo sencillo:

13. Introducción a las pruebas
public int suma(int a, int b)
{
return a + b;
}
¿Qué casos de prueba podemos escribir?.
Valores de
prueba
Acciones Resultado
esperado
??? Suma(a, b) ???
Los casos de prueba son
finitos (y cuantos menos,
mejor).

14. Introducción a las pruebas
public int suma(int a, int b)
{
return a + b;
}
¿Qué casos de prueba podemos escribir?.
Valores de
prueba
Acciones Resultado
esperado
0, 0 Suma(a, b) 0
0, b = no 0 Suma(a, b) b
3, 4 Suma(a, b) 7
-2, -8 Suma(a, b) -10
-3, 6 Suma(a, b) 3
Integer.MAX_V
ALUE, 6
Suma(a, b) -2147483643
Y algunas permutaciones más.

15. En conclusión
• Probar es ejecutar casos de prueba.
• Caso de prueba:
entrada + acciones + salida
salida obtenida == salida esperada
salida obtenida != salida esperada
• ¿Un programa que pasa todos sus casos de prueba es un programa
sin errores?.

16. En conclusión
No
Las pruebas sólo pueden
encontrar los errores que buscan.
Por esto es tan importante un
buen diseño de pruebas.

17. FASES DE LA PRUEBA
• Diseño de las pruebas (¿técnicas?)
• Generación de casos de prueba (¿datos de prueba?)
• Definición del procedimiento de la prueba (¿cómo, donde?)
• Ejecución de la prueba
• Informe de la prueba (¿resultados?)
TÉCNICAS DE PRUEBA
• Pruebas estructurales o de Caja Blanca.
• Pruebas funcionales o de caja negra.
ESTRATEGIAS DE PRUEBA
• Pruebas unitarias.
• Pruebas de integración.
• Pruebas de sistema.
• Pruebas de aceptación.
• Pruebas de regresión.
Niveles de prueba
Aspectos que
trataremos hoy

18. Niveles de prueba
P
r
o
c
e
s
o
d
e
d
e
s
a
r
r
o
l
l
o
P
r
o
c
e
s
o
d
e
p
r
u
e
b
a
Pruebas
unitárias
Pruebas de
integración
Pruebas de
sistema
Pruebas de
aceptación
Componentes
aislados
Verifican
Interacción
entre
componentes
Verifican
Requisitos del
sistema
Necesidades
de los
usuarios
Verifican
Verifican
Pruebas de
implantación
Paso a
producción
Verifican

19. Pruebas unitarias
Cuando: Durante la
construcción del sistema.
Objetivo: Prueban el diseño
y el comportamiento de
cada uno de los
componentes una vez
construidos.
Cobertura
CruiseControl
XUnit
TestNG
Cactus
jMock
EasyMock
muJava
CoView
Herramientas:

20. Pruebas unitarias
Técnicas:
• Análisis de caminos.
• Partición de categorías.
• Mutaciones.
• Algoritmos genéricos.
En general, han sido muy
estudiadas.

21. Pruebas de integración
Herramientas:
Las mismas, vamos
sustituyendo los mocks por
las clases reales y, si es
necesario, escribiendo más
casos de prueba.
Cuando: Durante la construcción
del sistema
Objetivo: Comprueban la correcta
unión de los componentes entre sí
a través de sus interfaces, y si
cumplen con la funcionalidad
establecida

22. Pruebas de integración
Técnicas:
Arriba abajo:
El primer componente que se prueba es el primero
de la jerarquía (A). Una de las ventajas es que las
interfaces entre los distintos componentes se
prueban en una fase temprana y con frecuencia.
Abajo a arriba:
Se prueban primero los componentes de más bajo
nivel (E, F) Este tipo de enfoque permite un
desarrollo más en paralelo, pero presenta mayores
dificultades a la hora de planificar y de gestionar.

23. Pruebas de sistema
Herramientas:
Cuando: Durante la construcción
del sistema (partes completas).
Objetivo: Prueban a fondo el
sistema, comprobando su
funcionalidad e integridad
globalmente, en un entorno lo
más parecido posible al entorno
final de producción.
Herramientas:
Técnicas: probar el sistema como
lo hará el usuario final.
JMeter
The Grinch
Avignon
JWebTest Selenium
Abbot
Marathon
HttpUnit
GUItar

24. Pruebas de implantación
Herramientas:
Cuando: Durante la implantación en
el entrono de producción.
.
Objetivo: Comprueban el correcto
funcionamiento del sistema dentro
del entorno real de producción
(rendimiento, copias de seguridad,
etc.).
Herramientas:
Las mismas. Las pruebas se vuelven
a ejecutar en el entorno real de
producción y se añaden nuevas
pruebas.
.

25. Pruebas de aceptación
Herramientas:
Cuando: Después de la
implantación en el entorno de
producción.
Objetivo: Verifican que el sistema
cumple con todos los requisitos
indicados y permite que los
usuarios del sistema den el visto
bueno definitivo.
Herramientas:
Las mismas. Las pruebas se vuelven
a ejecutar en el entorno real de
producción y se añaden nuevas
pruebas.
.

26. Pruebas de regresión
Cuando: Durante el
mantenimiento del sistema.
Objetivo: Comprobar que los
cambios sobre un componente de
un sistema de información, no
introducen un comportamiento no
deseado o errores adicionales en
otros componentes no
modificados
Herramientas:
Las mismas.

27. Características de una buena prueba
• Ha de tener una alta probabilidad de encontrar un fallo. Cuanto más,
mejor.
• No debe ser redundante. Si ya funciona, no lo probamos más.
• Debe ser la “mejor de la cosecha”. Si tenemos donde elegir, elegimos
la mejor.
• No debería ser ni demasiado sencilla ni demasiado compleja. Si es muy
sencilla no aporta nada, si es muy compleja a lo mejor no sabemos lo
que ha fallado.

28. Automatización de las pruebas
“No sirven para nada”
“Engaño”
“Pérdida de tiempo”
“Descartadas al primer cambio”
“Imposibles de mantener”
“Moda”
¿Por qué?.
Algunas palabras que hemos escuchado hablando de pruebas.

29. Automatización de las pruebas
Las pruebas son polémicas:
• No son parte de la solución.
• No se las entregamos a nuestros clientes.
• Incluso pueden darles a nuestros clientes una mala
impresión.
• Nuestros clientes no nos las pagan.
• Difíciles de mantener.
Sin embargo, las pruebas son imprescindibles.
La automatización nos permite reducir
costes.

30. Automatización de las pruebas
¿Qué significa automatizar?.
¿Qué podemos automatizar?.
En este caso concreto: realizar de manera
automática mediante herramientas
software.
Diseño de las pruebas
Codificación de las pruebas
Ejecución de las pruebas
Evaluación de resultados
Lo más habitual, muchas
técnicas y herramientas
Menos habitual, pocas
técnicas y herramientas.
El objetivo de esta
presentación

31. Automatización de las pruebas
Ventajas de la automatización:
• Mayor rapidez de ejecución.
• Menos recursos.
• Evitamos pruebas obsoletas

32. Automatización de las pruebas
Inconvenientes:
• ¡Muy pocas herramientas!.
• Necesitan una “base” a menudo inexistente.
• Un conjunto pobre de pruebas.

33. Automatización de las pruebas
Cuando automatizar y cuando no automatizar.
Bien Mal.
Gastamos más en la
automatización que en
la pruebas en sí.
No buscamos
automatizarlo
absolutamente todo.
Tenemos modelos y
documentación del
sistema.
Construimos el sistema
sobre la marcha.
Nosotros controlamos
las herramientas de
prueba.
Las herramientas de
prueba nos controlan a
nosotros.

34. Gracias
Somos UTM