Студопедия

Главная страница Случайная страница

КАТЕГОРИИ:

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






Обоснование




 

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


 

Краткое описание Описание проблемы на кон­

проблемы цептуальном уровне. Обычно

такое описание дефекта уме­

щается в одной строке.

 

Описание Детальное описание симпто­

проблемы мов проблемы и того, как она

ограничивает функциональные

возможности или производи­

тельность системы.

 

Степень Упорядочивание дефектов по

серьезности степени серьезности послед­

дефекта ствий. Примеры:

 

Катастрофический- вызыва­

 

ет разрушение системы

 

Крупный- программный про­

дукт не подлежит использова­

нию

 

Умеренный- продукт можно

использовать, однако имеют

место некоторые неудобства

для пользователя

 

Незначительный- пользова­

 

тель не ощущает последствий

 

Помеха- можно устранить,

 

когда позволит время.

 

Как воспроизвести Используется детально прора­

проблему ботанная методика воспроиз­

ведения проблемы, включая

выбор используемой конфигу­

рации средств тестирования.

Может оказаться достаточным

сказать: "Выполнить прогон

теста с идентификатором та­

ким-то", если этот тест хорошо

документирован.


 

Это описание используется в сообщени­ ях о статусе дефекта и в отчетных док­ ладах и адресовано руководству проекта и членам других групп, стремящихся к пониманию проблемы во всех деталях.

 

Это описание предназначено для тех, кому требуется детальное понимание проблемы, например, разработчику, который работает над устранением дефекта, или руководителю, распреде­ ляющему ресурсы.

 

Серьезность последствий часто опреде­ ляет приоритеты усилий разработчиков при устранении дефектов и тестировщи-ков при проверке результатов этих ис­ правлений.

 

 

Детально проработанная методика по­ зволяет разработчикам воспроизвести дефект и предоставляет возможность разработчикам и тестировщикам прове­ рять результаты устранения проблемы.


Глава 5. Системные испытания

 

 

Каждый дефект получает в базе данных отслеживания дефектов уникальный идентификатор, так называемый идентификатор дефекта. Идентификатор дефектов представляет собой ключ, который поддерживает запросы, поступающие в базу дан­ ных с таким расчетом, чтобы можно было получить информацию о его состоянии, которое можно рассматривать как показатель продвижения работ по его устранению. В базе данных отслеживания дефектов должны храниться сведения о том, кто обна­ ружил дефект, когда он был обнаружен, уровень серьезность дефекта, а также под­ робное описание проблем, которые он вызвал. Если дефект был обнаружен во время системных испытаний, должна быть записана информация, касающаяся теста, кото­ рый выявил этот дефект. Для хорошо документированного тестового случая вполне достаточно запомнить только идентификатор теста. Если тест не задокументирован должным образом или если дефект был обнаружен в результате специализированного (ad hoc) тестирования, необходимо записать информацию о конфигурации средствтестирования и о специальных действиях, выполненных для обнаружения этого де­ фекта. Пример отчета о дефекте, который может использоваться для целей докумен­ тирования, приводится далее в разделе "Как составлять сообщения о дефектах".



 

 

Данные о дефекте, попадающие в базу данных отслеживания дефектов, должны быть изучены группой анализа обнаруженных дефектов (или группой контроля за внесением изменений) с целью определения степени серьезности дефекта. На самом ли деле это дефект? Правильная ли степень серьезности была присвоена обнаружен­ ному дефекту? Должен ли он быть устранен в текущем выпуске программного продук­ та? Информация, которая должна быть внесена в базу данных отслеживания дефек­ тов по результатам работы группы анализа дефектов, показана в таблице 5.3. В ре­ зультате анализа дефект переводится в одно из следующих трех состояний:



 

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

Отложить (defer)— дефект переводится в это состояние, если группа анализарешит отложить устранение этого дефекта до последующих выпусков про­ граммного продукта.

Игнорировать (trash)— дефект переходит в это состояние, если группа анали­за решила, что дефект был внесен по ошибке.

 

В зависимости от итогового состояния дефекта, в базу данных отслеживания де­ фектов вводятся различные данные. Например, если дефект двигается в направлении состояния "исправить", следует ввести имя исполнителя, ответственного за устране­ ние дефекта. Если информация относительно дефекта готовится для передачи заказ­ чикам, должен быть введен текст пояснительной записки по выпуску. Более подроб­ ная информация, касающаяся анализа дефектов, будет изложена в разделе "Анализ дефектов".

 

Как показано в таблице 5.4, окончательный набор данных нужно вводить в систе­ му отслеживания дефектов во время исправления дефекта. Необходимо зафиксиро­ вать имя исполнителя, исправляющего дефект, дату исправления и идентификатор сборки, в которой производилось исправление. Должно быть дано подробное объяс­ нение основной причины проблемы, чтобы группа разработки могла воспроизвести и устранить проблему.


 

126 Часть I. Процесс быстрого тестирования

 

 

Таблица 5.3. Данные отслеживания дефекта в состояниях "исправить" (fix), "отложить" (defer) и "игнорировать" (trash)


 

Характеристика Описание  
Идентификатор Уникальный идентификатор
дефекта дефекта  
(не изменяется)    
Состояние Состояния "исправить" отложить
дефекта и "игнорировать"  

 

 

Кто исправил Имя исполнителя, которому пору­
  чено устранить дефект.
Кем отложен срок Имя ответственного лица, которое
исправления своим решением отодвинуло ис­
  правления дефекта на более
  поздний срок (оставить поле пус­
  тым, если исправление дефекта
  не отложено).
Кто проигнорировал Имя ответственного лица, которое
дефект приняло решение не исправлять
  дефект (оставить поле пустым,
  если исправление дефекта не
  откладывалось).
Дата начала День, месяц и год, когда устране­
исправления ние дефекта было поручено раз­
  работчику, ответственному за
  исправления.
Дата, когда исправ­ День, месяц и год, когда исправ­
ление было ление было отложено.
отложено  
Дата, когда было День, месяц и год, когда было
принято решение принято решение не делать ис­
не делать правления.
исправления.  
Нужна пояснитель­ Введите "Y", если нужна поясни­
ная записка к тельная записка к выпуску, и "N",
выпуску (Y/N)? если такая пояснительная записка
  не нужна.

 


.

mylektsii.ru - Мои Лекции - 2015-2019 год. (0.009 сек.)Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав Пожаловаться на материал