Регрессионное тестирование: различия между версиями

Материал из Википедии — свободной энциклопедии
Перейти к навигации Перейти к поиску
[непроверенная версия][непроверенная версия]
Содержимое удалено Содержимое добавлено
мНет описания правки
Строка 58: Строка 58:


== Литература ==
== Литература ==
<ref name=":0" /> S. Yoo and M. Harman. Regression testing minimisation, selection and prioritisation: A survey. Software Testing, Veri_cation, and Reliability, 1(1):121-141, 2010.
<ref name=":0" /> S. Yoo and M. Harman. Regression testing minimisation, selection and prioritisation: A survey. Software Testing, Veri_cation, and Reliability, стр:121-141, 2010.


<ref>{{Статья|автор=Michael Felderer, Matthias Büchler, Martin Johns|заглавие=Security Testing: A Survey|ссылка=https://www.researchgate.net/publication/297918097_Security_Testing_A_Survey|язык=|издание=researchgate|тип=|год=2016|месяц=март|число=12|том=|номер=|страницы=22-26|issn=}}</ref> Michael Felderer, Matthias Büchler, Martin Johns. Security Testing: A Survey
<ref>{{Статья|автор=Michael Felderer, Matthias Büchler, Martin Johns|заглавие=Security Testing: A Survey|ссылка=https://www.researchgate.net/publication/297918097_Security_Testing_A_Survey|язык=|издание=researchgate|тип=|год=2016|месяц=март|число=12|том=|номер=|страницы=22-26|issn=}}</ref> Michael Felderer, Matthias Büchler, Martin Johns. Security Testing: A Survey

Версия от 21:12, 16 декабря 2016

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

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

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

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

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

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

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

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

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

Тест минимизации наборов

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

Тестовая задача на определение приоритетов

Тестовая задача выбора

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

Цитаты

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

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

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

См. также

Примечания

  1. S. Yoo and M. Harman. Regression testing minimisation, selection and prioritisation: A survey.. — 2010. — С. 121-141.
  2. Ф. Брукс, Мифический человеко-месяц или как создаются программные системы. Пер. с англ. — СПб.: Символ-Плюс, 2001. — 304 с.: ил. (с. 113—114).

Ссылки

Литература

[1] S. Yoo and M. Harman. Regression testing minimisation, selection and prioritisation: A survey. Software Testing, Veri_cation, and Reliability, стр:121-141, 2010.

[2] Michael Felderer, Matthias Büchler, Martin Johns. Security Testing: A Survey

  1. Ошибка в сносках?: Неверный тег <ref>; для сносок :0 не указан текст
  2. Michael Felderer, Matthias Büchler, Martin Johns. Security Testing: A Survey // researchgate. — 2016. — 12 март. — С. 22-26.