ВВЕДЕНИЕ 3
1 ПОСТАНОВКА ЗАДАЧИ 6
1.1 Требования к системе 6
1.2 Выбор технологий и инструментов 8
2 АРХИТЕКТУРА СИСТЕМЫ И
2.1 Общая архитектура системы 11
2.2 Архитектура библиотеки 13
3 РАЗРАБОТКА БИБЛИОТЕКИ 16
3.1 Распознавание тряски 16
3.2 Автоматический сбор данных 19
3.3 Настройка и отправка 21
4 ИСПОЛЬЗОВАНИЕ БИБЛИОТЕКИ 27
4.1 Создание и настройка приложения в Slack 27
4.2 Создание и настройка приложения в Jira 27
4.3 Подключение зависимости к проекту 28
4.4 Инициализация библиотеки 28
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ 31
ПРИЛОЖЕНИЕ
Тестирование мобильных приложений - очень сложный и трудоемкий процесс. В различных компаниях по разработке ПО тестирование реализовано самыми различными способами: где-то его почти нет в связи с недостатком средств, где-то тестирование является неотъемлемой частью разработки, кроме того, когда компания является лишь стартапом, то роль тестировщика в конечном итоге выполняет разработчик. Так или иначе, тестирование является частью любого проекта разработки ПО. Существует очень много видов тестирования, но все они могут быть разделены на 2 типа:
1) автоматическое тестирование - способ тестирования, когда тестовый сценарий прогоняется на существующем коде автоматически,
2) ручное тестирование - процесс проверки качества приложения с помощью определенного набора тест-кейсов, осуществляемый непосредственно тестировщиком.
Автоматическое тестирование способно обнаружить большое количество ошибок, допущенных в коде приложения. Но когда тестирование касается мобильных приложений, то ручное тестирование является решающим или единственным этапом тестирования.
При тестировании различных приложений (после того как тестировщик находит несоответствия в мобильном приложении) создание задачи, оповещение программиста и воспроизведение найденного бага занимает очень много времени. Данный цикл каждый раз занимает большое количество времени, от нахождения проблемы, до ее решения, поскольку включает в себя несколько этапов:
- заполнение информации о найденной ошибке в системе отслеживания ошибок или баг-репорте
- оповещение разработчика о найденных несоответствиях.
- нахождение разработчиком причины бага.
Если верить данным, полученным из электронного ресурса, уже в 2015 году количество различных Android-устройств насчитывало более 24 тысячи [2]. Это говорит о том, что между этими устройствами несколько тысяч отличий, начиная от разрешения экрана и заканчивая версией операционной системы, которая в свою очередь у каждого производителя изменена по-своему. Конечно, для большей успешности приложения не помешало бы протестировать его на каждом устройстве. Это к сожалению невозможно, но есть небольшое количество устройств, при тестирование на которых, можно дать большую вероятность, что приложение будет корректно функционировать и на других устройствах. При таких обстоятельствах ручное тестирование является единственным вариантом оценки качества работы приложения.
Обычно ручное тестирование мобильного приложения проходит в следующем порядке. Сначала создаются тест-кейсы для проверки определенного функционала. В ходе выполнения определенного кейса, когда тестировщик находит несоответствие, это приводит к выполнению примерно следующих действий:
1) в ручную делается скриншот экрана девайса на котором происходит тестирование
2) в системе отслеживания ошибок находится нужный проект
3) создается задача, с полным описанием бага и прикрепленным скриншотом
4) разработчику сообщается о найденном баге
5) разработчик приступает к решению проблемы, сначала ему нужно самому воспроизвести баг. В зависимости от типа бага, если он связан с данными и логикой приложения, разработчику нужно посмотреть логи. И в большинстве случаев уже в этом этапе ошибка находится и устраняется.
Описанные выше этапы можно легко автоматизировать, поскольку каждый раз выполняются одни и те же действия. Что немаловажно, с помощью автоматизации сбора информации возможно намного увеличить эффективность и уменьшить время исправления ошибки.
Таким образом, цель данной дипломной работы - создать программный инструмент для сокращение времени от нахождения несоответствия до его решения, путем создания библиотеки для ОС Android для автоматизации сбора тестирования в приложении, автоматического создания задачи в системе отслеживания ошибок и автоматизации оповещения разработчика через мессенджер, предоставив ему всю собранную информацию, чтобы сразу приступить к решению проблемы, а не пытаться найти причины ошибки.
Чтобы достигнуть поставленной цели необходимо было выполнить следующие задачи:
• Проектирование архитектуры библиотеки;
• Разработка функционала сбора данных;
• Интеграция с сервисом Slack;
• Интеграция с сервисом Jira;
• Публикация библиотеки в системе управления зависимостями JitPack.
Разработанный в результате выполнения данной дипломной работы программный инструмент для автоматизированного сбора результатов тестирования Android-приложений обладает следующим функционалом:
1. Автоматическое распознавание встряхивания
2. Автоматический сбор информации, включающий логи приложения, скриншот экрана, название устройства, текущая версия ОС Android, версия проекта, версия кода проекта.
3. Авторизация в Slack.
4. Выбор канала для отправки оповещений.
5. Оповещение разработчика о найденном несоответствии через Slack API.
6. Авторизация в Jira.
7. Выбор проекта для создания задачи.
8. Создание задачи в Jira.
Данный программный инструмент позволит тестировщику не тратить время на однотипные и повторяющиеся действия. Нужно лишь описать найденную ошибку и система сама создаст задачу в системе отслеживания ошибок Jira и оповестит разработчика через корпоративный мессенджер Slack. Разработчику же сразу будет доступна вся нужная информация о состоянии приложения в момент нахождения несоответствия, что позволит ему сократить время нахождения ошибки и её исправления.
С точки зрения разработчика библиотека является легко интегрируемой и гибкой.
В дальнейшем планируется реализовать автоматический сбор данных