Главная > Open Source, web2.0, веб-обзоры, Высокопроизводительная архитектура, Разное > Экзамен для веб-проекта — статья для журнала Хакер

Экзамен для веб-проекта — статья для журнала Хакер

12 января 2009

117Статья написана для журнала Хакер и опубликована в 117 номере (сентябрь, 2008). Журнальная версия доступна он-лайн на сайте журнала. Ниже представлена авторская версия, без сокращений (вызванных ограничением объема материала в печатной версии).

Какие тесты есть и какие вам нужны

Вы научились создавать сайты! Да, все эти мучения с изучением HTML, CSS и PHP (или, упаси бог, Perl) закончились и вы теперь создаете реальные веб-проекты и находятся люди (на удивление много!) которые готовы платить за это деньги. Но ведь все не так просто. Просто взять и создать сайт, написать все скрипты и связать с макетами страниц - этого уже недостаточно! Как минимум, от вас требуется проверить работу сайта в самых распространённых браузера и добиться одинакового отображения в каждом из них (поверьте, только одно это доставит вам немало хлопот и бессонных ночей). В процессе работы вы неоднократно захотите проверить, как же загружаются все элементы страницы, как они взаимодействуют и вообще, что это за квадратик воон там, в углу? А самый требовательный заказчик захочет знать, выдержит ли его сайт одновременное нашествие сотен или даже тысяч посетителей, или, если это модное веб-приложение, то захочет проверить, все ли кнопки нажимаются и правильно ли сайт на них реагирует (в зависимости от введённых пользователем данных, а он то может ввести такое...). А вы готовы к этому? Не бойтесь, если что - этот материал вам поможет быстро и легко разобраться в этой хитрой задаче тестирования веб-сайтов.

Сначала давайте разберемся, о каком тестировании будет идти речь. Если вы опытный программист, то при слове "тесты" сразу вспомните различные виды UnitTest или тестирования кода, когда вы вместе с каким-либо алгоритмом сразу пишете для него специальные тесты, всесторонне проверяющие как же работает ваш великий код. Такая известная практика или парадигма проектирования, как "гибкая разработка" (Agile development) предлагает целый принцип создания программ - Test Driven Development (разработка через тестирование). Многие популярные фреймворки имеют в своём составе инструменты и код для быстрого создания таких тестов (юнит-тестов), однако сейчас мы поговорим о немного других тестах. Конечно, тестирование кода на этапе, когда вы увлечённо пишете очередной шедевр, нужная и полезная вещь, однако оставим это программистам, а сами поднимемся немного выше.
Для веб-сайтов мы выделим несколько видов тестирования, которые вы должны делать - или потому что так хочет заказчик, или даже для собственного интереса (а ведь ой как интересно узнать, что будет с вашим сайтом, если туда сразу придет сотня посетителей).

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


Тестирование дизайна и общей работы сайта в разных браузерах
.

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

  • Microsoft Internet Explorer (5.5, 6.0, 7.0) при этом стоит попробовать как на WinXP и Vista (с разными сервис-паками), так и на Windows 2000/2003/2008 (ну и что, что это серверная платформа, там тоже люди сидят и даже ходят по сайтам). Какое отношение к тестированию у сервис-пака? Очень даже прямое - большинство пользователей устанавливают его и дальше не меняют никаких настроек, поэтому их версия браузера будет отличаться от других, тех, кто регулярно его обновляет или кто поставил его самостоятельно.
  • Opera (разные версии, например, текущая стабильная, последняя ночная сборка и одна-две предыдущие версии). При этом учитывайте, что Opera кроссплатформенный браузер и вам стоит посмотреть, как ведет себя ваш сайт и в Opera на Linux-е, и на MacOS и, конечно же, на MS Windows. Ах да, желательно поставить себе на мобильный телефон Opera Mini (для обычных телефонов с Java) или Opera Mobile (для смартфонов) и просмотреть через него - сегодня многие пользователи хотят работать с интернетом прямо с телефона, при этом не ограничивать себя только wap-сайтами.
  • Mozilla Firefox. Следует протестировать как самую последнюю версию (3.0) так и все предыдущие (да-да, и 2.0 и 1.5 и даже, если уж серьезно подходить к делу, то 1.0). Не побрезгуйте и посмотрите текущие ночные сборки и, на момент написания статьи, 3.1 альфа-версию - ведь когда вы сдадите сайт клиенту и он проработает месяц-два, эта версия уже будет стабильной и рабочей. А нам незачем потом выслушивать недовольного клиента, что у него не работает сайт, верно? Учтите, что иногда даже небольшие обновления могут повлиять на отображения страниц, хоть и не критично, поэтому попробуйте поставить несколько апдейтов и посмотрите, не изменилось ли чего. Сложность тестирования в Firefox состоит в том, что к нему, как к никакому другому браузеру, есть сотни и тысячи плагинов и дополнений, которые часто затрагивают отображение страниц, так что если вы хотите быть крутым разработчиком веб-сайтов, посмотрите самые распространенные плагины, которые могут повлиять на то, как браузер показывает странички и поставьте их для проверки. Так как Firefox тоже кросс-платформенное приложение, его нужно поставить для основных операционных систем и тестировать на всех - в реальности, конечно же, достаточно четырёх (Win32 (XP и Vista), MacOS X и Linux по выбору). Учитывайте и разные проекты на основе движка Firefox (который Gecko) - хотя единство движка вроде как означает, что и страницы будут отображаться одинаково, на практике это не всегда так. Поэтому можно протестировать свой сайт и в Flock (социальный браузер, достаточно интересный проект), для MacOS нужно попробовать Camino, а также обратите внимание на K-Meleon для платформы Windows.
  • Safari - обязательно проверьте этот браузер, он родной для MacOS, но существует и версия для Windows.
  • Для платформы Linux можно попробовать Konqueror, хотя почти все браузеры, кроме, конечно, Internet Explorer, имеют и Linux-версии, поэтому многие пользователи используют для навигации в сети именно их, а не встроенный браузер (тем более, что далеко не все работают за KDE)


Много, правда? Но нужны ли вам обязательно все браузеры? Давайте немного подумаем. На самом деле, если вы делаете обычный веб-сайт, допустим, персональную страницу, сайт-визитку или небольшой контентный проект, вам достаточно проверить отображение в основных браузерах - IE 6/7, Firefox 1.5/2.0/3.0, Opera 9.5 и Safari 3. Более того, думаю, можно будет обойтись только версиями для Windows-a и Linux, а в некоторых случаях и только Windows. Хотя здесь есть нюансы - если вы делаете сайт по мобильной связи, приготовитесь тестировать во всех браузерах для мобильных устройств, если ваша страница посвящена тонкостям настройки Vim-а, конечно, следует тестировать на всех популярных браузерах под Linux (и даже в текстовом Linux). Более серьёзные проекты, рассчитанные на широкую аудиторию, конечно же требуют более развёрнутой проверки и вам придётся устанавливать все эти десятки браузеров. Кстати, думаю вы догадались использовать виртуальные машины для того, чтобы использовать только один компьютер для проверки? Возьмите, к примеру, открытую систему VirtualBox (она достаточно простая, небольшая по размеру, стабильная и поддерживает большой список ОС), создайте несколько виртуальных машин, выделив им минимум ресурсов - нам же достаточно только установить там браузер, никаких ресурсоёмких приложений. Некоторые сложности возникнут только с проверкой под MacOS X и, честно говоря, автор сам еще не нашёл достаточно удобного и простого решения этой проблемы. Хорошо хоть Safari есть под Windows.

1ietestertools
Но существуют и программные средства, облегчающие задачи установки различных браузеров и проверки в них сайтов. В основном, самые большие сложности возникают при попытке установить на одной системе сразу несколько браузеров Internet Explorer параллельно - он очень сильно внедряется в систему и поставить еще один браузер будет очень проблематично. Вам поможет утилита IETester Tools. Это самостоятельный пакет, в котором вам предложат проверить свой сайт сразу в нескольких версиях IE - 5.5, 6.0, 7.0 и даже в бета-версии IE 8. Представляете, насколько удобнее загрузить всего один пакет размером около 25 Мб и установить его как обычную программу вместо часовой возни с настройкой разных браузеров или, что еще сложнее, развёртыванием пары-тройки виртуальных машин! Для запуска IETester ваш необходимо только система WinXP или Vista с установленным IE 7 (более ранние версии содержат некоторые баги) и все - через несколько минут вы можете лицезреть ваш сайт сразу в основных браузерах из прошлого, настоящего и даже будущего, просто переключаясь между вкладками. Вот чего бы хотелось, если уж на то пошло, то точно такого же пакета, но включающего в себя все браузеры, которые существуют для Windows, а также какое-то дополнение, например, автоматическая запись скриншотов и утилита их сравнения (иначе вас ждёт увлекательный квест в стиле "найди 10 отличий"). Как вы думаете, такой пакет существует? А может именно вы возьметесь за его создание? Уверен, множество веб-мастеров скажут вам огромнейшее спасибо...

