Тестовая документация. Отчет о прохождении тестов.дпо_ЦЗН

Тестовая документация. Отчет о прохождении тестов.дпо_ЦЗН

Просмотрите все вопросы и варианты бесплатно. Правильные ответы скрыты и открываются только после получения доступа.

50 вопросов Вариант 1 Доступ 7 дней
Содержание теста

Вопросы и варианты

Без отметок и подсказок к правильным ответам

Вопрос 1

Тестирование black box проводится:

  1. без доступа к коду системы
  2. без знания внутренних механизмов работы системы
  3. опирается на внешние проявления работы системы
  4. с доступом к коду системы
Вопрос 2

Ключевые преимущества grey box тестирования:

  1. функциональное тестирование ПО полностью имитирует фактическое использование системы
  2. позволяет своевременно выявить системные ошибки ПО
  3. экономия за счет исправления ошибок на более раннем этапе жизненного цикла ПО
  4. позволяет найти множества проблем при работе с ПО в дальнейшем
Вопрос 3

Проводится анализ исходных документов о системе, при:

  1. подготовке
  2. проведении
  3. отчете
  4. регрессионном тестировании
Вопрос 4

Функциональное тестирование ведется вручную по подготовленным заранее тестовым сценариям с занесением всех найденных ошибок в багтрекинговую систему, при:

  1. подготовке
  2. проведении
  3. отчете
  4. регрессионном тестировании
Вопрос 5

Происходит разработка и согласование отчетов о проведенном тестировании со списком обнаруженных отклонений и рекомендациями по улучшению системы, при:

  1. проведении
  2. подготовке
  3. отчете
  4. регрессионном тестировании
Вопрос 6

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

  1. подготовке
  2. проведении
  3. отчете
  4. регрессионном тестировании
Вопрос 7

Оценка уязвимости ПО к различным атакам и попыткам несанкционированного доступа к данным – это:

  1. тестирование безопасности
  2. системное тестирование
  3. тестирование мобильных приложений
  4. тестирование установки
Вопрос 8

Проверка соответствия ПО требованиям, заявленным в спецификации– это:

  1. тестирование безопасности
  2. системное тестирование
  3. тестирование мобильных приложений
  4. тестирование установки
Вопрос 9

Выявление дефектов в работе графического интерфейса– это:

  1. тестирование безопасности
  2. системное тестирование
  3. тестирование мобильных приложений
  4. тестирование установки
Вопрос 10

Тестирование процесса инсталляции/деинсталляции программного обеспечения – это:

  1. тестирование безопасности
  2. системное тестирование
  3. тестирование мобильных приложений
  4. тестирование установки
Вопрос 11

Проверка работы ПО на различных программных и аппаратных окружениях – это:

  1. конфигурационное тестирование
  2. интеграционное тестирование
  3. smoke-тестирование
  4. тестирование документации
Вопрос 12

Тестирование взаимодействий между компонентами системы и между несколькими системами– это:

  1. конфигурационное тестирование
  2. интеграционное тестирование
  3. smoke-тестирование
  4. тестирование документации
Вопрос 13

Короткий цикл тестов для выявления правильной работы основных функций приложения– это:

  1. конфигурационное тестирование
  2. интеграционное тестирование
  3. smoke-тестирование
  4. тестирование документации
Вопрос 14

Проверка документов на соответствие принятым стандартам, а также соответствие определенным характеристикам– это:

  1. конфигурационное тестирование
  2. интеграционное тестирование
  3. smoke-тестирование
  4. тестирование документации
Вопрос 15

Автоматизированные регрессионные тесты имеют ключевые преимущества:

  1. значительное сокращение количества дефектов в системе к моменту релиза
  2. исключение деградации качества системы при росте функциональности
  3. уменьшение вероятности критических ошибок в опытно-промышленной эксплуатации
  4. приводят к уменьшению качества системы при росте функциональности
Вопрос 16

Основные этапы регрессионных тестов

  1. верификационные тесты
  2. регрессионные тесты
  3. регресс на исправленных ошибках
  4. smoke тестирование
Вопрос 17

Интеграционное тестирование позволяет:

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

Анализ исходных документов о системе включает:

  1. функциональные и бизнес-требования
  2. техническое задание
  3. паспорт проекта
  4. прототипы дизайнов проекта
Вопрос 19

Интеграционное тестирование гарантирует сразу несколько преимуществ:

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

Smoke-тестирование (дымовое тестирование) ставит задачу:

  1. выявить дефекты сразу после сборки ПО
  2. оценки устойчивости системы к противоправным действиям
  3. ускорения начала процесса тестирования рекомендуется воспользоваться разработкой эмуляторов внешних систем
  4. Оценки плотности покрытия системы тестами
Вопрос 21

Системное тестирование предназначено для:

  1. тестирования готового ПО в том состоянии, в котором оно будет внедряться в опытно-промышленную эксплуатацию
  2. создания нового ПО или при его изменении в связи с развитием бизнеса
  3. выявления дефектов сразу после сборки ПО
  4. оценки устойчивости системы к противоправным действиям
Вопрос 22

Тестирование документации предназначено для:

  1. тестирования готового ПО в том состоянии, в котором оно будет внедряться в опытно-промышленную эксплуатацию
  2. создания нового ПО или при его изменении в связи с развитием бизнеса
  3. выявления дефектов сразу после сборки ПО
  4. оценки устойчивости системы к противоправным действиям
Вопрос 23

Дымовое тестирование предназначено для:

  1. тестирования готового ПО в том состоянии, в котором оно будет внедряться в опытно-промышленную эксплуатацию
  2. создания нового ПО или при его изменении в связи с развитием бизнеса
  3. выявления дефектов сразу после сборки ПО
  4. оценки устойчивости системы к противоправным действиям
Вопрос 24

Тестирование безопасности проводится для:

  1. тестирования готового ПО в том состоянии, в котором оно будет внедряться в опытно-промышленную эксплуатацию
  2. создания нового ПО или при его изменении в связи с развитием бизнеса
  3. выявления дефектов сразу после сборки ПО
  4. оценки устойчивости системы к противоправным действиям
Вопрос 25

Тестовый отчет (или тест) содержит информацию о следующем:

  1. кто, на какой версии и в каком контексте (сервер, браузер и т.п.), выполнил шаги тестовых сценариев
  2. какие были получены результаты тестирования
  3. какие дефекты были зарегистрированы при тестировании
  4. понравилось ли пользователю приложение
Вопрос 26

В разделах с общей информацией тест-плана можно фиксировать:

  1. требования к окружению
  2. перечень реквизита
  3. период тестирования
  4. тестовые сценарии
Вопрос 27

Для разработки тестовых сценариев и выполнения тестов используются системы управления тестированием:

  1. существенно повышающие производительность тест-дизайнеров
  2. обеспечивающие видимость уровня качества приложений среди всех участников проекта
  3. существенно повышающие производительность тестировщиков
  4. уменьшающие стоимость тестирования
Вопрос 28

Автоматизация тестирования позволяет:

  1. высвободить ресурсы для проведения более сложных видов тестирования
  2. снизить количество дефектов, доходящих до стадии контроля качества
  3. ускорить выпуск релизов
  4. уменьшить стоимость тестирования
Вопрос 29

Тестируется минимально возможный для тестирования компонент, например, отдельный класс или функция:

  1. тестирование компонентов
  2. интеграционное тестирование
  3. системное тестирование
  4. альфа-тестирование
Вопрос 30

Тестируются интерфейсы между компонентами, подсистемами или системами:

  1. тестирование компонентов
  2. интеграционное тестирование
  3. системное тестирование
  4. альфа-тестирование
Вопрос 31

Тестируется интегрированная система на её соответствие требованиям:

  1. тестирование компонентов
  2. интеграционное тестирование
  3. системное тестирование
  4. альфа-тестирование
Вопрос 32

Имитация реальной работы с системой штатными разработчиками, либо реальная работа с системой потенциальными пользователями/заказчиком:

  1. тестирование компонентов
  2. интеграционное тестирование
  3. системное тестирование
  4. альфа-тестирование
Вопрос 33

Бета-тестирование — в некоторых случаях выполняется:

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

Трассировка тестовой документации на требования используется для следующих задач:

  1. вычисления процента покрытия требований тестовой документацией
  2. отслеживания изменений в требованиях
  3. отображения изменений в требованиях в тестовой документации
  4. тестирования компонентов
Вопрос 35

Бейзлайны тест-планов:

  1. создаются перед внесением изменений
  2. позволяют хранить текст сценариев
  3. нужны для проверки функциональности предыдущих версий
  4. используются для распространения предварительной версии с ограничениями по функциональности работы
Вопрос 36

График разработки тестовой документации отражает сходимость тест-дизайна:

  1. количество разделов в работе
  2. в стадии готовности
  3. на согласовании
  4. итоги прохождения тестов
Вопрос 37

Если команда работает с первичными требованиями, то поддержка тестовой документации в актуальном состоянии осуществляется при помощи дерева функций:

  1. импакт-мэппинга
  2. стори-мэппинга
  3. эпиков
  4. фейлов
Вопрос 38

Этап Обнаружен (Submitted):

  1. тестировщик нашел баг
  2. дефект успешно занесен в систему
  3. дефект может и не считаться дефектом или считаться неактуальным дефектом
  4. состоялось «рождение» дефекта в QA-мире
Вопрос 39

Этап Новый (New):

  1. тестировщик нашел баг
  2. дефект успешно занесен в систему
  3. дефект может и не считаться дефектом или считаться неактуальным дефектом
  4. состоялось «рождение» дефекта в QA-мире
Вопрос 40

Этап Отклонен (Declined):

  1. тестировщик нашел баг
  2. дефект успешно занесен в систему
  3. дефект может и не считаться дефектом или считаться неактуальным дефектом
  4. состоялось «рождение» дефекта в QA-мире
Вопрос 41

Этап Отложен (Deferred):

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

Этап Открыт (Opened):

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

Этап Исправлен (Fixed):

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

Этап Проверен (Verified):

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

Ошибка, которая приводит программу в нерабочее состояние:

  1. Blocker
  2. Critical
  3. Major
  4. Trivial
Вопрос 46

Критический дефект, приводящий некоторый ключевой функционал в нерабочее состояние:

  1. Blocker
  2. Critical
  3. Major
  4. Trivial
Вопрос 47

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

  1. Blocker
  2. Critical
  3. Major
  4. Trivial
Вопрос 48

Баг, не имеющий влияние на функционал или работу программы, но который может быть обнаружен визуально:

  1. Blocker
  2. Critical
  3. Major
  4. Trivial
Вопрос 49

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

  1. Blocker
  2. Critical
  3. Major
  4. Minor
Вопрос 50

Градация дефектов, с точки зрения приоритетности исправления:

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