Pruebas y Depuración

La confirmación de un sistema de software es un proceso continuo en cada etapa del ciclo de vida del software. La prueba de los programas sigue siendo la técnica de confirmación de sistemas mas utilizada, por lo que informe se centra en ese tema en su proceso asociado de depuración.

La prueba de los programas es parte del proceso de confirmación que suele realizarse durante la aplicación y también, en una forma distinta, cuando este ha terminado. La prueba consiste en ejercitar el programa utilizando datos similares a los datos reales que harán de ser ejecutados por el programa, observar los resultados y deducir la existencia de errores o insuficiencias del programa a partir de las anomalías de este resultado.

En ocasiones, se piensa que las pruebas y la depuración de programas son una misma cosa. Aunque están muy relacionadas, en realidad son procesos distintos. La prueba es el proceso de establecer la existencia de errores en el programa. Depuración es el proceso de localizar dónde se produjeron esos errores y corregir el código incorrecto.

Es muy importante comprender que la prueba nunca demuestra que un programa es correcto. Siempre es posible que existan errores aun después de la prueba mas completa. La prueba de programas sólo puede demostrar la presencia de errores en un programa, no su ausencia. De acuerdo con Myers, se considera prueba acertada aquella que establece la presencia de uno o más errores en el software objeto de la prueba. Obsérvese la diferencia con la definición normal de prueba acertada, que es una prueba que no descubre anomalías en el resultado.

La prueba de programas es un proceso destructivo. Se diseña para hacer que el comportamiento de un programa sea distinto del que intentaba su diseñador o aplicador. Como es una característica humana natural que un individuo tenga cierta afinidad con los objetos que ha construido, el programador responsable de la aplicación del sistema no es la persona mas apropiada para probar un programa. Psicológicamente, el programador no querrá “destruir” su creación, lo cual hará que, de manera consciente o inconsciente, elija pruebas que fallan, por lo que no serán adecuadas para demostrar la presencia de errores en el sistema.

Por otra parte, el conocimiento detallado de la estructura de un programa o sistema de programación puede ser muy útil para identificar los casos de prueba apropiados, y el aplicador del sistema tiene una parte importante de esto. La clave de una prueba de programa acertada es establecer un ambiente de trabajo donde los aplicadores del sistema y las personas implicadas en estas pruebas realicen una función complementaria. Esto debe incluir la premisa de administración de que los “errores” de los programas son inevitables dada la complejidad de los sistemas implicados y que los errores no son condenables. El proceso de prueba no se debe ver como una amenaza para los individuos que participan en la aplicación, pues eso haría que se sintieran poco inclinados a cooperar con los encargados de realizar las pruebas.

Aunque es una parte del proceso de confirmación total, la prueba es la única técnica utilizada en la mayoría de las organizaciones de programación para confirmar un programa. La inspección y confirmación de programas no son técnicas de confirmación de uso general. Lamentablemente, por si sola, la prueba no puede confirmar totalmente un programa, lo que da como resultado la proliferación de sistemas no confiables.

Además de las técnicas de pruebas de programas, en este informe también se analiza la función de las inspecciones de confirmación formalizadas en el proceso de confirmación de software. El diseño de casos de prueba se ilustra con un ejemplo y se describen los instrumentos de software que se pueden usar en el proceso de pruebas.

Flujo de la Información de la Prueba

El flujo de información para la prueba sigue el esquema descrito en la figura 1.1. Se proporcionan dos clases de entradas al proceso de prueba:

Una configuración del software que incluye la Especificación de requerimientos, la Especificación de diseño y el código fuente; y en

Una Configuración de prueba que incluye un Plan y Procedimiento de prueba, casos de prueba y resultados esperados. En realidad la configuración de prueba es un subconjunto de la configuración del software cuando se considera el proceso de ingeniería del software completo.

Se lleva a cabo la prueba y se evalúa los resultados. O sea, se comparan los resultados de la prueba con los esperados. Cuando se descubren datos erróneos, esto indica la existencia de un error y comienza la depuración.

A medida que se van recopilando y evaluando los resultados de la prueba, comienza a vislumbrarse una medida cualitativa de la calidad y fiabilidad del software. Si se encuentran con regularidad errores serios que requieren modificaciones en el diseño; la calidad y la fiabilidad del software queda en entredicho, siendo necesarias posteriores pruebas. Si, por otro lado el funcionamiento del software parece ser correcto y los errores que se encuentran son de fácil corrección, se puede sacar dos conclusiones:

