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

Тестирование документации и требований. Методы и виды тестирования. Анализ требований к ПОДРБ_С по тест

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

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

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

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

Вопрос 1

Тестирование программы – это выполнение системы с целью выявления:

  1. пробелов
  2. ошибок
  3. соответствия требованиям
  4. качества работы операционной системы
Вопрос 2

Протестировать программное обеспечение возможно …

  1. в любое время в конкретный период цикла
  2. в определенное время в конкретный период цикла
  3. в определенное время в течение его цикла
  4. в любое время в течение его цикла
Вопрос 3

Своевременное начало тестирования снижает:

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

Тестирование проводится в разных формах на каждом этапе SDLC:

  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. IEEE 829
  2. IEEE 1061
  3. IEEE 1059
  4. IEEE 1008
Вопрос 19

Методология для установления требований к качеству, определения, реализации, анализа и валидации процесса и продукта метрик качества программного обеспечения:

  1. IEEE 829
  2. IEEE 1061
  3. IEEE 1059
  4. IEEE 1008
Вопрос 20

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

  1. IEEE 829
  2. IEEE 1061
  3. IEEE 1059
  4. IEEE 1008
Вопрос 21

Стандарт для модульного тестирования:

  1. IEEE 1008
  2. IEEE 1012
  3. IEEE 1028
  4. IEEE 1044
Вопрос 22

Стандарт для проверки и подтверждения программного обеспечения:

  1. IEEE 1008
  2. IEEE 1012
  3. IEEE 1028
  4. IEEE 1044
Вопрос 23

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

  1. IEEE 1008
  2. IEEE 1012
  3. IEEE 1028
  4. IEEE 1044
Вопрос 24

Стандарт для классификации программных аномалий:

  1. IEEE 1008
  2. IEEE 1012
  3. IEEE 1028
  4. IEEE 1044
Вопрос 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. Agile Model
  2. Rapid Application Development
  3. Rational Unified Process
  4. Юзабилити-тестирование
Вопрос 38

Методология быстрой разработки приложений:

  1. Agile Model
  2. Rapid Application Development
  3. Rational Unified Process
  4. Юзабилити-тестирование
Вопрос 39

Рациональный унифицированный процесс:

  1. Agile Model
  2. Rapid Application Development
  3. Rational Unified Process
  4. Юзабилити-тестирование
Вопрос 40

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

  1. Agile Model
  2. Rapid Application Development
  3. Rational Unified Process
  4. Юзабилити-тестирование
Вопрос 41

Уровня требований к ПО включают:

  1. Бизнес-требования
  2. Требования пользователей
  3. Функциональные требования
  4. Технологические требования
Вопрос 42

IEEE Standard Glossary of Software Engineering Terminology (1990) включает:

  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

Комплекс документирования ПО должен быть изложен:

  1. профессионально
  2. понятно
  3. структурировано
  4. систематически
Вопрос 52

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

  1. заказчиков
  2. пользователей
  3. разработчиков
  4. тестировщиков
Вопрос 53

Управление документацией должно непрерывно поддерживать её:

  1. полноту
  2. корректность
  3. согласованность с программным продуктом
  4. целостность
Вопрос 54

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

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

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

  1. качество создания
  2. трудоемкость создания
  3. длительность создания
  4. функциональность создания
Вопрос 56

Совокупные затраты на документирование крупных программных продуктов могут достигать от общей трудоемкости проекта

  1. 10 – 20%
  2. 20 – 30%
  3. 30 – 40%
  4. 40 – 50%
Вопрос 57

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

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

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

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

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

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

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

  1. до 50 тысяч строк
  2. до 100 тысяч строк
  3. до 300 тысяч строк
  4. один миллион строк или более
Вопрос 61

Состав и формы документов широко варьируется в зависимости от:

  1. класса объекта разработки
  2. характеристик объекта разработки
  3. используемой технологии
  4. доступного времени на разработку
Вопрос 62

Документация разработки:

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

Документация продукции:

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

Документация управления проектом включает:

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

Понятия качества документации включает:

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

Стандартизированные форматы зависят от таких факторов, как:

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

Основными ресурсами в стандарте, для документирования выделяются:

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

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

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

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

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

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

  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

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

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

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

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

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

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

Качественный программный продукт должен:

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

Надежность ПО определяет способность без сбоев выполнять заданные функции:

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

Защищенность определяет степень безопасности системы от

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

Удобство сопровождения определяет легкость, с которой обслуживается продукт в плане простоты:

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

Управление жизненным циклом программного продукта помогает разработчикам целенаправленно добиваться:

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

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

  1. Модульное тестирование
  2. Исследовательское тестирование
  3. Интеграционное тестирование
  4. Функциональное тестирование
Вопрос 97

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

  1. Модульное тестирование
  2. Исследовательское тестирование
  3. Интеграционное тестирование
  4. Функциональное тестирование
Вопрос 98

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

  1. Модульное тестирование
  2. Исследовательское тестирование
  3. Интеграционное тестирование
  4. Функциональное тестирование
Вопрос 99

Предполагает проверку конкретных требований к ПО и проводится после добавление к системе новых функций:

  1. Модульное тестирование
  2. Исследовательское тестирование
  3. Интеграционное тестирование
  4. Функциональное тестирование
Вопрос 100

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

  1. Регрессионное тестирование
  2. Исследовательское тестирование
  3. Интеграционное тестирование
  4. Функциональное тестирование