Ava Pruebas Del Software

 

PRUEBAS DEL SOFTWARE INTRODUCCIÓN Una de las características típicas del desarrollo de software es la realización de controles periódicos, normalmente coincidenestos con la terminación de cada unauna de las etapas, del producto o los documentos, controles pretenden hacer evaluación de la calidad de los productos generados para poder detectar posibles defectos. Sin embargo, todo producto software independientemente de estas revisiones debe ser probado mediante su ejecución controlada antes de la entrada en producción. Estas ejecuciones o ensayos de funcionamiento se denominan pruebas. Cuando se desarrolla software, dentro del ciclo de vida se ha establecido formalmente que la prueba es una actividad fundamental dentro de cada una de las etapas del proceso de desarrollo de software, porque a partir de la prueba se determina la calidad de los productos implementados. Desde hace mucho tiempo, la prueba ha sido un tema muy importante en la ingeniería de software, por eso se presenta una revisión técnica sobre la prueba de software, abordando fundamentalmente los enfoques propuestos para probar software construido bajo un enfoque funcional, orientado a objetos y basado en componentes. Las pruebas constituyen un método de verificación y validación de software cuando ya está en forma de código ejecutable. Donde la verificación se define como el proceso de evaluación de un sistema o de uno de sus componentes para determinar si los productos satisfacen las condiciones impuestas al comienzo de dicha fase, y la validación hace referencia al proceso de evaluación de un sistema o de uno de sus componentes durante o al final del proceso de desarrollo para determinar si satisface los requisitos especificados.

LA PRUEBA DEL SOFTWARE La prueba es una actividad fundamental en los procesos de desarrollo de software que permite al desarrollador determinar si el producto generado satisface las especificaciones que han sido establecidas en el diseño, también las pruebas permiten detectar la presencia de errores que pueden generar salidas o comportamientos inapropiados durante su ejecución. De acuerdo a la IEEE, el concepto de prueba se define como una actividad en la cual un sistema o componente es ejecutado bajo condiciones específicas, se observan o almacenan los resultados y se realiza una evaluación de algún aspecto del sistema o componente. Para Myers el probar es el proceso de ejecutar un

 

programa con el fin de encontrar errores. Al hablar de condiciones específicas, se supone una especie de ambiente de operación de la prueba para el cual deben existir determinados valores para las entradas y las salidas, así como también ciertas condiciones que delimitan a dicho ambiente de operación, formalmente esto es conocido como Caso de Prueba. El objetivo de las pruebas es la detección de errores o fallas y defectos en el software, esta es una actividad a posteriori, para la detección de problemas en el software y su rectificación. La mayoría de los estudios revelan que los mejores programadores tienen cierta medida de defectos por cada 1.000 líneas de código, estos defectos no son por negligencia sino que en su aparición influyen múltiples factores como la mala comunicación entre los miembros del equipo que da lugar a malentendidos en los requisitos pedidos. Por todo lo anterior el descubrimiento de un defecto significa un éxito para la mejora de la calidad del software, por eso las recomendaciones de G. J. Myers para las pruebas son las siguientes:

1. 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 se consideran síntomas de un posible defecto en el software.

2. El programador debe evitar probar sus propios programas.   Lo ideal sería que probara el software el peor enemigo de quien lo ha construido, ya que así se aseguraría una búsqueda implacable de cualquier error cometido.

3. Se debe inspeccionar el resultado de cada prueba para descubrir posibles síntomas de defectos.  Lamentablemente es frecuente pasar por alto síntomas bastante claros. Esto invalida todo el esfuerzo realizado en la planificación, diseño y ejecución de pruebas.

4. Al generar prueba, se deben incluir datos de entrada válidos y esperados, asícasos como,de datos no validos e inesperados. 5. Las pruebas se centran en dos objetivos.   Probar si el software no hace lo que debe, y probar si el software hace lo que no debe (provoca efectos secundarios adversos).

6. Se deben evitar los casos no documentados, ni diseñados con cuidado.   Ya que se debe probar una y otra vez el software hasta que queda libre de defectos. No documentar o guardar los casos significa repetir constantemente el diseño de casos de prueba.

7. No deben hacerse planes de prueba suponiendo que no hay defectos   en los programas y dedicando pocos recursos a las pruebas.   Hay que asumir que siempre hay defectos y hay que detectarlos.

 

 

8. La experiencia indica que donde hay un defecto hay otros. Es decir que la probabilidad de descubrir nuevos defectos en una parte del software es proporcional al número de defectos ya descubierto.

9. Las pruebas son una tarea más creativa que el desarrollo de software.  No  N o existen técnicas rutinarias para el diseño de pruebas y hay que recurrir al ingenio para alcanzar un buen nivel de detección de defectos con los recursos disponibles. De acuerdo a estas recomendaciones la filosofía más adecuada para realizar las pruebas 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. Donde un buen caso de prueba es aquel que tiene una gran probabilidad de encontrar un defecto no descubierto aún, ya que el éxito de una prueba consiste en detectar un defecto no encontrado antes. La prueba de software se realiza con el propósito de encontrar algo que difiera de las especificaciones planteadas para el producto o bien, para detectar la presencia de situaciones que pudieran generar resultados inapropiados. En la siguiente tabla se muestran los objetivos, los principios, las características y los atributos principales que deben tener las pruebas: Tabla 1. Objetivos, Principios, y Características Características de los Atributos de la Prueba

Objetivos de las La prueba es un proceso de ejecución de un programa con la intención de descubrir un error. pruebas

Principios de las Pruebas

Un buen caso de prueba es aquel que tiene alta probabilidad de mostrar un error no descubierto hasta entonces. Una prueba tiene éxito si se descubre un error. Hacer un seguimiento de las pruebas hasta los requisitos del cliente Plantear y diseñar las pruebas antes de generar ningún código

El 80% de todos los errores se centran en solo en el 20% de los módulos Empezar las pruebas en módulos individuales y avanzar hasta probar el sistema entero. No son posibles las pruebas exhaustivas Deben realizarse por un equipo independiente al equipo de desarrollo Operatividad Características de un software Objetividad fácil de probar Controlabilidad Capacidad de descomposición Simplicidad Estabilidad Facilidad de comprensión Atributos de una Más alta probabilidad de encontrar un error.

 

buena prueba

No debe ser redundante No debería ser ni demasiado sencilla ni demasiado compleja

TÉCNICAS DE DISEÑO DE CASOS DE PRUEBA El objetivo de las técnicas de diseño de casos de prueba es el de conseguir una confianza aceptable en que se detectarán los defectos existentes sin consumir una cantidad excesiva de recursos, por eso todas las pruebas debe moverse en un equilibrio entre la disponibilidad de recursos y la confianza que aportan los casos para descubrir los defectos existentes. La idea fundamental para el diseño de casos de prueba consiste en la elección de algunas posibilidades de funcionamiento del software que por sus características, se consideren representativas del resto. Así si no se detectan defectos en el software al ejecutar dichos casos, se puede tener un cierto nivel de confianza en que el programa no tiene defectos, la dificultad es saber elegir los casos que se deben ejecutar.

Pruebas de caja blanca: Las pruebas de caja blanca enfocan su atención a los detalles procedimentales del software, por eso la implementación de estas pruebas dependerá de la disponibilidad de código fuente. Este tipo de pruebas, permiten generar casos para ejercitar y validar los caminos de cada módulo, las condiciones lógicas, los bucles y sus límites, así como también para las estructuras de datos. Las pruebas inician con la observación de que un programa difícilmente puede considerarse como probado por completo si su código contiene partes que nunca han sido ejecutadas. Este método analiza la estructura lógica del programa y, para cada alternativa que puede presentarse, los datos de prueba ideados conducirán a ella. Se procura escoger los que verifiquen cada posibilidad en las proposiciones CASE, las cláusulas de cada proposición IF y la condición de terminación de cada ciclo.

Figura 1. Prueba de Caja Blanca

En un programa complejo este método es impráctico, pero en un producto o módulo pequeño es un excelente medio de prueba y depuración. Un buen criterio

 

de prueba para proyectos extensos consiste en aplicar los métodos a cada módulo pequeño conforme se escriba posteriormente se usan esos datos en las secciones más amplias del programa una vez terminadas.   Las pruebas de caja blanca se conocen como pruebas de caja de cristal o pruebas estructurales. La siguiente tabla muestra algunas de las pruebas más significativas dentro de este enfoque: Tabla 2. Pruebas de Caja Blanca

Prueba Prueba de caminos 

Prueba condiciones  

de

Prueba de ciclos   Prueba de definición de datos

