allure история тестов

Произвольные атачменты в отчетах

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

Здесь нам вновь поможет информация о внутреннем устройстве Vanessa-ADD. За работу с отчетом Allure отвечает плагин  addpluginsАллюр2Отчет.epf. Если открыть модуль формы этой обработки, то в нем можно обнаружить два нужных нам метода:

Методы похожи. Оба из них прикрепляют двоичные данные к отчету Allure сохраняя их в файл. Но метод ДобавитьФайлКТекущемуШагу получает эти двоичные данные из заданного файла, а не берёт произвольные.

Попробуем подключить с помощью них к шагу текстовый файл.

Можно было бы подумать, что нам поможет шаг выполнения произвольного кода, вызывающий этот метод. Например такой:

Он действительно сработает, и похожий шаг понадобится нам дальше, когда мы будем прикреплять графический файл. Но сейчас есть способ проще. Если из конфигуратора мы выполним поиск модулей в каталоге с библиотечными шагами OneScriptlibaddfeatureslibraries, содержащих текст «ДобавитьФайлКТекущемуШагу»,  то сможем найти обработку setlabelsallure.epf, содержащую такие замечательные шаги как

И Я подключаю файл ‘$workspaceRoot/fixtures/file.xls’ к шагу ‘id’

Если взглянуть на методы, реализующие эти шаги

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

Причина таких сложностей в поиске этих шагов заключается в том, что при объявлении этих шагов не заполнены последние параметры метода Ванесса.ДобавитьШагВМассивТестов. Из публикации по созданию собственных шагов //infostart.ru/public/992320 мы знаем, что это ведёт к невозможности увидеть их в форме выбора библиотечных шагов. Тем не менее, полученная информация о внутреннем устройстве этих шагов и реализующих их методов поможет нам дальше:

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

Итак, задействуем в нашем сценарии эти два шага. Один будет добавлять ссылку к логу выполнения сценария, а другой — прикреплять файл к шагу:

И Я подключаю файл ‘$workspaceRoot/allure/ПроизвольныйФайл.txt’ к шагу

И Я устанавливаю ссылку «//infostart.ru/public/1010127» с именем «Публикация с секретными возможностями Vanessa-ADD»

Загрузим один этот сценарий в bddRunner.epf и убедимся, что шаги корректно связались с реализующими их обработками:

Запустим наши команды по выполнению сценариев, генерации и открытию отчета Allure:

vanessa-runner vanessa —settings featuresVanessaRrunnerSettings.json

allure generate —clean allurexml_for_allure -o allurehtml_report

allure open allurehtml_report

Теперь можно увидеть, что нам стал доступен раздел Links, где есть нужная нам ссылка:

Прикрепить к шагу можно не только файл с текстовым содержимым (txt, json, xml) , но и например бинарный файл или картинку :

Существующий шаг встроенной библиотеки, как мы видели из кода реализующего его метода, определяет тип файла для отчета Allure исходя из его расширения. Но тип «jpg» не является валидным для Allure. Получив тип «jpg» фреймворк не в состоянии понять, что этот файл следует отобразить не как бинарные данные, а как изображение:

Чтобы передать правильный тип такого файла можно написать собственный шаг по образцу типового. Но можно воспользоваться и шагом исполнения произвольного кода. Передадим в метод ДобавитьФайлКТекущемуШагу описание типа, которое Allure сможет корректно обработать:

Снова выполнив сценарии и сгенерировав отчет, мы увидим, что теперь  Allure корректно отображает подключенное изображение:

Сколько стоит купить лицензию, варианты поставки

В рассмотренных выше примерах отчетности сценарии, которые были выполнены с ошибками, выделялись красным цветом.

В расшифровке мы также могли увидеть, на каком шаге произошла ошибка:

Но часто этой информации бывает недостаточно, чтобы понять в чём именно проблема. Ведь то, что ошибка зарегистрирована на каком-то шаге, не обязательно означает, что ошибка возникла именно в момент его выполнения. Часто это просто проверочный шаг-утверждение. Утверждение оказалось неверным и поэтому сценарий упал именно на этом шаге.

Например мы забыли указать цену в заказе клиента и потом попытались провести его, ожидая что вместо окна документа «Заказ клиента» откроется другое окно  (например ранее открытая форма списков заказов). В этом случае отчет о выполнении сценария сообщит нам, что ошибка зафиксирована на шаге, проверяющем, что открыта форма списка заказов. Но настоящая причина в том, что не было закрыто окно нового заказа при его проведении. При этом даже саму кнопку «Провести и закрыть» в тест-клиенте нажать удалось. А окно в свою очередь не закрылось из-за ошибок в заполнении документа и появления ошибки уже после нажатия на кнопку «Провести и закрыть».

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

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

Для создания скриншотов Vanessa-ADD использует внешние инструменты. Для этого она может взаимодействовать с двумя приложениями: Nircmd или IrfanView. Команды, которые необходимо использовать как для Nircmd, так и для InfranView описаны в F.A.Q. по фреймворку:

Подобно тому, как мы делали с фреймворком Allure, добавим путь к утилите в переменную PATH и убедимся, что система её находит выполнив команду where nircmd:

