«Начинайте тестировать как можно раньше» — эта фраза часто встречается в разных докладах и обучающих материалах. Это правда, чем раньше наши тесты найдут проблему, тем быстрее и дешевле мы ее решим. Это одна из главных причин эффективности CI. Часто встречаются команды, у которых очень много написанных автотестов, но они не используют тесты как подход к CI. Существуют различные причины, по которым команда считает, что эти тесты нельзя использовать в CI. Возможно, выполнение тестов занимает слишком много времени или они недостаточно надежны, чтобы давать правильные результаты, и требуют интерпретации человеком.

При оценке тестовых наборов (suites) я рисую на доске таблицу, в которой вертикальная ось представляет важность тестов, а горизонтальная ось — время, необходимое набору для выполнения тестов. Затем мы с командой пишем название каждого набора тестов на стикере и приклеиваем его на нужное место.

Пример такой таблицы:

Важность тестов делится на простые варианты: Low (низкий), Medium (средний), High (высокий).

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

С другой стороны, может быть набор тестов, который является частью чек‑листа, но никто не понимает, что проверяет этот тест. Возможно, первоначальный создатель покинул команду и никому этот набор тестов не перешел на поддержку. Такой набор относится к категории Low. Горизонтальную ось легко определить: это просто количество времени, которое требуется для запуска набора. Теперь, когда вы оценили каждый набор, подумайте, как вы можете улучшить их, сделав их более полезными или ускорив их выполнение. Я предпочитаю делить тесты в CI на следующие категории:

• Высокоэффективные тесты (High), которые выполняются в течение 15 минут или быстрее.Эти тесты выполняются на любой сборке. Они используются для принятия сборки для дальнейшего тестирования; пока эти тесты не пройдены, команда должна считать сборку сломанной. Ваши разработчики будут недовольны, если им придется ждать результатов сборки более 10 минут.

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

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

• Тесты со средним (Medium)значением— эти тесты могут выполняться один раз в неделю или один раз за релиз.

Я исключил тесты, которые имеют маленький приоритет и должны быть улучшены. Бесполезно хранить тесты, которые не приносят пользы. Поговорив с разработчиками, мы установили ограничения по времени выполнения тестов 15–45 минут. Такие тесты дают быстрый фидбэк. Это время может варьироваться в зависимости от ваших потребностей. Этот процесс демонстрирует, как надо мыслить при выборе тестов, которые должны выполняться вместе со сборкой нашего приложения.

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

Автоматизируйте старт тестов

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

Удалите неопределенность

Вся цель автоматизации состоит в том, чтобы получить надежные и точные результаты тестов. Когда тест падает, тестировщик должен выяснить, что пошло не так. Однако по мере увеличения количества ложных срабатываний увеличивается время, необходимое для анализа ошибок. Чтобы этого избежать, удалите флаки‑тесты из регресса. Кроме того, старые автотесты могут игнорировать важные проверки. Предотвратите это, проведя планирование перед выполнением любых тестов. Всегда следите за актуальностью каждого теста. Убедитесь, что правильность и достоверность автотестов проверяются во всех циклах тестирования.

Правильно работайте с ожиданиями

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

Над тестами должна работать вся команда.

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

Реорганизуйте настройку тестов

Большинство тестов имеют предусловия и подготовку тестовых данных. Например, у одной команды был набор тестов на основе UI, выполнение которых занимало много времени и приводило к большому количеству ложных ошибок из‑за времени ожидания и небольших корректировок пользовательского интерфейса. Мы реорганизовали эти тесты, чтобы выполнить настройку с помощью API и проверки через UI. Эти улучшения имели такой же функциональный охват, но работали на 85% быстрее и имели примерно вдвое меньше ложных ошибок.

Запускайте тесты параллельно

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

Создавайте небольшие, но эффективные наборы тестов

Сгруппируйте наиболее важные тесты и объедините их в smoke‑набор. Часто это относительно простые тесты, но они необходимы для проверк.и вашей системы для дальнейшего тестирования. Нет абсолютно никакого смысла продвигаться вперед, если эти тесты не пройдены. Если у вас уже есть эти наборы, просто убедитесь, что они работают быстро.

Присоединяйтесь в наше небольшое сообщество.