#performance #testing
#Производительность #тестирование
Вопрос:
Я провожу тестирование производительности нашего сайта. Сайт предоставляет множество API-интерфейсов веб-сервисов. Наш продукт имеет несколько рабочих процессов, и каждый полный рабочий процесс состоит из вызова более чем одного API.
Мне интересно, какой из следующих подходов является разумным:
-
Тестирование каждого отдельного API автономным способом.
-
Тестируйте каждый полный рабочий процесс, который включает несколько API.
Я думаю, что последнее имеет больше смысла, поскольку оно имитирует реальный сценарий. Я хотел бы услышать ваши комментарии.
Спасибо.
Ответ №1:
Есть (как обычно) плюсы и минусы каждого подхода. Лично я бы подумал о том, чтобы выполнить оба, начиная с одного теста API.
Единый API, вероятно, самый простой в создании, и его преимущество заключается в точном определении ваших проблем с производительностью. Также полезно выявлять регрессии производительности во время разработки. Если для приложения существуют модульные тесты, рассмотрите возможность их использования. Когда происходит регресс производительности, обычно также выполняется модульный тест, который внезапно стал медленнее.
После того, как вы это сделаете, вам все равно нужно будет выполнить более сложные тесты. Во-первых, потому что вам нужно знать, приемлема ли производительность определенного потока, а также потому, что между различными API могут возникнуть неожиданные взаимодействия. В зависимости от вашего приложения могут возникнуть неприятные проблемы с параллелизмом, узкие места пропускной способности и т. Д. Убедитесь, что вы запускаете несколько потоков одновременно, это то, что происходит в режиме реального времени, и это единственный способ найти проблемы, связанные с блокировкой в базе данных, узкими местами ввода-вывода и т. Д.
Но прежде чем начать, убедитесь, что у вас есть реалистичное представление о том, какой должна быть производительность, сколько одновременных пользователей будет и каковы требования к оборудованию. Нет предела повышению производительности, поэтому вы должны решить, что достаточно хорошо, или вы никогда не прекратите оптимизацию.