Bienvenido a mi Blog

PRUEBAS DE CAJA BLANCA

También suelen ser llamadas estructurales o de cobertura lógica. En ellas se pretende investigar sobre la estructura interna del código, exceptuando detalles referidos a datos de entrada o salida, para probar la lógica del programa desde el punto de vista algorítmico. Realizan un seguimiento del código fuente según se va ejecutando los casos de prueba, determinándose de manera concreta las instrucciones, bloques, etc. que han sido ejecutados por los casos de prueba.

En las pruebas de Caja Blanca se desarrollan casos de prueba que produzcan la ejecución de cada posible ruta del programa o módulo, considerándose una ruta como una combinación específica de condiciones manejadas por un programa.

Hay que señalar que no todos los errores de software se pueden descubrir verificando todas las rutas de un programa, hay errores que se descubren al integrar unidades del sistema y pueden existir errores que no tengan relación con el código específicamente.

 CARACTERÍSTICAS DE LAS PRUEBAS DE CAJA BLANCA.

En las pruebas de Caja Blanca, se pretende indagar sobre la estructura interna del código, omitiendo detalles referidos a datos de entrada o salida. Su objetivo principal es probar la lógica del programa desde el punto de vista algorítmico.

Estas se basan en el diseño de Casos de Prueba que usa la estructura de control del diseño procedimental para derivarlos. Mediante las pruebas de Caja Blanca el ingeniero de software puede obtener Casos de Prueba que:

·         Garanticen que se ejerciten por lo menos una vez todos los caminos independientes de cada módulo, programa o método.

·         Ejerciten todas las decisiones lógicas en las vertientes verdadera y falsa.

·         Ejecuten todos los bucles en sus límites operacionales.

·         Ejerciten las estructuras internas de datos para asegurar su validez.

Las pruebas de Caja Blanca son consideradas entre las más importantes que se aplican a los sistemas, con la que se obtienen como resultados la disminución en un gran porciento el número de errores existentes en el software y por ende una mayor calidad y confiabilidad en la codificación.

CLASIFICACIÓN DE LAS PRUEBAS DE CAJA BLANCA:

Prueba Unitaria

Este tipo de pruebas son ejecutadas normalmente por el equipo de desarrollo, básicamente consisten en la ejecución de actividades que le permitan verificar al desarrollador que los componentes unitarios están codificados bajo condiciones de robustez, esto es, soportando el ingreso de datos erróneos o inesperados y demostrando así la capacidad de tratar  errores de manera controlada.

Objetivo de la Prueba:

Se focaliza en ejecutar cada módulo (o unidad mínima a ser probada, ej = una clase) lo que provee un mejor modo de manejar la integración de las unidades en componentes mayores. Busca asegurar que el código funciona de acuerdo con las especificaciones y que el módulo lógico es válido.

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 a 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.

Compatibilidad

Las pruebas de compatibilidad son muy importantes para mostrar una calidad adecuada en tu software y así verificar que funcionará con normalidad en todos los navegadores o se podrá instalar en todos los sistemas operativos que veas necesario.

La prueba de compatibilidad es uno de los varios tipos de pruebas de software realizadas en un sistema que se construye sobre la base de ciertos criterios y que tiene que realizar una funcionalidad específica en una instalación ya existente / medio ambiente.

Pruebas de regresión:

El objetivo de las pruebas de regresión es garantizar que, ante cualquier modificación al código actual, ya sea por mantenimiento o por la incorporación de nueva funcionalidad, no se vea afectada en el resto de las secciones que integran a la aplicación.

Tanto las pruebas funcionales como las pruebas de regresión pueden ser desarrolladas de forma manual. Sin embargo, la mejor manera es diseñar y construir scripts de pruebas que puedan ejecutarse de forma automática, los beneficios son muchos, entre los cuales tenemos los siguientes:

• Teniendo en cuenta la posibilidad del cambio en los requerimientos funcionales, los scripts para este tipo de pruebas deberán crecer a la par de éstos, y será mejor adaptar el script ante este cambio y ejecutarlo automáticamente tantas veces como se requiera ese mismo número de veces la prueba de forma manual.
• Ante cualquier liberación de una nueva versión del producto, se deberá garantizar la ejecución exitosa del total de pruebas diseñadas (pruebas de regresión), y en definitivo, será mejor tener un set en el que se ejecuten de forma automática que desarrollarlas una a una de forma manual.

Con lo que llevamos visto, podemos darnos cuenta que una prueba que originalmente se diseñó con el propósito de ser una prueba funcional, puede también utilizarse como una prueba de regresión y con esto, tenemos un motivo más a favor del desarrollo de pruebas automatizadas.

Prueba del Camino Básico

La prueba del camino básico es una técnica de prueba de caja blanca propuesta inicialmente por Tom McCabe. 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. Los casos de prueba obtenidos del conjunto básico garantizan que durante la prueba se ejecuta por lo menos una vez cada sentencia del programa

Pasos del diseño de pruebas mediante el camino básico

 • Obtener el grafo de flujo, a partir del diseño o del código del módulo

 • Obtener la complejidad ciclomática del grafo de flujo

• Definir el conjunto básico de caminos independientes

• Determinar los casos de prueba que permitan la ejecución de cada uno de los caminos anteriores

 • Ejecutar cada caso de prueba y comprobar que los resultados son los esperados

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 o grafo del programa.

Para ilustrar el uso de un grafo de flujo, consideremos la representación del diseño procedimental. En ella, se usa un diagrama de flujo para representar la estructura de control del programa.

A continuación, se muestra el grafo de flujo correspondiente al diagrama de flujo.

Cada círculo, denominado nodo del grafo de flujo, representa una o más sentencias procedimentales. Un solo nodo puede corresponder a una secuencia de cuadros de proceso y a un rombo de decisión. Las flechas del grafo de flujo, denominadas aristas o enlaces, representan flujo de control y son análogas a las flechas del diagrama de flujo. Una arista debe terminar en un nodo, incluso aunque el nodo no represente ninguna sentencia procedimental. Las áreas delimitadas por aristas y nodos se denominan regiones. Cuando contabilizamos las regiones incluimos el área exterior del grafo, contando como otra región más.

Complejidad ciclomática

La complejidad ciclomática es una métrica del software que proporciona una medición cuantitativa de la complejidad lógica de un programa, es decir es una medida que proporciona una idea de la complejidad lógica de un programa. Cuando se usa en el contexto del método de prueba del camino básico, el valor calculado como complejidad ciclomática define el número de caminos independientes del conjunto básico de un programa y nos da un límite superior para el número de pruebas que se deben realizar para asegurar que se ejecuta cada sentencia al menos una vez.

Prueba de la Estructura de Control

 La técnica de prueba del camino básico es una de las muchas técnicas para la prueba de la estructura de control. Aunque la prueba del camino básico es sencilla y altamente efectiva, no es suficiente por sí sola. La prueba de la estructura de control crea variantes para las del diseño de pruebas. Estas variantes amplían la cobertura de la prueba y mejoran la calidad de la prueba de caja blanca.

Prueba de condición y Prueba de flujo de datos

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.

Una condición compuesta está formada por dos o más condiciones simples, operadores lógicos y paréntesis. Suponemos que los operadores lógicos permitidos en una condición compuesta incluyen OR (“I”), AND (“&”) y NOT (“¬”). A una condición sin expresiones relacionales se la denomina Expresión lógica.

Por tanto, los tipos posibles de componentes en una condición pueden ser: un operador lógico, una variable lógica, un par de paréntesis lógicos (que rodean a una condición simple o compuesta), un operador relacional o una expresión aritmética. Si una condición es incorrecta, entonces es incorrecto al menos un componente de la condición. Los tipos de errores de una condición pueden ser los siguientes:

