Как тестировать приложения которые работают с очередями сообщений

Обновлено: 06.01.2025

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

Рассмотрим основные моменты, на которые необходимо обратить особое внимание именно при тестировании мобильных приложений.

Размер экрана и touch-интерфейс.

• Необходимо проверить размеры всех элементов графического интерфейса пользователя, при этом обратить особое внимание на возможность использования всех элементов.
• Также следует проследить, за тем, чтобы в ходе работы приложения не возникало пустых экранов, так как появление пустого экрана часто ставит пользователя в тупик.
• Необходимо удостовериться, что многократное быстрое нажатие на кнопку не вызовет падения приложения, так же необходимо проследить, чтобы приложение корректно обрабатывало нажатие нескольких кнопок одновременно. Дело в том, что такие ситуации с кнопками часто встречаются при работе с сенсорным экраном.
• Необходимо проверять использование в приложении так называемых "нативных" жестов (например, pinch-to-zoom, doubletap), если необходимо, то соответствующий жест должен использоваться по умолчанию, а если над каким-то элементом действие, соответствующее жесту не предусмотрено, то жест использоваться не должен. Например, в случае поддержки увеличения части приложения, pinch-to-zoom должен использоваться по умолчанию, если же нет необходимости выделять какой-то элемент, то doubletap не должен ее выделять.

Ресурсы устройства.

• Необходимо проконтролировать возможные утечки памяти. Часто это случается в приложениях с окнами, содержащими большое количество информации, например, длинные списки. Память также может теряться во время длительной работы приложения, а также при некорректно работающем кэшировании изображений.
• Необходимо проверить корректность обработки ситуаций нехватки памяти для функционирования операционной системы, во время работы приложения в активном или фоновом режиме.
• Обязательно нужно проверить на целевом устройстве наличие всех поддерживаемых приложением функций (например, 3G, SD-карта и т. д.).

Различные разрешения экрана и версии ОС.

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

Реакция приложения на внешние прерывания.

• Необходимо проверить работу приложения в условиях эксплуатации мобильного устройства, а для таких устройств характерны частые изменения состояния: входящие и исходящие звонки, SMS, MMS; выключение/разрядка устройства; переход в режим ожидания (в том числе и с защитой паролем); смена ориентации устройства в режиме ожидания; отключение и включение сети, Bluetooth, авиарежима, GPS; потеря связи с сервером или прокси (подключение есть, но пакеты не проходят); отключение и подключение SD-карты, дополнительных устройств; зарядка устройства; работа с акселерометром; работа с физической клавиатурой (если в списке поддерживаемых моделей есть такие).

Рассмотрим основные отличия, характерные для мобильных приложений, в некоторых типах тестирования.

Тестирование обновлений. Частые обновления операционной системы ( по сравнению с персональными компьютерами) требуют обновления приложений, которое должно проходить просто и не требовать от пользователя специфических знаний. Необходимо проверять различные возможные пути установки приложения (Wi-Fi, 3G, установка с ПК, на SD ).

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

Тестирование удобства пользования (usability) . Этот вид тестирования является одним из самых важных, так как в условиях высокой конкуренции юзабилити приложения входит в список основных параметров, влияющих на популярность продукта. Позволяет выявить части приложения, которые недостаточно привлекательны, а может даже вызывают затруднения в навигации или использовании на сенсорных экранах. Следует так же убедиться, что модель потребления ресурсов приложением соответствует целевой аудитории, например, приложения-напоминания не должны вызывать чрезмерное потребление энергии.

Нагрузочное тестирование. Подразумевает наблюдение за использованием памяти и системных ресурсов, позволяет выявить "узкие" места в приложении, связанные с производительностью, обнаружить опасные утечки памяти.

Случайное тестирование (fuzzy testing, "monkey" testing) . Приложение должно корректно реагировать на возникновение случайных и непредсказуемых событий. Мобильные устройства чаще других попадают в условия, в которых получают хаотичную бесполезную информацию (например, не заблокированное устройство в кармане), поэтому приложение должно адекватно реагировать на подобные потоки данных .

Конфигурационное тестирование. Приложение должно правильно работать на всех платформенных решениях, для которых разрабатывалось. Мобильные устройства обладают широчайшим разнообразием, поэтому задача тестирования всех доступных видов устройств, на которых используются различные сборки ОС, которые имеют различные разрешения экранов, функционал и аппаратное обеспечение , крайне важна и очень трудновыполнима.

Лабораторное тестирование. Предполагает имитацию реальных условий качества связи и окружающей среды, позволяет проверить как поведет себя приложение при нестабильном сигнале Wi-Fi или с нулевым балансом на счету в сети 3G.

