Регрессионные виды тестирования (Regression testing)

Регресс - это противоположность прогресса. Любое ПО по мере прогресса в функционале неизбежно усложняется, увеличиваются взаимосвязи в функциях и т.п., и чтобы убедиться в том, что в существующей системе не начинается регресс, полезно иногда проводить ее полное тестирование. И уж тем более логично перетестировать всё, что можно, если в систему были внесены какие-то существенные изменения. Но этого недостаточно. По-сути, проблема намного серьезнее - мы каждый раз не знаем, что принесет с собой новая функциональность в системе. Нам каждый раз надо предположить/узнать/протестировать новые взаимодействия в системе, а не тестировать только новые функции в изоляции от остальных. Старый функционал с новым если начинают пересекаться - надо заново расчехлять аналитику, выявлять новые ситуации, которые могут возникнуть, писать новые тест-кейсы, которые затрагивают уже не столько функциональные, сколько интеграционные аспекты. Поэтому выяснение "не наступил ли регресс" (внимание, не путать с "не наступила ли регрессия") - постоянная задача, которую также необходимо решать в контексте maintenance testing.

Регрессионное тестирование (Regression Testing) - собирательное название для всех видов тестирования программного обеспечения связанных с изменениями, направленных на обнаружение ошибок в уже протестированных участках исходного кода, на проверку того, что новая функциональность не зааффектила (affect) старую. Такие ошибки — когда после внесения изменений в программу перестаёт работать то, что должно было продолжать работать, — называют регрессионными ошибками (regression bugs). Регрессионные тесты должны быть частью релизного цикла (Release Cycle) и учитываться при тестовой оценке (test estimation).

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

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

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

Можно заключить, что регрессионное тестирование выполняется чтобы минимизировать регрессионные риски. То есть, риски того, что при очередном изменении продукт перестанет выполнять свои функции. С регрессионным тестированием плотно связана другая активность - импакт анализ (Impact Analysis, анализ влияния изменений). Итоговая область регрессии называется Regression Scope / Scope of Regression.

Классификация регрессионного тестирования:

● Проверить всё (Retest All): Как следует из названия, все тест-кейсы в наборе тестов повторно выполняются, чтобы гарантировать отсутствие ошибок, возникших из-за изменения кода. Это дорогостоящий метод, поскольку он требует больше времени и ресурсов по сравнению с другими методами;

● Минимизация набора тестов (test suite minimization) стремится уменьшить размер тестового набора за счет устранения избыточных тестовых примеров из тестового набора;

● Задача выбора теста (test case selection) связана с проблемой выбора подмножества тестов, которые будут использоваться для проверки измененных частей программного обеспечения. Для этого требуется выбрать подмножество тестов из предыдущей версии, которые могут обнаруживать неисправности, основываясь на различных стратегиях. Большинство задокументированных методов регрессионного тестирования сосредоточены именно на этой технике. Обычная стратегия состоит в том, чтобы сосредоточить внимание на отождествления модифицированных частей SUT (system under test) и для выбора тестовых случаев, имеющих отношение к ним. Например, техника полного повторного тестирования (retest-all) – один из наивных типов выбора регрессионного теста путем повторного выполнения всех видов тестов от предыдущей версии на новой. Она часто используется в промышленности из-за её простого и быстрого внедрения. Тем не менее, её способность обнаружения неисправностей ограничена. Таким образом, значительный объём работ связан с разработкой эффективных и масштабируемых селективных методов;

● Задача определения приоритетов теста (test case prioritization). Ее цели заключаются в выполнении заказанных тестов на основе какого-либо критерия. Например, на основе истории, базы или требований, которые, как ожидается, приведут к более раннему выявлению неисправностей или помогут максимизировать некоторые другие полезные свойства;

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

Типы регрессии по Канеру:

● Регрессия багов (Bug regression) - попытка доказать, что исправленная ошибка на самом деле не исправлена;

● Регрессия старых багов (Old bugs regression) - попытка доказать, что недавнее изменение кода или данных сломало исправление старых ошибок, т.е. старые баги стали снова воспроизводиться;

● Регрессия побочного эффекта (Side effect regression) - попытка доказать, что недавнее изменение кода или данных сломало другие части разрабатываемого приложения;

Регрессия в Agile:

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

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

● Сквозная регрессия (End to End Regression): включает в себя все тест-кейсы, которые должны быть повторно выполнены для сквозного тестирования всего продукта, охватывая все основные функции;