Ingeniería de Software | Pruebas de caja negra

Prerrequisito – Pruebas de software | Conceptos básicos Las pruebas de caja negra son un tipo de pruebas de software en las que se desconoce la funcionalidad del software. La prueba se realiza sin el conocimiento interno de los productos. 

Las pruebas de caja negra se pueden realizar de las siguientes maneras: 

1. Pruebas impulsadas por la sintaxis: este tipo de prueba se aplica a sistemas que pueden representarse sintácticamente mediante algún lenguaje. Por ejemplo, compiladores, lenguaje que puede ser representado por una gramática libre de contexto. En este, los casos de prueba se generan para que cada regla gramatical se utilice al menos una vez. 

2. Partición de equivalencia: a menudo se ve que muchos tipos de entradas funcionan de manera similar, por lo que en lugar de darlas todas por separado, podemos agruparlas y probar solo una entrada de cada grupo. La idea es dividir el dominio de entrada del sistema en varias clases de equivalencia de modo que cada miembro de la clase funcione de manera similar, es decir, si un caso de prueba en una clase da como resultado algún error, otros miembros de la clase también darán como resultado el mismo error. error. 

La técnica consta de dos pasos:

  1. Identificación de la clase de equivalencia: divida cualquier dominio de entrada en un mínimo de dos conjuntos: valores válidos y valores no válidos . Por ejemplo, si el rango válido es de 0 a 100, seleccione una entrada válida como 49 y una no válida como 104.
  2. Generación de casos de prueba: (i) A cada clase de entrada válida e inválida se le asigna un número de identificación único. (ii) Escriba un caso de prueba que cubra todos los casos de prueba válidos e inválidos considerando que no hay dos entradas inválidas que se enmascaren entre sí. Para calcular la raíz cuadrada de un número, las clases de equivalencia serán: (a) Entradas válidas:
    • El número entero, que es un cuadrado perfecto, la salida será un número entero.
    • El número entero que no es un cuadrado perfecto, la salida será un número decimal.
    • decimales positivos
    • Números negativos (entero o decimal).
    • Caracteres que no sean números como «a», «!», «;», etc.

3. Análisis del valor límite: los límites son muy buenos lugares para que se produzcan errores. Por lo tanto, si los casos de prueba se diseñan para los valores límite del dominio de entrada, la eficiencia de las pruebas mejora y la probabilidad de encontrar errores también aumenta. Por ejemplo: si el rango válido es de 10 a 100, pruebe también para 10,100 aparte de las entradas válidas y no válidas. 

4. Representación gráfica de causa y efecto: esta técnica establece una relación entre la entrada lógica denominada causa con las acciones correspondientes denominadas efecto. Las causas y efectos se representan mediante gráficos booleanos. Se siguen los siguientes pasos:

  1. Identificar entradas (causas) y salidas (efecto).
  2. Desarrollar un gráfico de causa-efecto.
  3. Transforme el gráfico en una tabla de decisiones.
  4. Convierta las reglas de la tabla de decisiones en casos de prueba.

Por ejemplo, en el siguiente gráfico de causa-efecto:

  

Se puede convertir en una tabla de decisiones como:

  

Cada columna corresponde a una regla que se convertirá en un caso de prueba para la prueba. Así que habrá 4 casos de prueba. 

5. Pruebas basadas en requisitos: incluye la validación de los requisitos establecidos en el SRS de un sistema de software. 

6. Pruebas de compatibilidad: el resultado del caso de prueba no solo depende del producto, sino también de la infraestructura para entregar la funcionalidad. Cuando se cambian los parámetros de la infraestructura, aún se espera que funcione correctamente. Algunos parámetros que generalmente afectan la compatibilidad del software son:

  1. Procesador (Pentium 3, Pentium 4) y varios procesadores.
  2. Arquitectura y características de la máquina (32 bits o 64 bits).
  3. Componentes de back-end como servidores de bases de datos.
  4. Sistema Operativo (Windows, Linux, etc).

Herramientas utilizadas para las pruebas de caja negra:

  1. apio
  2. Selenium
  3. Interfaz de usuario codificada de Microsoft
  4. Herramientas de aplicación
  5. HP QTP.

Ventajas de las pruebas de caja negra:

  • El tester no necesita tener más conocimientos funcionales o habilidades de programación para implementar Black Box Testing.
  • Es eficiente para implementar las pruebas en el sistema más grande.
  • Las pruebas se ejecutan desde el punto de vista del usuario o cliente.
  • Los casos de prueba son fácilmente reproducibles.
  • Se utiliza para encontrar la ambigüedad y las contradicciones en las especificaciones funcionales.

Desventajas de las pruebas de caja negra:

  • Existe la posibilidad de repetir las mismas pruebas mientras se implementa el proceso de prueba.
  • Sin especificaciones funcionales claras, los casos de prueba son difíciles de implementar.
  • Es difícil ejecutar los casos de prueba debido a las entradas complejas en las diferentes etapas de la prueba.
  • A veces, no se puede detectar el motivo de la falla de la prueba.
  • Algunos programas de la aplicación no se prueban.
  • No revela los errores en la estructura de control.
  • Trabajar con un gran espacio de muestra de entradas puede ser exhaustivo y consume mucho tiempo.

Publicación traducida automáticamente

Artículo escrito por aastha98 y traducido por Barcelona Geeks. The original can be accessed here. Licence: CCBY-SA

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *