Интуит. ответы интуит 4 экзамен. Задача в общей постановке алгоритмически неразрешима
 Скачать 0.63 Mb.
|
|
Как определяется тестовая стратегия? | ||
| | | анализ архитектуры тестируемого приложения для выявления мест, по всей вероятности, содержащих дефекты 1 |
| | | определение и обоснование стратегии выбора входных данных, достаточных для достижения требуемого покрытия 1 |
| | | определение потребности в системе автоматизации тестирования |
| Почему MSC спецификация обеспечивает снижение трудоемкости тестирования? | ||
| | | MSC описывает множество инвариантных сценариев, отличающихся численными значениями символических параметров |
| | | MSC позволяет сгенерировать сотни тестов, а соответствующий testbench автоматически прогнать их |
| | | одна MSC может кодировать множество параллельных или недетерминированных сценариев |
| Какие основные уровни выделены в процессе тестирования? | ||
| | | модульное тестирование |
| | | интеграционное тестирование |
| | | системное тестирование |
| | | регрессионное тестирование |
| Чем отличается финальный цикл тестирования? | ||
| | | код последнего перед финальным циклом build не должен включать изменений |
| | | количество и структура дефектов, найденных на финальном цикле, не противоречат критериям приемки продукта |
| | | финальный цикл гарантирует заказчику качество продукта, оговоренное в спецификации |
| Каковы преимущества автоматизированного тестирования? | ||
| | | строгий контроль результатов по эталонам |
| | | высокая скорость выполнения тестового набора и возможность повторяемости |
| | | высокая надежность, не зависящая от времени тестового прогона |
| Какова процедура выбора и оценки критериев качества программного продукта? | ||
| | | определение заинтересованных сторон в качестве проекта |
| | | определение критериев качества, важных для каждого из участников |
| | | приоритезация критериев с учетом веса участников |
| | | определение набора критериев с определением целей по каждому критерию |
| | | определение стратегии тестирования, исходя из критериев и целей |
| Какие существуют типы тестирования по способу выбора входных данных? | ||
| | | функциональное, с покрытием функциональных требований и сценариев использования |
| | | стрессовое, с покрытием экстремальных режимов использования приложения |
| | | тестирование граничных значений и производительности |
| | | тестирование соответствия стандартам |
| | | тестирование совместимости с другими программно-аппаратными комплексами/платформами |
| Как осуществить планирование тестирования? | ||
| | | определение необходимых человеческих, программных и аппаратных ресурсов |
| | | разработка графика тестовых циклов и назначение задач на ресурсы |
| | | согласование графика тестирования с графиком разработки |
| | | планирование графика обнаружения ошибок в процессе тестирования |
9
| Какие существуют особенности документа для описания тестовых процедур? | ||
| | | содержат описание последовательности действий, необходимых для выполнения тестового набора |
| | | процедуры должны быть сформулированы так, чтобы их мог выполнить инженер, незнакомый с данным проектом |
| | | процедуры для автоматизированных тестов должны содержать только информацию для запуска и анализа результатов |
| | | процедуры автоматически выполняют тестовые наборы |
| Какая информация должна сопровождать действие по исправлению ошибки и перевод дефекта в состояние Resolved? | ||
| | | причину возникновения дефекта |
| | | место исправления дефекта |
| | | краткий комментарий сделанных исправлений |
| Каковы цели обзора тестового кода? | ||
| | | установить соответствие тестового набора тестовой стратегии |
| | | проверить правильность кодирования тестов |
| | | оценить степень качества кода, исходя из требований по стандартам, простоте поддержки, наличию комментариев и т.п. |
| Каковы особенности документа для описания дефектов? | ||
| | | номер теста, обнаруживавшего дефект |
| | | уровень серьезности дефекта |
| | | поле записи содержит номер build, на котором дефект был найден |
| | | описание дефекта и описание процедуры его воспроизведения |
| Каково содержание тестового отчета? | ||
| | | перечень функциональности, запланированной на тестирование |
| | | количество выполненных тестов и время тестирования |
| | | количество найденных и повторно открытых дефектов |
| | | фиксацию отклонений от процедуры тестирования |
| | | заключение о корректировках тестового набора перед следующим циклом тестирования |
| Какие тестовые метрики используются при тестировании? | ||
| | | покрытие функциональных требований и покрытие кода продукта |
| | | покрытие множества сценариев |
| | | количество и плотность найденных дефектов |
| | | скорость нахождения дефектов |
| Каковы особенности документа для описания тестов? | ||
| | | содержат информацию для анализа и поддержки тестового набора |
| | | содержат информацию, связывающую любую функцию с тестами, в которых она используется или связи любого теста со всеми используемыми функциями и их сочетаниями |
| | | содержат информацию о структуре и взаимосвязях тестовых файлов |
| | | концептуальное описание системы автоматизации тестирования |
| | | описание расписания тестирования |
| Какие бывают состояния дефекта? | ||
| | | New – дефект занесен в базу дефектов |
| | | Open – дефект зафиксирован за разработчиком для исправления |
| | | Resolved – дефект разработчиком исправлен |
| | | Verified – успешное исправление дефекта подтверждено инженером по качеству (SQE) |
| | | Postponed – решение о замораживании активности по исправлению дефекта |
| Каковы цели обзора тестовой стратегии? | ||
| | | установить достаточность проверок при тестировании |
| | | проанализировать оптимальность покрытия |
| | | проанализировать оптимальность подхода к автоматизации тестирования |