domingo, 30 de noviembre de 2008

RECOMENDACIONES

- Es muy importante tener un claro concepto de lo que son las pruebas de software y las diferentes clases de pruebas que podemos aplicar sobre los aplicativos que creamos ya que esto nos permitirá adquirir cierta experiencia en el área y por ende mejorara la calidad de los productos y servicios ofrecidos
- Se recomienda tener un conocimiento básico sobre programación en Visual Basic en caso de que se quiera tener acceso al codigo fuente del aplicativo para poder llevar a cabo las demás pruebas que se consideren necesarias o pertinentes para futuros trabajos relacionados con el área.

APLICACION PRUEBA DE CAJA BLANCA


REPRESENTACION DE LAS DECISIONES LOGICAS QUE INTERVIENEN EN EL PROGRAMA:

En el aplicativo solo se emplea una decisión lógica, la cual hace referencia al tipo de función que se desea graficar; dicha decisión permite establecer las operaciones o procesos que se realizarán en el caso de la función seleccionada.



1. Seleccion de la función a graficar




2. Se selecciona la función y=x^2+4x+5


3. Se selecciona la función y=5exp(x)+3x+2



4. Graficar función y mostrar valores correspondientes a la función y=x^2+4x+5




5. Graficar función y mostrar valores correspondientes a la función y=5exp(x)+3x+2


6. Fin.





REPRESENTACION DE LOS BUCLES QUE INTERVIENEN EN EL DESARROLLO DE PROCESOS:


Básicamente, se observa la presencia de tres bucles que intervienen en el desarrollo de los procesos, estos son:


A. Bucle encargado de gráficar los ejes horizontal y vertical en el PictureBox:



1. Inicio del bucle desde 1 hasta 100


2. Gráfica los puntos que conforman el eje X por medio del contador


3. Gráfica los puntos que conforman el eje Y por medio del contador















B. Bucle encargado de realizar la operación para obtener los valores que tendrá X y Y

1. Inicio del bucle con un contador X que va desde -5 hasta 5

2. Calculo del valor que toma Y de acuerdo a la función seleccionada.
3. Adición del valor de X a la lista correspondiente
4. Adición del valor de Y a la lista correspondiente.





C. Bucle encargado de realizar la gráfica de la función seleccionada:



1. Inicio del bucle con un contador X que va desde -5 hasta 5


2. Gráfica del punto obtenido de acuerdo a los valores dados por el contador para la variable X y Y.








REPRESENTACION EN FORMA DE DIAGRAMA DE FLUJO DE DATOS DEL CONTEXTO GENERAL DEL APLICATIVO





A continuación se puede apreciar el DFD del contexto general del funcionamiento del aplicativo:



1. Selección del tipo de función a graficar

2. Inicio del bucle con un contador X que va desde -5 hasta 5
3. Calculo del valor que toma Y de acuerdo a la función seleccionada.
4. Adición del valor de X a la lista correspondiente
5. Adición del valor de Y a la lista correspondiente.
6. Inicio del bucle desde 1 hasta 100
7. Gráfica los puntos que conforman el eje X por medio del contador
8. Gráfica los puntos que conforman el eje Y por medio del contador
9. Inicio del bucle con un contador X que va desde -5 hasta 5
10. Gráfica del punto obtenido de acuerdo a los valores dados por el contador para la variable X y Y.

APLICACION PRUEBA DE CAJA NEGRA

FUNCIONALIDAD INCORRECTA O FALTANTE:

Para que el aplicativo corra sin dificultad y sin problemas, se hace necesario que por medio de la Herramienta de Visual Basic 6.0 se genere el archivo .EXE correspondiente, con el fin de que el aplicativo se pueda ejecutar en el Sistema Operativo Windows de cualquier equipo de computo sin necesidad de tener instalado Visual Basic allí.

ANALISIS DE VALOR LIMITE:

Teniendo en cuenta las funciones empleadas para la realización de las gráficas, se puede observar que los valores de X y Y no afectan de manera alguna el desarrollo de las instrucciones o sentencias del código fuente del aplicativo; sin embargo, si se observa las propiedades del PictureBox empleado en Visual Basic, se observa que tienen un valor de escala definido, el cual se ha determinado de tal manera que se pueda observar bien la gráfica. Esto quiere decir que en cualquier momento que la gráfica supere dicho valor, se podría estar presentando un problema que llevaría a realizar una depuración del programa.

PRUEBA DE SEGURIDAD:

Teniendo en cuenta que el archivo generado es del tipo .EXE, el software cuenta con restricción total a cualquier usuario, impidiendo de esta manera la depuración del mismo al no tener acceso al código fuente de dicho aplicativo.

PRUEBA DE RENDIMIENTO:

Una vez finalizado el desarrollo del software, se le aplicó esta prueba, con el fin de determinar si aceptaba extensas intervenciones por parte del usuario al momento de gráficar una y otra vez las distintas funciones empleadas, obteniendo un resultado positivo sobre el software.

viernes, 28 de noviembre de 2008

SOFTWARE EMPLEADO

Se desarrollo un aplicativo con la Herramienta Visual Basic 6.0 con el fin de poder realizar la gráfica de las ecuaciones y=x^2+4x+5, y=5exp(x)+3x+2. Los pantallazos correspondientes se pueden apreciar a continuación:







Se puede observar que el aplicativo se encuentra dividido en tres partes:


1. Posibilidad de selección de la funció que queremos graficar.




2. Area en la cual será graficada la función seleccionada.




3. Area que muestra los valores de X y Y según la función seleccionada.






A continuación se puede apreciar las grafícas correspondientes a las funciones seleccionadas:




NOTA: Si desea solicitar el archivo ,EXE o incluso el codigo fuente de este aplicativo, favor escribir a alekkool@yahoo.es y le será enviado en el término de las distancia.

REFERENTE TEORICO

CAJA BLANCA:

Denominadas también pruebas estructurales o pruebas de caja transparente.
En estas pruebas siempre se observa el código y se formaliza en lo que se llama "cobertura".

Hay diferentes posibilidades de definir la cobertura. Todas ellas intentan sobrevivir al hecho de que el número posible de ejecuciones de cualquier programa no trivial es (a todos los efectos prácticos) infinito. Pero si el 100% de cobertura es infinito, ningún conjunto real de pruebas pasaría de un infinitésimo de cobertura.
1. Cobertura de segmentos
También denominada "cobertura de sentencias".
Por segmento se entiende una secuencia de sentencias sin puntos de decisión. Como el ordenador está obligado a ejecutarlas una tras otra, es lo mismo decir que se han ejecutado todas las sentencias o todos los segmentos.
El número de sentencias de un programa es finito. Basta coger el código fuente e ir contando. Se puede diseñar un plan de pruebas que vaya ejercitando más y más sentencias, hasta que hayamos pasado por todas, o por una inmensa mayoría.

En la práctica, el proceso de pruebas termina antes de llegar al 100%, pues puede ser excesivamente laborioso y costoso provocar el paso por todas y cada una de las sentencias.
A la hora de decidir el punto de corte antes de llegar al 100% de cobertura hay que ser precavido y tomar en consideración algo más que el índice conseguido. En efecto, ocurre con harta frecuencia que los programas contienen código muerto o inalcanzable. Puede ser que este trozo del programa, simplemente "sobre" y se pueda prescindir de él; pero a veces significa que una cierta funcionalidad, necesaria, es inalcanzable: esto es un error y hay que corregirlo.
2. Cobertura de ramas
La cobertura de segmentos es engañosa en presencia de segmentos opcionales. Por ejemplo:
IF Condicion THEN EjecutaEsto; END;

Desde el punto de vista de cobertura de segmentos, basta ejecutar una vez, con éxito en la condición, para cubrir todas las sentencias posibles. Sin embargo, desde el punto de vista de la lógica del programa, también debe ser importante el caso de que la condición falle (si no lo fuera, sobra el IF). Sin embargo, como en la rama ELSE no hay sentencias, con 0 ejecuciones tenemos el 100%.
Para afrontar estos casos, se plantea un refinamiento de la cobertura de segmentos consistente en recorrer todas las posibles salidas de los puntos de decisión. Para el ejemplo de arriba, para conseguir una cobertura de ramas del 100% hay que ejecutar (al menos) 2 veces, una satisfaciendo la condición, y otra no.
Estos criterios se extienden a las construcciones que suponen elegir 1 de entre varias ramas. Por ejemplo, el CASE. Nótese que si lograramos una cobertura de ramas del 100%, esto llevaría implícita una cobertura del 100% de los segmentos, pues todo segmento está en alguna rama. Esto es cierto salvo en programas triviales que carecen de condiciones (a cambio, basta 1 sóla prueba para cubrirlo desde todos los puntos de vista).
3. Cobertura de condición/decisión
La cobertura de ramas resulta a su vez engañosa cuando las expresiones booleanas que usamos para decidir por qué rama tirar son complejas. Por ejemplo:
IF Condicion1 OR Condicion2 THEN HazEsto; END;

Las condiciones 1 y 2 pueden tomar 2 valores cada una, dando lugar a 4 posibles combinaciones. No obstante sólo hay dos posibles ramas y bastan 2 pruebas para cubrirlas. Pero con este criterio podemos estar cerrando los ojos a otras combinaciones de las condiciones.
Consideremos sobre el caso anterior las siguientes pruebas:

Prueba 1: Condicion1 = TRUE y Condicion2 = FALSE
Prueba 2: Condicion1 = FALSE y Condicion2 = TRUE
Prueba 3: Condicion1 = FALSE y Condicion2 = FALSE
Prueba 4: Condicion1 = TRUE y Condicion2 = TRUE
Bastan las pruebas 2 y 3 para tener cubiertas todas las ramas. Pero con ellos sólo hemos probado una posibilidad para la Condición1.
Para afrontar esta problemática se define un criterio de cobertura de condición/decisión que trocea las expresiones booleanas complejas en sus componentes e intenta cubrir todos los posibles valores de cada uno de ellos.

Nótese que no basta con cubrir cada una de las condciones componentes, si no que además hay que cuidar de sus posibles combinaciones de forma que se logre siempre probar todas y cada una de las ramas. Así, en el ejemplo anterior no basta con ejecutar las pruebas 1 y 2, pues aun cuando cubrimos perfectamente cada posibilidad de cada condición por separado, lo que no hemos logrado es recorrer las dos posibles ramas de la decisión combinada. Para ello es necesario añadir la prueba 3.

El conjunto mínimo de pruebas para cubrir todos los aspectos es el formado por las pruebas 3 y 4. Aún así, nótese que no hemos probado todo lo posible. Por ejemplo, si en el programa nos colamos y ponemos AND donde queríamos poner OR (o viceversa), este conjunto de pruebas no lo detecta. Sólo queremos decir que la cobertura es un criterio útil y práctico; pero no es prueba exhaustiva.
4. Cobertura de bucles
Los bucles no son más que segmentos controlados por decisiones. Así, la cobertura de ramas cubre plenamente la esencia de los bucles. Pero eso es simplemente la teoría, pues la práctica descubre que los bucles son una fuente inagotable de errores, todos triviales, algunos mortales.
Un bucle se ejecuta un cierto número de veces; pero ese número de veces debe ser muy preciso, y lo más normal es que ejecutarlo una vez de menos o una vez de más tenga consecuencias indeseables. Y, sin embargo, es extremadamente fácil equivocarse y redactar un bucle que se ejecuta 1 vez de más o de menos.

Para un bucle de tipo WHILE hay que pasar 3 pruebas
1. 0 ejecuciones
2. 1 ejecución
3. más de 1 ejecución
Para un bucle de tipo REPEAT hay que pasar 2 pruebas
1. 1 ejecución
2. más de 1 ejecución
Los bucles FOR, en cambio, son muy seguros, pues en su cabecera está definido el número de veces que se va a ejecutar. Ni una más, ni una menos, y el compilador se encarga de garantizarlo. Basta pues con ejecutarlos 1 vez.

No obstante, conviene no engañarse con los bucles FOR y examinar su contenido. Si dentro del bucle se altera la variable de control, o el valor de alguna variable que se utilice en el cálculo del incremento o del límite de iteración, entonces eso es un bucle FOR con trampa.
También tiene "trampa" si contiene sentencias del tipo EXIT (que algunos lenguajes denominan BREAK) o del tipo RETURN. Todas ellas provocan terminaciones anticipadas del bucle. Estos últimos párrafos hay que precisarlos para cada lenguaje de programación. Lo peor son aquellos lenguajes que permiten el uso de sentencias GOTO.
CAJA NEGRA:
También conocida como pruebas de caja opaca, pruebas funcionales, pruebas de entrada/salida, pruebas inducidas por los datos.
Las pruebas de caja negra se centran en lo que se espera de un módulo, es decir, intentan encontrar casos en que el módulo no se atiene a su especificación. Por ello se denominan pruebas funcionales, y el probador se limita a suministrarle datos como entrada y estudiar la salida, sin preocuparse de lo que pueda estar haciendo el módulo por dentro.

