Сначала давай разберемся, о каком тестировании идет речь. Если ты опытный программист, то при слове «тестирование», вероятно, сразу вспоминаешь о популярном подходе программирования Test Driven Development (разработка через тестирование). Одновременно с кодом пишутся так называемые Unit-тесты, проверяющие, как этот самый код работает. Во многих популярных фреймворках сейчас по умолчанию включены инструменты для создания Unit-тестов, однако, сегодня мы их трогать не будем. Поговорим о тестировании уже существующего продукта. Условно процесс можно разделить на несколько этапов:
тестирование отображения в разных браузерах;
тестирование корректной работы и отладка AJAX, дизайна и процесса взаимодействия;
нагрузочное тестирование;
тестирование интерфейса (usability);
тестирование безопасности (pentest);

Разработка интерфейса – это тема для отдельного разговора, а о пен-тесте сайтов мы и так пишем каждый номер. Поэтому подробно остановимся на первых трех пунктах и инструментах, которые тебе пригодятся. Итак, поехали!
Тестирование дизайна и общей работы сайта в разных браузерах

Твоя задача – сделать так, чтобы во всех браузерах все элементы сайта отображались одинаково. Не зная внутренней кухни, легко подумать, что проблема ерундовая. На самом деле, это не так. Любой современный сайт сильно завязан на разных CSS-хаках и JS-скриптах, и так уж повелось, что разные браузеры парсят их по-разному. Опытные верстальщики имеют несколько приемов в запасе, и каждый из них проводит немало времени, открывая сайт под разными платформами. В принципе, достаточно ограничиться основными:
Microsoft Internet Explorer. Каждая из версий 5.5, 6.0, 7.0, – это, фактически, отдельный разговор.
Opera. Учти, что Opera – кроссплатформенный браузер и тебе стоит посмотреть, как ведет себя сайт под разными платформами. Многие пользователи балдеют от нового бразуера Opera Mini (для обычных телефонов с Java) или Opera Mobile (для смартфонов).
Mozilla Firefox. Браузер также кроссплатформенный, и у разных версий своя специфика обработки скриптов. Сейчас существуют несколько популярных проектов, построенных на движке Firefox – Gecko (например, Flock, K-Meleon, Camino), но единство движка отнюдь не обозначает, что страницы всегда будут отображаться одинаково.
Safari. Обязательно проверь этот браузер, родной для MacOS, но теперь и с версией для Винды.

Открывать страницу во всех этих браузерах – довольно кропотливая работа, однако, задачу можно упростить. Очень полезны виртуальные машины (например, на базе VMware Server), позволяющие быстро загрузить новую систему. Самые большие сложности возникают при попытке установить на одной системе несколько браузеров Internet Explorer параллельно – так как он очень сильно внедряется в систему и поставить еще один браузер проблематично. Тебе поможет утилита IETester (www.my-debugbar.com/wiki/IETester/HomePage). Это самостоятельный пакет, в котором можно проверить свой сайт сразу в нескольких версиях IE – 5.5, 6.0, 7.0 и даже в бета-версии IE 8. Представь, насколько удобнее загрузить всего один пакет размером около 25 Мб и установить его как обычную программу, вместо часовой возни с настройкой разных браузеров или, что еще сложнее, развертыванием двух-трех виртуальных машин! Через несколько минут после установки ты сможешь лицезреть сайт сразу в основных браузерах – из прошлого, настоящего и даже будущего, просто переключаясь между вкладками.

Правда, без ручной работы не обойтись. Чего бы хотелось по-настоящему – так это специального пакета, включающего средство для автоматической записи скриншотов на разных браузерах. А также средства для их быстрого сравнения (чтобы не играть в увлекательный квест в стиле «найди 10 отличий»). И такие пакеты есть! Например, для связки Internet Explore и Mozilla разработан специальный продукт Paessler Site Inspector (www.paessler.com/tools/psi), включающий в себя сразу два браузных движка IE и Gecko с мощными средствами для сравнения результатов их работы. К сожалению, в нем нет поддержки Opera и Safari, за которую многие бы сказали большое спасибо. А пока же мы будем всячески благодарить разработчиков замечательнейшего онлайн сервиса http://browsershots.org. В чем его смысл? Это очень простой инструмент, который создает скриншоты заданного сайта сразу в нескольких браузерах, причем разных версий и на разных платформах (Linux, Windows, MacOS). Ты сам указываешь нужные параметры, с которыми будет проходить тест – глубину цвета, разные версии JavaScript (пригодится для тестирования AJAX «штучек»), включаешь или выключаешь Java и поддержку Flash. Для проведения теста нужно ввести адрес сайта, выбрать из шести десятков нужные браузеры и отправить запрос в очередь. Через некоторое время на экране появится результат (все скриншоты можно скачать одним архивом). Кстати говоря, исходники сервиса распространяются совершенно бесплатно с отличной документацией, поэтому что-то похожее ты можешь замутить и сам.
Тестирование и отладка сложных веб-проектов и AJAX приложений

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

