PUEBA DE DESOFTWARE
Ariel Jiménez Díaz
Ing. Software II
Índice
Introducción........................................................................................................1
Prueba de software.............................................................................................2
Verificación y validación....................................................................................2
Organización de las pruebas del software......................................................3
Pasos de la pueba del software........................................................................5
Criterios para completar las pruebas...............................................................6
Aspectos Estratégicos.......................................................................................6
Prueba de Unidad...............................................................................................7
Pruebas de Integración......................................................................................8
Integración descendente...................................................................................8
Estrategias de prueba para webapps...............................................................9
Pruebas de validación......................................................................................10
Criterios de pruebas de validación.................................................................10
Revisión de la configuración...........................................................................10
Pruebas alfa y beta...........................................................................................11
Pruebas del sistema.........................................................................................11
Pruebas de recuperación.................................................................................12
Pruebas de seguridad......................................................................................12
Pruebas de Esfuerzo........................................................................................13
Pruebas de Rendimiento..................................................................................13
Pruebas de Despliegue....................................................................................13
El arte de la depuración...................................................................................14
Estrategias de depuración...............................................................................16
Corrección del error.........................................................................................16
Conclusión........................................................................................................17
Bibliografía........................................................................................................18
Introducción
Sin importar el tipo de software que se construya, una estrategia para planificar,
ejecutar y controlar pruebas sistemáticas comienza por considerar pequeños
elementos del software y moverse hacia afuera, hacia el programa como un
todo. Las pruebas de software representan el porcentaje más grande de
esfuerzo técnico en el proceso de software.
El objetivo es logra mediante una serie de pasos de prueba la verificación
funcional de un componente y en la incorporación de componentes en una
arquitectura de software. Las pruebas de validación demuestran la conformidad
con los requerimientos del software y las pruebas del sistema validan el
software una vez que se incorporó en un sistema más grande.
1
Prueba de software
Una estrategia de prueba de software proporciona una guía que describe los
pasos que deben realizarse como parte de la prueba, cuándo se planean y se
llevan a cabo dichos pasos, y cuánto esfuerzo, tiempo y recursos se requerirán.
Por tanto, cualquier estrategia de prueba debe incorporar la planificación de la
prueba, el diseño de casos de prueba, la ejecución de la prueba y la
recolección y evaluación de los resultados.
La prueba es un conjunto de actividades que pueden planearse por
adelantado y realizarse de manera sistemática. Por esta razón, durante el
proceso de software, debe definirse una plantilla para la prueba del software:
un conjunto de pasos que incluyen métodos de prueba y técnicas de diseño de
casos de prueba específicos.
En la literatura sobre el tema, se han propuesto algunas estrategias de prueba
de software.
Todas proporcionan una plantilla para la prueba y tienen las siguientes
características genéricas:
Para realizar una prueba efectiva, debe realizar revisiones técnicas efectivas
(capítulo15). Al hacerlo, eliminará muchos errores antes de comenzar la
prueba.
La prueba comienza en los componentes y opera “hacia afuera”, hacia la
integración de todo el sistema de cómputo.
Diferentes técnicas de prueba son adecuadas para distintos enfoques de
ingeniería de software y en diferentes momentos en el tiempo.
Las pruebas las realiza el desarrollador del software y (para proyectos
grandes) un grupo de prueba independiente.
Prueba y depuración son actividades diferentes, pero la depuración debe
incluirse en cualquier estrategia de prueba.
Una estrategia para la prueba de software debe incluir pruebas de bajo
nivel, que son necesarias para verificar que un pequeño segmento de código
fuente se implementó correctamente, así como pruebas de alto nivel, que
validan las principales funciones del sistema a partir de los requerimientos del
cliente.
2
Verificación y validación
La prueba de software es un elemento de un tema más amplio que usualmente
se conoce como verificación y validación (V&V).
La verificación se refiere al conjunto de tareas que garantizan que el
software implementa correctamente una función específica.
La validación es un conjunto diferente de tareas que aseguran que el
software que se construye sigue los requerimientos del cliente.
Boehm [Boe81] afirma esto de esta forma:
Verificación: “¿Construimos el producto correctamente?”
Validación: “¿Construimos el producto correcto?”
Organización de las pruebas del software
En todo proyecto de software hay un conflicto inherente de intereses que
ocurre conforme comienzan las pruebas. Hoy en día, a las personas que
construyen el software se les pide probarlo.
En sí, esto parece sencillo; después de todo, ¿quién conoce mejor el
programa que sus desarrolladores?
Por desgracia, estos mismos desarrolladores tienen mucho interés en
demostrar que el programa está libre de errores, que funciona de acuerdo con
los requerimientos del cliente y que se completará a tiempo y dentro del
presupuesto. Cada uno de estos intereses tiene un efecto negativo sobre las
pruebas más cuidadosas.
Desde un punto de vista psicológico, el análisis y diseño de software (junto
con la codificación) son tareas constructivas. El ingeniero de software analiza,
modela y luego crea un programa de computadora y su documentación. Como
cualquier constructor, el ingeniero de software está orgulloso del edificio que
construyó y ve con desconfianza a quien intente derrumbarlo
Cuando comienzan las pruebas, hay un sutil, pero definitivo, intento por
“romper” lo que construyó el ingeniero de software. Desde el punto de vista del
constructor, las pruebas pueden considerarse como (psicológicamente)
destructivas. De modo que el constructor actuará con cuidado, y diseñará y
ejecutará pruebas que demostrarán que el programa funciona, en lugar de
descubrir errores. Desafortunadamente, los errores estarán presentes. Y si el
ingeniero de software no los encuentra, ¡el cliente lo hará!
3
Pasos de la pueba del software.
5
Criterios para completar las pruebas
Cada vez que se analiza la prueba del software, surge una pregunta clásica:
“¿cuándo terminan las pruebas?, ¿cómo se sabe que se ha probado lo
suficiente?”. Lamentablemente, no hay una respuesta definitiva a esta
pregunta, pero existen algunas respuestas pragmáticas e intentos tempranos a
manera de guía empírica.
Una respuesta a la pregunta es: “nunca se termina de probar; la carga
simplemente pasa de usted (el ingeniero de software) al usuario final”. Cada
vez que el usuario ejecuta un programa de cómputo, el programa se pone a
prueba. Este instructivo hecho subraya la importancia de otras actividades a fin
de garantizar la calidad del software. Otra respuesta (un tanto cínica, mas no
obstante precisa) es: “las pruebas terminan cuando se agota el tiempo o el
dinero”.
Al coleccionar estadísticas durante las pruebas del software y usar los
modelos existentes de confiabilidad del mismo, es posible desarrollar
lineamientos significativos para responder la pregunta: “¿cuándo terminan las
pruebas?”. Hay poco debate acerca de que todavía queda mucho trabajo por
hacer antes de poder establecer reglas cuantitativas para las pruebas, pero los
acercamientos empíricos que existen en la actualidad son considerablemente
mejores que la intuición pura.
Aspectos Estratégicos
Especifican los requerimientos del producto en forma cuantificable mucho
antes de comenzar con las pruebas. Aunque el objetivo predominante de una
prueba es encontrar errores, una buena estrategia de prueba también valora
otras características de la calidad, como la portabilidad, el mantenimiento y la
facilidad de uso. Esto debe especificarse en una forma medible, de modo que
los resultados de las pruebas no sean ambiguos.
Establecen de manera explícita los objetivos de las pruebas. Los objetivos
específicos de las pruebas deben enunciarse en términos medibles. Por
ejemplo, la efectividad de las pruebas, su cobertura, el tiempo medio antes de
aparecer una falla, el costo por descubrir y corregir defectos, la densidad de
defectos restantes o la frecuencia de ocurrencia, y las horas de trabajo de
prueba deben enunciarse dentro del plan de la prueba.
Entienden a los usuarios del software y desarrollan un perfil para cada
categoría de usuario.
6
Los casos de uso que describen el escenario de interacción para cada clase
de usuario pueden reducir el esfuerzo de prueba global al enfocar las pruebas
en el uso real del producto.
Prueba de Unidad
La prueba de unidad enfoca los esfuerzos de verificación en la unidad más
pequeña del diseño de software: el componente o módulo de software. Al usar
la descripción del diseño de componente como guía, las rutas de control
importantes se prueban para descubrir errores dentro de la frontera del módulo.
La relativa complejidad de las pruebas y los errores que descubren están
limitados por el ámbito restringido que se establece para la prueba de unidad.
Las pruebas de unidad se enfocan en la lógica de procesamiento interno y de
las estructuras de datos dentro de las fronteras de un componente. Este tipo de
pruebas puede realizarse en paralelo para múltiples componentes.
Procedimientos de prueba de unidad. Las pruebas de unidad por lo general
se consideran como adjuntas al paso de codificación. El diseño de las pruebas
de unidad puede ocurrir antes de comenzar la codificación o después de
generar el código fuente. La revisión de la información del diseño proporciona
una guía para establecer casos de prueba que es probable que descubran
errores en cada una de las categorías analizadas anteriormente. Cada caso de
prueba debe acoplarse con un conjunto de resultados esperados.
7
Pruebas de Integración
Un neófito en el mundo del software podrá plantear una pregunta
aparentemente legítima una vez que todos los módulos se hayan probado de
manera individual: “si todos ellos funcionan individualmente, ¿por qué dudan
que funcionarán cuando se junten todos?”. Desde luego, el problema es
“juntarlos todos”: conectarlos. Los datos pueden perderse a través de una
interfaz; un componente puede tener un inadvertido efecto adverso sobre otro;
las subfunciones, cuando se combinan, pueden no producir la función principal
deseada; la imprecisión aceptable individualmente puede magnificarse a
niveles inaceptables; las estructuras de datos globales pueden presentar
problemas. Lamentablemente, la lista sigue y sigue.
Las pruebas de integración son una técnica sistemática para construir la
arquitectura del software mientras se llevan a cabo pruebas para descubrir
errores asociados con la interfaz. El objetivo es tomar los componentes
probados de manera individual y construir una estructura de programa que se
haya dictado por diseño.
Integración descendente. La prueba de integración descendente es un
enfoque incremental a la construcción de la arquitectura de software. Los
módulos se integran al moverse hacia abajo a través de la jerarquía de control,
comenzando con el módulo de control principal (programa principal). Los
módulos subordinados al módulo de control principal se incorporan en la
estructura en una forma de primero en profundidad o primero en:
8
Estrategias de prueba para webapps
La estrategia para probar webapps adopta los principios básicos para todas las
pruebas de software y aplica una estrategia y tácticas que se usan para
sistemas orientados a objetos. Los siguientes pasos resumen el enfoque:
1. El modelo de contenido para la webapp se revisa para descubrir errores.
2. El modelo de interfaz se revisa para garantizar que todos los casos de uso
pueden adecuarse.
3. El modelo de diseño para la webapp se revisa para descubrir errores de
navegación.
4. La interfaz de usuario se prueba para descubrir errores en los mecanismos
de presentación y/o navegación.
5. A cada componente funcional se le aplica una prueba de unidad.
6. Se prueba la navegación a lo largo de toda la arquitectura.
7. La webapp se implementa en varias configuraciones ambientales diferentes
y se prueba en su compatibilidad con cada configuración.
8. Las pruebas de seguridad se realizan con la intención de explotar
vulnerabilidades en la webapp o dentro de su ambiente.
9. Se realizan pruebas de rendimiento.
10. La webapp se prueba mediante una población de usuarios finales
controlada y monitoreada.
Los resultados de su interacción con el sistema se evalúan por errores de
contenido y navegación, preocupaciones de facilidad de uso, preocupaciones
de compatibilidad, así como confiabilidad y rendimiento de la webapp.
Puesto que muchas webapps evolucionan continuamente, el proceso de
prueba es una actividad siempre en marcha, y se realiza para apoyar al
personal que usa pruebas de regresión derivadas de las pruebas desarrolladas
cuando se elaboró por primera vez la webapp. En el capítulo 20 se consideran
métodos para probar la webapp.
9
Pruebas de validación
Las pruebas de validación comienzan en la culminación de las pruebas de
integración, cuando se ejercitaron componentes individuales, el software está
completamente ensamblado como un paquete y los errores de interfaz se
descubrieron y corrigieron. En el nivel de validación o de sistema, desaparece
la distinción entre software convencional, software orientado a objetos y
webapps. Las pruebas se enfocan en las acciones visibles para el usuario y las
salidas del sistema reconocibles por el usuario.
La validación puede definirse en muchas formas, pero una definición simple
(aunque dura) es que la validación es exitosa cuando el software funciona en
una forma que cumpla con las expectativas razonables del cliente. En este
punto, un desarrollador de software curtido en la batalla puede protestar:
“¿quién o qué es el árbitro de las expectativas razonables?”. Si se desarrolló
una Especificación de requerimientos de software, en ella se describen todos
los atributos del software visibles para el usuario; contiene una sección de
Criterios de validación que forman la base para un enfoque de pruebas de
validación.
Criterios de pruebas de validación
La validación del software se logra a través de una serie de pruebas que
demuestran conformidad con los requerimientos. Un plan de prueba subraya
las clases de pruebas que se van a realizar y un procedimiento de prueba
define casos de prueba específicos que se diseñan para garantizar que: se
satisfacen todos los requerimientos de funcionamiento, se logran todas las
características de comportamiento, todo el contenido es preciso y se presenta
de manera adecuada, se logran todos los requerimientos de rendimiento, la
documentación es correcta y se satisfacen la facilidad de uso y otros
requerimientos (por ejemplo, transportabilidad, compatibilidad, recuperación de
error, mantenimiento).
Revisión de la configuración
Un elemento importante del proceso de validación es una revisión de la
configuración. La intención de la revisión es garantizar que todos los elementos
10
de la configuración del software se desarrollaron de manera adecuada, y que
se cataloga y se tiene el detalle necesario para reforzar las actividades de
apoyo.
Pruebas alfa y beta
Virtualmente, es imposible que un desarrollador de software prevea cómo
usará el cliente realmente un programa. Las instrucciones para usarlo pueden
malinterpretarse; regularmente pueden usarse combinaciones extrañas de
datos; la salida que parecía clara a quien realizó la prueba puede ser
ininteligible para un usuario.
Cuando se construye software a la medida para un cliente, se realiza una
serie de pruebas de aceptación a fin de permitir al cliente validar todos los
requerimientos. Realizada por el usuario final en lugar de por los ingenieros de
software, una prueba de aceptación puede variar desde una “prueba de
conducción” informal hasta una serie de pruebas planificadas y ejecutadas
sistemáticamente.
De hecho, la prueba de aceptación puede realizarse durante un periodo de
semanas o meses, y mediante ella descubrir errores acumulados que con el
tiempo puedan degradar el sistema.
Si el software se desarrolla como un producto que va a ser usado por
muchos clientes, no es práctico realizar pruebas de aceptación formales con
cada uno de ellos. La mayoría de los constructores de productos de software
usan un proceso llamado prueba alfa y prueba beta para descubrir errores que
al parecer sólo el usuario final es capaz de encontrar.
Pruebas del sistema
Al comienzo de este libro, se resaltó el hecho de que el software sólo es un
elemento de un sistema basado en computadora más grande. A final de
cuentas, el software se incorpora con otros elementos del sistema (por ejemplo,
hardware, personas, información), y se lleva a cabo una serie de pruebas de
integración y validación del sistema. Estas pruebas quedan fuera del ámbito del
proceso de software y no se llevan a cabo exclusivamente por parte de
ingenieros de software.
Sin embargo, los pasos que se toman durante el diseño y la prueba del
software pueden mejorar enormemente la probabilidad de integración exitosa
del software en el sistema más grande. Un problema clásico en la prueba del
sistema es el “dedo acusador”. Esto ocurre cuando se descubre un error y los
11
desarrolladores de diferentes elementos del sistema se culpan unos a otros por
el problema.
En lugar de abandonarse a tal sinsentido, deben anticiparse los
potenciales problemas de interfaz y:
1) diseñar rutas de manejo de error que prueben toda la información
proveniente de otros elementos del sistema.
2) realizar una serie de pruebas que simulen los datos malos u otros errores
potenciales en la interfaz del software.
3) registrar los resultados de las pruebas para usar como “evidencia” si ocurre
el dedo acusador.
4) participar en planificación y diseño de pruebas del sistema para garantizar
que el software se prueba de manera adecuada.
Pruebas de recuperación
Muchos sistemas basados en computadora deben recuperarse de fallas y
reanudar el procesamiento con poco o ningún tiempo de inactividad. En
algunos casos, un sistema debe ser tolerante a las fallas, es decir, las fallas del
procesamiento no deben causar el cese del funcionamiento del sistema global.
En otros casos, la falla de un sistema debe corregirse dentro de un periodo de
tiempo específico u ocurrirán severos daños económicos.
Pruebas de seguridad
Cualquier sistema basado en computadora que gestione información sensible o
cause acciones que puedan dañar (o beneficiar) de manera inadecuada a
individuos es un blanco de penetración inadecuada o ilegal. La penetración
abarca un amplio rango de actividades: hackers que intentan penetrar en los
sistemas por deporte, empleados resentidos que intentan penetrar por
venganza, individuos deshonestos que intentan penetrar para obtener ganancia
personal ilícita.
La prueba de seguridad intenta verificar que los mecanismos de protección
que se construyen en un sistema en realidad lo protegerán de cualquier
12
penetración impropia. Para citar a Beizar [Bei84]: “La seguridad del sistema
debe, desde luego, probarse para ser invulnerable ante ataques frontales; pero
también debe probarse su invulnerabilidad contra ataques laterales y traseros.”
Pruebas de Esfuerzo
Los primeros pasos de la prueba del software dieron como resultado una
evaluación extensa de las funciones y el rendimiento normales del programa.
Las pruebas de esfuerzo se diseñan para enfrentar los programas con
situaciones anormales. En esencia, la persona que realiza las pruebas de
esfuerzo pregunta: “¿cuánto podemos doblar esto antes de que se rompa?”.
Pruebas de Rendimiento
Para sistemas en tiempo real y sistemas embebidos, el software que
proporcione la función requerida, pero que no se adecue a los requerimientos
de rendimiento, es inaceptable. La prueba de rendimiento se diseña para poner
a prueba el rendimiento del software en tiempo de corrida, dentro del contexto
de un sistema integrado. La prueba del rendimiento ocurre a lo largo de todos
los pasos del proceso de prueba. Incluso en el nivel de unidad, puede
accederse al rendimiento de un módulo individual conforme se realizan las
pruebas. Sin embargo, no es sino hasta que todos los elementos del sistema
están plenamente integrados cuando puede determinarse el verdadero
rendimiento de un sistema.
Pruebas de Despliegue
En muchos casos, el software debe ejecutarse en varias plataformas y bajo
más de un entorno de sistema operativo. La prueba de despliegue, en
ocasiones llamada prueba de configuración, ejercita el software en cada
entorno en el que debe operar. Además, examina todos los procedimientos de
instalación y el software de instalación especializado (por ejemplo,
“instaladores”) que usarán los clientes, así como toda la documentación que se
usará para introducir el software a los usuarios finales.
13
El arte de la depuración
La prueba del software es un proceso que puede planearse y especificarse de
manera sistemática.
Puede realizarse el diseño de casos de prueba, definir una estrategia y
evaluar los resultados comparándolos con las expectativas prescritas.
La depuración ocurre como consecuencia de las pruebas exitosas. Es decir,
cuando un caso de prueba descubre un error, la depuración es el proceso que
da como resultado la remoción del error. Aunque la depuración puede y debe
ser un proceso ordenado, todavía en mucho es un arte. Los ingenieros de
software con frecuencia se enfrentan con indicios “sintomáticos” de un
problema de software mientras evalúan los resultados de una prueba, es decir,
la manifestación externa del error y su causa interna pueden no tener relación
obvia una con otra. El proceso mental, pobremente comprendido, que conecta
un síntoma con una causa se conoce como depuración.
14
Estrategias de depuración
Sin importar el enfoque que se tome, la depuración tiene un objetivo
dominante: encontrar y corregir la causa de un error o defecto de software. El
objetivo se realiza mediante una combinación de evaluación sistemática,
intuición y suerte.
Bradley [Bra85] describe el enfoque de depuración de la siguiente forma:
La depuración es una aplicación directa del método científico que se ha
desarrollado durante más de 2 500 años. La base de la depuración es localizar
la fuente del problema [la causa] mediante una partición binaria, a través del
trabajo con hipótesis que predicen nuevos valores por examinar.
Tome un ejemplo simple que no sea de software: una lámpara en mi casa
no funciona. Si nada en la casa funciona, la causa debe estar en el interruptor
principal o en el exterior; observo mí alrededor para ver si el vecindario está a
oscuras. Conecto la lámpara sospechosa en un tomacorriente que funcione y
un electrodoméstico operativo en el circuito sospechoso. Y así continúo la
alternación entre hipótesis y pruebas.
Corrección del error
Una vez encontrado el error, debe corregirse. Pero, como ya se señaló, la
corrección de un error puede introducir otros errores y, por tanto, hacer más
daño que bien.
Van Vleck [Van89] sugiere tres preguntas simples que deben plantearse
antes de hacer la “corrección” que remueva la causa de un error:
1. ¿La causa del error se reproduce en otra parte del programa? En muchas
situaciones, un defecto de programa es causado por un patrón de lógica
erróneo que puede reproducirse en alguna otra parte. La consideración
explícita del patrón lógico puede resultar en el descubrimiento de otros errores.
16
2. ¿Qué “siguiente error” puede introducirse con la corrección que está a punto
de realizar?
Antes de hacer la corrección, debe evaluarse el código fuente (o, mejor, el
diseño) para valorar el acoplamiento de las estructuras lógica y de datos. Si la
corrección se realizará en una sección altamente acoplada del programa, debe
tenerse especial cuidado cuando se realice algún cambio.
3. ¿Qué debió hacerse para evitar este error desde el principio? Esta pregunta
es el primer paso hacia el establecimiento de un enfoque de aseguramiento de
calidad estadística del software (capítulo 16). Si se corrigen tanto el proceso
como el producto, el error se removerá del programa actual y podrá eliminarse
de todos los programas futuros.
17
Conclusión
Cada paso de la prueba se logra a través de una serie de técnicas de prueba
sistemáticas que auxilian en el diseño de casos de prueba. Con cada paso de
prueba, se amplía el nivel de abstracción con la que se considera el software.
La estrategia para probar software orientado a objeto comienza con pruebas
que ejercitan las operaciones dentro de una clase y luego avanzan hacia la
prueba basada en hebra para integración.
Las hebras son conjuntos de clases que responden a una entrada o evento.
Las pruebas basadas en uso se enfocan en clases que no colaboran
demasiado con otras clases.
17
Bibliografía
McGraw-Hill. (s.f.). Ingenieria del Software: Un Enfoque Práctico.
Pressman, R. (2006). Prueba de Software.
18