2browsershots
...так же, как сказали спасибо за онлайновый сервис
http://browsershots.org. Поразительно простой и функциональный сервис, который позволяет сделать скриншоты сайта, адрес которого вы введете, в нескольких десятках браузеров (разных программ и разных версий) на трёх платформах (Linux, Windows, MacOS). При этом вы можете указать различные параметры, с которыми будет тестироваться сайт - глубина цвета (может быть важно для сайтов с фотографиями, галерей и тому подобных проектов), отключенным JavaScript или указать конкретную версию (пригодится для тестирования AJAX "штучёк"), а также использовать или нет плагины для Java и Flash. Для теста просто вводите адрес сайта, отмечаете желаемые браузеры (да, это проблема, там есть такие, о которых вы точно даже не слышали) и все - запрос отправляется в очередь, а вы будете перенаправлены на страницу ожидания, где и появятся скриншоты по мере готовности.

3browsershots_evulate

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

Тестирование и отладка сложных веб-проектов (AJAX приложений)

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

Ваш первый и самый главный инструмент - это, помимо, конечно же, лучшего браузера Mozilla Firefox, будет Firebug, специальный плагин для облегчения работы с любым веб-сайтом. Из всех плагинов для веб-разработчиков именно Firebug является самым мощным и развитым средством, а если к нему добавить несколько дополнительных планов (да-да, именно так - плагин также может содержать свои плагины, такая вот рекурсия) - он оставляет позади даже более специализированные инструменты и коммерческие решения! Хотя Firebug сможет оказать вам просто неоценимую помощь уже на стадии разработки вашего сайта, сейчас нам более интересно использовать его для исследования уже созданного и вроде даже работающего сайта.

5firebug_htmldebug
Для начала просто откройте ваш сайт в браузере и настройте Firebug так, чтобы он был включён для вашего сайта (по умолчанию расширение отключено, так как существенно замедляет работу в браузере, о чем даже Google Mail предупреждает). На первой вкладке Console перед вами откроется импровизированная консоль, где будут отслеживаться все запросы со страницы, выводится все предупреждения или ошибки, если такие были в процессе загрузки. Вы можете отслеживать как общую активность, так и более глубокие вещи - например, ошибки и предупреждения обработчика CSS-стилей (особенно будет ценно при работе с вёрсткой и подгонкой ее к разным браузерам), движка обработки JavaScript (теперь вы никогда не пропустите ситуации, когда какой-то из скриптов неправильно работает или даже просто подозрительно себя ведет), ошибки обработки XML-данных и даже ошибки расширений (это значит, что вы можете отлаживать таким способом даже очень сложные веб-приложения и даже расширения для Firefox). Другие вкладки предоставляют подробную информацию о каждом аспекте страницы:

  • HTML позволяет просмотреть полную структуру страницы, а также в режиме реального времени изменять вручную любой ее элемент, просматривать какие CSS-стили применяются к каждому элементу (то есть, если вас спросят - а чего вот этот заголовок такого сине-малинового цвета и смещен куда-то, вы сможете аргументировано показать, где именно и почему произошло наложение стилей в вёрстке и надавать по рукам нерадивому дизайнеру). Кнопка Inspect позволяет просто на странице указать мышью любой элемент, сразу разворачивая внизу его код, а также сразу его изменить и посмотреть результат.
  • CSS служит для гибкого управления стилями и позволяет мгновенно включать и отключать любой из них, сразу просматривая результат. Больше нет вопросов "а как же это сделано?", просто включите на любой странице плагин и исследуйте код!
  • Script - это самый настоящий отладчик для JavaScript, с точками останова, пошаговым отладчиком и даже подсветкой синтаксиса (при помощи плагина Rainbow).
  • DOM - список всех объектов, доступных на странице - это и объекты JavaScript, например, создаваемые популярными AJAX-библиотеками, так и доступные всем глобальные компоненты браузера. В основном, это вам нужно будет при непосредственно разработке сайта.
  • Net держит под контролем всю сетевую деятельность, показывая все запросы с вашей страницы, начиная от запросов CSS стилей, рисунков, заканчивая XMLHTTPRequest, который используется всеми AJAX-библиотеками. Можно просмотреть полный текст запроса, ответа сервера и все HTTP-заголовки. На этой вкладке для нас самое важное и интересное - это временная диаграмма загрузки, которая показывает, как именно и в какой последовательности браузер загружает все части страницы. Здесь кроется поистине неограниченное поле для оптимизации. Если заказчик жалуется на медленную загрузку сайта или "заторможенность" каких-то его частей, вполне возможно, что ответ будет на этой вкладке, достаточно загрузить сайт и проанализировать затрачиваемое на полную загрузку время.
  • Для подробной статистики использования Cookie вам необходим еще один плагин - Firecookie, который добавляет панель для расширенной работы с "печеньками".
  • Если вы хотите посмотреть, как работает ваш супер-современный AJAX-скрипт, и, собственно, что же там так безбожно тормозит, вам просто необходим плагин Jiffy. Он поможет визуально (а значит красиво и просто) посмотреть, сколько же времени уходит на отработку каждой вашей JS-функции и в какой последовательности они вызываются. Также это позволит вам разобраться во внутреннем устройстве любых AJAX-фреймворков и рассказывать потом друзьям за пивом, чего же там разработчики в jQuery "нагородили".
  • Еще один отличный плагин от Yahoo - YSlow покажет вам не только статистику загрузки, но и сделает часть вашей работы сам. Плагин проанализирует все данные о вашей странице и ее частях, посмотрит, как она загружается и выдаст список рекомендаций, составленных разработчиками поискового гиганта, как же вы можете улучшить свой сайт. При этом советы достаточно толковые и чёткие, поэтому всегда советую прислушиваться к ним. А чтобы развеять все ваши сомнения (и чего там эти яховцы понимают то), даже составит красочную диаграмму, демонстрирующую текущее состояние и то идеальное, насколько можно ваше творение оптимизировать (в плане объем загружаемых данных и количества запросов, часто разница составляет десятки раз и это не предел ещё).

