Регрессионное тестирование — секретное оружие разработчиков

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

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

Общие сведения

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

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

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

Назначение

При внесении изменений в программу необходимо обеспечить сохранение ее качества. Для этой цели используется регрессионное тестирование, которое, хотя и требует затрат, является неотъемлемой частью области тестирования, связанной с обслуживанием (maintenance testing). Оно направлено на перепроверку правильности работы программы после внесенных изменений.

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

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

Основная задача РТ

Главной целью maintenance testing (тестирования при обслуживании) является установление систематического процесса управления изменениями в программном коде. После каждой модификации программы необходимо проверить, не повлияло ли это на ее функциональность. Если такое влияние обнаружено, это называется регрессионным дефектом. Для регрессионного тестирования функциональностей, которые не планировалось изменять, используются заранее созданные тесты.

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

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

Можно сделать вывод, что регрессионное тестирование выполняется с целью снижения рисков, связанных с возможными изменениями в программном продукте. Эти риски заключаются в том, что после внесения изменений продукт может перестать корректно выполнять свои функции. В рамках регрессионного тестирования также активно проводится анализ влияния изменений, чтобы определить область кода или функциональности, которую необходимо перепроверить. Эта область называется «Область регрессии» или «Объем регрессии» (Regression Scope / Scope of Regression).

Какие используются подходы в РТ

Существует несколько подходов и общих стратегий для успешного проведения регрессионного тестирования:

• Повторное выполнение всех существующих тестов: После каждого релиза тестировщики должны повторно протестировать «проблемные области» приложения. Это может быть сложно, особенно если тесты проводятся вручную, поэтому автоматизация тестов становится важным инструментом для ускорения процесса.
• Установление приоритетов: При проведении регрессионного тестирования не менее 50% всех тестов должны быть посвящены критически важной функциональности. Это позволяет обеспечить работоспособность ключевых аспектов приложения.
• Тестирование сложных функций: Особое внимание следует уделять сложным функциям, которые взаимодействуют с множеством компонентов. Такие функции могут повлиять на качество работы приложения в целом, поэтому их тщательно проверяют.
• Исследовательское тестирование при добавлении новых функций: При внесении новых функций в приложение важно проводить исследовательское тестирование. Это помогает выявить возможные неожиданные побочные эффекты и дефекты, которые могли появиться в результате изменений.
• Автоматизация: Для ускорения процесса и повышения производительности важно продуманно автоматизировать регрессионные тесты. Автоматизированные тесты могут быть запущены быстро и многократно, что делает их эффективным инструментом для регрессионного тестирования.
• Рендомное тестирование: Опытные тестировщики могут проводить случайные или рендомные тесты, чтобы выявить неочевидные дефекты или нестандартные сценарии использования приложения.

Эти подходы помогают обеспечить успешное проведение регрессионного тестирования и поддерживать высокое качество программного продукта.

Регрессионные тест-кейсы

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

Ориентированные на часто возникающие баги

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

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

Ориентированные на критически важные функции

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

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

Тест-кейсы с последними обновлениями кода

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

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

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

Связанные с интеграцией модулей

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

Примеры использования

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

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

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

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

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

Классификация

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

Проверка всего (Retest All)

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

Минимизация набора тестов (Test Suite Minimization)

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

Задача выбора теста (Test Case Selection)

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

Задача определения приоритетов теста (Test Case Prioritization)

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

Гибридный метод (Hybrid)

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

Классификация по Канеру

Типы регрессии по Канеру включают:

• Регрессия багов (Bug Regression): Это когда мы пытаемся доказать, что исправленная ошибка на самом деле не была полностью устранена и продолжает проявляться.
• Регрессия старых багов (Old Bugs Regression): Здесь мы пытаемся убедиться, что недавние изменения в коде или данных привели к тому, что старые ошибки, которые когда-то были исправлены, снова стали возникать.
• Регрессия побочного эффекта (Side Effect Regression): Этот тип регрессии связан с попыткой доказать, что недавние изменения в коде или данных оказали негативное воздействие на другие части разрабатываемого приложения, вызывая проблемы в несвязанных с ними областях.

Регрессия в Agile

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

В Agile существует две основные категории РТ:

• Регрессия уровня спринта (Sprint Level Regression): Это тестирование, которое фокусируется в основном на новых функциях или улучшениях, добавленных в последний спринт. Для этой категории регрессии выбираются тест-кейсы из набора тестов, которые связаны с новыми добавленными возможностями или улучшениями.
• Сквозная регрессия (End to End Regression): В этой категории регрессии включаются все тест-кейсы, которые должны быть повторно выполнены для проверки всего продукта. Это включает в себя тестирование всех основных функций продукта, чтобы убедиться, что они остаются работоспособными после внесенных изменений.

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

Смоук-тестирование

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

Регрессия уровня спринта (Sprint Level Regression) — это форма смоук тестирования, выполняемая для новых функций или улучшений, добавленных в последний спринт. Здесь выбираются тест-кейсы, связанные с этими новыми изменениями.

Тест верификации сборки (Build Verification Test, BVT) представляет собой автоматизированный набор тестов, который проверяет целостность каждой новой сборки и ее ключевую функциональность. Он часто используется в проектах с высокой частотой сборок, таких как проекты, использующие гибкие методологии разработки. BVT выполняется перед передачей каждой новой сборки в тестирование и включает в себя тестирование стабильности и тестируемости продукта.

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

Санити-тестирование

Санити тестирование (Sanity testing), также известное как тест работоспособности, представляет собой один из видов РТ. Оно проводится до или вместо полной регрессии, но после смоук тестирования.

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

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

Подтверждающее, повторное тестирование

Подтверждающее тестирование (confirmation testing), также известное как повторное тестирование (re-testing), представляет собой процесс, при котором выполняются тестовые сценарии, которые не были пройдены при последнем запуске, с целью подтвердить успешность исправлений.

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

Тестирование N+1 (N+1 testing)

Тестирование N+1 (N+1 testing) — это вариант РТ, в котором проверка работоспособности продуктов выполняется в несколько циклов. В каждом цикле ошибки, которые были обнаружены в предыдущем тестовом цикле «N», устраняются и затем повторно проводится проверка на работоспособность в тестовом цикле N + 1. Этот процесс продолжается до тех пор, пока не будет обнаружено ни одной ошибки, и все функциональные или кодовые изменения будут успешно проверены.

Инструменты

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

Katalon Studio

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

Одной из особенностей Katalon Studio является его способность выполнять тестовые сценарии в различных контекстах, браузерах и на разных устройствах. Кроме того, инструмент предоставляет настраиваемые отчеты о результатах тестирования, которые могут быть подробно изучены и отправлены по электронной почте в форматах LOG, HTML, CSV и PDF.

Selenium

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

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

Watir

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

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

Apache JMeter

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

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

Сравнение регрессионного и повторного тестирования

В таблице ниже рассмотрим основные сходства и отличия между повторным и регрессионным тестированием:

Преимущества РТ

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

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

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

Заключение

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

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

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