UNIDAD 2

FUNDAMENTOS
DE LAS PRUEBAS
DEL
SOFTWARE
¿Que son la pruebas de Software?

Las pruebas de software son un elemento critico para la Mejora la Calidad de Software en Producción
garantía de la calidad del software y representa una Mejora la Produccion de los Grupos de Trabajo
revisión final de las especificaciones, del diseño y de la
codificación. Reduce los Costos de Mantenimiento
 El proceso de operar un sistema o partes de
el bajo ciertas condiciones, observando y
registrando los resultados y realizar una
evaluación de algún aspecto del sistema o
componente. (IEEE)

Testing Es el proceso de ejecutar un programa con la

intensión de encontrar errores (Meyers)
(Definición)

El TESTING es el ARTE de DESTRUIR algo

CONSTRUCTIVAMENTE
 Inicialmente el
En los ‘80 aparecen
testing era
standares
debugging

Aún en nuestros dias

Testing En los ’90 aparecen
herramientas
se trata de un
proceso inmaduro

Cada vez existen mas

formalizaciones a
esta disciplina
 NO ES debuggear el código

NO ES simplemente verificar que

Testing las funciones del sistema se
implementen bien

NO ES una demostración de que

no hay errores
 ERROR
• Equivocación humana
• En error introduce uno o mas defectos en el código
• Ejemplo 1: Un paso de parámetros incorrectos
• Ejemplo 2: Un signo de comparación equivocado al inicio de
un bucle

DEFECTO (BUG)
Testing • Es la consecuencia de un error humano introducido en el
código
• Un defecto existe en el código y a partir de el se hace visible
una falla.
• No existe defecto si el sistema no puede fallar

FALLO (FAILURE)
• Ocurre cuando un programa no se comporta como se espera
• Un error introduce un o mas defectos
• Un defecto se materializa en una o mas fallas
 Testing exitoso es aquel que
encuentra la mayor cantidad de
defectos, no lo opuesto

Testing
Paradójicamente: Un desarrollo
exitoso puede conducir a un
testing poco/no exitoso
Por qué es necesario el testing?
La elaboración de Software es una tarea creativa y
manual. Los errores indefectiblemente están:
• Todos cometemos errores u omisiones
• capacitación insuficiente
• Comunicación deficiente
• Requerimientos incompletos o
desactualizados
• Se asumen situaciones
Por qué es necesario el testing?
Costo de un error
A medida que pasa el tiempo, el costo de corregir un defecto se incrementa
de manera inversamente proporcional al costo de detectarlo
$
Detección de defectos
Corrección de Defectos

Tiempo
Por qué es necesario el testing?

Identificar fallas tempranamente Asegurar que el producto satisface

los requisitos
Reduce los errores de producción Concordancia entre lo desarrollado y lo
Mejora la calidad del producto solicitado
Incrementa la credibilidad
Ayuda a asegurar que una falla en producción no
afectara los costos ni la rentabilidad
 La prueba exhaustiva del software es impracticable (no se
pueden probar todas las posibilidades de su
funcionamiento ni siquiera en programas sencillos.

Program Sumar
Int a,b : 0..99
Begin
El costo del Read (a)

Testing Read (b)

Write (a+b)
end
El costo del Testing
$
Costo de tener los defectos
Costo de Probar

% de errores eliminados
Tipos de Testing
• Pruebas de Unidad
• Se trata de las pruebas formales que permiten declarar que un módulo
está listo y terminado (no las informales que se realizan mientras se
desarrollan los módulos)

• Elemento de verificación
• interfaces entrada/salida
• estructuras de datos locales
• cálculos
• flujo de control
• caminos de procesamiento de errores
Tipos de Testing
• Pruebas de Sistema
• Se conoce con el nombre de pruebas de sistema a aquellas pruebas que
toman el Sistema de Información al completo y lo prueban tanto en su
conjunto como en sus relaciones con otros sistemas con los que se
comunique

• Elemento de verificación
• Cumplimiento de todos los requisitos funcionales, considerando el producto
software final al completo en un entorno de sistema
• El funcionamiento y rendimiento en las interfaces hardware, software, de usuario y
de operador
• Adecuación de la documentación de usuario
Tipos de Testing
• Pruebas de Aceptación de Usuario
• Comprobar si el producto está listo para ser implantado para el uso
operativo en el entorno del usuario.
• Participación del Usuario
• Está enfocada hacia la prueba de los requisitos de usuario especificados
• Está considerada como la fase final del proceso para crear una confianza
en que el producto es el apropiado para su uso en producción.
 Entorno de
Producción

Tipos de Requisitos No
Funcionales
Testing

Requisitos
Funcionales

Entorno de
Desarrollo
 Las pruebas que se realizan, desde una
perspectiva, para determinar lo rápido
que realiza una tarea un sistema en
condiciones particulares de trabajo.

Pruebas de También puede servir para validar y

verificar otros atributos de la calidad del
sistema, tales como la escalabilidad,
Performance fiabilidad uso de los recursos.

Eliminar ineficiencias en el código

(Algoritmos de búsqueda), Optimizar
queries, monitorizar uso de recursos
(CPU, Memoria, Disco)
 La prueba de
Software en el Ciclo
de vida de Software

Ciclo de Vida en Cascada

(Waterfall)
 La prueba de
Software en el Ciclo
de vida de Software

Ciclo de Vida Proceso

Unificado
 La prueba de
Software en el Ciclo
de vida de Software

Testing en Agile
El proceso de
pruebas
El proceso de pruebas
 Los recursos –
El enfoque
Personal Responsable

El esquema de Los elementos a

actividades de prueba probar

Planear la
Prueba Las actividades de
Las características
prueba

Los riesgos asociados

Planear la El Plan de Pruebas
Prueba El plan de pruebas es el documento mediante el cual el
equipo de testing le comunica al equipo de desarrollo
como se va a llevar adelante el plan de testing
El proceso de pruebas
DISEÑAR LAS PRUEBAS
Caso de Prueba

Un caso de prueba es una especificación

formal de un conjunto de entradas,
condiciones de ejecución y resultados
esperados, identificados con el propósito de
realizar una evaluación sobre algún aspecto
particular del sistema
Características de un Caso de Prueba

• Solo prueba una cosa en un caso de prueba

• El caso de prueba debe tener un propósito exacto
• El caso de prueba debe estar escrito en un lenguaje claro y fácil de entender.
• El caso de prueba debe ser relativamente pequeño
• El caso de prueba debe ser independiente
• El caso de prueba no debe tener pasos o palabras innecesarias
• El caso de prueba debe ser repetible
• El caso de prueba debe usar terminología consistente e identificación de funcionalidad
ELEMENTOS DE UN CASO DE PRUEBA
Test Case Id: un código que permite identificar unívocamente al caso de prueba
dentro de la suite

Descripción: contiene el propósito y objetivo de la prueba

Condiciones de ejecución: una descripción de las condiciones que serán

ejercitadas durante la prueba

Precondiciones: describe el estado requerido en el que el sistema debe estar

antes de comenzar la prueba
ELEMENTOS DE UN CASO DE PRUEBA
Entradas: enumera la lista de datos de entrada que serán aplicados durante la
ejecución del caso de prueba

Pasos: es la especificación individual de cada evento que se realiza sobre el

sistema y el resultado esperado del mismo

Resultados esperados: es el estado resultante o las condiciones observables

esperadas una vez que la prueba ha sido ejecutada

Postondiciones: describe el estado en el que el sistema debe quedar al finalizar

la ejecución de las pruebas
DE DONDE PARTIMOS?
Casos de Prueba – Casos de Uso
• A partir de Casos de Uso
• Dividir las funciones del caso de uso en áreas “testeables”, conjuntos de
tareas menores que permitan realizar mediciones individuales
• Identificar tareas iterativas
• Agrupar/Crear datos de prueba
• Escribir los casos de prueba documentando las precondiciones (las cuales
pueden ser tanto estados iniciales como otros casos de prueba)
• Realizar una prueba de escritorio siguiendo todos los casos de prueba que
componen cada flujo del caso de uso.
Casos de Prueba – Casos de Uso
• ID-Nombre: PE-Prestar Ejemplar
• Descripción: se permite al empleado prestar un ejemplar al cliente.
• Actores: empleado
• Pre-condiciones: que el cliente exista como tal
• Post-condiciones: se imprime el comprobante del préstamo y se
modifica la existencia del ejemplar en la BD para reflejar la operación.
Casos de Prueba – Casos de Uso
• Flujo Principal
1. El empleado ingresa el documento del cliente
2. El sistema busca los datos del cliente y los muestra por pantalla junto a las
reservas hechas, si es que tiene alguna vigente.
3. El empleado ingresa el código del ejemplar a retirar o selecciona una
reserva
4. El sistema valida la existencia actual del ejemplar solicitado y pide
confirmación del préstamo
5. El empleado confirma la operación
6. El sistema actualiza la existencia del ejemplar en la BD
Casos de Prueba – Casos de Uso
ID: TC-000235
Descripción: Validar la búsqueda de usuario por numero de documento
Precondiciones: el usuario esta logueado en la aplicación. Existe un usuario con DNI 20.000.001 en la
base de datos de usuarios con al menos una reserva asociada
Entradas:
#
Nro de Documento
Descripcion Resultado esperado
1 Hacer click en el link “búsqueda de usuarios” Se busca la pantalla de búsqueda según el mockup usrsearch_01 del caso de uso
2 Se ingresa el Valor 20.000.001 en el campo “documento” y Se visualiza la pantalla de resultados con la siguiente información: DNI, Nombre y
se hace click en el botón Buscar Teléfono del usuario, seguida de una lista de las reservas asociadas
3 Ejectuar la siguiente Query: La cantidad de registros y valores obtenidos coinciden con los valores mostrados en el
SELECT * FROM RESERVAS WHERE DNI=20000001 paso #2

Resultados esperados: los datos de usuario y sus reservas son correctamente mostrados en la pantalla
según los resultados de la consulta del paso 3
Postcondiciones: Se muestra el campo para ingresar el código de ejemplar a retirar, no se producen
Casos de Prueba – Casos de Uso
• Flujo Alternativo
2.1. El sistema no encuentra los datos del cliente y muestra un
mensaje de error por pantalla.
Casos de Prueba – Casos de Uso
ID: TC-000236
Descripción: Validar la detección de usuario no encontrado en la tabla de usuarios
Precondiciones: el usuario esta logueado en la aplicación. No existe un usuario con DNI 26.666.777 en la base
de datos.
Entradas: Nro de Documento
# Descripcion Resultado esperado
1 Hacer click en el link “búsqueda de usuarios” Se busca la pantalla de búsqueda según el mockup usrsearch_01 del caso de uso
2 Se ingresa el Valor 26.666.777 en el campo “documento” y Se muestra un mensaje en pantalla indicando que el usuario con el documento
se hace click en el botón Buscar especificado no existe en la base de datos.
3 Ejectuar la siguiente Query: La consulta devuelve resultado 0.
SELECT COUNT(*) FROM RESERVAS WHERE
DNI=26.666.777

Resultados esperados: No se muestran la pantalla de resultados, en lugar de ello se despliega un mensaje

indicando que no se encontró el usuario
Postcondiciones: Se muestra nuevamente el campo ingresar documento, no se producen cambios en la tabla
Casos de
Prueba –
Mockups
Casos de Prueba – User Stories
• Como usuario quiero poder loguearme al sistema para acceder a las
funciones del mismo

• Criterios de aceptación:
• La password tiene entre 6 y 10 caracteres alfanuméricos
• La password debe ser invisible
• El username y la password no pueden ser campos vacíos
• El username debe ser bloqueado después de tres intentos de acceso fallidos.
 Actividad en CV
El Mejor Template