XIII Международная студенческая научная конференция Студенческий научный форум - 2021

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

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

Подход получил название BDD (Behavior Driven Development) — разработка через поведение. Фиксируется поведение системы и на основании этого поведения производится разработка и тестирование. Подход заключается в том, что архитектуру системы нужно описать в терминах эксперта предметной области, а не IT-специалиста, чтобы архитектура или тесты были написаны человеческим языком, а не языком программирования. Были разработаны специальные инструменты и фреймворки, которые позволяют писать тесты человеческим языком. Самым популярным на сегодняшний момент фреймворком является Сucumber. Есть и другие, например: на Java есть JBehave, на С# существует фреймворк SpecFlow. Они очень похожи между собой. В основании лежит простой синтаксис, которой выполняется при разработке тестовых сценариев. Один из синтаксисов — это синтаксис названия тестового сценария и несколько ключевых слов. Типичный тестовый сценарий может быть даже на русском языке. Например, сценарий аутентификация пользователя.

Дано: Когда пользователь авторизуется под пользователем «Алексей»

И он заходит на страницу приветствия

Тогда проверяет, что заголовок страницы содержит «Здравствуйте, Алексей!»

Все написано человеческим языком и вопрос только в том, чтобы компьютер нас понял. На самом деле под этим фреймворком лежит так называемый «словарь», который мы должны перевести. Например, говорится, что функция «аутентификация пользователя» соответствует выражению «пользователь авторизуется под пользователем с параметром “_”», или «он заходит с параметром “_”», или «проходит регистрацию с параметром “_”» и так далее. Создается словарь выражений, которые будут разобраны фреймворком и будет выбрано какие именно функции использовать. Например, что делает Cucumber. У него есть словарь. На основании словаря преобразуется человеческий текст в последовательность команд на фреймворке низкого уровня. Это может быть фреймворк Selenium, SoapUI или UFT. Дальше эта последовать команд будет выполняться другим фреймворком. То есть, Cucumber является адаптером.

Данный метод хорошо работает тогда, когда есть разработчики, которые корректно пишут все методы, классы, когда дают API для тестирования, описания действий, либо сами создают Page Object Module, или есть выделенный человек, который описывает Page Object Module. И есть пользователи, аналитики и владельцы продукта, для которых описано, что все их пользовательские истории нужно писать именно в таком формате, а также используя ключевые слова.

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

Сложно сказать будет ли иметь широкое распространение фреймворк BDD, но в настоящее время активно используется фреймворк Cucumber. Он интегрирован также в средства управления тестированием, поэтому можно писать и разрабатывать тесты в средствах управления тестированием, соотносить их со словарями, вызывать определенным образом тесты без погружения во внутренности автоматизированного тестового фреймворка.