Дымовое тестирование веб-приложения .NET - PullRequest
3 голосов
/ 16 апреля 2010

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

Текущая ситуация: разработчики пишут веб-сайт, операции разворачивают его. После развертывания разработчик Smoke проверяет его, чтобы убедиться, что развертывание прошло гладко.

Мне кажется, это неправильно, по сути, это означает, что для развертывания приложения требуется два человека; в нашем случае эти два человека находятся на противоположных сторонах планеты, и часовые пояса вступают в игру, вызывая хаос. Но факт остается фактом: разработчики знают, каков минимальный набор тестов и который может со временем меняться (особенно для части нашего приложения, посвященной веб-сервисам). Операции, при всем уважении к ним (и они сказали бы это сами), - это кнопки, которые нуждаются в наборе инструкций.

Ручное решение состоит в том, что мы документируем тестовые случаи, и операции следуют этому документу при каждом их развертывании. Это звучит больно, к тому же они могут развертывать разные версии в разных средах (в частности, UAT и Production), и для каждого из них может потребоваться разный набор инструкций.

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

Теперь разработчики лучше документируют инструкции для компьютеров, чем для людей, поэтому очевидно, что очевидным решением является использование комбинации nUnit (я знаю, что это не модульные тесты как таковые, но это встроенный -предназначен для запуска тестов) и либо API Watin, либо Selenium для выполнения очевидных шагов браузера, обращения к веб-службе и объяснения ребятам из Operations, как выполнять эти модульные тесты. Я могу сделать это; Я в основном уже сделал это.

Но разве было бы неплохо, если бы я мог еще упростить этот процесс?

На этом этапе сотрудники отдела операций и компьютер должны будут знать, какой набор тестов относится к какой версии приложения, и сообщить исполнителю nUnit, на какой базовый URL-адрес он должен указывать (например, www.example.com). = v3.2 или test.example.com = v3.3).

Разве не было бы лучше, если бы у самого бегуна был способ дать ему базовый URL-адрес и позволить ему загрузить, например, zip-файл, распаковать его и автоматически отредактировать файл конфигурации перед запуском любых тестовых приборов, которые он там обнаружил?

Есть ли приложение с открытым исходным кодом, которое бы это делало? Есть ли необходимость в одном? Есть ли решение, использующее что-то кроме nUnit, может быть, Fitnesse?

Для справки, я сначала смотрю на инструменты на основе .NET, потому что большинство разработчиков в первую очередь разработчики .NET, но мы не женаты на этом. Если существует такой инструмент, использующий другие языки для написания тестов, мы с радостью адаптируемся, если есть тестер, работающий в Windows.

Ответы [ 7 ]

2 голосов
/ 16 апреля 2010

В прошлом я использовал Selenium для проведения подобных тестов дыма для веб-развертываний. Вы можете написать набор тестовых сценариев, а затем запустить их на одном и том же сайте в разных средах.

2 голосов
/ 16 апреля 2010

Я работал разработчиком дымовых тестов для приложения asp.net. Мы использовали QuickTest Pro , автоматизация тестовых прогонов была сделана с Quality Center (он назывался Test Director.). Это включало написание сотен тестовых сценариев, которые автоматизируют веб-браузер, взаимодействующий с веб-приложением. Эти тесты, когда они использовались, проверяют сборку перед ее развертыванием на наших производственных серверах. Quality Center позволяет вам определить «пул» тестовых машин, чтобы вы могли запускать большой список тестовых скриптов многопоточным способом.

Более упрощенным тестом на дым является регистрация всех ошибок / исключений, которые выдает приложение, и запуск паука в системе. Это не даст очень «глубокое» покрытие кода, но тесты дыма не предназначены для глубокого покрытия кода. Эта регистрация ошибок должна быть отделена от производственного приложения для обработки ошибок по мере их появления. Ошибки всегда будут появляться, хотя трещины и, к сожалению, лучшие тестеры будут вашими пользователями.

1 голос
/ 22 августа 2012

Я также обдумал эту последовательность и предложил декларативный подход к развертыванию и проверке, см. Здесь мои мысли,

http://jimblogdog.blogspot.co.uk/2010/10/introducingdeclarative-deployment.html

Я также создал несколько плагинов для моего проекта с открытым исходным кодом Wolfpack, чтобы автоматизировать весь этот процесс. По сути, вы упаковываете свои «тесты дыма при развертывании» в пакет NuGet и публикуете его в своем личном фиде NuGet. Wolfpack автоматически обнаружит новую версию пакета и загрузит его вместе с пакетом NUnit.Runner NuGet и распакует все файлы. Затем он будет молча запускать ваши тесты с помощью консоли запуска NUnit и анализировать результаты в предупреждении, которое вы можете получить по электронной почте, рычать, подбирать и т.д.

http://wolfpack.codeplex.com/

http://wolfpackcontrib.codeplex.com/wikipage?title=NUnitDeploymentPublisher

0 голосов
/ 12 августа 2010

После того, как мы потратили много времени, пытаясь найти более простое решение, мы в конечном итоге научили команду ops использовать NUnit Gui Runner. Это оказалось проще, чем ожидалось, и работает нормально.

0 голосов
/ 17 апреля 2010

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

Вы можете написать скрипт powershell или приложение, которое будет загружать файл конфигурации из веб-службы или веб-приложения, передавая тестовый URL-адрес в качестве параметра. Серверы или приложение будут работать на компьютере с доступом к VCS, поэтому они могут вернуть содержимое файла. После получения сценарий или приложение могут инициировать тесты.

0 голосов
/ 16 апреля 2010

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

0 голосов
/ 16 апреля 2010

Как правило, ваших тестов nUnit достаточно, чтобы, если они все пройдут, база кода работала нормально. Если вы внедряете код с прохождением тестов nUnit и обнаруживаете сбой на веб-сайте, вам необходимо добавить дополнительный nUnit, который также не работает по той же причине. Затем, когда вы исправляете свой код так, что nUnit проходит, вы знаете, что исправили проблему, возникающую в развернутом коде. По этой причине большинство систем автоматической сборки могут быть настроены на автоматический запуск всех тестов nUnit, а затем «сбой» сборки в случае сбоя любого из тестов.

...