Терминология тестирования программного обеспечения

Question

Я пытаюсь найти термин для тестирования программного обеспечения. В частности, это относится к следующему сценарию:

1. У вас есть программное обеспечение "S" версии V
2. S имеет функциональность для «свиста», «взрыва» и «зума»
3. Вы нашли ошибку с масштабированием S
4. Вы применяете патч к функции масштабирования
5. S теперь может увеличить
6. S больше не может свистеть.

Мой вопрос: Какие типы тестов специально разработаны для того, чтобы гарантировать, что исправление для определенного модуля не повредит другие модули? Это просто особый случай регрессионного тестирования? есть специальный термин для этого?

Извиняюсь, если это репост, и заранее спасибо!

Приветствия

Answer 1

Да, такая ошибка называется регрессией. А регрессионное тестирование является основным компонентом (автоматического и ручного) тестирования. Этот класс тестов часто просто возникает из-за создания тестов для новых вещей и конкретных ошибок по пути, но продолжает проверять новые сборки по всему совокупному набору тестов.

Answer 2

После добавления новых функциональных возможностей в существующий проект нам необходимо проверить влияние добавленных функциональных возможностей на существующие функциональные возможности. Это называется регрессионным тестированием.

По умолчанию: - Регрессионное тестирование - это форма тестирования программного обеспечения, которая подтверждает или отклоняет функциональность программного обеспечения после того, как программное обеспечение претерпевает изменения или усовершенствования.

Answer 3

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

Answer 4

Я иногда называю это явление "Ударить моль".

Вы исправляете одну вещь, а другая проблема возникает в другом месте.

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