Как тестировать мобильные и веб приложения
Тестирование веб-приложений — задача, с которой ручному тестировщику приходится сталкиваться довольно часто. В этой статье мы расскажем некоторые особенности данного процесса.
Кроссбраузерность
Первое — это проверка на правильность отображения и функционирования web-приложения на различных браузерах. Под правильностью понимается соответствие стандартам и требованиям.
Важно: перед началом тестирования надо выяснить, какие конкретно браузеры поддерживаются.
Что проверяем при кроссбраузерном тестировании: — функциональные возможности продукта, которые реализуются на стороне клиента; — правильно ли отображаются элементы графики; — корректно ли отображаются шрифты, размеры текстовых символов; — доступны ли формы, присутствующие на сайте, выполняют ли они свои функции, являются ли интерактивными.
Необходимо понимать, что тестировать надо все основные браузеры, однако отдельное внимание следует уделить браузеру Internet Explorer. Именно в с этим браузером чаще всего возникают проблемы. Особое внимание тут следует обращать на фокус полей, масштабируемость, работу JavaScript.
Web-формы
Формы для заполнения — важнейшие составляющие веб-приложений. Именно с помощью форм осуществляется взаимодействие клиента с сервером (клиент — это, к примеру, веб-браузер, через который пользователь обращается к серверу приложения).
Хорошая практика — составлять чек-лист UI-компонентов, которые нужно проверить (радио-баттоны, дроп-дауны, чек-боксы).
Но теперь давайте сделаем небольшое отступление и скажем, что валидация бывает как со стороны сервера, так и со стороны клиента.
Валидация со стороны сервера
Валидация со стороны клиента
Речь идет о выполнении проверки значений непосредственно при вводе данных. Для этого в Presentation Layer подключают специальные скрипты валидации (Presentation Layer — слой представления веб-приложения — то, что мы видим, UI).
Что такие скрипты могут проверять: — ввел ли пользователь в поле email символ @; — заполнены ли обязательные поля; — ввел ли пользователь цифры в поле ввода номера телефона; — не совпадают ли поля, которые не должны совпадать, и т. п.
Для чего это нужно? Ответ очевиден: валидация на стороне клиента уменьшает число обращений к серверу, снижая нагрузку на него.
База данных
При тестировании web-приложений не забываем про базы данных.
Что проверяем: — данные, введенные со стороны клиента, сохранились в базе; — данные, записанные в БД, корректно отображаются на клиенте; — данные можно удалить/изменить; — число открытых соединений с БД; — скорость обработки запросов.
Сервер
Сервер тестируется отдельно от клиента. Проверяем: — наличие валидации со стороны сервера (о ней упоминали выше); — корректность ответа сервера на подаваемый запрос со стороны клиента (правильный код состояния, заголовок, тело и т. д.) — тут используют такие инструменты, как Fiddler и Postman; — скорость обработки запросов.
Пользователи, multiple users
Как известно, одновременно с веб-приложением может работать большое число пользователей. Какие проверки здесь необходимы: — нагрузочное тестирование (сколько пользователей могут без проблем работать одновременно); — аутентификация и авторизация (что происходит на стороне сервера); — конкурентный (параллельный) доступ к ресурсам (скорость работы приложений не должна меняться); — уровни доступа пользователей.
Тестирование Mobile Web в чем-то похоже на тестирование Desktop Web. С одной стороны это те же HTML, CSS, JavaScript и прочие прелести, которые мы привыкли видеть. Те же проблемные места и типичные баги. С другой стороны, отличия все же имеются.
В этой статье я собрал небольшой чек-лист тех особенностей, которые важно проверять на Mobile Web проекте. Список не претендует на полноту, так что дополняйте его своими пунктами в комментариях. Я буду только рад. Единственное правило — пункт должен относиться только к мобильному вебу, а не к вебу вообще.
Начать хотелось бы с того, что у нас есть как минимум два способа тестировать Mobile Web проекты. Первый — эмулировать мобильный браузер средствами Chrome DevTools (или другими браузерами в их инструментах разработчика, но это менее популярный способ). Второй — тестировать на реальном девайсе, используя настоящий мобильный браузер.
Большую часть функционала вполне возможно проверить без девайса, но все же не все. Потому я разбил проверки на две больших части — то, что мы проверяем на ПК, а что только с мобильным устройством в руках.
Chrome DevTools
Итак, как было сказано выше, мобильное тестирование можно провести на ПК, не используя мобильное устройство. Браузер Chrome умеет работать в мобильном режиме.
Мобильный режим
Для того, чтобы перейти в мобильный режим просмотра веб-страницы, необходимо открыть Chrome DevTools и нажать на вот этот символ:
Перед нами откроется веб-приложение так, словно оно было открыто с мобильного девайса:
Мы можем выбирать из списка тип девайса, работу с которым мы эмулируем:
User Agent
Важно помнить, что некоторые веб-приложения помимо размера экрана еще ориентируются на User Agent. Такое приложение в мобильном режиме может визуально отличаться от того, что мы увидим на реальном девайсе.
Для того, чтобы все сделать правильно, необходимо в Chrome DevTools дополнительно настроить Network conditions, выставив мобильный User Agent:
После чего перезагрузить страницу и получить необходимый результат.
Network throttling
При помощи Chrome можно проверить работу приложения как на медленном интернете, так и вовсе оффлайн. Для этого на той же вкладке Network Conditions можно выбрать параметр network throttling:
Это важно в том случае, если пользователи часто используют приложение в условиях плохого интернета, например навигатор.
Это не все, что есть в Chrome DevTools. Это отличный инструмент как для работы с Desktop Web, так и для Mobile Web. По нему есть отличная документация от Google, in English of course.
У нас есть двухнедельный онлайн-курс по Chrome DevTools на русском. Вся информация на странице профиля. Движемся дальше. :)
Тестирование Mobile Web с помощью Chrome DevTools имеет ряд преимуществ. Это просто, быстро, не требует наличия реальных девайсов и позволяет выявить самые очевидные баги приложения. Но, увы, не все.
Производительность
Первая причина, почему стоит взять в руки мобильное устройство: необходимость проверить работоспособность приложения на слабом девайсе.
Современные веб-приложения перегружены всякого рода анимациями, сложными вычислениями на стороне клиента и так далее. Если на десктопе все это добро может работать гладко и красиво (хотя тоже не всегда), на каком-нибудь Samsung J-линейки (например, J2) могут быть лаги.
Мобильные браузеры
Вторая причина — мобильные браузеры. Речь о тех браузерах, которые встроены в систему и являются дефолтными. Многие люди используют их и не утруждают себя установкой мобильного Chrome.
Одним из представителей такого браузера является Samsung Internet Browser. На нем стоит проверить работу своего веб-приложения. Особенно если нет статистики, показывающей “с чего сидят” ваши пользователи. Если такая статистика есть и она утверждает, что с этих браузеров никто на приложение не заходит, то скорее всего тестировать его не надо. Хотя… а что, если они не заходят потому, что оно как раз сломано? :)
Стоит об этом подумать.
Работа в Background
Mobile Web приложение работает в мобильном браузере, что логично. При этом мобильные девайсы устроены так, что приложение может быть как в активном режиме, так и в бэкграунде. Например, если мы переключились на другое приложение или у нас входящий звонок.
Теперь предположим, что по какой-то причине наш пользователь перевел браузер с открытым приложением в бэкграунд. А затем вернулся. Вот несколько примеров того, что может быть не так. Например, у нас приложение-чат и вся история переписки потерялась. Теперь требуется перезагрузка страницы. Плохо? Конечно! Или у нас приложение “записная книжка”. Пользователь не успел что-то дописать, когда его прервал входящий звонок. Вернувшись, он обнаружил, что написанное им стерлось. Теперь придется писать все заново. А может лучше не пользоваться таким приложением?
Обязательно проверяйте, как ключевой функционал приложения работает после бэкграунда.
Электронная клавиатура
Чаще всего пользователи Mobile Web используют электронную клавиатуру для ввода текста. Бывает такое, что при ее появлении верстка приложения ломается. Обычно эта проблема связана с тем, как рассчитываются пропорции экрана и как они влияют на эту самую верстку.
Стоит обратить особое внимание на те страницы приложения, где пользователю приходится заполнять много данных: страница регистрации, какие-нибудь опросники и так далее.
Ориентация экрана
У мобильных приложений есть два типа ориентации экрана: portrait и landscape. Об этом можно почитать тут.
Если мы “положим на бок” наш девайс, большая часть мобильных приложений “перерисуется” под новые пропорции экрана. Это касается и мобильных браузеров. В этот момент верстка нашего веб-приложения также может сломаться в самых непредсказуемых местах.
Chrome DevTools умеет эмулировать оба режима, но все же сам процесс переворота и дальнейшая перерисовка веб-приложения происходит иначе, чем на настоящем мобильном браузере.
То, как наше приложение будет выглядеть после перерисовки обязательно стоит проверить. Причем, желательно, в обе стороны: из portrait в landscape и из landscape в portrait.
Веб-страница в нативном приложении
Еще один распространенный кейс: когда у приложения есть как Mobile Web версия, так и нативное приложение. В этом случае бывает так, что часть страниц в нативное приложение не переносят, а просто отображают их как WebView.
WebView — это компонент, который позволяет встраивать веб-страницы в приложение. Встроенный браузер просто рендерит внутри приложения то, что мы бы увидели на Mobile Web. Довольно часто это экономит время при разработке нативного приложения.
В таком случае стоит проверять изменения Mobile Web не только в браузере, но и внутри нативных приложений тоже. Конечно, тут без мобильного девайса никак не обойтись.
Обработка тапов
В отличие от Desktop Web, где есть только клик мышью, в мобильном приложении существует несколько способов взаимодействия с интерфейсом: touch, tap, flick и так далее. Об этом много где можно почитать, например тут.
Chrome DevTools умеет эмулировать часть этих действий. Но, во-первых, не все. А, во-вторых, не всегда результат во время эмуляции такой же, как во время использования реального девайса.
Даже если ваше мобильное веб-приложение не заточено под специальные действия, все равно стоит проверить взаимодействие интерфейса хотя бы с tap’ом. Особенно такие места, как меню или какие-нибудь переключатели. Суть в том, что tap не попадает в какие-то конкретные координаты. Он попадает на целую область. Если ваши элементы управления находятся рядом, tap может влиять на несколько элементов сразу и доставлять неудобство пользователю.
Итого
Я рассказал об основных особенностях тестирования Mobile Web проектов. Если вы пришли из тестирования Desktop Web, этот список скорее всего вам пригодится. Само собой, это не все, что можно было вспомнить касательно данного вопроса. Если хотите дополнить список, обязательно пишите в комментариях те проверки, которые делаете вы.
В этой статье мы рассмотрим тестирование веб приложений и сайтов. Она довольно длинная, поэтому усаживайтесь по удобнее.
Основные виды тестирования сайта (веб-приложения)
- Тестирование функциональности;
- Тестирование удобства использования;
- Тестирование интерфейса;
- Тестирование совместимости;
- Тестирование производительности и скорости загрузки сайта;
- Тестирование безопасности.
Тестирование функциональности
Проверьте все ссылки, присутствующие на веб-странице, а также ссылки на базы данных, формы, используемые для подтверждения действий и получения информации от пользователей, файлы Cookie и т.д.
Проверьте все ссылки
- Проверьте ссылки, исходящие от всех страниц к конкретному домену.
- Внутренние ссылки.
- Ссылки на другие элементы, расположенные внутри страниц.
- Ссылки для отправления электронной почты администратору или другим пользователям веб-страниц.
- Проверьте, нет ли ссылок на изолированные страницы.
Проверьте формы
Формы используются для получения информации от пользователей и взаимодействия с ними.
Что нужно проверить в формах:
- Правильность работы валидации в каждом поле формы.
- Значения полей, используемые по умолчанию.
- Опции для создания форм, удаления, просмотра и редактирования форм ( если такие имеются ).
Рассмотрим пример проекта поисковой системы, над которым я сейчас работаю. В проекте есть этапы регистрации рекламодателей и партнеров. Каждый шаг регистрации отличается от других, но зависит от остальных этапов. Поэтому весь процесс регистрации должен проходить правильно.
Есть различные виды валидации, например, проверка электронной почты, финансовой информации пользователя и т.д. Все поля с валидацией нужно протестировать в ручном или автоматическом режиме.
Тестирование файлов cookie
Проверьте, шифруются ли Cookie перед записью на компьютере. Протестируйте сеансы регистрации и статистику пользователя, когда сеанс посещения сайта закончится. Проверьте, влияет ли на безопасность приложения удаление файлов cookie .
Проверьте HTML/CSS
Если вы оптимизируете сайт для поисковых систем, то валидация HTML/CSS особенно важна. Первым делом проверьте сайт на наличие синтаксических ошибок в HTML-коде . Проверьте, доступен ли сайт для различных поисковых систем.
Тестирование базы данных
Взаимодействие веб-приложения с базой данных является очень важным моментом. Проверьте целостность данных и проведите тестирование сайта на наличие ошибок при редактировании, удалении, изменении форм или других действиях, имеющих отношение к базе данных.
Проверьте, все ли запросы к базе данных выполняются правильно, данные извлекаются и обновляются должным образом.
При тестировании функциональности сайтов нужно проверить:
Ссылки
- Внутренние ссылки;
- Внешние ссылки;
- Ссылки на электронную почту;
- Битые ссылки.
Формы
База данных
Следует проверить целостность базы данных.
Тестирование удобства использования (юзабилити сайта)
Тестирование юзабилити — это анализ взаимодействия пользователя и сайта, поиск ошибок и их устранение.
При этом проверяется:
- Легкость обучения;
- Навигация;
- Субъективная удовлетворенность пользователей;
- Общий вид.
Проверка навигации
Под навигацией подразумеваются средства для просмотра страниц пользователем. Это кнопки, блоки. А также то, как посетитель сайта использует ссылки на другие страницы.
- Сайт должен быть простым в использовании;
- Инструкции должны быть очень четкими;
- Проверьте, достигают ли предоставленные инструкции поставленной цели;
- Главное меню должно быть доступно на каждой странице;
- Главное меню должно быть построено в логической последовательности.
Проверка контента
Контент должен быть логичным и простым для понимания. Проверьте текст на наличие ошибок. Применение темных цветов раздражает пользователей, не нужно использовать их в теме оформления.
Для контента и фона страницы лучше применять общепринятые стандарты, чтобы цвет шрифта, рамок и т.д. не раздражал пользователей.
Контент должен быть содержательным, ссылки работать надлежащим образом, изображения соответствующего размера. Это основные стандарты, соблюдаемые при веб-разработке. Ваша задача — проверить все в рамках тестирования пользовательского интерфейса.
Другая информация для пользователей
Варианты поиска, карта сайта, справочные материалы и т.д. Проверьте работу всех ссылок в карте сайта. Функция « Поиск по сайту » должна помогать легко находить нужный контент.
Тестирование пользовательского интерфейса
Нужно проверить, правильно ли осуществляется связь с сервером. Следует проверить совместимость сервера с используемым программным обеспечением, аппаратными средствами, сетью и базой данных.
- Интерфейсы веб-сервера и приложения.
- Интерфейсы сервера базы данных и сервера приложения.
Проверьте, что происходит, когда пользователь прерывает какое-либо действие. А также, что происходит при повторном подключении к серверу в ходе выполнения какой-либо операции.
Проверка совместимости
- Совместимость с браузерами;
- Совместимость с операционными системами;
- Просмотр на мобильных устройствах;
- Параметры печати.
Совместимость с браузерами
Работа некоторых веб-приложений зависит от типа браузера. Сайт должен быть совместим с различной конфигурацией и параметрами разнообразных браузеров.
Верстка сайта должна быть кроссбраузерной. При использовании Java-скриптов и AJAX , обеспечивающего функциональность пользовательского интерфейса, проверки безопасности или валидации создают большую нагрузку на систему.
Проверьте работу веб-приложения в браузерах Internet Explorer , Firefox , Netscape Navigator , AOL , Safari , Opera разных версий.
Совместимость с операционными системами
Некоторые функции веб-приложения могут быть несовместимы с определенными операционными системами. Не во всех из них поддерживаются новые технологии, используемые в веб-разработке. Поэтому проверьте работу приложения в Windows , Unix , MAC , Linux , Solaris и их различных версиях.
Просмотр на мобильных устройствах
Проведите тестирование сайта на мобильных устройствах и проверьте, как просматриваются веб-страницы с помощью мобильных браузеров. Проблемы с совместимостью также могут возникнуть из-за мобильных устройств. Также не стоит забывать о тестировании сайта на разных разрешениях.
Параметры печати
Тестирование производительности сайта
Тестирование производительности сайта или веб-приложения должно включать в себя:
- Нагрузочное тестирование.
- Стрессовое тестирование.
Проверьте производительность приложения на различной скорости интернета.
Нагрузочное тестирование сайта ( веб-приложения ) — это тестирование, при котором большое количество пользователей одновременно выполняют запрос к одной и той же странице. Выдерживает ли система пиковые нагрузки?
Стрессовое тестирование — нагрузка системы, выходящая за пределы установленных лимитов. Стрессовое тестирование выполняется с целью достичь сбоя в работе сайта или веб-приложения путем увеличения нагрузки. А также проверить, как система реагирует на стресс, и как она восстанавливается после сбоев. Стрессовой нагрузке подвергают поля для ввода информации, входа и регистрации.
ab тестирование функциональности также включает в себя проверку на ошибки, связанные с оперативной памяти.
Тест производительности можно применять для проверки масштабируемости сайта или оценки продуктивности при использовании стороннего программного обеспечения.
Скорость соединения
Сплит тестирование сайта при использовании различных вариантов интернет-соединения: через модем, ISDN и т.д.
Нагрузка
- Количество пользователей, одновременно посещающих сайт;
- Проверьте работу системы при пиковых нагрузках;
- Пользователь осуществляет доступ к большому количеству данных.
Стрессовая нагрузка
- Непрерывная нагрузка;
- Производительность памяти, процессора, обработки файлов и т. д.
Тестирование безопасности
Ниже приведены некоторые наборы для тестирования веб-безопасности:
Основной причиной тестирования безопасности сайта является поиск потенциальных уязвимостей и их последующее устранение.
- Сетевое сканирование;
- Сканирование уязвимостей;
- Возможность потенциального взлома паролей;
- Обзор журнала;
- Средства для проверки целостности;
- Обнаружение вирусов.
Моменты, которые следует учитывать при тестировании сайта
Следует обратить внимание на взаимодействие HTML-страниц , интернет-подключение, брандмауэры, приложения, запускаемые на веб-страницах ( апплеты, JavaScript , модульные приложения ), а также приложения, работающие на стороне сервера ( скрипты CGI , интерфейсы баз данных, генераторы динамических веб-страниц ).
Есть множество типов серверов и браузеров различных версий. Между ними есть небольшие, но значимые различия.
Пример сценариев тестирования сайта
Дополнительные факторы, которые следует учесть при тестировании сайта:
- Какова ожидаемая нагрузка на сервер ( например, количество запросов за единицу времени )?
- Какая производительность требуется при различных видах нагрузки ( время ответа веб-сервера, время отклика базы данных на запрос )?
- Какие инструменты потребуются для тестирования производительности?
- Кто является целевой аудиторией? Какие браузеры будут использовать пользователи? Какова скорость подключения? Предназначен ли сайт для использования внутри организации или будет доступен в интернете для широкого круга пользователей?
- Какую производительность ожидает получить клиент ( насколько быстро должны загружаться страницы, как должны себя вести анимации, апплеты, нагрузка и запуск )?
- Будут ли разрешены простои сервера и техническое обслуживание, а также обновление контента? Если да, в каком количестве?
- Какие средства безопасности требуются ( файерволы, шифрование, пароли и т.д. ), и какую работу они будут выполнять? Как их можно проверять?
- Насколько надежным должно быть интернет-соединение? Как оно будет влиять на резервное копирование системы?
- Как будет выполняться управление обновлением контента сайта?
- Требования для технического обслуживания, отслеживания и контроля содержимого веб-страниц, графических элементов, ссылок и т.д.
- Какая спецификация HTML будет соблюдаться? Насколько точно?
- Как будут проверяться и обновляться внутренние и внешние ссылки? Насколько часто?
- Как будет происходить управление и проверка CGI апплетов, сценариев JavaScript , компонентов ActiveX и т.д.?
- Максимальный размер веб-страницы не должен превышать 3-5 экранов, кроме случаев, когда контент сосредоточен на одной теме. Если размер веб-страницы больше, предоставьте внутренние ссылки для навигации по ней.
- Разметка веб-страницы и элементы дизайна должны быть последовательными и логично связанными.
- Отображение веб-страниц должно быть независимо от типа браузера.
- На каждой странице следует указать ссылку для связи.
Пожалуйста, опубликуйте ваши отзывы по текущей теме статьи. За комментарии, отклики, дизлайки, лайки, подписки огромное вам спасибо!
Дайте знать, что вы думаете по этой теме материала в комментариях. За комментарии, подписки, дизлайки, отклики, лайки огромное вам спасибо!
Что пишут в блогах
- Расписание на декабрь
- Как вырасти из тестировщика в тест-менеджера
- Организация обучения джуниоров внутри команды. 2 декабря, Кострома
- Автоматизация рутины. Скачиваем файлы через bash
- Панбагон. 12 часов — опасное время
- Оффер сразу после курса для тестировщиков с нуля. Что бывает, если выйти из зоны комфорта
- Мои 12 недель в году. Часть 17 (переезд, ДР и пневмония)
- Как тестировщику с небольшим опытом подготовиться и сдать экзамен ISTQB FL: интервью
- Метрики в тестировании: какие выбрать и что делать, когда они становятся KPI?
- Александр Александров про тренды и технологии тестирования, про влияние Covid19 на рынок QA
Онлайн-тренинги
Что пишут в блогах (EN)
Разделы портала
Про инструменты
Автор: Яковлев Станислав — Team Lead команды тестирования сервиса Юла, телеграмм канал t.me/qa_chillout
Функциональное тестирование
В данном пункте нам важно убедиться, что наш продукт соответствует нужной функциональной спецификации, упомянутой в документации по разработке.
Что проверяем?
Интеграционное тестирование
Интеграционное тестирование проводится для того, чтобы убедиться, что ваше приложение совместимо со сторонними сервисами.
Что проверяем?
- Проверяем работу сторонних модулей: оплата, шаринг, карты.
- Реклама (просмотр, переходы по рекламе, аналитика).
- Метрики (переходы по страницам, показы элементов, клики).
Тестирование безопасности
Данная проверка нацелена на поиск недостатков и пробелов с точки зрения безопасности нашего приложения.
Что проверяем?
Тестирование локализации и глобализации
Тестирование интернационализации/глобализации WEB приложения включает тестирование приложения для различных местоположений, форматов дат, чисел и валют. Тестирование локализации включает тестирование WEB приложения с локализованными строками, изображениями и рабочими процессами для определенного региона.
Что проверяем?
- Дата и время. Например отображение времени, даты в соответствии с часовым поясом пользователя.
- Смена языка и проверка перевода всех элементов WEB приложения исходя из выбранного языка.
- Выбор номера телефона с разными кодами стран.
- Определение местоположения пользователя и отображение соответствующего пермишена ГЕО.
- Отображение соответствующих символов валюты.
Тестирование удобства использования
Тестирование удобства использования подразумевает проверку навигации, контента, другая информация для пользователя.
Что проверяем?
Кросс-платформенное тестирование
Кросс-платформенное тестирование проводится, чтобы убедиться, что ваше приложение совместимо с другими браузерами, различными оболочками, аппаратным обеспечением устройства.
Что проверяем?
- Тестирование в различных браузерах (Firefox, Chrome, Safari — это минимальный набор): анимация, верстка, шрифты, уведомления и т.д.
- Тестирование в различных версиях ОС: Windows, Mac, Linux.
- Java Script код работает в разных браузерах.
- Просмотр на мобильных устройствах.
Резюме
Мы ознакомились с универсальной шпаргалкой по тестированию WEB приложений. Не забывайте читать документацию и дополнять чек-лист проверками, характерными для вашего сервиса. А если остались вопросы — скорее пишите в телеграм-канал @qa_chillout.
Ваш пошаговый алгоритм тестирования мобильных приложений
Обеспечение качества (QA, от английского - Quality Assurance) является неотъемлемой частью жизненного цикла разработки любых приложений, включая мобильные. К сожалению, многие упускают из виду критические особенности тестирования мобильных приложений, которые часто приводят к сбоям, ошибкам в работе приложения и плохому качеству обслуживания клиентов.
Чтобы обеспечить успешную разработку любого приложения, специалист-тестировщик должен принимать участие во всех этапах разработки - от создания концепции и анализа требований, до создания спецификаций тестирования и выпуска готового продукта. Обеспечение качества также является ключевым элементом в последующих, после прохождения этапов разработки, обзорах программного продукта.
Однако часто бывает сложно определить, с чего начать организацию процесса тестирования мобильного приложения. Для беспроблемного тестирования мы рекомендуем просто выполнить девять указанных ниже шагов.
Давайте рассмотрим особенности тестирования мобильных приложений.
Цикл жизни спринтов
Этап 1: Планирование
Когда этап разработки приложения почти завершен, вы должны снова поставить перед собой вопрос - чего вы пытаетесь достичь разработкой данного приложения и какие у вас есть ограничения.
- Взаимодействует ли ваше приложение с другими приложениями?
- Насколько функциональны все возможности приложения?
- Является ли тестируемое мобильное приложение нативным, Mobile-web или гибридным?
- Ограничена ли задача тестирования приложения тестированием только внешнего интерфейса?
- Стоят ли задачи на тестирование бэкенда?
- Какова должна быть совместимость с различными беспроводными сетями?
- Как сильно данные приложения и свободное пространство, занимаемое им, зависят от особенностей использования приложения?
- Насколько быстро загружается ваше приложение, насколько быстро происходит серфинг по меню приложения и его функциям?
- Как будет обрабатываться возможное увеличение нагрузки на приложение?
- Влияют ли различные изменения в статусе и состоянии телефона на работу мобильного приложения?
Убедитесь, что вы договорились с командой тестировщиков о роли каждого из них и о ваших ожиданиях от процесса тестирования. В конце концов, общение является ключом к поддержанию правильной рабочей среды в команде.
Правильное понимание ролей и задач также относится и к моменту прописывания списка тест кейсов. Вся команда QA должна поддерживать и обновлять этот документ с отчетами по тестированию всех функций, реализованных на протяжении всего процесса разработки.
Этап 2. Определение необходимых типов тестирования мобильных приложений
Перед тестированием любых мобильных приложений определите, что именно в данном мобильном приложении вы хотите протестировать: набор функциональности, удобство использования, совместимость, производительность, безопасность и т. д. На этом же этапе имеет смысл выбрать методы тестирования мобильного приложения.
Тема связана со специальностями:
Определите, на какие целевые устройства направлено данное приложение, и какие требования к функционалу следует проверить.
Вы также должны определить, какие целевые устройства нужно включить в список тестирования.
Вы можете сделать это следующим образом:
• Выяснить, какие устройства будет поддерживать приложение;
• Определить, какая версия операционной системы будет самой ранней из тех, что поддерживаются приложением;
• Выявить наиболее популярные модели мобильных устройств у целевой аудитории;
• Определить набор не основных (дополнительных) устройств с экранами разных размеров, потенциально поддерживаемых приложением;
• Решить, будете ли вы использовать для тестирования физические устройства или их эмуляторы.
Этап 3: Тестовые случаи и разработка сценариев тестирования приложения
Подготовьте документ, описывающий тестовые случаи (test cases) для каждой тестируемой функции и функциональности.
В дополнение к функциональным тестовым случаям, также должны быть охвачены некоторые отдельные моменты (кейсы):
• Особенность использование батареи;
• Скорость работы приложения;
• Требования к данным;
• Объем используемой памяти.
Также перед началом тестирования важно определиться, какое сочетание ручного и автоматического тестирования вы будете применять.
При необходимости подготовьте отдельные наборы ручных тестовых случаев и сценариев для автоматического тестирования и адаптируйте их согласно требованиям проекта.
Этап 4: Ручное и автоматическое тестирование
Теперь пришло время для выполнения ручных и автоматизированных тестов.
Ранее, на предыдущих этапах, вы уже определили, какие тесты и скрипты использовать и подготовили их. Теперь, на текущем этапе, вы выполняете запуск тестов для проверки механизмов основной функциональности, чтобы убедиться в отсутствии поломок.
Автоматизированное тестирование мобильных приложений хорошо экономит время и другие ресурсы тестировщиков.
Этап 5: Тестирование юзабилити и бета-тестирование
После того, как базовый функционал протестирован, настало время убедиться, что мобильное приложение является достаточно простым в использовании и обеспечивает удовлетворительный пользовательский опыт. На этом этапе необходимо поддерживать соответствие матрице кроссплатформенности, чтобы обеспечить охват пользователей различных платформ, достигнутый бета-тестерами.
Пример матрицы поддержки разных версий платформы iOs
После того, как приложение будет протестировано внутри компании, вы сможете выпустить бета-версию приложения на рынок.
Тестирование совместимости
Мобильные устройства различаются в зависимости от платформы, модели и версии их операционной системы. Важно выбрать такое подмножество устройств, которое будет соответствовать вашему приложению.
Тестирование пользовательского интерфейса
Пользовательский опыт является ключевым элементом, при тестировании приложения. Ведь наше приложение разрабатывается именно для конечных пользователей. Вам следует качественно проверить удобство использования приложения, навигацию по его элементам и контент. Тестируйте меню, опции, кнопки, закладки, историю, настройки и навигацию приложения.
Тестирование интерфейса
Тестирование пунктов меню, кнопок, закладок, истории, настроек и навигации по приложению.
Тестирование внешних факторов
Приложения для мобильных устройств не будут единственными приложениями на устройстве пользователя. Вместе с вашим приложением будут установлены приложения от сторонних разработчиков. Возможно десятки таких приложений. Следовательно, вашему приложению придётся взаимодействовать с этими сторонними приложениями и прерывать работу различных функций устройства, таких как различные типы сетевых подключений, обращение к SD-карте, телефонные звонки и другие функции устройства.
Тестирование доступности
Мобильными устройствами могут пользоваться различные люди с ограниченными возможностями. По этой причине важно протестировать возможность работы с приложением людей с дальтонизмом, нарушениями слуха, проблемами пожилого возраста и другими возможными проблемами. Такое тестирование является важной частью общего тестирования юзабилити.
Видео курсы по схожей тематике:
Автоматизация тестирования мобильных приложений
Этап 6: Тестирование производительности
Мобильные устройства предоставляют для приложений меньший объем памяти и меньшую доступную мощность процессора, чем стационарные компьютеры и ноутбуки. По этой причине в работе мобильных приложений очень важна эффективность использования предоставляемых ресурсов. Вам следует проверить работоспособность тестируемого приложения, изменив соединение с 2G, 3G на WIFI, проверить скорость отклика, потребление заряда батареи, стабильность работы и т. д.
Рекомендуется проверять приложение на предмет масштабируемости применения и наличие возможных проблем с производительностью.
В рамках этого этапа важно пройти и нагрузочное тестирование мобильного приложения.
Функциональное тестирование
Функциональное тестирование мобильного приложения, по большей части, может быть выполнено так же, как вы выполнили бы его для любого другого типа приложения. По этой причине мы не будем вдаваться в подробности этого типа тестирования. Однако следует указать области, которые имеют особое значение для мобильных приложений.
Имейте в виду, что функциональное тестирование должно включать в себя тестирование всех функций приложения и не должно быть излишне сосредоточено на какой-то одной функции.
В рамках функционального тестирования, вам следует выполнить следующие тесты:
Этап 7: Аттестационное тестирование и тестирование безопасности приложения
Безопасность и конфиденциальность данных имеют огромное значение в наше время. Пользователи требуют, чтобы вся их информация хранилась безопасно и конфиденциально.
Убедитесь, что тестируемое приложение надежно защищено. Выполните проверку на возможность внедрения SQL инъекций, на возможность перехвата сеансов, анализа дампов данных, анализа пакетов и SSL трафика.
Очень важно проверить безопасность хранилища конфиденциальных данных вашего мобильного приложения и его поведение в соответствии с различными схемами разрешений для устройств.
Помимо проверки безусловного шифрования имен пользователей и паролей, задайте себе следующие вопросы:
• Есть ли у приложения сертификаты безопасности?
• Использует ли приложение безопасные сетевые протоколы?
• Существуют ли какие-либо ограничения, например количество попыток входа в систему до блокировки пользователей?
Этап 8: Тестирование устройства
Выполните тесты по тем алгоритмам, которые вы ранее прописали в тестовых случаях и сценариях тестирования на всех определенных для тестирования устройствах, в облаке и / или на физических устройствах.
Этап 9: контрольный этап и резюме
Этот этап включает в себя подробное и полное тестирование - от ранних итеративных этапов тестирования до регрессионных тестов, которые все еще могут потребоваться для стабилизации работы приложения и выявления незначительных дефектов.
На этом этапе тестирования вы можете добавить для проверки новые функции и изменить настройки на те, которых не будет в финальной версии.
После завершения тестирования приложения, дополнительные параметры и функции, добавленные для проверки на этом этапе, удаляются, и окончательная версия становится готовой для представления общественности.
Итоговый отчет о тестировании
Весь процесс тестирования мобильных приложений должен быть тщательно задокументирован. Проверьте дважды, сделаны ли нужные записи, и после этого сформируйте свой окончательный отчет о тестировании (test summary report).
Этот отчет должен включать:
• Важную информацию, выявленную в результате проведенных испытаний;
• Информацию о качестве проводимого тестирования;
• Сводную информацию о качестве тестируемого мобильного приложения;
• Статистику, полученную из отчетов об различных инцидентах;
• Информацию о видах тестирования и времени, затраченном на каждый из них.
Следует также указать в отчете, что:
• данное мобильное приложение пригодно для использования в том качестве, в котором заявлено;
• соответствует всем критериям приемлемости функционала и качества работы.
Бесплатные вебинары по схожей тематике:
Паттерны автоматизации тестирования
QA практикум. Техники тест дизайна. Часть 1
Kibana в жизни тестировщика
Вооружившись сводкой, руководство проекта теперь может решить, готово ли мобильное приложение к выпуску на рынок.
Тестирование мобильных приложений - сложная задача. Приспосабливая эти этапы тестирования к каждому разрабатываемому приложению и тщательно выполняя каждый шаг - вы гарантированно получите полнофункциональный качественный продукт.
В данной статье мы рассмотрели особенности тестирования мобильных приложений. Рассмотренные этапы тестирования важны и для тестирования андроид приложений и как ответ на вопрос как тестировать приложения для iphone.
Важно помнить, что тестирование приложений перед представлением на рынке – важный этап в разработке любых приложений. И, конечно же, тестирование мобильных приложений имеет свои особенности и важные моменты.
Ответственно подходите к вопросу разработки и тестирования мобильных приложений, своевременно изучая и применяя актуальные методики и технологии. С нашей стороны мы рекомендуем для изучения курс на ITVDN - Unit тестирование для Android разработчиков.
Читайте также: