PRUEBAS DEL SISTEMA

Definicin

De una manera general es posible definir una prueba como la ejecucin de una aplicacin, o un trozo de cdigo, para identificar uno o varios errores. Se define error como un resultado distinto del resultado esperado.

El proceso de prueba puede definirse como la verificacin dinmica del comportamiento del sistema a partir de un conjunto finito de casos de prueba.

Un aspecto fundamental del proceso de prueba es evaluar la satisfaccin de la especificacin funcional del sistema o requisitos por parte del sistema construido. Para garantizar el nivel de calidad del sistema construido es necesario verificar la correcta y completa implantacin de los requisitos establecidos en las etapas iniciales de desarrollo. Una herramienta adecuada para efectuar esta validacin son las pruebas del sistema.

Las pruebas de sistema buscan discrepancias entre el programa y sus objetivos o requerimientos, enfocndose en los errores hechos durante la transicin del proceso al disear la especificacin funcional. Esto hace a las pruebas de sistema un proceso vital de pruebas, ya que en trminos del producto, nmero de errores hechos, y severidad de esos errores, es un paso en el ciclo de desarrollo generalmente propenso a la mayora de los errores.

Las pruebas de sistema no son procesos para probar las funciones del sistema o del programa completo, porque sta sera redundante con el proceso de las pruebas funcionales. Las pruebas del sistema tienen un propsito particular: para comparar el sistema o el programa con sus objetivos originales (Requerimientos funcionales y no funcionales). Dado este propsito, se presentan dos implicaciones:

 Las pruebas de sistema no se limitan a los sistemas. Si el producto es un programa, la prueba del sistema es el proceso de procurar demostrar cmo el programa, en su totalidad, no resuelve sus objetivos o requerimientos. Las pruebas de sistema, por definicin, son imposibles si no estn los requerimientos por escrito, mensurables para el producto.

Las pruebas de sistema tienen como objetivo ejercitar profundamente el sistema comprobando la integracin del sistema de informacin globalmente, verificando el funcionamiento correcto de las interfaces entre los distintos subsistemas que lo componen y con el resto de sistemas de informacin con los que se comunica.

Antes de poner en funcionamiento el sistema es necesario probarlo es mucho menos costoso encontrar los problemas antes que el sistema se entregue a los usuarios.

Tipos de Pruebas

Pruebas Unitarias

Al desarrollar un nuevo software o sistema de informacin, la primera etapa de pruebas a considerar es la etapa de pruebas unitarias o tambin llamada pruebas de caja blanca (White Box), ests pruebas tambin son llamadas pruebas modulares ya que nos permiten determinar si un modulo del programa est listo y correctamente terminado, estas pruebas no se deben confundir con las pruebas informales que realiza el programador mientras est desarrollando el mdulo.

El principal factor que se debe considerar al inicio de las pruebas es el tamao del mdulo a probar, se debe considerar si el tamao del mdulo permitir probar adecuadamente toda su funcionalidad de manera sencilla y rpida. Tambin es

importante separar los mdulos de acuerdo a su funcionalidad, si los mdulos son muy grandes y contienen muchas funcionalidades, estos se volvern ms complejos de probar y al encontrar algn error ser ms difcil ubicar la funcionalidad defectuosa y corregirla. Al hacer esta labor el analista de pruebas podr recomendar que un modulo muy complejo sea separado en 2 o 3 mdulos ms sencillos.

Este tipo de pruebas debe ser realizado por personal especializado en Software testing, el cual debe estar familiarizado en el uso de herramientas de depuracin y pruebas, as mismo deben conocer el lenguaje de programacin en el que se est desarrollando la aplicacin, en la actualidad existen una gran cantidad de herramientas que apoyan la labor del analista de pruebas, inclusive se pueden conseguir herramientas para cada tipo de lenguaje, estas herramientas pueden facilitar el desarrollo de pruebas, elaboracin de casos de pruebas, seguimiento de errores, etc. Algunas de las herramientas que se utilizan para pruebas unitarias son: JUnit, La Suite de Mercury, CPPUnit etc.

El objetivo fundamental de las pruebas unitarias es asegurar el correcto funcionamiento de las interfaces, o flujo de datos entre componentes.

No es un requisito indispensable la culminacin de todos los mdulos del sistema para iniciar las pruebas, generalmente las pruebas modulares y las pruebas integrales se solapan; en la actualidad algunas metodologas consideran oportuno iniciar la etapa de pruebas unitarias poco despus del desarrollo.

En la Fig. 1 se muestra lo que se considera una representacin clsica de pruebas de caja blanca, en este tipo de pruebas el cubo representara un sistema en donde se pueden observar los diversos componentes que forman parte del mismo, cada uno de estos componentes debe ser probado en su totalidad (valos), y tambin sus interfaces o comunicaciones con los dems componentes (flechas), este tipo de pruebas tambin son llamadas pruebas de caja de cristal ya que este ltimo termino representa mejor el tipo de pruebas.

Pruebas de Integracin

La necesidad de realizar las pruebas de integracin viene dada por el hecho de que los mdulos que forman un programa suelen fallar cuando trabajan de forma conjunta, aunque previamente se haya demostrado que funcionan correctamente de manera individual.

La prueba de integracin es una prueba sistemtica para construir la arquitectura del software, mientras al mismo tiempo, se aplican las pruebas para descubrir errores asociados a la interfaz, asegurndonos que los mdulos que estn relacionados ejecuten correctamente.

A menudo se tiende a intentar una integracin, se combinan todos los componentes por anticipado, se prueba todo el programa como un todo. El objetivo es tomar los mdulos probados en unidad y estructurar un programa que est de acuerdo con el que dicta el diseo.

Con el uso de estas pruebas conseguimos ir formando el programa global a medida que se comprueba como los distintos componentes interaccionan y se comunican libres de errores.

Tipos de Integracin

 Integracin descendente, es una estrategia de integracin incremental a la construccin de la estructura de programas, en el cual se integran los mdulos movindose en direccin hacia abajo por la jerarqua comenzando por el control principal (Programa principal). Los mdulos subordinados de control principal se incorporan en la estructura, bien sea de forma primeroen-profundidad, o de primero-en-anchura. Integracin ascendente, es donde la construccin del diseo empieza desde los mdulos ms bajos hacia arriba (mdulo principal), el procesamiento requerido de los mdulos subordinados siempre est disponible y elimina la necesidad de resguardo. La seccin de una estrategia de integracin depende de las caractersticas depende de las caractersticas del software y, a veces, del plan del proyecto, en algunos de los casos se puede combinar ambas estrategias.

Pruebas del Sistema

Las pruebas del sistema tienen como objetivo ejercitar profundamente el sistema comprobando la integracin del sistema de informacin globalmente, verificando el funcionamiento correcto de las interfaces entre los distintos subsistemas que lo componen y con el resto de sistemas de informacin con los que se comunica. Pruebas

funcionales.

Dirigidas

asegurar

que

el

SI

realiza

correctamente todas las funciones que se han detallado en las especificaciones dadas por el usuario del sistema. Pruebas de comunicaciones. Determinan que las interfaces entre los componentes del sistema funcionan adecuadamente, tanto a travs de dispositivos remotos, como locales. Asimismo, se han de probar las interfaces hombre/mquina. Pruebas de rendimiento. Determinar que los tiempos de respuesta estn dentro de los intervalos establecidos en las especificaciones del sistema.

 Pruebas de volumen. Examinar el funcionamiento del sistema cuando est trabajando con grandes volmenes de datos, simulando las cargas de trabajo esperadas. Pruebas de sobrecarga. Comprobar el funcionamiento del sistema en el umbral lmite de los recursos, sometindole a cargas masivas. El objetivo es establecer los puntos extremos en los cuales el sistema empieza a operar por debajo de los requisitos establecidos. Pruebas de disponibilidad de datos. Consisten en demostrar que el sistema puede recuperarse ante fallos, tanto de equipo fsico como lgico, sin comprometer la integridad de los datos. Pruebas de facilidad de uso. Consisten en comprobar la adaptabilidad del sistema a las necesidades de los usuarios, tanto para asegurar que se acomoda a su modo habitual de trabajo, como para determinar las facilidades que aporta al introducir datos en el sistema y obtener los resultados. Pruebas de operacin. Consisten en comprobar la correcta

implementacin de los procedimientos de operacin, incluyendo la planificacin y control de trabajos, arranque y rearranque del sistema, etc. Pruebas de entorno. Verificar las interacciones del sistema con otros sistemas dentro del mismo entorno. Pruebas de seguridad. Consisten en verificar los mecanismos de control de acceso al sistema para evitar alteraciones indebidas en los datos.

Pruebas de Implantacin

