Отладка мобильных приложений: локализация дефектов и создание отчетов об ошибках
20 декабря 2022 г.В этой статье я опишу, что делает QA-специалист, обнаружив конкретную ошибку мобильного приложения.
Основные термины:
* Ошибка — это недостаток компонента или системы, из-за которого мобильное приложение не может выполнять требуемую функцию. Ошибка, обнаруженная во время выполнения, может привести к сбою мобильного приложения. Например, человек не может сохранить данные после заполнения анкеты. * Ошибка — это человеческая деятельность, которая может привести к неверному результату. Например: ввод букв в поле даты (допустимы только цифры) и последующее сохранение данных. * Сбой — это отклонение компонента или системы от ожидаемого результата, производительности или операции. Например: когда человек переходит на следующую страницу анкеты, данные с предыдущей страницы перезаписываются.
Начнем.
Классификация ошибок мобильных приложений
Функциональные ошибки мобильного приложения — мобильное приложение функционально не работает должным образом. Например:
* изменения данных в профиле не сохраняются * добавление комментария не работает * удаление товаров из корзины не работает * поиск не работает
Визуальные ошибки мобильного приложения: мобильное приложение выглядит не так, как должно. Например:
* текст выходит за пределы полей * элемент управления располагается поверх основного элемента * картинка не отображается
Логические ошибки мобильного приложения — мобильное приложение работает некорректно с точки зрения логики. Например:
* пользователь может поставить дату рождения "из будущего", а также несуществующие даты - 31 февраля, 32 декабря и т.д. * возможно оформление заказа без указания адреса доставки * логика поиска работает некорректно
Ошибки безопасности мобильного приложения — могут быть затронуты пользовательские данные, существует риск сбоя системы и т. д. Например:
* возможно получить логин и пароль в результате SQL инъекции * неограниченное время жизни сессии после авторизации
Итак, мы рассмотрели виды багов мобильных приложений. Теперь давайте поговорим о том, как их задокументировать.
Документация по ошибкам в мобильных приложениях
Отчет об ошибке мобильного приложения — это документ, описывающий ситуацию или последовательность действий, приведших к некорректной работе объекта тестирования, с указанием причин и ожидаемого результата.
Возможно, вы думаете, что «следующим шагом будет документирование ошибок мобильного приложения», но вы ошибаетесь.
Вы не можете просто пойти и задокументировать найденную ошибку мобильного приложения. В первую очередь важно выполнить локализацию.
Например, если ошибка мобильного приложения может повлиять на другие части системы, она должна быть представлена в отчете об ошибке, и эта гипотеза должна быть проверена заранее. Также необходимо очень подробно описать все условия и шаги, чтобы разработчик мог проверить этот баг мобильного приложения.
Но как искать баги в мобильных приложениях, чтобы разработчикам было понятно, откуда берутся эти дефекты и как их исправить? Было бы полезно, если бы вы придерживались определенного плана действий, который я опишу ниже.
Повторно проверьте ошибку мобильного приложения
Вам нужно еще раз проверить себя: воспроизвести ошибку мобильного приложения в тех же условиях. Если при следующем тесте ошибка не возникает, нужно убедиться, что все действия и этапы повтора, приведшие к такому результату, были соблюдены точно. Возможно, ошибка мобильного приложения появляется только при начальной загрузке системы (при первом использовании). Для более точного определения условий, при которых воспроизводилась ошибка, ее необходимо локализовать.
Локализация ошибки мобильного приложения
Для локализации бага мобильного приложения необходимо собрать как можно больше информации о его воспроизведении:
* Определите причины ошибки
Например, не удается восстановить пароль. Вы должны определить источник неправильного запроса к серверу: внутренний или внешний интерфейс.
* Анализ возможного влияния ошибки на другие области
Например, в одной из форм, которая редко используется, есть ошибка при нажатии кнопки "Редактировать". Если кнопка скрыта в качестве временного решения проблемы, это может повлиять на аналогичную форму в другом окне/вкладке, к которой пользователи обращаются чаще. Для качественного анализа нужно знать, как работает мобильное приложение и зависимости между его частями.
*Отклонение от ожидаемого результата
Вам необходимо проверить, соответствует ли результат теста ожидаемому результату. Решить эту задачу помогает техническое задание, в котором должна быть задокументирована информация о тестируемом мобильном приложении и его функционировании. Вы не должны пропускать этот шаг при тестировании. Если специалист недостаточно опытен и не знает требований, он может ошибаться и неправильно понимать, что относится к багам, а что нет. Внимательное изучение документации позволяет избежать подобных ошибок.
* Исследуйте окружающую среду
Необходимо воспроизвести ошибку в разных операционных системах (iOS, Android, Windows и т. д.) или браузерах (Google Chrome, Mozilla, Internet Explorer и т. д.). Вы должны проверить требования к продукту, чтобы определить, какие системы должны поддерживаться. Некоторые мобильные приложения работают только в определенных операционных системах или браузерах, поэтому вам не нужно проверять другие параметры.
* Проверяйте на разных устройствах
Например, настольное приложение предназначено для использования на компьютере, поэтому нет необходимости тестировать его на мобильных устройствах. Для смартфонов в идеале должна быть отдельная мобильная версия, которую, в свою очередь, нет смысла тестировать на компьютерах. Кроме того, некоторые PWA могут работать как на компьютерах, так и на мобильных устройствах, и их необходимо тестировать на всех типах устройств. Вы можете использовать эмулятор той или иной среды для тестирования.
Мобильное приложение необходимо протестировать на нескольких устройствах с разными диагоналями экрана. При этом можно руководствоваться требованиями к ПО, в которых должно быть указано, с какими устройствами ПО совместимо.
* Протестируйте разные версии мобильных приложений
Чтобы не путать реализуемые задачи, при разработке используется версионность программного обеспечения. Иногда ошибка воспроизводится в одной версии мобильного приложения, но не воспроизводится в другой. Этот атрибут нужно обязательно указать в баг-репорте, чтобы программист понял, в какой ветке искать проблему.
* Анализ системных ресурсов
Возможно, ошибка мобильного приложения была обнаружена при нехватке внутренней памяти устройства или оперативной памяти. В этом случае ошибка может воспроизводиться по-разному на одинаковых устройствах.
Исправление ошибок в мобильном приложении
Доказательства ошибки мобильного приложения должны быть зарегистрированы в журналах, снимках экрана или в записях с экрана:
* Журналы — это файлы, содержащие системную информацию сервера или устройства, в них содержится информация об определенных действиях пользователя или программы. Опытный разработчик должен просмотреть лог-файлы, чтобы понять ошибку. Обычно журналы прикрепляются к отчету об ошибке в виде файла .txt. * Живое ведение журнала — это запись системных журналов в реальном времени. Для этого можно использовать Sentry. * Скриншот. При наличии ошибок в интерфейсе скриншот помогает быстрее разобраться в проблеме. Программ для снятия скриншотов очень много, каждый QA специалист может использовать наиболее удобные для себя: Jing, ShareX, Lightshot и т.д. * Скринкаст — видеозапись экрана устройства. Таким образом, QA-специалист может легко показать ошибки в работе любого программного продукта. Незаменимыми инструментами любого эксперта по обеспечению качества являются Reflector, ADB Shell Screenrecord, AZ Screen Recorder и т. д.
Формат отчета об ошибках мобильного приложения
Все обнаруженные ошибки должны быть задокументированы, чтобы все участники проекта могли получить инструкции о том, как воспроизвести найденную ошибку и понять, насколько она критична. Если в команде принято устно передавать информацию о найденных багах разработчику, есть риск что-то упустить из виду.
Незадокументированная ошибка мобильного приложения Ошибка не обнаружена!
Когда вся необходимая информация собрана и ошибка локализована, вы можете выпустить отчет об ошибке в мобильном приложении. Чем точнее описание ошибки, тем меньше времени уходит на ее исправление. Список атрибутов разный для каждого проекта, но некоторые из них, такие как шаги воспроизведения, ожидаемые результаты и фактические результаты, присутствуют почти всегда.
Атрибуты отчета об ошибке мобильного приложения
* Имя
Ошибка мобильного приложения должна быть описана кратко и лаконично и иметь понятное название. Это поможет разработчику понять природу ошибки мобильного приложения и сможет ли он принять ее в работу. Это также облегчает подключение к проекту новых специалистов, особенно если разработка ведется много лет, и запомнить баги и отследить их становится все труднее. Название проекта можно составить по принципу "Где? Что? Когда?" или "Что? Где? Когда?" в зависимости от внутренних правил команды.
Например:
Где это происходит? - В карточке клиента (в каком разделе системы).
Что именно происходит? - Данные не сохраняются.
Когда это происходит? - При сохранении изменений.
* Компонент мобильного приложения
В какой части функционала обнаружена ошибка?
* Номер версии мобильного приложения
Версия продукта, в которой воспроизводится ошибка.
* Критичность
Этот атрибут показывает влияние ошибки на функциональность системы, например:
Блокировщик - ошибка, которая блокирует использование системы
Критическая — ошибка, нарушающая базовую бизнес-логику системы
Серьезная ошибка – ошибка, которая нарушает работу определенной функции, но не всей системы.
Незначительная — незначительная ошибка, не нарушающая бизнес-логику приложения, например, ошибка пользовательского интерфейса
Trivial — незаметная, неочевидная ошибка
* Приоритет
Приоритет определяет, насколько срочно ошибка должна быть исправлена. Обычно выделяют следующие виды приоритетов:
Высокий - ошибка должна быть исправлена как можно быстрее, она критична для проекта
Средний - ошибка должна быть исправлена, но ее наличие не критично для проекта
Низкий - ошибка подлежит исправлению, но не требует срочного решения
* Статус
Статус ошибки указывает на стадию жизненного цикла ошибки, независимо от того, находится ли ошибка в процессе или была устранена. Примеры: делать, в процессе, в тестировании, готово. Возможны дополнительные статусы в зависимости от особенностей проекта (например, аналитический).
* Назначено
Отчет об ошибке отправляется руководителю группы проекта или разработчику, который будет нести ответственность за исправление ошибки, в зависимости от соглашений, принятых командой.
* Предисловие (при необходимости)
Необходимо описать действия, предшествовавшие воспроизведению ошибки. Например, клиент авторизуется в приложении, создается запрос с параметрами ABC и т. д. Отчеты об ошибках могут не содержать предисловия, но иногда необходимо более простое описание шагов повтора.
* Повторить шаги
Одним из наиболее важных атрибутов является описание шагов, которые привели к обнаружению ошибки. Для описания бага оптимально использовать 5-7 четких и кратких шагов, например:
- Открыть (...)
- Нажмите (...)
- Введите значение N1 в поле A.
- Введите в поле B значение N2.
- Нажмите кнопку "Рассчитать".
* Фактический результат и ожидаемый результат
Что произошло после воспроизведения описанных выше шагов и что должно произойти после воспроизведения тестовых шагов в соответствии с требованиями?
* Прикрепленные файлы
Логи, скриншоты, записи экрана — все, что поможет разработчику понять и исправить ошибку мобильного приложения.
После создания отчета об ошибке вы должны проверить его, чтобы избежать ошибок или опечаток.
Я также рекомендую вам прочитать:
* Жизнь и времена Adobe Flash Player Gaming * Обречены ли облачные игры из-за физики? * Почему важна безопасность веб-сайтов и веб-приложений * Самый странный нераскрытый телевизионный взлом Америки и его история * Почему сетевая безопасность является неотъемлемой частью любого интернет- Подключенный бизнес
Оригинал