Что такое атомарный автоматизированный тест?

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

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

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

Проблемы, решаемые атомными тестами

  • Ненадежные результаты автоматизированных тестов
  • Медленные тесты
  • Тесты, которые сложно отлаживать
  • Тесты, не указывающие точную точку отказа

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

Автоматический приемочный тест не должен длиться дольше 1 минуты на ваших локальных ресурсах

Если ваш тест длится дольше 1 минуты, продолжайте читать, почему это может быть опасно. У написания атомарных тестов много преимуществ ...

Вот несколько примеров атомарных тестов графического интерфейса:

500% сокращение времени выполнения набора тестов (пример из практики)

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

Преимущества атомных испытаний

1. Атомные тесты быстро терпят неудачу

Во-первых, написание атомарных тестов позволяет быстро и быстро терпеть неудачу. Это означает, что вы получите очень быструю и целенаправленную обратную связь. Если вы хотите проверить состояние функции, это займет у вас не более 1 минуты.

2. Атомные тесты уменьшают нестабильность

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

https://info.saucelabs.com/sauce-labs-continuous-testing-benchmark-report-M.html

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

Вот пример:

  1. Откройте домашнюю страницу UltimateQA.com
  2. Утверждают, что страница открылась
  3. Подтвердите, что каждый раздел на странице существует
  4. Открыть страницу блога
  5. Искать статью
  6. Утверждают, что статья существует

Для автоматизации пользовательского интерфейса каждый шаг - это шанс того, что что-то пойдет не так ...

Возможно, изменился локатор, механизм взаимодействия, возможно, нарушена ваша стратегия синхронизации и т. Д.

Следовательно, чем больше шагов вы добавите, тем больше вероятность того, что ваш тест сломается и даст ложные срабатывания.

3. Атомарные проверки позволяют улучшить тестирование

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

4. Атомные тесты короткие и быстрые

Наконец, еще одним большим преимуществом написания атомарных тестов является то, что они будут выполняться быстрее при распараллеливании ...

Как я увеличил скорость выполнения тестов на 98% с помощью одного изменения?

В приведенном выше сценарии у меня был набор из 18 сквозных тестов, которые НЕ были атомарными и не выполнялись параллельно.

Сохраняя тот же охват кода, я разбил свои тесты на 180 крошечных атомарных тестов ...

Выполнял их параллельно и уменьшил среднее время тестового примера до 1,76 с с 86 с.

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

Николай Адволодкин

Если вы хотите узнать больше о передовых методах автоматизации, а также о CI / CD и разработке фреймворков, ознакомьтесь с Полным Selenium WebDriver с Java Bootcamp.

Кстати, я видел автоматические тесты, выполнение которых занимает 30–90 минут. Эти тесты очень утомительны, потому что они занимают очень много времени. Хуже того, я никогда не видел, чтобы такой тест давал ценные отзывы за всю мою карьеру. Только ложные срабатывания.

Пример использования Amazing Automation:

Разбивка:

30 000 тестов в неделю

96% проходной балл

Среднее время выполнения теста: 30 сек (в облаке!)

Среднее количество команд Selenium за тест: ‹30

Ммм, да. Вот что сделают атомные испытания 🔥🔥 👏👏

Как разбить гигантские сквозные UI-тесты?

Ладно, вы, поверьте, атомные испытания - это хорошо.

Но как же разбить большие сквозные тесты, не так ли?

Поверьте мне, вы не единственный, кто борется с этой ситуацией ...

Становится хуже:

Ежедневно я встречаю клиентов с той же проблемой.

Более того, я хотел бы дать простой ответ на этот вопрос. Но я не могу…

Для большинства людей эта проблема связана с технологиями и культурой.

Однако я предоставлю пошаговое руководство, которое поможет вам провести атомные тесты.

Это будет нелегко ... Но когда вы добьетесь этого, это будет ТАК сладко!

Вот простой сценарий:

  1. Откройте Amazon.com
  2. Утверждают, что страница открывается
  3. Искать предмет
  4. Утверждают, что предмет найден
  5. Добавить товар в корзину
  6. Подтвердите, что элемент добавлен
  7. Проверить
  8. Подтвердите, что оформление заказа завершено

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

Вы должны выполнить шаг 1 перед шагом 2 и так далее ... Потому что как вы можете перейти к процессу оформления заказа, не имея товара в корзине?

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

Боковое примечание:

Если вы хотите увидеть демонстрацию кода в реальном времени, я расскажу об этом в этом видео примерно через 13 минут:

Как управлять тестовыми данными для автоматизации пользовательского интерфейса?

Вы можете ввести данные с помощью нескольких опций:

  1. Использование чего-то вроде RESTful API для установки приложения в определенное состояние
  2. Использование JavaScript
  3. Внедрение данных в БД для установки приложения в определенное состояние
  4. Использование куки

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

Некоторые варианты:

  1. Используйте API для отправки веб-запроса, который создаст пользователя
  2. Используйте API, который создаст товар в вашей корзине Amazon.
  3. Теперь вы можете вывести пользовательский интерфейс на страницу корзины и оформить заказ с помощью веб-автоматизации.
  4. Очистите все тестовые данные после

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

Использование API очень быстро… Веб-запрос может выполняться примерно за 100 мс.

Это означает, что выполнение шагов 1, 2, 4 может занять менее одной секунды. Единственный другой шаг, который вам нужно будет сделать, - это завершить процесс оформления заказа.

Становится лучше:

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

Если вы хотите узнать больше о передовых методах автоматизации, а также о CI / CD и разработке фреймворков, ознакомьтесь с Полным Selenium WebDriver с Java Bootcamp.

Как контролировать состояние приложения с помощью JavaScript?

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

Итак, как нам удалить это из нашего теста, чтобы наш тест мог быть атомарным?

Вот один пример:

1. Мы выполняем некоторый JavaScript в нашей среде автоматизации, например:

Поздравляем, мы вошли в систему 🙂

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

Вот как будет выглядеть полный атомный тест:

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

Это признак атомарного теста в автоматизации пользовательского интерфейса.

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

Как координировать взаимодействие API и пользовательского интерфейса в одном тесте?

Что, если вы хотите скоординировать действия API и пользовательского интерфейса в одном тесте? Что ж, это будет выглядеть примерно так.

Наиболее распространенная ситуация - не чередовать вызовы Selenium и API. Обычно мы делаем API-интерфейс для настройки на севере штата. Материал пользовательского интерфейса для подтверждения функциональности. Материал API, который нужно очистить. Использование Selenium, API, Selenium, API, Selenium и т. Д. Не принято.

Однако в случае пользователя это точно возможно.

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

Что делать, если вы не можете ввести данные для тестирования?

Я знаю, что мир несовершенен, и многим из нас не повезло иметь приложения, разработанные с учетом тестируемости.

Так что ты можешь сделать?

У вас есть два варианта:

1. Работайте с разработчиками, чтобы сделать приложение более тестируемым.

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

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

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

Если продукт не работает, терпит неудачу вся команда, а не только конкретная группа

Опять же, это непросто ...

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

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

И в итоге наша команда оказалась сильнее и проворнее, чем когда-либо.

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

Вот второй вариант, и вы не хотите его слышать:

2. Если ваше приложение не поддерживает автоматизацию, не автоматизируйте

Если вы не можете работать с разработчиками, потому что не хотите…

Или если корпоративная культура не позволяет вам…

Тогда просто не автоматизируйте то, что не представляет ценности. Я знаю, что ваш менеджер просил вас автоматизировать ...

Однако мы инженеры по автоматизации. Мы профессионалы.

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

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

Хотя может показаться легким сказать «да, я автоматизирую ваш 30-минутный сценарий», это неправильно.

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

Ответ - это не нормально.

Вы должны быть экспертом и выбрать правильный подход к своей работе.

Если вы не согласны со мной ...

Посмотрите это видео от Роберта Мартина - возможно, одного из лучших разработчиков программного обеспечения этого века.

Он объясняет профессионализм лучше, чем я когда-либо

Если вы хотите узнать больше о передовых методах автоматизации, а также о CI / CD и разработке фреймворков, ознакомьтесь с Полным Selenium WebDriver с Java Bootcamp.

Что вы думаете? Можете ли вы написать атомарные тесты в своем приложении?