В этой статье я хочу показать каким образом можно быстро и практически бесплатно построить инфраструктуру автоматизированного тестирования вашего Web-приложения. В качестве объекта тестирования возьмем некоторое Web-приложение, которое может быть установлено на различные платформы, поддерживает несколько версий PHP, должно работать с использованием основных браузеров, может устанавливаться различными способами (через инсталлятор, путем подкладывания скриптов самого приложения и т.п.)

С целью максимально снизить стоимость организации и поддержки подобной инфраструктуры тестирования будут использоваться все возможные способы автоматизации: подготовка окружения, развертывание приложения, тестирование и сведение результатов в единый отчет. Хочется получить следующее: нажали одну кнопку (или вообще ничего не нажимали, а оно запустилось по расписанию) и через некоторое время получили отчеты о прохождении тестов на всех нужных окружениях и вариантах развертывания. Рассмотрим подробнее все шаги построения собственной тестовой лаборатории.

Подготовка окружений

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

VMWare предлагает бесплатный продукт для одновременного запуска нескольких виртуальных машин на тестовом сервере. Сами виртуальные машины можно создавать при помощи инструмента VMWare Converter. Теперь на тестовом сервере один раз настраиваем все возможные варианты окружений в которых будет тестироваться наше приложение, например, используем различные ОС, обеспечиваем тестирование через IE6 и IE7 (без необходимости деинсталлировать IE браузер, установленный по умолчанию).

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

Развертывание приложения

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

При помощи pstools мы организуем:

• копирование инсталлятора на виртуальную машину и установку приложения в тихом режиме
• копирования архива с приложением и его распаковку, в случае, если установка приложения допускает ручное развертывание
• копирование исходных кодов тестов и их компиляцию на виртуальной машине для тестирования приложения через браузеры IE6 и IE7
• копирование и установку дополнительного ПО, необходимого для работы приложения.

Все варианты сценариев развертывания содержатся в .bat файлах или исполняемых скриптах (jscript, vbscript).

Тестирование приложения

Для тестирования Web-приложения будем использовать связку NUnit и Watin, которые также распространяются бесплатно и реализуют отличную инфраструктуру для автоматизированного тестирования.

Запускаем исполняемый сценарий (например, .bat-файл), который забирает последнюю (или нужную) версию исходных кодов автотестов и выполняет их комплияцию в модуль, который затем может быть запущен на исполнение при помощи NUnit. Этот же сценарий подкладывает заранее подготовленный конфигурационный файл, в котором прописан адрес (или сетевое имя) виртуальной машины, на которой нужно выполнять тестирование.

Запускается тестирование, прокликивающее приложение.

Сведение результатов

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

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

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

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

Управление конфигурациями

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

Это действительно рабочий вариант организации сложной инфраструктуры тестирования, который используется в разработке DEVPROM и позволяет максимально снизить затраты на тестирование Web-приложения, а тестировщикам - максимально сконцентрироваться на логике автоматических тестов.

Подключение вашей инфраструктуры тестирования

Если вы не используете NUnit, как каркас для организации автоматического запуска тестов, то вы можете самостоятельно реализовать необходимую интеграцию DEVPROM с вашим инструментом тестирования. В разделе с документацией вы найдете описание DEVPROM API, которое можно использовать для создания отчетов по тестированию.

Пример реализации такой интеграции можно посмотреть в исходном коде плагина NUnit.TestReport.AddIn, который умещается на трех экранах монитора.

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

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

Итак, какие основные вещи следует иметь до и сделать во время деплоймента:

1. Максимально детальный план работ, расписанный по часам, минутам и исполнителям - это поможет реально оценить необходимое для деплоймента временное окно, а так же понимать, кто когда и что должен делать. Обязательным пунктом являются бакапы всего, что может сломаться в ходе обновления.
2. Такой же детальный план отката, на случай проблем - критически (!) важный пункт, который, из-за природного оптимизма, чаще всего никто не делает. Что соотвественно приводит к печальным последствиям, особенно если деплоймент идет в сильно сжатые сроки.
3. Дистрибутивы всех необходимых компонент, лицензионные ключи - чтобы не оказалось так, что в самый важный момент у нас нет какого-нибудь лицензионного ключа, а люди, у которых он есть, сейчас спят (так как ранее утро) или отдыхают с семьей на природе (потому что выходные).
4. Контактные мобильные (!) телефоны абсолютно всех людей, которые могут помочь или от которых что-либо может зависеть - это позволить максимально быстро решить любую проблему, если таковая возникнет (а она, как правило, обязательно возникнет).
5. Доступ (заранее проверенный) ко всем необходимым серверам, наличие всех необходимых прав - как думаете, сколько времени займет срочное получение доступа к какому-нибудь серверу в выходные, из России в США, через их сервис-деск?
6. Уведомление всех людей, которых может затронуть обновление - это необходимо сделать для того, чтобы они могли подготовиться к обновлению, а так же не проводили никакие работы с приложением во время его обновления.
7. Оценка влияния на другие сервисы - необходимо оценить влияние нашего обновления на зависимые сервисы - можем ли мы их остановить (не нарушит ли это работу других пользователей) и не являются ли эти сервисы зависимыми.
8. Проверка, что все остановленные на время деплоймента сервисы поднялись нормально (наши и другие сервисы) - обязательно проверить все сервисы, которые были остановлены, поднялись ли они после, например, перезапуска системы.
9. Смок тестирование - после окончания деплоймента необходимо убедиться, что обновленный компонент работоспособен, и что соседние сервисы так же работают нормально.

Кстати, например именно этот чеклист в свое время (несколько лет назад), сильно помог бы нам не завалить один из первых удаленных деплойментов на европейской фабрике заказчика. Тогда все закончилось в целом хорошо - нас только сильно наругали и заставили написать lessons learnt. И конвеер на фабрике тогда не остановился, и бизнес не начал терять деньги.

А ведь могло бы быть и по-другому..