Тестування переривань у мобільному додатку
Томас Гамільтон
⚡ Розумний підсумок
Interrupt Testing checks how a mobile application behaves when a call, alarm, notification, or network drop takes over, and whether the application returns to its exact previous state once the interruption ends.
Що таке тестування переривань?
Тестування переривань is a branch of Mobile Application Testing that deals with how an application reacts to an interruption and resumes to its previous state. The interruption comes from outside the application — the operating system, the hardware, or another app — and the test verifies that no data, screen state or in-progress transaction is lost when control returns.
Тестування переривань застосовується до будь-якого типу застосунків — веб-, мобільних, автономних тощо. Різноманітність пристроїв, мереж та конфігурацій робить його набагато більш важливим для... мобільний додатків, ніж для інших.
Навіщо вам тестування переривань?
Що майже завжди трапляється під час зустрічі? Вас переривають, чи не так? Коли це трапляється, деякі люди навіть не моргають, деяким потрібна хвилина, щоб прийти до тями, а деякі повністю втрачають хід думок. Простими словами, тестування переривань намагається з'ясувати, яку поведінку демонструє ваш додаток.
Відкладіть на секунду всі формулювання та розгляньте іншу реальну ситуацію. Скажімо, у вас є ліхтарик, і ви його вмикаєте. Батарея розряджається, що перериває його поточний активний стан. Замініть батарейки та відновіть його роботу. Ліхтарик має знову ввімкнутися у звичайному режимі. Це випадок використання. Дисципліна тестування, яка зосереджується на тому, чи відбувається це, чи ні, називається тестуванням переривань.
Бізнес-кейс простий. Переривання відбувається в найневідповідніший момент — посеред оплати, посеред завантаження, посеред форми — і користувач, який втрачає цю роботу, рідко намагається знову. Збої в резюме, порожні екрани, дублікати транзакцій та втрата введених даних форми — все це дефекти, які виявляє лише переривання, тому вони переживають функціональний пропуск, який ніколи нічого не перериває.
Тип перерв у мобільному додатку
Переривання поділяються на кілька знайомих груп, які зведено на ілюстрації нижче.
Ми всі знайомі з поширеними перебоями, які зазвичай трапляються. Ось деякі з них:
- Низький заряд батареї
- Battery full — when charging
- Вхідний телефонний дзвінок
- Вхідні SMS
- Вхідне сповіщення з іншого мобільного застосунку
- Підключено для зарядки
- Відключено від зарядки
- Пристрій вимкнено
- Нагадування про оновлення програм
- сигнал тривоги
- Втрата з'єднання з мережею
- Відновлення підключення до мережі
This list is not exhaustive but includes the most common scenarios. A practical way to organise it is by origin: device-dependent events such as battery and charging, user-initiated events such as answering a call or switching apps, and external events such as losing signal in a lift or a tunnel.
Роздільна здатність у разі переривання
Очікувана поведінка у разі цих переривань є однією з наступних чотирьох:
- Запуск у фоновому режимі: The interruption takes over while the application takes a back seat. It gains control after the interruption ends. For example, a phone call or FaceTime call that you attend while you are reading a digital book on iBooks (or a similar application). When the user answers the phone, iBooks waits until the call is done and then resumes when it ends.
- Показати сповіщення: The alert disappears and you work as usual. A “SMS received” message appears in the header. The user does not bother about it and continues working with the application as normal. Other mobile app alerts, such as a new friend request on Facebook or a WhatsApp message, also fall into this category. But if the user decides to read the message, the behavior described in point 1 is followed. If the alert is ignored, the state of the application is unchanged.
- Заклик до дії: Alarms have to be turned off or snoozed before you continue working. The same applies to app update messages. You either have to cancel or accept the changes before you proceed. Another example is the low battery alert — you can choose to continue as usual or go into a low power mode, if the device allows it.
- Немає впливу: Прикладом є підключення до мережі, коли ваш пристрій підключається до нього. Також, коли ви підключаєте пристрій для заряджання, не потрібно сповіщати чи закликати до дії. Ймовірно, він виконуватиме свою роботу, поки ви продовжуєте використовувати свою програму.
Таким чином, залежно від переривання, яке ви тестуєте, зрозумійте поведінку та перевірте, чи задовольняє ваш додаток вимоги. Також описана вище поведінка не обов'язково має бути однаковою для всіх додатків та пристроїв. Обов'язково дізнайтеся конкретні деталі для вашого мобільного додатку.
Тестові випадки тестування переривань з очікуваними результатами
Після узгодження очікуваного рішення кожне переривання стає звичайним тестовим випадком із тригером, дією та перевіреним результатом. У таблиці нижче показано, як чотири вищезгадані рішення перетворюються на конкретні сценарії.
| Переривання | Тестовий сценарій | Очікуваний результат |
| Вхідний телефонний дзвінок | Ініціювати виклик, коли форма наполовину заповнена, відповісти на нього, а потім завершити виклик | Програма переходить у фоновий режим і відновлює роботу на тому ж екрані з незмінними введеними даними. |
| Вхідні SMS-повідомлення або push-сповіщення | Надіслати повідомлення під час перегляду відео або завантаження та ігнорувати банер | Banner appears and disappears; the application state is unchanged |
| сигнал тривоги | Дозволити спрацьовування запланованого будильника під час активного сеансу та відхилити його | Сигналізація спочатку вимагає заклику до дії, а потім програма відновлює роботу з того місця, де зупинилася |
| Попередження про низький заряд акумулятора | Розрядити пристрій до порогу попередження під час транзакції | Warning is shown, the transaction is not cancelled, and low power mode does not break the screen |
| Втрата з'єднання з мережею | Вимкнути підключення під час запиту, а потім відновити його | A clear message is shown, no crash occurs, and the request completes or fails safely on restoration |
| Зарядка підключена або відключена | Підключення та відключення зарядного пристрою під час активного сеансу | No impact — the application continues without a visible change |
| Application update reminder | Викликати запит на оновлення під час використання програми | Користувач може скасувати або прийняти, і нижній екран зберігається в будь-якому випадку. |
Залишайте один рядок на кожне переривання для кожного критичного екрана, а не один рядок на переривання для всієї програми. Екран оплати, екран входу та довга форма дають різні збої, і один загальний випадок приховує це.
Тепер, коли ми зрозуміли, що таке тестування переривань і що потрібно перевіряти при його проведенні, настав час поговорити про те, як це зробити.
Як виконати тестування переривань
Подивіться на цю заяву: iBooks має працювати у фоновому режимі, коли користувач отримує вхідний телефонний дзвінок.
Хіба ви не назвали б це функціональною вимогою програми iBooks? Я точно так би сказав.
Отже, тестування переривань є підмножиною Функціональне тестування для мобільного застосунку. Для проведення тестування переривань ви використовуєте ті самі рамки та інструменти для тестування мобільних застосунків. Тестери мають навички продумувати ці сценарії. Після цього ви розробляєте тестові випадки та виконуєте їх точно так само, як і будь-який інший тест.
In practice the sequence is short and repeatable:
- List the critical user journeys — login, payment, upload, long forms, media playback.
- Відобразіть кожну ймовірну перешкоду зі списку вище на кожній подорожі.
- Узгодьте очікувану роздільну здатність для кожного сполучення з власником продукту, оскільки універсального значення за замовчуванням не існує.
- Переривайте роботу в найнебезпечніший момент, а не в момент простою, а потім продовжуйте.
- Перевірити стан, дані, сеанс та пам'ять після відновлення, а не лише те, що програма все ще відкрита.
For more information on the wider discipline, see the Мобільне тестування навчальний посібник та зразки випадків у Тестування мобільних додатків.
Інструменти та методи для моделювання переривань
The scenarios above have to be produced on demand rather than waited for, and each platform provides a way to do that.
- Android Emulator extended controls: Бічна панель емулятора імітує вхідний дзвінок, SMS, рівень заряду батареї та стан зарядного пристрою, а також силу стільникового сигналу, тому більшість переривань можна викликати без використання другої трубки.
- Симулятор iOS та Xcode: Connectivity and hardware states can be varied from the simulator and from device settings, while a paired physical device covers the call scenarios that a simulator cannot raise.
- Другий фізичний пристрій: Calling or messaging the device under test from another handset remains the most faithful way to reproduce a real interruption, especially for timing-sensitive cases.
- Налаштування пристрою: Airplane mode, Wi-Fi toggles, Do Not Disturb, battery saver and scheduled alarms cover connectivity and power interruptions on real hardware.
- Структури автоматизації: Той самий стек автоматизації, який використовується для решти вашого функціонального пакету, може керувати застосунком до та після переривання, тому перевірка резюме здійснюється ствердно, а не на око.
- Real-device clouds: Ферма розміщених пристроїв розширює охоплення різних виробників та версій ОС, що важливо, оскільки обробка переривань є однією з областей, де налаштування постачальників найбільше розходяться.
Whatever the mechanism, record the exact moment of interruption in the test case. “Interrupt during upload” and “interrupt after upload” are different tests with different failure modes.
Найкращі практики тестування переривань
Кілька звичок відрізняють корисний набір переривань від вправи з галочками в блоці.
- Перебивайте в найневідповідніший момент: Target у момент фіксації транзакції або запису файлу, оскільки саме в цьому випадку стан є найбільш крихким.
- Test the resume, not the interruption: Дефект майже завжди з'являється після повернення керування, тому твердження належать до відновленого екрану.
- Cover both directions of a network change: Втрата з'єднання та його відновлення – це окремі випадки, і другий пропускається частіше.
- Vary the duration: A two-second alert and a ten-minute call push the application through different lifecycle paths, including being evicted from memory.
- Розподіл між версіями ОС та низькоякісним обладнанням: Фонове видалення набагато агресивніше на пристроях з обмеженнями, що виявляє недоліки, які приховує флагманський телефон.
- Автоматизуйте повторювані дії: Перебої з підключенням та перебої з батареєю повністю автоматизовані, звільняючи ручну роботу для викликів та будильників.
- Спостерігайте за використанням ресурсів, а також зазначайте: Переривання, яке призводить до витоку пам'яті або розрядки батареї під час відновлення, є дефектом, навіть якщо екран виглядає правильно, що пов'язує цю роботу з тестування продуктивності мобільного додатку.
Хіба тестування переривання не те саме, що тестування відновлення?
Ні, це не. Тестування відновлення підтверджує відновлення після збою. Переривання не обов'язково є збоєм — це простоtrac.
Це як різниця між комою та крапкою в англійській мові. Різниця лише технічна, але картина зрозуміла. Тестування відновлення запитує, чи може програма відновитися після того, як щось зламалося; тестування переривань запитує, чи щось взагалі зламається, коли щось інше виходить на передній план.
That is what there is to know to get started with Interrupt Testing — an important and intuitive branch of Mobile Application Testing.
