Get your 6-month No-Cost Opt-Out offer for Unlimited Software Automation?

El análisis del valor límite (abreviado BVA) es una técnica habitual de pruebas de caja negra. El enfoque comprueba los defectos del software verificando los valores de entrada en los límites de los rangos permitidos.

En este artículo se explica qué son las pruebas de análisis de límites, por qué son útiles y se exploran algunos enfoques, técnicas y herramientas de pruebas de límites.

 

Tabla de contenidos

¿Qué es el análisis del valor límite en las pruebas de software?

Pruebas Estáticas en Pruebas de Software - ¡Qué es, Tipos, Proceso, Enfoques, Herramientas, y Más!

El análisis del valor límite es un tipo de prueba funcional. Este tipo de pruebas se ocupa de verificar que cada función del software cumple los requisitos y especificaciones. En el caso de las pruebas de contorno, esta funcionalidad incluye el modo en que el software trata las distintas entradas.

BVA es una técnica de prueba de software que valida cómo responderá el software a las entradas en o alrededor del borde de los límites de entrada. En esencia, cada entrada tiene rangos permitidos. Por ejemplo, puede tener una casilla de contraseña para un inicio de sesión que acepte contraseñas de entre 8 y 12 caracteres. La prueba de límites comprobará contraseñas con longitudes de caracteres de 7, 8, 12 y 13.

La idea es que los límites de los límites, es decir, 7, 8, 12 y 13, son más propensos a dar errores que los números dentro de los límites, como 9, 10 y 11. Aunque las ventajas pueden parecer marginales en el ejemplo de una casilla de campo que acepta entre 8 y 12 caracteres, se hacen más evidentes cuando hay que escribir casos de prueba para casillas de campo que aceptan entre 1 y 20 caracteres o números entre 1 y 1000, etc.

Así, para ahorrar tiempo y reducir el número de casos de prueba dentro de las pruebas funcionales, el análisis del valor límite se fija en los valores:

  • En el valor mínimo
  • Directamente por debajo del valor mínimo
  • Al valor máximo
  • Directamente por encima del valor máximo

 

Ventajas del análisis del valor límite en las pruebas

Pruebas de control de calidad: qué son, tipos, procesos, enfoques, herramientas y mucho más.

Las pruebas de límites ofrecen varias ventajas convincentes a los equipos de control de calidad.

#1. Mejor calidad del software

La pesadilla de los probadores son los errores y defectos que pasan desapercibidos. Con tantas cosas que verificar, algunos defectos pueden pasar desapercibidos. Las pruebas de contorno demuestran la funcionalidad de las áreas del software que tienen más probabilidades de contener errores, lo que conduce a una mejor construcción del software y, en última instancia, a una aplicación más fiable y estable.

#2. Mayor cobertura de las pruebas

El BVA es muy útil en las pruebas de software porque ayuda a reducir el número de casos de prueba necesarios para una cobertura completa de las pruebas. El análisis de valores límite garantiza que los valores importantes y que cada valor pueda probarse más a fondo.

#3. Detección precoz de defectos

Las pruebas de valor límite forman parte de un enfoque que da prioridad a la detección temprana de defectos. Detectar los errores en una fase temprana del proceso permite a los equipos de desarrollo ahorrar tiempo y dinero, sin mencionar el hecho de que es mucho más fácil poner remedio a los errores en las primeras fases del desarrollo.

#4. Eficiencia

Las pruebas de valores límite son muy eficaces porque reducen la necesidad de muchos casos de prueba. De hecho, la reducción de las entradas a todas menos las que tienen más probabilidades de causar problemas puede ahorrar mucho tiempo a los equipos de pruebas, tanto en la redacción como en la ejecución de los casos de prueba.

 

Inconvenientes del análisis del valor límite en las pruebas

Diferentes metodologías de software y control de calidad

Por supuesto, ninguna técnica de prueba de software es perfecta ni está exenta de limitaciones. Aunque el análisis del valor límite tiene muchas ventajas, trabajar con esta técnica de comprobación funcional tiene algunas limitaciones.

