Справочник по параметрам командной строки Microsoft.Testing.Platform (MTP)

В этой статье приведена центральная точка входа для параметров командной строки MTP.

Important

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

Параметры платформы

@

Указывает имя файла ответа. Имя файла ответа должно немедленно следовать символу @ без пробела между символом @ и именем файла ответа.

Параметры в файле ответа интерпретируются так, как если бы они присутствовали в этом месте в командной строке. Символ обратной косой черты \ нельзя использовать для объединения строк. Использование файла ответа помогает выполнять очень длинные команды, которые могут превышать ограничения терминала. Файл ответа можно объединить с встроенными аргументами командной строки. Рассмотрим пример.
```
./TestExecutable.exe @"filter.rsp" --timeout 10s
```
где filter.rsp может содержать следующее содержимое:
```
--filter "A very long filter"
```
Или один файл rsp можно использовать для указания времени ожидания и фильтрации следующим образом:
```
./TestExecutable.exe @"arguments.rsp"
```
```
--filter "A very long filter" --timeout 10s
```
Замечание

При использовании dotnet test средство синтаксического анализа командной строки SDK использует подход, при котором каждой строке соответствует один маркер, где каждая строка в файле ответа рассматривается как один маркер. В этом случае каждый аргумент должен находиться в отдельной строке:
```
--filter
A very long filter
--timeout
10s
```
--config-file

Указывает файл testconfig.json.
--debug

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

Замечание

Этот параметр доступен в MTP начиная с версии 1.9.0. Он заменяет предыдущий --debug-wait-attach параметр (представленный в MTP 1.6.0); старое имя было удалено и больше не должно использоваться.
--diagnostic

Включает ведение журнала диагностики. Уровень журнала по умолчанию — Trace. Для каждого тестового источника MTP записывает <asm>_<tfm>_<arch>_<timestamp>.diag. Если метки времени совпадают, MTP добавляет суффикс с идентификатором процесса и счётчиком вместо того, чтобы перезаписывать существующий файл.
--diagnostic-synchronous-write

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

Замечание

Доступно в MTP начиная с версии 2.0.0. Он заменяет предыдущий --diagnostic-filelogger-synchronouswrite параметр, который был удален в MTP 2.0.0.
--diagnostic-output-directory

Каталог вывода журнала диагностики: если не указан, файл создается в каталоге по умолчанию TestResults.
--diagnostic-file-prefix

Префикс имени файла журнала. Значение по умолчанию — <asm>_<tfm>_<arch>.

Замечание

Доступно в MTP начиная с версии 2.0.0. Он заменяет предыдущий --diagnostic-output-fileprefix параметр, который был удален в MTP 2.0.0.
--diagnostic-verbosity

Определяет уровень детализации при использовании переключателя --diagnostic. Доступные значения: Trace, Debug, Information, Warning, Errorили Critical.
--enable-dynamic-extensions

Включает загрузку расширений, объявленных файлами манифеста *.testingplatformextensions.json, расположенными рядом с тестовым приложением. Динамические расширения отключены по умолчанию. Сведения о требованиях к безопасности и схеме манифеста см. в разделе "Динамические расширения загрузки".

Замечание

Этот параметр доступен в MTP начиная с версии 2.4.0.
--exit-on-process-exit

Завершите тестовый процесс, если зависимый процесс завершится. Необходимо указать PID.
--filter-uid

Фильтрует запускаемые тесты по уникальным идентификаторам узлов тестов. Принимает один или несколько уникальных идентификаторов.

Авторы фреймворков должны учитывать TestNodeUidListFilter для обнаружения и выполнения. Инструкции по реализации см. в разделе «Соблюдение фильтров запросов».

Замечание

Этот параметр доступен в MTP начиная с версии 1.8.0. Начиная с MTP 2.3.0, нельзя использовать --filter-uid вместе с --treenode-filter; при указании обоих параметров проверка командной строки завершится ошибкой с кодом выхода InvalidCommandLine.
--help

Выводит описание использования команды.
--ignore-exit-code

