Globedia.com

×

Error de autenticación

Ha habido un problema a la hora de conectarse a la red social. Por favor intentalo de nuevo

Si el problema persiste, nos lo puedes decir AQUÍ

×
×
Recibir alertas

¿Quieres recibir una notificación por email cada vez que Balderascamacho escriba una noticia?

Desarrollo de proyectos de software

17/06/2013 23:01 1 Comentarios Lectura: ( palabras)

Desarrollo de "sistema administracion de evaluaciones"

TECNOLOGICO DE ESTUDIOS SUPERIORES DE ECATEPEC

ADMINISTRACION DE EVALUACIONES

1) Balderas Camacho Antonio

2) Moya Ramos Oscar

3) Núñez Fajardo Itzel

4) Ruiz García Víctor Manuel

5) Zamora Hernández Verónica

PROFESORA: XÓCHITL RAQUEL WONG COHÉN

INTRODUCCION:

Las pruebas de software son los procesos que nos permiten verificar y obtener la verdadera calidad de un programa. Para determinar el nivel de calidad se deben efectuar unas medidas o pruebas que permitan comprobar el grado de cumplimiento respecto de las especificaciones iniciales del sistema. El análisis puede probar la presencia de errores pero no la ausencia de ellos.

INDICE

Proceso de pruebas.................................................................................

Generar un plan de pruebas......................................................................

Diseñar pruebas específicas.....................................................................

Tomar configuración del software a probar....................................................

Configurar las pruebas..............................................................................

Evaluar resultados...................................................................................

Depuración............................................................................................

Análisis de errores..................................................................................

Técnicas de diseño de casos de pruebas....................................................

Enfoque práctico recomendado para el diseño de casos.................................

Estrategias de aplicación de las pruebas de unidad, de integración, de sistema, de aceptación............................................................................................

Implantación y mantenimiento...................................................................

Implantación e Integración de casos de uso y componentes de software............

Mantenimiento del software......................................................................

PRUEBAS DE SOFTWARE

Las pruebas de software son investigaciones técnicas y objetivo es proporcionar información objetiva e independiente sobre la calidad del producto a la parte. Son una actividad más en el proceso de control de calidad.

Las pruebas son 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.

El proceso de pruebas comienza con la generación de un plan de pruebas con base en la documentación del proyecto y la documentación del software a probar. Después de dicho plan, se entra en detalle diseñando pruebas específicas basándose en la documentación del software a probar y una vez detalladas las pruebas se toma la configuración del software que se va a probar para ejecutar sobre ella los casos. Después de los resultados de salida, se pasa a su evaluación mediante comparación con la salida esperada. A partir de ésta, se pueden realizar dos actividades:

  • La depuración (localización y corrección de defectos).
  • El análisis de la estadística de errores. [1]

GENERAR UN PLAN DE PRUEBAS

Plan de pruebas de software

Su propósito es explicitar el alcance, enfoque, recursos requeridos, calendario, responsables y manejo de riesgos de un proceso de pruebas.

Un plan de pruebas incluye:

1. Identificador del plan.

2. Alcance

Indica el tipo de prueba y las propiedades/elementos del software a ser probado.

3. Items a probar

Indica la configuración a probar y las condiciones mínimas que debe cumplir para comenzar a aplicarle el plan.

4. Estrategia

Describe la técnica, patrón y/o herramientas a utilizarse en el diseño de los casos de prueba.

5. Categorización de la configuración

Explicita las condiciones bajo las cuales, el plan debe ser:

Suspendido, Repetido; Culminado.

6. Tangibles

Explicita los documentos a entregarse al culminar el proceso previsto por el plan p. ej. subplanes, especificación de pruebas, casos de prueba, resumen gerencial del proceso y bitácora de pruebas.

7. Procedimientos especiales

Identifica el grafo de las tareas necesarias para preparar y ejecutar las pruebas, así como cualquier habilidad especial que se requiere.

8. Recursos

Específica las propiedades necesarias y deseables del ambiente de prueba, incluyendo las características del hardware, el software de sistemas

9. Calendario

Esta sección describe los hitos del proceso de prueba y el grafo de dependencia en el tiempo de las tareas a realizar.

10. Manejo de riesgos

Explicita los riesgos del plan, las acciones mitigantes y de contingencia.

11. Responsables

Especifica quién es el responsable de cada una de las tareas previstas en el plan. [2]

DISEÑAR PRUEBAS ESPECÍFICAS.

La prueba:

Es un conjunto de actividades que se pueden planificar por adelantado y llevar a cabo sistemáticamente. Plantilla para la prueba del software: un conjunto de pasos en los que podamos situar los métodos específicos de diseño de casos de prueba.

Se han propuesto varias estrategias de prueba del software en distintos libros. Todas proporcionan al desarrollador de software una plantilla para la prueba y todas tienen las siguientes características generales:

  • La prueba comienza en el nivel de módulo y trabaja «hacia fuera», hacia la integración de todo el sistema basado en computadora.
  • Según el momento son apropiadas diferentes técnicas de prueba.
  • La prueba la lleva a cabo el responsable del desarrollo del software y (para grandes proyectos) un grupo independiente de pruebas.
  • La prueba y la depuración son actividades diferentes, pero la depuración se debe incluir en cualquier estrategia de prueba.

Una estrategia de prueba del software debe incluir:

Pruebas de bajo nivel que verifiquen que todos los pequeños segmentos de código fuente se han implementado correctamente, así como pruebas de alto nivel que validen las principales funciones del sistema frente a los requisitos del cliente. Una estrategia debe proporcionar una guía al profesional y proporcionar un conjunto de hitos para el jefe de proyecto. Debido a que los pasos de la estrategia de prueba se dan a la vez cuando aumenta la presión de los plazos fijados, se debe poder medir el progreso y los problemas deben aparecer lo antes posible. [3]

TOMAR CONFIGURACIÓN DEL SOFTWARE A PROBAR.

En cualquier proyecto de software existe un conflicto y se pide a la gente que ha construido el software que lo pruebe.

Los mismos programadores tienen un gran interés en demostrar que el programa está libre de errores, que funciona de acuerdo con las especificaciones del cliente y que estará listo de acuerdo con los plazos y el presupuesto. Cada uno de estos intereses se convierte en inconveniente a la hora de encontrar errores a lo largo del proceso de prueba.

El ingeniero de software crea un programa de computadora, su documentación y sus estructuras de datos asociadas. Cuando comienza la prueba, aparece una sutil, aunque firme intención de «romper» lo que el ingeniero del software ha construido. Desde el punto de vista del constructor, la prueba se puede considerar (psicológicamente) destructiva. Por lo tanto, el constructor anda con cuidado, diseñando y ejecutando pruebas que demuestren que el programa funciona, en lugar de detectar errores. Desgraciadamente, los errores seguirán estando. Y si el ingeniero de software no los encuentra, el cliente si lo hará.

A menudo, existen ciertos malentendidos que se pueden deducir equivocadamente de la anterior discusión: (1) el responsable del desarrollo no debería entrar en el proceso de prueba; (2) el software debe ser «puesto a salvo» de extraños que puedan probarlo de forma despiadada; (3) los encargados de la prueba sólo aparecen en el proyecto cuando comienzan las etapas de prueba. Todas estas frases son incorrectas.

El responsable del desarrollo del software siempre es responsable de probar las unidades individuales (módulos) del programa, asegurándose de que la una lleva a cabo la función para la que fue diseñada. En muchos casos, también se encargará de la prueba de integración, el paso de prueba que lleva a la construcción (y prueba) de la estructura total del sistema. Sólo una vez que la arquitectura del software esté completa entra en juego un grupo independiente de prueba. [4]

CONFIGURAR LAS PRUEBAS.

