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

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

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

Друзья, поддержите нас вступлением в наш телеграм канал QaRocks. Там много туториалов, задач по автоматизации и книг по QA.

Что такое стресс-тестирование?

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

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

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

Обычно стресс-тестирование API или веб-сайта необходимо для того, чтобы определить:

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

При проведении стресс-тестирования настройте тест так, чтобы количество одновременных пользователей или объем обрабатываемого трафика были выше, чем:

• Обычно наблюдается в приложении.
• Вы считаете, что приложение способно обработать.

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

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

Классическими примерами необходимости стресс-тестирования являются “Черная пятница” (Black Friday) и “Киберпонедельник” (Сyber Monday) – два дня в году, когда многие веб-сайты получают многократно больше трафика, чем обычно.

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

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

С учетом сказанного, вы, вероятно, не захотите проводить этот тест в продакшене. Мы рекомендуем проводить стресс-тест в UAT (User acceptance testing) или в стейджинге.

API стресс-тест в k6

Вы можете создать стресс-тест в k6(инструмент нагрузочного тестирования, который делает тестирование производительности простым для инженерных команд), правильно настроив объект параметров (options). Для стресс-тестов подходящим исполнителем (executor) является ramping-arrival-rate, так как вы можете установить необработанную пропускную способность как значение в итерациях в секунду.

Помните, что цель этого теста заключается в том, чтобы постепенно вывести ваш API из работы, например:

import http from "k6/http";
import { sleep } from "k6";

export const options = {
  scenarios: {
    stress: {
      executor: "ramping-arrival-rate",
      preAllocatedVUs: 500,
      timeUnit: "1s",
      stages: [
        { duration: "2m", target: 10 }, // below normal load
        { duration: "5m", target: 10 },
        { duration: "2m", target: 20 }, // normal load
        { duration: "5m", target: 20 },
        { duration: "2m", target: 30 }, // around the breaking point
        { duration: "5m", target: 30 },
        { duration: "2m", target: 40 }, // beyond the breaking point
        { duration: "5m", target: 40 },
        { duration: "10m", target: 0 }, // scale down. Recovery stage.
      ],
    },
  },
};

export default function () {
  const BASE_URL = "https://test-api.k6.io"; // make sure this is not production
  const responses = http.batch([
    ["GET", `${BASE_URL}/public/crocodiles/1/`],
    ["GET", `${BASE_URL}/public/crocodiles/2/`],
    ["GET", `${BASE_URL}/public/crocodiles/3/`],
    ["GET", `${BASE_URL}/public/crocodiles/4/`],
  ]);
}

График VU стресс-теста должен выглядеть примерно так:

В этой конфигурации нагрузка увеличивается на 100 пользователей каждые 2 минуты и остается на этом уровне в течение 5 минут. Мы также включили этап восстановления в конце, где система постепенно снижает нагрузку до 0.

Если ваша инфраструктура настроена на автомасштабирование, этот тест поможет вам определить:

• Насколько быстро механизмы автомасштабирования реагируют на увеличение нагрузки.
• Происходят ли сбои во время событий масштабирования.

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

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

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

Spike-тестирование – это разновидность стресс-тестирования, но в нем нагрузка не увеличивается постепенно. Вместо этого оно мгновенно создает экстремальную нагрузку в течение очень короткого времени. В то время как стресс-тест позволяет SUT (System Under Test) постепенно масштабировать свою инфраструктуру, тестирование нагрузки этого не позволяет.

Выполнение spike-тестирования позволяет определить:

• Как будет работать ваша система при внезапном всплеске трафика.
• Восстановится ли ваша система после того, как трафик спадет.

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

Другой типичный пример – “объятия смерти HackerNews”: кто-то ссылается на ваш сайт на одном из популярных интернет-форумов, таких как Reddit или HackerNews, что приводит тысячи людей в вашу систему одновременно.

Успех или неудача spike-тестирования зависит от ваших ожиданий. Обычно системы реагируют 4 различными способами:

• Отлично: Производительность системы стабильна во время всплеска трафика. Время отклика одинаково при низком и высоком трафике.
• Хорошо: Время отклика меньше, но система не выдает никаких ошибок. Все запросы обрабатываются.
• Плохо: Система выдает ошибки во время всплеска трафика, но восстанавливается до нормального уровня после того, как трафик спадает.
• Плохо: Система падает и не восстанавливается после спада трафика.

API spike test в k6

Вот пример конфигурации скрипта для spike-тестирования. Как и при стресс-тестировании, ramping-arrival-rate является хорошим исполнителем для spike-тестирования.

import http from "k6/http";
import { sleep } from "k6";

export const options = {
  scenarios: {
    spike: {
      executor: "ramping-arrival-rate",
      preAllocatedVUs: 1000,
      timeUnit: "1s",
      stages: [
        { duration: "10s", target: 10 }, // below normal load
        { duration: "1m", target: 10 },
        { duration: "10s", target: 140 }, // spike to 140 iterations
        { duration: "3m", target: 140 }, // stay at 140 for 3 minutes
        { duration: "10s", target: 10 }, // scale down. Recovery stage.
        { duration: "3m", target: 10 },
        { duration: "10s", target: 0 },
      ],
      gracefulStop: "2m",
    },
  },
};

export default function () {
  const BASE_URL = "https://test-api.k6.io"; // make sure this is not production

  const responses = http.batch([
    [
      "GET",
      `${BASE_URL}/public/crocodiles/1/`,
      null,
      { tags: { name: "PublicCrocs" } },
    ],
    [
      "GET",
      `${BASE_URL}/public/crocodiles/2/`,
      null,
      { tags: { name: "PublicCrocs" } },
    ],
    [
      "GET",
      `${BASE_URL}/public/crocodiles/3/`,
      null,
      { tags: { name: "PublicCrocs" } },
    ],
    [
      "GET",
      `${BASE_URL}/public/crocodiles/4/`,
      null,
      { tags: { name: "PublicCrocs" } },
    ],
  ]);
}

График VU spike-тестирования должен выглядеть примерно так:

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

Помните, что смысл этого теста заключается в том, чтобы внезапно перегрузить систему. Не бойтесь увеличивать количество виртуальных пользователей (VUs) сверх ожидаемого наихудшего случая. В зависимости от ваших потребностей, вы можете продлить этап восстановления до 10 или более минут, чтобы увидеть, когда система окончательно восстановится.

Заключение

Стресс-тестирование и spike-тестирование помогают подготовиться к экстремальным условиям, с которыми ваша система неизбежно столкнется в продакшене.

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

После того, как ваша система станет устойчивой к стрессу, вам может понадобиться soak test, чтобы проверить, не появятся ли другие проблемы с надежностью в течение длительного периода времени.

Перевод статьи «Stress testing».