Тестирование инфраструктуры с PowerShell

Схема цикла тестирования инфраструктуры и примеры скриптов

Быстрые ссылки

Что такое тестирование инфраструктуры?
Тестирование сетевого порта
Тестирование разрешения DNS-имени
Методология разработки тестов
Критерии приёмки
Шаблоны и сниппеты
Заключение

Что такое тестирование инфраструктуры?

Тестирование инфраструктуры — это запуск кода, который читает текущие конфигурации и состояния компонентов ИТ-среды и сравнивает их с ожидаемыми значениями. Коротко: это автоматическая проверка того, что инфраструктура «такая, как должна быть».

Примеры простых проверок:

Был ли создан пользователь AD с нужными атрибутами?
Отвечает ли порт 80 на веб‑сервере?
Запущен ли сервис DHCP?

Почему это важно: ручная проверка не масштабируется. Скрипт, который создаёт 1 000 пользователей, может вернуть отсутствие ошибки, но это не значит, что всё настроено правильно. Автоматические тесты дают быстрый, повторяемый и документируемый ответ.

Важно: перед тем как писать тесты, определите, что в вашей организации означает «в рабочем состоянии» для каждого компонента — это базовое требование для корректных тестов.

Тестирование сетевого порта

Задача: подтвердить, что на удалённом хосте слушает ожидаемый порт (TCP/UDP). Это часто говорят как «сервис поднят» — практическая проверка заключается в попытке установить соединение с портом.

Технические заметки: TCP — проверяется установкой TCP‑соединения; UDP — часто требует особой логики (ответа от сервера) и дополнительных таймаутов. В PowerShell и .NET есть средства для обоих протоколов, но готовые скрипты упрощают задачу.

Готовый скрипт из сообщества

Можно использовать общедоступный скрипт Test-NetworkPort.ps1 из PowerShell Gallery. Чтобы установить:

Install-Script -Name Test-NetworkPort

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

PS > Test-NetworkPort.ps1 -ComputerName DC -Port 389
True

Скрипт вернёт True, если порт доступен, и False, если нет. Чтобы узнать дополнительные параметры и варианты использования, читайте встроенную справку:

Get-Help Test-NetworkPort.ps1 -Full

Когда этот тест может ошибаться:

Межсетевой экран (firewall) блокирует входящие соединения, но сервис локально слушает порт — тогда порт будет недоступен извне.
Сервис использует TLS/STARTTLS и ожидает специфичных заголовков — простая TCP‑проверка может завершиться успешно, но высокоуровневый сценарий всё равно будет некорректен.

Альтернативы и дополнения:

Test-NetConnection (встроенный в Windows PowerShell) — даёт базовую информацию о TCP‑подключении и трассировке.
Nmap — полезен для комплексного сканирования портов и fingerprinting.
Сценарные проверки приложения на уровне HTTP/HTTPS (Invoke-WebRequest или curl) — чтобы проверить, что сервис отвечает корректным приложением, а не только что порт открыт.

Рекомендуемая проверка в тестовом сценарии:

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

Тестирование разрешения DNS-имени

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

Готовый скрипт из сообщества

Скрипт Test-DnsNameResolution.ps1 можно установить так:

Install-Script -Name Test-DnsNameResolution

Пример использования:

PS> Test-DnsNameResolution.ps1 -Name DC.mylab.local -Server DC
False

Если скрипт вернёт True — сервер DC разрешил имя DC.mylab.local. False означает, что либо записи нет, либо сервер не смог её разрешить.

Альтернативные команды в PowerShell:

Resolve-DnsName — современная встроенная команда для проверки DNS в Windows 8+/Server 2012+.
nslookup — классический инструмент, полезен при отладке DNS на старых системах.
Test-Connection / ping — проверяет маршрутизируемость, но не заменяет проверку DNS.

Типичные причины ошибок при проверке DNS:

Запись ещё не реплицировалась между DNS‑серверами.
Динамическая регистрация DNS не сработала (клиент не зарегистрировал имя).
Неправильная зона или синтаксис имени.

Методология разработки инфраструктурных тестов

Определите ожидаемое состояние — что значит «в порядке» для этого компонента.
Напишите простой тест, который возвращает булевое значение или структурированный результат (OK/Warning/Error).
Логируйте контекст: время, хост, версия теста, вывод ошибок.
Интегрируйте тесты в CI/CD или планировщик задач (например, Azure Pipelines, GitHub Actions, Jenkins, Scheduled Task).
Периодически пересматривайте тесты и обновляйте ожидаемые состояния при изменениях архитектуры.

