В рамках брейнштормов по поиску если не правильного, то оптимального решения, команды генерируют идеальные сценарии. А что если развернуть угол и рассмотреть тот или иной процесс или кейс с противоположной, плохой точки зрения, - как не нужно делать или сделать хуже? В этом посте переворачиваю с ног на голову нагрузочное тестирование и даю 7 вредных советов 👿:
#1. Забудьте про цель тестирования
Зачем тратить драгоценное время на понимание цели тестирования, на определение эндпоинтов, которые необходимо проверить. Давайте начнем, а там как пойдет, по ходу дела разберемся.
Реальность: отсутствие цели значительно увеличивает время проведения теста и приводит к нерелевантным результатам, которым нельзя доверять.
#2. Используйте одинаковые данные
Не надо заморачиваться на подготовку разнообразных данных. Это утомительно и занимает много времени. Можно просто взять самый простой набор данных и сразу начать тестировать.
Реальность: одинаковые данные не отражают реального поведения пользователей, поэтому чем больше данные похожи на прод, тем более релевантными будут результаты теста.
#3. Игнорируйте мониторинг системы
Не утруждайте себя настройкой логов и алертов приложений и серверов перед тестированием. Достаточно просто запустить тесты и посмотреть на общий результат в конце.
Реальность: мониторинг дает понять, как ведет себя система под нагрузкой, в том числе дает информацию об узких местах, требующих внимания. Без этой информации ценность теста значительно снижается.
#4. Проводите тесты только один раз
Не стоит заморачиваться на регулярные проверки: достаточно провести тесты перед стартом работы системы, а потом все будет нормально.
Реальность: регулярные тесты необходимы для выявления проблем и узких мест в постоянно меняющихся приложениях и инфраструктуре. Однократное тестирование не гарантирует работоспособность системы в будущем.
#5. Не надо беспокоиться о реалистичности сценариев
Сценарии тестирования можно придумать на ходу. Реалистичность не важна, главное запустить и посмотреть результаты и красивые графики.
Реальность: нереалистичные сценарии не позволяют получить адекватную и релевантную информацию о производительности системы. Для получения объективной картины необходимо учитывать реальные условия использования системы и поведение пользователей.
#6. Документирование результатов не для нас
Результаты тестирования? Какие-то странички в корпоративной вики? Кому они нужны? Просто запомните все результаты, а лучше не все: просто посмотрите на графики, остальное можно опустить.
Реальность: без надлежащей документации результаты могут быть потеряны или неправильно интерпретированы. Документация помогает оценивать результаты и принимать корректные решения.
#7. Запускайте тесты, когда захотите
Запускайте нагрузочные тесты только в то время, когда удобно лично вам. И не надо никого уведомлять. В конце концов, вы получите более честные "результаты", ведь никто не будет готовиться.
Реальность: запуск тестов без планирования и уведомления своей команды и команд связанных систем может привести к непредсказуемым сбоям и потерям данных. Команды разработки и оперирования должны быть готовы к тестам, чтобы максимально быстро реагировать на возникающие проблемы.
Вывод
Следуя этим "вредным" советам, вы можете значительно снизить качество и эффективность вашего нагрузочного тестирования. На самом деле, важно использовать современные инструменты, планировать и документировать тесты, учитывать реальные сценарии использования и прислушиваться к отзывам команды.
#1. Забудьте про цель тестирования
Зачем тратить драгоценное время на понимание цели тестирования, на определение эндпоинтов, которые необходимо проверить. Давайте начнем, а там как пойдет, по ходу дела разберемся.
Реальность: отсутствие цели значительно увеличивает время проведения теста и приводит к нерелевантным результатам, которым нельзя доверять.
#2. Используйте одинаковые данные
Не надо заморачиваться на подготовку разнообразных данных. Это утомительно и занимает много времени. Можно просто взять самый простой набор данных и сразу начать тестировать.
Реальность: одинаковые данные не отражают реального поведения пользователей, поэтому чем больше данные похожи на прод, тем более релевантными будут результаты теста.
#3. Игнорируйте мониторинг системы
Не утруждайте себя настройкой логов и алертов приложений и серверов перед тестированием. Достаточно просто запустить тесты и посмотреть на общий результат в конце.
Реальность: мониторинг дает понять, как ведет себя система под нагрузкой, в том числе дает информацию об узких местах, требующих внимания. Без этой информации ценность теста значительно снижается.
#4. Проводите тесты только один раз
Не стоит заморачиваться на регулярные проверки: достаточно провести тесты перед стартом работы системы, а потом все будет нормально.
Реальность: регулярные тесты необходимы для выявления проблем и узких мест в постоянно меняющихся приложениях и инфраструктуре. Однократное тестирование не гарантирует работоспособность системы в будущем.
#5. Не надо беспокоиться о реалистичности сценариев
Сценарии тестирования можно придумать на ходу. Реалистичность не важна, главное запустить и посмотреть результаты и красивые графики.
Реальность: нереалистичные сценарии не позволяют получить адекватную и релевантную информацию о производительности системы. Для получения объективной картины необходимо учитывать реальные условия использования системы и поведение пользователей.
#6. Документирование результатов не для нас
Результаты тестирования? Какие-то странички в корпоративной вики? Кому они нужны? Просто запомните все результаты, а лучше не все: просто посмотрите на графики, остальное можно опустить.
Реальность: без надлежащей документации результаты могут быть потеряны или неправильно интерпретированы. Документация помогает оценивать результаты и принимать корректные решения.
#7. Запускайте тесты, когда захотите
Запускайте нагрузочные тесты только в то время, когда удобно лично вам. И не надо никого уведомлять. В конце концов, вы получите более честные "результаты", ведь никто не будет готовиться.
Реальность: запуск тестов без планирования и уведомления своей команды и команд связанных систем может привести к непредсказуемым сбоям и потерям данных. Команды разработки и оперирования должны быть готовы к тестам, чтобы максимально быстро реагировать на возникающие проблемы.
Вывод
Следуя этим "вредным" советам, вы можете значительно снизить качество и эффективность вашего нагрузочного тестирования. На самом деле, важно использовать современные инструменты, планировать и документировать тесты, учитывать реальные сценарии использования и прислушиваться к отзывам команды.