После этого необходимо перезапустить консоль, из которой мы собираемся вызывать запуск сценариев, или сеанс тест-менеджера, если выполняем запуск интерактивно. Иначе они не получат новое значение переменной PATH и при начале выполнения сценариев с нужными нам настройками для создания скриншотов просто произойдёт зависание с выводом ошибки в окно сообщений тест-менеджера:

Указать необходимость делать скриншот и команду для его снятия можно в графическом интерфейсе Vanessa-ADD. Но мы уже хорошо умеем работать с консолью )) Поэтому сразу перейдём к конфигурационному файлу и добавим в него необходимые для этого строки:

Выполним команду  vanessa-runner vanessa —settings featuresVanessaRrunnerSettings.json

Результатом будут скриншоты окон, снятые в момент возникновения ошибок. И часть файлов, содержащих исходные данные для генерации HTML-отчета, будут ссылаться на эти скриншоты:

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

Allure Report Features

As you can see, after execution, Allure provides the parameterized test run results as a set of tests. If any of the tests fail, Allure provides detailed information about that particular case.

Categories is one of the most time-saving features of Allure Report. It provides simple automation for fail resolution. There are two categories of defects by default:

Categories are fully customizable via simple json configuration. To create custom defects classification, add categories.json file to allure-results directory before report generation.

Test result falls into the category if its status is in the list and both the error message and the stack trace match the pattern.

In the case of using allure-maven  or allure-gradle plugins, categories.json  file can be stored in the test resources directory.

Retires are executions of the same test cases (asignature is calculated based on test method name and parameters as well) within one test suite execution, e.g. when we are using TestNG IRetryAnalyzer or JUnit retry Rules. Not supported for local runs.

Allure 2 supports history for tests in the report. At each report generation during the build, the Allure Plugin for Jenkins will try to access the working directory of the previous build and copy the contents of allure-reporthistory folder to the current report.

At the moment the history entry for the test case stores information for up to 5 previous results. Not supported for local runs.

Набор подсистем «Умные таблицы»

Инструментарий разработчика Платформа 1С v8.3 Беларусь Россия Казахстан Абонемент ($m)

Данный набор подсистем – прикладная библиотека, призванная помочь программисту 1С быстрее решать ряд типовых задач бизнес-логики, таких как: ведение статусов объектов, отправка почтовых сообщений в определенное время, ведение произвольных таблиц с возможностью редактирования, сохранения и группировки, ориентированные на расчет бюджетных таблиц (план продаж, ретробонусы B2C, проценты по договорам B2B и договорные условия по КАМ), расчет коммерческой политики для бюджетных таблиц, исполнение произвольных алгоритмов с хранением кода в информационной базе, определение рабочих баз, хранение файлов во внешних СУБД (Postgre SQL, MS SQL и MongoDB) и выполнение произвольного кода после изменений ссылочного объекта вне транзакции изменения.

Allure Report Launch

A great way to get started with Allure Report is to run it locally. Local execution does not provide execution and results history, nor the trend graphs.

The best way to give Allure Report a try is to open an example with an IDE. Check all the dependencies and build the project with Gradle.

After that, we need to run the tests with the./gradlew test command. When the tests are executed, Gradle will store the results in the target directory.

Let’s take the data and build a report! With the allure serve /path/to/the/project/allure-example/build/allure-results command, we start the Allure Report instance and build a local web report which automatically opens as a page.

CI (Jenkins, TeamCity, and Bamboo)

Plenty of native integrations with programming languages, testing frameworks, including Java (jUnit, TestNG), Python (PyTest, Nose), JavaScript (Jasmine, Mocha), .NET, Cucumber, Go, PHP ready to run on any CI system (Jenkins, Bamboo, GitLab, GitHub, CircleCI, TeamCity, and others).

Как было раньше?

Обычно тест состоит из следующих шагов:

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

Что дальше?

На этом цикл публикаций, посвященных сценарному тестированию и BDD заканчивается. Но возможности Vanessa-ADD и параллельного проекта Vanessa-Automation не ограничиваются тем, что мы рассмотрели в этих пяти публикациях.

Если Вы планируете продолжить изучать и применять сценарное тестирование и разработку через тестирование, то дальше Вас ждут:

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

Как заставить открываться «Все функции» в 97 раз быстрее!

Инструментарий разработчика Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Очистка кэша 1С 8 (8. 0, 8. 1, 8. 2, 8. Грамотная чистка кэша 1С с сохранением настроек.

Инструментарий разработчика Платформа 1С v8.3 Конфигурации 1cv8 Россия Абонемент ($m)

Эффективное средство для устранения ошибок, возникающих в локальном кэше 1С на клиенте, которым легко сможет воспользоваться пользователь с любым уровнем знаний.
Wsf-скрипт, созданный на стандартном языке автоматизации Windows — «WSH JScript», очищает кэш 1С просто, быстро и безопасно.
Кроме варианта, очищающего кэш текущего пользователя, имеется также вариант для чистки кэша 1С всех пользователей терминального-сервера.

Как будет?

Рассмотрим самый простой кейс, когда нужно сделать запрос и проверить пару полей:

А если в тесте возникнут какие-то проблемы, то отчёт будет такой:

При этом мы поддержали все возможные теги и лейблы Allure.

Сейчас мы рассмотрели самый простой тест с минимальным количеством информации, проверок и без каких-либо дополнений.

Заинтересовались? Тогда давайте рассмотрим все возможности библиотеки.

Что сейчас?

В целом эта команда замечательно работает. У нас есть пайплайн, на котором гоняются тесты, собранные в нескольких quality-гейтах. Обычно это какая-нибудь регрессия, приёмочное тестирование, смоук или какой-то канареечный релиз. Всё это есть в пайплайнах. Эти автотесты работают — периодически запускаются, падают или не падают. Если падают, то кто-то разбирает результаты. Сошлюсь тут на хабрапост от Superjob.

Одновременно с этим существует небольшой аппендикс, где ручные тестировщики на новую функциональность или сложные e2e-тесты всё ещё пишут развесистые тест-кейсы и прогоняют их руками. И в целом вроде бы всё работает. Как на картинке  — машинки летят отдельно, люди летят отдельно, тесты выполняются, светофоры есть — очень круто. Ну, DevOps же!

Но тут я вспоминаю более раннюю фразу того же Серёги Егорова от 15 марта 2021 года:

Эта цитата великолепна. Можно сразу и не заметить, что в слове DevOps нет буквы Т, и так же можно не замечать, что с тестированием в DevOps всё тоже не так понятно.

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

Невидимая сторона

Глядя на такой слайд, скорее всего, вы ждёте, что справа что-нибудь появится — какой-то текст или буллет-пойнты:

Но там ничего нет и не появится — сколько ни вглядывайтесь. Это и есть та невидимая сторона. И она выглядит как подразделение QA, которое немножечко выпадает из истории. Почему? Потому что тестировщики тоже пишут тесты.

Зачастую в подразделениях, которые занимаются качеством, ручники правят балом. Это значит, что структура тест-кейсов, процессы в отделе, механики разбора результатов, механики по составлению отчетов, основные детали и взаимодействия с другими подразделениями построены по принципам, которые были разработаны довольно давно. Это хорошие принципы, они позволяют находить очень много багов и вовремя их исправлять. Но пока весь остальной мир бежит галопом в сторону DevOps и пытается сделать shift left всего, что можно (или shift right, если left невозможно), это разбегание shift left — shift right, приводит к тому, что тестирование подбуксовывает.

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

И они действительно пишут автоматизированные end-to-end тесты, которые чаще всего выглядят как ручные тестовые сценарии, которые загнаны в REST-код и гоняются на вашем CI/CD. И если вы это смотрите, то вполне вероятно, что вы ровно в этой ситуации и находитесь. Потому что, с точки зрения DevOps, тестирование есть — тесты присылают, они гоняются, результаты разбираются, ещё и девелоперы накидывают своих тестов. Да вообще всё круто! Все quality-гейты выглядят солидно.

Но эту штуку можно очень сильно улучшить. И об этом мы поговорим, чтобы ваше тестирование соотносилось с теми практиками и подходами, которые существуют в DevOps.

TestOps Lifecycle

Недавно мы в Qameta сформулировали штуку, которая называется TestOps Lifecycle. Она рассматривает девять стадий развития тестовой инфраструктуры команды и процессов.

Каждый ряд отвечает за некую веху (M — manual, A — automated, T — TestOps), а каждый столбик — за степень её развития. М1 — ручное тестирование, которое только зародилось. A3 — это супер-топовая автоматизация.

TestOps — это подход, который мы предлагаем, чтобы естественным образом вернуть тестирование в DevOps. Долго название мы не выдумывали: DevTestOps не звучит, поэтому оставили просто TestOps. Подробнее о жизненном цикле говорилось в докладе Артёма Ерошенко «Сказка о потерянном времени». А еще подробнее этот концепт был раскрыт в нашем блоге.

Зачем нам нужен TestOps? Именно с этого вопроса и появился этот доклад, потому что полгода назад после конференции Heisenbug, когда мы сидели в барчике, я рассказывал коллегам, что мы делаем свой продукт, который помогает компаниям реализовывать TestOps. Меня спрашивают: «А что за TestOps? Ведь тестирование же и так есть в DevOps, ты же знаешь классический треугольник: Dev, Ops и QA».

И действительно, смотрите, все работают вместе:

У девелоперов 80% кода покрыто тестами. Ops-ы говорят: «Слушайте, даже если мы что-то не успеваем, давайте делать canary-релизы». Управление качеством происходит. Но при этом тестирование происходит не всегда хорошо.

Где-то там находится маленький автоматизатор на стыке девелоперов и QA, потому что, скорее всего, автотесты гоняются на отдельном сервере на отдельные сборки. При этом руководитель подразделения говорит: «Слушайте, вы тут написали функциональности, нам нужен день на написание новых тест-кейсов, чтобы эту функциональность нормально end-to-end проверить. А ещё нужно денька два на прогон, потому что мы сейчас 50 ручных тестов проверим, а у нас пять тестировщиков. У них это займёт некоторое время»

Действительно ли тогда картинка выглядит так? Возможно, она выглядит как-то так:

Девелоперы говорят: «QA не нужно, мы сами все тесты напишем».

Ребята из QA говорят: «Там всё гоняется, ребята хотят сильно быстрее. Пойду-ка я чек-листы обновлю и всё будет нормально».

Ops-ы кричат: «Так, у нас все процессы уже готовы, валите-ка вы нафиг. Смотрите, пайплайны есть, quality-гейты есть, тесты гоняются, результаты проверяются, релизы чистые. Мы же катим в прод! Ну да, бывают баги».

На предыдущем слайде вы видели Зеппа Браннигана, и он такой: «Ну, я пошёл заниматься своим делом». Можно подумать, что я хочу сказать, что ручные тестировщики — нехорошие. Но это не так. Ручные тестировщики — крутые специалисты. Они молодцы, они классно делают свою огромную работу, и у них есть свои уникальные компетенции. Но они не успевают писать тесты на новую функциональность, потому что последние годы заставили менеджеров думать, что нам нужно два релиза в день.

Ещё раз сделаю отсылочку к ребятам из SuperJob, потому что у них была такая же история. У них была куча ручных тестировщиков, и они релизились раз в неделю. Потом пришел кто-то из менеджеров и сказал: «Слушайте, ребятки, тут все вообще-то релизятся два раза в неделю». И все такие: «Ну, давайте релизиться дважды в неделю». Ручные тестировщики почесали репу: «Тогда нам придётся рабочий день увеличивать или тестировщиков нанять, потому что это долго. Давайте что-нибудь попробуем автоматизировать». Они взяли базовый PHP-фреймворк, начали писать тестики на PHP и всё ускорили.

Потом приходят менеджеры и говорят: «Так, мы в два раза ускорились. Давайте теперь дважды в день релизить». И тут начинается головная боль, потому что в таком темпе вообще никак это не успеть. И есть ещё куча проблем — ребята не успевают прогонять эти тесты, особенно если они ручные. Разбирать падения — это вообще боль, потому что, если у вас есть тысяча тестов и падает 5%, это 50 тестов. Если у вас нет автоматизации, репортинга и так далее, то вручную всё это проверять — это больно.

Раньше не было никаких инструментов, поэтому сейчас нужно за ними активно следить на конференциях. А мы знаем, какой процент людей ходит на конференции или митапы. Кто-то, может, почитывает Хабр, и на этом всё. Не все знают про новые инструменты, и нет никакого глобального обучения. Нормальные курсы появляются только сейчас. Поэтому надо учиться, учиться и еще раз учиться, а у ручных тестировщиков и своей работы немало.

Как жить

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

Вот та самая «схема из девяти квадратиков», в реальности она выглядит чуть-чуть сложнее:

Мы сегодня не будем рассматривать все 9 стадий, потому что в контексте этого доклада нам интересно, когда уже есть какое-то тестирование и нам нужно его двигать вперед. Нас интересуют 5 стадий.

Я попробую рассказать вам, как из М2 перейти в стадию А1, то есть ввести какую-то автоматизацию. А затем её поднастроить.

И есть опциональные шаги, которые можно пропустить, если у вас уже очень крутая команда.

Итак, как нам прийти в шаг Т2? Мы не говорим про T3, потому что там уже условная команда мечты и всё прекрасно.

M2-M3

Первая история — это переход из М2 в М3. Давайте посмотрим, что такое стадия М2. Это когда у нас есть команда нормальных ручных тестировщиков-миддлов, парочка сеньоров, и основные задачи на этом этапе — повышать прозрачность тестирования.

То есть делать такие процессы, чтобы люди понимали, куда все двигается, какие тесты прошли, какие не прошли. Формализовать работу с тест-кейсами, создать шаблоны, спроектировать все эти тест-кейсы и уйти от принципа «чуваки, не парьтесь, я всё проверил». Условно, если разработчик говорит: «Вот эту функциональность проверять не надо, там всё покрыто тестами», ручные тестировщики на этапе М2 должны сказать: «Нет, подожди, мы напишем свои E2E-тесты и всё погоняем».

Здесь важно понять, что на этом этапе уже нужны коммуникации. Я уже упоминал, что тестировщики и разработчики относятся к тестированию по-разному. Разработчик пытается убедиться в том, что всё работает, как надо. А тестировщики пытаются найти случаи, в которых что-то работает не так.

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

И в этом месте нужны TMS — Test Management Systems, которые заменяют тестировщикам в больших командах условный Excel. Они позволяют использовать удобный интерфейс для создания тест-кейсов, проходить в них шажки и галочками всё отмечать. Многие TMS умеют закидывать результаты ручного тестирования на СI, чтобы CI сам понимал, что тесты прошли и прогон можно зацепить вебхуком, чтобы всё побежало. В качестве примеров назову TestRail и PractiTest — это индустриальные стандарты, они очень часто используются.

Чтобы попасть из стадии M2 на M3, нужно сначала начать измерять время качества и количества прогонов и покрыть все E2E-тестами, а затем переходить к следующему шагу: оптимизировать ручную работу.

При этом есть два пути. Можно сразу пойти за автоматизацией в А1. А можно пойти в сторону M3: это когда у нас появляется команда крутых ручников, умеющих использовать инструменты автоматизации ручного тестирования. То есть инструменты вроде Postman, Playwright, Fake Data, QA Wolf, инструменты для тестирования, которые позволяют эмулировать вёрстку на экранах с разными разрешениями без обилия разных девайсов и ручного запуска всех этих вещей.

А для чего все это? Для того, чтобы начать верить в автоматизацию. Тогда дальнейший переход в А1 будет намного менее болезненный.

Зачем нам вообще переходить из этого места? Потому что на М2 мы можем только донанимать тестировщиков, и у этого подхода, очевидно, есть пределы. M3 масштабируется намного лучше, потому что автоматизированные инструменты позволяют всё померить, понять, где проблемы, и что-то оптимизировать. Но при этом все еще остается большой предельный срок и мы все еще зависим от людей, которые осуществляют тестирование, и мы можем забыть о трех ночных прогонах. Нет, наверняка есть команды, в которых тестировщики любят работать по ночам. Однако это не очень хорошо с точки зрения вселенной и отношения к людям. Поэтому мы хотим от этого уходить.

M2-A1

Давайте посмотрим на переход от М2 к А1. А1 — это стадия, на которой у нас есть один автоматизатор и основные задачи — просто начать что-то автоматизировать и покрыть простыми тестами mission-critical кейсы. При этом у нас Restful-тесты будут полностью копировать пошагово ручные сценарии.

Вторая штука — это научиться делать самодокументацию. При изменении какой-то функциональности или изменении теста, если самодокументацию не сделать, то она начнёт очень быстро устаревать, когда мы начнем наращивать объем тестов. Каждое отделение фиче-ветки будет делать документацию устаревший, потому что где-то меняется функциональность. Вручную документацию править плохо, потому что автоматизатор поправит тест, а ручной тестировщик, который занимается докой, про это может вообще не вспомнить или не узнать. Вы, конечно, можете заниматься тем, чтобы строить сложные системы коммуникации и нотификации в Slack, но может быть всё-таки стоит подумать про автоматизацию — мы же на DevOps-конференции 🙂

Здесь у нас остаются некоторые проблемы — сильно быстрее не стало, и вот это очень опасный шаг. Потому что мы начали делать автоматизацию, смотрим на это и думаем: «Быстрее не стало, зато стало очень запутаннее!» У нас появилась куча инструментов, новые люди, которые немножко отличаются от классических тестировщиков, у нас появились новые коммуникации. Теперь ещё и тестировщики странно на нас поглядывают.

A1-A2

Поэтому нам нужно быстренько двигаться в стадию А2. А это такая стадия, на которой автоматизаторы уже умеют пушить в репу и строить аналитику в Grafana. Компании уже стараются построить стабильность SQS — Software Quality System. И первое, что здесь нужно это сделать — кнопку для всех. Что значит кнопка? Это значит, что когда мы увеличили покрытие автоматизации, когда мы уже знаем, что наши тесты хорошие, мы начинаем эти тесты потихонечку перепиливать и делать их атомарными.

Готовим сами данные и готовим какое-то API, чтобы эти тесты нормально ходили туда-сюда в код. При этом это можно делать и со стороны разработки, и со стороны тестирования. То есть, когда мы научим наших двух Бендеров со стороны разработки и со стороны тестирования общаться, мы должны сделать кнопочку и заставлять всех нажимать эту кнопочку. А кнопочка делает одну простую вещь — запускает набор автоматизированных тестов и показывает результат. И мы делаем так, чтобы про эту кнопку все знали.

Если у нас покрытие обеспечено, как только у нас возникает эта история, могут возникнуть и проблемы. Наша задача — сделать так, чтобы разработчик сделал фиче-ветку и как только внес изменения, то нажал кнопку. Если где-то что-то упало, мы должны быстро пофиксить тесты, а если они фиксятся долго, то, скорее всего, на шаге А1 мы что-то сделали не так — надо возвращаться и переделывать.

Что такое атомарные тесты? Это значит, что когда у нас существует развесистый тест-кейс из предыдущего пункта, он в автоматизации жутко неудобен. Потому что автоматизация привыкла тестировать одну функцию. Если у разработчика есть один юнит-тест, он же не такой уж и большой. И здесь мы стремимся к тому же самому эффекту — мы хотим, чтобы один тест тестировал маленькую функциональность. Всё остальное мы мокаем, закрываем заглушками, изолируем и делаем на один ручной тест-кейс пять-семь автоматических тестов. И вот в этот момент сама документация нам очень важна, потому что эти пять-семь тестов очень сложно будет смапить на ручные тест-кейсы, которые существовали до этого в документации. Документация она существует либо в testRel, либо в Confluence в виде списка тест-кейсов или тест-сьютов. И как только мы попробуем эти автоматизированные тест-кейсы натянуть на нашу документацию, мы поймём, что все плохо. Если у нас будет сама документация, то у нас будет больше тестов в доке, но при этом каждый из них будет всегда актуален.

И когда это всё происходит, наш Бендер становится расслабленный, берет бутылочку пива и, в целом, всё хорошо. Я снова возвращаюсь к истории Superjob, потому что ребята круто всё сделали. Они действительно настроили автоматизацию таким образом, что регрессионные и acceptance quality-гейты прогонялись полностью автоматически, они начали релизить дважды в сутки, это тоже круто. У них остался только один дежурный разработчик и один дежурный тестировщик на случай, если релизы вдруг падают или не проходят «качественные ворота».

Но опять же, если вы почитаете статью, то в конце увидите замечательную мысль о том, что все еще не закончено. Потому что у вас все еще есть куча проблем. Флакающие тесты, которые дают разные результаты при неизменном коде теста — в зависимости от времени запуска, в зависимости от инфраструктуры, на которой запустили, в зависимости от параметров launch-a, в зависимости от положения Меркурия в доме Луны (или как это правильно говорится?). В общем, в зависимости от странных и непонятных факторов.

Здесь наши инструменты — это Grafana, Allure Report, ReportPortal и так далее. Эти штуки позволяют нам смотреть аналитику с автотестов быстро, четко, понятно. Заодно они помогут нам результаты разбирать.

Файл настроек запуска Vanessa-Runner

Помимо того, что утилита Vanessa-Runner может оперировать файлом с параметрами запуска Vanessa-ADD, она также может принимать свои собственные параметры в виде json-файла.  Это позволяет сократить длину консольной команды для запуска, что удобно, когда параметры командной строки при запуске меняются редко и при этом их достаточно много. А ведь это типичная ситуация в случае автоматического запуска сценарных и дымовых тестов.

Путь к этому файлу задаётся через специальный параметр —settings консольной команды runner (или её синонима vanessa-runner).

Файл позволяет задавать настройки по умолчанию в специальном блоке default. Для каждой отдельной команды Vanessa-Runner (таких как run, xunit, vanessa) могут быть заданы одноимённые блоки, где переопределяются настройки по умолчанию. То есть при выполнении конкретной команды берутся настройки по умолчанию, а затем дополняются и переопределяются настройками заданными для конкретной команды.

Возьмем например файл приведенный в репозитории на github:

Согласно нему для всех команд кроме команд runner vanessa и runner xunit будет использоваться база данных по относительному пути build/ib. Но для команды runner xunit будет использоваться другая база из каталога build/ibservicexdd.

Для всех команд рабочим каталогом будет считаться текущий каталог. Но для команды runner vanessa рабочим каталогом (каталогом проекта) будет являться подкаталог features текущего каталога.

Таким образом преимуществом задания параметров в файле является не только сокращение консольных команд, но и возможность задать параметры сразу для многих команд Vanessa-Runner и использовать один файл для команд run, vanessa, xunit и так далее.

Поскольку сейчас мы планируем выполнять только команду runner vanessa, запускающую сценарное тестирование, то настройки можно задавать как в блоке default , так и в блоке vanessa и даже свободно перемещать между ними. На результат запуска это не повлияет. Но всё же правильно будет оставить параметр —vanessasettings в специфичном для команды runner vanessa блоке:

Командная строка запуска сценарного тестирования с использованием такого файла будет выглядеть крайне минималистично:

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

Если запуск сценарных тестов выполняется не под специально созданными временными пользователями с постоянно меняющимися паролями, то имеет смысл хранить параметры авторизации в более безопасном месте. Например при использовании Jenkins их можно задавать в специальном хранилище данных авторизации, а при исполнении задачи сборки/тестирования данные авторизации можно считывать из него и передавать в командную строку. В то время как большинство остальных неизменных параметров продолжат храниться в конфигурационном файле:

Подсистема «Показатели объектов»

Если вашим пользователям нужно вывести в динамический список разные показатели, которые нельзя напрямую получить из таблиц ссылочных объектов, и вы не хотите изменять структуру справочников или документов — тогда эта подсистема для вас. С помощью нее вы сможете в пользовательском режиме создать свой показатель, который будет рассчитываться по формуле или с помощью запроса. Этот показатель вы сможете вывести в динамический список, как любую другую характеристику объекта. Также можно будет настроить отбор или условное оформление с использованием созданного показателя.

Установка Allure 2

На этой странице есть ссылка для загрузки zip-архива с последней версией фреймворка, который подходит для операционной системы Windows.

После скачивания и распаковки этого архива полный путь к подкаталогу bin, где хранится исполняемый файл allure.bat, необходимо добавить в системную переменную PATH:

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

Если всё сделано правильно, то при определении из консоли месторасположения файла, отвечающего за команду allure, мы получим наш путь:

На этом установка Allure 2 закончена.

Запуск через Vanessa-Runner

Как мы видели выше, ручное формирование параметров запуска является проблематичным. Нам необходимо при каждом запуске прописывать путь к платформе, путь к обработке bddRunner.epf и ключ /TESTMANAGER.

Для упрощения запуска платформы 1С:Предприятия и управления из консоли различными составляющими платформы существует удобный инструмент — Vanessa-Runner, который также как и Vanessa-ADD может устанавливаться как одна из библиотек OneScript. Этот инструмент предоставляет удобные возможности для управления кластером серверов 1С через службу администрирования RAS, управления хранилищем, компиляции/декомпиляции файлов конфигурации и внешних обработок,  команды для запуска платформы 1С в различных режимах и т.д.

Как и в случае с большинством библиотек OneScript установка Vanessa-Runner может быть выполнена менеджером пакетов opm через команду  opm install vanessa-runner:

Среди этих команд есть две важные для тестирования прикладных решений:

Получим справку по команде runner vanessa:

Параметр —vanessasettings  заменяет параметр VBParams, который мы указывали при запуске bddRunner.epf из командной строки без применения Vanessa-Runner. Через него мы будем передавать путь к json-файлу настроек для запуска bddRunner.epf.

Доступен параметр —workspace, определяющий каталог проекта и заменяющий параметр workspaceRoot, который мы задавали при использовании CLI платформы 1С. Если параметр —workspace не задавать, то он всё равно будет явно передаваться в команду запуска платформы 1С, но при этом будет автоматически устанавливаться в значение текущего каталога:

Рассмотрим, что происходит при выполнении команды

Vanessa-Runner видит команду vanessa и понимает, что необходимо запустить Vanessa-ADD. Для этого она формирует нужную строку запуска платформы 1С и затем выполняет её:

1)  Она автоматически определяет путь к наиболее старшей версии платформы из установленных в системе и запускает платформу по этому пути. Этим поведением можно управлять через параметр —v8version.