Аттестационное тестирование. Используется для подтверждения соответствия приложения стандартам, лицензионным соглашениям и условиям использования. Рассмотрим требования к приложениям, разработанным для мобильных устройства, работающих под управлением Android .

Для отдельных магазинов приложений (Amazon App Store , Samsung Apps, Yandex. Store и подобных) могут существовать свои собственные требования и гайдлайны.

По разным данным в среднем человек проводит с мобильным устройством от 3 до 6 часов в день. Это большая аудитория, возможно она даже больше аудитории десктопных приложений. Раз мобилками пользуется так много людей, значит там много денег. Чтобы заработать больше деньег качество приложения должно быть на высоте. Конечно же за это качество отвечают в большей степени тестровщики.

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

В конце статьи бонусом собрал видео лекции об особенностях мобильного тестирования.

С чего начать

Мобильные приложения делятся на 3 типа:

1. Нативное приложение - приложение под определенную платформу доступное через маркетплейс (Google Play, AppStore и т.д.). Еще одно важно отличие - автономная работа в режиме оффлайн. Яркий пример мобильные игры.
2. Веб-приложение - открывается через браузер, а значит это просто веб-сайт.
3. Гибридное приложение - устанавливается через маркетплейс, а отображается внутри приложения как веб-сайт. Часто это приложения супермаркетов, недорогих доставок еды.

Немного о плюсах и минусах типов

Говорим о плюсах и минусах именно для тестирования. Если говорить в общем, то список будет намного длинее. Например, нативное приложение очень дорогое в ращработке и тестировании, что является минусом для бизнеса.

Плюсы нативного приложения:

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

Минусы нативного приложения:

• правки багов доезжают только при релизе следующей версии
• тестирование на каждой платформе
• занимают больше памяти

• правки багов приезжают быстрее
• тестирование проводится в браузере и не сильно завязано на ОС/модель телефона/платформу
• не требуется тестировать установку, удаление и обновление

• ограниченный доступ к функциональности девайса (FaceID, отпечаток пальца, камера и т.п.)
• не работают в оффлайне

Плюсы гибридного приложения:

• мультиплатформенные, т.е. реализация на всех ОС одна
• правки багов приезжаюь быстрее, т.к. по сути функционал это встроенный веб-сайт в приложение
• могут использовать большинство функций девайса

Минусы гибридного приложения:

• не работают в офлайне
• ограниченный доступ к функциональности девайса

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

• Функциональное тестирование - проверка реализованного функционала. Чаще всего сравнивается реализация и ТЗ.
• Тестирование пользовательского взаимодействия (также известное, как тестирование удобства использования, тестирование UX) - удобства работы с приложнием: свайпы, тапы, скролы и т.п.
• Тестирование совместимости - установка на разные ОС, платформах, на разных моделях, проверка на разных разрешениях и т.п.
• Тестирование подключения - проверка на разных типах подключения(wi-fi, мобильная сеть), переключение типов и оффлайн работа
• Тестирование производительности - утечка памяти, стабильность работы при большом количестве пользователей и т.п.

Как выбрать устройства для тестирования

Платформа (смартфон или планшет), ОС определяютя техническим заданием.

Выбор версий и моделей базируется на статистике. Это либо внутреняя статистика вашего сервиса (google analytics, яндекс метрика) или общедоступные дашборды:

• официальная статистика использования устройств Apple
• официальная статистика использования устройств Android
• deviceAtlas - позволят получить выборку по разным параметрам (регион, производитель и т.д.)
• statcounter - аналог deviceAtlas

Дальше зависит от технической базы твоей компании. По возможностям выбираете тестирование на физических устройствах, сервисах удаленного доступа к физическим устройствам ( perfecto , Device Everwhere ) или на симуляторах/эмуляторах.

Не стоит забывать про тестирование на пользователях в бете. Это возможно тестирования на широком наборе устройств, с разными ОС, ресурсами и т.д. Например, в Google Play при публикации приложения есть возможность раздать новое приложение только на некоторый процент пользователей.

Основные проверки по типам тестирования

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

• Установка приложения
• Тестирование по ТЗ
• Соответствие общепринятым правилам, например, математическим
• Первый запуск приложения
• Открытие приложения из списках активных (горячий старт)
• Открытие приложения, когда его нет в списке активных (холодный старт)
• Открытие приложения интентом, т.е. вызвать другим приложением, например, тап по ссылке в мессенджере вызывает тестируемое приложение
• Закрытие (только тестируемого приложения, всех приложений в менеджере приложений)
• Удаление приложения из разных точек (логнтапом по иконке, из списка установленных приложений)
• Обновление ( важно проверить сохраность пользовательских действий)

