Ingeniria de Software

5-4-2014

METODO DE PRUEBA CAJA BLANCA INGENIERIA DE SOFTWARE APLICADA

Isaias Teran UNIVERSIDAD POLITECNICA DE PUEBLA INGENIERIA EN INFORMATICA

ÍNDICE 1. INTRODUCCIÓN ................................................................................................ 3 2. CONTENIDO ....................................................................................................... 5 2 .1 DEFINICIONES............................................................................................. 5 Caja blanca: ...................................................................................................... 5 Calidad de Software:......................................................................................... 5 Pruebas de Software: ....................................................................................... 5 Prueba de Código (Caja Blanca): ..................................................................... 6 2.2 APLICACIÓN PRUEBA DE CAJA BLANCA ............................................... 6 DECISIONES LÓGICAS ................................................................................... 6 Imagen 2.2.1 ..................................................................................................... 8 Imagen 2.2.2 ..................................................................................................... 9 Imagen 2.2.3 ................................................................................................... 10 Imagen 2.2.4 ................................................................................................... 11 BUCLES ......................................................................................................... 11 Imagen 4.2.5 ................................................................................................... 11 DIAGRAMA DE FLUJO DE DATOS (DFD) ................................................... 12 Imagen 4.2.6 ................................................................................................... 12 2.3 HERRAMIENTAS QUE SE UTILZAN PARA PRUEBAS DE CAJA BLANCA ........................................................................................................................... 12 JTest: .............................................................................................................. 12 Insure++:......................................................................................................... 13 BullseyeCoverage: .......................................................................................... 13 LDRA: ............................................................................................................. 13 Logiscope TestChecker: ................................................................................. 13 CMT++: ........................................................................................................... 13 CTC++: ........................................................................................................... 14 2.4 DISEÑO ...................................................................................................... 14 Prueba de condición: ...................................................................................... 14 Prueba de la Ruta Básica ............................................................................... 15 Imagen 4.4.1 ................................................................................................... 16 Imagen 4.4.2 ................................................................................................... 16

Imagen 4.4.3 ................................................................................................... 16 Imagen 4.4.4 ................................................................................................... 16 Imagen 4.4.5 ................................................................................................... 17 Prueba de condición ....................................................................................... 17 Prueba del flujo de datos ................................................................................ 17 Prueba de bucles ............................................................................................... 18 Imagen 4.4.6 ................................................................................................... 18 2.5. DESARROLLO DE PRUEBAS DE CAJA BLANCA .................................... 18 2.6 IMPLEMENTACIÓN ..................................................................................... 19 Imagen 2.6.1 .................................................................................................. 20 2.6.2 IMPLEMENTACIÓN Y MANTENIMIENTO DE SOFTWARE .................... 20 3. CONCLUSION .................................................................................................. 21 4. RECUPERACION DE EXPERIENCIA.............................................................. 21 4.1 Trabajo realizado ......................................................................................... 21 4.1.2 Personal .................................................................................................... 22 5. BIBLIOGRAFIA ................................................................................................. 22

1. INTRODUCCIÓN Las ciencias informáticas y paralelamente la producción de Software, han alcanzado en la actualidad un elevado auge e importancia a nivel mundial. Su desarrollo crece de forma vertiginosa y con ello la demanda de mejores software con menores tiempos y costos de producción. Los beneficios que trae desde el punto de vista del desarrollo de sistemas para el uso interno, sino también con el objetivo de introducirse en el mercado a escala mundial aprovechando su perspectiva económica. Uno de los mayores problemas que se afrontan en la esfera de la informática es la calidad de software. El proceso de pruebas al software (también conocido como beta testing) es uno de los aspectos fundamentales para medir el estado de calidad de un sistema informático e introducirlo satisfactoriamente en el mercado mundial. El objetivo del presente trabajo de investigación, es elaborar un documento de un procedimiento para realizar pruebas, aplicando el método de Caja Blanca explicando definiciones, conceptos y como se utiliza hoy en día este método con las nuevas tecnologías informáticas. Actualmente crear un sistema funcional y sin errores hoy en día es primordial ya que día con día el usuario como tal exige más a la tecnología sin ningún margen de error debido a esto existen numerosas técnicas que se emplean para verificar y corregir todos los errores que se presente a la hora del diseño, implementación y programación de un sistema debido a los distintos métodos de programación y lenguaje que hoy en día se conocen. Con el crecimiento acelerado de las tecnologías y la informática, la producción de software desempeña un papel importante, provocando a su vez una competencia en los sistemas, donde la calidad es fundamental para conseguir rentabilidad en la producción. La necesidad de realizar pruebas de calidad converge hacia el aseguramiento de la eficiencia del producto antes de salir al mercado. También al incremento de las tecnologías se vincula el desarrollo de aplicaciones, y en este caso nos interesan a aquellas que son creadas con la meta de poder automatizar el proceso de pruebas de código que se realizan sobre el software.

