Начнем с упомянутого тестирования производительности.
Задача теста — найти самые «узкие» места системы или архитектуры. Для этого мы на пределе загружаем систему и считаем время выполнения операций, тестируем нагрузку на канал и на жесткие диски, когда запись действий идет в базу данных.
На практике вы просто эмулируете работу пользователя.
При тестировании производительности мы определяем:
- количество пользователей одновременно работающих с приложением,
- границы приемлемой производительности при увеличении нагрузки,
- исследуем производительность на высоких, предельных, стрессовых нагрузках.
Стрессовое тестирование.
Здесь мы оцениваем способность системы к регенерации и возвращению к нормальному состоянию. Сколько по времени приложение будет «лежать», и как быстро восстановится, насколько оперативно переключится между серверами для продолжения работы. По сути, мы ищем максимальную точку деградации, где начинаются ошибки и отказы и анализируем, как ведет себя система.
Объемное тестирование.
Используется редко, что делается зря, так как этот вид тестирования позволяет узнать, что будет с системой при увеличении потока пользователей. При объемном тестировании мы проверяем:
- как работает система, когда объем базы данных увеличится,
- измеряем время выполнения операций при увеличении числа пользователей,
- определяем количество клиентов, которые могут одновременно работать в приложении или в системе.
Для подобного теста хорошим решением будет использовать Kubernetes. Он поднимает такие системы при возрастающем объеме, фиксит, что время ожидания увеличилось и запускает второй-третий-четвертый сервер, чтобы распределить нагрузку.
Тестирование стабильности (надежности).
Долгий и муторный тест на утечки памяти: прогоняем весь сервер целиком, смотрим, насколько стабильно ведет себя система при многочасовом использовании.
Бывает так, что на сайте в режиме отладки включено «Логирование всего». То есть мы записываем все действия пользователя, и сервер очень быстро забивается. В этом случае к нему практически нельзя подключиться.
Метрики
Время ожидания отклика — интервал между запросом и ответом сервера. Логично, что чем он меньше, тем лучше для пользователя. Золотой серединой принято считать промежуток времени в 100 миллисекунд. Если отклик больше — то «все плохо» или вы портал «Госуслуг», а если меньше - то большой молодец.
Пропускная способность — количество пользователей или запросов, которым одновременно отвечает система. Здесь же смотрим, как быстро работают сервисы между собой для передачи отклика. Измеряем в количестве запросов в секунду.
Ширина канала — замеряем в целом максимальный объем запросов и пользователей, который может обработать система. Например, тысячи китайцев, которые вводят логин и пароль :)
Перцентили — замеряем среднее время ожидания. Корректно оценивать работу сервера для 90 или 99 процентов пользователей. Остальные, к сожалению, будут страдать.
Частота ошибок.
Метрика показывает, что в системе что-то не так: мы отлавливаем те самые 400-сотые ошибки, ищем логи самого приложения. Смотрим, какой процент наших ответов на запросы успешен, и как он возрастает в зависимости от количества запросов.
Напоследок расскажем забавную историю о юных QA-инженерах, применяющих нагрузочное тестирование — школьниках из Казани, которые написали свою систему для теста. В тот момент, когда родителям раз в месяц отправляли данные с оценками учеников, сайт школы «падал». Ребята просто «роняли» портал своими Ddos-атаками, а их программа генерировала кучу запросов на сервер. Лучше, как говорится, уронить систему, а не лицо.
Только помните, что первое преследуется по закону, если сделано не в рамках работы на вашем проекте.