Регрессионное тестирование (реже нерегрессионное тестирование [1] ) — это повторное выполнение функциональных и нефункциональных тестов для того, чтобы убедиться, что ранее разработанное и протестированное программное обеспечение по-прежнему работает так, как ожидалось, после внесения изменений. [2] В противном случае это будет называться регрессией .
Изменения, которые могут потребовать регрессионного тестирования, включают исправления ошибок , улучшения программного обеспечения, изменения конфигурации и даже замену электронных компонентов ( аппаратного обеспечения ). [3] Поскольку наборы регрессионных тестов имеют тенденцию расти с каждым обнаруженным дефектом, часто применяется автоматизация тестирования. Очевидным исключением является регрессионное тестирование GUI , которое обычно должно выполняться вручную. Иногда выполняется анализ влияния изменений для определения соответствующего подмножества тестов ( нерегрессионный анализ [4] ).
При обновлении или изменении программного обеспечения или его повторном использовании на измененной целевой платформе возникновение новых неисправностей и/или повторное возникновение старых неисправностей является довольно распространенным явлением.
Иногда повторное появление происходит из-за того, что исправление теряется из-за плохой практики контроля версий (или простой человеческой ошибки в контроле версий). Часто исправление проблемы будет « хрупким », поскольку оно исправляет проблему в узком случае, где она была впервые обнаружена, но не в более общих случаях, которые могут возникнуть в течение жизненного цикла программного обеспечения. Часто исправление проблемы в одной области непреднамеренно вызывает программную ошибку в другой области.
Может случиться, что при перепроектировании функции некоторые из тех же ошибок, которые были допущены в исходной реализации функции, также возникнут при перепроектировании. В большинстве ситуаций разработки программного обеспечения считается хорошей практикой кодирования , когда ошибка обнаружена и исправлена, записать тест, который выявляет ошибку, и регулярно перезапускать этот тест после последующих изменений в программе. [5]
Хотя это можно сделать с помощью ручных процедур тестирования с использованием методов программирования, часто это делается с помощью автоматизированных инструментов тестирования . [6] Такой набор тестов содержит программные инструменты, которые позволяют тестовой среде автоматически выполнять все регрессионные тестовые случаи ; многие проекты имеют автоматизированные системы непрерывной интеграции для повторного запуска всех регрессионных тестов через заданные интервалы и сообщают о любых сбоях (которые могут подразумевать регрессию или устаревший тест). [7]
Обычные стратегии — запускать такую систему после каждой успешной компиляции (для небольших проектов), каждую ночь или раз в неделю. Эти стратегии можно автоматизировать с помощью внешнего инструмента.
Регрессионное тестирование является неотъемлемой частью метода разработки программного обеспечения экстремального программирования . В этом методе проектные документы заменяются обширным, повторяемым и автоматизированным тестированием всего программного пакета на каждом этапе процесса разработки программного обеспечения . Регрессионное тестирование проводится после завершения функционального тестирования, чтобы убедиться, что другие функции работают.
В корпоративном мире регрессионное тестирование традиционно выполнялось группой обеспечения качества программного обеспечения после того, как группа разработчиков завершила работу. Однако дефекты, обнаруженные на этом этапе, являются наиболее дорогостоящими для исправления. Эта проблема решается с появлением модульного тестирования . Хотя разработчики всегда писали тестовые случаи как часть цикла разработки, эти тестовые случаи, как правило, были либо функциональными тестами , либо модульными тестами , которые проверяют только предполагаемые результаты. Тестирование разработчиками заставляет разработчика сосредоточиться на модульном тестировании и включать как положительные, так и отрицательные тестовые случаи. [8]
Различные методы регрессионного тестирования:
Эта техника проверяет все тестовые случаи в текущей программе, чтобы проверить ее целостность. Хотя это и дорого, так как необходимо повторно запустить все случаи, она гарантирует отсутствие ошибок из-за измененного кода. [9]
В отличие от Retest all, этот метод запускает часть тестового набора (из-за стоимости retest all), если стоимость выбора части тестового набора меньше, чем у метода Retest all. [9]
Приоритизируйте тестовые случаи, чтобы повысить скорость обнаружения ошибок в тестовом наборе. Методы приоритезации тестовых случаев планируют тестовые случаи так, чтобы тестовые случаи с более высоким приоритетом выполнялись до тестовых случаев с более низким приоритетом. [9]
Этот метод представляет собой гибрид выбора регрессионного теста и приоритизации тестовых случаев. [9]
Регрессионное тестирование выполняется, когда вносятся изменения в существующую функциональность программного обеспечения или если в программном обеспечении есть исправление ошибки. Регрессионное тестирование может быть достигнуто с помощью нескольких подходов; если следовать подходу «тестировать все» , это дает уверенность в том, что изменения, внесенные в программное обеспечение, не повлияли на существующую функциональность, которая не изменилась. [10]
В гибкой разработке программного обеспечения , где жизненные циклы разработки программного обеспечения очень короткие, ресурсы ограничены, а изменения в программное обеспечение вносятся очень часто, регрессионное тестирование может привести к большим ненужным накладным расходам . [10]
В среде разработки программного обеспечения, которая имеет тенденцию использовать компоненты черного ящика от третьей стороны, выполнение регрессионного тестирования может быть сложным, поскольку любое изменение в стороннем компоненте может повлиять на остальную часть системы (а выполнение регрессионного тестирования на стороннем компоненте затруднено, поскольку это неизвестная сущность). [10]
Регрессионное тестирование может использоваться не только для проверки правильности программы, но часто и для отслеживания качества ее вывода. [11] Например, при проектировании компилятора регрессионное тестирование может отслеживать размер кода и время, необходимое для компиляции и выполнения тестовых наборов.
Также в результате появления новых ошибок обслуживание программ требует гораздо большего тестирования системы на каждое написанное утверждение, чем любое другое программирование. Теоретически, после каждого исправления необходимо запустить весь пакет тестовых случаев, ранее запущенных против системы, чтобы убедиться, что она не была повреждена каким-либо неясным образом. На практике такое регрессионное тестирование должно действительно приближаться к этой теоретической идее, и это очень затратно.
— Фред Брукс , «Мифический человеко-месяц» , стр. 122
Регрессионные тесты можно в целом разделить на функциональные тесты или модульные тесты . Функциональные тесты проверяют всю программу с различными входными данными. Модульные тесты проверяют отдельные функции, подпрограммы или методы объектов. Как инструменты функционального тестирования, так и инструменты модульного тестирования, как правило, автоматизированы и часто являются сторонними продуктами, которые не являются частью набора компиляторов. Функциональный тест может быть заскриптованной серией входных данных программы, возможно, даже включающей автоматизированный механизм управления движениями мыши и щелчками. Модульный тест может быть набором отдельных функций в самом коде или драйверном слое, который ссылается на код без изменения тестируемого кода.
Тестирование, которое фокусируется на проблемах регрессии, называется (не)регрессионным тестированием. Обычно «не» опускается