El desarrollo de Sistemas de software implica la realización de una serie de actividades predispuestas a incorporar errores (en la etapa de definición de requerimientos, de diseño, de desarrollo. Debido a que estos errores se deben a nuestra habilidad innata de provocar errores, tenemos que incorporar una actividad que garantice la calidad del software. En el siguiente trabajo se presentara los siguientes puntos: • Fundamentos de la prueba del software, que definen los objetivos fundamentales de la fase de prueba en base a la prueba de caja blanca. • Diseño de casos de prueba, que se centra en un conjunto de técnicas para que satisfagan los objetivos globales de la prueba en base a la prueba de caja blanca. 2.-Las tareas que se llevan a cabo para darle cumplimiento a los objetivos trazados son: 1. Fundamentar las pruebas de software especificando sus objetivos, estrategias a seguir a la hora de aplicarlas y cómo se debe hacer su planificación. 2. Profundizar en el estado actual de las pruebas de software en la Facultad 2. 3. Investigar las Técnicas de Pruebas de Caja Blanca que más se utilizan, sus objetivos y pasos.

2. CONTENIDO 2 .1 DEFINICIONES 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 módulo, las de caja blanca están dirigidas a las funciones internas. Entre las técnicas usadas se encuentran; la cobertura de caminos (pruebas que hagan que se recorran todos los posibles caminos de ejecución), 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 e interacciones, y luego para las interacciones máximas, máximas menos uno y más uno). Calidad de Software: La calidad debe ser especificada, planificada, administrada, medida y certificada. Esto implica una visión integral que arroja la comprobación del software, con el fin de lograr un mayor grado de satisfacción y confianza del cliente hacia la organización productora de software. Constituye entonces las pruebas del software, tarea de alta prioridad para las empresas productoras. Pruebas de Software: La prueba del software es un elemento crítico para la garantía de calidad del software y representa una revisión de las especificaciones, del diseño y de la codificación. Otras definiciones acerca de pruebas de software:  Las pruebas de software (en inglés software testing) son las investigaciones empíricas y técnicas cuyo objetivo es proporcionar información objetiva e independiente sobre la calidad del producto a la parte interesada o stakeholder. Es una actividad más en el proceso de control de calidad.  Las pruebas son básicamente un conjunto de actividades dentro del desarrollo de software. Dependiendo del tipo de pruebas, estas actividades podrán ser implementadas en cualquier momento de dicho proceso de desarrollo.

 Existen distintos modelos de desarrollo de software, así como modelos de pruebas. A cada uno corresponde un nivel distinto de involucramiento en las actividades de desarrollo.

Prueba de Código (Caja Blanca): Se basa en examinar la lógica del programa. Considerado 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 por ende una mayor calidad y confiabilidad. 2.2 APLICACIÓN PRUEBA DE CAJA BLANCA DECISIONES LÓGICAS -Validación del dominio 1. xMin = Val(txtxMin): xMax = Val(txtxMax) 2. If xMin < -5 Then

3. MsgBox "El limite inferior no debe ser menor a -5", vbCritical, "Error"

4. txtxMax.Text = ""

Label10(0).Caption = ""

txtxMin.SetFocus Parabola.Cls

Exit Sub 7. End If

5. If xMax > 5 Then

3. MsgBox "El limite superior no debe ser mayor a 5", vbCritical, "Error" 4. txtxMin.Text = "" txtxMax.Text = ""

Label10(0).Caption = "" txtxMin.SetFocus Parabola.Cls

Exit Sub

7. End If

6. If xMin >= xMax Then

3. MsgBox "El dominio no es válido", vbCritical, "Error"

4. txtxMin.Text = ""

txtxMax.Text = ""

txtxMin.SetFocus Exit Sub

7. End If

Imagen 2.2.1 Calculo de tabla de valores para puntos intermedios (razón de cambio 0.5)

1. If x 2. m = x + 0.5 3. n = (m ^ 2) + (4 * m) + 5 4. k = Label12.Count 5. Load Label12(k) With Label12(k) .Top = Label12(k - 1).Top + 665