Pruebas alfa y beta

Es virtualmente imposible que un constructor de software pueda prever cómo usará realmente el programa el usuario. Se pueden malinterpretar las instrucciones de uso, se pueden utilizar habitualmente extrañas combinaciones de datos y una salida que puede parecer clara para el responsable de las pruebas puede ser ininteligible para el usuario.

Prueba del sistema

Un problema típico de la prueba del sistema es la «delegación de culpabilidad». Esto ocurre cuando se descubre un error y cada uno de los creadores de cada elemento del sistema echa la culpa del problema a los otros.

Prueba de recuperación

Muchos sistemas basados en computadora deben recuperarse de los fallos y continuar el proceso en un tiempo previamente especificado. En algunos casos, un sistema debe ser tolerante con los fallos; es decir, los fallos del proceso no deben hacer que cese el funcionamiento de todo el sistema.

Prueba de seguridad

Cualquier sistema basado en computadora que maneje información sensible o lleve a cabo acciones que puedan perjudicar (o beneficiar) impropiamente a las personas es un posible objetivo para entradas al sistema impropias o ilegales.

Prueba de resistencia

La prueba de resistencia ejecuta un sistema de forma que demande recursos en cantidad, frecuencia o volúmenes anormales.

Prueba de rendimiento

Para sistemas de tiempo real y sistemas empotrados, es inaceptable el software que proporciona las funciones requeridas pero no se ajusta a los requisitos de rendimiento. La prueba de rendimiento está diseñada para probar el rendimiento del software en tiempo de ejecución dentro del contexto de un sistema integrado. [5]

SISTEMA "ADMINISTRACION DE EVALUACIONES"

EVALUAR RESULTADOS

Un elemento importante del proceso de validación es la revisión de la configuración. La intención de la revisión es asegurarse de que todos los elementos de la configuración del software se han desarrollado bien, y están detallados para soportar la fase de mantenimiento durante el ciclo de vida del software[6]

DEPURACIÓN

La depuración es el proceso de encontrar los errores del programa y corregir o eliminar dichos errores.

Cuando se ejecuta un programa se pueden producir tres tipos de errores:

  • Errores de compilación. Se producen normalmente por un uso incorrecto de las reglas del lenguaje de programación y suelen ser errores de sintaxis. Si existe un error de sintaxis, la computadora no puede comprender la instrucción, no se obtendrá el programa objeto y el compilador imprimirá una lista de todos los errores encontrados durante la compilación.
  • Errores de ejecución. Estos errores se producen por instrucciones que la computadora puede comprender pero no ejecutar.

Ejemplos:

División entre cero y raíces cuadradas de números negativos. En estos casos se detiene la ejecución del programa y se imprime un mensaje de error.

  • Errores de lógica: Se producen en la lógica del programa y la fuente del error suele ser el diseño del algoritmo. Estos errores son los más difíciles de detectar, ya que el programa puede funcionar y no producir errores de compilación ni de ejecución, y solo puede advertir el error por la obtención de resultados incorrectos. [7]

ANÁLISIS DE ERRORES

El análisis es el proceso de ejecución de un programa con la intención de descubrir un error.

Un buen caso de análisis es aquel que tiene una alta probabilidad de mostrar un error no descubierto hasta entonces.

Un análisis tiene éxito si descubre un error no detectado hasta entonces. (Fig. 1) [8].

(Fig.1)

TECNICAS DE DISEÑO DE CASOS DE PRUEBAS

El método del camino básico, propuesto por Tom McCabe, 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 derivados del conjunto básico garantizan que durante la prueba se ejecuta por lo menos una vez cada sentencia de programa.

Cualquier representación del diseño procedimental se puede traducir a un grafo de flujo. La complejidad ciclo matica de este grafo 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.

La complejidad se puede calcular de tres formas:

1.- El numero de regiones del grafo de flujo

2.- Aristas - Nodos + 2

