TRABAJO DE PRINCIPIOS

Universidad Nacional Experimental
De Los Llanos Occidentales
“Ezequiel Zamora”
UNELLEZ.
Bachilleres:
Leydy Herrera.
C.I 24.111.594.
Prof: José V Rojas.
Ing. En Informática.
Barinas, Julio del 2013.
PRUEBAS DEL SOFTWARE:
¿Que son Pruebas?
Es una actividad en la cual un sistema o uno de sus componentes se
ejecutan, en circunstancias previamente especificadas los resultados se
observan y registran y se realiza una evaluación de algún aspecto.
¿Qué es 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.
¿Qué es Validación?
Es 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.
¿Qué es un Caso de prueba?
Es un conjunto de entradas, condiciones de ejecución y resultados
esperados desarrollados para un objetivo particular.
¿Qué es un Defecto?
Es un defecto en el software como por ejemplo, un proceso
una
definición de datos o un paso de procesamiento incorrectos en un programa.
¿Qué es un Fallo?
Es la incapacidad de un sistema o de alguno de sus componentes
para realizar las funciones requeridas dentro de los requisitos de rendimiento
especificados.
¿Qué es un Error?
Tiene varias acepciones:
La diferencia entre un valor calculado, observado o medio y el valor
verdadero, especificado o teóricamente correcto.
¿Qué es una Prueba del software?
Es la ejecución de un programa con la intención de descubrir un error
técnica experimental para la búsqueda de errores en los programas
Relación entre Efecto Error Y Fallo:
Objetivos de las Pruebas:
La prueba es el proceso de ejecución de un programa con la intención
de descubrir un error.
Un buen caso de prueba es aquel que tiene una alta probabilidad de
mostrar un error no descubierto hasta entonces.
Una prueba tiene éxito si descubre un error no detectado hasta
entonces.
Principios de las Pruebas:

A todas las pruebas se les debería poder hacer un seguimiento hasta
los requisitos del cliente.

Las pruebas deberían planificarse mucho antes de que empiecen.

Las pruebas deberían empezar por “lo pequeño” y progresar hacia “lo
grande”.

No son posibles las pruebas exhaustivas.

Para ser más eficaces (pruebas con la más alta probabilidad de
encontrar errores), las pruebas deberían ser realizadas por un equipo
independiente.

Se debe inspeccionar a conciencia el resultado de cada prueba para,
así, poder descubrir posibles síntomas de defectos.

Cada caso de prueba debe definir el resultado de salida esperado.

Al generar casos de prueba, se deben incluir tanto datos de entrada
válidos y esperados como no válidos e inesperados.

Las pruebas deben centrarse en dos objetivos (es habitual olvidar el
segundo):

Probar si el software no hace lo que debe hacer

Probar si el software hace lo que no debe hacer, es decir si provoca
efectos secundarios

Se deben evitar los casos desechables.

No deben hacerse planes de prueba suponiendo que, prácticamente,
no hay defectos en los programas, y dedicando pocos recursos a las
pruebas.

La experiencia indica que donde hay un defecto hay otros.

Las pruebas son una tarea creativa como el desarrollo de software.
Facilidad de Pruebas:
 Operatividad.
 Observabilidad.
 Controlabilidad.
 Capacidad de descomposición.
 Simplicidad.
 Estabilidad.
 Facilidad de comprensión.
Proceso de Prueba:
 La depuración (localización y corrección de defectos).
 El análisis de la estadística de errores.
Ciclo Completo de las Pruebas:
Enfoque de Diseño de Casos de Prueba:
Enfoque estructural o de caja blanca.
Enfoque funcional o de caja negra.
Enfoque Aleatorio.
Pruebas de Caja Blanca:

Garanticen que se ejercita por lo menos una vez todos los caminos
independientes de cada módulo.

Ejerciten todas las decisiones lógicas en sus vertientes verdadera y
falsa.

Ejecuten todos los bucles en sus límites y con sus límites
operacionales.

Ejerciten las estructuras internas de datos para asegurar su validez.
Criterios de Cobertura Lógica:
 Cobertura de Sentencias.
 Cobertura de decisiones.
 Cobertura de Condiciones.
 Criterios de decisión/Condición.
 Criterio de Condición Múltiple.
 Criterio de Cobertura de Caminos (impracticable)
Variantes de Prueba de Caja Blanca:
a) Prueba del Camino Básico.
b) Prueba de Condición.
c) Prueba de Flujo de Datos.
d) Prueba de Bucles.
Prueba de Condición:
Ventajas:
•
La cobertura de la prueba de una condición es sencilla.
La cobertura de la prueba de las condiciones de un programa da una
orientación para generar pruebas adicionales del programa.
Estrategias de prueba de Condiciones:
 Prueba de Ramificaciones.
 Prueba de Dominio.
E1<operador-relacional>E2
Se necesitan 2n (n>0) pruebas como máximo
Para encontrar errores.
Prueba de Flujo de Datos:
Esta técnica selecciona caminos de un programa de acuerdo a las
definiciones y uso de las variables.
El enfoque de prueba de flujo de datos es efectivo para la protección
contra errores.
Prueba de bucles:
Tipos de pruebas:
 Bucles simples.
 Bucles Anidados.
 Bucles Concatenados.
 Bucles no Estructurados.
Pruebas de Caja Negra:
Intenta encontrar errores de las siguientes categorías:
Funciones Incorrectas o Ausentes.
Errores de Interfaz.
Errores en estructuras de datos o acceso a bases de datos externas.
Errores de rendimiento.
Errores de inicialización y terminación.
Variantes de pruebas de caja negra:
a) Métodos de prueba basados en grafos.
b) Partición Equivalente.
c) Análisis de valores límite.
d) Prueba de Comparación.
e) Conjetura de Errores.
Prueba de Comparación:
Se desarrollan versiones independientes de una aplicación con las
mismas especificaciones.
Probar todas las versiones con los mismos datos de prueba.
Luego se ejecutan las versiones en paralelo y se hace una
comparación en tiempo real de los resultados.
Conjetura de Errores:

Enumerar una lista de equivocaciones que pueden cometer los
desarrolladores.

Generar casos de prueba en base a dicha lista.

La generación de casos se obtiene en base a la intuición o la
experiencia.
Pruebas Aleatorias:
Se simula los posibles datos de entrada en la secuencia y frecuencia
que pueden aparecer en la práctica.
Si el proceso de generación se ha realizado correctamente, se crearán
eventualmente todas las posibles entradas del programa en todas las
posibles combinaciones y permutaciones.
Baja probabilidad de encontrar errores.
Recomendaciones para unas Pruebas Exitosas:

Cada caso de prueba debe definir el resultado de salida esperado que
se comparará con el realmente obtenido.

El programador debe evitar probar sus propios programas, ya que
desea (consciente o inconscientemente) demostrar que funcionan sin
problemas.

Además, es normal que las situaciones que olvidó considerar al crear
el programa queden de nuevo olvidados al crear los casos de prueba.

Se debe inspeccionar a conciencia el resultado de cada prueba, así
poder descubrir posibles síntomas de defectos.

Al generar casos de prueba, se deben incluir tanto datos de entrada
válidos y esperados como no válidos e inesperados.
Las pruebas deben centrarse en dos objetivos (es habitual olvidar el
segundo):

Se deben evitar los casos desechables, es decir, los no documentados
ni diseñados con cuidado.

No deben hacerse planes de prueba suponiendo que, prácticamente,
no hay defectos en los programas y, por lo tanto, dedicando pocos recursos
a las pruebas pero siempre hay defectos.

La experiencia parece indicar que donde hay un defecto hay otros, es
decir, la probabilidad de descubrir nuevos defectos en una parte del software
es proporcional al número de defectos ya descubierto.

Las pruebas son una tarea tanto o más creativa que el desarrollo de
software. Siempre se han considerado las pruebas como una tarea
destructiva y rutinaria.

Es interesante planificar y diseñar las pruebas para poder detectar el
máximo número y variedad de defectos con el mínimo consumo de tiempo y
esfuerzo.
Referencias Bibliográficas:
www.sistemas.edu.bo/.../tema6%20Pruebas%20del%20software.ppt
http://alarcos.inf-cr.uclm.es/doc/ISOFTWAREI/Tema09.pdf
http://lsi.ugr.es/~ig1/docis/pruso.pdf
http://materias.fi.uba.ar/7548/PruebasSoftware.pdf