·         error en operador lógico (existencia de operadores lógicos incorrectos/desaparecidos/sobrantes)

·         error en variable lógica

·         error en paréntesis lógico

·         error en operador relacional

·         error en expresión aritmética.

El método de la prueba de condiciones se centra en la prueba de cada una de las condiciones del programa. Las estrategias de prueba de condición tienen, generalmente, dos ventajas. La primera, que la cobertura de la prueba de una condición es sencilla. La segunda, que la cobertura de la prueba de las condiciones de un programa da una orientación para generar pruebas adicionales del programa.

El propósito de la prueba de condiciones es detectar, no sólo los errores en las condiciones de un programa, sino también otros errores en dicho programa. Si un conjunto de pruebas de un programa P es efectivo para detectar errores en las condiciones que se encuentran en P, es probable que el conjunto de pruebas también sea efectivo para detectar otros errores en el programa P.

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.

Dado que las sentencias de un programa están relacionadas entre sí de acuerdo con las definiciones de las variables, el enfoque de prueba de flujo de datos es efectivo para la protección contra errores. Sin embargo, los problemas de medida de la cobertura de la prueba y de selección de caminos de prueba para la prueba de flujo de datos son más difíciles que los correspondientes problemas para la prueba de condiciones.

En resumen, las pruebas de condición son pruebas que ayudan a ejercitar las condiciones lógicas, es decir, las funciones de las pruebas de condición es probar las todas las condiciones de un programa de software. Si se encontrase un error en las condiciones del programa, ayudaría a encontrar errores en el programa en general.

Prueba de bucles

Los bucles son la piedra angular de la inmensa mayoría de los algoritmos implementados en software. Y sin embargo, les prestamos normalmente poca atención cuando llevamos a cabo las pruebas del software. Como ya se sabe un bucle es una sentencia que se realiza repetidas veces a un segmento aislado de código, hasta que la condición asignada a dicho bucle deje de cumplirse, generalmente un bucle es usado para hacer una acción repetida sin tener que escribir varias veces el mismo código, ahorrando tiempo y organizando mejor el código. 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

·         Bucles no estructurados

PRUEBAS DE CAJA NEGRA

También suelen ser llamadas funcionales y basadas en especificaciones. En ellas se pretende examinar el programa en busca de que cuente con las funcionalidades que debe tener y como lleva a cabo las mismas, analizando siempre los resultados que devuelve y probando todas las entradas en sus valores válidos e inválidos.

Al ejecutar las pruebas de Caja Negra se desarrollan casos de prueba reales para cada condición o combinación de condiciones y se analizan los resultados que arroja el sistema para cada uno de los casos. En esta estrategia se verifica el programa considerándolo una caja negra. Las pruebas no se hacen en base al código, sino a la interfaz. No importa que se cubran todas las rutas dentro del programa, lo importante es probar todas las entradas en sus valores válidos e inválidos y lograr que el sistema tenga una interfaz amigable.

La prueba de caja negra pretende demostrar:

• Las funciones del software son operativas

• La entrada se acepta de forma correcta

• Se produce una salida correcta

• La integridad de la información externa se mantiene

A continuación, se derivan conjuntos de condiciones de entrada que utilicen todos los requisitos funcionales de un programa. Las pruebas de caja negra pretenden encontrar estos tipos de errores:

• Funciones incorrectas o ausentes

• Errores en la interfaz

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

• Errores de rendimiento

• Errores de inicialización y de terminación Los tipos de prueba de cana negra que vamos a estudiar son:

• Prueba de partición equivalente

• Prueba de análisis de valores límites

CLASIFICACIÓN DE LAS PRUEBAS DE CAJA NEGRA:

Prueba Integración

Pruebas de Integración: este tipo de pruebas son ejecutas por el equipo de desarrollo y consisten en la comprobación de que elementos del software que interactúan entre sí, funcionan de manera correcta.

Objetivo de la Prueba:

