В нынешних реалиях IT-сообщества очень просто найти инструменты для проведения нагрузочного тестирования. Их легко можно объединить в несколько одновременно работающих механизмов и провести нагрузку в несколько сотен виртуальных пользователей.
Но это ничего не даст, если у вас нет правильного понимания того, зачем такие проверки проводить и чему полученные результаты могут вас научить в будущем.
А значит, перед тем как приступать к тестам, нужно ответить на такие вопросы:
- Какие конкретные сценарии будут проверяться?
- Какое ожидаемое поведение ПО должно быть в этих сценариях?
Например, у нас есть сайт по продаже компьютеров. Администраторы обратили внимание, что ресурс наиболее активен рано утром в среду. Вы заказали рекламу на телевидение и ожидаете массу новых посетителей уже в ближайшее время.
Держа все это в уме, вы логически обдумываете следующие шаги:
- Все страницы сайта должны корректно загружаться не более чем за 1.5 секунды при обычной нагрузке в среду утром.
- Ресурс должен легко обрабатывать от 500 запросов за 1 секунду.
- Сайт должен выдерживать нагрузку в 5000 пользователей за 1 сеанс. Такое число запросто может возникнуть после рекламы на ТВ.
Следующее действие — проанализировать, какое определенное тест-окружение будет использоваться.
Естественно, тестирование после релиза — наиболее реалистичное окружение. Но проведение нагрузочной проверки в таких условиях — не очень хорошая идея, если итогом тестов станет неработоспособность веб-сайта.
Следующий самый реалистичный сценарий — это тест-окружение, которое сможет точно демонстрировать реальное окружение в плане суммы используемых серверов и объема БД для бэк-офиса. Идеальный сценарий, когда ваше тест-окружение применяется только для нагрузочных тестов. К сожалению, это не всегда осуществимо в реальности.
Может возникнуть так, что тестовое окружение одновременно будет необходимо сразу для нескольких QA-инженеров. И тогда каждый должен точно знать, что делает другой и как это может повлиять на вашу работу. Другие тестировщики должны знать, когда выполняются ваши нагрузочные проверки и сильно не удивляться завышенному времени отклика.
Как только тестовое окружение будет готово, можно выполнить несколько простых тестов, чтобы понять, какие базовые метрики вам необходимы.
Проектирование нагрузочных тестов
- Создание индивидуальных вариаций, к примеру, загрузка веб-страницы или единичный запрос по API;
- Тестирование полных пользовательских сценариев: просмотр страниц сайта, добавление товара в корзину, процедура оформления совершенного заказа.
В применении обеих стратегий есть смысл, если использовать их не одновременно. Допустим, вы можете для начала просчитать, сколько по времени будет загружаться главная страница при 2 тысячах запросов этой страницы за 1 час. В отдельной проверке можно создать сценарий, при котором больше сотни пользователей смогут просматривать страницы сайта, добавляя товары в корзину и совершая заказы, с последующим отслеживанием итогов на выявление ошибок.
Для подобного теста необходимо определиться с такими вопросами:
- Какое количество пользователей будет одновременно взаимодействовать с системой?
- Такие взаимосвязи будут добавляться одновременно или постепенно?
- Сколько времени продлится один тест?
Для наглядности допустим, что у нас есть тест под наш магазин по продаже телевизоров. Делаем тест для даты, когда рекламу сайта покажут по ТВ.
Предположим, у нас есть сформированные тест-шаги, корректно загружающие веб-сайт, листающие страницу и добавляющие некоторые товары в виртуальную корзину. Нам необходимо, чтобы система выдерживала нагрузку от 5 000 пользователей за час, поэтому на этом и будет сфокусирован наш тест.
В реальности, вряд ли все 5 тысяч пользователей одновременно станут совершать покупки, а значит можно указать тесту добавление нового пользователя каждые 10 секунд. Каждый такой пользователь пройдет по тестовому сценарию один раз, а затем он завершится. Проверка будет выполняться от одного часа или же до момента, когда все 5 000 посетителей завершат свои тестовые сценарии.
Перед началом выполнения тестов нужно убедиться, что шаги могут возвращать дефекты, если не получают ожидаемого итога. Крайне важно удостовериться в том, что тесты действительно проверяют предполагаемое изначально поведение ПО.
Проведение теста
Когда есть шаги, заданы тест-конфигурации (число пользователей, частота их добавления), и тестировщик убедился, что валидация итога в порядке, наступает время для проведения теста нагрузки.
Пока проводится тест, необходимо следить за временем ответов от сервера и загрузкой процессора. Если будет много дефектов или всплесков чрезмерной загрузки ЦП, можно сразу же остановить тест и самостоятельно отметить, на какой конкретно загрузке это произошло.
В любом случае (при преждевременной остановке теста или после его успешного окончания), понадобится несколько прогонов, дабы с полной уверенностью убедиться, что итоги полностью соответствуют друг другу. В конце тестов мы можем ответить на вопрос, смогут ли выдержать разрабатываемое программное обеспечение 5 000 заказов за 1 час.
Если все тестовые заказы прошли успешно, а время ответа сервера было приемлемым, значит ответ «да». Если в процессе тестирования мы столкнемся с проблемами, или время ответа от сервера будет значительным образом увеличено, тогда ответ «нет».
В таком случае всей собранной информацией стоит быстрее поделиться с программистами, чтобы наглядно им продемонстрировать, при какой сумме пользователей ваша система перестает нормально функционировать.
Одним словом, нагрузочное тестирование — вещь непростая и требует оно достаточно времени и внимания. Но в то же время, с помощью данного вида проверок можно заранее уберечь систему от всевозможных сбоев в работе.
Оставить комментарий