CARLOS GONZALEZ CC: 79.212.539
domingo, 30 de noviembre de 2008
Suscribirse a:
Entradas (Atom)
skip to main |
skip to sidebar
Crear un aplicativo que permita graficar las siguientes funciones: Y=X2+4x+5 y Y=5exp(x)+3x+2.
1. Funcionalidad Incorrecta o Faltante: El software esta diseñado para tomar las variables que le sean asignadas y así trabajar con las constantes que están definidas dentro de las funciones dadas, de esta manera se obtiene el resultado esperado.
2. -Análisis de valores Límites: El diseño del software, al no tener sus validaciones mínimas, no acepta valores negativos o decimales, lo que ocasiona que el programa entre en modo de depuración.
3. -Prueba de Seguridad: para la realización de esta prueba se emplearon variables globales, ya que estas permiten un mejor recorrido al momento de ejecutar una depuración paso a paso, lo cual se traduce en un mejor tiempo de respuesta.
4. -Prueba de Rendimiento:
1. Se debe tener en cuenta al momento de desarrollar un aplicativo que tipo de prueba se va a realizar, el entorno y la validez de los datos.
2. Es importante verificar si el aplicativo esta cumpliendo con los requerimientos, y si se cumple con el modelo de desarrollo seleccionado para su implementación.
3. el lenguaje de desarrollo aunque es importante, no es lo mas esencial al crear una aplicación, lo que se debe tener claro, es como será la implementación y si las pruebas realizadas cumplen a cabalidad con lo que se espera realice el programa.
TRABAJO COLABORATIVO
PRUEBAS DE SOFTWARE
GRUPO 301569_8
PARTICIPANTES:
CARLOS A GONZALEZ
COD: 79.212.539
TUTOR:
JHON FREDY MONTES MORA
EVALUACION DE SOFTWARE
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA
ESCUELA DE CIENCIAS BASICAS E INGENIERIA
INGENIERIA DE SISTEMAS
BOGOTA
2008
PRUEBAS DE SOFTWARE
GRUPO 301569_8
PARTICIPANTES:
CARLOS A GONZALEZ
COD: 79.212.539
TUTOR:
JHON FREDY MONTES MORA
EVALUACION DE SOFTWARE
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA
ESCUELA DE CIENCIAS BASICAS E INGENIERIA
INGENIERIA DE SISTEMAS
BOGOTA
2008
DISEÑOS DE CASOS DE PRUEBA
TECNICAS DE PRUEBA
Existen dos tipos de técnicas de prueba:
Técnicas de Caja Blanca
Son las que se hacen basados en los criterios del contenido de los módulos (el código de la aplicación)
El criterio de selección de casos buscará una cobertura limitada:
- Caminos independientes
- Valores de las condiciones
- Bucles dentro y fuera de sus límites operacionales
- Estructura de datos
- Los errores se esconden en los rincones y se acumulan en las fronteras
Técnicas de Caja Negra
Se basa en los criterios de las interfaces y las especificaciones de los módulos.
Permiten detectar:
- El funcionamiento incompleto o incorrecto
- Errores en la interfaz gráfica
- Errores de acceso a estructuras de datos externas
- Problemas de rendimiento
- Errores de inicio y terminación de la aplicación
La cobertura que presenta esta técnica son:
- Valores representativos de los conjuntos de datos
- Fronteras, valores o combinaciones de valores conflictivos
- Capacidad de proceso.
Existen dos tipos de técnicas de prueba:
Técnicas de Caja Blanca
Son las que se hacen basados en los criterios del contenido de los módulos (el código de la aplicación)
El criterio de selección de casos buscará una cobertura limitada:
- Caminos independientes
- Valores de las condiciones
- Bucles dentro y fuera de sus límites operacionales
- Estructura de datos
- Los errores se esconden en los rincones y se acumulan en las fronteras
Técnicas de Caja Negra
Se basa en los criterios de las interfaces y las especificaciones de los módulos.
Permiten detectar:
- El funcionamiento incompleto o incorrecto
- Errores en la interfaz gráfica
- Errores de acceso a estructuras de datos externas
- Problemas de rendimiento
- Errores de inicio y terminación de la aplicación
La cobertura que presenta esta técnica son:
- Valores representativos de los conjuntos de datos
- Fronteras, valores o combinaciones de valores conflictivos
- Capacidad de proceso.
PRUEBA DE CAJA NEGRA
Los datos de prueba se escogerán atendiendo a las especificaciones del problema, sin importar los detalles internos del programa, a fin de verificar que el programa corra bien.
Criterios mínimos que guiarán al escoger los datos de prueba:
· Valores Fáciles: El programa se depurará con datos de fácil comprobabilidad.
· Valores típicos realistas: se ensayará un programa con datos seleccionados para que representen como se aplicará. Los Datos han de ser sencillos, de modo que los resultados sean verificables en forma manual.
· Valores extremos
· Valores ilegales: Cuando en un programa entra basura, su salida habrá de ser un mensaje de error adecuado. Es preferible que el programa ofrezca indicación de errores en la entrada y que realice cálculos que sigan siendo factibles luego de desechar la entrada equivocada.
El método de la caja negra se centra en los requisitos fundamentales del software y permite obtener entradas que prueben todos los requisitos funcionales del programa.
Con este equipo de pruebas se intenta encontrar:
· Funciones incorrectas o ausentes.
· Errores de interfaz.
· Errores en estructuras de datos o en accesos a la bases de datos externas
· Errores de rendimiento.
· Errores de inicialización y terminación.
Con la aplicación de esa técnica se obtiene un conjunto de pruebas que:
Reduce el numero de casos de pruebas y nos dicen algo sobre la presencia o ausencia de errores.
Partición equivalente:
Una partición equivalente es un método de prueba de caja negra que divide el dominio de entrada de un programa en clases de datos. El diseño de casos de prueba para la partición equivalente se basa en la evaluación de las clases de equivalencia.
Análisis de valores limite:
Nos lleva a elegir las pruebas que nos ejecuten los valores límite, con esta técnica se complementa la partición equivalente.
Prueba de comparación:
Esta técnica consiste en la comparación de salidas de un mismo software pero de sus diferentes versiones.
Prueba De La Caja De Cristal
Principia con la observación de que un programa difícilmente puede considerarse como probado por completo si su código contiene partes que nunca han sido ejecutadas.
Este método analiza la estructura lógica del programa y, para cada alternativa que puede presentarse, los datos de prueba ideados conducirán a ella. Se procura escoger los que verifiquen cada posibilidad en las proposiciones case, las cláusulas de cada proposición if y la condición de terminación de cada ciclo.
En un programa extenso, este método es impráctico, pero en un modulo pequeño constituye un excelente medio de prueba y depuración.
En una prueba que se vale del método de la caja de cristal, se tornan patentes las ventajas de un diseño de programa modular.
Un buen criterio de prueba para proyectos extensos consiste en aplicar los métodos de la caja de cristal a cada módulo pequeño conforme se escriba; luego se usan esos datos en las secciones más amplias del programa una vez terminadas.
Prueba de la Caja de Pandora:
Consiste en abternerse de realizar pruebas de depurar bastante bien un proyecto; se deja al cliente que lo ensaye y acepte. El resultado es una bomba de tiempo.
Los datos de prueba se escogerán atendiendo a las especificaciones del problema, sin importar los detalles internos del programa, a fin de verificar que el programa corra bien.
Criterios mínimos que guiarán al escoger los datos de prueba:
· Valores Fáciles: El programa se depurará con datos de fácil comprobabilidad.
· Valores típicos realistas: se ensayará un programa con datos seleccionados para que representen como se aplicará. Los Datos han de ser sencillos, de modo que los resultados sean verificables en forma manual.
· Valores extremos
· Valores ilegales: Cuando en un programa entra basura, su salida habrá de ser un mensaje de error adecuado. Es preferible que el programa ofrezca indicación de errores en la entrada y que realice cálculos que sigan siendo factibles luego de desechar la entrada equivocada.
El método de la caja negra se centra en los requisitos fundamentales del software y permite obtener entradas que prueben todos los requisitos funcionales del programa.
Con este equipo de pruebas se intenta encontrar:
· Funciones incorrectas o ausentes.
· Errores de interfaz.
· Errores en estructuras de datos o en accesos a la bases de datos externas
· Errores de rendimiento.
· Errores de inicialización y terminación.
Con la aplicación de esa técnica se obtiene un conjunto de pruebas que:
Reduce el numero de casos de pruebas y nos dicen algo sobre la presencia o ausencia de errores.
Partición equivalente:
Una partición equivalente es un método de prueba de caja negra que divide el dominio de entrada de un programa en clases de datos. El diseño de casos de prueba para la partición equivalente se basa en la evaluación de las clases de equivalencia.
Análisis de valores limite:
Nos lleva a elegir las pruebas que nos ejecuten los valores límite, con esta técnica se complementa la partición equivalente.
Prueba de comparación:
Esta técnica consiste en la comparación de salidas de un mismo software pero de sus diferentes versiones.
Prueba De La Caja De Cristal
Principia con la observación de que un programa difícilmente puede considerarse como probado por completo si su código contiene partes que nunca han sido ejecutadas.
Este método analiza la estructura lógica del programa y, para cada alternativa que puede presentarse, los datos de prueba ideados conducirán a ella. Se procura escoger los que verifiquen cada posibilidad en las proposiciones case, las cláusulas de cada proposición if y la condición de terminación de cada ciclo.
En un programa extenso, este método es impráctico, pero en un modulo pequeño constituye un excelente medio de prueba y depuración.
En una prueba que se vale del método de la caja de cristal, se tornan patentes las ventajas de un diseño de programa modular.
Un buen criterio de prueba para proyectos extensos consiste en aplicar los métodos de la caja de cristal a cada módulo pequeño conforme se escriba; luego se usan esos datos en las secciones más amplias del programa una vez terminadas.
Prueba de la Caja de Pandora:
Consiste en abternerse de realizar pruebas de depurar bastante bien un proyecto; se deja al cliente que lo ensaye y acepte. El resultado es una bomba de tiempo.
APLICACIÓN DE PRUEBA DE CAJA NEGRA
Crear un aplicativo que permita graficar las siguientes funciones: Y=X2+4x+5 y Y=5exp(x)+3x+2.
1. Funcionalidad Incorrecta o Faltante: El software esta diseñado para tomar las variables que le sean asignadas y así trabajar con las constantes que están definidas dentro de las funciones dadas, de esta manera se obtiene el resultado esperado.
2. -Análisis de valores Límites: El diseño del software, al no tener sus validaciones mínimas, no acepta valores negativos o decimales, lo que ocasiona que el programa entre en modo de depuración.
3. -Prueba de Seguridad: para la realización de esta prueba se emplearon variables globales, ya que estas permiten un mejor recorrido al momento de ejecutar una depuración paso a paso, lo cual se traduce en un mejor tiempo de respuesta.
4. -Prueba de Rendimiento:
APLICACION DE PRUEBA CAJA BLANCA
A-C: ANALISIS DE PROCEDIMIENTO.
E-C: ELEVACION DE LA PENDIENTE.
E-C: ELEVACION DE LA PENDIENTE.
DIAGRAMA DE FLUJO DE DATOS
CONCLUSIONES
1. Después de finalizar esta practica (trabajo de investigación) he comprendido que con las pruebas no puede asegurarse que no existen errores sólo pueden mostrar que existen defectos en el software.
2. La mayoría de los usuarios de programas extensos no se interesan en los detalles del funcionamiento del programa, lo que buscan son las respuestas.
3. En una prueba que se vale del método de la caja de cristal se tornan patentes las ventajas de un diseño de programa modular.
4. Se ve claramente la importancia de la realización de pruebas para verificar el correcto funcionamiento de los aplicativos, y prevenir los errores antes de la entrega final del producto.
2. La mayoría de los usuarios de programas extensos no se interesan en los detalles del funcionamiento del programa, lo que buscan son las respuestas.
3. En una prueba que se vale del método de la caja de cristal se tornan patentes las ventajas de un diseño de programa modular.
4. Se ve claramente la importancia de la realización de pruebas para verificar el correcto funcionamiento de los aplicativos, y prevenir los errores antes de la entrega final del producto.
RECOMENDACIONES
1. Se debe tener en cuenta al momento de desarrollar un aplicativo que tipo de prueba se va a realizar, el entorno y la validez de los datos.
2. Es importante verificar si el aplicativo esta cumpliendo con los requerimientos, y si se cumple con el modelo de desarrollo seleccionado para su implementación.
3. el lenguaje de desarrollo aunque es importante, no es lo mas esencial al crear una aplicación, lo que se debe tener claro, es como será la implementación y si las pruebas realizadas cumplen a cabalidad con lo que se espera realice el programa.