Часто задаваемые вопросы по планам тестирования

Azure Test Plans использует три уровня доступа:

• Stakeholder: может предоставлять отзывы с помощью расширения Test & Feedback, но не может получить доступ к порталу Test Plans.
• Базовый: может выполнять тестовые случаи, пометить результаты теста и просмотреть диаграммы и отчеты.
• Basic + Test Plans: полные возможности, включая создание и управление планами тестирования, наборами тестов, тестовыми вариантами, конфигурациями и параметрами. Visual Studio Enterprise, Visual Studio Test Professional и подписки MSDN Platforms включают эквивалентный доступ.

Полная матрица разрешений приведена в разделе Доступ и разрешения на ручное тестирование.

Вкладка Define доступна только пользователям с доступом Basic + Test Plans или эквивалентом. Пользователи с уровнем доступа Basic могут использовать вкладки Execute и Chart, но не могут создавать или управлять тестовыми случаями через вкладку Define. Чтобы получить доступ, попросите администратора назначить вам уровень доступа Basic + Test Plans.

Azure Test Plans поддерживает три типа наборов тестов:

• Статические наборы тестов: вручную упорядочивать тестовые случаи в группы. Используйте статические наборы, если вы хотите вручную выбрать связанные тестовые случаи.
• Наборы тестов на основе требований: автоматическое связывание тестовых случаев с элементами невыполненной работы (пользовательские истории, элементы невыполненной работы продукта). Используйте наборы на основе требований для отслеживания тестового покрытия по требованиям. Этот тип набора является единственным способом обеспечения сквозной трассировки требований.
• Наборы тестов на основе запросов: автоматически заполняйте тестовые случаи на основе запроса рабочего элемента (например, все тестовые случаи с приоритетом=1). Набор обновляется всякий раз, когда результаты запроса изменяются.

Дополнительные сведения см. в разделе "Тестовые объекты и термины".

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

Yes. Выберите "Печать " в диалоговом окне "Экспорт" , а затем нажмите кнопку "Отмена " в диалоговом окне "Печать ", чтобы отобразить данные в отчете. Выделите весь текст и скопируйте его в документ Word. Форматирование отчета сохраняется.

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

Эта проблема может возникнуть, если вам будет предложено ввести учетные данные при выборе ссылки. Без выхода из Azure DevOps выберите View Tests, чтобы просмотреть нужный набор тестов и соответствующие тесты.

В Планах тестирования используйте каталог для поиска ваших планов тестирования.

• Mine: отображает тестовые планы для команд, которым вы принадлежите, а также ваши избранные команды. Планы группируются по командам.
• All: отображает все тестовые планы в проекте. Вы можете добавить планы в избранное в этом представлении.

Используйте элементы управления фильтра для поиска по имени, команде, состоянию или итерации. Дополнительные сведения см. в разделе Navigate Test Plans.

Yes. См. примеры тестирования копирования.

Yes. Нажмите Shift+Enter в поле действий или ожиданий результатов, чтобы добавить дополнительную строку.

Выберите тестовый шаг. Нажмите клавиши ALT+P , чтобы вставить новый шаг теста над выбранным шагом.

См. Удаление тестовых артефактов.

Тестовые случаи можно импортировать и экспортировать в массовом режиме с помощью CSV-файлов или XLSX. Импорт позволяет создавать новые тестовые случаи или обновлять существующие (включая идентификаторы тестовых вариантов). Экспорт позволяет скачать сведения о тестовом случае, включая пользовательские столбцы.

Пошаговые инструкции см. в статье "Массовый импорт и экспорт тестовых случаев".

Yes. В том же CSV-файле или XLSX оставьте поле идентификатора пустым для новых тестовых случаев и добавьте существующий идентификатор для обновлений.

Мастер импорта проверяет файл на каждом этапе — отправку файлов, сопоставление полей и до окончательного импорта. Он отображает ошибки в строке, и их необходимо устранить перед тем, как продолжить импорт.

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

Чтобы устранить ошибки, исправьте CSV-файл или XLSX, перезагрузите его и завершите импорт.

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

Для других типов рабочих элементов (пользовательские истории, задачи, ошибки) см. Массовый импорт или обновление (CSV).

Включите следующие девять заголовков с точной орфографией:

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

Действительны следующие ограничения.

• Тестовые случаи должны находиться в состоянии проектирования во время импорта.
• Названия тестового случая не могут превышать 128 символов.
• Импорт и экспорт файлов имеет ограничение размера 20 МБ.
• У вас должны быть разрешения для области и путей итерации целевого тестового плана и набора тестов.
• Операции завершаются сбоем, если тестовый случай имеет более 1000 связанных ссылок.

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

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

Вы выполняете контрольные точки, а не тестовые случаи напрямую. Точка тестирования — это уникальное сочетание тестового случая, набора тестов, конфигурации и средства тестирования. Например, если тестовый случай назначен двумя конфигурациями браузера (Chrome и Edge), то создается две точки тестирования — по одному для каждой конфигурации. На вкладке "Выполнение" отображается последний результат выполнения для каждой точки тестирования.

При выполнении тестов на вкладке "Выполнение " можно выбрать один из следующих средств выполнения:

• Запускатель тестов на основе веб-браузера: проводит ручные тесты в браузере. Можно при желании выбрать конкретную сборку, с которой можно связать результаты.
• Test Runner client (desktop): Десктопное приложение для тестирования десктопных приложений.
• Автоматические тесты с помощью этапа выпуска: активирует автоматическое выполнение тестов из конвейера сборки и выпуска.

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

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

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

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

• Снимки экрана: создание аннотированных снимков экрана во время выполнения теста.
• Журнал действий изображения: автоматически фиксирует взаимодействие с приложением в виде пошагового визуального журнала.
• Записи экрана: запишите экран во время тестирования. Записи автоматически останавливаются через 10 минут.

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

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

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

Выберите "Настроить " и выберите нужный параметр в контекстном меню диаграммы.

Отчет о ходе выполнения имеет следующие ограничения:

• Отображает данные для одного или нескольких планов тестирования только по одному проекту. Для создания межпроектной отчетности используйте API OData.
• Данные обновляются примерно каждые 15 минут и не в режиме реального времени.
• Процентные значения не отображают десятичные знаки.
• Результаты, такие как Заблокированные и Не применимые, не отражены в Проценте успешных тестов или Проценте неудачных тестов, что может показать разрыв между Процентом выполнения тестов и суммой Процента успешных тестов и Процента неудачных тестов.
• Данные из планов тестирования перемещенные с локальной версии Azure DevOps Server не отображаются.

Дополнительные сведения см. в отчете о ходе выполнения.

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

Вам потребуется разрешение уровня проекта Управление конфигурациями тестов с параметром Разрешить. По умолчанию это разрешение предоставляется членам групп Contributors и Администраторы проекта.

Вы можете связать автоматизированные методы тестирования с рабочими элементами тестов, чтобы их можно было запустить из Test Plans. В Visual Studio откройте Test Explorer, выберите метод теста и выберите Связать с тестовым случаем. Вы также можете связать тесты с помощью конвейера сборки в Azure DevOps.

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

Поддерживаются следующие платформы тестирования:

• Visual Studio ассоциации: MSTest v1/v2, NUnit, xUnit, Selenium, Закодированный пользовательский интерфейс
• Azure DevOps ассоциации: Java (Maven/Gradle с JUnit), JavaScript (Jest), Python (PyTest)
• .NET Core: поддерживается с помощью Visual Studio 15.9 или более поздней версии с файлом .runsettings

Тесты из репозиториев GitHub также поддерживаются при выполнении Azure Pipelines с задачами VSTest или PublishTestResults.

Yes. Вы можете использовать как YAML, так и классические конвейеры для выполнения автоматических тестов из планов тестирования. Настройте конвейер сборки в параметрах плана тестирования и настройте конвейер выпуска (классический или YAML) для автоматического выполнения тестов по запросу.

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

Yes. Используйте команду Run с параметрами . Откройте контекстное меню для набора тестов и выберите "Выполнить с параметрами", а затем укажите:

