Ingeniería de Software | Pruebas de caja blanca

Prerrequisito – Pruebas de software | Lo esencial

Las técnicas de prueba de caja blanca analizan las estructuras internas, las estructuras de datos utilizadas, el diseño interno, la estructura del código y el funcionamiento del software en lugar de solo la funcionalidad como en las pruebas de caja negra. También se denomina prueba de caja de vidrio o prueba de caja transparente o prueba estructural.

Proceso de trabajo de las pruebas de caja blanca:

• Entrada: requisitos, especificaciones funcionales, documentos de diseño, código fuente.
• Tramitación: Realización de análisis de riesgos para orientar a lo largo de todo el proceso.
• Planificación adecuada de las pruebas: diseñar casos de prueba para cubrir todo el código. Ejecute enjuague-repetir hasta que se alcance el software sin errores. Además, se comunican los resultados.
• Salida: Elaboración de informe final de todo el proceso de ensayo.

Técnicas de prueba:

• Cobertura de declaraciones: en esta técnica, el objetivo es atravesar todas las declaraciones al menos una vez. Por lo tanto, se prueba cada línea de código. En el caso de un diagrama de flujo, cada Node debe atravesarse al menos una vez. Dado que todas las líneas de código están cubiertas, ayuda a señalar el código defectuoso.
  

  Ejemplo de cobertura de estados de cuenta

• Cobertura de rama: En esta técnica, los casos de prueba están diseñados para que cada rama de todos los puntos de decisión se atraviese al menos una vez. En un diagrama de flujo, todos los bordes deben recorrerse al menos una vez.
  

  Se requieren 4 casos de prueba de modo que se cubran todas las ramas de todas las decisiones, es decir, se cubran todos los bordes del diagrama de flujo

• Cobertura de condiciones: en esta técnica, todas las condiciones individuales deben cubrirse como se muestra en el siguiente ejemplo:
  1. LEER X, Y
  2. SI(X == 0 || Y == 0)
  3. IMPRIMIR ‘0’

  En este ejemplo, hay 2 condiciones: X == 0 e Y == 0. Ahora, prueba que estas condiciones obtengan VERDADERO y FALSO como sus valores. Un posible ejemplo sería:

  • #TC1 – X = 0, Y = 55
  • #TC2 – X = 5, Y = 0
• Cobertura de condiciones múltiples: en esta técnica, todas las combinaciones posibles de los posibles resultados de las condiciones se prueban al menos una vez. Consideremos el siguiente ejemplo:
  1. LEER X, Y
  2. SI(X == 0 || Y == 0)
  3. IMPRIMIR ‘0’
  • #TC1: X = 0, Y = 0
  • #TC2: X = 0, Y = 5
  • #TC3: X = 55, Y = 0
  • #TC4: X = 55, Y = 5

  Por lo tanto, se requieren cuatro casos de prueba para dos condiciones individuales.
  De manera similar, si hay n condiciones , se requerirían 2 ^{n casos de prueba.}

• Prueba de ruta básica: en esta técnica, los gráficos de flujo de control se crean a partir de código o diagrama de flujo y luego se calcula la complejidad ciclomática que define la cantidad de rutas independientes para que se pueda diseñar la cantidad mínima de casos de prueba para cada ruta independiente.
  Pasos:
  1. Hacer el gráfico de flujo de control correspondiente
  2. Calcular la complejidad ciclomática
  3. Encuentra los caminos independientes
  4. Diseñar casos de prueba correspondientes a cada camino independiente

  Notación de gráfico de flujo: es un gráfico dirigido que consta de Nodes y aristas. Cada Node representa una secuencia de sentencias o un punto de decisión. Un Node de predicado es el que representa un punto de decisión que contiene una condición después de la cual se divide el gráfico. Las regiones están delimitadas por Nodes y aristas.
  

  Complejidad Ciclomática: Es una medida de la complejidad lógica del software y se utiliza para definir el número de caminos independientes. Para un grafo G, V(G) es su complejidad ciclomática.
  Cálculo de V(G):

  1. V(G) = P + 1, donde P es el número de Nodes predicados en el diagrama de flujo
  2. V(G) = E – N + 2, donde E es el número de aristas y N es el número total de Nodes
  3. V(G) = Número de regiones que no se superponen en el gráfico

  Ejemplo:
  
  V(G) = 4 (Usando cualquiera de las fórmulas anteriores)
  Nº de caminos independientes = 4

  • #P1: 1 – 2 – 4 – 7 – 8
  • #P2: 1 – 2 – 3 – 5 – 7 – 8
  • #P3: 1 – 2 – 3 – 6 – 7 – 8
  • #P4: 1 – 2 – 4 – 7 – 1 – . . . – 7 – 8
• Pruebas de bucle: los bucles se utilizan ampliamente y son fundamentales para muchos algoritmos, por lo que su prueba es muy importante. A menudo se producen errores al principio y al final de los bucles.
  1. Bucles simples: para bucles simples de tamaño n, se diseñan casos de prueba que:
     • Sáltate el bucle por completo
     • Solo un paso a través del bucle.
     • 2 pases
     • m pasa, donde m < n
     • n-1 y n+1 pasa
  2. Bucles anidados: para los bucles anidados, todos los bucles se establecen en su recuento mínimo y comenzamos desde el bucle más interno. Las pruebas de bucle simples se realizan para el bucle más interno y esto se trabaja hacia afuera hasta que se hayan probado todos los bucles.
  3. Bucles concatenados: Bucles independientes, uno tras otro. Se aplican pruebas de bucle simple para cada uno.
     Si no son independientes, trátelos como anidando.

ventajas:

1. Las pruebas de caja blanca son muy exhaustivas ya que se prueban todo el código y las estructuras.
2. Da como resultado la optimización del error de eliminación de código y ayuda a eliminar líneas adicionales de código.
3. Puede comenzar en una etapa anterior, ya que no requiere ninguna interfaz como en el caso de las pruebas de caja negra.
4. Fácil de automatizar.

Desventajas:

1. La principal desventaja es que es muy caro.
2. El rediseño del código y la reescritura del código necesitan que los casos de prueba se escriban nuevamente.
3. Se requiere que los evaluadores tengan un conocimiento profundo del código y el lenguaje de programación en lugar de las pruebas de caja negra.
4. Las funcionalidades que faltan no se pueden detectar ya que se prueba el código existente.
5. Muy complejo ya veces poco realista.