Pruebas de interrupción en aplicaciones móviles

⚡ Resumen inteligente

Las pruebas de interrupción comprueban cómo se comporta una aplicación móvil cuando se produce una llamada, una alarma, una notificación o una caída de la red, y si la aplicación vuelve a su estado anterior exacto una vez que finaliza la interrupción.

🔘 Alcance: Esta técnica pertenece al ámbito de las pruebas de aplicaciones móviles, pero también se aplica a software web y de escritorio.
☑️ Fuentes de interrupción: Las llamadas entrantes, los SMS, las alarmas, la batería baja, los eventos de carga, las actualizaciones de aplicaciones y los cambios de red cubren la mayoría de los escenarios reales.
✅ Cuatro resultados esperados: Ejecutarse en segundo plano, mostrar una alerta, realizar una llamada a la acción o no tener ningún impacto: cada aplicación define cuál de estas opciones se aplica.
🧪 Diseño de pruebas: Las pruebas de interrupción son un subconjunto de las pruebas funcionales, por lo que se aplican los mismos marcos de trabajo, casos de prueba y proceso de ejecución.
🛠️ simulación: Los controles extendidos del emulador, la configuración del dispositivo y las nubes de dispositivos reales reproducen llamadas, alertas y pérdidas de conectividad bajo demanda.
📊 No se trata de pruebas de recuperación: Las pruebas de recuperación validan la restauración después de un fallo, mientras que una interrupción es solo unatracción, no es una culpa.

Descubre más

¿Qué son las pruebas de interrupción?

Prueba de interrupción Es una rama de las pruebas de aplicaciones móviles que analiza cómo una aplicación reacciona ante una interrupción y retoma su estado anterior. La interrupción proviene del exterior de la aplicación (el sistema operativo, el hardware u otra aplicación) y la prueba verifica que no se pierda ningún dato, estado de la pantalla ni transacción en curso al recuperar el control.

Las pruebas de interrupción se aplican a cualquier tipo de aplicación: web, móvil, independiente, etc. La variedad de dispositivos, redes y configuraciones hace que sea mucho más prominente para móvil aplicaciones que para los demás.

¿Por qué necesita pruebas de interrupción?

¿Qué es lo que casi siempre ocurre en una reunión? Que te interrumpen, ¿verdad? Cuando sucede, algunos ni se inmutan, otros necesitan un minuto para retomar la conversación y otros pierden completamente el hilo. En pocas palabras, las pruebas de interrupción buscan determinar qué comportamiento presenta tu aplicación.

Dejemos de lado la terminología por un momento y consideremos otra situación real. Imaginemos que tenemos una linterna y la encendemos. La batería se agota, lo que interrumpe su funcionamiento. Reemplazamos las baterías y la linterna se enciende de nuevo con normalidad. Este es el caso de uso. Una disciplina de pruebas que se centra en determinar si esto ocurre o no se denomina prueba de interrupción.

El argumento comercial es sencillo. Una interrupción llega en el peor momento posible —en medio de un pago, una carga de datos o un formulario— y un usuario que pierde su trabajo rara vez lo vuelve a intentar. Los fallos al reanudar la aplicación, las pantallas en blanco, las transacciones duplicadas y la pérdida de datos en los formularios son defectos que solo una interrupción pone de manifiesto, razón por la cual persisten en una fase funcional que nunca interrumpe nada.

Tipo de interrupciones en la aplicación móvil

Las interrupciones se agrupan en una serie de categorías bien conocidas, resumidas en la siguiente ilustración.

Todos conocemos las interrupciones comunes que suelen ocurrir. Aquí les presentamos algunas:

Bateria BAJA
Batería llena — al cargar
Llamada telefónica entrante
SMS entrantes
Alerta entrante de otra aplicación móvil.
Conectado para cargar
Desconectado de la carga
Dispositivo apagado
Recordatorios de actualización de la aplicación
Alarma
Pérdida de conexión de red
Restauración de la conexión de red

Esta lista no es exhaustiva, pero incluye los escenarios más comunes. Una forma práctica de organizarla es por origen: eventos dependientes del dispositivo, como la batería y la carga; eventos iniciados por el usuario, como contestar una llamada o cambiar de aplicación; y eventos externos, como perder la señal en un ascensor o un túnel.

