Мобильное тестирование: полное руководство26.05.2015 14:32

Александр Шитиков, руководитель отдела разработки AGIMA.mobile, прокомментировал перевод статьи о шести основных типах тестирования мобильных приложений.

26.05.2015 | Автор: Guru99, перевод: AGIMA.mobile

Александр Шитиков Руководитель отдела разработки AGIMA.mobile

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

Вам подойдет один из представленных ниже типов в зависимости от того, какую цель вы преследуете:

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

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

Целевая аудитория (пользователь, компания, образовательная среда).

Канал, по которому распространяется приложение (например, App Store, Google Play или раздача напрямую).

Комментарий: Александр Шитиков Руководитель отдела разработки AGIMA.mobile

Говоря простым языком, мы проверяем, выполняет ли приложение ожидаемые функции, которые обычно описаны в спецификации или продиктованы бизнес-процессами.

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

Основные сценарии функциональных тестов:

Проверить корректность работы обязательных полей.

Убедиться, что обязательные поля отображаются на экране не так, как необязательные.

Убедиться, что работа приложения во время запуска/выхода удовлетворяет основным требованиям.

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

Проверить, может ли телефон хранить, принимать и отправлять SMS-сообщения во время работы приложения. Для этого вам понадобится другой телефон, с которого можно отправить сообщение на тестируемое устройство с уже запущенным приложением.

Убедиться, что устройство работает в многозадачном режиме, когда это необходимо.

Проверить, как функционируют необходимые опции для работы с социальными сетями — Поделиться, Публикация, Навигация.

Убедиться, что приложение поддерживает платежные операции через системы оплаты Visa, Mastercard, Paypal и др.

Проверить адекватность работы сценариев прокрутки страницы.

Проверить, присутствует ли надлежащая навигация между важными модулями приложения.

Убедиться, что количество ошибок округления минимально.

Проверить наличие сообщений об ошибках, например, сообщения «Ошибка сети. Пожалуйста, попробуйте позже» в случае некорректной работы сети.

Убедиться, что установленное приложение не препятствует нормальной работе других приложений и не съедает их память.

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

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

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

Проверить, как приложение работает на всех устройствах поколений 2G, 3G и 4G.

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

Убедиться, что существует доступное руководство пользователя.

Комментарий: Александр Шитиков Руководитель отдела разработки AGIMA.mobile

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

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

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

регистрация: с логином и паролем, без пароля, через соц.сети и т.д.;

авторизация: с логином и паролем, через соц.сети и т.д.;

восстановление пароля;

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

Позитивные сценарии:

Регистрация в приложении доступна всеми описанными в ТЗ способами.

Можно зарегистрироваться, заполнив только обязательные поля.

Можно зарегистрироваться, заполнив полностью все поля.

После регистрации можно авторизоваться в приложении. При этом введенные данные корректно сохранены в профиле (e-mail, пароль, личная информация и т.д.).

Зарегистрировавшись на одном устройстве, можно авторизоваться на другом — данные корректно сохраняются на сервере и доступны.

Выход из системы работает корректно.

Восстановление пароля работает корректно.

Негативные сценарии (самое очевидное):

Повторная регистрация на один и тот же e-mail, с одним и тем же логином недоступна.

Регистрация без заполнения обязательных полей недоступна.

Регистрация, если все поля оставлены пустыми, недоступна.

Регистрация, если формат введенных данных не соответствует требованиям, недоступна.

Авторизация с пустыми полями недоступна.

Авторизация с неправильным/удаленным/заблокированным логином недоступна.

Авторизация с неправильным паролем недоступна.

Создание контакта. Логично предположить, что если пользователь создает контакт, то должна быть возможность его просмотреть, отредактировать и удалить. Это базовый набор функций, которыми может обладать item.

Позитивные сценарии:

Создание, изменение, просмотр и удаление контактов доступны.

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

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

При создании корректно обрабатываются все описанные в ТЗ типы данных.

После создания контакт доступен для просмотра.

Изменение учитывает обязательные поля/данные/элементы. Сохранить контакт без них недоступно.

После удаления контакт больше не доступен.

Негативные сценарии:

Создание двух одинаковых контактов недоступно (это может быть и позитивным сценарием).

Создание контакта с отсутствующими обязательными элементами/данными недоступно.

Сюда же, к функциональному тестированию, отнесу проверку пользовательского интерфейса:

Проверка экранов на совпадение с макетами.

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

Проверка состояний элементов: кнопки изменяют цвет, если нажаты; списки сворачиваются и разворачиваются и т.д.

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

Тестирование производительности Комментарий: Александр Шитиков Руководитель отдела разработки AGIMA.mobile

Также известно как нагрузочное тестирование. Это автоматизированное тестирование, которое имитирует работу определенного количества пользователей какого-либо общего ресурса.

Основные задачи:

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

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

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

Проверить поведение приложения в стресс-условиях.

Проверить работу в условиях «разросшейся» базы данных — насколько быстро выполняются запросы.

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

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

Определить, работает ли приложение одинаково в разных условиях загрузки сети.

Выяснить, способно ли текущее покрытие сети обеспечить работу приложения на различных уровнях пользовательской нагрузки.

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

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

Проверить, соответствует ли требованиям время реакции приложения.

Оценить способность продукта и/или аппаратного обеспечения справляться с планируемыми объемами нагрузки.

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

Проверить работу приложения в случаях перехода из Wi-Fi-сети в мобильную 2G/3G-сеть и наоборот.

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

Убедиться в том, что потребление батареи и утечка памяти не выходят за пределы нормы, а работа различных ресурсов и сервисов, таких как GPS-навигация или камера, соответствует требованиям.

Проверить стойкость приложения в условиях жесткой пользовательской нагрузки.

Проверить эффективность сети в условиях, когда устройство находится в движении.

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

Тестирование безопасности Комментарий: Александр Шитиков Руководитель отдела разработки AGIMA.mobile

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

Основная цель этого типа тестирования — обеспечить безопасность сети и данных приложения.

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

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

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

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

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

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

Защитить приложение от атак типа SQL-injection.

Найти случаи неуправляемого кода и устранить его последствия.

Удостовериться в том, что срок действия сертификатов не истек, вне зависимости от того, использует приложение Certificate Pinnig или нет.

Защитить приложение и сеть от DoS-аттак.

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

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

Проверить все криптографические коды и, если необходимо, исправить ошибки.

Удостовериться в том, что бизнес-логика приложения защищена и не подвержена атакам извне.

Проанализировать взаимодействие файлов системы, выявить и скорректировать уязвимые места.

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

Защитить приложение от вредоносных атак на клиентов.

Защитить систему от вредоносных внедрений в момент работы программы.

Предотвратить возможные вредоносные последствия кэширования файлов.

Предотвратить ненадежное хранение данных в кэш-памяти клавиатуры устройства.

Предотвратить возможные вредоносные действия файлов cookie.

Обеспечить регулярный контроль безопасности данных.

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

Обезопасить систему от случаев переполнения буфера или нарушения целостности информации в памяти.

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

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

Итак, для проведения юзабилити-тестирования следует:

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

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

Убедиться в том, что значки и картинки смотрятся естественно в среде приложения.

Убедиться в том, что цвет кнопок, выполняющих одну и ту же функцию, совпадает.

Убедиться в правильной работе системы уменьшения и увеличения масштаба просмотра.

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

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

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

Убедиться в том, что текст прост, ясен и виден пользователю.

Убедиться в том, что короткие предложения и абзацы возможно прочитать.

Найти оптимальный размер шрифта.

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

Убедиться в том, что завершить работу приложения можно из любого состояния и что оно возобновляет работу в этом же состоянии.

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

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

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

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

Комментарий: Александр Шитиков Руководитель отдела разработки AGIMA.mobile

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

Тестирование удобства пользования дает оценку уровня удобства использования приложения по следующим пунктам:

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

Правильность (accuracy) — сколько ошибок сделал пользователь во время работы с приложением?

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

Эмоциональная реакция (emotional response) — Как пользователь себя чувствует после завершения задачи: растерян, испытал стресс или, наоборот, ему все понравилось? Порекомендует ли пользователь систему своим друзьям?

Для улучшения удобства использования полезно следовать двум принципам:

«Защита от дурака». Если поле предполагает ввод номера телефона, то стоит ограничить диапазон ввода только цифрами и соответствующим образом сформировать клавиатуру. Аналогично для e-mail и остальных элементов, которые предполагают пользовательский ввод данных.

Использовать цикл Демминга (планирование-действие-проверка- корректировка), то есть собирать информацию о дизайне и удобстве использования у существующих пользователей, и на основе их мнений планировать изменения в приложении.

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

Важнейшие сценарии конфигурационного тестирования:

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

Убедиться в том, что текст легко читается на любом устройстве.

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

Комментарий: Александр Шитиков Руководитель отдела разработки AGIMA.mobile

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

На клиентском уровне можно выделить:

Тип устройства: смартфон, планшет и т.д.

Конфигурация устройства: количество оперативной памяти, тип процессора, разрешение экрана, емкость аккумулятора и т.д.

Тип и версия операционной системы. iOS 6, 7; Android 4.2.2 и т.д.

Тип сети: Wi-Fi, GSM.

Перед проведением конфигурационного тестирования рекомендуется

Создавать матрицу покрытия (матрица покрытия — это таблица, в которую заносят все возможные конфигурации).

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

Шаг за шагом, в соответствии с расставленными приоритетами, проверяют каждую конфигурацию.

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

Тестирование на восстановление Комментарий: Александр Шитиков Руководитель отдела разработки AGIMA.mobile

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

Проверка восстановления после сбоя системы и сбоя транзакций.

Проверка эффективного восстановления приложения после непредвиденных сценариев сбоя.

Проверка способности приложения обрабатывать транзакции в условиях сбоя питания (разряженная батарея / некорректное завершение работы приложения).

Проверка процесса восстановления данных после перерыва в соединении.

Другие важные области проверки:

Тестирование установки (быстрая, соответствующая требованиям установка приложения).

Тестирование удаления (быстрое, соответствующее требованиям удаление приложения).

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

Проверка наличия нефункциональных клавиш.

Проверка экрана загрузки приложения.

Проверка возможности ввода с клавиатуры во время сбоев сети.

Проверка методов запуска приложения.

Проверка наличия эффекта зарядки в случае, если приложение находится в фоновом режиме.

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

Выявление последствий извлечения аккумулятора во время работы приложения.

Проверка уровня потребления энергии приложением.

Проверка побочных эффектов приложения.

Комментарий: Александр Шитиков Руководитель отдела разработки AGIMA.mobile

Отдельно укажу интеграционное тестирование, в рамках которого проводятся проверки взаимодействия модулей друг с другом, а также приложения с операционной системой и другими приложениями.

Сюда попадают все сценарии, связанные с различного рода прерываниями во время работы с приложением:

произошел телефонный звонок;

поступило смс;

на экране появилось уведомление другого приложения;

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

приложение было свернуто в трей;

приложение переведено в фоновый режим и т.д.

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

Вычитано Протекстом

Автор: Guru99, перевод: AGIMA.mobile

Оригинал: http://www.guru99.com/testing-mobile-apps.html