teoria - Auditoriasistemas8989898989

ESTRATEGIAS DE PRUEBA DEL SOFTWARE
Una estrategia de prueba del software integra los métodos de diseño de caso de
pruebas del software en una serie bien planeada de pasos que desembocará en la
eficaz construcción de software. La estrategia proporciona un mapa que describe
los pasos que se darán como parte de la prueba indica cuándo se planean y
cuándo se dan estos pasos, además de cuánto esfuerzo, tiempo y recursos
consumirán. Por tanto, cualquier estrategia de prueba debe incorporar la
planeación de pruebas, el diseño de caso de pruebas, la ejecución de pruebas y la
recolección y evaluación de los datos resultantes.
Se han propuesto varias estrategias de prueba del software en distintos libros;
todas proporcionan al desarrollador del software una plantilla para pruebas y todas
tienen las siguientes características genéricas:
 Para realizar pruebas efectivas un equipo de software debe efectuar revisiones técnicas formales y efectivas. Esto eliminará muchos errores antes
de que empiece la prueba.
 La prueba comienza al nivel de componentes y trabaja "hacia fuera", hacia
la integración de todo el sistema de cómputo.
 Diferentes técnicas de prueba son apropiadas en diferentes momentos.
 La prueba la dirige el desarrollador del software y (en el caso de proyectos
grandes) un grupo independiente de pruebas.
 La prueba y la depuración son actividades diferentes, pero la segunda debe
