- отключена возможность кросс-доменной и кросс-документной связей;

- порядок атрибутов может отличаться от IE7, поэтому рекомендуется использовать обращение по имени

- нельзя присвоить неподдерживаемое значение в CSS

- GetElementById, теперь чувствителен к регистру букв (“Test” и “test” – для тего разные идентификаторы)

Дистрибутив: http://www.microsoft.com/rus/windows/internet-explorer/

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

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

Приёмочное тестирование (Acceptance testing) web-приложений с PHP

Введение

В этой статье я расскажу о приёмочном тестировании (также известного как – функциональное тестирование), кое-что большинство PHP программистов смогут использовать в своей повседненвной практике. Я уверен, что многие из нас хорошо знакомы с юнит тестированием (unit testing), и даже интеграционным тестированием (Integration Testing), где же эта «лишняя спица в колесе» появляется при тестировании веб-приложений при нашей растущей одержимости Web 2.0 и AJAX, и как она отличается от первых двух методов? Ниже я объясню это. Также я покажу, как сделать приёмочное испытание с использованием убийственного сочетания PHPUnit и Selenium.

Зачем нужны приёмочные испытания?

Приёмочные испытания позволяют определить работает ли приложение так, как ожидает клиент (тот, кто заказал приложение). Теперь о том, что это означает…

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

Главное отличие приёмочных тестов в том, что они довольно просты. Интеграционные тесты работают по аналогии с юнит тестами, но с целыми группами связанных классов. Акцент делается на концепции «группы». Мы не тестируем каждый класс в отдельности, как с юнит тестами, а тестируем группы классов, которые вместе создают желаемый результат. Интеграционные тесты, поэтому написаны для и пишутся самими программистами. С другой стороны, приёмочные тесты работают для всего приложения (без изоляции классов и компонентов), как правило, по отношению к интерфейсу пользователя (прим. в данном случае имеется ввиду не только графический интерфейс, но и любой другой реализованный в виде запросов и видимых ответов), не важно для браузеров или веб-служб. Они пишутся для обеспечения соответствия приложения целям определенных клиентом. По сути, клиент даже может отвечать за написание тестов!

Теперь мы знаем, что приёмочное тестирование является самостоятельной практикой, но зачем нам её использовать?

1. Она отражает ожидания клиента (а не для разработчиков!);
2. Она оценивает, когда функциональность значимая для клиента закончена (знание о том, когда нужно остановиться);
3. Она гарантирует быстрое определение будущего поведения, которое отличается от ожидаемого (регрессионное тестирование);
4. Как любой хороший набор тестов она поддерживает рефакторинг в том же порядке, как юнит и интеграционные тесты.

О пользовательских историях (User Stories) и приёмочных тестах

Для тех, кто практикует экстремальное программирование, приёмочные тесты обычно пишутся для того, чтобы установить, что соответствие “пользовательским историям” является полным и не отклоняется от них в течение разработки.

Пользовательские истории – это краткое описание заказчиком некоторых частей значимой функциональности приложения, то есть ожидаемое поведение, которое должны проверять при приёмочных тестах. В плане XP (eXtreme Programming) это заменяет традиционную зависимость от спецификации, которая описывает каждый шаг в развитии, за счет жесткости в исполнении, с более гибким подходом, где наборы пользовательских историй отслеживают текущие требования. Пользовательские истории ведутся с пониманием положения, что план любого релиза, основанного на них, может подвергаться частым изменениям.

Давайте кратко посмотрим на написание пользовательских историй.

Клиент может авторизоваться на сайте.

Как PHP разработчики некоторые из нас могут посчитать это тупым и очевидным требованием. Старайтесь не думать так. Для клиента это важная функция. Если предположить, что дальнейшие обсуждения с клиентом не вызовут никаких изменений в этой пользовательской истории, то мы можем написать приёмочные тесты еще до начала разработки. Этот процесс звучит похоже на юнит тестирование – сначала тесты, потом код (прим. На самом деле не совсем так и тут сказывается то, что автор больше работал в условиях XP или TDD, в условиях многомодульных проектов следование такому правилу себе дороже). Вы можете оценить успешность реализации, независимо от того, все ли предварительно написанные тесты успешно пройдены (в нашем случае для веб-интерфейса). Дальше, после обсуждения идей с программистами клиент написал следующие тесты.