Мини‑методология для быстрого старта:

Начните с «smoke» тестов (ключевые порты, DNS, доступ к БД).
Добавьте «integration» тесты для проверки взаимодействия сервисов.
Со временем добавляйте «contract» тесты (например, ожидаемые заголовки HTTP/API ответ).

Критерии приёмки

Тесты возвращают однозначный результат (True/False или структурированный JSON с кодом статуса).
Результаты тестов автоматически сохраняются в журнал или систему мониторинга (с отметкой времени и окружением).
При провале теста создаётся тикет или оповещение (e‑mail, Slack, PagerDuty) в зависимости от тяжести.
Тесты запускаются автоматически при изменениях инфраструктуры и по расписанию.

Шаблоны и сниппеты

Быстрый чек‑лист для написания теста порта (шаблон):

Вход: ComputerName, Port, Protocol, Timeout
Действие: попытка установить соединение (TCP) или отправить UDP‑пакет и ждать ответа
Выход: Boolean; при False — объект с причиной (timeout, refused, no route)

Простой пример на PowerShell (черновой сниппет):

function Test-Port {
    param(
        [string]$ComputerName,
        [int]$Port,
        [int]$TimeoutMs = 3000
    )
    try {
        $tcp = New-Object System.Net.Sockets.TcpClient
        $iar = $tcp.BeginConnect($ComputerName, $Port, $null, $null)
        $wait = $iar.AsyncWaitHandle.WaitOne($TimeoutMs, $false)
        if (-not $wait) { return $false }
        $tcp.EndConnect($iar)
        $tcp.Close()
        return $true
    } catch {
        return $false
    }
}

# Использование
Test-Port -ComputerName "DC" -Port 389

Шаблон для проверки DNS с использованием Resolve-DnsName:

function Test-Dns {
    param(
        [string]$Name,
        [string]$Server
    )
    try {
        $r = Resolve-DnsName -Name $Name -Server $Server -ErrorAction Stop
        return $true
    } catch {
        return $false
    }
}

# Использование
Test-Dns -Name "DC.mylab.local" -Server "DC"

Ролевая чеклист‑матрица

Сисадмин:
- Создать базовые smoke‑тесты (порт, DNS, служба)
- Автоматизировать запуск по расписанию
DevOps/SRE:
- Интегрировать тесты в пайплайн деплоя
- Настроить оповещения и автоматическую диагностику при падениях
Разработчик приложения:
- Добавить тесты API/контракта в интеграционные тесты
- Убедиться, что тесты фиксируют версию API/контракта

Decision flow для диагностики (Mermaid)

flowchart TD
    A[Начать тест] --> B{Тип теста}
    B -->|Порт| C[Проверить доступность порта]
    B -->|DNS| D[Проверить разрешение имени]
    C --> E{Успех}
    D --> E
    E -->|Да| F[Лог: OK]
    E -->|Нет| G[Проверить firewall и локальный сервис]
    G --> H{Сервис запущен?}
    H -->|Да| I[Проблема с сетью/маршрутизацией]
    H -->|Нет| J[Перезапустить сервис и ретест]

Критерии тестовых сценариев и приёмки

Примеры тесткейсов:

TC-001: Тест порта LDAP (389) на контроллере домена — успешно в 95% попыток в течение 3 секунд.
TC-002: Разрешение DNS для новой машины — должно возвращать A‑запись после создания в зоне.

Критерии приёмки:

Тесты должны выполняться без ручного вмешательства.
Ошибки сопровождаются диагностическими логами и рекомендациями для устранения.
Все тесты покрыты в CI или расписании задач.

Заключение

Автоматизированное тестирование инфраструктуры — обязательный навык для масштабируемого управления средой. Начните с простых smoke‑проверок портов и DNS, используйте готовые скрипты из PowerShell Gallery или пишите свои функции для повторного использования. Интегрируйте тесты в процессы деплоя и мониторинга, и вы получите более надёжные релизы и меньше ручной рутинной работы.

Важно: цель тестов — не заменить мониторинг в реальном времени, а дать воспроизводимую проверку ожидаемого состояния после изменений.

Короткая памятка: