ClubEnsayos.com - Ensayos de Calidad, Tareas y Monografias
Buscar

Evaluación y mejora para el desarrollo de software


Enviado por   •  22 de Junio de 2023  •  Tareas  •  1.848 Palabras (8 Páginas)  •  93 Visitas

Página 1 de 8

[pic 1]

TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN

EVALUACIÓN Y MEJORA PARA EL DESARROLLO DE SOFTWARE

Pruebas de Caja Blanca

Jesús Daniel Cruz Sánchez TIC4A

Hugo Bryan Castañeda Uribe

Josué Cardona Velázquez

Mauricio Alejandro Gutiérrez Luna

Santa Catarina N.L.

Pruebas de Caja Blanca

Pruebas de caja blanca (White-Box Testing). Son pruebas estructurales. Conociendo el código y siguiendo su estructura lógica, se pueden diseñar pruebas destinadas a comprobar que el código hace correctamente lo que el diseño de bajo nivel indica y otras que demuestren que no se comporta adecuadamente ante determinadas situaciones. Ejemplos típicos de ello son las pruebas unitarias. Se centran en lo que hay codificado o diseñado a bajo nivel por lo que no es necesario conocer la especificación de requisitos, que por otra parte será difícil de relacionar con partes diseñadas a muy bajo nivel.

En este tipo de pruebas, el probador puede ver el código. Se centra principalmente en verificar el flujo de entradas y salidas a través de la aplicación, mejorando el diseño y la usabilidad, fortaleciendo la seguridad. La prueba de caja blanca también se conoce como prueba de caja clara, prueba de caja abierta, prueba estructural, prueba de caja transparente, prueba basada en código y prueba de caja de vidrio. Generalmente lo realizan los desarrolladores.

El cuadro transparente o el nombre de WhiteBox simboliza la capacidad de ver a través de la capa externa del software (o "cuadro") en su funcionamiento interno.

[pic 2]

Ejemplos

Pruebas unitarias

  • Evaluar si el funcionamiento de cada uno de los métodos de una clase se comporta como se espera.
  • Cuando una parte del código ha sido modificado y se desea ver que el nuevo código cumple con los requerimientos anteriores y que no se ha alterado  su funcionalidad despues despues de la nueva modificacion.
  • Si existen variables o librerías inutilizables.

Técnicas usadas en caja blanca 

  • La cobertura de caminos (pruebas que hagan que se recorran todos los posibles caminos de ejecución
  • Pruebas sobre las expresiones lógico-aritméticas
  • Pruebas de camino de datos (definición-uso de variables)
  • Comprobación de bucles (se verifican los bucles para 0, 1 y n interacciones, y luego para las interacciones máximas, máximas menos uno y más uno.
  • Las pruebas de caja blanca se llevan a cabo en primer lugar sobre un módulo concreto, para luego realizar las de caja negra sobre varios subsistentes (integración)
  • 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 una programación estructurada)
  • Puede utilizar recursos como el Debugging
  • En las pruebas de caja blanca, puede proveer la solución a cualquier desperfecto que se encuentre en el código a la hora de probar, o reportar a los desarrolladores la solución al desperfecto y no solo la existencia del mismo

Pruebas de Software con enfoque de Caja Blanca

Pruebas Funcionales

  1. Prueba unitaria

Se probó cada uno de los botones para verificar que su funcionalidad correspondiera a cada uno de ellos con la finalidad de corregir errores en caso de encontrarlos.

Para esto se verificó tanto el código como el diseño, todo de manera individual y no se encontró ningún tipo de error en la pantalla.

[pic 3][pic 4]

  1. Integración

En esta prueba se realizó exactamente lo mismo a la anterior con la única diferencia es que en esta ocasión se realizó la prueba a dos hasta 4 botones ejecutándose al mismo tiempo.

Esto para que el cliente no tenga inconveniente en realizar varias tareas a la vez.Al igual que en la prueba anterior en esta no se registró ningún tipo de error.

[pic 5]

  1.  Regresión

Se agrega una pantalla nueva con botones nuevos y se verifica el código ya existente para comprobar que este no haya sufrido cambios al momento de agregar las nuevas pantallas. El código sufrió ciertos cambios por los cuales tuvimos que reorganizarlo.

[pic 6]

  1. Pruebas de funcionalidad

En esta etapa como su nombre lo dice utilizamos el sistema como se debería usar por parte de un usuario, realizamos todas las tareas que este sistema debería hacer normalmente con el código organizado, las pantallas y botones terminados. Pasamos el sistema a un dispositivo Android para verificar que este actuara de manera correcta ante cualquier tipo de tarea solicitada. Después de esto se realizó la misma operación, pero ya con el sistema en una PC.

Para Android se tuvo complicaciones ya que el sistema no es compatible con móviles, en cambio al realizar las mismas tareas en la PC no tuvimos ningún tipo de problemas ya que está creado específicamente para escritorio.

[pic 7][pic 8][pic 9][pic 10]

  1. Pruebas de estrés

Esta etapa consiste básicamente en sobrecargar el sistema de información para verificar que sucede con el mismo, en este caso lo que hicimos fue agregar una cantidad elevada de usuarios para ver si la base de datos era capaz de resistir esta información, al realizar esto nos percatamos de que nuestra base de datos no era lo suficiente como para albergar a más de 4 usuarios registrados en el sistema por lo que pusimos como máximo este número de usuarios al mismo tiempo.

Pruebas de seguridad

  1. PENTEST INTERNO:

La etapa PENTEST Interna se llevó a cabo realizando una simulación de hackeo por nuestra parte ya que nosotros somos los que en teoria podriamos saber los puntos débiles de la misma, para esto uno de nuestros miembros de equipo se encarga de realizarlo o si es necesario más de una persona, como única regla se pide que todas la personas involucradas sean parte del grupo que realizó el software.

  1. PENTEST EXTERNO:

En esta etapa el software fue puesto a prueba emulando un hackeo por personas externas a la red interna del software, esto para que nosotros podamos ver los puntos vulnerables de la misma y así poder poner algo que dificulte al intruso a realizar su cometido con éxito.

...

Descargar como (para miembros actualizados)  txt (11.6 Kb)   pdf (1.4 Mb)   docx (1.4 Mb)  
Leer 7 páginas más »
Disponible sólo en Clubensayos.com