.Caption = Str(m) .Visible = True End With 6. l = Label13.Count 7. Load Label13(l) With Label13(l) .Top = Label13(l - 1).Top + 665 .Caption = Str(n) .Visible = True End With

8. End If

Imagen 2.2.2 - Calculo para el Ymin y el Ymax

1. Ymin = f(xMin)

2. If f(xMax) < ymin =" f(xMax)"> 4. If xMin < ymin =" f(Xv)">

Imagen 2.2.3 1. Ymax = f(xMin)

2. If f(xMax) > Ymax Then 3. Ymax = f(xMax)

4. If xMin Ymax Then 7. Ymax = f(Xv)

Imagen 2.2.4 BUCLES

Imagen 4.2.5

DIAGRAMA DE FLUJO DE DATOS (DFD)

Imagen 4.2.6

2.3 HERRAMIENTAS QUE SE UTILZAN PARA PRUEBAS DE CAJA BLANCA JTest: Es el primer sistema automático de búsqueda de errores en el código de programación para programadores de Java. Esta nueva tecnología desarrollada por la empresa ParaSoft, utiliza la Test Generation Technolgy (Tecnologías de Generación de Pruebas) para analizar programas en Java. Se trata de una herramienta que permite realizar análisis de código, pruebas unitarias automáticas y cobertura de código, así como generación dinámica de pruebas funcionales. En el ámbito de los análisis dinámicos, JTest es capaz de generar automáticamente todas las pruebas unitarias que sean necesarias, teniendo en cuenta los parámetros de cobertura de código e intentando encontrar pruebas que deriven en errores de

ejecución. Genera pruebas funcionales filtradas por las acciones y los datos, incluyendo peticiones HTTP2 y JDBC3. Insure++: Es un entorno automatizado en una aplicación de herramientas de prueba C/C++ que detecta errores difíciles de localizar; como corrupción de la memoria, asignación de errores de memoria, errores de iniciación de variables, definición de conflictos entre variables, indicador de errores, errores de biblioteca, errores lógicos y errores en algoritmos. Sin embargo tiene licencia la cual hay que pagar un monto significativo cada cierto período de tiempo. BullseyeCoverage: Es un analizador de código de cobertura para C ++ y C que indica cómo gran parte del código fuente se pone a prueba. Puede usar esta información para rápidamente centrar su esfuerzo de ensayo y determinar las áreas que necesitan ser revisadas. El código cobertura de análisis es útil durante la unidad de verificación, integración de pruebas y la liberación final. Permite crear código más fiable y ahorrar tiempo. Sin embargo la licencia se debe comprar cada cierto período de tiempo, según el cliente determine, oscilando de 500 euros a 1000 euros. LDRA: Es una herramienta de control de calidad que ofrece un potente código fuente de pruebas y análisis para la validación y verificación de aplicaciones de software. Es importante cuando el software informático requiere ser fiable, robusto y libre de errores. Se trata de un potente y plenamente integrado suite de herramientas, que permite al software avanzado de técnicas de análisis que puedan aplicarse en las etapas claves del desarrollo del ciclo de vida. Sin embargo sus herramientas no contienen la comprobación de estándares de codificación y para su empleo hay que comprarla a precios estimados. Logiscope TestChecker: Aplicación para la representación gráfica de cobertura del código fuente. Evalúa el nivel de cobertura del código, el usuario debe de comprar la licencia por período de tiempos, no realiza evaluaciones al código de C Sharp y no cuenta con la verificación de estándares. CMT++: Es una herramienta para la medida de la complejidad para C/C ++, la misma es fácil de utilizar para ambos lenguajes. También el código en ensamblador

se puede medir con esta herramienta. CMT++ está destinado para organizaciones desarrolladoras de software que se esfuerzan por un proceso de desarrollo productivo resultante en productos de alta calidad. Se puede utilizar CMT++ también para medir la cantidad de código que se tiene: líneas físicas, líneas de comentarios, líneas de programa, declaraciones. Es una herramienta que a pesar de sus características no es gratuita y la documentación para su aprendizaje se encuentra en otros idiomas exceptuando el castellano. CTC++: Con esta herramienta ocurre lo mismos inconvenientes que con CMT++, aunque no se debe de dejar de mencionar que Testwell CTC++ (Test Analizador de Cobertura para C y C++) es una herramienta de cobertura código/prueba potente y fácil de usar, la cual muestra las partes del código que han sido ejecutadas (probadas). La herramienta analiza todos los niveles de cobertura requeridos en proyectos "críticos" y ayuda a garantizar una mayor calidad del código. Testwell CTC++ puede utilizarse para obtener las certificaciones en la industria automotriz, aérea y médica.