6firebug_jiffyС этими инструментами вы сможете разобрать "по косточкам" любой скрипт и любой сайт или AJAX-приложение, какое бы оно сложное не было. Но, как и с тестированием в разных браузерах, и здесь, как ни странно, тоже есть великолепный он-лайновый инструмент. Созданный нашими разработчиками сервис Webo.in (http://webo.in) позволяет совершенно бесплатно всесторонне проверить ваш сайт и даст дельные советы по его оптимизации (и да, на русском языке!)

8weboin_loads

Самое интересное или DDOS своими руками


Самым интересным видом тестирования будет такой себе "ручной DDOS", а по научному "нагрузочное тестирование". Грубо говоря, мы с помощью специальных программ имитируем заход (и даже выполнения каких-либо действий) нескольких посетителей, а в конце теста смотрим на результат. Система тестирования подсчитывает какое время отклика для каждого такого "виртуала", произошли ли какие-то ошибки, а также сразу покажет сколько запросов в секунду может вытянуть ваша система. Следует заметить, что таким тестом мы проверяем не только сам по себе сайт, но и всю связку - оборудование, операционную систему, веб-сервер и сервер базы данных, всё в месте. И это единственный тест, где нам необходим достаточно мощный компьютер даже для запуска самой программы тестирования, при этом, конечно, очень желательно, чтобы сам сайт находился на другой машине, а в идеале - тестируется уже конечное место обитания проекта, хотя не все хостинг-провайдеры на такое согласятся, поэтому лучше лишний раз не рисковать (вдруг действительно, решат что атака на них).

91sloppy

Сначала лучше всего проверить, как будет выглядеть ваш сайт, когда реальные пользователи будут подключаться с разной скоростью. Ведь если вы разрабатываете сайт и у вас канал на 100 Мбit, то вы даже не заметите, что набрав адрес, что-то еще происходит - ввжик и все. А вот где-то в другом месте еще остались за счастье и 64 - 128 Кб каналы. Конечно, для самой обычной страницы с парой абзацев текста и рисунком скорость не является ключевым значением, но вот уже для сложных систем, веб-приложений или порталов разница будет заметная. Посетителю не хочется ждать, он скорее уйдёт с сайта, чем будет ожидать минуту или больше, пока все загрузиться. Для сложных AJAX-приложений скорость может влиять на порядок загрузки файлов и часто определяет скорость реакции интерфейса. Так что, скрепя сердцем, нужно посмотреть, как будет работать сайт и на более медленных каналах. Для этого существует совершенно простая программка, прокси-сервер Sloopy (http://www.dallaway.com/sloppy/). Минимум настроек - запустили, указали сайт, выставили скорость (от 9.6 Кб до 512 Кб) и порт - и все, открываете свой сайт (адрес вида localhost:указанный порт) и наслаждаетесь (или идёте за пивом), процессом загрузки вашего детища на диал-апе или обычном DSL-соединении.

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

Как и все уважающие себя люди, мы будем использовать открытое ПО для этой цели. Нет, конечно есть и другие программы, даже бесплатные, а есть и очень дорогие тестовые комплексы, о нескольких самых простых но мощных, мы коротко расскажем во врезке, но для всех повседневных задач тестирования нам вполне хватит и открытого проекта, разрабатываемого под эгидой Apache Fundation - Apache JMeter (http://jakarta.apache.org/jmeter/). Поверьте, в ней столько еще возможностей, что хватит на все проекты, которые вы только сможете сделать.

10apache_jmeter_testplan1
JMeter - это универсальная платформа для тестирования любых веб-проектов, а также почти любых сетевых серверов или сервисов. С ее помощью можно сформировать запрос в любом формате, собрать всю информацию о его обработке, сетевых задержках, произвести анализ ответа сервера (например, HTTP-заголовков), а с полученной информацией можно производить обработку, к примеру, разобрать регулярным выражением или проверить на присутствие определенного текста. Все эти действия задаются специальным мастером, формируя таким образом план теста. Создавая группу потоков мы имитируем определенное количество пользователей, задавая различные задержки перед подключением следующего пользователя, а также гибко настраиваем все аспекты запросов (можно подставить cookie, необходимые параметры запроса и многое другое). Для любителей экспериментов есть развитые возможности программирования поведения тестовых запросов - доступны различные конструкции if/include/loop и многие другие. Чтобы много не рассказывать (а там есть о чём), скажу, что буквально на каждом этапе можно делать почти все, что угодно и как только придумаете обрабатывать запросы или ответы.

Кроме именно тестирования веб-проектов (то есть, HTTP-сервера), мы можем проверить работу под нагрузкой и TCP, FTP, SOAP/XML-RPC, JMS и LDAP, а также JDBC для теста баз данных.

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

Но хватит теории, давайте что-то нагрузим! Пусть у нас есть локальный веб-сервер, где есть простая страничка с формой. Для первого теста сойдет - мы посмотрим, как сервер справиться с нашествием большого количества желающих зарегистрироваться и воспользоваться вашим сайтом. Сейчас и тестовый сервер, и JMeter физически на одной машине, но для реальных тестов необходимо их разносить или даже кластеризировать - сам тестер создает очень большую нагрузку, а уж сервер еще больше. Только будьте осторожны - удаленный администратор узла, который вы захотите "протестировать" может быть совсем не в восторге от такого подарка.

11apache_jmeter_run_results_tree

Запустив JMeter мы создадим свой первый тестовый план. Для начала создайте группу потоков (Thread Group), где и нужно указать количество пользователей, количество повторов и задержку между их подключением, а также можно настроить планировщик, чтобы протестировать сайт, когда админа не будет на месте (но помните, что это может быть...чревато).

Мы не будем пока придумывать очень серьезное тестирование, поэтому просто создадим обычные HTTP GET запросы к указанной странице и посмотрим, как сервер с этим справиться. Для этого к нашей группе нужно добавить описание действий, которые делает наш виртуальный пользователь. Выберем Sampler->HTTP Request (обычный HTTP запрос) и заполним его параметры. Задаем IP или адрес тестируемого сайта, если нужно - порт, если нужно - кодировку запроса, а также путь (в нашем случае это и есть корневая страница сайта). Тип запроса будет обычный GET (но поддерживаются любые HTTP методы). Если нам необходимо передавать какие-то параметры, ниже мы можем добавить все необходимое. Не забудьте включить опцию "Retrive All Embedded resources from HTML" - мы же хотим проверить реальные действия браузера, поэтому нам нужно кроме запроса основной страницы загружать и все включенные в нее ресурсы, такие как изображения, CSS и JS файлы, в общем все, что загружает обычный посетитель. Остальные параметры пока можно игнорировать.

Теперь каждый из потоков (посетителей) в нашем тесте будет использовать это как шаблон и формировать свой запрос к сайту. Конечно, в будущем вы научитесь добавлять сюда дополнительные действия, к примеру, создавать уникальные параметры для каждого запроса, но сейчас это пока еще "высокая материя".

Но нам же еще нужно как то посмотреть результаты. Для этого к тестовому плану необходимо добавить обработчики результатов (Listener). Для оценки общей картины мы добавим Summary Report, а для детальной информации о ходе обработки каждого запроса - View Results Tree (конечно, это нужно только если у вас не так много запросов, иначе вы просто захлебнетесь в тысячах логов, поэтому если тестирование большое, лучше рассматривать общую картину, а детально рассматривать только ошибочные запросы и, для проверки, несколько случайных).

Вот и все, для начала работы стоит только сохранить конфигурацию нашего тестового плана и запустить его на выполнение через меню Run. Учитывайте, что тест может длится долго или даже очень долго, если вы задали большое количество пользователей, а также достаточно сильно нагружает компьютер (неважно, что у вас последний Core 2 Duo).

12apache_jmeter_run_results_graph

Процесс тестирования вы можете наблюдать в реальном времени, открыв Results Tree. Для каждого запроса отображаются детально все заголовки, которые посланы или полученные, данные о времени обработки и возникшие ошибки, а также полное текст ответа от сервера.

Если вы хотите еще более красиво и наглядно посмотреть результат или процесс в реальном времени - добавте Graph Results и диаграмма загрузки будет рисоваться просто перед вами, сидите, потягивайте пиво и радуйтесь жизни... Хотя для полной интерпретации результатов нужна серьезная подготовка, общие выводы вы сможете сделать почти сразу. Например, смотря на Summary Report вы сразу увидите примерное количество запросов страницы, что может выдержать ваш сервер. Допустим, это 100 запросов в минуту. А в вашем приложении кеширование есть? Попробуйте включить его и прогнать тест заново, уверен, результат вам понравиться. А дальше начинается кропотливая работа - меняем какие-о значения в настройках сервера или вашего приложения, оптимизируем его и, вместо "на глаз" заключения, что теперь "все летает", просто запускаем еще раз тест и смотрим на изменения значений. И если теперь в строке "Throughput" отчета будет не 100 а 150 или 240 - то это уже повод гордиться и рассказывать как вы круто заоптимизировали в полтора-два раза скорость сайта.

Врезка.

Для нагрузочного тестирования есть отличный коммерческий продукт – Webserver Stress Tool 7 http://www.paessler.com/webstress). Он позволяет тестировать только веб-приложения и содержит, в отличие от JMeter, встроенный прокси для имитации различной скорости доступа к сайту. Можно задавать различные User agents для виртуальных посетителей и раздельно настраивать загрузку изображений, стилей, внедренных флеш-объектов и апплетов, а также обрабатывать фреймы. Интерфейс – более наглядный и дружественный к пользователю. В результате теста формируется красивый отчет с диаграммами и графиками загрузки (в виде HTML-страницы или сразу Word-файла), отлично действующими на менеджеров заказчика. В остальном функциональность пакета идентична открытому JMeter

13webserver_stress_tools

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

  1. 12 января 2009 в 23:32 | #1

    На IE5.5 думаю можно без сомнений забить, см. например
    http://top.bigmir.net/report/4961/users
    IE 5, который идет с Win2k и то распространеннее, а 5.5 идет с Windows Me.

    Так что я бы заменил IE 5.5 на IE 8 🙂

  2. 12 января 2009 в 23:34 | #2

    Для тестирования в старых версиях Firefox и Opera хорошо подходят portable версии этих браузеров.

  3. Евгений
    13 января 2009 в 08:06 | #3

    интересная статья, спасибо.

    PS. IETester Tools ссылку поправьте, не туда ведет)

  4. 13 января 2009 в 11:45 | #4

    Нет никакой проблемы потестировать сайт в родном Сафари. Качаем виртуальную машину с уже установленным хаккинтошем, запускаем под ВМВаре и наслаждаемся. Ищите в торрентах.

    • 13 января 2009 в 12:05 | #5

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

  5. 20 января 2009 в 22:40 | #6

    Это очень простое решение. Ничего ставить не надо -распаковать и запустить. Все уже установлено.
    http://torrents.ru/forum/viewtopic.php?t=1249700
    Хотя конечно проблемы не на ТРУ (Интел) железе возможны. У меня работает стабильно.

  6. 22 января 2009 в 16:45 | #7

    Romashka — да, вы правы. Решение есть, спасибо!

Комментирование отключено.