Pruebas de caja blanca
Páginas: 8 (1805 palabras)
Publicado: 20 de mayo de 2011
Introducción
En el control de la calidad de un software es muy importante llevar a cabo la revisión del código fuente mediante las Pruebas de Caja Blanca. Para que estas sean realizadas con la calidad y profundidad requerida hay que seguir una serie de pasos y completar toda la documentación que se genera durante la puesta en marcha de las mismas.
Este procedimiento pretende proporcionar lasecuencia de acciones necesarias para lograr el diseño e implantación de los casos de Pruebas de Caja Blanca usando la Técnica del Camino Básico y de esta forma mejorar la situación existente actualmente en la Facultad 2 de la Universidad de las Ciencias Informáticas en cuanto a la revisión del código fuente de los software terminados.
El Formato usado para el diseño de este procedimientocumple con los estándares definidos en la Norma ISO 9000 del 2005. (Ver Anexo 1)
2.2 Objetivo
Establecer los principios de trabajo de la Facultad 2 para la ejecución de las Pruebas de Caja Blanca a Productos de Software terminados usando la Técnica del Camino Básico.
Especificar cada una de las actividades a seguir durante la realización de estas pruebas así como las plantillas a utilizar encada caso.
Facilitar el trabajo del personal dedicado a la ejecución de las Pruebas de Caja Blanca en la Facultad 2.
2.3 Alcance
Este procedimiento abarca aquellos productos de software terminados que se revisan en la facultad 2 y de los cuales se tenga disposición del código fuente, además de la documentación necesaria.
El mismo va dirigido a aquellas personas que pertenecen a la facultad 2 yque se encargan de la revisión exhaustiva del código de los software a probar.
Estas pruebas no evalúan a los programadores sino al código como tal.
2.4 Definiciones, Acrónimos y Abreviaturas
2.4.1 Documentación del Proyecto
Documentos generados durante la producción del Proyecto por el equipo de desarrollo del mismo y que describen todo el entorno de software y hardware relacionado coneste.
2.4.2 Pruebas de Código (Caja Blanca)
La prueba de código se basa en examinar la lógica del programa. Para ejecutarlos el analista desarrolla 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. [McCabe, 1996]
2.4.3 Caso de Prueba
Instrucciones documentadaspara la persona que realiza las pruebas que especifican cómo se tiene o tendría que probar una función o una combinación de funciones. El caso de prueba incluye información detallada sobre los siguientes pasos:
Objetivo de la prueba.
Funciones que se han de comprobar.
Entorno de prueba y otras condiciones (detalles de configuración y trabajos preparatorios).
Datos de prueba.
Comportamientoesperado del sistema.
2.4.4 Defectos del Producto
Fallas existentes en el producto que hacen que el mismo no cumpla con los requisitos especificados por el cliente para su uso o exista un incumplimiento de los estándares definidos por el Grupo de Aseguramiento de Calidad.
2.4.5 Grafo de Flujo
Se usan para traducir o representar la secuencia de ocurrencia de todo segmento de código decualquier programa. 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 nodos, las aristas y las regiones. [McCabe, 1996]
2.4.6 Nodo
Cada círculo representado en el grafo se denomina nodo del Grafo de Flujo, el cual representa una o más secuenciasprocedimentales. Un solo nodo puede corresponder a una secuencia de procesos o a una sentencia de decisión. [McCabe, 1996]
2.4.7 Arista
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. [McCabe, 1996]
2.4.8 Regiones...
En el control de la calidad de un software es muy importante llevar a cabo la revisión del código fuente mediante las Pruebas de Caja Blanca. Para que estas sean realizadas con la calidad y profundidad requerida hay que seguir una serie de pasos y completar toda la documentación que se genera durante la puesta en marcha de las mismas.
Este procedimiento pretende proporcionar lasecuencia de acciones necesarias para lograr el diseño e implantación de los casos de Pruebas de Caja Blanca usando la Técnica del Camino Básico y de esta forma mejorar la situación existente actualmente en la Facultad 2 de la Universidad de las Ciencias Informáticas en cuanto a la revisión del código fuente de los software terminados.
El Formato usado para el diseño de este procedimientocumple con los estándares definidos en la Norma ISO 9000 del 2005. (Ver Anexo 1)
2.2 Objetivo
Establecer los principios de trabajo de la Facultad 2 para la ejecución de las Pruebas de Caja Blanca a Productos de Software terminados usando la Técnica del Camino Básico.
Especificar cada una de las actividades a seguir durante la realización de estas pruebas así como las plantillas a utilizar encada caso.
Facilitar el trabajo del personal dedicado a la ejecución de las Pruebas de Caja Blanca en la Facultad 2.
2.3 Alcance
Este procedimiento abarca aquellos productos de software terminados que se revisan en la facultad 2 y de los cuales se tenga disposición del código fuente, además de la documentación necesaria.
El mismo va dirigido a aquellas personas que pertenecen a la facultad 2 yque se encargan de la revisión exhaustiva del código de los software a probar.
Estas pruebas no evalúan a los programadores sino al código como tal.
2.4 Definiciones, Acrónimos y Abreviaturas
2.4.1 Documentación del Proyecto
Documentos generados durante la producción del Proyecto por el equipo de desarrollo del mismo y que describen todo el entorno de software y hardware relacionado coneste.
2.4.2 Pruebas de Código (Caja Blanca)
La prueba de código se basa en examinar la lógica del programa. Para ejecutarlos el analista desarrolla 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. [McCabe, 1996]
2.4.3 Caso de Prueba
Instrucciones documentadaspara la persona que realiza las pruebas que especifican cómo se tiene o tendría que probar una función o una combinación de funciones. El caso de prueba incluye información detallada sobre los siguientes pasos:
Objetivo de la prueba.
Funciones que se han de comprobar.
Entorno de prueba y otras condiciones (detalles de configuración y trabajos preparatorios).
Datos de prueba.
Comportamientoesperado del sistema.
2.4.4 Defectos del Producto
Fallas existentes en el producto que hacen que el mismo no cumpla con los requisitos especificados por el cliente para su uso o exista un incumplimiento de los estándares definidos por el Grupo de Aseguramiento de Calidad.
2.4.5 Grafo de Flujo
Se usan para traducir o representar la secuencia de ocurrencia de todo segmento de código decualquier programa. 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 nodos, las aristas y las regiones. [McCabe, 1996]
2.4.6 Nodo
Cada círculo representado en el grafo se denomina nodo del Grafo de Flujo, el cual representa una o más secuenciasprocedimentales. Un solo nodo puede corresponder a una secuencia de procesos o a una sentencia de decisión. [McCabe, 1996]
2.4.7 Arista
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. [McCabe, 1996]
2.4.8 Regiones...
Leer documento completo
Regístrate para leer el documento completo.