La calidad y la fiabilidad del software son aceptables

Las pruebas son inadecuadas para descubrir errores serios.

Finalmente, si la prueba no descubre errores, quedará la sospecha que la configuración de la prueba no ha sido la mas optima y que los errores están escondidos en el software. Estos defectos serán descubiertos por el usuario y reparados por el profesional en la etapa de mantenimiento con un costo por arreglo que puede ser entre 40 y 60 veces superior al costo por arreglo en la fase de desarrollo.

Diseño de casos de prueba

Cualquier producto de ingeniería puede ser probado de una de dos formas:

• Conociendo la función especifica para la que fue diseñado el producto, se pueden llevar a cabo pruebas que demuestren que cada función es completamente operativa

• Conociendo el funcionamiento del producto, se puede desarrollar pruebas que aseguren que “todas las piezas encajan”, o sea, que la operación interna se ajusta a las especificaciones y que todos los componentes internos se han comprobado en forma adecuada.

La primera aproximación de prueba se denomina Prueba de la caja negra y la segunda Prueba de la caja blanca.

Prueba de la Caja Blanca

La prueba de la caja blanca es un método de diseño de casos de prueba que usa la estructura de control del diseño procedimental para deribar los casos de prueba. Mediante los métodos de prueba de la caja blanca el ingeniero del software puede derivar casos de prueba que:

• Garanticen que se ejercitan al menos una vez todos los caminos independientes de cada módulo

• Se ejercitan todas las decisiones lógicas en sus caras verdaderas y falsas

• Se ejecutan todos los bucles en sus límites y con sus límites operacionales

• Se ejercitan las estructuras de datos internas para asegurar su validez.

En estas encrucijadas se puede exponer una pregunta razonable: ”¿Por qué gastar tiempo y energía probando y preocupándose de las minuciosidades lógicas cuando podríamos gastar mejor el esfuerzo asegurando que se han alcanzado los requerimientos del programa?”. La respuesta se encuentra en la naturaleza misma de los defectos del software

• Los errores lógicos y las suposiciones incorrectas son inversamente proporcionales a la probabilidad de que se ejecute un camino del programa. Los errores tienden a producirse en nuestro trabajo cuando diseñamos o implementamos funciones, condiciones o controles que se encuentran fuera de los normal. El procedimiento habitual tiende a hacer más comprensible, mientras que el procesamiento de “casos especiales” tiende a caer en el caos.

• A menudo creemos que un camino lógico tiene pocas posibilidades de ejecutarse cuando, de hecho, se puede ejecutar de forma regular. El flujo lógico de un programa a veces no es nada intuitivo, lo que significa que nuestras suposiciones intuitivas sobre el flujo de control y los datos nos pueden llevar a tener errores de diseño que solo se descubren cuando comienza la prueba del camino.

• Los errores tipográficos son aleatorios. Cuando se traduce un programa a código fuente de un lenguaje de programación, es muy probable que se den algunos errores de escritura. Muchos serán descubiertos por los mecanismos de comprobación de sintaxis, pero otros permanecerán indetectados hasta que comience la prueba. Es igual de probable que haya un error tipográfico en un oscuro camino lógico que en un camino principal.

Cada una de estas razones nos da un argumento para llevar a cabo las pruebas de caja blanca. La prueba de caja negra, sin tener en cuenta como sea de completa, puede pasarse los tipos de errores que acabamos de señalar. Como estableció Beizer: “Los errores se esconden en los rincones y se aglomeran en los límites”. Es mucho más fácil de descubrirlos con la prueba de caja blanca.

Pruebas del Camino Básico.

La prueba del camino básico es una técnica de prueba de la caja blanca propuesta inicialmente por Tom McCabe. El método del camino básico permite al diseñador de casos de prueba derivar una medida de complejidad lógica de un diseño procedural y usar esa medida como guía para la definición de un conjunto básico de caminos de ejecución. Los casos de prueba derivados del conjunto básico garantizan que durante la prueba se ejecuta por lo menos una vez cada sentencia del programa.

Notación de grafo de flujo