#1. Alcance limitado

BVA trabaja en los límites o bordes de las entradas de datos válidas. En general, ignora las entradas intermedias razonando que estarán bien si las entradas válidas de los bordes lo están. Sin embargo, no hay que descartar que algunos de estos valores que no se han comprobado puedan plantear problemas.

#2. Demasiado simplista

El análisis de límites consiste en simplificar las cosas. Aunque esto funciona para reducir los casos de prueba, el enfoque es menos adecuado para dominios muy complejos con múltiples límites, interacciones o dependencias. De hecho, puede tener dificultades para gestionar situaciones complejas, lo que significa que es necesario explorar otras técnicas para obtener una cobertura adecuada.

#3. Supuestos

Cualquier proceso que intente aumentar la eficacia corre el riesgo de pasar por alto errores concretos. El BVA se centra en los límites de una zona de distribución. Para ello, debe hacer suposiciones sobre otros insumos que se encuentran a ambos lados de los valores límite. Los responsables de las pruebas deben encontrar un equilibrio entre eficacia y cobertura, lo que supone un ligero riesgo si sólo se utilizan las pruebas de límites.

#4. Basarse en especificaciones y requisitos precisos

La eficacia del BVA depende de la calidad y exactitud de las especificaciones y la documentación de requisitos. Cualquier error no comprobado en estos documentos puede repercutir en las pruebas de valores límite y provocar errores específicos que no se comprueban ni descubren hasta las últimas fases críticas del desarrollo.

#5. Dependencia de las clases de equivalencia

Para realizar un BVA exhaustivo es necesario tener un buen conocimiento de las clases de equivalencia. Establecer estas clases con precisión requiere experiencia y cierta información sobre la aplicación.

 

Retos del análisis del valor límite

en pruebas de software

retos-pruebas-de-carga

A estas alturas, ya debería tener bastante claros los pros y los contras de las pruebas de límites. Sin embargo, si desea aplicar este enfoque en sus propias pruebas de software, también debe ser consciente de los diversos retos que debe superar.

Estos son algunos de los retos que plantea la aplicación de pruebas de valor límite en las pruebas de software.

 

#1. Delimitación de fronteras

La identificación de límites en sistemas sencillos plantea pocos retos a los probadores competentes. Sin embargo, hay situaciones más complejas, como:

  • Dominios de entrada complejos con diversas variables de entrada o relaciones intrincadas.
  • Límites no documentados que no se han esbozado claramente en los documentos de especificación.
  • Límites dinámicos que cambian en función de las acciones del usuario u otras condiciones.

 

#2. Requisitos ambiguos

Los documentos de requisitos mal redactados o poco claros pueden dificultar la identificación de los valores límite. La claridad, la exhaustividad y el compromiso de elaborar documentos de especificaciones exhaustivos llevan tiempo, pero al final dan sus frutos.

 

#3. Experiencia

El análisis del valor límite puede resultar engañosamente complejo. De hecho, los equipos de pruebas necesitan personal con experiencia y conocimientos en la materia para comprender los sutiles matices de la técnica. Además, los encargados de las pruebas deben tener algún conocimiento del software o, como mínimo, disponer de documentos de especificaciones fiables a los que recurrir.

 

IS YOUR COMPANY IN NEED OF

ENTERPRISE LEVEL

TASK-AGNOSTIC SOFTWARE AUTOMATION?

#4. Errores

El análisis de límites pretende reducir el número de casos de prueba necesarios para verificar entradas válidas e inválidas. Sin embargo, los defectos que quedan fuera del intervalo de prueba pueden pasar fácilmente desapercibidos. Además, los errores “de uno en uno” son errores de codificación comunes que pueden producirse en los límites o cerca de ellos. Los responsables de las pruebas deben ser conscientes de estos escenarios y tomar las medidas oportunas.

 

#5. Explosión del caso de prueba

