Добавлен: 01.04.2023
Просмотров: 87
Скачиваний: 1
Мобильное приложение - это постоянный труд
С выпуском приложения работа над ним не заканчивается. В приложение еще нужно привлечь пользователей. Собирать метрики и анализировать их поведение, чтобы найти способ, как сделать продукт еще лучше.[13]
Вывод
Создание даже простого ПО требует проработки каждой фазы разработки. Необходим четкий план действий для тех, кто хочет, чтобы их приложение было востребованным.
Глава 2 Тестирование
Функциональное тестирование мобильных приложений обычно охватывает тестирование взаимодействия с пользователем, а также тестирование транзакций. Важные для этого вида тестирования факторы:
Тип приложения, определяемый его бизнес-функциональностью (банкинг, игровая индустрия, социальные сети, образование).
Целевая аудитория (пользователь, компания, образовательная среда).
Канал, по которому распространяется приложение (например, App Store, Google Play или раздача напрямую).
Говоря простым языком, мы проверяем, выполняет ли приложение ожидаемые функции, которые обычно описаны в спецификации или продиктованы бизнес-процессами.
Поэтому функциональное тестирование может проводиться на основе требований. В этом случае формируются тестовые случаи (Test cases), для их создания используется техническое задание на основе бизнес-процессов. После этого создают, так называемые случаи использования (Use cases). Они описывают сценарии ежедневного или постоянного использования приложения.
Основные сценарии функциональных тестов:
Проверить корректность работы обязательных полей.
Убедиться, что обязательные поля отображаются на экране не так, как необязательные.[14]
Убедиться, что работа приложения во время запуска/выхода удовлетворяет основным требованиям.
Убедиться, что приложение переходит в фоновый режим в случае входящего звонка. Для этого вам понадобится еще один телефон.[15]
Проверить, может ли телефон хранить, принимать и отправлять SMS-сообщения во время работы приложения. Для этого вам понадобится другой телефон, с которого можно отправить сообщение на тестируемое устройство с уже запущенным приложением.
Убедиться, что устройство работает в многозадачном режиме, когда это необходимо.
Проверить, как функционируют необходимые опции для работы с социальными сетями — Поделиться, Публикация, Навигация.
Убедиться, что приложение поддерживает платежные операции через системы оплаты Visa, Mastercard, Paypal и др.
Проверить адекватность работы сценариев прокрутки страницы.
Проверить, присутствует ли надлежащая навигация между важными модулями приложения.
Убедиться, что количество ошибок округления минимально.
Проверить наличие сообщений об ошибках, например, сообщения «Ошибка сети. Пожалуйста, попробуйте позже» в случае некорректной работы сети.
Убедиться, что установленное приложение не препятствует нормальной работе других приложений и не съедает их память.
Проверить, способно ли приложение вернуться в то состояние, в котором оно находилось перед приостановкой (например, жесткая перезагрузка или системный сбой).
Установка приложения должна проходить без значительных ошибок при условии, что устройство соответствует системным требованиям.
Убедиться, что автоматический запуск приложения работает корректно.
Проверить, как приложение работает на всех устройствах поколений 2G, 3G и 4G.[16]
Выполнить регрессивное тестирование для выявления новых программных ошибок в существующих и уже модифицированных областях системы. Дополнительное проведение всех предыдущих тестов для проверки поведения программы после изменений.
Убедиться, что существует доступное руководство пользователя.
Руководитель отдела разработки AGIMA.mobile система обладает большим количеством функций, и не всегда есть возможность проверить их все. Поэтому перед началом функционального тестирования обычно приоритезируют те или иные тест-кейсы и юз-кейсы, в соответствии с расставленными приоритетами распределяют время и затем уделяют внимание наиболее важным. Выделить какие-то стандартные сценарии для функциональных тестов довольно сложно из-за разнообразия приложений, но можно выделить часто встречающиеся модули, составить для них тест-кейсы и в дальнейшем использовать их, модифицируя под конкретные требования.
Для каждой функции необходимо проверять как позитивные сценарии, так и негативные. Сценарий считается позитивным, если в итоге пользователь достигает своей цели (создает item, отправляет сообщение и т.д.). Негативный, соответственно, наоборот — на каком-то из шагов происходит ошибка, и цель не может быть достигнута.
К примеру, рассмотрим логин/логаут и создание контакта (раздела, пользователя, или любого другого item). Стандартный логин/логаут может включать в себя опции:
регистрация: с логином и паролем, без пароля, через соц.сети и т.д.;
авторизация: с логином и паролем, через соц.сети и т.д.;
восстановление пароля;
выход из системы: самостоятельный, по истечению сессии и т.д.
Позитивные сценарии:
Регистрация в приложении доступна всеми описанными в ТЗ способами.[17]
Можно зарегистрироваться, заполнив только обязательные поля.
Можно зарегистрироваться, заполнив полностью все поля.
После регистрации можно авторизоваться в приложении. При этом введенные данные корректно сохранены в профиле (e-mail, пароль, личная информация и т.д.).
Зарегистрировавшись на одном устройстве, можно авторизоваться на другом — данные корректно сохраняются на сервере и доступны.
Выход из системы работает корректно.
Восстановление пароля работает корректно.
Негативные сценарии (самое очевидное):
Повторная регистрация на один и тот же e-mail, с одним и тем же логином недоступна.
Регистрация без заполнения обязательных полей недоступна.
Регистрация, если все поля оставлены пустыми, недоступна.
Регистрация, если формат введенных данных не соответствует требованиям, недоступна.
Авторизация с пустыми полями недоступна.
Авторизация с неправильным/удаленным/заблокированным логином недоступна.
Авторизация с неправильным паролем недоступна.
Создание контакта. Логично предположить, что если пользователь создает контакт, то должна быть возможность его просмотреть, отредактировать и удалить. Это базовый набор функций, которыми может обладать item.
Позитивные сценарии:
Создание, изменение, просмотр и удаление контактов доступны.
Создание контакта с минимальным набором данных доступно.[18]
Создание контакта с максимальным набором данных доступно.
При создании корректно обрабатываются все описанные в ТЗ типы данных.
После создания контакт доступен для просмотра.
Изменение учитывает обязательные поля/данные/элементы. Сохранить контакт без них недоступно.
После удаления контакт больше не доступен.
Негативные сценарии:
Создание двух одинаковых контактов недоступно (это может быть и позитивным сценарием).
Создание контакта с отсутствующими обязательными элементами/данными недоступно.
Сюда же, к функциональному тестированию, отнесу проверку пользовательского интерфейса:
Проверка экранов на совпадение с макетами.
Проверка работы «нативных» жестов: свайп, мультитач и т.д. — приложение должно реагировать на них определенным образом.
Проверка состояний элементов: кнопки изменяют цвет, если нажаты; списки сворачиваются и разворачиваются и т.д.
Проверка локализации, если таковая заявлена в приложении. При этом важно уделить внимание верстке — многие названия на других языках гораздо длиннее, чем на английском или на русском. [19]
Тестирование производительности
Также известно как нагрузочное тестирование. Это автоматизированное тестирование, которое имитирует работу определенного количества пользователей какого-либо общего ресурса.
Основные задачи:
Определить количество пользователей, которые могут одновременно работать с приложением.
Проверить, как ведет себя приложение при увеличении интенсивности выполнения каких-либо операций.
Проверить работоспособность приложения при многочасовом использовании на средней нагрузке.
Проверить поведение приложения в стресс-условиях.
Проверить работу в условиях «разросшейся» базы данных — насколько быстро выполняются запросы.
Основная цель этого вида тестирования — убедиться в том, что приложение работает приемлемо при определенных требованиях производительности: доступ большому числу пользователей, устранение важного элемента инфраструктуры, как, например, сервера базы данных, и др.
Основные сценарии тестирования производительности мобильных приложений:
Определить, работает ли приложение одинаково в разных условиях загрузки сети.[20]
Выяснить, способно ли текущее покрытие сети обеспечить работу приложения на различных уровнях пользовательской нагрузки.
Выяснить, обеспечивает ли существующая клиент-серверная конфигурация оптимальную производительность.
Найти различные узкие места приложения и инфраструктуры, которые снижают производительность приложения.[21]
Проверить, соответствует ли требованиям время реакции приложения.
Оценить способность продукта и/или аппаратного обеспечения справляться с планируемыми объемами нагрузки.
Оценить время, в течение которого аккумулятор может поддерживать работу приложения в условиях планируемых объемов нагрузки.
Проверить работу приложения в случаях перехода из Wi-Fi-сети в мобильную 2G/3G-сеть и наоборот.
Проверить, что каждый из уровней памяти процессора работает оптимально.
Убедиться в том, что потребление батареи и утечка памяти не выходят за пределы нормы, а работа различных ресурсов и сервисов, таких как GPS-навигация или камера, соответствует требованиям.
Проверить стойкость приложения в условиях жесткой пользовательской нагрузки.
Проверить эффективность сети в условиях, когда устройство находится в движении.
Проверить производительность приложения, если оно работает в условиях непостоянного подключения к интернету.
Тестирование безопасности
Это стратегия тестирования, используемая для проверки безопасности системы, а также для анализа рисков, связанных с обеспечением целостного подхода к защите приложения, атак хакеров, вирусов, несанкционированного доступа к конфиденциальным данным.
Основная цель этого типа тестирования — обеспечить безопасность сети и данных приложения.
Ниже приведены ключевые действия для проверки безопасности мобильного приложения.[22]
Убедиться в том, что данные пользователей приложения — логины, пароли, номера банковских карт — защищены от сетевых атак автоматизированных систем и не могут быть найдены путем подбора.
Удостовериться в том, что приложение не дает доступ к секретному контенту или функциональности без надлежащей аутентификации.
Убедиться в том, что система безопасности приложения требует надежного пароля и не позволяет взломщику завладеть паролями других пользователей.
Убедиться в том, что время таймаута сессии адекватно для приложения.
Найти динамические зависимости и принять меры для защиты этих уязвимых участков от взломщиков.
Защитить приложение от атак типа SQL-injection.
Найти случаи неуправляемого кода и устранить его последствия.
Удостовериться в том, что срок действия сертификатов не истек, вне зависимости от того, использует приложение Certificate Pinnig или нет.
Защитить приложение и сеть от DoS-аттак.
Проанализировать требования хранения и проверки данных.
Обеспечить управление сеансами для защиты информации от неавторизованных пользователей.
Проверить все криптографические коды и, если необходимо, исправить ошибки.
Удостовериться в том, что бизнес-логика приложения защищена и не подвержена атакам извне.
Проанализировать взаимодействие файлов системы, выявить и скорректировать уязвимые места.
Проверить обработчики протокола (например, не пытаются ли перенастроить целевую страницу по умолчанию, используя вредоносные плавающие фреймы).