Resolución en caso de Interrupción

El comportamiento esperado en caso de estas interrupciones es uno de los cuatro siguientes:

Ejecutar en segundo plano: La interrupción toma el control mientras la aplicación pasa a un segundo plano. Retoma el control una vez finalizada la interrupción. Por ejemplo, una llamada telefónica o una videollamada de FaceTime que atiendes mientras lees un libro digital en iBooks (o una aplicación similar). Cuando el usuario contesta la llamada, iBooks espera a que termine y luego se reanuda.
Mostrar alerta: La alerta desaparece y la aplicación sigue funcionando con normalidad. Aparece un mensaje de «SMS recibido» en el encabezado. El usuario no le presta atención y continúa usando la aplicación como siempre. Otras alertas de aplicaciones móviles, como una nueva solicitud de amistad en Facebook o un mensaje de WhatsApp, también entran en esta categoría. Pero si el usuario decide leer el mensaje, se sigue el comportamiento descrito en el punto 1. Si se ignora la alerta, el estado de la aplicación permanece sin cambios.
Llamada a la acción: Las alarmas deben desactivarse o posponerse antes de continuar trabajando. Lo mismo ocurre con los mensajes de actualización de las aplicaciones. Debes cancelar o aceptar los cambios antes de seguir adelante. Otro ejemplo es la alerta de batería baja: puedes optar por continuar como de costumbre o activar el modo de bajo consumo, si el dispositivo lo permite.
Sin impacto: Un ejemplo es cuando se habilita una conexión de red y tu dispositivo se conecta a ella. Asimismo, cuando conectas tu dispositivo para cargarlo, no es necesario realizar ninguna alerta ni acción. Probablemente, el sistema seguirá funcionando mientras continúas usando tu aplicación.

Por lo tanto, dependiendo de la interrupción que esté probando, comprenda el comportamiento y verifique si su aplicación lo reproduce. Además, el comportamiento descrito anteriormente no tiene por qué ser el mismo para todas las aplicaciones y dispositivos. Asegúrese de conocer los detalles específicos de su aplicación móvil.

Casos de prueba de interrupción con resultados esperados

Una vez acordada la resolución prevista, cada interrupción se convierte en un caso de prueba ordinario con un desencadenante, una acción y un resultado verificable. La tabla siguiente muestra cómo se traducen las cuatro resoluciones anteriores en escenarios concretos.

Interrupción	Escenario de prueba	Resultado Esperado
Llamada telefónica entrante	Realiza una llamada cuando el formulario esté medio lleno, respóndela y luego finaliza la llamada.	La aplicación pasa a segundo plano y se reanuda en la misma pantalla con los datos introducidos intactos.
Alerta de SMS entrante o notificación push	Enviar un mensaje mientras se está reproduciendo un video o se está subiendo un archivo, e ignorar el banner.	El banner aparece y desaparece; el estado de la aplicación permanece sin cambios.
Alarma	Permitir que una alarma programada se active durante una sesión activa y luego descartarla.	La alarma requiere primero una llamada a la acción, luego la aplicación se reanuda donde se detuvo.
Aviso de batería baja	Agotar el dispositivo hasta el umbral de advertencia durante una transacción.	Se muestra una advertencia, la transacción no se cancela y el modo de bajo consumo no daña la pantalla.
Pérdida de conexión de red	Desactive la conectividad durante la solicitud y luego restáurela.	Se muestra un mensaje claro, no se produce ningún fallo y la solicitud se completa o falla de forma segura al restaurarse.
Cargando enchufado o desenchufado	Conecta y desconecta el cargador durante una sesión activa.	Sin impacto: la aplicación continúa sin cambios visibles.
Recordatorio de actualización de la aplicación	Mostrar un aviso de actualización mientras la aplicación está en uso.	El usuario puede cancelar o aceptar, y la pantalla subyacente permanece visible independientemente de la elección.

Mantenga una fila por interrupción por pantalla crítica en lugar de una fila por interrupción para toda la aplicación. La pantalla de pago, la pantalla de inicio de sesión y un formulario extenso fallan de manera diferente, y un único caso genérico oculta esa diferencia.

