·+Регрессионное+тестирование+(regression+testing)


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

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

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

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

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

На вопрос когда и как проводить регрессионное тестирование, и какие тесты ставить в первую очередь ответить не просто. Все определяется видом разрабатываемого ПО, продолжительностью жизненного цикла, сроками тестирования, количеством членов команды. Далее описаны лишь общие положения:
 * 1) Регрессионное тестирование проводится в каждой новой версии.
 * 2) Начинают регрессионное тестирование с Тестов верификации версии. Если программа приходит от разработчика в виде полноценной инсталляции, то Тесты верификации начинаются с проверки инсталляции, после чего проводится краткий набор тестов функциональности. Если хотя бы один из тестов failed, версия передается на доработку, регрессионное тестирование прекращается, а тестер возвращается к тестированию последней "рабочей" версии.
 * 3) После успешного прохождения тестов верификации версии, проводят серию Тестов верификации багов.
 * 4) Из Собственно тестов регрессии проводят лишь те, которые сопряжены с измененным в новой версии участком кода.
 * 5) Аналогичным образом (см. пункт 4 ) отбираются тесты в группу регрессии на "закрытых" багах.
 * 6) Тесты регрессии, выполненные успешно (pass) дважды считаются "закрытыми". Дальнейшее их использование производится так как описано в пункте 4.
 * 7) Для тестов регрессии, которые предполагается проводить более 3-5 раз рекомендуется писать скрипты для автоматизации процесса. Это относится ко всемгруппам тестов регрессии.
 * 8) Отбор тестов для Финального регрессионного тестирования осуществляется по следующим принципам:
 * В первую очередь отбирают тесты забракованные (failed) два и более раз. В том числе и те, которые выявляли баги, требующие доработки (re-do).
 * Во вторую очередь отбираются тесты забракованные один раз, и успешно пройденные повторно.
 * Далее отбираются все тесты, которые были пройдены успешно (pass), но проводились только один раз.
 * Затем проводятся все остальные тесты, в зависимости от поставленной задачи.

Для наглядности при проведении Регрессионного тестирования можно использовать следущую таблицу: Количество столбцов соответствует количеству версий. Например,
 * № теста || № версии || № бага || № версии || № бага ||
 * № теста || Версия 1 || № бага || Версия 2 || № бага || Версия 3 || № бага ||
 * 1 || Pass ||  ||   ||   ||   ||   ||
 * 2 || Pass ||  ||   ||   ||   ||   ||
 * 3 || Fail || 1 || Pass || 1 - verified ||  ||   ||
 * 4 || Pass ||  ||   ||   ||   ||   ||
 * 5 || Pass ||  ||   ||   ||   ||   ||
 * 6 || Fail || 2 || Pass || 2 - verified ||  ||   ||
 * 7 || Fail || 3 || Fail || 3 - re-do || Pass || 3 - verified ||
 * 8 ||  ||   || Pass ||   ||   ||   ||
 * 9 ||  ||   || Fail || 4 ||   ||   ||
 * 10 ||  ||   ||   ||   || Pass ||   ||


 * Комментарий.** В ходе тестирования среди первых тестов №№ 1, 2, 4, 5 были проведены успешно и отмечены как pass. Тесты № 3, 6, 7 выявили баги (fail) соответственно №№ 1, 2 и 3. В версии №2 разработчик сообщил, что баги №№ 1,2 и 3 исправлены. В ходе Тестов верификации багов (предполагается, что Тесты верификации версии прошли успешно) выяснилось, что тесты №№ 3 (выявил баг № 1) и 6 (баг № 2) прошли успешно (баги помечены как verified), а тест № 7 (баг № 3 ) - вновь выявил тот же баг, о чем сообщено разработчику (re-do). Кроме того во второй версии было продолжено тестирование и проведены тесты №№ 8 и 9. Тест № 8 прошел успешно, а тест № 9 выявил баг № 4. В третьей версии (тесты верификации версии также прошли успешно) разработчик повторно сообщил, что баг № 3 исправлен, что и подтвердило повторное проведение этого теста (тест - pass, баг - verified). Информации об исправлении бага № 4 в третьей версии от разработчика не поступало, поэтому этот тест верификации не проводился. Очередной тест № 10 багов не выявил (pass).

http://ru.wikipedia.org/wiki/%D0%A0%D0%B5%D0%B3%D1%80%D0%B5%D1%81%D1%81%D0%B8%D0%BE%D0%BD%D0%BD%D0%BE%D0%B5_%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5 http://www.protesting.ru/testing/types/regression.html http://s-test.narod.ru/Articles/regtest.htm http://www.intuit.ru/department/se/testing/11/