Все, кто работает и не работает с мобильными приложениями, знает, что проверка реакции приложения на потерю интернета, на входящий звонок и т.п. безумно важна. То, как мы проводим, поиск ошибок, связанных с подобными тестами, я расскажу в статье.
Терминология
Беседуя с коллегами, я выяснила, что существует довольно много вариантов того, как называть подобные тесты. Некоторые из вариантов:
- Тестирование стабильности
- Тестирование восстановления (recovery testing или restoration testing)
- Проверка помех (interruption testing)
- Fragmentation overlay testing
- Стресс-тестирование (stress testing)
- Проверка мобильных функций (мобильное тестирование)
Самые популярные – это interruption testing и stress testing. Возможно, вы используете какой-то ещё термин. Я и мои коллеги используют термин «стресс-тесты». Поэтому буду использовать в статье именно его.
Примеры багов.
Чтобы лучше понять сами тесты, посмотрите на примеры нескольких реальных багов, с которыми я сталкивалась при работе с iOS устройствами:
- Приложение – загрузчик файлов на Dropbox. Идет загрузка файлов. Когда пропадает интернет, приложение крешится.
- Приложение – музыкальный плеер. Играет музыка, осуществляется входящий звонок. После его завершения музыка должна продолжится, а она не продолжается.
- Любое приложение. После прихода memory warning пропадает с экрана кнопка (не отрисовывается) или весь экран просто становится чёрным.
- Приложение-игра. Пропадает и не восстанавливается до перезапуска приложения соединение с игровым сервером, если во время игры, которая требует интернет, тип соединения меняется с Wi-Fi на 3g,
Матрица стресс-тестов.
В качестве примера для статьи я буду использовать маленькое приложение, которое позволяет сначала скачать файлы из интернета и затем сохранить (отправить) их на Dropbox. На скриншотах представлен интерфейс взаимодействия с Dropbox.
В мобильном тестировании проверка реакции на стрессовую ситуацию (стресс-тест) чаще всего представляется как анализ двух событий, произошедших в один момент времени. При этом одно событие – это выполнение приложением своей обычной логики (идёт процесс загрузки файла на Dropbox), а второе событие – это некие внешние обстоятельства (пропал интернет).
Соответственно, стресс тесты для приложения можно представить в виде таблицы (матрицы), в которой одна сторона – это особые стрессовые ситуации, которые могут повлиять на приложение, а другая сторона – это особо важные операции внутри приложения, которые должны правильно реагировать на стрессовые ситуации.
Общий шаблон подобной матрицы можно представить в таком виде.
| Стрессовое событие 1 | Стрессовое событие 2 | Стрессовое событие 3 | ||
| Важная операция1 внутри приложения до стрессовой ситуации | Ожидаемый результат после стрессовых событий | Y | N | N |
| Операция2 внутри приложения | Ожидаемый результат после стрессового события | N | Y | Y |
| Состояние1 приложения | Ожидаемый результат после стрессовых событий | N | N | Y |
В этой матрице:
- Y – обозначает необходимость проводить тест (yes).
- N – обозначает, что тест не имеет смысла (no).
Перед тем как мы пришли к такой матрице, необходимо было пройти несколько шагов.
Шаг 1. Стрессовые ситуации.
Первое, что мы сделали в команде это провели брейншторм по поводу всех возможных стрессовых ситуаций, которые могут случиться с нашим приложением. Этот набор довольно-таки конечный список для определённого проекта/группы проектов/фирмы. Новые идеи возникают довольно редко. Но когда возникают мы, естественно, добавляем её в общий список.
В общий список были включены работа с интернетом (потеря, смена типа соединения, смена точки соединения), с памятью (физической и оперативной), функции мобильной связи (входящий звонок) и другие.
Тот список, что получился у нас можно скачать по ссылке представленной в конце статьи.
Следует обратить внимание:
- Некоторые из идей могут не подходить под какой-то проект.
- Для некоторых приложений некоторые из ситуации будут являться не стрессовыми, а частью бизнес-логики приложения.
- Некоторые из идей будут очень приоритетны в одном проекте и менее приоритетны в другом.
- Некоторые ситуации могут казаться дублирующимися, но т.к. у нас нет 100%-ного подтверждения, мы их держим в списке.
- Существуют множество комплексных стрессовых ситуаций (сначала зазвонил будильник, потом зазвонил телефон). И мы, осознавая риск пропуска ошибки, эти комплексные ситуации рассматриваем крайне редко (только для критически важного для бизнеса функционала). В матрице подобных тестов у нас на данный момент нет.
Шаг 2. Ситуация приложения на момент стрессовой ситуации.
По моему опыту, новичку вначале тяжело выделить все ситуации внутри приложения, которые нужно проверить. Поэтому совет начинать с самых простых и приоритетных – длительные операции, фоновые операции и работа с интернетом. Дальше обратите внимание на каждое атомарное действие пользователя и каждое из возможных состояний приложения. Вероятно ситуаций будет либо очень много, либо очень мало. Экспериментируйте, анализируйте, что может быть лишним, выставляйте приоритеты. В последствии по мере роста опыта и знаний об особенностях работы приложения вы список расширите или, наоборот, сузите.
При формулировке операции желательно использовать настоящее время и указывать то, что видит или делает пользователь (или что делает система) максимально чётко. Например, формулировка «Пользователь отправляет файл на Dropbox” для стресс-тестов двусмысленна. В одном варианте понимания пользователь может только нажимать на кнопку «Отправить», а в другом может находится уже в состоянии процесса отправки и наблюдает за бегущим progress bar. Это две ситуации, которые стоит рассматривать раздельно.
Вот несколько операций и состояний нашего приложения, на которые я обратила внимание при разработке примера:
- Пользователь нажимает на кнопку «Отправить»
- Пользователь случайно нажал на кнопку «Снять выделение» во время нажатия на «Отправить» (multi touch)
- Идёт процесс загрузки на Dropbox
- Пользователь отменяет загрузку файлов на Dropbox
- Открыт таб «Файлы» с выделенными файлами
- Пользователь нажимает на таб «Плейлисты»
- Пользователь случайно нажал на таб «Плейлисты» во время отмечания файлов, которые нужно загрузить (multi touch)
Все выявленные важные для проверки состояния приложения записываем в общую матрицу тестов.
Шаг 3. Необходимость теста.
Имея список стресс тестов и состояний приложения остаётся их скрестить – на пересечении строки и колонки проставить актуальность (необходимость) теста. На этом этапе важно и не пропустить важный тест, и не переборщить слишком большим количеством возможно бесполезных тестов.
Вечный вопрос тестировщика «А вдруг?? А вдруг именно вот в этом случае что-то случится» при составлении матрицы прямо как нож к горлу. J Здесь могут помочь приоритеты, анализ рисков, анализ наиболее важных модулей приложения.
Особенно осторожным рекомендую быть с мультитачами. В примере выше я обратила внимание на одновременное нажатие двух рядом стоящих элементов интерфейса. Но ведь можно проверить и одновременное нажатие на «Отправить» и «Плейлисты» (не рядом стоящие элементы), можно устроить нажатие сразу в три или четыре места. Но тут появляется вопрос – зачем? Вы всегда должны осознавать какой смысл у таких тестов. Из моей практики мультитачи приносят очень много крэшей. И тестировщики (начинающие в первую очередь), естественно, любят когда они находят факт подобных поломок. Но проблема в том, что большинство их таких ситуаций может не случиться у пользователя. К тому же, такие баги, может быть, будет сложно исправить. И, естественно, что многие из таких бессмысленных багов отклоняются. Повторюсь, важно осознавать зачем вы проводите такие тесты и несут ли они смысл. Например, мультитачи пятью или даже десятью пальцами уместны в программах для рисования, особенно если они созданы для детей (это же любимое дело «полапать» везде, где можно, всеми пальчиками! J), в программах иммитирующих музыкальный инструмент, в играх. В приложениях-утилитах чаще всего достаточно 1-2 пальцев и анализ рядом стоящих элементов интерфейса.
Шаг 4. Ожидаемый результат.
Вначале большинство стресс тестов проводились как исследование с целью выяснить, а как же приложение себя ведёт, Ожидаемый результат был не очевиден. Поэтому он записывался уже в процессе прохождения тестов (по сути, чтобы не забыть как же приложение себя ведет). Если возникали вопросы, то мы шли к PM, аналитикам, программистам, читали гайдлайны. После чего делали выводы, записывали баги и ожидаемый результат в матрицу. Когда накопился опыт, ожидаемый результат можно было уже предсказывать. Но все равно не 100%-но во всех случаях.
Сейчас ожидаемый результат записывается тезисно, без подробностей, с целью запомнить это поведение на будущее. Самый очевидный ожидаемый результат не записывает. Например, ожидаемые результаты для мультитачей или ситуаций, когда нет интернета, можем и не записывать, т.к для нас очевидно, что приложение не должно крешится, а пользователю должно быть выдано сообщение о том, что интернет отсутствует.
Итого, после 4х шагов у нас есть матрица.
Частота проведения тестирования.
В нашей команде существует правило, что любой новый функционал необходимо рассматривать со стороны всех видов тестирования. В том числе, со стороны стресс-тестов. В этот же момент и должна обновляться матрица тестов.
Большинство тестов из нашей матрицы проводились 1 раз и больше не повторялись. Они либо для менее приоритетного функционала, либо слишком мала вероятность того, что изменится поведение и что-то сломается. Тем не менее, общее правило проходить повторно стресс-тесты хотя бы раз в полгода-год, существует. И некоторые команды, когда есть свободное время, их повторяют.
Но некоторые тесты, которые отвечают за суперважный для нас функционал, мы включаем в чеклист для приёмочного (acceptance) тестирования.
Пример такого теста для нашего маленького приложения это убедиться, что если пропадает интернет во время загрузки файлов на Dropbox, пользователю выдается соответствующее сообщение и он сможет продолжить работу с приложением.
Итоговые рекомендации по составлению матрицы стресс-тестов
- Составьте список стрессовых ситуаций
- Выучите их. Вы не сможете выделить важные операции в приложении, если не знаете, какие стрессовые ситуации с ними могут случиться.
- Выделите в своем приложении самые важные операции. Если сложно, то вначале особый акцент можно сделать просто на операциях работы с интернетом, длительных операциях (больше 2х секунд – это длительная для мобильного), «фоновых» (например, проигрывание музыки).
- Составьте таблицу и отметьте какие операции приложения с какими стрессовыми ситуациями нужно скрестить.
- Где возможно, опишите ожидаемые результаты.
- Проведите тесты. И там, где невозможно было заполнить ожидаемый результат, заполните.
- Не забывайте обновлять. Матрица стресс-тестов требует обновления, когда изменяется старая логика приложения или добавляется новый функционал.
Список идей со стрессовыми ситуациями, разобранный пример и шаблон нашей матрицы можно скачать по ссылке.
Проверка влияния внешних событий на работу мобильного приложения from Vlad Orlikov on Vimeo.