Identificar errores introducidos por la combinación de programas probados unitariamente. Determina cómo la base de datos de prueba será cargada. Verificar que las interfaces entre las entidades externas (usuarios) y las aplicaciones funcionan correctamente. Verificar que las especificaciones de diseño sean alcanzadas. Determina el enfoque para avanzar desde un nivel de integración de las componentes al siguiente.

Descripción de la Prueba:

·Describe cómo verificar que las interfaces entre las componentes de software funcionan correctamente. ·Determina cómo la base de datos de prueba será cargada. ·Determina el enfoque para avanzar desde un nivel de integración de las componentes al siguiente. ·Decide qué acciones tomar cuando se descubren problemas. Por cada Caso de Prueba ejecutado: ·                     Comparar el resultado esperado con el resultado obtenido.

Validación

Las pruebas de validación empiezan tras la culminación de la prueba de integración, cuando se han ejercitado los componentes individuales. Se ha terminado e ensamblar el software como paquete y se han descubierto y corregido los errores de interfaz.

La prueba se concentra en las acciones visibles para el usuario y en la salida del sistema que este puede reconocer. La validación de define de una forma simple en que se alcanza cuando el software funciona de tal manera que satisface las expectativas razonables del cliente (especificación de requisitos de validación).

La validación del software se logra mediante una serie de pruebas que demuestren que se cumple los requisitos.

Prueba GUI (Interfaz de usuario)

Las interfaces gráficas de usuario (IGUs) 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 menos costosa en tiempo y más exacta. Al mismo tiempo, la complejidad de las IGUs ha aumentado, originando más dificultad en el diseño y ejecución de los casos de prueba.

Las pruebas de interfaces son particularmente importantes para el desarrollo orientado a objetos y basado en componentes. Los objetos y los componentes se definen por sus interfaces y pueden ser reutilizados en combinación con otros componentes en sistemas diferentes. Los errores de interfaz en el componente compuesto no pueden detectarse probando los objetos individuales o componentes.

Integración Incremental

Al realizar una integración incremental debemos combinar o unir el siguiente modelo que se debe probar con el conjunto de módulos ya probados. El número de módulos se incrementa progresivamente hasta formar el programa completo. Esto lo podemos realizar en dos formas.

• Integración Incremental Ascendente.

• Integración Incremental Descendente.

Integración incremental ascendente:

En este tipo de integración se combinan los módulos de más bajo nivel en grupos que realizan alguna sub función específica.

Atreves de un driver (módulo impulsor) se simulan llamadas a los módulos, se introducen los datos de prueba y se recogen los resultados.

Cada grupo se prueba usando un driver (test integrador), y este luego es sustituido por los módulos de nivel superior en la jerarquía. En el último paso se prueba el programa completo con sus entradas y salidas reales.

Ejemplo: Para probar un sistema bancario, se debe empezar por los módulos que aplican lógica de negocio y que hacen cambios en la base de datos, una vez que cada uno de estos módulos funciona correctamente, se inicia las pruebas de niveles superiores, los cuales básicamente hacen llamadas a estos módulos de bajo nivel, esta segunda etapa normalmente es mucho más rápida.

Tal como se muestra en la siguiente figura, luego de probar los módulos de más bajo nivel, continuamos con los módulos del siguiente nivel, para esto debemos construir nuevos drivers o impulsores (B y C), que se aplicarán directamente a los módulos superiores (B y C) y estos a su vez se integrarán a los de más bajo nivel.

La integración incremental descendente:

Los módulos se incorporan iniciando del módulo de control principal (de mayor nivel) para luego ir incorporando los módulos subordinados progresivamente. No hay un procedimiento considerado óptimo para seleccionar el siguiente módulo a incorporar. La única regla es que el módulo incorporado tenga todos los módulos que lo invocan previamente probados.

En general no hay una secuencia óptima de integración. Debe estudiarse el problema concreto y de acuerdo a este, buscar el orden de integración más adecuado para la organización de las pruebas. No obstante, pueden considerarse las siguientes pautas:

