-------------------------------------------------------------------------------------------

UNIDAD 3. DISEÑO Y REALIZACIÓN DE PRUEBAS

© Luis Pilo Aceituno. lpilo@educarex.es
INTRODUCCIÓN
Las pruebas de software consisten en verificar y validar un producto
software antes de su puesta en marcha. La ejecución de pruebas consta de
varias etapas
● Planificación de pruebas
● Diseño y construcción de los casos de prueba.
● Definición de los procedimientos de prueba.
● Ejecución de las pruebas
● Registro de los resultados
● Registro de los errores.

TÉCNICAS DE DISEÑO DE CASOS DE CASOS DE PRUEBA.

Un caso de prueba es un conjunto de entradas, condiciones de ejecución y
resultados esperados desarrollados para conseguir una condición de prueba.
Es necesario definir la precondición y la postcondición, identificar unos
valores de entrada y conocer el comportamiento que debería tener el
sistema ante dichos valores de entrada.
Para el diseño de casos de prueba se utilizan dos técnicas
● Prueba de Caja Blanca
● Prueba de Caja Negra
Las pruebas de caja blanca se centran en validar la estructura interna del
programa (necesitan conocer los detalles procedimentales del código). Las
de caja negra validan los requisitos funcionales sin fijarse en el
funcionamiento interno (necesitan saber la funcionalidad que el código ha
de proporcionar).
A) Pruebas de caja blanca.

Se las conoce como pruebas estructuradas o de caja de cristal. Se basan en

el examen de los detalles procedimentales del código. Mediante esta
técnica se pueden obtener casos de prueba que:
● Garanticen que se ejecuten todos los caminos independientes de cada
módulo.
● Ejecuten todas las sentencias
● Ejecuten todas las decisiones lógicas en su parte verdadera y falsa
● Ejecute todos los bucles en sus límites
● Utilicen todas las estructuras de datos internas.
Una de las más utilizadas es la prueba del camino básico.

B) Pruebas de caja negra.

Se llevan a cabo sobre la interfaz del software, no hace falta conocer la
estructura interna del programa ni su funcionamiento. Se pretender obtener
casos de prueba que demuestren que las funciones del software son
operativas, es decir que las salidas que devuelven son las esperadas en
función de las entradas.
Estas pruebas también se llaman pruebas de comportamiento. El sistema se
considera como una caja negra cuyo comportamiento sólo se puede
determinar estudiando las entradas y salidas
Se intenta encontrar errores de las siguientes categorías
● Funcionalidad incorrecta o ausente.
● Errores de interfaz
● Errores de estructura de datos o de accesos a bases de datos externas
● Errores de rendimiento.
● Errores de inicialización y finalización.
Algunas de las técnicas de caja negra son:
1. Clases equivalentes.
2. Análisis de los valores límites
3. Métodos basados en grafos
4. Pruebas de comparación.
ESTRATEGIAS DE PRUEBA DEL SOFTWARE.

Puede verse en el contexto de una espiral. Avanzado desde el vértice

encontramos las siguientes pruebas
1. Pruebas de unidad: Se centran en la unidad más pequeña de software,
el módulo.
2. Pruebas de integración. Se toman los módulos probados y se
construye una estructura de programa que esté de acuerdo con lo que
dicta el diseño.
3. Pruebas de validación. Prueba el software en el entorno real de
trabajo con la intervención del usuario final. Se validan los requisitos
del análisis de requisitos del software y se compara con el sistema
que ha sido construido.
4. Prueba del sistema. Verifica que se alcanza la funcionalidad y
rendimiento total. El software se prueba como un todo.

1.-Prueba de Unidad

Se prueba cada unidad o módulo con objeto de eliminar errores en la

interfaz y en la lógica interna. Utiliza técnicas de caja negra o blanca según
interese.
Se realizan pruebas sobre.
● La interfaz del módulo.
● Las estructuras de datos locales para asegurarse que mantienen su
integridad
● Las condiciones límites para asegurar que funcionan correctamente
● Todos los caminos independientes de la estructura de control para
asegurarnos que todas las sentencias se ejecutan al menos una vez.
● Todos los caminos de manejo de errores
Algunas herramientas que se utilizan son: JUnit y PHPUnit
2.-Pruebas de Integración.

Se observa cómo interactúan los distintos módulos. Existen dos enfoques.

