Universidad Mariano Gálvez de Guatemala

Centro Universitario de Quetzaltenango

Ingeniería De software
Ing. Durwin Ruiz

Estrategias de
Prueba del Software

1
Pruebas
Las pruebas consisten en un
conjunto de actividades que se
planean con anticipación y se
realizan de manera sistemática.

Un conjunto de pasos en que se

puedan incluir técnicas y métodos
específicos del diseño de casos de
prueba

Características

Deben ser realizadas basadas en revisiones formales

La prueba debe comenzar a nivel de componentes y

trabajar hacia afuera

Diferentes técnicas de prueba son apropiadas en

diferentes momentos

La prueba debe ser dirigida por el desarrollador del

software y en casos de proyectos grandes por un
grupo independiente de pruebas

Las pruebas y la depuración son actividades diferentes

2
Verificación y Validación

Verificación:
Conjunto de actividades que aseguran que el
software implemente correctamente una función
específica

Validación:
Conjunto de actividades que aseguran que el
software construido corresponde con los requisitos
del cliente

Consideraciones erróneas

El responsable del desarrollo no debería

participar en el proceso de prueba

El software debe ponerse a salvo de

extraños que lo prueben sin misericordia

Quienes aplican las pruebas sólo deben

participar en el proyecto cuando vayan a
darse los primeros pasos de esas
pruebas

El primer error que comete la gente es pensar que el

equipo de pruebas es responsable de asegurar la
calidad. Brian Marick

3
Estrategias de Prueba

Pasos de la prueba

4
Aspectos Estratégicos

Especificar los requisitos del producto de manera cuantificable mucho

antes de que empiecen las pruebas

Establecer explícitamente los objetivos de la prueba

Comprender cuales son los usuarios del software y desarrollar un perfil

para cada categoría de usuario

Desarrollar un plan de prueba que destaque la “prueba de ciclo rápido”

Construir un software robusto diseñado para probarse a si mismo

Usar revisiones técnicas formales y efectivas como filtro previo a la prueba

Realizar revisiones técnicas formales para evaluar la estrategia de prueba

los propios casos de prueba

Desarrollar un enfoque de mejora continua

Pruebas de Unidad

Errores comunes:
•Aplicación incorrecta o mal entendida
de la precedencia aritmética
•Operaciones de modo mezcladas
•Inicialización incorrecta
•Falta de precisión
•Representación simbólica

Casos de prueba:
•Comparaciones entre diferentes tipos
de datos
•Operadores lógicos
•Expectativa de igualdad
•Comparación incorrecta de variables
•Terminación inapropiada o
inexistente de bucles
•Variables de bucle modificadas de
manera inapropiada

5
 Pruebas de Integración
Es una técnica sistemática para construir la
arquitectura del software mientras, al mismo
tiempo, se aplican las pruebas para
descubrir errores asociados con la interfaz.

Objetivo:
Tomar componentes a los que se aplicó una
prueba y construir una estructura de
programa que determine el diseño

Enfoques:
BigBang
Incremental

Bing Bang
Es un enfoque no incremental que consiste en integrar todos los módulos y una vez
juntos probar el sistema esperando la explosión de errores que se puede generar. No es
una técnica recomendada pues dificulta el aislamiento de errores.

VENTAJAS
• Útil para la detección de errores cuando se encuentren todos los módulos ya en
construcción
• Aplicable antes de la entrega de proyecto para evaluar el trabajo de todo el sistema
con diversos escenarios.
• Se puede evaluar la interacción entre módulos para agilizar los procesos.
• Es apta para aplicar diversos escenarios para poder analizar el trabajo de todos los
módulos en diversas situaciones

DESVENTAJAS
• Dificultan la detección de posibles errores.
• Solo es posible aplicarla hasta que se esté avanzado el proyecto.
• Se tienen que trabajar con todos los módulos, no se puede hacer un análisis
individual.
• Si el proyecto es de corto plazo no se tiene mucho tiempo para la aplicación de la
prueba y realizar las correcciones

https://www.youtube.com/watch?v=W0-PFvqmxPY&feature=youtu.be&hd=1

