Панель мониторинга "Качество" (Agile и CMMI)
Панель мониторинга "Качество" можно использовать для обзора хода процессов в областях тестирования, разработки и построения, связанных с качеством программного обеспечения при разработке. Команда может использовать панель мониторинга "Качество" для изучения и принятия решений, соответствующих целям команды в отношении качества продукта.
С помощью этой панели мониторинга можно отслеживать ход выполнения тестов, состояния построений, процесс разрешения и закрытия ошибок, долю реактивации ошибок, процент протестированного кода и тенденции в изменениях кода. Каждый из этих показателей отображается для последних четырех недель.
Содержание раздела
|
Эту панель мониторинга можно использовать для ответа на следующие вопросы.
|
Требования
Те же требования, что и в разделе Панели мониторинга портала проекта.
Данные, отображаемые на панели мониторинга
Участники команды могут использовать панель мониторинга "Качество", чтобы определить общее качество разрабатываемого продукта. В идеальном случае доля успешных выполнений тестов, ошибки и обработка кода вместе демонстрируют одинаковые показатели, но зачастую происходит иначе. В случае обнаружения расхождений необходимо подробнее изучить соответствующее построение и ряд данных. Панель мониторинга "Качество" объединяет результаты тестов, покрытие кода после тестирования, обработку кода и ошибки для облегчения одновременного понимания многих перспектив.
Чтобы узнать о веб-частях, которые отображаются на панели мониторинга качества, см. приведенные далее рисунок и таблицу.
Примечание
Отчет Ход выполнения плана тестирования доступен только в том случае, если команда создает планы тестирования и выполняет тесты.
Диаграммы хода выполнения, сборки и кода, а также отчеты с по
не отображаются, когда хранилище данных для командного проекта недоступно.
Дополнительные сведения об интерпретации, обновлении и настройке диаграмм, отображаемых на панели мониторинга "Качество", см. в разделах, перечисленных в таблице ниже.
Веб-часть |
Отображаемые данные |
Связанный раздел |
---|---|---|
![]() |
Гистограмма результатов всех тестовых случаев, сгруппированных по последнему записанному результату, — Никогда не запускавшиеся, Заблокирован, Не пройден или Пройден — на протяжении последних четырех недель. ![]() |
|
![]() |
Гистограмма, отображающая количество построений с результатами Завершен неудачей или Успешно завершен на протяжении последних четырех недель. ![]() |
|
![]() |
Гистограмма совокупного количества всех ошибок, сгруппированных по состоянию, на протяжении последних четырех недель. ![]() |
|
![]() |
Гистограмма, отображающая количество ошибок, повторно активированных командой из состояния разрешенных или закрытых, на протяжении последних четырех недель. ![]() |
|
![]() |
График, отображающий процент кода, протестированного с использованием тестов проверки построения (BVT) и других тестов, на протяжении последних четырех недель. ![]() |
|
![]() |
Гистограмма, отображающая количество строк кода, добавленных, удаленных и измененных командой в возвратах перед построением, на протяжении последних четырех недель. ![]() |
|
![]() |
Список предстоящих событий. Этот список является производным от веб-части SharePoint. ![]() |
Неприменимо |
![]() |
Количество активных, разрешенных и закрытых рабочих элементов. Открыть список рабочих элементов можно путем нажатия каждого номера. Этот список является производным от веб-части Team Web Access. ![]() |
Неприменимо |
![]() |
Список последних построений и их состояний. Для просмотра дополнительных сведений выберите конкретную сборку. Этот список является производным от веб-части Team Web Access. ![]() Условные обозначения:
|
|
![]() |
Список последних возвратов. Для просмотра дополнительных сведений выберите конкретный возврат. Этот список является производным от веб-части Team Web Access. ![]() |
Действия, необходимые для наблюдения за качеством
Для обеспечения точности и актуальности панели мониторинга "Качество" команда должна выполнить действия, описанные в этом разделе.
Действия, необходимые для отслеживания хода выполнения плана тестирования
Для обеспечения точности и актуальности отчета "Ход выполнения плана тестирования" команда должна выполнить следующие действия:
Определите тестовые случаи и пользовательские истории и создайте связи Тест выполнил между тестовыми случаями и описаниями функциональности пользователей.
Определите планы тестирования и назначьте им тестовые случаи.
Для ручных тестов, отмечать результаты каждого проверочного шага в тестовом случае как "пройдено" или "не пройдено".
Важно!
Если тест проверочный, тест-инженеры должны отмечать шаги теста состояниями. Общий результат тестового случая отражает состояние всех шагов теста, отмеченных тест-инженером. Таким образом, тестовый случай получит состояние "Завершен неудачей", если инженер-испытатель отметил какой-либо шаг теста как завершенный неудачей или не отметил его вовсе.
Для автоматических тестов, каждый тестовый случай автоматически отмечается как пройденный или завершившийся неудачей.
(Необязательно) Чтобы включить фильтрацию, назначьте каждому тестовому случаю значения Путь итерации и Путь к области.
Примечание
Информацию об определении путей к областям и путей итераций см. в разделе Создание и изменение областей или итераций.
Действия, необходимые для отслеживания хода исправления и реактиваций ошибок
Для обеспечения точности и актуальности отчетов "Ход исправления ошибок" и "Реактивации ошибок" команда должна выполнить следующие действия:
Определение ошибок.
Обновление Состояния каждой ошибки по мере ее исправления, проверки, закрытия или реактивации.
(Необязательно) Задайте пути Итерация и Область для каждой ошибки, если необходимо фильтровать по этим полям.
Действия, необходимые для отслеживания состояния сборки, покрытия кода и обработки кода
Для обеспечения точности и актуальности отчетов "Состояние построения", "Покрытие кода" и "Обработка кода" участники команды должны выполнить следующие действия:
Настройка системы построения. Для использования приложения построение Team Foundation необходимо настроить систему построения.
Подробнее см. в разделе Configure and manage your build system.
Создание определений построения. Для получения кода для разных платформ можно создать несколько определений построения и выполнить каждое из них. Также каждое построение можно выполнить с использованием другой конфигурации.
Подробнее см. в разделе Определение процесса сборки.
Определение тестов для автоматического запуска в качестве части построения. Как часть определения построения можно выбрать тесты, которые будут выполняться как часть построения или в случае ошибки будут остановлены.
Подробнее см. в разделе Использование шаблона по умолчанию для процесса сборки.
Настройка тестов для сбора данных о покрытии кода. Чтобы данные о покрытии кода попали в отчет, члены команды должны инструментировать тесты для сбора этих данных.
Подробнее см. в разделе Выполнение тестов в процессе сборки.
Регулярное выполнение построения. Построения можно выполнять с регулярными интервалами или после каждого возврата. Используя запланированный триггер, можно создавать регулярные построения.
Подробнее см. в разделах Создание или изменение определения сборки и Запуск сборок, наблюдение за сборками и управление ими.
Примечание
Несмотря на то что член команды может вручную оценить построение с помощью приложения Обозреватель построений, эта оценка не отражается в отчете "Индикаторы качества построения". Оценка построения отображается в отчете "Сводка построения". Подробнее см. в разделах Оценка качества завершенной сборки и Отчет "Сводка построения".
Устранение неполадок, связанных с качеством
Таблица ниже описывает специфические проблемы качества, которые можно отслеживать и для которых можно определить действия с помощью панели мониторинга "Качество".
Ошибка |
Просматриваемые отчеты |
Примечания к устранению неполадок |
---|---|---|
Ошибки построения |
Состояние построений |
Построение, выполняемое каждую ночь, является пульсом проектов разработки программного обеспечения. Если построения не завершаются успешно или не проходят тесты проверки построения (BVT), команда должна немедленно устранить проблему. |
Неудачные тесты |
Ход выполнения плана тестирования Обработка кода |
При увеличении доли неудачных тестов и обработки кода команда может изучить причины столь частой неудачной работы программного обеспечения. Причинами могут являться либо рекомендации свободной разработки, либо тесты, слишком строгие для раннего цикла итерации. |
Выполнение тестов с высокой частотой обнаружения ошибок |
Ход выполнения плана тестирования Ход исправления ошибок |
Когда при увеличении числа выполняемых в один момент времени тестов увеличивается количество обнаруживаемых ошибок, команде следует изучить следующие возможные причины:
|
Тесты устарели |
Ход выполнения плана тестирования Покрытие кода Обработка кода |
Когда выполняется большое число тестов, значительный объем кода изменяется и покрытие кода уменьшается, команде не следует выполнять тесты, использующие новый код. Поскольку тесты не разрабатываются с той же скоростью, с какой меняется код, покрытие теста может становиться менее и менее адекватным. |
Команда не тестирует, не закрывает и не реактивирует разрешенные ошибки |
Ход исправления ошибок |
Когда в отчете "Ход устранения ошибок" для разрешенных ошибок происходит увеличение числа ошибок, разработчики разрешают ошибки, но тест-инженеры не подтверждают и не закрывают их. Команде следует изучить, почему был разработан этот шаблон. |
Слишком мало тестов |
Ход выполнения плана тестирования Обработка кода |
Когда выполняется небольшое число тестов, обработка кода высока, а покрытие кода меньше ожидаемого, команде, возможно, следует выделить больше ресурсов для тестов. Кроме того, следует убедиться, что инженеры-испытатели работают над теми же функциями, что и остальная часть команды. |
Реактивации |
Реактивации ошибок |
Если команда реактивирует ошибки с высокой или возрастающей частотой, инженеры-испытатели зачастую отклоняют исправления разработчиков. Команде необходимо решить эти проблемы, чтобы избежать выделения значительных ресурсов ради повторной обработки отклоненных исправлений. Возможными причинами являются плохая отчетность об ошибках, плохое управление лабораторией тестирования или излишне агрессивное рассмотрение. |
Неадекватное модульное тестирование |
Покрытие кода Обработка кода |
Когда убывание в покрытии кода совпадает с увеличением в обработке кода, разработчики могут возвратить код для покрытия без каких-либо соответствующих модульных тестов. В большинстве случаев, если команда использует разработку под управлением тестов или сходные методы, покрытие кода должно приближаться к отметке 100%. Если модульные тесты используются повторно как тесты проверки построения (BVT), покрытие кода должно отображаться в соответствующих отчетах. |