Home

Автор: Энди Найт (Andy Knight)
Оригинал статьи
Перевод: Ольга Алифанова

Сталкивались ли вы с багами в веб-приложениях? Еще бы, все с ними встречались. Баги плохо выглядят, портят пользователю впечатление, и снижают ценность веб-приложения. Серьезные баги могут повлечь за собой большие издержки для бизнеса и повредить репутации компании.

Как предотвратить проникновение багов к пользователям? Лучший способ поймать баги – протестировать веб-приложение. Однако Web UI-тестирование может быть непростой задачей. Оно требует больше усилий, нежели юнит-тестирование, и славится своей нестабильностью.

Не бойтесь! Это пособие сделает тестирование Web UI простым занятием. Мы создадим простое, но устойчивое тест-решение для Web UI, используя Python, pytest, и Selenium WebDriver. Мы изучим стратегии хорошего тест-дизайна, а также паттерны хорошего кода автоматизации. К концу этого руководства вы будете владеть тест-автоматизацией веб-приложений! Ваш тест-проект на Python может также стать основой для ваших собственных кейсов.

Пример проекта

В ходе обучения мы создадим пример тест-проекта с рядом основных тестов для поисковой системы DuckDuckGo. Все инструкции и код будут предоставлены. Я очень рекомендую создать и пополнять этот проект на вашем собственном компьютере в ходе продвижения по руководству.

Пример проекта требует базовых навыков программирования на Python. Убедитесь, что на вашей машине установлена последняя версия Python 3 (а не Python 2). Вы можете скачать ее с Python.org. Код будет написан на Python 3.7.3. Примеры для командной строки будут использовать UNIX (однако в других операционных системах все примерно так же). Я также рекомендую хорошую Python IDE вроде PyCharm или Visual Studio Code.

Полный код проекта размещен на GitHub: https://github.com/testproject-io/python-webui-testing. У каждой главы есть ветка, соответствующая новому описанному в разделе коду. Мастер-ветка содержит финальную версию. Если вы застряли, сравните свой код с кодом в GitHub.

Тестирование, движимое целями

Многие подходы к разработке "движимы" какой-либо целью. Разработка "через тестирование" побуждает разработчиков писать тесты до создания кода продукта. Разработка "через поведение" побуждает команды определять фичи как спеки с примерами. Я хотел бы ввести новый термин – "тестирование через цели".

Прежде чем прикоснуться к клавиатуре и начать создавать тесты, задайте себе вопрос – какую цель я преследую, тестируя? Тестирование – отличная штука, но мы не тестируем просто чтобы потестировать. Тестироавние – способ достижения качества. Команды должны решить, какие аспекты качества для них наиболее важны, а затем разработать подходящую тест-стратегию. К примеру, посмотрим на некоторые цели и стратегии для тестирования веб-приложения:

Зачем нам Web UI-тестирование?

Веб-приложения предназначены для людей, которые визуально взаимодействуют со страницей, не видя ее управляющего кода. Следовательно, Web UI-тестирование нацелено на проверку пользовательского взаимодействия в реальном браузере. Тесты Web UI – истинный end-to-end, потому что все, спрятанное за фронт-эндом – сервисы, базы данных, и все прочие системы – должны быть в строю, чтобы всецело поддерживать приложение. Эти тесты отвечают на один главный вопрос – работают ли функции приложения на самом деле? Они – неотъемлемая часть устойчивой стратегии тестирования веб-сайта.

К счастью, тесты Web UI можно автоматизировать ради стабильности, повторяемости и скорости. Пакеты вроде Selenium WebDriver позволяют разработчикам автоматизировать браузерные взаимодействия на языках типа Java, C# и Python. Более продвинутые инструменты (например, TestProject) предоставляют полную платформу для записи, рефакторинга и отчетности о Web UI-тестах прямо из коробки.

Однако у Web UI-тестирования есть и недочеты:

1. Это медленные тесты, даже если они автоматизированы. Им нужно время на открытие браузера, загрузку страниц, и отправку взаимодействий. Типичный автоматизированный Web UI-тест занимает около минуты, в то время как типичный юнит-тест – миллисекунду.
2. Эти тесты не могут указать на ошибку в коде, в отличие от юнит-тестов. К примеру, Web UI-тест может выявить неверное отображение форматов строки, но он не может сообщить, какой метод, файл и номер строчки виноваты в этом.
3. Эти тесты могут быть нестабильными. Любой тест черного ящика полагается на тестируемую систему. Состояние гонки и проблема остановки – это их данность. Код тест-автоматизации нуждается в тщательном дизайне и испытаниях на безопасность, чтобы стать устойчивым.

Если кратко,Web UI-тесты дороги: они требуют времени, опыта и поддержки.

Как оправдать затраты

Лучший способ минимизировать вышеописанные риски – балансировка тест-стратегии с бюджетной эффективностью. Не каждая фича нуждается в Web UI-тесте. Вместо этого концентрируйтесь на самых критических функциях, и придерживайтесь "счастливого пути", а не граничных случаев. Убедитесь, что вы достигли хорошего покрытия на уровне юнит-тестов и интеграции, чтобы поймать баги как можно раньше. Более широкое покрытие на более низких уровнях ведет к пониженному риску на более высоких уровнях, а это в свою очередь значит, что вам потребуется меньше Web UI-тестов.

Эта зависимость наилучшим образом иллюстрируется знаменитой тест-пирамидой:

Тест-пирамида побуждает команды балансировать высокоуровневые дорогие тесты (вроде Web UI) с более низкоуровневыми, быстрыми, простыми тестами (вроде юнит-тестов или API-тестов).

Наши цели

Наши цели в этом руководстве очень прямолинейны:

1. Изучить базовые навыки автоматизации Web UI с Python.
2. Настроить хороший проект тест-автоматизации на Python, который можно расширять новыми тестами.
3. Написать и локально прогнать несколько примеров тестов.

Мы сконцентрируемся целиком на Web UI-тестировании.

Продолжение следует.

Обсудить в форуме