2.4 DISEÑO Técnicas de diseño de pruebas de caja blanca son: Dentro de éste tipo de prueba se contempla el método del camino básico mencionado anteriormente pero además existen otras pruebas asociadas que permiten ampliar la cobertura de la prueba y mejorar su calidad. Estas son: 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. Algunos conceptos empleados alrededor de esta prueba son los siguientes:  Condición simple: es una variable lógica o una expresión relacional ( E1 < operador - relacional > E2).  Condición compuesta: está formada por dos o más condiciones simples, operadores lógicos y paréntesis.

En general los tipos de errores que se buscan en una prueba de condición, son 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. Prueba de la Ruta Básica Técnica de prueba de caja blanca que propuso Tom McCabe. Permite conocer una medida de la complejidad lógica de un diseño procedural y usar esta medida como guía para definir un conjunto básico de rutas de ejecución. Estas garantizan que se ejecute cada instrucción del programa por lo menos una vez durante la prueba.

Componentes de la gráfica de flujo: Aristas: enlaces Nodos: instrucción procedural Nodo predicado: nodo del que emanan dos aristas ( if ) Región: área que se limitan por aristas y nodos EJEMPLO:

Imagen 4.4.1

Imagen 4.4.2

Imagen 4.4.3

Imagen 4.4.4 La complejidad ciclomática se basa en la teoría gráfica y se calcula de tres maneras: 1. Número de regiones 2. Complejidad ciclomática es igual a número de aristas, menos el número de nodos más V(G) = E – N + 2 3. Complejidad ciclomática es igual al número de nodos predicado más uno V(G) = P + 1

Imagen 4.4.5 Prueba de condición Método que ejercita las condiciones lógicas contenidas en un módulo del programa. Una condición simple es una variable booleana o una expresión relacional Esta prueba se concentra en la prueba de cada condición del programa para asegurar que no contiene errores. Expresión1 Expresión2 Objetivo: probar todos los casos de la relación. Prueba del flujo de datos Método que selecciona rutas de prueba de acuerdo con las ubicaciones de las definiciones y usos de las variables del programa. Asume que cada instrucción se le asigna un número de instrucción y ninguna función modifica sus parámetros o variables globales. Probar las DEF( I ) y las USO( I ) Donde: DEF( I ) = x | instrucción I contiene una definicion de x USO ( I ) = x | instrucción I contiene un uso de x Objetivo: probar todas las DEF y USO de I

Prueba de bucles Técnica de prueba de caja blanca que se concentra exclusivamente en la validez de la construcción de bucles. Tipos de bucles: simple, anidado, concatenado, no estructurado.

Imagen 4.4.6

2.5. DESARROLLO DE PRUEBAS DE CAJA BLANCA Tabla 1. Complejidad ciclomática vs Evaluación de riesgo.

La complejidad ciclomática puede ser aplicada en varias áreas incluyendo: Análisis de Riesgo en desarrollo de código: Mientras el código está en desarrollo, su complejidad puede ser medida para estimar el riesgo inherente. Análisis de riesgo de cambio durante la fase de mantenimiento: La complejidad del código tiende a incrementarse a medida que es mantenido durante el tiempo. Midiendo la complejidad antes y después de un cambio propuesto, puede ayudar a decidir cómo minimizar el riesgo del cambio. Planificación de Pruebas: El análisis matemático ha demostrado que la complejidad ciclomática indica el número exacto de casos de prueba necesarios para probar cada punto de decisión en un programa.

Reingeniería: Provee conocimiento de la estructura del código operacional de un sistema. El riesgo involucrado en la reingeniería de una pieza de código está relacionado con su complejidad. Posible representación de casos de prueba para pruebas estructurales.

El proceso de pruebas de un software consta de varias etapas dentro de ellas las más importantes son:  Inspección del análisis: Se verifica si se cometieron errores o falla en la etapa de análisis.  Inspección del diseño: Se comprueba el diseño y se trata de hallarle defectos.  Inspección del código: Se observa el entendimiento y facilidad del código.  Pruebas unitarias: Se debe probar cada método de las clases implementadas por separado.  Pruebas de integración: Se prueban todas las clases, verificando que compaginen entre sí.  Pruebas de validación de requerimientos: Validan que se cumple con todos los requerimientos exigidos por el cliente.  Pruebas de sistema: Ejecutar el programa para verificar si cumple con los requisitos exigidos. 2.6 IMPLEMENTACIÓN Las pruebas contemplan los distintos caminos que se pueden generar gracias a las estructuras condicionales, a los distintos estados del mismo, etc. Debido a que el equipo de desarrollo conoce todas las condiciones del sistema LMP podemos realizar pruebas con diferentes escenarios y tipos de datos de

entrada de información en el sistema por ejemplo en el alta de usuarios podemos probar el ingreso de la información con diferentes textos de entrada y en caso de tener algún error corregirlo de manera rápida y ágil. Por ejemplo la imagen 2.6.1 muestra los errores posibles en el alta de un usuario.

Imagen 2.6.1 2.6.2 IMPLEMENTACIÓN Y MANTENIMIENTO DE SOFTWARE Después de realizar las pruebas en el sistema, el PROVEEDOR realizó la instalación de la aplicación en producción con el equipo de software y hardware solicitado al

CLIENTE. Durante esta etapa el equipo de instalación realizó el

deployment de la aplicación ya previamente probada, aun así se realizaron pruebas de caja negra en la aplicación final para asegurar su correcto funcionamiento.

Éste comienza casi de inmediato. El software se libera a los usuarios finales y, en cuestión de días, los reportes de errores se filtran de vuelta hacia la organización de ingeniería de software. En semanas una clase de usuarios indica que el software debe cambiarse de modo que pueda ajustarse a las necesidades especiales de su entorno. Y en meses, otro grupo corporativo, que no quería saber nada del software cuando se liberó, ahora reconoce que puede ofrecerle beneficios inesperados. Necesitará algunas mejoras para hacer que funcione en su mundo.

El reto del mantenimiento del software comienza. Uno se enfrenta con una creciente lista de corrección de errores, peticiones de adaptación y mejoras categóricas que deben planearse, calendarizarse y, al final de cuentas, lograrse. Mucho antes, la fila creció bastante y el trabajo que implica amenaza con consumir los recursos disponibles. En esta etapa de mantenimiento a la aplicación el equipo del PROVEEDOR da soporte a la aplicación a la fecha debido a que han surgido requerimientos de nuevas funcionalidades al sistema además de cuidar la estabilidad del mismo.

Durante este periodo he tenido la oportunidad de aplicar mis conocimientos en desarrollo de software especialmente para aplicar mejoras de funcionalidad las cuales se han acoplado a las nuevas necesidades de la empresa. 3. CONCLUSION Es claro que una actividad indispensable en todo proceso de desarrollo de software, es la prueba, si esta actividad no se llevara a cabo, se tendría un desconocimiento total sobre la calidad de los productos. No se puede negar que, con la aparición de nuevos modelos de desarrollo, muchos de los procesos involucrados en la construcción de software se han simplificado; sin embargo existen otras actividades que no han corrido con la misma suerte, ejemplo de ello es la prueba de software. 4. RECUPERACION DE EXPERIENCIA 4.1 Trabajo realizado En toda implementación de nuevo sistema de software es indispensable conocer acerca de los conceptos principales sobre la calidad y pruebas de software logran describir aspectos relacionados con los procesos de pruebas de sistemas identificando las estrategias de pruebas. Las búsquedas de los tipos de pruebas ayudan a resumir sus características y a describir los flujos actuales del proceso de calidad los cuales fui desarrollando en este documento para poder implementar en la vida laboral y profesional.

4.1.2 Personal Como experiencia personal en la creación del proyecto del método de prueba de caja es para mí poder tener la satisfacción de tener el conocimiento de poder corregir los errores de algún software así mismo emplear soluciones y mejoras del mismo 5. BIBLIOGRAFIA http://angelmolsoftware.blogspot.mx/2008/11/pruebas-del-software-caja-blanca-ycaja.html http://200.69.103.48/comunidad/grupos/arquisoft/fileadmin/Estudiantes/Pruebas/H TML%20-%20Pruebas%20de%20software/node26.html http://www.informaticajuridica.com/trabajos/Propuesta_Procedimiento_para_realizar_pruebas_Caja_Blan ca_aplicaciones_desarrollan_lenguaje_Python.asp http://fcqi.tij.uabc.mx/usuarios/luisgmo/data/8.2%20prb-cal-mant.pdf