6
Pruebas de Integración: Descendente
1. El módulo de control principal se utiliza como
controlador de prueba, y se sustituyen los
resguardos en todos los componentes M1
directamente subordinados al módulo de
control principal
M2 M3 M4
2. Dependiendo del enfoque de integración
seleccionado (profundidad-anchura) se van
reemplazando los resguardos subordinados, M5 M6 M7
uno por uno, con los componentes reales

3. Se aplican pruebas cada vez que se integre un M8

nuevo módulo

4. Al completar cada conjunto de pruebas se

reemplaza otro resguardo con el módulo real

5. Se aplica la prueba de regresión para

asegurarse de que no se han introducido
nuevos errores.

Pruebas de Integración: Ascendente

1. Se combinan los
módulos de bajo nivel
en grupos que realicen Mc
una subfunción
específica del software
Ma Mb

2. Se escribe un
controlador con el fin de C1 C2 C3
coordinar la entrada y
salida de los casos de
prueba

3. Se prueba el grupo

4. Se eliminan los
controladores y se
combinan los grupos
ascendiendo por la
estructura del programa

7
Pruebas de Regresión

Es una actividad que ayuda a asegurar que los

cambios no introduzcan comportamiento indeseable o
errores adicionales

Las pruebas de regresión deben incluir tres clases

diferentes de casos de prueba:

•Una muestra representativa de pruebas que ejercerán todas las

funciones del software

•Pruebas adicionales que se concentran en las funciones del

software que probablemente el cambio afectaría

•Pruebas que se concentran en los componentes del software

que han cambiado

Prueba de Humo (Smoke test)

Una prueba de humo o smoke test, es un testing rápido que se realiza sobre
aspectos funcionales no tanto para encontrar bugs sino para asegurarse que la
funcionalidad básica del software o de una parte del software se encuentre
estable y responda al comportamiento esperado.

El objetivo es verificar, con pruebas sencillas y que demanden poco tiempo, que
ciertos caminos de la aplicación funcionen correctamente.

Se minimiza el riesgo en
Integrar los elementos de
la integración
código en una construcción
Se mejora la calidad del
Diseñar pruebas para exponer
producto final
errores
Se simplifica el
La construcción se integra con
diagnóstico y la corrección
otras construcciones y se
de errores
prueba diariamente
El progreso es más fácil
de evaluar

8
Estrategias de prueba Para Software OO

Prueba de Unidad: Las pruebas de clase para el software orientado

a objetos se orienta mediante las operaciones que encapsula la clase
y en el comportamiento de estado de la clase

Prueba de Integración:

*Prueba basada en subprocesos: Integra al conjunto de clases

requerido para responder a una entrada o un evento del sistema.

*Prueba basada en el uso: Empieza la construcción del sistema con

la prueba de esas clases (independientes) que usan muy pocas
clases de servidor. Posteriormente se prueba la siguiente capa de
clases, llamadas clases dependientes, que usan las clases
independientes. Esta secuencia de capas de clases dependientes
continúa hasta que se construye todo el sistema.

Pruebas de Validación

En el nivel de validación o sistema desaparece la distinción entre software

convencional y orientado a objetos.

Se concentra en las acciones visibles para el usuario y la salida

La validación funciona cuando se satisface las expectativas razonables

del cliente. (Especificaciones del cliente)

Cumplimientos de: Desempeño, documentación y Facilidad de uso,

Pruebas Alfa y pruebas Beta: Las pruebas alfa se aplican por

usuarios finales en el lugar de trabajo del desarrollador

Pruebas Beta: Se aplican en el lugar de trabajo de los usuarios

finales. El desarrollador no está. Pa prueba es una aplicación en
un entorno que no controla el desarrollador.

9
Pruebas del Sistema

El software sólo es un elemento de un sistema más

grande. Se incorpora a otros elementos como
hardware, personas, información

Las pruebas no se realizan únicamente por ingenieros

de software

Entre éstas pruebas se involucran:

•Pruebas de recuperación.
•Pruebas de seguridad
•Pruebas de resistencia
•Pruebas de desempeño

Depuración

Ocurre como consecuencia de una prueba realizada con éxito.

Puede establecerse un caso de prueba. Se evalúan los resultados y se

encuentra una falta de correspondencia entre el desempeño esperado y
el real.

10
Depuración: Consideraciones para
la corrección
•El síntoma y la causa pueden estar separados geográficamente

