January
У вас не случалось такого: закончили проект, во время активного использования обраружили пару багов, исправили, заодно и пару функций добавили, а потом через некоторое время обнаружили, что код, с которым раньше не было проблем, нормально не работает?
По достоверным данным кол-во ошибок после изменения кода (будь-то добавление новой функциональности или же исправление багов) составляет около 50%. Для того, чтобы выявить эти ошибки, и нужно регрессионное тестирование (regression test).
Перечислю основные виды тестов регрессии в порядке их важности (обычно в таком порядке их и выполняют).
1. Тесты верификации версии (Build Verification Test). Нужны эти тесты для проверки основной функциональности каждой версии программы. Только будучи уверенным в том, что основная функциональность программы не нарушена, можно спать спокойно. При нахождении ошибки с помощью таких тестов необходимо пересмотреть соответствующую часть кода на предмет ошибок.
2. Тесты верификации багов (Bug Verification Test). Если некоторый тест выявил баг, необходимо после исправления провести этот тест еще раз. Хотя проведение этих тестов и является логичным, многие программисты пренебрегают такого вида тестированием.
3. Тесты регрессии (Regression Test Pass). К этим тестам относятся те, которые уже проводились с предыдущими версиями софта и не выявляли ошибок. пногда при отсутствии времени некоторые из тестов можно пропустить (желательно только тогда, когда не были внесены изменения в соответствующие участки кода). Если ранее такие тесты уже проводились более 3 раз, процесс неплохо было бы автоматизировать.
4. Тесты регрессии на исправленных багах (тесты на закрытых багах). Что такое закрытые баги можно понять из примера. Пусть некоторый тест нашел ошибку. После исправления этот же тест ошибки не обнаружил. В этом случае баг и называется “закрытым”. Баг может проявится снова по ряду причин (особенно при модификации кода). Поэтому время от времени нужно возвращаться к этому месту программы.
В крупных фирмах при проведении регрессионного тестирования часто создают таблицы вида “номер теста - версия программы 1 - номер бага - версия 2 - … - версия N - номер бага”.
Регрессионное тестирование поможет вашей программе всегда оставаться на высоте.
1 Comment »
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) В ситуации с выходом новой версии, даже если в системе не осталось
“неисправленных” дефектов и не была добавлена новая функциональность или же
урезана или удалена старая функциональность, тестировщик обязан прогнать
весь набор тест-кейсов, чтобы гарантировать, что система работоспособна и
отвечает требованиям заказчика.
