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

Тестирование документации и требований.дпо

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

50 вопросов Вариант 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. 10 – 20%
  2. 20 – 30%
  3. 30 – 40%
  4. 40 – 50%
Вопрос 7

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

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

Эксплуатационная документация программного продукта включает:

  1. подробные технические описания
  2. развития и корректировки ими программ и данных
  3. средства для решения конкретных функциональных задач систем
Вопрос 9

Основная задача включает:

  1. фиксировании всего жизненного цикла ПС
  2. полноценном использовании функционировании объектов
  3. обобщении результатов функционировании объектов и процессов
  4. возможность корректного использования ПС за пределами условий эксплуатации
Вопрос 10

Малый масштаб:

  1. до 50 тысяч строк
  2. до 100 тысяч строк
  3. до 300 тысяч строк
  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

В стандарте ISO 12182 установлена схема классификации, помогающая:

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

Процесс для записи информации, произведенной процессами жизненного цикла – это:

  1. Процесс документирования
  2. Реализация процесса
  3. Проектирование и разработка
  4. Производство
Вопрос 20

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

  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

Цель тестирования документации:

  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. Функциональное тестирование