Регрессионное тестирование или Regression Testing

Привет, Вы узнаете о том , что такое регрессионное тестирование, Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое регрессионное тестирование, regression testing , настоятельно рекомендую прочитать все из категории Качество и тестирование программного обеспечения. Quality Assurance..

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

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

Сам по себе термин "Регрессионное тестирование", в зависимости от контекста использования может иметь разный смысл. Сэм Канер, к примеру, описал 3 основных типа регрессионного тестирования:

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

Регрессио́нное тести́рование (англ. regression testing, от лат. regressio — движение назад) — собирательное название для всех видов тестирования программного обеспечения, направленных на обнаружение ошибок в уже протестированных участках исходного кода. Такие ошибки — когда после внесения изменений в программу перестает работать то, что должно было продолжать работать, — называют регрессионными ошибками (англ. regression bugs).

Регрессионное тестирование (по некоторым^{[каким?]} источникам) включает new bug-fix — проверка исправления вновь найденного дефекта, old bug-fix — проверка, что исправленный ранее и верифицированный дефект не воспроизводится в системе снова, а также side-effect — проверка того, что не нарушилась работоспособность работающей ранее функциональности, если ее код мог быть затронут при исправлении некоторых дефектов в другой функциональности. Обычно используемые методы регрессионного тестирования включают повторные прогоны предыдущих тестов, а также проверки, не попали ли регрессионные ошибки в очередную версию в результате слияния кода.

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

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

Регрессионное тестирование является неотъемлемой частью экстремального программирования. Об этом говорит сайт https://intellect.icu . В этой методологии проектная документация заменяется на расширяемое, повторяемое и автоматизированное тестирование всего программного пакета на каждой стадии процесса разработки программного обеспечения.

Использование

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

Классификация

В своей статье S. Yoo and M. Harman предоставляют следующую классификацию регрессионного тестирования:

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

Задача минимизации наборов

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

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

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

Задача с определением приоритетов

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

Один из методов предлагает основанные на ошибках приоритетные тесты, которые непосредственно используют знание об их способности обнаруживать неисправности.

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

Задача выбора тестов

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

1. Подход, основанный на диаграмме состояния (UML-based), регрессионного тестирования для требований безопасности аутентификации, конфиденциальности, доступности, авторизации и целостность. Тесты, представленные в виде диаграммы последовательности, выбираются на основе теста изменения требований.
2. Подход к улучшению регрессионного тестирования на основе нефункциональных требований онтологий. Тесты выбираются на основе изменений и воздействий анализа нефункциональных требований, таких как безопасность, производительность и надежность. Каждый тест связан с измененным требованием, которое выбирается для регрессивного тестирования.
3. Подход для обеспечения проверки дополнительных доказательств для сертификации требований безопасности услуг. Этот подход основан на обнаружении изменений в тестовой модели обслуживания, которая будет определять, должны ли быть созданы новые тестовые случаи или существующие будут отобраны для повторного выполнения на выделенном сервисе.
4. Подход к разработке безопасных систем оцениваемых по общим критериям. В этом подходе тестовые задания по требованиям безопасности создаются вручную и представлены в виде диаграммы последовательности. В случае изменения при необходимости пишутся новые тесты, а затем все тесты выполняются на новой версии.
5. Подход к требованиям тестирования безопасности веб-сервиса релизов. Пользователь службы может периодически повторно выполнить набор тестов, направленных против сервиса чтобы проверить, что пользователь по-прежнему обладает правильными правами.
6. Coverage-based метод отбора для эволюционного тестирования политик безопасности, каждая из которых включает в себя последовательность правил для определения, какие кто имеет допуск к ресурсу и при каких условиях.

Преимущества и недостатки

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

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

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

Цитаты

Фундаментальная проблема при сопровождении программ состоит в том, что исправление одной ошибки с большой вероятностью (20—50 %) влечет появление новой. Поэтому весь процесс идет по принципу «два шага вперед, шаг назад».

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

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

— Ф. Брукс Мифический человеко-месяц или как создаются программные системы

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