• Si hay secciones críticas como ser un módulo complicado, se debe proyectar la secuencia de integración para incorporarlas lo antes posible.

• El orden de integración debe incorporar cuanto antes los módulos de entrada y salida.

Prueba de Seguridad

Objetivo:

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.

Áreas:

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

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

Garantiza:

Que los usuarios están restringidos a funciones específicas o su acceso está limitado únicamente a los datos que está autorizado a acceder.

Que solo aquellos usuarios autorizados a acceder al sistema son capaces de ejecutar las funciones del sistema.

Objetivos específicos de seguridad de cada sistema.

Partición Equivalente

Los datos de entrada y los resultados de salida de un programa normalmente se pueden agrupar en varias clases diferentes que tienen características comunes tales como números positivos, números negativos y selecciones de menús. Los programas normalmente se comportan de una forma similar para todos los miembros de una clase. Es decir, si se prueba un programa que realiza algún cálculo y requiere dos números positivos, entonces se esperaría que el programa se comportase de la misma forma para todos los números positivos.

La partición equivalente es un método de prueba de caja negra que divide el campo 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 errores (por ejemplo, proceso 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.

Análisis de valores limite

 Por razones que no están del todo claras, los errores tienden a darse más en los límites del campo de entrada que en el centro por así decirlo. Por ello, se ha desarrollado el análisis de valores límites “AVL” como técnica de prueba. El análisis de valores límite nos lleva a una elección de casos de prueba que ejerciten los valores límite. El análisis de valores límite es una técnica de diseño de casos de prueba que complementa a la partición equivalente. En lugar de seleccionar cualquier elemento de una clase de equivalencia, el AVL lleva a la elección de casos de prueba en los extremos de la clase.

Prueba de comparación

Hay situaciones, por ejemplo, aviónica de aeronaves, control de planta nuclea en las que la fiabilidad del software es algo absolutamente crítico. En ese tipo de aplicaciones, a menudo se utiliza hardware y software redundante para minimizar la posibilidad de error. Cuando se desarrolla software redundante, varios equipos de ingeniería del software separados desarrollan versiones independientes de una aplicación, usando las mismas especificaciones. En esas situaciones, se deben probar todas las versiones con los mismos datos de prueba, para asegurar que todas proporcionan una salida idéntica. Luego, se ejecutan todas las versiones en paralelo y se hace una comparación en tiempo real de los resultados, para garantizar la consistencia. Las aplicaciones de software se que desarrollan de forma redundante o en serie se deben desarrollar en versiones independiente. Estas versiones independientes son la base de una técnica de prueba de caja negra denominada prueba de comparación o prueba mano a mano.

Bibliografía

Blank, I., Herrera, L., & Ortiz, M. (Mayo de 2005). Obtenido de http://carolina.terna.net/ingsw3/datos/Pruebas_Funcionales.pdf

Desconocido. (Martes de Agosto de 2010). Obtenido de http://85517atesting.blogspot.mx/2010/08/pruebas-de-software-testing.html

Frausto, E. (Abril de 2014). Obtenido de http://sg.com.mx/revista/43/pruebas-funcionales-y-regresion-selenium#.VwvfrqR97IU

Iglesias Fraga, D., & Laura , C. M. (2016). Obtenido de http://lbd.udc.es/jornadas2011/actas/PROLE/PROLE/S4/11_article.pdf

Acerca de nosotros: lsi.us.es. (11 de 04 de 2016). Obtenido de http://www.lsi.us.es/docencia/get.php?id=361

Acerca de nosotros: materias.fi.uba.ar. (11 de 04 de 2016). Obtenido de http://materias.fi.uba.ar/7548/PruebasSoftware.pdf

Alvarez, J. (11 de 04 de 2016). Acerca de nosotros: infor.uva. Obtenido de http://www.infor.uva.es/jvalvarez/docencia/tema7.pdf