Las pruebas en aplicaciones Web, conceptos y clasificación

Las pruebas en aplicaciones Web, conceptos y clasificación

Introducción

El constante desarrollo de las Tecnologías de la Información y las Comunicaciones (TIC) han llevado a la sociedad a insertarse en un mundo, donde el impacto de los Software (SW) ha revolucionado la forma de pensar y actuar de las personas con las que interactúan. La lucha de los grandes productores por ser cada día mejores, al ofrecer productos más baratos y asequibles a los usuarios, ha transformado en pocos años la forma de hacer y desarrollar las actividades; que antes se hacían con otros programas y que ahora se realizan de forma más sencilla, rápida y menos costosa, mediante software de una alta calidad en el mercado mundial.

Hoy es una realidad que existen dificultades en los procesos de pruebas que se deben aplicar durante el desarrollo de aplicaciones web para lograr una satisfacción plena del cliente. Entre ellas podemos mencionar que:

• No existe una metodología que guíe el proceso de aplicación de pruebas en cada una de las fases.

• Existe un diseño incoherente de las pruebas.

• No se realizan pruebas de integración,

• No se revisan los modelos de despliegue.

• No se utilizan herramientas en la realización de pruebas.

1.1 Pruebas

Las pruebas son una actividad en la cual un sistema o componente es ejecutado bajo unas condiciones o requerimientos específicos, los resultados son observados y registrados, y una evaluación es hecha de algún aspecto del sistema o componente. (1)

La prueba es un proceso que se enfoca sobre la lógica interna del software y las funciones externas. La prueba es un proceso de ejecución de un programa con la intención de descubrir un error. Un buen caso de prueba es aquel que tiene alta probabilidad de mostrar un error no descubierto hasta entonces. Una prueba tiene éxito si descubre un error no detectado hasta entonces.

1.2 Objetivos de las Pruebas

• Encontrar y documentar los defectos que puedan afectar la calidad del software.

• Validar que el software trabaje como fue diseñado.

• Validar y probar los requisitos que debe cumplir el software.

• Validar que los requisitos fueron implementados correctamente

• Verificar la interacción de componentes.

• Verificar la integración adecuada de los componentes.

• Verificar que todos los requisitos se han implementado correctamente.

• Identificar y asegurar que los defectos encontrados se han corregido antes de entregar el software al cliente.

• Diseñar pruebas que sistemáticamente saquen a la luz diferentes clases de errores, haciéndolo con la menor cantidad de tiempo y esfuerzo. (2)

1.3 Clasificación y aplicación de Pruebas

Cuando se comienza a trabajar en un software determinado, es necesario realizarles distintos tipos de pruebas, para lograr una buena calidad en el mismo y así lograr la menor cantidad posible de errores. Es por esto que las pruebas se clasifican en dos grandes grupos, ya que toda aplicación puede ser probada bajo los siguientes esquemas:

1) Conociendo la función del producto (programa), demostrar que esa función anda bien. Este caso se realiza sobre las interfaces y se lo denomina PRUEBA DE CAJA NEGRA.

2) Demostrar que la operación interna del módulo se ajusta a lo especificado y que los componentes internos andan bien, (esta prueba se desarrolla en base a los caminos lógicos del módulo, se denomina PRUEBA DE CAJA BLANCA).

Esta última es la prueba que mejor deja ver las dificultades.

Prueba de Caja Blanca:

Permiten examinar la estructura interna del programa. Se diseñan casos de prueba para examinar la lógica del programa. Es un método de diseño de casos de prueba que usa la estructura de control del diseño procedimental para derivar casos de prueba que garanticen que:

1) Que se ejecutan al menos de una vez todos los caminos independientes de cada módulo.

2) Que se prueben todas las decisiones lógicas en sus ramas verdaderas y falsas.

3) Ejecutar todos los bucles o ciclos con los límites que se les haya definido.

4) Ejecutar las estructuras internas de datos para asegurar su validez.

Métodos o Técnicas de Caja Negra:

Son complementarias a las de caja blanca. Pero en la práctica se hace normalmente solo la prueba de caja negra. Las pruebas se llevan a cabo sobre la interfaz del software, y es completamente indiferente el comportamiento interno y la estructura del programa.

Los casos de prueba de la caja negra pretende demostrar que:

• Las funciones del software son operativas.

• La entrada se acepta de forma adecuada.

• Se produce una salida correcta, y

• La integridad de la información externa se mantiene.

La prueba de caja negra responde a las preguntas:

? Qué casos de entrada terminan definiendo buenos casos de prueba.

? Si el sistema es sensible a determinados casos de entrada.

? Qué volúmenes (niveles de datos) tolera el sistema.

2 Realización de las Pruebas.

Las diferentes pruebas que deben realizarse se basan en realizar pruebas a diferentes niveles, es necesario probar si cada unidad funciona, luego es necesario probar si los distintos componentes encajan entre sí y por último es necesario probar el sistema globalmente. Este proceso es algo bastante lógico, pues si por ejemplo sólo se prueba el sistema, sería difícil encontrar determinados tipos de errores.

2.1 Principios básicos de pruebas.

Deben ser llevadas a cabo por personas distintas a los diseñadores de los programas, así se puede verificar además del correcto funcionamiento del programa su correcta concepción e interpretación. (3) Además de seguir estos 10 principios:

1. La prueba puede ser usada para mostrar la presencia de errores, pero nunca de su ausencia.

2. La principal dificultad del proceso de prueba es decidir cuándo parar.

3. Evitar casos de pruebas no planificados, no reusables y triviales a menos que el programa sea verdaderamente sencillo.