Ahora que entendemos qué es el Interrupt Testing y qué validar al realizarlo, es momento de hablar sobre cómo hacerlo.

Cómo hacer pruebas de interrupción

Mire esta afirmación: iBooks debe ejecutarse en segundo plano cuando el usuario recibe una llamada telefónica entrante.

¿No considerarías esto un requisito funcional de la aplicación iBooks? Yo sí lo consideraría.

Entonces, las pruebas de interrupción son un subconjunto de Prueba de funcion Para realizar pruebas de interrupción en una aplicación móvil, se siguen los mismos marcos y herramientas de prueba. La clave está en concebir estos escenarios. Una vez hecho esto, se diseñan los casos de prueba y se ejecutan exactamente igual que cualquier otra prueba.

En la práctica, la secuencia es corta y repetible:

Enumera los flujos de usuario críticos: inicio de sesión, pago, carga de archivos, formularios extensos, reproducción de contenido multimedia.
Asigne a cada trayecto todas las posibles interrupciones de la lista anterior.
Acuerde con el responsable del producto la resolución prevista para cada emparejamiento, ya que no existe una solución predeterminada universal.
Realice la interrupción en el momento de mayor riesgo, no en un momento de inactividad, y luego reanude la actividad.
Verifique el estado, los datos, la sesión y la memoria después de la reanudación, no solo que la aplicación siga abierta.

Para obtener más información sobre la disciplina en general, consulte la Pruebas móviles tutorial y los casos de ejemplo en Prueba de aplicaciones móviles.

Herramientas y técnicas para simular interrupciones

Los escenarios descritos anteriormente deben generarse bajo demanda, en lugar de esperar a que se generen, y cada plataforma ofrece una forma de hacerlo.

Android Controles extendidos del emulador: El panel lateral del emulador simula una llamada entrante, un SMS, el nivel de batería y el estado del cargador, así como la intensidad de la señal celular, por lo que la mayoría de las interrupciones pueden consultarse sin necesidad de un segundo teléfono.
Simulador de iOS y Xcode: La conectividad y el estado del hardware pueden variar desde el simulador y desde la configuración del dispositivo, mientras que un dispositivo físico emparejado cubre los escenarios de llamada que un simulador no puede generar.
Un segundo dispositivo físico: Llamar o enviar un mensaje al dispositivo que se está probando desde otro teléfono sigue siendo la forma más fiel de reproducir una interrupción real, especialmente en casos donde el tiempo es un factor crucial.
Configuración de dispositivo: El modo avión, los interruptores de Wi-Fi, el modo No molestar, el ahorro de batería y las alarmas programadas cubren las interrupciones de conectividad y energía en hardware real.
Marcos de automatización: La misma pila de automatización que se utiliza para el resto de su conjunto de funciones puede controlar la aplicación antes y después de la interrupción, de modo que la comprobación de reanudación se realiza de forma asertiva en lugar de visual.
Nubes de dispositivos reales: Una granja de dispositivos alojada amplía la cobertura entre fabricantes y versiones de sistemas operativos, lo cual es importante porque la gestión de interrupciones es una de las áreas donde más difieren las personalizaciones de los proveedores.

Sea cual sea el mecanismo, registre el momento exacto de la interrupción en el caso de prueba. "Interrupción durante la carga" e "interrupción después de la carga" son pruebas diferentes con distintos modos de fallo.

Mejores prácticas para pruebas de interrupción

Algunos hábitos distinguen un conjunto de herramientas de interrupción útiles de un simple trámite burocrático.