• Тип теста и средство запуска: выберите автоматизированные тесты с использованием Release Stage.
• Сборка: выберите сборку, в которую есть тестовые двоичные файлы. Результаты теста ассоциированы с этой сборкой.
• Конвейер выпуска: выберите конвейер, который может использовать выбранный артефакт сборки.
• Этап выпуска: выберите этап, настроенный в конвейере выпуска.

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

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

Мы рекомендуем отдельный конвейер выпуска и этап для автоматического тестирования по запросу, так как:

• Запланированные этапы обычно внедряют приложение в первую очередь — возможно, вам не потребуется полное внедрение каждый раз при проведении нескольких тестов.
• Каждый запуск по запросу инициирует новый выпуск. Большие объемы выпусков по запросу могут затруднять поиск запланированных релизов для тестирования и производственных релизов.
• Может потребоваться настроить задачу тестирования Visual Studio с помощью идентификатора Test run для трассировки того, что вызвало каждый выпуск.

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

Дополнительные сведения см. в разделе Сборка и агенты выпуска, Развертывание агента на Windows и Агентные пулы.

При выборе тестов с использованиемтестового запуска подсистема управления тестами передает список выбранных тестов через объект тестового запуска. Задача тестирования Visual Studio ищет идентификатор тестового запуска, извлекает сведения о выполнении теста (имена контейнеров и методов тестирования), выполняет тесты, обновляет результаты и задает связанные точки тестирования.

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

Используйте файл runsettings для передачи значений в качестве параметров. Например, в релизе с несколькими этапами можно передать соответствующий URL приложения в тестовую задачу каждого этапа. Укажите файл runsettings и переопределите параметры в задаче Visual Studio Test.

Да, если выполнены следующие условия:

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

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

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

Рабочий процесс по запросу оптимизирован для одной сборки Azure Pipelines. Поддержка выпусков с несколькими артефактами и источников артефактов, отличных от Azure Pipelines (например, Jenkins), оценивается на основе отзывов пользователей.

См. статью "Начало работы с тестированием Selenium".

По умолчанию Azure DevOps удаляет все результаты теста через год (365 дней), если вы не сохраняете сборку, связанную с этими результатами. У старых проектов может быть не настроено автоматическое удаление.

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

См. раздел "Настройка политик хранения тестов".

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

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

Получите доступ к Центру управления тестовым запуском из Test Plans>Runs. Дополнительные сведения см. в разделе "Тестовые запуски".

Видеозаписи, созданные расширением Test и Feedback, можно просмотреть в браузере Google Chrome и в видеопроигрыватель VLC.

Расширение Test & Feedback совместимо с Azure DevOps Server (прежнее название — Team Foundation Server) 2015 года и более поздними версиями. Все пользователи, включая пользователей, которым предоставлено Stakeholder access, могут использовать расширение в подключенном режиме. Функциональные возможности, связанные с аналитикой сеансов и запросом и предоставлением потока обратной связи, требуют Azure DevOps Server 2017 или более поздних версий.

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

Расширение Тест и Обратная связь доступно для Google Chrome и Microsoft Edge. Доступность компонентов зависит от браузера — для полной матрицы совместимости см. раздел "Установка расширения тестирования и отзывов".

• режим Connected: расширение подключается к Azure DevOps или Azure DevOps Server. Вы можете создавать ошибки и задачи, которые автоматически связаны с вашим сеансом исследовательского тестирования, просматривать информацию о сеансе и использовать поток запроса и предоставления обратной связи.
• режим Standalone: используйте расширение без подключения к Azure DevOps. Вы можете записывать снимки экрана, заметки и записи с экрана, а затем экспортировать их в виде HTML-отчета. Автономный режим полезен для нерегламентированного тестирования.

Дополнительные сведения см. вExploratory Testing с расширением Test & Feedback в подключенном режиме и автономном режиме.

Связанный контент

• Создание тестового плана
• Создание тестовых вариантов
• Выполнение ручных тестов
• Запустите автоматические тесты из планов тестирования
• Отслеживание состояния теста
• Управление доступом к тестам и разрешениями