Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

Gerty Niklistchek Control6

Descargar como pdf o txt
Descargar como pdf o txt
Está en la página 1de 6

TALLER DE INTEGRACIÓN INFORMÁTICA

SEMANA 6

Gerty Marioly Niklistchek Carrillo


26 de febrero de 2023
Técnico en informática
Identifique y mencione los tipos de prueba que realizará a su diseño de sistema (se deben incluir al menos
4 tipos de prueba). Valor, 1 punto.
Elabore el plan de pruebas por cada prueba definida donde indique: Valor, 5 puntos.
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. Valor 1 punto.

• Elabore la lista de verificación de las pruebas. Valor 1 punto.


• 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. Valor 1 punto.

DESARROLLO
El sistema se someterá a 4 pruebas:

Pruebas de caja blanca: estas pruebas consisten en comprender la lógica interna del código fuente
del sistema, su estructura condicional y la lógica del estado en cuestión.

Pruebas de integración: estas pruebas implican probar el comportamiento de varios sistemas que
interfieren con la aplicación, como los servicios con páginas HTML.

Pruebas de contenido: estas pruebas están diseñadas para verificar la coherencia y la consistencia
y si los usuarios comprenden las ideas y las palabras utilizadas en el programa.

Prueba de usabilidad: verifique qué tan fácil es para los usuarios comenzar a usar el programa,
cuánto tiempo se tarda en aprender el programa, cuántos errores se cometen, cuánto se tarda en
resolverlos y, por último, verifique la satisfacción del usuario al usar el programa.
Calendario de pruebas de caja blanca:
Metodología:
1. Cada pieza de código fuente será estudiada y revisada, y cada pieza de funcionalidad será
completamente comentada y fragmentada.
2. Elementos por probar: código fuente y su base de datos.
3. Criterios de aceptación del caso de prueba: El código fuente se considera exitoso si no
consume muchos recursos, está bien comentado y todos los módulos del programa funcionan
correctamente.
4. Tarea para realizar: Mire cada segmento del código fuente, mire la base de datos para
encontrar una coincidencia con el código fuente.
5. Requisitos ambientales: El programador auditor debe disponer de todos los elementos del
programa, ya sea código fuente o base de datos, y una máquina con los recursos necesarios
para probar ambos módulos.
6. Responsabilidades: Todas las pruebas son realizadas por el equipo de pruebas y los
programadores junto con los programadores de revisión.
7. riesgos y contingencias: los programadores corrigen los errores antes de que los
programadores auditores los vean, el programa utiliza más recursos de los esperados, los
cambios tardan más de lo habitual.

Plan de prueba de integración:


a. Método: Comprobar la aplicación y su estabilidad en el entorno html.
b. Elementos comprobables: la funcionalidad de la aplicación y todos sus módulos en un entorno
interno.
c. Criterios de aceptación del caso de prueba: una prueba se considera exitosa si la aplicación
funciona con todos sus módulos a través de una red de interna.
d. Tarea: Definir la ruta HTML de la aplicación. Compruebe la estabilidad de cada módulo y
pruebe la conexión desde la conexión de red interna.
e. Requisitos ambientales: las computadoras y los usuarios se conectarán a la ruta del programa.
Dos redes que conectan ordenadores, de distintas partes de la escuela.
f. Responsabilidades: Todas las pruebas son realizadas por el equipo de pruebas y los
programadores junto con los programadores de pruebas.
g. Riesgos y contingencias: malas rutas.
La aplicación no se conecta a la base de datos, el módulo no responde, la aplicación tarda mucho
tiempo y la parte principal de la aplicación está desequilibrada. Plan de prueba de contenido:

1. Procedimiento: revise el cuerpo de la aplicación con algunos usuarios finales y concéntrese en las
ideas y la terminología que se utilizará en cada módulo.
2. Ítems a revisar: aplicación, ver los términos utilizados en cada módulo, Criterios de aceptación de
casos de prueba: ¿Existe consenso entre los usuarios y expertos que utilizarán la aplicación sobre
la forma en que se llama a cada procedimiento del módulo?
3. Tareas a realizar: Revisar programa en red, asesorar a los usuarios sobre las reglas de cada proceso,
implementar nuevas reglas en el programa en red.
4. Necesidades ambientales: usuarios, cuentas de usuario, encuesta semestral, programadores y
reputación del módulo.
5. Responsabilidades: Todas las pruebas son realizadas por el equipo de pruebas y los programadores
en colaboración con los usuarios finales.
6. Riesgos y eventos: los usuarios no entienden los términos, los programadores no cumplen con los
nuevos términos, no aceptan los términos que se utilizarán.

Plan de prueba de usabilidad:


a. Importante: El usuario prueba el programa y cada módulo.
b. Elementos de prueba: todo el programa en una red interna.
c. Criterios de aceptación para casos de prueba: Los usuarios piensan que el programa
es bueno y están de acuerdo en que el programa es amigable y fácil de usar.
d. Tareas a realizar: Crear cuentas para cada usuario, el usuario prueba cada módulo,
recibe un informe y calificación de cada usuario.
e. Requisitos ambientales: cada usuario dispone de un ordenador con acceso a la red
interna, los informes se agregan por cuenta de usuario por usuario.
f. Responsabilidades: Programación e informática, usuario final.
g. Riesgos y sorpresas: los usuarios tienen malas críticas sobre la aplicación.
h. La ejecución de la aplicación falla independientemente de los mensajes del usuario.
i.
Definición de usuario para ejecutar la prueba:

Usuario final: El usuario final es una persona que vive diariamente con la aplicación desarrollada y
participa en las pruebas de contenido y usabilidad.
Desarrolladores: los "programadores" desarrolladores realizan pruebas de integración y caja blanca
porque son responsables de desarrollar el código y la aplicación.
REFERENCIAS BIBLIOGRÁFICAS
IACC (2020 Integración). Semana 6. Informática Pruebas y correcciones para el logro del funcionamiento
integrado. Semana 6 .

También podría gustarte