с использованием тестового бегуна для тестов производительности сети

Question

Мы пишем приложение в MVC/C# на VS2013.

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

[Test, Category("UITest")] 
    public void CanCreateMeasureSucceedWithOnlyRequiredFields() 
    { 
     ManageMeasureDto dto = new ManageMeasureDto() 
     { 
      Name = GetRandomString(10), 
      MeasureDataTypeId = MeasureDataTypeId.FreeText, 
      DefaultTarget = GetRandomString(10), 
      Description = GetRandomString(100)  
     }; 

     new ManageScreenUITest<MeasureConfigurationController, ManageMeasureDto>(c => c.ManageMeasure(dto), WebDrivers).Execute(ManageScreenExpectedResult.SavedSuccessfullyMessage); 
    } 

Метод Execute принимает значения в DTO и вызывает selenium.sendKeys и кучу других методов, чтобы фактически выполнить тест, представить форму, утверждают ответ содержит то, что мы хотим.

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

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

Оттуда я мог бы по существу «набрасываться» мои тесты, чтобы создать сценарий, например:

public void MeasureTestScenario() 
{ 
    CanListMeasures(); 
    CanSearchMeasures(); 
    measureId = CanCreateMeasure(); 
    CanEditMeasure(measureId); 
} 

Пропавших кусок головоломки, как я бегу эти «сценарии» под нагрузкой? IE, я после тестового запуска, который может выполнить 1..N из этих тестов параллельной, надеюсь, что-то вроде таких, как Ramp up time, случайные ожидания между каждым сценарием и т. Д. В идеале количество параллельных тестов будет настраиваться при запуске время, т. е. порождает еще 5 тестовых потоков. Отчетность не является очень важной, поскольку я могу регистрировать время выполнения как часть веб-запроса.

Возможно, есть и другой подход, например, с помощью C# для управления более традиционным инструментом тестирования нагрузки?

Настоящим преимуществом этого метода является обработка более сложных экранов, то есть экрана, содержащей коллекции объектов. Я могу получить случайную родительскую запись из БД, использовать мой существующий код automapper для создания вложенного dto, иметь код для ходьбы, чтобы изменить случайные значения, а затем использовать мою тестовую среду для отправки значений dto в качестве веб-запроса. Гораздо проще, чем вручную кодировать скрипты JMeter. cheers, dave

Answer 1

При использовании NUnit в качестве бегуна для различных задач/тестов в порядке, я не думаю, что это правильный инструмент для тестирования производительности.

Он использует отражение, имеет накладные расходы, он использует в конечном итоге предопределенные настройки для webclient и т. Д. Это намного лучше, если используется инструмент тестирования производительности. Вы можете использовать NUnit для его настройки/запуска.

Answer 2

Я не согласен с тем, что NUnit не используется, с соответствующим протоколированием любой функциональный тестовый бегун может использоваться для тестирования производительности. Накладные расходы не имеют значения, когда сам тестовый код предоставляет данные, например, при отправке запросов и получении ответов или при запросе страницы и при завершении загрузки. Анализ журнальных файлов и генерация некоторых основных показателей - довольно простая задача IMO. Если он станет огромным проектом, который меняет вещи, но, скорее всего, я могу обойтись с помощью приложения командной строки, которое занимает час или два, чтобы писать.

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