Javenue logo

Javenue

Программирование на Java

Информационные технологии

Регрессионное тестирование кода (regression testing)

[Если вас интересует практический подход к регрессионному тестированию программного кода на Java - обратите внимание на подробную статью Использование библиотеки JUnit для unit-тестирования кода.]

У вас не случалось такого: закончили проект, во время активного использования обраружили пару багов, исправили, заодно и пару функций добавили, а потом через некоторое время обнаружили, что код, с которым раньше не было проблем, нормально не работает?

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

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

1. Тесты верификации версии (Build Verification Test). Нужны эти тесты для проверки основной функциональности каждой версии программы. Только будучи уверенным в том, что основная функциональность программы не нарушена, можно спать спокойно. При нахождении ошибки с помощью таких тестов необходимо пересмотреть соответствующую часть кода на предмет ошибок.

2. Тесты верификации багов (Bug Verification Test). Если некоторый тест выявил баг, необходимо после исправления провести этот тест еще раз. Хотя проведение этих тестов и является логичным, многие программисты пренебрегают такого вида тестированием.

3. Тесты регрессии (Regression Test Pass). К этим тестам относятся те, которые уже проводились с предыдущими версиями софта и не выявляли ошибок. пногда при отсутствии времени некоторые из тестов можно пропустить (желательно только тогда, когда не были внесены изменения в соответствующие участки кода). Если ранее такие тесты уже проводились более 3 раз, процесс неплохо было бы автоматизировать.

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

Теперь рассмотрим два таких набора ситуаций:

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

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

В крупных и не очень фирмах при проведении регрессионного тестирования часто используют автоматизированные тесты, которые прогоняются на тестовых серверах сразу же после деплоя новой промежуточной версии приложения, а так же после выкатки новой версии на Production сервера. Думаю, стоит посвятить теме автоматизированного тестирования отдельную статью.

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


Комментариев: 0

  Выйти

  * для публикации комментариев нужно