Инструменты для ручного и автоматизированного тестирования

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВНЕ ДЛЯ НОВИЧКОВВ РАЗРАБОТКЕ

Тестировщику Разработчику Аналитику

Инструменты для ручного и автоматизированного тестирования

Тестирование программного обеспечения — неотъемлемый этап жизненного цикла разработки, направленный на верификацию и валидацию поведения системы относительно заданных требований. Современные практики разработки, особенно в условиях DevOps и непрерывной интеграции/доставки (CI/CD), требуют широкого спектра тестовых подходов и зрелой инфраструктуры автоматизации, поддерживаемой специализированными инструментами. Выбор инструмента определяется множеством факторов: тип тестируемой системы, уровень абстракции (единичный модуль, API, пользовательский интерфейс), требования к производительности и безопасности, а также интеграционные возможности с существующими процессами разработки.

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

Юнит-тестирование

Юнит-тестирование (unit testing) представляет собой метод проверки отдельных компонентов программного обеспечения (обычно функций, методов или классов) в изоляции от остальной системы. Цель — подтвердить корректность логики на минимальном уровне абстракции. Ключевым требованием к юнит-тестам является независимость: каждый тест должен быть детерминированным, быстрым и не зависеть от внешних систем (файловой системы, базы данных, сетевых вызовов).

Для юнит-тестирования существуют специализированные фреймворки, предоставляющие функциональность для:

организации тестовых наборов (test suites),
управления жизненным циклом тестов (setup, teardown),
формулировки утверждений (assertions),
имитации зависимостей (mocking/stubbing).

JUnit (Java)

JUnit — де-факто стандарт для юнит-тестирования в экосистеме Java. Начиная с версии 5 (JUnit Jupiter), фреймворк предлагает модульную архитектуру, поддержку расширений, параметризованных тестов и условного выполнения. Аннотации, такие как @Test, @BeforeEach, @AfterAll, позволяют декларативно управлять поведением тестов. JUnit интегрирован в большинство IDE и сборочных систем (Maven, Gradle), а также поддерживается большинством CI/CD-решений.

Для интеграции JUnit 5 в проект, управляемый через Maven, необходимо добавить зависимости в файл pom.xml. Эти зависимости обеспечивают наличие ядра фреймворка, API для написания тестов и модуля Jupiter для поддержки новых возможностей.

В секцию <dependencies> файла конфигурации добавляют следующие элементы:

junit-jupiter-api: Предоставляет аннотации и классы для написания тестовых методов.
junit-jupiter-engine: Содержит исполняемую часть фреймворка, которая запускает тесты во время выполнения.
junit-vintage-engine (опционально): Позволяет запускать старые тесты, написанные для JUnit 4, в среде JUnit 5.

Пример конфигурации зависимостей версии 5.9 или новее:

<dependency>
    <groupId>org.junit.jupiter</groupId>
    <artifactId>junit-jupiter-api</artifactId>
    <version>5.9.3</version>
    <scope>test</scope>
</dependency>
<dependency>
    <groupId>org.junit.jupiter</groupId>
    <artifactId>junit-jupiter-engine</artifactId>
    <version>5.9.3</version>
    <scope>test</scope>
</dependency>

После добавления этих строк необходимо выполнить команду mvn clean install в терминале проекта. Процесс загрузки артефактов происходит автоматически из репозиториев Maven Central.

В проектах на базе Gradle настройку выполняют внутри файла build.gradle. Для включения JUnit 5 используют плагин java-library или application и добавляют зависимости в секцию testImplementation.

Следующий блок кода подключает необходимые компоненты фреймворка:

dependencies {
    testImplementation 'org.junit.jupiter:junit-jupiter-api:5.9.3'
    testRuntimeOnly 'org.junit.jupiter:junit-jupiter-engine:5.9.3'
}

Также важно убедиться, что задача сборки настроена на использование теста. В современных версиях Gradle это делается автоматически при наличии плагина java, но можно явно указать задачу:

tasks.named('test') {
    useJUnitPlatform()
}

Команда gradle build или gradle test инициирует скачивание библиотек и их подключение к проекту.

Инструменты IntelliJ IDEA и Eclipse автоматически обнаруживают добавленные зависимости после синхронизации проекта с файлами конфигурации сборки.

В IntelliJ IDEA процесс выглядит следующим образом:

Открывают файл pom.xml или build.gradle.
Нажимают кнопку «Reload Project» (иконка с двумя стрелками) в правом верхнем углу редактора.
IDE автоматически создает структуру папок src/test/java, куда помещают файлы тестов.
При создании нового класса теста IDE предлагает добавить аннотацию @Test и импортировать соответствующие пакеты.

В Eclipse пользователи нажимают правой кнопкой мыши по проекту, выбирают «Build Path», затем «Configure Build Path». Во вкладке «Libraries» проверяют наличие библиотек JUnit. Если они отсутствуют, их добавляют вручную или обновляют проект через меню «Project» -> «Clean».

После установки фреймворка код тестов размещают в директории src/test/java. Структура пакетов должна повторять структуру основного кода приложения. Это позволяет находить тесты, соответствующие конкретным классам, используя ту же иерархию именования.

Файлы тестов обычно получают суффикс Test или Tests к имени тестируемого класса. Например, класс UserService получает тестовый файл UserServiceTest.

Запуск тестов выполняется через командную строку или интерфейс IDE.

В Maven команда выглядит так:

mvn test

В Gradle используется:

gradle test

При выполнении этих команд система сборки сканирует директорию src/test/java, находит классы с аннотацией @Test и запускает их. Результаты отображаются в консоли в виде отчета о пройденных и упавших тестах.

Интеграция с CI/CD системами происходит автоматически, если в конфигурации пайплайна прописаны команды сборки и запуска тестов. GitHub Actions, GitLab CI и Jenkins поддерживают эти команды без дополнительных настроек благодаря стандартной структуре Maven и Gradle проектов.

NUnit (.NET)

NUnit — один из старейших и наиболее развитых фреймворков для .NET-платформы, вдохновлённый JUnit. Он поддерживает широкий набор атрибутов для организации тестов, параметризацию, теории (theories), а также гибкие механизмы конфигурации. NUnit совместим с .NET Framework, .NET Core и .NET 5+, и активно используется как в коммерческой, так и в open-source разработке.

Самый быстрый способ добавить фреймворк в существующий проект — использование консольной утилиты .NET. Этот метод работает для проектов любого типа: классических (.NET Framework, если используется старая версия), .NET Core или .NET 5+.

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

dotnet new nunit -o MyProject.Tests

Эта команда создает новую папку с файлами шаблона теста и автоматически добавляет необходимые пакеты.

Если проект уже существует, необходимо перейти в корневую директорию решения (sln) или папки проекта .csproj и выполнить команду добавления пакета:

dotnet add package NUnit
dotnet add package NUnit3TestAdapter
dotnet add package Microsoft.NET.Test.Sdk

Первая команда устанавливает ядро фреймворка. Вторая обеспечивает адаптер, который позволяет IDE и сборщикам находить и запускать тесты NUnit. Третья предоставляет базовые функции для запуска тестовых сред.

В проектах, где управление зависимостями происходит через XML-файл .csproj, можно добавить нужные элементы вручную. Это удобно при работе в средах, где нет доступа к консоли, или при необходимости жесткого контроля версий.

В секцию <ItemGroup> внутри файла конфигурации добавляют следующие строки:

NUnit: Основной пакет с атрибутами и assertion-методами.
NUnit3TestAdapter: Адаптер для совместимости с инструментами сборки.
Microsoft.NET.Test.Sdk: Наборы инструментов для выполнения тестов.

Пример содержимого секции:

<ItemGroup>
    <PackageReference Include="NUnit" Version="4.0.1" />
    <PackageReference Include="NUnit3TestAdapter" Version="4.5.0" />
    <PackageReference Include="Microsoft.NET.Test.Sdk" Version="17.8.0" />
</ItemGroup>

После изменения файла необходимо восстановить зависимости командой dotnet restore.

Инструмент Visual Studio предлагает графический интерфейс для управления пакетами NuGet, что исключает необходимость ручного редактирования файлов.

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

В окне «Обозреватель решений» нажимают правой кнопкой мыши по проекту, содержащему тесты.
Выбирают пункт «Управление библиотеками NuGet...».
Во вкладке «Обзор» вводят название пакета NUnit и устанавливают его.
Повторяют процедуру для пакетов NUnit3TestAdapter и Microsoft.NET.Test.Sdk.
После установки Visual Studio автоматически обновляет файл .csproj и загружает необходимые файлы.

При создании нового проекта тестов через мастер создания проекта («Файл» -> «Создать» -> «Проект») следует выбрать шаблон «Тестовый проект xUnit», но затем заменить его на шаблон «Тестовый проект NUnit» (если он доступен) или просто установить пакеты вручную, так как структура файлов остается схожей.

Код тестов размещают в отдельном проекте, который ссылается на основной проект приложения. Обычно этот проект называют [ИмяОсновногоПроекта].Tests.

Файлы тестов получают суффикс Test к имени класса. Внутри файла используют пространство имен NUnit.Framework для импорта атрибутов. Класс теста помечают атрибутом [TestFixture], а методы — атрибутом [Test].

Пример структуры файла:

using NUnit.Framework;

[TestFixture]
public class CalculatorTests
{
    [Test]
    public void Add_TwoNumbers_ReturnsSum()
    {
        // Логика теста
    }
}

Запуск тестов выполняется через меню «Тест» в Visual Studio или через консольную утилиту.

В Visual Studio:

Открывают окно «Обозреватель тестов» (Ctrl+E, T).
Нажимают кнопку «Запустить все» или выбирают конкретный тест/класс.
Результаты отображаются в виде отчета с цветом индикаторов (зеленый — успешно, красный — ошибка).

В консоли используют команду:

dotnet test

Эта команда компилирует проект, сканирует файлы на наличие классов с атрибутом [TestFixture], запускает методы с атрибутом [Test] и выводит итоговый отчет в терминал. Команда также поддерживает фильтрацию по имени теста или параметрам запуска.

Интеграция с системами непрерывной интеграции (CI/CD), такими как GitHub Actions, Azure DevOps или GitLab CI, происходит автоматически при наличии файла конфигурации пайплайна, вызывающего команду dotnet test. Эти системы понимают стандартную структуру проекта .NET и не требуют дополнительных настроек для работы с NUnit.

TestNG (Java)

TestNG — альтернатива JUnit, изначально разработанная с акцентом на поддержку крупномасштабного тестирования, включая интеграционные и end-to-end сценарии. Он предлагает более гибкие механизмы группировки тестов, зависимости между тестами, параллельное выполнение и расширенные аннотации. Хотя TestNG менее распространён в чистом юнит-тестировании, его потенциал раскрывается в сложных конфигурациях, где требуется композиция тестовых сценариев.

Для интеграции фреймворка TestNG в проект, управляемый через Maven, необходимо добавить зависимости в файл pom.xml. Эти зависимости обеспечивают наличие ядра фреймворка, API для написания тестов и адаптера для запуска.

В секцию <dependencies> файла конфигурации добавляют следующие элементы:

testng: Основной пакет, содержащий аннотации (@Test, @BeforeSuite), классы assertions и механизмы управления зависимостями.
junit-vintage-engine (опционально): Не требуется, так как TestNG является самостоятельной платформой, но может понадобиться для совместимости с другими инструментами в специфических сценариях.

Пример конфигурации зависимости версии 7.x:

<dependency>
    <groupId>org.testng</groupId>
    <artifactId>testng</artifactId>
    <version>7.9.0</version>
    <scope>test</scope>
</dependency>

После добавления этой строки необходимо выполнить команду mvn clean install. Процесс автоматически скачивает библиотеку из репозитория Maven Central.

В проектах на базе Gradle настройку выполняют внутри файла build.gradle. Для включения TestNG используют плагин java и добавляют зависимости в секцию testImplementation.

Следующий блок кода подключает необходимые компоненты фреймворка:

dependencies {
    testImplementation 'org.testng:testng:7.9.0'
}

Также важно настроить задачу сборки для использования TestNG вместо JUnit по умолчанию. В современных версиях Gradle это делается путем указания платформы в задаче теста:

tasks.named('test') {
    useTestNG()
}

Команда gradle build или gradle test инициирует скачивание библиотек и их подключение к проекту.

В IntelliJ IDEA процесс выглядит следующим образом:

Открывают файл pom.xml или build.gradle.
Нажимают кнопку «Reload Project» (иконка с двумя стрелками) в правом верхнем углу редактора.
IDE автоматически создает структуру папок src/test/java, куда помещают файлы тестов.
При создании нового класса теста IDE предлагает добавить аннотацию @Test и импортировать пространство имен org.testng.annotations.

В Eclipse пользователи нажимают правой кнопкой мыши по проекту, выбирают «Build Path», затем «Configure Build Path». Во вкладке «Libraries» проверяют наличие библиотеки TestNG. Если она отсутствует, её добавляют вручную или обновляют проект через меню «Project» -> «Clean».

Файлы тестов обычно получают суффикс Test к имени тестируемого класса. Например, класс UserService получает тестовый файл UserServiceTest.

Уникальной особенностью TestNG является использование XML-файла конфигурации для определения порядка выполнения, группировки и зависимостей тестов. Этот файл называют testng.xml и размещают в директории src/test/resources.

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

<!DOCTYPE suite SYSTEM "https://testng.org/testng-1.0.dtd">
<suite name="All Tests" parallel="tests" thread-count="2">
    <test name="Integration Tests">
        <classes>
            <class name="com.example.IntegrationTest"/>
            <class name="com.example.EndToEndTest"/>
        </classes>
    </test>
    <test name="Unit Tests">
        <classes>
            <class name="com.example.UnitTest"/>
        </classes>
    </test>
</suite>

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

Запуск тестов выполняется через командную строку или интерфейс IDE.

В Maven команда выглядит так:

mvn test

Если используется файл testng.xml, его можно указать явно:

mvn test -Dtestng.xml=testng.xml

В Gradle используется:

gradle test

При выполнении этих команд система сборки сканирует директорию src/test/java, находит классы с аннотацией @Test и запускает их согласно правилам, заданным в testng.xml. Результаты отображаются в консоли в виде отчета о пройденных и упавших тестах с детализацией по группам и зависимостям.

Интеграция с CI/CD системами происходит автоматически, если в конфигурации пайплайна прописаны команды сборки и запуска тестов. GitHub Actions, GitLab CI и Jenkins поддерживят эти команды без дополнительных настроек благодаря стандартной структуре Maven и Gradle проектов.

PyTest (Python)

PyTest — полноценная экосистема для тестирования в Python. Он поддерживает как юнит-, так и функциональное тестирование, отличается минималистичным синтаксисом (тесты — обычные функции), мощной системой фикстур (fixtures) для управления состоянием и зависимостями, а также богатыми возможностями параметризации. PyTest совместим с unittest и doctest, но превосходит их в выразительности и расширяемости.

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

Для добавления фреймворка в текущее окружение выполняют команду:

pip install pytest

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

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

Процесс выглядит следующим образом:

Переходят в корневую директорию проекта.
Создают окружение командой python -m venv .venv (имя папки может быть любым).
Активируют окружение:
- В Windows: .venv\Scripts\activate.
- В macOS/Linux: source .venv/bin/activate.
После активации в строке терминала появляется имя окружения в скобках.
Выполняют команду pip install pytest внутри активного окружения.

PyTest автоматически сканирует проект на наличие файлов конфигурации. Это позволяет управлять поведением запуска, путями к тестам и плагинами без изменения кода.

Существует несколько форматов конфигурации. Современным стандартом является файл pyproject.toml, используемый также для описания зависимостей проекта.

Пример содержимого секции [tool.pytest.ini_options] в файле pyproject.toml:

[tool.pytest.ini_options]
testpaths = ["tests"]
python_files = ["test_*.py", "*_test.py"]
python_functions = ["test_*"]
addopts = "-v --tb=short"

Файл pytest.ini использует формат INI и подходит для проектов, где не используется TOML:

[pytest]
testpaths = tests
python_files = test_*.py python_functions = test_* addopts = -v --tb=short

Файл conftest.py размещают в директории с тестами для определения глобальных фикстур и плагинов, которые применяются ко всем тестам в этой ветке дерева.

Уникальной особенностью PyTest является отсутствие жестких требований к именам классов или методов. Тесты представляют собой обычные функции или методы классов.

Правила обнаружения тестов определяются конфигурацией:

Файлы должны начинаться с префикса test_ или заканчиваться суффиксом _test.py.
Функции должны начинаться с префикса test_.
Классы могут назваться как угодно, но методы внутри них должны начинаться с test_.

Типичная структура папок выглядит так:

project_root/
├── src/
│   └── my_app.py
├── tests/
│   ├── conftest.py
│   ├── test_my_app.py
│   └── integration/
│       └── test_integration.py
├── pyproject.toml
└── requirements.txt

В этом примере файлы test_my_app.py и test_integration.py будут найдены и запущены автоматически.

Запуск тестов осуществляется через консольную утилиту pytest. Команда сканирует текущую директорию и все поддиректории на соответствие правилам именования.

Базовая команда:

pytest

Она запускает все найденные тесты и выводит подробный отчет в терминал.

Дополнительные опции позволяют гибко управлять процессом:

-v: Включает расширенный вывод информации о каждом тесте.
-k "expression": Запускает только тесты, чьи имена соответствуют выражению (например, pytest -k "login").
--cov: Запускает сборку покрытия кода при наличии плагина pytest-cov.
--html=report.html: Генерирует отчет в формате HTML.
tests/test_file.py: Запускает конкретный файл.

Интеграция с системами непрерывной интеграции, такими как GitHub Actions, GitLab CI или Jenkins, происходит автоматически благодаря стандартному имени команды pytest.

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

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

pytest-cov: Для измерения покрытия кода.
pytest-xdist: Для параллельного выполнения тестов на нескольких ядрах процессора.
pytest-mock: Для создания мок-объектов и патчей.
pytest-flask: Для тестирования приложений на базе Flask.

Плагины устанавливают той же командой pip, что и основной фреймворк, например:

pip install pytest-cov pytest-xdist

После установки они становятся доступны сразу при запуске pytest.

Jest (JavaScript/TypeScript)

Jest — фреймворк, разработанный Facebook, изначально ориентированный на тестирование JavaScript-приложений, особенно React. Его ключевые особенности — встроенная поддержка моков, мгновенное выполнение (snapshot testing), изоляция тестов и параллельное выполнение. Jest особенно популярен в среде TypeScript благодаря встроенной типизации и тесной интеграции с транспиляторами.

Процесс подключения начинается с создания проекта или использования существующего. Для новых проектов часто используют инструменты инициализации, такие как create-react-app, Vite или Next.js, которые включают настройку тестов по умолчанию. В ручном режиме или для существующих проектов установку выполняют через менеджер пакетов npm или yarn.

Команда установки устанавливает ядро фреймворка, среду выполнения (JSDOM) для эмуляции браузера и необходимые утилиты:

npm install --save-dev jest jsdom

Или для менеджера yarn:

yarn add --dev jest jsdom

Флаг --save-dev (или -D) указывает на то, что библиотека необходима только на этапе разработки и сборки, но не должна попадать в итоговый файл приложения для продакшена.

После установки необходимо создать файл конфигурации. Jest автоматически ищет файл jest.config.js в корне проекта. Если файл отсутствует, можно использовать встроенные настройки по умолчанию, однако создание собственного файла позволяет точно определить правила обнаружения тестов и поведение среды.

Пример базовой конфигурации jest.config.js:

module.exports = {
  testEnvironment: 'jsdom', // Эмуляция браузерной среды
  roots: ['<rootDir>/src'], // Корневая директория для поиска кода
  testMatch: ['**/__tests__/**/*.[jt]s?(x)', '**/?(*.)+(spec|test).[tj]s?(x)'], // Шаблоны имен файлов тестов
  transform: {
    '^.+\\.tsx?$': 'ts-jest' // Транспайлер для TypeScript файлов
  },
  moduleFileExtensions: ['ts', 'tsx', 'js', 'jsx', 'json', 'node'],
};

Для проектов на чистом JavaScript блок transform можно опустить, так как Node.js понимает синтаксис ES6+. Для TypeScript проектов обязательно наличие пакета ts-jest и его настройка в конфигурации.

Чтобы запускать тесты через консольную команду, необходимо добавить соответствующий скрипт в файл package.json. Это стандартный способ организации команд в экосистеме Node.js.

В секции "scripts" добавляют строку:

"scripts": {
  "test": "jest",
  "test:watch": "jest --watch",
  "test:coverage": "jest --coverage"
}

Команда npm test запускает все найденные тесты. Опция --watch включает режим наблюдения за изменениями в коде и автоматический перезапуск тестов при сохранении файлов. Флаг --coverage генерирует отчет о покрытии кода тестами.

Jest следует соглашениям об именах файлов для автоматического обнаружения тестов. Тестовые файлы должны иметь расширения .js, .jsx, .ts или .tsx и содержать суффиксы test или spec.

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

project_root/
├── src/
│   ├── index.ts
│   └── utils/
│       └── math.ts
├── tests/
│   ├── math.test.ts
│   └── __snapshots__/
│       └── math.snap
├── jest.config.js
└── package.json

Файлы могут находиться как в отдельной папке tests или __tests__, так и лежать рядом с исходным кодом (например, math.test.ts рядом с math.ts). Главное — соответствие шаблону, указанному в конфигурации testMatch.

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

Базовая команда:

npm test

Или напрямую через npx (не требует глобальной установки):

npx jest

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

При использовании TypeScript важно убедиться, что компилятор настроен корректно. Пакет ts-jest выступает в роли трансформатора, позволяя Jest выполнять файлы .ts без предварительной компиляции в JavaScript.

Необходимо установить зависимости:

