»

Янв 26

Немного о «нагрузочном» тестировании

 Совокупность информации в интернете иногда вгоняет в когнитивный диссонанс.

Получил интересный вопрос от знакомого:

«Крупный системный интегратор, приглашает тестировщика по автоматизированному нагрузочному тестированию.© вакансия.  А разве бывает другое?»

«Пытаются заманить упоминанием слова автоматизация, что ли?» — имел глупость подумать я, — «Или есть компании, у которых нагрузочное тестирование выполняется пулом 100-500-1000-… инженеров?»

Но тут, внезапно, при просмотре старых записей одного из форумов, мое представление о нагрузочном тестировании перевернулось…

Мысль поразившая выделена мной жирным текстом. Орфография и пунктуация авторские:
«Я бы так не сказал. Тот кто знает акхитектуру прелажения подсознательно будет делать все правильно. И вероятность что он, а не пользователь, выявин «неудобства» и неполадки гараздо ниче, чем если с софтиной поработает чел. хорошо знаюший предметную область, просто хороший и опытный пользователь. Также проведет испытания на высоких пиковых нагрузках, т.е. очень много и очень быстро попробует поработать. А потом раскажит о своих впечатлениях и пожеланиях».

Признаюсь, на мой взгляд довольно-таки странное представление о нагрузочном тестировании и предоставлении информации о качестве нагружаемой системы.

Почему?

Ручное нагрузочное тестирование для меня выглядит так:

Печальное должно быть зрелище.

Я бы обозначил сразу такие проблемы:

1.      Оборудование – вы только представьте себе, какая должна быть тестовая лаборатория для эмуляции, например, пяти тысяч пользователей. Стадион? А если надо проверить возможность работы системы с 20-ю тысячами пользователей?

2.      Время – организация одного тестового прогона — это вам не флэшмоб собрать. Здесь влиять будут доли секунды. А если таких прогонов надо, хотя бы 100? А если это проверка daily билдов?

3.      Затраты на оплату труда, даже если это дешёвая рабочая сила, не понимающая что такое компьютер, на мой взгляд не оправданы (стараюсь быть очень корректным в формулировке :-))

А вот на отважного менеджера,  который будет управлять этой командой, я бы посмотрел с удовольствием, особенно после месяца-двух ежедневных прогонов тестов. Нет, не для того что бы позлорадствовать. Мне просто интересно посмотреть на такого человека после его рабочего дня.

 

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

Поделиться в соц. сетях

Опубликовать в Facebook
Опубликовать в Google Plus
Опубликовать в LiveJournal
Опубликовать в Яндекс

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

1 пинг

  1. novak che

    Вам не кажется, что всё же «нагрузка» и «высокая нагрузка» это несколько разные вещи? Да и тестировать можно не только программные объекты. Потому можете смело говорить знакомому — бывает. Но крайне редко, а у «крупных интеграторов» и вообще, наверное, никогда.

    1. Сергей Атрощенков

      Согласен, что разница есть.
      Тем не менее, мне стало интересно, как в ручную можно создать нагрузку (мы же говорим именно про нагрузочное тестирование, а не функциональное).
      Проводить тестирование нагрузки не для выяснения масштабируемости системы или её готовности — мне кажется не очень разумным шагом.

      Ваш комментарий напомнил мне реальный случай из опыта: Была найдена утечка памяти приложения после ~15 однотипных действий.
      Да, это можно отнести к найденному узкому месту, и можно это назвать нагрузочным тестированием. Хотя эти тесты проводились как функциональные.

  1. О 10 вариантах замедлить производительность вашей команды. | BarbaricQA.com

    […] тестирование нагрузки быстро-и-часто-кликая? не новость, да. — это […]

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Вы можете использовать эти теги HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>