1. Страница авторизации отображает форму для входа;
2. Отправка правильного сочетания идентификатора пользователя и пароля приводит к успешной авторизации;
3. Отправка недействительной пары логин – пароль, показать регистрационную форму с указанием ошибок;
4. Форма для логина всегда сопровождается гиперссылкой “Забыли логин или пароль?”.

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

Клиент может восстановить забытый логин и пароль

Если каждый из четырех тестов проходит, мы можем считать, что обе пользовательских истории реализованы. Кроме того, при приёмочных тестах это явный сигнал, что пора прекратить разработку для этой функциональности. Если только клиент не придёт с новыми идеями (или уточнением существующих) нет причин расходовать ресурсы на неё. Это сделано! Вперёд!

Итерации

В нашей команде, несущейся в авангарде экстремального программирования, мы также занимаемся привязыванием пользовательских историй к конкретным “Итерациям (Iterations)”. Итерация, в общем смысле, это определенный период разработки, к концу которого у нас должна быть полностью протестированная, рабочая (хотя и неполная) версия приложения, которая будет проходить все приёмочные тесты для всех пользовательских историй, привязанных к этой итерации. Я уверен, что многие из вас сталкивались с итерационной разработкой. Итерация, как правило, длится не более нескольких недель. Учитывая, что проект может длиться несколько месяцев в плане разработки будет множество итераций, и каждая новая планируется на основе предыдущей.
Возвращаясь к нашему примеру. Пользовательская история про авторизацию была записана в итерацию # 1. Уверенный, что пришло время для разработки, вы загружаете ваш любимый редактор и принимаетесь за воплощение идеи. Следующий шаг? Написать приёмочные тесты в виде автоматизированного тестирования там, где это возможно.

Подготовка к приёмочному тестированию

Требования:

• PHPUnit 3.0 http://www.phpunit.de
• Testing_Selenium http://pear.php.net/
• Java 5 (1.5.0) требуется для Selenium RC http://java.sun.com
• Selenium Remote Control (RC) http://openqa.org/

Многие PHP программисты стремятся использовать PHP библиотеки для написания приёмочных тестов, и это подход я использую здесь. В этой статье мы будем использовать PHPUnit, который с версии 3.0 содержит класс PHPUnit_Extensions_SeleniumTestCase, который может быть использован для определения приёмочных тестов и используется с Selenium Core при тестировании. Важно отметить, что эти тесты не являются юнит тестами. Да, PHPUnit это библиотеки для юнит тестирования, но они столь же эффективны для интеграционных и приёмочных тестов.

Руководство по использованию PHPUnit с Selenium можно почитать тут: http://www.phpunit.de/pocket_guide/3.1/en/selenium.html. Расширение PHPUnit для Selenium также потребует, установленного пакета PEAR Testing_Selenium. PHPUnit и Testing_Selenium могут быть взяты из PEAR (PHPUnit 3 доступен только через phpunit.de, руководство по установке тут http://www.phpunit.de/pocket_guide/3.1/).

Selenium это веб-приложение для приёмочного тестирования ( прим. не совсем верно. Selenium это всё-таки функциональное тестирование, но может быть использован и для приёмочного) веб-приложений, созданное ThoughtWorks. В него входит несколько пакетов приложений, включая Selenium Core, Selenium RC и Selenium IDE. Его цель состоит в том, чтобы запустить тесты в реальном браузере (со всеми тараканами и примочками!), используя Selenium Core для воспроизведения действия пользователя, их проверки и создания отчетов с результатами тестирования. Selenium Core написан на Javascript и содержит в себе “BrowserBot”. Selenium Remote Control – это дополнительный сервер, который потребуется для запуска тестов приведенных в этой статье. Он позволяет использовать любой язык программирования для взаимодействия с Selenium Core в браузере через посылку простых HTTP GET запросов на сервер RC. Все это звучит сложно, но работать с ним просто.

