Введение

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

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

Предыстория

По мере обновления или изменения программного обеспечения, или при повторном использовании его в модифицированной среде, часто возникают новые ошибки и/или повторно проявляются старые. Иногда повторное проявление происходит из-за потери исправления в результате ненадлежащей практики контроля версий (или простой человеческой ошибки при контроле версий). Зачастую исправление проблемы оказывается "хрупким" – оно решает проблему в конкретном случае, когда она была впервые обнаружена, но не в более общих случаях, которые могут возникнуть в течение жизненного цикла программного обеспечения. Нередко исправление проблемы в одной области непреднамеренно вызывает программную ошибку в другой. Может случиться, что при переработке функциональности те же ошибки, которые были допущены при первоначальной реализации, повторятся и в переработанной версии. В большинстве ситуаций разработки программного обеспечения считается хорошей практикой кодирования, что при обнаружении и исправлении ошибки необходимо создать тест, выявляющий эту ошибку, и регулярно повторно запускать этот тест после внесения последующих изменений в программу. Хотя это можно делать вручную, используя методы программирования, чаще для этого используются автоматизированные инструменты тестирования. Такой набор тестов содержит программные средства, позволяющие тестовой среде автоматически выполнять все сценарии регрессионного тестирования; некоторые проекты даже настраивают автоматизированные системы для повторного запуска всех регрессионных тестов через заданные интервалы и отчетов о любых сбоях (которые могут указывать на регрессию или устаревший тест). Распространенные стратегии – запускать такую систему после каждой успешной компиляции (для небольших проектов), каждую ночь или раз в неделю. Эти стратегии можно автоматизировать с помощью внешнего инструмента. Регрессионное тестирование является неотъемлемой частью методологии разработки программного обеспечения Extreme Programming. В этой методологии проектная документация заменяется обширным, воспроизводимым и автоматизированным тестированием всего программного пакета на каждом этапе процесса разработки. Регрессионное тестирование проводится после завершения функционального тестирования для проверки работоспособности других функций. В корпоративной среде регрессионное тестирование традиционно выполнялось командой по обеспечению качества программного обеспечения после завершения работы команды разработчиков. Однако дефекты, обнаруженные на этом этапе, обходятся наиболее дорого при исправлении. Эта проблема решается за счет развития юнит-тестирования. Хотя разработчики всегда писали тестовые примеры в рамках цикла разработки, эти примеры обычно представляли собой либо функциональные тесты, либо юнит-тесты, проверяющие только ожидаемые результаты. Тестирование, проводимое разработчиками, заставляет их уделять больше внимания юнит-тестированию и включать как позитивные, так и негативные тестовые примеры.

Повторно проверить все

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

Выбор регрессивного теста

В отличие от метода Retest all, эта техника запускает часть набора тестов (ввиду стоимости повторного тестирования всего набора), если стоимость выбора части набора тестов меньше, чем стоимость метода Retest all. В гибкой разработке программного обеспечения, где жизненные циклы разработки очень короткие, ресурсы ограничены, а изменения в программном обеспечении происходят часто, регрессионное тестирование может приводить к значительным избыточным затратам. Например, при разработке компилятора регрессионное тестирование может отслеживать размер кода и время, необходимое для компиляции и выполнения тестовых случаев. Регрессионные тесты можно широко классифицировать как функциональные тесты или модульные тесты. Функциональные тесты проверяют полную программу с различными входными данными. Модульные тесты проверяют отдельные функции, подпрограммы или методы объектов. Как инструменты функционального тестирования, так и инструменты модульного тестирования обычно автоматизированы и часто являются продуктами сторонних разработчиков, не входящими в состав компиляторного пакета. Функциональный тест может представлять собой последовательность запрограммированных входных данных для программы, возможно, даже включающую автоматизированный механизм для управления движениями мыши и щелчками. Модульный тест может быть набором отдельных функций в самом коде или драйверным слоем, который связывается с кодом, не изменяя тестируемый код.