Comments on: Регрессионное тестирование (regression testing) http://www.javenue.info/post/24 Блог разработчика о Java и родственных технологиях Sun, 05 Feb 2012 00:12:15 +0000 http://wordpress.org/?v=2.2.1 By: dima http://www.javenue.info/post/24#comment-71407 dima Fri, 01 Oct 2010 08:03:34 +0000 http://www.javenue.info/post/24#comment-71407 Буква ш в тексте отображается иероглифами Буква ш в тексте отображается иероглифами

]]> By: generator http://www.javenue.info/post/24#comment-30724 generator Mon, 10 Nov 2008 08:14:38 +0000 http://www.javenue.info/post/24#comment-30724 to Bishop позволю себе не согласиться с Вами, регрессия и повтор это разные понятия. Советую прочитать стандарты. После выхода релиза тестирование не прекращается, если есть баги, поэтому при выпуске баг-фикса необходимо провести ,нет не повторное тестирование, как это напра?ивается, а проводят регрессивное т.е. возвращаются к результатам полученным при появлении бага и тестируют этот функционал, затем тестируют смежные модули. А повторное тестирование это изменение набора тестовых значений без исправлений бага, для определения области действия. П.С. Статья хоро?ая. П.С.С. Автору на заметку - сделайте ссылки на стандарты ;). to Bishop позволю себе не согласиться с Вами, регрессия и повтор это разные понятия. Советую прочитать стандарты. После выхода релиза тестирование не прекращается, если есть баги, поэтому при выпуске баг-фикса необходимо провести ,нет не повторное тестирование, как это напра?ивается, а проводят регрессивное т.е. возвращаются к результатам полученным при появлении бага и тестируют этот функционал, затем тестируют смежные модули.
А повторное тестирование это изменение набора тестовых значений без исправлений бага, для определения области действия.
П.С.
Статья хоро?ая.
П.С.С.
Автору на заметку - сделайте ссылки на стандарты ;).

]]> By: Bishop http://www.javenue.info/post/24#comment-980 Bishop Tue, 19 Sep 2006 15:53:44 +0000 http://www.javenue.info/post/24#comment-980 В данных примерах не точно указано и не все ситуации указаны, когда применяется и как это выглядит Вот мое предсавление об этом: Regression testing Общее представление Это тестирование, которое проводится при втором и последующих тестирований версий продукта вплоть до релиза. Сам термин следует понимать, как "повторное тестирование", тоесть, что есть "повтор" - повтор это действие, которое проводиться 2 и более раз. Когда применяется 1) После того, как программист исправил дефект (ы) 2) После добавления новой функциональности (например, в случае с change request) или с урезанием или полным удалением старой функциональности. 3) С выходом новой версии. С какой целью применяется 1) В ситуации с исправленным дефектом, тестировщик проводит проверку дефекта. При проверки, он обязан удостовериться, что дефект исправлен корректно, а именно: согласно System Requirements по данной функциональности. 2) В ситуации с добавлением новой функциональности, тестировщик обязан удостовериться, что при добавлении новой функциональности не были повреждены участки старой функциональности. 2.1) В ситуации с урезанием или полным удалением старой функциональности, тестировщик обязан удостовериться, что при урезании или полном удалении старой функциональности не были повреждены другие участки функциональности, которые не относились к данному исправлению (в точности урезанию или удалению). 3) В ситуации с выходом новой версии, даже если в системе не осталось "неисправленных" дефектов и не была добавлена новая функциональность или же урезана или удалена старая функциональность, тестировщик обязан провести регрессионное тестирование, чтобы гарантировать, что система работоспособна и отвечает требованиям заказчика. Как это выглядит 1) В ситуации с исправленным дефектом. При выходе новой версии. Тестировщик обязан проверить дефект (ы) на корректность исправления. ? прогнать весь набор тест-кейсов, чтобы гарантировать, что не затронуты другие участки функциональности. 2) В ситуации с добавлением новой функциональности или урезанием или удалением старой функциональности. При выходе новой версии, тестировщик обязан прогнать весь набор тест-кейсов, чтобы гарантировать, что не затронуты другие участки функциональности. 3) В ситуации с выходом новой версии, даже если в системе не осталось "неисправленных" дефектов и не была добавлена новая функциональность или же урезана или удалена старая функциональность, тестировщик обязан прогнать весь набор тест-кейсов, чтобы гарантировать, что система работоспособна и отвечает требованиям заказчика. В данных примерах не точно указано и не все ситуации указаны, когда применяется и как это выглядит
Вот мое предсавление об этом:

Regression testing

Общее представление

Это тестирование, которое проводится при втором и последующих тестирований
версий продукта вплоть до релиза. Сам термин следует понимать, как “повторное
тестирование”, тоесть, что есть “повтор” - повтор это действие, которое
проводиться 2 и более раз.

Когда применяется

1) После того, как программист исправил дефект (ы)
2) После добавления новой функциональности (например, в случае с change request)
или с урезанием или полным удалением старой функциональности.
3) С выходом новой версии.

С какой целью применяется

1) В ситуации с исправленным дефектом, тестировщик проводит проверку дефекта. При
проверки, он обязан удостовериться, что дефект исправлен корректно, а именно:
согласно System Requirements по данной функциональности.

2) В ситуации с добавлением новой функциональности, тестировщик обязан
удостовериться, что при добавлении новой функциональности не были повреждены
участки старой функциональности.

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

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

Как это выглядит

1) В ситуации с исправленным дефектом. При выходе новой версии. Тестировщик
обязан проверить дефект (ы) на корректность исправления. ? прогнать
весь набор тест-кейсов, чтобы гарантировать, что не затронуты другие участки
функциональности.

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

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

]]>