Стратегия автоматизации тестирования для гибких проектов

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

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

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

Управляющее резюме

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

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

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

Для этого требуется «инвертировать пирамиду автоматизации тестирования», переместив тесты GUI, выполнение которых занимает много времени, на более низкие уровни, например Уровень API, который может запускаться сразу после модульных тестов как часть сборки, чтобы обеспечить начальный уровень уверенности.

Связанный:

• Как выбрать, какие тесты автоматизировать?
• С чего начать автоматизацию тестирования существующего сайта?
• Должна ли автоматизация тестирования выполняться отдельной специализированной командой?

Обзор стратегии автоматизации тестирования

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

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

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

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

Модульные тесты формируют основу для автоматизации тестирования на более высоких уровнях.

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

Определение пакетов регрессии

Автоматизированные регрессионные тесты - это ядро ​​стратегии автоматизации тестирования.

Пакет Smoke Regression Pack

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

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

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

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

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

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

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

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

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

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

Стратегия автоматизации тестирования для нескольких гибких команд

Автоматизированные модульные тесты

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

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

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

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

Автоматическая интеграция / API или сервисные тесты

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

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

При необходимости, насмешки, такие как Wiremock будет использоваться, чтобы исключить зависимость других 3^rdпартийные системы и когда нижестоящие системы недоступны для предоставления данных, необходимых для тестирования.

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

Для сервисных тестов можно использовать такие инструменты, как SoapUI.

Тестирование приложений

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

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

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

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

Сквозные сценарии тестирования

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

Переворачивание пирамиды автоматизации тестирования

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

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

Хрупкий

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

Ограниченное тестирование

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

Медленный

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

Наименьшая рентабельность инвестиций

Из-за вышеупомянутых проблем автоматические тесты GUI обеспечивают наименьшую рентабельность инвестиций.

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