как протестировать приложение на андроид

Тестируем Android-приложение правильно

Меня зовут Андрей Рыжкин, я CTO AGIMA.

Сегодня я расскажу о том, как мы тестируем приложения на Android, а также поделюсь нашим чек-листом.

Чек-лист от команды AGIMA

В 2020 году количество приложений для Android вплотную приблизилось к трём миллионам (по данным Appbrain на 28 марта). И это число продолжает расти – каждый день появляются сотни новых программ для этой операционной системы. В том числе благодаря AGIMA. Мы создаем самые разные приложения для Android – простые и сложные, узкоспециализированные и «для всех». И можем немало рассказать о нюансах их разработки.

Конечно, главное в Android-приложении – его функционал. Недочеты вёрстки редко бросаются в глаза, но качество любого продукта – в мелочах. Поэтому мы всегда тщательно тестируем приложения перед запуском. А для того, чтобы тестирование занимало минимум времени и приносило максимум пользы, мы разработали специальный чек-лист, которым рады поделиться с вами!

Но сначала перечислим шесть наиболее распространенных проблем вёрстки, избежать которых поможет наш чек-лист.

1. Сдвиг элемента страницы

При вёрстке страницы можно применить три вида выравнивания по вертикали (Align Top, Align Middle и Align Bottom) и три – по горизонтали (Align Left, Align Center, Align Right). Но если использовать их несогласованно, отдельные элементы страницы начинают «съезжать» со своих мест.

На рисунке слева всё хорошо, но стоит изменить разрешение – и заголовок сдвигается вправо.

2. Обрезка текста

Проблема появляется, когда компоненты GUI пытаются сжать, чтобы «втиснуть» в маленький экран.

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

3. Отсутствие элемента страницы

При снижении разрешения экрана элементы увеличиваются в размере. И при неправильной вёрстке некоторые из них могут просто «исчезнуть».

4. Пересечение элементов

Иногда, также при снижении разрешения или уменьшении размера экрана, компоненты GUI «наезжают» друг на друга. В итоге на странице воцаряется полный хаос.

5. Выход элементов за границы экрана

Причина всё та же – при изменении разрешения элементы страницы увеличиваются, и экрана банально «не хватает» для их отображения. В итоге страница ужасно выглядит (и это в лучшем случае, в худшем ей становится просто невозможно пользоваться).

6. Артефакты адаптивного дизайна

При увеличении разрешения экрана может возникнуть «обратная» ситуация – компоненты GUI и текстовые символы могут уменьшиться до абсолютно нечитабельных размеров.

Согласно Material Design, размер любого элемента, с которым взаимодействует пользователь, будь то кнопка, чекбокс или радиобаттон, не должен составлять меньше 48 пикселей по любому измерению.

Гайдлайн не дает четких рекомендаций по размеру текста, однако по результатам исследования комфортным считается шрифт в 16 пикселей высотой, а приемлемым для чтения – 12-14 пикселей.

Перечисленные проблемы часто «наслаиваются» друг на друга – как известно, беда не приходит одна. И результаты таких сочетаний могут быть самыми непредсказуемыми. Но это – тема для отдельной статьи.

А теперь – обещанный чек-лист. Используйте его во время тестирования Android-приложения – и от вас не «ускользнет» ни одна ошибка!

Чек-лист

Запуск и выход из приложения:

Вёрстка (на всех заявленных в ограничениях устройствах и разрешениях):

И напоследок важный вопрос для всех читателей. Какие пункты вы добавили бы к нашему чек-листу? Будем рады вашим идеям!

Статья написана с ex-head QA AGIMA Рамилем Усмановым.

Источник

Тестирование мобильных приложений: tips & tricks

Наша новая статья представляет собой список рекомендаций и советов. Из неё вы узнаете:

Как облегчить процесс тестирования?

