Данная статья описывает наиболее распространенные подходы к тестированию производительности приложений; пользуясь аналогиями «из жизни» и примерами из опыта автора, показывает, почему так делать нельзя; и, наконец, пытается заронить искру понимания важности нагрузочного тестирования в светлые умы разработчиков, менеджеров и прочих хороших людей.

Начнем с пары историй.

История А.

На днях разговаривал с одним программистом. Пишет он на С++, работает в крупной компании в Чикаго; софтом, к созданию которого он причастен, активно пользуются финансовые и трейдерские компании. У нас, говорит, в продукте 600 тысяч строк кода. Начиналось все с небольшого приложения для анализа биржевой статистики, и вот за 20 лет вымахал такой монстр. Здорово, говорю. Внушает уважение. И как вы его тестируете, вашего монстра? Для этого, отвечает мне программист, есть специальный индус. Он какие-то тест кейсы выполняет, отчеты пишет. А до него этим менеджер один занимался, но тот все больше ручное тестирование делал. Новые функции проверял, например. Теперь вот индус. Хорошо, продолжаю выпытывать я, это функциональное тестирование. А производительность вы как-то тестируете? Нет, говорит, если клиенты начинают жаловаться на медленную работу, мы тогда сами ищем узкие места и сами же из исправляем. Кто разрабатывает продукт, тот его и знает лучше. Какой тестер с этим справится?

Умный человек, подумал я, а говорит глупости.

На днях сервис OnLive (облачный игровой сервис, см. подробнее в топике OnLive — революция подкралась незаметно) объявил об отмене абонентской платы. Дела, мол, идут так хорошо, что мы можем себе позволить не брать с пользователей 5 долларов в месяц (сразу после старта было 15).

Что ж, успех любого хорошего дела (если это конечно успех, а не судорожная попытка привлечь больше подписчиков) — это всегда хорошо. Но в данном случае, это еще и повод попробовать попробовать OnLive «на зуб». Несмотря на то, что сервис запущен почти четыре месяца назад, отзывов пользователей не очень много и они, по большей части, восторженные (см. например Мысли об OnLive). Такое единодушие вызывает определенные сомнения, не правда ли?

Ниже — впечатления от одного неполного вечера использования OnLive (плюс скриншоты). Отвечая на невысказанный вопрос «Зачем это нужно, если все интересующиеся могут посмотреть своими глазами?» — сервис пока доступен только в США.

В марте 2010 в рассылке пришло приглашение на конференцию «Эволюция законодательства в области качества ПО». Основным докладчиком значился Cem Kaner, JD (доктор юридических наук), PhD, профессор Технологического Института Флориды, в общем, серьезный товарищ. И тезисы были тоже очень привлекательные (цитирую в моем переводе):
— почему производители ПО не имеют обязательств, сравнимых с производителями других продуктов;
— как, с точки зрения закона, должны трактоваться программные сервисы (именно сервисы, не ПО — мое примечание);
— законность ограничения прав на reverse engineering.

И т.п. Очень интересная должна была быть конференция. К сожалению, я на нее не попал.

В свете некоторых недавних событий, мне захотелось порассуждать о первом пункте плана. Итак, «Почему производители ПО не имеют обязательств, сравнимых с производителями других продуктов?».

На сайте HP обнаружилось вот что:

"

Что характерно:
— гугль не в курсе;
— HP не в курсе (пару недель назад говорили, что в ноябре будет «что-то новое»).

Вопрос — есть ли среди присутствующих те, кто занимается нагрузочным тестированием? Или интересуется? Или нуждается в? Странно, что данная тематика совершенно не представлена на habrahabr.

Просматривал давеча список игр, купленных в «стиме», вот что подумалось.

Оглядываясь в прошлое, неожиданно приходишь к выводу, что середина-конец 90-х годов прошлого века — краткий «золотой век» компьютерных игр. Который не повторится больше никогда.

В то время сошлось очень много звезд:
1. персональные компьютеры стремительно набирали популярность, рынок рос небывалыми темпами;
2. интернет был в зачаточном состоянии, не было конкуренции со стороны сегодняшних сетевых сервисов и соц. сетей, отнимающих у покупателей свободное время;
4. компьютерное «железо» было малопроизводительным. Успех игры гораздо больше зависел от удачной идеи/сюжета/геймплея, и существенно меньше — от технической «продвинутости»;
3. как следствие — стоимость разработки игры была относительно небольшой (это вам не 100 миллионов на Starcraft 2);

Этих четырех пунктов достаточно, чтобы объяснить небывалый расцвет того времени и все, что случилось с КИ потом. А потом было вот что: