Автоматизация веб-приложений под ключ

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

Проверка такого веб-продукта становится сущим кошмаром. Ведь придется проклацать до 1500 страниц (условно), протестировать все функции.

А если релизов несколько, то сделать те же манипуляции минимум несколько раз.

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

А на горизонте уже маячат е2е тесты. Но к ним нужно еще дойти, и прежде чем их создавать, необходимо делать тест-кейсы. Причем, большое количество тест-кейсов.

Если два первых абзаца заставили вас нервничать и переживать насчет объемов предстоящих работ, вам действительно будет интересно прочесть данный материал.

В статье пойдет речь о методиках автоматизированного тестирования ПО, во время которого пользователю не придется создавать тонны тест-кейсов или е2е-тесты.

Создание «правильных» автоматизированных тест-кейсов

Иногда может так сложиться, что при тестировании веб-продукта, основа проверок будет завязана на внешнем интерфейсе ПО.

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

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

1. Кликнуть на кнопку;
2.  Ввести нужное значение Х;
3.  Выбрать значение ХХ в выпадающем меню.

Ну и проверки:

1. Появится ли текст ХХ;
2.  Есть ли уведомление об ошибке;
3.  Появится ли заголовок Z.

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

После этого приходит осознание того, что это очень легко автоматизировать.

Итак, начнем с самого простого.

Автоматизация перехвата события

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

Любой фреймворк содержит под эти цели особые методы. К примеру, fromEvent внутри Angular и document.addEventListener в JavaScript и отчасти в React.

Для объектов управления с параметрами ввода, наподобие календаря или входа, редактируется только вид события, на которое пользователь должен оформить подписку: вместо click у нас будет focusout.

fromEvent (this.elementRef.nativeElement, ‘click’)
.subscribe (tagName => {
if (tagName === ‘BUTTON’) {
this. testCaseService.addAction( `Haжать нa кнопку «${action.name}»`
} else if (tagName ===’INPUT-CALENDAR’) {
this. testCaseService
.addAction`Выбрать дату «${action.name}» «${action.value}»`);
}
});

Ну и наиболее важное — проверки. То, как веб-продукт должен вести себя после выполнения действий со стороны тестировщика.

Что всегда тестирует QA-специалист? К примеру, он решил ввести некорректное значение в поле input, веб-сайт должен отреагировать должным образом на это действие сообщением с текстом ошибки.

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

Все подобные изменения, так или иначе, связанные с редактированием объектов в DOM-дереве. Есть масса способов отследить их.

Например, применять MutationObserver в React и JavaScript или ngAfterViewInput в Angular (выполняя проставление директивы на нужные элементы формы на веб-сайте).

ngAfterViewInit() {
const tagName = this.nativeElement .nodeName;
const text = this.nativeElement .textContent;
if ([‘SPAN’, ‘P’] .includes(tagName)) {
this. testCaseService.addContent(`**Появился текст** «${text}»\n`);
} else if (tagName === ‘H1’) {
this. testCaseService.addContent(`**Появился заголовок** «${text}»\n`);
} …
}

Автоматизация написания e2e-тестов

Если проанализировать автоматически сгенерированный тест-кейс, то он, по своей сути, представляет классический пользовательский сценарий, который приведен к единообразной структуре.

На сегодняшний день, есть масса фреймворков с оригинальной gherkin-нотацией, которая базируется на разноплановых поведенческих сценариях: от SpecFlow, Cucumber.js до CodeceptJS и других.

Как пример, получаем такой тест:

Feature: Автоматически сгенерированный e2e-тест
Background:
When Авторизуемся «логин» «пароль»

Scenario:
When Нажать нa кнопку «Ответил кто-то другой»
Then Переход на экран «Кем приходится клиенту»
And Появился заголовок «Ответил кто-то другой»
When Выбрать в поле «Кем приходится клиенту» «Родственник»
When Выбрать в поле «Уточнение» «Супруг или супруга”
When Нажать на кнопку «Продолжить”

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

Хорошая новость заключается в том, что создавать обработчик под каждую фичу нет необходимости.

И это универсальный совет, так как даже если у нас 1000 оригинальных действий и, соответственно, проверок, мы столько же получим первоклассных e2e тестов.

Конечно же, программный код будет немного разнится из-за непосредственной зависимости от выбранного вами фреймворка и верстки на сайте. Создание подобного обработчика не занимает много времени.

Вот пример подобной уловки:

Итоги

При правильном использовании средств автоматизации тестирования даже самых больших и сложных проектов, процесс создания универсальных e2e тестов может занимать не более двух минут. Это где-то на 60% быстрее от того, если бы создавать подобные проверки самостоятельно, вручную.

Уже невозможно работать только с ручными e2e тестами, используя их как единственный источник проверок. Эпоха разноплановых фреймворков и других системных решений позволяет не просто облегчить процесс создания тестов, но и создавать универсальные техники и методики автоматизированных проверок, которые можно использовать на схожем веб-функционале, даже по прошествии некоторого времени.