incluirse en cualquier estrategia de prueba.
Una estrategia para la prueba del software debe incluir pruebas de bajo nivel
(necesarias para confirmar la correcta implementación de un pequeño segmento
de código fuente) y de alto nivel (que validen las principales funciones del sistema
a partir de los requisitos del cliente). Una estrategia debe servir como guía para el
profesional y fijar un conjunto de guías para el jefe de proyecto. Debido a que los
pasos de la estrategia de prueba son simultáneos, cuando empieza a aumentar la
presión las fechas límite debe tenerse la opción de medir los avances y buscar
que los problemas aparezcan lo antes posible.
ORGANIZACIÓN PARA LAS PRUEBAS DEL SOFTWARE
En cualquier proyecto de software se presenta un conflicto de intereses cuando
comienzan las pruebas. Ahora se pide a las personas que han construido el
software que lo prueben. En sí, esto parece inofensivo; después de todo, ¿quién
conoce mejor un programa que la persona que lo desarrolló? Por desgracia, a
esos mismos desarrolladores les interesa mucho demostrar que el programa está
libre de errores, que funciona de acuerdo con los requisitos del cliente y que se
completará a tiempo y sin rebasar el presupuesto. Cada uno de estos intereses
mina las bondades de la prueba.
ESTRATEGIA DE PRUEBA PARA ARQUITECTURAS CONVENCIONALES DEL
SOFTWARE
Sería factible considerar que el proceso de ingeniería del software es equipa la
espiral que se ilustra en la figura. Al principio, la ingeniería del sistema define el
papel del software y lleva al análisis de los requisitos de éste, donde se establecen
el dominio de información, la función, el comportamiento, el desempeñe
restricciones y los criterios de validación del software. Al desplazarse hacia el
interior de la espiral se llega al diseño y, por último, a la codificación. El desarrollo
software de computadora requiere recorrer la espiral hacia dentro, a lo largo de
línea bien definida que disminuye el grado de abstracción tras cada vuelta.
Figura (Estrategias de Prueba).
También es posible ver una estrategia para la prueba del software en el contenido
de la espiral. La prueba de unidad comienza en el vértice de la espiral se
concentra en cada unidad (componente) del software, tal como se implementó en
el código fuente. La prueba avanza al desplazarse hacia fuera, a lo largo de la
espiral, hasta llegar a la prueba de integración, donde se atiende el diseño y la
construcción de la arquitectura del software. Si se recorre otra vuelta hacia fuera
en la espiral se encuentra la prueba de validación, donde se validan los requisitos
establecen como parte del análisis de requisitos del software, comparándolos con
el software que se ha construido. Por último, se llega a la prueba del sistema,
donde se prueba como un todo el software y otros elementos del sistema. El
software de computadora se prueba recorriendo la espiral hacia fuera, por una
línea bien definida, de manera; que en cada vuelta se ensancha el alcance de la
prueba.
Figura (Pasos de la Prueba de Software).
PRUEBA DE UNIDAD
La prueba de unidad se concentra en el esfuerzo de verificación de la unidad más
pequeña del diseño del software: el componente o módulo de software. Tomando
como guía la descripción del diseño al nivel de componentes, se prueban
importantes caminos de control para descubrir errores dentro de los límites del
módulo. S alcance restringido que se ha determinado para las pruebas de unidad
limita la relativa complejidad de las pruebas y los errores que éstas descubren.
Las pruebas de unidad se concentran en la lógica del procesamiento interno y en
las estructuras de datos dentro de los límites de un componente. Este tipo de
prueba se puede aplicar paralelo a varios componentes.
Consideraciones sobre la prueba de unidad. En la figura se ilustran de manera
esquemática las pruebas que se aplican como parte de la prueba de unidad. La
interfaz del módulo se prueba para asegurar que la información fluye
apropiadamente hacia dentro y hacia fuera de la unidad de programa sujeta a
prueba. Se examinan las estructuras de datos locales para asegurar que los datos
temporales mantienen la integridad durante todos los pasos de la ejecución de un
algoritmo. Se recorren todos los caminos independientes (caminos de base) en
toda la estructura para asegurar que todas las instrucciones de un módulo se
hayan ejecutado por lo menos una vez Se prueban las condiciones límite para
asegurar que el módulo opera apropiadamente, en los límites establecidos para
restringir el procesamiento. Y por último, se prueban todos los caminos de manejo
de errores.
Es necesario probar el flujo de datos en la interfaz del módulo antes de inicializar
cualquier otra prueba. Si los datos no entran ni salen apropiadamente, todas
demás pruebas resultarán inútiles. Además, durante la prueba de unidad debe
recorrerse las estructuras de datos locales y evaluarse (si es posible) el impacto
local sobre los datos globales.
Figura (Pruebas de Unidad).
Durante la prueba de unidad, una tarea esencial es la prueba selectiva de las rutas
ejecución. Se deben diseñar casos de prueba para descubrir errores debidos a
cálculos incorrectos, comparaciones erróneas o flujos de control inapropiados.
La prueba de límites es una de las tareas más importantes de la prueba de unidad.
Con frecuencia, el software falla en sus límites. Es decir, a menudo los errores
ocurren cuando se procesa el enésimo elemento de una matriz de n dimensiones,
cuando se evoca la i-ésima repetición de un bucle con i pasos, cuando se
encuentra el valor máximo o mínimo permisible. Es muy probable descubrir
errores en los casos de prueba que se ejercen sobre la estructura de datos, el flujo
de control y los valores de datos ubicados apenas abajo de los máximos o
mínimos, sobre éstos y apenas arriba de ellos.
PRUEBA DE INTEGRACIÓN
Un neófito en el mundo del software podría plantear una pregunta aparentemente
legítima, una vez que se haya aplicado una prueba de unidad a todos los módulos
"Si todo funciona bien individualmente, ¿por qué dudan que funcione cuando se
une?.
El problema, por supuesto, consiste en "unir" (crear la interfaz). En una interfaz es
posible perder datos, un módulo podría tener un efecto adverso e inadvertido
sobre otro, la combinación de subfunciones tal vez no produzca la función principal
deseada, la imprecisión aceptable en elementos individuales podría ampliarse
hasta grados inaceptables y las estructuras globales de datos podrían presentar
problemas. Es triste, pero la lista sigue y sigue.
La prueba de integración es una técnica sistemática para construir la arquitectura
del software mientras, al mismo tiempo, se aplican las pruebas para descubrir
errores asociados con la interfaz. El objetivo es tomar componentes a los que se
aplicó una prueba de unidad y construir una estructura de programa que determine
el diseño.
Prueba de humo. La prueba de humo es un enfoque de prueba de integración
que suele utilizarse mientras se desarrollan productos de software. Está diseñado
como mecanismo para marcar el ritmo en proyectos en los cuales el tiempo es
crítico, lo que permite que el equipo de software evalúe su proyecto con
frecuencia. En esencia, el enfoque de la prueba de humo abarca las siguientes
actividades:
 Los componentes de software traducidos a código se integran en una
"construcción", la cual incluye todos los archivos de datos, las librerías, los
módulos reutilizables y los componentes de ingeniería que se requieren
para implementar una o más funciones del producto.
 Se diseña una serie de pruebas para exponer errores que impedirán que la
construcción realice apropiadamente su función. El objetivo es descubrir
errores "paralizantes" que tengan la mayor probabilidad de retrasar el
proyecto de software.
 La construcción se integra con otras construcciones, y diariamente se aplica
