Наверное, каждая команда знакома с этой болью — неактуальной документацией.
Как бы команда ни старалась, в современных проектах мы выпускаем так часто, что описать все изменения практически невозможно.
Наша группа тестирования совместно с системными аналитиками решили попробовать оживить нашу конструкторскую документацию.
В веб-проектах Альфа-Банка используется фреймворк автоматизации тестирования.
Акита , который использует сценарии BDD. На сегодняшний день фреймворк приобрел большую популярность благодаря низкому порогу входа, простоте использования и возможности протестировать верстку.
Но мы решили пойти дальше — сгенерировать документацию на основе описанных тестовых сценариев, тем самым значительно сократив время, которое аналитики тратят на вечную проблему обновления документации.
На самом деле мы уже использовали плагин генерации документации с Akita, который проходил шаги в скриптах и загружал их в формат html, но для того, чтобы сделать этот документ актуальным, нам нужно было добавить:
- скриншоты;
- значения переменных (файл конфигурации, учетные записи пользователей и т. д.);
- статусы и параметры запроса.
feature. Мы решили добавить динамики, и чтобы не нагромождать плагины поверх плагинов, решили написать свои.
Для начала мы решили выяснить, как можно собирать скриншоты и значения переменных, используемых в тестовых сценариях, из фич-файлов.
Все оказалось довольно просто.
При запуске тестов Cucumber создает отдельный файл огурца.
json для каждого файла функции.
Этот файл содержит следующие объекты:
Название и ключевое слово набора тестов:
Массивы элементов — сами скрипты и шаги:
Поле вывода содержит дополнительную информацию, например, переменные — адреса, ссылки, учетные записи пользователей и т. д.:
Embeddings содержит скриншоты, которые селен делает при прохождении тестов:
Таким образом, нам просто нужно пройтись по файлам огурца.
json, собрать названия тест-кейсов, тестовых скриптов, вытащить шаги, собрать дополнительную информацию и скриншоты.
Чтобы в документации отображались запросы, происходящие в фоновом режиме или на конкретное действие, нам пришлось обратиться за помощью к нашим фронтенд-разработчикам.
Используя прокси, мы смогли перехватить идентификатор трассировки, генерируемый фронтальными запросами к сервисам.
По этому же TraceId логи записываются в эластик, откуда мы подтягиваем все необходимые параметры запроса в отчет о тестировании и документацию.
В результате мы получили файл в формате Asciidoc — удобный формат файла, немного сложнее аналога Markdown, но имеет гораздо больше возможностей форматирования (можно вставить изображение или таблицу, чего нельзя сделать в Markdown).
Чтобы преобразовать полученный Asciidoc в другие форматы, мы используем Ascii Doctorj, официальную версию Java-инструмента AsciiDoctor. В результате мы получаем готовую документацию в формате html, которую можно загрузить в confluence, отправить коллеге или положить в репозиторий.
Как подключиться?
Теперь, чтобы сгенерировать фронтовую документацию для вашего проекта, вам достаточно подключить к нему плагин документации и после запуска всех тестов выполнить команду adoc
.
Что мы хотим улучшить?
- Добавьте настраиваемые технические шаги.
Текущая версия плагина содержит шаги «И был сделан скриншот…».
Подобные шаги не имеют смысла для документации, и мы хотим их скрыть.
Сейчас мы их зашили внутрь плагина, и они пропускаются, но есть недостаток — каждое добавление такого шага приводит к тому, что нам нужно собирать новую версию плагина.
Чтобы уйти от этого, мы планируем такие шаги перенести в файл конфигурации и прописать там те шаги, которые мы не хотим видеть в скриптах.
- Сделайте плагин с открытым исходным кодом.
Какие команды выиграют от нашего внедрения?
- используйте Cucumber (или аналогичный фреймворк);
- хотите иметь актуальную документацию по фронту и базу знаний;
- хочу привлечь аналитиков к тестированию.
Результат:
Пилот на нескольких командах показал, что с помощью плагина мы можем поддерживать документацию в актуальном состоянии; аналитикам больше не нужно тратить время на его поддержание.Кстати, по поводу холивара, нужен БДД или нет, в понедельник проведем специальная встреча .Кроме того, реализация этой возможности заставила нас задуматься о продолжении внедрения полноценного BDD внутри команд. Сегодня мы проводим эксперимент — аналитики формулируют позитивный путь клиента, указывают на бизнес-ограничения с помощью шагов Akita BDD, тестировщики, в свою очередь, пишут кастомные шаги и дополнительные проверки для этих сценариев.
Теги: #Разработка сайта #тестирование #Тестирование веб-сервисов #Тестирование ИТ-систем #Подготовка технической документации #документация #бдд #gradle #Альфа-банк #акита #огурец
-
Мне Хотелось Красивое Железо. Случилось
19 Oct, 24 -
Медиаплатформа Медиатека
19 Oct, 24 -
Сегодня Indextank Отключает Все Свои Серверы
19 Oct, 24 -
Toshiba Spursengine — Новый Аналог Ibm Cell
19 Oct, 24 -
Вау-Фактор Vista: Праздник Для Простых Людей
19 Oct, 24 -
Эксперименты С Записью Жизни (Лайфблогинг)
19 Oct, 24