Анализируются проблемы применения автоматизированного тестирования, предлагается подход управляемой поведением разработки как метод их решения. Рассматривается реализующий данный подход фреймворк SpecFlow, архитектура его проекта и подход параллельного выполнения автоматизированных тестов.

Автоматизация функционального тестирования вошла в практику разработки программного обеспечения (ПО) достаточно давно, однако в большинстве случаев до сих пор играет вспомогательную роль. Новая функциональность проверяется вручную, а автоматизированные тесты пишутся на уже устоявшуюся функциональность [1] и сразу играют роль регрессионных. Это обосновано — тратить ресурсы на автоматизацию, наиболее дорогой вид тестирования [2], сырой функциональности неразумно.

Однако, как показывает практика, подобный подход имеет свои недостатки:

1. Высокая динамичность современной разработки, когда заказчику нужно все уже вчера, приводит к тому, что до того, как функциональность будет покрыта автоматизированными тестами, разработчики ее успевают «сломать» не один раз. Этот недостаток частично ликвидирует написание юнит-тестов, или в классическом исполнении, или по методологии «test-driven development». Однако, согласно опыту автора, юнит-тесты или, иначе говоря, тесты кода, никогда не могут полностью заменить функциональные тесты, проводимые на пользовательском интерфейсе и имитирующие действия конечного пользователя.
2. Требования бизнес-аналитиков к текущей задаче используются по назначению только во время работы над ней и теряются в ворохе часто плохо структурированной документации сразу после ее тестирования.
3. К тому времени, как на данную функциональность начинают писаться автоматизированные тесты, детали функциональности забываются, особенно в условиях неполной документации, что является спецификой методологии Agile [3] и на их восстановление требуется дополнительное время нередко сразу многих членов команды.

Ответом на перечисленные выше проблемы явился подход разработки, управляемой поведением («behavior-driven development», BDD) [4]. Согласно ему, кардинально меняется очередность и приоритетность этапов разработки:

1. Бизнес-аналитик разрабатывает требования (включая подробные мокапы) на новую функциональность.
2. Программист реализует эти требования в виде автоматизированных тестов, написанных не на языке программирования, а на одном из обычных человеческих языков (включая русский). Разумеется, при этом, конечно, должны выполняться определенные правила, регламентированные вошедшей в BDD спецификацией языка Gherkin. Язык предусматривает три основных блока Given/When/Then, в которых, соответственно, задаются предусловия, вводятся действия и описывается ожидаемая реакция на эти действия. Ключевая особенность этого этапа — готовый тест должен быть понятен бизнес-аналитиком и всеми вовлеченными в процесс членами команды, независимо от их квалификации и специализации.
3. Каждый из шагов, написанных на человеческом языке, «под капотом» реализуется кодом (технология адаптирована для всех основных языков разработки) так, чтобы автотест-драйвер мог работать с планируемым функционалом. Функционала на этом этапе еще нет, соответственно нет и локаторов для работы автотест-драйвера, но написать автоматизированный тест (за некоторыми исключениями) уже возможно, используя планируемые локаторы, которыми являются части мокапа, разработанного бизнес-аналитиком в первом пункте.
4. Только на этом этапе разработчик начинает реализацию функционала. Критерием приемки является успешное прохождение автоматизированных тестов, написанных на 2 и 3 этапах. Также на этом этапе идет и незначительная корректировка самих тестов, например, в ситуациях, когда полностью закончить обращение к оконному элементу можно только после реализации функционала.
5. После успешной приемки новой функциональности автоматизированные тесты переходят из категории приемочных в категорию регрессионных и далее продолжают свою работу непрерывно.

Описанный подход, разработанный Деном Нортом [4], полностью устраняет описанные выше недостатки классической методики:

1. Любая поломка только что сделанного функционала тут же обнаруживается, причем более эффективно, чем юнит-тестами.
2. Требования бизнес-аналитика не перестают работать и не теряются — они переходят в текстовую часть автоматизированного теста и «работают» каждый раз, когда запускается тест. Это приводит к тому, что отпадает необходимость, полностью никогда не достижимая, держать требования в голове или продолжительное время восстанавливать их при необходимости. Функцию памяти требований берет на себя сам тест.

Рис. 1. Сравнение процесса идентификации бага при классическом подходе и при подходе BDD

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

Реализацией подхода BDD для.Net является SpecFlow. Проект SpecFlow предусматривает наличие следующей структуры:

1. файл с расширением.feature содержит описание сценария на языке, удобном для человека (по спецификации Gherkin).

Рис. 2. Пример сценария по спецификации Gherkin

2. с файлом сценария связывается файл, содержащий реализацию всех шагов сценария на языке программирования.

Рис. 3. Сравнение архитектур проекта автотестов при классическом подходе и при подходе BDD

При классическом подходе проект автоматизированных тестов имеет следующую структуру (рисунок 3): классы страниц с оконными элементами — т. н. pageObjects — содержат декларации всех используемых оконных элементов с локаторами на странице в виде свойств и методы, реализующие логику работы с имеющимися оконными элементами. При этом методы оперируют только с высокоуровневыми свойствами оконных элементов, такими, например, как Value у текстовых полей и Click у кнопок. Реализация же этих свойств через методы автотест-драйвера помещается уровнем ниже — в классах оконных элементов. Что касается классов реализации автоматизированного теста на языке программирования (уровень выше классов оконных элементов), то в них вызываются только методы страниц оконных элементов, например, SelectCertificate, LoadReport и т. д.

При подходе BDD описанная выше архитектура остается, но при этом над слоем верхнего уровня — классами реализации тестов на языке программирования добавляется еще один слой — классы реализаций автотестов на языке, понятном любому человеку. Таким образом добавление лишь одного слоя полностью меняет концепцию разработки ПО.

Одним из негативных моментов автоматизированных функциональных тестов является значительное время их исполнения. Каждый из автоматизируемых сценариев может занимать до нескольких десятков минут или даже часов, при подходе BDD тестов создается множество и это множество для в веб-разработке нужно умножить на количество поддерживаемых браузеров. Казалось бы, в режиме непрерывной интеграции прогон автоматизированных тестов может занимать неоправданно большое время. Однако, Specflow и другие платформы с недавнего времени внедряют поддержку параллельного выполнения автоматизированных тестов. Исследование показало (таблица 1), что выполнение Specflow тестов в нескольких потоков позволяет снизить среднее время их выполнения почти в три раза, однако дальнейшее увеличение количества потоков практически перестает влиять на среднее время прохождения.

Таблица 1

Среднее время прохождения демонстрационного автоматизированного теста взависимости от количества запущенных одновременно копий

Рис. 4. Среднее время прохождения демонстрационного автоматизированного теста в зависимости от количества запущенных одновременно копий

Заключение:

Рассмотрены проблемы применения автоматизации тестирования программного обеспечения. Обосновано использование подхода BDD и его преимущества, главным из которых является постоянная и автоматизированная вовлеченность в процесс требований к ПО. Проведен обзор фреймворка Specflow: проведен анализ архитектуры его проекта автоматизированных тестов и рассмотрен эффект параллельного их выполнения.

Литература:

1. Галимова Е. Ю., Коваленко А. Н. Метод выбора между ручным и автоматизированным тестированием, основанный на свойствах программного продукта. — Вестник Донского Государственного Технического университета, 2016, № 4, с. 134–139.
2. Cohn M. Succeeding with Agile: Software Development Using Scrum. — Addison-Wesley Signature, 2009, 475 с.
3. Apke L. Understanding The Agile Manifesto. — Lulu Publishing, 2015, 74 c.
4. North D. Behaviour Modification. — Better Software magazine, 2006, c. 27–31.