SW Testing: ADA - Ut10 - c0809

Desarrollo de Aplicaciones Informáticas Desarrollo de contenidos
Análisis y Diseño Detallado de Aplicaciones

Informáticas de Gestión Ut10: Pruebas del software
Ut10: PRUEBAS DEL SOFTWARE
Tabla de contenidos
1. INTRODUCCIÓN ................................................................................................. 2
1.1. Filosofía de las pruebas del software .......................................................... 2
2. EL PROCESO DE PRUEBA .................................................................................... 3
3. TÉCNICAS DE DISEÑO DE CASOS DE PRUEBA ..................................................... 4
4. PRUEBAS ESTRUCTURALES (CAJA BLANCA) ....................................................... 5
5. PRUEBA FUNCIONAL (CAJA NEGRA) .................................................................. 6
6. PRUEBAS ALEATORIAS ....................................................................................... 8
7. EJECUCIÓN DE LAS PRUEBAS ............................................................................. 8
7.1. El proceso de ejecución de las pruebas ....................................................... 8
7.2. Documentación de la ejecución de las pruebas ........................................... 9
7.3. Depuración ................................................................................................ 10
8. ESTRATEGIA DE APLICACIÓN DE LAS PRUEBAS ............................................... 11
8.1. Prueba de unidad ...................................................................................... 12
8.2. Pruebas de integración.............................................................................. 12
8.2.1. Integración incremental ascendente .................................................. 12
8.2.2. Integración incremental descendente ................................................ 13
8.2.3. Integración no incremental ................................................................ 15
8.2.4. Comparación entre los distintos tipos de integración ......................... 15
8.3. Prueba del sistema .................................................................................... 17
8.4. Prueba de aceptación ................................................................................ 17
9. PRUEBAS EN DESARROLLOS ORIENTADOS A OBJETOS ......... ¡Error! Marcador no
definido.
9.1. Estrategias de pruebas orientadas a objetos ... ¡Error! Marcador no definido.
9.1.1. Las pruebas de unidad en el contexto de la OO ....... ¡Error! Marcador no
definido.
9.1.2. Las pruebas de integración en el contexto de la OO ¡Error! Marcador no
definido.
9.1.3. Las pruebas de validación (sistema) en el contexto de la OO ...... ¡Error!
Marcador no definido.
9.2. Diseño de casos de prueba para software OO . ¡Error! Marcador no definido.
9.2.1. Aplicabilidad de los métodos convencionales .......... ¡Error! Marcador no
definido.
9.2.2. Diseño de pruebas basadas en el escenario ............. ¡Error! Marcador no
definido.
Página 1 de 17

1. INTRODUCCIÓN
Las pruebas, junto con las revisiones intermedias durante el desarrollo del producto, constituyen un método más
para poder verificar y validar el software. Cuando hablamos de verificación nos estamos preguntando si estamos
construyendo correctamente el producto y cuando nos referimos a validación nos preguntamos: ¿estamos
construyendo el producto correcto?.
Las pruebas permiten verificar y validar el software cuando ya está en forma de código ejecutable. A
continuación se exponen algunos conceptos relacionados con las pruebas:
Prueba: es “una actividad en la cual un sistema o uno de sus componentes se ejecuta en circunstancias
previamente especificadas, los resultados se observan y registran y se realiza una evaluación de algún
aspecto”. O sea, es el proceso de ejecutar un programa con el fin de encontrar errores.
Caso de prueba: es “un conjunto de entradas, condiciones de ejecución y resultados esperados

desarrollados para un objetivo particular como, por ejemplo, ejercitar un camino concreto de un
programa o verificar el cumplimiento de un determinado requisito”.
Defecto: es, por ejemplo, un proceso, una definición de datos o un paso de procesamiento incorrectos
en un programa.
Fallo: es “la incapacidad de un sistema o de alguno de sus componentes para realizar las funciones
requeridas dentro de los requisitos de rendimiento especificados”
Error: tiene varias acepciones:
o La diferencia entre un valor calculado, observado o medido y el valor verdadero, especificado o

teóricamente correcto.
o Una acción humana que conduce a un resultado incorrecto (una metedura de pata). Por
ejemplo, que el programador o el operador pulse una tecla equivocada.
1.1. Filosofía de las pruebas del software
Las recomendaciones acerca de cómo realizar las pruebas son las siguientes:
Cada caso de prueba debe definir el resultado de salida esperado. Este resultado esperado es el que
se compara con el realmente obtenido de la ejecución en la prueba. Las discrepancias entre ambos
(errores) se consideran síntomas de un posible defecto en el software.
El programador debe evitar probar sus propio programas, ya que desea (consciente o
inconscientemente) demostrar que funcionan sin problemas. Esta actitud inadecuada lleva a realizar
pruebas menos rigurosas de lo que sería deseable. Además, es normal que las situaciones que ha
olvidado considerar al crear el programa (por ejemplo, no pensar en cómo tratar un fichero de
entrada vacío) queden de nuevo olvidadas al escribir casos de prueba. Lo ideal sería que probara el
software el peor enemigo de quien lo ha construido.
Se debe inspeccionar a conciencia el resultado de cada prueba para, así, poder descubrir posibles
síntomas de defectos.
Al generar casos de prueba, se deben incluir tanto datos de entrada válidos y esperados como no
válidos e inesperados.
Las pruebas deben centrarse en dos objetivos:
o Probar si el software no hace lo que debe hacer.

o Probar si el software hace lo que no debe hacer, es decir, si provoca efectos secundarios
adversos.
No deben hacerse planes de prueba suponiendo que, prácticamente, no hay defectos en los
programas y, por lo tanto, dedicando pocos recursos a las pruebas.
La experiencia parece indicar que donde hay defectos hay otros, es decir, la probabilidad de descubrir
nuevos defectos en una parte del software es proporcional al número de defectos ya descubierto.
Por lo tanto la filosofía más adecuada para las prueba consiste en planificarlas y diseñarlas de forma
sistemática para poder detectar el máximo número y variedad de defectos con el mínimo consumo de tiempo y
esfuerzo.
Página 2 de 17

2. EL PROCESO DE PRUEBA
El proceso de prueba comienza con la generación de un plan de pruebas en base a la documentación sobre
el proyecto y la documentación sobre el software a probar. A partir de dicho plan, se entra en detalle diseñando
pruebas específicas basándose en la documentación del software a probar. Una vez detalladas las pruebas, se
toma la configuración del software (la versión más actual) que se va a probar para ejecutar sobre ella los casos.
En algunas situaciones, se puede tratar de reejecuciones de pruebas, por lo que es conveniente tener constancia de
los defectos ya detectados aunque aún no corregidos. A partir de los resultados de salida, se pasa a su evaluación
mediante comparación con la salida esperada. A partir de ésta se pueden realizar dos actividades:
• La depuración (localización y corrección de defectos).

• El análisis de la estadística de errores.
La depuración puede corregir o no los defectos. Si no consigue localizarlos, puede ser necesario realizar pruebas
adicionales para obtener más información. Si se corrige un defecto, se debe volver a probar el software para
comprobar que el problema está resuelto.
Por otro lado, el análisis de errores puede servir para realizar predicciones de la fiabilidad del software y para
detectar las causas más habituales de error y mejorar los procesos de desarrollo.
Página 3 de 17

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

El diseño de los casos de prueba está totalmente mediatizado por la imposibilidad de probar exhaustivamente el
software. Por ejemplo, pensemos en un programa muy sencillo que sólo suma dos números enteros de dos cifras
(del 0 al 99). Si quisiéramos probar todos los valores válidos que se pueden sumar, deberíamos probar 10.000
combinaciones distintas de 100 posibles números del primer sumando y cien del segundo. Y todavía quedaría por
probar todas las posibilidades de error al introducir los datos (por ejemplo, teclear una letra en vez de un número).
En consecuencia, las técnicas de diseño de casos de prueba tienen como objetivo conseguir una confianza
aceptable en que se detectarán los defectos existentes sin necesidad de consumir una cantidad excesiva de recursos
(por ejemplo, tiempo para probar o tiempo de ejecución).
Ya que no se pueden probar todas las posibilidades del funcionamiento de un programa, se ha de elegir las
posibilidades que, por sus características, se consideren representativas del resto. La dificultad estriba en saber
elegir los casos que se deben ejecutar.
Existen tres enfoques principales para el diseño de casos:
1. El enfoque estructural o de caja blanca. Consiste en centrarse en la estructura interna

(implementación) del programa para elegir los casos de prueba. La prueba ideal consistiría en probar
todos los posibles caminos de ejecución, a través de las instrucciones del código, que puedan trazarse.
2. El enfoque funcional o de caja negra. Consiste en estudiar la especificación de las funciones, la
entrada y la salida para derivar los casos. La prueba ideal consistiría en probar todas las posibles
entradas y salidas del programa.
3. El enfoque aleatorio consiste en utilizar modelos estadísticos que representen las posibles entradas al
programa para crear a partir de ellos los casos de prueba. La prueba exhaustiva consistiría en probar
todas las posibles entradas al programa.
Estos tres enfoques no son excluyentes entre sí, ya que se pueden combinar para conseguir una detección de
defectos más eficaz.
Caja blanca
Entrada Salida
Caja negra
Entrada Salida
Funciones
Página 4 de 17

4. PRUEBAS ESTRUCTURALES (CAJA BLANCA)

Como ya hemos dicho antes, es esencial elegir los caminos de prueba que ofrezcan una seguridad aceptable en
descubrir defecto, y para ello se utilizan los criterios de cobertura lógica.
Una posible clasificación de criterios de cobertura lógica es la que se ofrece abajo. Se encuentran ordenados por
orden de exigencia y, por tanto, de coste económico. Es decir, el criterio de cobertura de sentencias es el que ofrece
una menor seguridad de detección de defectos, pero es el que cuesta menos en número de ejecuciones del
programa.
1. Cobertura de sentencias: Se trata de generar los casos de prueba necesarios para que cada
sentencia del programa se ejecute al menos una vez.
2. Cobertura de decisiones: Consiste en escribir casos suficientes para que cada decisión tenga, por lo
menos una vez, un resultado verdadero y, al menos una vez, uno falso. En general, una ejecución de
pruebas que cumple la cobertura de decisiones cumple también la de sentencias.
3. Cobertura de condiciones: Se trata de diseñar tantos casos como sea necesario para que cada
condición de cada decisión adopte el valor verdadero al menos una vez y falso al menos una vez. No
podemos asegurar que si se cumple la cobertura de condiciones se cumple necesariamente la de
decisiones.
4. Criterio de decisión/condición: Consiste en exigir el criterio de cobertura de condiciones obligando

a que se cumpla también el criterio de decisiones.
5. Criterio de condición múltiple: En el caso de que se considere que la evaluación de las condiciones
de cada decisión no se realiza de forma simultánea, se podría considerar que cada decisión
multicondicional se descompone en varias decisiones unicondicionales. Es decir, una decisión como
IF(a=1) AND (c=4) THEN se convierte en una concatenación de dos decisiones: IF (a=1) y IF (c=4).
En este caso debemos conseguir que todas las combinaciones posibles de resultados (verdadero/falso)
de cada condición en cada decisión se ejecuten al menos una vez.
then then
(a=1) (c=4)
(a=1) and (c=4)
else
else
La cobertura de caminos (secuencia de sentencias) es el criterio más elevado: cada uno de los posibles
caminos del programa se debe ejecutar al menos una vez. Se define camino como la secuencia de sentencias
encadenadas desde la sentencia inicial del programa hasta su sentencia final. Para reducir el número de caminos a
probar, se habla del concepto de camino de prueba, que es un camino del programa que atraviesa, como máximo,
una vez el interior de cada bucle que encuentra. La idea en la que se basa consiste en que ejecutar un bucle más
de una vez no supone una mayor seguridad de detectar defectos en él. Sin embargo, hay especialistas que
recomiendan que se prueba cada bucle tres veces: uno sin entrar en su interior, otra ejecutándolo una vez y otra
más ejecutándolo dos veces.
Página 5 de 17

5. PRUEBA FUNCIONAL (CAJA NEGRA)
Esta prueba se centra en el estudio de la especificación del software, del análisis de las funciones que debe
realizar, de las entradas y de las salidas. De nuevo, hay que buscar criterios que permitan elegir un subconjunto de
casos cuya ejecución aporte una cierta confianza en detectar los posibles defectos del software. Lo importante, en
este caso, es saber definir un buen caso de prueba, veamos algunas técnicas para ello.
5.1. Particiones o clases de equivalencia

Utiliza las cualidades que definen un buen caso de prueba de la siguiente manera:
• Cada caso debe cubrir el máximo número de entradas.

• Debe tratarse el dominio de valores de entrada dividido en un número finito de clases de
equivalencia que cumplan la siguiente propiedad: la prueba de un valor representativo de una
clase permite suponer “razonablemente” que el resultado obtenido será el mismo que el
obtenido probando cualquier otro valor de la clase.
El Método de diseño de casos consiste en:
1. Identificación de las clases de equivalencia:
Para identificar las posibles clases de equivalencia de un programa a partir de su especificación deben
seguirse los siguientes pasos:
• Identificación de las condiciones de las entradas del programa, es decir, restricciones de

formato o contenido de los datos de entrada.
• A partir de ellas, se identifican clases de equivalencia que pueden ser:
De datos válidos.
De datos inválidos o erróneos.
Existen algunas reglas que ayudan a la identificación de las clases:
• Si se especifica un rango de valores para los datos de entrada (por ejemplo, ”el
número estará comprendido entre 1 y 49”), se creará una clase válida (1<= número
< = 49) y dos clases no válidas (número <1 y número >49).
• Si se especifica un número de valores (por ejemplo, ”se pueden registrar de uno a
tres propietarios de un piso”), se creará una clase válida (1<= propietarios < = 3) y
dos clases no válidas (propietarios <1 y propietarios >3).
• Una situación del tipo debe ser o booleana (por ejemplo, “el primer carácter debe
ser una letra”), se identifican una clase válida (es una letra) y una no válida (no es
una letra).
• Si se especifica un conjunto de valores admitidos (por ejemplo, ”se pueden
registrar tres tipos de inmuebles: pisos, chalés y locales comerciales”) y se sabe que
el programa trata de forma diferente cada uno de ellos, se creará una clase válida por
cada valor y una no válida (cualquier otro caso, por ejemplo, plaza de garaje).
• En cualquier caso, si se sospecha que ciertos elementos de una clase no se tratan
igual que el resto de la misma, debe dividirse en clases menores.
2. Creación de los casos de prueba correspondientes:
El último paso del método es el uso de las clases de equivalencia para identificar los casos de prueba
correspondientes. Este proceso consta de las siguientes fases:
• Asignación de un número único a cada clase de equivalencia.

• Hasta que todas las clases hayan sido cubiertas por casos de prueba, se tratará de escribir un
caso que cubra tantas clases válidas, no incorporadas, como sea posible.
• Hasta que todas las clases no válidas hayan sido cubiertas por casos de prueba, escribir un
caso para una única clase no válida sin cubrir. La razón de cubrir con casos individuales las
clases no válidas es que ciertos controles de entrada pueden enmascarar otros controles
similares. Por ejemplo, “introducir cantidad (1-99) y letra inicial (A-Z)” ante el caso: “1051”
(dos errores), se puede indicar sólo el mensaje “105 fuera de rango de cantidad” y dejar sin
examinar el resto de la entrada.
Página 6 de 17

Por ejemplo, aplicación de esta técnica para una aplicación bancaria en la que el operador deberá
proporcionar un código, un nombre para que el usuario identifique la operación (por ejemplo, “nómina”) y una
orden que disparará una serie de funciones bancarias.
Especificación
• Código área: numero de 3 dígitos que no empieza ni por 0, ni por 1.

• Nombre de identificación: 6 caracteres.
• Órdenes posibles: “cheque”, “depósito”, “pago factura”, ”retirada de fondos”.
Aplicación de las reglas
• Código, número (booleano) regla 3

o Clase válida (número)
o Clase no válida (no es número).
• Código, rango de valores (la clase anterior se subdivide) regla 5, regla 1

o Subclase válida (200 <= código <= 999)
o Subclases no válidas (código <200; código >999).
• Nombre, número específico de valores regla 2

o Clase válida (6 caracteres)
o Dos Clases no válidas (más de 6 caracteres; menos de 6 caracteres).
• Orden, conjunto de valores regla 4

o Una clase válida para cada orden (“cheque”, “depósito”, ….); 4 en total.
o Una clase no válida (“divisas”, por ejemplo).
Resumiendo, las clases de equivalencia se muestran en la tabla
Condición de entrada Clases válidas Clases inválidas

Código área (1) 200 ≤ código ≤ 999 (2) código <200
(3) código >999
(4) no es número
Nombre para identificar la (5) seis caracteres (6) menos de 6 caracteres
operación (7) más de 6 caracteres
Orden (8) «cheque» (12) ninguna orden válida
(9) «depósito»
(10) «pago factura»
(11) «retirada de fondos»
Casos válidos:
- 300 Nómina Depósito (1) (5) (9)

- 400 Viajes Cheque (1) (5) (8)
- 500 Coches Pago Factura (1) (5) (10)
- 600 Comida Retirada Fondos (1) (5) (11)
Casos no válidos:
- 180 (2)
- 1032 (3)
- XY (4)
- 350 <INTRO> (1) (6)
- 450 Regalos (1) (7)
- 550 Casa (1) (12)
Página 7 de 17

6. PRUEBAS ALEATORIAS
En estas pruebas simulamos la entrada habitual del programa creando datos de entrada en la secuencia y con la
frecuencia con las que podrían aparecer en la práctica, de forma continua sin parar. Esto implica usar una
herramienta denominada generador de pruebas, a la que se alimenta con una descripción de las entradas y las
secuencias de entrada posibles y su probabilidad de ocurrir en la práctica.
Si el proceso de generación se ha realizado correctamente, se crearán eventualmente todas las posibles

entradas del programa en todas las posibles combinaciones y permutaciones. Sin embargo, esta técnica es menos
utilizada que las anteriores.
7. EJECUCIÓN DE LAS PRUEBAS
7.1. El proceso de ejecución de las pruebas
El proceso abarca las siguientes fases:
1. Ejecutar las pruebas, cuyos casos y procedimientos han sido diseñados previamente.
2. Comprobar si se ha concluido el proceso de prueba (según los criterios de compleción
especificados en el plan de pruebas).
3. En el caso de que hayan terminado las pruebas, se evalúan los resultados; en caso contrario,
hay que generar las pruebas adicionales para que satisfagan los criterios de compleción de
pruebas.
1.EJECUTAR
3.PRUEBAS
ADICIONALES
2.COMPROBAR
SI TERMINÓ
LA PRUEBA
3.EVALUAR
RESULTADOS
El proceso EJECUTAR, a su vez, tiene las siguientes fases:
1. Se ejecutan las pruebas, es decir, se realiza el paso por el ordenador de los datos de prueba.
2. Se comprueba si ha habido algún fallo al ejecutar (se cae el sistema, se bloquea el teclado, etc.)
3. Si lo ha habido, se puede deber a un defecto software, lo que nos lleva al proceso de depuración o
corrección del código. Se puede deber también a un defecto en el propio diseño de las pruebas. En
ambos casos, las nuevas pruebas o las corregidas se deberán ejecutar en el ordenador.
4. De no existir fallos, se pasará a la comprobación de la terminación de las pruebas (paso 2 del anterior
esquema).
Página 8 de 17

EJECUTAR
PRUEBAS
DEPURAR
LAS DEPURACIÓN
PRUEBAS
Si ¿ALGUN Si
FALLO? DEFECTOS
DEFECTOS
EN LAS SOFTWARE
No
PRUEBAS
COMPROBAR
TERMINACIÓN
Por su parte, el proceso de COMPROBACIÓN DE LA TERMINACIÓN tiene las siguientes fases:
1. Tras la ejecución, se comprueba si se cumplen los criterios de compleción de pruebas descritos en el

plan de pruebas.
2. En el caso de terminar las pruebas, se pasa a la evaluación de los productos probados sobre la base
de los resultados obtenidos (terminación normal).
3. En caso de no terminar las pruebas, se debe comprobar la presencia de condiciones anormales en la
prueba (por ejemplo, un defecto importante no corregido ya detectado previamente, tiempo
finalizado, etc.).
4. Si hubiesen existido condiciones anormales (por ejemplo, no se han podido probar todos los casos
porque el sistema se cae regularmente), se pasa de nuevo a la evaluación (terminación anormal); en
caso contrario, se pasa a generar y ejecutar pruebas adicionales para satisfacer cualquiera de las dos
terminaciones.
PRUEBAS
ADICIONALES EJECUCIÓN
No Si Criterios de
CONDICIONES ¿Pruebas compleción descritos
ANORMALES adicionales? en el plan de pruebas
No
TERMINACIÓN
NORMAL
EVALUACIÓN
TERMINACIÓN
ANORMAL
7.2. Documentación de la ejecución de las pruebas
Al igual que el diseño de las pruebas, la documentación de la ejecución es fundamental para la eficacia
en la detección y corrección de defectos, así como para dejar constancia del resultado de las pruebas. Los
documentos que la componen son:
Página 9 de 17

Especificación Casos
de las pruebas procedimientos
EJECUCION
Histórico Informe Histórico Informe

de de de de
pruebas incidente pruebas incidente
Ejecución
Ejecución
Informe
Resúmen
1. Documentación de entrada: constituida por las especificaciones de los casos de prueba que
se van a usar y las especificaciones de los procedimientos de prueba.
2. Documentación de salida (informes sobre la ejecución): Cada ejecución de pruebas

generará dos tipos de documentos:
o Histórico de pruebas o registro cronológico de la ejecución.

o Informe de las incidencias ocurridas (si hay) durante la ejecución.
3. Informe resumen de pruebas: Documentación de salida correspondiente a un mismo

diseño de prueba (entrada y salida).
7.3. Depuración
Se define la depuración como el proceso de “localizar, analizar y corregir los defectos que se
sospecha que contiene el software”. Suele ser la consecuencia de una prueba con éxito (aquella que descubre
un defecto). Las consecuencias de la depuración pueden ser dos:
• Encontrar la causa del error, analizarla y corregirla.

• No encontrar la causa y, por lo tanto, tener que generar nuevos casos de prueba que puedan
proporcionar información adicional para su localización (casos de prueba para la depuración).
Resultados
Casos
de
prueba
Ejecución
Causas
ignoradas
Correcciones
Síntomas
de
Depuración defectos
Causas (errores)
Página 10 de 17

El proceso de prueba implica generar unos casos de prueba, ejecutarlos en el ordenador y obtener unos
resultados. Dichos resultados se analizan para la búsqueda de síntomas de defectos (errores) en el software.
Esta información se pasa al proceso de depuración para obtener las causas del error (defecto). En caso de
conseguirlo, se corrige el defecto; en caso contrario, se llevarán a cabo nuevas pruebas que ayuden a
localizarlo. Tras corregir el defecto, se efectuarán nuevas pruebas que comprueben si se ha eliminado dicho
problema.
Consejos para la depuración:
• Localización del error:
o Analizar la información y pensar.

o Al llegar a un punto muerto pasar a otra cosa.
o Al llegar a un punto muerto describir el problema a otra persona.
o No experimentar cambiando el programa.
o Se deben atacar los errores de uno en uno.
• Corrección del error:
o Donde hay un defecto, suele haber más.

o Debe corregirse el defecto, no sus síntomas.
o La corrección debe situarnos temporalmente en la etapa de diseño.
8. ESTRATEGIA DE APLICACIÓN DE LAS PRUEBAS
Una vez conocidas las técnicas de diseño y aplicación de las pruebas, debemos analizar cómo se utilizan dentro
del ciclo de vida, integrando las pruebas con el desarrollo del software y permitiendo la coordinación del personal de
desarrollo con el del departamento de Calidad y del cliente.
En general, la estrategia de pruebas suele seguir las siguientes etapas:
• Se comienza en la prueba de cada módulo, que normalmente la realiza el propio personal de desarrollo
en su entorno (prueba de unidad).
• Con el esquema del diseño del software, los módulos probados se integran para comprobar sus
interfaces en el trabajo conjunto (prueba de integración).
• El software totalmente ensamblado se prueba como un conjunto para comprobar si cumple o no tanto
los requisitos funcionales como los de rendimiento y seguridad, (prueba de validación). Este nivel de
prueba suele coincidir con el de la prueba del sistema, cuando no se tiene que acoplar el nuevo diseño
a un sistema ya existente.
• El software ya validado se integra con el resto del sistema para probar su funcionamiento conjunto
(prueba del sistema).
• Por último, el producto final se pasa a la prueba de aceptación para que el usuario compruebe en su
propio entrono de explotación si lo acepta como está o no (prueba de aceptación).
La relación entre las etapas del desarrollo y las pruebas se establece en el ciclo en uve (V):
Requisitos Pruebas de
de usuario aceptación
Especificac. Pruebas de
de requisitos sistema
Diseño Pruebas de
modular integración
Especific. y Pruebas de
lógica de unidad
módulo
Código
Página 11 de 17

1. La prueba de módulo (prueba de unidad) centra sus actividades en ejercitar la lógica del módulo
(caja blanca) y los distintos aspectos de la especificación de las funciones que debe realizar el módulo
(caja negra).
2. La prueba de integración debe tener en cuenta los mecanismos de agrupación de módulos fijados en
la estructura del programa, así como, en general, las interfaces entre componentes de la arquitectura
del software.
3. La prueba del sistema debe centrar sus comprobaciones en el cumplimiento de los objetivos
indicados para el sistema.
4. La prueba de aceptación sirve para que el usuario pueda verificar si el producto final se ajusta a los
requisitos por él fijados, normalmente en criterios de aceptación en el contrato.
8.1. Prueba de unidad
Hablamos de una unidad de prueba para referirnos a uno o más módulos que cumplen las siguientes
condiciones:
• Todos son del mismo programa.

• Al menos uno de ellos no ha sido probado.
• El conjunto de módulos es el objeto de un proceso de prueba.
La prueba de unidad puede abarcar desde un módulo a un grupo de pocos módulos o un programa
completo y el enfoque está claramente orientado al diseño de casos de caja blanca, aunque se complementan
con caja negra.
Estas pruebas suelen ser realizadas por personal de desarrollo, pero evitando que sea el propio
programador quien las realice. En este caso, nos estamos refiriendo a las pruebas formales que permiten
declarar que un módulo está listo y terminado, no a las pruebas informales que los programadores efectúan
mientras desarrollan el código.
8.2. Pruebas de integración
Estas pruebas están relacionadas con la forma prevista de integración de los distintos componentes del
software hasta contar con el producto global que debe entregarse. Implican una progresión ordenada de
pruebas que parte desde los componentes (módulos) y que culmina en el sistema completo. Su objetivo
fundamental es la prueba de las interfaces (flujos de datos) entre los módulos.
Los tipos fundamentales de integración son los siguientes:
• Integración incremental: Se combina el siguiente módulo que se debe probar con el

conjunto de módulos que ya están probados. Se incrementa progresivamente el número de
módulos hasta formar el programa completo. En función del orden elegido existen dos tipos:
o Ascendente: se comienza por los módulos hoja.
o Descendente: se comienza por los módulos raíz.
• Integración no incremental: Se prueba cada módulo por separado y, luego, se integran

todos de una vez y se prueba el programa completo.
Las pruebas de integración y de módulos no son secuenciales (unas detrás de otras), sino que se
solapan y mezclan continuamente.
8.2.1. Integración incremental ascendente
Empieza combinando primero los módulos de más bajo nivel. El proceso es el siguiente:
• Se combinan los módulos de bajo nivel en grupos que realizan alguna subfunción
específica. El objetivo es reducir el número de pasos de integración.
• Se escribe para cada grupo un módulo impulsor que es un módulo escrito para permitir
simular la llamada a los módulos, introducir los datos de prueba a través de los
parámetros de llamada y recoger los resultados a través de los de salida.
• Se prueba cada grupo empleando su impulsor.
• Se eliminan los módulos impulsores de cada grupo y se sustituyen por los módulos de
nivel superior de la jerarquía.
Página 12 de 17

En caso de contar con el siguiente diseño,
B C D
E F G
el orden y los pasos de integración seguirían el siguiente esquema:
1ª fase
Impulsor de E Impulsor de F Impulsor de G Impulsor de D
E F G D
2ª fase 3ª fase
Impulsor de E Impulsor de F A
B C D
B C
E F G
E F G
En esta integración podemos ver cómo se entrelazan las pruebas modulares y las pruebas de
integración. En la primera fase, se realizan las pruebas modulares de E, F, G y D. En la segunda, sin
embargo, se puede observar que se realizan simultáneamente, por ejemplo, la prueba modular de B y la de
integración entre B-E. Esta mezcla de pruebas de unidad y de integración ocurre en todas las integraciones
incrementales.
8.2.2. Integración incremental descendente
Comienza con el módulo de control principal (de mayor nivel o programa principal o módulo raíz) y
va incorporando módulos subordinados progresivamente. No existe un procedimiento general para
determinar cuál de los módulos subordinados posibles es mejor incorporar primero. Hay que estudiar en
cada caso cuál es el mejor orden de incorporación para minimizar el esfuerzo o para lograr una mejor
organización. Como consejos generales se tienen los siguientes:
• Si hay secciones críticas (por ejemplo, un módulo complejo, con un algoritmo nuevo o más
propenso a errores), se debe planear la secuencia de integración para que se prueben lo antes
posible.
• El orden de integración debe incorporar cuanto antes los módulos de entrada/salida para
facilitar la ejecución de las pruebas.
Existen dos órdenes fundamentales de integración descendente:
Página 13 de 17

• Primero en profundidad: se van completando ramas del árbol modular (en el ejemplo
anterior, la secuencia sería A-B-E-C-F-G-D).
• Primero en anchura: se van completando niveles (horizontales) de jerarquía modular (en el
ejemplo anterior, la secuencia sería A-B-C-D-E-F-G).
Las etapas fundamentales de integración son las siguientes:
• El módulo raíz es el primero. Se escriben módulos ficticios para simular la presencia de los
subordinados ausentes que serán llamados por el módulo raíz.
• Una vez probado el módulo raíz (sin detectarse ya ningún defecto), se sustituye uno de los
subordinados ficticios por el módulo correspondiente según el orden elegido. Se incorporan
ficticios para recoger las llamadas del último incorporado.
• Se ejecutan las correspondientes pruebas cada vez que se incorpora un módulo nuevo.
• AL terminar cada prueba, se sustituye un ficticio por su correspondiente real.
• Conviene repetir algunos casos de prueba de ejecuciones anteriores para asegurarse de que
no se ha introducido ningún defecto nuevo.
La codificación de módulos ficticios subordinados es más complicada que la creación de impulsores.

Los ficticios deben simular que recogen el control de la llamada y que hacen algo con los parámetros que
se les pasan. Debido a la dificultad de construcción, existen diversos niveles de sofisticación de los ficticios:
1. Módulos que sólo muestran un mensaje de traza.

2. Módulos que muestran los parámetros que se les pasa.
3. Módulos que devuelven un valor que no depende de los parámetros que se pasen como
entrada.
4. Módulos que, en función de los parámetros pasados, devuelven un valor de salida que más o
menos se corresponda con dicha entrada.
Tipo 1 Tipo 2 Tipo 3 Tipo 4
Un ejemplo de paso intermedio en la integración descendente en profundidad sería el siguiente:
B Ficticio C Ficticio D
Página 14 de 17

