Мои Конспекты
Главная | Обратная связь

...

Автомобили
Астрономия
Биология
География
Дом и сад
Другие языки
Другое
Информатика
История
Культура
Литература
Логика
Математика
Медицина
Металлургия
Механика
Образование
Охрана труда
Педагогика
Политика
Право
Психология
Религия
Риторика
Социология
Спорт
Строительство
Технология
Туризм
Физика
Философия
Финансы
Химия
Черчение
Экология
Экономика
Электроника

Ошибки, жизненный цикл и описание. Отчет о контроле ошибок





Помощь в ✍️ написании работы
Поможем с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой
  • Синонимы ошибки

 

  • Системы хранения и отслеживания истории ошибок

 

  • Когда писать отчет об ошибке

 

  • Как зарегистрировать ошибку

 

  • Как правильно описать проблему

 

  • Дополнения к отчету об ошибке

 

  • Примеры информативных скриншотов

 

  • Примеры

Ошибка в программе обычно называется «баг» от английского bug — жук, клоп и др. Историй возникновения этого термина несколько, все они доступны для любознательных в интернете.

В процессе работы с ошибкой, особенно в англоязычной среде, можно встретить различные вариации этого термина, такие как:

► bug

► error

► defect

► system problem

► misfeature

► fault

В профессиональном тестинге продукта обязательно использование специализированной утилиты, системы хранения и отслеживания истории багов (bug tracking system) или на сленге «багобазы». Ее применение не только значительно облегчает учет ошибок, а и делает работу над ошибками последовательной, прозрачной, эффективной.

Существуют десятки таких систем на разный вкус, но самые правильные имеют следующий минимальный набор функций:

► немедленное оповещение (по e-mail) заинтересованных лиц об изменении статуса бага (добавлении нового, исправлении, закрытии и т.п.);

► выдача статистики, отчета о текущем состоянии всех или отфильтрованных по критериям багов;

► добавление и хранение не только текста с описанием проблемы, но и вложенных снимков экрана (скриншотов), логов и прочих материалов;

► добавление и хранение ответных комментариев других лиц по каждому багу, истории манипуляций с багом;

► настройка окружения (пользователи, количество и названия всех реквизитов ошибки: тип, серьезность, приоритет, продукт, модуль, версия, конфигурация и т.д.) под проект.

Во время выполнения тестов или по собственному наблюдению тестировщик может обнаружить какую-то проблему, претендующую на роль бага. Но в некоторых ситуациях найденный нюанс может оказаться как раз не багом, а «фичей» (от англ. feature), то есть, предусмотренной функцией, в этом случае тестировщик, зарегистрировавший проблему в багобазе, получит от разработчика злорадный ответ «not a bug» (который, правда, можно оспорить, если это имеет смысл).

Основной критерий, помогающий определить баг — это точное описание ситуации в документации. Если в авторитетной документации по проекту (тест-план, требования, спецификация, RFC) описано определенное поведение объекта тестирования в данной ситуации, а в реальности этот объект ведет себя иначе, это баг. Бывает, правда, что ошибка не в продукте, а в документации, но это уже отдельный разговор.

Но даже если найденный баг не подкрепляется достойными аргументами, а тестировщик считает, что проблема все-таки есть (например, его опыт подсказывает, что определенное поведение продукта не соответствует ожиданиям пользователя), он может внести свое замечание под грифом, который в различных багобазах называется как «feature request», «enhancement», «suggestion» или «probably a bug».

Следует, однако, проявлять сдержанность в творческом процессе поиска багов и не наполнять багобазу никому не нужными замечаниями. Также, если известно (или это можно быстро определить), что такой баг уже опубликован, добавлять дубликат не надо. Перед принятием решения о регистрации бага желательно запустить тест с негативным результатом еще раз или два и быть уверенным, что ошибка повторяется.

Но и бояться опубликовать лишнее тоже не следует, гораздо больший грех — оставить найденную серьезную проблему без внимания разработчика.

Что нужно делать, когда решение о публикации ошибки принято?

Прежде всего, нужно открыть используемую в проекте багобазу и авторизоваться там под своим аккаунтом. Затем, если это возможно сделать быстро, убедиться, что такого бага еще никто не регистрировал (если в проекте выделен человек — диспетчер добавленных ошибок, то об этом можно не заботиться).

Теперь можно добавить новый отчет о найденной проблеме. Обычно для этого нужно использовать ссылку или кнопку с названием типа «добавить новый», в этом случае откроется форма, в которой уже должны быть заполнены некоторые общие поля:

§ продукт;

§ дата;

§ имя тестировщика, его e-mail;

§ статус нового бага («новый», «добавленный»);

остается только указать из списка или вписать индивидуальные данные об ошибке:

§ модуль, в котором найдена проблема;

§ заголовок, суть проблемы (summary);

§ серьезность ошибки и приоритет ее исправления;

§ описание ошибки, шагов ее воспроизведения (см. далее);

§ дополнительные материалы (см. далее).

В случае если нужно использовать большинство информации из уже опубликованного бага, можно воспользоваться функцией копирования имеющегося бага в новый.

После заполнения формы остается подтвердить ее (отправить на сервер, добавить в базу), и новому багу будет присвоен уникальный идентификатор, который следует использовать в отчетах тестирования. Затем хорошие багобазы шлют уведомления о добавленной записи заинтересованным лицам.

В форме добавления нового бага поле «описание» самое важное, поэтому максимум внимания нужно уделить ему. Обычно в этом поле пишутся такие возможные подробности (напомним, что суть проблемы у нас уже есть в заголовке отчета): что именно произошло, при каких обстоятельствах получена ошибка, полная цитата сообщения об ошибке или кусочек лога, что от объекта тестирования ожидалось вместо ошибки, ссылка на тест-кейс или требование, каковы возможные причины ошибки и как она может быть исправлена (это писать следует, только если наверняка известно), конфигурация окружения (если она неочевидна), а также шаги воспроизведения ошибки (steps to reproduce), если она может быть повторена.

Если к описанию прикладываются дополнительные материалы, желательно указать это в тексте описания, чтобы их не забыли посмотреть, например: «see also screenshot ”bug-144-screenshot-001.gif” attached» или «see log “bug-144-log.txt” attached for details».

Можно ли объединять в одном отчете несколько ошибок или все ошибки следует разъединять и описывать в одном отчете только одну ошибку? Считается, что разъединять надо всегда. Но все же объединить кое-что можно — то, что исправляется одним действием одним человеком. Например: 1 человек должен 1 раз открыть страницу и исправить на ней 5 опечаток. В этом случае все 5 опечаток можно заявить в одном отчете. Но если есть подозрение, что все объединенные ошибки не будут исправлены «за один заход», скопом, то надо разъединять.

Поставьте себя на место разработчика и напишите описание проблемы так, чтобы у него возникло минимум вопросов к вам по вашему отчету.

Лишнюю информацию, которая не поможет делу, можно пропустить.

Обычно одного описания проблемы разработчику мало для того, чтобы ее понять и исправить, а иногда для того, чтобы признать ошибку. Поэтому к описанию желательно по возможности добавлять следующие материалы:

► Фрагмент лога работы продукта, в котором отмечена проблема. Если работа продукта логируется, разработчик в 90% случаях потребует лог ошибки, так как для него это самый понятный язык описания проблемы. Но километровый лог, собранный за весь день тестирования, будет ему бесполезен. Нужно выкусить только ту часть лога, которая имеет отношение к регистрируемой проблеме, обычно это от начала запуска теста до его завершения или до проблемной точки.

► Скриншот (снимок экрана) или несколько с обозначением проблемы. Если ошибка представлена наглядно на экране, разработчик будет благодарен за возможность увидеть ее своими глазами без повторения теста на своей стороне. Желательно иметь базовые навыки работы с каким-нибудь графическим редактором, чтобы уметь вырезать только относящуюся к делу часть экрана и акцентировать проблему стрелками, окружностью, возможно текстом, а иногда и нарисовать то, что должно было быть, и тогда разработчику будет еще легче понять претензии тестировщика.

Однако не стоит перегружать отчет об ошибке лишней информацией, если дополнительные материалы никак не помогут разработчику, прикреплять их не нужно.

Хорошо составленный отчет о найденной проблеме может содержать следующее:

Заголовок:
Не открывается новое окно при нажатии кнопки «Go» в окне «Start game».

Описание:
Открой экран начала игры в IE6sp2. Прокрути экран вниз, поставь чекбокс «Start new game» и нажми кнопку «Go». Игра начинается в том же окне, см. прикрепленный скриншот «screen-game1-01.gif».

Согласно требованию «Req-System1-0010» при нажатии кнопки «Go» должно открываться новое окно «Game 1».

Посмотрел код, у кнопки пропущен параметр «'_blank'».

Необязательно заполнять все поля формы, предложенные багобазой. Бесполезные в конкретном случае данные, как уже говорилось, не помогут.

Итак, полезность отчета о найденной ошибке — в его точности, то есть, нужная информация должна присутствовать в полном объеме, а ненужная нет.

Еще примеры отчетов:

Литература:

22. Microsoft Corporation - Тестирование производительности Web-приложений Microsoft .NET / Пер. с англ. – М.: Издательско-торговый дом «Русская Редакция», 2003. – 352 с.: ил.

23. Диан Стотлемайер. – Тестирование Web-приложений. Пер. с англ. – М.: КУДИЦ-ОБРАЗ, 2003. – 240 с.

24. Рекс Блэк. – Ключевые процессы тестирования. Планирование, подготовка, проведение, совершенствование. – М.: Издательство «Лори», 2006.

25. Тамре Л. – Введение в тестирование программного обеспечения.: Пер. с англ. – М.: Издательский дом «Вильямс», 2003. – 368 с.: ил. – Парал. тит. англ.

 

 

Доверь свою работу ✍️ кандидату наук!
Поможем с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой



Поиск по сайту:







©2015-2020 mykonspekts.ru Все права принадлежат авторам размещенных материалов.