Отчет "Индикаторы качества построения"

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

В идеале, показатели тестов, ошибки и обработка кода должны давать одинаковую картину, но зачастую это не так. При обнаружении расхождения с помощью отчета "Индикаторы свойства построения" можно изучить подробные сведения о конкретном построении и ряд данных. Поскольку в этом отчете сочетаются результаты тестов, объем протестированного кода, обработка кода и ошибки, он позволяет взглянуть на проблему одновременного с нескольких ракурсов.

Сведения о способах доступа к отчетам, их обновления и управления отчетами см. в разделе Отчеты (гибкая разработка).

Примечание

Для этого отчета требуется, чтобы коллекция командных проектов, в которой содержится нужный командный проект, была создана с поддержкой служб отчетов SQL Server.Если при запуске Сред. Командный обозреватель и развертывании узла командного проекта не отображается пункт Отчеты, отчет недоступен.

В этом разделе Данные в отчете Изменение количества построений в отчете Интерпретация отчета Фильтрация отчета

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

Необходимые разрешения

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

Данные в отчете

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

Каждая вертикальная полоса соответствует набору данных, полученных из одного или нескольких построений. В варианте отчета для размера кода длина каждой вертикальной полосы соответствует размеру кода, возращенного в базу кода. Масштаб полос выбран таким образом, что высота диаграммы совпадает с размером самого большого рисунка. Ручные тесты можно выполнять в любое время после построения, с которым они связаны. Тесты, которые еще не выполнялись, считаются тестами "с неопределенным результатом".

На следующем рисунке изображен простой отчет "Индикаторы свойства построения".

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

Индикатор качества	Описание
Активные ошибки (количество)	График, на котором отображается число ошибок, активных на момент построения. Примечание Ошибки не связаны явным образом с построениями.Некоторые учтенные ошибки могут не влиять на построения, отображающиеся на графике.С помощью параметра "Область" можно отфильтровать ошибки по области продукта.Эта методика позволяет обнаружить ошибки, которые вероятнее всего влияют на построения в отчете.
Обновление кода (строк)	График, на котором указано количество строк кода, добавленных, удаленных и измененных командой в возвратах перед построением. Количество обработанного кода определяется путем деления числа строк кода, которые команда добавила, удалила или изменила в построении на общее количество строк в построении.
Объем протестированного кода (процент)	График, на котором отображен процент кода, покрытого тестами.
Тесты с неопределенным результатом	Серая область линейчатой диаграммы с накоплением, указывающая число не выполненных успешно или приостановленных тестов. Если построение завершилось неудачей, тесты не зачитываются или засчитываются как тесты с неопределенным результатом.
Неудачные тесты	Красная область линейчатой диаграммы с накоплением, указывающая число неудавшихся тестов для построения.
Пройденные тесты	Серая область диаграммы с накоплением, указывающая число пройденных тестов для построения.

Примечание

Сведения о значении результатов непройденных и пройденных тестов см. в разделе Отчет "Ход выполнения плана тестирования".

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

• Изменить диапазон по оси X, задав число построений и указав дату окончания отчета. Дата первого отображаемого построения зависит от частоты построений.

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

• Отфильтровать ошибки, произошедшие в отчете, задав области продукта, которые нужно в него включить. Этот фильтр не влияет на набор построений, отображающихся по оси X, обработку кода, объем протестированного кода или результаты тестов.

Дополнительные сведения см. в разделе Фильтрация отчета далее в этом разделе.

Необходимые действия по управлению тестированием и построением

Чтобы отчет "Индикаторы свойства построения" был полезен и отражал все индикаторы качества, которые в нем можно отобразить, участники команды должны выполнить перечисленные ниже действия для управления тестами и построением.

• Настройка системы построения. Для использования приложения Team Foundation Build необходимо настроить систему построения.

  Дополнительные сведения см. в разделе Настройка системы построения.

• Создание определений построения. Для получения кода для разных платформ можно создать несколько определений построения. Также каждое построение можно выполнить с использованием другой конфигурации.

  Дополнительные сведения см. в разделе Определение процесса построения.

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

  Дополнительные сведения см. в разделе Определение построения с помощью шаблона по умолчанию.

• Настройка тестов для сбора данных о покрытии кода. Чтобы данные о покрытии кода попали в отчет, члены команды должны инструментировать тесты для сбора этих данных.

  Дополнительные сведения см. в разделах Практическое руководство. Настройка покрытия кода с помощью параметров тестирования для автоматических тестов и Практические примеры: Gather Code-Coverage Data with Generic Tests.

• Регулярное выполнение построения. Построения можно запускать через заданные интервалы или после каждого возврата. Используя запланированный триггер, можно создавать регулярные построения.

  Дополнительные сведения см. в разделах Создание базового определения построения и Запуск построений и наблюдение за ними.

  Примечание

  Несмотря на то что член команды может вручную оценить построение с помощью приложения Сред. Обозреватель сборки, эта оценка не отражается в отчете "Индикаторы качества построения".Оценка построения отображается в отчете "Сводка построения".Дополнительные сведения см. в разделах Оценка качества завершенного построения и Отчет "Сводка построения".

Изменение количества построений в отчете

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

Определение числа построений, представленных в отчете

1. В поле Число построений введите число построений, которые нужно включить.

2. Далее, в поле Окончание итерации (дата), щелкните значок календаря и выберите дату, соответствующую последнему дню выполнения построений, которые необходимо включить в отчет.

3. Нажмите кнопку Просмотр отчета.

Интерпретация отчета

Просмотрев отчет, можно найти ответы на следующие вопросы по любому конкретному определению построения:

• Каково качество программного обеспечения?

• Тестирует ли команда достаточный объем кода?

• Удается ли пройти тесты?

• Свидетельствуют ли метрики кода и тестовые метрики о достаточно высокой вероятности того, что команда сможет справиться с поставленной задачей?

• Как часто тесты проходят успешно и какое количество кода тестируется?

  Примечание

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

Рабочая версия отчета

В рабочем отчете "Индикаторы свойства построения" будут отображены следующие индикаторы:

• большинство тестов пройдено (большая зеленая область) и мало тестов не пройдено (небольшое количество красного);

• доля красного не превышает 20–30 процентов.

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

Нерабочая версия отчета "Индикаторы свойства построения"

В нерабочей версии отчета "Индикаторы свойства построения" отображается один или несколько перечисленных ниже индикаторов. Для изучения причины можно руководствоваться приведенными ниже указаниями.

• Объем протестированного кода меньше, а обработанного кода больше. На следующем рисунке показано уменьшение объема протестированного кода и увеличение объема обработанного кода. Такие данные являются однозначным предупреждением о том, что код возвращается без проведения надлежащих модульных тестов, которые необходимы для его покрытия.

  

• Запуск незначительной доли тестов. На следующей иллюстрации показана незначительная доля выполняемых тестов. Такие данные могут свидетельствовать о недостаточности тестирования, выполняемого командной. Это затруднение может указывать на недостаток ресурсов или о том, что тест-инженеры заняты не тестированием текущих функциональных возможностей, а другими задачами, например созданием средств автоматизации тестов. В любом случае, необходимо обеспечить баланс ресурсов.

  

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

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

  

• Высокая доля непройденных тестов. На следующем рисунке показано, что многие тесты выполняются с достаточным покрытием, однако пройти эти тесты не удается. Такие данные могут свидетельствовать о неправильном подходе к разработке или, на ранних итерациях, о завышенной строгости тестов для продукта на данном этапе разработки продукта.

  

  Проблемы, ставшие причиной непрохождения тестов, нужно устранить как можно скорее. Если исправление кода нецелесообразно, непройденные тесты нужно временно отключить, а ошибку занести в журнал. Хотя иногда, на ранних этапах проекта, вполне допустимо считать ошибки анализа кода менее срочными, нужно следить за тем, чтобы красная часть не становилась слишком большой.

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

  

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

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

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

• Число активных ошибок снижается без роста числа пройденных тестов. Если число активных ошибок снижается, а доля пройденных тестов не растет, возможно, существует риск роста частоты возобновлений.

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

Фильтрация отчета

Отчет "Индикаторы свойства построения" можно отфильтровать следующими способами.

• Изменить интервал времени, задав число построений и указав дату окончания отчета.

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

  Примечание

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

• Отфильтровать ошибки, произошедшие в отчете, задав области продукта, которые нужно в него включить.

На следующем рисунке показаны доступные фильтры.

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

Фильтрация построений, отображаемых в отчете

1. В поле Число построений введите число построений, которые нужно включить.

2. Рядом с полем Дата окончания щелкните значок календаря, а затем выберите последнюю дату построений, которые нужно включить в отчет.

3. В списке Платформа установите флажки рядом с необходимыми платформами, чтобы отобразить их в отчете.

4. В списке Конфигурация установите флажки рядом с необходимыми конфигурациями, чтобы отобразить их в отчете.

5. В списке Определение построения установите флажки рядом с необходимыми определениями построения, чтобы отобразить их в отчете.

6. Нажмите кнопку Просмотр отчета.

Фильтрация числа ошибок, отображаемых в отчете

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

   На этом шаге отчет фильтруется в соответствии с иерархией результатов тестирования.

2. Нажмите кнопку Просмотр отчета.

См. также

Основные понятия

Отчет "Ход выполнения плана тестирования"

Отчет "Успех построения за период времени"

Отчет "Сводка построения"

Артефакты (гибкая разработка)

Другие ресурсы

Отчеты (гибкая разработка)