state transition testing technique
Aprenda qué es la prueba de transición estatal y cómo utilizar el diagrama de transición estatal:
En nuestro último artículo, vimos el ' Gráfico de causa y efecto 'Técnica de escritura de casos de prueba. Hoy pasemos al siguiente método dinámico de escritura de casos de prueba: la técnica de transición de estado.
Este documento explora la expansión de este concepto de prueba a aplicaciones más grandes, que no son FSM en su conjunto, pero algunos de sus componentes sí lo son, a fin de adoptar su característica única de 'tener estado' y reglas de transición, lo que resulta en muchas ventajas.
Prueba de transición estatal
Las pruebas de transición estatal son una Técnica de prueba de caja negra , que se puede aplicar para probar 'Máquinas de estado finito'.
Una 'máquina de estado finito (FSM)' es un sistema que estará en diferentes estados discretos (como 'listo', 'no listo', 'abierto', 'cerrado', ...) dependiendo de las entradas o estímulos.
Los estados discretos con los que termina el sistema dependen de las reglas de transición del sistema. Es decir, si un sistema da una salida diferente para la misma entrada, dependiendo de su estado anterior, entonces es un sistema de estados finitos.
Además, si todas las transacciones se prueban en el sistema, se denomina cobertura de 'conmutación 0'. Si la prueba cubre 2 pares de transacciones válidas, entonces es una cobertura de “1 interruptor”, y así sucesivamente.
Lo que vas a aprender:
¿Qué es la técnica de prueba de transición estatal?
La técnica de transición de estados es una técnica de prueba dinámica, que se utiliza cuando el sistema se define en términos de un número finito de estados y las transiciones entre los estados se rigen por las reglas del sistema.
O, en otras palabras, esta técnica se utiliza cuando las características de un sistema se representan como estados que se transforman entre sí. Las transformaciones están determinadas por las reglas del software. La representación pictórica se puede mostrar como:
Entonces aquí vemos que una entidad transiciones del Estado 1 al Estado 2 debido a algunos aporte condición, que conduce a una evento y resulta en acción y finalmente da el producción .
Para explicarlo con un ejemplo:
Visita un cajero automático y retira $ 1000. Obtienes tu dinero en efectivo. Ahora te quedas sin saldo y haces exactamente la misma solicitud de retirar $ 1000. Esta vez, el cajero automático se niega a darte el dinero por falta de saldo. Entonces, aquí el transición , que causó el cambio de estado es la retirada anterior
Definición de prueba de transición de estado
Habiendo entendido qué es la transición estatal, ahora podemos llegar a una definición más significativa para las pruebas de transición estatal. Por lo tanto, es una especie de prueba de caja negra en la que el probador tiene que examinar el comportamiento de AUT (Aplicación bajo prueba) frente a varias condiciones de entrada dadas en una secuencia.
El comportamiento del sistema se registra tanto para valores de prueba positivos como negativos.
¿Cuándo usar las pruebas de transición estatal?
Las pruebas de transición de estado se pueden emplear en las siguientes situaciones:
implementación de clasificación de burbujas c ++
- Cuando la aplicación bajo prueba es un sistema en tiempo real con diferentes estados y transiciones englobadas.
- Cuando la aplicación depende del evento / valores / condiciones del pasado.
- Cuándo es necesario probar la secuencia de eventos.
- Cuando la aplicación necesita ser probada contra un conjunto finito de valores de entrada.
¿Cuándo no usar las pruebas de transición estatal?
No debe confiar en las pruebas de transición estatal en las siguientes situaciones:
- Cuando no se requieren pruebas para combinaciones de entrada secuenciales.
- Cuando se requiere probar diferentes funcionalidades de la aplicación (más como pruebas exploratorias).
Ejemplo de prueba de transición de estado en pruebas de software
En el escenario práctico, a los probadores normalmente se les dan los diagramas de transición de estado y se nos pide que los interpretemos.
Estos diagramas son proporcionados por los analistas de negocios o una parte interesada y usamos estos diagramas para determinar nuestros casos de prueba.
Consideremos la siguiente situación:
Nombre del software - Manage_display_changes
Especificaciones - El software responde a las solicitudes de entrada para cambiar el modo de visualización de un dispositivo de visualización de la hora.
El modo de visualización se puede establecer en uno de los cuatro valores:
- Dos correspondientes a mostrar la hora o la fecha.
- Los otros dos al alterar la hora o la fecha.
Los diferentes estados son los siguientes:
- Modo de cambio (CM): La activación de esto hará que el modo de visualización se mueva entre 'mostrar hora (T)' y 'mostrar fecha (D)'.
- Restablecer (R): Si el modo de visualización se establece en T o D, entonces un 'reinicio' hará que el modo de visualización se establezca en los modos 'alterar la hora (AT)' o 'alterar la fecha (AD)'.
- Ajuste de tiempo (TS): La activación de esto hará que el modo de visualización vuelva a T desde AT.
- Ajuste de fecha (DS): La activación de esto hará que el modo de visualización vuelva a D desde AD.
Diagrama de transición de estado
Ahora, pasemos a interpretarlo:
Aquí:
# 1) Varios estados son:
- Tiempo de visualización (S1),
- Cambiar hora (S3),
- Mostrar fecha (S2) y
- Cambiar fecha (S4).
# 2) Varias entradas son:
- Cambiar modo (CM),
- Restablecer (R),
- Ajuste de tiempo (TS),
- Ajuste de fecha (DS).
# 3) Varias salidas son:
- Alter Time (AT),
- Tiempo de visualización (T),
- Fecha de visualización (D),
- Modificar la fecha (AD).
# 4) Los estados cambiados son:
- Tiempo de visualización (S1),
- Cambiar hora (S3),
- Mostrar fecha (S2) y
- Cambiar fecha (S4).
Paso 1: Escribe todos los estados de inicio. Para esto, tome un estado a la vez y vea cuántas flechas salen de él.
- Para el estado S1, hay dos flechas que salen de él. Una flecha va a indicar S3 y otra flecha va a indicar S2.
- Para el estado S2: hay 2 flechas. Uno va al estado S1 y el otro al S4
- Para el estado S3: solo sale 1 flecha, yendo al estado S1
- Para el estado S4: solo sale 1 flecha, yendo al estado S2
Pongamos esto sobre nuestra mesa:
Dado que para los estados S1 y S2 salen dos flechas, lo hemos escrito dos veces.
Paso 2: Para cada estado, escriba sus estados finales de transición.
- Para el estado S1: los estados finales son S2 y S3
- Para el estado S2: los estados finales son S1 y S4
- Para el estado S3: el estado final es S1
- Para el estado S4: el estado final es S2
Ponga esto sobre la mesa como un estado de salida / resultante.
Paso 3: Para cada estado de inicio y su estado de finalización correspondiente, anote las condiciones de entrada y salida
- Para que el estado S1 vaya al estado S2, la entrada es Cambiar modo (CM) y la salida es Mostrar fecha (D) que se muestra a continuación:
De manera similar, anote las condiciones de entrada y su salida para todos los estados de la siguiente manera:
Paso 4:
Ahora agregue el ID del caso de prueba para cada prueba que se muestra a continuación:
Ahora vamos a convertirlo en casos de prueba formales:
De esta forma, se pueden derivar todos los casos de prueba restantes. Asumo el otro atributos de los casos de prueba como precondiciones, gravedad, prioridad, entorno, compilación, etc. también se incluyen en el caso de prueba.
Resumiendo los pasos una vez más:
- Identifique los estados iniciales y su estado final basándose en las líneas / flechas que salen del estado inicial.
- Para cada estado inicial, averigüe la condición de entrada y el resultado de salida
- Marque cada conjunto como un caso de prueba independiente.
Más ejemplos de técnica de transición de estado
Aquí hay un ejemplo más de la técnica de prueba de transición de estado en aplicaciones de software más grandes.
Descripción:
‘ Pruebas funcionales de estado ' El enfoque se puede utilizar para probar partes o componentes específicos de la aplicación, con la característica de una máquina de estado finito (FSM).
Pasos en la implementación:
#1) El primer paso para implementar las 'Pruebas funcionales con estado' es identificar diferentes componentes / partes de la aplicación que se pueden clasificar como FSM. Las entradas, estados y salidas se rastrean cuidadosamente para cada uno de estos FSM.
#2) El siguiente paso sería desarrollar casos de prueba para estos FSM basados en reglas de transición, entradas, salidas y estados de transición.
#3) El tercer paso sería integrar la prueba de estos componentes con otros componentes de interfaz para validar la aplicación de un extremo a otro.
Esto se puede explicar por medio de un ejemplo de una aplicación denominada 'Proyecto de casa', que rastrea la construcción de una casa, con varios componentes de aplicación como aprobación de la arquitectura de la casa, registro de la parcela y la casa, selección del contratista de la construcción. , aprobación de préstamo de vivienda, etc.
Por ejemplo,
Consideraremos probar un componente FSM de la aplicación “Proyecto de vivienda”: Aprobación del préstamo para vivienda.
Solicitud de aprobación de préstamo para vivienda (HLA)
La aplicación HLA será ejecutada por un Usuario de procesamiento de préstamos independiente, que procesa la solicitud de préstamo. A continuación se detallan los diferentes pasos en la tramitación de la solicitud:
1.1.1 Paso 1: Colección de documentos
El primer paso es la recopilación de los documentos relevantes para solicitar el préstamo, como se menciona en la siguiente tabla. Son las 'condiciones' para una aplicación exitosa. El solicitante recopila los documentos requeridos y los aplica al préstamo hipotecario.
El Usuario de Procesamiento de Préstamos reconoce la recepción de los documentos y cambia el estado de la Solicitud de Préstamo (es decir, el estado del componente de la Solicitud de HLA) al estado 'Aplicado'.
Tabla 1: Lista de documentos
1.1.2 Paso 2: Evaluación del préstamo
En esta etapa, el prestamista evalúa la Solicitud de Préstamo para determinar si cumple con sus requisitos crediticios. Los documentos de respaldo se verifican en este momento.
mejor eliminación gratuita de software publicitario y malware
Tabla 2: Criticidad de los documentos
Se validan los documentos necesarios para la evaluación, es decir, las “condiciones” que deben validarse en esta etapa. Cada condición tiene una criticidad asociada (mencionada como 'Y' en la tabla anterior). Una vez que se satisfacen todas las condiciones críticas requeridas, la aplicación pasa al estado 'Confirmado', es decir, el componente de la aplicación HLA está en el estado 'Confirmado'.
Señalar para tener en cuenta:
#1) Este principio aporta una estructura y objetividad a las condiciones de prueba y las definiciones de 'estado' del sistema. .
Además, no todas las 'condiciones' para validar el sistema son críticas para que alcance este estado 'Confirmado'. En la tabla anterior, 4 condiciones están marcadas como 'No críticas' para que la aplicación alcance el estado 'Confirmado'.
#2) El número de validaciones se puede reducir de manera óptima, según el riesgo o la criticidad de las reglas requeridas para cada estado. Esto reducirá significativamente el tiempo necesario para la ejecución de la prueba y, al mismo tiempo, no comprometerá la calidad de las pruebas.
#3) Esto no solo es útil para probar los componentes individuales, sino también para probar el sistema de un extremo a otro.
#4) Además, es muy útil al crear conjuntos de pruebas de regresión.
Entonces, en esta etapa, es un tipo de prueba de cambio 0. Pero las etapas posteriores de aprobación pueden ser tipos de validaciones de 1 interruptor o 2 interruptores para esa etapa.
Por ejemplo, El 'certificado de matrimonio' puede no ser demasiado relevante en esta etapa, pero en las últimas etapas de la aprobación, cuando se considera el riesgo del solicitante de pagar el EMI, el certificado de matrimonio puede ser relevante, es decir, si el cónyuge también está empleado , reduce el riesgo y, si no se emplea, aumenta el riesgo.
#5) El principio anterior se puede utilizar para ampliar las condiciones de prueba según los requisitos del componente en esa etapa.
1.1.3 Paso 3: Aprobación condicional
El estado actual de la aplicación es 'Confirmado'. El prestamista otorgaría 'Aprobación condicional' para que el proceso de préstamo avance. Se requieren más validaciones para mover la aplicación HLA al estado 'Aprobado'.
1.1.4 Paso 4: Aprobación
Las validaciones críticas se llevan a cabo en esta etapa:
- Evaluación por el seguro hipotecario de prestamistas (LMI): esto implicaría validaciones de 2 cambios o más para la autenticidad de la propiedad.
- El prestamista puede exigir información que no se proporcionó durante la etapa de 'Confirmación'.
Una vez que se cumplen las condiciones anteriores, la aplicación pasa al estado 'Aprobado'. La autoridad final del proceso de aprobación puede verificar la credibilidad del solicitante del Préstamo pidiendo más detalles o no puede preguntar si los otros documentos del Solicitante son concluyentes. Es decir, se requerirían más entradas de diferentes componentes de la aplicación principal para probar la validez .
#6) En otras palabras, se pueden requerir (o reducir) más validaciones para la transición a un estado diferente dependiendo de las condiciones de entrada al componente desde otros componentes de la aplicación.
El diagrama siguiente muestra el proceso de aprobación.
Figura 1: Proceso de aprobación de préstamos
Riesgos y desafíos
- Para aplicaciones grandes, un conocimiento profundo de la aplicación es esencial para dividir la aplicación en diferentes componentes lógicos para permitir la categorización como FSM y componentes regulares. Esto podría requerir un tiempo costoso de las PYME.
- No todas las aplicaciones tendrían la viabilidad de este tipo de categorización FSM.
- Dado que los componentes de FSM interactúan con los componentes regulares en la aplicación, las entradas a los FSM de diferentes componentes requieren una planificación y ejecución cuidadosas.
Ventajas de las pruebas de transición estatal
- Con esta técnica, al utilizar una representación gráfica o tabular del comportamiento del sistema, el evaluador se familiariza con el diseño de la aplicación y se siente fácil de cubrir y diseñar las pruebas de manera efectiva y eficiente.
- Los estados no planificados o no válidos del sistema también se cubren con esta técnica.
- Con el diagrama de transición de estado, es fácil verificar si se cubren todas las condiciones.
Desventajas de las pruebas de transición estatal
- Esta técnica no se puede utilizar para sistemas de estados no finitos.
- Definir todos los estados posibles para sistemas grandes y complejos es una tarea bastante engorrosa.
Conclusión
La prueba de transición de estado es un enfoque útil cuando se requiere probar diferentes transiciones de sistema para sistemas de estado finito.
Probar una aplicación con el concepto de 'prueba funcional con estado' puede brindar a las organizaciones de prueba un enfoque de prueba único para probar aplicaciones complejas, lo que aumentaría la productividad de ejecución de pruebas sin comprometer la cobertura de las pruebas.
La prueba de transición de estado es un enfoque de prueba único para probar aplicaciones complejas, lo que aumentaría la productividad de ejecución de la prueba sin comprometer la cobertura de la prueba.
La limitación de esta técnica es que no se puede utilizar hasta que, ya menos que el sistema bajo prueba, tenga solo estados finitos.
Lectura recomendada
- ¿Qué es la técnica de prueba basada en defectos?
- ¿Qué es la técnica de prueba de matriz ortogonal (OATS)?
- Pruebas funcionales versus pruebas no funcionales
- ¿Qué son las pruebas de comparación (aprender con ejemplos)?
- ¿Qué es la prueba de mutación? Tutorial con ejemplos
- ¿Qué son las pruebas de resistencia en las pruebas de software (ejemplos)?
- ¿Qué son las pruebas de extremo a extremo: marco de pruebas E2E con ejemplos?
- Mejores herramientas de prueba de software 2021 (Herramientas de automatización de pruebas de control de calidad)