В первой вкладке Console перед вами откроется импровизированная консоль, где будут отслеживаться все запросы со страницы, выводиться все предупреждения или ошибки, если такие были в процессе загрузки. Ты можешь отслеживать как общую активность, так и вещи более глубокие. Например, ошибки обработчика CSS-стилей (особенно будет ценно при работе с версткой и подгонкой ее к разным браузерам), движка обработки JavaScript (теперь ты никогда не пропустишь ситуации, что какой-то из скриптов неправильно работает или просто подозрительно себя ведет), ошибки обработки XML-данных и даже ошибки расширений. Другие вкладки предоставляют подробную информацию о каждом аспекте страницы:
HTML показывает полную структуру страницы, а также, в режиме реального времени, позволяет изменять любой ее элемент, просматривать какие CSS-стили применяются к каждому элементу. То есть, если тебя спросят: а чего вот этот заголовок такого сине-малинового цвета и смещен куда-то, – ты сможешь аргументировано показать, где именно и почему произошло наложение стилей в верстке и надавать по рукам нерадивому дизайнеру. Кнопка Inspect позволяет указать мышью любой элемент на странице и, сразу разворачивая внизу его код, изменить и посмотреть результат.
CSS служит для гибкого управления стилями – можно мгновенно включить и отключить любой из них, моментально оценивая результат. Больше не будет вопросов – «а как же это сделать?». Просто включи на любой странице плагин и исследуй код.
Script – это самый настоящий отладчик для JavaScript, поддерживающий точки останова, пошаговый отладчик и даже подсветку синтаксиса (при помощи плагина Rainbow).
DOM – список всех объектов, доступных на странице: здесь и компоненты JavaScript, например, создаваемые популярными AJAX-библиотеками, и доступные всем глобальные объекты браузера. Эта вкладка более ценна во время непосредственной разработки сайта.
Net держит под контролем сетевую деятельность и показывает все запросы с вашей страницы, начиная от загрузок CSS-стилей и рисунков и заканчивая XMLHTTPRequest, который используется AJAX-библиотеками. Можно просмотреть полный текст запроса, ответ сервера и все HTTP-заголовки. На этой вкладке для нас интереснее всего временная диаграмма загрузки, которая показывает, как именно и в какой последовательности браузер загружает все части страницы. Тут кроется поистине неограниченное поле для оптимизации. Если заказчик жалуется на медленную загрузку сайта или «заторможенность» каких-то его частей, вполне возможно, что ответ найдется на вкладке Net. Достаточно загрузить сайт и проанализировать затрачиваемое на полную загрузку время.

Для подробной статистики использования Cookie тебе потребуется еще один плагин – Firecookie (www.softwareishard.com/blog/firecookie). Он добавляет панель для расширенной работы с «печеньками». Если хочешь посмотреть, как работает твой AJAX-скрипт, и, собственно, что же там так безбожно тормозит, тебе просто необходим плагин Jiffy (jiffypot.com). Он поможет визуально (а значит, красиво и просто) посмотреть, сколько времени уходит на отработку каждой JS-функции и в какой последовательности они вызываются. Также с ним можно разобраться во внутреннем устройстве любых AJAX-фреймворков и рассказывать потом друзьям за пивом, чего же там разработчики в jQuery «нагородили».