2)  Также она автоматически подставляет путь ко внешней обработке bddRunner.epf. Если Vanessa-ADD установлена как библиотека OneScript в каталог OneScript/lib/add, то путь подставляемый по умолчанию подойдёт. Если же установка была произведена в другой каталог, то следует воспользоваться параметром —pathvanessa чтобы явно задать путь к bddRunner.epf.

3) Такие параметры как /TESTMANAGER , /DisableSturtupDialogs, /C»StartFeaturePlayer» подставляются в командную строку запуска платформы 1С автоматически.

4) Другие опции запуска получаются путем преобразования параметров Vanessa-Runner в параметры Vanessa-ADD или параметры тонкого клиента.

Параметр —additional — это то, что ранее мы передавали как значение параметра  /C. Так как для задания VBParams он нам больше не нужен, и ключ StartFeaturePlayer тоже подставляется автоматически, то в большинстве случаев запуска bddRunner.epf его не нужно будет указывать. Но при необходимости мы по прежнему можем передавать через него любые дополнительные параметры, например при использовании типовых конфигураций может оказаться удобен ключ «РежимОтладки».

Также рекомендую обратить внимание на параметр —v8version. Он позволяет автоматически подбирать заданную версию платформы, а не последнюю из доступных. Например, если в системе установлены 8.3.10.2466,  8.3.12.1529 и 8.3.14.1450, можно запустить версию 8.3.12.1529 вместо последней из доступных указав параметр —v8version 8.3.12