3.-Nodos predicado + 1

El valor de V(G) nos da el número de caminos linealmente independientes de la estructura de control del programa. Entonces se preparan los casos de prueba que forzarán la ejecución de cada camino del conjunto básico.

Prueba de condiciones.

La prueba de condiciones 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. Se basa en el criterio de que 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 sea también efectivo para detectar otros errores en el programa P.

Para una expresión relacional de la forma:

E1 <operador relacional> E2

Se requieren tres pruebas: el valor de E1 mayor, menor o igual que el de E2. La prueba que haga el valor de E1 mayor o menor que el de E2 debe hacer que la diferencia entre estos dos valores sea lo más pequeña posible.

Si la expresión es de la forma B1 & B2 donde B1 y B2 son variables lógicas, esta se cubre para B1 verdadero y B2 falso, B1 falso y B2 verdadero y ambos B1 y B2 verdadero.

Prueba de bucles

Los bucles son la piedra angular de la mayoría de los algoritmos implementados en software. La prueba de bucles es una técnica de prueba de caja blanca que centra su punto de atención en la validez de las construcciones de bucles.

A) Bucles simples: Se les debe aplicar el siguiente conjunto de pruebas, donde n es el número máximo de pasos permitidos para el bucle:

1. Pasar por alto totalmente el bucle

2. Pasar una sola vez por el bucle

3. Pasar dos veces por el bucle

4. Hacer m pasos por el bucle con m < n

5. Hacer n-1, n y n+1 pasos por el bucle

B) Bucles anidados

1. Comenzar por el bucle más interior. Establecer los demás bucles en sus valores mínimos.

2. Llevar a cabo las pruebas de bucles simples para el bucle más interior, mientras se mantienen los parámetros de iteración de los bucles externos en sus valores mínimos. Añadir otras pruebas para valores fuera de rango o excluidos.

3. Progresar hacia fuera, llevando a cabos pruebas para el siguiente bucle, pero manteniendo todos los bucles externos en sus valores mínimos y los demás bucles anidados en sus valores "típicos".

4. Continuar hasta que se hayan probado todos los bucles.

C) Bucles concatenados: Se pueden probar mediante el enfoque anteriormente definido para los bucles simples, mientras cada uno de los bucles sea independiente del resto

D) Bucles no estructurados: Esta clase de bucles se deben rediseñar para que se ajusten a las construcciones de la programación estructurada.

2.- Pruebas de caja negra

2.1- Partición Equivalente

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, 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 de casos de prueba que hay que desarrollar.

El diseño de casos de prueba para la partición equivalente se basa en una evaluación de las clases de equivalencia para una condición de entrada. Una clase de equivalencia representa un conjunto de estados válidos o inválidos para condiciones de de entrada.

1. Si una condición de entrada especifica un rango, se define una clase de equivalencia válida y dos inválidas

2. Si una condición de entrada requiere un valor específico, se define una clase de equivalencia válida y dos inválidas.

3. Si una condición de entrada especifica un miembro de un conjunto, se define una clase de equivalencia válida y una inválida.

4. Si una condición de entrada es lógica, se define una clase válida y una inválida. [9].

ESTRATEGIAS DE APLICACIÓN DE PRUEBAS

Pruebas de unidad:

Las pruebas de unidad son un proceso para probar los subprogramas, las subrutinas, los procedimientos individuales o las clases en un programa. Es decir, es mejor probar primero los bloques desarrollados más pequeños del programa, que inicialmente probar el software en su totalidad. Las motivaciones para hacer eso son tres.

Primera, las pruebas de unidad son una manera de manejar los elementos de prueba combinados, puesto que se centra la atención inicialmente en unidades más pequeñas del programa.

Pruebas de aceptación:

El objetivo de las pruebas de aceptación es validar que un sistema cumple con el funcionamiento esperado y permitir al usuario de dicho sistema que determine su aceptación, desde el punto de vista de su funcionalidad y rendimiento.

Las pruebas de aceptación son definidas por el usuario del sistema y preparadas por el equipo de desarrollo, aunque la ejecución y aprobación final corresponden al usuario.

Pruebas de integración:

El objetivo de las pruebas de integración es verificar el correcto ensamblaje entre los distintos componentes una vez que han sido probados unitariamente con el fin de comprobar que interactúan correctamente a través de sus interfaces, tanto internas como externas, cubren la funcionalidad establecida y se ajustan a los requisitos no funcionales especificados en las verificaciones correspondientes. [10]

UNIDAD 5: IMPLANTACIÓN Y MANTENIMIENTO

Implantación e Integración de casos de uso y componentes de software

Es un modelo de análisis que proporciona una comprensión detallada de los requisitos e impone una estructura del sistema a mantener cuando se le de forma.

El diseño produce un modelo físico del sistema a implementar que no es genérico, más formal que el de análisis, dinámico, realizado según la ingeniería de ida y vuelta con el modelo de implantación y que debe ser mantenido durante todo el ciclo de vida del software.

La implementación:

Consiste en implementar el sistema en términos de componentes, es decir, ficheros de código fuente, de cabecera, ejecutables, etc.

Los fines de la implantación son básicamente:

  • Planificar las integraciones a realizar en cada iteración.
  • Distribuir los componentes ejecutables a los nodos en el diagrama de despliegue.
  • Implementar las clases y subsistemas encontrados durante el diseño por medio de componentes de ficheros fuentes.
  • Probar los componentes individuales e integrarlos en el sistema. [11].

FUENTES DE INFORMACIÓN

[1] http://www.slideshare.net/Adark/pruebas-y-depuracin

[2] www.sistemas.edu.bo/.../tema6%20Pruebas%20del%20software.ppt‎

[3] http://www.angelfire.com/empire2/ivansanes/bywbox.htm

[4]http://www.slideshare.net/AntonioMartinez37/estrategias-de-aplicacion-de-pruebas-12932762

[5] http://prezi.com/x9vodpjnuofa/implementacion-e-integracion-de-casos-de-uso-y-componentes-de-sw/#

[6] http://200.69.103.48/comunidad/grupos/arquisoft/fileadmin/Estudiantes/Pruebas/HTML%20-%20Pruebas%20de%20software/node11.html

[7] http://desasof2004.blogspot.mx/2009/06/plan-de-pruebas-de-software.html

[8] http://www.angelfire.com/my/jimena/ingsoft/guia10.htm

[9] http://fcqi.tij.uabc.mx/usuarios/luisgmo/data/8.3%20prb-cal-mant.pdf

[10] http://www.tesoem.edu.mx/alumnos/cuadernillos/2011.009.pdf

[11] http://alarcos.inf-cr.uclm.es/doc/ISOFTWAREI/Tema09.pdf

CONCLUSIÓN

En conclusión si tras la depuración se presentan errores en el programa fuente es preciso volver a editar el programa, corregir los errores y compilar de nuevo, este proceso se repite hasta que no se produzcan errores y de esa manera se obtiene el programa objeto y la depuración es el proceso de encontrar los errores del programa o corregirlo o eliminar dichos errores. Cuando se ejecuta un programa se puede producir tres tipos de errores: Errores de compilación, Errores de ejecución, Errores de lógicos. En este caso se debe volver a la fase del diseño del algoritmo, modificarlo, cambiar el programa fuente, compilar y ejecutar una vez más.


Sobre esta noticia

Autor:
Balderascamacho (1 noticias)
Visitas:
914
Tipo:
Tutorial
Licencia:
Distribución gratuita
¿Problemas con esta noticia?
×
Denunciar esta noticia por

Denunciar

Etiquetas

Comentarios

×
¿Desea borrar este comentario?
Borrar
0
+ -
Responder

Balderascamacho (18/06/2013)

Exelente