INGENIERE SOFTWARE "

PRUEBAS EN LA INDUSTRIA DEL SOFTWARE

A nivel general se constituye en una característica de la producción industrial, la realización de las pruebas del producto terminado, y a ello no escapa la industria del Software, las cuales se constituyen en un elemento crítico para la garantía de calidad del software y representa una revisión final de las especificaciones del diseño y de la codificación.

La creciente percepción del software como un elemento del sistema y la importancia de los «costes» asociados a un fallo del propio sistema, están motivando la creación de pruebas minuciosas y bien planificadas a fin de que éstas detecten el mínimo de error, ya que ello es garantía para la calidad del producto, traduciéndose en incremento de su competitividad.

Fundamentos de las pruebas de software. La prueba es el proceso de ejecución de un programa con la intención de descubrir un error. Las pruebas son una parte muy importante durante el desarrollo del sistema aunque algunos desarrolladores consideran que son destructivas en lugar de constructivas, sin embargo siguen siendo de gran importancia. Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrar un error no descubierto hasta entonces.

Para poder aplicar los métodos para el diseño de casos de prueba se deben entender algunos principios básicos, dentro de los cuales se encuentran los siguientes:

• A todas las pruebas se les debería poder hacer un seguimiento hasta los requisitos del cliente

• Las pruebas deberían planificarse mucho antes de que empiecen.

• El principio de Pareto es aplicable a la prueba del software.

• Las pruebas deberían empezar por «lo pequeño» y progresar hacia «lo grande».

• No son posibles las pruebas exhaustivas.

• Para ser más eficaces, las pruebas deberían ser realizadas por un equipo independiente.

• La facilidad de prueba del software es simplemente la facilidad con la que se puede probar un programa de computadora.

Se puede medir la facilidad de prueba de un software, de acuerdo a descubrir hasta qué punto cumple con las siguientes características:

• Operatividad: Cuanto mejor funcione, se puede probar de una manera más eficiente.

• Observabilidad: Lo que ves es lo que pruebas.

• Controlabilidad: Cuanto mejor podamos controlar el software, más se puede automatizar y

Optimizar.

• Capacidad de descomposición: Controlando el ámbito de las pruebas, podemos aislar más rápidamente los problemas y llevar a cabo mejores pruebas de regresión.

• Simplicidad: Cuanto menos haya que probar, más rápidamente podremos probarlo. Estabilidad. «Cuanto menos cambios, menos interrupciones a las pruebas.

• Facilidad de comprensión: Cuanta más información tengamos, más inteligentes serán las pruebas.

En el diseño de los casos de prueba se deben encontrar y diseñar pruebas que tengan el mayor número de posibilidades de que ayuden a encontrar muchos errores.

Un sistema se puede probar conociendo la función específica para la que fue diseñado el producto, se pueden llevar a cabo pruebas que demuestren que cada función es completamente operativa y, al mismo, tiempo buscando errores en cada función, o también conociendo el funcionamiento del producto, se pueden 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 de forma adecuada.

La prueba de caja blanca. Denominada a veces prueba de caja de cristal es un método de diseño de casos de prueba que usa la estructura de control del diseño procedimental para obtener los casos de prueba. La prueba de caja blanca del software se basa en el minucioso examen de los detalles procedimentales. Se comprueban los caminos lógicos del software proponiendo casos de prueba que ejerciten conjuntos específicos de condiciones y/o bucles. Se puede examinar el «estado del programa» en varios puntos para determinar si el estado real coincide con el esperado.

La prueba del camino básico. Es una técnica de prueba de caja blanca. El método del camino básico permite al diseñador de casos de prueba obtener una medida de la complejidad lógica de un diseño procedimental y usar esa medida como guía para la definición de un conjunto básico de caminos de ejecución. Para poder realizar este tipo de prueba se requiere del grafo de flujo (o grafo del programa). El grafo de flujo representa el flujo de control lógico.