A. Integración no incremental o big bang. Se prueba cada módulo por
separado y luego se combinan todos de una vez y se prueba todo el
programa completo.
B. Integración incremental. El programa se va construyendo y probando
en pequeños segmentos. Se dan dos estrategias: Ascendente y
Descendete.En la integración ascendente la construcción y prueba
del programa empieza desde los módulos de los niveles más bajos de
la estructura del programa. En la descendente la integración
comienza en el módulo principal moviéndose hacia abajo.

3.-Pruebas de validación.
La validación se consigue cuando el software funciona de acuerdo con las
expectativas del cliente definidas en el documento de especificación de
requisitos del software.
Se llevan a cabo una serie de pruebas de caja negra que demuestran la
conformidad con los requisitos.
Las técnicas son:
A. Prueba Alfa​. Se llevan a cabo por el cliente en el lugar de desarrollo.
El cliente utiliza el software de forma natural bajo la observación del
desarrollador que irá registrando los errores y problemas de uso.
B. Prueba Beta.​ Se lleva a cabo por los usuarios finales del software en
su lugar de trabajo. El desarrollador no está presente. El usuario
registra todos los problemas que encuentra e informa al desarrollador
4.-Prueba del sistema.
Formado por un conjunto de pruebas. Son las siguientes.
A. Prueba de recuperación. Se fuerza el fallo del software y se verifica
que la recuperación se lleva a cabo de forma apropiada.
B. Prueba de seguridad. Verifica que el sistema está protegido contra
accesos ilegales.
C. Prueba de resistencia (Stress).Enfrenta al sistema con situaciones que
demandan gran cantidad de recursos, por ejemplo diseñando casos de
prueba que requieran el máximo de memoria

DOCUMENTACIÓN PARA LAS PRUEBAS.

El conjunto de documentos que puede producirse durante las pruebas es:

● Plan de pruebas:​ Describe el enfoque, los recursos y el calendario de
las actividades de prueba. Identifica los elementos a probar, las
características a probar, las tareas a realizar, el personal
responsable,..
● Especificación de las pruebas.​ cubren tres tipos de documentos.
o La especificación del diseño de pruebas: Se identifican los
requisitos, casos de prueba y se especifican los criterios de
pasa y no pasa
o La especificación de los casos de prueba: Documenta los
valores reales utilizados para la entrada
● Informes de prueba​ :Se definen 4 tipos de documentos
o Un informe que identifica los elementos que están siendo
probados
 o Un registro de las pruebas donde se registra que ocurre durante
la ejecución de las pruebas
o Un informe de incidentes de prueba
o Un informe de resumen de las actividades de prueba.
PRUEBAS DE CÓDIGO
Consiste en la ejecución del programa con el objetivo de encontrar errores.
Se parte de un conjunto de entradas y una serie de condiciones de ejecución
se observan y registran los resultados y se comparan con los resultados
esperados.
Para las pruebas de código las técnicas dependen del tipo de enfoque
● De caja blanca:​ Se centran en la estructura interna del
programa
● De caja negra​: Se centra en las funciones de entrada y salida
del programa

PRUEBAS DE CAMINO BÁSICO

Es una técnica de caja blanca que permite al diseñador obtener una medida
de la complejidad lógica de un diseño procedimental y usar esa medida
como guía para obtener un conjunto básico de caminos de ejecución.
Los casos de prueba obtenidos del conjunto básico garantizan que durante
la prueba se ejecuta por lo menos una vez cada sentencia del programa
Para la obtención de la medida de la complejidad lógica o complejidad
ciclomática emplearemos una representación del flujo de control
denominada grafo de flujo o grafo del programa.
Notación de grafo de flujo.
● SECUENCIA
Instrucción 1
Instrucción 2
-----------
Instrucción n
 ● CONDICIONAL
Si​ <condición> ​Entonces
< Instrucción>
Si no
<Instrucción>
Fin si

c ) ​HACER MIENTRAS

Mientras​ <condición> ​Hacer

<Instrucción>
Fin mientras

d) ​REPETIR HASTA
Repetir
<Instrucciones>
Hasta que​ <condición>
e) ​CONDICIONAL MÚLTIPLE
Según sea​ <variable> ​hacer
Case​ opcion 1
<Instrucciones>
​Case​ opcion 2
<Instrucciones>
​Case​ opcion 3
< Instrucciones >
​Otro caso
<Instrucciones>
Fin según

Cada círculo representa una o más sentencias sin bifurcaciones

