VERIFICACION Y

VALIDACION

FRANCISCO I. REYES ACEVEDO

DEFINICIONES
Verificación:
El proceso de evaluación de un sistema (o de uno de sus
componentes para determinar si los productos de una fase
dada satisfacen las condiciones impuestas al comienzo de
dicha fase.

Validación:
El proceso de evaluación de un sistema o de uno de sus
componentes durante o al final del proceso de desarrollo
para determinar si satisface los requisitos marcados por el
usuario.
Pruebas (test):
Una actividad en la cual un sistema o uno de sus componentes
se ejecuta en circunstancias previamente especificadas, los
resultados se observan y registran y se realiza una evaluación de
algún aspecto
Caso de prueba (test case):
Un conjunto de entradas, condiciones de ejecución y resultados
esperados desarrollados para un objetivo particular
Defecto (defect, fault, bug):
Un defecto en el software como, por ejemplo, un proceso, una
definición de datos o un paso de procesamiento incorrectos en
un programa
Fallo ( failure):
La incapacidad de un sistema o de alguno de sus
componentes para realizar las funciones requeridas
dentro de los requisitos de rendimiento especificados
Error (error):
La diferencia entre un valor calculado, observado o
medio y el valor verdadero, especificado o
teóricamente correcto
IDEAS PARADÓGICAS DE LAS PRUEBAS
La prueba exhaustiva del software es impracticable no
se pueden probar todas las posibilidades de su
funcionamiento ni siquiera en programas sencillos
El objetivo de las pruebas es la detección de defectos
en el software (descubrir un error es el éxito de una
prueba)
El descubrimiento de un defecto significa un éxito
para la mejora de la calidad
PROCESO DE PRUEBA
La depuración (localización y corrección de defectos)
El análisis de la estadística de errores

ACTIVIDADES
Sirve para realizar predicciones de la fiabilidad del
software y para detectar las causas más habituales de
error y por tanto mejorar los procesos de desarrollo
ENFOQUES DE DISEÑO DE PRUEBAS
Existen dos enfoques principales para el diseño de
casos:
1.- El enfoque estructural o de caja blanca. Se centra en la
estructura interna del programa (analiza los caminos
de ejecución).
2.- El enfoque funcional o de caja negra. Se centra en las

funciones, entradas y salidas.

PRUEBAS FUNCIONALES

 Se centran en las funciones, entradas y salidas.

 Es impracticable probar el software para todas las posibilidades. De

nuevo hay que tener criterios para elegir buenos casos de prueba

Un caso de prueba funcional es bien elegido si se cumple que:

 Reduce el número de otros casos necesarios para que la prueba sea

razonable. Esto implica que el caso ejecute el máximo número de
posibilidades de entrada diferentes para así reducir el total de casos.
 Cubre un conjunto extenso de otros casos posibles, es decir, no indica
algo acerca de la ausencia o la presencia de defectos en el conjunto
específico de entradas que prueba, así como de otros conjuntos similares.
TÉCNICA: PARTICIPACIONES O CLASES DE
EQUIVALENCIA

Cada caso debe cubrir el máximo número de entradas

Debe tratarse el dominio de valores de entrada

dividido en un número finito de clases de equivalencia
que cumplan la siguiente propiedad: la prueba de un
valor representativo de una clase permite suponer
“razonablemente” que el resultado obtenido (existan
defectos o no) será el mismo que el obtenido probando
cualquier otro valor de la clase
PASOS PARA IDENTIFICAR CLASES DE EQUIVALENCIA

 1. Identificación de las condiciones de las entradas del programa,

es decir, restricciones de formato o contenido de los datos de
entrada
 2. A partir de ellas, se identifican clases de equivalencia que
pueden ser:
a) De datos válidos
b) De datos no válidos o erróneos
 3. Existen algunas reglas que ayudan a identificar clase:
a) Si se especifica un rango de valores para los datos de
entrada, se creará una clase válida y dos clases no válidas
b) Si se especifica un número finito y consecutivo de
valores, se creará una clase válida y dos no válidas
 c) Si se especifica una situación del tipo «debe ser» o booleana
(por ejemplo, «el primer carácter debe ser una letra»), se
identifican una clase válida («es una letra») y una no válida
(«no es una letra»)
d) Si se especifica un conjunto de valores admitidos y se sabe
que el programa trata de forma diferente cada uno de ellos, se
identifica una clase válida por cada valor y una no válida
e) En cualquier caso, si se sospecha que ciertos elementos de
una clase no se tratan igual que el resto de la misma, deben
dividirse en clases menores
Ejemplo: Aplicación bancaria en la que el operador debe proporcionar un código,
un nombre y una operación
PRUEBAS DE CARGA, DE RENDIMIENTO Y
DE STRESS
 De Carga (Load test): pruebas para determinar y validar la respuesta de la
aplicación cuando es sometida a una carga de usuarios y/o transacciones que se
espera en el ambiente de producción. Ejemplo: verificar la correcta respuesta de
la aplicación ante el alta de 100 usuarios en forma simultanea. Se compara con
el volumen esperado.
 De rendimiento (performance test): estas pruebas se realizan para medir la
respuesta de la aplicación a distintos volúmenes de carga esperados (cantidad
de usuarios y/o peticiones). Ejemplo: velocidad de respuesta al procesar el
ingreso de 10, 100 y 1000 usuarios en forma simultánea. Se comprar con el
rendimiento esperado.
 De Estrés (stress test): pruebas para encontrar el volumen de datos o de tiempo
en que la aplicación comienza a fallar o es incapaz de responder a las
peticiones. Son pruebas de carga o rendimiento, pero superando los límites
esperados en el ambiente de producción y/o determinados en las pruebas.
Ejemplo: encontrar la cantidad de usuarios simultáneos, en que la aplicación
deja de responder (cuelgue o time out) en forma correcta a todas las peticiones.
PRUEBAS UNITARIAS
Son pruebas dirigidas a probar clases aisladamente y
están relacionadas con el código y la responsabilidad de
cada clase y sus fragmentos de código más críticos.

Por ejemplo una clase que envíe emails, debe ser capaz
de probarse aislada chequeando que sea capaz de enviar
emails, y asegurándonos de probar todas las
posibilidades de fallo y éxito. En un modelo basado en
pruebas, se deben definir casos de prueba para cada
clase de forma aislada, una prueba no debe depender de
otras clases.
PORQUE HACER PRUEBAS UNITARIAS
 Asegura calidad del código entregado. Es la mejor forma de detectar errores
tempranamente en el desarrollo. No obstante, esto no asegura detectar todos los
errores, por tanto prueba de integración y aceptación siguen siendo necesarias.
 Ayuda a definir los requerimientos y responsabilidades de cada método en cada clase
probada.
 Constituye una buena forma de ejecutar pruebas de concepto. Cuando es necesario
hacer pruebas de conceptos sin integrar usar pruebas unitarias se convierte en un
método efectivo.
 Permite hacer refactoring tempranamente en el código. No es necesario todo un ciclo
de integración para hacer refactoring en la aplicación, basta con ver como se
comporta un caso de prueba para hacer refactoring unitario sobre la clase que
estamos probando en cuestión.
 Permite incluso hacer pruebas de stress tempranamente en el código. Por ejemplo un
método que realice una consulta SQL que exceda los tiempos de aceptación es
posible optimizarla antes de integrar con la aplicación.
 Permite encontrar errores o bugs tempranamente en el desarrollo. Y está demostrado
PRUEBAS DE INTEGRACION
 La prueba de integración es una técnica sistemática para construir la estructura
del programa mientras al mismo tiempo, se lleva a cabo pruebas para detectar
errores asociados con la interacción.

 El objetivo es tomar los módulos probados en unidad y estructurar un

programa que esté de acuerdo con el que dicta el diseño. La integración puede
ser descendente si se integran los módulos desde el control o programa
principal, o bien, ascendente, si la verificación del diseño empieza desde los
módulos más bajos y de allí al principal. La selección de una estrategia de
integración depende de las características del software y, a veces, del plan del
proyecto, en algunos de los casos se puede combinar ambas estrategias.
PLAN DE PRUEBAS
Objetivo del documento
Señalar el enfoque, los recursos y el esquema de
actividades de prueba, así como los elementos a probar,
las características, las actividades de prueba, el
personal responsable y los riesgos asociados
ESTRUCTURA DEL ESTANDAR
IEEE-1008-1987
1. Identificador único del documento
2. Introducción y resumen de elementos y características a probar
3. Elementos software a probar
4. Características a probar
5. Características que no se probarán
6. Enfoque general de la prueba
7. Criterios de paso/fallo para cada elemento
8. Criterios de suspensión y requisitos de reanudación
9. Documentos a entregar
10. Actividades de preparación y ejecución de pruebas
11. Necesidades de entorno
12. Responsabilidades en la organización y realización de las pruebas
13. Necesidades de personal y formación
14. Esquema de tiempos
15. Riesgos asumidos por el plan y planes de contingencias
16. Aprobaciones y firmas con nombre y puesto desempeñado