Interrumpir en el peor momento: Target en el instante en que se confirma una transacción o se escribe un archivo, porque es ahí donde el estado es más frágil.
Prueba la reanudación, no la interrupción: El defecto casi siempre aparece después de que se restablece el control, por lo que las aserciones deben aparecer en la pantalla restaurada.
Cubrir ambas direcciones de un cambio en la red: Perder una conexión y recuperarla son casos distintos, y el segundo se omite con mayor frecuencia.
Varía la duración: Una alerta de dos segundos y una llamada de diez minutos hacen que la aplicación pase por diferentes rutas del ciclo de vida, incluida su eliminación de la memoria.
Se presenta en diversas versiones de sistemas operativos y hardware de gama baja: La eliminación de archivos en segundo plano es mucho más agresiva en dispositivos con recursos limitados, lo que pone al descubierto defectos que un teléfono de gama alta oculta.
Automatice las tareas repetibles: Las interrupciones de conectividad y de la batería se automatizan de forma eficiente, lo que libera tiempo y esfuerzo para situaciones de llamadas y alarmas.
Observa el uso de los recursos y el estado: Una interrupción que provoca fugas de memoria o descarga la batería al reanudarse es un defecto incluso cuando la pantalla se ve correcta, lo que vincula este trabajo con pruebas de rendimiento de aplicaciones móviles.

¿No son las pruebas de interrupción lo mismo que las pruebas de recuperación?

No, no es. Pruebas de recuperación valida la restauración tras un fallo. Una interrupción no es necesariamente un fallo, es simplemente una desconexión.tracción.

Es como la diferencia entre una coma y un punto en español. La distinción es meramente técnica, pero la idea es clara. Las pruebas de recuperación preguntan si la aplicación puede volver a funcionar después de un fallo; las pruebas de interrupción preguntan si algo falla cuando otra cosa toma el primer plano.

Eso es lo que hay que saber para empezar con las pruebas de interrupción, una rama importante e intuitiva de las pruebas de aplicaciones móviles.

Preguntas Frecuentes

Los escenarios son los mismos, pero los resultados no. Las dos plataformas gestionan las aplicaciones en segundo plano y la eliminación de memoria de manera diferente, y Android Las interfaces de los fabricantes añaden sus propias reglas de batería, por lo que la misma prueba puede pasar en una familia de dispositivos y fallar en otra.

Los modelos de IA leen historias de usuario e informes de fallos y proponen combinaciones de interrupciones que un evaluador podría no haber considerado; por ejemplo, una llamada que llega justo durante la actualización del token. El aprendizaje automático también agrupa los registros de fallos de producción para mostrar qué interrupciones afectan primero a los usuarios reales.

Copilot redacta correctamente el código estándar: minimiza la aplicación, activa o desactiva la conectividad, espera y, finalmente, muestra la pantalla restaurada. La decisión de cuándo interrumpir y qué estado debe mantenerse recae en el evaluador, por lo que conviene tratar los scripts generados como un borrador inicial para revisar.

Sí. Ambos nombres describen la misma actividad y se usan indistintamente en diferentes equipos y con distintas herramientas. Elija una ortografía para su plan de pruebas y úsela de forma consistente, ya que la terminología mixta dificulta la búsqueda de conjuntos de pruebas y facilita la creación de casos duplicados.

Utilice ambos. Los emuladores son ideales para una conectividad rápida y repetible, así como para casos de batería en una cadena de procesamiento. Se requieren dispositivos reales para llamadas genuinas, administradores de batería del proveedor y eliminación de memoria insuficiente, que son precisamente las condiciones que exponen los defectos de reanudación más difíciles de detectar.

Bloqueos al reanudar la aplicación, pantallas en blanco o incorrectas tras regresar, pérdida de datos introducidos en formularios, pagos duplicados tras un intento de reintento, sesiones interrumpidas que requieren un nuevo inicio de sesión, reproducción multimedia bloqueada y fugas de memoria o batería que aparecen solo después de que la aplicación se ejecute repetidamente en segundo plano.

Es ambas cosas. Las interrupciones de red, batería y cambio de aplicación se registran de forma fiable y deben incluirse en la prueba de regresión. Las llamadas entrantes, las alarmas y las indicaciones de encendido específicas del fabricante suelen ser más rápidas de probar manualmente en un teléfono real, por lo que la mayoría de los equipos mantienen un pequeño conjunto de pruebas manuales.

Comience tan pronto como se complete la funcionalidad de un proyecto crítico, en lugar de durante la última semana de consolidación. Los defectos que se reanudan a menudo requieren cambios en el ciclo de vida o en la gestión del estado, y estos son costosos de implementar una vez que la versión candidata está congelada.