Desarrollo de software
Las pruebas del sistema implican integrar dos o más componentes que implementan funciones del sistema o características y a continuación se prueba este sistema integrado. En un proceso de desarrollo iterativo, las pruebas del sistema se ocupan de probar un incremento que va a ser entregado al cliente; en un proceso en cascada, las pruebas del sistema se ocupan de probar elsistema completo.
Para la mayoría de los sistemas complejos, existen dos fases distintas de pruebas del sistema:
l. Pruebas de integración, en las que el equipo de pruebas tiene acceso al código fuente del sistema. Cuando se descubre un problema, el equipo de integración intenta encontrar la fuente del problema e identificar los componentes que tienen que ser depurados. Las pruebas deintegración se ocupan principalmente de encontrar defectos en el sistema.
2. Pruebas de entregas, en las que se prueba una versión del sistema que podría ser entregada a los usuarios. Aquí, el equipo de pruebas se ocupa de validar que el sistema satisface sus requerimientos y con asegurar que el sistema es confiable. Las pruebas de entregas son normalmente pruebas de caja negra en las que el equipode pruebas.
Se ocupa simplemente de demostrar si el sistema funciona o no correctamente. Los problemas son comunicados al equipo de desarrollo cuyo trabajo es depurar el programa.
Cuando los clientes se implican en las pruebas de entregas, éstas a menudo se denominan pruebas de aceptación. Si la entrega es lo suficientemente buena, el cliente puede entonces aceptarla para su uso.Fundamentalmente, se puede pensar en las pruebas de integración como las pruebas de sistemas incompletos compuestos por grupos de componentes del sistema. Las pruebas de entregas consisten en probar la entrega del sistema que se pretende proporcionar a los clientes.
Pruebas de entregas
Las pruebas de entregas son el proceso de probar una entrega del sistema que será distribuida a los clientes. Elprincipal objetivo de este proceso es incrementar la confianza del suministrador en que el sistema satisface sus requerimientos. Si es así, éste puede entregarse como un producto o ser entregado al cliente. Para demostrar que el sistema satisface sus requerimientos, tiene que mostrarse que éste entrega la funcionalidad especificada, rendimiento y confiabilidad.
Las pruebas de entregas son normalmenteun proceso de pruebas de caja negra en las que las pruebas se derivan a partir de la especificación del sistema. El sistema se trata como una caja negra cuyo comportamiento sólo puede ser determinado estudiando sus entradas y sus salidas relacionadas. Otro nombre para esto es pruebas funcionales, debido a que al probador sólo le interesa la funcionalidad y no la implementación del software.Autores adecuada como Whittaker (Whittaker, 2002) han recogido su experiencia de pruebas en un conjunto de guías que incrementan la probabilidad de que las pruebas de defectos tengan éxito. Algunos ejemplos de estas guías son:
l. Elegir entradas que fuerzan a que el sistema genere todos los mensajes de error.
2. Diseñar entradas que hacen que los búferes de entrada se desborden.
3. Repetir lamisma entrada o series de entradas varias veces.
4. Forzar a que se generen las salidas inválidas.
5. Forzar los resultados de los cálculos para que sean demasiado grandes o demasiado pequeños.
Para validar que el sistema satisface los requerimientos la mejor aproximación a utilizar es la prueba basada en escenarios, en la que se idean varios escenarios y se desarrollan casos de prueba apartir de estos escenarios. Por ejemplo, el siguiente escenario podría describir cómo el sistema de librería LIBSYS, tratado en capítulos anteriores, podría utilizarse:
Una estudiante escocesa que estudia la Historia Americana tiene que escribir un trabajo sobre «la mentalidad sobre las fronteras en el Este Americano desde 1840 a 1880». Para hacer esto necesita encontrar documentación de varias...
Regístrate para leer el documento completo.