3. Используйте «обезьянок» для поиска крашей и зависаний, пока вы тестируете функционал более осмысленно. Наиболее эффективно комбинировать обезьянок и средства для снятия телеметрии для ускорения локализации проблемы, например, с TestFairy. С недавних пор TestFairy поддерживает и iOS, но пока функционал ограничен.

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

10. Заполняйте оперативную память девайса перед запуском приложения. Это поможет, во-первых, провести стресс-тестирование и проверить скорость работы, а во-вторых — проверить сохранение и возобновление состояния приложения (куда мы вернемся после сворачивания приложения, запустятся ли все нужные сервисы).

Работа с сетью

Работа с данными приложений, внешними и внутренними сервисами

1. Если есть сторонний сервис — он обязательно подведет. Недавняя авария у FB повлияла на работу некоторых приложений и сайтов. Например, пару версий назад приложение Habrahabr «расшаривало» статьи с блокированием UI без индикатора активности. В момент, когда «тормозил» Facebook или Интернет, «шаринг» вешал всё приложение до тех пор, пока процесс не завершался.

Лучше заранее выявить максимальное количество внештатных ситуаций и продумать шаги для их устранения: предусмотреть обработку неожиданных ответов (ошибки, мусор, отсутствие ответа, пустой ответ) от сторонних сервисов с индикацией проблемы пользователю, добавить таймауты к необходимым реквестам и т.д.

2. Если есть сторонние библиотеки — они обязательно будут вызывать проблемы. В частности Twitter, PayPal, Facebook довольно часто содержат в себе баги. Как пример, в одной из версий Twitter SDK был краш при получении 503 ошибки от собственного бэкенда — библиотека просто падала и утаскивала за собой приложение. Facebook SDK тоже нередко падает на Android (можно видеть в краш-алертах процесс под названием com.facebook.katana время от времени).

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

Android

1. Выставьте кастомные разрешения экрана эмулятора — это позволит выявить проблемы с layout, если у вас есть определённая нехватка девайсов или нужно проверить, правильно ли написан layout. Также разрешение экрана и плотность пикселов можно редактировать через ADB и на физическом девайсе, например, на Nexus 10.

2. Если клавиатура переопределена (используется кастомная), то уделите этому дополнительное внимание. Бывают как ошибки клавиатур, которые не удаётся обойти, так и логические или графические ошибки.

3. Staged rollout позволит легко найти проблемы, которые могли пропустить при тестировании релизной версии: можно зарелизиться на 5-10% и помониторить графики и краши, при необходимости — откатиться или перевыложить версию с фиксом.

4. Используйте do not keep activities при тестировании и убедитесь, что приложения готовы к неожиданным завершениям активностей, что может вести к крашам или потере данных.

1. Проверьте, не переопределены ли стандартные жесты. Например, при активации «Универсального Доступа» активируются дополнительные жесты, они могут конфликтовать с жестами вашего приложения (например, трёх- и четырёхпальцевый жест).

2. Также уделяйте внимание сторонним клавиатурам. Например, в iOS9 есть баг, который приведет к крашу приложения, если в модальном окне в WebView вводить текст с помощью сторонней клавиатуры.

3. Покажите разработчикам сервис rollout.io, который позволяет патчить некоторые краши на продакшене, переопределять параметры, показывать алерты с извинениями или делать некоторые кнопки неактивными. Нас он уже спасал не один раз.

4. Для интерактивного тестирования верстки или проверки того, что все скрины убрались из иерархии, можно использовать стандартные средства Xcode или Spark Inspector, RevealApp.

5. Попросите интегрировать в меню отладчика вызов Memory Warning. Его обычно вешают на определённый жест (тап несколькими пальцами, нажатие на строку состояния или навигации) или на кнопки регулирования громкости. Это нужно, чтобы проверить адекватность поведения приложения при Memory Warning, подчищает ли оно за собой ресурсы и насколько корректно это делается. Например, у нас был неприятный баг, когда после Memory Warning наш Image service выгружал картинку из памяти и на экране оставалась заглушка.

Налаживаем процессы

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

1. Введите культуру Pre-QA. Перед отправкой тикета на ревью сядьте вместе с разработчиком за его машину и потестируйте 5-10 минут фичу под отладчиком на одном-двух девайсах — большинство самых глупых ошибок найдется сразу. Это также позволяет обучить разработчиков базовым навыкам тестирования: как минимум они будут повторять за вами действия, как максимум — вникнут и будут тестировать более осмысленно. Никому не хочется допускать глупые ошибки и выставлять их на общее обозрение.

2. Хотя бы бегло просматривайте diff-ы каждой ветки (фичи) и задавайте как можно больше вопросов разработчикам.
Таким образом вы, во-первых, поднимите свой престиж как тестировщика — вы пытаетесь разобраться в коде и областях, которые затронуты этой фичей. Даже сейчас тестировщики мобильных приложений иногда воспринимаются разработчиками как обезьянки, которые тыкают в телефон и жонглируют ими чтобы «уронить» приложение.

Если нет свободных девелоперов — вы можете выступить ревьювером: разработчик во время объяснения работы фичи иногда сам находит недостатки или кейсы, которые он не учел.

Во-вторых, вы начнёте постепенно изучать язык программирования и будете лучше понимать, что происходит «под капотом» приложения.

3. Изучите жизненный цикл сущностей приложения и самого приложения (Activity для Android 1, 2, 3; ViewController для iOS 1, 2, 3) для понимания, из какого в какое состояние может переходить экран приложения и оно само. Чем лучше вы знаете работу приложения изнутри, тем более полно сможете его протестировать.

4. Если у вас есть приложения для iOS и Android, то важно соблюдать правильный баланс ресурсов для их тестирования.

Разное

4. Также не стоит забывать о временных поясах и локации пользователей. Возможно, ваше приложение не рассчитано на работу в определённых странах (хотя и выложено там по ошибке или вы, как пользователь, приехали на время в другую страну). Местоположение на iOS можно «фейкать» в настройках симулятора (Debug > Locations), а на Android есть приложения, позволяющие это делать.
Если приложение работает с данными и есть несколько дата-центров в разных временных зонах, необходимо убедиться, что все работает правильно и не возникает коллизий при переключении между дата-центрами.

5. Научитесь обновлять и «даунгрейдить» прошивки — платформы фрагментированы, особенно Android и Blackberry. Облачные сервисы хороши, но они стоят денег, поэтому не все компании имеют возможность ими пользоваться из-за недостатков финансирования или политики безопасности.

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

Заключение

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

Составляя этот список, мы с коллегами основывались на собственном опыте и будем рады увидеть ваше мнение в комментариях.

Александр Хозя
Lead Mobile QA Engineer

Источник

Чек-лист тестирования мобильных приложений

У многих начинающих специалистов в области тестирования возникает вопрос: «А как же протестировать мобильное приложение. С чего начать, какие проверки стоит осуществить?» Данный вопрос актуален, когда они приходят в компанию, где нет документации на проекте, либо это только что появившийся стартап. Чтобы ответить на эти вопросы была подготовлена универсальная шпаргалка, которую можно использовать при тестировании практически любого приложения.

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

Чек-лист для тестирования мобильных приложений состоит из восьми разделов:

Функциональное тестирование

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

Что проверяем?

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. Потребление ресурсов приложением (например расход заряда батареи)

Источник

Процесс тестирования мобильных приложений

Тестирование – очень важный этап разработки мобильных приложений.

Стоимость ошибки в релизе мобильного приложения высока. Приложения попадают в 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: а расскажите как устроено тестирование у вас, хотя бы сколько тестировщиков на разработчика

Подписывайтесь на наш хабра-блог. Каждый четверг полезные статьи о мобильной разработке, маркетинге и бизнесе мобильной студии.

Источник