•Es posible que el síntoma desaparezca temporalmente al corregir otro

error

•Es probable que el síntoma no lo cause algún error

•El síntoma podría deberse a un error humano difícil de localizar

•El síntoma podría deberse a problemas de tiempo y no de procesamiento

•Es difícil de reproducir

•El síntoma podría presentarse intermitentemente

•El síntoma se debe a causa distribuidas entre varias tareas

Fundamentos de las pruebas

•Facilidad de prueba

•Operatividad

•Observabilidad

•Controlabilidad

•Capacidad para descomponer

•Simplicidad

•Estabilidad

•Facilidad de comprensión

11
Características de las pruebas

•Una buena prueba tiene una elevada

probabilidad de encontrar errores

•Una buena prueba no es redundante

•Una buena prueba debe ser la mejor

de su clase

•Una buena prueba no debe ser ni muy

simple ni demasiado compleja

PRUEBAS DE CAJA BLANCA Y

CAJA NEGRA
Las pruebas de caja blanca del
software se basa en un examen
cercano al detalle procedimental.
Se pruebas las rutas lógicas del
software y la colaboración entre
componentes, al proporcionar
casos de prueba que ejerciten
conjuntos específicos de
condiciones, bucles o ambos.

Las pruebas de caja negra son

las que se aplican a la interfaz
del software. Una prueba de
este tipo examina algún aspecto
funcional de un sistema que
tienen poca relación con la
estructura lógica interna del
software.

12
Caja Blanca: Ruta básica

Notación gráfica del flujo

Caja Blanca: Complejidad Ciclomática

13
Caja Blanca: Complejidad Ciclomática

1. El número de regiones corresponde a la complejidad

ciclomática

2. La complejidad ciclomática V(G), de una gráfica de flujo,

G, se define como V(G) = E – N + 2

Con E= número de aristas, N= número de nodos de la

gráfica

3. La complejidad ciclomática, V(G) de una gráfica de flujo

G, también se define como

V(G) = P + 1
Donde p es el número de nodos predicado incluidos en la
gráfica de flujo G

Ejemplo: Realizar el algoritmo para calcular el mayor de tres

números

Inicio

Ingresar
datos A,B,C

Es Si Es Si
A>B A>C

No No
Es Si A es
C es mayor
B>C
mayor

B es
mayor Fin
No
C es
mayor

14
Caja Blanca: Complejidad Ciclomática
Procedimiento promedio:
Procedimiento para calcula el promedio de 100 o menos números que
caen entre valores límite; también calcula la suma y el total de números
válidos

INTERFACE RETURNS promedio, total.entrada, total.valido;

INTERFACE ACCEPTS valor, minimo, maximo;

TYPE valor{1:100} IS SCALAR ARRAY;

TYPE promedio, total.entrada, total.valido;
mínimo, maximo, suma IS SCALAR;
TYPE i IS INTEGER;
i=1;
total.entrada = total.valido=0; 2 3
1 suma = 0;
DO WHILE valor[i] <> -999 AND total.entrada < 100
6
4 incrementar total.entrada en 1;
IF valor[i] > = minimo AND valor [1] < = maximo
THEN incrementar total.valido en 1;
5 suma = suma + valor[1]
7 ELSE omitir
ENDIF
8 incrementar i en 1;
9 ENDDO
IF total.valido > 0 10
11 THEN promedio = suma / total.valido;
ELSE promedio = -999;
13 ENDIF 12
END PROMEDIO

Caja Blanca:
declaraciones
Complejidad
Ciclomática
Int size
Int=size

Public static void bubbleSort2 (Sequence S) {

Position prec, succ;
int n = S.size(); for
for (int i = 0; i < n; i++) {
prec = S.first();
for (int j=1; j < n - i; j++) { (i<n)
succ = S.after(prec); prec
if (valAtPos(prec) > valAtPos(succ))
S.swapElements(prec, succ);
prec = succ;
for
} (j<n)
}
} For (i>=n)
succ If prec>succ
prec succ S.swap Prec succ
Prec=succ

End routine

15
Caja Blanca: Complejidad Ciclomática

Thomas McCabe, establece en sus trabajos los

siguientes valores de referencia:

<= 10, métodos sencillos, sin mucho riesgo.

> 10, <= 20, métodos medianamente complejos,

