January
2006
У вас не случалось такого: закончили проект, во время активного использования обраружили пару багов, исправили, заодно и пару функций добавили, а потом через некоторое время обнаружили, что код, с которым рань?е не было проблем, нормально не работает?
По достоверным данным кол-во о?ибок после изменения кода (будь-то добавление новой функциональности или же исправление багов) составляет около 50%. Для того, чтобы выявить эти о?ибки, и нужно регрессионное тестирование (regression test).
Перечислю основные виды тестов регрессии в порядке их важности (обычно в таком порядке их и выполняют).
1. Тесты верификации версии (Build Verification Test). Нужны эти тесты для проверки основной функциональности каждой версии программы. Только будучи уверенным в том, что основная функциональность программы не нару?ена, можно спать спокойно. При нахождении о?ибки с помощью таких тестов необходимо пересмотреть соответствующую часть кода на предмет о?ибок.
2. Тесты верификации багов (Bug Verification Test). Если некоторый тест выявил баг, необходимо после исправления провести этот тест еще раз. Хотя проведение этих тестов и является логичным, многие программисты пренебрегают такого вида тестированием.
3. Тесты регрессии (Regression Test Pass). К этим тестам относятся те, которые уже проводились с предыдущими версиями софта и не выявляли о?ибок. пногда при отсутствии времени некоторые из тестов можно пропустить (желательно только тогда, когда не были внесены изменения в соответствующие участки кода). Если ранее такие тесты уже проводились более 3 раз, процесс неплохо было бы автоматизировать.
4. Тесты регрессии на исправленных багах (тесты на закрытых багах). Что такое закрытые баги можно понять из примера. Пусть некоторый тест на?ел о?ибку. После исправления этот же тест о?ибки не обнаружил. В этом случае баг и называется “закрытым”. Баг может проявится снова по ряду причин (особенно при модификации кода). Поэтому время от времени нужно возвращаться к этому месту программы.
В крупных фирмах при проведении регрессионного тестирования часто создают таблицы вида “номер теста - версия программы 1 - номер бага - версия 2 - … - версия N - номер бага”.
Регрессионное тестирование поможет ва?ей программе всегда оставаться на высоте.
2 Comments »
RSS feed for comments on this post. TrackBack URI
В данных примерах не точно указано и не все ситуации указаны, когда применяется и как это выглядит
Вот мое предсавление об этом:
Regression testing
Общее представление
Это тестирование, которое проводится при втором и последующих тестирований
версий продукта вплоть до релиза. Сам термин следует понимать, как “повторное
тестирование”, тоесть, что есть “повтор” - повтор это действие, которое
проводиться 2 и более раз.
Когда применяется
1) После того, как программист исправил дефект (ы)
2) После добавления новой функциональности (например, в случае с change request)
или с урезанием или полным удалением старой функциональности.
3) С выходом новой версии.
С какой целью применяется
1) В ситуации с исправленным дефектом, тестировщик проводит проверку дефекта. При
проверки, он обязан удостовериться, что дефект исправлен корректно, а именно:
согласно System Requirements по данной функциональности.
2) В ситуации с добавлением новой функциональности, тестировщик обязан
удостовериться, что при добавлении новой функциональности не были повреждены
участки старой функциональности.
2.1) В ситуации с урезанием или полным удалением старой функциональности,
тестировщик обязан удостовериться, что при урезании или полном удалении старой
функциональности не были повреждены другие участки функциональности, которые не
относились к данному исправлению (в точности урезанию или удалению).
3) В ситуации с выходом новой версии, даже если в системе не осталось
“неисправленных” дефектов и не была добавлена новая функциональность или же
урезана или удалена старая функциональность, тестировщик обязан провести
регрессионное тестирование, чтобы гарантировать, что система работоспособна и
отвечает требованиям заказчика.
Как это выглядит
1) В ситуации с исправленным дефектом. При выходе новой версии. Тестировщик
обязан проверить дефект (ы) на корректность исправления. ? прогнать
весь набор тест-кейсов, чтобы гарантировать, что не затронуты другие участки
функциональности.
2) В ситуации с добавлением новой функциональности или урезанием или удалением
старой функциональности. При выходе новой версии, тестировщик обязан прогнать
весь набор тест-кейсов, чтобы гарантировать, что не затронуты другие участки
функциональности.
3) В ситуации с выходом новой версии, даже если в системе не осталось
“неисправленных” дефектов и не была добавлена новая функциональность или же
урезана или удалена старая функциональность, тестировщик обязан прогнать
весь набор тест-кейсов, чтобы гарантировать, что система работоспособна и
отвечает требованиям заказчика.
to Bishop позволю себе не согласиться с Вами, регрессия и повтор это разные понятия. Советую прочитать стандарты. После выхода релиза тестирование не прекращается, если есть баги, поэтому при выпуске баг-фикса необходимо провести ,нет не повторное тестирование, как это напра?ивается, а проводят регрессивное т.е. возвращаются к результатам полученным при появлении бага и тестируют этот функционал, затем тестируют смежные модули.
А повторное тестирование это изменение набора тестовых значений без исправлений бага, для определения области действия.
П.С.
Статья хоро?ая.
П.С.С.
Автору на заметку - сделайте ссылки на стандарты ;).