Las pruebas de caja negra están especialmente indicadas en aquellos módulos que van a ser interfaz con el usuario (en sentido general: teclado, pantalla, ficheros, canales de comunicaciones, etc etc) Este comentario no obsta para que sean útiles en cualquier módulo del sistema.

Las pruebas de caja negra se apoyan en la especificación de requisitos del módulo. De hecho, se habla de "cobertura de especificación" para dar una medida del número de requisitos que se han probado. Es fácil obtener coberturas del 100% en módulos internos, aunque puede ser más laborioso en módulos con interfaz al exterior. En cualquier caso, es muy recomendable conseguir una alta cobertura en esta línea.

El problema con las pruebas de caja negra no suele estar en el número de funciones proporcionadas por el módulo (que siempre es un número muy limitado en diseños razonables); sino en los datos que se le pasan a estas funciones. El conjunto de datos posibles suele ser muy amplio (por ejemplo, un entero).

A la vista de los requisitos de un módulo, se sigue una técnica algebráica conocida como "clases de equivalencia". Esta técnica trata cada parámetro como un modelo algebráico donde unos datos son equivalentes a otros. Si logramos partir un rango excesivamente amplio de posibles valores reales a un conjunto reducido de clases de equivalencia, entonces es suficiente probar un caso de cada clase, pues los demás datos de la misma clase son equivalentes.

El problema está pues en identificar clases de equivalencia, tarea para la que no existe una regla de aplicación universal; pero hay recetas para la mayor parte de los casos prácticos:
· si un parámetro de entrada debe estar comprendido en un cierto rango, aparecen 3 clases de equivalencia: por debajo, en y por encima del rango.
· si una entrada requiere un valor concreto, aparecen 3 clases de equivalencia: por debajo, en y por encima del rango.
· si una entrada requiere un valor de entre los de un conjunto, aparecen 2 clases de equivalencia: en el conjunto o fuera de él.
· si una entrada es booleana, hay 2 clases: si o no.
· los mismos criterios se aplican a las salidas esperadas: hay que intentar generar resultados en todas y cada una de las clases.
Ejemplo: utilizamos un entero para identificar el día del mes. Los valores posibles están en el rango [1..31]. Así, hay 3 clases:
1. números menores que 1
2. números entre 1 y 31
3. números mayores que 31
Durante la lectura de los requisitos del sistema, nos encontraremos con una serie de valores singulares, que marcan diferencias de comportamiento. Estos valores son claros candidatos a marcar clases de equivalencia: por abajo y por arriba.

Una vez identificadas las clases de equivalencia significativas en nuestro módulo, se procede a coger un valor de cada clase, que no esté justamente al límite de la clase. Este valor aleatorio, hará las veces de cualquier valor normal que se le pueda pasar en la ejecución real.
La experiencia muestra que un buen número de errores aparecen en torno a los puntos de cambio de clase de equivalencia. Hay una serie de valores denominados "frontera" (o valores límite) que conviene probar, además de los elegidos en el párrafo anterior. Usualmente se necesitan 2 valores por frontera, uno justo abajo y otro justo encima.

PORTADA

Pedro Aleksander Bernal

Estudiante de Ingeniéría de Sistemas
Universidad Nacional Abierta y a Distancia
Noviembre de 2008.

miércoles, 26 de noviembre de 2008

CONCLUSIONES

- Las pruebas de software permiten la ejecución de un programa cuya intención u objetivo principal es el de detectar errores presentes en el software con el fin de disminuirlos y corregirlos para que a su vez se mejore la calidad con la que se producen los diferentes aplicativos.
- Las pruebas de caja blanca poseen criterior basados en el contenido y la estructura del código fuente de los modulos, mientras que llas pruebas de caja negra poseen criterios basados en las interfaces y las especificaciones de los módulos.