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