Validación y

verificación de
software mediante
pruebas
 Definición Myers (1979): “Prueba es el proceso de
ejecución de un programa con la intención de hallar
errores.”
Definición IEEE Std 610.12 (1990): ”(1) El proceso de
operar un sistema o componente bajo condiciones
especificadas, observando o registrando los
resultados, y haciendo una evaluación de algún
aspecto del sistema o componente. (2) ”El proceso de
analizar un elemento de software para detectar las
diferencias entre las condiciones existentes y las
Definición requeridas (es decir, errores) y para evaluar las
de prueba características del elemento de software.”
Definición Galin (2004): ”Las pruebas de software son
un proceso formal llevado a cabo por un equipo de
pruebas especializado en el que se examinan una
unidad de software, varias unidades de software
integradas o un paquete de software completo
ejecutando los programas en una computadora.
Todas las pruebas asociadas se realizan de acuerdo
con los procedimientos de prueba aprobados en
casos de prueba aprobados.”
 Componentes clave de
cualquier proceso de pruebas

Fuente: Walkinshaw, Neil (2017). Software Quality Assurance Consistency in the Face of Complexity and Change.
Editorial Springer.
Conjunto de entradas de prueba, condiciones de ejecución y
resultados esperados, desarrollados para un objetivo
concreto.

Consideraciones:
• Todos los casos de uso e historias de usuario tienen casos de
prueba.
• Para cada caso de uso e historia de usuario siempre existen
por lo menos un caso de prueba exitoso y uno no exitoso.
• Existen tanto casos de prueba específicos como generales.

Casos de prueba
 Ejemplos simples
No depende de un
estado del sistema.

Casos dependen del

estado.

Fuente: Walkinshaw, Neil (2017). Software Quality Assurance Consistency in the Face of Complexity and Change.
Editorial Springer.
 Un buen caso de prueba debe ser:

• Relativamente simple
• Preciso: de 10 a 15 pasos o
menos, no explicar la
funcionalidad una y otra vez.
Características • Repetible y reusable: fácil de
ejecutar.
• Rastreable.
• Un caso activo: de clic en…, el
sistema muestra…, aparece una
pantalla…
• Independiente.
 Diseño de pruebas
Implica diseñar casos de pruebas con entradas y
salidas definidas para evaluar el sistema.

La meta del diseño de casos de pruebas es crear

un conjunto de pruebas que sean efectivas
durante la etapa de validación.

El valor esperado del resultado de un caso de

prueba tiene que ser mayor que el costo de
diseñar y ejecutar la prueba.

El tiempo que se invierte en un caso de prueba

es tiempo que se “resta” a otras actividades o
casos de prueba.
Datos de pruebas
Lote de transacciones preparadas, procesadas mediante
las aplicaciones, con la finalidad de verificar el
funcionamiento efectivo de los controles programados
previstos.

Deben cubrir los posibles valores de cada parámetro

basado en los requerimientos.

Los tipos de datos se pueden clasificar como:

• Representativos (datos comunes).
• Incorrectos, incompletos e incongruentes.

Existen tres técnicas para el manejo de datos de pruebas:

1. clases de equivalencia,
2. análisis de límites y
3. suposición de errores.
 Una clase de equivalencia es un
subconjunto de datos que representa
una clase más amplia cuyos miembros
están relacionados.

Debido a que probar cada uno de los

valores es impráctico, se deberán de
Clases de escoger unos cuantos valores de cada
equivalencia clase de equivalencia o partición.

Cada clase es una partición de

equivalencia o dominio donde el
programa se comporta de forma
equivalente para cada miembro de la
clase.
 Ejemplos de clases de equivalencia para
cadenas:

• Cadena vacía.
• Cadena consistente de únicamente un
espacio vacío.
Clases de • Cadena que empieza o termina en un
espacio en blanco.
equivalencia • Sintácticamente correcta: valores cortos
y largos.
• Valor sintácticamente incorrecto:
caracteres o combinaciones ilegales
(probar caracteres especiales como #, ",
', &, <, ... y caracteres "extranjeros"
escritos desde teclados internacionales)
 Ejemplos de clases de equivalencia
para números:

• Cadena vacía.
• Cero
• Grandes y pequeños en rangos
Clases de positivos.
equivalencia • Grandes y pequeños en rangos
negativos.
• Fuera del rango de positivos.
• Fuera del rango de negativos.
• Que comiencen con ceros.
• Sintácticamente inválidos (por
ejemplo, que incluya letras).
 Ejemplos de clases de equivalencia
