Técnicas de prueba de software con ejemplos de diseño de casos de prueba

¿Qué es la técnica de prueba de software?

Las técnicas de prueba de software le ayudan a diseñar mejores casos de prueba. Dado que no es posible realizar pruebas exhaustivas, las técnicas de prueba manuales ayudan a reducir la cantidad de casos de prueba que se deben ejecutar y, al mismo tiempo, aumentan la cobertura de las pruebas. Ayudan a identificar condiciones de prueba que, de otro modo, serían difíciles de reconocer.

Análisis de valor límite (BVA)

El análisis del valor límite se basa en pruebas en los límites entre particiones. Incluye límites máximos, mínimos, interiores o exteriores, valores típicos y valores de error.

Generalmente se ve que una gran cantidad de errores ocurren en los límites de los valores de entrada definidos en lugar de en el centro. También se conoce como BVA y ofrece una selección de casos de prueba que ejercen valores límite.

Esta técnica de prueba de caja negra complementa la partición de equivalencia. Esta técnica de prueba de software se basa en el principio de que, si un sistema funciona bien para estos valores particulares, funcionará perfectamente bien para todos los valores que se encuentren entre los dos valores límite.

Directrices para el análisis del valor límite

• Si una condición de entrada está restringida entre los valores xey, entonces los casos de prueba deben diseñarse con valores xey, así como valores que estén por encima y por debajo de xey.
• Si una condición de entrada es una gran cantidad de valores, se debe desarrollar el caso de prueba que necesita ejercitar los números mínimo y máximo. Aquí también se prueban los valores por encima y por debajo de los valores mínimo y máximo.
• Aplique las pautas 1 y 2 a las condiciones de salida. Proporciona una salida que refleja los valores mínimo y máximo esperados. También prueba los valores inferiores o superiores.

Ejemplo:

Input condition is valid between 1 to 10

Boundary values 0,1,2 and 9,10,11

Partición de clases de equivalencia

La partición de clases equivalente le permite dividir un conjunto de condiciones de prueba en una partición que debe considerarse la misma. Este método de prueba de software divide el dominio de entrada de un programa en clases de datos a partir de las cuales se deben diseñar casos de prueba.

El concepto detrás de esta técnica de diseño de casos de prueba es que el caso de prueba de un valor representativo de cada clase es igual a una prueba de cualquier otro valor de la misma clase. Le permite identificar clases de equivalencia válidas e inválidas.

Ejemplo:

Las condiciones de entrada son válidas entre

 1 to 10 and 20 to 30

Por tanto, hay cinco clases de equivalencia.

--- to 0 (invalid)
1 to 10 (valid)
11 to 19 (invalid)
20 to 30 (valid)
31 to --- (invalid)

Selecciona valores de cada clase, es decir,

-2, 3, 15, 25, 45

Lea también más sobre – Análisis de valor límite y pruebas de partición de equivalencia

Pruebas basadas en tablas de decisión

Una tabla de decisiones también se conoce como tabla de Causa-Efecto. Esta técnica de prueba de software se utiliza para funciones que responden a una combinación de entradas o eventos. Por ejemplo, se debe habilitar un botón de envío si el usuario ha ingresado todos los campos obligatorios.

La primera tarea es identificar funcionalidades donde el resultado depende de una combinación de insumos. Si hay un gran conjunto de combinaciones de entrada, divídalo en subconjuntos más pequeños que sean útiles para gestionar una tabla de decisiones.

Para cada función, debe crear una tabla y enumerar todos los tipos de combinaciones de entradas y sus respectivas salidas. Esto ayuda a identificar una condición que el evaluador pasa por alto.

A continuación se muestran los pasos para crear una tabla de decisiones:

• Registre las entradas en filas
• Introduzca todas las reglas en la columna.
• Llene la tabla con las diferentes combinaciones de entradas
• En la última fila, anote el resultado frente a la combinación de entrada.

Ejemplo: Un botón de envío en un formulario de contacto se habilita solo cuando el usuario final ingresa todas las entradas.

Transición de estado

En la técnica de transición de estado, los cambios en las condiciones de entrada cambian el estado de la aplicación bajo prueba (AUT). Esta técnica de prueba permite al evaluador probar el comportamiento de un AUT. El probador puede realizar esta acción ingresando varias condiciones de entrada en una secuencia. En la técnica de transición de estado, el equipo de pruebas proporciona valores de prueba de entrada positivos y negativos para evaluar el comportamiento del sistema.

Lineamiento para la Transición de Estado:

• La transición de estado debe usarse cuando un equipo de pruebas está probando la aplicación para un conjunto limitado de valores de entrada.
• La técnica de diseño de casos de prueba debe usarse cuando el equipo de pruebas desea probar la secuencia de eventos que suceden en la aplicación bajo prueba.

Ejemplo:

En el siguiente ejemplo, si el usuario ingresa una contraseña válida en cualquiera de los tres primeros intentos, podrá iniciar sesión correctamente. Si el usuario ingresa una contraseña no válida en el primer o segundo intento, se le solicitará que vuelva a ingresar la contraseña. Cuando el usuario ingresa una contraseña incorrecta 3^rd tiempo, se ha realizado la acción y la cuenta será bloqueada.

Diagrama de transición de estado

En este diagrama, cuando el usuario proporciona el número PIN correcto, pasa al estado de acceso concedido. La siguiente tabla se crea en función del diagrama anterior:

Tabla de transición de estado

	PIN correcto	PIN incorrecto
S1) Inicio	S5	S2
S2) 1st intento	S5	S3
S3) 2nd intento	S5	S4
S4) 3rd intento	S5	S6
S5) Acceso concedido	–	–
S6) Cuenta bloqueada	–	–

En la tabla anterior, cuando el usuario ingresa el PIN correcto, el estado pasa a Acceso concedido. Y si el usuario ingresa una contraseña incorrecta, pasa al siguiente estado. Si el hace lo mismo 3^rd En ese momento, alcanzará el estado de cuenta bloqueada.

Error al adivinar

Error al adivinar Es una técnica de prueba de software basada en adivinar el error que puede prevalecer en el código. La técnica se basa en gran medida en la experiencia en la que los analistas de pruebas utilizan su experiencia para adivinar la parte problemática de la aplicación de prueba. Por lo tanto, los analistas de pruebas deben tener habilidades y experiencia para adivinar mejor los errores.

La técnica cuenta una lista de posibles errores o situaciones propensas a errores. Luego el evaluador escribe un caso de prueba para exponer esos errores. Para diseñar casos de prueba basados ​​en esta técnica de prueba de software, el analista puede utilizar experiencias pasadas para identificar las condiciones.

Pautas para adivinar errores:

• La prueba debe utilizar la experiencia previa de probar aplicaciones similares.
• Comprensión del sistema bajo prueba.
• Conocimiento de errores típicos de implementación.
• Recuerde áreas previamente conflictivas
• Evaluar datos históricos y resultados de pruebas

Conclusión

• La técnica de diseño de casos de prueba le permite diseñar mejores casos. Hay cinco técnicas utilizadas principalmente.
• El análisis de valores límite consiste en probar los límites entre particiones.
• La partición de clases equivalente le permite dividir un conjunto de condiciones de prueba en una partición que debe considerarse la misma.
• La técnica de prueba del software Decision Table se utiliza para funciones que responden a una combinación de entradas o eventos.
• En la técnica de transición de estado, los cambios en las condiciones de entrada cambian el estado de la aplicación bajo prueba (AUT)
• La adivinación de errores es una técnica de prueba de software que se basa en adivinar el error que puede prevalecer en el código.