Pruebas del software Tema 4 Definiciones asociadas Verificación

Pruebas del software
Tema 4
Definiciones asociadas
Verificación: El proceso de evaluación de un sistema (o de uno de sus componentes
para determinar si los productos de una fase dada satisfacen las condiciones impuestas al
comienzo de dicha fase
Definiciones
Pruebas (test): «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»
Caso de prueba (test case): «un conjunto de entradas, condiciones de ejecución y
resultados esperados desarrollados para un objetivo particular»
Defecto (defect, fault, «bug»):«un defecto en el software como, por ejemplo, un proceso,
una definición de datos o un paso de procedimiento incorrectos en un programa»
Fallo (failure): «La incapacidad de un sistema o de alguno de sus componentes para
realizar las funciones requeridas dentro de los requisitos de rendimiento especificados»
Error (error): Tiene varias acepciones:
-La diferencia entre un valor calculado, observado o medido y el valor verdadero,
especificado o teóricamente correcto (Fallo)
-Un defecto (Defecto)
-Un resultado incorrecto (Fallo)
-Una acción humana que conduce a un resultado incorrecto (Error)
-Relación entre error, defecto y fallo
Recomendaciones para unas pruebas exitosas
Cada caso de prueba debe definir el resultado de salida esperado que se comparará con
el realmente obtenido.
El programador debe evitar probar sus propios programas, ya que desea (consciente o
inconscientemente) demostrar que funcionan sin problemas.
Además, es normal que las situaciones que olvidó considerar al crear el programa
queden de nuevo olvidados al crear los casos de prueba
Se debe inspeccionar a conciencia el resultado de cada prueba, 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 (es habitual olvidar el segundo):
Probar si el software no hace lo que debe hacer
Probar si el software hace lo que debe hacer, es decir, si provoca efectos secundarios
adversos
Se deben evitar los casos desechables, es decir, los no documentados ni diseñados con
cuidado.
Ya que suele ser necesario probar muchas veces el software y por tanto hay que tener
claro qué funciona y qué no
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  siempre hay
defectos
La experiencia parece indicar que donde hay un defecto hay otros, es decir, la
probabilidad de descubrir nuevos defectos en una parte del software es proporcional al
número de defectos ya descubierto.
Las pruebas son una tarea tanto o más creativa que el desarrollo de software. Siempre se
han considerado las pruebas como una tarea destructiva y rutinaria.
Es interesante planificar y diseñar las pruebas para poder detectar el máximo número y
variedad de defectos con el mínimo consumo de tiempo y esfuerzo
Ciclo completo de las pruebas
Plan de pruebas
Planear
pruebas
Información sobre proyecto
Diseñar
pruebas
Configuración de
pruebas (casos de
procedimientos)
Ejecutar
pruebas
Configuración de
software revisado
Información sobre software
(ERS, diseño, etc)
Resultados
Resultados
esperados
Correcciones
DESARROLLO
Depuración
Evaluar
pruebas
Errores: histórico e
informes de pruebas
Acciones preventivas
(formación, mejora de
procesos, etc)
Predicción de fiabilidad
Análisis
de
errores
Estadísticas de
errores
Proceso de prueba
El proceso de prueba comienza con la generación de un plan de pruebas en basa 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 trama la configuración del software que se va a probar
para ejecutar sobre ella los casos.
En algunas situaciones, se puede tratar de reejecuciones de pruebas, por lo que se
convenientes 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 esta 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
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
Técnicas de diseños de casos de prueba
Imposibilidad de probar exhaustivamente el software
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
La seguridad total sólo puede obtenerse de la prueba exhaustiva, que no es practicable
Objetivo: conseguir confianza aceptable en que se encontrarán todos los defectos
existentes, sin consumir una cantidad excesiva de recursos
Ya que no se pueden probar todas las posibilidades de funcionamiento del software, la
idea fundamental para el diseño casos de prueba consistente en elegir algunas de ellas
que, por sus características, se consideran representativas del resto.
Enfoques de diseños de pruebas
El enfoque estructural o de caja blanca: consiste en centrarse en la estructura interna
(implementación) del programa para elegir los casos de prueba.
En este caso, la prueba ideal del software consistirá en probar todos los posibles caminos
de ejecución, a través de las instrucciones del códigos, que puedan trazarse
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 del software consistiría en probar todas las posibles entradas y salidas
del programa
El enfoque aleatorio consiste en utilizar modelos (en muchas ocasiones 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 enfoques no son excluyentes entre sí
Pruebas estructurales
Grafo de flujo de un programa (pseudocódigo)
1
Abrir archivos;
2
Leer archivo ventas, al final indicar no más registros;
Limpiar línea de impresión
WHILE
(haya registros ventas)
3
DO
Total nacional = 0;
4
Total extranjero = 0;
WHILE
(haya registros ventas)
IF
(nacional)
y
(mismo producto)
DO
THEN
5
Sumar ventas nacional a total nacional
ELSE
6
Sumar ventas nacional a total extrangero
ENDIF;
7a
7b
Leer archivo ventas, al final indicar no más registros;
ENDWHILE;
8,9
Escribir línea de listado;
Limpiar área de impresión;
10,11
ENDWHILE;
12,13
Cerrar archivos.
Notación de grafo de flujo
Pruebas estructurales
El diseño de casos tiene que basarse en la elección de caminos importantes que ofrezcan
una seguridad aceptable en descubrir defectos
Se utilizan los llamados criterios de cobertura lógica
Pruebas estructurales
Criterios de cobertura lógica
Cobertura de sentencias. Se trata de generar los casos de prueba necesarios para que
cada sentencia o instrucción del programa se ejecute al menos una vez.
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.
(Incluye a la cobertura de sentencias)
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 el
falso al menos una vez. (No incluye cobertura de condiciones)
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.
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 puede considerar que
cada decisión multicondicional se descompone en varias condiciones unicondicionales.
Ejemplo en la siguiente diapositiva.
Criterio de cobertura de caminos. Se recorren todos los caminos (impracticable)
Ejemplo de descomposición de una decisión
multicondicional
La complejidad de McCabe V(G)
(Complejidad Ciclomática)
La métrica de McCabe ha sido muy popular en el diseño de pruebas
Es un indicador del número de caminos independientes que existen en un grafo
La complejidad de McCabe V(G)
El criterio de prueba de McCabe es: Elegir tantos casos de prueba como caminos
independientes (calculados como V(G))
La experiencia en este campo asegura que:
-V(G) marca el límite mínimo de casos de prueba para un programa
-Cuando V(G) > 10 la probabilidad de defectos en el módulo o programa crece
muchoquizás sea interesante dividir el módulo
Ejemplo
1
a1
a3
2
a4
Región 1
3
a5
a6
a7
4
Región 2
a8
a9
Región 3
5
a10
a11
6
Región 4
7
a13
9
a12
8
a14
10
Región 5
11
Derivación de casos de pruebas
1. Usando el diseño o el código como base, dibujamos el correspondiente grafo de flujo.
2. Determinamos la complejidad ciclomática del grafo de flujo resultante, V(G).
3. Determinamos un conjunto básico de hasta V(G) caminos linealmente
independientes.
4. Preparamos los casos de prueba que forzarán la ejecución de cada camino del
conjunto básico.
Algunos consejos:
Numerar los nodos del grafo secuencialmente
Describir el conjunto de caminos independientes (subrayar aristas que los hacen
independientes de los anteriores). En el ejemplo anterior serían:
1-2-11
1-2-3-4-10-2
1-2-3-4-5-10-2
1-2-3-4-5-6-7-9
1-2-3-4-5-6-8-9
Algunos caminos no se pueden ejecutar solos y requieren la concatenación con otro
Algunos caminos pueden ser imposibles  seleccionar otros
A partir de los caminos, analizar el código para ver qué datos de entrada son necesarios,
y qué salida se espera
Complejidad ciclomática
Conclusiones
La experimentación con la métrica de McCabe ha dado como resultado las conclusiones
[Beizer 90]:
V(G) marca un límite mínimo del nº de casos de prueba, contando cada condición de
decisión como un nodo individual.
Parece que cuando V(G) es mayor que 10 la probabilidad de defectos en el módulo crece
bastante si dicho valor alto no se debe a sentencias CASE
(en ese caso, es recomendable replantearse el diseño modular).
Pruebas de bucles (Beizer 90)
Bucles simples (“n” es el nº máx. de iteraciones):
-Pasar por alto totalmente el bucle.
-Pasar una sola vez por el bucle.
-Pasar dos veces por el bucle.
-Hacer m pasos por el bucle, con m<n.
-Hacer n-1, n y n+1 pasos por el bucle.
Bucles no estructurados:
-rediseñar primero.
Bucles anidados (para evitar progresión geométrica):
-Llevar a cabo las pruebas de bucles simples con el bucle más interior. Configurar el
resto de bucles con sus valores mínimos.
-Progresar hacia afuera, llevando a cabo pruebas para el siguiente bucle, manteniendo
los bucles externos en sus valores mínimos y los internos en sus valores “típicos”.
Bucles concatenados:
-si no son independientes, como con los bucles anidados.
Prueba Funcional o de caja negra
Estudia la especificación del software, las funciones que debe realizar, las entradas y las
salidas.
Busca tipos de errores diferentes a las pruebas de caja blanca:
-¿es el sistema particularmente sensible a ciertos datos de entrada?
-¿qué volumen de datos tolerará el sistema?
-¿qué efectos tendrán determinadas combinaciones de datos sobre el funcionamiento del
sistema?
Un caso de prueba está bien elegido si:
-reduce el nº de casos de prueba adicionales para alcanzar una prueba razonable
-nos dice algo sobre la presencia o ausencia de clases de errores.
Prueba Funcional
Particiones o clases de equivalencia
Cada caso de prueba debe cubrir el máximo nº de entradas.
Debe tratarse el dominio de valores de entrada dividido en un nº finito de clases de
equivalencia
la prueba de un valor representativo de la clase permite suponer
“razonablemente” que el resultado obtenido será el mismo que
probando cualquier otro valor de la clase
Método de diseño:
-Identificación de clases de equivalencia.
-Creación de los casos de prueba correspondientes.
Paso 1. Identificar las clases de equivalencia
Identificar 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 las clases de equivalencia que puede ser:
De datos válidos
De datos no válidos
Algunas reglas para identificar clases:
-Por cada rango de valores, se especifica una clase válida y dos no válidas.
-Si se especifica un nº de valores, se creará una clase válida y dos no válidas.
-Si se especifica una situación del tipo “debe ser” o booleana, se identifica una clase
válida y una no válida.
-Si se especifica un conjunto de valores admitidos, y el programa trata de forma
distinta cada uno de ellos, se crea una clase válida por cada valor, y una no válida.
-Si se sospecha que ciertos elementos de una clase no se tratan igual que el resto
de la misma, debe dividirse en clases menores.
Algunas reglas para identificar clases:
-Por cada rango de valores, se especifica una clase válida y dos no válidas
(válida) 1 
-Si se especifica un nº de valores, se creará una clase válida y dos no válidas
(válida) num propietarios = 3;
(no válidas) num propietarios < 3, num propietarios > 3
-Si se especifica una situación del tipo “debe ser” o booleana, se identifica una clase
válida y una no válida
(válida) “El primer carácter es una letra”; (no válida) “(...) no es una letra”
(válida) “X es un número”; (no válida) “X no es un número”
-Si se especifica un conjunto de valores admitidos, y el programa trata de forma distinta
cada uno de ellos, se crea una clase válida por cada valor, y una no válida
Tres tipos de inmuebles: (válidas) “pisos”, “chalets”, “locales comerciales”;
(no válida) “jkllñ”
Paso 2. Identificar los casos de prueba
Asignación de un número único a cada clase de equivalencia.
Hasta que todas las clases de equivalencia 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 de equivalencia no válidas hayan sido cubiertas por casos de
prueba, escribir un caso para una ÚNICA clase no válida sin cubrir.
Ejemplo
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: Número de 3 dígitos que no empieza ni por 0, ni por 1.
-Nombre de identificación: 6 caracteres.
-Órdenes posibles: “Cheque”, “deposito”, “Pago factura”, “retirada de fondos”.
Aplicación de las reglas:
-Código
-Número, regla 3, booleana:
Clase válida (número)
Clase no válida (no número)
-Regla 5, la clase número debe subdividirse; por la regla 1, rango, obtenemos:
Subclase válida (200 ≤ código ≤ 900)
Dos subclases no válidas (código < 200; código > 999)
-Nombre de id., número específico de valores, regla 2:
Clase válida (6 caracteres)
Dos clases no válidas (más de 6; menos de 6 caracteres)
Orden, conjunto de valores, regla 4:
Una clase válida para cada orden (“cheque”, “depósito”,…); 4 en total.
Una clase no válida (“divisas”, por ejemplo)
Ejemplo (Tabla de clases de equivalencias)
Condición de entrada
Clases válidas
Clases inválidas
Código área
Nombre para identificar
la operación
Orden
(1) 200 ≤ código ≤
900
(5) Seis caracteres
(8) “cheque”
(9) “depósito”
(10) “paso factura”
(11) “retirado
fondos”
(2) Código < 200
(3) Código > 999
(4) No es número
(6) Menos de 6
caracteres
(7) Más de 6 caracteres
(12) Ninguna orden
válida
Ejemplo
Prueba Funcional
Análisis de Valores Límite (AVL)
Los casos de prueba que exploran las condiciones límite producen mejores resultados
“Los defectos del software se acumulan en las situaciones límite”
Diferencias de AVL con particiones de equivalencia:
-No se elige “cualquier elemento” de la clase de equivalencia, sino uno o más de manera
que los márgenes se sometan a prueba.
-Los casos de prueba se generan considerando también el espacio de salida.
Análisis de Valores Límite.
Reglas para identificar casos
Si una condición de entrada especifica un rango delimitado por los valores (“-1.0 ≤ valor
≤ +1.0”), se deben generar casos para los extremos del rango (-1.0 y +1.0) y casos no
válidos justo por debajo y justo por encima de los extremos (-1.001, y +1.001), en el caso
que se admitan 3 decimales.
Si una condición de entrada especifica un número de valores (el fichero de entrada
tendrá de 1 a 255 registros”), se deben desarrollar casos de prueba que ejerciten los
valores máximo y mínimo, uno más el máximo y uno menos el mínimo (0, 1, 255 y 256).
Usar la regla 1 para la condición de salida (“el descuento máximo aplicable en compra al
contado será el 50%, el mínimo será el 6%)
-Se escribirán casos para intentar obtener descuentos de 5.99%, 6%, 50% y 50.01%
Usar la regla 2 para condiciones de salida (“el programa puede mostrar de 1 a 4 listados”)
-Se escribir casos para intentar generar 0, 1, 4 y 5 listados
-En esta regla como en la 3, debe recordarse que:
Los valores límites de entrada no generan necesariamente los valores límites de
salida
No siempre se pueden generar resultados fuera del rango de salida
Si la entrada o la salida de un programa es un conjunto ordenado (por ejemplo una tabla
un archivo secuencial…), los caos deben concentrarse en el primero y en el última
elemento.
Conjetura de errores
Se enumera una lista de posibles equivocaciones típicas que pueden cometer los
desarrolladores y de situaciones propensas a ciertos errores
-El valor cero es una situación propensa a error tanto en la salida como en la entrada
-En situaciones en las que se introduce un número variable de valores, conviene
centrarse en el caso de no introducir ningún valor y en el de un solo valor. También
puede ser interesante un lista que tiene todos los valores iguales
-Es recomendable imaginar que el programador pudiera haber interpretado algo mal en
la especificación
-También interesa imaginar lo que el usuario puede introducir como entrada a un
programa
Prueba de Interfaces Gráficas de Usuario (GUI, Graphical User
Interface)
Uso de una lista de chequeo preestablecida
Para ventanas:
-¿Se abrirán las ventanas mediante órdenes basadas en el teclado o en un menú?
-¿Se puede ajustar el tamaño, mover y desplegar la ventana?
-¿Se regenera adecuadamente cuando se escribe y se vuelve a abrir?
...
Para menús emergentes y operaciones con el ratón:
-¿Se muestra la barra de menú apropiada en el contexto apropiado?
-¿Es correcto el tipo, tamaño y formato del texto?
-¿Si el ratón tiene varios botones, están apropiadamente reconocidos en el contexto?
Entrada de datos:
-¿Se repiten y son introducidos adecuadamente los datos alfanuméricos?
-¿Funcionan adecuadamente los modos gráficos de entrada de datos? (p.e. barra
deslizante)
-¿Se reconocen adecuadamente los datos no válidos?
-¿Son inteligibles los mensajes de entrada de datos?
Pruebas aleatorias
En las pruebas aleatorias 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 manera repetitiva)
Para ello habitualmente se utilizan generadores automáticos de casos de prueba
Enfoque práctico recomendado para el diseño de casos
Se propone un uso más apropiado de cada técnica (caja blanca y negra) para obtener un
conjunto de casos útiles:
-Si la especificación contiene combinaciones de condiciones de entrada, comenzar
formando sus grafos de causa-efecto (ayudan a la comprensión de dichas combinaciones)
-En todos los casos, usar el análisis de valores límites para añadir casos de prueba: elegir
límites para dar valores a las causas en los casos generados asumiendo que cada causa es
una clase de equivalencia
-Identificar las clases válidas y no válidas de equivalencia para la entrada y la salida, y
añadir los casos no incluidos anteriormente
-Utilizar la técnica de conjetura de errores para añadir nuevos casos, referidos a valores
especiales
-Ejecutar los casos generados hasta el momento y analizar la cobertura obtenida
-Examinar la lógica del programa para añadir los casos precisos (de caja blanca) para
cumplir el criterio de cobertura elegido si los resultados de la ejecución del punto anterior
indican que no se ha satisfecho el criterio de cobertura elegido
Una cuestión importante es ¿por qué son necesarias las pruebas de caja blanca si
comprobamos que las funciones se realizan correctamente?
-Los errores lógicos y las suposiciones incorrectas son inversamente proporcionales a la
probabilidad de que se ejecute un camino del programa ( a menor probabilidad de
ejecutarse un camino, mayor número de errores)
-Se suele creer que un determinado camino lógico tiene pocas posibilidades de ejecutarse
cuando, de hecho, se puede ejecutar regularmente
-Los errores tipográficos son aleatorios; pueden aparecer en cualquier parte del programa
(sea muy usada o no)
-La probabilidad y la importancia de un trozo de código suele ser calculada de forma muy
subjetiva
No obstante las pruebas de caja blanca solas tampoco garantizan el éxito:
if (x+y+z)/3=x
then print (x, y y z son iguales)
else print (x, y y z no son iguales)
Una prueba de caja blanca como esta
x=5, y=5, z=5
x=2, y=3, z=7
No detecta el error lógico, que si sería detectado con otro tipo de pruebas funcionales.
Estrategia de aplicación de las pruebas
Se analiza cómo plantear las pruebas en el Ciclo de Vida.
La estrategia de pruebas suele seguir estas etapas
Comenzar pruebas a nivel de módulo
Continuar hacia la integración del sistema completo y a su instalación
Culminar con la aceptación del producto por parte del cliente
(Etapas típicas más en detalle)
-Se comienza en la prueba de cada módulo, que normalmente la realiza el propio personal
de desarrollo en su entorno
-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 requisitos de rendimientos,
seguridad, etc. (prueba funcional o de validación).
-El software ya validado se integra con el resto del sistema (por ejemplo, elementos
mecánicos, interfaces electrónicas, etc.) 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 entorno de explotación si lo acepta como está o no (prueba de
aceptación)
Relación entre productos de desarrollo y niveles de prueba
Prueba de unidad
La prueba de módulo 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)Es la prueba de cada módulo, que normalmente realiza el propio personal de desarrollo
en su entorno
Hablamos de 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
Prueba de integración
Con el esquema del diseño del software, los módulos probados se integran para
comprobar sus interfaces en el trabajo conjunto
El orden de integración elegido influye en una gran variedad de aspectos como los
siguientes:
-La forma de preparar casos
-Las herramientas necesarias
-El orden de codificar y probar los módulos
-El coste de la depuración
-El coste de preparación de casos
Tipos fundamentales de integración
Integración incremental: Se combina el siguiente módulo que se debe probar con el
conjunto de módulos que ya están probados
Ascendente: se comienzan por los módulos hoja
Descendente: se comienza por el módulo 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.
Ventajas de la integración incremental y la no incremental
Pruebas de integración
No incremental
Incremental



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 oportunidad de
probar módulos en paralelo



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
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 ventajosa con defectos en
niveles del programa
Las entradas son más fáciles de
crear
Es más fácil observar los
resultados de las pruebas


Método ventajoso con grandes fallos en
los niveles superiores
Tras incorporar funciones de E/S, fácil
representación de casos
Permite ver antes una estructura previa
del programa
Desventajas
Desventajas




Se requiere módulos
impulsores
El programa, como entidad, no
existe hasta incorporar el
último módulo




Requiere ficticios subordinados
Módulos subordinados ficticios no son
fáciles de crear
Antes de incorporar E/S, es difícil
representar casos y las entradas pueden
ser difíciles de crear
Difícil observar resultados
Induce a superposición de diseño y
pruebas
Induce a retrasar la terminación de la
prueba de algunos módulos
Pruebas de sistema
Es el proceso de prueba de un sistema integrado de hardware y software para comprobar
lo siguiente:
-Cumplimiento de todos los requisitos funcionales, considerando el producto software
final al completo en un entorno de sistema
-El 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
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
suelen llamarse pruebas de sobrecarga (stress testing)
-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, de los diagramas de flujo de datos)
Pruebas de aceptación
Es la prueba planificada y organizada formalmente para determinar si se cumplen los
requisitos de aceptación marcados por el cliente.
Sus características principales son las siguientes:
-Participación del usuario
-Está enfocada hacia la prueba de los requisitos de usuario especificados.
-Está considerada como la fase final del proceso para crear una confianza en que el
producto es el apropiado para su uso en explotación
Recomendaciones generales
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
Las pruebas se deben realizar en el entorno en el que se utilizará el sistema. Si se trata de
un sistema contratado, la prueba se realiza bajo control de la organización de desarrollo
en el entorno real de trabajo, ayudando al usuario