con riesgo moderado.

> 20, <= 50, métodos complejos, con alto riesgo.

> 50, métodos inestables, de altísimo riesgo.

Matriz de Gráfica

Gráfica de flujo

1 Conectado al nodo

a 1 2 3 4 5
1 a
3 2
e d Nodo
3 d b
b
4 c f
5
4 5 g e
f
c
g
* Peso del enlace
2

16
Pruebas POO

Es importante también conocer la CC promedio de todas las clases en

nuestro proyecto. Para eso se calcula la CC de cada método y lo
dividimos por el número de métodos en las clases. Para eso también hay
una tabla:

1 - 2: Poca Complejidad
3 - 4: Complejidad Moderada
5 - 6: Complejidad Alta
6+: Complejidad muy alta

Herramienta para el cálculo de CC en php:

https://github.com/sebastianbergmann/phploc

N-Path
N-Path es una métrica de software, que por encima se parece un poco a la complejidad
ciclomática. Aunque ambos se relacionan un poco, en realidad nos sirven para medir
cosas completamente distintas. Con N-Path calculamos el número de caminos
distintos que puede tomar una rutina (a funciones o métodos).

Tenemos una función en javascript. Veamos su NPath – Las líneas de distintos colores
que indican cuales son los distintos caminos que puede tomar la rutina.

El valór máximo al que puede llegar el NPath = 2^(CC-1).

En este caso, esta rutina tiene una CC (complejidad ciclomática) de 4. El resultado sería
- NPath = 2^(4-1) = 2^3 = 8.

Al igual que con la complejidad ciclomática, también existe una tabla de referencia para
ver que tan compleja es una rutina.
1 - 16: Complejidad Baja.
17 - 128: Complejidad Moderada.
129 - 1024: Complejidad Alta.
1025+: Complejidad Muy Alta.

17
Pruebas de Condición

Método de diseño de casos de prueba que ejercita las condiciones lógicas

que se han utilizando en un módulo del programa. Una condición simple
es una variable booleana o una expresión relacional

E1 <operador relacional> E2

Una condición compuesta la integran dos o más condiciones simples,

Pruebas de Bucles

Bucles Simples
¿Cómo efectuar casos de prueba?

1) Omitir por completo el bucle

2) Sólo un paso por el bucle

3) Dos pasos por el bucle

4) m pasos por el bucle, donde m < n

5) n = 1, n, n + 1 pasos por el bucle

18
Bucles Anidados
¿Cómo efectuar casos de prueba?

1) Iniciar en el bucle más interno. Asignar a

todos los bucles los valores mínimos

2) Aplicar pruebas de bucle simple al más interno

mientras se mantienen los externos en los
valores mínimos del parámetro de iteración.
Agregar otras pruebas para los valores fuera
de rango o excluidos

3) Trabajar hacia fuera, conduciendo pruebas

para el siguiente bucle, pero manteniendo
todos los demás bucles externos en valores
mínimos y otros bucles anidados en valores
“típicos”

4) Seguir mientras no se hayan probado todos

los bucles

Bucles Concatenados

¿Cómo efectuar casos de prueba?

Se prueban considerándolos
como bloques simples.

Si no son independientes (una

salida de un bucle representa
la entrada de otro), se
recomienda el enfoque basado
en bucles anidados

19
 Bucles No Estructurados

Herramientas para
medir la CC
Jsmeter

Sonar:
https://www.adictosaltrabajo.com/tutoriale
s/sonar-total-quality/

http://pear.php.net/package/PHP_CodeSn
iffer/

http://msquaredtechnologies.com/m2rsm/

20
Bibliografía:

Ing. De Software
Roger Pressman
Editorial McGraw Hill

Lecturas Adicionales
http://formandobits.com/2013/07/los-siete-principios-de-las-pruebas-software/

http://formandobits.com/2013/12/cuales-son-las-normas-certificaciones-y-
herramientas-mas-demandadas/

http://formandobits.com/2013/09/por-que-spock-no-seria-un-buen-responsable-
de-calidad/

https://modelosdepruebasw.wordpress.com/

http://www.baufest.com/index.php/es/que-es-una-prueba-de-humo-o-smoke-test-
por-irina-fuentes-vinas-y-santiago-becquart

21