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


Панель мониторинга "Качество" (Agile и CMMI)

 

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

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

Содержание раздела

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

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

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

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

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

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

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

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

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

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

Требования

Те же требования, что и в разделе Панели мониторинга портала проекта.

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

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

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

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

Примечание

Отчет Ход выполнения плана тестирования доступен только в том случае, если команда создает планы тестирования и выполняет тесты.

Диаграммы хода выполнения, сборки и кода, а также отчеты с Шаг 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.  

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

Разработка кода и управление ожидающими изменениями

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

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

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

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

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

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

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

    Важно!

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

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

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

    Примечание

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

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

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

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

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

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

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

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

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

    Подробнее см. в разделе Configure and manage your build system.

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

    Подробнее см. в разделе Определение процесса сборки.

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

    Подробнее см. в разделе Использование шаблона по умолчанию для процесса сборки.

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

    Подробнее см. в разделе Выполнение тестов в процессе сборки.

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

    Подробнее см. в разделах Создание или изменение определения сборки и Запуск сборок, наблюдение за сборками и управление ими.

    Примечание

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

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

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

Ошибка

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Реактивации

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

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

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

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

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

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

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

См. также

Панели мониторинга портала проекта