Pruebas de Software

Pruebas de Software

Básicamente son los procesos que permiten verificar y revelar la calidad de un producto software antes de su puesta en marcha. Básicamente, es una fase en el desarrollo de software que consiste en probar las aplicaciones construidas. Las pruebas de software se integran dentro de las diferentes fases del ciclo de vida del software dentro de la Ingeniería de software. En este sentido, se ejecuta el aplicativo a probar y mediante técnicas experimentales se trata de descubrir qué errores tiene. Para determinar el nivel de calidad se deben efectuar unas medidas o pruebas que permitan comprobar el grado de cumplimiento respecto de las especificaciones iniciales del sistema.

Una prueba es una actividad en la que un sistema o un componente es ejecutado bajo condiciones especificadas, los resultados son observados o registrados, y una evaluación es realizada de un aspecto del sistema o componente. [IEEE Std.610.12-1990].

Otras definiciones de diferentes especialistas de pruebas manifiestan que las pruebas de software son actividades claves para que los procesos de validación y verificación tengan éxito, ya que ayudan a entregar el producto con la calidad suficiente para satisfacer las necesidades del cliente y con la certeza de que el producto cumple las especificaciones definidas.

Por lo que considero que las pruebas pueden considerarse como un proceso que intenta proporcionar confianza en el software y cuyo objetivo fundamental es demostrar al desarrollador y al cliente que el software satisface sus requisitos. Algo importante que se debe tener en cuenta es que las pruebas de software nunca se deben realizar en un entorno de producción.

Pruebas Unitarias

La prueba de unidad es la primera fase de las pruebas dinámicas y se realizan sobre cada módulo del software de manera independiente. Su objetivo es identificar errores introducidos por la combinación de programas o componentes probados unitariamente, para asegurar que la comunicación, enlaces y los datos compartidos ocurran apropiadamente. Se diseñan para descubrir errores o completitud en las especificaciones de las interfaces.

Descripción de la Prueba

• Particionar los módulos en pruebas en unidades lógicas fáciles de probar.

• Por cada unidad hay que definir los casos de prueba (pruebas de caja blanca).

• Para esto los casos de prueba deben diseñarse de forma tal que se recorran todos los caminos de ejecución posibles dentro del código bajo prueba; por lo tanto, el diseñador debe construirlos con acceso al código fuente de la unidad a probar.

• Los aspectos que considerar son los siguientes: Rutinas de excepción, Rutinas de error, Manejo de parámetros, Validaciones, Valores válidos, Valores límites, Rangos, Mensajes posibles.

Técnicas de la prueba

• Comparar el resultado esperado con el resultado obtenido.

• Si existen errores, reportarlos.

Criterio de completitud

• Todas las pruebas planeadas han sido ejecutadas.

• Todos los defectos que se identificaron han sido tenidos en cuenta. 

Consideraciones  Especiales

• Para la elaboración de pruebas unitarias en java se puede utilizar el JUNIT y CACTUS.

Pruebas de sistema

Esta prueba tiene como objetivo verificar que se han integrado adecuadamente todos los elementos del sistema y que realizan las operaciones apropiadas funcionando como un todo. Básicamente la idea de estas pruebas es asegurar la apropiada navegación dentro del sistema, ingreso de datos, procesamiento y recuperación.

Descripción

Las pruebas del sistema deben enfocarse en requisitos que puedan ser tomados directamente de casos de uso y reglas y funciones de negocios. El objetivo de estas pruebas es verificar el ingreso, procesamiento y recuperación apropiado de datos, y la implementación apropiada de las reglas de negocios. Este tipo de pruebas se basan en técnicas de caja negra, esto es, verificar el sistema (y sus procesos internos), la interacción con las aplicaciones que lo usan vía GUI y analizar las salidas o resultados.

En esta prueba se determina qué pruebas de Sistema (usabilidad, volumen, desempeño, etc.) asegurarán que la aplicación alcanzará sus objetivos de negocio.

