Панель мониторинга "Качество" (CMMI)
Во время разработки ПО с помощью панели мониторинга "Качество" можно отслеживать ход выполнения тестов, состояния сборок, процесс разрешения и закрытия ошибок, долю реактивации ошибок, процент протестированного кода и тенденции в изменениях кода. Каждый из этих показателей отображается для последних четырех недель. Команда может использовать панель мониторинга "Качество" для принятия решений, соответствующих целям команды в отношении качества продукта.
Примечание
Доступ к панелям мониторинга осуществляется на портале командного проекта.Доступ к панели мониторинга "Качество" возможен только в том случае, если этот портал работает и настроен на использование SharePoint Server Enterprise Edition.Дополнительные сведения см. в разделе Панели мониторинга.
В этом разделе
|
Эту панель мониторинга можно использовать для ответа на следующие вопросы.
|
Необходимые разрешения
Для просмотра панели мониторинга необходимо иметь разрешение или принадлежать к группе, имеющей разрешение Чтение в Продукты SharePoint для командного проекта. Для изменения, копирования или настройки панели мониторинга необходимо иметь разрешение или принадлежать к группе, имеющей разрешения Члены в Продукты SharePoint для командного проекта. Дополнительные сведения см. в разделе Добавление пользователей в командные проекты.
Для изменения отчета в приложении Office Excel необходимо быть членом группы безопасности TfsWarehouseDataReaders в службах аналитики SQL Server и необходимо иметь разрешение или принадлежать к группе, имеющей разрешения Члены в Продукты SharePoint для командного проекта. Дополнительные сведения см. в разделе Предоставление доступа к базам данных хранилища данных для Visual Studio ALM.
Для просмотра рабочего элемента необходимо быть членом группы Читатели или иметь разрешение Просмотр рабочих элементов на этом узле со значением Разрешить. Для создания или изменения рабочего элемента необходимо быть членом группы Участники или располагать разрешением Изменение рабочих элементов на этом узле со значением Разрешить.
Данные, отображаемые на панели мониторинга
Участники команды могут использовать панель мониторинга "Качество", чтобы определить общее качество разрабатываемого продукта. В идеальном случае доля успешных выполнений тестов, ошибки и обработка кода вместе демонстрируют одинаковые показатели, но зачастую происходит иначе. В случае обнаружения расхождений необходимо подробнее изучить соответствующее построение и ряд данных. Панель мониторинга "Качество" объединяет результаты тестов, покрытие кода после тестирования, обработку кода и ошибки для облегчения одновременного понимания многих перспектив.
Чтобы узнать о веб-частях, которые отображаются на панели мониторинга качества, см. приведенные далее рисунок и таблицу.
Примечание
Отчет Ход выполнения плана тестирования доступен только в том случае, если команда создает планы тестирования и выполняет тесты с использованием приложений Test Runner и Microsoft Test Manager.
Ход выполнения, построение, диаграммы кода, отчеты через не отображаются, когда хранилище данных для командного проекта недоступно.
Дополнительные сведения об интерпретации, обновлении и настройке диаграмм, отображаемых на панели мониторинга "Качество", см. в разделах, перечисленных в таблице ниже.
Веб-часть |
Отображаемые данные |
Связанный раздел |
---|---|---|
Гистограмма результатов всех тестов, сгруппированных по последнему записанному результату, — Никогда не выполнялся, Заблокирован, Завершен неудачей или Завершен — на протяжении последних четырех недель. |
||
Гистограмма, отображающая количество построений с результатами Завершен неудачей или Успешно завершен на протяжении последних четырех недель. |
||
Гистограмма совокупного количества всех ошибок, сгруппированных по состоянию, на протяжении последних четырех недель. |
||
Гистограмма, отображающая количество ошибок, повторно активированных командой из состояния разрешенных или закрытых, на протяжении последних четырех недель. |
||
График, отображающий процент кода, протестированного с использованием тестов проверки построения (BVT) и других тестов, на протяжении последних четырех недель. |
||
Гистограмма, отображающая количество строк кода, добавленных, удаленных и измененных командой в возвратах перед построением, на протяжении последних четырех недель. |
||
Список предстоящих событий. Этот список является производным от веб-части SharePoint. |
Неприменимо |
|
Количество активных, разрешенных и закрытых рабочих элементов. Открыть список рабочих элементов можно путем нажатия каждого номера. Этот список является производным от веб-части Team Web Access. |
Типы и рабочий процесс рабочего элемента шаблона процесса CMMI |
|
Список последних построений и их состояний. Для просмотра дополнительных сведений выберите конкретную сборку. Этот список является производным от веб-части Team Web Access. Условные обозначения: : Сборка не начата : Выполняется сборка : Сборка успешно завершена : Ошибка сборки : Сборка остановлена : Сборка частично успешно выполнена |
||
Список последних возвратов. Для просмотра дополнительных сведений выберите конкретный возврат. Этот список является производным от веб-части Team Web Access. |
Действия, необходимые для наблюдения за качеством
Для обеспечения точности и актуальности панели мониторинга "Качество" команда должна выполнить действия, описанные в этом разделе.
Действия, необходимые для отслеживания хода выполнения плана тестирования
Для обеспечения точности и актуальности отчета "Ход выполнения плана тестирования" команда должна выполнить следующие действия:
Определите тестовые случаи и требования и создайте связи Тест выполнил между тестовыми случаями и требованиями.
Определите планы тестирования и назначьте им тестовые случаи.
Для ручных тестов следует отмечать результаты каждого проверочного шага в тестовом случае как "Пройден" или "Не пройден".
Важно!
Тестерам следует отмечать шаг проверочного теста состоянием.Общий результат тестового случая отражает состояние всех шагов теста, отмеченных тест-инженером.Таким образом, тестовый случай получит состояние "Завершен неудачей", если инженер-испытатель отметил какой-либо шаг теста как завершенный неудачей или не отметил его вовсе.
Для автоматических тестов каждый тестовый случай автоматически отмечается как пройденный или непройденный.
(Необязательно) Назначение каждому тестовому случаю значения Путь итерации и Путь к области для поддержки фильтрации.
Примечание
Сведения об определении путей к итерациям и областям см. в разделе Добавление и изменение области и путей итерации.
Действия, необходимые для отслеживания хода исправления и реактиваций ошибок
Для обеспечения точности и актуальности отчетов "Ход исправления ошибок" и "Реактивации ошибок" команда должна выполнить следующие действия:
Определение ошибок.
Обновление Состояния каждой ошибки по мере ее исправления, проверки, закрытия или реактивации.
(Необязательно) Задайте пути Итерация и Область для каждой ошибки, если необходимо фильтровать по этим полям.
Действия, необходимые для отслеживания состояния сборки, покрытия кода и обработки кода
Для обеспечения точности и актуальности отчетов "Состояние построения", "Покрытие кода" и "Обработка кода" участники команды должны выполнить следующие действия:
Настройка системы построения. Для использования приложения Team Foundation Build необходимо настроить систему построения.
Дополнительные сведения см. в разделе Configuring Your Build System.
Создание определений построения. Для получения кода для разных платформ можно создать несколько определений построения и выполнить каждое из них. Также каждое построение можно выполнить с использованием другой конфигурации.
Дополнительные сведения см. в разделе Определение процесса сборки.
Определение тестов для автоматического запуска в качестве части построения. Как часть определения построения можно выбрать тесты, которые будут выполняться как часть построения или в случае ошибки будут остановлены.
Дополнительные сведения см. в разделе Использование шаблона по умолчанию для процесса сборки.
Настройка тестов для сбора данных о покрытии кода. Чтобы данные о покрытии кода попали в отчет, члены команды должны инструментировать тесты для сбора этих данных.
Дополнительные сведения см. в разделах Больше не рекомендуется настраивать покрытие кода с использованием параметров тестирования и How to: Gather Code-Coverage Data with Generic Tests.
Регулярное выполнение построений. Построения можно выполнять с регулярными интервалами или после каждого возврата. Используя запланированный триггер, можно создавать регулярные построения.
Дополнительные сведения см. в разделах Создание или изменение определения сборки и Запуск сборок, наблюдение за сборками и управление ими.
Примечание
Несмотря на то что член команды может вручную оценить построение с помощью приложения Обозреватель сборки, эта оценка не отражается в отчете "Индикаторы качества построения".Оценка построения отображается в отчете "Сводка построения".Дополнительные сведения см. в разделах Оценка качества завершенной сборки и Отчет "Сводка построения".
Устранение неполадок, связанных с качеством
Таблица ниже описывает специфические проблемы качества, которые можно отслеживать и для которых можно определить действия с помощью панели мониторинга "Качество".
Проблема |
Просматриваемые отчеты |
Примечания к устранению неполадок |
---|---|---|
Ошибки построения |
Состояние построений |
Построение, выполняемое каждую ночь, является пульсом проектов разработки программного обеспечения. Если построения не завершаются успешно или не проходят тесты проверки построения (BVT), команда должна немедленно устранить проблему. |
Неудачные тесты |
Ход выполнения плана тестирования Обработка кода |
При увеличении доли неудачных тестов и обработки кода команда может изучить причины столь частой неудачной работы программного обеспечения. Причинами могут являться либо рекомендации свободной разработки, либо тесты, слишком строгие для раннего цикла итерации. |
Выполнение тестов с высокой частотой обнаружения ошибок |
Ход выполнения плана тестирования Ход устранения ошибок |
Когда при увеличении числа выполняемых в один момент времени тестов увеличивается количество обнаруживаемых ошибок, команде следует изучить следующие возможные причины:
|
Тесты устарели |
Ход выполнения плана тестирования Покрытие кода Обработка кода |
Когда выполняется большое число тестов, значительный объем кода изменяется и покрытие кода уменьшается, команде не следует выполнять тесты, использующие новый код. Поскольку тесты не разрабатываются с той же скоростью, с какой меняется код, покрытие теста может становиться менее и менее адекватным. |
Команда не тестирует, не закрывает и не реактивирует разрешенные ошибки |
Ход устранения ошибок |
Когда в отчете "Ход устранения ошибок" для разрешенных ошибок происходит увеличение числа ошибок, разработчики разрешают ошибки, но тест-инженеры не подтверждают и не закрывают их. Команде следует изучить, почему был разработан этот шаблон. |
Слишком мало тестов |
Ход выполнения плана тестирования Обработка кода |
Когда выполняется небольшое число тестов, обработка кода высока, а покрытие кода меньше ожидаемого, команде, возможно, следует выделить больше ресурсов для тестов. Кроме того, следует убедиться, что инженеры-испытатели работают над теми же функциями, что и остальная часть команды. |
Реактивации |
Реактивации ошибок |
Если команда реактивирует ошибки с высокой или возрастающей частотой, инженеры-испытатели зачастую отклоняют исправления разработчиков. Команде необходимо решить эти проблемы, чтобы избежать выделения значительных ресурсов ради повторной обработки отклоненных исправлений. Возможными причинами являются плохая отчетность об ошибках, плохое управление лабораторией тестирования или излишне агрессивное рассмотрение. |
Неадекватное модульное тестирование |
Покрытие кода Обработка кода |
Когда убывание в покрытии кода совпадает с увеличением в обработке кода, разработчики могут возвратить код для покрытия без каких-либо соответствующих модульных тестов. В большинстве случаев, если команда использует разработку под управлением тестов или сходные методы, покрытие кода должно приближаться к отметке 100%. Если модульные тесты используются повторно как тесты проверки построения (BVT), покрытие кода должно отображаться в соответствующих отчетах. |
Настройка панели мониторинга "Качество"
Панель мониторинга "Качество" можно настроить следующими способами:
Изменение фильтров для каждого отчета Excel, чтобы сосредоточить внимание на определенных областях продуктов и итерациях.
Добавление веб-части пользовательского запроса, которая отображает список рабочих элементов, найденных по запросу. Например, можно добавить запрос для внесения в список всех активных ошибок, не связанных с тестовым случаем. Этот запрос отобразит объем ошибок, включенных в отчет, но не обнаруженных в ходе тестирования, и поэтому не подвергнутых тесту регрессии.
Добавление существующих отчетов Excel, например Тенденции ошибок и Анализ сбоя, на панель мониторинга.
Дополнительные сведения о работе с отчетами в приложении Office Excel, а также о настройке этих отчетов содержатся на следующих страницах веб-сайта Майкрософт: