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

⚡ Умное резюме

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

  • 🔘 Функциональный подход прежде всего: Прежде всего, подтвердите обязательные поля, процесс установки, запуск и остановку, платежи и навигацию.
  • ☑️ Перерывы имеют значение: Звонки, сообщения и перезагрузки должны оставлять приложение в восстанавливаемом состоянии.
  • Ограничения производительности: Измеряйте время отклика, расход заряда батареи, утечки памяти и поведение при переключении сети.
  • 🧪 Глубина защиты: Защита от атак, связанных с аутентификацией, истечением срока действия сессии, привязкой сертификатов, внедрением кода и небезопасным локальным хранилищем.
  • 🇧🇷 Правила удобства использования: Скорость работы приложения определяется такими параметрами, как сенсорные области, единообразные значки, читаемый текст и понятный путь отмены действия.
  • 📊 Поддерживаемые устройства: Размеры экрана, разрешение и версии операционной системы — все это влияет на результат, поэтому совместимость обеспечивается на уровне всего набора устройств.

Тестирование мобильных приложений: примеры тестовых случаев и тестовых сценариев.

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

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

Функциональное тестирование мобильного приложения

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

К числу факторов, имеющих значение при функциональном тестировании, относятся:

  1. Тип приложения в зависимости от использования бизнес-функций (банковские, игровые, социальные или деловые).
  2. Target тип аудитории (потребитель, предприятие, образование)
  3. Канал распространения, используемый для распространения приложения (например, Apple App Store). Google (Играть, прямая дистрибуция)

Как показано на диаграмме, эти факторы определяют глубину залегания каждой из областей ниже.

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

К наиболее фундаментальным сценариям функционального тестирования можно отнести следующие:

  1. Чтобы проверить, все ли обязательные поля работают должным образом.
  2. Для проверки того, что обязательные поля отображаются на экране иначе, чем необязательные.
  3. Для проверки корректной работы приложения при его запуске и остановке.
  4. Чтобы проверить, переходит ли приложение в свернутый режим при входящем телефонном звонке, используйте второй телефон для звонка на это устройство. Это и есть суть процесса. тестирование прерываний.
  5. Чтобы проверить, способен ли телефон хранить, обрабатывать и получать SMS-сообщения во время работы приложения, используйте второй телефон для отправки SMS-сообщения на тестируемое устройство, на котором в данный момент запущено тестируемое приложение.
  6. Для подтверждения способности устройства выполнять необходимую многозадачность всякий раз, когда это требуется.
  7. Для проверки того, что приложение поддерживает необходимые функции социальных сетей, такие как обмен информацией, публикация сообщений и навигация.
  8. Для проверки того, поддерживает ли приложение любые платежные системы, такие как Visa, Mastercard или PayPal, в соответствии с требованиями приложения.
  9. Для проверки того, что сценарии прокрутки страниц включены в приложении, если это необходимо.
  10. Для проверки соответствия навигации между соответствующими модулями приложения требуемым параметрам.
  11. Для подтверждения того, что ошибки усечения сводятся к приемлемому пределу.
  12. Для проверки того, получает ли пользователь соответствующее сообщение об ошибке, например, «Сетевая ошибка. Пожалуйста, попробуйте позже», всякий раз, когда возникает сетевая ошибка.
  13. Чтобы убедиться, что установленное приложение обеспечивает удовлетворительную работу других приложений и не потребляет память этих приложений.
  14. Чтобы убедиться, что приложение возобновляет работу с последней операции в случае жесткой перезагрузки или сбоя системы.
  15. Чтобы убедиться, что установка приложения может пройти без проблем при наличии у пользователя необходимых ресурсов и не приведет к каким-либо существенным ошибкам.
  16. Для проверки того, что приложение выполняет автоматический запуск в соответствии с требованиями.
  17. Для проверки соответствия приложения требованиям всех поколений мобильных сетей, а именно 3G, 4G и 5G.
  18. Выполнять Регрессионное тестирование Выявлять новые программные ошибки в существующих областях системы после внесения в них изменений. Также повторно запускать ранее проведенные тесты, чтобы убедиться, что поведение программы не изменилось в результате изменений.
  19. Чтобы проверить, предоставляет ли приложение руководство пользователя для тех, кто с ним не знаком.

Тестовые случаи тестирования производительности

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

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

Общие сценарии тестирования для тестирование производительности В мобильном приложении присутствуют следующие элементы:

  1. Определить, работает ли приложение в соответствии с требованиями в различных условиях нагрузки.
  2. Чтобы определить, способно ли текущее покрытие сети поддерживать приложение на пиковом, среднем и минимальном уровнях пользователей.
  3. Определить, обеспечивает ли существующая конфигурация клиент-сервер требуемый оптимальный уровень производительности.
  4. Цель состоит в выявлении различных узких мест в работе приложения и инфраструктуры, которые препятствуют достижению приложением требуемого уровня производительности.
  5. Для проверки соответствия времени отклика приложения требованиям.
  6. Оценить продукт и/или оборудование, чтобы определить, сможет ли оно справиться с прогнозируемыми объемами нагрузки.
  7. Цель исследования — оценить, сможет ли время работы батареи обеспечить работу приложения при прогнозируемых объемах нагрузки.
  8. Для проверки производительности приложения при переключении сети с 4G/5G на Wi-Fi или наоборот.
  9. Для проверки того, что каждый из необходимых циклов ЦП оптимизирован.
  10. Для проверки того, что потребление заряда батареи, утечки памяти и производительность таких ресурсов, как GPS и камера, находятся в пределах требуемых норм.
  11. Для проверки долговечности приложения при высокой пользовательской нагрузке.
  12. Для проверки производительности сети при перемещении с устройством.
  13. Для проверки производительности приложения в условиях прерывистых фаз подключения.

Тестовые случаи тестирования безопасности

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

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

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

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

  1. Для проверки способности приложения противостоять атакам методом перебора, которые представляют собой автоматизированный процесс проб и ошибок, используемый для угадывания имени пользователя, пароля или номера кредитной карты.
  2. Для проверки того, что приложение не позволяет злоумышленнику получить доступ к конфиденциальной информации или функциям без надлежащей аутентификации.
  3. Для подтверждения того, что приложение имеет надежную систему защиты паролем и не позволяет злоумышленнику получить, изменить или восстановить пароль другого пользователя.
  4. Чтобы убедиться, что приложение не страдает от недостаточного истечения срока действия сеанса.
  5. Для выявления динамических зависимостей и принятия мер по предотвращению доступа злоумышленников к этим уязвимостям.
  6. Предотвращать SQL атаки, связанные с инъекциями.
  7. Для выявления и восстановления любых сценариев неуправляемого кода.
  8. Для обеспечения проверки подлинности сертификатов и наличия в приложении функции привязки сертификатов.
  9. Для защиты приложения и сети от атак типа «отказ в обслуживании».
  10. Анализировать требования к хранению и проверке данных.
  11. Для включения управления сессиями с целью предотвращения несанкционированного доступа пользователей к нежелательной информации.
  12. Чтобы проверить, не поврежден ли какой-либо криптографический код, и убедиться, что он исправлен.
  13. Для подтверждения того, что реализация бизнес-логики защищена и не уязвима для внешних атак.
  14. Чтобы проанализировать взаимодействие файловых систем, определить любые уязвимости и устранить эти проблемы.
  15. Для проверки обработчиков протокола, например, путем попытки перенастроить стандартную целевую страницу приложения с помощью вредоносного iframe.
  16. Для защиты от вредоносных инъекций на стороне клиента.
  17. Для защиты от вредоносных инъекций во время выполнения.
  18. Чтобы исследовать кэширование файлов и предотвратить любые вредоносные возможности.
  19. Для предотвращения небезопасного хранения данных в кэше клавиатуры приложений.
  20. Для проверки файлов cookie и предотвращения любых вредоносных действий, связанных с ними.
  21. Обеспечивать регулярные проверки для анализа защиты данных.
  22. Цель – исследовать файлы, созданные пользователем, и предотвратить любые вредоносные действия, совершаемые с использованием таких файлов.
  23. Для предотвращения переполнения буфера и повреждения памяти.
  24. Для анализа различных потоков данных и предотвращения любых уязвимостей, возникающих в результате их обработки.

Тестовые случаи юзабилити-тестирования

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

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

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

  1. Чтобы убедиться, что кнопки имеют необходимый размер и подходят для больших пальцев.
  2. Чтобы кнопки располагались в одном и том же разделе экрана и не вводили пользователей в заблуждение.
  3. Чтобы значки были естественными и соответствовали приложению.
  4. Чтобы гарантировать, что кнопки с одинаковой функцией будут иметь одинаковый цвет.
  5. Для обеспечения проверки работоспособности кранаping Функция масштабирования включена.
  6. Чтобы гарантировать, что ввод с клавиатуры может быть минимизирован соответствующим образом.
  7. Чтобы гарантировать, что приложение предоставляет возможность вернуться или отменить действие при касании неправильного элемента в течение приемлемого времени.
  8. Чтобы контекстные меню не были перегружены, поскольку ими нужно пользоваться быстро.
  9. Чтобы текст был простым и понятным, легко воспринимался пользователями.
  10. Чтобы короткие предложения и абзацы были понятны конечным пользователям.
  11. Чтобы гарантировать, что размер шрифта достаточно большой, чтобы его можно было прочитать, а не слишком большой или слишком маленький.
  12. Чтобы убедиться, что приложение запрашивает подтверждение у пользователя всякий раз, когда он начинает загрузку большого объема данных, что может негативно сказаться на производительности приложения.
  13. Для проверки того, что закрытие приложения происходит из разных состояний, и подтверждения того, что оно повторно открывается в том же состоянии.
  14. Для обеспечения преобразования всех строк в соответствующие языки при наличии средств языкового перевода.
  15. Чтобы гарантировать, что элементы приложения всегда синхронизируются в соответствии с действиями пользователя.
  16. Цель состоит в том, чтобы предоставить конечному пользователю руководство пользователя, которое поможет ему понять и использовать приложение, если он не знаком с его принципами работы.

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

Тестовые случаи тестирования совместимости

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

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

Ниже приведены наиболее важные области тестирования совместимости.

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

Тестовые случаи тестирования возможности восстановления

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

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

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

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

  1. Тестирование установки (возможность установки приложения за разумное время и с соблюдением необходимых критериев).
  2. Тестирование на удаление (возможность удаления приложения за разумное время и с соблюдением необходимых критериев).
  3. Тестовые сценарии для сети (проверка работоспособности сети при требуемой нагрузке и ее способности поддерживать все необходимые приложения в ходе тестирования).
  4. Проверьте неназначенные клавиши
  5. Проверьте заставку приложения.
  6. Продолжение ввода с клавиатуры во время прерываний и в других ситуациях, например, при проблемах с сетью.
  7. Методы, отвечающие за выход из приложения
  8. Эффект зарядного устройства, когда приложение работает в фоновом режиме
  9. Низкий заряд батареи и высокие требования к производительности
  10. Извлечение батареи во время работы приложения
  11. Потребление заряда батареи приложением
  12. Проверьте побочные эффекты приложения.

Часто задаваемые вопросы (FAQ)

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

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

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

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

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

Да. Он создает объекты страниц. Appium Указатели местоположения и блоки утверждений из короткого комментария, описывающего экран. RevПросмотрите каждое предложение, поскольку сгенерированные локаторы часто ссылаются на элементы, которых не существует.

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

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

Подведем итог этой публикации следующим образом: