Что такое автотесты в программировании

Автотесты – барское дело

Зачем разработчикам писать автотесты? С таким же успехом их можно заставить класть плитку или вести бухгалтерию. Не барское это дело! Или, все-таки, барское?

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

В разработке программного обеспечения существует много мифов и глупостей. Рассмотрим два из них.

Так уж сложилось, что тестировщики в индустрии в среднем зарабатывают меньше, чем разработчики. Происходит это, видимо, из-за того, что бытует мнение, что на роль тестировщиков можно нанять студентов за недорого, показать им куда надо «тыкать» — и все, команда тестировщиков готова. Это заблуждение, конечно. Хороший тестировщик является по сути исследователем программ, который понимает как они устроены внутри и должен стоить дорого, но это почему-то мало кто понимает.

Второе заблуждение – это отношение к автотестам. Считается, что разработка автотестов – это глупая нудная работа, которую можно поручить кому угодно.

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

Вторая причина вытекает из того, что команда тестирования не владеет продуктовым кодом. Кодом владеют разработчики и только они могут вносить в него исправления.

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

Точно такая же ситуация имеет место быть и при разработке функциональных автотестов. Когда продуктовый код пишут разработчики, а тесты для этого кода тестировщики, то трудоемкость и качество (поддерживаемость, скорость выполнения, хрупкость и пр.) таких тестов получается хуже, чем если бы и то и другое разрабатывала одна команда. Это происходит из-за того, что разработчик имеет возможность слегка подправить код так, чтобы ему самому было удобнее для этого кода написать автотест. Теоретически, инженер из команды тестирования тоже может попросить команду продуктовых разработчиков модифицировать код. Но на практике, это происходит не всегда, так как часто тестировщику проще оставить в тесте костыль (например, sleep), чем обращаться с просьбой к команде разработчиков, которые в данный момент заняты чем-то важным, ждать пока они реализуют то, что ему нужно, потом получить не то, что он просил и так по кругу. В результате, со временем тесты обрастают костылями, становятся неподдерживаемыми и превращаются в тот самый чемодан без ручки, который и выбросить жалко и тащить тяжело.

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

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

Разработка автотестов является у нас неотъемлемой частью общего процесса разработки продукта. При планировании итерации для каждой пользовательской истории мы обязательно закладываем время на подготовку автотестов для неё. Трудоемкость автотестов обычно составляет 10-20% от трудоемкости истории, но потраченное время потом многократно окупается.

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

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

Как с помощью автотестов не сойти с ума, поддерживая молодой быстрорастущий веб-сервис: подробная инструкция

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

Автотесты в веб-сервисы Наигру: сценарии
Что такое автотесты простым языком?

Если совсем просто, то это когда вместо человека тестирование производит программа. Первые автотесты появились в эпоху бородатых систем DOS. В общем технология не новая и человечество в этом вопросе набило немало шишек.

В интернете встретили хорошую аналогию: представьте что мост — это программа (или в нашем случае веб-сервис). По мосту запускаем полностью нагруженный товарный состав (виртуальный трафик). Когда поезд едет по мосту, на котором установлены датчики, мы получаем информацию о трещинах, деформации балок, разрушении железнодорожного полотна. Это есть end-to-end тестирование (подробнее описано ниже). А вот если добавить, что после каждого изменения моста (добавление балки, изменение геометрии опор и т.д.) поезд запускается автоматически, а датчики, улавливая ошибку, не пропускают его дальше – то это уже автоматическое end-to-end тестирование.

Простое тестирование – это когда после изменения конструкции моста мы запускаем поезд вручную и смотрим, оцениваем, выдержит ли мост поезд или нет (и ставим под мост тестировщиков и разработчиков, ха-ха).

С определениями разобрались. Поехали дальше.

Что и как можно автоматически тестировать?

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

Если говорить совсем точно, статья будет про автоматическое end-to-end (E2E, сквозное) тестирование, имитирующее пользовательскую среду и поэтапно моделирующие действия пользователей.

Автоматическое end-to-end (E2E) тестирование — это процесс автоматического тестирования с подробной эмуляцией действий пользователя: кликаньем мышки, переходами по страницам, заполнения форм и так далее. Цель E2E тестирования — удостовериться, что программа работает именно так, как задумано для конечного пользователя.

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

Пример. Мы «выкатываем» приложение с потенциалом 10 000 регистраций в месяц. Предположим, мы не заметили, что после изменения одной из функций пользователи не видят модальное окно об успешной регистрации и это снижает общую конверсию на 5%. Стоимость одной регистрации составляет 15 долларов. За первый месяц мы потеряем 7 500 долларов.

Типы E2E тестирования: черный и белый ящик

Метод черного ящика — метод тестирования, при котором проверяется только интерфейс. Ошибки в логике не отслеживаются.

Метод белого ящика — метод тестирования, при котором проверяется сопоставление работы программы с эталоном.

Мы в проекте использовали метод белого ящика и проверяем правильность работы не только блоков интерфейса, но и логики.

Как мы пришли к автотестам в проекте Наигру

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

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

Например, перестала работать кнопка «Записаться на игру» после доработки механизма перехода игроков из резерва в основной состав. Или при создании регулярных игр возникали баги в обычных разовых играх – например, при записи на игру не показывалось модальное окно об успешном действии и пользователь не мог понять, записан ли он.

Наигру: Ошибка «Не показывается модальное окно»

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

Ручное тестирование

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

Регрессионное тестирование делится на 3 уровня: проверка нового блока, проверка ранее добавленных блоков, а также проверка связанных и не связанных сторонних блоков после добавления или изменения блока. В среднем одно такое тестирование занимало два рабочих дня.

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

Подготовка к автоматическому тестированию

Пришли к выводу, что рациональнее будет автоматизировать проверку всех основных сценариев. В описываемом проекте примерами таких сценариев являются:

Регистрация/авторизация пользователей
Создание и редактирование игры
Запись на игру
Отписка игрока от тренировки
Запись в резерв, переход в основной состав

Сформировали алгоритмы поведения пользователей

Например, проверка регистрации: сайт открывается → выбор чекбокса города Москва → нажатие «Сохранить» → нажатие на «Войти или создать аккаунт» → проверка ошибки неправильно заполненного телефона → ввод сгенерированного номера → нажатие «Войти» → проверка наличия авторизации после регистрации и выход из профиля.

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

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

Как писать автотесты с Selenium

Автоматизируем проверку имени пользователя на Java.

Selenium — это инструмент с открытым кодом для автоматизации тестирования WEB. С его помощью можно заменить рутинные операции, которые вынуждены делать мануальные тестировщики. Например, текстовый ввод или однотипные взаимодействия со множеством элементов страниц. Также Selenium облегчает тестирование разных локализаций, потому что взаимодействие с элементами страницы происходит на уровне кода.

Плюс Selenium в том, что он поддерживает самые популярные языки программирования (Java, Python, JavaScript, PHP).

статьи по теме:

Что нужно знать.

Чтобы лучше понять, как работает Selenium, напишем тест на Java.

Сравнение имени пользователя и логина: пишем код

Напишем тест, который будет открывать «Википедию», логиниться и проверять, соответствует ли имя пользователя его логину.

1. Устанавливаем WebDriver— драйвер, который управляет работой браузера (открывает страницы и отправляет им команды). Тест будет написан для Chrome, поэтому понадобится драйвер для последней версии Chrome.
2. Подтягиваем зависимость для Selenium-java в pom.xml Maven-проекта.

  org.seleniumhq.selenium selenium-java 4.0.0

3. Создаем три класса в папке Test:
- WikiLoginPage (отвечает за работу со страницей авторизации).
- WikiMainPage (отвечает за страницу, которая загружается после авторизации).
- WikiLoginTest (основной тестовый класс).
Также необходимо выставить небольшую задержку в 5 секунд, чтобы все статические элементы страницы успели загрузиться — timeouts().implicitlyWait(Duration.ofSeconds(5)). Аннотация @BeforeClass говорит о том, что этот метод будет вызван только один раз до запуска всех тестов. Метод quitDriver завершает работу драйвера и закрывает браузер.

Аннотация @AfterClass обеспечивает его вызов только после того, как отработают все остальные методы. В переменные name и password прописываем данные пользователя, которые будем проверять.
```
import org.junit.AfterClass; import org.junit.BeforeClass; import org.openqa.selenium.WebDriver; import org.openqa.selenium.chrome.ChromeDriver; import java.time.Duration; public class WikiLoginTest < public static WebDriver driver; public static WikiLoginPage wikiLoginPage; public static WikiMainPage wikiMainPage; public static String url = "https://ru.wikipedia.org/w/index.php?title=Служебная:Вход&returnto=Заглавная+страница"; public static String name = "your_name"; public static String password = "your_password"; @BeforeClass public static void openWikiLoginPage() < System.setProperty("webdriver.chrome.driver", "c:/chromedriver.exe"); driver = new ChromeDriver(); driver.manage().timeouts().implicitlyWait(Duration.ofSeconds(5)); driver.get(url); wikiLoginPage = new WikiLoginPage(driver); wikiMainPage = new WikiMainPage(driver); >@AfterClass public static void quitDriver() < driver.quit(); >>
```
- 5. Теперь нужен класс для работы со страницей ввода имени пользователя и пароля — WikiLoginPage. В нем с помощью PageFactory создаем хранилища объектов. К статическим объектам страницы (WebElement) обращаемся с помощью локаторов и аннотации @FindBy. В @FindBy передаем id элемента. Чтобы выбрать идентификатор для элемента, в Google DevTools нажимаем правой кнопкой мыши на элемент, а затем выбираем «посмотреть код» и копируем id.
- В тесте мы будем использовать три локатора:
  - nameField — для имени пользователя;
  - passwordField — для пароля;
  - loginButton — для кнопки авторизации.
```
import org.openqa.selenium.WebDriver; import org.openqa.selenium.WebElement; import org.openqa.selenium.support.FindBy; import org.openqa.selenium.support.PageFactory; public class WikiLoginPage < public WebDriver driver; public WikiLoginPage(WebDriver driver) < PageFactory.initElements(driver, this); this.driver = driver; >@FindBy(id = "wpName1") WebElement nameField; @FindBy(id = "wpPassword1") WebElement passwordField; @FindBy(id = "wpLoginAttempt") WebElement loginButton; public void inputName(String name) < nameField.sendKeys(name); >public void inputPassword(String password) < passwordField.sendKeys(password); >public void clickLoginButton() < loginButton.click(); >>
```
  - 6. В классе WikiMainPage пишем локатор для определения имени пользователя (userName) и метод (getText) для получения текста из имени. У userName нет своего id, а потому в FindBy передаем xpath. xpath — это язык запросов, с помощью которого можно обращаться к элементам страницы.
```
import org.openqa.selenium.WebDriver; import org.openqa.selenium.WebElement; import org.openqa.selenium.support.FindBy; import org.openqa.selenium.support.PageFactory; public class WikiMainPage < public WebDriver driver; public WikiMainPage(WebDriver driver) < PageFactory.initElements(driver, this); this.driver = driver; >@FindBy(xpath = "//*[@id=\"pt-userpage\"]/a/span") private WebElement userName; public String getUserName()
```
  - 7. Когда оба класса готовы, дорабатываем WikiLoginTest — добавляем импорты для работы теста и пишем тестовый метод.
```
import org.junit.Test; import org.junit.Assert;
```
  - Метод wikiLoginTest проверяет совпадение имени пользователя с отображаемым на странице. Для этого поочередно вызываются все методы, работающие с элементами страницы. После этого сравниваем значение текста элемента (wikiMainPage.getUserName()) с переменной, в которой хранится имя пользователя (name). Аннотация @Test помечает метод как тестовый.
```
@Test public void wikiLoginTest()
```
  - 8. Запускаем тест — в левом нижнем углу отобразится тестовый класс (WikiLoginTest) с удачно запущенным тестовым методом (wikiLoginTest) и временем его работы. Если тесты падают, они становятся красными.
  - Этот автотест можно доработать. Например, вынести все переменные в отдельный конфигурационный файл. Также можно отойти от явного управления драйверами (особенно если будет использован не один браузер). Для этого понадобится библиотека WebDriverManager, которая автоматизирует загрузку драйверов, поиск браузеров в системе, запуск в Docker-контейнерах. С WebDriverManager не придется каждый раз открывать браузер при вызове тестовых методов.
  Готовый код можно найти тут.
  
  Автоматизированное тестирование: что это?
  
  Прошли времена, когда найти работу ручным тестировщиком было легко. Сейчас все больше работодателей предпочитают QA-инженеров, которые умеют писать автотесты. Так работа идет быстрее и эффективнее, а сам тестировщик может сосредоточиться на более сложных задачах. Рассказываем, что такое автотестирование, для чего оно подходит и какие инструменты нужны, чтобы освоить автоматизацию тестирования с нуля.
  
  Освойте профессию
  «Тестировщик-автоматизатор»
  
  Что такое автоматическое тестирование
  
  Автотестирование (autotesting) — это способ тестирования продукта с использованием специальных программ. QA-инженер на основе тестового сценария пишет автотест, который проверяет код на ошибки, прогоняет на продукте разные пользовательские сценарии, тестирует базовый функционал, собирает ошибки в итоговый отчет. Данные автоматизированного и ручного тестирования собирают вместе, чтобы передать их разработчикам и улучшить продукт.
  
  Какие виды тестирования можно автоматизировать
  
  Автотестирование — это хороший способ избавить QA-инженеров от рутины постоянно повторяющихся тестов и снизить риски, что тестировщик пропустит серьезную ошибку. Написать автотесты можно для:
  
  Профессия / 16 месяцев
  Тестировщик-автоматизатор
  Лучший выбор для быстрого старта в IT
  3 474 ₽/мес ~~6 317 ₽/мес~~
  - Дымового тестирования (smoke testing). Это проверка базовых функций ПО: работает ли форма входа в приложение, можно ли открыть его на разных устройствах, доступен ли API.
  - Модульного тестирования (unit testing). Это проверка кода отдельного модуля, функции приложения.
  - Нагрузочного тестирования. Это тип тестирования, который можно выполнить только автоматизированно. В процессе автотест генерирует большое количество пользователей в приложении, чтобы проверить, сколько оно может обработать и не сломаться.
  - Интеграционных тестов. Проверяют, насколько хорошо отдельные модули работают вместе, и правильно ли они передают друг другу данные. Например, ведет ли форма покупки билетов туда, куда должна вас вести — к странице оплаты.
  - Регрессионных тестов. Они помогают защитить уже существующий качественный код от багов, которые возникают при обновлении.
  Сергей Рудик, QA-ментор в Skillfactory:
  
  Автотесты могут проверить техническую сторону интерфейса приложения или сайта: соответствие цветов задаче, наличие кнопок, их работоспособность. Автотестам можно передать также пользовательские сценарии, например, доставки еды или заказа такси. Программа проверит все, что происходит: как меняется состояние страницы, какие элементы на ней появляются или, наоборот, не появляются, насколько хорошо работает связь интерфейса с API, как компоненты приложения взаимодействуют друг с другом.
  
  Возможно ли автоматизированное тестирование без ручного?
  
  Нет. Как минимум потому, что автоматизированное тестирование нужно организовать, а значит, сначала сделать что-то руками.
  
  Сергей Рудик, QA-ментор в Skillfactory:
  
  Без опыта ручного тестирования в QA никуда. Автотестирование не заменяет на 100% всю работу тестировщиков. Сначала нужно в любом случае проверить продукт руками: посмотреть, что в нем есть, какие нужны сценарии тестирования, чтобы его проверить, составить тест-кейсы, сценарии и чек-листы. Всем этим занимаются люди, а на основе этих документов потом пишут автотесты.
  
  Также в тестировании очень важно помнить, что пользователь может вести себя непредсказуемо, поэтому каждому продукту нужен взгляд человека. Ручное тестирование важно при проверке UI и UX: автотест может подтвердить, что кнопки правильного цвета и работают, но не может сказать, насколько удобно и интересно взаимодействовать с приложением.
  
  Станьте тестировщиком – это лучший выбор для быстрого старта в IT
  
  Как начать автоматизацию тестирования?
  
  В первую очередь нужно составить тест-кейсы: это документы, в которых прописано, что нужно проверить, какие шаги для этого предпринять и какие результаты должно показать приложение. Например, если вам нужно протестировать поисковую строку на сайте, сценарий будет состоять из проверки строки ввода, кнопки «поиск», реакции сайта на неудачный поиск, работу кнопки-крестика для отмены поиска. У каждого из этих элементов есть ожидаемый результат, если его не происходит — автотест в отчете должен вам об этом сообщить.
  
  Затем нужно выбрать фреймворк тестирования — это платформа или набор инструментов, которые будут использоваться для написания и реализации автотестов.
  
  Сергей Рудик, QA-ментор в Skillfactory:
  
  Писать автоматизированные тесты можно на Java, Python, Go. Найти заготовки для различных тестов, на основе которых вы подготовите собственный тест, можно в библиотеках: например, PyTest, Selenium. Python и PyTest помогают писать тесты для проверки бэкенда, API. На Selenium можно проверить интерфейс и создать эмуляцию браузера. Этих инструментов достаточно для старта в автоматизированном тестировании.
  
  По данным исследования Skillfactory, от продвинутых кандидатов на позицию тестировщиков-автоматизаторов также ждут:
  - Владение SQL, GraphQL, JSON — чтобы запрашивать нужные данные из базы, HTTP — чтобы искать ошибки в коде сайтов и веб-приложений.
  - Умение работать с ПО для разработки: Git — для хранения версий кода, Postman — для тестирования бэкенда сайта, DevTools — чтобы проверять фронтенд сайта.
  - Знание ПО для управления данными: ORACLE, PostgreSQL, Grafana, REST API.
  После того как инструменты выбраны и тесты написаны, можно запускать проверку и ждать ответа от автоматизированной системы. Итогом работы автотеста должен стать баг-репорт — отчет об ошибках, которые передают команде разработки на исправление.
  
  Тестировщик-автоматизатор
  
  Как ворваться в IT, даже если вы не умеете программировать? Стать тестировщиком. Для старта достаточно базовых знаний ПК. А начать работать можно уже через 4 месяца обучения.
  Похожие публикации: