пятница, 9 октября 2009 г.

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

С точки зрения тестирования производительности все системы разделяются на:

Высоконагруженные. Сотни тысяч пользователей, десятки миллионов хитов в день, десятки гигабайт данных, терабайты трафика. Yandex.ru, например.

Низконагруженные. Например, системы В2В взаимодействия (системы межкорпоративного взаимодействия). Такую систему обычно используют около 100-500 сотрудников компании и 1000 – 5000 клиентов компании и, конечно же, не все одновременно.

Если в высоконагруженных системах производительность стоит на первом месте, то в В2В системах на первом месте - функциональность. Неотъемлемая характеристика В2В систем – сложная бизнес логика. И эта сложная логика должна работать без сбоев и глюков.

Поэтому, при тестировании В2В систем основная часть средств и времени отдается таким видам тестирования как: функциональное, юзабилити и интеграционное тестирование. На тестирование производительности остается очень мало времени.
Но его все равно проводить необходимо.

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

Мы можем потратить кучу времени и средств на обеспечение супер производительности нашей системы. Допустим, она будет чудесно работать под нагрузкой миллион хитов в день. Но в реальности максимальная нагрузка, которой подвергается наша система – 10 тысяч хитов в день. И, по прогнозам экспертов, до миллиона хитов ей еще расти и расти. Что мы сделали? Мы просто выбросили деньги на ветер и потратили силы зря. Не нужна нашей системе такая производительность, и еще много лет будет не нужна. Лучше бы мы разработали какую-то новую функциональность, которая действительно облегчила бы жизнь нашим пользователям.

То есть, мы должны честно ответить на примерно такие вопросы:

  • Какое среднее количество пользователей будет одновременно работать с системой (Сколько сотрудников ежедневно пользуются системой?. Сколько клиентов в день заходят в нашу систему?);
  • Какое максимальное количество пользователей будет одновременно работать с системой (Скольким людям понадобится достать или загрузить данные в системе в конце квартала, например?);
  • Какой запас производительности мы хотим иметь (Что если произойдет что-то непредсказуемое и куча людей ломятся в систему, сколько их может быть? Или, что если мы банально ошиблись в наших расчетах средней нагруженности системы. Насколько мы могли ошибиться?);
  • Границы приемлемой производительности системы (Какие показатели производительности мы будем считать хорошими/нормальными/плохими/очень плохими. Время выполнения операции 3 секунды это хороший или плохой показатель для нашей системы, а 10 секунд? Ну, 10 секунд это точно плохо, скажете вы. Ок. А если это операция формирования квартального отчета по результатам деятельности отдела? Вы все еще уверены, что 10 секунд это много для такой операции? Подсказка: тут нет общепринятых стандартов. Для каждой конкретной системы и даже для каждой конкретной операции хорошие и плохие показатели могут отличаться в разы).
Иногда слышу нарекания коллег тестировщиков, мол вот я выявил, что система падает при непрерывной работе 20-ти пользователей с таким-то модулем на протяжении 30 минут. Кошмар! Завел баг, сказал менеджерам, а они ничего с этим не делают. Ах они такие!

А менеджеры просто знают, что этим модулем пользуются от силы 1-2 пользователя в день и то не каждый день. То есть такая производительность модуля устраивает всех уже на протяжении нескольких лет. И еще несколько лет будет устраивать. Как только нарисуется тенденция к увеличению интереса пользователей к модулю, вот тогда найденная проблема станет действительно актуальной и ей уделят необходимое внимание.

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

Комментариев нет:

Отправить комментарий