Когда следует использовать Закодированные Тесты ИП вместо других типов тестов Visual Studio .NET

В этом руководстве мы будем рассматривать Закодированные тесты ИП, Модульные тесты, Веб-тесты производительности, Нагрузочные тесты и Ручные тесты с помощью Microsoft Test Manager. Мы рассмотрим сценарии, когда мы предпочли бы один тип теста другому и для каких сценариев. Прежде чем выбрать какой-то подход для использования как Закодированные тесты ИП, мы настоятельно рекомендуем сделать обоснование и оценку всех следующих методов

Модульные тесты

Модульный тест лучше всего подходит для тестирования наименьшей единицы исходного кода и включает в себя необходимые для этой цели функции, такие как возможность интегрироваться с Mocks/Stubs/Fakes. В этом случае разработчик должен иметь глубокие знания тестируемого кода и сильный навыки кодирования. Платформа модульного тестирования также хорошо работает для тестирования интеграции, в этом случае автор может иметь меньше понимания тестируемого кода, но сильные навыки кодирования все равно будут полезны. Кроме того, модульные тесты являются более предпочтительным методом для тестирования служб Windows Communication Foundation. Модульные тесты службы Windows Communication Foundation могут и должны использоваться как часть нагрузочного тестирования этих служб. Хотя тестирование веб-страниц с использованием модульных тестов, включая HostType и параметры UrlToTest, AspNetDevelopmentServerHost, возможно, но это не идеальный и не самый лучший способ проверки ответов страницы или тестирования пользовательского интерфейса.

Веб-тест производительности

Веб-тесты производительности работают на уровне протокола. Они предназначены для отправки запроса и получения ответов через HTTP, и поэтому этот тип теста подходит только для приложений, которые используют HTTP для взаимодействия между клиентом и сервером. HTTP-ответ является тем, что мы проверяем; Мы на самом деле не проверяем отображаемые страницы. Тут имеет важное значение понимать, как сегодня все больше и больше страниц строятся Генераторами HTML в серверной части и HTML изменяется в клиентской части. В веб-тесте производительности мы используем правила извлечения для динамического генерирования запросов и используем проверки в заголовках и на уровне содержимого ответов. Проверка ИП, созданного с помощью JavaScript, элементов управления ActiveX или плагина не возможно с помощью такой функциональности. Веб-тест производительности исключительно хорошо подходит для записи сценариев, используемых в нагрузочных тестах. Кроме того, они хороши для: Проверки пар ответов на запросы, тестирования времени отклика сервера, проверки генерирования HTML в серверной части, проверки кодов ответов HTTP и тестирования веб-служб ASMX. Обычно веб-тест производительности не используется для тестирования взаимодействия с пользователем, служб WCF и динамически генерируемого HTML. Вполне возможно построить очень мощный веб-тест производительности с небольшими или вообще без навыков кодирования, но навыки кодирования будут полезны для более сложных сценариев, а также является желательным твердое понимание регулярных выражений.

Закодированные тесты ИП

Мы собираемся рассмотреть четыре различных стиля закодированных тестов ИП. Первый будет называться как «Стандартные» закодированные тесты ИП. В этом методе будет использоваться одна карта ИП. Второй метод будет описан как закодированные тесты ИП с несколькими картами ИП. В этом методе мы отступим от стандартного теста в том, что команда будет создавать модули приложения и создавать карты ИП для каждого модуля. Последние два метода будут именоваться «Сначала Код» Закодированный тест ИП и Платформа «Расширенные Закодированные Тесты ИП» (CUITe).

Стандартные закодированные тесты ИП

В этом методе автор позволяет Visual studio полностью управлять картой ИП. С этой техникой автор предпочитает возможности Visual Studio для записи и генерирования кода вместо ручного кодирования и манипуляции кодом. Поскольку используется единая карта ИП, эта карта скоро станет большой и трудно поддерживаемой и поэтому в действительности подходит только для относительно простых приложений со зрелым и стабильным пользовательским интерфейсом. Кроме того, наличие одной карты ИП делает затруднительным использование несколькими людьми для изъятия на редактирование этого файла в одно и то же время, и поэтому этот метод лучше всего подходит для очень небольшой группы или еще лучше для одной команды. Этот метод может использоваться для тестирования любого приложения, описанного в матрице поддерживаемых платформ и требует меньше навыков кодирования, хотя на практике базовые навыки программирования потребуются для выполнения базового обслуживания тестов. Хотя можно использовать любой стиль закодированного теста ИП,  но в нагрузочном тесте это не практично, поскольку каждый виртуальный пользователь требует выделенного агента.

Закодированные тесты ИП с несколькими картами ИП

