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

Частый вопрос наших учеников: «Как тестировать мобильные приложения?» В этом руководстве мы предоставляем примеры тестовых сценариев/тестовых случаев для тестирования мобильного приложения.

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

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

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

Различные факторы, имеющие значение для функционального тестирования:

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

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

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

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

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

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

1. Определить, работает ли приложение в соответствии с требованиями в различных условиях нагрузки.
2. Чтобы определить, способно ли текущее покрытие сети поддерживать приложение на пиковом, среднем и минимальном уровнях пользователей.
3. Определить, обеспечивает ли существующая конфигурация клиент-сервер требуемый оптимальный уровень производительности.
4. Выявить различные узкие места приложений и инфраструктуры, которые не позволяют приложению работать на требуемом уровне приемлемости.
5. Проверить, соответствует ли время ответа приложения требованиям.
6. Оценить продукт и/или оборудование, чтобы определить, сможет ли оно справиться с прогнозируемыми объемами нагрузки.
7. Оценить, сможет ли срок службы батареи обеспечить работу приложения при прогнозируемых объемах нагрузки.
8. Для проверки производительности приложения при переключении сети на WIFI с 2G/3G или наоборот.
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 и предотвращения любых злонамеренных действий с помощью файлов cookie.
21. Обеспечивать регулярные проверки для анализа защиты данных.
22. Исследуйте специально созданные файлы и предотвращайте любые вредоносные действия со стороны специально созданных файлов.
23. Чтобы предотвратить переполнение буфера и случаи повреждения памяти.
24. Для анализа различных потоков данных и предотвращения каких-либо уязвимостей в них.

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

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

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

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

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

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

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

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

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

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

Важный контрольный список

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