Ingenieria del software: prueba de la caja blanca y camino básico
Enviado por cesar javier perez pincay
La fase de pruebas es una de las más costosas del ciclo de vida software en sentido estricto deben realizarse pruebas de todos los artefactos generados durante la construcción de un producto, lo que incluye especificaciones de requisitos, casos de uso, diagramas de diversos tipos y el código fuente y lo productos que forman parte de la aplicación de esta forma se aplican diferentes técnicas de prueba a cada tipo de producto software.
Según el estudio el fundamento de prueba de Software es un área del desarrollo y despliegue de los productos de software que son predominantemente vistas como una actividad periférica, con formalidad, de los despliegue del software, son cambio de actitud de Programa de estudios de como fundamento hacia las pruebas de software pueden reducir los problemas de una forma normalmente asociados con el lanzamiento del nuevo software y Minimizar el riesgo implicado, que a la vez es un elemento crítico para la garantía de la calidad del software y representa una revisión final de las especificaciones del diseño y codificación, que nos lleva al proceso de ejecución de un programa con la intención de descubrir un error, aunque los desarrolladores de software son gente constructiva que requiere que se descarten ideas preconcebidas sobre la corrección del software que se desarrollan con cualquier conflicto de intereses que aparezcan cuando se descubran errores.
El proceso de pruebas de software es un aspectos fundamentales para medir el estado de calidad de un sistema informático e introducirlo satisfactoriamente en el mercado mundial, el objetivo es elaborar la propuesta de un procedimiento para realizar pruebas, aplicando el método de Caja Blanca, a las aplicaciones que se desarrollan en distinto lenguaje, las principales bibliografías especializadas en el tema, profundizando en los diferentes métodos de pruebas que existen, la fundamentación es las técnicas encaminadas a la revisión del código fuente de un sistema informático.
Sin embargo el trabajo se lleva a cabo para tener un procedimiento para realizar pruebas de Caja Blanca a los sistemas que se desarrollan, en el mismo se exponen las actividades a seguir que nos proporciona cada uno de los artefactos de entrada y salida que se realicen, indicando cómo se utilizan y se completan, para confirmar la validez del trabajo realizado se aplican procedimiento al sistema de gestión de Información, con solución planteado en la propuesta en sus actividades y se evidencian los resultados en cada uno de los artefactos involucrados.
Según Ramses, (2015), afirma que fundamento de prueba es un proceso que se enfoca sobre la lógica interna del software y las funciones externas, es un proceso de ejecución de programa con la intención de descubrir un error, y no pueden asegurar la ausencia de defectos.
Tipos de defectos del software.
Defectos.
Es un desperfecto que puede ocasionar fallas en el sistema a la hora de realizar una función requerida
Fallas.
Pueden estas suceder en cualquier etapa del sistema, generalmente suceden al principio en el desarrollo.
Error.
Es resultado de una falla humana lo cual produce un resultado incorrecto.
Datos de Prueba.
Es una lista de variables o posibles valores usados en el caso de prueba.
Validación.
Proceso mediante el cual evaluamos si el sistema cumple los requerimientos solicitados.
Estos tipos de defecto se realizan durante o al final del proceso de desarrollo determinando su factibilidad.
Principios de Proceso de Prueba.
Para Gary, S. R. (2011), definine los principio de prueba de software que son predominantemente vistas como una actividad periférica, es una formalidad, antes de despliegue de software, que son cambio de actitud y programas de estudios como fundamento hacia las pruebas de software pueden reducir los problemas normalmente asociados con el lanzamiento del nuevo software y minimizar el riesgo implicado.
Según Educación, (2013), afirma que en muchos casos, las pruebas tienen objetivos generales que son llevadas a cabo para encontrar defectos y luego proporcionar a los programadores la información que ellos necesitan para corregir estos defectos, los programadores no resuelven todos los defectos usualmente, pero nuestra información donde solo corrigen los defectos más importantes, también las pruebas llevadas a cabo en enfoque para dar confianza en el nivel de calidad del sistema.
Cuando las compañías adquieren aplicaciones, éstas ejecutan a menudo pruebas de aceptación para ganar la confianza previa al despliegue de la aplicación en el centro de datos. Así mismo las pruebas se llevadas a cabo para prevenir defectos, sin embargo, las pruebas previenen defectos cuando los probadores están involucrados en las revisiones y cuando los diseños de las pruebas son completados en paralelo con la implementación del sistema.
Las actividades de pruebas tempranas crean ciclos de retroalimentación beneficiosos entre las actividades de pruebas y las actividades de desarrollo, limpiando los defectos temprano en el ciclo de vida. Finalmente las pruebas proporcionar información, obtener una visión acerca de lo que realmente importa a la calidad del sistema sometido a pruebas.
¿Estamos listos para enviar?
¿Cuándo estaremos listos para enviar?
¿Cuáles son las áreas de riesgo que todavía tenemos que abordar?
¿Cuáles son los problemas conocidos más temidos?
Una vez que empecemos a generar información que conceda una visión del nivel de calidad, se va al siguiente objetivo, el de ayudar a la gerencia a comprender la calidad en el contexto de los objetivos más grandes del proyecto.
La lista de objetivos no es en absoluto exhaustiva, es capaz de pensar en otros objetivos que acerca a sus propios proyectos, lo importante no es los objetivos de pruebas que son escogidos, sino el alineamiento de esos objetivos.
Objetivos de las prueba.
Pueden cambiar dependiendo de la fase o del nivel de pruebas con el que estemos involucrados. Por considere el objetivo de las pruebas de encontrar defectos o "bugs". Glosario del ISTQB Objetivo de prueba, una razón o propósito para el diseño y la ejecución de una prueba, para las pruebas unitarias o de componente, podría encontrar defectos en las partes individuales del sistema sometido a pruebas antes de que las partes estén totalmente integradas al mismo.
Para las pruebas de integración o cadena, es posible encontrar defectos en las relaciones e interfaces entre los pares y grupos de componentes en el sistema sometido a pruebas a medida que las partes se juntan. Para las pruebas de sistema, es posible que quiera encontrar defectos en los comportamientos, funciones y respuestas generales y particulares del sistema sometido a pruebas en su totalidad. Para las pruebas piloto o de aceptación, por lo general no deseamos encontrar defectos en absoluto, usualmente es un problema si encontramos defectos. Se demostrar que el producto está listo para su despliegue o versión, o evaluar la calidad y dar información acerca del riesgo del despliegue o la versión.
Las pruebas de mantenimiento, podríamos estar buscando especialmente un tipo particular de defecto, aquellos introducidos durante el desarrollo de los cambios. Finalmente, para las pruebas operativas, queremos buscar otra vez un tipo particular de defectos, especialmente aquellos relacionados con las características no funcionales del sistema como la fiabilidad o la disponibilidad, usualmente en el entorno en funcionamiento, un objetivo general debe ser adaptado a un objetivo específico basado en el contexto en el cual es aplicado, los probadores de software, efectivos y eficientes, podemos definirlas estrictamente. Por efectivo, queremos decir producir un resultado decidido, decisivo o esperado.
Pruebas de la caja blanca y del camino básico
Según, Bárbara,(2012)afirma que la pruebas de caja blanca, también llamada caja transparente, se establecen por medio del diseño de casos que se usan como base la estructuras de control del flujo la prueba de caja blanca se basa en el diseño de casos de prueba que usa la estructura de control del diseño procedimental para derivarlos.
Se considera a la prueba de Caja Blanca como uno de los tipos de pruebas más importantes que se le aplican a los software, logrando como resultado que disminuya en un gran porciento el número de errores existentes en los sistemas y que sea de gran confiabilidad.
Mediante la prueba de la caja blanca el ingeniero del software puede obtener caso.
1. Que se ejecute por lo menos una vez cada instrucción del programa.
2. Garantizar que todas las condiciones se comprueban como verdaderas y falsas.
3. Que se ejecuten los bucles, probando el caso general y los casos extremos.
La primera es la prueba del camino básico, que se basa en la complejidad del flujo de ejecución desglosado en un conjunto básico de caminos.
La prueba de condiciones tiene como objetivo ejercitar adecuadamente todas las condiciones del módulo para buscar errores que puedan estar en variables lógicas, paréntesis, operadores relacionales o expresiones lógicas.
La prueba de bucles tiene como objetivo reducir la posibilidad de que se pase por alto un error no encontrado en otro tipo de prueba.
Para María, (2009), afirma que la caja blanca son pruebas estructurales, conociendo el código y siguiendo su estructura lógica, se pueden diseñar pruebas destinadas a comprobar que el código hace correctamente lo que el diseño de bajo nivel indica y otras que demuestren que no se comporta adecuadamente ante determinadas situaciones.
En los sistemas orientados a objetos, las pruebas de caja blanca pueden aplicarse a los métodos de la clase, que a la vez se dedica a todo tipo de pruebas más especializadas un argumento podría ser que los métodos de una clase suelen ser menos complejos que los de una función de programación estructurada, dentro de las Pruebas de Caja Blanca encontramos las llamadas coberturas sentencia, decisión, condición aunque las pruebas son aplicables a varios niveles unidad, integración y sistema, habitualmente se aplican a las unidades de software su cometido es comprobar los flujos de ejecución dentro de cada unidad función, clase, módulo también pueden probar los flujos entre unidades durante la integración, e incluso entre subsistemas, durante las pruebas de sistema, el enfoque permite diseñar pruebas que cubran una amplia variedad de casos de prueba, podría pasar por alto partes incompletas de la especificación o requisitos faltantes, se garantiza la prueba exhaustiva de todos los flujos de ejecución del código analizado.
Las principales técnicas de diseño de pruebas de caja blanca son:
Prueba de flujo de control.
Prueba de Datos
Prueba de Bifurcacion.
Prueba de Caminos basicos.
Pruebas de flujo de control.
En estas pruebas se quiere encontrar errores en la parte lógica del programa, utilizando las condiciones simples operador-relación o con condiciones complejas.
Pruebas de flujo de datos.
Por medio de esta herramienta se hace la selección mas adecuada del flujo de datos, para llegar a una resolución correcta, esto para probar las variables y definiciones en el programa.
Pruebas de bifurcación (branch testing).
Como lo dice su titulo, es ligado a una bifurcación o para bucles. Con ella podemos definir si algún bucle esta correctamente implementado y si las lineas de código donde exista una condición es la mejor opción o si debería ser cambiada.
Pruebas de caminos básicos:
Esta prueba lo que demuestra es el conjunto de pasos base del programa, lo que quiere lograr es que cada sentencia de código se ejecute mínimo una vez.
Deacuerdo con freddy, (2008), en analisis de la prueva de caja blanca en programación, se denomina cajas blancas a un tipo de pruebas de software que se realiza sobre las funciones internas de un módulo, así como las pruebas de caja negra ejercitan los requisitos funcionales desde el exterior del modulo, las de caja blanca están dirigidas a las funciones internas. Entre las técnicas usadas se encuentran la cobertura de pruebas sobre las expresiones lógico-aritméticas, pruebas de camino de datos definición uso de variables, comprobación de bucles se verifican los bucles para 0,1 y n iteraciones, y luego para las iteraciones máximas, máximas menos uno y más uno.
Las pruebas de caja blanca se llevan a cabo en primer lugar, sobre un módulo concreto, para luego realizar las de caja negra sobre varios subsistemas.
El objetivo de las pruebas de caja blanca pueden aplicarse a los métodos de la clase, pero según varias opiniones, ese esfuerzo debería dedicarse a otro tipo de pruebas más especializadas una forma puede ser que los métodos de una clase suelen ser menos complejos que los de una función de programación estructurada, realizan un seguimiento del código fuente según va ejecutando los casos de prueba, de manera que se determinan de manera concreta las instrucciones, bloques, en los que existen errores. Cuando se pasan casos de prueba al programa que se está probando, es conveniente conocer qué porcentaje del programa se ha ejecutado, de manera que estemos próximos a asegurar que todo él es correcto existen varias formas de medir la cobertura lograda en el programa por los casos de prueba, algunas de las cuales se presentan en el siguiente epígrafe.
La prueba del camino básico es una técnica de prueba de caja blanca propuesta inicialmente por Tom McCabe, esta técnica 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 diseño de casos de prueba de caminos de ejecución, los casos de prueba derivados del conjunto básico garantizan que durante la prueba se ejecuta por lo menos una vez cada sentencia del programa.
La idea es derivar casos de prueba a partir de un conjunto dado de caminos independientes por los cuales puede circular el flujo de control. Para obtener dicho conjunto de caminos independientes se construye el Grafo de Flujo asociado y se calcula su complejidad ciclomática.
Los pasos que se siguen para aplicar esta técnica son:
Partir del diseño o del código fuente, se dibuja el grafo de flujo asociado.
Se calcula la complejidad ciclomática del grafo.
Se determina un conjunto básico de caminos independientes.
Se preparan los casos de prueba que obliguen a la ejecución de cada camino del conjunto básico.
Los casos de prueba derivados del conjunto básico garantizan que durante la prueba se ejecuta por lo menos una vez cada sentencia del programa.
Notación de Grafo de Flujo
Para aplicar la técnica del camino básico se debe introducir una sencilla notación para la representación del flujo de control, el cual puede representarse por un Grafo de Flujo, cada nodo del grafo corresponde a una o más sentencias de código fuente. Todo segmento de código de cualquier programa se puede traducir a un Grafo de Flujo. Para construir el grafo se debe tener en cuenta la notación para las instrucciones. Un Grafo de Flujo está formado por 3 componentes fundamentales que ayudan a su elaboración, comprensión y nos brinda información para confirmar que el trabajo se está haciendo adecuadamente.
Los componentes son:
Nodo
Cada círculo representado se denomina nodo del Grafo de Flujo, el cual representa una o más secuencias procedimentales. Un solo nodo puede corresponder a una secuencia de procesos o a una sentencia de decisión. Puede ser también que hallan nodos que no se asocien, se utilizan principalmente al inicio y final del grafo.
Aristas
Las flechas del grafo se denominan aristas y representan el flujo de control, son análogas a las representadas en un diagrama de flujo. Una arista debe terminar en un nodo, incluso aunque el nodo no represente ninguna sentencia procedimental.
Regiones
Las regiones son las áreas delimitadas por las aristas y nodos. También se incluye el área exterior del grafo, contando como una región más. Las regiones se enumeran. La cantidad de regiones es equivalente a la cantidad de caminos independientes del conjunto básico de un programa.
Complejidad Ciclomática
La complejidad ciclomática es una métrica de software extremadamente útil pues proporciona una medición cuantitativa de la complejidad lógica de un programa. 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 ejecute cada sentencia al menos una vez. Un camino independiente es cualquier camino del programa que introduce por lo menos un nuevo conjunto de sentencias de procesamiento o una nueva condición. El camino independiente se debe mover por lo menos por una arista que no haya sido recorrida anteriormente.
Derivación de casos de prueba
Luego de tener elaborados los Grafos de Flujos y los caminos a recorrer, se preparan los casos de prueba que forzarán la ejecución de cada uno de esos caminos. Se escogen los datos de forma que las condiciones de los nodos predicados estén adecuadamente establecidas, con el fin de comprobar cada camino.
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. Es el único método caja blanca que cubriremos. Se basa en construir un caso de prueba por camino básico que se encuentre en el grafo de programa asociado al método de la clase que se desea someter a pruebas. Los pasos del método son:
Dibujar el grafo del programa del método de la clase.
Determinar el número ciclomático del grafo, Este número corresponde al número de regiones en el grafico.
E – N + 2,donde E, es el número de aristas del grafo y N el número de nodos.
Construir una secuencia de V(G) caminos linealmente independientes en G. Recursivamente:
(a) El primer camino es cualquiera de los caminos mínimos del nodo origen del grafo a uno de los nodos de terminación del grafo. Se inicializa A(G), el conjunto de aristas en la secuencia linealmente independiente de G con todas aquellas aristas que forman este primer camino.
(b) El próximo camino se forma agregando un nuevo camino entre el origen y una terminación de G Este nuevo camino debe agregar el mínimo número posible de aristas nuevas a A, (pero que agregue por lo menos una arista nueva.
Preparar un caso de prueba por camino hallado en el paso anterior.
(a) Determinar los datos a proporcionar como entrada para ejecutar el camino hallado.
(b) Usando la especificación funcional del método, indicar cuál es el resultado esperado.
Es una tecnica de prueba de caja blanca el metodo del camino basico permite al diseñador de casos de prueba obtener una medida de la complejidad logica de un diseno precedimental y usar esa medida como guia para la definicion de un conjunto basico de caminos de ejecucion, los casos de prueba obtenidos del conjunto basico garantizan que durante la prueba se ejecuta por lo menos una vez cada sentencia del programa.
Este taller busca brindar a los distintos roles involucrados en el desarrollo de software y pruebas, una visión general de los conceptos, del proceso de pruebas y del modelo de madurez de pruebas, que faciliten la implementación de prácticas dentro de su organización en otra parte se puede explican diversas técnicas que formalizan la selección y elaboración de casos de prueba con el fin de que los roles tengan una aproximación sistemática que los lleve a aumentar su cobertura de pruebas.
La prueba ideal de un sistema sería exponerlo en todas las situaciones posibles, así encontraríamos hasta el último fallo. Indirectamente, garantizamos su respuesta ante cualquier caso que se le presente en la ejecución real.a la vez esto es imposible desde todos los puntos de vista humano, económico e incluso matemático, la fase de pruebas absorbe una buena porción de los costes de desarrollo de software. Además, se muestra renuente a un tratamiento matemático o, simplemente, automatizado. Su ejecución se basa en metodología reglas que se les dan a los encargados de probar que se va desarrollando con la experiencia, y deacuerdo a esta experienza se obtine un proceso que se enfoca sobre la lógica interna del software y las funciones externas. A la vez este 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. La prueba no puede asegurar la ausencia de defectos sólo puede demostrar que existen defectos en el software, cualquier proceso de ingeniería puede ser probado de una de dos formas se pueden llevar a cabo pruebas que demuestren que cada función es completamente operativa. Se pueden desarrollar pruebas que aseguren que la operación interna se ajusta a las especificaciones y que todos los componentes internos se han comprobado de forma adecuada.La primera aproximación se denomina prueba de la caja negra y la segunda prueba de la caja blanca.
Arguinzone, J., Barrios, R., Camacho, W., & Zambrano, A. (2015). Transcripción de Fundamentos de Prueba de Software.
AT, m., & PP, a. (1991). Face recognition using eigenfaces. Proc. IEEE Conf. Computer Vision and Pattern Recognition.
BORQUEZ, J. J. (6 de junio de 2013). ingeneria en software. isuu.
Brunelli, R. a. (1993). Face recognition: features versus templates (Vol. 15). IEEE Trans. PAM1.
Dijkstra, E. (1972). The Humble Programmer. ACM Turing Lecture, 17.
Educacion. (2013 ). Fundamentos de Pruebas de Software – Capítulo 1.
Forman, G. Z. (1994). The challenges of mobile computing. IEEE, 27(4), 38-47.
FREDDY, M. M. (2008). PRUEBAS DEL SOFTWARE CAJA BLANCA Y CAJA NEGRA.
Gary, S. R. (2011). Fundamentos de Pruebas de Software.
Jimènez, G. B. (2016). industria del software mundia. colombia.
Lienhart, R. a. (2002). An extended set of Haar-like features for rapid object detection. ICIP02.
María, L. J. (2009). Pruebas de Caja Blanca.
Medina Ramos, G. E. (2012). sistema de informacion. 3-10.
Ramses, B. (2015). Fundamentos de Prueba de Software.
Tanenbaum, A. (2012). España.
V, p., & J, m. (2001). How face detection works. From http://www.cognotics.com/opencv/servo_2007_series/part_2/sidebar.html
W. Zhao, R. C. (2003). Face Recognition: A literature survey (Vol. 35). ACM Computing Surveys.
Autor:
Cesar Javier Pérez Pincay.
Ingeniera en formación del Sexto Semestre de la Carrera de Ingeniería en Computación y Redes, Facultad de Ciencias Técnicas, Materia Ingeniería del software. Universidad Estatal del Sur de Manabí. Ecuador.