Definición En este tipo de prueba se realiza un análisis sobre una representación gráfica de un programa denominada grafo de control. En el grafo los nodos representan bloques de instrucciones de un programa y los flujos de ejecución para dichas instrucciones se representan por medio de aristas. A partir del grafo se identifica un conjunto básico de caminos de ejecución sobre el que se realiza pruebas con el propósito de ejercitar el flujo de ejecución de los caminos en una unidad. Teniendo en cuenta un grafo de control, se genera casos de prueba para elementos individuales de expresiones lógicas, de esta forma se pretende probar cada condición con todas sus posibles alternativas. Donde a partir del grafo de control, pueden generarse casos de prueba para las iteraciones definidas en los programas con el propósito de verificar si se realizan de forma correcta. Estas pruebas son realizadas con el objetivo de encontrar posibles contradicciones o redundancias en la definición de los datos utilizados en el software, para eso se realiza un análisis del comportamiento de cada uno de los datos o cada una de los flujos de ejecución.

Pruebas de caja negra: Las pruebas de caja negra también conocidas como pruebas funcionales o de comportamiento concentran la atención en generar casos de prueba que permitan ejercitar los requisitos funcionales de un programa. Este tipo de pruebas como se concentran en su funcionalidad, mucho del trabajo se realiza interactuando con la interfaz del software. Los casos de prueba generados en este enfoque, se diseñan a partir de valores entrada y salida y de esta forma se determina la validez de una salida para un conjunto de entradas proporcionadas. Los datos de prueba se escogen atendiendo a las especificaciones del problema con el fin de verificar que el programa corra bien. Dentro de los criterios mínimos de guía para elegir los datos de prueba están los siguientes: Valores Fáciles,  El programa se depurará con datos de fácil comprobación; Valores típicos realistas,

 

se ensayará un programa con datos seleccionados para que representen como se aplicará, donde los datos deben ser sencillos, de modo que los resultados sean verificables en forma manual; Valores extremos o Valores ilegales, Cuando en un programa entra basura, su salida habrá de ser un mensaje de error adecuado, por eso es preferible que el programa ofrezca indicación de errores en la entrada y que realice cálculos que sigan siendo factibles luego de desechar la entrada equivocada.

Figura 2: Prueba de Caja Negra

Las pruebas de caja negra permiten detectar errores como funciones incorrectas o ausentes, errores en estructuras de datos, errores de rendimiento, errores de interfaz, y errores de inicialización y terminación, entre otros. Con la aplicación de esa técnica se obtiene un conjunto de pruebas que reduce el número de casos de pruebas y dicen algo sobre la presencia o ausencia de errores, algunas de las pruebas más conocidas se muestran en la siguiente tabla: Tabla 3. Pruebas de Caja Negra

Prueba

Definición

ésta en en dividir los valores válid válidos os y no Partición equivalente  En esta técnica la idea ésta

válidos para entradas y salidas en un número reducido de particiones de tal manera que el comportamiento del software sea el mismo para cualquier valor contenido en una partición particular, esto permite reducir la cantidad de casos de prueba generados en el proceso. Análisis de los Esta técnica se enfoca en la generación de casos de prueba de valores límite  los valores limites bajo la consideración de que existe una tendencia a fallar precisamente cuando el software trabaja con valores extremos de la variable de entrada. Generalmente los valores establecidos para generar los casos de prueba son el mínimo, valores un poco arriba del mínimo, valor máximo y valores un poco arriba del máximo. Pruebas según la Este tipo de prueba la generación de casos se realiza a partir de experiencia (error la intuición y la experiencia, donde se redacta una lista de

 

guessing)  Tablas de decisión 

posibles fallas o de las posibles situaciones en las cuales suele ocurrir algún problema y así desarrollar casos de prueba basados en la información contenida en estas listas. Este tipo de prueba permite permit e describir el comportamiento de un programa a partir de un conjunto de acciones que este realiza cuando se opera bajo determinadas condiciones, estas condiciones pueden ser interpretadas como entradas de un programa y las acciones como las salidas producidas. Para ello se pueden utilizar conectores lógicos y (AND), o (OR) y no (NOT). Al incluir aspectos lógicos este tipo de prueba se hace más rigurosa ya que permite transformar una especificación en lenguaje natural en una especificación más formal.

ESTRATEGIAS DE APLICACIÓN DE PRUEBAS DEL SOFTWARE Una estrategia de prueba integra las técnicas de diseño de casos de prueba en un conjunto de pasos bien planeados que dan como resultado la correcta construcción del software, donde la estrategia proporciona una guía para los desarrolladores del software, para la organización de control de calidad y para el cliente. La estrategia de software incorpora la planificación de la prueba, el diseño de casos de prueba, la ejecución de pruebas y la agrupación, y evaluación de los datos resultantes.

Prueba de unidad La prueba de unidad centra el proceso de verificación en la menor unidad del diseño del software, donde se prueban los caminos de control importantes con el fin de descubrir errores dentro del ámbito de un módulo o función. La complejidad relativa de las pruebas y errores descubiertos se encuentra limitada por los lineamientos establecidos por la prueba de software realizada. Se prueba la Interfaz del módulo para asegurar que la información fluye en forma adecuada hacia y desde la unidad del programa; se analizan las estructuras de datos para asegurar los datos su integridad losque pasos de ejecución del algoritmo;que se prueba lasmantienen condiciones límite paradurante asegurar el módulo funciona correctamente dentro de los límites establecidos por el procesamiento; se activan los caminos básicos de la estructura de control con el fin de asegurar de que las sentencias del módulo se ejecutan una sola vez; y finalmente se prueban todos los caminos de manejo de errores. La siguiente tabla muestra muestra la lista de comprobaciones propuesta por Myers para la prueba de interfaces:

 

Tabla 4: Lista de comprobaciones para la prueba de interf interfaces aces

Lista de comprobaciones ¿Es igual el número de parámetros de entrada al número para la prueba de de argumentos? interfaces de un módulo ¿Coinciden las características (atributos) de los parámetros con los argumentos? ¿Coinciden el sistema de unidades de los parámetros con el correctos de los argumentos? ¿Son el número, atributos y el orden de los argumentos de las funciones incorporadas? ¿Existen referencias o parámetros que no estén asociados con el punto de entrada actual? ¿Entran sólo argumentos alterados? ¿Son consistentes las definiciones de variables globales entre módulos? ¿Se pasan las restricciones como argumentos? ¿Son correctos los atributos de los archivos?

Cuando un módulo tenga operaciones básicas de Entrada/Salida externa, se ¿Son correctas las sentencias de apertura? deben llevar a cabo ¿Coinciden las especificaciones de formato con las pruebas adicionales sentencias de Entrada/Salida?

¿Coincide el tamaño del buffer con el tamaño del registro? ¿Se abren los archivos antes de usarlos? ¿Se tienen en cuenta las condiciones de fin de archivo? ¿Se manejan errores de Entrada/Salida? ¿Hay algún error textual en la información de salida?

Los casos de prueba se diseñan para descubrir errores tales como: Tipificación impropia o inconsistente, Inicialización o valores implícitos erróneos, Nombres de variables incorrectos, Tipos de datos inconsistentes, Desbordamiento o errores en el direccionamiento de memoria. También se diseñan casos de prueba para detectar errores causados por cálculos incorrectos o flujos de control inapropiados tales como: Procedencia aritmética incorrecta mal aplicada, Operaciones de modo mixto, Inicializaciones incorrectas, Falta de precisión, Representación incorrecta de una expresión. Los casos de prueba deben descubrir errores como: Comparaciones entre tipos de datos distintos, Operadores lógicos o de procedencia incorrecta, Terminación de ciclos inapropiada o inexistente, Falta de salida cuando se encuentra una iteración mal aplicada, Variables internas a un ciclo modificadas en forma inadecuada. Entre los errores que deben comprobarse están: La condición de error hace que intervenga el sistema antes que el mecanismo de errores, Descripción ilegible del error, El error señalado no corresponde con el error encontrado, La descripción del error no proporciona suficiente información para ayudar en la localización de la causa del error.

 

La prueba de los límites es la última etapa de la prueba de unidad y quizá la más importante, generalmente los errores de condiciones límite aparecen cuando se procesa el elemento n-ésimo de un arreglo n-dimensional, cuando se hace la iésima repetición de un ciclo de x pasos o cuando se llega a los valores máximo ó mínimo permitidos. La estrategia de planificación y aplicación de las pruebas pretende integrar el diseño de los casos de prueba en una serie de pasos coordinados a través de la creación de distintos niveles de prueba, con diferentes objetivos. Donde permite la coordinación del personal de desarrollo y del cliente, gracias a la definición de los papeles que desempeña cada uno y la forma de llevarlos a cabo. En general, la estrategia de pruebas comienza a nivel de módulo, una vez terminadas, progresan hacia la integración del sistema completo y su instalación, y culminan cuando el cliente acepta el producto y se pasa a su explotación inmediata. 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; luego el software totalmente ensamblado se prueba como un conjunto de pruebas para comprobar si cumple o no los requisitos funcionales como los de rendimientos, seguridad, etc.; posteriormente el software ya validado se integra con el resto del sistema para probar su funcionamiento conjunto; y finalmente 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.

Pruebas de integración Las pruebas de integración están ligadas a la forma de integrar los distintos componentes del software hasta contar con el producto total que debe entregarse, implican una progresión ordenada de pruebas que parte desde los componentes y que culmina en el sistema completo, el objetivo fundamental es probar las interfaces entre componentes o módulos. La prueba de Integración es una técnica sistemática para construir la estructura del programa y al mismo tiempo se llevan a cabo pruebas para detectar errores asociados con la interacción, el propósito es tomar los módulos probados en unidad y estructurar un programa que esté de acuerdo con lo que dicta el diseño. Una vez que los módulos funcionen por separado y hayan pasado la prueba de unidad es necesario realizar las pruebas para ver cómo funcionan juntos todos los módulos, es aquí donde pueden surgir problemas en la unión de los módulos. Los problemas más frecuentes son que los datos se pueden perder en una interfaz, un módulo puede tener un efecto adverso sobre otro módulo, las funciones al combinarse pueden producir el objetivo no deseado, las estructuras de datos globales pueden presentar problemas, entre otros. Existen 2 tipos de integración: La primera es la no incremental, donde se intenta elaborar software en módulos grandes, en otros casos un sólo módulo, pero en

 

ellos es más difícil aislar los errores y cuando alguno de ellos es corregido produce otros errores; la segunda es de tipo incremental en donde se desarrollan módulos pequeños y funcionales que hacen que los errores sean más fáciles de aislar y corregir, es más probable que se puedan probar completamente las interfaces y aplicar un enfoque de prueba sistemático.

Integración Incremental Ascendente: El proceso empieza combinando primero los módulos módulos de más bajo nivel nivel en grupos que realizan alguna sub-función sub -función específica, donde se busca reducir el número de pasos de integración. Luego se describe para cada grupo un módulo impulsor o conductor, que es un módulo que permite 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. Posteriormente, se prueba cada grupo empleando su impulsor y por último se eliminan los módulos impulsores de cada grupo y se sustituyen por los módulos del nivel superior de la jerarquía.

Integración Incremental Descendente: La integración incremental descendente comienza con el módulo de control principal 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, es decir, no se puede dar una regla general que permita determinar la secuencia óptima de incorporación de módulos. 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. La siguiente figura muestra la integración incremental descendente

Figura 3. Integración Incremental Descendente

 

  Las etapas fundamentales de la integración descendente 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 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.

Integración no incremental: En este tipo de integración cada módulo requiere de los siguientes elementos 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. La integración no incremental es el único caso en el que las pruebas de unidad y las de integración están totalmente separadas.

Prueba de aceptación El objetivo de esta prueba es comprobar si el producto está listo para ser implantado para el uso operativo en el entorno del usuario, si la prueba del sistema determinó la capacidad real del sistema y permitió a la organización de desarrollo tener confianza en que estaba listo para su funcionamiento, 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 características principales de esta prueba son las siguientes: Participación del usuario, se enfoca hacia la prueba de los requisitos de usuario especificados, es la fase final del proceso para crear una confianza en que el producto es el apropiado para su uso en explotación. Las recomendaciones generales que pueden darse para la prueba de aceptación son las siguientes: 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á 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 (prueba alfa). En el caso de productos de interés general, se entregan versiones (versiones beta) a usuarios de confianza, sin control directo, que informarán de la opinión que les merece la aplicación.

Prueba de validación y verificación La verificación es un conjunto de actividades que aseguran que el software implementa correctamente una función específica, y la validación se refiere a un

 

conjunto diferente de actividades que aseguran que el software construido se ajusta a los requisitos y necesidades del cliente. La definición de estos dos conceptos envuelve lo que se conoce como calidad del software, en donde los métodos de análisis, de diseño y de implementación actúan para mejorar la calidad al proporcionar técnicas continuas y resultados predecibles. Las revisiones técnicas formales de inspección ayudan a asegurar la calidad la calidad de los productos, a lo largo del proceso la medición y el control se aplican sobre cada elemento de una configuración del software. Es importante mencionar que la validación y verificación abarcan un amplio rango de la calidad del software que incluyen revisiones técnicas formales, auditorías de configuración y calidad, supervisión de rendimiento, simulación, estudio de viabilidad, revisión de la documentación, revisión de la base de datos, análisis de algoritmos, pruebas de desarrollo, prueba de calificación y prueba de instalación. La prueba de validación se logra cuando las expectativas razonables del cliente se cumplen, en donde incluyen la especificación de requisitos, documentos en donde se describen los atributos del software visibles para el usuario, esta información forma la base del enfoque a la prueba de validación. El procedimiento de prueba estará diseñado para asegurar que se satisfacen los requisitos funcionales, que se alcanzan todos los requisitos de rendimiento, que la documentación es correcta y que se alcanzan otros requisitos tales como portabilidad, compatibilidad, recuperación de errores, facilidad de mantenimiento, entre otros.

Prueba del sistema   La 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, el cumplimiento de todos los requisitos funcionales del producto software completo en un entorno de sistema, El funcionamiento y rendimiento en las interfaces hardware, software, de usuario y de operador, la adecuación de la documentación de usuario, la ejecución y rendimiento en condiciones límite y de sobrecarga. Los casos para la prueba del sistema tienen tres fuentes principales para su diseño:   Casos basados en los requisitos gracias gracias a técnicas de caja caj a negra aplicadas aplicadas a las especificaciones



  Casos necesarios necesarios para probar el rendimiento del sistema y de su capacidad funcional (pruebas de volumen de datos, de límites de procesamiento, etc.)



  Casos basados en el diseño de alto alto nivel aplicando técnicas de c aja blanca aplicadas a los flujos de datos de alto nivel (por ejemplo, de los diagramas de flujo de datos).



 

La prueba del sistema tiene la finalidad de verificar que se hayan integrado correctamente cada uno de los elementos del sistema, existen diferentes tipos de pruebas del sistema, algunas de ellas son las siguientes:

Prueba de Recuperación: La prueba de recuperación se hace al sistema forzando a que produzca fallas de software de muchas maneras y verificando que la recuperación se lleve a cabo, ya sea automáticamente o manual, tomando en cuenta los recursos que se requieran para efectuar la recuperación.

Prueba de Seguridad: Esta prueba intenta verificar la aplicación de los mecanismos de protección incorporados en el sistema, donde se realizan pruebas de intrusión tratando de violar la seguridad del sistema, intentando obtener las claves de acceso por cualquier medio externo, bloqueando el sistema, negación de servicio, o curiosear los datos públicos para encontrar una clave de acceso al sistema.

Prueba de Resistencia: Esta prueba  está diseñada para enfrentar a los programas en situaciones anormales, es decir, ejecutar el sistema en forma que demande recursos en cantidad, frecuencia o volúmenes anormales. El encargado de la prueba debe intentar colapsar el sistema y para lograrlo se puede tomar en consideración lo siguiente: Diseñar pruebas especiales que generen 10 o más interrupciones por segundo; incrementar las frecuencias de datos de entrada en un orden de magnitud con el fin de comprobar cómo responden las funciones de entrada; ejecutar casos de prueba que requieran al máximo de memoria o de espacio en disco; ó diseñar casos de prueba que produzcan excesivas búsquedas de datos almacenados en disco.

Depuración  La depuración aparece como resultado de una prueba efectiva, es decir, cuando en un caso de prueba se encuentra un error, la depuración es el proceso que resulta en la eliminación de un error. Se debe tomar en cuenta que la depuración no es una técnica de prueba, aunque siempre se da como consecuencia de la prueba. El proceso de depuración comienza en los casos de prueba, se evalúan los resultados y resulta una falta de correspondencia entre los esperados y los reales, el proceso de depuración intenta hacer corresponder el sistema con una causa, llevando así a la corrección del error.

 

  Figura 4. Depuración de errores

La depuración tiene como objetivo principal encontrar y corregir la causa de un error en el software. Existen 3 enfoques que se pueden proponer en la depuración:     La categoría categorí a de depuración "eliminación "eliminación de causas" se manifiesta mediante inducción o deducción. Los datos relacionados con la ocurrencia del error se organizan para llegar a las posibles causas; se desarrolla una lista de las causas y se llevan a cabo las pruebas para eliminar cada una.   La categoría de depuración por "fuerza bruta" es la categoría probablemente la más común y la menos eficiente en el momento de aislar la causa del error del software en donde se confía que en algún lugar de la gran cantidad de información producida nos puede llevar finalmente al éxito, lo más frecuente es que se desperdicie tiempo y esfuerzo.   La vuelta atrás es es el enfoque enfoque más normal para la depuración, depuración, que se puede usar con gran éxito en programas pequeños. Partiendo de donde se detecta el error hacia atrás en el código fuente hasta llegar a la posición del error.







PRUEBA DE SOFTWARE PARA OBJETOS El software construido a partir del modelo orientado a objetos también requiere ser sometido a pruebas con el propósito de garantizar su calidad. En términos generales, se puede decir que los dos enfoques más representativos en materia de pruebas, de caja blanca y de caja negra, son aplicables al software orientado a objetos en cierta medida. Sin embargo, existen algunas características del software orientado a objetos que generan problemas adicionales no cubiertos por las técnicas tradicionales de prueba.

 

 

Métodos de prueba de software orientado a objetos. Muchas de las generalidades de los métodos de prueba tradicionales han sido adaptadas considerando las características del modelo orientado a objetos, con el propósito de que puedan ser aplicables en este nuevo contexto. Actualmente, existen muy pocas investigaciones sobre el estudio de prueba de software orientado a objetos; ya que el área de prueba de software es bastante compleja y dentro de este marco de objetos existe una carencia de métodos robustos para garantizar la realización de las pruebas de forma eficaz. En este panorama se presenta el estado actual en cuanto a prueba de software orientado a objetos en términos del nivel de prueba.

Pruebas de unidad En el software orientado a objetos la menor unidad a considerar para realizar una prueba es la clase. La prueba de clases en el ámbito de software Orientado a Objetos es equivalente a la prueba de unidad realizada al software tradicional. Esta prueba está fundamentalmente dirigida a las operaciones encapsuladas por la clase, así como al estado y comportamiento del objeto que se implementa en ella. El énfasis de la prueba de unidad es verificar que esta pequeña unidad trabaje correctamente en forma aislada, antes de proceder a integrarla en el sistema. Los métodos contenidos en una clase pueden ser muchos y una operación en particular de ese conjunto, a consecuencia de la herencia, puede existir como parte de varias clases diferentes. Por lo tanto el significado de prueba de unidad cambia en muchos sentidos y es importante diseñarla bajo ciertas consideraciones. Se han propuesto estrategias para llevar a cabo las pruebas de unidad considerando aspectos como el orden en que los métodos son sometidos a la prueba, el orden en que una jerarquía de clases puede ser probada, ejercitar el flujo de datos o bien el análisis del estado del objeto. Los aspectos que deben considerarse para construir casos de prueba para una clase deben verificar que esta proporcione los servicios que promete, que responda correctamente a las condiciones esperadas y, más aún, ante las inesperadas. Aspectos adicionales pueden el verificar si la clase contiene y permite disponer de todas las funciones asociadas a ella o que cada método de la clase ejecute su responsabilidad especificada. Algunas de las técnicas más populares para realizar pruebas de unidad se muestran en la siguiente tabla:

 

Tabla 5. Pruebas de Unidad de Software Software Orientado a Objetos

Prueba Pruebas estructurales

Definición

Prueba de valores limite

Prueba estados

basada

en

Prueba incremental

Si se tiene la disponibilidad de código fuente, pueden realizarse pruebas estructurales a las unidades sometidas a la prueba. Las acciones de esta actividad pueden diseñarse con el propósito de ejercitar todas las rutas del código, las condiciones establecidas o bien las ciclos definidos en el programa.  Mediante esta técnica se prueba la unidad bajo situaciones inusuales o extremas, con el propósito verificar cómo son manejadas por el software. Para ello, los casos de prueba suministrados son diseñados considerando valores frontera, es decir los valores mínimo y máximo que la unidad puede aceptar, así como también aquellos valores cercanos a las fronteras identificadas.   Para esta técnica, se generarán casos de prueba para un contexto en donde una clase se modela como una máquina de estados con secuencias de transiciones, con esto se pretende analizar el estado de los objetos de acuerdo a su comportamiento. Una vez que se ha establecido modelo estados en con labase en los atributos delunobjeto, se de consideran prueba los métodos necesarios para poder observar los cambios de estado. La aplicación de esta técnica permite observar alguna de las siguientes situaciones: se produce un cambio a un estado correcto, se produce cambio a un estado incorrecto, no hay cambio de estado, se produce un estado indefinido correcto o bién, se produce un estado indefinido incorrecto.  La prueba incremental dirige su atención a las subclases generadas como consecuencia de la herencia, siendo la clase padre una clase previamente probada. Aunque existen situaciones en las que éste tipo de pruebas se descarta, se pueden identificar algunas en las que no estarían de más: cuando se han agregado o modificado propiedades y/o métodos, cuando existen propiedades y métodos que se han heredado y no se han alterado, pero que realizan algún tipo de interacción con elementos nuevos o modificados.

Pruebas de integración. Cuando se aplican pruebas de integración al software orientado a objetos, se pretende demostrar que las unidades que ya han sido sometidas a un proceso de prueba y funcionan correctamente, lo hacen de igual forma cuando interactúan y se integran con otras unidades del sistema. Prácticamente, el trabajo de esta prueba se concentra en la interacción de métodos en diferentes unidades.

 

Existe una coincidencia en los dos enfoques para realizar este tipo de pruebas: el basado en hilos y el basado en uso. En el primero, pretende que todas las clases respondan a sencillas entradas externas, provenientes de otra unidad. De esta forma, se realizan casos de prueba para cada clase en la unidad, con lo cual un hilo de este conjunto se ejercita. En el enfoque basado en uso, se realizan pruebas para clases las cuales usan servicios de otras clases. En la siguiente tabla se presentan algunos métodos para realizar pruebas de integración: Tabla 6. Pruebas de Integración de Software Orientado a Objetos

Prueba Definición Método de Caminos Este método se concentra principalmente en probar aquellos caminos que se generan por un evento de entrada y terminan de Mensajes  El método Overbek 

de

El método de Kung 

con un evento de salida En este método se prueban las clases por pares, donde una hace el papel de cliente y otra el de servidor, estableciéndose para estas dos conjuntos de pruebas. El primer conjunto, son pruebas orientadas a verificar si los mensajes de entrada y de salida generados son correctos; es decir si se usa correctamente cualquier clase servidora y si todas las secuencias de operaciones son correctas. En el segundo conjunto se verifica además de lo anterior, si la clase cliente siempre satisface las precondiciones de la clase servidora, así como también si satisface las salidas esperadas por la clase servidora. Este método emplea una estrategia de ingeniería en reversa sobre el código de las unidades con el propósito de generar un diagrama de relaciones entre objetos. A partir de este diagrama se propone un orden para las pruebas que minimiza el uso de cabos. El diagrama se convierte en un grafo acíclico, que puede contener varios clústeres de objetos y los ordenan topológicamente. Su método involucra las etapas de pruebas de unidad y de integración y puede usarse también para pruebas de regresión.

Pruebas de sistema. Las pruebas de unidad se concentran en verificar si las funcionalidades descritas en las especificaciones o en los requisitos iniciales corresponden a las que se presentan en el producto final. En esta área, al igual que la de pruebas de integración, se han generado pocos trabajos, por lo que se emplean muchos de los métodos tradicionales.

 

Tabla 7. Pruebas de Sistema de Software Orientado a Objetos

Prueba Prueba de función 

Pruebas de aceptación 

Prueba bajo stress 

Definición La prueba de función comúnmente es llllevada evada a cabo por el grupo de personas que desarrollaron el producto. Este enfoque se orienta a confirmar que la aplicación alcanza los requerimientos y la funcionalidad especificadas por el usuario En este tipo tip o de pruebas, versiones que aún no han sido liberadas en el mercado, son ofrecidas a ciertos grupos de usuarios con el propósito de que las utilicen. El propósito de ésto es que los usuarios reporten defectos que pudieran presentarse. Para realizar esta prueba, el sistema somete a condiciones extremas de trabajo, como pueden ser un alto volumen de transacciones o un gran número de usuarios. Aplicando este enfoque, se puede verificar si el sistema se comporta como se espera aún ante este tipo de escenarios.