В этом методе автор создает контейнера для управления пользовательским интерфейсом, создавая карты пользовательского интерфейса в «модулях», где «модуль» может быть страница, форма, пользовательский элемент управления или другая логическая разбивка пользовательского интерфейса. Даже если автор берет под контроль карты ИП, он может позволить Visual studio управление большинством кодирования через генерацию кода. Несколько карт ИП поощряют повторное использование кода и являются благоприятной средой для команды, т.к. члены команды могут работать в различных областях приложения без необходимости извлечения и изменения тех же карт ИП. Использование нескольких карт пользовательского интерфейса делает этот метод наиболее подходящим для тестирования более сложного ИП, но этот метод занимает много времени и тоже подходит для зрелого ИП. Этот метод может использоваться для тестирования любого приложения, описанного в матрице поддерживаемых платформ и требует скромных навыков кодирования, чтобы собрать сгенерированный код и выполнять базовое обслуживание тестов. Хотя можно использовать любой стиль закодированного теста ИП,  но в нагрузочном тесте это не практично, поскольку каждый виртуальный пользователь требует выделенного агента.

«Сначала Код» Закодированные тесты ИП

В этом методе автор не использует карты ИП и поиск его соответствующего элемента управления – это скорее Поиск DOM, который используется для динамического поиска. Этот метод будет работать только с приложениями на основе браузера. Поиск DOM уровня для одного элемента управления будет более устойчивыми к изменениям, чем с помощью сгенерированного поиска элемента управления через карту ИП, поэтому этот метод может быть выполнен на ранних этапах жизни приложения, а также лучше подходит если ИП часто изменяется. Компромисс заключается в том, что поиск для каждого элемента управления, начиная с DOM, не будет выполнять также как в первых 2-ух методах поэтому, если тест производительности является важным, то вы не сможете использовать эту технику. Этот метод подходит для сложных веб-приложений и работает хорошо в больших командах, т.к. нет необходимости использовать общие карты ИП. Этот метод не имеет понятия редактора карт ИП и требует экспертных навыков кодирования для эффективного создания и поддержки надежных тестов. Хотя можно использовать любой стиль закодированного теста ИП,  но в нагрузочном тесте это не практично, поскольку каждый виртуальный пользователь требует выделенного агента.

Платформа CUITe (Расширенные Закодированные Тесты ИП)

В этом методе автор не использует карты пользовательского интерфейса, только разве что совсем другое хранилище для обеспечения поиска расположения элементов управления. Хранилище объектов может поддерживаться с использованием функции записи, но использование записи или даже репозитория не является необходимым. Этот метод будет работать только с приложениями на основе браузера и включает некоторую поддержку Silverlight. Резко снижается объем кода, необходимого для этой техникой, и следовательно существенно увеличивает эксплуатационную надежность. Этот метод подходит для более сложных веб-приложений, чем техника, один и два, потому что улучшены возможности поиска особенно для тестирование html-таблицы, но она будет не такой устойчивой, как метод Сначала Код, если вы используете возможности взаимодействия с элементами управления без создания класса ObjectRepository, который не рекомендуется авторами платформы. Эта техника будет хорошо работать в больших командах, т.к. нет необходимости для совместного использования одной карты ИП или репозитория. Этот метод требует экспертных навыков кодирования для эффективной разработки надежных тестов. Эта техника зависит от движка закодированных тестов ИП, поэтому можно ожидать некоторое запаздывания между выпуском новых версий Visual Studio и CUITe. Этот метод используется даже некоторыми группами внутри корпорации Майкрософт, но это до сих пор внешнее решение. Хотя можно использовать любой стиль закодированного теста ИП,  но в нагрузочном тесте это не практично, поскольку каждый виртуальный пользователь требует выделенного агента.

Ручные тесты с Microsoft Test Manager

Большинство людей понимают, что запись ручных тестов для приложений описанных в матрице поддерживаемых платформ и использование функции перемотки вперед это сладкая конфетка в Microsoft Test Manager, но и имеются более полезные функции для тестирования. Microsoft Test Manager отлично работает для выполнения тестирования свободным поиском (без сценария), создания тестовых скриптов из записи действий собранных в ходе тестирования. Все, что записывается в сценарий, может выполняться вручную с помощью Microsoft Tests Manager. Это включает в себя выполнение тестов, которые требуют физической манипуляции с устройством, такое как источник питания, или тестирование приложений сложных для написания сценариев. Польза от использования ручных тестов в Microsoft Tests Manager будет до тех пор, пока пользовательский интерфейс не является достаточно зрелым, чтобы перейти на закодированные тесты ИП. Ручные тесты будут полезны для любого теста, который не содержит пользовательский интерфейс.

Нагрузочный тест

Основной целью нагрузочного теста является моделирование действий множества пользователей, доступ к серверу или ферме серверов в одно и то же время. Используйте веб-тесты производительности в нагрузочном тесте для моделирования действий пользователей для открытия одновременных подключений к серверу и выполнения нескольких HTTP-запросов. Добавьте модульные тесты в нагрузочный тест для имитации нескольких пользователей или агентов для проверки службы Windows Communication Foundation или нагрузки сервера не на основе веб.