post

Все, кто работает и не работает с мобильными приложениями, знает, что проверка реакции приложения на потерю интернета, на входящий звонок и т.п. безумно важна. То, как мы проводим, поиск ошибок, связанных с подобными тестами, я расскажу в статье.

Терминология

Беседуя с коллегами, я выяснила, что существует довольно много вариантов того, как называть подобные тесты. Некоторые из вариантов:

  • Тестирование стабильности
  • Тестирование осстановления (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, пользователю выдается соответствующее сообщение и он сможет продолжить работу с приложением.

Итоговые рекомендации по составлению матрицы стресс-тестов

  1. Составьте список стрессовых ситуаций
  2. Выучите их. Вы не сможете выделить важные операции в приложении, если не знаете, какие стрессовые ситуации с ними могут случиться.
  3. Выделите в своем приложении самые важные операции. Если сложно, то вначале особый акцент можно сделать просто на операциях работы с интернетом, длительных операциях (больше 2х секунд – это длительная для мобильного), «фоновых» (например, проигрывание музыки).
  4. Составьте таблицу и отметьте какие операции приложения с какими стрессовыми ситуациями нужно скрестить.
  5. Где возможно, опишите ожидаемые результаты.
  6. Проведите тесты. И там, где невозможно было заполнить ожидаемый результат, заполните.
  7. Не забывайте обновлять. Матрица стресс-тестов требует обновления, когда изменяется старая логика приложения или добавляется новый функционал.

Список идей со стрессовыми ситуациями, разобранный пример и шаблон нашей матрицы можно скачать по ссылке.

Проверка влияния внешних событий на работу мобильного приложения from Vlad Orlikov on Vimeo.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Можно использовать следующие HTML-теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>