Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Диплом Курочкина.docx
Скачиваний:
44
Добавлен:
27.10.2018
Размер:
353.22 Кб
Скачать

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. Указана версия и приоритет данной ошибки.