Автор статьи: Павел Балахонов, более 13 лет в автоматизации тестирования
В данной статье хочу затронуть важную тему — тест-дизайн в автоматизации тестирования. Почему эта тема важна? Потому что качество автотестов и инструментов автоматизации тестирования напрямую зависит от того тест-дизайна, который будет заложен в ваш инструмент автоматизации тестирования. Но перед тем, как перейти к дизайну автотестов и инструментов автоматизации тестирования, предлагаю рассмотреть основные показатели качества автотестов:
Стабильность
Скорость
Стоимость
Скорость
На мой взгляд, это очень важный показатель качественных автотестов, которым многие команды просто пренебрегают. Чаще всего автотесты запускаются в пайплайнах сборки тестовых стендов, и, когда стенд собирается ночью, то хочется получить результаты тестирования развернутого релиза утром в начале рабочего дня. Я думаю, мало кто хочет, запустив автотесты, ждать, пока они пройдут и сообщат результат спустя 1-2 рабочих дня. Поэтому крайне важно иметь быстрые тесты. Как это достигается? На самом деле, самые популярные способы получения быстрых прогонов тестов следующие:
Сокращение пула с автотестами, который запускается после сборки стенда. В данном способе мы можем выделить основные сценарии, с помощью которых можно будет провести смок тестирование всех основных компонентов развернутого программного продукта и прогонять на регулярной основе только эти сценарии. С одной стороны мы ускорим время прогона автотестов за счет сокращения пула, но с другой стороны мы не сможем гарантировать ту полноту тестирования, которую можно достичь при прогоне пула со всеми автотестами.
Параллелизация тестов. На мой взгляд один из основных способов ускорения автотестов. Есть разные варианта параллелизации автотестов: thread side, server side, ci/cd side. Но за счет выстраивания эффективной модели параллелизации можно достичь фантастических результатов и ускорить прогоны автотестов в разы.
Профилирование кода автотестов. Тоже является основным способом ускорения автотестов. Подразумевает пересмотр кода автотестов и удаление кода, который заведомо может замедлять прогон автотестов.
Стабильность
Так же является важным показателем качественных автотестов и показывает на сколько стабильны автотесты от прогона к прогона на одной и той же конфигурации продукта развернутого на стенде.
Стоимость
Данный показатель связан со стабильностью автотестов и показывает, сколько ресурсов необходимо для покрытия автотестами сценариев и адаптации автотестов под изменения в продукте.
На данные показатели качества автотестов влияет тест-дизайн инструментов автоматизации тестирования, который рассмотрим ниже.
В автоматизации тестирования выделяют 2 основных тест-дизайна:
двухуровневый
трехуровневый
Двухуровневый
На сегодняшний день данный тип тест дизайна является часто используемым и основным при проектировании инструментов тестирования и автотестов. Выглядит следующим образом:
![](https://habrastorage.org/getpro/habr/upload_files/ba3/971/a6a/ba3971a6af579ca6f1c6b84e8e74d526.png)
На этом изображении можно выделить 2 уровня:
Уровень взаимодействия. На данном уровне описываются ресурсы взаимодействия с SUT в зависимости от типа взаимодействия и типов автотестов.
Уровень тестов. На данном уровне находятся сценарии, в которых через DI создаются объекты ресурсов взаимодействия. На этом уровне располагаются только тесты, которые представляют из себя методы с набором вызовов методов ресурсов взаимодействия.
Данный дизайн является простым, дешевым и позволяет выстроить автотесты на любом проекте любой сложности, которые будут обладать описанными выше основными критериями качества.
Трехуровневый
Данный тип тест-дизайна также популярен в определенных командах автотестирования. Он выглядит следующим образом:
![](https://habrastorage.org/getpro/habr/upload_files/de9/3ea/c74/de93eac748bd6a0d713326d8411416d7.png)
В отличие от предыдущего тест-дизайна, здесь появляется третий слой, который является неким адаптером между слоем ресурсов взаимодействия и слоем тестов. Данный тест-дизайн часто используется в BDD. На первый взгляд кажется, что мы можем описать сценарии на уровне тестов, используя вызовы бизнесовых методов, которые описаны на слое steps — и автотесты станут более читаемыми не техническими специалистами. Но с другой стороны, слой steps вносит дороговизну в инструменты автоматизации и в автотесты. А дороговизна в том, что данный слой необходимо написать и постоянно поддерживать под изменения в продукте, что может существенно повысить стоимость автоматизации в целом.
Подводя итоги: в этой статье мы рассмотрели основные типы тест-дизайнов, а также плюсы и минусы того или иного решения. На самом деле, на выбор тест-дизайна сильно влияет проект, договорённости в команде и процессы, которые созданы и интегрированы или которые планируется создать и интегрировать. Но верный выбор тест-дизайна в будущем позволит писать качественные инструменты автоматизации и качественные автотесты.
Напоследок приглашаю тестировщиков на ближайшие открытые уроки по автоматизации:
13 августа: API автоматизация тестирования с Rest Assured. Разберем популярный инструмент для API автоматизации тестирования Rest Assured и методики написания API автотестов на нем. Записаться по ссылке
20 августа: Stream API и функциональные интерфейсы в Java. Разберем обработку элементов коллекций с помощью Stream API и функциональных интерфейсов при написании автотестов. Записаться по ссылке