FRANCISCO I.

REYES ACEVEDO

DEFINICIONES
Verificacin:
El proceso de evaluacin 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.
Validacin:

El proceso de evaluacin 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 evaluacin de algn aspecto
Caso de prueba (test case):
Un conjunto de entradas, condiciones de ejecucin y
resultados esperados desarrollados para un objetivo
particular
Defecto (defect, fault, bug):
Un defecto en el software como, por ejemplo, un proceso,
una definicin 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
tericamente correcto

IDEAS PARADGICAS 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 deteccin 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 depuracin (localizacin y correccin de defectos)
El anlisis de la estadstica de errores

ACTIVIDADES
Sirve para realizar predicciones de la fiabilidad del
software y para detectar las causas ms habituales de
error y por tanto mejorar los procesos de desarrollo

ENFOQUES DE DISEO DE
PRUEBAS
Existen dos enfoques principales para el diseo de

casos:
1.- El enfoque estructural o de caja blanca. Se centra en la
estructura interna del programa (analiza los caminos
de ejecucin).
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 nmero de otros casos necesarios para que la prueba sea

razonable. Esto implica que el caso ejecute el mximo nmero 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
especfico de entradas que prueba, as como de otros conjuntos
similares.

TCNICA: PARTICIPACIONES O CLASES DE

EQUIVALENCIA
Cada caso debe cubrir el mximo nmero de entradas
Debe tratarse el dominio de valores de entrada

dividido en un nmero 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. Identificacin 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 vlidos
b) De datos no vlidos o errneos
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 vlida y dos clases no vlidas
b) Si se especifica un nmero finito y consecutivo de
valores, se crear una clase vlida y dos no vlidas

c) Si se especifica una situacin del tipo debe ser o booleana

(por ejemplo, el primer carcter debe ser una letra), se
identifican una clase vlida (es una letra) y una no vlida
(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 vlida por cada valor y una no vlida
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: Aplicacin bancaria en la que el operador debe proporcionar un cdigo,

un nombre y una operacin

PRUEBAS DE CARGA, DE
RENDIMIENTO Y DE STRESS
De Carga (Load test): pruebas para determinar y validar la respuesta de la
aplicacin cuando es sometida a una carga de usuarios y/o transacciones que se
espera en el ambiente de produccin. Ejemplo: verificar la correcta respuesta de
la aplicacin 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 aplicacin a distintos volmenes 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 simultnea. Se comprar con el
rendimiento esperado.
De Estrs (stress test): pruebas para encontrar el volumen de datos o de tiempo
en que la aplicacin comienza a fallar o es incapaz de responder a las
peticiones. Son pruebas de carga o rendimiento, pero superando los lmites
esperados en el ambiente de produccin y/o determinados en las pruebas.
Ejemplo: encontrar la cantidad de usuarios simultneos, en que la aplicacin
deja de responder (cuelgue o time out) en forma correcta a todas las peticiones.

PRUEBAS UNITARIAS
Son pruebas dirigidas a probar clases aisladamente y

estn relacionadas con el cdigo y la responsabilidad

de cada clase y sus fragmentos de cdigo ms crticos.
Por ejemplo una clase que enve emails, debe ser capaz

de probarse aislada chequeando que sea capaz de

enviar emails, y asegurndonos 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 cdigo 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 integracin y aceptacin siguen siendo
necesarias.
Ayuda a definir los requerimientos y responsabilidades de cada mtodo 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 mtodo efectivo.
Permite hacer refactoring tempranamente en el cdigo. No es necesario todo
un ciclo de integracin para hacer refactoring en la aplicacin, basta con ver
como se comporta un caso de prueba para hacer refactoring unitario sobre la
clase que estamos probando en cuestin.
Permite incluso hacer pruebas de stress tempranamente en el cdigo. Por
ejemplo un mtodo que realice una consulta SQL que exceda los tiempos de
aceptacin es posible optimizarla antes de integrar con la aplicacin.
Permite encontrar errores o bugs tempranamente en el desarrollo. Y est
demostrado

PRUEBAS DE INTEGRACION
La prueba de integracin es una tcnica sistemtica para construir la estructura
del programa mientras al mismo tiempo, se lleva a cabo pruebas para detectar
errores asociados con la interaccin.
El objetivo es tomar los mdulos probados en unidad y estructurar un

programa que est de acuerdo con el que dicta el diseo. La integracin puede
ser descendente si se integran los mdulos desde el control o programa
principal, o bien, ascendente, si la verificacin del diseo empieza desde los
mdulos ms bajos y de all al principal. La seleccin de una estrategia de
integracin depende de las caractersticas 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

Sealar el enfoque, los recursos y el esquema de

actividades de prueba, as como los elementos a probar,
las caractersticas, las actividades de prueba, el
personal responsable y los riesgos asociados

ESTRUCTURA DEL ESTANDAR

IEEE-1008-1987
1. Identificador nico del documento
2. Introduccin y resumen de elementos y caractersticas a probar
3. Elementos software a probar
4. Caractersticas a probar
5. Caractersticas que no se probarn
6. Enfoque general de la prueba
7. Criterios de paso/fallo para cada elemento
8. Criterios de suspensin y requisitos de reanudacin
9. Documentos a entregar
10. Actividades de preparacin y ejecucin de pruebas
11. Necesidades de entorno
12. Responsabilidades en la organizacin y realizacin de las pruebas
13. Necesidades de personal y formacin
14. Esquema de tiempos
15. Riesgos asumidos por el plan y planes de contingencias
16. Aprobaciones y firmas con nombre y puesto desempeado