Prueba

Investigue
Defina las pruebas y los roles que participan en cada una de ellas.
Prueba de unidad.
Las pruebas unitarias se tienen que poder ejecutar sin necesidad de intervención
manual. Esta característica posibilita que podamos automatizar su ejecución.
Tienen que poder repetirse tantas veces como uno quiera. Por este motivo, la rapidez
de las pruebas tiene un factor clave. Si pasar las pruebas es un proceso lento no se
pasarán de forma habitual, por lo que se perderán los beneficios que éstas nos
ofrecen.
Se deben poder cubrir casi la totalidad del código de nuestra aplicación. Una prueba
unitaria será tan buena como su cobertura de código. La cobertura de código marca la
cantidad de código de la aplicación que está sometido a una prueba. Por tanto, si la
cobertura es baja, significará que gran parte de nuestro código está sin probar. Tienen
que poder ejecutarse independientemente del estado del entorno. No puede afectar la
ejecución de otra. Después de la ejecución de una prueba el entorno debería quedar
igual que estaba antes de realizar la prueba.
Las diferentes relaciones que puedan existir entre módulos deben ser simulada para
evitar dependencias entre módulos. Es importante conocer claramente cuál es el
objetivo del test. Cualquier desarrollador debería poder conocer claramente cuál es el
objetivo de la prueba y su funcionamiento. Esto sólo se consigue si se trata el código
de pruebas como el código de la aplicación. Es importante tener en cuenta que
aunque estas son las características de una buena prueba, no siempre será posible ni
necesario cumplir con todas estas reglas y será la experiencia la que nos guiará en la
realización de las mismas.
Prueba de integración
Los casos de prueba de integración se utilizan para verificar que los componentes
interaccionan entre si de la forma mas apropiada despues de haber sido integrados en
una construccion. Estos pueden ser derivados de las realizaciones de los casos de
uso, debido a que las realizaciones de los casos de uso describen como interaccionan
las clases y los objetos, y a su vez como interaccionan los componentes.

El rol que presenta esta prueba tiene distintos puntos de vista, uno siendo que los
ingenieros de pruebas deberian crear un conjunto de casos de prueba que hicieran
porsible alcanzar los objetivos establecidos en el plan con un esfuerzo minimo. Por
otro lado los diseñadores de pruebas crean los casos de pueba de integracion
consideran como entrada primeramente los diagramas de interaccion de las
realizaciones de casos de uso. Se buscan combinaciones de entrada, salida y estado
inicial de sistema que den lugar a escenarios interesantes que empleen las clases que
participan en los diagramas.

Pasos:
1- Realizar las pruebas de integracion relevantes a la construccion realizando los
procedimientos de prueba manualmente para cada caso de prueba o ejecutando
cualquier componente de prueba que automatice los rendimientos de prueba.
2- Comparar los resultados de las pruebas con los resultados esperados e investigar
los resultados de las pruebas que no coinciden con los esperados.
3- Informar de los defectos a los ingenieros de componenter responsables de los
componentes que se cree contienen los fallos.
4- Informar de los defectos a los diseñadores de pruebas, quienes usaran los defectos
para evaluar los resultados del esfuerzo de prueba.
Pruebas del sistema:
Prueban q el sistema funciona globalmente de forma correcta. Cada prueba del
sistema trabaja combinaciones de CU bajo condiciones diferentes. Se prueba el
sistema como un todo probando CU, unos detrás de otros y, si es posible, en paralelo.
Se trata de ver que cada CU funciona adecuadamente en distintas configuraciones
HW, de carga, con varios actores a la vez, en distinto orden, etc. La prueba de sistema
puede empezar cuando las pruebas de integración son satisfactorias.
Un ingeniero de pruebas de sistemas es responsable de realizar las pruebas de
sistemas necesarias sobre una construcción que muestra el resultado de una
interacción completa. Las pruebas de sistemas se llevan a cabo para verificar las
interacciones entre los actores y el sistema. El ingeniero de pruebas se encarga de
documentar los defectos en los resultados de las pruebas de sistemas. Algunas
pruebas de sistema pueden ser realizadas por otros miembros del proyecto, como los
especificadores de casos de uso, o incluso por personas externas al proyecto, como
usuarios de versiones beta.
Pruebas de aceptación
Se presta atención en recabar los detalles y comentarios por medio de encuestas o
envíos de datos estadísticos no sin antes presentar un cuadro de diálogo al usuario
primerizo o con una versión nueva. El enfoque es verificar que todo opere
correctamente, en el concepto de que si hay un daño este sea limitado y controlado.
Las pruebas de aceptación son pruebas formales que verifican si un sistema satisface
los requisitos empresariales. Requieren que se esté ejecutando toda la aplicación
durante las pruebas y se centran en replicar las conductas de los usuarios.