Con múltiples límites de entrada en juego, los casos de prueba pronto pueden volverse complejos y multiplicarse sin control. En estas situaciones, el tiempo y el dinero que se pueden ahorrar con las pruebas de contorno se pierden, lo que socava las ventajas de la solución. Las construcciones complejas de software con muchas combinaciones o permutaciones pueden tener un efecto similar.

 

#6. Limitaciones de la herramienta de análisis

Las herramientas de automatización de pruebas de software pueden ayudar a los equipos a realizar un análisis adecuado del valor límite. Sin embargo, incluso en el mejor de los casos, estas herramientas requieren cierta intervención manual tanto para las pruebas como para su creación. Esta situación puede agravarse en el caso de construcciones complejas con interacciones multivariables.

 

Diferentes tipos de valor límite

pruebas de software

lista de comprobación de los procesos de prueba de software

En el libro Software Testing: A Craftsman’s Approach, los autores Paul C. Jorgensen y Byron DeVries describen cuatro tipos diferentes de pruebas de valor límite, que son:

 

1. Prueba del valor límite normal (NBVT)

  • Comprueba los valores de entrada válidos en los bordes del dominio de entrada
  • Explora los valores mínimos y máximos junto con las entradas situadas justo por encima y por debajo del límite.
  • Este es el tipo clásico de análisis del valor límite

 

2. Prueba robusta del valor límite (RBVT)

  • Similar al NBVT anterior, pero incluye también las entradas no válidas
  • Pruebas en los límites y un poco más allá, pero también tiene en cuenta las entradas no válidas.
  • Se centra en la búsqueda de errores a partir de resultados extremos o inesperados

 

3. Prueba del valor límite en el peor de los casos (WBVT)

  • Verifica el comportamiento del software utilizando valores extremos válidos e inválidos
  • Explora los valores en el borde de los dominios de entrada y los valores más allá de estos límites.
  • Busca comprender el comportamiento del software en condiciones más extremas

 

4. Prueba robusta del valor límite en el peor de los casos (RWBVT)

  • Utiliza una combinación de RBVT y WBVT para realizar las pruebas de valores límite más exhaustivas.
  • Prueba valores de entrada válidos y no válidos en límites típicos y extremos.
  • Ofrece la mejor oportunidad de encontrar defectos relacionados con los límites

 

Estos enfoques difieren en cuanto a su exhaustividad, siendo el RWBVT el más completo. Sin embargo, los responsables de las pruebas deben ser conscientes de la inversión adicional de tiempo y esfuerzo necesaria para desbloquear este nivel adicional de descubrimiento de defectos.

 

Partición de equivalencia y valor límite

análisis: similitudes y diferencias

aclarar algunas confusiones en la automatización de pruebas de software

La partición de equivalencia y el análisis del valor límite suelen utilizarse conjuntamente. De hecho, ambas técnicas son muy complementarias. Sin embargo, describen enfoques distintos para validar la introducción de datos. He aquí las similitudes y diferencias entre ambos.

 

1. Similitudes

La partición de equivalencia y el análisis del valor límite forman una gran pareja. He aquí algunas de las similitudes entre ambas técnicas.

  • Ambas son técnicas de prueba de caja negra, es decir, se centran en las entradas y salidas, que pueden probarse sin conocer a priori el código fuente de la aplicación.
  • Ambas forman parte de un enfoque exhaustivo de los insumos para las pruebas
  • Ambos ayudan a los evaluadores a encontrar un equilibrio entre una cobertura de pruebas exhaustiva sin escribir una cantidad excesiva de casos de prueba.

 

2. Diferencias

Para explorar las diferencias entre la partición de equivalencia y el análisis del valor límite, debemos examinar cada uno por separado.

Partición por equivalencia

  • Divide los datos de entrada en clases de equivalencia que deberían dar lugar a resultados similares en el sistema.
  • Utiliza un único valor representativo de cada clase y prueba el sistema con ese valor.
  • Se trata de identificar las clases de equivalencia válidas e inválidas

 

Análisis del valor límite

  • Comprueba los valores en los límites o bordes de las clases de equivalencia
  • Pruebe una serie de valores, incluidos el mínimo, el máximo y los valores a ambos lados del límite.
  • Busca errores que se encuentran en el borde de los límites

 

