Тестирование инф.систем. Ответы на вопросы к лекциям Понятие тестирования программного обеспечения
 Скачать 0.52 Mb.
|
Обычно критерии входа покрывают:готовность и доступность тестового окружения; готовность средства тестирования в окружении; доступность тестируемого кода; доступность тестовых данных. 14.Что такое критерий выхода? Критерий выхода определяет, когда нужно прекращать тестирование, например, по окончании уровня тестирования или когда набор тестов достиг определенной цели. Обычно критерии выхода покрывают:тщательность оценки, например покрытие кода, функциональности или рисков; оценку плотности дефектов или измерение надежности; стоимость; остаточные риски, такие как неисправленные дефекты или недостаток тестового покрытия какой-либо области; план, основанный на времени выхода ПО на рынок. Когда принято составлять график тестирования? Как только оценка трудозатрат выполнена, определяют ресурсы и составляют график тестирования. На этом этапе фиксируются сроки тестирования, которые при успешном раскладе не должны быть превышены. Работы по тестированию могут зависеть от многих факторов, включая: • характеристики продукта: качество спецификаций или другой информации, используемых моделей тестирования (т.е. основы тестирования), размер продукта, сложность предметной области, требования к надежности и безопасности и требования к документации; • характеристики процесса разработки: стабильность организации, используемые средства, процессы тестирования, квалификация вовлеченных людей и временные ограничения; • результат тестирования: количество дефектов и объем работы, которую необходимо переделать. Как вы понимаете понятия мониторинга и контроля процесса тестирования? Мониторинг процесса тестирования – это постоянное наблюдение и отслеживание процесса, его активностей и результатов в определенных временных рамках. Мониторинг необходим для получения результата и обзора процесса тестирования. Отслеживание может быть проведено вручную или автоматически при помощи специальных инструментов. На основе полученной информации могут быть измерены критерии выхода, например покрытие, плотность дефектов и т.д. Контроль тестирования в отличие от мониторинга описывает любые направляющие или корректирующие действия, принятые как результат по полученной и собранной информации и значениям метрик. Контроль в общем случае затрагивает любые действия по тестированию и, кроме того, может оказывать воздействия на любые задачи жизненного цикла программного обеспечения. Приведите примеры метрик тестирования. В качестве примеров тестовых метрик можно привести:процент работ по подготовке тестовых сред; процентное соотношение запланированных и подготовленных тестовых сценариев; количество выполненных и невыполненных тестовых сценариев; процент пройденных успешно и проваленных тестовых сценариев; процент заблокированных тестовых сценариев; процент неактуальных тестовых сценариев; количество найденных и исправленных дефектов; плотность дефектов; количество дефектов по критичности; количество переоткрытых в ходе повторного тестирования дефектов; интенсивность отказов; тестовое покрытие требований, рисков или кода; стоимость тестирования и др. 18.Что такое матрица трассировки и как ее строят? В рамках мониторинга тестирования наиболее часто используют так называемую матрицу покрытия (трассировки). Это специальный документ, который позволяет более структурированно отобразить требования к продукту, отследить степень покрытия требований тестами и дает возможность поддержать тесты в более актуальном состоянии, если в требования вносятся изменения. Матрица трассировки составляется в несколько этапов:составление нумерованного списка требований к приложению; составление нумерованного списка тестов; непосредственное составление матрицы трассировки. 19.Для чего необходима отчётность по тестированию? ходе тестирования и по его завершении обязательным является составление отчётности по тестированию. Формы отчетности могут быть самыми разными и, как правило, зависят от потребностей и специфики проекта. Отчеты могут предоставить заинтересованным лицам следующие сведения: сроки достижения критериев выхода; результаты анализа метрик тестирования для принятия дальнейших решений. 20.Как правильно завершать процесс тестирования? Решение о прекращении тестирования обычно зависит от времени (которое есть в распоряжении), бюджета и необходимой продолжительности тестирования. Чаще всего решение завершить тестирование принимается, когда закончилось время/бюджет, или же когда все тестовые сценарии выполнены. Но это компромиссное решение, которое может быть в ущерб качеству. 21.Для чего необходима система управления тестами? Системы управления тестированиемиспользуются для хранения информации о том, как должным образом проводить тестирование, осуществление очередности проведения тестирования в соответствии с его планом, а также для получения информации в виде отчетов о стадии тестирования и качестве тестируемого продукта. 22.Какие системы управления тестами вам известны? 23.Каковы основные функции системы управления дефектами? Для таких целей предусмотрены так называемые системы багтрекинга (bug tracking system или BTS). Такие инструменты выполняют, как правило, следующие основные функции: документирование дефектов и инцидентов, а также вопросов и предложений по улучшению программного продукта; отслеживание хода работ по дефектам и инцидентам; сбор статистики. Кроме того, системы багтрекинга позволяют выполнять и такие действия, как: фиксация времени, потраченного на исправление дефекта; оформление не только дефектов, но и задач внутри проекта; составление отчетности по проекту и т.д. 24.Что такое жизненный цикл дефекта и какие состояния он включает? Жизненный цикл дефекта (bug workflow) – это последовательность этапов, которые проходит дефект с момента его создания до момента закрытия и завершения работ по нему. Зачастую жизненный цикл зависит от выбранной системы управления дефектами и специфики проекта. Наиболее обобщенный жизненный цикл дефекта включает в себя следующие состояния:«Открыт» (Open) – статус присваивается автоматически после внесения баг-репорта, т.е. создания дефекта в системе управления дефектами; «Отклонён» (Need More Info / Resolved как Invalid, Won’t fix, Can’t reproduce или Not a bug) – ошибка была проанализирована разработчиком или другим участником процесса разработки и по результатам анализа выявлена недостаточность описания или дефект является дубликатом, не будет исправлен по согласованию заинтересованных сторон, не может быть воспроизведён или заведен по ошибке и не является дефектом согласно требованиям к системе; «Исправлен» (Resolved / Fixed) – данный статус присваивается специалистом разработки после того, как ошибка была устранена; «Открыт повторно» (Reopened) - данный статус присваивается тестировщиком при повторном возникновении ошибки после её предварительного исправления; «Закрыт» (Closed) – дефект получает данный статус после проведения проверки, которая выявила окончательное исправление. Для чего используются плагины в системе управления дефектами, например, в Atlassian JIR На рисунке 21 представлена форма создания дефекта в системе Atlassian JIRA:  Рисунок 21 – Форма создания дефекта в системе Atlassian JIRA Рисунок 21 иллюстрирует систему JIRA, которая уже была настроена под нужды конкретного проекта, а потому имеются многочисленные дополнительные поля, а также поля, предзаполненные данными проекта. |