·
Encontrar gran cantidad de
errores en la aplicación realizada en el menor tiempo posible.
·
Características de las
pruebas
Un buen caso de prueba es
aquel que descubre errores no descubiertos.
·
Concejos
Llevar un seguimiento
desde el principio ósea desde la recolección de los requerimientos
Ya que desde allí se logra
saber para que servirá la aplicación.
·
Para ejecutar una prueba
debemos comenzar desde lo más simple hasta lo más complejo para así generar
grupos de módulos y lograr el sistema en general.
·
No son posibles las
pruebas exhaustivas debido que el tamaño
de una aplicación es relativamente grande.
COMPLEJIDAD DE UNA PRUEBA
Ø OPERATIVIDAD:
cuanto mejor funcione con mayor eficiencia se probara, que sean escasos los
errores que bloquean el sistema.
Ø OBSERVABILIDADA:
las entradas generan distintas salidas; Las variables y estados son visibles
durante la ejecución.
Ø CONTRABILIDAD:
cuanto mejor sea el manejo mejor se puede optimizar; Las variables y estados se pueden manipular.
Ø CAPACIDAD
DE DESCOMPOSICION: El sistema está construido por módulos independientes.
Ø SIMPLICIDAD:
Que con el mínimo de características cumpla con los requerimientos; Que debe
ser manejado por módulos (simplicidad estructural); Que el código debe estar
estandarizado.
Ø ESTABILIDDAD:
Los cambios en el software son infrecuentes; Si se realiza algún cambio es
controlado; Un cambio no afecta la prueba se recupera bien de un fallo.
Ø FACILIDAD
DE COMPRENSION:
-Diseño hecho correctamente
- Documentación accesible
- Documentación detallada
y exacta.
Para realizar un caso de
prueba se debe tener en cuenta el dominio de la aplicación
METODO DE LA CAJA NEGRA
Se refirieren
A las pruebas que se
llevan a cabo sobre la interfaz del
software. No toma mucho en cuenta la estructura lógica del sistema básicamente
halla errores en:
- Funciones incorrectas o
faltantes
- Errores de interface
- Estructura de datos
- Acceso a base de datos
- Errores en
comportamiento o desempeño
- Errores de iniciación y
de término
METODO DE LA CAJA BLANCA
-
Son los que se encargan
del dominio de la información y la estructura lógica del sistema.
-
Ponen a prueba cada
condición y bucle del sistema.
-
Son diseñados después de
que se tiene el código fuente.
-
Se debe garantizar el recorrido
en condiciones de sus dos vertientes V y F.
-
Que los bucles operen
hasta sus límites.
-
Que se ejerciten las
estructuras de datos.
PRUEBA
DEL CAMINO BASICO
-
Técnica de caja blanca.
-
Permite diseñar casos de
prueba obteniendo una complejidad lógica y así saber un camino de ejecución.
-
Garantizar que por lo
menos recorra una vez cada nodo << sentencias o bucles>>
COMPLEJIDAD CICLOMATICA
-
Medición cuantitativa de
la dificultad lógica del programa.
-
Genera el número de
pruebas necesarias para que se ejecuten todos las sentencias presentados en el
diagrama al menos una vez.
ALGORITMOS PARA HALLAR CAMINOS
1.
Según el número de
regiones presentes en el diagrama
2.
Ecuación V(G)= A – N+2
*V= complejidad ciclo matica
*G= grafo
*A= aristas
*N=nodos
3.
Ecuación 2 V(G)= P+1
*V= complejidad ciclo matica
*P=nodos predicado
*G= grafo
COMPLEJIDAD SISTEMATICA
-
Añade un nombre a las aristas y se genera una matriz en la
cual se mira la conexión entre nodos y aristas.
-
En la complejidad sistemática
se deben realizar las pruebas de :
*Condición: rectifican y miran operadores booleanos.
*Flujo de datos: que no se modifiquen variables
globales.
*Bucles: que se ejecuten adecuadamente los tipos de
bucle
- simple
- anidado
- concatenado
- no estructurado
PASOS A SEGUIR
1.
Según el diseño de la
aplicación se diagrama.
2.
Determinar la complejidad
ciclo matica del grafo
3.
Determinar las rutas de
cada camino.
4.
Preparar casos de prueba
que fuercen la ejecución de cada camino
No hay comentarios:
Publicar un comentario