Функциональное и регрессионное тестирование: как не дать багам вернуться
Функциональное тестирование нужно, чтобы быть уверенным: программа делает ровно то, что обещает. Особенно это важно, если в код вносят изменения — чтобы не сломалось то, что уже работало. Это и есть регрессионное тестирование.
В этой статье мы детально разберём тестовое задание среднего уровня. Пошагово объясним каждый вопрос и покажем, как такие задачи встречаются в работе тестировщика с небольшим опытом. Это полезно, если хочешь расти с джуна до мидла.
Вопрос 1. Выберите верное утверждение о тестировании методом черного ящика.
1. Метод черного ящика используется для проверки только функциональных требований
2. Метод черного ящика применяется на всех уровнях тестирования
3. Метод черного ящика выполняется только с использованием автоматизированного тестирования
4. Для выполнения тестирования методом черного ящика требуется детальное знание внутренней структуры тестируемой программы
5. Базисом для тестирования методом черного ящика является код программы
Объяснение:
Метод черного ящика — это когда тестировщик не знает, как программа устроена внутри, и проверяет только входы и выходы.
Он может использоваться на всех уровнях тестирования:
Ему не нужен код программы (это база для белого ящика), не нужно детальное знание внутренностей.
И он точно не выполняется только автоматизировано — его можно проводить и вручную.
Также он не ограничен только функциональными требованиями, можно проверять и нефункциональные характеристики (например, корректность сообщений об ошибках).
«Не важно, тестируешь ты кусочек кода или всю систему, если смотришь только на вход и выход, а не в потроха — это черный ящик, и он работает везде.»
Выбранный ответ:
Метод черного ящика применяется на всех уровнях тестирования.
Вопрос 2. Кем выполняется бета-тестирование программы?
2. Членами команды тестирования, которые проводили альфа-тестирование программы
3. Членами команды тестирования, которые не участвовали в альфа-тестировании программы
4. Ограниченным кругом пользователей
5. Лицами, не имеющими опыта работы с подобным ПО
Объяснение:
Бета-тестирование — это когда программа уже вышла за пределы команды разработки и тестирования, и её дают попробовать реальным пользователям, но пока ещё в ограниченных масштабах.
Это нужно, чтобы собрать отзывы и найти баги, которые не заметили внутри компании.
- Альфа-тестирование обычно проводится самой командой разработки или QA.
- Бета-тестирование — следующая стадия, на ней участвуют ограниченный круг пользователей, которые тестируют программу в реальных условиях.
«На альфе проверяют сами, а на бете дают посмотреть друзьям, которые уже не в семье, но ещё не весь мир.»
Выбранный ответ: Ограниченным кругом пользователей.
Вопрос 3. Кем, как правило, должно выполняться компонентное тестирование?
2. Специалистами по ручному тестированию
3. Специалистами по автоматизированному тестированию
4. Специалистами по нагрузочному тестированию
Объяснение:
Компонентное (или модульное) тестирование — это проверка отдельных маленьких частей программы (функций, классов, модулей) изолированно от всей системы.
Такое тестирование чаще всего выполняют разработчики, потому что они лучше всех знают код этих модулей и могут быстро написать для них юнит-тесты.
- Системные аналитики занимаются требованиями, а не проверкой кода.
- Специалисты по ручному тестированию обычно проверяют интеграцию и систему в целом.
- Автоматизаторы больше занимаются автотестами для UI, API, нагрузкой — но именно компонентные юнит-тесты чаще всего пишут сами разработчики.
- Нагрузочное тестирование — вообще отдельная история, не про модули.
«Компоненты пишет разработчик, и тесты для них он же обычно сразу и делает.»
Выбранный ответ: Разработчиками.
Вопрос 4. На каком из перечисленных уровней тестирования чаще всего требуется применение заглушек, драйверов и эмуляторов?
3. Нефункциональное тестирование
4. Интеграционное тестирование
5. Функциональное тестирование
Объяснение:
Заглушки (stubs), драйверы и эмуляторы нужны тогда, когда у нас ещё не все части системы готовы, а тестировать взаимодействие уже надо.
Это как если бы у тебя ещё нет настоящей кассы в магазине, но ты хочешь проверить, как работает программа заказа — тогда ставишь вместо кассы «муляж».
Такое чаще всего бывает на интеграционном тестировании, когда проверяют, как модули или системы взаимодействуют друг с другом, но каких-то реальных компонентов ещё нет, поэтому их подменяют заглушками или эмуляторами.
- Приёмочное и системное тестирование идут уже ближе к концу, когда всё собрано.
- Нефункциональное — это про скорость, надёжность и т.д., там обычно не ставят заглушки.
- Функциональное — это что тестируем, а не уровень (может быть и на модульном, и на интеграционном, и на системном).
«Интеграция — это когда проверяют стыковку, а для стыковки часто нужно временно поставить заглушки.»
Выбранный ответ: Интеграционное тестирование.
Вопрос 5. Какое тестирование позволяет проверить реакцию системы на ввод некорректных данных?
1. Тестирование производительности
2. Конфигурационное тестирование
3. Тестирование удобства использования
4. Тестирование устойчивости и надежности
Объяснение:
Когда мы специально вводим в систему всякие неправильные данные — чтобы посмотреть, не упадёт ли она, не сломается ли, а выдаст понятную ошибку — это называется негативное тестирование (или тестирование на устойчивость к ошибкам ввода).
Формально в стандартных классификациях это входит в тестирование устойчивости и надёжности (robustness testing), потому что цель — проверить, насколько система спокойно выдерживает ошибки пользователя или некорректные данные.
- Тестирование производительности — проверяет скорость.
- Конфигурационное — на разных ОС, браузерах и т.д.
- Тестирование удобства — насколько приятно пользоваться.
- Нагрузочное — сколько пользователей одновременно выдержит.
«Мы специально портим данные, чтобы убедиться, что программа не сломается. Это и есть проверка устойчивости.»
Выбранный ответ: Тестирование устойчивости и надёжности.
Вопрос 6. Какое из перечисленных утверждений верно?
1. Тестовые данные можно не задавать специально, а выбирать любые
2. Тестовые данные необходимо варьировать
3. Тестовые данные следует получать только у заказчика
4. Тестовые данные создаются исключительно специальными инструментами - генераторами тестовых данных
5. Тестовые данные варьируются только в случае радикального изменения требований
Объяснение:
Тестовые данные — это данные, на которых мы проверяем работу программы. Чтобы действительно проверить все возможные сценарии (нормальные, граничные, ошибочные), их нужно обязательно варьировать.
- Если всегда проверять на одинаковых данных, можно не найти баги, которые проявляются только при других значениях.
- Их не всегда берут у заказчика — часто тестировщики готовят их сами.
- Генераторы помогают, но тестовые данные можно (и нужно) создавать вручную тоже.
- А уж «можно выбрать любые» — совсем неправда, тогда теряется смысл тестирования.
- Не ждут «радикального изменения требований», чтобы начать варьировать данные — их варьируют всегда.
«Если тестировать только на одной фамилии Иванов, можно не заметить, что программа падает на фамилии из трёх слов. Поэтому данные надо всегда менять.»
Выбранный ответ: Тестовые данные необходимо варьировать.
Вопрос 7. Тестировщик выполняет быструю проверку, чтобы убедиться, что изменённые или добавленные функции работают нормально. К какому виду тестирования это относится?
1. Тестирование структуры/архитектуры программного обеспечения
2. Функциональное тестирование
3. Тестирование нефункциональных характеристик
Объяснение:
Такое быстрое поверхностное тестирование после внесения изменений в код называют санитарным тестированием (smoke testing). Его задача — убедиться, что «система вообще запускается и не падает», и что самые базовые функции после изменений не сломаны.
- Это не тестирование архитектуры — там смотрят структуру программы.
- Не приёмочное — его делает заказчик для принятия всего продукта.
- Не тестирование нефункциональных характеристик — это про скорость, надёжность, безопасность.
- И даже не просто функциональное в целом — оно обычно глубже и полнее, чем санитарное.
«Санитарное тестирование — это как понюхать молоко, чтобы понять, можно ли его пить, прежде чем налить в кофе.»
Выбранный ответ: Санитарное тестирование.
Вопрос 8. В каком случае следует проводить повторное тестирование исправленных дефектов (подтверждающее тестирование)?
1. Только во время дымового тестирования (проверки общей работоспособности и стабильности новой сборки)
2. Для каждой новой сборки, переданной на тестирование
3. Только при проведении регрессионного тестирования
4. В период проведения приемочного тестирования
5. При передаче продукта в эксплуатацию
Объяснение:
Подтверждающее тестирование (confirmation testing, иногда говорят retesting) — это когда тестировщик повторно запускает тесты, чтобы убедиться: исправленный баг действительно устранён.
Его проводят для каждой новой сборки, где эти исправления должны появиться, чтобы проверить, что дефект закрыт.
Это не связано напрямую с регрессионным тестированием (там проверяют, не сломалось ли что-то другое), не только в дымовом, не только в приёмочном и не только при вводе в эксплуатацию.
И уж точно не «только тогда» — а всегда, когда поступила новая сборка с исправлением.
«Если починили кран, надо снова открыть воду и проверить, не течёт ли. Каждый раз, как после ремонта.»
Выбранный ответ: Для каждой новой сборки, переданной на тестирование.
Вопрос 9. Что из перечисленного является целью дымового тестирования?
1. Быстрая проверка исправленных дефектов
2. Быстрое определение работоспособности стабильной сборки
3. Краткая проверка надежности системы
4. Краткая проверка работоспособности нового функционала
5. Определение работоспособности новой сборки системы
Объяснение:
Дымовое тестирование (smoke testing) — это поверхностная проверка работоспособности новой сборки системы, чтобы понять:
Оно не нацелено на проверку исправленных багов (это подтверждающее), не тестирует глубоко надёжность, не фокусируется на новом функционале в отдельности.
Просто проверяет: «Не загорится ли?»
«Дымовое тестирование — это как быстро включить прибор и посмотреть, не идёт ли из него дым.»
Выбранный ответ: Определение работоспособности новой сборки системы.
Вопрос 10. Какое минимальное количество тестовых сценариев требуется для покрытия всех действительных классов эквивалентности для расчета бонуса?
Объяснение:
Здесь используется техника эквивалентного разбиения, где каждый диапазон значений, который программа обрабатывает одинаково, считается отдельным классом эквивалентности.
В задаче явно даны такие классы:
Это значит, у нас 4 класса эквивалентности, для покрытия которых нужно как минимум 4 теста, по одному примеру из каждого диапазона.
Чтобы объяснить для простого понимания:
«Если есть четыре группы стажа для начисления бонуса, значит нужно хотя бы четыре теста, по одному на каждую группу, чтобы проверить все правила.»
Вопрос 11. Какой будет набор тестовых данных для анализа граничных значений?
Объяснение:
Тут важны «границы», на которых поведение системы меняется.
По условиям задачи:
Для анализа граничных значений выбирают числа на границах и сразу вокруг них:
Это значит, что нужны скорости около 40, 60 и 80, то есть:
- 39, 40, 41 — для перехода между «ничего» и «предупреждение»,
- 59, 60, 61 — для перехода «предупреждение» → «штраф»,
- 79, 80, 81 — для перехода «штраф» → «лишение».
«Мы специально берём числа прямо на границах и рядом, чтобы проверить, не ошибётся ли программа на переходах между режимами.»
Выбранный ответ: 39, 41, 59, 61, 79, 81.
Вопрос 12. Какой из наборов тестовых входных данных обеспечивает покрытие эквивалентного разбиения?
1. 1000, 2001, 4000, 4001, 6000
2. 123, 2345, 3456, 4567, 5678
3. 999, 1001, 1999, 2001, 6001
4. 666, 1999, 2222, 5555, 6666
Объяснение:
Эквивалентное разбиение — это когда тестовые данные выбираются так, чтобы каждая группа, где система ведёт себя одинаково, была проверена хотя бы одним значением.
По условию задачи у нас 5 диапазонов:
Нужно взять по одному числу из каждого диапазона.
999, 1001, 1999, 2001, 6001 охватывает:
· 1999 (1001–2000, дублирует диапазон)
Этот набор слегка избыточен (есть два значения для одного диапазона), но всё равно перекрывает все классы, включая верхний свыше 6000.
Все другие варианты либо пропускают какой-то диапазон, либо повторяют диапазоны, не охватывая весь спектр.
«Берём по одному примеру для каждого диапазона, чтобы проверить все ответы программы.»
Выбранный ответ: 999, 1001, 1999, 2001, 6001.
Вопрос 13. Какую информацию тестировщик может НЕ включать в баг-репорт?
1. Серьезность, если есть приоритет
4. Приоритет, если есть серьезность
Объяснение:
В баг-репорте всегда важно указать:
- шаги воспроизведения — чтобы разработчик понял, как повторить ошибку,
- скриншоты или даже видео — чтобы наглядно показать проблему,
- серьезность (severity) и приоритет (priority) — если один из них не указан, обычно указывают другой.
А вот логи сервера приложений — это дополнительная техническая информация, которая чаще всего не обязательна для UI-багов. Тестировщики могут их приложить, но для дефекта, когда «нельзя нажать кнопку» или «не тот текст на экране», обычно хватает интерфейсной информации.
«Если на экране криво отображается кнопка, достаточно скриншота и описания. Логи сервера тут могут вообще не помочь.»
Выбранный ответ: Логи сервера приложений.
Вопрос 14. В каком случае тест-кейсы выполняются как регрессионные?
1. В первом прогоне тест-кейс пройден со статусом "Fail" (Провален), и во втором прогоне - со статусом "Fail" (Провален)
2. В первом прогоне тест-кейс пройден со статусом "Pass" (Пройден), а во втором прогоне тест-кейс не выполнялся
3. В первом прогоне тест-кейс пройден со статусом "Fail" (Провален), а во втором прогоне - со статусом "Pass" (Пройден)
4. В первом прогоне тест-кейс пройден со статусом "Pass" (Пройден), и во втором прогоне - со статусом "Pass" (Пройден)
5. В первом прогоне тест-кейс не выполнялся, а во втором прогоне - со статусом "Pass" (Пройден)
Объяснение:
Регрессионное тестирование — это когда мы заново прогоняем уже ранее проходившие тест-кейсы, чтобы убедиться: новые изменения не поломали старый рабочий функционал.
Обычно:
- в первом прогоне всё работало (Pass),
- потом разработчики внесли изменения,
- и во втором прогоне тестировщик снова запускает те же тесты, чтобы убедиться, что ничего не сломалось.
В первом прогоне тест-кейс пройден со статусом "Pass" (Пройден), и во втором прогоне — со статусом "Pass" (Пройден).
«Регрессия — это когда повторяешь старый тест, чтобы убедиться, что после правок программа ведет себя так же хорошо, как раньше.»
Выбранный ответ:
В первом прогоне тест-кейс пройден со статусом "Pass" (Пройден), и во втором прогоне — со статусом "Pass" (Пройден).
Вопрос 15. Какой из тестовых сценариев будет выполняться третьим по счету?
Объяснение:
Посмотрим по зависимостям и приоритетам:
1. TC 120 — нет зависимости, можно выполнить сразу.
2. TC 245 — зависит от TC 120, значит второй.
3. После TC 245 можно запускать:
· TC 063 (высокий приоритет, зависит от TC 245),
· TC 047 (средний, тоже от TC 245),
· TC 128 (низкий, тоже от TC 245).
Из этих трёх TC 063 имеет наивысший приоритет, значит он пойдет третьим.
«Сначала выполняем TC 120, потом TC 245, а так как TC 063 зависит только от TC 245 и самый важный, то он будет третьим.»
Заключение
После разбора ты лучше поймёшь, как искать ошибки в уже знакомом функционале после доработок. Эти знания помогут не бояться более сложных задач и брать на себя ответственность за стабильность продукта — важный шаг для развития в тестировании.