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

Краткое описание проекта

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

Сервис представляет собой RESTful-систему, состоящую из набора микросервисов. Микросервисы представляют собой прослойку между конечными пользователями и ПУ. И таким образом позволяют получать данные, а также управлять ПУ по протоколам HTTPS, DLMS и IEC-104.

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

Обязанности команды ДжазТим

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

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

Функциональное тестирование

На постоянной основе был внедрён процесс функционального тестирования и тестирования UI для проверки соответствия интерфейса пользователя установленным стандартам и нормам, определёнными заказчиком. Проверки состоят из валидации объектов пользовательского интерфейса, которые непосредственно отображаются пользователю при его взаимодействии с сервисами приложения. Для этого используются различные техники тест-дизайна:

классы эквивалентности (используется для построения тестовых данных для подготовки выгрузки Excel отчётов, при проверке создания новых портов для подключения к устройствам);
граничные условия (используется при выгрузке анализа дефектов, при включении/выключении синхронизации времени, инициативной передачи и досбора);
доменный анализ (используется при проверке добавления ПУ);
попарное тестирование (используется для выгрузки Excel отчётов по видам показаний и информации по ПУ в том или ином сервисе, при проверках настроек планировщика, устройств и досбора).

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

Интеграционное тестирование

После подготовки и организации регулярного процесса функционального тестирования, мы внедрили процесс интеграционного тестирования. Оно позволяет обнаруживать дефекты, возникающие при взаимодействии микросервисов между собой, а также дефекты при подключении пользователя к ПУ через микросервисы. При проведении тестирования используется специальный инструмент GuruxDirector (open source решение для работы с DLMS устройствами), который позволяет считывать объекты (объект является основным элементом информационной структуры ПУ, содержит все параметры и данные, а также имеет уникальное логическое имя) со счётчиков электроэнергии, газа или воды, совместимые с протоколом DLMS/COSEM. Использование GuruxDirector позволяет проверить наличие ошибок, связанных с взаимодействием нескольких микросервисов при чтении объектов из ПУ.

REST API тестирование

Ещё одной особенностью предоставления услуг по обеспечению качества продукта стало внедрение проведения REST API тестирования для проверки работы функций, которые недоступны на UI, а также дополнительного прохождения тестов на отработку запросов к ПУ. Данная проверка позволяет убедиться в стабильном взаимодействии микросервисов между собой и получении данных через микросервисы с использованием http-методов.

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

Регрессионное и смоук тестирование

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

Для проведения данных видов тестирования были согласованы и внедрены следующие особенности:

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

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

Автоматизированное тестирование

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

Первоначальная задача заключалась в разработке фреймворка для автоматизированного тестирования критической функциональности продукта. Для покрытия были отобраны тест-кейсы, затрагивающие работу UI, работу по выгрузке и проверке создаваемых Excel отчётов и по проверке работы ПУ через инструмент GuruxDirector. Чтобы автоматизировать эти тест-кейсы были созданы клиенты по работе с Excel файлами, и клиент Gurux, который имитирует работу инструмента GuruxDirector.

Разработка клиента для работы с Excel-файлами

Excel-клиент разработан на основе библиотеки Java Apache POI, которая позволяет читать документы Microsoft Office, в частности MS Excel. В приложении при запросе на получение отчёта, он скачивается в виде .zip архива. Excel клиент осуществляет разархивацию и извлекает Excel файл. Далее создаётся объект книги (Workbook), объект листа книги Excel (Sheet) и осуществляется построчная считка из каждой строки листа в объект структуры данных Map, языка программирования Java (Map<Integer, List<String>>). После чего данные из объекта структуры данных распределяются в нужный объект отчёта. Для получения окончательного результата данные в созданном отчёте сверяются с данными из БД. Результаты проверки считаются положительными, если данные совпадают и в отчёте отсутствуют дубликаты ПУ.

Разработка клиента для работы с библиотекой Gurux

GuruxDLMS клиент разработан на основе библиотеки Gurux и проходит следующие шаги для получения данных:

Установление соединения с ПУ.
Создание объекта для считывания конкретных значений с ПУ (к примеру значение времени, частота сети, фазное напряжение, журнал суточных показаний и т.п.).
Считывание данных с ПУ в соответствии с созданным объектом.
Разрыв соединения с ПУ.

В рамках Gurux-клиента автоматизирован тест-кейс, с применением свойства многопоточности для проверки одновременной работы нескольких ПУ.

Автоматизация работы с Grafana

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

Для визуализации данных системы мониторинга используется инструмент Grafana. Заказчик поставил задачу создать автотесты на отобранные метрики продукта за определённый период времени, удовлетворяющие определённым условиям. Перед началом разработки фреймворка автоматизатор тестирования изучил, на каком окружении заказчика и в каком виде хранятся данные метрик, и как можно получить данные за период времени по конкретной метрике. Фреймворк для мониторинга работы продукта использует REST API запросы с использованием библиотеки Rest Assured. В базу данных временных линий Prometheus отправляется запрос на получение данных по конкретным метрикам за конкретный промежуток времени. Тест считается пройденным, если значения метрик удовлетворяет заданным условиям.

Используемые технологии

Databases: pgAdmin.
Backend: Java 11, Swagger, Grafana, Apache POI, Log4j2, Lombok, Gson.
Test Automation: JUnit 5, Selenide, Rest Assured, Allure, Awaitility.
CI/CD and DevOps: Maven, TeamCity.
Languages, Protocols, APIs, Network Tools: DevTools, JWT, Putty, Gurux DLMS/COSEM Director.
Software Engineering and Management Tools: TestLink, Jira, Confluence, Git, IntelliJ IDEA.

Особенности проекта

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

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

На проекте организован и успешно внедрён процесс мануального и автоматизированного тестирования.
Создана техническая документация для процесса тестирования:

Создан и подробно описан тест-план;
Создано 6 тест-сьютов:

GUI-тестирование (~400 тест-кейсов);
Регрессионное тестирование (~150 тест-кейсов);
Смоук-тестирование (~150 тест-кейсов);
REST API тестирование (~50 тест-кейса);
Чек-лист для тестирования сервиса авторизации (~150 тест-кейса);
Интеграционное тестирование (~50 тест-кейса).

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

Уровень покрытия функциональности GUI тест-кейсами — 95%.
С нуля написан фреймворк для функционального автотестирования приложения.
Разработан клиент для тест-кейсов, использующих утилиту Gurux. Процент покрытия функциональности, связанной с работой с Gurux составляет 62,5% от существующих мануальных тест-кейсов. Также разработан клиент для тест-кейсов, в которых формируются и проверяются Excel отчёты.
Автоматизированы тест-кейсы, проверяющие критически важный функционал UI компонента.
С нуля написан фреймворк для мониторинга работы приложения с помощью данных, собранных Prometheus.
Регулярное создание release notes по выпуску новых версий продукта и размещение данной информации в Confluence заказчика.

Достижения компании на проекте

На проекте бесперебойно обеспечивается качество продукта. Процесс тестирования непрерывно связан с процессом разработки. В релиз уходят версии, прошедшие регрессионное тестирование. Стабильность работы продукта на продакшн окружении поддерживается за счёт проведения смоук-тестирования.
Каждую ночь в автоматическом режиме на билд сервере TeamCity запускается прогон всех автотестов. Утром автоматизатор тестирования присылает в чат с заказчиком подробный отчёт с количеством пройденных и упавших тест-кейсов, а также с описанием причин падения. Данная информация позволяет находить проблемы в критически важной функциональности продукта и оперативно исправлять их.
Команда ДжазТим тесно сотрудничала с заказчиком при реализации нового микросервиса авторизации, что позволило учесть все требования к ролям пользователей используемых при работе с продуктом и создать матрицы ролей для проведения тестирования.
Наша команда обеспечила бесшовную передачу знаний, подходов между участниками проекта — использовалось много разных технологий и инструментов, но все лучшие практики были собраны в одном месте.

Свяжитесь с нами, чтобы обсудить Ваш IT-проект