Ejemplos de partición de equivalencia y análisis del valor límite

Para ayudarle a comprender mejor la partición de equivalencias y el análisis del valor límite, aquí tiene algunos ejemplos.

Ejemplo de partición de equivalencia:

Supongamos que tiene un cuadro de entrada para la matriculación de vehículos. Normalmente, las matrículas de los coches estadounidenses tienen entre 6 y 7 caracteres. Para simplificar, descartaremos las matrículas especiales.

Datos válidos = Placas de 6 ó 7 caracteres

Datos no válidos = Placas con >6 o >7 caracteres.

 

Ejemplo de análisis del valor límite:

Utilizando el mismo ejemplo de matrícula que el anterior, el análisis de límites probará

Datos válidos = Placas con 6 ó 7 caracteres

Datos no válidos = Placas con 5 u 8 caracteres y, en algunos casos, con 4 y 9 caracteres.

 

Ejemplo de análisis del valor límite

ventajas de las pruebas alfa y de la rpa

Tal vez la mejor manera de comprender plenamente el concepto sea examinar uno o dos ejemplos de análisis del valor límite.

 

Ejemplo de prueba del valor límite nº 1

Para explorar las pruebas de valores límite con más detalle, veamos un ejemplo de un dominio de verificación de edad.

Tenemos una casilla donde el usuario puede introducir su edad.

Los valores límite son:

IS YOUR COMPANY IN NEED OF

ENTERPRISE LEVEL

TASK-AGNOSTIC SOFTWARE AUTOMATION?

  • Edad mínima = 18 años
  • Edad máxima = 120 años

 

Ejemplo de casos de prueba límite:

Hay un total de seis casos de prueba:

  • 17, 18 y 19, que están por debajo del mínimo, el mínimo y por encima del mínimo, respectivamente
  • 119, 18 y 19, que están por debajo del máximo, el máximo y por encima del máximo, respectivamente.

 

Ejemplo de prueba del valor límite nº 2.

En nuestro siguiente ejemplo de prueba de límites, exploraremos un sitio web con un descuento por compra de valor mínimo del 20% en pedidos de 100 dólares o más.

En este ejemplo, una compra superior a 600 € conlleva un descuento del 25%. La prueba del valor límite se aplicará a las entradas comprendidas entre 100 y 600 dólares.

Los valores límite son:

Descuento mínimo = 100

Descuento máximo = 600

 

Ejemplo de casos de prueba límite:

De nuevo, generamos un total de seis casos de prueba, que son:

  • 99,99 $, 100 $ y 100,01 $, que están por debajo del mínimo, el mínimo y por encima del mínimo, respectivamente.
  • 599,99 $, 600 $ y 600,01 $, que están por debajo del máximo, del máximo y por encima del máximo, respectivamente.

 

¿Son precisas las pruebas de límites en las pruebas de software?

pruebas alfa frente a pruebas beta

En el artículo de investigación Black Box Testing with Equivalence Partitioning and Boundary Value Analysis Methods, los autores exploran el uso de la partición de equivalencias y el análisis de valores límite para probar un sistema de información académica para la Universidad de Mataram, en Indonesia.

Los autores utilizaron la popular herramienta de pruebas de código abierto Selenium para sus pruebas y ejecutaron un total de 322 casos de prueba. Las pruebas de equivalencia y el análisis del valor límite desvelaron unos 80 casos fallidos, lo que dio lugar a una proporción aproximada de 75:25 entre resultados válidos y no válidos. En general, el uso de una combinación de partición de equivalencias y BVA en las pruebas de software permitió realizar pruebas exhaustivas y útiles para el software.

 

Mejores herramientas de comprobación de valores límite

ZAPTEST RPA + Paquete de automatización de pruebas

Aunque son escasas las herramientas de software dedicadas a las pruebas de límites, hay muchas herramientas de pruebas notables que son capaces de realizar esta tarea.

#3. TestCaseLab

TestCaseLab es una herramienta de gestión de pruebas basada en la nube que puede ayudar con las pruebas BVA. El software permite a los equipos crear y gestionar casos de prueba desde su intuitiva y atractiva interfaz de usuario. TestCaseLab es flexible y está repleto de funciones, pero tiene sus limitaciones, como la limitación de los informes y las opciones de personalización.

 

#2. Micro Focus UFT One

Micro Focus UFT One es una herramienta de pruebas de software centrada en pruebas funcionales y de regresión. Es compatible con diferentes plataformas, dispositivos y pruebas de API y ofrece sólidas opciones de integración. Ofrece creación de pruebas sin código y basadas en palabras clave, y puede ayudar a los equipos a crear casos de prueba de análisis de valor límite con facilidad. Hay que tener en cuenta algunas limitaciones, como una curva de aprendizaje pronunciada y una falta de potencia en comparación con herramientas como ZAPTEST.

 

#1. ZAPTEST

Automatización ágil de pruebas DevOps: Explicación del enfoque de automatización basado en maquetas de ZAPTEST

ZAPTEST es una completa herramienta de pruebas de automatización de software con funciones avanzadas de RPA. Se ha creado para proporcionar a los probadores un conjunto sólido y fácil de usar de herramientas de automatización de pruebas que pueden ayudar a verificar el software de diversas maneras, incluso con BVA en las pruebas de software.

Algunos de los casos de uso más convincentes de ZAPTEST para ayudar al análisis de valores límite incluyen la generación de casos de prueba, la gestión de datos de prueba, la ejecución de pruebas y la elaboración de informes y análisis. Con una gama de plantillas y un alto nivel de personalización combinados con la creación de casos de prueba sin código, los usuarios de ZAPTEST pueden crear y gestionar de forma rápida y sencilla casos de prueba robustos para todo tipo de análisis de límites.

Además de la generación y gestión de casos de prueba, las capacidades RPA de ZAPTEST pueden ayudar a los equipos de pruebas con sus pruebas de análisis de valor límite de otras maneras. Por ejemplo, puede automatizar la ejecución de casos de prueba, generar datos de prueba y crear potentes integraciones con otras herramientas de prueba.

 

Consejos para las pruebas de valores límite

  • Combine el análisis de valores límite con la partición de equivalencias para garantizar que sus casos de prueba cubren varios escenarios de entrada.
  • Utilice escenarios de entrada no válida (es decir, pruebas negativas) para asegurarse de que verifica cómo gestiona el software los errores y las entradas inesperadas.
  • Invierta tiempo en identificar los valores límite de los distintos tipos de datos, como texto, números, booleanos, etc.
  • Dar prioridad a las pruebas de valor límite para las funcionalidades críticas o las áreas en las que es más probable que se produzcan errores.
  • Utiliza datos realistas que representen el tipo de datos que tus usuarios introducirán en tus dominios.

 

Reflexiones finales

El análisis del valor límite es un enfoque útil para las pruebas funcionales. Cuando se tiene un dominio de entrada, es necesario comprobar que acepta datos válidos y envía mensajes de error cuando recibe datos no válidos. Las pruebas de análisis de límites ayudan a verificar esa funcionalidad de forma eficiente, construyendo sólo los casos de prueba necesarios para realizar pruebas exhaustivas.

La prueba de límites examina valores dentro o alrededor del rango aceptable y verifica cómo responde el sistema a estas entradas. El resultado es que se ahorra mucho tiempo y se reduce el esfuerzo, ya que no es necesario crear casos de prueba redundantes. En el vertiginoso mundo del desarrollo de software, en el que los plazos de entrega son cada vez más estrictos, los equipos de pruebas necesitan toda la ayuda posible.

Download post as PDF

Alex Zap Chernyak

Alex Zap Chernyak

Founder and CEO of ZAPTEST, with 20 years of experience in Software Automation for Testing + RPA processes, and application development. Read Alex Zap Chernyak's full executive profile on Forbes.

Get PDF-file of this post