Крайне важной особенностью запуска Vanessa-ADD через Vanessa-Runner является возможность их взаимодействия через временный текстовый файл. Платформа 1С не умеет работать с потоками stdout и stderr (а значит и с cmd и ssh) в реальном времени. Чтобы узнать результат выполнения какой-либо операции нам приходится дожидаться её полного завершения. А Vanessa-Runner может получать информацию о ходе выполнения сценариев и/или дымовых тестов от Vanessa-ADD онлайн, не дожидаясь завершения тестирования. Это преимущество может показаться незначительным, до тех пор пока мы итак смотрим глазами на результат выполнения команд и на процесс работы тест-клиента и тест-менеджера. Но ценность вывода лога выполнения в stdout и stderr становится очевидна при запуске сценариев на CI-сервере, когда текстовый лог выполнения — это основа мониторинга состояния выполняемого приложения со стороны CI-сервера.

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

Посмотрим на процесс запуска и выполнения сценариев через Vanessa-Runner теперь. На протяжении всего хода выполнения сценариев мы видим прогресс и служебные сообщения в консоли:

Faster — многофункциональный ускоритель работы программиста 1С и других языков программирования
Промо

Программа Faster 9.4 позволяет ускорить процесс работы программиста
(работает в любом текстовом редакторе).
Подсказка при вводе текста на основе ранее введенного текста и настроенных шаблонов.
Программа Faster позволяет делится кодом с другими программистами в два клика или передать ссылку через QR Код.
Исправление введенных фраз двойным Shift (с помощью speller.yandex). Переводчик текста. Переворачивает текст случайно набранный на другой раскладке.
Полезная утилита для тех, кто печатает много однотипного текста, кодирует в среде Windows на разных языках программирования.
Через некоторое время работы с программой у вас соберется своя база часто используемых словосочетаний и кусков кода.
Настройка любых шорткатов под себя с помощью скриптов.
Никаких установок и лицензий, все бесплатно.

Файл настроек запуска bddRunner. epf

Есть однозначное соответствие между большинством из этих параметров и настройками, задаваемыми на вкладке «Сервис» и вкладке «Библиотеки» в Vanessa-ADD:

Но возможности, предоставляемые файлом настроек и запуском из консоли всё же больше, чем предоставляют интерактивные настройки. Описание большинства из параметров также можно найти по приведённым выше ссылкам на репозитории github. Повторим здесь описание наиболее важных из них, и на их примере рассмотрим правила указания параметров в зависимости от их типа данных.

При указании значений значений, являющихся путями к каталогам, допустимо использовать шаблоны подстановки $workspaceRoot, вместо которого будет подставляться значение ключа командной строки workspaseRoot, и $instrumentsRoot — каталог установки Vanessa-ADD.

«КаталогиБиблиотек» — задаёт массив путей к библиотекам, которые после загрузки тест-менеджера также появятся на вкладке «Библиотеки». Массив в формате Json задаётся в квадратных скобках, элементы массива перечисляются через запятую.

«ВыполнитьСценарии» — булево. Задавать значение типа булево для bddRunner.epf можно как в виде литералов true / false, так и в виде строк «Истина» / «Ложь». Как уже было сказано выше, если мы хотим, чтобы сценарии после открытия bddRunner.epf загрузились на вкладку выполнения сценариев необходимо передавать в этот параметр Истину. Но также это приведёт к автоматическому старту выполнения сценариев после их загрузки.

«ЗакрытьTestClientПослеЗапускаСценариев» — булево. Определяет будет ли закрыто тестируемое приложение (тест-клиент), но не после запуска сценариев, как можно подумать исходя из названия параметра, а после выполнения всех сценариев.

«ЗавершитьРаботуСистемы» — булево. Определяет будет ли закрыт тест-менеджер после выполнения сценариев.

При автоматизации тестирования на сервере CI оба этих параметра «ЗакрытьTestClientПослеЗапускаСценариев» и «ЗавершитьРаботуСистемы» имеет смысл устанавливать в Истину. Ведь нам не нужно чтобы на сервере накапливались незакрытые сеансы 1С. Но например для случая отладки бывает смысл устанавливать эти параметры в Ложь, чтобы подключившись к серверу увидеть в каком состоянии находятся тест-менеджер и тест-клиент своими глазами.

«ДелатьСкриншотПриВозникновенииОшибки»  — булево. Определяет будет ли автоматически выполняться скриншот при возникновении ошибки. Крайне важный параметр для автоматизации тестирования. Без скриншота при возникновении ошибки мы будем иметь только тестовые логи выполнения сценариев и зачастую будет сложно или невозможно сразу понять в чём причина ошибки. Скриншоты часто позволяют экономить время и не прогонять повторно весь сценарий вручную, чтобы увидеть где возникла ошибка. Есть аналогичный параметр, который говорит о том, что нужно делать скриншот каждого окна. Но обычно в его установке нет необходимости и создание скриншотов каждого окна только замедлит выполнение сценариев.

