Тестування переривань у мобільному додатку
Томас Гамільтон
⚡ Розумний підсумок
Тестування переривань перевіряє, як поводиться мобільний застосунок, коли перехоплює виклик, тривога, сповіщення або збій мережі, і чи повертається застосунок до свого попереднього стану після закінчення переривання.
Що таке тестування переривань?
Тестування переривань – це розділ тестування мобільних додатків, який досліджує, як додаток реагує на переривання та повертається до попереднього стану. Переривання відбувається ззовні додатка – операційної системи, апаратного забезпечення чи іншого додатка – і тест перевіряє, чи не втрачаються дані, стан екрана чи транзакція, що виконується, коли керування повертається.
Тестування переривань застосовується до будь-якого типу застосунків — веб-, мобільних, автономних тощо. Різноманітність пристроїв, мереж та конфігурацій робить його набагато більш важливим для... мобільний додатків, ніж для інших.
Навіщо вам тестування переривань?
Що майже завжди трапляється під час зустрічі? Вас переривають, чи не так? Коли це трапляється, деякі люди навіть не моргають, деяким потрібна хвилина, щоб прийти до тями, а деякі повністю втрачають хід думок. Простими словами, тестування переривань намагається з'ясувати, яку поведінку демонструє ваш додаток.
Відкладіть на секунду всі формулювання та розгляньте іншу реальну ситуацію. Скажімо, у вас є ліхтарик, і ви його вмикаєте. Батарея розряджається, що перериває його поточний активний стан. Замініть батарейки та відновіть його роботу. Ліхтарик має знову ввімкнутися у звичайному режимі. Це випадок використання. Дисципліна тестування, яка зосереджується на тому, чи відбувається це, чи ні, називається тестуванням переривань.
Бізнес-кейс простий. Переривання відбувається в найневідповідніший момент — посеред оплати, посеред завантаження, посеред форми — і користувач, який втрачає цю роботу, рідко намагається знову. Збої в резюме, порожні екрани, дублікати транзакцій та втрата введених даних форми — все це дефекти, які виявляє лише переривання, тому вони переживають функціональний пропуск, який ніколи нічого не перериває.
Тип перерв у мобільному додатку
Переривання поділяються на кілька знайомих груп, які зведено на ілюстрації нижче.
Ми всі знайомі з поширеними перебоями, які зазвичай трапляються. Ось деякі з них:
- Низький заряд батареї
- Акумулятор повністю заряджений — під час заряджання
- Вхідний телефонний дзвінок
- Вхідні SMS
- Вхідне сповіщення з іншого мобільного застосунку
- Підключено для зарядки
- Відключено від зарядки
- Пристрій вимкнено
- Нагадування про оновлення програм
- сигнал тривоги
- Втрата з'єднання з мережею
- Відновлення підключення до мережі
Цей список не є вичерпним, але містить найпоширеніші сценарії. Практичний спосіб упорядкування – за походженням: події, залежні від пристрою, такі як заряджання акумулятора, події, ініційовані користувачем, такі як відповідь на дзвінок або перемикання програм, та зовнішні події, такі як втрата сигналу в ліфті чи тунелі.
Роздільна здатність у разі переривання
Очікувана поведінка у разі цих переривань є однією з наступних чотирьох:
- Запуск у фоновому режимі: Переривання бере на себе, поки програма відходить на другий план. Воно отримує контроль після завершення переривання. Наприклад, телефонний дзвінок або дзвінок FaceTime, на який ви звертаєтесь під час читання цифрової книги в iBooks (або подібній програмі). Коли користувач відповідає на дзвінок, iBooks чекає, поки дзвінок завершиться, а потім відновлює його після його завершення.
- Показати сповіщення: Сповіщення зникає, і ви працюєте як завжди. У заголовку з’являється повідомлення «SMS отримано». Користувач не звертає на це уваги та продовжує працювати з додатком як завжди. Інші сповіщення мобільного додатка, такі як новий запит на дружбу у Facebook або повідомлення у WhatsApp, також належать до цієї категорії. Але якщо користувач вирішує прочитати повідомлення, виконується поведінка, описана в пункті 1. Якщо сповіщення ігнорується, стан додатка не змінюється.
- Заклик до дії: Перш ніж продовжити роботу, потрібно вимкнути або відкласти будильники. Те саме стосується повідомлень про оновлення програм. Перш ніж продовжити, потрібно або скасувати, або прийняти зміни. Іншим прикладом є сповіщення про низький заряд батареї — ви можете продовжити як завжди або перейти в режим низького енергоспоживання, якщо пристрій це дозволяє.
- Немає впливу: Прикладом є підключення до мережі, коли ваш пристрій підключається до нього. Також, коли ви підключаєте пристрій для заряджання, не потрібно сповіщати чи закликати до дії. Ймовірно, він виконуватиме свою роботу, поки ви продовжуєте використовувати свою програму.
Таким чином, залежно від переривання, яке ви тестуєте, зрозумійте поведінку та перевірте, чи задовольняє ваш додаток вимоги. Також описана вище поведінка не обов'язково має бути однаковою для всіх додатків та пристроїв. Обов'язково дізнайтеся конкретні деталі для вашого мобільного додатку.
Тестові випадки тестування переривань з очікуваними результатами
Після узгодження очікуваного рішення кожне переривання стає звичайним тестовим випадком із тригером, дією та перевіреним результатом. У таблиці нижче показано, як чотири вищезгадані рішення перетворюються на конкретні сценарії.
| Переривання | Тестовий сценарій | Очікуваний результат |
| Вхідний телефонний дзвінок | Ініціювати виклик, коли форма наполовину заповнена, відповісти на нього, а потім завершити виклик | Програма переходить у фоновий режим і відновлює роботу на тому ж екрані з незмінними введеними даними. |
| Вхідні SMS-повідомлення або push-сповіщення | Надіслати повідомлення під час перегляду відео або завантаження та ігнорувати банер | Банер з'являється та зникає; стан програми не змінюється |
| сигнал тривоги | Дозволити спрацьовування запланованого будильника під час активного сеансу та відхилити його | Сигналізація спочатку вимагає заклику до дії, а потім програма відновлює роботу з того місця, де зупинилася |
| Попередження про низький заряд акумулятора | Розрядити пристрій до порогу попередження під час транзакції | Попередження відображається, транзакцію не скасовано, а режим низького енергоспоживання не порушує роботу екрана. |
| Втрата з'єднання з мережею | Вимкнути підключення під час запиту, а потім відновити його | Відображається чітке повідомлення, збій не відбувається, а запит безпечно завершується або завершується невдачею під час відновлення. |
| Зарядка підключена або відключена | Підключення та відключення зарядного пристрою під час активного сеансу | Без впливу — програма продовжує працювати без видимих змін |
| Нагадування про оновлення програми | Викликати запит на оновлення під час використання програми | Користувач може скасувати або прийняти, і нижній екран зберігається в будь-якому випадку. |
Залишайте один рядок на кожне переривання для кожного критичного екрана, а не один рядок на переривання для всієї програми. Екран оплати, екран входу та довга форма дають різні збої, і один загальний випадок приховує це.
Тепер, коли ми зрозуміли, що таке тестування переривань і що потрібно перевіряти при його проведенні, настав час поговорити про те, як це зробити.
Як виконати тестування переривань
Подивіться на цю заяву: iBooks має працювати у фоновому режимі, коли користувач отримує вхідний телефонний дзвінок.
Хіба ви не назвали б це функціональною вимогою програми iBooks? Я точно так би сказав.
Отже, тестування переривань є підмножиною Функціональне тестування для мобільного застосунку. Для проведення тестування переривань ви використовуєте ті самі рамки та інструменти для тестування мобільних застосунків. Тестери мають навички продумувати ці сценарії. Після цього ви розробляєте тестові випадки та виконуєте їх точно так само, як і будь-який інший тест.
На практиці послідовність коротка та повторювана:
- Перелічіть критичні шляхи користувача — вхід, оплата, завантаження, довгі форми, відтворення медіа.
- Відобразіть кожну ймовірну перешкоду зі списку вище на кожній подорожі.
- Узгодьте очікувану роздільну здатність для кожного сполучення з власником продукту, оскільки універсального значення за замовчуванням не існує.
- Переривайте роботу в найнебезпечніший момент, а не в момент простою, а потім продовжуйте.
- Перевірити стан, дані, сеанс та пам'ять після відновлення, а не лише те, що програма все ще відкрита.
Для отримання додаткової інформації про ширшу дисципліну див. Мобільне тестування навчальний посібник та зразки випадків у Тестування мобільних додатків.
Інструменти та методи для моделювання переривань
Вищезазначені сценарії мають створюватися на вимогу, а не чекати, і кожна платформа надає спосіб зробити це.
- Android Розширені елементи керування емулятора: Бічна панель емулятора імітує вхідний дзвінок, SMS, рівень заряду батареї та стан зарядного пристрою, а також силу стільникового сигналу, тому більшість переривань можна викликати без використання другої трубки.
- Симулятор iOS та Xcode: Стан підключення та обладнання можна змінювати за допомогою симулятора та налаштувань пристрою, тоді як парний фізичний пристрій охоплює сценарії викликів, які симулятор не може викликати.
- Другий фізичний пристрій: Дзвінок або надсилання повідомлення на тестований пристрій з іншого телефону залишається найточнішим способом відтворення реального переривання, особливо у випадках, чутливих до часу.
- Налаштування пристрою: Режим польоту, перемикачі Wi-Fi, режим «Не турбувати», режим економії заряду батареї та заплановані будильники охоплюють перебої з’єднання та живлення на реальному обладнанні.
- Структури автоматизації: Той самий стек автоматизації, який використовується для решти вашого функціонального пакету, може керувати застосунком до та після переривання, тому перевірка резюме здійснюється ствердно, а не на око.
- Хмари реальних пристроїв: Ферма розміщених пристроїв розширює охоплення різних виробників та версій ОС, що важливо, оскільки обробка переривань є однією з областей, де налаштування постачальників найбільше розходяться.
Яким би не був механізм, запишіть точний момент переривання в тестовому випадку. «Переривання під час завантаження» та «Переривання після завантаження» – це різні тести з різними режимами відмови.
Найкращі практики тестування переривань
Кілька звичок відрізняють корисний набір переривань від вправи з галочками в блоці.
- Перебивайте в найневідповідніший момент: Target у момент фіксації транзакції або запису файлу, оскільки саме в цьому випадку стан є найбільш крихким.
- Перевірте резюме, а не те, що вас перебиває: Дефект майже завжди з'являється після повернення керування, тому твердження належать до відновленого екрану.
- Охопіть обидва напрямки змін у мережі: Втрата з'єднання та його відновлення – це окремі випадки, і другий пропускається частіше.
- Змінюйте тривалість: Двосекундне сповіщення та десятихвилинний дзвінок пропускають програму через різні життєві цикли, включаючи видалення з пам'яті.
- Розподіл між версіями ОС та низькоякісним обладнанням: Фонове видалення набагато агресивніше на пристроях з обмеженнями, що виявляє недоліки, які приховує флагманський телефон.
- Автоматизуйте повторювані дії: Перебої з підключенням та перебої з батареєю повністю автоматизовані, звільняючи ручну роботу для викликів та будильників.
- Спостерігайте за використанням ресурсів, а також зазначайте: Переривання, яке призводить до витоку пам'яті або розрядки батареї під час відновлення, є дефектом, навіть якщо екран виглядає правильно, що пов'язує цю роботу з тестування продуктивності мобільного додатку.
Хіба тестування переривання не те саме, що тестування відновлення?
Ні, це не. Тестування відновлення підтверджує відновлення після збою. Переривання не обов'язково є збоєм — це простоtrac.
Це як різниця між комою та крапкою в англійській мові. Різниця лише технічна, але картина зрозуміла. Тестування відновлення запитує, чи може програма відновитися після того, як щось зламалося; тестування переривань запитує, чи щось взагалі зламається, коли щось інше виходить на передній план.
Ось що потрібно знати, щоб розпочати роботу з тестуванням переривань — важливою та інтуїтивно зрозумілою галуззю тестування мобільних застосунків.
