Какие архитектурные требования к сервису вы знаете и как их проверяете?

«Какие архитектурные требования к сервису вы знаете и как их проверяете?» — вопрос из категории Архитектура, который задают на 24% собеседований AQA / Automation. Ниже — развёрнутый ответ с разбором ключевых моментов.

Ответ

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

  1. Масштабируемость: Сервис должен выдерживать рост нагрузки. На практике я проверяю это:

    • Нагрузочным тестированием (например, с помощью JMeter или k6), оценивая, как растёт время отклика и потребление ресурсов при увеличении числа пользователей.
    • Проверяю, поддерживает ли сервис горизонтальное масштабирование (запуск нескольких инстансов).
  2. Отказоустойчивость: Система должна корректно обрабатывать сбои. Мои проверки включают:

    • Тесты на устойчивость (Chaos Engineering): Имитация отказов зависимостей (база данных, внешний API) с помощью инструментов вроде WireMock для моков или Pumba для контейнеров. Смотрю, есть ли у сервиса механизмы повторных попыток (retry), circuit breaker и graceful degradation.
    • Проверка, что частичный отказ не приводит к полной недоступности сервиса.
  3. Производительность:

    • Измерение времени отклика (p95, p99) и пропускной способности (RPS) в рамках нагрузочного тестирования.
    • Профилирование и поиск узких мест (bottlenecks) с помощью APM-инструментов (Datadog, New Relic).
  4. Безопасность:

    • Проверка валидации и санитизации всех входящих данных (тесты на SQL-инъекции, XSS).
    • Верификация корректной работы аутентификации и авторизации (например, что пользователь не может получить доступ к чужим данным через подмену ID в запросе).
  5. Надёжность API (для REST):

    • Следование принципам REST (корректное использование HTTP-методов, кодов состояния).
    • Проверка поддержки кэширования (заголовки Cache-Control, ETag).
    • Тестирование идемпотентности критичных операций (например, PUT или DELETE).

Пример проверки статуса и времени отклика в интеграционном тесте:

@Test
public void api_should_respond_within_sla() {
    long startTime = System.currentTimeMillis();
    Response response = given()
                            .when()
                            .get("/api/v1/health");
    long responseTime = System.currentTimeMillis() - startTime;

    assertThat(response.statusCode()).isEqualTo(200);
    assertThat(responseTime).isLessThan(500); // Проверка SLA в 500 мс
}

Эти проверки я закладываю в pipeline как этап non-functional testing.