В этой статье я хочу поделиться своим опытом создания инфраструктуры для интеграционного тестирования веб-приложения.
Приложение построено на платформе .
Net и состоит из приложения ASP.NET MVC и базы данных MSSQL. Цель интеграционного тестирования была сформулирована следующим образом: автоматизировать развертывание приложения и выполнение тестов пользовательского интерфейса, чтобы можно было быстро убедиться, что установленная версия приложения успешно выполняет все необходимые тестовые сценарии.
Другими словами, нам нужно быстро проверить, что будет, когда мы установим новую версию для заказчика и начнем с ней работать.
Поскольку результат этих тестов является показателем качества создаваемого приложения, мы всегда будем знать качество нашего приложения, а значит и ситуацию, в которой мы находимся.
Поскольку интеграционное тестирование позволит смоделировать действия пользователя, можно сказать, что оно позволит проверить факт успешного выполнения того или иного пункта технического задания.
Если создать тесты по каждому пункту ТЗ (мы получим программу и методику испытаний - PMI :) и автоматизировать их, то количество успешно пройденных тестов будет означать реальную информацию о том, на сколько процентов ТЗ выполнено.
.
В противном случае оценка состояния системы будет выглядеть так: - Ну, как наша система сегодня, словом? - Словом, тогда.
это работает. - А если в двух словах? — В двух словах, это не работает. Что следует проверить при таком тестировании: — Компиляция и ассемблирование приложения — Порядок установки или обновления приложения: — Установка новой или обновление существующей базы данных — Установка нового приложения ASP.NET. — Выполнение тестовых сценариев, в каждом из которых: — Система готовится к выполнению сценария.
Поскольку каждый сценарий имеет предварительные условия, необходимо подстроить систему под эти условия.
Например, если для сценария вам нужен пользователь в системе, создавший три заказа, вам нужно каким-то образом получить пользователя и его три заказа в базе данных.
— Тестовый скрипт выполняется посредством эмуляции действий пользователя в браузере.
— Система возвращается в состояние, которое было до выполнения скрипта, фактически в состояние сразу после установки приложения — Составление отчета о качестве выполнения заявки — Сборка установочного пакета, содержащего приложения известного качества.
Этот процесс показан на схеме ниже.
Хотелось бы обратить ваше внимание на то, что указанная схема позволяет воспроизвести на машине разработчика и на сервере продолжения интеграции те же действия, которые будут выполняться в производственной среде во время и после установки туда обновленного приложения.
Базовые конфигурации
Ниже описано, как следует развертывать конфигурации в различных средах для интеграционного тестирования и производственного использования.Хотелось бы сразу обратить ваше внимание на то, что взаимодействие с приложением происходит одинаково во всех средах.
Взаимодействие с приложением происходит через браузер, обновление базы данных осуществляется в виде выполнения скрипта обновления базы данных, а обновление приложения ASP.NET осуществляется посредством стандартного Deployment.
Конфигурация на машине разработчика
В конфигурации разработчика в качестве основного инструмента используется Visual Studio. В данной конфигурации предполагается, что СУБД будет использоваться на машине разработчика.
Я считаю, что этот вариант лучше, чем вариант, когда все разработчики используют одну общую базу данных.
С одной стороны, общую базу данных дешевле поддерживать, и у каждого разработчика всегда есть последняя версия базы данных.
Но с другой стороны, в таких базах данных легко можно получить нарушение целостности данных, например, можно ввести несколько неверных заказов, потому что разработчик забыл сделать какую-то проверку.
Конечно, позже он это проверит и больше неверных заказов в системе создаваться не будет. Но другой разработчик может продолжать отлаживать свой функционал по неверным заказам и допускать множество скрытых ошибок.
В случае с персональной базой данных задача создания целостных данных становится явной и проще решаемой.
Об этом написано ниже в разделе «Маленькие хитрости».
Перед проведением интеграционного теста разработчик должен восстановить рабочую базу данных с производственного сервера в СУБД интеграционного тестирования.
Конечно, получить рабочую базу с промышленного стенда нереально, но какая-то база, максимально приближенная к ней, все равно должна быть, чтобы корректно проверять процесс обновления базы.
Вариантом может быть обезличивание рабочей базы, то есть делается копия рабочей базы, а затем в ней меняются имена заказчиков и суммы контрактов, чтобы коммерческая информация не дошла до разработчиков и тестировщиков.
Первым этапом тестов будет проверка развертывания базы данных, то есть разработчик опубликует базу данных.
Для этого разработчик публикует проект базы данных в целевой базе данных.
Во время сборки проекта Visual Studio зайдет в целевую базу данных, сравнит ее со скриптами текущего проекта и создаст разностный скрипт, который будет выполнен.
Уже здесь могут возникнуть ошибки, например, забыли создать поле, на которое ссылается вторичный ключ, или произошел конфликт первичных ключей при вставке исходных данных.
Получается, что все эти ошибки разработчик обнаружит и исправит на этапе тестирования, а не на этапе внедрения, думаю, все знают, сколько нервов это экономит. Следующим шагом разработчик должен запустить тесты с помощью Visual Studio Test Runner. Интеграционные тесты при выполнении наполняют базу данных необходимыми для теста данными и тем самым удовлетворяют предварительным требованиям тестов, затем тест через Selenium RC Server вызывает браузер и имитирует действия пользователя.
Результат теста еще раз проверяется через браузер, а также можно получить данные из базы данных для сравнения с эталонными.
После запуска теста база данных возвращается в исходное состояние.
В результате после запуска тестов видно общее состояние системы.
Конфигурация на сервере Продолжает интеграцию
Здесь вместо Visual Studio используется сервер интеграции Continues, но все действия аналогичны тем, что на машине разработчика.
Промышленная конфигурация
В промышленной среде обновление устанавливается через установщик, который работает с промышленной средой так же, как и в интеграционных тестах.
Пользователи также работают с системой так же, как было проверено в тестах.
Никаких неприятных сюрпризов больше быть не должно.
Необходимые инструменты
Для создания необходимой инфраструктуры вам потребуются следующие инструменты: Решение Visual Studio, содержащее несколько проектов: - Проект базы данных SQL Server. Как известно, такой проект позволяет хранить все DDL и SQL-скрипты, необходимые для разработки структуры и исходного содержимого базы данных.Основным преимуществом этого проекта является то, что он может генерировать сценарий различия для обновления существующей базы данных до последней версии.
Это позволяет устанавливать обновления без удаления существующих данных.
Более того, эту операцию можно автоматизировать через MSBuild и выполнить на сервере Continues Integration. — Проект с приложением ASP.NET. Содержит само приложение.
Проект также используется для проверки развертывания веб-приложения на сервере, опять же автоматически с помощью MSBuild. — Проект, содержащий интеграционные тесты.
Это проект MSTest или NUnit. Этот проект будет использоваться для запуска тестов и создания отчета о тестировании.
Это минимальный набор проектов, который необходим для организации автоматизированного интеграционного тестирования.
Конечно, Решение хранится в системе контроля версий, такой как SVN. Кроме того, решение содержит пакет nuGet «Selenuim Remote Contol».
К сожалению, Selenim IDE не полностью поддерживает новый «Selenium WebDriver», поэтому экспорт тестовых сценариев из Selenim IDE в код C# возможен только для Remote Contol. В противном случае некоторые шаги не будут экспортированы в C# и их придется писать вручную, что заметно медленнее, чем экспорт из Selenim IDE. Для «Selenuim Remote Contol» вам понадобится Java-приложение «selenium-server-standalone-x.x.x.jar».
Для быстрой и удобной записи тестов вам понадобится FireFox с установленным дополнением Selenim IDE. Вам также понадобится сервер продолжения интеграции, чтобы постоянно получать последнюю версию из SVN и запускать тесты.
Настройка вашей среды
Я покажу вам, как устанавливать и настраивать описанные выше продукты на различных стендах.
проект базы данных
Начнем с проекта базы данных.Проект базы данных может иметь несколько файловPublish.xml, каждый из которых описывает, где и как будет опубликована база данных.
Поскольку база данных каждого разработчика находится по своему адресу, эти файлы необходимо удалить из системы контроля версий и настроить отдельно для каждого разработчика.
Чтобы опубликовать базу данных, вам нужно щелкнуть правой кнопкой мыши по этому файлу в Visual Studio и выбрать «Опубликовать».
Публикация аналогична развертыванию, за исключением того, что параметры развертывания хранятся в свойствах проекта, а параметры публикации — в файлеPublish.xml.
Чтобы опубликовать базу данных из командной строки, вам необходимо вызвать следующую команду:
> MSBuild /t:Publish /p:SqlPublishProfilePath="mypublishfile.publish.xml" DBProject.sqlproj
веб приложение
Приложение ASP.NET в Visual Studio можно запустить с помощью команды «Выполнить» или развернуть с помощью стандартных инструментов Visual Studio. На Continues Integration Server это также можно сделать разными способами, например, через xCopy. Я не буду на этом останавливаться более подробно, поскольку, с одной стороны, это достаточно большой материал, а с другой – его легко найти в Интернете.
Селеновый сервер
Вам также понадобится сервер Selenium RC, который можно скачать здесь: docs.seleniumhq.org/download Запускает сервер командой > java -jar c:\selenium\selenium-server.jar -multiwindow Когда сервер запущен, вы можете запускать тесты.
Тестовый проект с интеграционными тестами
Это может быть проект MSTest или проект NUnit. Для начала в него необходимо установить пакет nuGet Selenium.RC.
Как уже говорилось, в начале каждого теста вам необходимо запустить SQL-скрипт, который будет заполнять базу данных данными для теста.
Поскольку я часто работаю со скриптами, созданными в SQL Server Management Studio, то постоянно вижу в них команду «GO».
Для выполнения таких скриптов используется библиотека smo, это несколько сборок, которые можно установить в составе MSSQL Server SDK и найти их, например, в «C:\Program Files (x86)\Microsoft SQL Server\110».
\SDK\Assemblies», но надо учитывать, что они скомпилированы для .
Net 2.0 и просто заставить их работать в .
Net 4.0 и старше невозможно.
Поэтому тестовое приложение я обычно настраиваю для .
Net 3.5. После этого в тестовом проекте можно создать следующий вспомогательный класс:
Теги: #интеграционное тестирование #ASP.NET #Selenium #mssql #mssql #.public class TestDBHelper {
NET #ASP #ASP #tdd
-
Интерфейсы В Реальном Мире
19 Oct, 24 -
Запуск Apache Spark В Kubernetes
19 Oct, 24 -
Послевкусие От Котлина, Часть 1
19 Oct, 24 -
Даты Выхода Новых Версий Плеера Amarok
19 Oct, 24 -
Kotlin Для Android: Теперь Официально
19 Oct, 24
