UT3_Diseño y realización de pruebas

5/17/2018 UT3_Diseño y realización de pruebas - slidepdf.com

http://slidepdf.com/reader/full/ut3diseno-y-realizacion-de-pruebas 1/17

TEMA 3. Diseño y realización de Pruebas

ÍNDICE

1 INTRODUCCIÓN 1

2 PRINCIPIOS BÁSICOS DE LAS PRUEBAS 2

2.1 NO ES UNA ACTIVIDAD SECUNDARIA 2

2.2 OBJETIVOS DE LAS PRUEBAS 2

2.3 PRINCIPIOS DE LAS PRUEBAS 2

3 DISEÑO DE CASOS DE PRUEBAS 2

3.1 PRUEBAS DE UNIDADES 3

3.1.1 PRUEBAS DE CAJA BLANCA Ó TRANSPARENTES 3

3.1.2 PRUEBA DEL CAMINO BÁSICO 3

3.1.2.1 COMPLEJIDAD CICLOMÁTICA DE MCCABE 5

3.1.2.2 PASOS DEL DISEÑO DE PRUEBAS MEDIANTE EL CAMINO BÁSICO 6

3.1.3 PRUEBA DE BUCLES 7

3.1.4 EJEMPLOS DE PRUEBAS DE CAJA BLANCA 8

3.1.5 PRUEBAS DE CAJA NEGRA 10

3.1.5.1 CLASES DE EQUIVALENCIA 11

3.1.5.2 A NÁLISIS DE VALORES LÍMITE 12

3.1.5.3 DOCUMENTACIÓN 13

3.2 PRUEBAS DE INTEGRACIÓN 13

3.2.1 PRUEBAS DE INTEGRACIÓN 13

3.2.2 PRUEBAS DE SISTEMA 13

3.2.3 PRUEBAS DE CARGA 13

3.3 PRUEBAS DE ACEPTACIÓN 14

3.3.1 PRUEBAS ALFA 14

3.3.2 PRUEBAS BETA 14

4 PLANIFICACIÓN DE LAS PRUEBAS 14

4.1 PLAN DE PRUEBAS EN MÉTRICA V3 15




Pág 1 Curso 2011 - 2012

03

Diseño y realización de pruebasDiseño y realización de pruebasDiseño y realización de pruebasDiseño y realización de pruebas

1 Introducción

Una de las fases del ciclo de vida del software antes de entregar un programa para su explotación es la fase de prue-

bas.

Las pruebas del sistema ayudan a garantizar la calidad del mismo. Una vez desarrollado el sistema hay que probar si

este funciona correctamente y si cumple las especificaciones indicadas por el cliente, por ello, los objetivos de las pruebas son

los siguientes:

→ Comprobar que el sistema hace lo que tiene que hacer

→ El sistema realiza sus funciones correctamente

→ Lo hace de una manera eficiente

Para la realización de las pruebas se somete al sistema a una serie de Planes de Prueba con el fin de encontrar todos

los errores del sistema, introducir mejoras en el mismo, modificar elementos, etcétera.

Hay que tener en cuenta que:

El objetivo principal de los casos de prueba es encontrar el número máximo de errores en el sistema, la ausen-

cia de errores es prácticamente imposible.

En resumen, las pruebas ayudan a comprobar si el sistema es:

→ Correcto: el sistema hace lo que tiene que hacer.

→ Eficiente: el sistema hace lo que debe consumiendo el menor número de recursos y consiguiendo tiempos de respuesta lo

más cortos posible.

→ Eficaz: el sistema debe resolver todos los casos que sea posible de la mejor forma

Para comprobar esto se emplearán dos técnicas:




Pág 2 Curso 2011 - 2012

→ Técnicas de Verificación de sistema, se usan para comprobar si el sistema está bien implementado, es decir, si ¿el siste-

ma hace lo que debe de hacer?.

→ Técnicas de Validación del sistema, se usan para comprobar que el sistema realiza lo que el cliente quiere, es decir, si ¿El

sistema hace lo que el cliente quiere?.

2 Principios básicos de las pruebas

2.1 No es una actividad secundaria

• No es una actividad secundaria:

o 30-40% del esfuerzo de desarrollo

o En aplicaciones críticas (p.ej. control de vuelo, reactores nucleares),

¡de 3 a 5 veces más que el resto de pasos juntos de la ingeniería del software!

El coste aproximado de los errores del software (bugs) para la economía americana es el equivalente al 0,6% de su

PIB, unos 60.000 millones de dólares

⇒ ¡Evitar bichos puede ser un gran negocio!

2.2 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 descubrir un error no encontrado hasta entonces

• Una prueba tiene éxito si descubre un error no detectado hasta entonces.

• No sólo se prueba el código: tb. documentación y ayuda

2.3 Principios de las pruebas

A continuación se enumerarán unos principios fundamentales de la fase de pruebas, que es necesario tener en cuenta:

1. A todas las pruebas se les debería poder hacer un seguimiento hasta los requisitos de los clientes (trazabilidad ).

2. Las pruebas deberían planificarse antes de que empiecen.

3. El principio de Pareto es aplicable a la prueba del software (“donde hay un defecto, hay otros”).

4. Las pruebas deberían empezar por “lo pequeño” y progresar hacia “lo grande”.

5. No son posibles las pruebas exhaustivas.

6. Para ser más efectivas, las pruebas deberían ser conducidas por un equipo independiente.

7. Se deben evitar los casos de prueba no documentados ni diseñados con cuidado.

8. No deben realizarse planes de prueba suponiendo que prácticamente no hay defectos en los programas y, por tanto, dedi-

cando pocos recursos a las pruebas.

9. Al generar casos de prueba se deben incluir tanto datos de entrada válidos y esperados como no válidos e inesperados.

3 Diseño de casos de Pruebas

Dado que la prueba exhaustiva del sistema es imposible, se utilizarán técnicas que ayuden a la detección del máximo

número de errores en el sistema.

Se clasificarán los casos de pruebas atendiendo varios criterios:




Pág 3 Curso 2011 - 2012

→ Pruebas de Unidades

a. Pruebas de Caja Negra

b. Pruebas de Caja Blanca

→ Pruebas de Integración

c. Pruebas de Integración

d. Pruebas de Subsistema y Sistema

e. Pruebas de Carga

→ Pruebas de Aceptación

3.1 Pruebas de Unidades

3.1.1 Pruebas de Caja Blanca ó Transparentes

Son aquellas pruebas que permiten examinar la estructura interna del programa. Es decir, se fijan en el código, si

los bucles, las sentencias condicionales, los puntos de toma de decisión, etcétera funcionan correctamente, y emiten resultados

para todos los caminos que se puedan seguir.

Este tipo de pruebas serán realizadas solamente por los programadores o por personas que conozcan el código, los da-

tos y los flujos.

→ Las pruebas se basan en el criterio de cobertura, que será una medida porcentual de ¿cuánto código se ha cubierto?

Las pruebas de caja blanca intentan garantizar que:• Se ejecutan al menos una vez todos los caminos independientes de cada módulo• Se utilizan las decisiones en su parte verdadera y en su parte falsa• Se ejecuten todos los bucles en sus límites• Se utilizan todas las estructuras de datos internas

3.1.2 Prueba del camino básico

Es una técnica de caja blanca que propuso inicialmente Tom MacCabe.

• Permite que el diseñador de casos de prueba obtenga una medida de la complejidad lógica de un diseño procedimental

y que use esta medida como guía para definir un conjunto básico de rutas de ejecución

• Los casos de prueba deben garantizar que se ejecuta cada instrucción del programa por lo menos una vez durante la

prueba

• Conceptos

– Complejidad ciclomática

– Conjunto de caminos independientes

– Casos de prueba

ENTRADA SALIDA

Caja Blanca




Pág 4 Curso 2011 - 2012

Para la realización de estas pruebas es conveniente construir un diagrama de flujo de control y sobre él escoger una serie de

caminos lógicos que se van a ejecutar usando distintos datos para comprobar el correcto funcionamiento del código.

Los diagramas de flujo se pueden representar como sigue:

A continuación se muestra un ejemplo basado en un diagrama de flujo que representa la estructura de control del programa.

Figura “Ciclos”

En el grafo de flujo

• Cada nodo representa una o más sentencias procedimentales

XXXX

XXXX

XXXX

SSSSeeeecuenciacuenciacuenciacuencia CondCondCondCondiiiición IFción IFción IFción IF Bucle HACER HASTABucle HACER HASTABucle HACER HASTABucle HACER HASTA Bucle MIEBucle MIEBucle MIEBucle MIENNNNTRASTRASTRASTRAS




Pág 5 Curso 2011 - 2012

• Un solo nodo puede corresponder a una secuencia de pasos del proceso y a una decisión

• Las flechas (aristas) representan el flujo de control

Cualquier representación del diseño procedimental se puede traducir a un grafo de flujo.

Si en el diseño procedimental se utilizan condiciones compuestas, la generación del grafo de flujo tiene que descom-

poner las condiciones compuestas en condiciones sencillas, tal y como muestra la figura siguiente.

3.1.2.1 Complejidad Ciclomática de McCabe

El número de caminos que se pueden seguir para la realización de las pruebas es infinito, debido a esto y para acotar

el número de caminos de prueba aparece el término COMPLEJIDAD CICLOMÁTICA.

Complejidad Ciclomática para indicar el número de caminos independientes que existen en un grafo. PROPORCIONA

EL LÍMITE SUPERIO DEL NÚMERO NECESARIO DE CASOS DE PRUEBA PARA GARANTIZAR QUE CDADA

INSTRUCCIÓN DEL PRORAMA SE HAYA EJECUTADO POR LOS MENOS UNA VEZ

La complejidad ciclomática, representada por V(G) se puede calcular de tres formas distintas:

1. V(G) = a –n +2 , donde

a: número de arcos o aristas del grafo

n: número de nodos

2. V(G) = r, donde R: el número de regiones cerradas del grafo

3. V(G) = c + 1

C: número de nodos de condición o de orden

Los caminos independientes del grafo son los que deben utilizarse como casos de prueba.

Según la figura anterior Figura “Ciclos”

o La complejidad ciclomática sería:

• Como el grafo tiene cuatro regiones, V(G) = 4

• Como el grafo tiene 11 aristas y 9 nodos, V(G) = 11 - 9 - 2 = 4

• Como el grafo tiene 3 nodos predicado, V(G) = 3 + 1 = 4




Pág 6 Curso 2011 - 2012

A partir del valor de la complejidad ciclomática obtenemos el número de caminos independientes, que nos dan un va-

lor límite para el número de pruebas que tenemos que diseñar.

o En el ejemplo, el número de caminos independientes es 4, y los caminos independientes son:

• 1-11

• 1-2-3-4-5-10-1-11

• 1-2-3-6-7-9-10-1-11

• 1-2-3-6-8-9-10-1-11

3.1.2.2 Pasos del diseño de pruebas mediante el camino básico

1. Dibujar el grafo de flujo

Tomando como base el diseño o el propio código del programa dibujar el grafo de flujo.

2. Determinar la complejidad ciclomática del grafo

3. Determinar un conjunto de caminos linealmente independientes

4. Preparar los casos de prueba

Para cada uno de los caminos del grafo anterior, preparar los casos de prueba.

Ejemplo:

Se trata de identificar un camino básico e ir haciendo variaciones sobre este, por ejemplo:

1 – 2 – 11

1 – 2 – 3 – 4 – 10 – 2




Pág 7 Curso 2011 - 2012

1 – 2 – 3 – 5 – 10 – 2

1 – 2 – 3 – 5 – 6 – 7 - 9

1 – 2 – 3 – 5 – 6 – 8 - 9

3.1.3 Prueba de bucles

Los bucles son la piedra angular de la inmensa mayoría de los algoritmos implementados en software, por lo que te-

nemos que prestarles una atención especial a la hora de realizar la prueba del software.

La prueba de bucles es una técnica de prueba de caja blanca que se centra en la validez de las construcciones de los

bucles.

Se pueden definir cuatro tipos de bucles diferentes:

o Simples

o Concatenados

o Anidados

o No estructurados

→ Bucles simples. Para este tipo de bucles se deben llevar a cabo los siguientes casos de prueba - considerando que n, es el

número máximo de pasos permitidos por el bucle-:

a. Pasar por alto totalmente el bucle

b. Pasar una sola vez por el buclec. Pasar dos veces por el bucle

d. Hacer “m” pasos por el bucle con m<n

e. Hacer n-1 , n y n+1 pasos por el bucle

→ Bucles anidados. Cuando existen bucles anidados se llevan a cabo los siguientes caminos de prueba:

a. Comenzar por el bucle más interior. Establecer los demás bucles en sus valores mínimos.

b. Llevar a cabo las pruebas de bucles simples para el bucle más interior, mientras se mantienen los parámetros

de iteración ( por ejemplo, contadores de bucles) de los bucles externos en sus valores mínimos. Añadir otras

pruebas para valores de fuera de rango o excluidos

c. Progresar hacia fuera, llevando a cabo pruebas para el siguiente bucle, pero manteniendo todos los bucles ex-

ternos en sus valores mínimos y los demás bucles anidados en sus valores “típicos”.




Pág 8 Curso 2011 - 2012

d. Continuar hasta que se hayan probado todos los bucles.

→ Bucles concatenados.

Probar los bucles concatenados mediante las técnicas de prueba para bucles simples, considerándolos como bucles in-

dependientes

→ Bucles no estructurados

Siempre que sea posible, esta clase de bucles debe diseñarse nuevamente para reflejar el uso de las construcciones de

programación estructurada

3.1.4 Ejemplos de pruebas de caja blanca

Ejemplo 1:

Ejemplo 2




Pág 9 Curso 2011 - 2012




Pág 10 Curso 2011 - 2012

V(G) = 6 regiones

V(G) = 17 aristas – 13 nodos + 2

V(G) = 5 nodos predicado + 1

Rutás básicas independientes: ….

3.1.5 Pruebas de Caja Negra

Las pruebas de Caja Negra son aquellas que comprueban el funcionamiento de un componente software a través de su

interfaz, es decir ,de sus entradas y salidas, sin entrar a ver su funcionamiento interno.

Estas pruebas se pueden ver desde un enfoque funcional del sistema, ya que se diseñan los casos de prueba y los da-

tos de prueba a partir de las especificaciones funcionales del sistema, se busca probar completamente:

→ Las funciones realizadas por el sistema→ El cumplimiento de los objetivos del sistema

ENTRADA SALIDA

Caja Blanca

FUNCIONES




Pág 11 Curso 2011 - 2012

→ Las reacciones del sistema ante los estímulos exteriores

Para comprobar el correcto funcionamiento del sistema se:

Introducen valores límites

Se introducen datos erróneos, valores susceptibles a crear problemas.

Se introducen datos equivalentes

Estas pruebas ayudan a encontrar errores en las siguientes categorías:

Funciones incorrectas o ausentes

Errores de interfaz

Errores en estructuras de datos o en acceso a base de datos externas

Errores de rendimiento

Errores de inicialización y de terminación

3.1.5.1 Clases de Equivalencia

El problema que tienen las pruebas de Caja Negra es que los rangos de datos son muy amplios y sería muy costoso

probar todos los valores de un rango, para evitar realizar esto se agrupan los datos en lo que llamamos CLASES DE EQUI-

VALENCIA.

Esta técnica trata cada parámetro como un modelo algebraico donde unos datos son equivalentes a otros. Si logramos

partir un rango excesivamente amplio de posibles valores reales a un conjunto reducido de clases de equivalencia, entonces es

suficiente probar un caso de cada clase, pues los demás datos de la misma clase son equivalentes.Para crear las clases de equivalencia existe una norma que es la que sigue:

si un parámetro de entrada debe estar comprendido en un cierto rango, aparecen 3 clases de equivalencia: por de-

bajo, en el propio rango y por encima del rango.

si una entrada requiere un valor concreto, aparecen 3 clases de equivalencia: por debajo, en el rango y por encima

del rango.

si una entrada requiere un valor de entre los de un conjunto, aparecen 2 clases de equivalencia: en el conjunto o

fuera de él.

si una entrada es booleana, hay 2 clases: si o no.

los mismos criterios se aplican a las salidas esperadas: hay que intentar generar resultados en todas y cada una de

las clases.

Por ejemplo: Si la especificación del problema es la siguiente:

Código: número de 3 dígitos que no empieza ni por 0, ni por 1.

Identificador: 9 caracteres.

Ordenes posibles: "cheque", "depósito", "pago factura", "retirada de fondos"

Edad: Entre 18 y 65




Pág 12 Curso 2011 - 2012

Condición de Entrada Clases de equivalencia válidas Clases de equivalencia inválidas

Código (1) 200 < codigo <999 (2) Codigo < 200

(3) Codigo > 999

(4) No es un número

Identificador 9 caracteres Menos de 9 caracteres

Mas de 9 caracteres

Orden (1) “cheque”

(2) “depósito”

(3) “pago factura”

(4) “retirada de fondos”

(5) Ninguna orden válida

Edad (1) 18 < = edad <=65 (2) edad < 18

(3) edad > 65

(4) No es número

3.1.5.2

Análisis de valores límite

Esta técnica es complementaria a las Clases de Equivalencia y explora las condiciones límites de un programa.

Es más probable que una función falle cuando los valore s de entrada a la misma se sitúan en el límite de valores del

rango de la función.

Por ejemplo, si una variable toma valores entre 20 y 500 se deben escoger los siguientes casos de prueba:

19 Justo debajo del rango

20 El límite inferior del rango

21 Dentro del rango

Un valor cualquiera de la mitad del rango

499 Valor debajo del límite superior

500 El límite superior

501 Justo por encima del rango superior

Si los recursos lo permiten, se podrían añadir las siguiente pruebas adicionales:

Valores negativos

Al menos un valor positivo menor que 19




Pág 13 Curso 2011 - 2012

Algún valor muy superior a 500

3.1.5.3 Documentación

Deberemos documentar las pruebas realizadas. SE muestra un posible esquema de documento

Núm. Prueba Descr. Prueba Datos entrada Resultado esperado Resultado obtenido Comentarios

3.2 Pruebas de Integración

3.2.1 Pruebas de integración

Son aquellas pruebas que comprueban que los componentes probados individualmente funcionan correctamente traba-

jando juntos, es decir, integrados.

Estas pruebas se realizan de forma gradual y se pueden realizar de dos formas:

1. Incremental (ascendente o descendente)

Se combina el siguiente módulo que se quiere probar con el conjunto de módulos que ya están probados.

2. No incremental

Se prueba cada módulo por separado, y luego se integran todos a la vez y se prueba el sistema completo.

3.2.2 Pruebas de Sistema

Estas pruebas consideran el producto final al completo, es decir, al sistema final, comprobando que módulos probados

individualmente funcionan correctamente cuando trabajan juntos, y que los fallos en el sistema pueden ser debidos a una erró-

nea comunicación entre subsistemas.

3.2.3 Pruebas de carga

Estas pruebas se realizan utilizando datos reales de la ejecución del programa con el fin de comprobar el rendimiento

y la integridad de la aplicación.




Pág 14 Curso 2011 - 2012

3.3 Pruebas de Aceptación

Estas pruebas las realiza el cliente. Son básicamente pruebas funcionales, sobre el sistema completo, y buscan una co-

bertura de la especificación de requisitos y del manual del usuario. Estas pruebas no se realizan durante el desarrollo, debido a

que el programa en desarrollo no es presentable al cliente, sino una vez pasadas todas las pruebas de integración por parte del

desarrollador.Los más expertos pueden demostrar que después de que un sistema supere todas las pruebas realizadas por el desarro-

llador, todavía aparecen una seria de errores que sólo aparecen cuando el cliente utiliza el sistema.

Aquí se presenta un grave problema, el desarrollador una vez finalizada totalmente la aplicación se encuentra con una

serie de errores que debe subsanar, para evitar poner en marcha una aplicación que no es correcta y que una vez distribuida

resolver los errores es más complejo se practican dos tipos de pruebas, las llamadas Pruebas Alfa y Pruebas Beta.

Este tipo de pruebas, alfa y beta, son habituales en productos que se van a vender a muchos clientes. Algunos de los

potenciales compradores se prestan a estas pruebas bien por ir entrenando a su personal con tiempo, bien a cambio de alguna

ventaja económica (mejor precio sobre el producto final, derecho a mantenimiento gratuito, a nuevas versiones, etcétera). La

experiencia muestra que estas prácticas son muy eficaces.- Y de ahí vienen los famosos programas Beta que todos conocemos-.

3.3.1 Pruebas Alfa

Las pruebas alfa consisten en invitar al cliente a que venga al entorno de desarrollo a probar el sistema. Se trabaja en

un entorno controlado y el cliente siempre tiene un experto a mano para ayudarle a usar el sistema y para analizar los resulta-

dos.

3.3.2 Pruebas Beta

Las pruebas beta se realizan después de las pruebas alfa, y se desarrollan en el entorno del cliente, un entorno que está

fuera de control. Aquí el cliente se queda a solas con el producto y trata de encontrarle fallos (reales o imaginarios) de los que

informa al desarrollador.

4 Planificación de las Pruebas

La Fase de Pruebas, por su envergadura e importancia, necesita una organización seria y fiable. Ante una fase de

pruebas, se debe tomar como axioma que se van a encontrar errores.

Los componentes de una planificación serán:

1. Objetivos: Definir los objetivos de cada fase de las pruebas.

2. Criterios de terminación: Especificar cuando se deben acabar las pruebas.

3. Cronología: Fijar los tiempos necesarios para cada fase (diseño, escritura y ejecución)

4. Responsabilidades: Especificar los responsables de cada fase, así como quién corregirá los errores detectados.

5. Bibliotecas de casos de prueba y normas: Crear una sistemática de identificación, escritura y almacenamiento de casos de

prueba.

6. Herramientas: Establecer cuáles serán las herramientas de prueba que se van a utilizar.

7. Tiempo de máquina: Determinar el tiempo de computación que se necesita en cada fase del proyecto de prueba. 8. Configuración del equipo: Detallar la necesidad de configuraciones especiales de equipo o de algún período concreto.




Pág 15 Curso 2011 - 2012

9. Integración: Describir el plan de integración del sistema.

10. Métodos de seguimiento: Especificar los métodos que se han de utilizar en las pruebas.

11. Depuración: Definir un mecanismo para informar sobre los errores detectados, para seguier el proceso de las correcciones

y para incorporar éstas al sistema.

El orden de realización de las pruebas podría ser el que se muestra en la Figura 1. Pruebas del sistema :

FiguraFiguraFiguraFigura 1111. Prueba. Prueba. Prueba. Pruebas del sistemas del sistemas del sistemas del sistema

En cuanto a las pruebas unitarias un posible orden de las mismas es el que sigue:

1. Pasar pruebas de caja negra analizando valores límite. Recuerde que hay que analizar condiciones límite de entrada y de

salida.

2. Identificar clases de equivalencia de datos (entrada y salida) y añadir más pruebas de caja negra para contemplar valores

normales (en las clases de equivalencia en que estos sean diferentes de los valores límite; es decir, en rangos amplios de va-

lores).

3. Añadir pruebas basadas en "presunción de error". A partir de la experiencia y el sentido común, se aventuran situaciones

que parecen proclives a padecer defectos, y se buscan errores en esos puntos.

4. Medir la cobertura de caja blanca que se ha logrado con las fases previas y añadir más pruebas de caja blanca hasta lograr

la cobertura deseada.

4.1 Plan de pruebas en Métrica v3

[Según Métrica v3]

o Sirve como guía para la realización de las pruebas

o Permite verificar que el sistema de información cumple las necesidades establecidas por el usuario

o Define los objetivos de la prueba de un sistema establece y coordina una estrategia de trabajo, y provee del marco adecua-

do para elaborar una planificación paso a paso de las actividades de prueba

o El plan se inicia en el Análisis del Sistema (ASI).




Pág 16 Curso 2011 - 2012

o El plan se va completando y detallando a medida que se avanza en los restantes procesos del ciclo de vida del software,

Diseño del Sistema de Información (DSI), Construcción del Sistema de Información (CSI) e Implantación y Aceptación

del Sistema (IAS).

Ejercicio:

Resumen de actividades a realizar según métrica V3 y que tengan que ver con las pruebas indicando los productos de en-

trada y salida de cada actividad

UT3_Diseño y realización de pruebas

Documents

Transcript of UT3_Diseño y realización de pruebas