TRABAJO COLABORATIVO No. 3
PRUEBAS DE SOFTWARE - CALIDAD DE SOFTWARE
PRESENTADO POR:
MARIA DEL PILAR AMAYA NIÑO
24.176.303
TUTOR:
JOHN MONTES
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA “UNAD”
ESCUELA DE CIENCIAS BÁSICAS, E INGENIERÍA
PROGRAMA DE INGENIERIA DE SISTEMAS
2008
Técnicas de pruebaPRUEBAS DE SOFTWARE - CALIDAD DE SOFTWARE
PRESENTADO POR:
MARIA DEL PILAR AMAYA NIÑO
24.176.303
TUTOR:
JOHN MONTES
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA “UNAD”
ESCUELA DE CIENCIAS BÁSICAS, E INGENIERÍA
PROGRAMA DE INGENIERIA DE SISTEMAS
2008
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.
Diseño de casos de prueba
Se trata de diseñar pruebas que tengan la mayor probabilidad de encontrar el
mayor número de errores con la mínima cantidad de esfuerzo y de tiempo.
Cualquier producto de ingeniería se puede probar de dos formas:
PRUEBAS DE CAJA NEGRA:
Las pruebas de caja negra se llevan a cabo sobre la interfaz del software, obviando el comportamiento interno y la estructura del programa.
Los casos de prueba de la caja negra pretenden demostrar que:
Las funciones del software son operativas
La entrada se acepta de forma correcta
Se produce una salida correcta
La integridad de la información externa se mantiene
A continuación se derivan conjuntos de condiciones de entrada que utilicen todos los requisitos funcionales de un programa.
Las pruebas de caja negra pretenden encontrar estos tipos de errores:
Funciones incorrectas o ausentes
Errores en la interfaz
Errores en estructuras de datos o en accesos a bases de datos externas
Errores de rendimiento
Errores de inicialización y de terminación
PRUEBAS DE CAJA BLANCA
La prueba de la caja blanca es un método de diseño de casos de prueba que usa la estructura de control del diseño procedimental para derivar los casos de prueba.
Las pruebas de caja blanca intentan garantizar que:
Se ejecutan al menos una vez todos los caminos independientes decada módulo.
Se utilizan las decisiones en su parte verdadera y en su parte falsa
Se ejecuten todos los bucles en sus límites
Se utilizan todas las estructuras de datos internas
Funcionalidad incorrecta ó faltante:
La funcionalidad es correcta, ya que los enlaces realizados en los formularios están correctamente lo que hacen que el sistema corra bien y la grafica funcione correctamente.
Análisis de Valores Límite:
Los valores limite de la ecuación en este caso para X es -5 y 5 fueron exactos dándole su respectivo valor a Y por lo tanto no surgió ningún problema
Prueba de Seguridad
Los tipos de restricción fueron respetados por el programa ya que como se dijo anteriormente se respetaron los limites de la ecuación.
Prueba de rendimiento
Al ejecutar el programa la duración en calcular los datos de Y es mínimo podríamos hablar de uno o dos segundo; por lo tanto se deduce que el programa es muy ágil.
Aplicación Prueba de Caja Blanca
Representacion en forma de Grafos todas las decisiones lógicas intervenidas en el programa
Representar en forma de Grafos todos los posibles bucles que intervienen en el desarrollo de procesos.
FORMULA 1
Private Sub Comando11_Click()
If x <> 0 Then
MsgBox "La fórmula ya está calculada."
Else
incremento = -5
x = -5
While incremento <= 5 n = ((5 ^ x) + (3 * x) + 2) DoCmd.GoToRecord , , acNewRec m = incremento incremento = (incremento + 0.5) x = m y = n Wend DoCmd.OpenQuery "borra", , acReadOnly DoCmd.Close DoCmd.OpenForm "formula" End If End Sub Private Sub Comando4_Click() If x <> 0 Then
MsgBox "La fórmula ya está calculada."
Else
incremento = -5
x = -5
While incremento <= 5 n = ((x * x) + (4 * x) + 5) DoCmd.GoToRecord , , acNewRec m = incremento incremento = (incremento + 0.5) x = m y = n Wend DoCmd.OpenQuery "borra", , acReadOnly DoCmd.Close DoCmd.OpenForm "formula" End If End Sub Private Sub Comando5_Click() On Error GoTo Err_Comando5_Click DoCmd.OpenQuery "eliminar", , acReadOnly DoCmd.OpenQuery "eliminar", , acReadOnly DoCmd.Close Exit_Comando5_Click: Exit Sub Err_Comando5_Click: MsgBox Err.Description Resume Exit_Comando5_Click End Sub Private Sub Comando8_Click() DoCmd.OpenForm "Grafico" End Sub Private Sub Form_Activate() DoCmd.Maximize End Sub FORMULA 2 Private Sub Comando11_Click() If x <> 0 Then
MsgBox "La fórmula ya está calculada."
Else
incremento = -5
x = -5
While incremento <= 5 n = ((5 ^ x) + (3 * x) + 2) DoCmd.GoToRecord , , acNewRec m = incremento incremento = (incremento + 0.5) x = m y = n Wend DoCmd.OpenQuery "borra", , acReadOnly DoCmd.Close DoCmd.OpenForm "formula" End If End Sub Private Sub Comando4_Click() If x <> 0 Then
MsgBox "La fórmula ya está calculada."
Else
incremento = -5
x = -5
While incremento <= 5
n = ((x * x) + (4 * x) + 5)
DoCmd.GoToRecord , , acNewRec
m = incremento
incremento = (incremento + 0.5)
x = m
y = n
Wend
DoCmd.OpenQuery "borra", , acReadOnly
DoCmd.Close
DoCmd.OpenForm "formula"
End If
End Sub
Private Sub Comando5_Click()
On Error GoTo Err_Comando5_Click
DoCmd.OpenQuery "eliminar", , acReadOnly
DoCmd.OpenQuery "eliminar", , acReadOnly
DoCmd.Close
Exit_Comando5_Click:
Exit Sub
Err_Comando5_Click:
MsgBox Err.Description
Resume Exit_Comando5_Click
End Sub
Private Sub Comando8_Click()
DoCmd.OpenForm "Grafico"
End Sub
Private Sub Form_Activate()
DoCmd.Maximize
End Sub
Se determino la importancia de las pruebas que se deben realizar en proceso de ejecución de un programa, las cuales se hacen con la intención de descubrir un error.
Un buen caso de prueba es aquel que tiene una alta probabilidad de
mostrar un error no descubierto hasta entonces.
Es importante que como ingenieros diseñemos casos de prueba que, sistemáticamente, saquen a la luz diferentes clases de errores, haciéndolo con la menor cantidad de tiempo y de esfuerzo.
Debemos tener en cuenta que las pruebas no pueden asegurar ausencia de errores; estos pueden demostrar que existen defectos en el software.
El conjunto de casos de prueba pueden ser infinitos, por lo tanto se deben escoger los mejores casos de prueba.
Si existen módulos sospechosos conviene aislarlos y probarlos concienzudamente.
Permitir a personas ajenas al proyecto para que las pruebas necesarias
Realizar revisiones grupales de los códigos fuente
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.
Diseño de casos de prueba
Se trata de diseñar pruebas que tengan la mayor probabilidad de encontrar el
mayor número de errores con la mínima cantidad de esfuerzo y de tiempo.
Cualquier producto de ingeniería se puede probar de dos formas:
PRUEBAS DE CAJA NEGRA:
Las pruebas de caja negra se llevan a cabo sobre la interfaz del software, obviando el comportamiento interno y la estructura del programa.
Los casos de prueba de la caja negra pretenden demostrar que:
Las funciones del software son operativas
La entrada se acepta de forma correcta
Se produce una salida correcta
La integridad de la información externa se mantiene
A continuación se derivan conjuntos de condiciones de entrada que utilicen todos los requisitos funcionales de un programa.
Las pruebas de caja negra pretenden encontrar estos tipos de errores:
Funciones incorrectas o ausentes
Errores en la interfaz
Errores en estructuras de datos o en accesos a bases de datos externas
Errores de rendimiento
Errores de inicialización y de terminación
PRUEBAS DE CAJA BLANCA
La prueba de la caja blanca es un método de diseño de casos de prueba que usa la estructura de control del diseño procedimental para derivar los casos de prueba.
Las pruebas de caja blanca intentan garantizar que:
Se ejecutan al menos una vez todos los caminos independientes decada módulo.
Se utilizan las decisiones en su parte verdadera y en su parte falsa
Se ejecuten todos los bucles en sus límites
Se utilizan todas las estructuras de datos internas
Funcionalidad incorrecta ó faltante:
La funcionalidad es correcta, ya que los enlaces realizados en los formularios están correctamente lo que hacen que el sistema corra bien y la grafica funcione correctamente.
Análisis de Valores Límite:
Los valores limite de la ecuación en este caso para X es -5 y 5 fueron exactos dándole su respectivo valor a Y por lo tanto no surgió ningún problema
Prueba de Seguridad
Los tipos de restricción fueron respetados por el programa ya que como se dijo anteriormente se respetaron los limites de la ecuación.
Prueba de rendimiento
Al ejecutar el programa la duración en calcular los datos de Y es mínimo podríamos hablar de uno o dos segundo; por lo tanto se deduce que el programa es muy ágil.
Aplicación Prueba de Caja Blanca
Representacion en forma de Grafos todas las decisiones lógicas intervenidas en el programa
Representar en forma de Grafos todos los posibles bucles que intervienen en el desarrollo de procesos.
FORMULA 1
Private Sub Comando11_Click()
If x <> 0 Then
MsgBox "La fórmula ya está calculada."
Else
incremento = -5
x = -5
While incremento <= 5 n = ((5 ^ x) + (3 * x) + 2) DoCmd.GoToRecord , , acNewRec m = incremento incremento = (incremento + 0.5) x = m y = n Wend DoCmd.OpenQuery "borra", , acReadOnly DoCmd.Close DoCmd.OpenForm "formula" End If End Sub Private Sub Comando4_Click() If x <> 0 Then
MsgBox "La fórmula ya está calculada."
Else
incremento = -5
x = -5
While incremento <= 5 n = ((x * x) + (4 * x) + 5) DoCmd.GoToRecord , , acNewRec m = incremento incremento = (incremento + 0.5) x = m y = n Wend DoCmd.OpenQuery "borra", , acReadOnly DoCmd.Close DoCmd.OpenForm "formula" End If End Sub Private Sub Comando5_Click() On Error GoTo Err_Comando5_Click DoCmd.OpenQuery "eliminar", , acReadOnly DoCmd.OpenQuery "eliminar", , acReadOnly DoCmd.Close Exit_Comando5_Click: Exit Sub Err_Comando5_Click: MsgBox Err.Description Resume Exit_Comando5_Click End Sub Private Sub Comando8_Click() DoCmd.OpenForm "Grafico" End Sub Private Sub Form_Activate() DoCmd.Maximize End Sub FORMULA 2 Private Sub Comando11_Click() If x <> 0 Then
MsgBox "La fórmula ya está calculada."
Else
incremento = -5
x = -5
While incremento <= 5 n = ((5 ^ x) + (3 * x) + 2) DoCmd.GoToRecord , , acNewRec m = incremento incremento = (incremento + 0.5) x = m y = n Wend DoCmd.OpenQuery "borra", , acReadOnly DoCmd.Close DoCmd.OpenForm "formula" End If End Sub Private Sub Comando4_Click() If x <> 0 Then
MsgBox "La fórmula ya está calculada."
Else
incremento = -5
x = -5
While incremento <= 5
n = ((x * x) + (4 * x) + 5)
DoCmd.GoToRecord , , acNewRec
m = incremento
incremento = (incremento + 0.5)
x = m
y = n
Wend
DoCmd.OpenQuery "borra", , acReadOnly
DoCmd.Close
DoCmd.OpenForm "formula"
End If
End Sub
Private Sub Comando5_Click()
On Error GoTo Err_Comando5_Click
DoCmd.OpenQuery "eliminar", , acReadOnly
DoCmd.OpenQuery "eliminar", , acReadOnly
DoCmd.Close
Exit_Comando5_Click:
Exit Sub
Err_Comando5_Click:
MsgBox Err.Description
Resume Exit_Comando5_Click
End Sub
Private Sub Comando8_Click()
DoCmd.OpenForm "Grafico"
End Sub
Private Sub Form_Activate()
DoCmd.Maximize
End Sub
CONCLUSIONES
Se determino la importancia de las pruebas que se deben realizar en proceso de ejecución de un programa, las cuales se hacen con la intención de descubrir un error.
Un buen caso de prueba es aquel que tiene una alta probabilidad de
mostrar un error no descubierto hasta entonces.
Es importante que como ingenieros diseñemos casos de prueba que, sistemáticamente, saquen a la luz diferentes clases de errores, haciéndolo con la menor cantidad de tiempo y de esfuerzo.
Debemos tener en cuenta que las pruebas no pueden asegurar ausencia de errores; estos pueden demostrar que existen defectos en el software.
RECOMENDACIONES
El conjunto de casos de prueba pueden ser infinitos, por lo tanto se deben escoger los mejores casos de prueba.
Si existen módulos sospechosos conviene aislarlos y probarlos concienzudamente.
Permitir a personas ajenas al proyecto para que las pruebas necesarias
Realizar revisiones grupales de los códigos fuente