npm install --save-dev ts-jest typescript @types/jest

Пакет @types/jest предоставляет определения типов для аннотаций и функций Jest, что позволяет редактору кода предлагать автодополнение и проверять типы.

Интеграция с системами непрерывной интеграции, такими как GitHub Actions, GitLab CI или Jenkins, происходит автоматически благодаря стандартному вызову команды npm test.

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

Устанавливает зависимости (npm install).
Запускает тесты (npm test).

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

Mocha + Chai (JavaScript)

Mocha — платформа для тестирования, предоставляющая основу для организации тестов (хуки, асинхронные тесты, генерация отчётов), но не включающая утверждения. В сочетании с библиотекой Chai (или другими assertion-библиотеками, например, should.js) образует гибкую связку. Mocha особенно подходит для сложных асинхронных сценариев и тестирования на Node.js, где важна настраиваемость.

Процесс подключения начинается с создания или использования существующего проекта Node.js. Для новых проектов часто применяют команду npm init, которая генерирует файл package.json. Если проект уже существует, переходят в его корневую директорию.

Для установки фреймворка Mocha и библиотеки утверждений Chai используют менеджер пакетов npm или yarn. Важно отметить, что Mocha отвечает только за организацию тестов (хуки, асинхронность), а проверки результатов выполняются через Chai.

Команда установки для обоих инструментов:

npm install --save-dev mocha chai

Или для менеджера yarn:

yarn add --dev mocha chai

Флаг --save-dev указывает на то, что эти библиотеки необходимы только на этапе разработки и не должны попадать в итоговый код приложения.

Mocha автоматически сканирует проект на наличие файлов конфигурации. По умолчанию он ищет файл .mocharc.js или .mocharc.json в корне проекта. Можно также передать параметры запуска напрямую в командной строке.

Пример содержимого файла .mocharc.js:

module.exports = {
  timeout: 5000, // Таймаут выполнения теста в миллисекундах
  recursive: true, // Поиск тестов во всех поддиректориях
  require: 'chai/register-should', // Автоматическая регистрация assertion-стиля Chai
  extension: ['js'], // Расширения файлов для поиска
  reporter: 'spec' // Формат отчета (доступны: spec, dot, json, xunit)
};

Эта конфигурация задает поведение по умолчанию: поиск файлов с расширением .js во всех папках, таймаут 5 секунд и использование стиля should из библиотеки Chai.

Чтобы запустить тесты удобной командой, необходимо добавить соответствующий скрипт в файл package.json. Это стандартный способ организации команд в экосистеме Node.js.

В секции "scripts" добавляют строку:

"scripts": {
  "test": "mocha",
  "test:watch": "mocha --watch",
  "test:coverage": "nyc mocha"
}

Команда npm test запускает все найденные тесты согласно конфигурации. Опция --watch включает режим наблюдения за изменениями в коде и автоматический перезапуск тестов при сохранении файлов. Для генерации отчета о покрытии кода часто используют плагин nyc (istanbul).

Mocha следует соглашениям об именах файлов для автоматического обнаружения тестов. Тестовые файлы обычно размещают в папке tests или test и называют их с суффиксом test.js или префиксом test..

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

project_root/
├── src/
│   └── utils.js
├── tests/
│   ├── utils.test.js
│   └── integration.test.js
├── .mocharc.js
└── package.json

Можно использовать любую структуру папок, если она соответствует параметру recursive: true в конфигурации или явно указана в команде запуска.

В файле теста импортируют необходимые модули и определяют блоки describe (группа тестов) и it (один тест). Утверждения реализуются через методы объекта expect, assert или стили should/must из Chai.

Пример файла tests/utils.test.js:

const { expect } = require('chai');
const { add } = require('../src/utils');

describe('Модуль утилит', () => {
  describe('Функция сложения', () => {
    it('должна возвращать сумму двух чисел', () => {
      const result = add(2, 3);
      expect(result).to.equal(5);
    });

    it('должна работать с отрицательными числами', () => {
      const result = add(-1, -1);
      expect(result).to.equal(-2);
    });
  });
});

Также можно использовать стиль should:

require('chai').should();
// ...
result.should.be.equal(5);

Mochа отлично справляется с асинхронным кодом. Поддерживаются три способа передачи асинхронности:

Возврат промиса (Promise) из теста.
Использование ключевого слова async перед функцией теста.
Передача функции обратного вызова (done) как последнего аргумента.

Пример с промисом:

it('должен вернуть данные из API', async () => {
  const data = await fetchData();
  expect(data.status).to.equal('ok');
});

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

Базовая команда:

npm test

Или напрямую через npx (не требует глобальной установки):

npx mocha

Результаты отображаются в консоли с цветовой индикацией: зеленые точки или галочки означают успешное прохождение, красные крестики — ошибки. Также выводятся сообщения о времени выполнения и количестве пройденных/упавших тестов.

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

Устанавливает зависимости (npm install).
Запускает тесты (npm test).

Система автоматически обрабатывает результаты и помечает сборку как успешную или неудачную в зависимости от выхода кода процесса. Mocha поддерживает генерацию отчетов в форматах JSON, JUnit и HTML, которые могут быть загружены в систему для детального анализа.

RSpec (Ruby)

RSpec — фреймворк для Ruby, построенный на принципах BDD (Behavior-Driven Development), но широко используемый и для юнит-тестирования. Он позволяет писать тесты в форме читаемых спецификаций (describe, it, expect), что улучшает документируемость кода. RSpec включает в себя мощные средства мокирования и поддержку метаданных для фильтрации тестов.

Процесс подключения фреймворка начинается с редактирования файла Gemfile, который содержит список зависимостей проекта. В секцию group :development или group :test добавляют пакет rspec-rails (для проектов на базе фреймворка Rails) или просто rspec-core и rspec-expectations (для чистых Ruby-проектов).

Для стандартных проектов на Ruby используют следующую запись:

group :development, :test do
  gem 'rspec', '~> 3.12'
end

Эта строка указывает менеджеру пакетов Bundler на необходимость установки ядра RSpec, библиотеки ожиданий (expectations) и других вспомогательных компонентов версии 3.12 или новее.

После изменения файла Gemfile необходимо выполнить команду установки в терминале. Утилита bundle считывает файл конфигурации, скачивает необходимые пакеты из репозитория RubyGems и устанавливает их в изолированную среду проекта.

Команда выглядит следующим образом:

bundle install

Если проект не использует Bundler, можно установить пакет глобально через менеджер gem:

gem install rspec

Однако использование bundle является стандартом для управления зависимостями в современных Ruby-проектах, так как это гарантирует воспроизводимость окружения.

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

Выполнение команды:

bundle exec rspec --init

Создает следующие элементы в корне проекта:

Папку spec/, где размещают все тестовые файлы.
Файл .rspec, содержащий параметры запуска по умолчанию (например, флаг --format documentation).
Файл spec/spec_helper.rb, который выступает точкой входа для настройки среды перед запуском каждого теста (импортирование библиотек, настройка моков).
Файл spec/rails_helper.rb (только для проектов Rails), который подключает базу данных и фреймворк Rails к тестам.

Файлы тестов размещают внутри директории spec. Именование файлов должно следовать соглашению: имя тестируемого класса или модуля заканчивается на _spec.rb. Например, класс User получает файл user_spec.rb.

Структура папок типична для проекта:

project_root/
├── app/
│   └── models/
│       └── user.rb
├── spec/
│   ├── models/
│   │   └── user_spec.rb
│   ├── spec_helper.rb
│   └── .rspec
├── Gemfile
└── Gemfile.lock

Тесты пишутся в виде читаемых предложений, использующих ключевые слова describe (описание группы), it (конкретное поведение) и expect (ожидание результата). Синтаксис имитирует естественный язык, что позволяет документации быть частью кода.

Пример файла spec/models/user_spec.rb:

require 'rails_helper' # Или 'spec_helper' для чистого Ruby

RSpec.describe User, type: :model do
  describe '#full_name' do
    it 'возвращает полное имя пользователя' do
      user = User.new(first_name: 'Иван', last_name: 'Петров')
      expect(user.full_name).to eq('Иван Петров')
    end

    it 'не должен возвращать пустое имя при отсутствии данных' do
      user = User.new
      expect(user.full_name).to be_empty
    end
  end
end

Блок describe группирует связанные тесты. Блок it описывает одно конкретное поведение. Метод expect принимает значение и сравнивает его с ожидаемым результатом с помощью цепочки методов (to eq, to be, to include и т.д.).

Запуск тестов выполняется через утилиту rspec, вызываемую через bundle exec для использования версий из локального Gemfile.

Базовая команда:

bundle exec rspec

Она сканирует директорию spec, находит все файлы с суффиксом _spec.rb, выполняет код и выводит результат в формате, заданном в файле .rspec.

Дополнительные опции позволяют гибко управлять процессом:

-f d: Использует формат вывода documentation (по умолчанию часто включен).
-e "описание": Запускает только тесты, чье описание совпадает с выражением.
spec/models/user_spec.rb: Запускает конкретный файл.
--fail-fast: Останавливает выполнение после первой ошибки.

Интеграция с системами непрерывной интеграции, такими как GitHub Actions, GitLab CI или Jenkins, происходит автоматически благодаря стандартному вызову команды bundle exec rspec.

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

Устанавливает зависимости Ruby (bundle install).
Запускает тесты (bundle exec rspec).

Система автоматически обрабатывает результаты и помечает сборку как успешную или неудачную в зависимости от выхода кода процесса. RSpec поддерживает генерацию отчетов в форматах JSON, JUnit и HTML, которые могут быть загружены в систему для детального анализа.

PHPUnit (PHP)

PHPUnit — официальный фреймворк для юнит-тестирования в PHP, входящий в состав рекомендаций PHP-FIG. Он поддерживает аннотации, фикстуры, моки и широкий спектр утверждений. PHPUnit интегрирован в основные IDE и фреймворки (Laravel, Symfony), и остаётся стандартом для проверки логики в PHP-проектах.

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

Для добавления фреймворка в существующий проект переходят в корневую директорию и выполняют команду:

composer require --dev phpunit/phpunit

Флаг --dev указывает на то, что библиотека необходима только в среде разработки и не должна попадать в итоговую сборку для продакшена. Composer автоматически скачивает последнюю стабильную версию PHPUnit, а также все необходимые зависимости (например, библиотеки для генерации отчетов или работы с аннотациями) из репозитория Packagist.

После установки Composer создает файл vendor/bin/phpunit. Для автоматического запуска тестов часто создают собственный файл конфигурации, называемый phpunit.xml или phpunit.xml.dist. Этот файл определяет пути к тестам, настройки среды выполнения и параметры отчетов.

Если файл отсутствует, его можно сгенерировать командой:

./vendor/bin/phpunit --generate-configuration

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

<?xml version="1.0" encoding="UTF-8"?>
<phpunit xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:noNamespaceSchemaLocation="https://schema.phpunit.de/10.5/phpunit.xsd"
         bootstrap="vendor/autoload.php"
         colors="true"
         cacheDirectory=".phpunit.cache">
    <testsuites>
        <testsuite name="Unit Tests">
            <directory>tests</directory>
        </testsuite>
    </testsuites>
    <source>
        <include>
            <directory suffix=".php">src</directory>
        </include>
    </source>
</phpunit>

Этот файл указывает Composer загрузить автозагрузчик (bootstrap), искать файлы тестов в папке tests, а исходный код приложения — в папке src.

Тестовые файлы размещают в отдельной директории, обычно называемой tests. Именование файлов должно соответствовать соглашению: имя класса заканчивается на Test.php. Например, класс UserService получает файл UserServiceTest.php.

Структура папок типична для проекта:

project_root/
├── src/
│   └── UserService.php
├── tests/
│   ├── UserServiceTest.php
│   └── IntegrationTest.php
├── vendor/
├── composer.json
├── phpunit.xml
└── .gitignore

Внутри файла теста импортируют пространство имен PHPUnit\Framework\TestCase и наследуются от этого класса. Методы тестов помечают префиксом test.

Пример содержимого файла tests/UserServiceTest.php:

<?php

namespace Tests;

use PHPUnit\Framework\TestCase;
use App\Services\UserService;

class UserServiceTest extends TestCase
{
    public function testUserCreation(): void
    {
        $service = new UserService();
        $user = $service->create('Ivan', 'Petrov');
        
        $this->assertEquals('Ivan Petrov', $user->getFullName());
        $this->assertNotNull($user->getId());
    }
}

Аннотации и атрибуты (в новых версиях) позволяют задавать условия выполнения, мокировать зависимости и управлять фикстурами.

Запуск тестов выполняется через консольную утилиту, расположенную в директории vendor/bin.

Базовая команда:

./vendor/bin/phpunit

Она сканирует директорию tests согласно конфигурации phpunit.xml, выполняет методы с префиксом test и выводит подробный отчет в терминал.

Дополнительные опции позволяют гибко управлять процессом:

--coverage-text: Выводит отчет о покрытии кода в текстовом формате.
--filter "MethodName": Запускает только тесты, чьи имена соответствуют выражению.
--testdox: Форматирует вывод в виде читаемых предложений (Behavior-Driven Development стиль).
tests/IntegrationTest.php: Запускает конкретный файл.

Для удобства вызова тестов часто добавляют скрипт в файл composer.json. Это позволяет использовать команду composer test вместо длинного пути к бинарному файлу.

В секции "scripts" добавляют строку:

"scripts": {
    "test": "phpunit",
    "test:coverage": "phpunit --coverage-html build/coverage"
}

После этой настройки команда composer test выполнит запуск всех тестов, а composer test:coverage сгенерирует HTML-отчет в папку build/coverage.

Интеграция с системами непрерывной интеграции, такими как GitHub Actions, GitLab CI или Jenkins, происходит автоматически благодаря стандартному вызову команды ./vendor/bin/phpunit или composer test.

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

Устанавливает зависимости PHP (composer install).
Запускает тесты (./vendor/bin/phpunit).

Система автоматически обрабатывает результаты и помечает сборку как успешную или неудачную в зависимости от выхода кода процесса. PHPUnit поддерживает генерацию отчетов в форматах JUnit, XML и HTML, которые могут быть загружены в систему для детального анализа.

В популярных PHP-фреймворках установка PHPUnit часто происходит автоматически при создании нового проекта.

Для Laravel:

Файл phpunit.xml уже присутствует в проекте.
Зависимость установлена через Composer.
Команда php artisan test вызывает PHPUnit под капотом.

Для Symfony:

Пакет symfony/phpunit-bridge обеспечивает совместимость и управление версиями.
Тесты запускаются через bin/phpunit или symfony phpunit.

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

xUnit (.NET)

xUnit — современный фреймворк для .NET, созданный авторами NUnit с учётом недостатков предыдущих поколений. В отличие от NUnit, xUnit отказывается от концепции [SetUp]/[TearDown] в пользу конструкторов и IDisposable, что лучше отражает семантику тестов. Он оптимизирован для параллельного выполнения и считается предпочтительным выбором для новых .NET-проектов, особенно в экосистеме ASP.NET Core.

Самый эффективный способ добавить фреймворк xUnit в проект — использование консольной утилиты .NET. Этот метод работает для проектов любого типа: .NET Core, .NET 5, .NET 6 и новее.

Для создания нового проекта тестирования с использованием шаблона xUnit выполняют команду:

dotnet new xunit -o MyProject.Tests

Эта команда создает новую папку с файлами шаблона теста и автоматически добавляет необходимые пакеты.

dotnet add package xunit
dotnet add package xunit.runner.visualstudio
dotnet add package Microsoft.NET.Test.Sdk

Первая команда устанавливает ядро фреймворка с атрибутами и assertion-методами. Вторая обеспечивает адаптер для визуализации результатов в IDE (Visual Studio) и запуска через консоль. Третья предоставляет базовые функции для выполнения тестовых сред.

В проектах, где управление зависимостями происходит через XML-файл .csproj, можно добавить нужные элементы вручную. Это удобно при работе в средах без доступа к консоли или при необходимости жесткого контроля версий.

В секцию <ItemGroup> внутри файла конфигурации добавляют следующие строки:

xunit: Основной пакет с атрибутами ([Fact], [Theory]) и классами утверждений.
xunit.runner.visualstudio: Адаптер для совместимости с инструментами Visual Studio и другими сборщиками.
Microsoft.NET.Test.Sdk: Наборы инструментов для обнаружения и запуска тестов.

Пример содержимого секции:

<ItemGroup>
    <PackageReference Include="xunit" Version="2.6.6" />
    <PackageReference Include="xunit.runner.visualstudio" Version="2.5.6">
        <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
        <PrivateAssets>all</PrivateAssets>
    </PackageReference>
    <PackageReference Include="Microsoft.NET.Test.Sdk" Version="17.8.0" />
</ItemGroup>

После изменения файла необходимо восстановить зависимости командой dotnet restore.

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

В окне «Обозреватель решений» нажимают правой кнопкой мыши по проекту, содержащему тесты.
Выбирают пункт «Управление библиотеками NuGet...».
Во вкладке «Обзор» вводят название пакета xunit и устанавливают его.
Повторяют процедуру для пакетов xunit.runner.visualstudio и Microsoft.NET.Test.Sdk.
После установки Visual Studio автоматически обновляет файл .csproj и загружает необходимые файлы.

При создании нового проекта тестов через мастер создания проекта («Файл» -> «Создать» -> «Проект») выбирают шаблон «Тестовый проект xUnit». Эта опция автоматически создает структуру файлов и подключает все необходимые зависимости.

Файлы тестов получают суффикс Test к имени класса. Внутри файла используют пространство имен xunit для импорта атрибутов. Класс теста помечают атрибутом [Collection] (если требуется группировка) или просто оставляют как есть, а методы помечают атрибутами [Fact] (для простых тестов) или [Theory] (для параметризованных).

Пример структуры файла:

using Xunit;

public class CalculatorTests
{
    [Fact]
    public void Add_TwoNumbers_ReturnsSum()
    {
        var calculator = new Calculator();
        var result = calculator.Add(2, 3);
        
        Assert.Equal(5, result);
    }
}

Отличительной чертой xUnit является использование конструктора класса для инициализации объектов перед каждым тестом и внедрение зависимостей, а не использование методов [SetUp]/[TearDown].

Запуск тестов выполняется через меню «Тест» в Visual Studio или через консольную утилиту.

В Visual Studio:

Открывают окно «Обозреватель тестов» (Ctrl+E, T).
Нажимают кнопку «Запустить все» или выбирают конкретный тест/класс.
Результаты отображаются в виде отчета с цветовой индикацией (зеленый — успешно, красный — ошибка).

В консоли используют команду:

dotnet test

Эта команда компилирует проект, сканирует файлы на наличие классов с методами, помеченными атрибутами [Fact] или [Theory], запускает их и выводит итоговый отчет в терминал. Команда также поддерживает фильтрацию по имени теста или параметрам запуска.

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

В файле AssemblyInfo.cs или через конфигурацию сборки можно включить глобальное параллельное выполнение:

[assembly: CollectionBehavior(MaxParallelThreads = Environment.ProcessorCount)]

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

Интеграция с системами непрерывной интеграции, такими как GitHub Actions, Azure DevOps или GitLab CI, происходит автоматически при наличии файла конфигурации пайплайна, вызывающего команду dotnet test.

Эти системы понимают стандартную структуру проекта .NET и не требуют дополнительных настроек для работы с xUnit. При выполнении команды dotnet test система автоматически обнаруживает тесты, запускает их в изолированных процессах и возвращает код выхода, указывающий на успех или неудачу сборки.

Тестирование интеграции и API

Если юнит-тестирование фокусируется на изолированных компонентах, то интеграционное тестирование проверяет взаимодействие между модулями, подсистемами или внешними сервисами. В современных распределённых архитектурах, основанных на микросервисах и RESTful/GraphQL API, интеграционное тестирование часто сводится к валидации корректности обмена данными через сетевые интерфейсы. Таким образом, API-тестирование становится центральным элементом стратегии обеспечения качества.

API-тесты проверяют:

соответствие контракта (формат запроса/ответа, HTTP-статусы, заголовки);
семантическую корректность бизнес-логики;
обработку ошибок и граничных условий;
производительность и устойчивость под нагрузкой.

Инструменты для API-тестирования условно делятся на три категории:

Интерактивные инструменты (в первую очередь для ручного тестирования и прототипирования);
Фреймворки для автоматизированного тестирования (встроенные в CI/CD-процессы);
Гибридные решения, сочетающие декларативное описание тестов с возможностями нагрузки и безопасности.

Postman (REST API тестирование)

Postman — один из самых популярных инструментов для разработки, документирования и тестирования API. Первоначально задуманный как клиент для отправки HTTP-запросов, он эволюционировал в полноценную платформу с поддержкой:

коллекций запросов и переменных окружения;
написания тестов на JavaScript (встроенный скриптовый движок на базе Node.js);
генерации документации и мониторинга;
интеграции с CI/CD через Newman (CLI-версия Postman).

Хотя Postman изначально ориентирован на ручное тестирование, его сценарии могут быть автоматизированы и включены в пайплайны, особенно в ранних этапах разработки (shift-left testing).

Postman предоставляет нативные приложения для операционных систем Windows, macOS и Linux. Это основной способ работы с инструментом для ручного тестирования, создания коллекций и написания скриптов.

Процесс установки выглядит следующим образом:

Переходят на официальный сайт Postman (postman.com) в раздел «Загрузить».
Выбирают версию, соответствующую операционной системе пользователя.
Загружают установочный файл и запускают его.
Следуют инструкциям мастера установки. После завершения процесса приложение готово к работе.

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

Для интеграции с системами непрерывной интеграции (CI/CD) и автоматизации тестовых сценариев используют утилиту командной строки — Newman. Она позволяет запускать коллекции Postman без графического интерфейса.

