|
3.4 Pruebas
3.4.1 Objetivo
Esta t‚cnica tiene por objetivo ejecutar los programas para
encontrar errores.
3.4.2 Utilidad
Se desarrolla un programa de pruebas para probar que no
existen errores en un programa, es decir hacer que el programa
falle.
La confiabilidad es un aspecto del dise¤o, por lo que debe
estar dentro del sistema, m s adelante se indican las estrate-
gias especificas de pruebas.
3.4.3 Descripci¢n
La prueba del equipo l¢gico es el m‚todo m s usado para deter-
minar si ‚ste funciona como debe. El proceso de pruebas es uno
de los componentes de un conjunto de actividades que permiten
asegurar la calidad del producto (equipo l¢gico).
* Principio b sico de pruebas.
Uno de los princios b sicos en la realizaci¢n de pruebas es
que ‚stas han de ser llevadas a cabo por personas distintas a
los dise¤adores de los programas, tanto para evitar una simple
verificaci¢n de que el programa funcione correctamente, como
para probar que ese programa ha sido concebido e interpretado
correctamente.
Los casos de prueba deben ser escritos tanto para condiciones
de entradas inv lidas o inesperadas, como para condiciones
v lidas y esperadas.
Un principio deducido de la experiencia y observaci¢n de prue-
bas de diferentes programas, es que la probabilidad de
encontar errores adicionales en una secci¢n del programa, es
proporcional al n£mero de errores ya encontradas en la misma
secci¢n.
* Realizaci¢n de las pruebas.
Para cada sistema se realizar n diferentes clases de pruebas:
Pruebas Unitarias: Todos los componentes del sistema que se
desarrollen individualmente para comprobar su correcto funci-
onamiento.
Pruebas de integraci¢n: Se prueba la integraci¢n entre los
componentes del sistema para demostrar que se puede encajar
correctamente.
Pruebas de sistemas: Se prueba el sistema globalmente.
a) Tipos de pruebas
Existen dos tipos de pruebas :
Pruebas del tipo CAJA BLANCA, que permite examinar la estruc-
tura interna del programa.
Pruebas del tipo CAJA NEGRA, donde los casos de prueba se
dise¤an considerando exclusivamente las entradas y salidas
del sistema, sin preocuparse por la estructura interna del mismo.
* Pruebas unitarias de integraci¢n
Las pruebas unitarias se realizan al crear cada m¢dulo o compon-
ente individual de un sistema. Las pruebas de integraci¢n son
realizadas sobre estos componentes individuales son llamados
cuando es necesarios y que los datos que se transmiten entre
dichos componentes son los requeridos.
Se cuentan con dos tipos de pruebas :
a) Desarrollo incremental.
b) Estrategias de integraci¢n.
Se detallar n ambos tipos de pruebas.
a) Desarrollo incremental
Al probar cada m¢dulo individualmente es necesario crear m¢dulos
auxiliares que simulen las acciones de los m¢dulos indicados por
el m¢dulo que se est probando.
As¡ mismo se han de crear m¢dulos ®conductores¯ para establecer
las pre-condiciones necesarias, al m¢dulo objeto de la prueba y
examinar los resultados de la prueba.
Debido a todo esto, a menudo se combinan ambos tipos de prueba
unitarias y de integraci¢n.
El tipo de prueba incremental consiste en agregar cada m¢dulo o
componente individual al conjunto de componentes existentes y el
conjunto resultante de prueba. Esto reduce la necesidad de crear
m¢dulo conductores y permitiendo adem s, examinar en detalle las
interfases. Cuando las pruebas unitarias y de integraci¢n se
realizan separadamente, es dif¡cil examinar los componentes
individuales o m¢dulos que causan resultados incorrectos, por el
contrario, con el tipo de prueba incremental es probable que
surgan al incorporar un nuevo componente a un grupo previamente
probado, sean debidos precisamente a ‚ste £ltimo o a las interf-
ases entre ‚l y los otros componentes.
b) Estrategias de integraci¢n
Es importante determinar la secuencia en que van a producir
e integrar los componentes. Para una estructura de programas
organizada jer rquicamente, se podr enfocar el problema de
la prueba utilizando varias estrategias diferentes:
* Estrategias de arriba a abajo (Top-Down)
* Estrategias de abajo a arriba (Bottom-Up)
* Estrategias combinadas
* Comparaci¢n de estrategias.
* Pruebas del sistema y de aceptaci¢n
a) Pruebas Globales.
Una vez que se han probado los componentes individuales y se
han integrado, se ha de probar el sistema global. En esta
etapa pueden distinguirse los siguientes tipos de prueba,
cada uno con un objetivo claramente definido:
* Pruebas funcionales
* Pruebas de comunicaci¢n
* Pruebas de rendimiento
* Pruebas de volumen
* Pruebas de sobrecarga
* Pruebas de disponibilidad de datos
* Pruebas de facilidad de uso
* Pruebas de operaci¢n
* Pruebas de entorno
* Pruebas de seguridad
b) Pruebas de aceptaci¢n.
Son aquellas pruebas que realiza el usuario con el objeto de
comprobar si el sistema es aceptable para ‚l. Estas pruebas
son del mismo tipo que las mencionadas anteriormente, pero
son determinadas por el usuario, en lugar de serlo por el
equipo de desarrollo.
Un lugar especial de estas pruebas es el de la ejecuci¢n en
paralelo con el viejo sistema, para comparar los resultados
producidos por ambas ejecuciones.
* 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 :
* Objetivos: Definir los objetivos de cada fase de las
pruebas.
* Criterios de terminaci¢n, Especificar cu ndo se deben
acabar las pruebas.
* Cronolog¡a: Fijar los tiempos necesarios para cada fase
(dise¤o, escritura, ejecuci¢n).
* Responsabilidades: Especificar los responsables de cada
fase, as¡ como qui‚n corregir los errores detectados.
* Bibliotecas de caso de prueba y normas: Crear una sistem t-
ica de identificaci¢n, escritura y almacenamiento de casos de
prueba.
* Herramientas: Establecer cu les ser n las herramientas de
pruebas que se van a utilizar.
* Tiempo de m quina: Determinar el tiempo de computaci¢n que
se necesita en cada fase del proyecto de prueba.
* Configuraci¢n de equipo: Detallar la necesidad de computac-
i¢n especiales de equipo o de un per¡odo concreto.
* Integraci¢n: Describir el plan de integracion del sistema.
* M‚todos de seguimiento: Especificar los m‚todos que se han
de utilizar en las pruebas.
* Depuraci¢n: Definir un mecanismo para informar sobre los
errores detectados, para seguir el proceso de las correccio-
nes y para incorporar ‚stas al sistema.
* Terminaci¢n de las pruebas.
Es dif¡cil que el £ltimo error detectado,era el £nico que
quedaba. Sin embargo, existen m‚todos para mostrar cu ndo
esta pr¢ximo el final, los dos m s comunes son:
Terminar la prueba cuando el tiempo establecido para la
misma ha expirado.
Terminar la prueba cu ndo todos los casos de prueba se ejec-
utan sin detectar errores.
Otros m‚todos m s complicados de aplicar pero m s efectivos
son:
* Estimaci¢n de n£mero total de errores del programa..
* Estimaci¢n del porcentaje de estos errores que pueden
encontrarse f cilmente.
* Estimaci¢n de que fracci¢n de errores se originan en proc-
esos particulares de dise¤o.
Para realizar cualquiera de estas estimaciones es necesario
contar con una historia o experiencia previa que permita
definir dichas estimaciones.
|
