Завершая цикл статей (часть 1, часть 2) о вычислении производительности софта, хотелось бы рассказать, как правильно проводить перформанс-тестирование (performance testing). Тема становится все более популярной, но при этом далеко не все понимают, что под этим подразумевается. Ведь прежде чем ответить на вопрос «как», нам нужно разобраться с вопросом «что»: что именно нам нужно тестировать?

 

Нефункциональные требования, или «хочу, чтобы все работало быстро»

В теории перед тем, как начать программировать, нужно придумать спроектировать архитектуру будущего софта. Но еще раньше надо определиться с требованиями, которые бывают как функциональные (нужна кнопка «Вход» и такие-то страницы), так и нефункциональные (например, использовать PostgreSQL, Ubuntu 14.04). Одним из типов нефункциональных требований и являются требования к производительности.

Рис. 1. Perfomance-тесты в действии
Рис. 1. Perfomance-тесты в действии
 

Определяемся с требованиями к производительности

Требования к производительности могут и даже должны отличаться от проекта к проекту — практически не бывает двух проектов с одинаковыми требованиями. Их можно сгруппировать по типам софта (это описано в разных книгах по методологии тестирования, но я буду полагаться на свой опыт, а книги ты и так сможешь прочитать).

  • Desktop-приложения (актуально и для современных мобильных и веб-приложений). В таком софте обычно важны скорость запуска, время отклика на нажатия клавиш (никто не хочет ждать десять секунд после нажатия на пункт меню), время выполнения распространенных операций. Например, в текстовом редакторе при открытии файла можно и подождать секунду-другую, но вот ждать столько же, пока на экране появится набранный символ, — это нонсенс.
  • Server-side приложения — всевозможные СУБД, API (REST-, SOAP-, RPC-серверы) и так далее. Тут список требований к скорости работы может быть просто огромный, начиная от времени ответа на запрос для одного клиента и заканчивая временем отклика при условии, что у нас есть одновременно 1k клиентов к REST API и все они что-то делают.
  • *aaS, всевозможные облака. Производительность облака может измеряться совсем иначе, чем, например, REST API сервиса. Тут в зависимости от типа облака все может сильно и очень сильно меняться. В случае с perfomance SaaS (software-as-a-service) требования почти такие же, как и к любому высоконагруженному веб-приложению. А вот если ты тестируешь IaaS (infrastructure-as-a-service), то требования могут быть совсем другими, например: запуск X виртуальных инстансов не должен занимать больше Y времени, а вот временем, сколько она будет выключаться, иногда можно и пренебречь.

Тут как и с любыми требованиями — нужно отталкиваться от того, что в итоге должно получиться, и не забывать про здравый смысл. Ведь если твой REST API отправляет ответ за одну секунду, а WEB UI потом десять секунд отображает результат, то оптимизировать бэкенд нужно не в первую очередь. Пользователи будут более благодарны за быстрый UI.

 

Такие разные тесты

Основных видов перформанс-тестирования не так уж и много: performance testing, load testing (нагрузочное тестирование), stress (стресс-тестирование) и configuration (конфигурационное тестирование, где мы меняем всевозможные параметры софта и железа). Исходя из требований, времени и возможности (см. «треугольник требований»), мы можем выбрать необходимые тесты. Поговорим подробнее о них, прежде чем приступить к написанию тестов.

Продолжение статьи доступно только подписчикам

Вариант 1. Оформи подписку на «Хакер», чтобы читать все статьи на сайте

Подписка позволит тебе в течение указанного срока читать ВСЕ платные материалы сайта, включая эту статью. Мы принимаем оплату банковскими картами, электронными деньгами и переводами со счетов мобильных операторов. Подробнее о подписке

Вариант 2. Купи одну статью

Заинтересовала статья, но нет возможности оплатить подписку? Тогда этот вариант для тебя! Обрати внимание: этот способ покупки доступен только для статей, опубликованных более двух месяцев назад.


3 комментария

Подпишитесь на ][, чтобы участвовать в обсуждении

Обсуждение этой статьи доступно только нашим подписчикам. Вы можете войти в свой аккаунт или зарегистрироваться и оплатить подписку, чтобы свободно участвовать в обсуждении.

Check Also

LUKS container vs Border Patrol Agent. Как уберечь свои данные, пересекая границу

Не секрет, что если ты собрался посетить такие страны как США или Великобританию то, прежд…