Согласен, что для локальной установки требуется много места и памяти. Но в принципе это разовое действие. Если же поднимать виртуалки в Azure, то там можно сразу использовать галерею готовых образов с предустановлеными компонентами, в том числе VS, MTM и тп.
Жалко, что в докладах про AppSec.NET камера ~90% времени направлена на спикера. Из за этого презентации и демо видны не полностью. Но в целом у вас получились очень интересные и полезные доклады. Молодцы!:)
«Тесты совершают намного больше одного действия»
На мой взгляд — это антипаттерн. Тесты должны быть простыми — подготовка данных, действие и проверка. Благодаря такому подходу — тесты станет гораздо проще поддерживать, да и поиск ошибок упростится — представьте — если падает тест, то можно сразу предположить в каком именно методе и при каких условиях возникает ошибка, а не разгребать тонну логов и стек трейсов.
Тесты иммитурующии работу троллей разбивайте на маленькие:)
И еще очень полезны практики код ревью тестах (как между тестировщиками, так и перекрестные ревью разработчик — тестировщик).
Полностью согласен с автором. Технологии меняются и пора меняться тестировщикам. Такие тестировщики, т.е. Software Developer In Tests наиболее полезны в продуктовых командах, т.е. работая вместе с разработчиками. В данном случае стоит использовать, тот язык, на котором построен основной код продукта
Я скоро планирую написать небольшую step by step статью- как создать site 2 site подключение между ажурными vnet сетями и связать локальную корп сеть с ажурной. Основной посыл статьи будет — создание гибридной тестовой инфраструктуры (тест контроллер в корпоративной сети, а агенты в Azure VPN.), но все же там будет подробно освещены эти и другие подобные вопросы.
узнаю компанию :) — бывший ситроникс.
И автору привет) Только кто такой этот Саня, который «внедрил кошерную SOA-архитектуру, покрыл весь код тестами, а также наладил процесс Continuous Delivery.»?)
Хорошо было бы провести побольше тестов (с прогревочными вызовами и тп). Еще рекомендую написать вывод, а то с первого взгляда не особо понятно, что вы пытались увидеть.
>На основании чего сделаны такие выводы? Я бы на Вашем месте, прошелся по ссылкам, которые привел ТС. Хоть им больше 10 лет и касаются в основном IIS 6 + .NET 1.0, но общие концепции оптимизации там приведены хорошо и настройка пула предваряется немалым количеством предварительных мероприятий.
К сожалению я не смотрел приведенные ссылки. Но могу например сказать, что до 4го фреймворка дефолтовое значение параметра maxConnections было равно 2. Сейчас все приведенные выше параметра по дефолту расчитываются исходя из количество ядер процессора. Таким образом статья актуальна)
Почему я привел пример с maxConnections? Просто я обычно работал с ASP.NET приложениями, которые выступали клиентам к множеству внешних удаленных сервисов.
>Следующий вопрос — тюнинг для каких целей?
Так почитайте раздел «предыстория». Если в кратце, то как я понимаю, автор статьи столкнулся с проблемой, когда при превышении какой то определенного числа пользователей, сервер становился неработоспособным. При этом загрузка CPU, памяти и других аппаратных ресурсов оставалась в норме.
Профлирование серверного когда не выявило проблем.
А вот например снятие Full User Dump с процесса w3wp показало, что нет свободных хенделеров для обработки всей очереди http реквестов, или например в дампе наблюдается большая очередь коннектов на внешний бекенд сервис. Это конечно я утрирую. Т.к. автор не указал точной причины, почему же все таки было принято решение менять настройки апп пула и asp.net приложения.
>cчетчик на загрузку CPU… ну узнали Вы, что он загружен. Что дальше? Я знал о том, что некоторый компонент системы (не обязательно CPU) нагружен еще до того, как начал оптимизацию.
Да любой профайлер Вам в помощь) Например dotTracePerfomance, Подключаетесь к процесс w3wp, проводите нагрузочное тестирование, и определяете, что грузит процессор. Интересует именно %UserTime, всякие сериализации, десериализации, вычисления и тп.
>Имхо, приведенная стратегия — это не оптимизация производительности, а бездумное перераспределение ресурсов.
Не согласен, очень часто бутылочным горлышком является именно maxConnections.
Здесь описано не бездумное перераспределение ресурсов, а тюнинг. Разработчики приложений сами должны оценить — подойдут ли им значения по умолчанию, которые рекомендует MS или использовать свои.
>Если начинаются «зависания», то начать, мне кажется, стоит с определения источника проблемы. Первый шаг — тот же IIS Failed Request Tracing, который разжевывает все этапы прохождения запросов и соответствующие тайминги. Активно применяется и для исследования проблем производительности.
В первую очередь стоит все таки обратить внимание на счетчики производительности, а не IIS Freb логи. Они вам например не покажут, что cpu загружен на 100%.
Небольшой апдейт. Когда готовил статью, т.е. еще на прошлой неделе, Application Insights можно было настраивать из старого стабильного портала теперь его мигрировали в новый портал. А сам процесс настройки стал даже проще.
После этого у вас появится представление как реализовывать CodedUI тесты на базе MS Test.
Там все довольно просто — записываете некоторую последовательность действий и проверок, а фреймворк сам генерирует код. Я рекомендую его использовать только в качестве примера, т.к. этот автосгенеренный код мягко говоря вообще не поддерживаемый.
Но на базе CodedUI фреймворка, можно писать вполне хорошие тесты. В идеале, разработчики UI интерфейса также должны согласовывать изменения своих компонент с разработчиками UI тестов — это обеспечит надежность самих тестов. К сожалению это не всегда выполнимо. Особенно в тех случаях когда тесты и код разрабатываются разными командами или компаниями. В результате, иногда, я знаю сам лично несколько примеров, стоимости поддержки UI автотестов может стать очень высокой и от них придется отказываться.
Кроме MsTest есть еще множетсво xUnit фреймворков. И все они очень похожи) Начните с моей любимой книги «Art of unit testing». Книга универсальная и читается очень легко). А по MsTest есть куча документации в msdn.
У нас строго типизированное публичное апи, которое и так фильтрует практически весь «мусор».
Специально ни каких Fuzzy фреймворков мы не используем, но всегда пишем отдельные тесты проверяющие корректную обработку «не правильных входных данных».
Опять же все зависит от системы.
Года 3 назад читал книгу, «Исследование уязвимостей методом грубой силы» (вроде такое название), так там приводили примеры уязвимостей системы, которая написана на C или каком то подобном языке- и что при определенных входных данных в системе возникало переполнение буфера, которое открывало злоумышленнику возможность исполнения произвольного кода.
в общем мое мнение- тесты на обработку некорректных данных, исключительных ситуаций (как минимум описанных в спецификации интерфейсов) должны быть включены в регресс.
Спецификация это очень общее понятие. Здесь все зависит от методологии. Стоимость исправления ошибок в спецификации (или в любой другой документации) велика по сравнение с банальными ошибками в коде.
По своему опыту могу сказать, что тестировщики, как минимум, должны критически относится к документации, а не принимать ее как есть.
Если мы говорим о спецификации интерфейсов (low level design), то следует проверять ее на соответствие бизнес спецификации и так далее. Есть даже такой отдельный вид тестирования как статическое, задача которого не только проверять качество кода, но и документацию.
Спасибо)
Посмотрю обязательно.
На самом деле я не вижу ничего сложного в написании парсера TRX файлов. Это же обычный XML с результатами тестов. Для простого отчета по результату прогона тестов действительно возможно достаточно любого парсера.
Но, TFS база, откуда мы вытаскиваем результаты тест кейсов хранит очень много полезной информации — в частности это история прогона (по этой истории можно предположительно понять какой именно чекин сломал тест). Также при необходимости туда можно записывать intelliTrace и другую отладочную информацию, которая иногда требуется для поиска проблемы.
Мы размещаем наши сервисы в Azure, потому что это удобно)
Относительно простой деплой сервисов, удобная инфраструктура для горизонтального масштабирования, встроенные средства диагностики и много-много всего)
На мой взгляд — это антипаттерн. Тесты должны быть простыми — подготовка данных, действие и проверка. Благодаря такому подходу — тесты станет гораздо проще поддерживать, да и поиск ошибок упростится — представьте — если падает тест, то можно сразу предположить в каком именно методе и при каких условиях возникает ошибка, а не разгребать тонну логов и стек трейсов.
Тесты иммитурующии работу троллей разбивайте на маленькие:)
И еще очень полезны практики код ревью тестах (как между тестировщиками, так и перекрестные ревью разработчик — тестировщик).
И автору привет) Только кто такой этот Саня, который «внедрил кошерную SOA-архитектуру, покрыл весь код тестами, а также наладил процесс Continuous Delivery.»?)
К сожалению я не смотрел приведенные ссылки. Но могу например сказать, что до 4го фреймворка дефолтовое значение параметра maxConnections было равно 2. Сейчас все приведенные выше параметра по дефолту расчитываются исходя из количество ядер процессора. Таким образом статья актуальна)
Почему я привел пример с maxConnections? Просто я обычно работал с ASP.NET приложениями, которые выступали клиентам к множеству внешних удаленных сервисов.
>Следующий вопрос — тюнинг для каких целей?
Так почитайте раздел «предыстория». Если в кратце, то как я понимаю, автор статьи столкнулся с проблемой, когда при превышении какой то определенного числа пользователей, сервер становился неработоспособным. При этом загрузка CPU, памяти и других аппаратных ресурсов оставалась в норме.
Профлирование серверного когда не выявило проблем.
А вот например снятие Full User Dump с процесса w3wp показало, что нет свободных хенделеров для обработки всей очереди http реквестов, или например в дампе наблюдается большая очередь коннектов на внешний бекенд сервис. Это конечно я утрирую. Т.к. автор не указал точной причины, почему же все таки было принято решение менять настройки апп пула и asp.net приложения.
>cчетчик на загрузку CPU… ну узнали Вы, что он загружен. Что дальше? Я знал о том, что некоторый компонент системы (не обязательно CPU) нагружен еще до того, как начал оптимизацию.
Да любой профайлер Вам в помощь) Например dotTracePerfomance, Подключаетесь к процесс w3wp, проводите нагрузочное тестирование, и определяете, что грузит процессор. Интересует именно %UserTime, всякие сериализации, десериализации, вычисления и тп.
Не согласен, очень часто бутылочным горлышком является именно maxConnections.
Здесь описано не бездумное перераспределение ресурсов, а тюнинг. Разработчики приложений сами должны оценить — подойдут ли им значения по умолчанию, которые рекомендует MS или использовать свои.
>Если начинаются «зависания», то начать, мне кажется, стоит с определения источника проблемы. Первый шаг — тот же IIS Failed Request Tracing, который разжевывает все этапы прохождения запросов и соответствующие тайминги. Активно применяется и для исследования проблем производительности.
В первую очередь стоит все таки обратить внимание на счетчики производительности, а не IIS Freb логи. Они вам например не покажут, что cpu загружен на 100%.
Если я прав, то вам надо прочитать:
habrahabr.ru/post/97012/
msdn.microsoft.com/en-us/library/dd286726.aspx
msdn.microsoft.com/en-us/library/dd286681(v=vs.100).aspx
После этого у вас появится представление как реализовывать CodedUI тесты на базе MS Test.
Там все довольно просто — записываете некоторую последовательность действий и проверок, а фреймворк сам генерирует код. Я рекомендую его использовать только в качестве примера, т.к. этот автосгенеренный код мягко говоря вообще не поддерживаемый.
Но на базе CodedUI фреймворка, можно писать вполне хорошие тесты. В идеале, разработчики UI интерфейса также должны согласовывать изменения своих компонент с разработчиками UI тестов — это обеспечит надежность самих тестов. К сожалению это не всегда выполнимо. Особенно в тех случаях когда тесты и код разрабатываются разными командами или компаниями. В результате, иногда, я знаю сам лично несколько примеров, стоимости поддержки UI автотестов может стать очень высокой и от них придется отказываться.
Специально ни каких Fuzzy фреймворков мы не используем, но всегда пишем отдельные тесты проверяющие корректную обработку «не правильных входных данных».
Опять же все зависит от системы.
Года 3 назад читал книгу, «Исследование уязвимостей методом грубой силы» (вроде такое название), так там приводили примеры уязвимостей системы, которая написана на C или каком то подобном языке- и что при определенных входных данных в системе возникало переполнение буфера, которое открывало злоумышленнику возможность исполнения произвольного кода.
в общем мое мнение- тесты на обработку некорректных данных, исключительных ситуаций (как минимум описанных в спецификации интерфейсов) должны быть включены в регресс.
По своему опыту могу сказать, что тестировщики, как минимум, должны критически относится к документации, а не принимать ее как есть.
Если мы говорим о спецификации интерфейсов (low level design), то следует проверять ее на соответствие бизнес спецификации и так далее. Есть даже такой отдельный вид тестирования как статическое, задача которого не только проверять качество кода, но и документацию.
Посмотрю обязательно.
На самом деле я не вижу ничего сложного в написании парсера TRX файлов. Это же обычный XML с результатами тестов. Для простого отчета по результату прогона тестов действительно возможно достаточно любого парсера.
Но, TFS база, откуда мы вытаскиваем результаты тест кейсов хранит очень много полезной информации — в частности это история прогона (по этой истории можно предположительно понять какой именно чекин сломал тест). Также при необходимости туда можно записывать intelliTrace и другую отладочную информацию, которая иногда требуется для поиска проблемы.
Относительно простой деплой сервисов, удобная инфраструктура для горизонтального масштабирования, встроенные средства диагностики и много-много всего)