Установка Newman выполняется через менеджер пакетов npm (Node.js), так как она построена на базе среды Node.js.

Команда установки глобально:

npm install -g newman

Или локально в проекте:

npm install newman

После установки команда newman становится доступной в терминале.

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

Процесс экспорта:

Открывают нужную коллекцию в интерфейсе Postman.
Нажимают три точки рядом с названием коллекции.
Выбирают пункт «Экспорт» (Export).
Сохраняют файл в формате JSON (например, api-collection.json) в корневую директорию проекта.

Файл содержит все запросы, переменные окружения, скрипты проверки (tests) и настройки коллекции.

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

Для подключения окружения к автоматическому запуску:

Создают новое окружение в интерфейсе Postman.
Добавляют необходимые переменные и их значения.
Экспортируют само окружение в отдельный JSON-файл (например, environment.json).
При запуске Newman указывают путь к этому файлу через флаг -e.

Для удобства вызова тестов в проекте добавляют скрипт в файл package.json. Это позволяет запускать API-тесты стандартной командой.

Пример конфигурации секции "scripts":

"scripts": {
  "test:api": "newman run api-collection.json -e environment.json",
  "test:api:report": "newman run api-collection.json -e environment.json --reporters cli,json --reporter-json-export reports/newman-report.json"
}

Команда npm test:api запускает все запросы из коллекции с подстановкой переменных из окружения. Флаг --reporters позволяет генерировать отчеты в форматах HTML или JSON для последующего анализа.

Автоматизация проверок в Postman осуществляется путем написания скриптов в блоке «Tests» для каждого запроса. Эти скрипты выполняются после получения ответа сервера.

Синтаксис использует глобальные объекты pm, доступные в среде выполнения Postman:

pm.response.to.have.status(200): Проверяет код ответа.
pm.test("Name of test", function() { ... }): Определяет название теста.
pm.expect(responseBody).to.be.an('object'): Использует библиотеку Chai для сложных утверждений.
pm.environment.set("token", responseJson.token): Сохраняет данные из ответа в переменную окружения для использования в следующих запросах.

Пример скрипта:

pm.test("Status code is 200", function () {
    pm.response.to.have.status(200);
});

pm.test("Response has user data", function () {
    var jsonData = pm.response.json();
    pm.expect(jsonData).to.have.property('id');
});

Подключение Postman к пайплайнам GitHub Actions, GitLab CI, Jenkins или Azure DevOps происходит через выполнение команды newman.

Типичный сценарий в пайплайне:

Этап подготовки: Устанавливают зависимости Node.js (npm install).
Этап запуска: Выполняют команду newman run <путь_к_коллекции> -e <путь_к_окружению>.
Этап обработки результатов: Настраивают генерацию отчета (например, в формате JUnit или HTML) и сохраняют его как артефакт сборки.

При неудачном выполнении любого теста (возврат кода выхода отличного от нуля) пайплайн помечается как проваленный. Это обеспечивает контроль качества API на ранних этапах разработки (shift-left testing).

Postman автоматически генерирует документацию на основе содержимого коллекции. Чтобы подключить эту документацию к проекту:

В интерфейсе приложения переходят во вкладку «Docs».
Настраивают макет и содержание описания.
Публикуют документацию на облачном сервере Postman или экспортируют её в статические файлы (HTML).
Размещают полученные файлы на веб-сервере или в репозитории проекта.

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

RestAssured (Java для API-тестов)

RestAssured — библиотека для Java, позволяющая писать читаемые и выразительные тесты для REST-сервисов в стиле DSL (Domain-Specific Language). Она абстрагирует низкоуровневую работу с HTTP-клиентами (например, Apache HttpClient) и предоставляет цепочку методов вида:

given().param("key", "value")
.when().get("/api/resource")
.then().statusCode(200).body("field", equalTo("expected"));

RestAssured интегрируется с JUnit/TestNG, поддерживает валидацию JSON/XML через JsonPath/XmlPath и совместим с основными фреймворками сериализации (Jackson, Gson).

Для интеграции библиотеки RestAssured в проект, управляемый через Maven, необходимо добавить зависимости в файл pom.xml. Библиотека абстрагирует работу с HTTP-клиентами и предоставляет DSL для написания тестов.

В секцию <dependencies> файла конфигурации добавляют следующие элементы:

rest-assured: Основной пакет, содержащий все необходимые классы для построения запросов, отправки данных и проверки ответов.
json-path и xml-path: Включены в состав основного пакета, но могут быть добавлены явно при необходимости использования расширенных функций парсинга.
jackson-databind или gson: Опциональные зависимости для работы с сериализацией/десериализацией JSON, если требуется сложная работа с объектами.

Пример конфигурации зависимости версии 5.x (актуальная версия):

<dependency>
    <groupId>io.rest-assured</groupId>
    <artifactId>rest-assured</artifactId>
    <version>5.4.0</version>
    <scope>test</scope>
</dependency>

После добавления этой строки необходимо выполнить команду mvn clean install для автоматического скачивания библиотеки из репозитория Maven Central.

В проектах на базе Gradle настройку выполняют внутри файла build.gradle. Для включения RestAssured используют плагин java и добавляют зависимости в секцию testImplementation.

Следующий блок кода подключает необходимые компоненты фреймворка:

dependencies {
    testImplementation 'io.rest-assured:rest-assured:5.4.0'
    // Опционально: поддержка Jackson для сложных объектов
    testImplementation 'com.fasterxml.jackson.core:jackson-databind:2.15.2'
}

Также важно настроить задачу сборки для использования JUnit или TestNG. Если используется JUnit 5, это делается автоматически, но можно явно указать:

tasks.named('test') {
    useJUnitPlatform()
}

Команда gradle build или gradle test инициирует скачивание библиотек и их подключение к проекту.

В IntelliJ IDEA процесс выглядит следующим образом:

Открывают файл pom.xml или build.gradle.
Нажимают кнопку «Reload Project» (иконка с двумя стрелками) в правом верхнем углу редактора.
IDE автоматически создает структуру папок src/test/java, куда помещают файлы тестов.
При создании нового класса теста IDE предлагает импортировать статические методы из io.restassured.RestAssured (например, given(), when(), then()).

Код тестов размещают в директории src/test/java. Тесты для REST-сервисов обычно группируют в отдельные пакеты, например com.example.api.tests.

Файлы тестов получают суффикс Test к имени тестируемого сервиса. Внутри файла импортируют статические методы библиотеки, чтобы использовать цепочку вызовов в стиле DSL.

Типичная структура файла:

package com.example.api.tests;

import static io.restassured.RestAssured.given;
import static io.restassured.matcher.RestAssuredMatchers.*;
import static org.hamcrest.Matchers.*;

import org.junit.jupiter.api.Test;

public class UserServiceApiTest {

    @Test
    public void testGetUserById() {
        given()
            .baseUri("https://api.example.com")
            .pathParam("id", "123")
        .when()
            .get("/users/{id}")
        .then()
            .statusCode(200)
            .body("name", equalTo("Ivan Petrov"))
            .body("email", containsString("@example.com"));
    }
}

Использование статических импортов (static import) позволяет писать код без префиксов классов, делая его похожим на естественный язык.

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

Можно установить базовый URL и тип контента один раз перед выполнением всех тестов в классе:

@BeforeAll
public static void setup() {
    given()
        .baseUri("https://api.example.com")
        .contentType(ContentType.JSON);
}

Или задать параметры в каждом методе через метод given().baseUri(...).

RestAssured поддерживает мощную систему проверки ответов через встроенные матчеры и язык запросов JsonPath.

Основные возможности проверки:

Статус-код: .statusCode(200) или .statusCode(HttpStatus.OK.value()).
Тело ответа: .body("field", equalTo("value")) для проверки конкретных полей.
JSON-структура: .body("users.size()", is(1)) для проверки количества элементов.
Наличие поля: .body("user.id", notNullValue()).
Сложные выражения: Использование методов containsString, equalTo, greaterThan, hasItems и других из библиотеки Hamcrest.

Пример проверки JSON-ответа:

.then()
    .assertThat()
    .body("data.name", equalTo("Alice"))
    .body("data.age", greaterThan(18))
    .body("items", hasSize(3));

Для работы со сложными объектами (DTO) RestAssured использует стандартные библиотеки сериализации. Если проект использует Jackson или Gson, необходимо добавить соответствующие зависимости.

При отправке объекта в теле запроса RestAssured автоматически сериализует его в JSON:

given()
    .body(userObject) // Объект класса User
    .post("/users");

Библиотека сама определит нужный конвертер, если он установлен в классеpath.

Запуск тестов выполняется через командную строку или интерфейс IDE.

В Maven команда выглядит так:

mvn test

В Gradle используется:

gradle test

При выполнении этих команд система сборки сканирует директорию src/test/java, находит классы с аннотацией @Test и запускает их. RestAssured отправляет HTTP-запросы, получает ответы и проверяет их согласно заданным условиям. Результаты отображаются в консоли в виде отчета о пройденных и упавших тестах.

Интеграция с системами непрерывной интеграции, такими как GitHub Actions, GitLab CI или Jenkins, происходит автоматически благодаря стандартной структуре Maven и Gradle проектов.

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

Устанавливает зависимости (mvn install или gradle build).
Запускает тесты (mvn test или gradle test).

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

Supertest (API-тесты для Node.js)

Supertest — утилита для тестирования HTTP-серверов в Node.js, особенно часто используемая с Express. Она позволяет отправлять запросы к локальному экземпляру приложения без необходимости запуска отдельного сервера, что ускоряет выполнение тестов. Supertest строится поверх SuperAgent и предоставляет fluent API для проверки статусов, заголовков и тел ответов. Типичный сценарий:

request(app)
  .get('/api/users')
  .expect(200)
  .expect('Content-Type', /json/)
  .then(res => {
    expect(res.body).to.be.an('array');
  });

Supertest является стандартным инструментом для тестирования серверной части приложений на Node.js, особенно в связке с фреймворком Express. Для подключения библиотеки используют менеджер пакетов npm или yarn.

Команда установки добавляет Supertest в секцию зависимостей разработки:

npm install --save-dev supertest

Или для менеджера yarn:

yarn add --dev supertest

Флаг --save-dev (или -D) указывает на то, что библиотека необходима только на этапе разработки и не должна попадать в итоговый код приложения для продакшена.

После установки необходимо импортировать функцию request из пакета supertest в файлах тестов. Этот импорт предоставляет основной интерфейс для отправки запросов к приложению.

В коде теста добавляют следующую строку:

const request = require('supertest');
// Или для ES6 модулей:
import request from 'supertest';

Если используется фреймворк Mocha или Jest, этот импорт обычно размещают в начале файла теста или в глобальном файле конфигурации (например, setup.js).

Уникальной особенностью Supertest является возможность передачи экземпляра сервера напрямую в функцию request(). Это позволяет отправлять HTTP-запросы к локальному процессу приложения без запуска отдельного сервера в режиме прослушивания портов.

Для этого в коде теста получают ссылку на экспортированный объект приложения (обычно это результат вызова require('./app') или require('./server')).

Пример базовой структуры теста:

const request = require('supertest');
const app = require('../src/app'); // Путь к основному файлу приложения

describe('API Users', () => {
  it('должен возвращать список пользователей', async () => {
    const response = await request(app)
      .get('/api/users')
      .expect(200);
      
    expect(response.body).to.be.an('array');
  });
});

Метод .expect() используется для цепочки проверок: первый аргумент — ожидаемый статус ответа, второй — заголовок, третий — его значение.

Supertest идеально интегрируется с популярными фреймворками для тестирования, такими как Jest, Mocha или Jasmine. Он работает синхронно с промисами (Promise), что позволяет использовать ключевое слово async/await для написания чистого кода.

При использовании Jest:

Тесты пишутся внутри блока it или test.
Функция request возвращает промис, который можно ожидать.
Проверки реализуются через встроенные функции expect самого Jest.

При использовании Mocha:

Тесты оборачиваются в блок it.
Можно использовать коллбэки или async/await.
Библиотека Chai часто используется вместе с Supertest для расширенных утверждений (chai.expect, chai.should).

Файлы тестов размещают в папке tests или __tests__. Именование файлов следует соглашению с суффиксом .test.js или _spec.js.

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

project_root/
├── src/
│   └── app.js
├── tests/
│   ├── api.test.js
│   └── auth.spec.js
├── package.json
└── node_modules/

В файле api.test.js импортируют приложение и определяют сценарии проверки API.

Ниже приведен пример теста, проверяющего создание пользователя, статус ответа, тип контента и структуру тела ответа:

const request = require('supertest');
const app = require('../src/app');

describe('POST /api/users', () => {
  it('должен создавать нового пользователя', async () => {
    const newUser = { name: 'Ivan', email: 'ivan@example.com' };

    const response = await request(app)
      .post('/api/users')
      .send(newUser)
      .set('Content-Type', 'application/json')
      .expect(201)
      .expect('Content-Type', /json/)
      .then(res => {
        expect(res.body.name).toBe(newUser.name);
        expect(res.body.email).toBe(newUser.email);
        expect(res.body.id).toBeDefined();
      });
  });
});

Метод .send() передает данные в теле запроса, а .set() устанавливает заголовки. Метод .then() позволяет выполнить дополнительные логические проверки после получения ответа.

Запуск осуществляется через консольную утилиту тестового фреймворка (например, jest или mocha). Команда npm test выполняет все найденные тесты, включая сценарии с Supertest.

Базовая команда:

npm test

Или напрямую через npx:

npx jest
# или
npx mocha

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

Интеграция с системами непрерывной интеграции, такими как GitHub Actions, GitLab CI или Jenkins, происходит автоматически благодаря стандартному вызову команды тестирования.

В конфигурации пайплайна достаточно указать этап, который:

Устанавливает зависимости (npm install).
Запускает тесты (npm test).

Система автоматически обрабатывает результаты и помечает сборку как успешную или неудачную в зависимости от выхода кода процесса. Supertest не требует дополнительных настроек в CI/CD, так как работает полностью в памяти процесса Node.js без необходимости внешнего доступа к сети.

Karate DSL (API + UI тесты в одном фреймворке)

Karate — необычный инструмент, сочетающий в себе BDD-стиль описания тестов с возможностями мощного API-тестирования. Он использует синтаксис, близкий к Gherkin, но не требует реализации шагов на Java — логика встроена в DSL. Karate поддерживает:

валидацию JSON/XML с помощью встроенных выражений;
мокирование серверов (mock server);
параллельное выполнение;
генерацию отчётов;
встраивание в Maven/Gradle.

Хотя упоминается как инструмент для UI-тестов, его реальная сила — в API-валидации, особенно в гибридных сценариях (например, вызов API перед проверкой UI).

Для интеграции фреймворка Karate в проект, управляемый через Maven, необходимо добавить зависимости в файл pom.xml. Библиотека объединяет возможности тестирования API, мокирования и генерации отчетов в единый инструмент, работающий поверх JUnit или TestNG.

В секцию <dependencies> файла конфигурации добавляют следующие элементы:

karate-junit5: Основной пакет, содержащий ядро фреймворка, движок выполнения сценариев и поддержку JUnit 5. Этот артефакт автоматически подтягивает все необходимые зависимости для работы DSL и валидации ответов.
karate-core: Базовая библиотека без привязки к конкретному фреймворку запуска (JUnit/TestNG). Часто используется вместе с плагином для сборки, но для большинства задач достаточно karate-junit5.

Пример конфигурации зависимости версии 1.x (актуальная версия):

<dependency>
    <groupId>io.karatelabs</groupId>
    <artifactId>karate-junit5</artifactId>
    <version>1.4.1</version>
    <scope>test</scope>
</dependency>

В проектах на базе Gradle настройку выполняют внутри файла build.gradle. Для включения Karate используют плагин java и добавляют зависимости в секцию testImplementation.

Следующий блок кода подключает необходимые компоненты фреймворка:

dependencies {
    testImplementation 'io.karatelabs:karate-junit5:1.4.1'
}

Также важно настроить задачу сборки для использования JUnit 5. В современных версиях Gradle это делается путем указания платформы в задаче теста:

tasks.named('test') {
    useJUnitPlatform()
}

Команда gradle build или gradle test инициирует скачивание библиотек и их подключение к проекту.

Уникальной особенностью Karate является использование файлов с расширением .feature, написанных на языке Gherkin. Эти файлы размещают в директории src/test/java/features (или src/test/resources/features).

Структура папок типична для проекта:

project_root/
├── src/
│   └── main/
│       └── java/
│           └── com/example/App.java
├── src/test/
│   ├── java/
│   │   └── com/example/KarateTest.java
│   └── resources/
│       └── features/
│           ├── api.feature
│           └── integration.feature
├── pom.xml
└── karate-config.js

Файлы .feature содержат описания сценариев на естественном языке (Given, When, Then), где логика проверки и отправки запросов выполняется встроенными средствами DSL, а не внешними шагами.

Тесты пишутся в файлах .feature. Синтаксис позволяет отправлять HTTP-запросы, проверять статус-коды, тела ответов и заголовки без написания Java-кода.

Пример содержимого файла api.feature:

Feature: Проверка API пользователей

Scenario: Получение списка пользователей
  Given url 'https://api.example.com/users'
  And header Content-Type = 'application/json'
  When method GET
  Then status 200
  And match response contains { id: '#number', name: '#string' }
  
Scenario: Создание нового пользователя
  Given url 'https://api.example.com/users'
  And request { name: 'Ivan', email: 'ivan@example.com' }
  When method POST
  Then status 201
  And match response.id > 0

Конструкция match использует встроенный язык выражений для глубокой валидации JSON и XML структур. Ключевые слова url, header, request, method формируют запрос, а status и match проверяют результат.

Для запуска сценариев через JUnit или TestNG создают класс, который наследуется от Karate и использует аннотацию @CucumberOptions. Этот класс указывает путь к файлам .feature и параметры запуска.

Пример класса KarateTest.java:

import io.cucumber.junit.Cucumber;
import io.cucumber.junit.CucumberOptions;
import org.junit.runner.RunWith;

@RunWith(Cucumber.class)
@CucumberOptions(
    features = "src/test/java/features",
    glue = {"io.karatelabs"},
    monochrome = true,
    plugin = {"html:target/karate-reports", "json:target/karate-results.json"}
)
public class KarateTest {
    // Класс служит точкой входа для запуска всех сценариев
}

Этот класс связывает файлы .feature с механизмом выполнения JUnit и обеспечивает генерацию отчетов.

Для управления переменными окружения (базовые URL, токены авторизации) используют JavaScript-файл karate-config.js, расположенный в корне ресурсов (src/test/resources). Этот файл выполняется перед каждым сценарием и позволяет динамически подставлять значения.

Пример содержимого karate-config.js:

function fn() {
  var env = 'dev';
  var config = {
    apiUrl: 'https://api.dev.example.com',
    token: 'test-token-123'
  };
  
  if (env === 'prod') {
    config.apiUrl = 'https://api.prod.example.com';
  }
  
  return config;
}

В файлах .feature переменные из этого объекта доступны как $config.api_url или напрямую через имя переменной.

Запуск тестов выполняется через командную строку или интерфейс IDE.

В Maven команда выглядит так:

mvn test

В Gradle используется:

gradle test

При выполнении этих команд система сборки сканирует директорию features, находит файлы .feature, выполняет сценарии согласно описанию и выводит подробный отчет в терминал. По умолчанию генерируется HTML-отчет в папке target/karate-reports.

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

Для этого создают отдельный файл .feature с заголовком Background и специфическими директивами, либо используют встроенные команды в основном сценарии. В файле конфигурации Maven можно указать флаг для запуска моков.

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

Устанавливает зависимости (mvn install или gradle build).
Запускает тесты (mvn test или gradle test).

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

SoapUI (SOAP и REST API)

SoapUI — один из старейших инструментов для тестирования веб-сервисов. Изначально разработанный для SOAP, он позже получил поддержку REST. SoapUI предлагает:

визуальное построение запросов на основе WSDL/OpenAPI;
функциональные, нагрузочные и security-тесты в одном интерфейсе;
параметризацию и циклы через Groovy-скрипты.

Существует как бесплатная (Open Source), так и коммерческая (ReadyAPI) версии. SoapUI особенно популярен в enterprise-средах с унаследованными SOAP-сервисами.

SoapUI — это автономное приложение с графическим интерфейсом, которое не требует сборки проекта или подключения через менеджер пакетов (Maven/Gradle) для запуска основного функционала. Для работы необходимо скачать установочный файл с официального сайта SmartBear.

Процесс установки выглядит следующим образом:

Переходят на официальный сайт SmartBear в раздел загрузок (soapui.org/download).
Выбирают версию SoapUI Open Source (бесплатная) или ReadyAPI (коммерческая).
Скачивают установщик для соответствующей операционной системы (Windows, macOS, Linux).
Запускают установщик и следуют инструкциям мастера.
После завершения процесса приложение готово к работе без дополнительных настроек.

Встроенный клиент автоматически определяет установленную среду Java Runtime Environment (JRE). Если JRE отсутствует, программа предложит установить её автоматически или запросит путь к существующей установке.

Основой подключения сервиса в SoapUI является создание проекта на основе спецификации веб-сервиса. Это позволяет инструменту автоматически построить структуру тестовых наборов, методов и параметров.

Процесс создания проекта:

Открывают SoapUI и нажимают кнопку «New Project» (или «File» -> «New SOAP/REST Project»).
В поле «Project Name» вводят название проекта.
В поле «Initial URL» указывают адрес ресурса:
- Для SOAP: полный путь к файлу WSDL (например, http://server/api?wsdl) или локальный путь к файлу.
- Для REST: ссылка на документацию OpenAPI/Swagger (JSON/YAML) или просто базовый URL API.
Нажимают «OK».

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

Для гибкой работы с разными средами (разработка, тестирование, продакшн) в SoapUI используют переменные проекта. Их можно определить в разделе «Properties» или «Variables» в свойствах проекта.

Пример настройки переменной baseUrl:

Открывают свойства проекта (правая кнопка мыши по названию проекта -> «Edit Properties»).
Добавляют новую переменную с именем baseUrl и значением https://api.example.com.
В запросе вместо жесткого URL используют синтаксис ${#Project#baseUrl}.

Для сложной логики (парсинг ответов, циклы, динамическая генерация токенов) используют встроенный движок Groovy. Скрипты можно добавить в следующие места:

Setup Script: Выполняется перед отправкой запроса.
Test Step Script: Выполняется после получения ответа.
Cleanup Script: Выполняется после завершения теста.

Пример Groovy-скрипта для извлечения токена из ответа:

def response = context.response
def json = new groovy.json.JsonSlurper().parseText(response)
context.setVariable("authToken", json.token)

В отличие от текстовых фреймворков, структура в SoapUI визуальна и хранится внутри файла проекта (расширение .xml). Файл проекта содержит все определения запросов, скрипты, переменные и результаты тестов.

Типичная структура проекта в дереве интерфейса:

MyProject (file.xml)
├── Service 1 (WSDL/OpenAPI)
│   ├── Operation 1 (GET /users)
│   │   ├── Request 1 (Default)
│   │   └── Response 1 (Expected)
│   └── Operation 2 (POST /user)
│       ├── Request 1
│       └── Test Steps (Functional Tests)
├── Functional Test Suite
│   ├── Test Case 1 (Login Flow)
│   │   ├── Step 1: Login Request
│   │   ├── Step 2: Verify Token
│   │   └── Step 3: Get User Profile
│   └── Test Case 2 (Error Handling)
└── Load Test Suite (для нагрузочных тестов)

Тестовые кейсы (Test Cases) объединяют шаги (Steps) в логические цепочки. Каждый шаг может быть отдельным HTTP-запросом или вызовом скрипта.

Автоматизация проверок происходит через добавление шагов проверки (Assertion) к ответу запроса. Эти проверки могут быть статическими (проверка статуса 200) или динамическими (сравнение значений JSON).

Основные виды утверждений:

Status Code Assertion: Проверяет код ответа HTTP.
Valid XML Assertion: Проверяет корректность XML-структуры.
Valid JSON Assertion: Проверяет структуру и значения в JSON.
Response Time Assertion: Проверяет время отклика сервера.
XPath Match Assertion: Ищет конкретные значения в XML/JSON через XPath или JsonPath.

Пример настройки проверки:

В окне ответа на запрос нажимают кнопку «Add Assertion».
Выбирают тип (например, «Valid JSON Assertion»).
Вводят выражение проверки, например: $.name == "Ivan".
Сохраняют изменения.

Для автоматизации в пайплайнах непрерывной интеграции используют консольную утилиту SoapUI Pro или ReadyAPI, так как бесплатная версия (Open Source) имеет ограниченную поддержку CLI. Однако существуют сторонние инструменты и плагины, позволяющие запускать проекты Open Source версии через командную строку.

Если используется коммерческая версия (ReadyAPI):

Устанавливают ReadyAPI Command Line Tool.
Экспортируют проект в формат .xml (если он еще не сохранен).

Создают команду запуска:

readyapi-cli -project myProject.xml -testSuite "Functional Test Suite" -testCase "Login Flow" -propertyFile env.properties

Получают результат в формате XML или HTML.

Для бесплатной версии часто используют обходные пути через эмуляцию GUI или использование плагинов для Maven, которые вызывают внутреннюю логику SoapUI.

После выполнения набора тестов SoapUI автоматически формирует отчеты.

Процесс генерации:

В меню выбирают «Run» -> «Report».
Выбирают формат отчета (HTML, PDF, Excel, XML).
Указывают путь сохранения.
Отчет содержит детальную статистику: количество пройденных/упавших тестов, время выполнения, логи ошибок и скриншоты запросов/ответов.

Эти отчеты можно автоматически прикреплять к результатам сборки в системах CI/CD для анализа качества API.

В крупных проектах SoapUI часто интегрируется с инструментами управления требованиями и дефектами (например, Jira). Также поддерживается работа с LDAP и SSO для авторизации пользователей.

Ключевые преимущества для enterprise:

Поддержка сложных протоколов (WS-Security, WS-ReliableMessaging).
Встроенные нагрузочные тесты (Load Test) без необходимости подключения внешних инструментов.
Возможность создания моков (Mock Services) для имитации зависимых сервисов прямо в интерфейсе.
Глубокая настройка безопасности и проверка уязвимостей (Security Test).

Инструмент регулярно обновляется. Для получения новых версий и патчей безопасности следует следить за официальными релизами на сайте SmartBear. Важно использовать актуальные версии для совместимости с современными стандартами REST и новыми версиями Java.

JMeter (нагрузочное тестирование + API)

Apache JMeter — изначально инструмент для нагрузочного тестирования, но благодаря плагинной архитектуре и гибкому HTTP-клиенту он активно используется и для функционального API-тестирования. Сценарии в JMeter строятся визуально (в виде дерева элементов), что облегчает создание сложных последовательностей запросов, обработку ответов (через регулярные выражения, JSON Extractor) и параметризацию. Однако из-за отсутствия типобезопасности и сложности отладки JMeter редко используется в качестве основного инструмента для юнит- и интеграционных тестов, но остаётся стандартом для производительностного анализа.

Apache JMeter — это автономное приложение с графическим интерфейсом, написанное на Java. Для работы необходимо установить среду выполнения Java (JRE или JDK) версии 8 или выше.

Процесс установки выглядит следующим образом:

Переходят на официальный сайт Apache JMeter (jmeter.apache.org).
В разделе «Downloads» скачивают архив последней стабильной версии (например, apache-jmeter-5.x.zip для Windows/Linux или .tar.gz для Linux/macOS).
Распаковывают содержимое архива в любую удобную директорию (например, /opt/jmeter или C:\Program Files\jmeter).
Запускают исполняемый файл:
- В Windows: bin\jmeter.bat.
- В macOS/Linux: bin/jmeter.sh.
После запуска открывается графический интерфейс, готовый к созданию тестовых планов.

Для удобства использования можно добавить путь к директории bin в системную переменную среды PATH. Это позволит запускать JMeter из любой точки терминала командой jmeter.

В файле конфигурации системы (~/.bashrc, ~/.zshrc или свойствах Windows) добавляют строку:

export JMETER_HOME=/path/to/apache-jmeter
export PATH=$JMETER_HOME/bin:$PATH

После сохранения изменений перезагружают терминал.

Уникальной особенностью JMeter является визуальное построение сценариев в виде дерева элементов. Тесты создаются через создание «Теста» (Test Plan), который содержит «Группу потоков» (Thread Group), имитирующую пользователей.

Структура типичного функционального теста:

Test Plan: Корневой элемент проекта.
Thread Group: Определяет количество виртуальных пользователей, время их жизни и интервал между запросами.
HTTP Request Defaults: Задает базовые параметры (протокол, хост, порт, путь), чтобы не дублировать их в каждом запросе.
HTTP Request: Конкретный запрос к API (метод GET/POST, URL, параметры, тело запроса).
Assertions: Правила проверки ответа (статус код, текст тела, регулярные выражения, JSON Path).
Listeners: Элементы для вывода результатов (View Results Tree, Summary Report).

Пример создания функционального сценария:

Создают новую группу потоков (Thread Group) и задают 1 поток.
Добавляют элемент «HTTP Request Defaults» и указывают базовый URL сервера.
Добавляют элемент «HTTP Request», выбирают метод POST, указывают путь /api/users и задают JSON-тело запроса.
Добавляют элемент «JSON Extractor» для извлечения ID пользователя из ответа.
Добавляют элемент «Assertion» -> «Response Assertion» для проверки статуса 201.

Базовая поставка JMeter поддерживает основные протоколы, но для расширенного функционала (например, работа с WebSocket, gRPC, GraphQL или улучшенная валидация JSON) используют плагинный менеджер JMeter Plugins Manager.

Процесс установки менеджера:

Скачивают файл PluginsManager.jar с официального репозитория GitHub.
Помещают его в папку lib/ext внутри директории установки JMeter.
Запускают JMeter и открывают меню «Options» -> «Plugins Manager».
В списке доступных плагинов находят нужные (например, JsonPath Assertion, GraphQL Support) и нажимают «Install Selected».
Перезапускают JMeter для применения изменений.

Для проведения тестов с разными данными (разные пользователи, разные токены) используют элементы управления данными.

CSV Data Set Config: Позволяет загружать данные из внешнего CSV-файла. Каждый ряд файла становится переменной, доступной в шагах теста.
User Defined Variables: Позволяют задать статические переменные прямо в интерфейсе.
Variables: Динамические значения, генерируемые скриптами Groovy.

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

Создают файл users.csv со столбцами username,password.
Добавляют элемент «CSV Data Set Config», указывают путь к файлу и имена переменных.
В запросе используют переменные как ${username} и ${password}.

JMeter предоставляет мощные инструменты для извлечения данных из ответов и их проверки.

JSON Extractor: Извлекает значения из JSON-ответов по пути (JSON Path). Результат сохраняется в переменную для использования в следующих запросах.
Regular Expression Extractor: Извлекает данные с помощью регулярных выражений (полезно для XML или сложных текстовых форматов).
Boundary Extractor: Извлекает данные между двумя заданными маркерами.
Assertions: Проверяют соответствие ответа ожидаемому значению. Поддерживают проверку кода ответа, текста, времени отклика и содержимого.

Запуск выполняется через графический интерфейс или консольную утилиту.

В графическом интерфейсе:

Нажимают кнопку «Start» (зеленый треугольник) на панели инструментов.
Результаты отображаются в реальном времени во вкладках «View Results Tree» или «Summary Report».

В консоли (для автоматизации):

Используют команду jmeter -n -t test_plan.jmx -l results.jtl.
- -n: Неграфический режим.
- -t: Путь к файлу теста (.jmx).
- -l: Путь к файлу логирования результатов (.jtl).
Можно добавить флаг -e для генерации HTML-отчета после завершения теста:
```
jmeter -n -t test_plan.jmx -l results.jtl -e -o ./report_folder
```

Интеграция с системами непрерывной интеграции (GitHub Actions, GitLab CI, Jenkins) происходит через запуск JMeter в неграфическом режиме.

Типичный сценарий в пайплайне:

Этап подготовки: Устанавливают Java и скачивают JMeter (или используют готовый образ Docker с JMeter).
Этап запуска: Выполняют команду jmeter -n -t path/to/test.jmx -l results.jtl.
Этап анализа: Парсят файл results.jtl для получения статистики или проверяют наличие ошибок.
Этап отчетности: Генерируют HTML-отчет с помощью команды jmeter -g results.jtl -o report_folder и прикрепляют его к сборке.

Хотя JMeter изначально создан для нагрузочного тестирования, он эффективно применяется и для функциональных проверок API благодаря возможности:

Создавать сложные цепочки запросов с зависимостями (извлечение данных из одного ответа и передача в другой).
Использовать скрипты Groovy для сложной логики обработки.
Моделировать различные сценарии поведения пользователей.
Проверять производительность одновременно с функциональностью.

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

UI и End-to-End (E2E) тестирование

End-to-End (E2E) тестирование имитирует действия реального пользователя в полной цепочке взаимодействия с системой: от запуска приложения и ввода данных до получения конечного результата. В веб- и мобильных приложениях это почти всегда включает взаимодействие с пользовательским интерфейсом (UI). Цель E2E-тестов — проверить, что система в целом работает корректно в условиях, приближенных к эксплуатационным, включая интеграцию с базами данных, сетевыми сервисами, аутентификацией и другими внешними зависимостями.

E2E-тесты, в отличие от юнит- и интеграционных, обладают рядом особенностей:

Высокая стоимость выполнения (медленные, требуют запуска браузера или эмулятора);
Хрупкость (чувствительны к изменениям UI);
Низкая диагностичность (при падении сложно определить корневую причину без дополнительной инструментации).

Тем не менее, они незаменимы для валидации критически важных пользовательских сценариев. Современные инструменты E2E-тестирования стремятся минимизировать эти недостатки за счёт:

автоматического ожидания состояний (auto-waiting);
встроенных механизмов отладки и визуализации;
поддержки параллелизма и изоляции тестов;
интеграции с облачными платформами для кросс-браузерного и кросс-платформенного тестирования.

Selenium WebDriver

Selenium — исторически первый и наиболее распространённый инструмент для автоматизации веб-браузеров. WebDriver, его основной компонент, предоставляет унифицированный API для управления браузерами (Chrome, Firefox, Safari, Edge и др.) через специальные драйверы (chromedriver, geckodriver и т.п.). Selenium поддерживает большинство языков программирования (Java, C#, Python, JavaScript и др.) и интегрируется с соответствующими юнит-фреймворками.

Ключевые преимущества Selenium:

кросс-браузерность;
зрелая экосистема и обширное сообщество;
поддержка реальных браузеров, а не только headless-режимов.

Однако он требует ручного управления ожиданиями, подвержен «флакингу» (нестабильности), а архитектура, основанная на JSON Wire Protocol, уступает по производительности современным альтернативам.

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

Для каждого популярного браузера требуется свой драйвер:

Chrome: chromedriver.
Firefox: geckodriver.
Edge: msedgedriver.
Safari: Встроен в macOS (требуется только включение функции в настройках).

Драйверы можно скачать вручную с официальных сайтов разработчиков или использовать инструменты автоматической загрузки (например, webdriver-manager для Java/C# или встроенные механизмы в современных версиях библиотек). Файлы драйверов должны быть доступны системе либо лежать в папке проекта, либо находиться в системной переменной среды PATH.

Процесс подключения зависит от языка программирования. Библиотека Selenium выступает как обертка над драйверами и предоставляет единый API для всех языков.

Для Python: Используют команду pip:

pip install selenium webdriver-manager

Пакет webdriver-manager часто добавляют для автоматического скачивания и управления версиями драйверов, что избавляет от ручного поиска файлов.

Для Java: В файле pom.xml добавляют зависимость:

<dependency>
    <groupId>org.seleniumhq.selenium</groupId>
    <artifactId>selenium-java</artifactId>
    <version>4.15.0</version>
    <scope>test</scope>
</dependency>

Для автоматизации драйверов также часто подключают selenium-webdriver и webdrivermanager.

Для C# (.NET): В файле .csproj или через NuGet Package Manager:

dotnet add package Selenium.WebDriver
dotnet add package WebDriverManager

После установки необходимо настроить создание экземпляра браузера в коде. Современные версии Selenium (начиная с 4.x) используют протокол W3C WebDriver, который позволяет передавать настройки драйвера прямо при создании объекта.

Пример создания Chrome-браузера в Python:

from selenium import webdriver
from selenium.webdriver.chrome.service import Service
from webdriver_manager.chrome import ChromeDriverManager
from selenium.webdriver.chrome.options import Options

options = Options()
options.add_argument('--headless') # Запуск без графического интерфейса (опционально)
options.add_argument('--no-sandbox')

service = Service(ChromeDriverManager().install())
driver = webdriver.Chrome(service=service, options=options)

Пример создания в Java:

import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.chrome.ChromeOptions;

ChromeOptions options = new ChromeOptions();
options.addArguments("--headless"); // Запуск без GUI
options.addArguments("--no-sandbox");

WebDriver driver = new ChromeDriver(options);

Selenium не является самостоятельным фреймворком для утверждений, поэтому его связывают с JUnit, TestNG, pytest или xUnit.

Типичная структура теста:

Setup: Инициализация драйвера перед каждым тестом (@BeforeEach, setup).
Test Logic: Открытие страницы, поиск элементов, взаимодействие, проверка результатов.
Teardown: Закрытие браузера после теста (@AfterEach, teardown) для освобождения ресурсов.

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

import pytest
from selenium import webdriver
from selenium.webdriver.common.by import By

@pytest.fixture(scope="function")
def browser():
    driver = webdriver.Chrome()
    yield driver
    driver.quit()

def test_login(browser):
    browser.get("https://example.com/login")
    assert "Login" in browser.title

Одной из главных проблем Selenium является нестабильность («flakiness») из-за разного времени загрузки страниц. Для решения этого используют явные ожидания (Explicit Waits), которые заставляют тест ждать появления элемента или выполнения условия, а не просто фиксированную паузу.

Использование WebDriverWait и условий (Expected Conditions):

from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

wait = WebDriverWait(driver, 10)
element = wait.until(EC.presence_of_element_located((By.ID, "username")))

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

Файлы тестов размещают в стандартных директориях проекта (tests, src/test/java и т.д.). Рекомендуется применять паттерн «Страница объектов» (Page Object Model), где каждый веб-элемент и действие на странице инкапсулированы в отдельном классе.

Структура папок:

project_root/
├── src/
│   └── main/...
├── tests/
│   ├── pages/
│   │   └── LoginPage.py
│   ├── tests/
│   │   └── test_login.py
│   └── conftest.py (или setup.py)

Такая архитектура упрощает поддержку: изменение структуры страницы требует правок только в одном месте класса страницы, а не во всех тестах.

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

В Python:

pytest tests/

В Java:

mvn test

В .NET:

dotnet test

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

Интеграция с системами непрерывной интеграции (GitHub Actions, GitLab CI, Jenkins) возможна благодаря поддержке headless-режимов и Docker.

Типичный сценарий в пайплайне:

Устанавливают зависимости проекта.
Скачивают необходимые браузеры и драйверы (часто используются готовые образы Docker, например, selenium/standalone-chrome).
Запускают тесты в контейнере или виртуальной машине.
При необходимости генерируют отчеты о покрытии или скриншоты при падении тестов.

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

Современные браузеры требуют особого внимания к настройкам безопасности и политикам доступа. Часто необходимо явно указывать пути к профилям пользователя, отключать расширения или задавать специфические флаги (например, --disable-dev-shm-usage для работы в Docker-контейнерах Linux).

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

Playwright

Playwright — современный инструмент от Microsoft, разработанный как ответ на ограничения Selenium и Puppeteer. Он поддерживает Chromium, WebKit и Firefox из коробки, без необходимости внешних драйверов. Playwright предоставляет:

автоматические ожидания (auto-waiting) до кликабельности, видимости и других состояний;
возможность перехвата и мокирования сетевых запросов;
поддержку нескольких контекстов браузера в одном процессе (изоляция);
встроенный video recording и tracing.

Playwright доступен для JavaScript/TypeScript, Python, Java и .NET, что делает его универсальным выбором для полиглотных команд.

Playwright поставляется с собственным инструментом командной строки, который автоматически скачивает необходимые браузеры (Chromium, WebKit, Firefox) и драйверы для выбранной платформы. Это устраняет необходимость ручной установки внешних исполняемых файлов, как это требовалось в Selenium.

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

Для JavaScript/TypeScript:

npm init playwright@latest

Или для установки вручную:

npm install -D @playwright/test
npx playwright install

Команда install скачивает браузеры и сохраняет их в каталог .cache/ms-playwright.

Для Python:

pip install playwright
playwright install

Для Java: В файле pom.xml добавляют зависимость:

<dependency>
    <groupId>com.microsoft.playwright</groupId>
    <artifactId>playwright</artifactId>
    <version>1.40.0</version>
    <scope>test</scope>
</dependency>

Затем выполняют команду в терминале:

mvn exec:java -e -D exec.mainClass=com.microsoft.playwright.CLI -D exec.args="install"

Для .NET:

dotnet add package Microsoft.Playwright.NUnit
dotnet playwright install

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

Для JavaScript/TypeScript создают файл playwright.config.ts (или .js).
Для Python — файл playwright.ini или параметры в pytest.ini.
Для Java — класс конфигурации или настройки в pom.xml.

Пример содержимого playwright.config.ts:

import { defineConfig, devices } from '@playwright/test';

export default defineConfig({
  testDir: './tests', // Директория с тестами
  fullyParallel: true, // Параллельный запуск тестов
  forbidOnly: !!process.env.CI, // Запрет дубликатов в CI
  retries: process.env.CI ? 2 : 0, // Количество повторов при ошибке в CI
  workers: process.env.CI ? 1 : undefined,
  reporter: 'html', // Генерация HTML-отчета
  use: {
    baseURL: 'https://example.com', // Базовый URL
    trace: 'on-first-retry', // Запись трассировки при первой ошибке
    screenshot: 'only-on-failure', // Скриншоты только при падении
  },
  projects: [
    {
      name: 'chromium',
      use: { ...devices['Desktop Chrome'] },
    },
    {
      name: 'firefox',
      use: { ...devices['Desktop Firefox'] },
    },
    {
      name: 'webkit',
      use: { ...devices['Desktop Safari'] },
    },
  ],
});

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

Файлы тестов размещают в директории, указанной в конфигурации (обычно tests). Playwright ожидает файлы с суффиксом .spec.ts, .spec.js, .py или .java в зависимости от языка.

Типичная структура:

project_root/
├── tests/
│   ├── login.spec.ts
│   └── api.spec.ts
├── playwright.config.ts
└── package.json

Playwright предоставляет интуитивно понятный API для взаимодействия со страницей. Автоматические ожидания (auto-waiting) реализованы внутри методов действия: инструмент сам ждет, пока элемент станет видимым, кликабельным и доступным для ввода, прежде чем выполнить действие.

Пример теста на TypeScript:

import { test, expect } from '@playwright/test';

test('должен открыть главную страницу', async ({ page }) => {
  await page.goto('/');
  await expect(page).toHaveTitle(/Example/);
  
  const button = page.getByRole('button', { name: /Login/i });
  await button.click();
  
  await expect(page.locator('#user-profile')).toBeVisible();
});

Метод getByRole использует семантическую разметку для поиска элементов, что делает тесты более устойчивыми к изменениям CSS-классов.

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

Пример перехвата ответа:

await page.route('**/api/users', route => {
  route.fulfill({
    status: 200,
    contentType: 'application/json',
    body: JSON.stringify([{ id: 1, name: 'Mock User' }]),
  });
});
await page.goto('/users');

Это особенно полезно для изоляции фронтенд-тестов от нестабильности бэкенда.

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

Каждый тест по умолчанию получает новый контекст, поэтому данные не смешиваются между тестовыми кейсами.

Инструмент автоматически записывает видео выполнения теста и создает детальную трассировку (tracing), если тест упал или настроена генерация отчета.

Для включения записи видео в конфигурации:

use: {
  video: 'retain-on-failure',
}

Трассировка создается автоматически при включении флага trace: 'on-first-retry'. Она позволяет воспроизвести каждый шаг теста, увидеть DOM-снимки, сетевые запросы и консольные логи в специальном интерфейсе.

Запуск осуществляется через консольную утилиту или скрипт в package.json.

Базовая команда:

npx playwright test

Дополнительные опции:

--headed: Запуск с графическим интерфейсом браузера (для отладки).
--project=chromium: Запуск только на конкретном браузере.
--reporter=list: Вывод результатов в консоль.
--ui: Запуск интерактивного режима отладки.

Playwright идеально подходит для автоматизации в пайплайнах благодаря поддержке headless-режимов и Docker.

В конфигурации GitHub Actions пример выглядит так:

- name: Install dependencies
  run: npm ci
- name: Install Browsers
  run: npx playwright install --with-deps
- name: Run Tests
  run: npx playwright test --reporter=line

Система автоматически скачивает браузеры, запускает тесты в режиме без GUI и генерирует отчеты. Playwright также поддерживает интеграцию с Allure Report для детальной визуализации результатов.

Playwright имеет единый API для JavaScript, Python, Java и .NET. Это позволяет разным членам команды использовать предпочитаемый язык для написания тестов, сохраняя общую структуру проектов и возможность совместного использования утилит и конфигураций.

Cypress

Cypress — E2E-фреймворк, работающий исключительно в браузере (в том же контексте, что и тестируемое приложение). Это позволяет ему обеспечивать мгновенную синхронизацию с DOM, автоматические ожидания и встроенный debugger. Cypress предлагает:

интерактивный режим разработки тестов (Time Travel);
визуальные отчёты об ошибках;
простую настройку без внешних зависимостей.

Ограничения: поддержка только Chromium-браузеров и Firefox (без Safari), отсутствие поддержки нескольких вкладок и iframe в ранних версиях (частично преодолено в версиях 10+). Cypress идеален для фронтенд-команд, разрабатывающих одностраничные приложения (SPA).

Cypress поставляется с собственной командной строкой (CLI), которая автоматически настраивает структуру проекта, устанавливает зависимости и создает базовые файлы конфигурации. Этот инструмент работает в контексте Node.js, поэтому проект должен быть инициализирован как модуль Node.

Для начала работы переходят в корневую директорию проекта и выполняют команду:

npx cypress open

Или для автоматической установки без открытия графического интерфейса:

npm install --save-dev cypress
npx cypress install

Первый вариант запускает мастер настройки, который предлагает выбрать тип тестирования (E2E, Component) и автоматически создает папки cypress или src с тестами. Второй вариант выполняет установку пакетов и настройку файлов конфигурации в фоновом режиме.

После установки создается файл конфигурации cypress.config.js (или cypress.config.ts для TypeScript). В нем определяются параметры запуска, пути к файлам тестов, таймауты и настройки браузеров.

Пример содержимого cypress.config.js:

const { defineConfig } = require("cypress");

module.exports = defineConfig({
  e2e: {
    baseUrl: "https://example.com", // Базовый URL приложения
    setupNodeEvents(on, config) {
      // Здесь можно добавить плагины или хуки
      return config;
    },
    specPattern: 'cypress/e2e/**/*.cy.{js,jsx,ts,tsx}', // Шаблоны имен файлов тестов
    supportFile: 'cypress/support/e2e.js', // Файл глобальных настроек
    viewportWidth: 1920,
    viewportHeight: 1080,
    video: true, // Запись видео выполнения
    screenshotOnRunFailure: true, // Скриншот при ошибке
  },
});

Файл supportFile позволяет добавлять глобальные команды и настройки, которые применяются ко всем тестам.

По умолчанию Cypress использует следующую иерархию папок внутри директории cypress:

e2e/ (или integration/ в старых версиях): Содержит файлы E2E-тестов.
components/: Для компонентного тестирования (если включено).
fixtures/: Хранит JSON/XML данные для моков.
support/: Содержит вспомогательные функции и глобальные команды.
plugins/: (В старых версиях) Для подключения плагинов.

Типичная структура:

project_root/
├── cypress/
│   ├── e2e/
│   │   └── login.cy.js
│   ├── fixtures/
│   │   └── user.json
│   ├── support/
│   │   ├── commands.js
│   │   └── e2e.js
│   └── cypress.config.js
├── package.json
└── node_modules/

Файлы тестов должны иметь суффикс .cy.js или .cy.ts.

Cypress предоставляет API, который выполняется прямо внутри браузера, что обеспечивает мгновенный доступ к DOM и объекту window. Тесты пишутся с использованием синтаксиса Chai для утверждений.

Пример теста на JavaScript:

describe('Сценарий входа', () => {
  it('должен успешно войти в систему', () => {
    cy.visit('/login');
    
    cy.get('#email').type('ivan@example.com');
    cy.get('#password').type('secret123');
    cy.get('button[type="submit"]').click();
    
    cy.url().should('include', '/dashboard');
    cy.contains('Добро пожаловать, Иван').should('be.visible');
  });
});

Метод cy автоматически ожидает появления элементов, их видимости и кликабельности, устраняя необходимость в явных ожиданиях (wait, sleep).

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

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

Открывают интерфейс тестирования командой npx cypress open.
Выбирают нужный файл теста.
Во время выполнения теста в боковой панели отображается список всех выполненных команд.
При наведении курсора на любой шаг показывается состояние страницы именно в этот момент (скриншот, DOM, консоль).
Можно кликнуть на любой шаг и сразу перейти к нему, чтобы проверить логику.

Cypress позволяет легко загружать данные из внешних файлов и перехватывать сетевые запросы.

Фикстуры: Данные хранятся в папке fixtures и загружаются командой cy.fixture().
```
cy.fixture('user.json').then((user) => {
  cy.request('POST', '/api/login', user);
});
```
Мокирование: Метод cy.intercept() перехватывает HTTP-запросы и возвращает заданные ответы без обращения к реальному серверу.
```
cy.intercept('GET', '/api/users', { fixture: 'users.json' }).as('getUsers');
cy.visit('/users');
cy.wait('@getUsers');
```

Запуск осуществляется через консольную утилиту или скрипт в package.json.

Базовая команда для запуска в headless-режиме (без GUI):

npx cypress run

Эта команда запускает все найденные тесты в браузере по умолчанию (обычно Chrome) и выводит отчет в терминал.

Дополнительные опции:

--browser chrome: Явное указание браузера.
--spec 'cypress/e2e/login.cy.js': Запуск конкретного файла.
--record: Запись результатов в облачное хранилище Cypress Cloud (при наличии аккаунта).
--env: Передача переменных окружения.

Cypress идеально интегрируется с системами непрерывной интеграции благодаря стабильному headless-режиму и возможности записи результатов в облако.

Типичный сценарий в пайплайне GitHub Actions:

- name: Install dependencies
  run: npm ci
- name: Run tests
  run: npx cypress run --record --key ${{ secrets.CYPRESS_RECORD_KEY }}

При использовании Docker образы Cypress уже содержат необходимые браузеры и драйверы, что упрощает настройку среды.

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

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

Puppeteer

Puppeteer — библиотека от Google для автоматизации Chromium и Chrome. В отличие от Selenium, она работает только с браузерами на основе Chromium, но предлагает более низкоуровневый и производительный контроль. Puppeteer часто используется для тестирования, генерации PDF, скриншотов, веб-скрапинга и анализа производительности.

Для тестирования Puppeteer обычно комбинируется с Jest или Mocha. Его основное преимущество — скорость и точность, но отсутствие поддержки Firefox и Safari ограничивает его применение в кросс-браузерных сценариях.

Puppeteer — это библиотека для среды Node.js, поэтому её установка выполняется через npm или yarn. При первом запуске команда установки автоматически скачивает последнюю стабильную версию браузера Chromium (без необходимости вручную искать драйверы, как в случае с Selenium).

Команда установки:

npm install puppeteer

Или для менеджера yarn:

yarn add puppeteer

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

Для гибкого управления поведением браузера (например, отключение графического интерфейса в CI/CD) часто создают файл конфигурации или используют переменные окружения. Однако базовая настройка может быть выполнена прямо в коде теста.

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

Puppeteer не является самостоятельным фреймворком для утверждений, поэтому его связывают с Jest, Mocha или Vitest.

Типичная структура теста:

Setup: Запуск браузера и создание новой страницы (page).
Test Logic: Переход по URL, взаимодействие с элементами, сбор данных.
Teardown: Закрытие браузера и освобождение ресурсов.

Пример интеграции с Jest:

const puppeteer = require('puppeteer');

describe('Тестирование главной страницы', () => {
  let browser;
  let page;

  // Инициализация перед каждым тестом
  beforeEach(async () => {
    browser = await puppeteer.launch({ headless: 'new' });
    page = await browser.newPage();
  });

  // Очистка после каждого теста
  afterEach(async () => {
    await browser.close();
  });

  it('должен загрузить заголовок', async () => {
    await page.goto('https://example.com');
    const title = await page.title();
    expect(title).toBe('Example Domain');
  });
});

Файлы тестов размещают в стандартных директориях проекта (tests, __tests__). Рекомендуется применять паттерн разделения логики: выносить управление браузером в отдельные утилиты или классы-обертки, если тестов много.

Типичная структура:

project_root/
├── src/
│   └── app.js
├── tests/
│   ├── browser.setup.js      # Общие функции создания браузера
│   ├── home.test.js          # Тесты главной страницы
│   └── api-scraper.test.js   # Скрипинг API
├── package.json
└── node_modules/

API Puppeteer предоставляет методы для навигации, поиска элементов, ввода данных и получения информации о странице. Все действия выполняются асинхронно.

Пример комплексного сценария:

it('должен заполнить форму и отправить запрос', async () => {
  await page.goto('https://example.com/form');
  
  // Заполнение полей
  await page.type('#username', 'Ivan');
  await page.type('#email', 'ivan@example.com');
  
  // Нажатие кнопки (с автоматическим ожиданием доступности)
  await page.click('button[type="submit"]');
  
  // Проверка результата (ожидание появления элемента)
  await page.waitForSelector('.success-message');
  
  const text = await page.$eval('.success-message', el => el.innerText);
  expect(text).toContain('Данные отправлены');
});

Методы type, click, goto автоматически ждут, пока элемент станет видимым и кликабельным, что устраняет необходимость в явных паузах.

Puppeteer обладает встроенными функциями для захвата состояния страницы и анализа сети без сторонних библиотек.

Скриншот:

await page.screenshot({ path: 'screenshot.png' });

Генерация PDF:

await page.pdf({ path: 'document.pdf', format: 'A4' });

Перехват сетевого трафика:

await page.setRequestInterception(true);
page.on('request', request => {
  if (request.url().includes('api')) {
    request.respond({ status: 200, body: JSON.stringify({ data: [] }) });
  } else {
    request.continue();
  }
});

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

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

Базовая команда для Jest:

npm test

Или напрямую через npx:

npx jest

При запуске в режиме CI/CD важно убедиться, что переменная окружения CI=1 установлена, так как некоторые версии Puppeteer могут менять поведение в зависимости от этого флага (например, отключать sandbox).

Интеграция с GitHub Actions, GitLab CI или Jenkins происходит автоматически благодаря поддержке headless-режима.

Типичный сценарий в пайплайне:

Устанавливают зависимости (npm ci).
Выполняют команду npx puppeteer browsers install chrome (если браузер не был скачан ранее).
Запускают тесты (npm test).

В отличие от Selenium, здесь не требуется устанавливать дополнительные драйверы в систему, так как Chromium скачивается внутри контейнера сборки вместе с библиотекой. Это упрощает настройку сред разработки и деплоя.

Начиная с версии 2.0, Puppeteer перешел на использование режима headless: 'new', который работает быстрее и надежнее старого режима. При написании новых тестов рекомендуется явно указывать этот флаг:

await puppeteer.launch({ headless: 'new' });

Также стоит учитывать, что Puppeteer обновляется синхронно с Chrome, поэтому при обновлении браузера на клиенте может потребоваться обновление версии пакета в проекте.

TestCafe

TestCafe — E2E-фреймворк, не требующий WebDriver или внешних драйверов. Он внедряет скрипты непосредственно в страницу, что упрощает настройку и повышает стабильность. TestCafe поддерживает параллельное выполнение на локальных и удалённых браузерах, включая мобильные устройства. Особенность — написание тестов на чистом JavaScript/TypeScript без необходимости в дополнительных assertion-библиотеках.

WebdriverIO

WebdriverIO — современная реализация WebDriver API поверх Node.js. Он объединяет гибкость Selenium с удобством JavaScript-экосистемы. WebdriverIO поддерживает как протокол WebDriver (для реальных браузеров), так и DevTools Protocol (для прямого управления Chromium), что обеспечивает максимальную производительность. Фреймворк включает в себя встроенные сервисы для отчётов, скриншотов, автоматических ожиданий и интеграции с BDD-фреймворками (Cucumber).

Appium

Appium — кросс-платформенный инструмент для автоматизации мобильных приложений (iOS, Android, Windows). Он реализует WebDriver-протокол для мобильных платформ, позволяя использовать один и тот же API для разных ОС. Appium поддерживает нативные, гибридные и веб-приложения. Для iOS используется XCUITest, для Android — UiAutomator2 или Espresso (в зависимости от конфигурации).

Detox

Detox — фреймворк для E2E-тестирования мобильных приложений, особенно популярный в экосистеме React Native. В отличие от Appium, Detox работает на уровне нативного кода (через grey-box подход), что позволяет синхронизироваться с внутренним состоянием приложения и избегать использования таймаутов. Это делает тесты значительно стабильнее и быстрее.

Maestro

Maestro — относительно новый инструмент для мобильного тестирования, основанный на декларативном YAML-описании сценариев. Он не требует написания кода и ориентирован на простоту и скорость написания тестов. Maestro автоматически синхронизируется с UI и поддерживает как Android, так и iOS. Хотя он менее гибок, чем Detox или Appium, его подход привлекателен для QA-инженеров без глубоких навыков программирования.

Нагрузочное и стресс-тестирование

Нагрузочное тестирование (load testing) и стресс-тестирование (stress testing) относятся к классу нефункционального тестирования, направленного на оценку поведения системы под определённой или экстремальной нагрузкой. Цель нагрузочного тестирования — определить, как система справляется с ожидаемым объёмом пользовательских запросов в штатном режиме. Стресс-тестирование, в свою очередь, проверяет устойчивость системы при условиях, выходящих за пределы нормальной эксплуатации: резкий всплеск трафика, отказ компонентов, истощение ресурсов и т.п.

Ключевые метрики, оцениваемые при таких тестах:

пропускная способность (throughput, запросов/сек);
время отклика (response time, latency);
ошибки (error rate);
потребление ресурсов (CPU, память, сеть, I/O);
масштабируемость и восстанавливаемость (recovery after failure).

Современные инструменты нагрузочного тестирования отличаются архитектурой (локальная vs распределённая), языком описания сценариев, возможностями генерации отчётов и интеграции с CI/CD-процессами.

JMeter

Apache JMeter — один из самых зрелых и широко применяемых инструментов для нагрузочного тестирования. Изначально созданный для тестирования веб-приложений, он со временем обрёл поддержку множества протоколов: HTTP/HTTPS, FTP, JDBC, JMS, SOAP, REST, LDAP и др.

JMeter использует визуально-ориентированную модель построения тестовых планов: сценарий представляется в виде иерархического дерева элементов (Thread Groups, Samplers, Listeners, Timers, Assertions). Это упрощает создание сложных сценариев без написания кода, но усложняет версионный контроль и повторное использование. Для автоматизации JMeter можно запускать в CLI-режиме и интегрировать в пайплайны через Maven, Gradle или Jenkins.

Преимущества:

богатая плагинная экосистема;
поддержка распределённой генерации нагрузки;
визуализация результатов в реальном времени.

Недостатки:

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

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

Gatling

Gatling — высокопроизводительный инструмент на базе Scala и Akka, ориентированный на асинхронную, неблокирующую генерацию нагрузки. В отличие от JMeter, сценарии в Gatling пишутся на Scala (или через DSL на Java/Kotlin), что обеспечивает типобезопасность, повторное использование кода и удобство версионирования.

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

Gatling интегрируется с Maven, Gradle, Jenkins и поддерживает CI/CD-ориентированный workflow. Он особенно популярен в средах, где важны воспроизводимость, точность измерений и автоматизация.

Gatling — это инструмент, который работает как часть процесса сборки проекта. Для интеграции необходимо добавить зависимости в файл pom.xml. Библиотека предоставляет DSL (Domain Specific Language) на Scala, но может использоваться из кода Java или Kotlin благодаря компилятору Scala.

В секцию <dependencies> файла конфигурации добавляют следующие элементы:

gatling-highcharts: Основной пакет, содержащий движок выполнения сценариев, DSL для написания тестов и генератор отчетов Highcharts.
scala-library: Зависимость необходима, так как синтаксис сценариев пишется на языке Scala. Обычно она подтягивается автоматически, но может быть указана явно.
gatling-charts-highcharts: Часто используется как альтернатива или дополнение для генерации отчетов.

Пример конфигурации зависимости версии 3.x (актуальная версия):

<dependency>
    <groupId>io.gatling.highcharts</groupId>
    <artifactId>gatling-charts-highcharts</artifactId>
    <version>3.9.5</version>
    <scope>test</scope>
</dependency>

В проектах на базе Gradle настройку выполняют внутри файла build.gradle. Для включения Gatling используют плагин scala или просто добавляют зависимость в секцию testImplementation.

Следующий блок кода подключает необходимые компоненты фреймворка:

dependencies {
    testImplementation 'io.gatling.highcharts:gatling-charts-highcharts:3.9.5'
}

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

Уникальной особенностью Gatling является размещение сценариев в директории src/test/scala (или src/test/java, если используется Java-версия DSL). Сценарии пишутся в виде классов, наследуемых от класса Simulation.

Структура папок типична для проекта:

project_root/
├── src/
│   └── main/
│       └── java/...
├── src/test/
│   ├── scala/
│   │   └── com/example/loadtests/
│   │       ├── ApiLoadTest.scala
│   │       └── LoginFlow.scala
│   └── resources/...
├── pom.xml
└── target/

Файлы сценариев имеют расширение .scala. Если используется Java-синтаксис (через обертки), файлы могут называться .java, но стандартным подходом является использование Scala для максимальной выразительности и производительности.

Тесты в Gatling описывают поведение виртуального пользователя через цепочку действий (Scenario). Каждый сценарий определяется в отдельном классе, наследующем от Simulation.

Пример содержимого файла ApiLoadTest.scala:

import io.gatling.core.Predef._
import io.gatling.http.Predef._
import scala.concurrent.duration._

class ApiLoadTest extends Simulation {

  // Определение протокола (базовые настройки HTTP)
  val httpProtocol = http
    .baseUrl("https://api.example.com")
    .acceptHeader("application/json")

  // Определение сценария поведения пользователя
  val scn = scenario("API Load Test").repeat(10) {
    exec(http("Get Users")
      .get("/users"))
    .pause(1.second)
    .exec(http("Get User Detail")
      .get("/users/1"))
  }

  // Настройка нагрузки (Ramp Up, Hold, Ramp Down)
  setUp(scn.injectOpen(rampUsers(100).during(1.minute)))
    .protocols(httpProtocol)
}

Код описывает последовательность запросов, паузы между ними и условия завершения. Метод setUp связывает сценарий с профилем нагрузки.

Запуск выполняется через командную строку или интерфейс IDE.

В Maven команда выглядит так:

mvn gatling:test

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

В Gradle используется:

gradle gatlingTest

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

После выполнения теста Gatling автоматически генерирует интерактивный HTML-отчет в директории target/gatling/default-<timestamp>/index.html.

Отчет содержит:

Графики времени отклика (среднее, 95-й перцентиль, 99-й перцентиль).
Количество успешных и неудачных запросов.
Статистику по количеству активных виртуальных пользователей во времени.
Детальные логи ошибок.

Отчеты можно просматривать в любом браузере без необходимости установки дополнительного ПО.

Gatling идеально подходит для автоматизации в пайплайнах непрерывной интеграции благодаря встроенной поддержке Maven и Gradle.

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

Устанавливает зависимости (mvn install или gradle build).
Запускает тесты (mvn gatling:test или gradle gatlingTest).
Сохраняет артефакты (HTML-отчеты) для последующего анализа.

Система автоматически помечает сборку как неудачную, если сценарий завершается с ошибкой или если пороги производительности (например, время отклика выше определенного значения) не выполнены. Это позволяет интегрировать проверку SLA прямо в процесс разработки.

Хотя Gatling изначально написан на Scala, его API позволяет писать сценарии на Java и Kotlin. Это расширяет возможности команды, позволяя использовать знакомый синтаксис. Однако для получения максимальной производительности и доступа к полным возможностям DSL рекомендуется использовать Scala.

Компилятор Scala обрабатывает код сценариев и превращает их в байт-код JVM, который выполняется высокопроизводительным движком Akka.

Gatling поддерживает сложные сценарии, такие как:

Параметризация данных: Загрузка данных из CSV/Excel файлов и использование их в запросах.
Проверки ответов: Автоматическая валидация статус-кодов, тела ответа и заголовков.
Динамические данные: Извлечение значений из одного ответа и использование их в следующих запросах (например, токены авторизации).
Моделирование сети: Имитация задержек сети, потери пакетов и других сетевых аномалий.

Эти функции делают Gatling мощным инструментом для стресс-тестирования сложных распределенных систем.

Locust

Locust — инструмент на Python, отличающийся декларативным и простым синтаксисом описания пользовательского поведения. Сценарии пишутся как обычные Python-функции с использованием асинхронных вызовов через библиотеку gevent. Это делает Locust чрезвычайно гибким: можно легко моделировать сложные цепочки запросов, использовать внешние библиотеки, генерировать данные на лету.

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

Ограничения: производительность уступает Gatling при очень высокой нагрузке из-за особенностей Python и gevent, но для большинства приложений достаточна.

Locust — это инструмент для нагрузочного тестирования, который устанавливается как обычная библиотека Python. Для корректной работы необходимо наличие среды выполнения Python версии 3.7 или новее.

Процесс установки выполняется через стандартный менеджер пакетов pip. Команда добавляет ядро фреймворка, библиотеку gevent (необходимую для асинхронности) и веб-интерфейс.

Базовая команда установки:

pip install locust

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

Уникальной особенностью Locust является написание сценариев в виде обычных Python-классов и функций. Это позволяет использовать всю мощь языка программирования для генерации данных, логики переходов и обработки ответов.

Необходимо создать файл с расширением .py (например, user_behavior.py) в корне проекта. Внутри файла определяют классы пользователей, наследуемые от базового класса User, и методы действий.

Пример содержимого файла user_behavior.py:

from locust import HttpUser, task, between

class WebsiteUser(HttpUser):
    # Время паузы между действиями пользователя (от 1 до 3 секунд)
    wait_time = between(1, 3)

    @task(3)
    def index_page(self):
        # Загрузка главной страницы с частотой 3 раза больше других задач
        self.client.get("/")

    @task(1)
    def get_about_page(self):
        # Загрузка страницы "О нас"
        self.client.get("/about")

    @task
    def create_account(self):
        # Создание аккаунта с передачей данных в теле запроса
        self.client.post("/login", json={"username": "test_user", "password": "secret"})

Ключевые элементы конструкции:

HttpUser: Базовый класс для создания пользователей, которые отправляют HTTP-запросы.
@task: Декоратор, помечающий метод как действие пользователя. Число после декоратора определяет вес задачи (вероятность её выбора).
wait_time: Метод, задающий случайную задержку между вызовами задач, что делает поведение более естественным.
self.client: Объект клиента, использующий библиотеку requests под капотом для отправки запросов.

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

Создание файла locustfile.py (или использование имени созданного ранее файла):

Файл должен содержать классы пользователей, описанные выше.
Локус автоматически сканирует файлы в текущей директории, ищет классы, наследуемые от User, и предлагает их в интерфейсе.

Locust предоставляет встроенный веб-сервер для визуализации результатов и управления нагрузкой. Для запуска инструмента выполняют команду в терминале, указывая имя файла сценария.

Команда запуска:

locust -f user_behavior.py

После выполнения команда откроет веб-интерфейс по адресу http://localhost:8089. Пользователь видит панель управления, где может ввести количество пользователей (users), скорость их появления (spawn rate) и нажать кнопку «Start».

Интерфейс отображает метрики в реальном времени:

Количество активных пользователей;
Скорость запросов в секунду (RPS);
Среднее время отклика;
Процент ошибок;
График загрузки.

Для масштабирования нагрузки на множество машин Locust поддерживает архитектуру мастер-воркер. Мастер-узел координирует работу воркеров, распределяя нагрузку и собирая статистику.

Запуск мастера:

locust --master -f user_behavior.py

Запуск одного из воркеров (на другой машине или в контейнере):

locust --worker --master-host=<IP_МАСТЕРА> -f user_behavior.py

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

Для автоматизации в пайплайнах непрерывной интеграции (GitHub Actions, GitLab CI, Jenkins) используют неграфический режим работы. В этом режиме Locust выполняет тесты и завершает работу с кодом ошибки, если превышены пороги производительности.

Создание файла конфигурации locust.conf (опционально) или передача параметров через командную строку:

locust -f user_behavior.py --headless --users=100 --spawn-rate=10 --run-time=60s --host=https://api.example.com

Параметры команды:

--headless: Запуск без открытия веб-интерфейса.
--users: Общее количество виртуальных пользователей.
--spawn-rate: Скорость появления пользователей в секунду.
--run-time: Время выполнения теста (например, 60 секунд).
--host: Базовый URL тестируемого приложения.

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

Locust умеет сохранять результаты тестов в различные форматы для последующего анализа.

Флаг --html генерирует подробный HTML-отчет:

locust -f user_behavior.py --headless --users=100 --spawn-rate=10 --run-time=60s --host=https://api.example.com --html=report.html

Отчет содержит графики, таблицы статистики и детальные данные об ошибках, доступные для просмотра в любом браузере после завершения теста. Также поддерживается экспорт данных в JSON или CSV для интеграции с внешними системами мониторинга.

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

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

import random
from locust import HttpUser, task

class DynamicUser(HttpUser):
    @task
    def search(self):
        query = f"product_{random.randint(1, 1000)}"
        self.client.get(f"/search?q={query}")

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

k6

k6 — современный инструмент с открытым ядром, написанный на Go, ориентированный на инженерные практики DevOps. Сценарии пишутся на JavaScript (ES2015+), но выполняются в собственном движке, что обеспечивает высокую производительность и предсказуемое потребление ресурсов.

k6 спроектирован с прицелом на:

CI/CD-интеграцию (поддержка thresholds — автоматический fail при превышении latency/error rate);
локальное и облачное выполнение (k6 Cloud);
тестирование не только HTTP, но и gRPC, WebSockets, мониторинга через Prometheus.

Отчёты могут выводиться в stdout, JSON, InfluxDB и другие системы. k6 особенно популярен в командах, практикующих «тестирование как код» и стремящихся к раннему включению нагрузочных тестов в пайплайн.

k6 — это самодостаточный инструмент, не требующий установки дополнительных зависимостей для базовой работы. Он распространяется как единый бинарный файл, что упрощает развертывание в любой среде.

Для установки на локальной машине используют официальный скрипт или скачивают архив с GitHub.

Скрипт установки для macOS и Linux:

curl --proto '=https' --tlsv1.2 -sSf https://raw.githubusercontent.com/grafana/k6/master/install.sh | sh

Эта команда автоматически определяет операционную систему, скачивает последнюю стабильную версию и размещает исполняемый файл k6 в системной директории (например, /usr/local/bin).

Для Windows можно скачать архив с бинарниками с официального репозитория GitHub и добавить путь к папке с файлом k6.exe в переменную среды PATH.

Проверка установки выполняется командой:

k6 version

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

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

Структура файла обычно включает импорт библиотеки k6, определение конфигурации и функции сценариев.

Пример базового сценария load_test.js:

import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    { duration: '30s', target: 10 },   // Разгон до 10 пользователей за 30 секунд
    { duration: '1m', target: 10 },    // Удержание нагрузки 1 минуту
    { duration: '30s', target: 0 },    // Сброс нагрузки за 30 секунд
  ],
  thresholds: {
    http_req_duration: ['p(95)<500'], // 95% запросов должны быть быстрее 500 мс
    http_req_failed: ['rate<0.01'],   // Уровень ошибок не более 1%
  },
};

export default function () {
  const res = http.get('https://example.com/api/health');
  
  check(res, {
    'status is 200': (r) => r.status === 200,
    'response time < 500ms': (r) => r.timings.duration < 500,
  });

  sleep(1); // Пауза между запросами
}

Функция options задает профиль нагрузки и пороги срабатывания. Если условия в thresholds нарушаются, тест завершается с ошибкой, что критично для автоматизации в CI/CD.

Для удобства запуска и управления версиями часто добавляют вызовы k6 в скрипты проекта, если он управляется через Node.js (npm) или аналогичные системы.

В файле package.json добавляют секцию "scripts":

{
  "scripts": {
    "test:load": "k6 run load_test.js",
    "test:load:cloud": "k6 cloud load_test.js",
    "test:load:report": "k6 run load_test.js --summary-export=report.json"
  }
}

Команда npm test:load запускает сценарий локально. Флаг --summary-export генерирует JSON-файл со сводной статистикой, который затем можно использовать для построения графиков или интеграции с дашбордами.

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

Для вывода отчета в консоль в реальном времени используют флаг --summary-export или стандартный вывод. Для интеграции с Prometheus можно запустить сервер k6 с экспортом метрик:

k6 run load_test.js --out json=results.json

Или подключить встроенный экспорт в InfluxDB:

k6 run load_test.js --out influx=http://localhost:8086/k6

Также поддерживается вывод в JSON для последующей обработки:

k6 run load_test.js --summary-export=summary.json

Эти данные позволяют интегрировать результаты тестов в системы аналитики, такие как Grafana, или передавать их в системы оповещения при нарушении SLA.

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

Базовая команда:

k6 run load_test.js

Инструмент выполняет сценарий согласно профилю нагрузки из options, собирает метрики производительности и выводит итоговый отчет в терминал. Отчет содержит среднее время ответа, проценты (p95, p99), количество успешных и неудачных запросов.

Дополнительные опции:

--vus: Явное указание количества виртуальных пользователей.
--duration: Ограничение времени выполнения теста.
--quiet: Тихий режим без вывода прогресса в консоль (удобно для CI).
--verbose: Подробный логирование каждого шага.

k6 идеально подходит для автоматизации в пайплайнах благодаря поддержке пороговых значений (thresholds) и возможности генерации машиночитаемых отчетов.

Типичный сценарий в пайплайне GitHub Actions:

- name: Install k6
  uses: grafana/k6-action@v0.0.1
- name: Run Load Test
  run: k6 run --summary-export=report.json load_test.js
- name: Check Thresholds
  if: always()
  run: |
    # Проверка exit code: если пороги превышены, k6 вернет код 1
    echo "Тест завершен"

Если условия в thresholds нарушаются, процесс завершается с ненулевым кодом выхода, что автоматически помечает сборку как неудачную. Это обеспечивает принцип «тестирование как код» и предотвращает попадание медленных или нестабильных релизов в продакшн.

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

Подключение требует наличия аккаунта и API-ключа. Команда запуска выглядит так:

k6 cloud load_test.js

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

Кроме HTTP, k6 поддерживает тестирование gRPC, WebSockets и других протоколов через встроенные библиотеки или внешние модули.

Для gRPC необходим дополнительный пакет:

k6 install go.k6.io/xk6-gRPC/v1

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

Библиотека k6/prometheus позволяет отправлять метрики прямо в Prometheus:

import { Trend, Counter } from 'k6/metrics';

const myTrend = new Trend('my_custom_metric');

export default function () {
  myTrend.add(http.get('https://example.com').timings.duration);
}

Такая гибкость делает k6 универсальным инструментом для комплексной оценки производительности распределенных систем.

Тестирование безопасности

Тестирование безопасности (security testing) направлено на выявление уязвимостей, недостатков в защите и несоответствий требованиям информационной безопасности в программном обеспечении. В отличие от функционального тестирования, где проверяется соответствие ожидаемому поведению, security-тестирование предполагает активный поиск слабых мест, которые могут быть использованы злоумышленниками для несанкционированного доступа, модификации данных, отказа в обслуживании или утечки информации.

Современное security-тестирование включает как автоматизированные сканирования, так и ручной анализ (penetration testing). Инструменты этой категории делятся на:

динамические анализаторы (DAST — Dynamic Application Security Testing), работающие с запущенным приложением;
статические анализаторы (SAST), анализирующие исходный код (в данной главе не рассматриваются, так как фокус — на runtime-инструментах);
специализированные утилиты для эксплуатации конкретных типов уязвимостей.

OWASP ZAP (Zed Attack Proxy)

OWASP ZAP — это open-source инструмент DAST, разработанный под эгидой OWASP (Open Web Application Security Project). Он предназначен для автоматического и полуавтоматического сканирования веб-приложений на наличие уязвимостей, таких как XSS, SQL-инъекции, CSRF, небезопасные конфигурации и др.

ZAP работает как прокси-сервер между браузером и тестируемым приложением, перехватывая и анализируя весь трафик. Он поддерживает:

автоматическое сканирование (Active Scan);
пассивный анализ (Passive Scan) без вмешательства в работу приложения;
fuzzing (перебор входных данных);
скриптовую автоматизацию на JavaScript;
интеграцию с CI/CD через CLI.

OWASP ZAP особенно ценен на этапах разработки и тестирования, где требуется раннее выявление уязвимостей без привлечения специалистов по информационной безопасности.

OWASP ZAP (Zed Attack Proxy) — это автономное приложение с графическим интерфейсом, написанное на Java. Для работы необходимо наличие среды выполнения Java (JRE или JDK).

Процесс установки выглядит следующим образом:

Переходят на официальный сайт проекта (owasp.org/www-project-zap/).
В разделе «Downloads» выбирают последнюю стабильную версию для своей операционной системы (Windows, macOS, Linux).
Скачивают установочный файл (например, zap-stable-*.exe для Windows или архив .tar.gz для Linux/macOS).
Запускают установщик или распаковывают архив в удобную директорию.
При первом запуске программа автоматически обновляет списки уязвимостей и дополнений.

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

Для интеграции в пайплайны CI/CD и автоматизации процессов используют неграфический режим работы. В этом режиме ZAP работает как сервер, управляемый через команды терминала или API.

Установка CLI-версии часто выполняется вместе с десктопным приложением, так как бинарные файлы находятся в одной папке.

Команда запуска в режиме headless:

./zap.sh -daemon -port 8090 -config api.key=YOUR_API_KEY

Или для Windows:

zap.bat -daemon -port 8090 -config api.key=YOUR_API_KEY

Параметры:

-daemon: Запуск без графического интерфейса.
-port: Порт, на котором слушает API (по умолчанию 8090).
-config: Передача параметров конфигурации, включая ключ API (api.key), который генерируется автоматически при первом запуске и хранится в файле настроек.

Основной принцип работы ZAP — использование его в качестве прокси между браузером пользователя и тестируемым приложением. Это позволяет инструменту видеть весь трафик, отправляемый и получаемый браузером.

Процесс настройки:

Открывают настройки браузера (например, Firefox или Chrome).
В разделе «Сеть» или «Прокси» указывают адрес localhost и порт 8090 (или тот, что указан в параметрах запуска ZAP).
Если используется десктопная версия, можно нажать кнопку «Open Browser» внутри интерфейса ZAP, которая автоматически настроит прокси и откроет браузер.
Важно импортировать корневой сертификат безопасности ZAP в доверенные сертификаты браузера, чтобы инструмент мог расшифровывать HTTPS-трафик. Сертификат скачивается по адресу http://zap.

Для автоматизации тестов в CI/CD создают файл конфигурации в формате JSON, описывающий шаги выполнения: захват трафика, активное сканирование, паузы, экспорт отчета.

Пример содержимого файла zap-automation.json:

{
  "rules": [
    {
      "id": "passive-scan",
      "name": "Passive Scan",
      "type": "scan",
      "params": {
        "url": "https://example.com",
        "contextName": "MyContext"
      }
    },
    {
      "id": "active-scan",
      "name": "Active Scan",
      "type": "scan",
      "params": {
        "url": "https://example.com",
        "contextName": "MyContext",
        "scanPolicyName": "Default Policy"
      }
    },
    {
      "id": "export-report",
      "name": "Export Report",
      "type": "report",
      "params": {
        "templateId": "traditional-json",
        "outputPath": "/path/to/report.json"
      }
    }
  ],
  "urls": ["https://example.com"],
  "contexts": ["MyContext"]
}

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

Наиболее удобный способ использования ZAP в CI/CD — запуск контейнера Docker. Образ owasp/zap2docker-stable содержит все необходимые компоненты и не требует ручной установки зависимостей.

Типичная команда запуска в пайплайне:

docker run --rm owasp/zap2docker-stable zap-baseline.py -t https://example.com -r report.html

Команда zap-baseline.py автоматически выполняет пассивное и активное сканирование заданного URL и генерирует отчет в формате HTML.

Для более сложной логики используют команду zap-cli или прямой вызов API:

docker run --rm -v $(pwd):/zap/wrk/:rw owasp/zap2docker-stable \
  zap-cli quick-scan https://example.com -s high -o report.xml

Флаг -v монтирует локальную папку проекта в контейнер, чтобы сохранить результаты сканирования на хост-машине.

ZAP поддерживает множество форматов отчетов, включая HTML, XML, JSON, Markdown и PDF. Формат выбирается в зависимости от требований системы отчетности.

Основные параметры экспорта:

HTML: Интерактивный отчет для просмотра человеком.
JSON/XML: Машиночитаемые форматы для парсинга в CI/CD системах.
SARIF: Стандартный формат для интеграции с инструментами статического анализа кода (например, GitHub Security Alerts).

Пример команды для генерации отчета SARIF:

zap-api-scan.py -f openapi.yaml -t https://example.com -O sarif -r zap-report.sarif

Для тонкой настройки глубины и агрессивности сканирования используют политики (Scan Policies). Можно выбрать стандартные профили («Default», «Fast Attack») или создать свои, исключая опасные проверки для определенных типов приложений.

В CLI это делается через флаг -p:

zap-baseline.py -t https://example.com -p "Custom Policy"

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

Подключение ZAP к пайплайнам (GitHub Actions, GitLab CI, Jenkins) происходит через запуск Docker-контейнера или CLI-утилиты.

Типичный сценарий в пайплайне:

Этап подготовки: Устанавливают зависимости (если не используется Docker) или скачивают образ.
Этап запуска: Выполняют команду сканирования целевого URL.
Этап анализа: Парсят полученный отчет (XML/JSON) и проверяют количество критических уязвимостей.
Этап принятия решения: Если найдены критические ошибки, сборка помечается как неудачная.

Пример условия в GitHub Actions:

- name: Run OWASP ZAP
  run: docker run --rm owasp/zap2docker-stable zap-baseline.py -t ${{ secrets.TARGET_URL }} -r report.xml
- name: Check Results
  run: |
    if grep -q "High" report.xml; then
      echo "Critical vulnerabilities found!"
      exit 1
    fi

ZAP поддерживает написание скриптов на JavaScript (Groovy, Python) для расширения функциональности. Эти скрипты могут выполнять сложные действия: модификацию запросов, генерацию данных для fuzzing, динамическую настройку контекстов.

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

Инструмент особенно эффективен на этапах разработки, где требуется раннее выявление проблем. Разработчики могут запустить базовое сканирование перед коммитом кода, чтобы убедиться в отсутствии критических уязвимостей.

Важно помнить, что ZAP — это DAST-инструмент (Dynamic Application Security Testing), поэтому он требует работающего приложения для анализа. Он не заменяет SAST (статический анализ кода), а дополняет его, проверяя поведение приложения в реальном времени.

Burp Suite

Burp Suite — коммерческий (с бесплатной Community-версией) инструмент от компании PortSwigger, считающийся промышленным стандартом для ручного и автоматизированного тестирования веб-безопасности. Его архитектура основана на модульной системе инструментов (Proxy, Scanner, Intruder, Repeater, Sequencer и др.), объединённых в единую платформу.

Ключевые возможности:

Proxy — перехват и модификация запросов/ответов в реальном времени;
Scanner (в Pro-версии) — автоматическое сканирование с высокой точностью и низким числом ложных срабатываний;
Intruder — инструмент для fuzzing и brute-force атак;
Repeater — ручная отправка и модификация запросов для проверки гипотез.

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

Burp Suite — это автономное приложение с графическим интерфейсом, написанное на Java. Для работы необходимо наличие среды выполнения Java (JRE или JDK). Компания PortSwigger предлагает две версии: Community Edition (бесплатная, ограниченная функционалом сканирования) и Professional Edition (коммерческая, с полным набором инструментов автоматизации).

Процесс установки выглядит следующим образом:

Переходят на официальный сайт PortSwigger (portswigger.net/burp).
В разделе «Downloads» выбирают версию Community Edition (или Professional, если есть лицензия).
Скачивают установочный файл для соответствующей операционной системы (Windows, macOS, Linux).
Запускают установщик и следуют инструкциям мастера.
После завершения процесса приложение готово к работе. При первом запуске может потребоваться активация лицензии (для профессиональной версии) или принятие условий использования (для бесплатной).

Встроенный клиент автоматически настраивает прокси-сервер для локального использования.

Основной принцип работы Burp Suite — использование его в качестве прокси между браузером пользователя и тестируемым приложением. Это позволяет инструменту видеть весь трафик, отправляемый и получаемый браузером, и модифицировать его в реальном времени.

Процесс настройки:

Открывают настройки браузера (например, Firefox или Chrome).
В разделе «Сеть» или «Прокси» указывают адрес localhost и порт 8080 (стандартный порт Burp Proxy).
Если используется десктопная версия, можно нажать кнопку «Open Browser» внутри интерфейса Burp, которая автоматически настроит прокси и откроет браузер.
Важно импортировать корневой сертификат безопасности Burp в доверенные сертификаты браузера, чтобы инструмент мог расшифровывать HTTPS-трафик. Сертификат скачивается по адресу http://burpsuite или через меню «Proxy» -> «Options» -> «CA Certificate».

После настройки прокси становятся доступными основные инструменты Burp Suite:

Proxy: Отображает все проходящие запросы и ответы. Позволяет приостанавливать трафик для анализа.
Repeater: Позволяет отправить любой перехваченный запрос повторно, изменив его параметры (заголовки, тело, параметры), и сразу увидеть результат. Критически важен для проверки гипотез уязвимостей.
Intruder: Инструмент для автоматизированного перебора (fuzzing) и подбора данных (brute-force). Позволяет задавать списки значений для конкретных параметров запроса и анализировать различия в ответах сервера.
Sequencer: Анализирует случайность генерируемых токенов и сессионных ID.
Decoder: Конвертирует данные между различными форматами кодирования (URL, Base64, Hex и т.д.).

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

Процесс создания:

В главном окне Burp Suite переходят во вкладку «Project options».
Создают новый проект и сохраняют его в файл с расширением .bpr.
В проекте можно определять контексты (Contexts), которые группируют целевые ресурсы, определяют авторизацию, типы данных и правила обработки ответов.

Для интеграции в пайплайны CI/CD и автоматизации процессов используют встроенный API Burp Suite. Он доступен как в Community, так и в Professional версиях, но некоторые функции (например, автоматическое сканирование) требуют лицензии Professional.

Автоматизация выполняется через скрипты на Python или Java, которые взаимодействуют с Burp через расширение API.

Пример структуры скрипта на Python:

import sys
sys.path.append('/path/to/burp_api')
from burp import IBurpExtender, IScannerCheck, IScanIssue

class MyExtension(IBurpExtender):
    def registerExtenderCallbacks(self, callbacks):
        self.callbacks = callbacks
        self.helpers = callbacks.getHelpers()
        # Регистрация кастомных проверок или логика автоматизации

Скрипт загружается в Burp через меню «Extensions» -> «Add Extension».

Подключение Burp Suite к пайплайнам (GitHub Actions, GitLab CI, Jenkins) происходит через запуск CLI-инструмента Burp Scanner или использование Docker-образа.

Типичный сценарий в пайплайне с использованием Docker:

docker run --rm -v $(pwd):/workdir portswigger/burp-scan-cli \
  -t https://example.com \
  -o report.html \
  -f html

Или использование официальных образов для запуска сканирования:

docker run --rm -v $(pwd):/zap/wrk/:rw owasp/zap2docker-stable \
  zap-baseline.py -t https://example.com -r report.xml

Примечание: Для Burp Suite Professional часто используются специализированные образы Docker от PortSwigger, поддерживающие CLI-режим.

Команда сканирования выполняет автоматический анализ уязвимостей, генерирует отчет в формате HTML, XML или JSON и завершает работу с кодом ошибки, если найдены критические проблемы.

Burp Suite поддерживает множество форматов отчетов, включая HTML, XML, JSON, Markdown и PDF. Формат выбирается в зависимости от требований системы отчетности.

Основные параметры экспорта:

HTML: Интерактивный отчет для просмотра человеком.
JSON/XML: Машиночитаемые форматы для парсинга в CI/CD системах.
SARIF: Стандартный формат для интеграции с инструментами статического анализа кода (например, GitHub Security Alerts).

Пример команды для генерации отчета SARIF (если поддерживается):

burpsuite-cli scan -t https://example.com -o sarif -r burp-report.sarif

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

Расширения загружаются через меню «Extensions» -> «Add extension» и могут быть установлены из репозитория BApp Store (библиотека готовых расширений).

Важно помнить, что Burp Suite — это DAST-инструмент (Dynamic Application Security Testing), поэтому он требует работающего приложения для анализа. Он не заменяет SAST (статический анализ кода), а дополняет его, проверяя поведение приложения в реальном времени.

Для профессионального использования рекомендуется приобрести лицензию Professional, которая включает автоматическое сканирование, поддержку API и приоритетную техническую поддержку. Бесплатная версия Community Edition подходит для ручного тестирования и обучения, но ограничена в возможностях автоматизации и глубине сканирования.

SQLmap

SQLmap — автоматизированная консольная утилита с открытым исходным кодом, предназначенная исключительно для обнаружения и эксплуатации уязвимостей типа SQL-инъекция. Инструмент поддерживает широкий спектр СУБД (MySQL, PostgreSQL, Oracle, MSSQL, SQLite и др.), автоматически определяет тип базы данных, извлекает структуру схемы, данные, а в некоторых случаях — выполняет команды ОС.

SQLmap работает путём отправки специально сконструированных запросов и анализа ответов на предмет изменений (time-based, boolean-based, error-based инъекции). Он активно используется как на этапе тестирования, так и в образовательных целях для демонстрации рисков небезопасного обращения с SQL-запросами.

Важно: использование SQLmap допустимо только в рамках авторизованного тестирования.

SQLmap написан на языке Python, поэтому для его работы необходима установленная среда Python (версии 3.x). Перед установкой рекомендуется убедиться, что версия Python актуальна, так как инструмент активно развивается и может использовать новые синтаксические конструкции.

Также требуется наличие интернета для скачивания зависимостей и обновлений базы данных уязвимостей.

Самый простой и рекомендуемый способ установки — использование менеджера пакетов pip, входящего в состав Python.

Выполните команду в терминале:

pip install sqlmap

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

Для системных дистрибутивов Linux (например, Ubuntu/Debian) можно установить пакет через системный менеджер пакетов, но версия из pip обычно является более свежей:

sudo apt-get install python3-sqlmap

Однако для получения последней версии лучше использовать метод с pip.

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

Команды:

git clone https://github.com/sqlmapproject/sqlmap.git
cd sqlmap
python3 sqlmap.py --version

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

SQLmap не требует сложной конфигурации файлов проекта. Он запускается напрямую через интерпретатор Python или через созданный скрипт обертки.

Базовая команда запуска:

python3 sqlmap.py -u "https://example.com/page?id=1"

Где:

-u: URL адрес тестируемой страницы с параметром, который подозревается на наличие уязвимости.
Инструмент автоматически определит тип СУБД, проведет анализ и предложит варианты эксплуатации.

Для эффективного использования необходимо правильно указать целевой объект.

Тестирование конкретного параметра:
```
sqlmap -u "https://example.com/product?id=1&cat=books" -p id
```
Параметр -p указывает конкретный параметр (id) для проверки, игнорируя остальные.
Чтение параметров из файла (Cookie, Headers): Если для доступа к ресурсу требуются куки или заголовки авторизации, их можно передать через файл:
```
sqlmap -u "https://example.com/admin" --cookie="session=abc123"
```
Или использовать файл request.txt для передачи полного HTTP-запроса:
```
sqlmap -r request.txt
```
Выбор метода инъекции: По умолчанию SQLmap пытается определить тип инъекции самостоятельно (boolean-based, time-based, error-based). Можно принудительно задать метод:
```
sqlmap -u "https://example.com" --batch --technique=T
```
Где T означает только время-based тесты.

Для снижения интерактивности при использовании в скриптах или образовательных демонстрациях включается режим «batch». В этом режиме инструмент принимает все решения самостоятельно, не запрашивая подтверждения у пользователя.

Флаг --batch:

sqlmap -u "https://example.com" --batch

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

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

Пример команды для скрипта:

python3 sqlmap.py -u "http://test-env.local/login" --batch --dump --tables --risk=3 --level=5

Параметры:

--dump: Извлечение данных.
--tables: Вывод списка таблиц.
--risk и --level: Настройка агрессивности тестирования (от 1 до 5). Высокие значения увеличивают риск нарушения работы сервиса.

Nessus

Nessus — коммерческий сканер уязвимостей от Tenable, ориентированный на инфраструктурное и сетевое тестирование. В отличие от OWASP ZAP и Burp Suite, Nessus фокусируется на операционных системах, сетевых устройствах, базах данных и сервисах (SSH, RDP, SMB и др.).

Он использует обширную базу сигнатур (более 80 000 проверок), обновляемую ежедневно, и способен обнаруживать устаревшие версии ПО, неправильные настройки, открытые порты и известные CVE-уязвимости. Nessus часто применяется в enterprise-средах для аудита соответствия политикам безопасности (например, PCI DSS, HIPAA).

Хотя Nessus не является инструментом для тестирования кода приложения напрямую, он критически важен для оценки окружающей среды, в которой это приложение работает.

Тестирование мобильных приложений

Мобильные приложения предъявляют уникальные требования к тестированию, обусловленные разнообразием платформ (iOS, Android), устройств (разные размеры экранов, сенсоры, производительность), операционных систем (множество версий), а также спецификой взаимодействия с пользователем (жесты, ориентация, фон/активность, push-уведомления). Тестирование мобильных приложений включает как функциональные, так и нефункциональные аспекты: UI, производительность, потребление батареи, работу в условиях нестабильного соединения и т.д.

Инструменты для мобильного тестирования можно разделить на три категории:

Кросс-платформенные — единый код для iOS и Android;
Нативные — специализированные фреймворки для одной платформы;
Гибридные/специализированные — ориентированные на определённые типы приложений (например, React Native).

Appium

Appium — самый известный кросс-платформенный инструмент для автоматизации мобильных приложений. Он реализует протокол WebDriver для мобильных ОС, что позволяет использовать привычные API и интегрировать тесты в существующие Selenium-инфраструктуры. Appium поддерживает:

нативные приложения (написанные на Swift/Kotlin);
гибридные (веб-контент внутри WebView);
мобильные веб-сайты.

Для Android Appium использует UiAutomator2 (или Espresso в режиме automationName: Espresso), для iOS — XCUITest. Это обеспечивает взаимодействие на уровне нативных тестовых фреймворков, что повышает стабильность и точность. Appium работает по принципу «не нужно перекомпилировать приложение», что упрощает интеграцию в CI/CD.

Ключевое ограничение — скорость выполнения тестов из-за накладных расходов на межпроцессное взаимодействие.

Espresso (Android)

Espresso — нативный фреймворк для Android, разработанный Google. Он работает внутри процесса приложения, что обеспечивает мгновенную синхронизацию с UI-потоком и исключает необходимость в ручных ожиданиях. Тесты на Espresso компилируются вместе с приложением и запускаются на устройстве или эмуляторе через Android Test Orchestrator.

Преимущества:

высокая стабильность и скорость;
глубокая интеграция с Android SDK;
поддержка сценариев с несколькими Activity и Fragment.

Недостатки:

только для Android;
ограниченная поддержка WebView без дополнительных настроек;
требует знания Kotlin/Java.

Espresso является стандартом для юнит- и UI-тестирования в официальной документации Android.

XCUITest (iOS)

XCUITest — нативный фреймворк от Apple для тестирования iOS-приложений. Он является частью XCTest и работает на уровне UI-иерархии приложения через private API. XCUITest позволяет записывать и воспроизводить взаимодействия с интерфейсом, поддерживает параметризацию и интеграцию с Xcode.

Ключевые особенности:

запуск только на симуляторах или реальных устройствах под управлением macOS;
строгая изоляция между тестом и приложением (grey-box подход);
встроенная поддержка доступности (accessibility identifiers) для надёжной локации элементов.

XCUITest — основной выбор для iOS-разработчиков, особенно в enterprise-средах.

Detox (React Native)

Detox — фреймворк, разработанный Wix, специально для E2E-тестирования React Native-приложений. В отличие от Appium, Detox использует grey-box подход: он интегрируется в нативный код приложения и получает информацию о его внутреннем состоянии (например, завершении анимаций, сетевых запросов). Это позволяет избегать таймаутов и делать тесты детерминированными.

Detox поддерживает как iOS (через EarlGrey), так и Android (через Espresso), и пишется на JavaScript/TypeScript. Он особенно эффективен в CI/CD благодаря стабильности и скорости.

Maestro

Maestro — современный инструмент с открытым ядром, предлагающий декларативный подход к мобильному тестированию. Сценарии описываются в YAML-файлах, что делает их легко читаемыми и поддерживаемыми даже без глубоких навыков программирования:

appId: com.example.app
---
- launchApp
- tapOn: "Login"
- inputText: "user@example.com"
- assertVisible: "Welcome"

Maestro автоматически синхронизируется с UI через accessibility-метки и поддерживает как Android, так и iOS. Его философия — «максимальная простота при достаточной выразительности». Хотя гибкость уступает кодовым фреймворкам, Maestro быстро набирает популярность в командах, стремящихся снизить порог входа в автоматизацию.

Тестирование баз данных

Тестирование баз данных (database testing) направлено на верификацию корректности структуры данных, целостности, производительности запросов и соответствия бизнес-логике на уровне СУБД. В отличие от тестирования прикладного кода, где акцент делается на поведении функций, тестирование базы данных фокусируется на:

валидности схемы (таблицы, индексы, ограничения, триггеры);
корректности выполнения DML-операций (INSERT, UPDATE, DELETE);
консистентности данных при транзакциях;
производительности сложных запросов и планов выполнения;
соблюдении бизнес-правил, реализованных на уровне хранимых процедур или представлений.

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

DBUnit (Java)

DBUnit — расширение для JUnit, предназначенное для управления состоянием базы данных в тестах. Он позволяет:

загружать эталонные данные из XML, CSV или JSON перед выполнением теста;
выгружать текущее состояние БД для сравнения;
очищать или восстанавливать данные после теста.

DBUnit работает на уровне отдельных таблиц и поддерживает различные стратегии вставки данных (CLEAN_INSERT, REFRESH, DELETE_ALL и др.). Это особенно полезно при тестировании DAO-слоёв или сервисов, напрямую взаимодействующих с БД, где важно контролировать точное начальное состояние.

DBUnit не заменяет ORM-тесты, но дополняет их, обеспечивая воспроизводимость и изоляцию.

Для интеграции библиотеки DBUnit в проект, управляемый через Maven, необходимо добавить зависимости в файл pom.xml. Библиотека предоставляет инструменты для работы с эталонными данными (datasets) и управления состоянием базы данных во время выполнения тестов.

В секцию <dependencies> файла конфигурации добавляют следующие элементы:

dbunit: Основной пакет, содержащий ядро фреймворка, классы для работы с таблицами и стратегии очистки/вставки данных.
junit-jupiter-api или testng: Зависимость от основного фреймворка тестирования (JUnit 5 или TestNG), так как DBUnit является расширением для них.
jdbc-driver: Драйвер конкретной СУБД (например, H2, PostgreSQL, MySQL), к которой подключается приложение, необходим для создания соединения.
commons-dbcp2 (опционально): Часто используется для управления пулом соединений в тестах, если требуется изоляция транзакций.

Пример конфигурации зависимости версии 2.x (актуальная версия):

<dependency>
    <groupId>org.dbunit</groupId>
    <artifactId>dbunit</artifactId>
    <version>2.7.0</version>
    <scope>test</scope>
</dependency>
<dependency>
    <groupId>com.h2database</groupId>
    <artifactId>h2</artifactId>
    <version>2.2.224</version>
    <scope>test</scope>
</dependency>

После добавления этих строк необходимо выполнить команду mvn clean install для автоматического скачивания библиотек из репозитория Maven Central.

В проектах на базе Gradle настройку выполняют внутри файла build.gradle. Для включения DBUnit используют плагин java и добавляют зависимости в секцию testImplementation.

Следующий блок кода подключает необходимые компоненты фреймворка:

dependencies {
    testImplementation 'org.dbunit:dbunit:2.7.0'
    testImplementation 'com.h2database:h2:2.2.224'
    // Если используется JUnit 5
    testImplementation 'org.junit.jupiter:junit-jupiter-api:5.9.3'
}

Также важно настроить задачу сборки для использования JUnit 5 или TestNG. В современных версиях Gradle это делается путем указания платформы в задаче теста:

tasks.named('test') {
    useJUnitPlatform()
}

Команда gradle build или gradle test инициирует скачивание библиотек и их подключение к проекту.

В IntelliJ IDEA процесс выглядит следующим образом:

Открывают файл pom.xml или build.gradle.
Нажимают кнопку «Reload Project» (иконка с двумя стрелками) в правом верхнем углу редактора.
IDE автоматически создает структуру папок src/test/java, куда помещают файлы тестов.
При создании нового класса теста IDE предлагает импортировать статические методы из org.dbunit.dataset.DataSet и классы DatabaseTester или IDatabaseConnection.

Уникальной особенностью DBUnit является использование внешних файлов для хранения эталонного состояния базы данных. Эти файлы размещают в директории src/test/resources/datasets (или аналогичной).

Поддерживаемые форматы файлов:

XML: Стандартный формат, описывающий таблицы и строки в виде тегов.
CSV: Простой текстовый формат, где каждая строка представляет запись.
JSON: Современный формат для хранения данных.

Типичная структура проекта:

project_root/
├── src/
│   └── main/...
├── src/test/
│   ├── java/...
│   └── resources/
│       └── datasets/
│           ├── users.xml
│           └── orders.csv
├── pom.xml
└── target/

Пример содержимого файла users.xml:

<?xml version="1.0" encoding="UTF-8"?>
<dataset>
    <USERS ID="1" NAME="Ivan" EMAIL="ivan@example.com"/>
    <USERS ID="2" NAME="Maria" EMAIL="maria@example.com"/>
</dataset>

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

Использование аннотации @DBUnitTest (для JUnit 5 с плагином dbunit-junit5) или ручное управление через DatabaseTester:

Пример теста с ручной инициализацией:

import org.dbunit.database.DatabaseConnection;
import org.dbunit.dataset.IDataSet;
import org.dbunit.dataset.xml.FlatXmlDataSetBuilder;
import org.dbunit.operation.DatabaseOperation;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;

import javax.sql.DataSource;
import java.sql.Connection;

public class UserServiceTest {

    private DataSource dataSource;
    private Connection connection;

    @BeforeEach
    public void setUp() throws Exception {
        // Инициализация DataSource (например, H2 in-memory)
        dataSource = createDataSource(); 
        connection = dataSource.getConnection();
        
        // Загрузка эталонных данных из XML
        IDataSet dataSet = new FlatXmlDataSetBuilder()
            .setColumnSensing(true)
            .build(new File("src/test/resources/datasets/users.xml"));
            
        DatabaseOperation.CLEAN_INSERT.execute(
            new DatabaseConnection(connection), 
            dataSet
        );
    }

    @Test
    public void testUserCreation() throws Exception {
        // Логика теста: вызов сервиса, который работает с БД
        // ...
        
        // Проверка результата
        // Можно использовать Asserts DBUnit для сравнения текущего состояния с эталоном
    }
}

Метод DatabaseOperation.CLEAN_INSERT полностью очищает таблицу перед вставкой новых данных, обеспечивая чистое состояние. Другие операции: REFRESH (обновляет существующие записи), DELETE_ALL (удаляет все, но не пересоздает таблицу), INSERT (добавляет данные без удаления старых).

DBUnit поддерживает различные стратегии управления состоянием таблицы:

CLEAN_INSERT: Удаляет все строки из таблицы, затем вставляет данные из эталонного файла. Самый надежный способ для изоляции.
REFRESH: Обновляет существующие строки новыми значениями из файла. Новые строки добавляются, старые обновляются.
DELETE_ALL: Удаляет все строки из таблицы. Не подходит для тестов, требующих первичных ключей.
INSERT: Просто вставляет данные. Может привести к конфликтам, если в таблице уже есть данные.
UPDATE_ONLY: Обновляет только те строки, которые существуют в базе.

Выбор стратегии зависит от требований теста. Для изоляции обычно выбирают CLEAN_INSERT.

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

Пример использования DefaultAssertionError или методов Assert.assertEquals:

import org.dbunit.dataset.DataSetException;
import org.dbunit.dataset.IDataSet;
import org.dbunit.dataset.xml.FlatXmlDataSetBuilder;
import org.dbunit.assertion.IAssertion;
import org.dbunit.extensions.pool.ConnectionPoolDataSource;

// После выполнения теста
IDataSet actualDataSet = getActualDataSet(connection);
IDataSet expectedDataSet = new FlatXmlDataSetBuilder().build(new File("expected.xml"));

assertDatasetEquals(expectedDataSet, actualDataSet);

Это позволяет автоматически проверить, что база данных находится в ожидаемом состоянии после выполнения теста, даже если изменения были внесены косвенно.

Хотя DBUnit работает напрямую с таблицами, его часто используют вместе с ORM-фреймворками. В этом случае тесты проверяют работу DAO-слоя или репозиториев, а не логику ORM.

Процесс подключения:

Создают соединение с базой данных, минуя Hibernate Session Factory.
Используют DBUnit для загрузки данных.
Запускают тест, который вызывает сервисы, использующие Hibernate.
Сравнивают результат с эталоном.

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

Запуск тестов выполняется через командную строку или интерфейс IDE.

В Maven команда выглядит так:

mvn test

В Gradle используется:

gradle test

При выполнении этих команд система сборки сканирует директорию src/test/java, находит классы с аннотацией @Test и запускает их. DBUnit загружает данные перед каждым тестом и очищает их после, обеспечивая полную изоляцию. Результаты отображаются в консоли в виде отчета о пройденных и упавших тестах.

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

Устанавливает зависимости (mvn install или gradle build).
Запускает тесты (mvn test или gradle test).

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

tSQLt (SQL Server)

tSQLt — фреймворк для юнит-тестирования баз данных Microsoft SQL Server. Он реализован полностью на T-SQL и позволяет писать тесты как хранимые процедуры с использованием специальных assertion-методов (tSQLt.AssertEquals, tSQLt.AssertEqualsTable и др.).

Ключевые возможности:

изоляция тестов через создание временных схем (fake tables);
мокирование таблиц и хранимых процедур;
автоматическое управление транзакциями (откат после каждого теста);
генерация отчётов о покрытии и результатах.

tSQLt интегрируется с SQL Server Data Tools (SSDT) и может запускаться из CI/CD-пайплайнов через PowerShell или SQLCMD. Он особенно ценен в enterprise-средах, где значительная часть логики реализована на уровне БД.

tSQLt — это набор объектов базы данных, а не отдельное приложение, поэтому установка происходит непосредственно внутри экземпляра Microsoft SQL Server. Процесс начинается с получения исходного кода фреймворка.

Для начала работы необходимо скачать последнюю версию библиотеки с официального репозитория на GitHub или получить её через пакетный менеджер NuGet. Файл содержит скрипт CreateFramework.sql, который создает все необходимые объекты (хранимые процедуры, таблицы, функции) в базе данных.

Процесс загрузки:

Переходят на страницу релизов проекта tSQLt на GitHub.
Скачивают архив с исходным кодом последней стабильной версии.
Распаковывают содержимое архива в локальную директорию.
Открывают файл CreateFramework.sql в инструменте управления базой данных (например, SSMS).

Рекомендуется создавать изолированную базу данных специально для размещения тестовых скриптов и объектов tSQLt, чтобы не смешивать их с продакшен-кодом.

В менеджере объектов SQL Server (Object Explorer):

Создают новую базу данных с именем, например, MyApp_Tests.
Подключаются к этой базе данных.
Выполняют команду USE MyApp_Tests; для переключения контекста.

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

Выполнение скрипта CreateFramework.sql:

Скрипт автоматически создает таблицу tSQLt.FakeTable для мокирования.
Создает хранимую процедуру tSQLt.RunTests для запуска всех тестов.
Добавляет процедуры для assertions (AssertEquals, AssertEqualsTable, Fail и другие).
Настраивает механизм автоматического отката транзакции после каждого теста.

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

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

Команда создания схемы:

CREATE SCHEMA TestSchema;

Тесты в tSQLt пишутся как обычные хранимые процедуры, но они должны находиться в созданной схеме и иметь суффикс Test в имени. Например, процедура TestSchema.Test_UserCreation.

Синтаксис тестов в tSQLt прост: процедура должна вызывать методы проверки из схемы tSQLt. Каждый тест выполняется в рамках отдельной транзакции, которая автоматически откатывается после завершения процедуры, независимо от результата.

Пример структуры теста:

CREATE PROCEDURE TestSchema.Test_AddUser
AS
BEGIN
    -- Создаем фейковую таблицу пользователей
    EXEC tSQLt.FakeTable 'Users';
    
    -- Вставляем тестовые данные
    INSERT INTO Users (Id, Name) VALUES (1, 'Ivan');
    
    -- Вызываем тестируемую логику (предположим, есть процедура AddUser)
    EXEC dbo.AddUser @Name = 'Maria';
    
    -- Проверяем результат
    DECLARE @ExpectedCount INT = 2;
    DECLARE @ActualCount INT;
    
    SELECT @ActualCount = COUNT(*) FROM Users;
    
    EXEC tSQLt.AssertEquals @ExpectedCount, @ActualCount;
END;

Метод tSQLt.FakeTable заменяет реальную таблицу на временную структуру, позволяя манипулировать данными без влияния на основную БД.

Для выполнения всех тестов в базе данных используется специальная хранимая процедура tSQLt.RunTests. Она сканирует схему с тестами, выполняет каждую процедуру и фиксирует результаты.

Базовая команда запуска:

EXEC tSQLt.RunTests;

Результатом выполнения является вывод в консоль списка пройденных и упавших тестов с указанием имен процедур и сообщений об ошибках.

Для запуска конкретного теста указывают его имя:

EXEC tSQLt.RunTests 'TestSchema.Test_AddUser';

Интеграция tSQLt в пайплайны непрерывной интеграции (GitHub Actions, Azure DevOps, Jenkins) осуществляется через выполнение скриптов T-SQL с использованием утилит командной строки.

Основные инструменты для автоматизации:

SQLCMD: Утилита командной строки, входящая в состав инструментов SQL Server. Позволяет выполнять скрипты и получать статус выполнения.
PowerShell: Сценарии могут использовать модуль SqlServer для подключения к БД и запуска процедур.

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

sqlcmd -S <ServerName> -d <DatabaseName> -Q "EXEC tSQLt.RunTests" -b

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

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

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

Одной из ключевых особенностей tSQLt является возможность создания «фейковых» версий таблиц и хранимых процедур. Это позволяет тестировать логику приложения без необходимости наличия реальных данных или внешних зависимостей.

Метод tSQLt.FakeTable создает копию структуры таблицы, но очищает её от данных и блокирует влияние на оригинал. Метод tSQLt.FakeStoredProcedure позволяет подменить поведение реальной процедуры на заглушку, возвращающую предопределенные значения.

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

Инструмент поддерживает работу с большими объемами данных и сложными транзакциями, сохраняя целостность основной базы данных благодаря механизму автоматического отката. Интеграция с SSDT (SQL Server Data Tools) позволяет управлять версиями тестов вместе с основным кодом базы данных.

SQLTest (PostgreSQL)

Хотя название «SQLTest» может ассоциироваться с универсальным инструментом, в контексте PostgreSQL чаще подразумевают использование встроенных средств тестирования или специализированных расширений. PostgreSQL не имеет официального фреймворка вроде tSQLt, но для тестирования баз данных применяются следующие подходы:

pgTAP — фреймворк на основе TAP (Test Anything Protocol), позволяющий писать тесты на PL/pgSQL с использованием функций вроде ok(), is(), results_eq();
pytest + psycopg2 — для интеграции с Python-инфраструктурой: тесты управляют транзакциями, загружают фикстуры и проверяют состояние БД через SQL-запросы;
custom scripts — запуск SQL-скриптов с последующей валидацией через diff или hash-сравнение.

Важно отметить: в отличие от SQL Server или Oracle, в экосистеме PostgreSQL доминирует подход «логика в приложении», поэтому тестирование БД часто сводится к проверке миграций, индексов и производительности запросов, а не к юнит-тестированию хранимых процедур.

Тем не менее, если бизнес-логика частично или полностью реализована в PostgreSQL (например, через триггеры или функции на PL/pgSQL), применение pgTAP или интеграция с PyTest становится оправданным.

pgTAP — это расширение для PostgreSQL, реализующее протокол TAP (Test Anything Protocol). Оно позволяет писать юнит-тесты непосредственно внутри СУБД на языке PL/pgSQL. В отличие от SQL Server или Oracle, где тестирование часто является встроенной функцией, здесь требуется явная установка расширения.

Процесс установки выполняется через утилиту psql или графический интерфейс управления базами данных (например, DBeaver, pgAdmin).

Команда подключения к базе данных и активации расширения:

CREATE EXTENSION IF NOT EXISTS pgtap;

Эта команда создает в текущей базе данных схему public (или специальную схему, если она указана) с набором функций для проверки результатов (ok, is, results_eq, plan, diag и др.). После выполнения все функции становятся доступны для вызова в любых хранимых процедурах и скриптах.

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

Если бизнес-логика распределена между приложением и базой данных, предпочтительным подходом является использование Python-инструментов. Это позволяет объединить тестирование кода приложения и проверку состояния БД в едином пайплайне.

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

pip install pytest psycopg2-binary pytest-postgresql

Пакет pytest-postgresql предоставляет фикстуры для автоматического запуска временного экземпляра PostgreSQL в процессе тестирования, что обеспечивает полную изоляцию и воспроизводимость.

Тесты для PostgreSQL могут размещаться в двух разных местах в зависимости от выбранного подхода.

Для pgTAP: Файлы с тестами (расширение .sql) размещают в директории проекта, обычно в папке tests или sql_tests. Внутри файла пишутся функции на PL/pgSQL, которые вызывают функции из расширения pgTAP.
- Пример структуры: src/db/tests/test_user_functions.sql.
Для PyTest: Тесты размещаются в стандартной директории tests (или test_*.py). Здесь создаются классы или функции, которые используют библиотеку psycopg2 для подключения к БД и выполняют SQL-запросы.

Типичная структура для Python-подхода:

project_root/
├── src/
│   └── app.py
├── tests/
│   ├── conftest.py          # Настройка фикстур (база данных, транзакции)
│   ├── test_db_schema.py    # Проверка миграций и индексов
│   └── test_business_logic.py # Проверка логики через SQL
├── requirements.txt
└── pytest.ini

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

Пример теста на PL/pgSQL для проверки функции получения пользователя:

CREATE OR REPLACE FUNCTION test_get_user_by_id() RETURNS void AS $$
BEGIN
  -- Устанавливаем план тестов (ожидаемое количество проверок)
  SELECT plan(2);

  -- Вызываем тестируемую функцию
  PERFORM get_user_by_id(1);

  -- Проверяем результат
  SELECT is(get_user_by_id(1), 'Ivan', 'User Ivan found');
  SELECT results_eq('SELECT name FROM users WHERE id = 1', ARRAY['Ivan'], 'Name matches expected value');

  -- Завершаем тест
  SELECT done();
END;
$$ LANGUAGE plpgsql;

Запуск такого теста выполняется командой SELECT test_get_user_by_id();. Результат выводится в формате TAP, который легко парсится CI-системами.

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

Пример файла tests/conftest.py:

import pytest
import psycopg2

@pytest.fixture(scope="function")
def db_connection():
    conn = psycopg2.connect("dbname=test user=postgres password=secret")
    yield conn
    conn.close()

@pytest.fixture(scope="function")
def transaction(db_connection):
    cursor = db_connection.cursor()
    cursor.execute("BEGIN")
    yield cursor
    cursor.execute("ROLLBACK")
    cursor.close()

Пример теста tests/test_db.py:

def test_user_creation(transaction):
    # Загрузка тестовых данных
    transaction.execute("INSERT INTO users (id, name) VALUES (1, 'Maria')")
    
    # Проверка наличия записи
    transaction.execute("SELECT name FROM users WHERE id = 1")
    result = transaction.fetchone()[0]
    
    assert result == 'Maria', "Имя пользователя должно совпадать"

Подключение инструментов к пайплайнам зависит от выбранного метода.

Для pgTAP:

В пайплайне (GitHub Actions, GitLab CI) создается этап, который запускает базу данных PostgreSQL.
Выполняется команда psql -d mydb -f tests/test_script.sql.
Вывод консоли анализируется на наличие строк ok (успех) или not ok (ошибка). Если хотя бы один тест не пройден, сборка помечается как неудачная.

Для PyTest:

Используется стандартная команда запуска:
```
pytest tests/
```
Плагин pytest-postgresql автоматически поднимает изолированную базу данных, выполняет тесты и уничтожает её после завершения. Это не требует ручной настройки сервера в среде CI.
Результаты выводятся в терминале с цветовой индикацией (зеленый — успех, красный — ошибка).

В экосистеме PostgreSQL, где логика часто находится в коде приложения, основное внимание уделяется проверке целостности схемы.

Миграции: Тесты проверяют, что скрипты миграции выполняются без ошибок и создают ожидаемые объекты (таблицы, индексы, ограничения).
Индексы: С помощью EXPLAIN ANALYZE в тестах проверяется, что запросы используют правильные индексы и время выполнения укладывается в лимиты.
Производительность: Сравнение хеш-сумм результатов запросов до и после изменений позволяет выявить регрессию в скорости работы.

Для сложных сценариев, когда нужно проверить структуру ответа или содержимое таблицы, используются скрипты на Bash или Python. Они выполняют SQL-запрос, сохраняют результат в файл, сравнивают его с эталонным файлом через утилиты diff или вычисляют контрольные суммы (hash).

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

Выполнение запроса: psql -c "SELECT * FROM orders" > actual_output.txt.
Сравнение: diff expected_output.txt actual_output.txt.
Возврат кода ошибки, если файлы различаются.

Такой подход прост в реализации и эффективен для проверки стабильности отчетов и данных.

Ключевым преимуществом обоих подходов является автоматическое управление транзакциями. При использовании pgTAP каждая проверка может выполняться в отдельной транзакции или в рамках одной большой, которая откатывается вручную. В pytest используется механизм yield для фиксации начала транзакции перед тестом и отката (ROLLBACK) после него.

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

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

Если же логика преимущественно находится в приложении (Java, C#, Python), а база данных выступает лишь как хранилище, интеграция с pytest дает больше гибкости. Она позволяет тестировать взаимодействие слоя доступа к данным (DAO) и проверять корректность миграций в контексте всего приложения.

Тестирование производительности

Тестирование производительности (performance testing) — это комплексный процесс оценки скорости, стабильности, масштабируемости и эффективности использования ресурсов программной системой под заданной нагрузкой. В отличие от нагрузочного тестирования, которое фокусируется на поведении при увеличении объёма запросов, performance testing охватывает более широкий спектр сценариев:

benchmarking — сравнение производительности до и после изменений;
профилирование — выявление узких мест (bottlenecks) в коде или инфраструктуре;
тестирование времени отклика — соответствие SLA;
тестирование масштабируемости — как система реагирует на добавление ресурсов;
тестирование стабильности при длительной нагрузке (soak testing).

Производительностное тестирование требует генерации нагрузки, мониторинга (APM-инструменты, метрики ОС, логи) и анализа (профилировщики, flame graphs, tracing). Ниже рассматриваются инструменты, которые позволяют как генерировать нагрузку, так и частично обеспечивать анализ результатов.

JMeter

Как уже отмечалось в разделе «Нагрузочное и стресс-тестирование», Apache JMeter активно используется и для performance testing. Его гибкость позволяет:

моделировать реалистичные пользовательские сценарии с паузами, логинами, кэшированием;
собирать метрики времени отклика, пропускной способности и ошибок;
использовать Listener’ы (например, Aggregate Report, Response Times Graph) для первичного анализа.

Однако для глубокого профилирования JMeter требует интеграции с внешними системами мониторинга (Prometheus, Grafana, Datadog).

Gatling

Gatling, благодаря своей архитектуре на основе Akka и асинхронной модели, обеспечивает высокую точность измерений времени отклика даже при интенсивной нагрузке. Его встроенные отчёты включают:

графики распределения времени отклика;
перцентили (95-й, 99-й);
динамику ошибок во времени;
детализацию по каждому шагу сценария.

Это делает Gatling не просто генератором нагрузки, но и инструментом для анализа производительности. Поддержка threshold’ов позволяет автоматически фиксировать регрессии в пайплайнах.

k6

k6 особенно силён в контексте continuous performance testing. Он позволяет задавать целевые метрики (например, «95-й перцентиль < 500 мс») прямо в коде теста:

export const options = {
  thresholds: {
    'http_req_duration': ['p(95) < 500'],
    'http_req_failed': ['rate < 0.01']
  }
};

При превышении порога тест завершается с ненулевым кодом возврата, что прерывает CI/CD-пайплайн. Такой подход интегрирует performance testing в культуру «shift-left» и позволяет выявлять регрессии на ранних этапах.

k6 также поддерживает экспорт метрик в Prometheus, InfluxDB и другие системы, что упрощает корреляцию с данными APM.

LoadRunner (Enterprise-решение)

LoadRunner от OpenText (ранее Micro Focus, HP) — это промышленное enterprise-решение для комплексного performance testing. Он поддерживает сотни протоколов (HTTP/HTTPS, SAP, Oracle E-Business, Citrix, WebSockets и др.) и позволяет:

записывать сценарии через Vuser-скрипты (на C или JavaScript);
моделировать десятки тысяч виртуальных пользователей;
интегрироваться с мониторингом серверов (SiteScope);
генерировать детальные аналитические отчёты с возможностью drill-down.

LoadRunner особенно востребован в крупных организациях с унаследованными системами, где требуется поддержка специфических корпоративных протоколов и соответствие строгим регуляторным требованиям. Однако его стоимость, сложность настройки и зависимость от Windows-инфраструктуры делают его менее привлекательным для современных cloud-native проектов.

BDD (Behavior-Driven Development)

Behavior-Driven Development (BDD) — это методология разработки программного обеспечения, ориентированная на совместное формулирование требований в виде выполнимых спецификаций, понятных как техническим, так и нетехническим участникам проекта. BDD расширяет идеи Test-Driven Development (TDD), перенося фокус с «тестов» на «поведение системы» и используя язык, близкий к естественному (Ubiquitous Language по Эрику Эвансу).

Основной элемент BDD — сценарий, описываемый в формате Gherkin:

Функция: Авторизация пользователя

  Сценарий: Успешный вход с корректными учетными данными
    Допустим пользователь находится на странице входа
    Когда он вводит логин "user@example.com" и пароль "secret"
    И нажимает кнопку "Войти"
    Тогда он должен быть перенаправлен на главную страницу

Такой сценарий не является просто документацией — он выполняется как автоматизированный тест. Для этого каждая строка (шаг) связывается с реализацией на языке программирования (step definition). Это обеспечивает двойную пользу: живая документация + автоматизированная проверка.

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

Cucumber

Cucumber — это оригинальная и наиболее распространённая реализация BDD, изначально написанная на Ruby, но впоследствии портированная на множество языков (Java, JavaScript, C#, Python и др.). Cucumber парсит .feature-файлы в формате Gherkin и сопоставляет шаги с аннотированными методами в коде.

Пример шага на Java:

@When("он вводит логин {string} и пароль {string}")
public void enterCredentials(String email, String password) {
    loginPage.enterEmail(email);
    loginPage.enterPassword(password);
}

Cucumber поддерживает:

теги для фильтрации сценариев;
параметризацию через таблицы и примеры (Scenario Outline);
генерацию HTML-отчётов с подсветкой пройденных/упавших шагов.

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

Behave (Python)

Behave — это Python-реализация BDD, полностью совместимая с синтаксисом Gherkin. Шаги определяются с помощью декораторов:

@when('он вводит логин "{email}" и пароль "{password}"')
def step_impl(context, email, password):
    context.login_page.enter_credentials(email, password)

Behave интегрируется с PyTest и unittest, поддерживает фикстуры через environment.py и генерирует отчёты в различных форматах (JSON, HTML). Он популярен в Python-сообществе, особенно в проектах с участием нетехнических стейкхолдеров.

SpecFlow (.NET)

SpecFlow — это официальный BDD-фреймворк для экосистемы .NET. Он интегрируется с Visual Studio и генерирует C#-код из .feature-файлов во время сборки. Шаги реализуются как методы с атрибутами [Given], [When], [Then].

SpecFlow тесно взаимодействует с NUnit, xUnit и MSTest, поддерживает внедрение зависимостей (через контекст), работу с таблицами и параметризацию. Он активно используется в enterprise-средах Microsoft, где требуется соответствие регуляторным стандартам и живая документация.

Тестирование в облаках и CI/CD

Современные практики разработки программного обеспечения предполагают непрерывную интеграцию (CI) и непрерывную доставку (CD), что требует автоматизации всех этапов тестирования и их встраивания в пайплайны сборки и развёртывания. Однако выполнение тестов, особенно UI- и E2E-сценариев, локально на машине разработчика или даже на CI-сервере, сталкивается с ограничениями:

отсутствие необходимых браузеров или версий ОС;
нехватка ресурсов для параллельного запуска;
сложность настройки мобильных эмуляторов или реальных устройств.

Для преодоления этих проблем появились облачные платформы для тестирования, предоставляющие виртуальные или реальные устройства, браузеры и инфраструктуру по требованию. Кроме того, сами CI/CD-системы эволюционировали в полноценные среды оркестрации тестов.

Sauce Labs

Sauce Labs — одна из первых и наиболее зрелых облачных платформ для кросс-браузерного и мобильного тестирования. Она предоставляет доступ к тысячам комбинаций:

браузеров (Chrome, Firefox, Safari, Edge) и их версий;
операционных систем (Windows, macOS, Linux, iOS, Android);
реальных мобильных устройств и эмуляторов.

Sauce Labs поддерживает Selenium, Appium, Playwright и Cypress. Тесты запускаются в облаке через стандартные WebDriver-команды, но с указанием желаемой конфигурации в capabilities. Платформа сохраняет:

видео запись сессии;
логи браузера и консоли;
скриншоты на каждом шаге;
метрики производительности.

Интеграция с Jenkins, GitHub Actions, GitLab CI осуществляется через API и официальные плагины. Sauce Labs особенно востребован в enterprise-средах, где критична поддержка устаревших браузеров и соответствие стандартам аудита.

BrowserStack

BrowserStack — конкурент Sauce Labs с аналогичной моделью предоставления «браузеров как сервиса». Его особенность — Live Testing: возможность вручную взаимодействовать с реальным устройством или браузером через веб-интерфейс. Это полезно для отладки или быстрой проверки бага.

BrowserStack также предлагает:

автоматизированное тестирование через Selenium/Appium;
интеграцию с локальной сетью через Local Testing (туннель);
поддержку параллельного выполнения до сотен сессий.

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

LambdaTest

LambdaTest — облачная платформа, позиционирующаяся как более экономичная альтернатива Sauce Labs и BrowserStack. Она поддерживает:

более 3000 комбинаций браузеров и ОС;
автоматизацию через Selenium, Cypress, Playwright;
тестирование на реальных мобильных устройствах;
инструменты для визуального тестирования и сравнения скриншотов.

LambdaTest особенно популярен в регионах с ограниченным доступом к другим платформам и среди команд с ограниченным бюджетом.

GitHub Actions / GitLab CI / Jenkins

Интеграция тестов в CI/CD-пайплайны — неотъемлемая часть современного процесса разработки. Каждая из систем предлагает свои механизмы:

GitHub Actions: тесты описываются в YAML-файлах в директории .github/workflows/. Поддерживается запуск контейнеров с браузерами (например, через selenium/standalone-chrome), кэширование зависимостей, параллелизм. Для Playwright и Cypress существуют официальные действия.
GitLab CI: использует .gitlab-ci.yml и runner’ы (Docker, Kubernetes, shell). GitLab предоставляет Auto DevOps, включающий базовые тесты, а также инструменты для мониторинга покрытия и отчётов через Merge Request Widgets.
Jenkins: благодаря плагинной архитектуре (Selenium Plugin, Pipeline, Blue Ocean) остаётся гибким решением для сложных enterprise-пайплайнов. Поддерживает распределённые ноды, параметризованные сборки и интеграцию с любыми облачными платформами через REST API.

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