В статье и статье описаны моменты, на которые стоит обращать внимание при подготовке к выполнению теста с высокой нагрузкой на Web-систему с Web-интерфейсом.
Предлагаю рассмотреть завершающие, по моему мнению, этапы подготовки к нагрузочному тестированию.
Разбивать тестовый сценарий
Когда планируешь тестирование системы, то составляется подробный план выполняемых действий. Подготовив последовательность шагов, то стоит еще раз на них посмотреть и разбить один большой сценарий на более мелкие.
Возьмем какой-нибудь личный кабинет банковского сектора. Мы проверяем как работает личный кабинет при нагрузочном тестировании. У нас есть определенные шаги:
- Открыть главную страницу.
- Перейти на страницу личного кабинета.
- Войти в систему.
- Проверить состояние своих счетов.
- Оплатить какую-либо услугу.
- Выполнить перевод на какую-либо карту.
- Выполнить выход из системы.
Первое что приходит нам в голову — это записать эти семь простых шагов в одном сценарии и выполнять его. Но мы можем разбить эту последовательность на 7 более простых наборов. В результате мы получим достаточно большое количество комбинаций множества тестов.
Примерный состав тестов из 7 разных наборов.
Мы можем наглядно видеть, как использование нескольких наборов позволяет нам создать несколько тестов, которые могут помочь нам выполнить нагрузочное тестирование нашего функционала в различных комбинациях и наиболее полным образом.
Такой уровень детализации дает возможность быстрее реагировать на изменяющиеся условия Web-системы. Например, если был изменен один из наборов, то нам необходимо будет повторно записать только его, а не всю последовательность целиком.
При разработке автоматизированных функционального тестирования принято разбивать один большой набор шагов на более мелкие функции. Такой же принцип применим и в нагрузочном тестировании.
Использование различных наборов в одном тесте
Чем больше тестируемая система, тем больше возможных вариантов использования ее может быть. В предыдущем разделе мы рассмотрели как можем разбить одну большую последовательность на несколько наборов и использовать их в разных тестах. Но что делать когда мы запускаем тест на несколько 1 000 пользователей.
Реальность такова, что люди не могут выполнять одновременно один набор шагов. Каждый человек индивидуален. Конечно для разных групп пользователей могут совпадать тестовые наборы, но ведь все эти группы могут работать с одним сайтом в один момент времени, а следовательно это один тест.
Многие утилиты позволяют параллельно запускать разные наборы в одном тесте параллельно. Нам надо только определить “сложный” набор, который может состоять из более простых. И потом уже несколько “сложных” наборов использовать в одном тесте.
Подобная детализация и использование наборов тестов приближает нас к возможному реальному использованию тестируемой Web-системы. Конечно, мы можем выполнить тестирование, не разбивая на наборы. Но как быть уверенными в том, что это отражает реальную историю использования. Если принять во внимание то, что web-система для нас неизвестна, мы не знаем ее структуру и архитектуру и видим только web версию, то мы не знаем точно какая из операций на каком сервере может выполняться.
В реальных условиях нагрузка будет отличаться от выполненного теста, когда мы использовали одну и ту же последовательность для всего теста и каждого пользователя. Я считаю, что подобная организация теста показывает реальный вариант использования Web-системы.
Данная организация наборов выполнения позволяет нам еще и регулировать задержки, с которыми могут начать выполняться те или иные наборы. А это еще один плюс к реалистичности нашего теста.
Использовать различные значения скорости обмена данными для запускаемых наборов
В наше время, при наличии огромного числа цифровых устройств и множества способов передачи данных, мы можем столкнуться с проблемами скорости передачи данных. Современные утилиты для нагрузочного тестирования или другие программные комплексы дают нам возможность ограничивать скорость обмена данными. Многие скажут зачем нам это, мы проверили то как система работает при использовании нашего канала передачи данных, а какой там у пользователей нас не интересует.
Предлагаю рассмотреть ситуацию, когда сервер поддерживает только 10 одновременных подключений. С ним будут одновременно работать 20 пользователей. Мы знаем, что когда тот или иной пользователь закончил работать, то он освобождает соединение и следующий может активно начинать его использовать. Если для части пользователей мы ограничим скорость обмена данными, то у нас увеличится и время получения данных. Из-за этого у нас увеличивается общее время работы всего сценария.
Если у нас достаточно много таких “медленных” пользователей, то мы заполним весь канал сервера, а значит новые, которые будут пытаться к нему подключится, получат отказ по истечении времени ожидания подключения. Другими словами из 20 пользователей несколько могут и вовсе завершится с ошибками.
Фактически это не является проблемой производительности сервера, он обрабатывал информацию с той скоростью, с которой работает клиент. Но с другой стороны мы несколько пользователей в любом случае теряем, они не смогут подключится к серверу. Любой web-сервер имеет у себя настройку, которая отвечает за то сколько же клиенту ждать в очереди на подключение.
При наличии высокоскоростного канала мы бы никогда данную проблему не выяснили бы, т. к. сервер скорее всего бы всегда успел бы завершать работу с текущим пользователем до того истечет время ожидания подключения следующего пользователя.
Выяснить подобную ситуацию мы смогли только при выполнении нагрузочного тестирования с учетом изменения значения скорости обмена данными.
Заказчику всегда лучше предоставлять полную информацию о работе его web-системы с учетом использования ее на различных цифровых устройствах. Вероятна ситуация, когда вы протестировали на максимальных настройках скорости, но большинство пользователей системы оказались с мобильными устройствами, где скорость обмена данными с web-системой может значительно отличаться и зависеть не только от типа устройства, но и от местоположения пользователя относительно устройства передачи данных.
Заключение
Разбитие одного большого сценария на мелкие наборы, дает нам возможность оперативно вносить изменения в определенный шаг сценария. Полностью заново записывать сценарий не требуется.
Детализация позволяет нам составить большое количество тестов с различным набором. Что приближает наши тесты к реальным нагрузкам, которые будут проводиться на Web-системе.
Правильный выбор скорости используемого канала покажет нам как наша система будет работать с реальными устройствами пользователей. Не всегда данные полученные при использовании полноценного канала обмена данными можно успешно экстраполировать на канал с меньшей пропускной способностью.
Надеюсь, что описанные мною этапы подготовки к выполнению нагрузочного теста на вашей Web-системе, помогут вам реализовать тест, который будет наиболее приближен к реальным условиям использования тестируемой системы и даст вам возможность быстро вносить изменения в ваш тестовый набор.
Удачных вам тестов и хороших результатов.
Автор: Nick-Monk
