Тестировал ли прерывание

Прерывание в контексте тестирования

Да, я тестировал прерывание в рамках различных проектов, особенно в области мобильных приложений, клиент**-серверных систем и комплексных интеграций. Прерывание (или interruption) — это ключевая концепция в тестировании, которая относится к ситуациям, когда нормальная работа системы нарушается внешними или внутренними событиями. Это критически важно для оценки стабильности, восстанавливаемости и пользовательского опыта приложения.

Основные типы прерываний, которые я тестировал

В своей практике я фокусировался на нескольких категориях прерываний:

• Системные прерывания (внешние):

    *   **Прерывание сети:** Смена типа сети (Wi-Fi на 4G/5G), потеря соединения, искусственное ограничение скорости через инструменты (например, **Charles Proxy** или **Network Link Conditioner**).
    *   **Прерывание питания:** Имитация внезапного отключения устройства (для серверов) или разряда батареи (для мобильных устройств).
    *   **Прерывание на уровне ОС:** Принудительная остановка процесса через диспетчер задач, переключение между приложениями (особенно на мобильных устройствах).

• Пользовательские прерывания (внутренние):

    *   **Входящий звонок** или сообщение во время работы приложения (классический случай для мобильного тестирования).
    *   **Переключение на другое приложение** (например, из игры в мессенджер) и затем возврат.
    *   **Открытие уведомления**, которое временно перекрывает интерфейс.

• Прерывания данных:

    *   **Неожиданное изменение данных** во время транзакции (например, удаление записи, с которой работает пользователь, другим процессом).
    *   **Прерывание длительных операций:** Загрузка файла, синхронизация данных, потоковая передача видео.

Пример тест-кейса для прерывания сети в мобильном приложении

Рассмотрим конкретный пример тестирования прерывания сети при отправке сообщения в мессенджере.

Feature: Отправка сообщения в условиях нестабильной сети

Scenario: Сообщение сохраняется локально при потере сети и отправляется после восстановления
  Given пользователь открыл диалог и написал новое сообщение
  When пользователь нажимает кнопку "Отправить"
  And сетевое соединение искусственно отключается (через Charles Proxy)
  Then сообщение сохраняется в локальной очереди "ожидания отправки"
  And интерфейс отображает статус "Ожидание сети..."
  When сетевое соединение восстанавливается
  Then система автоматически пытается отправлить сообщение из очереди
  And в интерфейсе статус меняется на "Отправлено"

Для автоматизации такого теста на Android (с использованием Appium и Python) код может выглядеть так:

import pytest
from appium import webdriver
from appium.webdriver.common.appiumby import AppiumBy

def test_message_send_with_network_interruption():
    # Предполагается, что драйвер уже настроен
    driver = webdriver.Remote('http://localhost:4723/wd/hub', desired_capabilities)

    # 1. Написать сообщение
    text_field = driver.find_element(AppiumBy.ID, "com.app.messenger:id/message_input")
    text_field.send_keys("Тестовое сообщение при прерывании сети")

    # 2. Нажать "Отправить"
    send_button = driver.find_element(AppiumBy.ID, "com.app.messenger:id/send_button")
    send_button.click()

    # 3. Имитация прерывания сети (через команду ADB или изменение прокси)
    # Это может зависеть от инструмента. Например, через Charles Proxy API.
    # driver.execute_script('mobile: networkSpeed', {'offline': True})

    # 4. Проверить локальное состояние (сообщение в очереди)
    pending_status = driver.find_element(AppiumBy.ID, "com.app.messenger:id/status_label")
    assert pending_status.text == "Ожидание сети..."

    # 5. Восстановить сеть
    # driver.execute_script('mobile: networkSpeed', {'full': True})

    # 6. Проверить успешную отправку
    # Ждем и проверяем изменение статуса
    # ... (используем явные ожидания WebDriverWait)
    success_status = driver.find_element(AppiumBy.ID, "com.app.messenger:id/status_label")
    assert success_status.text == "Отправлено"

Ключевые аспекты, проверяемые при тестировании прерываний

При тестировании прерываний я оценивал не просто факт падения системы, а ее поведение:

1. Сохранение состояния: Приложение должно корректно сохранять текущий прогресс или данные (например, заполненную форму, позицию в видео).
2. Восстановление: После устранения причины прерывания система должна либо автоматически продолжить операцию, либо предоставить пользователю четкий способ сделать это.
3. Информирование пользователя: Интерфейс должен показывать понятное состояние (например, "Соединение потеряно", "Попытка повторной отправки...").
4. Отсутствие данных/повреждений: Прерывание не должно приводить к потере данных, их повреждению или созданию дублирующих записей.
5. Стабильность UI: Интерфейс не должен "зависать" или показывать некорректные элементы после восстановления.

Инструменты и методы

Для имитации прерываний я использовал:

• Charles Proxy, Fiddler или Network Link Conditioner для управления сетью.
• ADB commands (для Android) или Simulator/Device settings для имитации звонков, переключений.
• Мониторы памяти и CPU (например, Android Studio Profiler) для отслеживания утечек ресурсов после прерывания.
• Сценарное тестирование и автоматизация на основе состояний.

Тестирование прерываний — это не просто проверка на "отказ", а глубокий анализ жизненного цикла приложения в реальных, неидеальных условиях. Это позволяет выявить архитектурные слабости, улучшить обработку ошибок и, в конечном счете, создать продукт, который устойчив к непредвиденным событиям и сохраняет доверие пользователя.