4. Una parte necesaria de un caso de prueba es la definición del resultado esperado.

5. Los casos de pruebas tienen que ser escritos no solo para condiciones de entrada válidas y esperadas sino también para condiciones no válidas e inesperadas.

6. Los casos de pruebas tienen que ser escritos para generar las condiciones de salida deseadas.

7. El número de errores sin descubrir es directamente proporcional al número de errores descubiertos.

8. Las pruebas deberían empezar por “lo pequeño” y progresar hacia “lo grande”.

9. Con la excepción de las pruebas de unidad e integración, un programa no deberá ser probado por la persona u organización que lo desarrolló.

10. Las pruebas deberían ser realizadas por un equipo independiente.

2.2 Tipos de Pruebas

Pruebas de Unidad:

La prueba de unidad se centra en el módulo. Usando la descripción del diseño detallado como guía, se prueban los caminos de control importantes con el fin de descubrir errores dentro del ámbito del módulo. La prueba de unidad hace uso intensivo de las técnicas de prueba de caja blanca. (4)

Pruebas de Integración:

El objetivo es coger los módulos probados en la prueba de unidad y construir una estructura de programa que esté de acuerdo con lo que dicta el diseño.

Hay dos formas de integración:

• Integración no incremental: Se combinan todos los módulos por anticipado y se prueba todo el programa en conjunto.

• Integración incremental: El programa se construye y se prueba en pequeños segmentos.

Pruebas del Sistema:

Verifica que cada elemento encaja de forma adecuada y que se alcanza la funcionalidad y el rendimiento del sistema total. La prueba del sistema está constituida por una serie de pruebas diferentes cuyo propósito primordial es ejercitar profundamente el sistema basado en computadora.

Pruebas de regresión:

Las pruebas de regresión son una estrategia de prueba en la cual las pruebas que se han ejecutado anteriormente se vuelven a realizar en la nueva versión modificada, para asegurar la calidad después de añadir la nueva funcionalidad. El propósito de estas pruebas es asegurar que:

• Los defectos identificados en la ejecución anterior de la prueba se han corregido.

• Los cambios realizados no han introducido nuevos defectos o reintroducido defectos anteriores.

Pruebas de Seguridad

La prueba de seguridad intenta verificar que los mecanismos de protección incorporados en el sistema lo protegerán, de hecho, de accesos impropios. Por supuesto, la seguridad del sistema debe ser probada en su invulnerabilidad frente a un ataque frontal, pero también debe probarse en su invulnerabilidad a ataques por los flancos o por la retaguardia.

Durante la prueba de seguridad, el responsable de la prueba desempeña el papel de un individuo que desea entrar en el sistema. ¡Todo vale! Debe intentar conseguir las claves de acceso por cualquier medio, puede atacar al sistema con software a medida, diseñado para romper cualquier defensa que se haya construido, debe bloquear el sistema, negando así el servicio a otras personas, debe producir a propósito errores del sistema, intentando acceder durante la recuperación o debe curiosear en los datos sin protección, intentando encontrar la clave de acceso al sistema, etc. (5)

Con tiempo y recursos suficientes, una buena prueba de seguridad terminaría por acceder al sistema. El papel del diseñador del sistema es hacer que el coste de la entrada ilegal sea mayor que el valor de la información obtenida.

Pruebas carga:

El objetivo de las pruebas de carga es determinar el rendimiento del sistema bajo condiciones de carga que se aproximan a la realidad esperada en producción.

Pruebas de Volumen:

Encontrar debilidades en el sistema al momento de manejar grandes volúmenes de datos durante prolongados períodos de tiempo, el objetivo principal es determinar si la plataforma de integración se degrada o deja de funcionar al manejar grandes volúmenes de datos.

2.3 Estrategias de pruebas del software:

Para conseguir el éxito de las pruebas durante todo el ciclo de vida de una aplicación Web, hay que dividirlas en las siguientes etapas:

• Planificación de las pruebas.

• Diseño de las pruebas.

• Implementación de las pruebas.

• Ejecución de las pruebas.

• Evaluación de las pruebas.

Planificación de las Pruebas.

La fase de pruebas necesita una organización seria y fiable. Las pruebas funcionan cuando encuentran errores. Debe de realizarse una planificación exhaustiva.

Terminación de las Pruebas.

El objetivo de las pruebas consiste en encontrar errores, pero si ya no se encuentran errores (no quiere esto decir que no los haya) debe seguirse un criterio de terminación de las pruebas; el criterio puede ser:

• Cuando el tiempo de la prueba ha expirado.

• Cuando todos los casos de prueba se ejecutan sin error.

Bibliografía

1 Velasco Elizondo Perla Inés . PRUEBA DE COMPONENTES DE SOFTWARE BASADAS EN EL MODELO DE JAVABEANS. http://www.cs.man.ac.uk/~velascop/publ/Tesis.pdf.

2 Departamento de Lenguajes y Sistemas Informáticos. http://lsi.ugr.es/~arroyo/inndoc/doc/pruebas/pruebas_d.php

3 Guia de Tecnicas de Pruebas y Metricas. http://www.lpsi.eui.upm.es/MDes/TfcMetrica/GTPrueb.htm.

4 profesores, Colectivo de. Conferencia de flujo de prueba. http://teleformacion.uci.cu/mod/resource/view.php?id=10817&subdir=/Conferencias_IS2_05-06.

5 Pressman, Roger S. Ingeniería de software un enfoque practico. Quinta Edición. pág. 316

Autor

Ing Edel Avila Cruz

Chinchon83@gmail.com