Antes de considerar el método del camino básico se debe introducir una sencilla notación para la representación del flujo de control, denominada grafo de flujo. El grafo de flujo representa el flujo de control lógico mediante la notación ilustrada en la figura 2.1. Cada construcción estructurada tiene un correspondiente símbolo en el grafo de flujo.

Para ilustrar el uso de un grafo de flujo, consideremos la representación del diseño procedural de la figura 2.2.

Aquí, se usa un diagrama de flujo para representar la estructura de control de un programa.

Cuando en un diseño procedural se encuentran condiciones compuestas, la generación del grafo de flujo se hace un poco mas complicada. Una condición compuesta se da cuando aparecen uno o mas operadores booleanos (OR, AND, NAND, NOR lógicos) en una sentencia condicional.

Prueba de Bucles

Los bucles son la piedra angular de la mayoría de los algoritmos implementados en software. Y por ello debemos prestarle normalmente un poco de atención cuando llevamos a cabo la prueba del software.

La prueba de bucles es una técnica de prueba de caja blanca que se centra exclusivamente en la validez de las construcciones de bucles. Se pueden definir cuatro clases diferentes de bucles: Bucles simples, Bucles concatenados, Bucles Anidados, y bucles no estructurado.

Además de un análisis del camino básico que aísle todos los caminos de un bucle, se recomienda un conjunto especial de pruebas adicionales para cada tipo de bucles. Estas pruebas buscan errores de inicialización, errores de indexación o de incremento y errores en los límites de los bucles.

Bucles Simples: A los bucles simples se les debe aplicar el siguiente conjunto de pruebas, donde n es el numero máximo de pasos permitidos por bucle.

Saltar totalmente el bucle.

Pasar una sola vez por el bucle.

Pasar dos veces por el bucle.

Hacer m pasos por el bucle con m<n.

Hacer n-1, n y n+1 pasos por bucle.

Bucles Anidados: Si extendiéramos el enfoque de prueba de los bucles simples a los bucles anidados, el numero de posibles pruebas crecería geométricamente a medida que aumenta el nivel de anidamiento. Esto nos llevaría a un numero impracticable de pruebas. Beizer sugiere un enfoque que ayuda a reducir el número de pruebas:

Comenzar en el bucle más interior. Disponer todos los demás bucles en sus valores mínimos.

Llevar a cabo las pruebas de bucles simples con el bucle mas interno mientras se mantiene los bucles exteriores con los valores mínimos para sus parámetros de iteración. Añadir otras pruebas para los valores fuera de rango o para valores excluidos.

Progresar hacia afuera, llevando a cabo las pruebas para el siguiente bicle, pero manteniendo todos los demás bucles exteriores en sus valores mínimos y los demás bucles anidados con valores “típicos”.

Continuar hasta que se hayan probado todos los bucles.

Bucles Concatenados: los bucle concatenados se pueden probar mediante el enfoque anteriormente definido para los bucles simple, mientras que cada uno de los bucles sea independiente del resto. Por ejemplo, si hay dos bucles concatenados y se usa el contador del bucle 1 como valor inicial del bucle 2, entonces los bucles no son independientes. Cuando los bucles no son independientes, se recomienda usar el enfoque aplicado para los bucles anidados.

Bucles No Estructurados: Siempre que sea posible, esta clase de bucles se deben rediseñar para que se ajuste a las construcciones de la programación estructurada.

Prueba de la Caja Negra

Los métodos de prueba de la caja negra se centran en los requerimientos funcionales del software. O sea, le prueba de la caja negra permite al ingeniero del software derivar conjuntos de condiciones de entrada que ejerciten completamente todos los requerimientos funcionales de un programa. La prueba de la caja negra no es una alternativa a las técnicas de prueba de la caja blanca. Mas bien se trata de un enfoque complementario que intenta descubrir diferentes tipos de errores que los métodos de la caja blanca.

La prueba de la caja negra intenta encontrar errores de las siguientes categorías:

Funciones incorrectas o ausentes

Errores de interfaz

Errores en estructura de datos o en acceso a base de datos externas

Errores de rendimiento

Errores de inicialización y de terminación.

A diferencia de la prueba de la caja blanca, que se lleva a cabo previamente en el proceso de prueba, la prueba de la caja negra tiende a ser aplicadas en posteriores fases de prueba. Ya que la prueba de la caja negra intencionadamente ignora la estructura de control, concentra su atención en el dominio de la información. Las pruebas se diseñan para responder a las siguientes preguntas:

• ¿Cómo se prueba la validez funcional?

• Qué clase de entrada compondrán unos buenos casos de prueba?

• ¿Es el sistema particularmente sensible a ciertos valores de entrada?

• ¿De qué forma están aislados los límites de una clase de datos?

• ¿Qué volúmenes y niveles de datos tolerará el sistema?

• ¿Qué efectos sobre la operación del sistema tendrán combinaciones especificas de datos?

Mediante las técnicas de prueba de la caja negra se derivan un conjunto de casos de prueba que satisfacen los siguientes criterios:

Casos de prueba que reducen, en un coeficiente que es mayor que uno, el numero de casos de prueba adicionales que se deben diseñar para alcanzar una prueba razonable,

Casos de prueba que nos dicen algo sobre la presencia o ausencia de clases de errores asociados solamente con la prueba en particular que se encuentra disponible.

Partición Equivalente

La partición equivalente es un método de prueba de la caja negra que divide el dominio de entrada de un programa en clases de datos de los que se pueden derivar casos de prueba. Un caso de prueba ideal descubre de forma inmediata una clase de error (por ejemplo procesamiento incorrecto de todos los datos de carácter) que de otro modo requerirían la ejecución de muchos casos antes de detectar el error genérico. La partición equivalente se dirige a la definición de casos de prueba que descubran clases de errores, reduciendo así el número total de casos de prueba que hay que desarrollar.

El diseño de casos de prueba para la partición equivalente se basa en una evaluación de las clases de equivalencia para una condición de entrada. Una clase de equivalencia representa un conjunto de estados válidos o inválidos para condiciones de entrada. Típicamente una condición de entrada es un valor numérico especifico, un rango de valores, un conjunto de valores relacionados o una condición booleana (si o no). Las clases de equivalencia se pueden definir de acuerdo a las siguientes directrices:

Si una condición de entrada especifica un rango, se define una clase de equivalencia válida y dos inválidas.

Si una condición de entrada requiere una valor especifico, se define una clase de equivalencia válida y dos inválidas.

Si una condición de entrada especifica un miembro de un conjunto, se define una clase de equivalencia válida y una inválidas.

Si una condición de entrada es booleana, se define una clase válida y una inválida.

Aplicando esas directrices para la derivación de clases de equivalencia, se pueden desarrollar y ejecutar casos de prueba para cada elemento de datos del dominio de entrada. Los casos de prueba se seleccionan de forma que se ejercite el mayor numero de atributos de cada clase de equivalencia a la vez.

Técnicas de Grafos Causa - Efecto

El uso de grafos de causa - efecto es una técnica de casos de prueba que proporciona una concisa representación de las condiciones lógicas y sus correspondientes acciones. La técnica sigue cuatro pasos:

Se listan para un módulo las causas (condiciones de entrada) y los efectos (acciones), asignando un identificador a cada uno de ellos.

Se desarrolla un grafo causa - efecto

Se convierte el grafo en una tabla de decisión

Se convierten las reglas de la tabla de decisión a casos de prueba

Si se ha usado una tabla de decisión como herramienta de diseño, los grafos causa - efecto ya no son necesarios.

Prueba de Corrección

Hemos visto que la prueba se puede usar perfectamente para descubrir errores, pero no se puede usar para demostrar la corrección de un programa. Si se pudiese realizar una herramienta infalible de prueba de la corrección del programa, el esfuerzo de la prueba se reduciría considerablemente, desaparecería la necesidad de modelos de fiabilidad y no existiría mas que una de las mayores contribuciones a la crisis del software (la pobre calidad del software). Las pruebas de correcciones manuales, tales como el uso de inducción matemática o de cálculo de predicado, puede ser de algún valor en la prueba de pequeños programas, pero tienen muy poca utilidad cuando se deben validar grandes subsistemas de software.

Si alguna vez se desarrolla un buen método de propósito general para la prueba de corrección de software, probablemente incluiría lo siguiente:

• Un método validado y que se aplique de forma sencilla para especificar afirmaciones sobre la correcta operación del software.

• Un método para indicar la variación respecto de la operación correcta (errores).

• Una técnica para descubrir la causa del error.

• Una aproximación totalmente automatizada que coja el código fuente o algún otro elemento de la configuración del software (por ejemplo, una representación del diseño) como entrada.

Durante la década pasada se han desarrollado varias aproximaciones automatizadas a la prueba de corrección de software de computadoras. Las herramientas automatizadas de comprobación de la corrección, que no se deben confundir con las herramientas automáticas de prueba, generalmente encierran una especificación formal de la lógica del programa. Esa especificación se puede obtener con un macrocompilador que produzca una representación simbólica del software. La corrección de un programa es “comprobada” mediante el uso de técnicas automatizadas [SMI85] basada en la teoría de la inteligencia artificial y del cálculo de predicados.

El proceso de Prueba

Excepto para programas de computador muy pequeños, no es realista intentar la prueba de los sistemas como si se tratara de una sola unidad. Los sistemas grandes se componen por subsistemas formados por módulos que, a su vez, pueden componerse de procedimientos. Si se intenta probar el sistema como una sola entidad, es posible que no se identifiquen más que un pequeño porcentaje de “errores”. El proceso de prueba, al igual que el de programación, debe avanzar en etapas, siendo cada una de ellas la continuación lógica de la anterior.

En el proceso de prueba se pueden encontrar 5 etapas:

Prueba de Unidad. Este tipo de prueba es considerada una de las primordiales ya que los resultados obtenidos de esta repercutirá directamente en la ejecución de las demás pruebas. El modo de operación de este tipo de prueba se basa directamente en concepto de caja blanca controlando, a base de condiciones limites, el buen funcionamiento interno del módulo, esto se refiere al manejo de flujos de datos internos en el módulo controlando las iteraciones, bucles y comparaciones que este realice para verificar todos los posibles caminos que puedan tomar la información recibida. Si los datos no son ingresados correctamente, o no se tratan de igual manera, esto nos indicará especialmente problemas en los cálculos internos como por ejemplo:

• Precedencia aritmética incorrecta o mal interpretada

• Operaciones de modo mixto

• Inicializaciones incorrectas

• Falta de precisión

• Incorrecta representación simbólica de una expresión

Tomando en cuenta los errores antes mencionados, las pruebas de unidad deben descubrir errores como:

• Comparaciones entre tipos de datos distintos

• Operadores lógico o precedencia incorrecta

• Igualdad esperada cuando los errores de precisión la hacen poco probable

• Variables o comparadores incorrectos

• Terminación de bucles inapropiada o inexistente

• Fallo de salida cuando se encuentra una iteración divergente

• Variables de bucle modificadas de forma inapropiadas

Las pruebas de límites son las últimas y probablemente las mas importantes dentro de las pruebas de unidad, ya que normalmente un software falla en sus condiciones límites, o sea, cuando sus datos son tratados a n repeticiones. Los casos de prueba que ejercitan las estructuras de datos, el flujo de control y los valores de datos por debajo, en y por encima de los máximos y los mínimos son muy apropiados para descubrir este tipo de errores.

Prueba de Integración: Dando un caso como ejemplo, una persona después de terminar las pruebes de unidad en todos los módulos que intervienen en el programa y que estos los hayan pasado sin ningún problema, podría considerar que el programa en su totalidad debería funcionar sin problemas; lo cual no es cierto, porque uno es fusión total de todos los módulos que fueron probados de manera independiente que fueron probados de una sola vez, nos produciría el concepto de Big-Bang y es casi seguro que se llegará a un caos total debido a que los errores producidos serán muy difícil aislarlos y a su vez corregirlos. A este concepto se aplica la prueba de integridad con la finalidad de producir la antítesis de Big-Bang.

Las pruebas de integración atacan directamente a un acoplamiento paulatino de los módulos anteriormente probados, este tipo de prueba maneja dos conceptos fundamentales,

Integración Descendente y Integración Ascendentes

Integración Descendente. Esta ataca directamente a la implementaron de los módulos desde el programa principal hacia los módulos inferiores de manera jerárquica. El modo de funcionamiento consiste en que el modulo de control principal maneje toda la información de las pruebas y las distribuya directamente a los módulos que se encuentren inmediatamente subordinados, y a su ves estos van realizando el mismo procedimiento a sus módulos dependientes. Hay que tener presente que las pruebas se tienen que realizar cada ves que se va incorporando un nuevo módulo.

La estrategia descendente suena relativamente fácil, pero en la realidad pueden producirse algunos problemas logísticos que podrían llegar a repercutir en los resultados de nuestras pruebas, esto se refiere a, que ocurriría si un módulo de nivel jerárquico superior depende de cálculos realizados en un módulo de nivel inferior. El encargado de realizar la prueba tiene tres opciones ante esta problemática:

Retrasar muchas de las pruebas hasta que se fusionen los módulos faltantes.

Realizar resguardos que realicen funciones limitadas que simulen los módulos reales.

Integrar el software desde el fondo de la jerarquía hacia arriba.

La primera aproximación hace que perdamos cierto control sobre la correspondencia de ciertas pruebas especificas con la incorporación de estos módulos y por ende el control que realicemos no será tan exacto y acabado , además de producir incongruencia en los resultados, por ende, dificulta la determinación de la causa del error y tiende a violar la naturaleza altamente de restrictiva de la aproximación descendente. La segunda aproximación es factible, pero puede llevar a un significativo incremento del esfuerzo a medida que los resguardos se hagan mas y mas complejos.

Integración Ascendente: Las pruebas de integración ascendente, como su nombre lo indica, consiste básicamente en tratar el módulo atómico (módulo de nivel jerárquico mas bajo) hacia arriba. Dado que los módulos son integrados de abajo hacia arriba, e procesamiento requerido de los módulos subordinados siempre esta disponible y se elimina la necesidad de resguardo.

Una estrategia de integración ascendente puede ser implementada mediante los siguientes pasos:

Se combinan los módulos de bajo nivel en grupos que realicen una función especifica del software.

Se escribe un conductor (Programa de control de la prueba) para coordinar la entrada y la salida de los casos de prueba.

Se prueba el grupo.

Se eliminan los conductores y se combinan los grupos moviéndose hacia arriba por la estructura del programa.

A medida que la integración progresa hacia arriba, disminuye la necesidad de conductores de pruebas separados. De hecho si los niveles superiores del programa se integran de forma descendente, se pueden reducir sustancialmente en numero de conductores y se simplifica enormemente la integración de grupos.

Hay muchas discusiones sobre las ventajas y desventajas de las pruebas de integración ascendentes frente a las descendentes, pero los que tenemos que tener claro, que se llegó a la conclusión que las ventajas de una, son las desventajas de la otra.

La selección de un tipo de prueba de integración dependerá directamente del software y a veces del plan del proyecto. En general el mejor compromiso puede ser una aproximación combinada (a veces denominada prueba sándwich) que use la descendente para los niveles superiores de la estructura del programa junto con la ascendente para los niveles subordinados.

A medida que progresen las pruebas de integración , el encargado debe identificar los módulos críticos. Un módulo critico es aquel que tiene una o mas de las siguientes características:

• Esta dirigido a varios requerimientos del software.

• Tiene un mayor nivel de control (Reside relativamente alto en la estructura del programa).

• Es complejo o propenso a errores.

• Tiene unos requerimientos de rendimientos muy definidos

Los módulos críticos deben ser probados lo antes posible. Además las pruebas de regresión se deben centrar en el funcionamiento de los módulos críticos.

Pruebas de Validación. Tras la culminación de las pruebas de integración, el software esta completamente ensamblado como un paquete; se han encontrado y corregido los errores de interfaces, y debe comenzar una serie final de pruebas del software -la prueba de validación. La validación puede ser definida de muchas formas, pero una simple indicación es que la validación se logra cuando el software funciona de acuerdo con las expectativas razonables del cliente. En este punto, un realizador de software estricto podría protestar: “¿Quién o qué es el árbitro de las expectativas razonables?”

Las Expectativas razonables están definidas en la Especificación de Requerimientos del Software. Las especificaciones contiene una sección denominada Criterios de Validación. La información contenida en esa sección forma la base de la aproximación a la prueba de validación.

Criterios de Validación. La validación del software se consigue mediante una serie de pruebas de caja negra que demuestre la conformidad de los requerimientos que fueron entregados con anterioridad. Un plan de prueba traza las pruebas que han de llevarse a cabo, y un procedimiento de prueba define los casos de pruebas específicos que se aplicaran para demostrar la conformidad de los requerimientos.

Una vez que se procede con cada uno de los casos de prueba de validación, puede darse uno de dos condiciones

Las características de funcionamiento o de rendimiento están de acuerdo con las especificaciones y son aceptadas.