una prueba de humo a todo el producto (en su forma actual). El enfoque de
la integración puede ser descendente o ascendente.
EL PROCESO DE DEPURACIÓN
La depuración no es una prueba, pero siempre ocurre como consecuencia de una.
Si se toma como referencia la figura, el proceso de depuración comienza con la
ejecución de un caso de prueba. Se evalúan los resultados y se encuentra una de
correspondencia entre el desempeño esperado y el real. En muchos casos, datos
que no corresponden son síntoma de una causa que aún no aparece. La
depuración trata de relacionar el síntoma con la causa, lo que conduce a corregir
el La depuración siempre arroja dos resultados: 1) se encuentra y se corrige la o
2) no se localiza la causa. En este último caso, la persona encargada de la
depuración debe sospechar la causa, diseñar uno o más casos de prueba que
ayuden a con validar esa sospecha y avanzar hacia la corrección del error de
manera iterativa.
Figura (Proceso de depuración).
Esta filosofía fundamental no cambia para las WebApps. De hecho, puesto que los
sistemas y aplicaciones basados en Web residen en una red e interoperan con
muchos sistemas operativos diferentes, navegadores (u otros dispositivos de
interfaz como PDA o teléfonos celulares), plataformas de hardware, protocolos de
comunicaciones y aplicaciones "de cuarto trasero", la búsqueda de errores
representa un desafío significativo para los ingenieros Web.
La comprensión de los objetivos de las pruebas dentro de un contexto de ingeniería Web requiere considerar las diversas dimensiones de la calidad WebApp. En el
contexto de esta exposición se consideran las dimensiones de calidad que son
particularmente relevantes en cualquier debate de las pruebas para el trabajo de
ingeniería Web. También se considera la naturaleza de los errores que se
encuentran como consecuencia de las pruebas, y la estrategia de poner a prueba
aplicable para descubrir dichos errores.
DIMENSIONES DE CALIDAD
La calidad se incorpora en una aplicación Web como consecuencia de un buen
diseño. Se evalúa al aplicar una serie de revisiones técnicas que valoran varios
elementos del modelo de diseño y al aplicar un proceso de prueba que se trata a
lo largo de este capítulo. Tanto las revisiones como las pruebas examinan una o
más de las siguientes dimensiones de calidad:
 El contenido se evalúa tanto en el ámbito sintáctico como semántico. En el
ámbito sintáctico, la ortografía, la puntuación y la gramática se valoran para
los documentos basados en texto. En el ámbito semántico se valoran la
exactitud (de la información presentada), la consistencia (a través de todos
los objetos de contenido y objetos relacionados) y la falta de ambigüedad.
 La función se prueba para descubrir errores que indiquen que no hay
concordancia con los requisitos del cliente Cada función de la WebApp se
valora en cuanto a exactitud, inestabilidad y concordancia general con los
estándares de implementación apropiados (por ejemplo, estándares de
lenguaje Java o XML).
 La estructura se valora para asegurarse de que entrega adecuadamente
contenido y función de la WebApp, que es extensible y puede sostenerse
conforme se añade nuevo contenido o funcionalidad.
 La facilidad de uso se prueba para garantizar que a cada categoría de
usuario la soporta la interfaz; puede aprender y aplicar toda la sintaxis y
semántica de navegación requerida.
 La navegabilidad se pone a prueba para garantizar que toda la sintaxis y
semántica de navegación se ejercen para descubrir cualquier error de
navegación (por ejemplo, vínculos rotos, vínculos inadecuados, vínculos
erróneos).
 El desempeño se prueba en una diversidad de condiciones operativas,
configuraciones y cargas para asegurar que el sistema responde a la
interacción del usuario y maneja cargas extremas sin que haya una
degradación operativa inaceptable.
 La compatibilidad se prueba al ejecutar la WebApp en varias
configuraciones huésped, en los lados tanto del cliente como del servidor.
El objetivo es encontrar errores específicos respecto a sólo una
configuración huésped.
 La interoperabilidad se prueba para asegurar que la WebApp realiza
interfaces adecuadas con otras aplicaciones o bases de datos.
 La seguridad se prueba al valorar las vulnerabilidades potenciales e
