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

Скачать тест — (Тестирование документации и требований.дпо_53760402.pdf)

1. Комплекс документирования ПО должен быть изложен:
2. Достоверность информации в документации нужна для взаимодействия:
3. Управление документацией должно непрерывно поддерживать её:
4. Общение всех участников проекта ПС между собой, с создаваемым продуктом и с документами необходимо для гарантии:
5. Реализация документов ПС в значительной степени определяет для сложных программных продуктов:
6. Совокупные затраты на документирование крупных программных продуктов могут достигать от общей трудоемкости проекта
7. Технологическая документация процессов разработки и обеспечения всего жизненного цикла, включает:
8. Эксплуатационная документация программного продукта включает:
9. Основная задача включает:
10. Малый масштаб:
11. Состав и формы документов широко варьируется в зависимости от:
12. Документация разработки:
13. Документация продукции:
14. Документация управления проектом включает:
15. Понятия качества документации включает:
16. Стандартизированные форматы зависят от таких факторов, как:
17. Основными ресурсами в стандарте, для документирования выделяются:
18. В стандарте ISO 12182 установлена схема классификации, помогающая:
19. Процесс для записи информации, произведенной процессами жизненного цикла – это:
20. Документы должны быть произведены и поставлены заказчику согласно плану – это:
21. Состав базовых документов, регламентирующих верификацию и тестирование программных компонентов:
22. Исходные данные для верификации программных компонентов:
23. Результаты верификации корректности взаимодействия компонентов в составе программного средства:
24. Требования к системе, предназначенные для программной реализации, корректно переработаны в спецификацию требований высокого уровня к комплексу программ, удовлетворяют исходным системным требованиям:
25. Формализованы методы, которые будут использованы на каждом этапе процесса верификации ПС:
26. Доступные ресурсы на тестирование компонента определяют:
27. Организация, подготовка тестирования а обеспечение качества компонентов включает:
28. Сценарии тестирования и спецификации тестов для каждого компонента включают:
29. Описания контрольных сценариев тестирования — набор конкретных тестовых значений и соответствующих им эталонов включает:
30. План тестирования программного компонента включает:
31. Тестирование документации – это:
32. В процесс тестирования документации важно вовлекать различных специалистов:
33. Возможность проверить все прописанные требования после их реализации, если требование является полным, одинаково воспринимается всеми участниками проекта, ни одна важная деталь не упущена:
34. Насколько прописанные требования возможно реализовать:
35. Требования должны отражать функциональности, действительно необходимые для пользователя, для удовлетворения пользователей:
36. Одинаковое восприятие требований всеми членами команды, никаких расхождений в трактовке быть не должно:
37. Примеры часто встречающихся дефектов документации:
38. Цель тестирования документации:
39. Перспективы использования тестирования документации:
40. Тестирование документации может решать важные вопросы, касающиеся бизнес-целей проекта:
41. Качественный программный продукт должен:
42. Надежность ПО определяет способность без сбоев выполнять заданные функции:
43. Защищенность определяет степень безопасности системы от
44. Удобство сопровождения определяет легкость, с которой обслуживается продукт в плане простоты:
45. Управление жизненным циклом программного продукта помогает разработчикам целенаправленно добиваться:
46. Предназначено для проверки правильности функционирования методов классов ПО:
47. Предназначено для тестирования, при котором тестировщик не имеет заранее определенных тестовых сценариев и пытается интуитивно исследовать возможности программного продукта и обнаружить и зафиксировать неизвестные ошибки:
48. Используется для проверки корректности совместной работы компонентов программного продукта:
49. Предполагает проверку конкретных требований к ПО и проводится после добавление к системе новых функций:
50. Применяется при внесении изменений в программное обеспечение с целью проверки корректности работы компонентов системы, которые потенциально могут взаимодействовать с измененным компонентом: