К основному контенту

LoadTest тонкого и толстого клиента в VS

Отвлечемся от последовательного изучения теории тестирования. Сегодня расскажу, как делать нагрузочные тесты в Visual Studio. Также будет использоваться БД SQLServer и браузер iexplorer.
Во время ознакомления с Web Performance and Load Test Project, я обращалась ко многим источникам. На основные из них буду прикладывать ссылки на соответствующем шаге.  
Итак, начнем!
Шаг 1. Для того чтобы начать работу, нужно определиться что вы будете тестировать: тонкого клиента или толстого.
Шаг 2. Выбрав нужный вам вариант, можно приступить к работе. Запускаем студию и выбираем:
- Unit test, если толстого клиента;
- Web Performance and Load Test Project, если тонкого.
        Далее действия расходятся. Unit test.
Шаг 3. В проект с юнит тестом добавляем класс и в нем собираем запросы к БД. Можно БД протестировать также другим способом, описанном в данных статьях: https://msdn.microsoft.com/ru-ru/library/jj851200(v=vs.103).aspx , https://msdn.microsoft.com/ru-ru/library/jj851212(v=vs.103).aspx , https://msdn.microsoft.com/ru-ru/library/jj851226(v=vs.103).aspx
        Если у вас запросы из клиента к БД размещены в коде, то можно их отловить Sql profile. Чтобы верно собрать запросы, можете воспользоваться https://www.codeproject.com/Articles/823854/How-to-connect-SQL-Database-to-your-Csharp-program.
Шаг 4. В unit тесте реализуем методы с вызовом запросов. Я разбивала так: один метод = одному действию пользователя, например, добавить user (при одном действии пользователя не обязательно будет один sql  запрос). 
Можно собрать, конечно, unit тесты и для Web service https://msdn.microsoft.com/cs-cz/library/ms243399(v=vs.100).aspx

Web performance test
Шаг 3. После того, как вы выберете данный вариант, у вас откроется Webtest для записи. Возможно, что в браузере не будет включен record (на скрине он включен => значок конфигурации -> настроить надстройки)
Вы можете «прокликать» необходимый бизнес – процесс, а студия запишет все необходимые запросы с параметрами. Но для дальнейшей работы с записанным webtest – ом его нужно будет откорректировать. Поэтому, чтобы хорошо разобраться в запросах, постепенно собираем их руками. С помощью средств разработчика в браузере отлавливаем запросы бизнес - процесса, который мы будем нагружать, и собираем вот в таком виде:
Для этого берем все данные из средства разработчика. На скрине (пример) выделен запрос красным цветом. Его копируем и вставляем в поле URL (следующий скрин)
Студия сама разберет параметры из запроса, которые идут после знака «?». Метод выбираем в соответствии с указанным методом (выделен желтым) в браузере. У post запроса параметры могут отображаться во вкладке «Текст запроса». По данной ссылке подробно описано создание веб теста: https://msdnshared.blob.core.windows.net/media/2016/09/Introduction-to-Web-Performance-and-Load-Testing-with-Visual-Studio-Enterprise-2015.pdf
Веб получение запросов https://habrahabr.ru/post/332862/
Шаг 4. В качестве параметров можно передавать .csv файл или подставлять данные из БД.
         Теперь займемся нагрузкой.
Шаг 5. Добавляем в проект LoadTest (описано в статье https://msdnshared.blob.core.windows.net/media/2016/09/Introduction-to-Web-Performance-and-Load-Testing-with-Visual-Studio-Enterprise-2015.pdf), собираем тест - методы, если unit test, или webtest-ы, если web performance, настраиваем и получаем тест в таком виде:

       Можно добавить машины, можно добавить еще сценарии. Настройки открываются при выборе Run Settings -> properties
Подробнее о нагрузке можно почитать здесь: https://habrahabr.ru/company/cognitive/blog/144461/
Статья написана кратко (несмотря на большой объем), в основном для фиксирования знаний. Если возникнут вопросы, то пишите, постараюсь по возможности ответить.

Комментарии

Популярные сообщения из этого блога

Дымовое, критического пути и расширенное тестирование

Из приведенной ранее классификации тестирования (в статье " С чего начинать изучение тестирования? Конечно же с методов! ") нам осталось рассмотреть «по степени важности тестируемых функций». Но, на этом теория еще не заканчивается) Итак, по степени важности тестируемых функций разделяют следующие виды: - «Дымовое» (smoke) - тестирование, которое состоит из минимального набора тестов на явные ошибки. Дымовое тестирование на начальном этапе выявляет основные критические дефекты. Исходя из того, что данные проверки практически всегда одинаковы и редко претерпевают изменениям, целесообразно будет их автоматизировать. Ежедневная сборка продукта и smoke тестирование являются передовыми практическими методами. Программу, не проходящую "дымовой тест", не имеет смысла отдавать для более глубокого тестирования. - Критического пути ( critical path test ) — основной тип тестовых испытаний, во время которого значимые элементы и функции приложения проверяются н

Тест план и тестовая модель - что это?

Test Plan (тест план)  — это документ или совокупность документов, расписывающих всю тестовую активность (цели, подходы, ресурсы и график запланированных тестовых активностей)  в пределах одного проекта, все работы проводимые командой тестирования или одним тестировщиком. В стандарте IEEE 829 перечислены пункты, из которых должен состоять тест-план:   1) Test plan identifier (идентификатор);   2) Introduction (описание/цель) - Предельно краткое описание цели разработки приложения (частично это напоминает бизнес-требования);   3) Features to be tested (Области, подвергаемые тестированию) - Перечень функций и/или нефункциональных особенностей приложения, которые будут подвергнуты тестированию. В некоторых случаях здесь также приводится приоритет соответствующей области. 4) Features not to be tested (Области, не подвергаемые тестированию) - Перечень функций и/или нефункциональных особенностей приложения, которые не будут подвергнуты тестированию. Причины исключе

Советы для молодых тестировщиков или как составлять тест - кейс =)

Тест (test) представляет собой набор операций, предназначенных для получения одного или большего числа ожидаемых результатов в некоторой программной системе. Тест-кейсы должен помочь тестировщику (даже начинающему) провести проверку продукта без ознакомления со всей документацией. В тест – кейсе желательно избегать зависимостей от других тест – кейсов. Тест кейс в основном состоит из * Основных параметров - id (номер) - уникальный идентификатор тест-кейса. Его удобно использовать для одинакового понимания, о какой проверке идет речь (например, дать ссылку в баге). - Автор – имя и фамилия тестировщика, который написал тест – кей. - Название — краткое описание сути проверки. - Предусловие – предварительные шаги. - Шаги – что нужно сделать, чтобы что-то получить. - Ожидаемый результат – тот результат, который соответствует документации или здравому смыслу =). - Фактический результат – то, что получилось в итоге действия в шаге. - Постусловия – заключительные ша