Un ejemplo de paso intermedio en la integración descendente en anchura sería el siguiente:
B C ficticio D
Ficticio E
8.2.3. Integración no incremental
En este tipo de integración cada módulo requiere para ser probado:
• Un módulo impulsor, que transmite o “impulsa” los datos de prueba al módulo y muestra
los resultados de dichos casos de prueba.
• Uno o más módulos ficticios que simulan la función de cada módulo subordinado llamado
por el módulo que se va a probar.
Después de probar cada módulo por separado, se ensamblan todos ellos de una sola vez para
formar el programa completo y probarlo en conjunto. Así, la prueba de cada módulo sigue el siguiente
esquema:
Impulsor
Casos de Módulo que se Resultados

prueba va a probar
ficticio 1 ficticio 2 ficticio 3
En este tipo de integración, las pruebas de unidad y las de integración están totalmente separadas.
8.2.4. Comparación entre los distintos tipos de integración
Ventajas de la integración incremental frente a la no incremental
La no incremental cuenta con las siguientes ventajas:
• Requiere menos tiempo de máquina para las pruebas, ya que se prueba de una sola vez
la combinación de los módulos.
• Existen más oportunidades de probar módulos en paralelo.
La incremental tiene las siguientes ventajas:
• Requiere menos trabajo, ya que se escriben menos módulos impulsores y ficticios.
• Los defectos y errores en las interfaces se detectan antes, ya que se empieza antes a
probar las uniones entre los módulos.
Página 15 de 17

• La depuración es mucho más fácil, ya que si se detectan los síntomas de un defecto en un

paso de la integración hay que atribuirlo muy probablemente al último módulo
incorporado.
• Se examina con mayor detalle el programa, al ir comprobando cada interfaz poco a poco.
Ventajas y Desventajas de las integraciones ascendente y descendente
Ascendente Descendente
Ventajas Ventajas
• Es un método ventajoso si aparecen • Es ventajosa si aparecen grandes
grandes fallos en la parte inferior del defectos en los niveles superiores del
programa, ya que se prueba antes. programa, ya que se prueban antes.
• La entradas para las pruebas son más • Una vez incorporadas las funciones de
fáciles de crear, puesto que los entrada/salida, es fácil manejar los
módulos inferiores tienen funciones casos de prueba.
más específicas. • Permite ver antes una estructura previa
• Es más fácil observar los resultados de del programa, lo que facilita el hacer
la prueba, ya que es en los módulos demostraciones y ayuda a mantener la
inferiores donde se elaboran los datos moral.
(los superiores suelen ser módulos de
control).
Desventajas Desventajas
• Se requieren módulos impulsores, que • Se requieren módulos ficticios que
deben codificarse. suelen ser complejos de crear.
• El programa, como entidad, sólo • Antes de incorporar la entrada/salida
aparece cuando se agrega el último resulta complicado el manejo de los
módulo. casos de prueba.
• Las entradas para las pruebas pueden
ser difíciles o imposibles de crear,
puesto que, a menudo, se carece de
los módulos inferiores que
proporcionan los detalles de operación.
• Es más difícil observar la salida, ya
que los resultados surgen de los
módulos inferiores.
• Pueden inducir a diferir la terminación
de la prueba de ciertos módulos.
Éstas pueden ser las recomendaciones prácticas respecto a la integración:
1. Utilizar una aproximación combinada o sándwich, que actúa de la siguiente manera:
a. Se comienza en los módulos de niveles superiores de forma descendente.

b. Se comienza simultáneamente de forma ascendente desde los módulos inferiores.
c. Se continúa hasta que ambas aproximaciones se encuentren en algún nivel intermedio.
2. Identificar y probar cuanto antes aquellos módulos considerados problemáticos: por ejemplo, módulos
que deben implementar varios requisitos, los que ejercen un mayor control sobre otros, los complejos
o propensos a defectos, los que deben cumplir requisitos de rendimiento estrictos, etc.
Página 16 de 17

8.3. Prueba del sistema
Es el proceso de prueba de un sistema integrado de hardware y software para comprobar si cumple los
requisitos especificados, es decir:
• Cumplimiento de todos los requisitos funcionales.

• Funcionamiento y rendimiento en las interfaces hardware, software, de usuario y de operador.
• Adecuación de la documentación de usuario.
• Ejecución y rendimiento en condiciones límite y de sobrecarga.
Los casos de prueba del sistema tienen tres fuentes principales para su diseño:
• Casos basados en los requisitos gracias a técnicas de caja negra aplicadas a las especificaciones.
• Casos necesarios para probar el rendimiento del sistema y de su capacidad funcional (pruebas de
volumen de datos, de límites de procesamiento, etc.). Este tipo de pruebas son las pruebas de
sobrecarga.
• Casos basados en el diseño de alto nivel aplicando técnicas de caja blanca a los flujos de datos de
alto nivel (por ejemplo, los diagramas de flujo de datos).
8.4. Prueba de aceptación
Esta prueba consiste en comprobar si el producto está listo para ser implantado para el uso operativo
en el entorno de usuario. Si la prueba del sistema determinó la capacidad real del sistema, la prueba de
aceptación pretende transmitir confianza en el sistema al usuario. Lo principal para evaluar el sistema es la
fiabilidad y la facilidad de uso.
La prueba de aceptación es la prueba planificada y organizada formalmente para determinar si se

cumplen los requisitos de aceptación marcados por el cliente. Las principales características son:
• Participación del usuario. Es el usuario quien ejecuta las pruebas y además, aporta datos de
prueba para la ejecución.
• Está enfocada hacia la prueba de los requisitos de usuario especificados, en forma de criterios de
aceptación, que se fijan junto a los requisitos en la etapa de Análisis.
• Está considerada la etapa final del proceso.
Es recomendable evitar ciertas prácticas en estas pruebas:
• Se debe evitar probar pensando en demostrar que el sistema es perfecto.

• Hay que evitar probar sin planificar, dejando que el usuario ejecute algunos casos sobre la
marcha.
Los casos de prueba pueden proceder de casos de caja negra sobre los requisitos o se pueden reutilizar
casos creados para la prueba del sistema. Otras posibilidades son:
• El procesamiento de una carga de trabajo típica (por ejemplo, los datos de un día, o de una
semana). Al ser muchos datos, la comprobación del resultado suele ser complicada.
• En sistemas que reemplazan a otro antiguo se pueden operar ambos en paralelo para ver si,
alimentados con los mismos datos, producen resultados distintos.
• Pruebas especiales de fiabilidad para comprobar qué nivel de degradación sufre el sistema ante un
error.
Las recomendaciones generales ante esta prueba son:
• Debe contarse con criterios de aceptación previamente aprobados por el usuario.

• No hay que olvidar validar también la documentación y los procedimientos de uso (por ejemplo,
mediante una auditoría).
• Las pruebas se deben realizar en el entorno en el que se utilizará el sistema (incluido el personal
que lo maneja). Si se trata de un sistema contratado, la prueba se realiza bajo el control de la
organización de desarrollo en el entorno real de trabajo (prueba alfa). En el caso de productos de
interés general (por ejemplo, paquetes informáticos), se entregan versiones (versiones beta) a
usuarios de confianza, que informarán acerca de la opinión que les merece (prueba beta).
Página 17 de 17

SW Testing: ADA - Ut10 - c0809

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

SW Testing: ADA - Ut10 - c0809

Hochgeladen von

Copyright:

Verfügbare Formate

Desarrollo de Aplicaciones Informáticas Desarrollo de contenidos

Análisis y Diseño Detallado de Aplicaciones

Ut10: PRUEBAS DEL SOFTWARE

Análisis y Diseño Detallado de Aplicaciones

Caso de prueba: es “un conjunto de entradas, condiciones de ejecución y resultados esperados

Error: tiene varias acepciones:

o La diferencia entre un valor calculado, observado o medido y el valor verdadero, especificado o

1.1. Filosofía de las pruebas del software

o Probar si el software no hace lo que debe hacer.

Análisis y Diseño Detallado de Aplicaciones

• La depuración (localización y corrección de defectos).

Análisis y Diseño Detallado de Aplicaciones

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

Existen tres enfoques principales para el diseño de casos:

1. El enfoque estructural o de caja blanca. Consiste en centrarse en la estructura interna

Análisis y Diseño Detallado de Aplicaciones

4. PRUEBAS ESTRUCTURALES (CAJA BLANCA)

4. Criterio de decisión/condición: Consiste en exigir el criterio de cobertura de condiciones obligando

Análisis y Diseño Detallado de Aplicaciones

5. PRUEBA FUNCIONAL (CAJA NEGRA)

5.1. Particiones o clases de equivalencia

• Cada caso debe cubrir el máximo número de entradas.

El Método de diseño de casos consiste en:

1. Identificación de las clases de equivalencia:

• Identificación de las condiciones de las entradas del programa, es decir, restricciones de

Existen algunas reglas que ayudan a la identificación de las clases:

2. Creación de los casos de prueba correspondientes:

• Asignación de un número único a cada clase de equivalencia.

Análisis y Diseño Detallado de Aplicaciones

• Código área: numero de 3 dígitos que no empieza ni por 0, ni por 1.

Aplicación de las reglas

• Código, número (booleano) regla 3

• Código, rango de valores (la clase anterior se subdivide) regla 5, regla 1

• Nombre, número específico de valores regla 2

• Orden, conjunto de valores regla 4

Resumiendo, las clases de equivalencia se muestran en la tabla

Condición de entrada Clases válidas Clases inválidas

- 300 Nómina Depósito (1) (5) (9)

Análisis y Diseño Detallado de Aplicaciones

Si el proceso de generación se ha realizado correctamente, se crearán eventualmente todas las posibles

7. EJECUCIÓN DE LAS PRUEBAS

7.1. El proceso de ejecución de las pruebas

El proceso abarca las siguientes fases:

El proceso EJECUTAR, a su vez, tiene las siguientes fases:

Análisis y Diseño Detallado de Aplicaciones

Por su parte, el proceso de COMPROBACIÓN DE LA TERMINACIÓN tiene las siguientes fases:

1. Tras la ejecución, se comprueba si se cumplen los criterios de compleción de pruebas descritos en el

7.2. Documentación de la ejecución de las pruebas

Análisis y Diseño Detallado de Aplicaciones

Histórico Informe Histórico Informe

2. Documentación de salida (informes sobre la ejecución): Cada ejecución de pruebas

o Histórico de pruebas o registro cronológico de la ejecución.

3. Informe resumen de pruebas: Documentación de salida correspondiente a un mismo

• Encontrar la causa del error, analizarla y corregirla.

Análisis y Diseño Detallado de Aplicaciones

Consejos para la depuración:

• Localización del error:

o Analizar la información y pensar.

• Corrección del error:

o Donde hay un defecto, suele haber más.

8. ESTRATEGIA DE APLICACIÓN DE LAS PRUEBAS

En general, la estrategia de pruebas suele seguir las siguientes etapas:

Análisis y Diseño Detallado de Aplicaciones