La prueba del camino básico también se considera una prueba de estructura de control aunque tiene algunas variantes que podrían mejorar el diseño de casos de prueba dentro de los cuales encontramos los siguientes:

o La prueba de condición, es un método de diseño de casos de prueba que ejercita las condiciones lógicas contenidas en el módulo de un programa. Una condición simple es una variable lógica o una expresión relacional, posiblemente precedida con un operador NOT.

o Prueba del flujo de datos. El método de prueba de flujo de datos selecciona caminos de prueba de un programa de acuerdo con la ubicación de las definiciones y los usos de las variables del programa

o Las pruebas de caja negra, también denominada prueba de comportamiento, se centran en los requisitos funcionales del software. O sea, la prueba de caja negra permite al ingeniero del software obtener conjuntos de condiciones de entrada que ejerciten completamente todos los requisitos funcionales de un programa.

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

o Funciones incorrectas o ausentes,

o Errores de interfaz.

o Errores en estructuras de datos o en accesos a bases de datos externas.

o Errores de rendimiento.

o Errores de inicialización y de terminación.

A diferencia de la prueba de caja blanca, que se lleva a cabo previamente en el proceso de prueba, la prueba de caja negra tiende a aplicarse durante fases posteriores de la prueba.

Prueba de entornos especializados, arquitecturas y aplicaciones.

Conforme el sistema se va haciendo más complejo también se requiere que vallan realizando pruebas más especializadas para los entornos, las arquitecturas y sus aplicaciones, y para ello contamos con los siguientes:

Prueba de interfaces gráficas de usuario

Las interfaces gráficas de usuario (IGU) presentan interesantes desafíos para los ingenieros del software. Debido a los componentes reutilizables provistos como parte de los entornos de desarrollo de las GUI, la creación de la interfaz de usuario se ha convertido en menos costosa en tiempo y más exacta.

Prueba de arquitectura cliente/servidor.

La arquitectura cliente-servidor (C/S) representa un desafío significativo para los responsables de la pruebas del software. La naturaleza distribuida de los entornos cliente-servidor, los aspectos de rendimiento asociados con el proceso de transacciones, la presencia potencial de diferentes plataformas hardware, las complejidades de las comunicaciones de red, la necesidad de servir a múltiples clientes desde una base de datos centralizada (o en algunos casos, distribuida) y los requisitos de coordinación impuestos al servidor se combinan todos para hacer las pruebas de la arquitectura C/S y el software residente en ellas, considerablemente más difíciles que la prueba de aplicaciones individuales

Prueba de la documentación y facilidades de ayuda.

Los errores en la documentación pueden ser tan destructivos para la aceptación del programa, como los errores en los datos o en el código fuente. Nada es más frustrante que seguir fielmente el manual de usuario y obtener resultados o comportamientos que no coinciden con los anticipados por el documento. Por esta razón, la prueba de la documentación debería ser una parte importante de cualquier plan de pruebas del software.

Pruebas Funcionales (Caja Negra)

Se denominan pruebas funcionales o Functional Testing, a las pruebas de software que tienen por objetivo probar que los sistemas desarrollados, cumplan con las funciones específicas para los cuales han sido creados, es común que este tipo de pruebas sean desarrolladas por analistas de pruebas con apoyo de algunos usuarios finales, esta etapa suele ser la última etapa de pruebas y al dar conformidad sobre esta el paso siguiente es el pase a producción.

A este tipo de pruebas se les denomina también pruebas de comportamiento o pruebas de caja negra, ya que los testers o analistas de pruebas, no enfocan su atención a como se generan las respuestas del sistema, básicamente el enfoque de este tipo de prueba se basa en el análisis de los datos de entrada y en los de salida, esto generalmente se define en los casos de prueba preparados antes del inicio de las pruebas.

Las pruebas funcionales en la mayoría de los casos son realizadas manualmente por el analista de pruebas,

...