- PVSM.RU - https://www.pvsm.ru -
Первая часть — здесь [1].
Представьте ситуацию. Перед вами стоит задача разработки нового функционала. У вас есть наработки от ваших предшественников. Если предположить, что вы никаких моральных обязательств не имеете, то как бы вы поступили?
Чаще всего все старые наработки подвергаются забвению и всё начинается сначала. В чужом коде копаться никто не любит, а при наличии времени почему бы не заняться созданием собственной системы? Это типичный подход, и он во многом правильный. Но в своём проекте мы поступили не так. В основу будущей системы автоматического тестирования мы заложили наработки по unit-тестам на utPLSQL от предшественников, а затем пошли работать в нескольких параллельных направлениях.
Модуль запуска представлен в виде одной универсальной процедуры с одним входным текстовым параметром. В качестве параметра можно передавать мнемокод автотеста, название пакета, название теста, настройку автотеста или зарезервированное ключевое слово. Процедура отбирает и запускает все автотесты, удовлетворяющие условиям.
Модуль генерации данных представлен в виде пакета, в котором для каждого объекта тестируемой системы (таблица в БД), создана специальная процедура, которая вставляет туда данные. В данной процедуре максимально заполнены дефолтные значения, что обеспечивает создание объектов буквально по щелчку пальцев. И для удобства использования были созданы шаблоны создаваемых данных. Например, создать клиента определённого возраста с тестовым телефоном и совершённой покупкой.
Но над оптимизацией скорости работы пришлось поработать. Обновление системы лояльности на продакшене производится ночью. В рамках одного из релизов ночью пришлось экстренно вносить изменения. Получасовое ожидание результатов автотестов в три часа ночи не сделало ответственного за релиз счастливым (пламенный привет Алексею Васюкову!), а на следующее утро в сторону нашей системы было сказано много теплых слов. Но по итогам был установлен 5-минутный норматив на работу.
Для ускорения производительности мы воспользовались двумя методами: автотесты стали запускаться в трех параллельных потоках, благо это очень удобно из-за архитектуры нашей системы лояльности. И мы отказались от подхода, когда автотест не создает для себя тестовые данные, а пытается найти в системе что-то подходящее. После внесения изменений общее время работы сократилось до 3-4 минут.
Это независимая от базы данных библиотека с открытым исходным кодом для отслеживания, управления и применения изменений схемы базы данных. Управляется посредством командной строки или фреймворков типа Apache Maven. Принцип работы Liquibase достаточно прост. У нас есть организованный определенным образом проект, который состоит из изменений или скриптов, которые надо накатывать на целевой сервер, и управляющие файлы, которые определяют, в какой последовательности и с какими параметрами данные изменения надо устанавливать.
На уровне СУБД создаётся специальная таблица, в которой Liquibase хранит лог накатов. Каждое изменение имеет рассчитанный хэш, который каждый раз сравнивается между проектом и состоянием в базе. Благодаря Liquibase мы легко накатываем изменения нашей системы на любой контур. Автотесты сейчас запускаются на тестовом и релизном контурах, а также на контейнерах (личных контурах разработчиков).
Итак, давайте поговорим о результатах применения нашей системы unit-тестирования.
Давайте поговорим о планах развития проекта по автоматизированному тестированию.
Безусловно, пока система лояльности Спортмастера жива и продолжает развиваться, можно также практически бесконечно развивать автотесты. Поэтому основное направление развития – это расширение зоны покрытия.
По мере увеличении количества автотестов неуклонно будет расти общее время их работы, и нам вновь придётся вернуться к вопросу производительности. Скорее всего, решение будет в увеличении количества параллельных потоков.
Но это очевидные пути развития. Если говорить о чём-то более нетривиальном, выделим следующее:
Нашей системе автотестирования чуть больше года и, возможно, сейчас самое время для оценки покрытия. В моём прошлом проекте (проект не Спортмастера) так и получилось. Спустя год после работы над автотестами руководство поставило задачу оценить, каков процент кода мы покрываем. При покрытии более 1% руководство было бы счастливо. Мы, разработчики, ожидали результат около 10%. Прикрутили code coverage, замерили, получили 20%. На радостях отправились за премией, но как мы за ней сходили и куда направились позже, это совсем другая история.
Давайте подытожим. На проекте система лояльности в Спортмастере нам удалось реализовать систему автоматизированного тестирования. Базисом её является решение utPLSQL от Стивена Фейерштейна. Вокруг utPLSQL расположен код автотестов и вспомогательные самописные модули: модуль запуска, модуль генерации данных и другие. Автотесты ежедневно запускаются и, что самое важное, работают и приносят пользу. Мы убеждены, что начали выпускать ПО более высокого качества. При этом полученное решение универсально и может быть свободно применено на любом проекте, где необходимо организовать автоматизированное тестирование на СУБД Оракл.
P.S. Данная статья получилась не очень конкретной: здесь много текста и практически отсутствуют технические примеры. Если глобально тематика интересна, то мы готовы её продолжить и вернуться с продолжением, где расскажем, что изменилось за прошедшие полгода и привести примеры кода.
Пишите комментарии, если есть моменты, на которых стоит сделать акцент в будущем, или вопросы, требующие раскрытия.
Автор: Максим Пономаренко
Источник [3]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/testirovanie/328635
Ссылки в тексте:
[1] здесь: https://habr.com/ru/company/sportmaster_lab/blog/464335/
[2] Image: https://habr.com/ru/company/sportmaster_lab/blog/465047/
[3] Источник: https://habr.com/ru/post/465047/?utm_source=habrahabr&utm_medium=rss&utm_campaign=465047
Нажмите здесь для печати.