Se descubre una desviación de la especificación y se crea una lista de diferencias. Las desviaciones o errores descubiertos en esta fase del proyecto raramente se pueden corregir antes de terminar el plan. A menudo es necesario negociar con el cliente un método para resolver las diferencias.

Pruebas alfa y beta: Es virtualmente imposible que un encargado del desarrollo pueda prever como un cliente usará realmente un programa, se puede interpretar mal las instrucciones de uso, se pueden usar regularmente extrañas combinaciones de datos y una salida que puede estar clara para el que realiza la prueba pero puede resultar ininteligible para un usuario normal.

Al memento de construir un software a medida se llevan a cabo una serie de pruebas de aceptación para que el cliente valide todos los requerimientos. Estas pruebas pueden tener lugar a lo largo de semanas o meses, descubriendo así, errores acumulados que podrían degradar el sistema.

Si el software se desarrolla como un producto para muchos clientes, no es practico realizar pruebas de aceptación para cada una de ellos. La mayoría de los constructores de productos de software llevan a cabo un proceso denominado pruebas alfa y beta para descubrir errores que parezcan que solo el usuario final pueda descubrir.

La prueba alfa es conducida por un cliente en el lugar de desarrollo. Se usa el software de forma natural, con el encargado del desarrollo “mirando por encima del hombro” del usuario y registrando errores y problemas de uso. Las pruebas alfa se desarrollan en un entorno controlado.

La prueba beta se lleva a cabo en uno o mas lugares de clientes por los usuarios finales del software. A diferencia de la prueba alfa, el encargado del desarrollo normalmente no esta presente. Así, la prueba beta es una aplicación “en vivo” del software en un entorno que no puede ser controlado por el equipo de desarrollo. El cliente registra todos los problemas (reales o imaginarios) que encuentra durante la prueba beta e informa a intervalos regulares al equipo de desarrollo. Como resultado de los problemas anotados durante la prueba beta, el equipo de desarrollo del software lleva a cabo modificaciones y así prepara una versión del producto de software para toda la base de clientes.

Pruebas de Recuperación. Muchos sistemas basados en computadoras deben recuperarse de los fallos y resumir el procesamiento en un tiempo previamente especificado. En algunos casos un sistema debe ser tolerante a fallos, o sea, los fallos de procesamiento no deben hacer que cese el funcionamiento de todo el sistema. En otros casos, se debe corregir un fallo del sistema en un determinado periodo de tiempo a riesgo que se produzca un serio daño económico.

La prueba de Recuperación es una prueba de sistema que fuerza el fallo del software de muchas formas y verifica que la recuperación se lleva a cabo apropiadamente. Si la recuperación es automática hay que evaluar la corrección de la reinicializacion, de los mecanismos de recuperación del estado del sistema, de la recuperación de datos y del rearranque. Si la recuperación requiere la intervención humana hay que evaluar los tiempos medios de reparación para determinar si están dentro de los límites aceptables.

Pruebas de Seguridad: Esta pruebas intentan verificar que los mecanismos de protección incorporados en el sistema, lo protejan, de hecho, de la penetración impropia. Durante la prueba de seguridad, el encargado de la prueba juega el papel de un individuo que desea penetrar el sistema. ¡Todo vale! Debe intentar hacerse con las claves de acceso por cualquier medio externo del oficio; debe atacar el sistema con cualquier software a medida, diseñado para romper cualquier defensa que haya sido construida; debe bloquear el sistema, negando así el servicio a otras personas; debe producir a propósito errores del sistema, intentando penetrar durante la recuperación; o debe curiosear en los datos públicos intentando encontrar las claves de acceso al sistema.

Con el suficiente tiempo y los suficientes recursos, una buena prueba de seguridad termina por penetrar el sistema. El papel del diseñador del sistema es hacer que el costo de la penetración sea mayor que el valor de la información obtenida médiate la penetración.

8

1

2

2

2

3

3

3

3

3

4

4

4

4

Prueba

Descendente

Prueba Ascendente

Prueba

Evaluación

Depuración

Modelo de Fiabilidad

Configuración

del software

Configuración

de prueba

Resultado de prueba

Resultados esperados

Tasa de error

Errores

Correcciones

Predicción de fiabilidad

Figura 1.1

Secuencia

IF

While

Case

Figura 2.1

1|

2

3

4

5

6

7

8

9

10

11