тестирование мобильных приложений это
Тестирование мобильных приложений — в чем особенность?
Всем привет! Меня зовут Ксюша, и я тестирую мобильные приложения в компании ATI.SU
Я искренне люблю мобильное тестирование, и в этой статье расскажу, что нужно знать, если вы решили погрузиться в эту область. Сделаю акцент на андроид, однако для ios большинство тезисов также применимы.
Начнем с девайсов
У ваших пользователей есть целый зоопарк устройств. Это могут быть планшеты и телефоны от различных производителей с разными версиями Андроида, разрешениями экрана, диагональю, прошивками и другими характеристиками. На Хабре есть хорошая статья про фрагментацию устройств на Андроид.
Как же учесть это, ведь невозможно протестировать приложение на всех вариантах устройств? Стоит выбирать наиболее популярные среди ваших пользователей девайсы, а еще тестировать на самой старой и самой новой из поддерживаемых ОС. Также важно проверять приложение девайсах с сильно кастомизированными прошивками. Например, xiaomi, huawei, samsung.
Перейдем к ui и ux
Для каждой из платформ существуют гайдлайны: Google Material Design для Android и Human Interface Guidlines для ios. В гайдлайнах описаны элементы интерфейса, их размеры, расположение на экране и не только. Гайдлайны нужны, чтобы создавать такой дизайн, который позволит пользователю не думать над простыми действиями. Например, над навигацией или выбором элементов. А еще гайдлайны пригодятся, чтобы один и тот же дизайн был одинаково функционален на разных девайсах и разных версиях платформы. Хорошее приложение должно следовать гайдлайнам, а тестировщик проверить это.
Кроме требований гайдлайнов, важно тестировать то, как пользователь взаимодействует с девайсом. Он может изменить размер шрифта, повернуть экран в ландшафтную ориентацию или свернуть приложение.
Рассмотрим разрешения
У каждого приложения на платформе Андроид есть список разрешений (permissions). Например, разрешения на доступ к файловой системе, местоположению или камере. В зависимости от функционала, приложение запрашивает их у системы. Для успешного тестирования стоит выяснить, при каких действиях приложение запрашивает разрешения, и протестировать эти действия с выданными разрешениями и без них.
Потестируем запросы
Обновим приложение
У приложения на Андроид есть своя база данных, которая хранится прямо на устройстве. Добавляя новые фичи, разработчик меняет и базу: удаляет, изменяет, добавляет поля и таблицы. Чтобы протестировать это, обновим приложение до версии, в которой база изменена. После обновления нужно проверить тот функционал, который был затронут при разработке.
Используем функции девайса
Кроме вашего приложения, пользователь совершает очень много действий на девайсе. Как отреагирует приложение, если пользователь изменит часовой пояс, дату или время? А если девайс перезагрузят? А если сеть станет не доступна на несколько минут, или пользователь переключится с wi-fi на мобильную сеть? Казалось бы, это внешний функционал операционной системы, но он напрямую влияет на работу приложения. Протестируем поведение приложение в перечисленных условиях.
Давайте зарелизим
Если вы тестировали веб-приложения, то наверное знаете, что можно в любой момент выложить изменения в продакшн, используя пару нехитрых команд git. И буквально в считанные секунды ваши пользователи получат новый функционал. У мобильных приложений такие быстрые релизы невозможны.
Когда билд готов к релизу, его загружают в Play Market или App Store. Там приложение проходит ревью и становится доступным для скачивания. Однако пользователи получат новый релиз только когда обновятся. А это процесс не быстрый. У большинства пользователей может быть отключено автообновление, и они могут месяцами откладывать обновление вручную.
К счастью, в вашем приложении может присутствовать механизм принудительного обновления. Это может быть экран с просьбой обновиться и кнопкой или баннер с предупреждением. Все зависит от фантазии команды разработки.
Подытожим
Мобильные девайсы и платформы часто обновляются, Google меняет требования к разработке, а рынок мобильных приложений растет. Именно поэтому тестировать мобильные приложения всегда интересно!
Я описала лишь основные направления тестирования мобильных приложений. По каждому из них можно написать несколько более подробных статей, но я надеюсь, что мир мобильных приложений теперь стал для вас немного приветливей!
Процесс тестирования мобильных приложений
Тестирование – очень важный этап разработки мобильных приложений.
Стоимость ошибки в релизе мобильного приложения высока. Приложения попадают в Google Play в течении нескольких часов, в Appstore несколько недель. Неизвестно сколько времени будут обновляться пользователи. Ошибки вызывают бурную негативную реакцию, пользователи оставляют низкие оценки и истерические отзывы. Новые пользователи, видя это, не устанавливают приложение.
Мобильное тестирование сложный процесс: десятки различных разрешений экрана, аппаратные отличия, несколько версий операционных систем, разные типы подключения к интернету, внезапные обрывы связи.
Поэтому в отделе тестирования у нас работает 8 человек (0,5 тестировщика на программиста), за его развитием и процессами следит выделенный тест-лид.
Под катом я расскажу как мы тестируем мобильные приложения.
Тестирование требований
Тестирование начинается до разработки. Отдел дизайна передает тестировщикам навигационную схему и макеты экранов, менеджер проекта – требования невидимые на дизайне. Если дизайн предоставляет заказчик, макеты до передачи в отдел тестирования проверяются нашими дизайнерами.
Тестировщик анализирует требования на полноту и противоречивость. В каждом проекте исходные требования содержат противоречивую информацию. Мы их решаем еще до начала разработки. Так же в каждом проекте требования неполны: не хватает макетов второстепенных экранов, ограничений на поля ввода, отображения ошибок, кнопки никуда не ведут. Неочевидны невидимые на макетах вещи: анимации, кеширование картинок и содержимого экранов, работа в нестандартных ситуациях.
Недостатки требований обсуждаются с менеджером проекта, разработчиками и дизайнерами. После 2-3 итераций, вся команда гораздо лучше понимает проект, вспоминает забытый функционал, фиксирует решения по спорным вопросам.
В основном на этом этапе используется basecamp.
Когда требования стали полны и непротиворечивы, тестировщик составляет smoke-тесты и функциональные тесты, покрывающие исходные данные. Тесты деляется на общие и специфические для разных платформ. Для хранения и прогона тестов мы используем Sitechсo.
Например, для проекта Trava на этом этапе было написано 1856 тестов.
Первый шаг тестирования закончен. Проект уходит в разработку.
Билд-сервер
Все наши проекты собираются на TeamCity билд-сервере.
Если менеджер проекта поставит галочку «для тестирования», тестировщикам уходит письмо о новой сборке для тестирования. Ее номер отображается на мониторе в кабинете тестировщиков. Красным отображаются билды выпущенные за последние сутки, их нужно тестировать активнее, чем белые.
Без «волшебного монитора» (кстати, работает на андроиде) часто тестировали старые билды. А новый билд с багами попадал заказчику. Теперь перед прогоном тест-кейсов достаточно взглянуть на монитор, путаница разрешилась.
Тестирование билдов бывает быстрое и полное.
Быстрое тестирование
Быстрое тестирование проводится после завершения итерации разработки, если сборка не пойдет в релиз.
Для начала проводятся smoke-тесты, чтобы понять имеет ли смысл тестировать сборку.
Затем берутся все выполненные задачи и пофикшенные баги за итерацию из Jira и скурпулезно проверяется соответствие результата описанию таска. Если задача включала в себя новые элементы интерфейса, она отправляется дизайнерам для сверки с макетами.
Некорректно выполненные задачи переоткрываются. Баги заносятся в Jira. К не UI багам обязательно прикладываются логи со смартфона. К UI багам скриншоты с пометками что не так.
После этого выполняются функциональные тесты этой итерации. Если были найдены баги не покрытые тест-кейсами, создается новый тест-кейс.
Для андроид приложений запускаются monkey тесты.
По окончании тестирования ставится галочка «тестирование багов пройдено» в билд-сервере (да, название галочки не очень правильное :).
Если в процессе тестирования не было найдено blocker, critical и major багов, ставится галочка «можно показывать заказчику». Ни один билд не отсылается заказчику без одобрения отдела тестирования. (По согласованию с заказчиком иногда высылаются билды с major багами).
Критичность бага определяется по таблице.
После завершения тестирования PM получает подробное письмо-отчет.
Полное тестирование
Полное тестирование проводится перед релизом. Включает себя в себя быстрое тестирование, регресионное тестирование, monkey-тестирование на 100 устройствах и тестирование обновлений.
Регрессионное тестирование подразумевает прогон ВСЕХ тест-кейсов по проекту. Тест-кейсов не только за последнюю итерацию, но и за все предыдущие и общие тест кейсы по требованиям. Это занимает день-три на одно устройство в зависимости от проекта.
Очень важный шаг — тестирование обновлений. Почти все приложения хранят данные локально (даже если это кука логина) и важно удостовериться, что после обновления приложения все данные пользователя сохранятся. Тестировщик скачивает билд из маркета, создает сохраняемые данные (логин, плейлисты, транзации учета финансов), обновляет приложение на тестовую сборку и проверяет, что все на месте. Затем прогоняет smoke-тест. Процесс повторяется на 2-3 устройствах.
Разработчики часто забывают о миграции данных со старых версий и тестирование обновлений позволило нам выявить множество критических ошибок с падениями, удалением пользовательских данных о покупках. Это спасло не одно приложение от гневных отзывов и потери аудитории.
Релизный monkey-тест мы проводим на 10 iOS и 80 Android устройствах при помощи сервиса Appthwack.
В конце полного тестирования, кроме письма, вручную составляется подробный отчет.
Сборка уходит в релиз только при 100% прохождении всех тест-кейсов.
Тестирование внешних сервисов
Тестировать интеграцию с Google Analytics, Flurry или системой статистики заказчика непросто. Бывало, что в релиз уходили сборки с нерабочим Google Analytics и никто не обращал на это внимания.
Поэтому в обязательно порядке для внешних сервисов создается тестовый аккаунт и он проверяется при полном тестировании. Кроме того отправка статистики фиксируется в логах, которые проверяются тестировщиками. При релизе тестовый аккаунт подменяется боевым.
Учет времени
Учет времени тестировщиков производится в отдельном Jira проекте. На составление тест-кейсов, прогон тестов, написание отчетов по проекту заводится отдельная задача и стандартными средствами в ней отмечается затраченное время.
UPD: а расскажите как устроено тестирование у вас, хотя бы сколько тестировщиков на разработчика
Подписывайтесь на наш хабра-блог. Каждый четверг полезные статьи о мобильной разработке, маркетинге и бизнесе мобильной студии.
Чек-лист тестирования мобильных приложений
У многих начинающих специалистов в области тестирования возникает вопрос: «А как же протестировать мобильное приложение. С чего начать, какие проверки стоит осуществить?» Данный вопрос актуален, когда они приходят в компанию, где нет документации на проекте, либо это только что появившийся стартап. Чтобы ответить на эти вопросы была подготовлена универсальная шпаргалка, которую можно использовать при тестировании практически любого приложения.
В данный чек-лист вошли только общие характеристики. Естественно, в тестируемом приложении может быть функциональность, для которой нужно применять отдельный подход и создать отдельные сценарии. То же самое верно для производительности, удобства использования, безопасности и прочего тестирования, которое необходимо вашему приложению.
Чек-лист для тестирования мобильных приложений состоит из восьми разделов:
Функциональное тестирование
В данном пункте нам важно убедиться, что наш продукт соответствует нужной функциональной спецификации, упомянутой в документации по разработке.
Что проверяем?
1. Установка/удаление/накатка версий
2. Запуск приложения (отображение Splash Screen)
3. Работоспособность основного функционала приложения
3.1 Авторизация (по номеру телефона/через соц. сети/e-mail)
3.2 Регистрация (по номеру телефона/через соц. сети/e-mail)
3.3 Онбординг новых пользователей
3.4 Валидация обязательных полей
3.5 Навигация между разделами приложения
3.6 Редактирование данных в профиле пользователя
3.7 Проверка оплаты
3.8 Тестирование фильтров
3.9 Бонусы
4. Корректное отображение ошибок
5. Работа с файлами (отправка/получение/просмотр)
6. Тестирование тайм-аутов
7. Тестирование заглушек (не соединения с интернетом/нет, например, товаров и т.д)
8. Тестирование pop-up, алертов
9. Тестирование WebView
10. Скролл/свайп элементов
11. Тестирование PUSH уведомлений
12. Сворачивание/разворачивание приложения
13. Разные типы подключений (сотовая связь/Wi-Fi)
14. Ориентация экрана (альбомная/портретная)
15. Темная/светлая темы
16. Реклама в приложении
17. Шаринг контента в соц. сети
18. Работа приложения в фоне
19. Пагинация страниц
20. Политики конфиденциальности и прочие ссылки на документы
Тестирование совместимости
Тестирование совместимости используется, чтобы убедиться, что ваше приложение совместимо с другими версиями ОС, различными оболочками и сторонними сервисами, а также аппаратным обеспечением устройства.
Что проверяем?
1. Корректное отображение гео
2. Информации об операциях (чеки и т.д.)
3. Различные способы оплаты (Google Pay, Apple Pay)
4. Тестирование датчиков (освещенности, температуры устройства, гироскоп и т.д.)
5. Тестирование прерываний (входящий звонок/смс/push/будильник/режим «Не беспокоить» и т.д.)
6. Подключение внешних устройств (карта памяти/наушники и т.д.)
Тестирование безопасности
Данная проверка нацелена на поиск недостатков и пробелов с точки зрения безопасности приложения.
Что проверяем?
1. Тестирование разрешений (доступ к камере/микрофону/галерее/и т.д.)
2. Данные пользователя (пароли) не передаются в открытом виде
3. В полях, с вводом пароля и подтверждением пароля, данные скрываются астерисками
Тестирование локализации и глобализации
Тестирование интернационализации/глобализации приложения включает тестирование приложения для различных местоположений, форматов дат, чисел и валют, а также замену фактических строк псевдостроками. Тестирование локализации включает тестирование приложения с локализованными строками, изображениями и рабочими процессами для определенного региона.
Что проверяем?
1. Все элементы в приложении переведены на соответствующий язык
2. Тексты зашиты внутри приложения и пользователь в настройках приложения может выставить необходимый язык
3. Тексты зависят от языка в системных настройках
4. Тексты приходят с сервера
5. Корректное отображение форматов дат (ГОД — МЕСЯЦ — ДЕНЬ или ДЕНЬ — МЕСЯЦ — ГОД.)
6. Корректное отображение времени в зависимости от часового пояса
Тестирование удобства использования
Тестирование удобства использования помогает удостовериться в простоте и эффективности использования продукта пользователем, с целью достижения поставленных целей. Иными словами, это не что иное, как тестирование дружелюбности приложения для пользователя.
Что проверяем?
1. Корректное отображение элементов на устройствах с различными разрешениями экранов
2. Все шрифты соответствуют требованиям
3. Все тексты правильно выровнены
4. Все сообщения об ошибках верные, без орфографических и грамматических ошибок
5. Корректные заголовки экранов
6. В поисковых строках присутствуют плейсхолдеры
7. Неактивные элементы отображаются серым
8. Ссылки на документы ведут на соответствующий раздел на сайте
9. Анимация между переходами
10. Корректный возврат на предыдущий экран
11. Поддерживаются основные жесты при работе с сенсорными экранами (swipe back и т.д.)
12. Пиксель-перфект
Стрессовое тестирование
Стрессовое тестирование направлено на определение эффективности производительности приложения в условиях повышенной нагрузки. Стресс-тест в этом контексте ориентирован только на мобильные устройства.
Что проверяем?
1. Высокая загрузка центрального процессора
2. Нехватка памяти
3. Загрузка батареи
4. Отказы
5. Низкая пропускная способность сети
6. Большое количество взаимодействий пользователя с приложением (для этого может понадобиться имитация реальных условий состояния сети)
Кросс-платформенное тестирование
Важный вид тестирования, который необходимо проводить для понимания того, будет ли должным образом отображаться тестируемый продукт на различных платформах, используемых целевой аудиторией.
Что проверяем?
— Работоспособность приложения на различных устройствах разных производителей
Тестирование производительности
Если пользователь устанавливает приложение, и оно не отображается достаточно быстро (например, в течение трех секунд), оно может быть удалено в пользу другого приложения. Аспекты потребления времени и ресурсов являются важными факторами успеха для приложения, и для измерения этих аспектов проводится тестирование производительности.
Что проверяем?
1. Время загрузки приложения
2. Обработка запросов
3. Кэширование данных
4. Потребление ресурсов приложением (например расход заряда батареи)
Тестирование мобильных приложений это
Данная статья будет полезна всем, кто вовлечен в процесс разработки как со стороны агентства, так и со стороны клиента: менеджерам, проектировщикам, разработчикам, тестировщикам. В ней рассматриваются основные особенности тестирования мобильных приложений. В своих комментариях я более подробно раскрою нюансы по каждом типу тестирования, а также приведу несколько примеров использования.
Вам подойдет один из представленных ниже типов в зависимости от того, какую цель вы преследуете:
Функциональное тестирование
Функциональное тестирование мобильных приложений обычно охватывает тестирование взаимодействия с пользователем, а также тестирование транзакций. Важные для этого вида тестирования факторы:
Тип приложения, определяемый его бизнес-функциональностью (банкинг, игровая индустрия, социальные сети, образование).
Целевая аудитория (пользователь, компания, образовательная среда).
Канал, по которому распространяется приложение (например, App Store, Google Play или раздача напрямую).
Говоря простым языком, мы проверяем, выполняет ли приложение ожидаемые функции, которые обычно описаны в спецификации или продиктованы бизнес-процессами.
Поэтому функциональное тестирование может проводиться на основе требований. В этом случае формируются тестовые случаи (Test cases), для их создания используется техническое задание на основе бизнес-процессов. После этого создают, так называемые случаи использования (Use cases). Они описывают сценарии ежедневного или постоянного использования приложения.
Основные сценарии функциональных тестов:
Проверить корректность работы обязательных полей.
Убедиться, что обязательные поля отображаются на экране не так, как необязательные.
Убедиться, что работа приложения во время запуска/выхода удовлетворяет основным требованиям.
Убедиться, что приложение переходит в фоновый режим в случае входящего звонка. Для этого вам понадобится еще один телефон.
Проверить, может ли телефон хранить, принимать и отправлять SMS-сообщения во время работы приложения. Для этого вам понадобится другой телефон, с которого можно отправить сообщение на тестируемое устройство с уже запущенным приложением.
Убедиться, что устройство работает в многозадачном режиме, когда это необходимо.
Проверить, как функционируют необходимые опции для работы с социальными сетями — Поделиться, Публикация, Навигация.
Убедиться, что приложение поддерживает платежные операции через системы оплаты Visa, Mastercard, Paypal и др.
Проверить адекватность работы сценариев прокрутки страницы.
Проверить, присутствует ли надлежащая навигация между важными модулями приложения.
Убедиться, что количество ошибок округления минимально.
Проверить наличие сообщений об ошибках, например, сообщения «Ошибка сети. Пожалуйста, попробуйте позже» в случае некорректной работы сети.
Убедиться, что установленное приложение не препятствует нормальной работе других приложений и не съедает их память.
Проверить, способно ли приложение вернуться в то состояние, в котором оно находилось перед приостановкой (например, жесткая перезагрузка или системный сбой).
Установка приложения должна проходить без значительных ошибок при условии, что устройство соответствует системным требованиям.
Убедиться, что автоматический запуск приложения работает корректно.
Проверить, как приложение работает на всех устройствах поколений 2G, 3G и 4G.
Выполнить регрессивное тестирование для выявления новых программных ошибок в существующих и уже модифицированных областях системы. Дополнительное проведение всех предыдущих тестов для проверки поведения программы после изменений.
Убедиться, что существует доступное руководство пользователя.
Часто система обладает большим количеством функций, и не всегда есть возможность проверить их все. Поэтому перед началом функционального тестирования обычно приоритезируют те или иные тест-кейсы и юз-кейсы, в соответствии с расставленными приоритетами распределяют время и затем уделяют внимание наиболее важным. Выделить какие-то стандартные сценарии для функциональных тестов довольно сложно из-за разнообразия приложений, но можно выделить часто встречающиеся модули, составить для них тест-кейсы и в дальнейшем использовать их, модифицируя под конкретные требования.
Для каждой функции необходимо проверять как позитивные сценарии, так и негативные. Сценарий считается позитивным, если в итоге пользователь достигает своей цели (создает item, отправляет сообщение и т.д.). Негативный, соответственно, наоборот — на каком-то из шагов происходит ошибка, и цель не может быть достигнута.
К примеру, рассмотрим логин/логаут и создание контакта (раздела, пользователя, или любого другого item). Стандартный логин/логаут может включать в себя опции:
регистрация: с логином и паролем, без пароля, через соц.сети и т.д.;
авторизация: с логином и паролем, через соц.сети и т.д.;
выход из системы: самостоятельный, по истечению сессии и т.д.
Регистрация в приложении доступна всеми описанными в ТЗ способами.
Можно зарегистрироваться, заполнив только обязательные поля.
Можно зарегистрироваться, заполнив полностью все поля.
После регистрации можно авторизоваться в приложении. При этом введенные данные корректно сохранены в профиле (e-mail, пароль, личная информация и т.д.).
Зарегистрировавшись на одном устройстве, можно авторизоваться на другом — данные корректно сохраняются на сервере и доступны.
Выход из системы работает корректно.
Восстановление пароля работает корректно.
Негативные сценарии (самое очевидное):
Повторная регистрация на один и тот же e-mail, с одним и тем же логином недоступна.
Регистрация без заполнения обязательных полей недоступна.
Регистрация, если все поля оставлены пустыми, недоступна.
Регистрация, если формат введенных данных не соответствует требованиям, недоступна.
Авторизация с пустыми полями недоступна.
Авторизация с неправильным/удаленным/заблокированным логином недоступна.
Авторизация с неправильным паролем недоступна.
Создание контакта. Логично предположить, что если пользователь создает контакт, то должна быть возможность его просмотреть, отредактировать и удалить. Это базовый набор функций, которыми может обладать item.
Создание, изменение, просмотр и удаление контактов доступны.
Создание контакта с минимальным набором данных доступно.
Создание контакта с максимальным набором данных доступно.
При создании корректно обрабатываются все описанные в ТЗ типы данных.
После создания контакт доступен для просмотра.
Изменение учитывает обязательные поля/данные/элементы. Сохранить контакт без них недоступно.
После удаления контакт больше не доступен.
Создание двух одинаковых контактов недоступно (это может быть и позитивным сценарием).
Создание контакта с отсутствующими обязательными элементами/данными недоступно.
Сюда же, к функциональному тестированию, отнесу проверку пользовательского интерфейса:
Проверка экранов на совпадение с макетами.
Проверка работы «нативных» жестов: свайп, мультитач и т.д. — приложение должно реагировать на них определенным образом.
Проверка состояний элементов: кнопки изменяют цвет, если нажаты; списки сворачиваются и разворачиваются и т.д.
Проверка локализации, если таковая заявлена в приложении. При этом важно уделить внимание верстке — многие названия на других языках гораздо длиннее, чем на английском или на русском.
Вам необходимо мобильное приложение и вы не знаете, с чего начать поиск подрядчика? Воспользуйтесь рейтингом разработчиков мобильных приложений от Рейтинга Рунета.
Пройдя по ссылке, вы сможете составлять срезы по тематикам и тем самым узнать, у кого из разработчиков больше всего опыта в создании развлекательных, музыкальных или образовательных проектов, новостных или игровых приложений.
Тестирование производительности
Также известно как нагрузочное тестирование. Это автоматизированное тестирование, которое имитирует работу определенного количества пользователей какого-либо общего ресурса.
Определить количество пользователей, которые могут одновременно работать с приложением.
Проверить, как ведет себя приложение при увеличении интенсивности выполнения каких-либо операций.
Проверить работоспособность приложения при многочасовом использовании на средней нагрузке.
Проверить поведение приложения в стресс-условиях.
Проверить работу в условиях «разросшейся» базы данных — насколько быстро выполняются запросы.
Основная цель этого вида тестирования — убедиться в том, что приложение работает приемлемо при определенных требованиях производительности: доступ большому числу пользователей, устранение важного элемента инфраструктуры, как, например, сервера базы данных, и др.
Основные сценарии тестирования производительности мобильных приложений:
Определить, работает ли приложение одинаково в разных условиях загрузки сети.
Выяснить, способно ли текущее покрытие сети обеспечить работу приложения на различных уровнях пользовательской нагрузки.
Выяснить, обеспечивает ли существующая клиент-серверная конфигурация оптимальную производительность.
Найти различные узкие места приложения и инфраструктуры, которые снижают производительность приложения.
Проверить, соответствует ли требованиям время реакции приложения.
Оценить способность продукта и/или аппаратного обеспечения справляться с планируемыми объемами нагрузки.
Оценить время, в течение которого аккумулятор может поддерживать работу приложения в условиях планируемых объемов нагрузки.
Проверить работу приложения в случаях перехода из Wi-Fi-сети в мобильную 2G/3G-сеть и наоборот.
Проверить, что каждый из уровней памяти процессора работает оптимально.
Убедиться в том, что потребление батареи и утечка памяти не выходят за пределы нормы, а работа различных ресурсов и сервисов, таких как GPS-навигация или камера, соответствует требованиям.
Проверить стойкость приложения в условиях жесткой пользовательской нагрузки.
Проверить эффективность сети в условиях, когда устройство находится в движении.
Проверить производительность приложения, если оно работает в условиях непостоянного подключения к интернету.
Тестирование безопасности
Это стратегия тестирования, используемая для проверки безопасности системы, а также для анализа рисков, связанных с обеспечением целостного подхода к защите приложения, атак хакеров, вирусов, несанкционированного доступа к конфиденциальным данным.
Основная цель этого типа тестирования — обеспечить безопасность сети и данных приложения.
Ниже приведены ключевые действия для проверки безопасности мобильного приложения.
Убедиться в том, что данные пользователей приложения — логины, пароли, номера банковских карт — защищены от сетевых атак автоматизированных систем и не могут быть найдены путем подбора.
Удостовериться в том, что приложение не дает доступ к секретному контенту или функциональности без надлежащей аутентификации.
Убедиться в том, что система безопасности приложения требует надежного пароля и не позволяет взломщику завладеть паролями других пользователей.
Убедиться в том, что время таймаута сессии адекватно для приложения.
Найти динамические зависимости и принять меры для защиты этих уязвимых участков от взломщиков.
Защитить приложение от атак типа SQL-injection.
Найти случаи неуправляемого кода и устранить его последствия.
Удостовериться в том, что срок действия сертификатов не истек, вне зависимости от того, использует приложение Certificate Pinnig или нет.
Защитить приложение и сеть от DoS-аттак.
Проанализировать требования хранения и проверки данных.
Обеспечить управление сеансами для защиты информации от неавторизованных пользователей.
Проверить все криптографические коды и, если необходимо, исправить ошибки.
Удостовериться в том, что бизнес-логика приложения защищена и не подвержена атакам извне.
Проанализировать взаимодействие файлов системы, выявить и скорректировать уязвимые места.
Проверить обработчики протокола (например, не пытаются ли перенастроить целевую страницу по умолчанию, используя вредоносные плавающие фреймы).
Защитить приложение от вредоносных атак на клиентов.
Защитить систему от вредоносных внедрений в момент работы программы.
Предотвратить возможные вредоносные последствия кэширования файлов.
Предотвратить ненадежное хранение данных в кэш-памяти клавиатуры устройства.
Предотвратить возможные вредоносные действия файлов cookie.
Обеспечить регулярный контроль безопасности данных.
Изучить пользовательские файлы и предотвратить их возможное вредоносное влияние.
Обезопасить систему от случаев переполнения буфера или нарушения целостности информации в памяти.
Сделать анализ различных потоков данных и защитить систему от их возможного вредоносного влияния.
Юзабилити-тестирование
Юзабилити-тестирование проводится для создания быстрых и простых в обращении приложений. Главная цель — обеспечить удобство пользования приложением, создать интуитивный, соответствующий принятым стандартам интерфейс.
Итак, для проведения юзабилити-тестирования следует:
Убедиться в том, что кнопки имеют нормальный размер и подходят для крупных пальцев.
Поместить кнопки в одной области экрана, чтобы не вызвать замешательства у пользователей.
Убедиться в том, что значки и картинки смотрятся естественно в среде приложения.
Убедиться в том, что цвет кнопок, выполняющих одну и ту же функцию, совпадает.
Убедиться в правильной работе системы уменьшения и увеличения масштаба просмотра.
Обеспечить минимальный ввод данных с клавиатуры.
Убедиться в наличии возможности возврата или отмены действия в случае нажатия не на ту кнопку.
Убедиться в том, что контекстуальные меню не перегружены, так как они предполагают быстрое использование.
Убедиться в том, что текст прост, ясен и виден пользователю.
Убедиться в том, что короткие предложения и абзацы возможно прочитать.
Найти оптимальный размер шрифта.
Убедиться в том, что в случае загрузки пользователем больших объемов информации приложение предупреждает о возможных сбоях в его работе из-за этого.
Убедиться в том, что завершить работу приложения можно из любого состояния и что оно возобновляет работу в этом же состоянии.
Проверить, что все строки отображаются на нужном языке, если в приложении есть опция перевода.
Убедиться в том, что компоненты приложения синхронизируются с действиями пользователя.
Обеспечить пользователя руководством, которое бы помогло ему понять работу приложения и эффективно им пользоваться.
Юзабилити-тестирование обычно проводится на пользователях, поскольку только люди могут понять субъективные ощущения других людей, вызываемые тем или иным приложением.
Тестирование удобства использования — это метод тестирования, направленный на установление степени удобства использования, обучаемости, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий
Тестирование удобства пользования дает оценку уровня удобства использования приложения по следующим пунктам:
Производительность, эффективность (efficiency) — сколько времени и шагов понадобится пользователю для завершения основных задач приложения, например, размещения новости, регистрации, покупки (чем меньше времени и шагов понадобится пользователю, тем лучше).
Правильность (accuracy) — сколько ошибок сделал пользователь во время работы с приложением?
Активизация в памяти (recall) — как долго пользователь помнит о том, как пользоваться приложением, после приостановки работы с ним на длительный период времени? (Повторное выполнение операций после перерыва должно проходить быстрее, чем у нового пользователя).
Эмоциональная реакция (emotional response) — Как пользователь себя чувствует после завершения задачи: растерян, испытал стресс или, наоборот, ему все понравилось? Порекомендует ли пользователь систему своим друзьям?
Для улучшения удобства использования полезно следовать двум принципам:
«Защита от дурака». Если поле предполагает ввод номера телефона, то стоит ограничить диапазон ввода только цифрами и соответствующим образом сформировать клавиатуру. Аналогично для e-mail и остальных элементов, которые предполагают пользовательский ввод данных.
Использовать цикл Демминга (планирование-действие-проверка- корректировка), то есть собирать информацию о дизайне и удобстве использования у существующих пользователей, и на основе их мнений планировать изменения в приложении.
Конфигурационное тестирование
Конфигурационное тестирование проводится для того чтобы обеспечить оптимальную работу приложения на разных устройствах — с учетом их размера, разрешения экрана, версии, аппаратного обеспечения и пр.
Важнейшие сценарии конфигурационного тестирования:
Убедиться в том, что интерфейс приложения соответствует размеру экрана устройства, текст не выходит за рамки дисплея.
Убедиться в том, что текст легко читается на любом устройстве.
Убедиться в том, что функция вызова/будильника доступна при запущенном приложении, приложение сворачивается или переходит в режим ожидания в случае входящего звонка, а по его завершении возобновляется.
«Это тип тестирования, предназначенный для проверки работоспособности приложения на различных конфигурациях системы. Имеет смысл рассмотреть клиентский уровень конфигурационного тестирования. Сервер у мобильных приложений часто единственный, а клиент устанавливается на большое количество самых разнообразных устройств. Но нужно учесть, что если приложение специфичное — например, игра, для которой выделено несколько серверов, то серверный уровень также становится приоритетным.
На клиентском уровне можно выделить:
Тип устройства: смартфон, планшет и т.д.
Конфигурация устройства: количество оперативной памяти, тип процессора, разрешение экрана, емкость аккумулятора и т.д.
Тип и версия операционной системы. iOS 6, 7; Android 4.2.2 и т.д.
Перед проведением конфигурационного тестирования рекомендуется
Создавать матрицу покрытия (матрица покрытия — это таблица, в которую заносят все возможные конфигурации).
Проводить приоритезацию конфигураций (на практике, скорее всего, все желаемые конфигурации проверить не получится).
Шаг за шагом, в соответствии с расставленными приоритетами, проверяют каждую конфигурацию.
Уже на начальном этапе становится очевидно: чем больше требований к работе приложения при различных конфигурациях рабочих станций, тем больше тестов нам необходимо будет провести. В связи с этим рекомендуем по возможности автоматизировать этот процесс, так как именно при конфигурационном тестировании автоматизация реально помогает сэкономить время и ресурсы. Конечно же, автоматизированное тестирование не является панацеей, но в данном случае оно окажется очень эффективным помощником.
Тестирование на восстановление
Тестирование на восстановление проверяет тестируемый продукт с точки зрения способности противостоять и успешно восстанавливаться после возможных сбоев, возникших в связи с ошибками программного обеспечения, отказами оборудования или проблемами связи. Применяется чаще всего в приложениях, которые должны работать 24×7, где каждая минута простоя стоит очень дорого.
Проверка восстановления после сбоя системы и сбоя транзакций.
Проверка эффективного восстановления приложения после непредвиденных сценариев сбоя.
Проверка способности приложения обрабатывать транзакции в условиях сбоя питания (разряженная батарея / некорректное завершение работы приложения).
Проверка процесса восстановления данных после перерыва в соединении.
Другие важные области проверки:
Тестирование установки (быстрая, соответствующая требованиям установка приложения).
Тестирование удаления (быстрое, соответствующее требованиям удаление приложения).
Сетевые тест-кейсы (проверка адекватной работы сети в разных условиях загрузки, а также способности сети обеспечить функционирование всех приложений, используемых в ходе тестирования).
Проверка наличия нефункциональных клавиш.
Проверка экрана загрузки приложения.
Проверка возможности ввода с клавиатуры во время сбоев сети.
Проверка методов запуска приложения.
Проверка наличия эффекта зарядки в случае, если приложение находится в фоновом режиме.
Проверка функционирования экономичного режима и режима высокой производительности.
Выявление последствий извлечения аккумулятора во время работы приложения.
Проверка уровня потребления энергии приложением.
Проверка побочных эффектов приложения.
Отдельно укажу интеграционное тестирование, в рамках которого проводятся проверки взаимодействия модулей друг с другом, а также приложения с операционной системой и другими приложениями.
Сюда попадают все сценарии, связанные с различного рода прерываниями во время работы с приложением:
произошел телефонный звонок;
на экране появилось уведомление другого приложения;
пропала сеть или ухудшилось качество связи (попадает сюда, т.к. это обычное событие для мобильных сетей);
приложение было свернуто в трей;
приложение переведено в фоновый режим и т.д.
Данные случаи должны быть предусмотрены при разработке и тестировании приложения.
Ищете исполнителя для реализации проекта?
Проведите конкурс среди участников CMS Magazine
Узнайте цены и сроки уже завтра. Это бесплатно и займет ≈5 минут.