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

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

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

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

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

Ответ 1

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

Ответ 2

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

Ответ 3

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

a) Единичные тесты

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

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

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

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

Ответ 4

Эксплуатационные тесты вполне могут состоять из модульных тестов.

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

Ответ 5

Ед. тесты не требуют времени для выполнения, потому что вы проверяете только конкретный блок/систему. Как если бы ваша тестируемая система ClassA: IClassA, вы делаете свое издевательство /stubbing и проверяете поведение ClassA и не должны тестировать поведение, отличное от ClassA, например, если ClassA использует ClassB. Вы должны ввести макет класса B вместо бетона, чтобы достичь этого.

Что касается тестов производительности, имеет смысл использовать платформу тестирования, например 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 вызывается в 12am один раз в день.

Ответ 6

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

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

Ответ 7

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

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

С точки зрения стоимости и стоимости: я нашел раннее тестирование производительности UNIT, используя Mock Objects, в зависимости от ситуации, будет идентифицировать утечки памяти и чрезмерное использование ЦП и Disk IO на ранней стадии SDLC, но я бы "вишневый выбор" тестируемого кода для пунктов с более высоким риском.

Ответ 8

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