Обратите внимание, что прошло много времени с момента последнего релиза Selenium RC 0.9.0 (привет 2006 году),в этой статье я рекомендую использовать снапшот Selenium 0.9.2. Это необходимо, поскольку версия 0.9.0 не очень хорошо работает с последними версиями Firefox 2 и Internet Explorer 7 (прим. последние релизы Selenium RC и Core были сделаны в январе 2009 (буквально вчера), поэтому плясать с бубном не нужно, но нет гарантий, что тесты из этой статьи заработают). Из архива Selenium RC потребуется только один JAR файл с названием “selenium-server-standalone.jar”.

Базовая форма приёмочных тестов с применением PHPUnit и Selenium RC очень проста.

/** PHPUnit_Extensions_SeleniumTestCase */
require_once 'PHPUnit/Extensions/SeleniumTestCase.php';

class GoogleIndexTest extends PHPUnit_Extensions_SeleniumTestCase
{
protected function setUp()
{
/**
* ‘*firefox’ => Firefox 1 or 2
* ‘*iexplore’ => Internet Explorer (all)
* ‘*custom /path/to/browser/binary => Любые другие браузеры (включая Firefox в Linux)
* ‘*iehta’ => экспериментальный встроенный IE
* ‘*chrome’ => Экспериментальный профайл для Firefox (не браузер Chrome)
*/
$this->setBrowser(‘*firefox’);
$this->setBrowserUrl(‘http://www.google.ie/’); // сайт, который будем тестировать
}

public function testTitle()
{
$this->open(‘http://www.google.ie/’); // открыть дефолтную страницу
$this->assertTitleEquals(‘Google’); // проверить существует ли ожидаемый заголовок (title).
}
}

Метод SetUp ()используется для определения наших тестов, начнём тут с указания какой браузер использовать. Firefox – один из возможных вариантов. Если Selenium RC не содержит ссылка на ваш браузер вы можете использовать префикс “*custom” и путь до браузера. Функция setBrowserUrl () устанавливает основной URL для тестов. Обычно это главная (начальная) страница вашего приложения (например, index.php). Страница доступна для тестов, только когда она открыта (если это не очевидно). Поэтому тесты лучше начинать с открытия страницы с помощью функции open().

Selenium Core (Javascript BrowserBot) работает в окне браузера, что происходит достаточно просто понять после небольшой практики. Существует пять концепций, которые необходимо понять с самого начала:

1. Действия (Actions, Selenium Actions)
2. Accessors
3. Assertions
4. Локатор элементов (Element Locators)
5. Шаблоны (Patterns)

Действия просто все ожидаемые действия, которые могут манипулировать состоянием веб интерфейса. Действия включают в себя нажатие на ссылку, нажатие клавиш, позиционирование мыши (например, onmouseover) и так далее. Все, что пользователь может сделать, Selenium Actions могут сделать тоже. Многим действия может быть указано ожидать определенного состояния. Самым простым является суффикс “AndWait”, который можно прикрепить к действиям, например, clickAndWait(). Это указывает Selenium, что после нужно отправить запрос на веб сервер и дождаться ответа перед тем как продолжить. Из-за изворотливого характера Selenium RC я рекомендую вам избегать использования “WaitFor” (ужасно работает в версии 0.9 и снапшоте 0.9.2 (прим. в 1.0 вроде ничего так)) и использовать отдельный вызов “waitForPageToLoad()”, – мы рассмотрим это действие позже.

Accessors – отслеживание состояния. Они могут быть использованы для хранения значений в переменных для последующего использования или сравнения. Использование accessors может быть весьма полезно во многих случаях, но тут мы о них только упомянем.

Assertions так же, как и Accessors оценивают состояние. Но они также позволяют сравнить хранимое значение с ожидаемым. Есть два основных типа “assert (прим. упрощая – это жесткое сравнение – хоть тресни, а должно быть)” и “verify (проверить)”. В Selenium Core неравенство при assert приведет к окончанию теста, в то время как неравенство при сравнении приведет только к записи в лог.
Чтобы получить информативный результат теста, попробуйте использовать методы assert только при крайней необходимости, где неравенство или несоответствие делает продолжение теста бессмысленным.

NB: При тестировании AJAX веб-интерфейсов “WaitFor” методы чрезвычайно удобны для определения того, когда AJAX манипулирует с DOM, после чего вы можете использовать обычные verify / assert. Лучше всего в таких случаях функция waitForCondition(), которая использует Javascript выражения, делающие проверки, в цикле или в течение определенного времени.

Полный список возможных действий, Accessors и Assertions существующих в Selenium Core тут: http://www.openqa.org/selenium-core/reference.html. Список большой, так что при тестировании можно долго развлекаться.

Два последних понятия это локатор элементов и шаблоны. Локатор – это метода для поиска элементов HTML/XML для тестирования. Selenium Core поддерживает поиск с помощью идентификатора и имени элемента, выражений Javascript DOM, XPath, CSS селекторов, и текста ссылки.

Шаблоны это методы для определения текста для поиска. По умолчанию используется метод “glob” (например, «*»/«?»). Также можно использовать точный поиск (полное совпадение). Ну, и где бы мы были без “регулярного выражения”! Несколько примеров я приведу позже.

Реализация пользовательских историй (или – вот одна из подготовленных ранее)

Чтобы не уходить в сторону от темы, будем считать, что пользовательские истории уже реализованы в коде. Необходимо скачать и установить локальную копию. Код написан с использованием Zend Framework), и уже протестирован с PHPUnit и Slenium.
http://downloads.astrumfutura.org/devzone/Acceptance_Testing_Tutorial_Application.tar.bz2 (прим. файл доступен)

Для установки, просто импортируйте /INSTALL.sql в базу данных, скопируйте файл /src/config/config.ini.dist в /src/config.ini и поменяйте настройки под ваше окружение, тоже самое сделайте для /tests/TestConfiguration.php. В этом конфигурационном файле, вы можете изменить значение TESTS_SELENIUM_BROWSER на любой другой вариант (список выше в примере). Baseurl также должен быть изменен и указывать на наше приложение в /WWW каталоге.

Что еще? Предположим, что установка была в корень сайте: зайдите на http://localhost/www/. Вы можете запустить все тесты, которые мы напишем ниже, они расположены тут: http://localhost/tests/AllTests.php

Написание и проведение приёмочных испытаний

Приступим к делу. Я уверен, что достаточно теории на этот момент! Итак, какой был первый приёмочный тест поставленный клиентом?

1. Страница авторизации отображает форму для входа

Наша форма для авторизации находится по адресу “/login” главного файла приложения. Это тот самый URL который нужно открыть в Selenium Core. Во-вторых, наш тест должен проверять наличие регистрационной формы на странице. Мы уже (см. /src/default/views/scripts/login_index.phtml) обозначили форму для входа, и установили уникальный идентификатор “login-form”, по которому мы можем её найти. Также мы уже знаем (из того же шаблона), что должны существовать два поля с идентификаторами “identity” и “password”. Для расширения кругозора мы будем использовать разные шаблоны в локаторе элементов

/** PHPUnit_Extensions_SeleniumTestCase */
require_once 'PHPUnit/Extensions/SeleniumTestCase.php';

class LoginIndexTest extends PHPUnit_Extensions_SeleniumTestCase
{
protected function setUp()
{
$this->setBrowser(‘*firefox’); // или *iexplore для IE
$this->setBrowserUrl(‘http://localhost/’);
}

public function testLoginFormExists()
{
$this->open(‘http://localhost/login’);

$this->assertElementPresent(“id=login-form”);
$this->assertElementPresent(“dom=document.forms['login-form'].identity”);
$this->assertElementPresent(“dom=document.forms['login-form'].password”);
$this->assertElementPresent(“xpath=//form[@id='login-form']/input[@type='submit']“);
}
}

Если вы скачали готовое приложение, то уже, вероятно запускали этот тест. Полный тест файл находится в файле /tests/AcceptanceTests/UserLoginTest.php. Возможно, вы уже догадываетесь, что добавление браузера и URL напрямую в код приведет к постоянным изменениям – поэтому в этих тестах используется набор констант из файла /tests/TestConfiguration.php.dist.

В примере выше встречается функция assertElementPresent(). Это проверка на наличие определенных элементов HTML / XML. Аргументом является строка, где тип локатора указывается слева от знака равно, а аргумент справа. Я использовал три различных типа. ID проверяет существование элемента с ID равным “login-form”. Наличие двух полей ввода проверяется с помощью выражений Javascript DOM. Наличие кнопки проверяется с помощью XPath.

Достаточно ли этих тестов? Существует риск, что если мы будем делать тесты слишком конкретизированными, то потом потребуется много времени на их редактирование при изменении интерфейса. Тем не менее, кое что еще должно быть проверено. Например, совпадает ли максимальная длина поля (maxlength) с длиной поля VARCHAR в базе данных или превышает его?

$this->assertElementPresent("xpath=//input[@id='identity' and @maxlength='20']");
$this->assertElementPresent("xpath=//input[@id='password' and @maxlength='64']");


2. Отправка правильного сочетания идентификатора пользователя и пароля приводит к успешной авторизации.

Теперь мы добавим тест, который будет отправлять валидные данные пользователя и проверять появилось ли сообщение, определенное в темплейте (см. темлейт login_index.phtml)

public function testValidAuthentication()
{
$this->open('http://localhost/login');

// заполняем форму
$this->type(“dom=document.forms['login-form'].identity”, ‘Padraic’);
$this->type(“dom=document.forms['login-form'].password”, ‘KSkjduj$!hjj*927′);

// отправляем данные
$this->click(“xpath=//form[@id='login-form']/input[@type='submit']“);
$this->waitForPageToLoad(30000); // 30 секунд по умолчанию

// проверяем сообщение
$this->assertTextPresent(‘exact:Welcome, Padraic’);

// проверяем, что нет сообщений об ошибке
$this->assertTextNotPresent(‘*invalid*’);
}

В примере виден ряд новых действий (action) и assertion методов. Первый type().type() имитирует ввод данные пользователем в текстовое поле, и мы используем его здесь, чтобы Selenium Core заполнил регистрационную форму. Действие click() определяет элемент для которого Selenium Core смоделирует нажатие (есть также метод submit() который можно использовать вместо click()). Дополнительный метод waitForPageToLoad() указывает Selenium, что после запроса будет ответ с сервера, и он должен ждать ответа перед тем, как продолжить. Оба PHPUnit и Selenium поддерживают метод clickAndWait(), который объединяет методы click() и waitForPageToLoad(). На момент написания статьи этот метод не работал, видимо будет в «следующем релизе», ну что же подождем и посмотрим…

Также в примере представлены методы assertTextPresent() и assertTextNotPresent(). Оба метода содержат шаблоны. Если вы вспомните, шаблоны используются для поиска текста на странице, используя различные методы, включая поиск glod, регулярные выражения и точное соответствие. В примере используется точное соответствие. Если вы не определите тип шаблона, по умолчанию будет использован “glob”. Хотя это и не плохо, вы, возможно, промахнетесь при поиске строк, которые содержат элементы glob – звездочка или знак вопроса.

3. Она гарантирует быстрое определение будущего поведения, которое отличается от ожидаемого (регрессионное тестирование)


public function testInvalidAuthenticationWithError()
{
$this->open('http://localhost/login');

// заполняем
$this->type(“dom=document.forms['login-form'].identity”, ‘Maugrim’);
$this->type(“dom=document.forms['login-form'].password”, ‘badpass’);

// отсылаем
$this->click(“xpath=//form[@id='login-form']/input[@type='submit']“);
$this->waitForPageToLoad(30000); // 30 secs

// проверяем, что логин не прошел
$this->assertTextNotPresent(‘regexp=Welcome,[a-zA-Z0-9 -_aouieAOUIE]‘);

// проверяем, что ошибка появилась на странице
$this->assertTextPresent(‘*invalid*’);
}

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

4. Форма для логина всегда сопровождается гиперссылкой “Забыли логин или пароль?”.

Это больше изменение теста testLoginFormExists, чем новый тест. Мы просто добавим следующее:
[code]
public function testLoginFormExists()
{
// ...

// проверяем существует ли ссылка
$this->assertElementPresent('link=regexp:^Forgot identity or password?$');
}
[/code]

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

Как запускать тесты?

1. Запуск сервера Selenium RC

java -jar selenium-server-standalone.jar

Перед запуском нужно убедиться, что пути до выбранного браузера и Java добавлены в переменную PATH.

2. Запустите файл AllTests.php из каталога /test в браузере.

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

Заключение

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

This document is meant to provide web application developers, browser engineers, and information security researchers with a one-stop reference to key security properties of contemporary web browsers. Insufficient understanding of these often poorly-documented characteristics is a major contributing factor to the prevalence of several classes of security vulnerabilities.

Сюрприз же прятался в хитром механизме автоматического обновления. Во-первых обновления закачивают без спроса. Я ставил версию 0.2 и про то, что у меня стоит более свежая версия узнал только когда посмотрел About. Но я не скачивал третью версию и не давал разрешения на обновление… Во-вторых автоматический апдейт отключить не получится – такой опции в настройках нет вообще.

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

Все эти события прошли мимо меня, пока я был в отпуске. Ну и ладушки.

Поскольку появление нового инструмента в руках пользователей всегда влечет определенные проблемы для тестирования, браузер пришлось отыскать и установить. Сейчас он (официальный сайт Google Chrome) занимает третью позицию в Google (PR 0), вторую в Yahoo, третью MSN, видимо дальние позиции в Live Search и Yandex, первую в Majestic 12, а Alexa почему то найти не удалось. Хорошие показатели, на мой взгляд после восьми дней жизни.

Инсталятор, скачиваемый на компьютер, меньше полумегабайта. Правда, при установки он скачивает из Сети порядка 20 Мегабайт данных. Устанавливается не в привычные “Program Files”, а в “Documents and Settings”. Прямо скажем очень странное решение. Занимает после установки около пятидесяти мегабайт, при этом сам инсталлятор не удаляется и лежит в папке “[Version]\Installer”. Вероятно, установка следующих версий будет приводить к накоплению данных.

Судя по структуре файлов, дальше планируется появление плагинов и тем. Смущает только реализация в виде DLL.

Первым не очень понятным фактом стало то, что запущенный Chrome загружает процессор от 2 до 7% постоянно. Такого поведения не наблюдается у Internet Explorer, Firefox и Opera. Простая загрузка браузера с пустой страницей не приводит к постоянной нагрузке на процессор. Что же делает при этом Chrome? При беглом осмотре понятно не стало – к файлам обращается в меру, при этом в своей директории, реестр использует не больше остальных, в Сеть тоже постоянно не ломится. Исходный код скачивать поленился, возможно, позже всё же пересилю себя.

Интерфейс и функциональность.

Стандартный интерфейс, как и у других браузеров, только сильно урезанный или без лишних элементов, смотря с какой точки зрения подходить. Если браузер воспринимать именно как инструмент для простого просмотра страниц, то очень хорошо. У меня же вызвало смешанные чувства. Такого же эффекта можно добиться в Firefox, IE и Opera нажав F11, разница лишь в том, что при этом браузеры основной тройки разворачиваются на весь экран.

Click!

Куда интереснее поведение адресной строки при вводе ссылки.

Click!

Во-первых шрифт и поле ввода больше, чем у других браузеров. Во вторых цветами отделается домен, символы разметки, пути до страницы на сайте и имена файлов. Немного необычно, но приятно. При вводе адреса Chrome показывается в выпадающем списке возможные результаты, основанные на уже существующей истории пользователя и наиболее близких имен доменов в базе Google. Так же предлагается поискать введенную фразу в выбранном поисковике (по умолчанию Google) и посмотреть всю историю по страницам, попадающую под введенное в адресную строку. Пожалуй, этим можно было удивить в прошлом году, пока не вышел браузер Firefox 3.0. Но всё-таки хорошо, что такая возможность есть уже в первых версиях, потому как ни IE, ни Opera этого пока не сделали (поиск идет по локальной истории).В новом пустом табе (по Ctrl + T например) по умолчанию отображаются наиболее часто посещаемые сайты, а так же список недавних закладок.

Порадовал и поиск по истории браузера. Вообще функциональность очень мне понравилась, в FF и Opera существует похожая возможность, но реализована она по другому – все ячейки пользователь заполняет самостоятельно.

Совсем другой разговор, если обратить внимание на табы. Все стандартные действия поддерживаются (переключение по Ctrl + цифра, Shift, Ctrl, Shift & Ctrl + Click), табы можно менять местами, а так же вообще вытаскивать их в отдельное окно и вкладывать отдельные окна друг в друга. Анимация табулек при перетаскивании и вложении сделана приятно.

При этом, как обещает Google, зависание одного таба не скажется на остальных. Подвесить Chrome удалось легко. Было достаточно загрузить небольшой PDF документ. Пока он полностью не загрузился окно Chrome зависло и переключится на другие табы и отдельные окна не получалось. Другие приложения работали нормально. Так получается из-за того, что на самом то деле табы не являются самостоятельными процессами и запускаются от процесса ядра (это видно через Process Explorer). В результате, когда повисает главный процесс – повисает и всё остальное. Но с другой стороны, если правильно угадать, то можно убить дочерний процесс, подвесивший всё приложение, тогда действительно на других табах это не скажется. У Internet Explorer таже история, если открывать страницы не в табах, а в отдельных окнах.

Другая возможность – создание ярлыков. Любая страничка может быть помещена на рабочий стол, в меню «Пуск» или на панель быстрого запуска. В отличии от простого drug-and-drop для других браузеров, в Chrome существует дополнительный пункт меню который позволяет создать сразу все ярлыки. При этом иконка берется из favicon.ico сайта.

Click!

Запускаются такие ярлыки в отдельном окне Chrome, вообще без навигации. Впрочем, с помощью меню в заголовке окна можно переключиться в нормальный режим. Чем то напоминает Active Desktop, только окна нормальные, а не «утопленные» на заднем плане.Любопытно сделан контекстный поиск по странице. По «Ctrl + F» панелька для ввода появляется чуть ниже строки адреса. При вводе текста показывается количество соответствий и текущее положение.

История посещений и загрузок показываются в отдельном окне в виде веб страниц, с возможностью поиска. Лично мне понравилось, потому как довольно удобно использовать. К сожалению, интерактивного поиска нет (как в Firefox в истории посещений). Функция удобная, когда нет уверенности в точном названии страницы.Интересно еще и то, что иногда количество процессов было больше чем процесс ядра + количество открытых табов и окон Chrome.Я заметил еще одну приятную особенность. При открытии новых окон, они появляются не как обычно правее и ниже родительского, а чуть ниже верхней грани, по середине заголовка.

Click!

Ребята из Google добавили любопытную функцию в браузер – диспетчер задач. Вызвать диспетчер можно из контекстного меню заголовка браузера.

Производительность и стандарты.

Чисто субъективно я не заметил никакой разницы между браузерами в плане скорости загрузки страниц. Страницы с видео роликами, так или иначе, подтормаживаются при загрузке. Не было чудес и при загрузке «Google Analytics» – так же заметны подтормаживания при смене периода.Очень хорошо почувствовал разницу в скорости обработки страницы при изменении размеров текста с помощью «Ctrl + Колёсико Мышки» и Ctrl + «+/- ». Chrome работает очень быстро, практически без задержек. Но, в Chrome возможность увеличения и уменьшения текста ограничена, в отличие от Firefox. Вместе с тем, на мой взгляд, увеличение лучше работает в Internet Explorer и Opera – не портит разметку, и при этом позволяет увеличить страницу, так что на картинках будут видны пикселы.

При старте Chrome в пике съедал 40% процессора (у меня стоит AMD Athlon 3500+ 64 bit с 1 GB Dual памяти и водруженной поверх XP 32 bit с SP3). Для сравнения Firefox потреблял 35%, Internet Explorer -60%, Opera – 50%. Как уже говорилось, дальше в режиме простоя Chrome потреблял от 2 до 7% процессора. Но у Chrome наблюдается сильное преимущество по переключению контекста между потоками, хотя это не очень точно.

Тут мне стало интересно, как поведет себя Chrome при открытии нескольких табов и окон. Методику я выбрал самую простую:

- Для каждого браузера (Chrome, Firefox 2, Internet Explorer 7, Opera 9.5) открывается 10 пустых табов (то есть свежие инсталляции, без истории закладок и плагинов).
- Открывается 10 табов с одним и тем же ресурсом (я выбрал главную страницу Youtube)
- Открывается 10 отдельных окон с Youtube (окна с пустыми страницами я опустил, ничего особенного предварительные тесты не показали).
- Каждый тест повторяется 10 раз и берутся усредненные значения, если не окажется, что есть очевидные пики.Условия проведения замеров одинаковые для всех браузеров (Windows XP SP3, 32bit, Athlong 3500+, 1GB Dual RAM).В результате я получил 6 табличек cо значениями для физической и виртуальной памяти.
Потребление физической памяти на пустой выглядело так, при открытии табов:

Физическая память (MB)

Виртуальная память (MB)

А вот так память потреблялась при загрузке главной страницы Youtube, опять-таки 10 табов в одном окне:

Физическая память (MB)

Виртуальная память (MB)

Распределение памяти при открытии десяти табов с Youtube оказалось следующим:

• Chrome – нерегулярно до 30% CPU, по разным процессам.
• Firefox – постоянное использование около 20% с пиками до 50%.
• Internet Explorer – от 20% до 50%
• Opera – использование CPU колебалось в районе 30%

Интересно так же то, что распределение памяти между процессами было неоднородным и отличалось в пределах до 5 мегабайт для табов, плюс два процесса по 50 мегабайт (плюс минус 3). В отличие от Firefox и Internet Explorer, память не росла безостановочно.
Распределение памяти в случае 10 разных окон.

Физическая память (MB)

Виртуальная память (MB)

В общем и целом Chrome показал себя довольно прожорливым браузером по памяти (но в случае с окнами – намного лучше, чем Internet Explorer), но наиболее нетребовательным к процессору. При теперешнем росте объемов памяти, в принципе, не существенно. Браузер действительно должен работать быстрее, чем остальные. Пока память не закончится, конечно.

Но всё-таки, реально отдельные процессы создает только Internet Explorer, в Chrome (повторюсь), так или иначе всё завязано на главный процесс ядра.

По стандартам всё очень даже неплохо:

Acid3
• Chrome – 79
• Opera 9.5 – 84
• Firefox 2 – 52
• Firefox 3 – 71
• Internet Explorer 7.0 – я не понял сколько, картинка была сбита полностью

Acid2
Chrome, Firefox 3, Opera 9.5 – прошли.

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

Закончу эту часть рассказа такой вот картинкой :)

Часть 2: Google Chrome для разработчиков