Позволяет игнорировать некоторые коды выхода, отличные от нуля, и вместо этого возвращается как 0. Дополнительные сведения см. в разделе Игнорировать определенные коды выхода.
--info

Отображает дополнительные сведения о тестовом приложении .NET, например:
- Платформа.
- Среда.
- Каждый зарегистрированный поставщик командной строки, например name, version, description и options.
- Каждое зарегистрированное средство, например command, name, version, description, и все поставщики командной строки.
Эта функция используется для понимания расширений, которые регистрируют один и тот же параметр командной строки или изменения доступных параметров между несколькими версиями расширения (или платформой).
--list-tests

Выводит список доступных тестов без их выполнения. При необходимости принимает аргумент, который управляет форматом выходных данных: text (по умолчанию, удобочитаемым человеком) или json.

Сведения о структурированных метаданных и пример см. в разделе Обнаружение тестов в формате JSON.

Замечание

Формат json выходных данных доступен в MTP начиная с версии 2.3.0.
--maximum-failed-tests

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

Авторы фреймворка должны реализовывать и регистрировать IGracefulStopTestExecutionCapability, а также регистрировать поставщик параметров с помощью AddMaximumFailedTestsService. Документация по возможностям включает примеры реализации и регистрации. Авторам тестов не нужно реализовывать эту возможность, если их платформа уже поддерживает этот параметр.

Замечание

Эта функция доступна в MTP начиная с версии 1.5.
--minimum-expected-tests

Указывает положительное минимальное количество тестов, которые должны выполняться. Если при запуске выполняется меньше тестов, в том числе ни одного, запуск завершается с кодом 9. Явно заданный минимум имеет приоритет над --zero-tests-policy.

С dotnet test этот параметр применяется ко всему запуску, если параметр указан до --, и к каждому тестовому модулю, если параметр указан после --. Дополнительные сведения см. в разделе "Минимальные значения для всего выполнения и каждого модуля".

Замечание

--minimum-expected-tests 0 недопустим. Чтобы подавить код выхода при отсутствии тестов, используйте --ignore-exit-code 8.
--no-banner

Отключает баннер запуска, сообщение об авторских правах и баннер телеметрии. Тот же эффект можно получить с помощью TESTINGPLATFORM_NOBANNER или DOTNET_NOLOGOпеременных среды.
--results-directory

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

С dotnet test значение по умолчанию зависит от версий SDK и MTP. Сведения об общем корневом каталоге, относительном к вызову, требованиях к версии и переопределениях структуры артефактов см. в разделе «Результаты и артефакты».

Чтобы изолировать несколько тестовых приложений, передайте параметр SDK --results-directory-layout per-module перед --. Эта опция относится к SDK, а не к ядру MTP, и недоступна при прямом запуске тестового приложения.
--server

Запускает тестовое приложение в JSON-RPC режиме сервера для интеграции редактора, интегрированной среды разработки или средства. Опустить значение или использовать jsonrpc. Сведения о поддерживаемом клиенте, работающем только как источник, см. в режиме сервера MTP.

Important

Значение dotnettestcli и его аргументы транспорта являются внутренними для интеграции пакета SDK .NET. Не передайте их вручную.
--show-slowest-tests

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

Замечание

Этот параметр доступен в MTP начиная с версии 2.4.0.
--timeout

Тайм-аут выполнения глобального теста. Принимает один аргумент в виде строки в формате <value>[h|m|s], где <value> плавает.
--treenode-filter

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

Замечание

Начиная с MTP 2.3.0, нельзя использовать --treenode-filter вместе с --filter-uid; при указании обоих параметров проверка командной строки завершится ошибкой с кодом выхода InvalidCommandLine.
--zero-tests-policy

Определяет, считается ли ошибкой запуск, в котором не был выполнен ни один тест, поскольку все тесты были пропущены. Допустимые значения: allow-skipped (по умолчанию) и strict. При allow-skipped выполнение запуска, в котором все этапы пропущены, завершается успешно. В случае strictсбоя код выхода завершается ошибкой 8. Явно заданное значение --minimum-expected-tests имеет приоритет над этой политикой и использует код выхода 9, если минимальное требование не соблюдено.

Замечание

Этот параметр доступен в MTP начиная с версии 2.3.0. При использовании dotnet test передайте параметр после --, чтобы передать его в каждый тестовый модуль. Если вы не задаёте глобальный минимум, SDK .NET 11 отдельно определяет результат для всего запуска при отсутствии выполненных тестов. Дополнительные сведения см. в разделе "Минимальные значения для всего выполнения и каждого модуля".

Обнаружение тестов в формате JSON

Начиная с MTP 2.3.0, используйте --list-tests json для обнаружения тестов в виде машиночитаемого JSON-документа вместо анализа списка, предназначенного для чтения человеком:

dotnet Contoso.MyTests.dll --list-tests json --no-banner

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

Не сочетайте режим обнаружения с параметрами, предназначенными только для выполнения, такими как --report-trx. Если testconfig.json включает эти параметры, используйте --config-file с отдельной конфигурацией обнаружения, не содержащей эти параметры.

Документ содержит schemaVersion и массив tests. Каждый тест включает uid и displayName. Необязательные поля включают type, location, traits и properties, когда среда тестирования предоставляет соответствующие метаданные. Например, тест с признаком Environment может давать:

{
  "schemaVersion": 1,
  "tests": [
    {
      "uid": "<test-uid>",
      "displayName": "ConnectToService",
      "traits": [
        { "key": "Environment", "value": "Staging" }
      ]
    }
  ]
}

И properties, и traits используют массивы пар "ключ-значение", а не объекты JSON. Не предполагайте, что ключи уникальны. Атрибуты представляют открытые TestMetadataProperty значения, включая категории MSTest и пользовательские TestProperty значения. Массив properties содержит сериализуемые строковые свойства, предоставляемые платформой или уровнем совместимости. Он экспортирует не все свойства, хранящиеся в памяти, а его внутренний тип SerializableKeyValuePairStringProperty не представляет собой API для внешних фреймворков или расширений.

Используйте обнаруженные UID с --filter-uid для выполнения выбранных тестов. Для типизированного клиента .NET с обнаружением, выполнением, отменой и динамическими обновлениями используйте режим сервера MTP.

Опции расширения в зависимости от сценария

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

Сценарий	Обязательный компонент	Документация по функциям
Сбор данных о покрытии кода	`Microsoft.Testing.Extensions.CodeCoverage` или `coverlet.MTP`	Покрытие кода
Сбор дампов сбоев или зависаний	`Microsoft.Testing.Extensions.CrashDump` или `Microsoft.Testing.Extensions.HangDump`	Аварийное завершение и зависание дампов
Создание тестовых отчетов	Пакет расширения для выбранного формата, например `Microsoft.Testing.Extensions.TrxReport`	Тестовые отчеты
Настройка выходных данных терминала	Ядро MTP (без дополнительного пакета)	Выходные данные терминала
Повторная проверка неудачных тестов	`Microsoft.Testing.Extensions.Retry`	повторная попытка

Поиск параметров в тестовом приложении

Запустите тестовый исполняемый файл с --help или запустите dotnet test --help в режиме MTP, чтобы вывести список параметров, доступных для текущего набора расширений.

Начиная с MTP 2.4, при ошибке «неизвестный параметр» предлагается однозначно совпадающее имя параметра, если такое существует. Если параметр принадлежит известному расширению, предоставляемому Microsoft, которое тестовое приложение не зарегистрировало, ошибка также указывает пакет NuGet, предоставляющий этот параметр.

Для расширенной диагностики зарегистрированных поставщиков и параметров выполните --info.

Запустите зарегистрированный инструмент

Некоторые расширения регистрируют команды, которые обрабатывают артефакты вместо выполнения тестов. Передайте имя команды в качестве первого позиционного аргумента тестового приложения. Например, расширение TRX предоставляет merge-trx и ms-trxcompare.

Запустите приложение с --info, чтобы вывести список зарегистрированных средств и их параметров командной строки. Эти команды относятся к тестовому приложению; это не команды dotnet tool.

См. также

Обратная связь

Были ли сведения на этой странице полезными?

Последнее обновление: 2026-11-06