Корреляция между проверкой работоспособности и регрессионным тестированием
После прочтения многих постов о тестировании на дым и психическое здоровье, в которых ни одно из них не содержало четкого описания, я сделал следующие выводы о порядке тестирования:
Дымовое тестирование (общая проверка работоспособности)--- затем -> Проверка работоспособности (проверка некоторых основных функций на несколько более глубокий уровень)(Специализированная проверка работоспособности)----------------then--------> Функциональное тестирование (полная проверка функциональности на более глубоких уровнях)
Во многих постах я читал, что здравомыслие - это подмножество регрессионного тестирования. Но согласно вышеупомянутому порядку кажется, что здравомыслие является подмножеством функционального тестирования. Кто-нибудь может уточнить, насколько здравомыслие является подмножеством регрессионного тестирования?
3 ответа
Функциональное тестирование. Функциональное тестирование включает тестирование черного ящика. Тестер определяет, где разработанный продукт возвращает правильные выходные данные для использованных правильных входных данных.
Регрессионное тестирование - Регрессионное тестирование гарантирует, что все функции работают должным образом после любого обновления или модификации.
Проверка работоспособности. Проверка работоспособности - это проверка на уровне поверхности, при которой тестировщик проверяет, что все меню, функции, команды, доступные в продукте и проекте, работают нормально.
Тестирование работоспособности выполняется, когда команде разработчиков необходимо узнать быстрое состояние продукта после того, как они внесли изменения в код, такие как состояние исправленной ошибки или реализовали какую-либо функцию.
Нет необходимости выполнять исправление для каждой сборки, но рекомендуется выполнить ее вместе с повторным тестированием неисправных проблем в новой сборке.
Когда программное обеспечение изменяется…. Цикл тестирования
Повторное тестирование -> Санитарное тестирование -> Регрессионное тестирование
Для проверки работоспособности тестер может извлечь тестовые наборы из набора регрессионных тестов. Основное внимание уделяется тому, чтобы у программного обеспечения / сборки не было серьезных проблем с блокировкой для начала регрессионного тестирования. Регрессионное тестирование находится на более глубоком уровне, который занимает больше времени, чем тестирование работоспособности.
Таким образом, мы не можем соотнести между sanity testing а также regression testing.Smoke testing сделано с основными / критическими функциями. Если у вас есть 5 дней жизненного цикла для любой функции, то вы можете потратить 1/2 дня на smoke testingЭто означает, что если в ваших базовых / критических функциях слишком много ошибок, вы не сможете перейти к дальнейшему тестированию.
В sanity testing мы берем некоторые функции, углубляемся и проводим тестирование этих функций. Это глубокое и узкое тестирование.
тогда как в regression testing Вы проводите тестирование на той функции, которая уже была протестирована. когда выйдет новая сборка, это повлияет на старые функции или сборку, которая появится в будущем. Тестирование неизмененных функций, чтобы убедиться, что оно не сломано из-за изменений / Вызывается повторное выполнение одних и тех же тестовых случаев в разных выпусках или циклах тестирования regression testing
Тестирование здравомыслия:
Sanity Testing является подмножеством регрессионного тестирования.
Всякий раз, когда код развертывается, мы проверяем, повторно тестируем ли ошибки, и проводим поверхностный уровень, проверяя, все ли значки, кнопки, вкладки присутствуют и работают ли они нормально или нет, и никаких дальнейших проблем не возникает из-за этих изменений.
Целью тестирования Sanity является не тестирование новой функциональности, а установление того, что разработчик применил некоторую рациональность (здравомыслие) при создании программного обеспечения. Например, если ваш научный калькулятор дает результат 2 +3=5! Тогда нет смысла тестировать расширенные функции, такие как sin 30 + cos 50
Регрессионное тестирование
Регрессионное тестирование проводится для каждого выпуска вместе с функциональными элементами, чтобы проверить, не влияет ли новая сборка кода на существующие функциональные возможности.