Поделиться через


Панель мониторинга "Качество" (гибкая разработка)

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

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

Примечание

Доступ к панелям мониторинга осуществляется через портал командного проекта.Доступ к панели мониторинга "Качество" возможен только в том случае, если этот портал работает и может использовать приложение Microsoft Office SharePoint Server 2007.Дополнительные сведения см. в разделе Панели мониторинга (гибкая разработка) или Доступ к порталу командного проекта и руководству по процессам.

В этом разделе

  • Данные, отображающиеся на панели мониторинга

  • Действия, необходимые для отслеживания качества

  • Устранение неполадок, связанных с качеством

  • Настройка панели мониторинга "Качество"

Эту панель мониторинга можно использовать для ответа на следующие вопросы:

  • Отслеживается ли объем тестирования?

  • Проводится ли тестирование командой соответствующих функциональных возможностей?

  • Соответствуют ли исправления ошибок высокому качеству?

  • Устарели ли тесты?

  • Достаточным ли количеством тестов обладает команда?

  • Обнаружены ли узкие места?

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

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

Для изменения отчета в приложении Office Excel необходимо быть членом группы безопасности TfsWarehouseDataReaders в службах аналитики SQL Server и необходимо иметь разрешение или принадлежать к группе, имеющей разрешения Члены в Продукты SharePoint для командного проекта. Дополнительные сведения см. в разделе Предоставление доступа к базам данных хранилища данных для Visual Studio ALM.

Для просмотра рабочего элемента необходимо быть членом группы Читатели или иметь разрешение Просмотр рабочих элементов на этом узле со значением Разрешить. Для создания или изменения рабочего элемента необходимо быть членом группы Участники или располагать разрешением Изменение рабочих элементов на этом узле со значением Разрешить. Дополнительные сведения см. в разделе Управление разрешениями.

Данные, отображающиеся на панели мониторинга

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

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

Панель мониторинга качества продукта

Примечание

Отчет Ход выполнения плана тестирования доступен только в том случае, если команда создает планы тестирования и выполняет тесты с использованием приложений Test Runner и Microsoft Test Manager.Сведения об определении наборов тестов и планов тестирования см. в разделе Группировка тестовых случаев в наборы тестов.

Ход выполнения, построение, диаграммы кода, отчеты Шаг 1 через Шаг 6 не отображаются, когда хранилище данных для командного проекта недоступно.

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

Веб-часть

Отображаемые данные

Связанный раздел

Шаг 1

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

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

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

Шаг 2

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

Отчет о состоянии построения

Отчет "Состояние построений" в формате Excel

Шаг 3

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

Отчет "Ход исправления ошибок" в формате Excel

Отчет "Ход исправления ошибок" в формате Excel

Шаг 4

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

Отчет "Реактивации ошибок" в формате Excel

Отчет "Реактивации ошибок" в формате Excel

Шаг 5

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

Отчет о покрытии кода

Отчет "Покрытие кода" в формате Excel

Шаг 6

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

Отчет об обновлении кода

Отчет "Обработка кода" в формате Excel

Шаг 7

Список предстоящих событий. Этот список является производным от веб-части SharePoint.

Веб-часть важных событий

Неприменимо

Шаг 8

Количество активных, разрешенных и закрытых рабочих элементов. Открыть список рабочих элементов можно посредством щелчка каждого номера. Этот список является производным от веб-части Team Web Access.

Веб-часть рабочих элементов проекта

Рабочие элементы и рабочий процесс (гибкая разработка)

9

Список последних построений и их состояний. Для просмотра дополнительных сведений выберите конкретное построение. Этот список является производным от веб-части Team Web Access.

Веб-часть последних построений

Условные обозначения:

Идет выполнение построения: построение выполняется

Построение не началось: построение не началось

Построение успешно завершено: построение успешно завершено

Ошибка построения: ошибка построения

Построение остановлено: построение остановлено

Построение выполнено частично: построение выполнено частично

Управление завершенными построениями и их просмотр

10

Список последних возвратов. Для просмотра дополнительных сведений выберите конкретный возврат. Этот список является производным от веб-части Team Web Access.

Веб-часть недавних возвратов

Работа с окнами "Возврат" и "Ожидающие изменения"

Действия, необходимые для наблюдения за качеством

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

Действия, необходимые для отслеживания хода выполнения плана тестирования

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

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

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

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

    Важно!

    Если тест проверочный, инженерам-испытателям необходимо отмечать шаг теста состоянием.Общий результат тестового случая отражает состояние всех шагов теста, отмеченных инженером-испытателем.Таким образом, тестовый случай получит состояние "Завершен неудачей", если инженер-испытатель отметил какой-либо шаг теста как завершенный неудачей или не отметил его вовсе.

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

  • (Необязательно) Назначить каждому тестовому случаю пути Итерация и Область для поддержки фильтрации.

    Примечание

    Сведения об определении путей итерации и области см. в разделе Создание и изменение областей и итераций.

Действия, необходимые для отслеживания хода исправления и реактиваций ошибок

Для обеспечения точности и актуальности отчетов "Ход исправления ошибок" и "Реактивации ошибок" команда должна выполнить следующие действия:

  • Определение ошибок.

  • Обновление Состояния каждой ошибки по мере ее исправления, проверки, закрытия или реактивации.

  • (Необязательно) Определение путей Итерация и Область для каждой ошибки, если необходимо фильтровать по этим полям.

Действия, необходимые для отслеживания состояния построения, покрытия кода и обработки кода

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

Устранение неполадок, связанных с качеством

Таблица ниже описывает специфические проблемы качества, которые можно отслеживать и для которых можно определить действия с помощью панели мониторинга "Качество".

Проблема

Просматриваемые отчеты

Примечания к устранению неполадок

Ошибки построения

Состояние построений

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

Неудачные тесты

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

Обработка кода

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

Выполнение тестов с высокой частотой обнаружения ошибок

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

Ход исправления ошибок

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

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

  • Тесты могли устареть, или была протестирована неверная функциональность.

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

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

Тесты устарели

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

Покрытие кода

Обработка кода

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

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

Команда не тестирует, не закрывает и не реактивирует разрешенные ошибки

Ход исправления ошибок

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

Слишком мало тестов

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

Обработка кода

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

Реактивации

Реактивации ошибок

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

Неадекватное модульное тестирование

Покрытие кода

Обработка кода

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

В большинстве случаев, если команда использует разработку под управлением тестов или сходные методы, покрытие кода должно приближаться к отметке 100%. Если модульные тесты используются повторно как тесты проверки построения (BVT), покрытие кода должно отображаться в соответствующих отчетах.

Настройка панели мониторинга "Качество"

Панель мониторинга "Качество" можно настроить следующими способами:

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

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

  • Добавление существующих отчетов Excel, например Тенденции ошибок и Анализ сбоя, на панель мониторинга.

Дополнительные сведения о работе с отчетами в приложении Office Excel, а также о настройке этих отчетов содержатся на следующих страницах веб-сайта Майкрософт:

См. также

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

Scrum

Панели мониторинга (гибкая разработка)

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