Тестирование производительности ПО

    На сайте тестировщиков недавно появилась статья, которая описывает один из подходов к тестированию ПО. Я считаю, что он является наиболее правильным и разработчикам нужно обязательно взять её на вооружение при тестировании собственных продуктов.

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

    Попутно хочу задать вопрос разработчикам, которые читают Хабр: а вы тестируете свои программные продукты на производительность? Какой алгоритм для этого испольуете? Инструментарий?


    Цитата:
    1. Первые тесты желательно проводить на самом низком нагрузочном профиле так как еще непонятно поведение системы, возможно есть серьезные препятствия для нормальной/ожидаемой производительности.
      Обычно практикуется повышение нагрузки, выраженное в увеличении интенсивностей выполнения операций (увеличение количества пользователей) с тем чтобы получить зависимости времен отклика от различных нагрузок.
      Одновременно с проведением теста необходимо снимать метрики производительности серверного оборудования так как тестирование Приложения обычно производится относительно аппаратных конфигураций (кол-во CPU x Memory). Наиболее важными из них являются:
      1. Показатели в процентах для процессоров:
        1. CPU user использование процессоров для работы Приложения,
          CPU wio ожидание процессорами ввода/вывода,
          CPU idle «простой» процессора
          Очереди на процессора
          Использование памяти
          Очереди на диски
          При этом дисковая подсистема и сеть не должны быть «узкими местами» так как в этом случае будет непонятно насколько эффективным с точки зрения производительности является само Приложение

          PS источник и полный текст: software-testing.ru
    Поделиться публикацией

    Комментарии 8

      +4
      Занимался (и занимаюсь) тестированием производительности веб-приложений, которые делает наша компания. Процедура не сильно отличается от описанной в статье, если коротко:
      1) выделяем пользовательские последовательности действий (сценарии поведения)
      2) группируем эти сценарии
      3) определяем количество виртуальных пользователей (для достижения заданных целей - малая, средняя, высокая загрузка, исследование на максимально возможную загрузку системы - пиковая производительность и т.п.)
      4) пишем тесты, выполняем.

      инструментарий - опенсорсовский:
      - генератор трафика - Apache JMeter
      - для сбора информации о загрузке системы используется вывод команды top c соответствующими фильтрами, для последующего анализа - самописный лог-парсер (параллельно он еще вычисляет ряд статистических критериев, но об этом ниже)

      Само по себе тестирование производительности - вещь хорошая, но в разовом исполнении оно дает только приблизительный результат (ну да, можно сказать, что "вот, мы сейчас обеспечиваем работу стольких-то пользователей"), наибольший интерес для нас представляет сравнение результатов подобного тестирования от версии к версии.
      Подобное сравнение опирается на сбор:
      * информации о загрузке процессора (частотная группировка, с фиксированным шагом - 0-2%б 2-4% и т.п.)
      * информации об объеме расходуемой памяти (аналогично, частотная группировка)
      * прочая информация (времена доступа к базе, и т.п. - все по частотам)
      От релиза к релизу алгоритм предварительной обработки замеров не меняется (строится частотная диаграмма). Сравнение качественных изменений проводится Т-Стьюдент тестом (для этого нам и были нужны частотные выборки одинаковой длины). Ну а вычисленный коэффициент как раз и показывает, насколько значимо приложенеи поменяло свое поведение.

      p.s.
      в планах ввести практику обязательного прохождения приложением теста на производительность.
        0
        Правильный линк на генератор трафика Apache JMeter вот: http://jakarta.apache.org/jmeter/
        (у вас побилось...)
          +1
          хм, спасибо. ссылка была истрактована как относительная, mea culpa - не указал http:// :)
          0
          Хочу отметить, что даже разовые прогоны позволяют узнать многое о системе, и не всегда дают только приблизительный результат. Есть еще немало параметров и метрик которые полезно знать прежде чем запускать систему.
          Я бы еще посмотрел на результаты, пусть даже разовые, не только со стороны обеспечения количества пользователей или анализа загрузки программно-аппаратного комплекса, но и как на результаты дающие уверенность, что завтра мы сможем, в случае увеличения нагрузки на систему, оперативно отреагировать и поддерживать большее количество. В данном случае я говорю об одном из трех основных показателей производительности - масштабируемости.
          Так же при единичном прохождении можно выявить как себя поведет система при нестандартных нагрузках, а главное посмотреть на восстанавливаемость системы после непредвиденных сбоев. Это тоже очень немаловажно.
          А вы у себя проходите эти фазы нагрузочного тестирования?
            0
            идеи есть, и в частном порядке я эксперименты ставлю (учитывая, что сервисы работают под Tomcat, c восстанавливаемостью плохо, уж если Out of memory, то до рестарта). Но как постоянная практика - это на стадии введения.
            Нестандартные нагрузки - исследование интересное, но в нашем сегменте рынка (intranet-сервисы, и слабонагруженные internet-приложения) не сильно пока востребованное.

            Меня еще интересует работа системы длительное время при стабильной средней нагрузке (stability testing) - расход памяти, загрузка, скорость отдачи страниц
              0
              Кстати не можете объяснить чем вызвана популярность tomcat ? :)
                0
                могу только сказать, почему мы его выбрали. OpenSource, хорошо настраивается, кластеризуется, кроссплатформенный, поддержка "мирового сообщества". До этого был JRun
                  0
                  Я тоже просто его довольно долго использовал. Но сейчас использую resin он уже GPL :)

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

        Самое читаемое