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.
• 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
muy buena la información, me sirvió de mucho
ResponderBorrarMe da gusto que te haya sido util
BorrarEste comentario ha sido eliminado por el autor.
BorrarExcelente aporte...
BorrarGracias a mi tambien me fue de mucha utilidad esta informacion
BorrarEste comentario ha sido eliminado por el autor.
ResponderBorrarperfecto lo que estaba buscando para análisis de algoritmos, gracias!
ResponderBorrarExcelente información,gracias por el aporte :)
ResponderBorrarmuy buena información compañero pero te ha faltado un poco un videito no sé. xd
ResponderBorrarEsta muy facil de entender los conceptos.
ResponderBorrarPruebas de caja negra: Realizar pruebas de forma que se
compruebe que cada función es operativa.
• Pruebas de caja blanca: Desarrollar pruebas de forma que se
asegure que la operación interna se ajusta a las especificaciones, y
que todos los componentes internos se han probado de forma
adecuada.