Регрессионное тестирование, инструменты и примеры

Что такое регрессионное тестирование?

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

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

БЕСПЛАТНО СКАЧАТЬ КНИГИ в телеграм канале "Библиотека тестировщика"

Примеры регрессионного тестирования

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

• Атрибут: визуальный, функциональный, производительность, безопасность.
• Уровень приложения: UI и API.
• Тип приложения: web, mobile, API и desktop.
• Детализация: сквозные, интеграционные и модульные тесты (пирамида тестов).

Для регулярной проверки существующего кода регрессионное тестирование в основном включает в себя следующие шаги:

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

Рассмотрим простой пример. У нас есть мобильное приложение типа community, в котором пользователи могут делиться своими соображениями в виде коротких сообщений. Другие пользователи могут комментировать эти сообщения и взаимодействовать с ними. Для дальнейшего улучшения UX инженер-программист хочет добавить функцию персонализированной рекомендации постов на основе интересов и прошлой активности пользователей.

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

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

Почему регрессионное тестирование важно в Agile и CI/CD?

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

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

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

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

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

Другими словами, если ваш продукт часто подвергается модификации, регрессионное тестирование станет фильтром, обеспечивающим качество по мере улучшения продукта.

Когда проводится регрессионное тестирование?

Как правило, регрессионное тестирование проводится в следующих случаях:

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

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

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

Как правило, хорошим практическим правилом является проверка критических возможностей:

• Функции, составляющие основные бизнес-потоки.
• Часто используемые функции.

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

1. Обнаружение изменений исходного кода

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

2. Определение приоритетов затронутых областей и тестовых примеров

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

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

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

3. Определение точки входа и выхода

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

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

4. Классификация регрессионных тестов

На этом этапе мы углубляемся в план, сформулированный на шаге №3, и классифицируем тесты по различным признакам. К числу общих критериев категоризации тестов относятся:

• Ручные и автоматизированные регрессионные тесты: Для специальных или неповторяющихся тестовых случаев наибольший смысл имеет ручное тестирование и человеческая оценка. Все, что включает в себя одну и ту же серию тестовых шагов, должно быть автоматизировано.
• Критические и некритические функции: оценивайте тестовые случаи на основе срочности и значимости и присваивайте им уровень важности (высокий, средний, низкий). Также могут учитываться и другие факторы, основанные на требованиях бизнеса.
• Типы тестирования: для каждого типа тестирования требуется своя настройка, инструменты и среда,. Поэтому классификация тестовых случаев по типам (например, функциональные/нефункциональные тесты) позволяет команде лучше контролировать проводимую работу. Для простоты многие команды тестировщиков постепенно переходят на централизованную систему тестирования. С ее помощью можно проводить широкий спектр тестов без необходимости постоянно переключаться между платформами.

5. Подготовка тестовой среды

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

Использовать облачные среды или физические устройства?

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

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

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

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

CI и контейнеры

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

6. Планирование и выполнение тестов

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

7. Измерение успешности регрессионного тестирования

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

Топ инструментов регрессионного тестирования

1. Платформа Katalon

Katalon Platform – это комплексная платформа для автоматизации регрессионного тестирования с поддержкой искусственного интеллекта, которая позволяет вывести регрессионное тестирование на новый уровень. Это универсальный инструмент для регрессионного тестирования веб-сайтов, веб-сервисов, десктопных и мобильных приложений и даже API.

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

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

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

После выполнения тестов Katalon Platform позволяет командам просмотреть результаты тестирования с помощью комплексных и настраиваемых отчетов о тестировании в форматах LOG, HTML, CSV и PDF, а затем переслать их в виде вложений по электронной почте. Для тестировщиков предусмотрен режим отладки, позволяющий провести анализ первопричины конкретного неудачного случая.

Платформа легко интегрируется в конвейер CI/CD благодаря разнообразной экосистеме интеграции. В бесплатной версии Katalon Platform есть практически все функции, необходимые вашей команде, чтобы начать тестирование и принести пользу без каких-либо затрат.

Кроме того, в Katalon Platform реализовано множество интересных функций искусственного интеллекта:

• StudioAssist: Использует ChatGPT для автономной генерации тестовых сценариев на основе обычного языка и быстро объясняет тестовые сценарии для понимания всеми заинтересованными сторонами.
• Генератор сценариев ручного тестирования: Интегрируется с JIRA, читает описание заявки, извлекает необходимую информацию о требованиях к тестированию ПО и выдает набор комплексных ручных тест-кейсов, соответствующих описанному сценарию тестирования.
• SmartWait: Автоматическое ожидание появления на экране всех необходимых элементов перед продолжением тестирования.
• Самовосстановление: Автоматически исправляет неработающие локаторы элементов и использует новые локаторы в последующих прогонах теста, что снижает затраты на обслуживание.

2. Selenium

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

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

3. Watir

Watir, или Web Application Testing in Ruby, – это библиотека с открытым исходным кодом, использующая язык программирования Ruby для облегчения тестирования на основе OLE, что избавляет от необходимости использования внешнего сервера. Благодаря обширному и интуитивно понятному интерфейсу, Watir позволяет пользователям легко создавать код, не прибегая к чтению обширной документации.

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

4. IBM Rational Functional Tester

Rational Functional Tester, или RFT, – это инструмент для автоматизации тестирования программного обеспечения от компании IBM. Он обеспечивает автоматизацию функционального, регрессионного, графического и управляемого данными тестирования и совместим с веб-приложениями, .NET, Java, Siebel, SAP, приложениями на базе эмулятора терминала и PowerBuilder.

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

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

5. Apache JMeter

Apache JMeter – это Java-приложение с открытым исходным кодом для тестирования нагрузки, производительности и функционального поведения веб-приложений. Оно было расширено для тестирования других функций, таких как эффективность и одновременная обработка запросов пользователей на сервере.

Графический интерфейс JMeter, основанный на графическом API Swing, прост в использовании и может быть запущен в любой среде, поддерживающей виртуальную машину Java, включая Windows, Linux и Mac. Это отличный инструмент для функционального тестирования производительности и регрессионного тестирования на различных технологиях.

Технологии регрессионного тестирования

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

1. Повторное тестирование

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

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

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

2. Выбор регрессионных тестов

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

Такой подход подходит для более сложных или масштабных приложений, в которых количество тестовых сценариев, подлежащих выполнению, достаточно высок.

3. Приоритизация тестовых случаев

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

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

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

4. Корректирующее регрессионное тестирование

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

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

5. Прогрессивное регрессионное тестирование

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

Ретестирование и регрессионное тестирование

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

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

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

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

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

Регрессионное тестирование в Agile

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

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

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

Заключение

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

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

Перевод статьи «What is Regression Testing? Definition, Tools and Examples».