KarakulkoDanill.md 30 KB

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

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

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

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

Обзор регрессионного теста

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

Например

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

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

Регрессионное тестирование не зависит от какого-либо языка программирования, такого как Java, C ++, C # и т. Д. Это метод тестирования, который используется для проверки продукта на наличие изменений или любых выполняемых обновлений. Оно проверяет, что любые изменения в продукте не влияют на существующие модули продукта.

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

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

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

Регрессионное тестирование должно быть частью цикла выпуска и должно учитываться при оценке тестирования. Когда выполнять этот тест?

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

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

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

На следующий день, когда вы возвращаетесь, вы выполняете тест еще раз – это означает, что вы повторяете тест, который выполняли ранее. Простой акт повторения теста - это Повторное тестирование.

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

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

Конечно, первоначальный вопрос:

Можно ли выполнить это тестирование вручную?

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

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

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

Ниже приведены различные типы регрессии :

Модульная регрессия
Частичная регрессия
Полная регрессия

1) Модульная регрессия

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

2) Частичная регрессия

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

3) Полная регрессия

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

Что мы делаем при регрессионной проверке?

Повторно запустите ранее проведенные тесты.
Сравните текущие результаты с результатами ранее выполненных тестов

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

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

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

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

Ниже приведены различные методы.

Повторное тестирование всех
Выбор регрессионного теста
Приоритизация тестовых примеров
Гибрид

Методы регрессионного тестирования

** 1) Повторное тестирование всех

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

** 2) Выбор регрессионного теста

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

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

** 3) Приоритизация тестовых примеров

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

** 4) Гибрид

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

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

Ниже приведен список тестовых примеров, которые можно использовать при выполнении этого теста:

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

Как выполнить регрессионное тестирование?

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

Ниже приведены различные шаги, связанные с выполнением этого Тестирования

Подготовьте набор тестов для регрессии с учетом пунктов, упомянутых в разделе “Как выбрать набор тестов регрессии”?
Автоматизируйте все тестовые примеры в наборе тестов.
Обновляйте набор регрессионных тестов всякий раз, когда это требуется, например, если обнаружен какой-либо новый дефект, который не охвачен в тестовом примере, и тестовый пример для него должен быть обновлен в наборе тестов, чтобы в следующий раз тестирование не было пропущено. Набор регрессионных тестов должен управляться надлежащим образом путем постоянного обновления тестовых примеров.
Выполняйте регрессионные тестовые примеры всякий раз, когда в коде происходят какие-либо изменения, исправляется ошибка, добавляется новая функциональность, выполняется улучшение существующей функциональности и т.д.
Создайте отчет о выполнении теста, который включает статус выполнения / сбоя выполненных тестовых примеров. 

Инструменты автоматического регрессионного тестирования

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

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

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

Большинство инструментов регрессионного тестирования имеют типы записи и воспроизведения. Вы можете записывать тестовые примеры, просматривая AUT (тестируемое приложение) и проверяя, приходят ли ожидаемые результаты или нет.

Рекомендуемые инструменты

1) Avo Assure

Avo Assure - это 100% решение для автоматизации тестирования без кода и гетерогенного тестирования, которое упрощает и ускоряет регрессионное тестирование.

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

Avo Assure поможет вам:

Достигайте > 90% охвата автоматизации тестирования путем многократного выполнения сквозных регрессионных тестов.
Легко визуализируйте всю иерархию тестирования одним нажатием кнопки. Определите планы тестирования и разработайте тестовые примеры с помощью функции Mindmaps.
Используйте более 1500 ключевых слов и > 100 ключевых слов, специфичных для SAP, для более быстрой доставки приложений
Выполняйте несколько сценариев одновременно, используя функцию интеллектуального планирования и выполнения.
Интегрируйтесь с множеством решений SDLC и непрерывной интеграции, таких как Jira, Sauce Labs, ALM, TFS, Jenkins и qTest.
Интуитивно анализируйте отчеты с помощью удобочитаемых скриншотов и видеороликов выполнения тестового примера.
Включите тестирование доступности для ваших приложений.

2) BugBug

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

Как это работает?

Создайте тестовый сценарий
Начать запись
Просто нажмите на свой веб–сайт - BugBug записывает все ваши взаимодействия в виде шагов тестирования.
Запустите свой тест – BugBug повторяет все ваши записанные шаги тестирования.

Более простая альтернатива Selenium

Легче учиться
Более быстрое создание готовых к производству регрессионных тестов.
Не требует кодирования

Хорошее соотношение цены и качества:

БЕСПЛАТНО, если вы запускаете автоматические регрессионные тесты только в своем локальном браузере.
Всего за 49 долларов в месяц вы можете использовать BugBug cloud для выполнения всех ваших регрессионных тестов каждый час.

3) Katalon

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

Вы можете:

Быстрое создание автоматизированных этапов тестирования с использованием записи и воспроизведения.
Легко захватывать тестовые объекты и поддерживать их во встроенном репозитории (модель страницы-объекта).
Повторно используйте ресурсы тестирования для увеличения количества автоматических регрессионных тестов.

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

4) Virtuoso

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

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

Кросс-браузерный и кросс-девайсный, напишите один тест для всех.
Самый быстрый опыт разработки.
Инструмент тестирования следующего поколения, дополненный искусственным интеллектом.
Гарантированное регрессионное тестирование в спринте.
Готовая интеграция с вашим конвейером CI / CD.

5) TimeShiftX

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

Selenium
АдвентНет QEngine
Регрессионный тестер
vTest
Watir
actiVate
Рациональный Функциональный Тестер
SilkTest

Большинство из них являются инструментами функционального и регрессионного тестирования.

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

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