Planifique y diseñe
a) La Prueba de Unidad para la clase de diseño Producto, explique en qué consiste y
realice lo siguiente:

La prueba de unidad para la clase diseño producto consiste en verificar la

implementación interna de cada método o acción de un componente y se trata de
verificar su comportamiento algorítmico.

ID Caso de Prueba:001 Tipo de Prueba: UNIDAD

Autor del Caso de Prueba: Nélida Cáceres
Requisitos de la prueba: Tiene que existir productos registrados
Propósito de la prueba: Comprobar la búsqueda de los datos del producto y registrar
 todos los cambios en el stock actual del producto.
Descripción de las acciones y/o condiciones para las Pruebas
Nº Acciones (entradas) Salida Esperada Salida Obtenida
1 BuscarDatosProductos() Se busca el código Se muestra por pantalla
Valores de entrada: del producto en el descripción, nombre,
código producto sistema, se espera categoría, precio de
que se muestre compra y de venta,
descripción, nombre, stock actual, mínimo y
categoría, precio de máximo del producto
compra y de venta, registrado con el código
stock actual, mínimo ingresado
y máximo del
producto solicitado.
2 RegistrarNuevoStock () Muestre por pantalla Muestra por pantalla un
Valores de entrada: un mensaje mensaje confirmando el
código producto confirmando el registro del stock pero
registro del nuevo no actualiza stock actual
stock del producto y del producto.
sus datos con su
stock actualizado

Resultados obtenidos
Resultado (Ap/Desap): Aprobado _ Desaprobado
Observaciones:

b) La Prueba de Integración para el caso de uso

CU01: Realizar pedido proveedor.
Utilice el cuadro del ejercicio anterior para diseñar la prueba

Prueba de integración para los componentes ficha producto, ficha proveedor y

ficha pedido.

ID Caso de Prueba:002 Tipo de Prueba: INTEGRACION

Autor del Caso de Prueba: Farfán
Requisitos de la prueba: Tienen que existir proveedores registrados en el sistema
Propósito de la prueba: Realizar pedido a proveedor
Descripción de las acciones y/o condiciones para las Pruebas
Nº Acciones (entradas) Salida Esperada Salida Obtenida
1 Clase: Producto Se busca el código No se muestra por
Método: del producto en el pantalla
BuscarDatosProductos() sistema, se espera descripción, precio
Valores de entrada: código que se muestre de compra y de
producto descripción, nombre, venta, stock
categoría, precio de mínimo y máximo
compra y de venta, del producto
stock actual, mínimo y registrado con el
máximo del producto código ingresado
solicitado.
Resultados obtenidos prueba 01, verificación 01: Desaprobado
1 Clase: Producto Se busca el código Se muestra por
Método: del producto en el pantalla
 BuscarDatosProductos() sistema, se espera descripción,
Valores de entrada: código que se muestre nombre, categoria,
producto descripción, nombre, precio de compra y
categoría, precio de de venta, stock
compra y de venta, actual, mínimo y
stock actual, mínimo y máximo del
máximo del producto producto registrado
solicitado. con el código
ingresado
Resultados obtenidos prueba 01, verificación 02: Aprobado
02 Clase: Pedido Se muestra por Se muestra por
Metodo: registrarPedido() pantalla un mensaje pantalla un
Valores de entrada: número de confirmando el mensaje de error.
pedido registro del pedido y
sus correspondientes
datos ( numero,
fecha, datos
proveedor, detalles
del producto, legajo).
Resultados obtenidos prueba 02, verificación 01: Desaprobado
02 Clase: Pedido Se muestra por Se muestra por
Método: registrarPedido() pantalla un mensaje pantalla un
Valores de entrada: número de confirmando el mensaje
pedido registro del pedido y confirmando el
sus correspondientes registro del pedido
datos (numero, fecha, y sus
datos proveedor, correspondientes
detalles del producto, datos.
legajo).
Resultados obtenidos prueba 02, verificación 02: Aprobado
03 Clase: Proveedor Se busca el CUIT del Muestra por
Método: buscarProveedor() proveedor en el pantalla algunos
Valores de entrada: CUIT del sistema y se espera detalles del
proveedor que se muestre por proveedor.
pantalla todos los
detalles del
proveedor.
Resultados obtenidos prueba 03, verificación 01: Desaprobado
03 Clase: Proveedor Se busca el CUIT del Muestra por
Método: buscarProveedor() proveedor en el pantalla todos los
Valores de entrada: CUIT del sistema y se espera detalles del
proveedor que se muestre por proveedor ( CUIT,
pantalla todos los DNI, apellido,
detalles del nombre, domicilio,
proveedor. teléfono, localidad,
correo y provincia).
Resultados obtenidos prueba 03, verificación 01: Aprobado