El documento describe los fundamentos y objetivos de las pruebas de software. Las pruebas intentan encontrar errores sistemáticamente mediante la creación de casos de prueba que ejerciten diferentes condiciones y caminos lógicos del programa. Un buen caso de prueba tiene alta probabilidad de encontrar un error no detectado previamente y no debe ser redundante ni demasiado simple o complejo.

1. PRUEBA DEL
SOFTWARE
EL INGENIERO INTENTA CONSTRUIR
EL SOFTWARE PARTIENDO DE UN
CONCEPTO ABSTRACTO Y LLEGANDO A
UNA IMPLEMENTACIÓN
TANGIBLE

2. Objetivos de las pruebas
La prueba es el
proceso de
ejecución de un
programa
con la intención
de descubrir un
error.
Nuestro objetivo es diseñar pruebas que
sistemáticamente
saquen a la luz diferentes clases de errores,
haciéndolo
con la menor cantidad de tiempo y de esfuerzo.
Una prueba
tiene éxito si
descubre un
error no
detectado
hasta entonces.
Nos quitan la idea que, normalmente,
tenemos de que una prueba tiene éxito si no
descubre errores..
Un buen caso de
prueba es aquel
que tiene una
alta
probabilidad de
mostrar un error
no descubierto
hasta
entonces.

3. FUNDAMENTOS DE LAS
PRUEBAS
EL INGENIERO CREA UNA SERIE DE CASOS DE PRUEBA
QUE INTENTAN «DEMOLER» EL SOFTWARE CONSTRUIDO
Las pruebas son uno de los
pasos de la ingeniería del
software que se puede ver (por
lo menos, psicológicamente)
como destructivo en lugar de
constructivo.

4. Para ser más eficaces,Para ser más eficaces,
las pruebas deberíanlas pruebas deberían
ser realizadasser realizadas
por un equipopor un equipo
independiente.independiente.
Principios de lasPrincipios de las
pruebaspruebas
A todas las pruebas se lesA todas las pruebas se les
debería poder hacer undebería poder hacer un
seguimiento hasta cumplirseguimiento hasta cumplir
con los requisitos del clientecon los requisitos del cliente
Las pruebas deberíanLas pruebas deberían
planificarse mucho antesplanificarse mucho antes
de que empiecen.de que empiecen.
El principio de Pareto esEl principio de Pareto es
aplicable a la pruebaaplicable a la prueba
del software.del software.
Las pruebas deberíanLas pruebas deberían
empezar por «loempezar por «lo
pequeño» y progresarpequeño» y progresar
hacia «lo grandehacia «lo grande
No son posibles lasNo son posibles las
pruebas exhaustivas.pruebas exhaustivas.

5. Operatividad. «Cuanto mejor funcione,
más eficientemente
se puede probar.»
Controlabilidad. «Cuanto mejor podamos
controlar
el software, más se puede automatizar y
optimizar.»
Capacidad de descomposición. «Controlando el
ámbito de las pruebas, podemos aislar más
rápidamente
los problemas y llevar a cabo mejores pruebas de
regresión.»
Observabilidad. «Lo que ves es lo que
pruebas.»
Simplicidad. «Cuanto menos haya que
probar, más
rápidamente podremos probarlo.»
Estabilidad. «Cuanto menos cambios, menos
interrupciones
a las pruebas.»

6. Facilidad de
comprensión.
«Cuanta más
información
tengamos, más
inteligentes serán
las pruebas.»
Una buena prueba tiene una
alta probabilidad de
encontrar un error.
Una buena prueba no debe ser
redundante. El tiempo
y los recursos para las pruebas
son limitados.
El diseño se ha
entendido
perfectamente
Una buena prueba debería
ser «la mejor de la cosecha »
Las dependencias
entre los
componentes
internos,
externos
Una buena prueba no
debería ser ni demasiado
sencilla
ni demasiado compleja.
Se han comunicado
los cambias del
diseño.

7. LAS PRUEBAS
 comprueban los caminos
lógicos del software
proponiendo
 casos de prueba que
ejerciten conjuntos
específicos de condiciones
y/o bucles. Se puede
examinar el
 «estado del programa» en
varios puntos para
determinar si el estado real
coincide con el esperado o
mencionado.
DE LA CAJA BLANCA
DE LA CAJA NEGRA Se basa las pruebas sobre la interfaz
del software operatividad del sistema
Se basa Es el minucioso examen de
los detalles procedimentales (Código
Fuente).
Es diseñada después de tener el
código fuente

8. LA PRUEBA DEL CAMINO BÁSICO
Permite al diseñador
de casos de prueba
obtener una
medida de la
complejidad lógica
de un diseño
procedimental y
usar esa medida
como guía para la
definición de un
conjunto básico de
caminos de
ejecución
Construcciones estructurales en forma de grafo de flujo:
Según-sea
(Case)
Secuencia Si-si-no Mientras Repetir-hasta- Según Sea
(If) (While) (Untii) (Case)
Donde cada círculo representa una o más
sentencias, sin bifurcaciones, en LDP o
código fuente

9. Diagramas de Flujo
Diagrama de Flujo Representa la
estructura y control del programa
Grafo de Flujo
Representa el Flujo de control
lógico mediante notación
ilustrada
Cada circula es un Nodo y
corresponde a una secuencia
de cuadros de proceso y a un
rombo de decisión
camino 1: 1-11
camino 2: 1-2-3-4-5-10-1-11
camino 3: 1-2-3-6-8-9-10-1-11
camino 4: 1-2-3-6-7-9-10-1-11
Fíjese que cada nuevo camino
introduce una nueva
arista. Cual es el nuevo camino?

10. Complejidad ciclomática
La complejidad ciclomática
es una métrica del
software que proporciona
una medición cuantitativa
de la complejidad lógica
de un programa
Definición: El número de
caminos
independientes del
conjunto básico
de un programa y nos da
un límite superior para
el
número de pruebas que
se deben realizar para
asegurar
que se ejecuta cada
sentencia al menos
una vez
Un camino independiente es cualquier
camino del programa que introduce, por
lo menos, un nuevo conjunto de
sentencias de proceso o una nueva
condición

11. Determinamos la complejidad ciclomática del
grafo de flujo resultante.
Se determina aplicando uno de los
algoritmos descritos en la Sección
Se debe tener en cuenta que se puede
determinar V(G) sin desarrollar el grafo de
flujo, contando todas las sentencias
condicionales del LDP
V(G) = 6 regiones
V(G) = 17 aristas - 13 nodos +2 = 6
V(G) = 5 nodos predicado + 1 = 6

12. Determinamos un conjunto básico de caminos
linealmente independientes.
camino 1: 1-2-10-11-13
camino 2: 1-2-10-12-13
camino 3: 1-2-3-10-11-13
camino 4: 1 -2-3-4-5-8-9-2-...
camino 5: 1 -2-3-4-5-6-8-9-2-...
camino 6: 1-2-3-4-5-6-7-8-9-2- ...
Los puntos suspensivos (...) que siguen a
los
caminos 4,5 y 6 indican que cualquier
camino del
resto de la estructura de control es
aceptable