La prueba de Sistema incluye:

• Prueba funcionalidad.

• Prueba de Usabilidad

• Prueba de Performance.

• Prueba de Documentación y Procedimientos.

• Prueba de Seguridad y Controles.

• Prueba de Volumen.

• Prueba de Esfuerzo (Stress).

• Prueba de recuperación.

• Prueba de múltiples sitios.

Para sistemas web se recomienda especialmente realizar mínimo el siguiente grupo de pruebas de sistema:

• Humo.

• Usabilidad.

• Performance.

• Funcionalidad

La prueba de sistemas es compleja por que intenta validar un numero de caracteriticas al mismo tiempo, a diferencia de otras pruebas que solo se centran en uno o dos aspectos del sistema al mismo tiempo.

Técnica

Ejecute cada caso de uso, flujo básico o función utilizando datos válidos e inválidos, para verificar que:

• Los resultados esperados ocurren cuando se utiliza un dato válido.

• Los mensajes de error o de advertencia aparecen en el momento adecuado, cuando se utiliza un dato inválido.

• Cada regla de negocios es aplicada adecuadamente

Pruebas de Desempeño

El objetivo de esta prueba es validar el tiempo de respuesta para las transacciones o funciones de negocios bajo las siguientes dos condiciones:

• Volumen normal anticipado.

• Volumen máximo anticipado.

 Descripción de la prueba

Las pruebas de desempeño miden tiempos de respuesta, índices de procesamiento de transacciones y otros requisitos sensibles al tiempo. El objetivo de las pruebas de desempeño es verificar y validar los requisitos de desempeño que se han especificado (en este caso, el desempeño ofrecido por el proponente). Las pruebas de desempeño usualmente se ejecutan varias veces, utilizando en cada una, carga diferente en el sistema. La prueba inicial debe ser ejecutada con una carga similar a la esperada en el sistema. Una segunda prueba debe hacerse utilizando una carga máxima. Adicionalmente, las pruebas de desempeño pueden ser utilizadas para perfilar y refinar el desempeño del sistema como una función de condiciones tales como carga o configuraciones de hardware 

Las principales actividades son:

• Comparar el desempeño del sistema actual con los requisitos,

• Poner a punto el sistema para mejorar las métricas de desempeño y proyectar la capacidad futura de carga del sistema.

Los objetivos de nivel de servicio definidos deben guiar la prueba de performance. Algunas características que afectan el desempeño son:

               

• Errores lógicos.

• Procesamiento ineficiente.

• Diseño pobre: muchas interfases, instrucciones y entradas/salidas.

• Cuellos de botella en discos, CPU ó canales de entrada/salida.

• Salidas del sistema.

• Tiempos de respuesta.

• Capacidad de almacenamiento.

• Etc.

Técnica

• Utilizar los procedimientos de prueba desarrollados para las pruebas del modelo del negocio (Pruebas del Sistema).

• Modificar archivos de datos (para incrementar el número de transacciones) o los scripts para incrementar el número de veces que ocurre cada transacción.

• Los scripts deben ser ejecutados en una máquina y deben ser repetidos con múltiples clientes.

Pruebas de Carga

Para este caso, el objetivo de la prueba se basa en que se debe verificar el tiempo de respuesta del sistema para transacciones o casos de uso de negocios, bajo diferentes condiciones de carga.

Descripción de la Prueba

Las pruebas de carga miden la capacidad del sistema para continuar funcionando apropiadamente bajo diferentes condiciones de carga. La meta de las pruebas de carga es determinar y asegurar que el sistema funciona apropiadamente aún más allá de la carga de trabajo máxima esperada. Adicionalmente, las pruebas de carga evalúan las características de desempeño (tiempos de respuesta, tasas de transacciones y otros aspectos sensibles al tiempo).

Técnica 

• Use los scripts desarrollados para Pruebas del Negocio.

• Modifique archivos de datos (para incrementar el número de transacciones o veces que cada transacción ocurre).

