- •Минобрнауки россии
- •Им. В.И.Ульянова (Ленина)” (сПбГэту)
- •Магистерская диссертация Тема: «Разработка оптимальных методов тестирования электронных курсов»
- •Минобрнауки россии
- •Им. В.И.Ульянова (Ленина)” (сПбГэту) техническое задание
- •Содержание
- •Словарь терминов
- •Введение
- •Аналитический обзор предметных областей
- •Общие вопросы тестирования и качества
- •Жизненный цикл проекта
- •Особенности web – приложений
- •Понятие дефект и качество
- •Анализ и управление требованиями
- •Основные виды тестирования
- •1.1.5.1. Функциональные виды тестирования
- •1.1.5.2. Нефункциональные виды тестирования
- •1.1.5.3. Связанные с изменениями виды тестирования
- •1.1.6. Внедрение тестирования
- •1.1.6.1. Фаза сбора требований
- •1.1.6.2. Фаза проектирования
- •1.1.6.3. Фаза реализации
- •1.1.6.4. Фаза выпуска продукта
- •1.1.7. Обобщение аналитической части
- •Тестирование
- •Тестирование
- •1.2. Системы электронного обучения
- •Задачи и особенности электронных курсов
- •1.2.2. Основные функции и свойства электронных курсов
- •1.2.3. Средства разработки электронных курсов
- •Определение критериев тестирования
- •2.1. Выявление особенностей тестирования электронных курсов
- •2.2. Выбор оптимальных методик и методов тестирования
- •2.3. Проектирование и разработка системы тестов
- •2.4. Тестовое покрытие и качество системы тестов
- •Разработка общих алгоритмов тестирования
- •3.1. Тестовые сценарии и их выполнение
- •3.2. Подготовка отчетов об ошибках
- •Практическое применение к электронным курсам courselab
- •4.1. Тестирование
- •4.2. Отчет о выполнение сценариев тестирования
- •4.3. Выводы
- •Вывод по результатам исследования
- •Список литературы
3.2. Подготовка отчетов об ошибках
Отчеты об ошибках (на англ. «Bug Report»)– это основной материальный продукт тестирования, надежная техническая документация, которая описывает вид ошибки в тестируемой системе.
Для упрощения организации взаимодействия групп и общего централизованного хранения отчетов об ошибках следует использовать системы отслеживания ошибок (на англ. «bug tracking»). Это позволяет иметь единое хранилище ошибок, отслеживать их повторное появление, контролировать скорость и эффективность исправления ошибок, видеть наиболее нестабильные компоненты системы, а также поддерживать связь между группой разработчиков и группой тестирования (уведомления об изменениях по почте и т.п.). Чем больше проект, тем сильнее потребность в централизованном хранилище дефектов.
Пример одной из свободных систем отслеживания ошибок с веб-интерфейсом. является Bugzilla (разработка компании Mozilla). Данная система очень проста и популярна в использовании [10].
Подобная система обеспечивает следующие функции:
-
хранение сообщения об ошибке (с обязательной информацией о том, к какому компоненту системы относится ошибка, кто ее нашел, как ее воспроизвести, кто отвечает за ее исправление и когда она должна быть исправлена);
-
система уведомления о появлении новых ошибок, об изменении статуса известных в системе ошибок (как правило, это уведомления по электронной почте);
-
отчеты об актуальных ошибках по компонентам системы, по интервалам времени, по группам разработчиков и разработчикам;
-
информация об истории ошибки (в том числе отслеживание похожих ошибок, отслеживание повторного возникновения ошибки);
-
правила доступа к ошибкам тех или иных категорий;
-
интерфейс ограниченного доступа к системе bug tracking для конечного пользователя информационной системы, который используется как интерфейс обмена информацией между пользователем и службой технической поддержки системы.
Существуют основные виды продвижения ошибки (на англ. «bug») по системе (на англ. «Defect flow»)(см. рисунок 6).
Рисунок 6 - Defect flow
При поступление ошибки в систему, из любого источника (заказчик, разработчик, тестировщик), баг принимает статус new (пер. с англ. «новый»). Затем рассматривается программистом его описание и: или ошибка решается (на англ. «resolve») или ей ставится статус duplicated (пер. с англ. «дубль»), что означает, что данная ошибка уже была и на данном этапе решается, или же ей ставится статус invalid (пер. с англ. «необоснованный»)- неверное описание, такой ошибки не существует. После всего этого командой тестировщиков данная ошибка перепроверяется и закрывается (на англ. «verify») в случае, если она больше не повторяется, или переоткрывается (на англ. «reopen»), если изменения все равно приводят к ошибке.
В отчете об ошибки необходимо соблюдать некоторые правила:
1. В отчете должна быть с самого начала понятна суть ошибки.
2.Должны быть четко понятны шаги воспроизведения.
3.Должен быть известен альтернативный правильный вариант поведения.
4. Указана версия и приоритет данной ошибки.