Тестирование пользовательского взаимодействия

Про тестирование пользовательского взаимодействия можно говорить много, поэтому поговорим об этом в отдельном посте (не забудь подписаться , чтобы не пропустить).

Тестирование совместимости

• Проверка на платформах: смартфон, планшет. Возможно по ТЗ будет необходимость проверить на умных колонках, часах или навигаторе.
• Тестирование на разных девайсах: модель, производитель, версиях ОС.
• Если это веб-приложение, то проверить на топовых браузерах
• Проверка на разных разрешениях и масштабах, в альбомной и портретных ориентациях экрана
• Перенос приложения на внешний/внутрений носитель
• Проверка доступности 3rd party services (CDN, библиотеки и т.п.)

Тестирование подключения

• Тестирование при подключеном Wi-Fi, 4G/3G/E/etc
• Разрыв и восстановление сети
• Переключение с одного типа сети к другому
• Оффлайн
• Смена, отключение геопозиции

Тестирование производительности

• Если это веб-приложение, то замерить производительность Lighthouse , Яндекс Метрикой и т.п.
• Репорты с маркетплейсов. Например Google Play присылает отчет об опубликованном приложении (безопасность, краши и т.п.)
• Отзывы пользователей
• Нагрузочное/стресс/стабильности тестирование

Особенности, о которых нужно помнить

Некоторые особенности, которые отличают мобильные приложения от десктопных, и как следствие накладывают дополнительные условия тестирования:

• Смена геопозиции в широком диапазоне. Юзер мобильных приложений более подвижные, чем десктопные :)
• Устройства сильно различаются: платформа, ОС, разрешение, ориентация, ресурсы (память, камера, наличие внешней памяти, датчики освещенности, ориентация экрана, датчики bluetooth/NFC/Wi-Fi/4G/etc)
• Способ взаимодействия в 90% тач. Плюс многие сенсоры оснащены мультитачом.
• Отдельно стоит проверить установку/обновление/работы при недостатке памяти
• Работу при отключении/включении функциональности девайса: bluetooth, NFC, режим полета, ночное освещение, движение глазами и т.п.
• Ограничения ОС. Тут куча кейсов с блокировкой кук, передачи геопозиции и т.п. на уровне ОС.
• Извлечение/переключение sim/flash-карты

Бонус

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

В этой статье мы рассмотрим тестирование веб приложений и сайтов. Она довольно длинная, поэтому усаживайтесь по удобнее.

Основные виды тестирования сайта (веб-приложения)

1. Тестирование функциональности;
2. Тестирование удобства использования;
3. Тестирование интерфейса;
4. Тестирование совместимости;
5. Тестирование производительности и скорости загрузки сайта;
6. Тестирование безопасности.

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

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

Проверьте все ссылки

• Проверьте ссылки, исходящие от всех страниц к конкретному домену.
• Внутренние ссылки.
• Ссылки на другие элементы, расположенные внутри страниц.
• Ссылки для отправления электронной почты администратору или другим пользователям веб-страниц.
• Проверьте, нет ли ссылок на изолированные страницы.

Проверьте формы

Формы используются для получения информации от пользователей и взаимодействия с ними.

Что нужно проверить в формах:

• Правильность работы валидации в каждом поле формы.
• Значения полей, используемые по умолчанию.
• Опции для создания форм, удаления, просмотра и редактирования форм ( если такие имеются ).

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

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

Тестирование файлов cookie

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

Проверьте HTML/CSS

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

Тестирование базы данных

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

Проверьте, все ли запросы к базе данных выполняются правильно, данные извлекаются и обновляются должным образом.

При тестировании функциональности сайтов нужно проверить:

Ссылки

1. Внутренние ссылки;
2. Внешние ссылки;
3. Ссылки на электронную почту;
4. Битые ссылки.

Формы

База данных

Следует проверить целостность базы данных.

Тестирование удобства использования (юзабилити сайта)

Тестирование юзабилити — это анализ взаимодействия пользователя и сайта, поиск ошибок и их устранение.

При этом проверяется:

• Легкость обучения;
• Навигация;
• Субъективная удовлетворенность пользователей;
• Общий вид.

Проверка навигации

Под навигацией подразумеваются средства для просмотра страниц пользователем. Это кнопки, блоки. А также то, как посетитель сайта использует ссылки на другие страницы.

• Сайт должен быть простым в использовании;
• Инструкции должны быть очень четкими;
• Проверьте, достигают ли предоставленные инструкции поставленной цели;
• Главное меню должно быть доступно на каждой странице;
• Главное меню должно быть построено в логической последовательности.

Проверка контента

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

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

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

Другая информация для пользователей

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

Тестирование пользовательского интерфейса

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

• Интерфейсы веб-сервера и приложения.
• Интерфейсы сервера базы данных и сервера приложения.

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

Проверка совместимости

• Совместимость с браузерами;
• Совместимость с операционными системами;
• Просмотр на мобильных устройствах;
• Параметры печати.

Совместимость с браузерами

Работа некоторых веб-приложений зависит от типа браузера. Сайт должен быть совместим с различной конфигурацией и параметрами разнообразных браузеров.

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

Проверьте работу веб-приложения в браузерах Internet Explorer , Firefox , Netscape Navigator , AOL , Safari , Opera разных версий.

Совместимость с операционными системами

Некоторые функции веб-приложения могут быть несовместимы с определенными операционными системами. Не во всех из них поддерживаются новые технологии, используемые в веб-разработке. Поэтому проверьте работу приложения в Windows , Unix , MAC , Linux , Solaris и их различных версиях.

Просмотр на мобильных устройствах

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

Параметры печати

Тестирование производительности сайта

Тестирование производительности сайта или веб-приложения должно включать в себя:

• Нагрузочное тестирование.
• Стрессовое тестирование.

Проверьте производительность приложения на различной скорости интернета.

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

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

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

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

Скорость соединения

Сплит тестирование сайта при использовании различных вариантов интернет-соединения: через модем, ISDN и т.д.

Нагрузка

1. Количество пользователей, одновременно посещающих сайт;
2. Проверьте работу системы при пиковых нагрузках;
3. Пользователь осуществляет доступ к большому количеству данных.

Стрессовая нагрузка

1. Непрерывная нагрузка;
2. Производительность памяти, процессора, обработки файлов и т. д.

Тестирование безопасности

Ниже приведены некоторые наборы для тестирования веб-безопасности:

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

• Сетевое сканирование;
• Сканирование уязвимостей;
• Возможность потенциального взлома паролей;
• Обзор журнала;
• Средства для проверки целостности;
• Обнаружение вирусов.

Моменты, которые следует учитывать при тестировании сайта

Следует обратить внимание на взаимодействие HTML-страниц , интернет-подключение, брандмауэры, приложения, запускаемые на веб-страницах ( апплеты, JavaScript , модульные приложения ), а также приложения, работающие на стороне сервера ( скрипты CGI , интерфейсы баз данных, генераторы динамических веб-страниц ).

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

Пример сценариев тестирования сайта

Дополнительные факторы, которые следует учесть при тестировании сайта:

• Какова ожидаемая нагрузка на сервер ( например, количество запросов за единицу времени )?
• Какая производительность требуется при различных видах нагрузки ( время ответа веб-сервера, время отклика базы данных на запрос )?
• Какие инструменты потребуются для тестирования производительности?
• Кто является целевой аудиторией? Какие браузеры будут использовать пользователи? Какова скорость подключения? Предназначен ли сайт для использования внутри организации или будет доступен в интернете для широкого круга пользователей?
• Какую производительность ожидает получить клиент ( насколько быстро должны загружаться страницы, как должны себя вести анимации, апплеты, нагрузка и запуск )?
• Будут ли разрешены простои сервера и техническое обслуживание, а также обновление контента? Если да, в каком количестве?
• Какие средства безопасности требуются ( файерволы, шифрование, пароли и т.д. ), и какую работу они будут выполнять? Как их можно проверять?
• Насколько надежным должно быть интернет-соединение? Как оно будет влиять на резервное копирование системы?
• Как будет выполняться управление обновлением контента сайта?
• Требования для технического обслуживания, отслеживания и контроля содержимого веб-страниц, графических элементов, ссылок и т.д.
• Какая спецификация HTML будет соблюдаться? Насколько точно?
• Как будут проверяться и обновляться внутренние и внешние ссылки? Насколько часто?
• Как будет происходить управление и проверка CGI апплетов, сценариев JavaScript , компонентов ActiveX и т.д.?
• Максимальный размер веб-страницы не должен превышать 3-5 экранов, кроме случаев, когда контент сосредоточен на одной теме. Если размер веб-страницы больше, предоставьте внутренние ссылки для навигации по ней.
• Разметка веб-страницы и элементы дизайна должны быть последовательными и логично связанными.
• Отображение веб-страниц должно быть независимо от типа браузера.
• На каждой странице следует указать ссылку для связи.

Пожалуйста, опубликуйте ваши отзывы по текущей теме статьи. За комментарии, отклики, дизлайки, лайки, подписки огромное вам спасибо!