intentar explotar cada una de ellas. Cualquier intento de penetración exitoso
se considera una falla en la seguridad.
Figura (Proceso de pruebas para una web).
La prueba de contenido (y las revisiones) intentan descubrir errores en el
contenido. Esta actividad de prueba es similar en muchos aspectos a la copiaedición de id documento escrito. De hecho, un gran sitio Web puede reclutar los
servicios de un corrector de estilo profesional para descubrir errores tipográficos,
equívocos gramaticales, errores en la consistencia del contenido, inexactitudes en
las representaciones gráficas y fallas en las referencias cruzadas. Además de
examinar el contenido estático en busca de errores, esta etapa de las pruebas
también considera el contenido dinámico derivado de los datos conservados como
parte de un sistema de base de datos integrado a la WebApp.
La prueba de la interfaz ejercita los mecanismos de interacción y valida los
aspectos estéticos de la interfaz del usuario. El objetivo es descubrir los errores
que resultan de mecanismos con una pobre implementación de interacción, u
omisiones, inconsistencias o ambigüedades que se han introducido a la interfaz en
forma inadvertida.
La prueba de navegación aplica casos de uso, derivados como parte de la
actividad de análisis, en el diseño de casos de prueba que ejerciten cada
escenario de contra el diseño de navegación.
La prueba de componentes ejercita el contenido y las unidades funcionales dentro
de la WebApp. Cuando se consideran las WebApps, cambia el concepto de unida.
La "unidad" de elección dentro de la arquitectura de contenido es la página Web.
Cada página Web encapsula contenida vínculos de navegación y elementos de
procesamiento (formatos, guiones, Apple) Una "unidad" dentro de la arquitectura
WebApp puede ser un componente funcional definido que proporciona servicio
directamente a un usuario final o un componente de infraestructura que posibilita
que la WebApp desarrolle todas sus capacidades. Cada componente funcional se
prueba, en gran parte, en la misma forma que se prueba un módulo individual en
el software convencional. En la mayoría de los Casos, las pruebas están
orientadas a las cajas negras. Sin embargo, si el procesamiento es complejo,
también se pueden usar pruebas de cajas blancas. Además de prueba funcional,
también se ejercitan las capacidades de bases de datos.
Conforme se construye la arquitectura de la WebApp, las pruebas de la
navegación y los componentes se utilizan como pruebas de integración. La
estrategia para la prueba de integración depende del contenido y la arquitectura
WebApp que se ha ya elegido. Si la arquitectura de contenido se diseña con
estructura lineal, retícula o jerárquica simple, es posible integrar páginas Web en
gran parte JB la misma forma como se integran módulos para el software
convencional. Sin embargo, si se usa una estructura de jerarquía mixta o de red
(Web), la prueba de integración es similar al enfoque usado para los sistemas OO.
Las pruebas basadas en ligas se pueden aprovechar para integrar el conjunto de
páginas Web (se puede usar una USN para definir el conjunto apropiado)
requerido para responder a un evento de usuario. Cada liga se integra y pone a
prueba individualmente. Mediante las pruebas de regresión se asegura que no
ocurran efectos colaterales. Las pruebas de agolpamiento integran un conjunto de
páginas asociadas (determinadas mediante el examen de los casos de uso y la
USN). Los casos de prueba se derivan para descubrir los errores en las
colaboraciones.
Cada elemento de la arquitectura WebApp se prueba de manera unitaria en la medida de lo posible. Por ejemplo, en una arquitectura MVC (capítulo 19), los componentes modelo, vista y controlador se prueban cada uno de manera individual.
Después de la integración, el flujo de control y datos a través de cada uno de
estos elementos se valora en detalle.
Las pruebas de configuración intentan descubrir los errores que son específicos
respecto de un cliente o ambiente de servidor particulares. Se crea una matriz de
referencia cruzada que define todos los probables sistemas operativos,
navegadores, plataformas de hardware y protocolos de comunicación. Entonces
las pruebas se encaminan a descubrir los errores asociados con cada posible
configuración.
La prueba de seguridad incorpora una serie de pruebas diseñadas para explotar
las vulnerabilidades en la WebApp y su ambiente. El objetivo es demostrar la
posibilidad de una brecha en la seguridad.
La prueba de desempeño abarca una serie de pruebas diseñadas para valorar 1)
cómo afecta el aumento del tráfico de usuarios la respuesta en tiempo y confiabilidad de la Web, 2) cuáles componentes de la WebApp son responsables de la
degradación del desempeño y qué características de uso provocan que ocurra la
degradación, y 3) cómo la degradación del desempeño impacta los objetivos y
requisitos globales de la WebApp.