Pasos para construir el diagrama de flujo
● Numeramos en el diagrama de flujo cada símbolo y los finales de
cada estructura aunque no tengan ningún símbolo.
(5)
(6) (7)
 (8)

Observar que aunque al final no hay ningún símbolo también se numera.

● Cada símbolo del grafo representa una o más sentencias.
- Un solo nodo puede corresponder con una secuencia de
símbolos del proceso y un rombo de decisión. El inicio y fin
del programa no se muestran
● Cuando encontramos condiciones compuestas se crea un nodo
aparte para cada condición.
- También podemos unir fin si o fin mientras con una secuencia
que les siga y ponerlas en el mismo nodo.
● Cuando me den el programa en pseudocódigo muestro en un
cuadrado las sentencias que se representan un nodo
- Al lado hay un número entre paréntesis que se corresponden
con un nodo en el grafo de flujo.
- Recordar que cada nodo puede corresponder a una o más
sentencias de proceso y un rombo de decisión.
COMPLEJIDAD CICLOMÁTICA
La complejidad ciclomática es una métrica del software que proporciona
una medida de la complejidad lógica del programa.
La complejidad ciclomática establece el número de caminos independientes
del conjunto de caminos de ejecución de un programa y por tanto el
número de casos de prueba que deben ejecutarse para asegurar que cada
sentencia se ejecuta al menos una vez.
La complejidad ciclomática puede calcularse de cualquier forma
1. V(G) = Número de regiones del grafo
2. V(G) = Aristas – Nodos +2
3. V(G) = Nodos predicados + 1
Ejemplo.
Para evaluar la complejidad de un programa , en el contexto de las pruebas
,seguimos la siguiente referencia
Complejidad ciclomática Evaluación del riesgo
Entre 1 y 10 Programas o métodos sencillos.
Poco riesgo
Entre 11 y 20 Programas o métodos más
complejos. Riesgo moderado
Entre 21 y 50 Programas o métodos complejos.
Alto riesgo
Mayor que 50 Programas o métodos no testealbes.
Muy alto riesgo

El valor de V(G) nos da el número de caminos independientes​. Un camino

independiente es cualquier camino del programa que introduce por lo
menos un nuevo conjunto de sentencias de proceso o una condición.
● En términos del diagrama de flujo un camino independiente
está constituido por lo menos por una arista que no haya sido
recorrida anteriormente a la definición del camino.
Ejemplo
Para el grafo 1 un conjunto de caminos independientes será
● Camino 1: 1 – 2 – 9
Podemos recorrer este camino para llegar del principio al fin del grafo sin
recorreré dos veces una arista.
● Camino 2: 1-2-3,4,5,-6-8-2-9
● Camino 3: 1-2-3,4,5-7-8-2-9
Ejercicio. Encontrar los caminos independientes del grafo 2
Obtención de los casos de prueba
El último paso de las pruebas de camino básico es construir los casos de
prueba que fuerzan la ejecución de cada camino.
Para comprobar cada camino debemos escoger los casos de prueba de
forma que las condiciones de los nodos predicados estén establecidos de la
forma adecuada. Podemos representar los casos de prueba como una tabla

Ejemplo. Casos de prueba del grafo 1.

Partición o clases de equivalencia

Es un método de prueba de caja negra que divide los valores de los campos
de entrada de un programa en clases de equivalencia.
Ejemplo. Supongamos un campo de entrada llamado ​nº de empleados
definido con una serie de condiciones: número de 3 tipos y el primero no
puede ser 0
Podemos definir una clase de equivalencia no válida: número empleado <
100 y otra válida número de empleado entre 100 y 999.
Para identificar las clases de equivalencia se examina cada condición de
entrada y se divide en 2 o más grupos.
1. Clases válidas
2. Clases no válidas
Se definen según estas directrices
● Si una condición de entrada especifica un rango se define una clase
valida y dos no válidas.
o La válida contempla valores del rango y las no válidas un
valor por encima del rango y otro por debajo.
● Si una condición de entrada requiere un valor especifico se define
una clase válida y dos no válidas
o La clase válida contempla el valor y las no válidas un valor
por encima y otro por debajo.
● Si una condición de entrada especifica un miembro de un conjunto se
define una clase válida y otra no válida.
o La válida está formada por los elementos del conjunto y la no
válida con un valor que no pertenece al conjunto.
● Si una condición de etrada es lógica se define una clase váida y otra
no válida.
o La válida cumple la condición y la no válida no.