La finalidad de las pruebas de implantacin es doble: Comprobar el funcionamiento correcto del mismo en el entorno de operacin.

 Permitir que el usuario determine, desde el punto de vista de operacin, la aceptacin del sistema instalado en su entorno real, segn el cumplimiento de los requisitos especificados.

Para ello, el responsable de implantacin revisa el plan de pruebas de implantacin y los criterios de aceptacin del sistema, previamente elaborados. Las pruebas las realizan los tcnicos de sistemas y de operacin, que forman parte del grupo de usuarios tcnicos que ha recibido la formacin necesaria para llevarlas a cabo.

Una vez ejecutadas estas pruebas, el equipo de usuarios tcnicos informa de las incidencias detectadas al responsable de implantacin, el cual analiza la informacin y toma las medidas correctoras que considere necesarias para que el sistema d respuesta a las especificaciones previstas, momento en el que el equipo de operacin lo da por probado.

Prueba de Aceptacin

Una prueba de aceptacin es un escenario de utilizacin del sistema y el comportamiento que de l se espera, visto desde la perspectiva del cliente, usuario o sistema externo que interacta con el programa.

Caractersticas: Describe un escenario (secuencia de pasos) de ejecucin o uso del sistema desde la perspectiva del cliente. Puede estar asociada a un requisitos funcional o requisito no funcional Un requisito tiene una o ms PAs asociadas. Cubren desde escenarios tpicos/frecuentes hasta los ms

excepcionales.

 Pueden

tener

infinitas

instanciaciones

(ejecuciones

con

valores

concretos). El diseo de las instanciaciones y su aplicacin es trabajo del tester.

Las pruebas de aceptacin constituyen el criterio de xito en cuanto a la implementacin de un requisito del sistema. Un mismo requisito del sistema puede presentarse en ejecucin como diferentes escenarios (por ejemplo alternativas correspondientes a elecciones que realiza el usuario al interactuar con el sistema). La idea es que junto con la definicin de la unidad de trabajo se definan las pruebas de aceptacin.

Las pruebas de aceptacin deben ser validadas con el cliente y verificadas (en cuanto a correccin y completitud) por otros miembros del equipo asignados a la unidad de trabajo.

Es importante que el analista establezca un orden en las pruebas, desde las correspondientes a escenarios ms tpicos/frecuentes a aquellos ms

excepcionales. ste orden servir de gua de implementacin a los programadores y al trabajo del tester. El programador debera escribir el cdigo con la idea de superar las pruebas de aceptacin de forma incremental, hasta implementar toda la funcionalidad y pasar todas las pruebas de aceptacin. El tester disear, aplicar, y documentar una o ms pruebas instanciadas (con valores concretos) para cada prueba de aceptacin.

Pruebas de Regresin

Las pruebas de regresin se realizan generalmente despus de la correccin de un defecto o despus de la adicin de nuevas funcionalidades. Su objetivo es asegurar que ningn defecto se aadi al sistema despus de la modificacin. No sirve para nada hacer pruebas en un sistema, pero despus de modificaciones no

hacer de nuevo las mismas pruebas, eso no va asegurar que el sistema no tiene defectos.

Llamamos prueba de regresin, porque tenemos que hacer nuevas pruebas donde se han probado antes. Por lo general, este tipo de pruebas se realiza a travs de herramientas de automatizacin de pruebas, pues muchas veces hay falta de tiempo para ejecutar casos de prueba ya ejecutadas, as las pruebas de regresin se deja a un segundo plano. Sin embargo, este es un grave defecto que los equipos estn poniendo. Las pruebas de regresin, a veces se puede encontrar ms defectos que en la primera prueba, esto es debido al tester tener ms familiaridad con el sistema y al volver a ejecutar los casos de prueba es posible detectar otros tipos de defectos donde en la primera ejecucin fue inadvertido.

Para que las pruebas de regresin sean ejecutadas de manera rpida, es necesario que el lder de calidad tenga ciencia de la necesidad de este tipo de prueba, para que pueda planear la ejecucin de pruebas de regresin y haciendo un aumento del tiempo de la actividad de la prueba.

El plan de casos de prueba de regresin puede ser de tres tipos: Los casos de prueba que cubren toda la funcionalidad del sistema. Los casos de prueba slo para las caractersticas que han sido modificados. Nuevos casos de prueba para las caractersticas que se vieron afectadas probablemente por el cambio.

Las pruebas de regresin es una forma efectiva de reducir la cantidad de defectos que se pueden encontrar en un sistema.