Semana 6 taller de integración informatica iacc

Marcelo Molina control 6

Programación avanzada II

Control Semana 6

Marcelo Molina Segovia

Taller de Integración Informática

Instituto IACC

17 de mayo de 2021

0

1

[pic 1]

Instrucciones:

Se requiere que incorpore a la plantilla donde está desarrollando su proyecto de título

los siguientes aspectos:

El plan de pruebas del sistema:



Identifique y mencione los tipos de prueba que realizará a su diseño de sistema (se deben

incluir al menos 4 tipos de prueba).



Elabore el plan de pruebas por cada prueba definida donde indique:

a. Enfoque: explicación general de la estrategia a implementar en la prueba

b. Elementos a probar

c. Criterio de aceptación de un caso de prueba

d. Tareas a realizar

e. Necesidades ambientales

f. Responsabilidades

g. Riesgos y contingencia



Defina los usuarios que ejecutaran las pruebas. Explique el tipo de usuario y en qué

pruebas participarán.



Elabore la lista de verificación de las pruebas. Realice las pruebas y muestre los

resultados respectivos. En caso de fallos indique el método de corrección de prueba

utilizado y explique el método de depuración utilizado.

Desarrollo:

0

1

[pic 2]

Las 4 pruebas que se realizaran al sistema son:

Prueba de caja blanca: esta prueba consiste en saber la lógica interna del código fuente del

sistema, su estructura condicional y la lógica de los estados que se consideraron.

Pruebas de integración: estas pruebas consisten en probar el funcionamiento de los distintos

sistemas que interfieren en la aplicación como el servicio web con la pagina HTML.

Pruebas de contenido: estas pruebas busca verificar la coherencia y consistencia y que el usuario

entienda la idea y las palabras usadas en el programa.

Pruebas de usabilidad: probar que tan fácil es para el usuario manejar el programa cuanto se

demora en dominarlo y cuantos errores comenten y se demoran en resolver por ultimo ver la satisfacción

del usuario al usar el programa.

Plan de prueba de caja blanca:

a. Enfoque: se estudiara y revisara cada segmento del código fuente y que este

adecuadamente comentado y en bloques cada segmento de la funciones.

b. Elementos a probar: el código fuente y sus bases de datos.

c. Criterio de aceptación de un caso de prueba: se considera exitoso el código fuente

si no consume muchos recursos está bien comentado y cada módulo del programa

funciona correctamente.

d. Tareas a realizar: revisar cada segmento del código fuente, revisar la base de datos

que coincida con el código fuente.

0

1

[pic 3]

e. Necesidades ambientales: es necesario que el programador auditor tenga todo los

elementos del programa ya sea el código fuente y la base de datos además de una

maquina con los recursos necesarios para revisar ambos módulos.

f. Responsabilidades: todas las pruebas serán realizadas por el equipo de pruebas y

los programadores en conjunto con el programador audito.

g. Riesgos y contingencia: que los programadores arreglen un erro antes de ser visto

por el programador auditor, que el programa consuma más recursos de lo previsto,

que tome más tiempo de lo habitual en hacer las revisiones.

Plan de prueba de integración:

a. Enfoque: probar la aplicación en el entorno html y su estabilidad.

b. Elementos a probar: la aplicación en un entorno web con la funcionalidad de

todos sus módulos.

c. Criterio de aceptación de un caso de prueba: se considera exitosa la prueba si la

aplicación funciona con todos sus módulos atreve de un navegador web a

distancia o fuera de la red de la empresa.

d. Tareas a realizar: definir la ruta HTML para conectarse a la aplicación. Probar la

estabilidad de cada módulo, conectarse desde una red externa para ver

conectividad.

e. Necesidades ambientales: un computador y la ruta “página web” donde se

conectara al programa el usuario. Dos redes para conectar el computador una de la

empresa y otra externa.

0

1

[pic 4]

f. Responsabilidades: todas las pruebas serán realizadas por el equipo de pruebas y

los programadores en conjunto con el programador audito.

g. Riesgos y contingencia: la ruta esta mala. La aplicación no se conecta con la base

de datos, los módulos no responden, la aplicación se demora mucho, el body de la

aplicación esta descuadrado.

Plan de prueba de contenido:

a. Enfoque: revisar el body de la aplicación en conjunto con un par de usuarios final

y centralizar las ideas y términos a usar en cada módulo.

...