Дайте знать, что вы думаете по этой теме материала в комментариях. За комментарии, подписки, дизлайки, отклики, лайки огромное вам спасибо!

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

Ваше мобильное приложение должно быть тщательно протестировано перед его выпуском конечному пользователю.

В этом уроке вы узнаете

• Стратегия тестирования мобильных приложений
• Производительность устройства
• Производительность сервера
• Производительность сети
• Устранение неполадок с производительностью мобильных приложений
• Полезные инструменты для тестирования мобильных приложений
• проблемы
• Настройка среды тестирования производительности мобильных приложений
• Контрольный список производительности для мобильных приложений

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

Производительность приложений на мобильном телефоне или любом интеллектуальном устройстве обычно измеряется по следующим трем категориям.

• Производительность устройства
• Производительность сервера / API
• Производительность сети

Производительность устройства

Когда клиент испытывает медленное приложение, он раздражается.

Для производительности устройства, вы будете проверять следующее —

Сколько времени занимает запуск вашего приложения? Это первый параметр производительности, объявленный пользователем. Как правило, после того, как пользователь нажмет на значок приложения, первый экран должен появиться через 1-2 секунды.

On constant use, some mobile apps, consume a high amount of battery life and heat the phone. This factor adds a lot to the performance of any mobile app and could normally happen when your app is using more resources than required. Excessive resource usage creates a burden on the processor and phone gets heat up.

When Testing an app, the memory consumption by an app should be checked. By implementing certain functionalities in the app, the memory consumption also increases. For example, in Android apps when push notifications are implemented then memory consumption increases.

In some cases, it has been observed that memory usage by whole O.S is mere 14%, but a new app is consuming 11%. So, these factors must be handled before deploying the app to the real world or giving to the client.

When testing a mobile app, it is mandatory to check apps on different devices. It could be the case that app is running smoothly on one device but not on other. Like for different vendors of Android devices, we can check the app on Samsung, HTC, and Lenovo phones. Similarly, the app needs to be tested with different RAM and processor specifications like 1 GB or 2 GB.

When the app under test is running in parallel with other apps, there should be no interference. The best way to check it is by switching app under testing and other apps.

An app that is running in the background is retrieved, it should remain in the same state as it was before. If this scenario is not handled properly, then data get lost. Again you have to enter data from scratch upon retrieving the app.

Server/API Performance

When the app is interacting with the server via API, the response time becomes critical to performance. For Server performance, you will check —

The app should handle data efficiently that is sent from the server. It must not take too much time while loading data. In certain apps, data is sent in a specified format. So before displaying it in the app, it should be converted to a relevant format. In this process, apps sometimes become slower and response time becomes longer.

The number of calls from App under test to the server generated from app should be less. In some cases, multiple API calls are made for the same functionality. For better performance, this should be handled with less number of calls.

Due to any reason if the server is down or unreachable we can save data in the native database. So, whenever the server is down, we can show data stored in the native database. Another solution could be the failover database servers i.e. if one of the servers is down or in maintenance phase the backup server should be available to switch over. The failover/backup server should be in continuous replication and synchronization with the main server.

Network Performance

The performance of the app on different networks and network properties need to be measured.

For Network performance, you will check following things.

When there is a delay in receiving information on the network, then it is termed as jitters. It is a problem with the connectionless networks or packet switch networks. As the information is distributed into packets, packets can travel by a dissimilar path from the sender to the receiver. When data arrives at the intended location, it becomes scrambled than it was originally sent. In the case of Jitters, the mobile app should be capable enough to handle it.

You need to Show the appropriate notifications to the end user, either to resend the request or wait till the system responds again.

In the case of complete packet loss, the app should be able to resend the request for the information or should generate the alerts accordingly. If data is not complete, then the user will not be able to comprehend information displayed in App. This can be stressful for the user. So, it is better to display a suitable message or prompt user to try again.

The app needs to be checked on a variety of networks with variable speed. The app should be tested on 2.5G, 3G, and 4G networks. Both Wi-Fi and mobile networks are included in this. Also, the behavior of app should be monitored. Especially, when both networks are available, and switching occurred from one network to another.

Например, проблема может возникнуть в приложении для пользователей при переключении телефонной сети с 4G на WIFI и наоборот. В этом случае приложение перестает отвечать на запросы и может потребовать перезапуска приложения для использования.

Устранение неполадок с производительностью мобильных приложений

Читайте также:

  
• Как скачать приложение квант мобайл банк
  
• Без приложения не конфиденциально
  
• Приложение где можно рисовать на фото
  
• Постановление 1867 какие приложения
  
• Выберите примеры приложений которые пишутся через дефис знаки не расставлены