para archivos:
• Blanco.
• Archivo de 0 bytes.
• Archivos grandes.
Clases de • Archivo con nombre corto.
equivalencia • Archivo con nombre grande.
• Nombre de archivo sintácticamente
incorrecto, si es posible (por
ejemplo, "Nombre Con$ Caracteres
Especiales.tar.gz").
 Análisis de límites
Esta técnica se enfoca en los límites de los valores de entrada y
salida para una función.

Por ejemplo, para el caso del consumo de crédito de una cuenta,

podemos definir un análisis de límites tal que:
• Límites (¢1000 a ¢15,000)

Entrada Clases de equivalencia Clases de equivalencia

válidas inválidas
Un número • 1000 - 15000 • 0-999.99
• 15000
• Formato de número
inválido
• Letras
Suposición de
errores
Es basada en la teoría de que
las pruebas deben ser
desarrolladas basadas en la
intuición del revisor.
Por ejemplo, en una prueba
para para un campo fecha, se
podría pensar en hacer una
prueba con los valores 29 de
febrero del 2000 o 29 de
febrero del 2001.
Formato de casos de prueba
Aproximaciones casos de prueba
1. Pruebas basadas en requerimientos
2. Pruebas estructurales
3. Pruebas dirigidas por los datos
4. Pruebas creadas por exploración
5. Tablas de decisión
6. Pruebas de comparación
7. Pruebas de particiones (clases de equivalencia)
Aproximaciones casos de prueba
1. Pruebas basadas en requerimientos
• Un principio general de la ingeniería de requerimientos es que los
requerimientos deberían ser estables.
• Las pruebas basadas en requerimientos son técnicas de pruebas de
validación donde se considera cada requerimiento y se deriva un
conjunto de pruebas para ese requerimiento.
Aproximaciones casos de prueba
2. Pruebas estructurales
• También llamadas pruebas de caja blanca.
• Derivación de casos de pruebas de acuerdo a la estructura del
programa. El conocimiento del programa se utiliza para identificar
casos de pruebas adicionales.
• El objetivo es ejercitar todas las sentencias del programa (no todas
las combinaciones de caminos)
Aproximaciones casos de prueba
3. Pruebas dirigidas por los datos
• Los datos que cambian (entorno, salidas, entradas, etc) está separado
de la lógica del test y es almacenado en un repositorio externo.
• Recomendado para sistemas complejos y en mantenimiento.
• Es una técnica cara pero muy útil para crear casos de prueba
precisos.
Aproximaciones casos de prueba
4. Pruebas creadas mediante exploración
• Es bastante costoso e implica mucho tiempo del personal de QA y
desarrollo.
• Quien crea las pruebas no debería conocer la aplicación de
antemano.
• Existe el riesgo de dejar por fuera áreas clave, es especialmente
importante la pericia de quien prueba.
Aproximaciones casos de prueba
5. Tablas de decisión
Ejemplo: Reserva de un pasaje de avión
El viajero se presenta en el mostrador de una aerolínea y solicita un
pasaje para viajar a la ciudad de Nueva York. Si requiere un pasaje de
primera clase y hay plazas disponibles para el vuelo deseado se le
vende el pasaje de primera clase. En el caso de no resultar posible lo
anterior por hallarse reservados todos los pasajes de primera clase,
se le interroga si aceptaría un pasaje en clase turística, en caso de
disponerse de tal plaza; obviamente, de contestar afirmativamente,
se le vende el pasaje de clase turística.
Puede ocurrir que no acepte
cambiar de clase, o que todos los
asientes de clase turística estén
reservados, en cuyo caso se lo
registra en lista de espera de
primera clase. Aproximacione
s casos de
prueba
Si el viajero requiere un pasaje de
clase turística y hay plaza
disponible se le vende un pasaje de
esa clase; caso contrario se le
interroga si está dispuesto a
adquirir un pasaje de primera clase;
de no ser así, se lo ubica en lista de
espera de la clase turística.
Aproximaciones casos de prueba
Aproximaciones casos de prueba
5. Pruebas de comparación
• Comparar salidas del mismo software pero en diferentes versiones.
• A cada versión se le aplica como entrada los casos de prueba
diseñados para la otra.
• Si las salidas de distintas versiones son idénticas entonces todas las
implementaciones son correctas.
• Si la salida es diferente, se revisan las aplicaciones para determinar el
defecto.
Entorno en el que el producto en desarrollo se
prueba con la ayuda de herramientas de
software y hardware.

Son herramientas desarrolladas especialmente

para hacer pruebas. Bancos de
pruebas
Muchos bancos de prueba están abiertos para
configurarlos debido a que normalmente hay
que adaptarlos a situaciones específicas.
(test bench )
A veces existen dificultades para integrarlas
debido a que el sistema a probar no está bien
diseñado para interactuar con estas
herramientas.
 Casos de pruebas negativos
Estos casos de prueba se diseñan para utilizar y probar el software en
una manera para la cual no fue creado.

Deben ser parte de todo el conjunto de pruebas de un sistema.

Casos de prueba negativos usados comúnmente:


Comillas simples y apóstrofes: en sistemas con bases datos basadas en
SQL. Por ejemplo: John's.

Datos de entrada requeridos: la especificación funcional debería
indicar cuáles campos son obligatorios.

Tipos de datos de entrada: fechas, campos numéricos, números de
teléfono, entre otros.
 Casos de pruebas negativos

Tamaño de los datos de entrada: validación de la cantidad de
caracteres para campos de texto.

Prueba de límites numéricos.

Restricciones de los tipos numéricos: enteros varían entre -32,767 y
32,767 y enteros largos entre -2,147,483,648 y 2,147,483,647.

Prueba de límites de fechas: la fecha de nacimiento de una persona no
debería ser “hace más de” 150 años.

Validación de fechas: 31/04/2007 y 30/02/2009 no existen; deben
considerarse también los años bisiestos.

Pruebas de sesiones y configuración Web: datos en la sesión de HTTP.

Cambios de rendimiento: impacto causado de una versión del
producto a otra.
Casos de pruebas negativos
 Axiomas de Myers
(The Art of Software Testing)
• Un buen conjunto de datos de prueba posee una gran probabilidad de
detectar un error no descubierto.
• Uno de los problemas más difíciles con que se tropieza en una prueba
es saber cuándo detenerse.
• Es imposible que usted pruebe su propio programa.
• La descripción de la información de salida o de los resultados
esperados, es un elemento imprescindible de todo conjunto de datos
de prueba.
• Evitar pruebas no repetibles o reproducibles.
 Axiomas de Myers
• Desarrollar datos de prueba con información de entrada relativa a
condiciones válidas e inválidas.
• Examinar y revisar cuidadosamente los resultados de cada prueba.
• Con el incremento del número de errores encontrados en un sistema,
aumenta igualmente la probabilidad de la existencia de errores no
descubiertos.
• Asignar la tarea de pruebas a las personas con mayor creatividad.
• Contemplar en el diseño y estructura del programa, las facilidades
para una prueba adecuada.
 Axiomas de Myers
• El diseño debe contemplar y asegurar que cada módulo sea integrado
con el sistema una sola vez.
• No alterar nunca el programa para que una prueba resulte más fácil.
• La prueba, como cualquier otra actividad, debe comenzar con el
establecimiento de los objetivos pertinentes.
Ejemplos de casos de prueba
Código 001
Descripción Ingresar a la cuenta de correo.
Prerrequisitos El equipo debe contar con conexión a Internet, tener una
cuenta activa.
Pasos a 1. Vaya al sitio http://www.gmail.com
reproducir 2. Introduzca un nombre de usuario y contraseña válidos
3. Clic en el botón Acceder
Datos de Nombre de usuario = {cvargascr}
prueba Contraseña = {12345}
Resultados Se muestra un mensaje de bienvenida a la bandeja de
esperados entrada del correo electrónico.
 Ejemplos de casos de prueba
Código 002
Descripción Validar la creación de un usuario sin que se complete la
información requerida en el formulario.
Prerrequisitos El equipo debe contar con conexión a Internet
Pasos a 1. Vaya al sitio http://www.gmail.com
reproducir 2. Clic en el botón Crear una nueva cuenta
- Una nueva pantalla se despliega.
3. No complete ningún campo del formulario y dé clic en
el botón Siguiente Paso.
Resultados Se muestra un mensaje de error al usuario solicitando
esperados completar los campos del formulario y el proceso no
continua.
 Ejemplos de casos de prueba
Código 003
Descripción Verifique que todos los componentes del sitio, estilos,
colores, entre otros, sean correctos.
Prerrequisitos El equipo debe contar con conexión a Internet
Pasos a 1. Vaya al sitio http://www.gmail.com
reproducir 2. Navegue entre las distintas páginas del sitio.
3. Para cada página verifique que:
 Los logos del sitio son mostrados.
 El color de fondo, tamaño de letra y estilo son
constantes.
 La página puede ser minimizada y maximizada sin
perder su información o estilo.
Resultados Las páginas se despliegan correctamente.
esperados
Errores comunes al escribir
CP
• Casos de prueba muy largos.
• Incompletos, incoherentes o incorrectos.
• Olvidar algún paso.
• Nombrar campos que están cambiando
constantemente y que pueden dejar de existir.
• No tener bien definido el funcionamiento de la
aplicación.
• No entender la diferencia entre un caso de
prueba exitoso y no exitoso.
• Falta de mantenimiento en los casos de
prueba.
• Enfocados a validaciones de campos en la
interfaz.
Fuentes de información para la
selección de casos de prueba
1. Requisitos y especificaciones funcionales
2. Código fuente
3. Dominio de entrada y salida
4. Perfil operacional o perfiles de usuario
5. Modelo de falla
 Fiabilidad
La fiabilidad se puede definir como el grado en el que se espera que un
programa realice su función con una precisión requerida.

Para validar que el sistema satisface los requerimientos, tiene que

medirse la fiabilidad del sistema tal y como lo ve un usuario típico del
mismo.
Práctica en clase
Elabore dos casos de prueba (uno de éxito y uno de fallo)
para cada uno de los siguientes sitios:
http://www.bncr.fi.cr
http://www.amazon.com
http://www.yuplon.com
http://www.facebook.com
http://www.nacion.com