Beruflich Dokumente
Kultur Dokumente
17.1- Con sus palabras, describa la diferencia entre verificación y validación. ¿Ambas
usan los métodos de diseño de casos de prueba y estrategias de pruebas? Explique su
respuesta.
Verificación Validación
Comprueba si el producto que se construye es Comprueba si el producto correcto está construido o no.
correcto o no.
Se ocupa de las especificaciones internas del Trata directamente con los usuarios y sus
producto. requerimientos.
Las técnicas de verificación son revisiones, Las técnicas de validación son pruebas de caja blanca,
reuniones, inspecciones, etc. pruebas de caja negra, pruebas de caja gris, etc.
El desarrollador debe validar y dar a conocer que el código desarrollado funcione correctamente con
los requerimientos levantados anteriormente. Se debe realizar de la siguiente manera: se debe escribir
o realizar pruebas unitarias manualmente.
Después de esto, los ingenieros de control de calidad(QAs), deben realizar distintas pruebas más
exhaustivas, además de pruebas muy importantes como lo son las de regresión, estas últimas se
realizan si el software las requiere.
Finalmente, debemos organizar las pruebas de aceptación del usuario (UAT, User Acceptance
Testing). Sobre la base de estos resultados, podemos decidir implementar una nueva versión del
software.
18.3-Proporcione al menos tres ejemplos en los que la prueba de caja negra puede dar la
impresión de que “todo está bien”, mientras que las pruebas de caja blanca pueden
descubrir un error. Proporcione al menos tres ejemplos en los que las pruebas de caja
blanca pueden dar la impresión de que “todo está bien”, mientras que las pruebas de
caja negra pueden descubrir un error.
Prueba de caja negra
1.Para la ventana de inicio de sesión, suponga que proporciona uname y contraseña y hace clic en
"Cancelar", vuelve a la ventana de inicio de sesión pero la base de datos aún mantiene el registro y lo
guarda.
En este caso, la prueba de caja negra verificará que el botón "Cancelar" funciona correctamente y la
ventana de inicio de sesión vuelve a aparecer. Pero solo las pruebas de caja blanca serían capaces de
asegurarse de que los datos recopilados realmente se hayan descartado o no
3. Cuando hay un disparador de bucle sin fin al configurar algo en la aplicación, por ejemplo. un
vehículo alcanzado en Times Square = Verdadero y una vez verdadero un bucle while sigue iniciando
x clases. Funcionalmente, nada estaría mal, pero esto podría ser un desastre en términos de pérdida de
memoria.
Prueba de caja blanca
¿Qué ocurre cuando la expresión booleana es más compleja? Es decir si se desea ingresar
al sistema ingresando un nombre de usuario erróneo a simple vista todo estará bien pero
al momento de verificar la condición en el sistema arrojará un error.
SQL
If Not rsempleado.EOF Then
If rsempleado.Fields(5) = LCase(txtpassword) Then
Unload Me
frmprincipal.Show
frmprincipal.StatusBar1.Panels(1).Text = "Usuario del Sistema: " & txtnom
End If
Else
MsgBox "Usuario no Autorizado", vbExclamation, "Aviso"
txtnom = ""
txtpassword = ""
txtnom.SetFocus
End If
End Sub
2.En pruebas de software, conociendo una función específica para la que fue diseñado el
producto, se pueden diseñar pruebas que demuestren que dicha función está bien
realizada. Dichas pruebas son llevadas a cabo sobre la interfaz del software, es decir, de la
función, actuando sobre ella como una caja negra, proporcionando unas entradas y
estudiando las salidas para ver si son o no las esperadas. | En los sistemas orientados a
objetos, las pruebas de caja blanca pueden aplicarse a los métodos de la clase, pero según
varias opiniones, ese esfuerzo debería dedicarse a otro tipo de pruebas más especializadas
(un argumento podría ser que los métodos de una clase suelen ser menos complejos que
los de una función de programación estructurada.
3.Al ejecutar una aplicación del sistema bibliotecario se ejecuta con normalidad
basándose en el código como lo hace las pruebas de caja blanca pero al momento de
llenar la base de datos se aplica las pruebas sobre el sistema como lo hace las pruebas de
caja negra si no se realiza siguiendo la integridad referencial de los datos nos arrojará
errores en el sistema.
18.4- ¿Las pruebas exhaustivas (incluso si es posible para programas muy pequeños)
garantizarán que el programa es 100 por ciento correcto? Explique su respuesta.
No, incluso las pruebas exhaustivas no garantizarán que la el programa es 100 por ciento correcto.
Hay demasiadas variables a tener en cuenta.
Considera lo siguiente:
Pruebas de instalación
¿Se instaló el programa de acuerdo con las instrucciones?
Pruebas de integración:
¿Funcionó el programa con todos los otros programas en el sistema sin interferencia, y lo hizo
Los módulos instalados del programa se integran y funcionan.
¿Con otros módulos instalados?
Prueba de funcionamiento:
¿Funcionó cada una de las funciones del programa correctamente?
Pruebas unitarias:
¿Funcionó la unidad como independiente diseñado, y funcionó la unidad cuando se coloca en la
general proceso?
Pruebas de aceptación del usuario: ¿cumplió el programa todos los
¿Los requisitos del usuario y el trabajo según el diseño del usuario?
Si bien estas son solo las pruebas básicas para una exhaustiva escenario de prueba, podría seguir
probando más allá de estas pruebas utilizando métodos destructivos, programa interno de caja blanca,
pruebas, establecer ejercicios del programa utilizando automatizado guiones, etc.
En conclusión las pruebas tienen que detenerse en algún momento en hora. O bien el tiempo se acaba
que fue asignado para
prueba, o usted gana un nivel de confianza que el programa es yendo a trabajar. (Por supuesto, cuanto
más pruebas, más alto su nivel de confianza).