Тесты СинергияАртём Хелп
Артём Help онлайнПолучить расчёт
Бесплатно оценим сроки и стоимостьОтправить задание в Telegram
Тестовая документация. Тест-план, тест-дизайн. Отчет о прохождении тестов.ДРБ_С по тест

Тестовая документация. Тест-план, тест-дизайн. Отчет о прохождении тестов.ДРБ_С по тест

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

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

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

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

Вопрос 1

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

  1. работоспособное состояние
  2. неработоспособное состояние
  3. исправное состояние системы
  4. неисправное состояние системы
Вопрос 2

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

  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. долговечность
  4. сохраняемость
Вопрос 12

Свойство системы сохранять значения показателей безотказности и ремонтопригодности в течение и после срока хранения и транспортировки:

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

В качестве технических требований на разработку надежного ПО рекомендуются следующие критерии:

  1. корректность программного обеспечения
  2. обслуживаемость системы
  3. безотказность системы
  4. долговечность системы
Вопрос 14

Число серьезных ошибок в программе и время, необходимое для их устранения - это:

  1. корректность программного обеспечения
  2. обслуживаемость системы
  3. безотказность системы
  4. ремонтопригодность системы
Вопрос 15

Степень влияния ошибок программного обеспечения на обслуживаемость системы – это:

  1. корректность программного обеспечения
  2. обслуживаемость системы
  3. безотказность системы
  4. ремонтопригодность системы
Вопрос 16

Частота системных отказов, вызываемых ошибками программного обеспечения

  1. корректность программного обеспечения
  2. обслуживаемость системы
  3. безотказность системы
  4. ремонтопригодность системы
Вопрос 17

Функция от самой программы и от того, что ждёт от неё пользователь– это:

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

вероятность того, что программа какой-то период времени будет работать без сбоев с учетом степени их влияния выходные результаты– это:

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

Функция от ущерба, наносимого ошибкой пользователя– это:

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

Обычные программы, средние значения MTBF для устойчи¬вых отказов:

  1. 10^2—10^3
  2. 10^3-10^4
  3. 10^6— 10^s
  4. 10^1-10^3
Вопрос 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

Введение стандартов в процесс создания программного изделия направлено на достижение следующих результатов:

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

В стандартах ЕСПД устанавливаются требования, которые обеспечивают возможность:

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

В состав ЕСПД входят:

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

Часть программы, допускающая автономную трансляцию – это:

  1. программный модуль
  2. программный сегмент
  3. подпрограмма
  4. программное изделие
Вопрос 42

часть программы, которая может выполняться, не требуя нахождения в оперативной памяти остальных частей– это:

  1. программный модуль
  2. программный сегмент
  3. подпрограмма
  4. программное изделие
Вопрос 43

часть программы, выделяемая в целях сокращения записи программы и выполняющая четко определённую функцию – это:

  1. программный модуль
  2. программный сегмент
  3. подпрограмма
  4. программное изделие
Вопрос 44

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

  1. программный модуль
  2. программный сегмент
  3. подпрограмма
  4. программное изделие
Вопрос 45

Состав программы и документации на неё – это:

  1. спецификация
  2. ведомость держателей подлинников
  3. текст программы
  4. описание программы
Вопрос 46

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

  1. спецификация
  2. ведомость держателей подлинников
  3. текст программы
  4. описание программы
Вопрос 47

Запись программы с необходимыми комментариями– это:

  1. спецификация
  2. ведомость держателей подлинников
  3. текст программы
  4. описание программы
Вопрос 48

Сведения о логической структуре и функционирование программы – это:

  1. спецификация
  2. ведомость держателей подлинников
  3. текст программы
  4. описание программы
Вопрос 49

Схема алгоритма, общее описание алгоритма и функционирования программы – это:

  1. пояснительная записка
  2. эксплуатационные документы
  3. текст программы
  4. описание программы
Вопрос 50

Сведения для облегчения функционирования и эксплуатации программы– это:

  1. пояснительная записка
  2. эксплуатационные документы
  3. текст программы
  4. описание программы
Вопрос 51

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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