Практическая. ПР_5. Составление отчета об ошибках по результатам тестирования мобильных приложений
 Скачать 383.92 Kb.
|
Учреждение образования«Гомельский государственный аграрно-экономический колледж»МЕТОДИЧЕСКИЕ УКАЗАНИЯ И ЗАДАНИЯ ДЛЯ ПРОВЕДЕНИЯ ПРАКТИЧЕСКОЙ РАБОТЫ №5 ПО ДИСЦИПЛИНЕ «ТЕСТИРОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ» специальность 2 – 40 01 01 «Программное обеспечение информационных технологий». Тема: Составление отчета об ошибках по результатам тестирования мобильных приложений. Цель: научиться составлять отчет об ошибках по результатам тестирования мобильных приложений. Оборудование: ПК, ОС Windows, MS WORD. Время выполнения: 2 часа. Теоретические сведения Отчёт об ошибках — документ, описывающий и приоритизирующий обнаруженный дефект, а также содействующий его устранению. Как следует из самого определения, отчёт о дефекте пишется со следующими основными целями: • предоставить информацию о проблеме — уведомить проектную команду и иных заинтересованных лиц о наличии проблемы, описать суть проблемы; • приоритизировать проблему — определить степень опасности проблемы для проекта и желаемые сроки её устранения; • содействовать устранению проблемы — качественный отчёт о дефекте не только предоставляет все необходимые подробности для понимания сути случившегося, но также может содержать анализ причин возникновения проблемы и рекомендации по исправлению ситуации. Отчёт о дефекте (и сам дефект вместе с ним) проходит определённые стадии жизненного цикла, которые схематично можно показать так: • Обнаружен (submitted) — начальное состояние отчёта (иногда называется «Новый» (new)), в котором он находится сразу после создания. Некоторые средства также позволяют сначала создавать черновик (draft) и лишь потом публиковать отчёт. • Назначен (assigned) — в это состояние отчёт переходит с момента, когда кто-то из проектной команды назначается ответственным за исправление дефекта. Назначение ответственного производится или решением лидера команды разработки, или коллегиально, или по добровольному принципу, или иным принятым в команде способом или выполняется автоматически на основе определённых правил. • Исправлен (fixed) — в это состояние отчёт переводит ответственный за исправление дефекта член команды после выполнения соответствующих действий по исправлению. • Проверен (verified) — в это состояние отчёт переводит тестировщик, удостоверившийся, что дефект на самом деле был устранён. Как правило, такую проверку выполняет тестиров- щик, изначально написавший отчёт о дефекте. • Закрыт (closed) — состояние отчёта, означающее, что по данному дефекту не планируется никаких дальнейших действий. Здесь есть некоторые расхождения в жизненном цикле, принятом в разных инструментальных средствах управления отчётами о дефектах: • Открыт заново (reopened) — в это состояние (как правило, из состояния «Исправлен») отчёт переводит тестировщик, удостоверившийся, что дефект по-прежнему воспроизводится на билде, в котором он уже должен быть исправлен. • Рекомендован к отклонению (to be declined) — в это состояние отчёт о дефекте может быть переведён из множества других состояний с целью вынести на рассмотрение вопрос об отклонении отчёта по той или иной причине. Если рекомендация является обоснованной, отчёт переводится в состояние «Отклонён» (см. следующий пункт). • Отклонён (declined) — в это состояние отчёт переводится в случаях, подробно описанных в пункте «Закрыт», если средство управления отчётами о дефектах предполагает использование этого состояния вместо состояния «Закрыт» для тех или иных резолюций по отчёту. • Отложен (deferred) — в это состояние отчёт переводится в случае, если исправление дефекта в ближайшее время является нерациональным или не представляется возможным, одна- ко есть основания полагать, что в обозримом будущем ситуация исправится (выйдет новая версия библиотеки, вернётся из отпуска специалист по некоей технологии, изменятся требования заказчика и т.д.). Порядок выполнения работы Сначала определимся с набором минимальных характеристик, необходимых для формирования отчета: Тема/Наименование - раскрываем кратко суть дефекта Последовательность действий - описание шагов, которые привели к некорректному поведению приложения Ожидаемый и Фактический результат - наши ожидания от выполнения последовательности действий и то, что мы получили по факту Категория дефекта - градации могут быть разными, но они помогают классифицировать дефект. Например: функциональность, удобство, контент, дизайн, логика. Критичность - пользуемся стандартной шкалой (Critical, Blocker, Medium, Minor, Trivial) Приоритет - пользуемся стандартной шкалой (High, Medium, Low) Скриншот - ссылка на скриншот экрана с ошибкой Ниже представлен пример оформления отчета с разбивкой по критичности дефектов. Начинаем с наивысшего уровня критичности, переходя к минорным дефектам.  Задание для учащихся. Создать таблицу и записать в нее результаты функционального тестирования мобильных приложений. Контрольные вопросы Что такое отчет об ошибках? Опишите цели описания отчета о дефекте? 3. Что такое дефект? 4. 5. Как составляются тестовые сценарии? Преподаватель Е.А. Крагель Рассмотрено на заседании цикловой комиссии информационных технологий и информатики Протокол № ___от _______________________ Председатель цикловой комиссии ____________ Кухаренко С.Н. |