Pruebas de Stress

Objetivo de la Prueba: Verificar que el sistema funciona apropiadamente y sin errores, bajo estas condiciones de stress:

• Memoria baja o no disponible en el servidor.

• Máximo número de clientes conectados o simulados (actuales o físicamente posibles).

• Múltiples usuarios desempeñando la misma transacción con los mismos datos. 

Descripción de la Prueba 

Las pruebas de stress se proponen encontrar errores debidos a recursos bajos o completitud de recursos. Poca memoria o espacio en disco puede revelar defectos en el sistema que no son aparentes bajo condiciones normales. Otros defectos pueden resultar de incluir recursos compartidos, como bloqueos de base de datos o ancho de banda de la red. Las pruebas de stress identifican la carga máxima que el sistema puede manejar. El objetivo de esta prueba es investigar el comportamiento del sistema bajo condiciones que sobrecargan sus recursos. No debe confundirse con las pruebas de volumen: un esfuerzo grande es un pico de volumen de datos que se presenta en un corto período de tiempo.

  

Aunque muchas pruebas de esfuerzo representan condiciones que el programa encontrará realmente durante su utilización, muchas otras serán en verdad situaciones que nunca ocurrirán en la realidad. Esto no implica, sin embargo, que estas pruebas no sean útiles. Si se detectan errores durante estas condiciones “imposibles”, la prueba es valiosa porque es de esperar que los mismos errores puedan presentarse en situaciones reales, algo menos exigentes.

Técnica 

• Usar los scripts utilizados en las pruebas de desempeño.

• Para probar recursos limitados, las pruebas se deben correr en un servidor con configuración reducida (o limitada).

• Para las pruebas de stress restantes, deben utilizarse múltiples clientes, ya sea corriendo los mismos scripts o scripts complementarios para producir el peor caso de volumen de transacciones.

Pruebas de Volumen

Se basan en su objetivo de verificar que la aplicación funciona adecuadamente bajo los siguientes escenarios de volumen:

• Máximo (actual o físicamente posible) número de clientes conectados (o simulados), todos ejecutando la misma función (peor caso de desempeño) por un período extendido.

• Máximo tamaño de base de datos (actual o escalado) y múltiples consultas ejecutadas simultáneamente.

Descripción de la Prueba

Las pruebas de volumen hacen referencia a grandes cantidades de datos para determinar los límites en que se causa que el Sistema falle. También identifican la carga máxima o volumen que el sistema puede manejar en un período dado. El objetivo de esta prueba es someter al sistema a grandes volúmenes de datos para determinar si el mismo puede manejar el volumen de datos especificado en sus requisitos.

Técnica

•  Utilizar los scripts diseñados para las pruebas de desempeño.

• Deben usarse múltiples clientes, ya sea corriendo las mismas pruebas o pruebas complementarias para producir el peor caso de volumen  por un período extendido.

• Se utiliza un tamaño máximo de Base de datos y múltiples clientes para correr consultas simultáneamente para períodos extendidos.

Pruebas de Seguridad y Control de Acceso

Objetivos de la Prueba

• Nivel de seguridad de la aplicación: Verifica que un actor solo pueda acceder a las funciones y datos que su usuario tiene permitido.

• Nivel de Seguridad del Sistema: Verificar que solo los actores con acceso al sistema y a la aplicación están habilitados para accederla.

Descripción de la Prueba

Las pruebas de seguridad y control de acceso se centran en dos áreas claves de seguridad:

• Seguridad del sistema, incluyendo acceso a datos o Funciones de negocios y

• Seguridad del sistema, incluyendo ingresos y accesos remotos al sistema.

Las pruebas de seguridad de la aplicación garantizan que, con base en la seguridad deseada, los usuarios están restringidos a funciones específicas o su acceso está limitado únicamente a los datos que está autorizado a acceder. Las pruebas de seguridad del sistema garantizan que solamente aquellos usuarios autorizados a acceder al sistema son capaces de ejecutar las funciones del sistema a través de los mecanismos apropiados.             

Debido a la creciente preocupación de la sociedad por la privacidad de la información, muchos programas tienen objetivos específicos de seguridad. El objetivo de esta prueba es evaluar el funcionamiento correcto de los controles de seguridad del sistema para asegurar la integridad y confidencialidad de los datos. El foco principal es probar la vulnerabilidad del sistema frente a accesos o manipulaciones no autorizadas. Una manera de encontrar esos casos de prueba es estudiar problemas conocidos de seguridad en sistemas similares y tratar de mostrar la existencia de problemas parecidos en el sistema que se examina.

Algunas consideraciones de prueba son:

• Controles de acceso físico.

• Acceso a estructuras de datos específicas a través de los programas de aplicación.

• Seguridad en sitios remotos.

• Existencia de datos confidenciales en reportes y pantallas.

• Controles manuales, incluyendo aquellos para autorización y aprobación, formularios, documentación numerada, transmisión de datos, balances y conversión de datos.

Técnica

• Funciones / Seguridad de Datos: Identificar cada tipo de usuario y las funciones y datos a los que se debe autorizar.

• Crear pruebas para cada tipo de usuario y verificar cada permiso, creando transacciones específicas para cada tipo de usuario.

• Modificar tipos de usuarios y volver a ejecutar las pruebas. En cada caso, verificar si los datos o funciones adicionales quedan correctamente permitidos o denegados.

Conclusión

Como hemos notado, este tema de pruebas de software es muy amplio y con muchas ramas por las cuales nosotros podemos recorrer y entender como estas funcionan y que tan importantes pueden llegar a ser. Como hemos visto las pruebas de sistemas tienen varios tipos de prueba, lo interesante aquí es como todas las pruebas siempre llegan al mismo objetivo, como a pesar de diferentes nombres siempre se están unidas unas de otras, incluso algunas trabajan en conjunto para maximizar los resultados, a lo cual llegamos a obtener resultados óptimos. En conclusión, cualquier tipo de prueba que exista, es de gran importancia para la ingeniería de software ya que estas nos ayudan a detectar gran cantidad de errores, los cuales pueden llegar a convertirse en un gran dolor de cabeza, pero gracias a las pruebas de software este número de errores se reduce considerablemente, y es aquí donde nos damos cuenta de lo valiosas que son.

Referencias Bibliográficas

Pérez, Cervantes, Urbano, Moya. (3 de marzo de 2012). Obtenido de Pruebas de Rendimiento: Tipos y objetivos: http://qatecnico.blogspot.com/2012/03/pruebas-de-rendimiento-tipos-y.html

aracelij. (13 de agosto de 2009). Slideshare. Obtenido de Pruebas De Software: https://es.slideshare.net/aracelij/pruebas-de-software

Gonzales, M. A. (1 de julio de 2014). Slideshare. Obtenido de Pruebas de software: https://es.slideshare.net/miluskaazabachegonzales/pruebas-de-software-36522714

Lemus, G. (27 de abril de 2012). Slideshare. Obtenido de Tipos de pruebas de software: https://es.slideshare.net/GuillermoLemus/tipos-de-pruebas-de-software

Mansilla, R. (4 de novimebre de 2009). Slideshare. Obtenido de Pruebas De Software: https://es.slideshare.net/cliceduca/pruebas-de-software-2420588

Londoño, J. H. (06 de abril de 2005). Obtenido de TIPOS DE PRUEBAS DE SOFTWARE: http://ing-sw.blogspot.com/2005/04/tipos-de-pruebas-de-software.html

catalinocordero. (29 de diciembre de 2014). Slideshare. Obtenido de Tecnicas de Pruebas: https://es.slideshare.net/catalinocordero/unidad-10-tecnicas-de-pruebas

Rodriguez, G. (27 de julio de 2012). Slideshare. Obtenido de Pruebas del software: https://es.slideshare.net/gladisha/pruebas-del-software-13780265