Еще один отличный плагин – YSlow (developer.yahoo.com/yslow) от Yahoo. Помимо того, что он сообщает статистику загрузки, он еще и попытается сделать за тебя часть работы. Сам проанализирует все данные о заданной странице и ее частях, посмотрит, как она загружается и выдаст список рекомендаций, как ты можешь оптимизировать ресурс. Советы достаточно толковые и четкие, поэтому рекомендую прислушиваться. Подобную функциональность предоставляет еще и онлайн сервис от наших разработчиков – Webo.in (http://webo.in). Совершенно бесплатно он всесторонне проверит сайт, после чего даст дельные советы по его оптимизации (и да, все на русском языке!).
Караул! Что с интернетом?

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

Любой раскрученный сайт подвергается огромным нагрузкам – регулярным и иногда пиковым, когда на сайт заходит максимальное количество пользователей. Поэтому одним из важнейших видов тестирования считается «DDoS-атака своими руками». Нагрузочное тестирование, как его правильно называть, дает понять, какой наплыв посетителей может выдержать сервер. Как это делается? А прямо в лоб! С помощью специальных программ мы будем имитировать заход (и выполнение определенных действий) некоторого количества посетителей, а по завершению теста – смотреть на результат. Система тестирования подсчитывает время отклика для каждого «виртуала», выясняет, произошли ли какие-нибудь ошибки, а также показывает – сколько же запросов в секунду может вытянуть твоя система. Подобным образом мы проверяем не только сам сайт, но и всю связку: оборудование, операционную систему, веб-сервер и СУБД. Естественно, для создания подобной нагрузки достаточная мощность нужна и на самом компьютере, откуда будут запускать программы тестирования. В качестве инструмента мы выберем открытое ПО, разрабатываемое под эгидой Apache Fundation – разработку Apache JMeter (http://jakarta.apache.org/jmeter/).

Проект JMeter – это универсальная платформа для тестирования почти любых сетевых серверов или сервисов. С ее помощью можно сформировать запрос в любом формате, собрать всю информацию об его обработке, сетевых задержках и произвести анализ ответа сервера (например, HTTP-заголовков). Полученный ответ сервера без труда можно разобрать регулярным выражением или же проверить на присутствие определенного текста. Программа работает в несколько потоков, и мы имитируем нужное нам количество пользователей. Любые действия задаются с помощью специального мастера, который в конце работы создает так называемый план тестирования. Регламентируются задержки перед подключением каждого следующего посетителя, а параметры запросов могут быть всячески настроены (к примеру, без проблем можно поставить cookie и задать нужные опции). Для любителей экспериментов есть развитые возможности программирования поведения тестовых запросов – доступны различные конструкции if/include/loop, таймеры и многое другое. Кроме тестирования веб-проектов (то есть, HTTP-сервера), доступно тестирование под нагрузкой и FTP-сервера, SOAP/XML-RPC сервисов, JMS и LDAP, а также тест баз данных JDBC. Результаты выводятся в виде подробного отчета о каждом запросе, предоставляется и итоговый, с общими результатами – количество успешных запросов, среднее время обработки, процент ошибок и тому подобное.

Но хватит теории, давайте что-то нагрузим! Возьмем локальный веб-сервер, где есть самая обычная страничка. Первый тест будет несложный: мы посмотрим, справится ли сервер с нашествием большого количества желающих. Сейчас и тестовый сервер, и JMeter физически на одной машине, хотя для реальных тестов их надо разносить или даже кластеризировать. Тестер создает очень большую нагрузку, а сервер – нагрузку еще больше. Учти: администратор узла, для которого ты хочешь устроить испытание, вероятнее всего, очень удивится и едва ли обрадуется. Итак, запускаем JMeter и создаем план для тестирования. Сначала задается группа потоков (Thread Group), где нужно указать количество пользователей, количество повторов, а также задержку между их подключением. Чтобы упростить задачу, мы обойдемся пока обычными GET-запросами к указанной HTTP-странице и посмотрим, как сервер с этим справится. Для этого к нашей группе нужно применить действие «Sampler -> HTTP Request» (обычный HTTP-запрос). Заполним его параметры: IP-адрес или имя тестируемого сайта, порт (в случае необходимости), кодировку запроса, а также путь (в нашем случае это и есть корневая страница сайта). Не забудь включить опцию «Retrive All Embedded resources from HTML». Мы же хотим проверить реальные действия браузера, поэтому нам нужно кроме запроса основной страницы загружать и все включенные в нее ресурсы: изображения, CSS- и JS-файлы. Словом, все, что загружает обычный посетитель.

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

План тестирования готов! Для начала работы осталось только сохранить конфигурацию нашего тестового плана и запустить его на выполнение через меню Run. Учти, если ты задашь большое количество пользователей, то тест будет длиться довольно долго и достаточно сильно нагрузит компьютер (неважно, что у тебя последний Core 2 Duo). Процесс тестирования отображается в реальном временем в Results Tree. Если хочешь больше визуализации, можешь добавить еще и Graph Results. Как оценивать результаты? Для полной интерпретации нужна серьезная подготовка, однако общие выводы можно сделать почти сразу. Например, смотря на Summary Report, ты сразу увидишь примерное количество запросов страницы, которое может выдержать твой сервер. Допустим, это 100 запросов в минуту. Теперь подумай, а есть ли в твоем приложении кэширование? Попробуй включить и прогнать тест заново – уверен, результат не заставит себя ждать. Затем начинается кропотливая работа: сюда входят изменение настроек сервера, оптимизация самого приложения, очередной запуск теста. Гордись, теперь вместо сомнительного заключения «на глаз», ты способен получить вполне конкретные данные.
ИНФО

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

WARNING

Нагрузочного тестирование чужого хостинга чревато последствиями! Администратор может подумать, что ты устраиваешь DDoS-атаку и предпринять меры (например, написать Abuse-жалобу твоему прову).

Источник