Тестирование производительности в сравнении с модульным тестированием

Question

Я читаю «Искусство модульного тестирования» Ошерова, и хотя я еще не видел, чтобы он что-то говорил о тестировании производительности, мне в голову приходят две мысли:

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

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

Мой вопрос таков: мои выводы / склонения соответствуют мыслям сообщества?

Answer 1

Я согласен с вашими выводами / знаниями. Настоящие модульные тесты проверяют только часть системы, игнорируя, высмеивая или подделывая остальную часть по мере необходимости. Интеграционные тесты (или регрессионные тесты) проверяют большинство или все модули, работающие вместе, и это является истинным показателем производительности.

Answer 2

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

Answer 3

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

а) Модульные испытания

б) Интеграционные тесты

Мы снова запускаем интеграционные тесты реальной базы данных (а не в памяти), чтобы убедиться, что сценарии sql, репозитории hibernate работают должным образом

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

Я столкнулся с JunitPerf , который может помочь мне достичь этой цели.

Answer 4

Модульные тесты не должны выполняться быстро, потому что вы тестируете только очень специфический блок / систему. Например, если ваша тестируемая система относится к классу ClassA: IClassA, вы выполняете макетирование / заглушку и проверяете только поведение ClassA и не должны тестировать поведение, отличное от ClassA, например, если ClassA использует ClassB. Для достижения этой цели вы должны ввести макет ClassB вместо бетона.

С точки зрения тестов производительности имеет смысл по-прежнему использовать среду тестирования, такую ​​как NUnit / MBUnit / MavenThought, просто хранить эти тесты в отдельной сборке и не вызывать их как часть ваших модульных тестов.

Так что, если вы используете Rake для вызова ваших тестов, некоторые из ваших задач могут выглядеть следующим образом:

Rake Test:All         #Run all unit tests
Rake Test:Acceptance  #Run all acceptance tests
Rake Test:Performance #Run all performance tests
Rake Test:Integration #Run all integration tests

После непрерывной интеграции Test: All всегда вызывается после успешной сборки, а Test: Performance вызывается в 12:00 один раз в день.

Answer 5

Тесты производительности вполне могут состоять из модульных тестов.

Например, модульный тест может выдать несколько различных параметров в метод и проверить, что метод возвращает ожидаемый результат. Тест производительности может выполнить этот модульный тест 1000 раз (или любое другое значение, которое имеет для вас смысл) при записи всего, от счетчиков ЦП и памяти, вплоть до того, сколько времени занял каждый тест.

Answer 6

Все зависит от того, что вы называете тестированием производительности. При микрооптимизации конкретного кода я обычно использую что-то очень похожее на модульное тестирование (я должен назвать это тестирование производительности блока ?). Это в основном то, что я делаю в этом вопросе (хотя мне все равно, нужно ли на самом деле использовать фреймворк для юнит-тестирования). Но я также делаю такие вещи, чтобы оптимизировать мой производственный код C ++ в рамках модульного тестирования BOOST.

На самом деле существует множество видов тестирования производительности на разных уровнях и для разных целей (стресс-тест под большой нагрузкой, профилирование, микрооптимизация). Тестирование производительности, о котором вы говорите в своем вопросе, похоже, находится на уровне функционального тестирования. Уровень, для которого вы, вероятно, не будете использовать фреймворк для юнит-тестирования.

Answer 7

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

Answer 8

Я помню, как много лет назад Microsoft выступала за тестирование производительности программистами своих индивидуальных приложений с помощью Visual Studio Net Application Center Test (ACT). Была (все еще может быть там) целая методология для выполнения Транзакционного анализа затрат (TCA) на отдельных осинах. При этом эти оспы могут быть протестированы с использованием веб-драйвера и возможных фиктивных объектов, чтобы изолировать тестируемый код (то есть имитировать доступ к БД, если он не был разработан).

Этот подход можно использовать при любом модульном тестировании при условии, что у вас есть драйвер и, опционально, фиктивная инфраструктура объектов, чтобы позаботиться о любых зависимостях, которые еще не написаны. Этот подход также стал популярным с SOAPUI \ LOADUI. Кроме того, я бы порекомендовал изолировать отдельные операторы SQL, которые можно протестировать (оптимизировать) в соответствии с заданным дизайном базы данных. Это (БД) тестирование производительности модуля SQL может быть выполнено в начале SDLC, и оно откроет возможности оптимизации запросов.

С точки зрения стоимости и стоимости: я обнаружил, что раннее тестирование производительности UNIT с использованием Mock Objects при необходимости выявляет утечки памяти и чрезмерное использование ЦП, а также дисковый ввод-вывод в начале SDLC, но я бы «выбрал» тестируемый код для предметов повышенного риска.