Этот параметр не является независимым. Он лишь говорит, что скриншот нужно делать. А как именно его делать задают два следующих параметра:

«КаталогOutputСкриншоты»: «$workspaceRoot/build/output/screenshots»  — определяет куда будут складываться скриншоты.

«КомандаСделатьСкриншот»: «»C:Program Files (x86)IrfanViewi_view32.exe» /capture=1 /convert=»  — определяет консольную команду для создания скриншотов.

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

«ДелатьОтчетВФорматеАллюр» — булево. Определяет необходимость формировать данные, которые затем фреймворк Allure сможет «перварить» в красивый отчёт HTML.

«КаталогOutputAllureБазовый»: «$workspaceRoot/build/output/allure/results-vb-testing» — задаёт каталог для выгрузки json-файлов, содержащих данные для фреймворка Allure из которых впоследствии можно формировать отчет в  HTML.

«ДелатьЛогВыполненияСценариевВТекстовыйФайл» — булево. Позволяет указать системе, что необходимо вести онлайн-лог выполнения сценариев в текстовый файл. Это бывает полезно, чтобы например отследить зависшие сценарии или просто понимать, на каком этапе находится процесс. Ниже будет рассмотрено использование этой настройки на примере запуска сценарного тестирования через Vanessa-Runner. Применение Vanessa-Runner позволит автоматически выводить содержимое этого файла в консоль.

«ИмяФайлаЛогВыполненияСценариев»: «$workspaceRoot/build/vanessaonline_testing.txt»  — задаёт соответствующий файл для ведения лога.

Следующие параметры соответствуют настройкам «Список исключаемых тэгов» и «Тэгов для запуска» на вкладке «Сервис». Они задаются как массивы строк:

Консоль Внедренца v

Идея данной обработки заключается в создании простого, функционального и универсального инструментария для внедренцев и программистов 1С, который будет работать как в толстом клиенте на обычных и на управляемых формах, так и в тонком клиенте. Интерфейс и логика работы максимально идентичны у обычных форм и управляемых. Инструментарий включает в себя: Консоль кода, Консоль запросов, Консоль отчетов (СКД), Универсальную обработку объектов, Средства для работы с таблицами базы данных 1С, Редактирование регистров сведений базы, Инструмент по работе с табличными документами — загрузка данных из табличного документа.