Sie sind auf Seite 1von 5

Técnicas de prueba del Software

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

Verificación se refiere a un conjunto de tareas que se La validación se refiere a un conjunto diferente de


llevan a cabo para verificar si el software implementa actividades que se llevan a cabo para garantizar que el
correctamente una función específica. software se construya según los requisitos del cliente.

La verificación se centra en el proceso. La validación se centra en el producto.

Comprueba si el producto que se construye es Comprueba si el producto correcto está construido o no.
correcto o no.

El objetivo de la verificación es garantizar que el El objetivo de la validación es garantizar que el


producto cumpla con los requisitos y las producto cumpla con los requisitos del usuario.
especificaciones de diseño.

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 equipo de control de calidad (QA) realiza la El equipo de pruebas realiza la validación.


verificación.

La verificación se realiza antes de la validación de Validación realizada después de la verificación de


preformado. preformado.
Si, las dos utilizan métodos de diseño de casos de prueba y estrategias de prueba, para la validación se
utiliza la pruebas de caja negra, mientras que para la verificación se utiliza la pruebas de caja blanca.

17.6- ¿Cómo puede la calendarización del proyecto afectar la prueba de integración?


La calendarización es la definición de marco de tiempo aproximado para eventos futuros. La
calendarización, por ejemplo, se utiliza en el diseño de las principales actividades del Marco para el
proyecto. Si el proyecto está retrasado, las pruebas de integración ni siquiera pueden comenzar. La
prueba de integración se realiza después de la prueba de unidad que ocurre después de la codificación.
Además, si la calendarización es ajustada, los gerentes de proyecto podrían reducir potencialmente el
tiempo en las pruebas de integración, reduciendo así la calidad o aumentando el costo.

17.8- ¿Quién debe realizar la prueba de validación: el desarrollador o el usuario del


software? Justifique su respuesta.
A la hora de tener el cuenta la validación o algún examen exhaustivo de nuestro software, teniendo en
cuenta el lanzamiento de este, debemos conocer cual persona es la encargada de validar dichos
software.

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

2. Contador de inicio de sesión:


Es posible que las pruebas de la caja negra no puedan abrumar un cierto valor de tipo de datos, por
ejemplo, Int 65326, pero si el desarrollador realiza un seguimiento de los contadores de inicio de
sesión, el valor entero puede ser superado pronto y existe la posibilidad de error. Bucle en caja blanca
(¿Cobertura de estado de cuenta?) Encontraría el problema.

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

1.Según las prueba de Unidades La cobertura de condición/decisión.

¿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).

Das könnte Ihnen auch gefallen