Пройдя в очередной раз весь путь от выбора CMS до тестирования я задумался о том, что весь этот путь хорошо описан. Вот только найти внятную информацию о тестировании, без предложения спустить на него все деньги или не делать вообще — очень сложно. Надеюсь, моя статья побудит профессионалов в области тестирования исправить это положение и написать о тестировании. Особенно о тестировании в проекте, бюджет которого невелик.
Те Хабровчане, кто давно занимается разработкой сайтов возможно (я надеюсь) найдут мою статью довольно банальной и само собой разумеющейся. Но пользователи, которые делают только первые шаги смогут подчерпнуть для себя толику полезного.
Что мы получаем, проведя описанные ниже действия можно посмотреть здесь.
Сайт должен поддерживаться редакторами, которые узнали про существования компьютеров довольно недавно и даже интерфейс Word'а вызывает у них легкий шок. HTML, основы работы сайта, основы программирования и многое другое, что превращает работу в CMS из творчества и исследования в работу над сайтом при помощи инструмента — это не мой случай.
При этом сайт наполнен формами, кнопочками, javascript'ами, движущимися элементами и прочим-прочим.
Поэтому, система управления контентом должна быть максимально настраиваемой, но очень удобной для редактора.
Я перерыл огромное количество существующих бесплатных и некоторые платные CMS и не нашел ничего более подходящего в моем случае, чем Umbraco.
Платформа .NET, на которой написана Umbraco — это скорее фишка, чем сложность для меня.
Ошибки на сайте можно исправить, контент можно добавить, дизайн полностью изменить. Но вот если сайт не выдерживает предполагаемой нагрузки — то придется переделывать его полностью. Поэтому нагрузочное тестирование крайне важно при разработке сайта. Советую делать его не один раз и первые прогоны делать уже на этапе разработки прототипов.
WCAT — это бесплатно-распространяемая утилита компании Microsoft для проведения нагрузочного тестирования сайта.
Собственно, ключевым для меня было бесплатно и Microsoft. Microsoft — только из соображений, что сайт на MS-решениях.
Плюс, система (или утилита) очень хорошо описана Microsoft'ом и реально удобна.
На этапе прототипов тестирование можно проводить прямо на среде разработки. Но чем ближе запуск, тем больше хочется прогнать систему под нагрузкой на целевой системе. Что есть у нас целевая система: Виртуальный сервер у хостера с приличными параметрами. Все машины, с которых мы можем создавать нагрузку расположены в офисе. В принципе, слишком большой нагрузки на сайт не ожидается, поэтому для создания нагрузки можно использовать только одну машину. Подчеркиваю — тестируем не локальную, а удаленную систему.
WCAT позволяет очень легко и просто создавать нагрузку в стиле: разогрев, нагрузка, отходняк. Но мне очень хотелось получить графики работы системы в зависимости от созданной нагрузки.
И задачу обработки логов WCAT решаем написанием небольшой утилиты для обработки логов.
Качаем:
WCAT
CPAU — утилита типа runas, но с возможностью передать пароль в командной строке.
Создаем файлы settings.ubr и umbraco.ubr (названия не принципиальны) по образу и подобию вложенных в папку WCAT\samples.
В файле umbraco.ubr есть перечисление запросов, которые должен сделать тестовый клиент. Лично я поступил просто. Перезапустил IIS, побродил по сайту, имитируя пользователя, затем просто перенес запросы из лога в файл, добавив необходимое окружение. WCAT очень серьезная утилита и позволяет настроить все необходимые аутентификации и дополнительные параметры для запроса. Как это сделать очень подробно разобрано в документации. Но в моем случае все просто и банально. Запросы без аутентификации и почти везде 200 OK в ответ.
Мы уже готовы, написав команду типа:
wcctl.exe -t umbraco.ubr -f settings.ubr -v 10 -s www.example.com -p 80 -c 1 -o report.xml -r report.xsl -x
а потом команду
wcclient.exe
и начать тестирование. Но я же хотел протестировать поведение системы под разной нагрузкой.
В дополнение, нас ждет большая засада. Мы не сможем подключиться к счетчикам целевой системы (через WMI) и сможем увидеть только время отклика, не представляя, что творится внутри.
Поэтому дальше начинается вудуизм.
Создаем пару bat-файлов.
1) test.bat
2) rem_test.bat
Первый файл понятен и примитивен.
О втором подробнее:
Мы подключаемся к целевой машине с правами ее пользователя, но на своей остаемся с правами локального пользователя. При помощи runas такой запуск проходит с ключиком /netonly.
ping' и нужны для задержки — сначала ждем пока ядро стартует, а потом пока выгрузится.
Немного лирики: кстати, при помощи runas можно заставить Windows Home работать в домене с правами доменного пользователя. Достаточно погасить explorer и запустить его командой runas с пользователем домена и ключом /netonly.
Итак, запускаем rem_test.bat и получаем кучу файлов типа report11.xml. Их можно открыть и просмотреть (не забудьте report.xsl из папки WCAT переложить к report'ам)
Но нам нужны графики. В этой куче файлов мы будем разбираться очень долго.
Что же делать?
Все очень просто.
Качать Microsoft Visual C# Express Edition и писать простую утилиту.
Пожалуй, не буду сюда включать ее код. Кто хочет — может скачать проект, а также все описанные мной файлы — здесь.
Таким образом, затраты на проведение тестирования составили 1 день для настройки, конфигурирования и проведения тестирования и ни копейки больше.
Я все еще надеюсь найти разработчиков и прекратить разрабатывать самостоятельно, тем более что это не входит в перечень моих текущих интересов. Если Вы хорошо знаете Umbraco и хотите применить знания на свое и не только благо — напишите мне в личку или на dima(at)kurilo.su.
P.S. Пока писал пост, думал, что получу комментарии типа: «судя по графику, ты тестировал пропускную способность канала твоего провайдера в офисе» или «так тестировать нельзя, для нагрузочных тестов надо делать отдельный стенд». Но получил ряд комментариев о том, что есть утилиты проще, узнал мнение профессионального тестировщика (судя по сайту) о том, что лучше заплатить денег буржуйской конторе (я не спорю, что лучше и, наверное позже воспользуюсь советом). И кучку минусов без объяснения.
Видимо, тема тестирования сайта в непромышленных условиях неактуальна. Судя по тенденции, все работают с высоко-нагруженными системами, no-SQL базами и прочими функциональными языками. Приму к сведению.
Те Хабровчане, кто давно занимается разработкой сайтов возможно (я надеюсь) найдут мою статью довольно банальной и само собой разумеющейся. Но пользователи, которые делают только первые шаги смогут подчерпнуть для себя толику полезного.
Что мы получаем, проведя описанные ниже действия можно посмотреть здесь.
Пара слов о CMS
Сайт должен поддерживаться редакторами, которые узнали про существования компьютеров довольно недавно и даже интерфейс Word'а вызывает у них легкий шок. HTML, основы работы сайта, основы программирования и многое другое, что превращает работу в CMS из творчества и исследования в работу над сайтом при помощи инструмента — это не мой случай.
При этом сайт наполнен формами, кнопочками, javascript'ами, движущимися элементами и прочим-прочим.
Поэтому, система управления контентом должна быть максимально настраиваемой, но очень удобной для редактора.
Я перерыл огромное количество существующих бесплатных и некоторые платные CMS и не нашел ничего более подходящего в моем случае, чем Umbraco.
Платформа .NET, на которой написана Umbraco — это скорее фишка, чем сложность для меня.
Нагрузочное тестирование
Ошибки на сайте можно исправить, контент можно добавить, дизайн полностью изменить. Но вот если сайт не выдерживает предполагаемой нагрузки — то придется переделывать его полностью. Поэтому нагрузочное тестирование крайне важно при разработке сайта. Советую делать его не один раз и первые прогоны делать уже на этапе разработки прототипов.
Почему WCAT
WCAT — это бесплатно-распространяемая утилита компании Microsoft для проведения нагрузочного тестирования сайта.
Собственно, ключевым для меня было бесплатно и Microsoft. Microsoft — только из соображений, что сайт на MS-решениях.
Плюс, система (или утилита) очень хорошо описана Microsoft'ом и реально удобна.
Конфигурация тестируемой системы
На этапе прототипов тестирование можно проводить прямо на среде разработки. Но чем ближе запуск, тем больше хочется прогнать систему под нагрузкой на целевой системе. Что есть у нас целевая система: Виртуальный сервер у хостера с приличными параметрами. Все машины, с которых мы можем создавать нагрузку расположены в офисе. В принципе, слишком большой нагрузки на сайт не ожидается, поэтому для создания нагрузки можно использовать только одну машину. Подчеркиваю — тестируем не локальную, а удаленную систему.
Как тестируем
WCAT позволяет очень легко и просто создавать нагрузку в стиле: разогрев, нагрузка, отходняк. Но мне очень хотелось получить графики работы системы в зависимости от созданной нагрузки.
И задачу обработки логов WCAT решаем написанием небольшой утилиты для обработки логов.
Тестирование
Подготовка
Качаем:
WCAT
CPAU — утилита типа runas, но с возможностью передать пароль в командной строке.
Создаем файлы settings.ubr и umbraco.ubr (названия не принципиальны) по образу и подобию вложенных в папку WCAT\samples.
В файле umbraco.ubr есть перечисление запросов, которые должен сделать тестовый клиент. Лично я поступил просто. Перезапустил IIS, побродил по сайту, имитируя пользователя, затем просто перенес запросы из лога в файл, добавив необходимое окружение. WCAT очень серьезная утилита и позволяет настроить все необходимые аутентификации и дополнительные параметры для запроса. Как это сделать очень подробно разобрано в документации. Но в моем случае все просто и банально. Запросы без аутентификации и почти везде 200 OK в ответ.
Мы уже готовы, написав команду типа:
wcctl.exe -t umbraco.ubr -f settings.ubr -v 10 -s www.example.com -p 80 -c 1 -o report.xml -r report.xsl -x
а потом команду
wcclient.exe
и начать тестирование. Но я же хотел протестировать поведение системы под разной нагрузкой.
В дополнение, нас ждет большая засада. Мы не сможем подключиться к счетчикам целевой системы (через WMI) и сможем увидеть только время отклика, не представляя, что творится внутри.
Поэтому дальше начинается вудуизм.
Создаем пару bat-файлов.
1) test.bat
@echo OFF
cd рабочая папка
wcctl.exe -t umbraco.ubr -f settings.ubr -v %1 -s www.example.com -p 80 -c 1 -o report%1.xml -r report.xsl -x2) rem_test.bat
@echo OFF
net use \\IP-адрес\ipc$ /user:имя целевой машины\administrator "пароль"
for /L %%c in (1, 10, 301) DO (
ping 127.0.0.1 -n 60 > NUL
cpau -u имя целевой машины\administrator -p "пароль" -ex "test.bat %%c"
ping 127.0.0.1 -n 60 > NUL
wcclient.exe
)
net use /DELETE \\IP-адрес\ipc$Первый файл понятен и примитивен.
О втором подробнее:
Мы подключаемся к целевой машине с правами ее пользователя, но на своей остаемся с правами локального пользователя. При помощи runas такой запуск проходит с ключиком /netonly.
ping' и нужны для задержки — сначала ждем пока ядро стартует, а потом пока выгрузится.
Немного лирики: кстати, при помощи runas можно заставить Windows Home работать в домене с правами доменного пользователя. Достаточно погасить explorer и запустить его командой runas с пользователем домена и ключом /netonly.
Тестирование
Итак, запускаем rem_test.bat и получаем кучу файлов типа report11.xml. Их можно открыть и просмотреть (не забудьте report.xsl из папки WCAT переложить к report'ам)
Но нам нужны графики. В этой куче файлов мы будем разбираться очень долго.
Что же делать?
Все очень просто.
Качать Microsoft Visual C# Express Edition и писать простую утилиту.
Пожалуй, не буду сюда включать ее код. Кто хочет — может скачать проект, а также все описанные мной файлы — здесь.
Заключение
Таким образом, затраты на проведение тестирования составили 1 день для настройки, конфигурирования и проведения тестирования и ни копейки больше.
Я все еще надеюсь найти разработчиков и прекратить разрабатывать самостоятельно, тем более что это не входит в перечень моих текущих интересов. Если Вы хорошо знаете Umbraco и хотите применить знания на свое и не только благо — напишите мне в личку или на dima(at)kurilo.su.
P.S. Пока писал пост, думал, что получу комментарии типа: «судя по графику, ты тестировал пропускную способность канала твоего провайдера в офисе» или «так тестировать нельзя, для нагрузочных тестов надо делать отдельный стенд». Но получил ряд комментариев о том, что есть утилиты проще, узнал мнение профессионального тестировщика (судя по сайту) о том, что лучше заплатить денег буржуйской конторе (я не спорю, что лучше и, наверное позже воспользуюсь советом). И кучку минусов без объяснения.
Видимо, тема тестирования сайта в непромышленных условиях неактуальна. Судя по тенденции, все работают с высоко-нагруженными системами, no-SQL базами и прочими функциональными языками. Приму к сведению.
