Современные веб-технологии

Основы тестирования и отладки Веб-приложений

Разбить на страницы
Показывать лекцию целиком

Презентацию к данной лекции Вы можете скачать здесь.

19.1. Тестирование Веб-приложений

19.1.1. Введение

Вычислительные и коммуникационные системы используются все чаще и с каждым днем все глубже входят в нашу повседневную жизнь. Компании и отдельные пользователи все больше зависят в своей работе от web-приложений. Веб-приложения соединяют различные отделы внутри компаний, различные компании и простых пользователей. Веб-приложения очень динамичны, а их функциональные возможности непрерывно растут. Непрерывно возрастает потоковый трафик средств информации и запросов, формируемых переносными и встроенными устройствами. Вследствие этого возрастает сложность систем такого рода. Очевидно, что для понимания, анализа, разработки и управления такими системами нужны количественные методы и модели, которые помогают оценить различные сценарии функционирования, исследовать структуру и состояние больших систем. Наблюдаются тенденции к постоянному росту спроса на Веб-службы. Таким образом, проблемы, связанные с недостаточной производительностью будут возникать и в будущем, и, в конце концов, они станут превалирующими при планировании и вводе в эксплуатацию новых Веб-служб и увеличении пользователей Интернета. Веб-приложения становятся все более распространенными и все более сложными, играя, таким образом, основную роль в большинстве онлайновых проектов. Как и во всех системах, основанных на взаимодействии между клиентом и сервером, уязвимости Веб-приложений обычно возникают из-за некорректной обработки запросов клиента и/или недостаточной проверки входной информации со стороны разработчика.

В первой части данной лекции мы рассмотрим вопросы специфичные для тестирования и отладки Веб-приложений.

Будут рассмотрены принципы следующих подходов к тестированию Веб-приложений [1, 2]:

  • функциональное тестирование ;
  • тестирование пользовательского интерфейса ;
  • тестирование удобства использования ;
  • нагрузочное и стрессовое тестирование ;
  • проверка ссылок и HTML-кода;
  • тестирование безопасности.
    •

    Также будет приведен обзор средств автоматизации тестирования Веб-приложений.

    С общими вопросами тестирования и верификации информационных систем предлагается ознакомиться в курсе Интернет Университета Информационных Технологий "Верификация программного обеспечения" [3].

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

    19.1.2. Подходы к функциональному тестированию Веб-приложений

    Функциональное тестирование (functional testing) – процесс верификации соответствия функционирования продукта его начальным спецификациям [4]. Характерным примером может быть проверка того, что программа подсчета выплат по банковской ссуде выдает корректные выкладки на любые введенные сумму ссуды и срок ее возврата. Обычно подобные проверки проводятся вручную, иногда к этому подключаются конечные пользователи в качестве бета-тестеров. Однако программные системы становятся все сложнее, а комбинации различных входных параметров и поддерживаемых операционных систем нередко исчисляются десятками и сотнями.

    Перечислим некоторые из методов функционального тестирования веб-приложений [5, 6]:

  • Record Play – основан на возможности средств автоматизации тестирования автоматически генерировать код.
  • Functional Decomposition – в основе лежит разбиение всех компонент фреймворка по функциональному признаку на бизнес-функции (реализуют/проверяют бизнес-функциональность приложения), user-defined функции (вспомогательные функции, которые еще имеют привязку к тестируемому приложению или к конкретному проекту), утилиты (функции общего назначения, не привязанные к конкретному приложению, технологии, проекту).
  • Data-driven – основан на том, что к некоторому тесту или группе тестов привязывается источник данных, и этот тест или набор тестов циклически выполняется для каждой записи из этого источника данных. Вполне может применяться в комбинации с другими подходами.
  • Keyword-driven – представляет собой фактически движок для обработки посылаемых ему команд, а сами инструкции выносятся во внешний источник данных.
  • Object-driven – основан на том, что основные ходовые части фреймворка реализованы в виде объектов, что позволяет собирать тесты по кирпичикам.
  • Model-based – основан на том, что тестируемое приложение (или его части) описывается в виде некоторой поведенческой модели.
    •

    Самым распространенным является подход, называемый Capture Playback (другие названия – Record Playback, Capture Replay) [6]. Суть этого подхода заключается в том, что сценарии тестирования создаются на основе работы пользователя с тестируемым приложением. Инструмент перехватывает и записывает действия пользователя, результат каждого действия также запоминается и служит эталоном для последующих проверок. При этом в большинстве инструментов, реализующих этот подход, воздействия (например, нажатие кнопки мыши) связываются не с координатами текущего положения мыши, а с объектами HTML-интерфейса (кнопки, поля ввода и т.д.), на которые происходит воздействие, и их атрибутами. При тестировании инструмент автоматически воспроизводит ранее записанные действия и сравнивает их результаты с эталонными, точность сравнения может настраиваться. Можно также добавлять дополнительные проверки – задавать условия на свойства объектов (цвет, расположение, размер и т.д.) или на функциональность приложения (содержимое сообщения и т.д.).

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

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

    19.1.3. Тестирование пользовательского интерфейса

    Часть программной системы, обеспечивающая работу интерфейса с пользователем – один из наиболее нетривиальных объектов для верификации [7]. Нетривиальность заключается в двояком восприятия термина "пользовательский интерфейс".

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

    С другой стороны пользовательский интерфейс – "лицо" системы, и от его продуманности зависит эффективность работы пользователя с системой. Факторы, влияющие на эффективность работы, в меньшей степени поддаются формализации в виде конкретных требований к отдельным элементам, однако должны быть учтены в виде общих рекомендаций и принципов построения пользовательского интерфейса программной системы. Проверка интерфейса на эффективность человеко-машинного взаимодействия получила название проверки удобства использования (usability verification, в русскоязычной литературе в качестве перевода термина usability часто используют слово "практичность").

    Функциональное тестирование пользовательского интерфейса состоит из пяти фаз [7]:

  • анализ требований к пользовательскому интерфейсу;
  • разработка тест-требований и тест-планов для проверки пользовательского интерфейса;
  • выполнение тестовых примеров и сбор информации о выполнении тестов;
  • определение полноты покрытия пользовательского интерфейса требованиями.
  • составление отчетов о проблемах в случае несовпадения поведения системы и требований, либо в случае отсутствия требований на отдельные интерфейсные элементы.
    •

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

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

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

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

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

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

    19.1.3.1. Ручное тестирование

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

    В табл. 19.1 приведен пример сценария для ручного тестирования пользовательского интерфейса [7].

    Пример сценария для ручного тестирования пользовательского интерфейса
    № п/п Действие Реакция системы Результат
    1 Щелкните на значке "Система" и выберите пункт меню "Администрирование системы". Появится окно ввода логина и пароля Верно
    2 Введите в появившееся окно ввода имя пользователя "admin" и пароль "admin". Затем нажмите кнопку "OK". Появится окно "Администрирование системы". В верхнем правом углу должно быть выведено имя вошедшего пользователя admin. Неверно Окно имеет название "Управление системой"

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

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

    19.1.3.2. Сценарии на формальных языках

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

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

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

    И при передаче информации в тестируемый интерфейс и при получении информации для анализа могут использоваться два способа доступа к элементам интерфейса [7]:

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

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

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

    19.1.4. Тестирование удобства пользования

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

    Выделяют следующие этапы тестирования удобства использования пользовательского интерфейса [7]:

  • Исследовательское – проводится после формулирования требований к системе и разработки прототипа интерфейса. Основная цель на этом этапе – провести высокоуровневое обследование интерфейса и выяснить, позволяет ли он с достаточной степенью эффективности решать задачи пользователя.
  • Оценочное – проводится после разработки низкоуровневых требований и детализированного прототипа пользовательского интерфейса. Оценочное тестирование углубляет исследовательское и имеет ту же цель. На данном этапе уже проводятся количественные измерения характеристик пользовательского интерфейса: измеряются количество обращений к системе помощи по отношению к количеству совершенных операций, количество ошибочных операций, время устранения последствий ошибочных операций и т.п.
  • Валидационное – проводится ближе к этапу завершения разработки. На этом этапе проводится анализ соответствия интерфейса программной системы стандартам, регламентирующим вопросы удобства интерфейса, проводится общее тестирование всех компонент пользовательского интерфейса с точки зрения конечного пользователя. Под компонентами интерфейса здесь понимается как его программная реализация, так и система помощи и руководство пользователя. Также на данном этапе проверяется отсутствие дефектов удобства использования интерфейса, выявленных на предыдущих этапах.
  • Сравнительное – данный вид тестирования может проводиться на любом этапе разработки интерфейса. В ходе сравнительного тестирования сравниваются два или более вариантов реализации пользовательского интерфейса.
    •

    Тестирование удобства пользования дает оценку уровня удобства использования приложения по следующим пунктам [7]:

  • производительность, эффективность (efficiency) – сколько времени и шагов понадобится пользователю для завершения основных задач приложения, например, размещение новости, регистрации, покупка и т.д.
  • правильность (accuracy) – сколько ошибок сделал пользователь во время работы с приложением
  • активизация в памяти (recall) – как много пользователь помнит о работе приложения после приостановки работы с ним на длительный период времени? (повторное выполнение операций после перерыва должно проходить быстрее, чем у нового пользователя)
  • эмоциональная реакция (emotional response) – как пользователь себя чувствует после завершения задачи – растерян, испытал стресс. Порекомендует ли пользователь систему своим друзьям.
    •

    Исследование и оценка сайтов может проводится разными методами, разработанными экспертами по юзабилити. Общим для всех методов является постановка реальных задач перед пользователями, а также фиксирование результатов тестирования для дальнейшего анализа. Для участия в юзабилити-тестировании отбираются пользователи, соответствующие целевой аудитории, они также не должны быть слишком знакомы с разработкой. Для того чтобы выявить и оценить наибольшее количество присутствующих на сайте проблем, необходимо привлекать реальных пользователей [8].

    На удобство использования пользовательского интерфейса влияют следующие факторы [7]:

  • легкость обучения – быстро ли человек учится использовать систему;
  • эффективность обучения – быстро ли человек работает после обучения;
  • запоминаемость обучения – легко ли запоминается все, чему человек научился;
  • ошибки – часто ли человек допускает ошибки в работе;
  • общая удовлетворенность – является ли общее впечатление от работы с системой положительным.
    •

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

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

    Например, Якоб Нильсен в своей работе [9] выделил 10 эвристических характеристик удобного пользовательского интерфейса, которые с его точки зрения должны проверяться при тестировании удобства использования интерфейса:

  • Наблюдаемость состояния системы – система всегда должна оповещать пользователя о том, что она в данный момент делает, причем через разумные промежутки времени;
  • Соотнесение с реальным миром – терминология, использованная в интерфейсе системы должна соотноситься с пользовательским миром, т.е. это должна быть терминология проблемной области пользователя, а не техническая терминология.
  • Пользовательское управление и свобода действий – пользователи часто выбирают отдельные интерфейсные элементы и используют функции системы по ошибке. В этом случае необходимо предоставлять четко определенный "аварийный выход", при помощи которого можно вернуться к предыдущему нормальному состоянию. К таким "аварийным выходам" относятся, например, функции отката и обратного отката.
  • Целостность и стандарты – для обозначения одних и тех же объектов, ситуаций и действий должны использоваться одинаковые слова во всех частях интерфейса. Более того, терминология сообщений в пользовательском интерфейсе должна учитывать соглашения конкретной платформы.
  • Помощь пользователям в распознавании, диагностике и устранении ошибок – Сообщения об ошибках должны быть написаны на естественном языке, а не заменяться кодами ошибок. Сообщения об ошибках должны четко определять суть возникшей проблемы и предлагать ее конструктивное решение.
  • Предотвращение ошибок – продуманный дизайн пользовательского интерфейса, предотвращающий появление ошибок пользователя всегда лучше хорошо продуманных сообщений об ошибках. При проектировании интерфейса необходимо либо полностью устранить элементы, в которых могут возникать ошибки пользователя, либо проверять ввод пользователя в этих элементах и сообщать ему о потенциально возможном возникновении проблемы.
  • Распознавание, а не вспоминание – при создании интерфейса необходимо минимизировать нагрузку на память пользователя, делая объекты, действия и опции ясными, доступными и явно видимыми. Пользователь не должен запоминать информацию при переходе от одного диалогового окна к другому. Во всех необходимых местах должны быть доступны контекстные инструкции по использованию интерфейса.
  • Гибкость и эффективность использования – в интерфейсе должны быть предусмотрены горячие клавиши (не обязательные к использованию начинающим пользователем) – они часто значительно ускоряют работу опытного пользователя. Иными словами, система должна предоставлять два способа работы – для новичков и для опытных пользователей. Желательно при этом давать возможность пользователю автоматизировать часто повторяющиеся действия.
  • Эстетичный и минимально необходимый дизайн – Окна не должны содержать не относящуюся к делу или редко используемую информацию. Каждый интерфейсный элемент, содержащий бесполезную информацию, играет роль информационного шума и отвлекает пользователя от действительно полезных интерфейсных элементов.
  • Помощь и документация – Несмотря на то, что в идеальном случае лучше, когда системой можно пользоваться без документации, она все равно необходима – как в виде системы помощи, так и, возможно, в виде печатного руководства. Информация в документации должна быть структурирована таким образом, чтобы пользователь мог легко найти нужный раздел, посвященный решаемой им задаче. Каждый такой ориентированный на конкретную задачу раздел должен помимо общей информации содержать пошаговые руководства по выполнению задачи и не должен быть слишком длинным.
    •

    Все эти эвристики могут использоваться при тестировании удобства использования пользовательского интерфейса. Достаточно очевидно, что при тестировании удобства слабо применимы способы автоматизации тестирования при помощи сценариев и подобные методы. Один из наиболее эффективных методов проверки интерфейса на удобство – использование формальной инспекции. Вопросы в бланке инспекции могут быть как общего характера (так, например, можно использовать в качестве вопросов перечисленные выше 10 эвристик), так и вполне конкретными. Например, в работе [10] приводится список контрольных вопросов, которые желательно проверять при тестировании удобства использования Веб-сайтов. С некоторыми изменениями эти вопросы применимы и для обычных оконных интерфейсов.

    19.1.5. Проверка ссылок

    Еще один вид тестирования – проверка ссылок [11]. В больших тестовых комплексах он интегрирован в проверку юзабилити, или же в проверку правильности HTML-кода, но существует и множество простеньких утилит для такого рода проверок. Такое тестирование актуально и для внутренних ссылок (в случае больших и разветвленных порталов), и для внешних – если это, к примеру, каталог сайтов, или просто обычная страница "Ссылки". Пожалуй, такой тест – это один из немногих тестов, специфический для веб-приложений и сайтов. Кроме того, такой тест можно и необходимо периодически проводить на работающем сайте – ведь со временем структура меняется, и некоторые ссылки могут стать неверными.

    19.1.6. Тестирование безопасности

    Отдельно следует отметить тест на безопасность [12]. Это очень важный тип тестов, так как от безопасности сервера зависит практически все – и сам бизнес, и доверие пользователей, и сохранность информации. Правда, в отличие от других тестов, тестирование безопасности следует проводить регулярно. Кроме того, тестированию подвергается не только сам конкретный сайт или веб-приложение, а весь сервер полностью – и веб-сервер, и операционная система, и все сетевые сервисы. Как и в случае других тестов, программа "прикидывается" реальным пользователем-взломщиком и пытается применить к серверу все известные ей методы атаки и проверяет все уязвимости. Результатом работы будет отчет о найденных уязвимостях и рекомендации по их устранению.

    Ошибки, связанные с проверкой корректности ввода, часто довольно сложно обнаружить в большом объеме кода, взаимодействующего с пользователем. Это является основной причиной того, что разработчики используют методологию тестирования приложений на проникновение для их обнаружения. Веб-приложения, однако, не имеют иммунитета и к более традиционным способам атаки. Весьма распространены плохие механизмы аутентификации, логические ошибки, непреднамеренное раскрытие информации, а также такие традиционные ошибки для обычных приложений как переполнение буфера. Приступая к тестированию Веб -приложений, необходимо учитывать все перечисленное, и должен применяться методический процесс тестирования ввода/вывода по схеме "черного ящика" в сочетании (если возможно) с аудитом исходного кода [13].

    Существуют различные инструменты позволяющие производить автоматическое тестирование безопасности, выполняя такие задачи как cross site scripting, SQL injection, включая переполнение буфера, подделка параметра, несанкционированный доступ, манипуляции с HTTP запросами и т.д. [14]

    19.1.7. Нагрузочное тестирование

    Следующим видом тестирования является тест на устойчивость к большим нагрузкам – Load-testing, stress-test или performance test [15]. Такой тест имитирует одновременную работу нескольких сотен или тысяч посетителей (каждый из которых может "ходить" по сайту в соответствии со своим сценарием ), проверяя, будет ли устойчивой работа сайта под большой нагрузкой. Кроме этого, можно имитировать кратковременные пики нагрузки, когда количество посетителей скачкообразно увеличивается – это очень актуально для новостных ресурсов и других сайтов с неравномерной аудиторией. В таком тесте проверяется не только и не столько сам сайт, сколько совместная слаженная работа всего комплекса – аппаратной части сервера, веб-сервера, программного ядра (engine) и других компонентов сайта.

    Основными целями нагрузочного тестирования являются [15]:

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

    В нагрузочное тестирование входят следующие тесты:

    19.1.7.1. Тестирование производительности (Performance testing)

    Задачей тестирования производительности является определение масштабируемости приложения под нагрузкой, при этом происходит [15]:

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

    19.1.7.2. Стрессовое тестирование (Stress Testing)

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

    19.1.7.3. Объемное тестирование (Volume Testing)

    Задачей объемного тестирования является получение оценки производительности при увеличении объемов данных в базе данных приложения, при этом происходит [15]:

  • измерение времени выполнения выбранных операций при определенных интенсивности выполнения этих операций;
  • может производиться определение количества пользователей, одновременно работающих с приложением.
    •

    19.1.7.4. Тестирование стабильности или надежности (Stability / Reliability Testing)

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

    19.1.7.5. Моделирование Транзакций (Transaction Simulation, TS)

    Этот метод используется в большом числе различных продуктов, в частности, в пакетах AppManager и Vivinet Manager компании NetlQ.

    Метод TS основан на использовании программных GUI-роботов (GUI -Graphical User Interface) [17]. GUI-робот – это специальная программа, которая "заставляет" реальное пользовательское приложение работать в автоматическом режиме, без участия самого пользователя (человека). Примерами средств, предназначенных для создания GUI-роботов, являются пакеты Rational Visual Test и Rational Robot компании Rational Software, а также пакет WinRunner компании Mercury Interactive.

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

    Основное достоинство метода TS заключается в том, что он позволяет измерять производительность работы приложения "с точки зрения пользователя" и, при этом, не требует доступа к коду пользовательского приложения [18]. Недостаток же метода в том, что он позволяет измерять время выполнения только рабочих транзакций и не может использоваться для измерения времени выполнения системных транзакций.

    19.1.7.6. Метод "Анализ данных на стороне клиента" (Client Capture, CC)

    Данный метод реализован, например, в программном пакете Vital Suite компании Lucent [17]. Метод основан на извлечении данных о работе приложения из операционной системы компьютера, где установлено пользовательское приложение. Для этого на компьютере пользователя устанавливается специальный Агент, который отслеживает взаимодействие приложения и ОС и, таким образом, получает информацию о доступности и времени реакции пользовательского приложения. Достоинство данного метода в том, что при его использовании нет необходимости модернизировать код приложения. Недостаток – дополнительные накладные расходы на компьютере пользователя (клиента) и ограниченный набор поддерживаемых приложений.

    19.1.7.7. Метод "Анализ Сетевого Трафика" (Network Sniffing, NS)

    Примером такого устройства является NetScout WAN Probes, компании NetScout [17].Он основан на извлечении информации о производительности приложений из сетевого трафика. Для этого в сети устанавливаются специальные Зонды (как правило, аппаратные), которые в режиме реального времени захватывают сетевой трафик, анализируют его и "извлекают" данные о времени реакции приложений, доступности приложения и т.п. АРМ-средства на базе метода "Network Sniffing" выпускаются, в основном, производителями аппаратных анализаторов сетевых протоколов.

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

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

    В настоящее время применяются два способа обеспечения независимости запросов: использование многопоточности и создание распределенных систем [19]. Многопоточность в той или иной форме применяется во всех рассмотренных средствах тестирования. Данный метод не позволяет воспроизводить и в явной форме задавать характер потока запросов (равномерный, пульсирующий и т.д.) и его статистические характеристики (средняя величина интервала времени между последовательными запросами, дисперсия и др.). Величина выделяемого нити кванта времени (а, следовательно, и величина интервала между запросами) зависит от производительности вычислительной системы и ее загруженности, а также от алгоритмов разделения времени, применяемых операционной системой. Непредсказуемые колебания интенсивности генерируемого потока запросов не позволяют достоверно оценить стабильность работы сервера. Увеличение числа нитей повышает уровень независимости запросов, однако конкуренция между нитями снижает ур овень нагрузки, что делает данный подход неприменимым для тестирования высокопроизводительных серверов.

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

    19.1.8. Проверка HTML-кода

    Еще одним типом тестирования является проверка верности HTML-кода страниц сайта [23]. Для такого рода тестирования написано множество утилит – от простых скриптов на Perl до мощных валидаторов, проверяющих весь сайт на соответствие стандартам (а некоторые валидаторы могут в автоматическом режиме исправлять найденные недочеты, например, пропущенные закрывающие теги и т.д.). Часто такие средства встраивают в Веб-редакторы, существуют браузеры с встроенными валидаторами.

    Например, FireBug интегрируется с браузером Firefox, чтобы обогатить инструментарий разработчика [24]. Вы сможете редактировать, отлаживать и исследовать CSS, HTML и JavaScript вживую, на любой веб-странице. Firebug предоставляет возможность делать экспериментальные изменения в HTML и смотреть, как они тут же отображаются на странице, производить мониторинг сетевых запросов.

    В комплекте с IE8 поставляется инструмент "средства разработчика", который, по сути, является аналогом FireBug [25].

    19.1.9. Обзор автоматизации тестирования

    В процессе создания информационных систем нередки ошибки и дефекты – это вполне ожидаемое и нормальное явление, а в условиях ограниченных временных ресурсов и высоких требований к качеству программных продуктов неизбежно возникает необходимость в организации эффективного контроля и управления всем процессом тестирования. Контроль качества ПО невозможен сегодня без автоматизации всех задач тестирования [20].

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

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

    Процесс автоматизации тестирования делится на три этапа [20]:

  • Запись. Сценарий тестирования записывается "на лету" по мере работы пользователя с приложением. Можно также вставить точки верификации (verification points) для проверки ответа системы и сделать сценарии тестирования зависящими от данных, чтобы выполнять один и тот же сценарий с различными наборами входных данных.
  • Улучшение. Добавление кода, выполняющего разнообразные функции. Типичные изменения сценариев тестирования – условное ветвление, рефакторинг и обработка исключительных ситуаций.
  • Воспроизведение. Выполнение сценариев, эмулирующих действия, которые выполнял пользователь приложения при записи теста. Расхождения регистрируются, и тестировщик может сделать вывод о том, хорошо ли функционирует приложение или регрессионное тестирование выявило проблемы.
    •

    Для автоматизации тестирования существует большое количество приложений. Наиболее популярные из них:

  • HP LoadRunner, HP QuickTest Professional, HP Quality Center;
  • Segue SilkPerformer;
  • IBM Rational FunctionalTester, IBM Rational PerformanceTester, IBM Rational TestStudio;
  • AutomatedQA TestComplete.
    •

    HP LoadRunner – программный продукт для автоматизации нагрузочного тестирования широкого набора программных сред и протоколов [21]. Поддерживает SOA, работу с Web-сервисами, Ajax, RDP, SQL, продуктами Citrix, платформы Java, .Net, а также все основные ERP- и CRM-приложения от PeopleSoft, Oracle, SAP и Siebel. Пакет HP LoadRunner включает в себя более 60 мониторов сбора данных о тестируемой инфраструктуре и предоставляет детальную диагностику по работе приложений.

    HP LoadRunner состоит из следующих приложений [22]:

  • Virtual User Generator (VuGen) – служит для разработки нагрузочных скриптов;
  • Load Generator – служит для генерации нагрузки (генерации виртуальных пользователей);
  • Controller – служит для разработки и запуска сценариев нагрузки;
  • Analysis – служит для анализа результатов нагрузочного тестирования.
    •

    Средства от IBM Rational [21]:

  • IBM Rational Robot – универсальное средство автоматизации тестирования общего назначения для команд разработчиков, выполняющих функциональное тестирование клиент-серверных приложений. Дает возможность обнаруживать неполадки в ПО благодаря расширению сценариев тестирования средствами условной логики, позволяющей целиком охватить тестируемое приложение. Robot позволяет создавать сценарии тестирования с вызовом внешних библиотек DLL или исполняемых модулей.
  • IBM Rational Performance Tester – инструмент нагрузочного и стрессового тестирования, с помощью которого можно выявлять проблемы системной производительности и их причины. Позволяет создавать тесты без написания кода и, не требуя навыков программирования. Обеспечивает гибкие возможности моделирования и эмуляции различных пользовательских нагрузок. Выполняет сбор и интеграцию данных о серверных ресурсах с данными о производительности приложений, получаемыми в режиме реального времени.
  • IBM Rational Functional Tester – набор средств автоматизированного тестирования, позволяющих выполнять функциональное и регрессионное тестирование, тестирование пользовательского интерфейса и тестирование, управляемое данными. Инструмент применяет технологию ScriptAssure (бесшовная проверка достоверности динамических данных) и функции поиска соответствия по шаблону, позволяющие повысить устойчивость сценариев тестирования в условиях частых изменений пользовательских интерфейсов приложений. Тестировщики могут выбрать язык сценариев для разработки и настройки тестов: Java в среде Eclipse или Microsoft Visual Basic .Net в среде Visual Studio .Net.
  • IBM Rational Quality Manager – решение для реализации процессов управления тестированием и качеством, поддерживает сотрудничество участников групп по разработке программных продуктов, предоставляя им возможность обмениваться информацией, применять средства автоматизации для сокращения графиков выполнения проектов, а также составлять отчеты по проектным показателям для принятия обоснованных решений. Rational Quality Manager может быть дополнен средством управления ресурсами тестирования Rational Test Lab, обеспечивающим учет ресурсов тестирования (серверов), их бронирование, автоматизацию развертывания тестовой среды на сервере и запуск скриптов тестирования, а также отчетность по использованию ресурсов тестирования.
  • Rational Quality Manager и Rational Test Lab созданы на базе открытой платформы Jazz, которая предоставляет стандартные интерфейсы и удобные возможности для интеграции с решениями партнеров и других производителей.
    •

    19.1.10. Ключевые термины

    Функциональное тестирование, Тестирование пользовательского интерфейса, Ручное тестирование, Сценарии, Тестирования удобства использования, Проверка ссылок, Тестирование безопасности, Нагрузочное тестирование, Тестирование производительности, Стрессовое тестирование, Объемное тестирование, Тестирование стабильности, Моделирование Транзакций, Метод "Анализ данных на стороне клиента", Метод "Анализ Сетевого Трафика", Автоматизации тестирования, Проверка HTML-кода.

    19.2. Отладка Веб-приложений

    19.2.1. Введение

    Отладка – этап разработки компьютерной программы, на котором обнаруживают, локализуют и устраняют ошибки [26]. Чтобы понять, где возникла ошибка, приходится:

  • узнавать текущие значения переменных;
  • и выяснять, по какому пути выполнялась программа.
    •

    Существуют две взаимодополняющие технологии отладки.

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

    Современный процесс веб-разработки включает не только работу с HTML, но и отладку сценариев, и проверку оформления страниц. По этой причине все основные браузеры, под которые производится верстка и оптимизация большинства страниц, включает в себя специальные средства для веб-мастеров.

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

    По состоянию на начало 2010 года, Internet Explorer, Firefox, Safari, Google Chrome, а также Opera имеют отладчики сценариев.

    Internet Explorer имеет три отладчика: Microsoft Visual Studio – самый полный из них, следом за ним следует Microsoft Script Editor (компонент Microsoft Office), и, наконец, свободный Microsoft Script Debugger, который гораздо более простой, чем два других. Бесплатный Microsoft Visual Web Developer Express предоставляет ограниченную версию с отладочной функцией JavaScript в Microsoft Visual Studio. В восьмой версии в IE вместе с инструментами для разработчиков появился встроенный отладчик.

    В Opera также имеется собственный отладчик – Opera Dragonfly.

    Разрабатываемые веб-приложения в Firefox можно отлаживать при помощи расширений Firebug и Venkman.

    В Safari входит отладчик JavaScript WebKit Web Inspector. Этот же отладчик доступен и в других браузерах, использующих WebKit: Google Chrome, Arora, Rekonq, Midori и др.

    Профилирование – сбор характеристик работы программы, таких как время выполнения отдельных фрагментов (обычно подпрограмм), число верно предсказанных условных переходов, число кэш промахов и т. д. [28]. Инструмент, используемый для анализа работы, называют профилировщиком. Обычно выполняется совместно с оптимизацией программы.

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

    Это часто используется, чтобы определить, как долго выполняются определенные части программы, как часто они выполняются, или генерировать граф вызовов (Call Graph). Обычно эта информация используется, чтобы идентифицировать те участки программы, которые работают больше всего. Эти трудоёмкие участки могут быть оптимизированы, чтобы выполняться быстрее. Это – также общая методика для отладки.

    Также выделяют анализ покрытия (Code Coverage) – процесс выявления неиспользуемых участков кода при помощи, например, многократного запуска программы.

    В табл. 19.2 приведено сравнение средств отладки кода страниц разными браузерами [29].

    Сравнение средств отладки кода страниц разными браузерами
    Браузер/функция IE8 Firefox ( Firebug ) Opera Safari Chrome
    Подсветка синтаксиса HTML есть есть есть есть есть
    Свертывание кода есть есть есть есть есть
    Правка HTML есть есть нет нет нет
    Валидатор HTML-кода есть (*) нет нет нет нет
    Очистка кэша есть нет нет нет нет
    Выделение/подсветка всех вхождений кода есть есть есть есть есть
    Вьювер/редактор CSS есть есть есть есть есть
    Подсветка синтаксиса CSS есть есть нет нет нет
    Отключение стилей CSS есть есть нет нет нет
    Создание новых стилей CSS есть есть нет нет нет
    Валидатор CSS есть (*) нет нет нет нет
    Подсветка JavaScript есть нет есть есть нет
    Отладчик JavaScript есть есть есть есть нет
    Точки остановки выполнения скрипта есть есть есть есть нет
    Ручное пошаговое выполнение скрипта есть есть есть есть нет
    Профили JavaScript есть есть нет есть нет
    Выполнение JavaScript есть есть есть есть есть
    Стек вызовов есть есть есть есть нет
    Местные переменные есть есть нет есть нет
    Отслеживание переменных есть есть есть нет нет
    Вьювер для веб-сервиса нет есть нет нет нет
    Переключение режимов совместимости браузера есть нет нет нет нет
    Парковка к границам окна есть есть есть есть есть
    Палитра цветов есть есть(*) нет нет нет
    Вкладки нет есть нет нет нет
    Скорость загрузки страницы (Yslow) нет есть нет нет нет

    * – поддерживается на стороннем веб-сервисе

    Рассмотрим подробнее средства отладки и профилирования Internet Explorer 8 и Mozilla Firefox.

    19.2.2. Отладка и профилирование в Internet Explorer 8

    Рассмотрим, какие же возможности предоставляет IE8, и сравним их с реализацией в других популярных веб-браузерах [29].

    Инструменты для разработчика – Developer Tools – требуются для быстрой проверки кода страницы на его валидность (соответствие веб-стандартам, отсутствие ошибок в синтаксисе), а также для отладки различных сценариев (в основном, из-за распространения AJAX в современном сайтостроительстве это отладка JavaScript) и отображения стилей (CSS, отдельные цвета, шрифты и графика). При этом важно, чтобы данные инструменты были встроены в сам браузер, а не представляли собой отдельное приложение. В IE длительное время не было подобного инструмента, пока в 2007 году не появился отдельный тулбар для разработчиков (IE Developer Toolbar). С его помощью можно было разбирать код страницы (DOM), "на лету" проверять корректность HTML, CSS, RSS, включать отображение линеек масштаба для последующей верстки страниц и многое другое. Кроме этого тулбара, под IE были выпущены еще ряд инструментов – инспектор кода IEWatch, отладчики DebugBar и Fiddler, средства для работы со скриптовыми технологиями Ajaxview и Visual Web Developer Express. Однако в большинстве своем это были решения от сторонних разработчиков браузера, а фирменная панель IE Developer Toolbar иногда замедляла быстродействие браузера.

    19.2.2.1. Состав Developer Tools

    Запуск встроенного в IE8 инструмента веб-разработки осуществляется или через меню (Сервис – Средства разработчика), или с помощью горячей клавиши F12. В отдельном окне откроется двухпанельный редактор. В левой части будет отображаться DOM-структура сайта (секции head, body), а справа – расширенное содержание выбранного фрагмента кода. Developer Tools поддерживает работу по инспекции и отладке HTML, CSS, JavaScript, а также просмотр cookies и кэша браузера (рис. 19.1).

    (рис 19.1) Developer Tools в Internet Explorer 8.0

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

    Developer Tools открываются под каждую открытую в IE8 страницу, поэтому, чтобы не загромождать экран окнами средств разработчика, их можно закреплять (команда Ctrl+P или нажатие на пиктограмму под кнопкой закрытия окна). В этом случае окно будет располагаться во вкладке редактируемой страницы в виде панели (рис. 19.2).

    (рис 19.2) Панель Developer Tools в Internet Explorer 8.0

    Работа с инструментом строится по классической схеме – пользователю нужно выделить фрагмент страницы или участок ее кода, который автоматически будет подсвечен согласно правилам синтаксиса HTML/CSS. Внесение изменений осуществляется простой правкой кода или установкой других значений атрибутов, после чего требуется нажать клавишу Enter. Отмена всех изменений производится или обновлением страницы, или нажатием на кнопку ESC, если требуется отменять правки по частям.

    19.2.2.2. Отладка HTML и CSS

    С помощью средств разработки можно проверять код HTML и каскадные таблицы стилей сайта в том виде, в котором они обрабатываются браузером Internet Explorer, а не в исходном виде. Это особенно удобно в случае с динамическими сайтами, сложными сайтами и сайтами, где применяются платформы ASP или PHP.

    В основной области содержимого используется дерево документо-объектной модели (DOM) сайта, соответствующее структуре, содержащейся в памяти браузера Internet Explorer для отображения сайта. Для перемещения по дереву можно использовать мышь или клавиатуру. Самый быстрый способ найти узел, соответствующий определенному элементу страницы, – использовать функцию "Выбрать элемент щелчком". Используйте эту функцию, чтобы выбрать элемент на странице, и в средствах разработки будет автоматически выбран нужный узел дерева. Также можно использовать поле поиска.

    После выбора элемента в дереве DOM в области свойств справа появятся более подробные сведения о выбранном элементе [30]:

  • Стиль. Команда "Стиль" повышает эффективность отладки CSS, предоставляя список всех правил, применяющихся к выбранному элементу. Правила отображаются в порядке следования. Правила, применяющиеся в последнюю очередь, отображаются в нижней части списка; свойства, которые далее заменяются другими, перечеркиваются; благодаря этому можно лучше понять, каким образом правила CSS влияют на текущий элемент, без сопоставления селекторов вручную. Можно быстро включать и отключать правила CSS, устанавливая или снимая флажок рядом с правилом. Изменения будут сразу же отображаться на странице.
  • Отслеживать стили. Эта команда содержит такие же сведения, что и команда "Стиль", но в данном случае стили группируются по свойствам. Если нужно найти сведения о каком-либо свойстве, используйте команду "Трассировка стиля". Нужно всего лишь найти нужное свойство, щелкнуть значок плюса (+), и на экране появится список всех правил, устанавливающих данное свойство. Правила перечисляются в порядке следования.
  • Раскладка. Команда "Раскладка" предоставляет сведения о макете модели, такие как смещение элементов, их высота и заполнение. Эту команду следует применять при отладке расположения элементов.
  • Атрибуты. Команда "Атрибуты" дает возможность исследовать все определенные атрибуты выбранного элемента. С помощью этой команды также можно изменять, добавлять и удалять атрибуты выбранного элемента.
    •

    После загрузки DOM-структуры сайта пользователь увидит древовидный список структуры тегов на левой панели. Справа же отображаются связанные с ними, соответственно, стили и атрибуты CSS. Например, при выборе в странице тега <div> можно увидеть связанные с таблицей классы CSS и отследить вызываемые параметры цветов, шрифтов, полей, отступов и так далее. Здесь же в разделе "Раскладка" (Layout) будет показано расположение этого элемента на площади страницы с указанием размеров в пикселях и пропорций. Естественно, его можно изменять непосредственно на этой вкладке. В атрибутах отображается список всех зависимостей HTML-кода на странице; к ним можно добавлять собственные из выпадающего списка (рис. 19.3).

    (рис 19.3) Атрибуты в Developer Tools

    Помимо отображения в рамках Developer Tools, расположение HTML-элементов можно увидеть и на самой оригинальной странице. Для этого следует указать в меню "Как векторные" (Outline) показ соответствующих фрагментов – ячеек таблицы, таблиц, элементов DIV-верстки, границ рисунков в относительных, абсолютных, постоянных и перемещенных границах. В результате на странице они будут размечены тонкими зелеными линиями.

    Многие средства разработчика HTML и CSS работают с отдельными элементами веб-страницы. Чтобы выбрать элемент, необходимо выделить на вкладке HTML или при нажатии на кнопку "Выбрать элемент щелчком" в меню "Найти" средств разработчика. После нажатия этой кнопки можно будет с помощью мыши выбрать элемент на веб-странице. На рис. 19.4 показаны результаты выбора элемента.

    (рис 19.4) Результаты выбора элемента в Developer Tools

    Developer Tools позволяет настраивать каскадные стили в режиме реального времени

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

    С помощью вкладки CSS можно понять взаимодействие между таблицами стилей. Она в большей степени полезна для сайтов, на которых используется несколько таблиц стилей. Для переключения между таблицами стилей используйте кнопку выбора таблиц стилей. При выборе таблицы стилей правила и связанные с ними свойства стилей появляются в основной области содержимого. Эта информация сгруппирована по правилам стилей. По умолчанию на этой кнопке отображается первая таблица стилей, на которую ссылается веб-страница. Как показано на рис. 19.5, правила таблиц стилей отображаются под кнопкой выбора таблиц стилей.

    (рис 19.5) Вкладка CSS в Developer Tools

    С помощью средства Layout можно вывести следующие значения:

  • Значения смещений, то есть расстояния между выбранным элементом и его родительскими элементами. Смещения представлены свойствами offsetLeft и offsetTop.
  • Значения величин Margin, Border и Padding, которые соответствуют значениям, установленным на веб-странице. Если в исходном коде веб-страницы значения для этих величин не указаны, используются значения по умолчанию Windows Internet Explorer.
  • Глубже других внутри находятся высота и ширина элемента, которые определяются свойствами offsetHeight и offsetWidth.
    •

    Для каждого атрибута рамочной модели указаны его величина и единица измерения. По умолчанию значения атрибутов рамочной модели указываются в точках; если единица измерения средством "Layout" не показана, значит, величина задана в точках. На рис. 19.6 изображено средство "Layout" вместе с выбранным на панели HTML (слева) элементом.

    (рис 19.6) Раскладка в Developer Tools

    Все изменения, внесенные с помощью средств разработчика, применяются только к внутреннему представлению сайта в браузере Internet Explorer. При обновлении страницы или при переходе на другую страницу вновь откроется исходный сайт. Однако в некоторых случаях может потребоваться сохранить изменения. На вкладках "HTML" и "CSS" нажмите кнопку "Сохранить" для сохранения текущего HTML- или, соответственно, CSS-кода в файл. Помните, что отличия от исходного кода могут быть не только в измененных вами фрагментах, но и в других частях, поскольку в средствах разработчика сайт отображается в соответствии с кодом в Internet Explorer, а не с кодом исходного сайта. Чтобы избежать случайной перезаписи кода, выходные данные сохраняются в виде текста, а в начало файла добавляется комментарий.

    19.2.2.3. Отладка JScript

    Отладка JScript – это важнейший этап в разработке веб-приложений. Благодаря интуитивно понятному упрощенному отладчику JScript средства разработчика позволяют существенно упростить весь процесс отладки JScript. Установив Internet Explorer 8, разработчики могут отлаживать JScript на любом сайте, загруженном в Internet Explorer (рис. 19.7).

    Developer Tools может использоваться также и как отладчик JavaScript. Для его запуска нужно перейти во вкладку "Сценарий" (Script) и нажать на кнопку Start Debugging. В результате произойдет перезагрузка текущей страницы в открытой вкладке (если в настройках браузера запрещена отладка скриптов), а Developer Tools "открепятся" от нижней части экрана. Остановка процесса отладки производится по нажатию на клавиатурное сочетание Shift+F5 или нажав на кнопку Stop Debugging.

    (рис 19.7) Отладка в Developer Tools

    Консоль JavaScript-кода может отслеживать вызов тех или иных переменных, выражений и стеков вызовов.

    В ходе процесса возможна установка контрольных точек автоматической остановки выполнения – для этого нужно выделить нужное место в коде скрипта, после чего нажать на кнопку F9. Есть также и запуск отладчика с пропуском ошибок исполнения (во избежание остановок) – для этого можно или щелкнуть по кнопке "Остановка при ошибке" или же продублировать это действие командой Ctrl+Shift+E. Кроме того, в случае, если установленная контрольная точка становится неактуальной (код на странице поменялся, указан неправильный путь до сценария и так далее), то в отладчике можно задать условия, при которых будет выполняться остановка (устанавливается в свойствах точки остановки). Наконец, в случае, когда выполнение сценария приостановлено, пользователь может вручную продолжить работу отладчика (кнопка F5), остановить процесс (Ctrl+Shift+B), перейти на следующий этап (F11) или предыдущий шаг (F10), повторить последний цикл скрипта до текущего состояния (Shift+F11).

    Любая ошибка во время выполнения приводит к тому, что отладчик автоматически останавливается в месте возникновения ошибки [30]. Windows Internet Explorer остановится и выделит строку, вызвавшую ошибку, в окне просмотра исходного кода.

    Примечание. Пока Windows Internet Explorer ожидает ввода от отладчика сценариев, он не отвечает ни на какие воздействия пользователя.

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

    На вкладке Breakpoints изображен список всех доступных точек останова. На рис. 19.8 показана вкладка Breakpoints, выбранная в правой части панели отладчика.

    (рис 19.8) Вкладка "Точки останова" в Developer Tools

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

    Примечание. Даже если перейти со страницы текущего веб-узла, Windows Internet Explorer сохранит информацию о точках останова до тех пор, пока не будут закрыты средства разработчика.

    Консоль JavaScript-кода может отслеживать вызов тех или иных переменных, выражений и стеков вызовов. Все полученные результаты могут протоколироваться. Еще одна полезная для веб-разработчика функция в Developer Tools связана с измерением производительности JavaScript на страницах. Под страницу могут создаваться специальные профили, которые показывают, какое количество времени было затрачено на исполнение того или иного сценария, а также число вызовов его при открытии страницы. Соответственно, под каждый сеанс будут создавать соответствующие отчеты, которые можно экспортировать в CSV-файл. Помимо этого, профили можно сохранять для сравнения между разными версиями кода.

    В любой момент, когда исполнение сценария приостановлено точкой останова, можно просмотреть значения переменных. С помощью средства Locals отладчика можно вывести имена, значения и типы всех переменных, существующих в текущей области видимости сценария. Значения переменных вне области видимости не определены. Область видимости – это интервал, в котором можно обращаться к некоторой переменной. На рис. 19.9 показан вид средства Locals во время отладки.

    (рис 19.9) Средства "Локальные" в Developer Tools

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

    (рис 19.10) Средства "Смотреть" в Developer Tools

    Еще один способ добавить точку наблюдения переменной – щелкнуть текст "Click to add…" в окне Watch и ввести имя переменной.

    Заметим, что функция профилирования JavaScript добавляет к функциональности отладчика возможность оптимизации кода. Иными словами, Developer Tools содержат инструмент, позволяющий выявить "узкие места" в веб-приложениях – обычно это наиболее часто используемые скрипты. Для этого вебмастеру необходимо инициировать процесс профилирования, чтобы увидеть скорость обработки сценариев. Результат будет представлен в виде списка последовательных вызовов скрипта или отдельных его функций. Чтобы увидеть URL, который относится к данному фрагменту и строку на странице, в IE8 должен быть включен отладчик сценариев.

    19.2.2.4. Профилирование JavaScript

    Благодаря профилированию сценариев можно улучшить работу веб-сайта посредством идентификации и исправления связанных с производительностью проблем в коде JavaScript (JScript) [30].

    Режим Profiler позволяет собрать информацию о временных характеристиках работы веб-узла, которая собирается по мере визуализации страниц веб-узла обозревателем Windows Internet Explorer. Данная информация помогает оптимизировать участки кода, на исполнение которых уходит слишком много времени, то есть узкие места.

    На вкладке "Профили" начните сеанс профилирования сценария нажатием кнопки "Запуск создания профилей". При этом обработчик сценариев переключается в режим профилирования, и на кнопке появляется текст "Остановка создания профилей". Выполните сценарий, который хотите профилировать на веб-странице. Щелкните "Остановка создания профилей" для завершения сеанса. Автоматически отображается отчет о только что созданном профиле.

    На рис. 19.11 показан основной пользовательский интерфейс вкладки "Профили".

    (рис 19.11) Вкладка "Профили" в Developer Tools

    Отчеты о профилях можно просматривать в представлении "Функции" или "Дерево вызовов", которое можно выбрать из раскрывающегося списка "Текущее представление".

  • В представлении "Функции" перечисляются все используемые функции.
  • В представлении "Дерево вызовов" показана иерархия вызовов.
    •

    В отчете показаны функции, использовавшиеся обозревателем Windows Internet Explorer для визуализации URL-адреса. Выводится название функции, число ее вызовов, включительное и исключительное время. Включительное время – это время, затраченное на исполнение самой функции и всех функций, из нее вызванных. Исключительное время – это время, затраченное на исполнение самой функции без учета функций, из нее вызванных.

    С помощью собранной профилировщиком информации легко найти узкие места в коде вашего веб-узла. Если обнаружить и изменить структуру неэффективного кода или медленных алгоритмов, то можно сократить время, которое обозреватель Windows Internet Explorer тратит на визуализацию веб-страниц.

    Данные профиля можно экспортировать из текущего отчета в CSV-файл.

    19.2.2.5. Другие возможности Developer Tools

    При создании средств разработчика в IE8 Microsoft учла современные требования к подобным инструментам. В частности, особое внимание было уделено к юзабилити решения. Так, в Developer Tools поддерживается полнотекстовый поиск фрагментов HTML (окно поиска расположено в верхнем правом углу окна), а также быстрый поиск всех вхождений тега на основе совместимых с W3C-стандартами селекторов (например, "@table"). Просмотр с помощью Developer Tools включен в контекстное меню IE8. В Developer Tools модули подгружаются по мере необходимости и под конкретную страницу, не затрагивая производительность IE8 на других открытых вкладках.

    Среди прочих возможностей Developer Tools есть расширенные инструменты работы с рисунками (показ путей, размеров, отчетов об изображениях, блокировка их на странице), ссылками на странице (генерация отчета обо всех внешних и внутренних гиперссылках с их атрибутами), кэшем браузера (просмотр и удаление cookies сайта или страницы, политика обновления кэша обозревателя для страницы или всего домена), а также полезные для верстальщика линейка масштаба, палитра цветов и подгонка страницы по определенное разрешение (есть предустановки под стандартные 800*600 и 1024*768 пикселей и возможность задать свой произвольный размер). Кроме того, рядом расположен переключатель отображения веб-документа под разные версии IE – режим совместимости с IE7/IE8, а также более старшими билдами браузера.

    Developer Tools являются удобным и эффективным инструментом для решения повседневных задач веб-мастера. В отличие от плагинов, которые загружают дополнительно не без того ресурсоемкий процесс любого браузера (этим особенно отличаются браузеры на движке Gecko, работающие под Windows), решение от Microsoft выглядит достойной и современной альтернативой.

    19.2.3. Отладка и профилирование в Firebug

    Firebug – расширение для браузера Firefox, являющееся консолью, отладчиком, и DOM-инспектором JavaScript, DHTML, CSS, XMLHttpRequest. Firebug показывает в консоли вызвавшую ошибку функцию, стек вызовов функций, вызвавших эту ошибку. Он предупреждает, что CSS-правило или JavaScript-метод/свойство, которое вы пытаетесь использовать, не существует [24].

    Основные возможности Firebug:

  • Удобный просмотр HTML-кода страницы. Функция Inspect позволяет точно определить местонахождение тега того или иного элемента, просмотреть все "привязанные" к нему свойства и стили.
  • Редактирование HTML и CSS прямо в браузере. Можно изменять атрибуты тегов и значения свойств для того, чтобы пронаблюдать изменения. Удобно для тех случаев, когда нужно путём экспериментов найти наиболее приемлемый вариант оформления создаваемой страницы.
  • Отладка JavaScript.
  • Отслеживание процесса загрузки страницы.
  • Просмотр HTTP-заголовков обычных и AJAX-запросов.
    •

    Firebug вызывается также при нажатии на клавишу F12 или при нажатии на изображение "жука" в статус баре браузера (рис. 19.12).

    (рис 19.12) "Жук" в статус баре браузера

    При нажатии на Control+F12 (или Command+F12 для Mac) Firebug откроется в отдельном окне (рис. 19.13).

    (рис 19.13) FireBug в отдельном окне

    Firebug, как и Developer Tools, можно "прикреплять" к инспектируемой странице (рис. 19.14).

    (рис 19.14) FireBug в виде панели браузера

    19.2.3.1. Отладка HTML и CSS

    В Firefox есть окно "View Source", но оно не покажет, как HTML выглядит на самом деле, после трансформаций JavaScript. Вкладка HTML в Firebug показывает, как HTML выглядит в данный момент времени.

    В дополнение, вкладки справа позволят выяснить свойства индивидуальных элементов, включая правила CSS, которые их стилизуют, размер и позицию в пикселях, и свойства DOM, к которым есть доступ из JavaScript.

    В любом сайте, основанном на JavaScript, HTML-элементы все время создаются, удаляются и изменяются. Firebug подсвечивает изменения HTML желтым цветом, как только они происходят.

    Firebug дает возможность делать изменения в HTML и смотреть, как они тут же отражаются на странице. Можно создавать, удалять или редактировать HTML-атрибуты и текст, просто кликая на них и табом перемещаясь от одного к другому (рис. 19.15). Изменения применяются мгновенно, в момент печати.

    (рис 19.15) Изменение HTML-атрибутов в FireBug

    Помимо этого Firebug позволяет редактировать HTML-исходник любого элемента, нажав правой кнопкой на элементе и выбрав "Edit HTML..." в меню.

    При помощи функции "Inspect" в панели Firebug можно, выделив мышью по странице элемент, увидеть его HTML и CSS (рис. 19.16).

    (рис 19.16) Выделение элемента на странице с помощью FireBug

    Firebug предоставляет инструменты для отладки CSS. Firebug показывает правила, которые работают в CSS, стилизуя каждый элемент (рис. 19.17). Правила отсортированы в восходящем порядке, и overridden-свойства вычеркнуты. У каждого правила есть ссылка на файл, из которого оно пришло.

    (рис 19.17) Выделение элемента на странице с помощью FireBug

    Редактирование CSS происходит также как и HTML (рис. 19.18). Во время печати, изменения тут же применяются к странице.

    (рис 19.18) Редактирование CSS с помощью FireBug

    При желании можно добавить новое CSS свойство (рис. 19.19).

    (рис 19.19) Добавление CSS-свойства с помощью FireBug

    Можно также отключать некоторые CSS свойства (рис. 19.20).

    (рис 19.20) Отключение CSS-свойства с помощью FireBug

    Вкладка "Макет" (Layout) визуально разбивает каждый контейнер в контейнерной модели и дает ширину каждого ребра (рис. 19.21). Дополнительно, она показывает ширину и высоту внутреннего контейнера, и сдвиги по x и y относительно родителя.

    (рис 19.21) Вкладка "Макет" в FireBug

    Двигая мышью по контейнерам во вкладке Layout, на странице появляются линейки и направляющие (рис. 19.22).

    (рис 19.22) Линейки и направляющие на HTML-странице

    Линейки окружают родителя текущего элемента, относительно которого заданы CSS-свойства left, top, bottom и right. Направляющие касаются каждого края элемента и являются отличным способом показать с точностью до пикселя, насколько точно сведены края нескольких контейнеров.

    Как и всякую другую вкладку Firebug, вкладку Layout можно редактировать.

    19.2.3.2. Отладка JavaScript

    Firebug содержит мощный JavaScript-отладчик, который дает Вам возможность приостановить выполнение в любой момент и просмотреть каждую переменную на этот момент.

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

    (рис 19.23) Выбор скриптового файла в FireBug

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

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

    Firebug позволяет Вам устанавливать "условные" брейпкойнты (рис. 19.24). Они проверяют выражение, которое должно быть истинным, чтобы брейкпойнт сработал.

    (рис 19.24) Точки останова в FireBug

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

    Также Firebug дает возможность заходить в отладчик автоматически, когда происходит ошибка (рис. 19.25).

    (рис 19.25) Отладчик в FireBug

    Когда отладчик приостанавливает выполнение, Firebug показывает стек вызова, т.е. набор вложенных вызовов функций, которые сейчас запущены и ждут возврата. Стек вызовов представлен компактной полоской кнопок в панели, каждая – с именем функции в стеке.

    19.2.3.3. Профилирование

    Чтобы использовать профилировщик, необходимо зайти во вкладку Console и кликнуть кнопку "Profile". После этого можно увидеть детальный отчет, который показывает, какие функции были вызваны и сколько времени заняла каждая (рис. 19.26).

    (рис 19.26) Профилирование в FireBug

    Помимо этого у каждого файла во вкладке "Сеть" (Net) есть полоска, которая показывает, когда началась и закончилась загрузка, относительно других файлов. Полоски могут показать, например, что JavaScript файлы загружаются по очереди, и никогда – параллельно. Это поможет оптимизировать порядок файлов на странице, чтобы пользователь проводил меньше времени, ожидая показа страницы. Также в панели Net можно фильтровать список по типам файлов (JavaScript, картинки и др.).

    (рис 19.27) Вкладка "Сеть" в FireBug

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

    Плюс ко всему Firebug показывает каждый XMLHttpRequest (например, используемые AJAX), и во вкладке Net, и в Console, вместе с текстом, который был отправлен и получен (рис. 19.28).

    (рис 19.28) XMLHttpRequest в FireBug

    19.2.4. Ключевые термины

    Отладка, Профилирование, Internet Explorer Developer Tools, Firebug.

    19.3. Краткие итоги

    Функциональное тестирование – процесс верификации соответствия функционирования продукта его начальным спецификациям.

    Методы функционального тестирования веб-приложений:

  • Record Play;
  • Functional Decomposition;
  • Data-driven;
  • Keyword-driven;
  • Object-driven;
  • Model-based.
    •

    Функциональное тестирование пользовательского интерфейса состоит из пяти фаз:

  • анализ требований к пользовательскому интерфейсу;
  • разработка тест-требований и тест-планов для проверки пользовательского интерфейса;
  • выполнение тестовых примеров и сбор информации о выполнении тестов;
  • определение полноты покрытия пользовательского интерфейса требованиями.
  • составление отчетов о проблемах в случае несовпадения поведения системы и требований, либо в случае отсутствия требований на отдельные интерфейсные элементы.
    •

    Тестирование удобства пользования дает оценку уровня удобства использования приложения по следующим пунктам:

  • производительность, эффективность;
  • правильность;
  • активизация в памяти;
  • эмоциональная реакция;
    •

    В нагрузочное тестирование входят следующие тесты:

  • Тестирование производительности ;
  • Стрессовое тестирование ;
  • Объемное тестирование ;
  • Тестирование стабильности или надежности;
  • Моделирование Транзакций ;
  • Метод "Анализ данных на стороне клиента" ;
  • Метод "Анализ Сетевого Трафика" ;
    •

    Другие виды тестирования Веб-приложений: проверка ссылок, тестирование безопасности, проверка верности HTML-кода.

    Процесс автоматизации тестирования делится на три этапа [20]:

  • Запись;
  • Улучшение;
  • Воспроизведение;
    •

    Для автоматизации тестирования существует большое количество приложений.

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

    Профилирование – сбор характеристик работы программы, таких как время выполнения отдельных фрагментов (обычно подпрограмм), число верно предсказанных условных переходов, число кэш промахов и т. д.

    Internet Explorer Developer Tools, входящий в комплект IE8 – инструмент для разработчика, требующийся для быстрой проверки кода страницы на его валидность, а также для отладки различных сценариев и отображения стилей.

    Firebug – расширение для браузера Firefox, являющееся консолью, отладчиком, и DOM-инспектором JavaScript, DHTML, CSS, XMLHttpRequest.

    Страницы:

    Презентацию к данной лекции Вы можете скачать здесь.

    19.1. Тестирование Веб-приложений

    19.1.1. Введение

    Вычислительные и коммуникационные системы используются все чаще и с каждым днем все глубже входят в нашу повседневную жизнь. Компании и отдельные пользователи все больше зависят в своей работе от web-приложений. Веб-приложения соединяют различные отделы внутри компаний, различные компании и простых пользователей. Веб-приложения очень динамичны, а их функциональные возможности непрерывно растут. Непрерывно возрастает потоковый трафик средств информации и запросов, формируемых переносными и встроенными устройствами. Вследствие этого возрастает сложность систем такого рода. Очевидно, что для понимания, анализа, разработки и управления такими системами нужны количественные методы и модели, которые помогают оценить различные сценарии функционирования, исследовать структуру и состояние больших систем. Наблюдаются тенденции к постоянному росту спроса на Веб-службы. Таким образом, проблемы, связанные с недостаточной производительностью будут возникать и в будущем, и, в конце концов, они станут превалирующими при планировании и вводе в эксплуатацию новых Веб-служб и увеличении пользователей Интернета. Веб-приложения становятся все более распространенными и все более сложными, играя, таким образом, основную роль в большинстве онлайновых проектов. Как и во всех системах, основанных на взаимодействии между клиентом и сервером, уязвимости Веб-приложений обычно возникают из-за некорректной обработки запросов клиента и/или недостаточной проверки входной информации со стороны разработчика.

    В первой части данной лекции мы рассмотрим вопросы специфичные для тестирования и отладки Веб-приложений.

    Будут рассмотрены принципы следующих подходов к тестированию Веб-приложений [1, 2]:

  • функциональное тестирование ;
  • тестирование пользовательского интерфейса ;
  • тестирование удобства использования ;
  • нагрузочное и стрессовое тестирование ;
  • проверка ссылок и HTML-кода;
  • тестирование безопасности.
    •

    Также будет приведен обзор средств автоматизации тестирования Веб-приложений.

    С общими вопросами тестирования и верификации информационных систем предлагается ознакомиться в курсе Интернет Университета Информационных Технологий "Верификация программного обеспечения" [3].

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

    19.1.2. Подходы к функциональному тестированию Веб-приложений

    Функциональное тестирование (functional testing) – процесс верификации соответствия функционирования продукта его начальным спецификациям [4]. Характерным примером может быть проверка того, что программа подсчета выплат по банковской ссуде выдает корректные выкладки на любые введенные сумму ссуды и срок ее возврата. Обычно подобные проверки проводятся вручную, иногда к этому подключаются конечные пользователи в качестве бета-тестеров. Однако программные системы становятся все сложнее, а комбинации различных входных параметров и поддерживаемых операционных систем нередко исчисляются десятками и сотнями.

    Перечислим некоторые из методов функционального тестирования веб-приложений [5, 6]:

  • Record Play – основан на возможности средств автоматизации тестирования автоматически генерировать код.
  • Functional Decomposition – в основе лежит разбиение всех компонент фреймворка по функциональному признаку на бизнес-функции (реализуют/проверяют бизнес-функциональность приложения), user-defined функции (вспомогательные функции, которые еще имеют привязку к тестируемому приложению или к конкретному проекту), утилиты (функции общего назначения, не привязанные к конкретному приложению, технологии, проекту).
  • Data-driven – основан на том, что к некоторому тесту или группе тестов привязывается источник данных, и этот тест или набор тестов циклически выполняется для каждой записи из этого источника данных. Вполне может применяться в комбинации с другими подходами.
  • Keyword-driven – представляет собой фактически движок для обработки посылаемых ему команд, а сами инструкции выносятся во внешний источник данных.
  • Object-driven – основан на том, что основные ходовые части фреймворка реализованы в виде объектов, что позволяет собирать тесты по кирпичикам.
  • Model-based – основан на том, что тестируемое приложение (или его части) описывается в виде некоторой поведенческой модели.
    •

    Самым распространенным является подход, называемый Capture Playback (другие названия – Record Playback, Capture Replay) [6]. Суть этого подхода заключается в том, что сценарии тестирования создаются на основе работы пользователя с тестируемым приложением. Инструмент перехватывает и записывает действия пользователя, результат каждого действия также запоминается и служит эталоном для последующих проверок. При этом в большинстве инструментов, реализующих этот подход, воздействия (например, нажатие кнопки мыши) связываются не с координатами текущего положения мыши, а с объектами HTML-интерфейса (кнопки, поля ввода и т.д.), на которые происходит воздействие, и их атрибутами. При тестировании инструмент автоматически воспроизводит ранее записанные действия и сравнивает их результаты с эталонными, точность сравнения может настраиваться. Можно также добавлять дополнительные проверки – задавать условия на свойства объектов (цвет, расположение, размер и т.д.) или на функциональность приложения (содержимое сообщения и т.д.).

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

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

    19.1.3. Тестирование пользовательского интерфейса

    Часть программной системы, обеспечивающая работу интерфейса с пользователем – один из наиболее нетривиальных объектов для верификации [7]. Нетривиальность заключается в двояком восприятия термина "пользовательский интерфейс".

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

    С другой стороны пользовательский интерфейс – "лицо" системы, и от его продуманности зависит эффективность работы пользователя с системой. Факторы, влияющие на эффективность работы, в меньшей степени поддаются формализации в виде конкретных требований к отдельным элементам, однако должны быть учтены в виде общих рекомендаций и принципов построения пользовательского интерфейса программной системы. Проверка интерфейса на эффективность человеко-машинного взаимодействия получила название проверки удобства использования (usability verification, в русскоязычной литературе в качестве перевода термина usability часто используют слово "практичность").

    Функциональное тестирование пользовательского интерфейса состоит из пяти фаз [7]:

  • анализ требований к пользовательскому интерфейсу;
  • разработка тест-требований и тест-планов для проверки пользовательского интерфейса;
  • выполнение тестовых примеров и сбор информации о выполнении тестов;
  • определение полноты покрытия пользовательского интерфейса требованиями.
  • составление отчетов о проблемах в случае несовпадения поведения системы и требований, либо в случае отсутствия требований на отдельные интерфейсные элементы.
    •

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

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

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

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

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

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

    19.1.3.1. Ручное тестирование

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

    В табл. 19.1 приведен пример сценария для ручного тестирования пользовательского интерфейса [7].

    Пример сценария для ручного тестирования пользовательского интерфейса
    № п/п Действие Реакция системы Результат
    1 Щелкните на значке "Система" и выберите пункт меню "Администрирование системы". Появится окно ввода логина и пароля Верно
    2 Введите в появившееся окно ввода имя пользователя "admin" и пароль "admin". Затем нажмите кнопку "OK". Появится окно "Администрирование системы". В верхнем правом углу должно быть выведено имя вошедшего пользователя admin. Неверно Окно имеет название "Управление системой"

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

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

    19.1.3.2. Сценарии на формальных языках

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

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

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

    И при передаче информации в тестируемый интерфейс и при получении информации для анализа могут использоваться два способа доступа к элементам интерфейса [7]:

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

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

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

    19.1.4. Тестирование удобства пользования

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

    Выделяют следующие этапы тестирования удобства использования пользовательского интерфейса [7]:

  • Исследовательское – проводится после формулирования требований к системе и разработки прототипа интерфейса. Основная цель на этом этапе – провести высокоуровневое обследование интерфейса и выяснить, позволяет ли он с достаточной степенью эффективности решать задачи пользователя.
  • Оценочное – проводится после разработки низкоуровневых требований и детализированного прототипа пользовательского интерфейса. Оценочное тестирование углубляет исследовательское и имеет ту же цель. На данном этапе уже проводятся количественные измерения характеристик пользовательского интерфейса: измеряются количество обращений к системе помощи по отношению к количеству совершенных операций, количество ошибочных операций, время устранения последствий ошибочных операций и т.п.
  • Валидационное – проводится ближе к этапу завершения разработки. На этом этапе проводится анализ соответствия интерфейса программной системы стандартам, регламентирующим вопросы удобства интерфейса, проводится общее тестирование всех компонент пользовательского интерфейса с точки зрения конечного пользователя. Под компонентами интерфейса здесь понимается как его программная реализация, так и система помощи и руководство пользователя. Также на данном этапе проверяется отсутствие дефектов удобства использования интерфейса, выявленных на предыдущих этапах.
  • Сравнительное – данный вид тестирования может проводиться на любом этапе разработки интерфейса. В ходе сравнительного тестирования сравниваются два или более вариантов реализации пользовательского интерфейса.
    •

    Тестирование удобства пользования дает оценку уровня удобства использования приложения по следующим пунктам [7]:

  • производительность, эффективность (efficiency) – сколько времени и шагов понадобится пользователю для завершения основных задач приложения, например, размещение новости, регистрации, покупка и т.д.
  • правильность (accuracy) – сколько ошибок сделал пользователь во время работы с приложением
  • активизация в памяти (recall) – как много пользователь помнит о работе приложения после приостановки работы с ним на длительный период времени? (повторное выполнение операций после перерыва должно проходить быстрее, чем у нового пользователя)
  • эмоциональная реакция (emotional response) – как пользователь себя чувствует после завершения задачи – растерян, испытал стресс. Порекомендует ли пользователь систему своим друзьям.
    •

    Исследование и оценка сайтов может проводится разными методами, разработанными экспертами по юзабилити. Общим для всех методов является постановка реальных задач перед пользователями, а также фиксирование результатов тестирования для дальнейшего анализа. Для участия в юзабилити-тестировании отбираются пользователи, соответствующие целевой аудитории, они также не должны быть слишком знакомы с разработкой. Для того чтобы выявить и оценить наибольшее количество присутствующих на сайте проблем, необходимо привлекать реальных пользователей [8].

    На удобство использования пользовательского интерфейса влияют следующие факторы [7]:

  • легкость обучения – быстро ли человек учится использовать систему;
  • эффективность обучения – быстро ли человек работает после обучения;
  • запоминаемость обучения – легко ли запоминается все, чему человек научился;
  • ошибки – часто ли человек допускает ошибки в работе;
  • общая удовлетворенность – является ли общее впечатление от работы с системой положительным.
    •

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

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

    Например, Якоб Нильсен в своей работе [9] выделил 10 эвристических характеристик удобного пользовательского интерфейса, которые с его точки зрения должны проверяться при тестировании удобства использования интерфейса:

  • Наблюдаемость состояния системы – система всегда должна оповещать пользователя о том, что она в данный момент делает, причем через разумные промежутки времени;
  • Соотнесение с реальным миром – терминология, использованная в интерфейсе системы должна соотноситься с пользовательским миром, т.е. это должна быть терминология проблемной области пользователя, а не техническая терминология.
  • Пользовательское управление и свобода действий – пользователи часто выбирают отдельные интерфейсные элементы и используют функции системы по ошибке. В этом случае необходимо предоставлять четко определенный "аварийный выход", при помощи которого можно вернуться к предыдущему нормальному состоянию. К таким "аварийным выходам" относятся, например, функции отката и обратного отката.
  • Целостность и стандарты – для обозначения одних и тех же объектов, ситуаций и действий должны использоваться одинаковые слова во всех частях интерфейса. Более того, терминология сообщений в пользовательском интерфейсе должна учитывать соглашения конкретной платформы.
  • Помощь пользователям в распознавании, диагностике и устранении ошибок – Сообщения об ошибках должны быть написаны на естественном языке, а не заменяться кодами ошибок. Сообщения об ошибках должны четко определять суть возникшей проблемы и предлагать ее конструктивное решение.
  • Предотвращение ошибок – продуманный дизайн пользовательского интерфейса, предотвращающий появление ошибок пользователя всегда лучше хорошо продуманных сообщений об ошибках. При проектировании интерфейса необходимо либо полностью устранить элементы, в которых могут возникать ошибки пользователя, либо проверять ввод пользователя в этих элементах и сообщать ему о потенциально возможном возникновении проблемы.
  • Распознавание, а не вспоминание – при создании интерфейса необходимо минимизировать нагрузку на память пользователя, делая объекты, действия и опции ясными, доступными и явно видимыми. Пользователь не должен запоминать информацию при переходе от одного диалогового окна к другому. Во всех необходимых местах должны быть доступны контекстные инструкции по использованию интерфейса.
  • Гибкость и эффективность использования – в интерфейсе должны быть предусмотрены горячие клавиши (не обязательные к использованию начинающим пользователем) – они часто значительно ускоряют работу опытного пользователя. Иными словами, система должна предоставлять два способа работы – для новичков и для опытных пользователей. Желательно при этом давать возможность пользователю автоматизировать часто повторяющиеся действия.
  • Эстетичный и минимально необходимый дизайн – Окна не должны содержать не относящуюся к делу или редко используемую информацию. Каждый интерфейсный элемент, содержащий бесполезную информацию, играет роль информационного шума и отвлекает пользователя от действительно полезных интерфейсных элементов.
  • Помощь и документация – Несмотря на то, что в идеальном случае лучше, когда системой можно пользоваться без документации, она все равно необходима – как в виде системы помощи, так и, возможно, в виде печатного руководства. Информация в документации должна быть структурирована таким образом, чтобы пользователь мог легко найти нужный раздел, посвященный решаемой им задаче. Каждый такой ориентированный на конкретную задачу раздел должен помимо общей информации содержать пошаговые руководства по выполнению задачи и не должен быть слишком длинным.
    •

    Все эти эвристики могут использоваться при тестировании удобства использования пользовательского интерфейса. Достаточно очевидно, что при тестировании удобства слабо применимы способы автоматизации тестирования при помощи сценариев и подобные методы. Один из наиболее эффективных методов проверки интерфейса на удобство – использование формальной инспекции. Вопросы в бланке инспекции могут быть как общего характера (так, например, можно использовать в качестве вопросов перечисленные выше 10 эвристик), так и вполне конкретными. Например, в работе [10] приводится список контрольных вопросов, которые желательно проверять при тестировании удобства использования Веб-сайтов. С некоторыми изменениями эти вопросы применимы и для обычных оконных интерфейсов.

    19.1.5. Проверка ссылок

    Еще один вид тестирования – проверка ссылок [11]. В больших тестовых комплексах он интегрирован в проверку юзабилити, или же в проверку правильности HTML-кода, но существует и множество простеньких утилит для такого рода проверок. Такое тестирование актуально и для внутренних ссылок (в случае больших и разветвленных порталов), и для внешних – если это, к примеру, каталог сайтов, или просто обычная страница "Ссылки". Пожалуй, такой тест – это один из немногих тестов, специфический для веб-приложений и сайтов. Кроме того, такой тест можно и необходимо периодически проводить на работающем сайте – ведь со временем структура меняется, и некоторые ссылки могут стать неверными.

    19.1.6. Тестирование безопасности

    Отдельно следует отметить тест на безопасность [12]. Это очень важный тип тестов, так как от безопасности сервера зависит практически все – и сам бизнес, и доверие пользователей, и сохранность информации. Правда, в отличие от других тестов, тестирование безопасности следует проводить регулярно. Кроме того, тестированию подвергается не только сам конкретный сайт или веб-приложение, а весь сервер полностью – и веб-сервер, и операционная система, и все сетевые сервисы. Как и в случае других тестов, программа "прикидывается" реальным пользователем-взломщиком и пытается применить к серверу все известные ей методы атаки и проверяет все уязвимости. Результатом работы будет отчет о найденных уязвимостях и рекомендации по их устранению.

    Ошибки, связанные с проверкой корректности ввода, часто довольно сложно обнаружить в большом объеме кода, взаимодействующего с пользователем. Это является основной причиной того, что разработчики используют методологию тестирования приложений на проникновение для их обнаружения. Веб-приложения, однако, не имеют иммунитета и к более традиционным способам атаки. Весьма распространены плохие механизмы аутентификации, логические ошибки, непреднамеренное раскрытие информации, а также такие традиционные ошибки для обычных приложений как переполнение буфера. Приступая к тестированию Веб -приложений, необходимо учитывать все перечисленное, и должен применяться методический процесс тестирования ввода/вывода по схеме "черного ящика" в сочетании (если возможно) с аудитом исходного кода [13].

    Существуют различные инструменты позволяющие производить автоматическое тестирование безопасности, выполняя такие задачи как cross site scripting, SQL injection, включая переполнение буфера, подделка параметра, несанкционированный доступ, манипуляции с HTTP запросами и т.д. [14]

    19.1.7. Нагрузочное тестирование

    Следующим видом тестирования является тест на устойчивость к большим нагрузкам – Load-testing, stress-test или performance test [15]. Такой тест имитирует одновременную работу нескольких сотен или тысяч посетителей (каждый из которых может "ходить" по сайту в соответствии со своим сценарием ), проверяя, будет ли устойчивой работа сайта под большой нагрузкой. Кроме этого, можно имитировать кратковременные пики нагрузки, когда количество посетителей скачкообразно увеличивается – это очень актуально для новостных ресурсов и других сайтов с неравномерной аудиторией. В таком тесте проверяется не только и не столько сам сайт, сколько совместная слаженная работа всего комплекса – аппаратной части сервера, веб-сервера, программного ядра (engine) и других компонентов сайта.

    Основными целями нагрузочного тестирования являются [15]:

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

    В нагрузочное тестирование входят следующие тесты:

    19.1.7.1. Тестирование производительности (Performance testing)

    Задачей тестирования производительности является определение масштабируемости приложения под нагрузкой, при этом происходит [15]:

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

    19.1.7.2. Стрессовое тестирование (Stress Testing)

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

    19.1.7.3. Объемное тестирование (Volume Testing)

    Задачей объемного тестирования является получение оценки производительности при увеличении объемов данных в базе данных приложения, при этом происходит [15]:

  • измерение времени выполнения выбранных операций при определенных интенсивности выполнения этих операций;
  • может производиться определение количества пользователей, одновременно работающих с приложением.
    •

    19.1.7.4. Тестирование стабильности или надежности (Stability / Reliability Testing)

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

    19.1.7.5. Моделирование Транзакций (Transaction Simulation, TS)

    Этот метод используется в большом числе различных продуктов, в частности, в пакетах AppManager и Vivinet Manager компании NetlQ.

    Метод TS основан на использовании программных GUI-роботов (GUI -Graphical User Interface) [17]. GUI-робот – это специальная программа, которая "заставляет" реальное пользовательское приложение работать в автоматическом режиме, без участия самого пользователя (человека). Примерами средств, предназначенных для создания GUI-роботов, являются пакеты Rational Visual Test и Rational Robot компании Rational Software, а также пакет WinRunner компании Mercury Interactive.

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

    Основное достоинство метода TS заключается в том, что он позволяет измерять производительность работы приложения "с точки зрения пользователя" и, при этом, не требует доступа к коду пользовательского приложения [18]. Недостаток же метода в том, что он позволяет измерять время выполнения только рабочих транзакций и не может использоваться для измерения времени выполнения системных транзакций.

    19.1.7.6. Метод "Анализ данных на стороне клиента" (Client Capture, CC)

    Данный метод реализован, например, в программном пакете Vital Suite компании Lucent [17]. Метод основан на извлечении данных о работе приложения из операционной системы компьютера, где установлено пользовательское приложение. Для этого на компьютере пользователя устанавливается специальный Агент, который отслеживает взаимодействие приложения и ОС и, таким образом, получает информацию о доступности и времени реакции пользовательского приложения. Достоинство данного метода в том, что при его использовании нет необходимости модернизировать код приложения. Недостаток – дополнительные накладные расходы на компьютере пользователя (клиента) и ограниченный набор поддерживаемых приложений.

    19.1.7.7. Метод "Анализ Сетевого Трафика" (Network Sniffing, NS)

    Примером такого устройства является NetScout WAN Probes, компании NetScout [17].Он основан на извлечении информации о производительности приложений из сетевого трафика. Для этого в сети устанавливаются специальные Зонды (как правило, аппаратные), которые в режиме реального времени захватывают сетевой трафик, анализируют его и "извлекают" данные о времени реакции приложений, доступности приложения и т.п. АРМ-средства на базе метода "Network Sniffing" выпускаются, в основном, производителями аппаратных анализаторов сетевых протоколов.

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

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

    В настоящее время применяются два способа обеспечения независимости запросов: использование многопоточности и создание распределенных систем [19]. Многопоточность в той или иной форме применяется во всех рассмотренных средствах тестирования. Данный метод не позволяет воспроизводить и в явной форме задавать характер потока запросов (равномерный, пульсирующий и т.д.) и его статистические характеристики (средняя величина интервала времени между последовательными запросами, дисперсия и др.). Величина выделяемого нити кванта времени (а, следовательно, и величина интервала между запросами) зависит от производительности вычислительной системы и ее загруженности, а также от алгоритмов разделения времени, применяемых операционной системой. Непредсказуемые колебания интенсивности генерируемого потока запросов не позволяют достоверно оценить стабильность работы сервера. Увеличение числа нитей повышает уровень независимости запросов, однако конкуренция между нитями снижает ур овень нагрузки, что делает данный подход неприменимым для тестирования высокопроизводительных серверов.

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

    19.1.8. Проверка HTML-кода

    Еще одним типом тестирования является проверка верности HTML-кода страниц сайта [23]. Для такого рода тестирования написано множество утилит – от простых скриптов на Perl до мощных валидаторов, проверяющих весь сайт на соответствие стандартам (а некоторые валидаторы могут в автоматическом режиме исправлять найденные недочеты, например, пропущенные закрывающие теги и т.д.). Часто такие средства встраивают в Веб-редакторы, существуют браузеры с встроенными валидаторами.

    Например, FireBug интегрируется с браузером Firefox, чтобы обогатить инструментарий разработчика [24]. Вы сможете редактировать, отлаживать и исследовать CSS, HTML и JavaScript вживую, на любой веб-странице. Firebug предоставляет возможность делать экспериментальные изменения в HTML и смотреть, как они тут же отображаются на странице, производить мониторинг сетевых запросов.

    В комплекте с IE8 поставляется инструмент "средства разработчика", который, по сути, является аналогом FireBug [25].

    19.1.9. Обзор автоматизации тестирования

    В процессе создания информационных систем нередки ошибки и дефекты – это вполне ожидаемое и нормальное явление, а в условиях ограниченных временных ресурсов и высоких требований к качеству программных продуктов неизбежно возникает необходимость в организации эффективного контроля и управления всем процессом тестирования. Контроль качества ПО невозможен сегодня без автоматизации всех задач тестирования [20].

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

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

    Процесс автоматизации тестирования делится на три этапа [20]:

  • Запись. Сценарий тестирования записывается "на лету" по мере работы пользователя с приложением. Можно также вставить точки верификации (verification points) для проверки ответа системы и сделать сценарии тестирования зависящими от данных, чтобы выполнять один и тот же сценарий с различными наборами входных данных.
  • Улучшение. Добавление кода, выполняющего разнообразные функции. Типичные изменения сценариев тестирования – условное ветвление, рефакторинг и обработка исключительных ситуаций.
  • Воспроизведение. Выполнение сценариев, эмулирующих действия, которые выполнял пользователь приложения при записи теста. Расхождения регистрируются, и тестировщик может сделать вывод о том, хорошо ли функционирует приложение или регрессионное тестирование выявило проблемы.
    •

    Для автоматизации тестирования существует большое количество приложений. Наиболее популярные из них:

  • HP LoadRunner, HP QuickTest Professional, HP Quality Center;
  • Segue SilkPerformer;
  • IBM Rational FunctionalTester, IBM Rational PerformanceTester, IBM Rational TestStudio;
  • AutomatedQA TestComplete.
    •

    HP LoadRunner – программный продукт для автоматизации нагрузочного тестирования широкого набора программных сред и протоколов [21]. Поддерживает SOA, работу с Web-сервисами, Ajax, RDP, SQL, продуктами Citrix, платформы Java, .Net, а также все основные ERP- и CRM-приложения от PeopleSoft, Oracle, SAP и Siebel. Пакет HP LoadRunner включает в себя более 60 мониторов сбора данных о тестируемой инфраструктуре и предоставляет детальную диагностику по работе приложений.

    HP LoadRunner состоит из следующих приложений [22]:

  • Virtual User Generator (VuGen) – служит для разработки нагрузочных скриптов;
  • Load Generator – служит для генерации нагрузки (генерации виртуальных пользователей);
  • Controller – служит для разработки и запуска сценариев нагрузки;
  • Analysis – служит для анализа результатов нагрузочного тестирования.
    •

    Средства от IBM Rational [21]:

  • IBM Rational Robot – универсальное средство автоматизации тестирования общего назначения для команд разработчиков, выполняющих функциональное тестирование клиент-серверных приложений. Дает возможность обнаруживать неполадки в ПО благодаря расширению сценариев тестирования средствами условной логики, позволяющей целиком охватить тестируемое приложение. Robot позволяет создавать сценарии тестирования с вызовом внешних библиотек DLL или исполняемых модулей.
  • IBM Rational Performance Tester – инструмент нагрузочного и стрессового тестирования, с помощью которого можно выявлять проблемы системной производительности и их причины. Позволяет создавать тесты без написания кода и, не требуя навыков программирования. Обеспечивает гибкие возможности моделирования и эмуляции различных пользовательских нагрузок. Выполняет сбор и интеграцию данных о серверных ресурсах с данными о производительности приложений, получаемыми в режиме реального времени.
  • IBM Rational Functional Tester – набор средств автоматизированного тестирования, позволяющих выполнять функциональное и регрессионное тестирование, тестирование пользовательского интерфейса и тестирование, управляемое данными. Инструмент применяет технологию ScriptAssure (бесшовная проверка достоверности динамических данных) и функции поиска соответствия по шаблону, позволяющие повысить устойчивость сценариев тестирования в условиях частых изменений пользовательских интерфейсов приложений. Тестировщики могут выбрать язык сценариев для разработки и настройки тестов: Java в среде Eclipse или Microsoft Visual Basic .Net в среде Visual Studio .Net.
  • IBM Rational Quality Manager – решение для реализации процессов управления тестированием и качеством, поддерживает сотрудничество участников групп по разработке программных продуктов, предоставляя им возможность обмениваться информацией, применять средства автоматизации для сокращения графиков выполнения проектов, а также составлять отчеты по проектным показателям для принятия обоснованных решений. Rational Quality Manager может быть дополнен средством управления ресурсами тестирования Rational Test Lab, обеспечивающим учет ресурсов тестирования (серверов), их бронирование, автоматизацию развертывания тестовой среды на сервере и запуск скриптов тестирования, а также отчетность по использованию ресурсов тестирования.
  • Rational Quality Manager и Rational Test Lab созданы на базе открытой платформы Jazz, которая предоставляет стандартные интерфейсы и удобные возможности для интеграции с решениями партнеров и других производителей.
    •

    19.1.10. Ключевые термины

    Функциональное тестирование, Тестирование пользовательского интерфейса, Ручное тестирование, Сценарии, Тестирования удобства использования, Проверка ссылок, Тестирование безопасности, Нагрузочное тестирование, Тестирование производительности, Стрессовое тестирование, Объемное тестирование, Тестирование стабильности, Моделирование Транзакций, Метод "Анализ данных на стороне клиента", Метод "Анализ Сетевого Трафика", Автоматизации тестирования, Проверка HTML-кода.

    19.2. Отладка Веб-приложений

    19.2.1. Введение

    Отладка – этап разработки компьютерной программы, на котором обнаруживают, локализуют и устраняют ошибки [26]. Чтобы понять, где возникла ошибка, приходится:

  • узнавать текущие значения переменных;
  • и выяснять, по какому пути выполнялась программа.
    •

    Существуют две взаимодополняющие технологии отладки.

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

    Современный процесс веб-разработки включает не только работу с HTML, но и отладку сценариев, и проверку оформления страниц. По этой причине все основные браузеры, под которые производится верстка и оптимизация большинства страниц, включает в себя специальные средства для веб-мастеров.

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

    По состоянию на начало 2010 года, Internet Explorer, Firefox, Safari, Google Chrome, а также Opera имеют отладчики сценариев.

    Internet Explorer имеет три отладчика: Microsoft Visual Studio – самый полный из них, следом за ним следует Microsoft Script Editor (компонент Microsoft Office), и, наконец, свободный Microsoft Script Debugger, который гораздо более простой, чем два других. Бесплатный Microsoft Visual Web Developer Express предоставляет ограниченную версию с отладочной функцией JavaScript в Microsoft Visual Studio. В восьмой версии в IE вместе с инструментами для разработчиков появился встроенный отладчик.

    В Opera также имеется собственный отладчик – Opera Dragonfly.

    Разрабатываемые веб-приложения в Firefox можно отлаживать при помощи расширений Firebug и Venkman.

    В Safari входит отладчик JavaScript WebKit Web Inspector. Этот же отладчик доступен и в других браузерах, использующих WebKit: Google Chrome, Arora, Rekonq, Midori и др.

    Профилирование – сбор характеристик работы программы, таких как время выполнения отдельных фрагментов (обычно подпрограмм), число верно предсказанных условных переходов, число кэш промахов и т. д. [28]. Инструмент, используемый для анализа работы, называют профилировщиком. Обычно выполняется совместно с оптимизацией программы.

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

    Это часто используется, чтобы определить, как долго выполняются определенные части программы, как часто они выполняются, или генерировать граф вызовов (Call Graph). Обычно эта информация используется, чтобы идентифицировать те участки программы, которые работают больше всего. Эти трудоёмкие участки могут быть оптимизированы, чтобы выполняться быстрее. Это – также общая методика для отладки.

    Также выделяют анализ покрытия (Code Coverage) – процесс выявления неиспользуемых участков кода при помощи, например, многократного запуска программы.

    В табл. 19.2 приведено сравнение средств отладки кода страниц разными браузерами [29].

    Сравнение средств отладки кода страниц разными браузерами
    Браузер/функция IE8 Firefox ( Firebug ) Opera Safari Chrome
    Подсветка синтаксиса HTML есть есть есть есть есть
    Свертывание кода есть есть есть есть есть
    Правка HTML есть есть нет нет нет
    Валидатор HTML-кода есть (*) нет нет нет нет
    Очистка кэша есть нет нет нет нет
    Выделение/подсветка всех вхождений кода есть есть есть есть есть
    Вьювер/редактор CSS есть есть есть есть есть
    Подсветка синтаксиса CSS есть есть нет нет нет
    Отключение стилей CSS есть есть нет нет нет
    Создание новых стилей CSS есть есть нет нет нет
    Валидатор CSS есть (*) нет нет нет нет
    Подсветка JavaScript есть нет есть есть нет
    Отладчик JavaScript есть есть есть есть нет
    Точки остановки выполнения скрипта есть есть есть есть нет
    Ручное пошаговое выполнение скрипта есть есть есть есть нет
    Профили JavaScript есть есть нет есть нет
    Выполнение JavaScript есть есть есть есть есть
    Стек вызовов есть есть есть есть нет
    Местные переменные есть есть нет есть нет
    Отслеживание переменных есть есть есть нет нет
    Вьювер для веб-сервиса нет есть нет нет нет
    Переключение режимов совместимости браузера есть нет нет нет нет
    Парковка к границам окна есть есть есть есть есть
    Палитра цветов есть есть(*) нет нет нет
    Вкладки нет есть нет нет нет
    Скорость загрузки страницы (Yslow) нет есть нет нет нет

    * – поддерживается на стороннем веб-сервисе

    Рассмотрим подробнее средства отладки и профилирования Internet Explorer 8 и Mozilla Firefox.

    19.2.2. Отладка и профилирование в Internet Explorer 8

    Рассмотрим, какие же возможности предоставляет IE8, и сравним их с реализацией в других популярных веб-браузерах [29].

    Инструменты для разработчика – Developer Tools – требуются для быстрой проверки кода страницы на его валидность (соответствие веб-стандартам, отсутствие ошибок в синтаксисе), а также для отладки различных сценариев (в основном, из-за распространения AJAX в современном сайтостроительстве это отладка JavaScript) и отображения стилей (CSS, отдельные цвета, шрифты и графика). При этом важно, чтобы данные инструменты были встроены в сам браузер, а не представляли собой отдельное приложение. В IE длительное время не было подобного инструмента, пока в 2007 году не появился отдельный тулбар для разработчиков (IE Developer Toolbar). С его помощью можно было разбирать код страницы (DOM), "на лету" проверять корректность HTML, CSS, RSS, включать отображение линеек масштаба для последующей верстки страниц и многое другое. Кроме этого тулбара, под IE были выпущены еще ряд инструментов – инспектор кода IEWatch, отладчики DebugBar и Fiddler, средства для работы со скриптовыми технологиями Ajaxview и Visual Web Developer Express. Однако в большинстве своем это были решения от сторонних разработчиков браузера, а фирменная панель IE Developer Toolbar иногда замедляла быстродействие браузера.

    19.2.2.1. Состав Developer Tools

    Запуск встроенного в IE8 инструмента веб-разработки осуществляется или через меню (Сервис – Средства разработчика), или с помощью горячей клавиши F12. В отдельном окне откроется двухпанельный редактор. В левой части будет отображаться DOM-структура сайта (секции head, body), а справа – расширенное содержание выбранного фрагмента кода. Developer Tools поддерживает работу по инспекции и отладке HTML, CSS, JavaScript, а также просмотр cookies и кэша браузера (рис. 19.1).

    (рис 19.1) Developer Tools в Internet Explorer 8.0

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

    Developer Tools открываются под каждую открытую в IE8 страницу, поэтому, чтобы не загромождать экран окнами средств разработчика, их можно закреплять (команда Ctrl+P или нажатие на пиктограмму под кнопкой закрытия окна). В этом случае окно будет располагаться во вкладке редактируемой страницы в виде панели (рис. 19.2).

    (рис 19.2) Панель Developer Tools в Internet Explorer 8.0

    Работа с инструментом строится по классической схеме – пользователю нужно выделить фрагмент страницы или участок ее кода, который автоматически будет подсвечен согласно правилам синтаксиса HTML/CSS. Внесение изменений осуществляется простой правкой кода или установкой других значений атрибутов, после чего требуется нажать клавишу Enter. Отмена всех изменений производится или обновлением страницы, или нажатием на кнопку ESC, если требуется отменять правки по частям.

    19.2.2.2. Отладка HTML и CSS

    С помощью средств разработки можно проверять код HTML и каскадные таблицы стилей сайта в том виде, в котором они обрабатываются браузером Internet Explorer, а не в исходном виде. Это особенно удобно в случае с динамическими сайтами, сложными сайтами и сайтами, где применяются платформы ASP или PHP.

    В основной области содержимого используется дерево документо-объектной модели (DOM) сайта, соответствующее структуре, содержащейся в памяти браузера Internet Explorer для отображения сайта. Для перемещения по дереву можно использовать мышь или клавиатуру. Самый быстрый способ найти узел, соответствующий определенному элементу страницы, – использовать функцию "Выбрать элемент щелчком". Используйте эту функцию, чтобы выбрать элемент на странице, и в средствах разработки будет автоматически выбран нужный узел дерева. Также можно использовать поле поиска.

    После выбора элемента в дереве DOM в области свойств справа появятся более подробные сведения о выбранном элементе [30]:

  • Стиль. Команда "Стиль" повышает эффективность отладки CSS, предоставляя список всех правил, применяющихся к выбранному элементу. Правила отображаются в порядке следования. Правила, применяющиеся в последнюю очередь, отображаются в нижней части списка; свойства, которые далее заменяются другими, перечеркиваются; благодаря этому можно лучше понять, каким образом правила CSS влияют на текущий элемент, без сопоставления селекторов вручную. Можно быстро включать и отключать правила CSS, устанавливая или снимая флажок рядом с правилом. Изменения будут сразу же отображаться на странице.
  • Отслеживать стили. Эта команда содержит такие же сведения, что и команда "Стиль", но в данном случае стили группируются по свойствам. Если нужно найти сведения о каком-либо свойстве, используйте команду "Трассировка стиля". Нужно всего лишь найти нужное свойство, щелкнуть значок плюса (+), и на экране появится список всех правил, устанавливающих данное свойство. Правила перечисляются в порядке следования.
  • Раскладка. Команда "Раскладка" предоставляет сведения о макете модели, такие как смещение элементов, их высота и заполнение. Эту команду следует применять при отладке расположения элементов.
  • Атрибуты. Команда "Атрибуты" дает возможность исследовать все определенные атрибуты выбранного элемента. С помощью этой команды также можно изменять, добавлять и удалять атрибуты выбранного элемента.
    •

    После загрузки DOM-структуры сайта пользователь увидит древовидный список структуры тегов на левой панели. Справа же отображаются связанные с ними, соответственно, стили и атрибуты CSS. Например, при выборе в странице тега <div> можно увидеть связанные с таблицей классы CSS и отследить вызываемые параметры цветов, шрифтов, полей, отступов и так далее. Здесь же в разделе "Раскладка" (Layout) будет показано расположение этого элемента на площади страницы с указанием размеров в пикселях и пропорций. Естественно, его можно изменять непосредственно на этой вкладке. В атрибутах отображается список всех зависимостей HTML-кода на странице; к ним можно добавлять собственные из выпадающего списка (рис. 19.3).

    (рис 19.3) Атрибуты в Developer Tools

    Помимо отображения в рамках Developer Tools, расположение HTML-элементов можно увидеть и на самой оригинальной странице. Для этого следует указать в меню "Как векторные" (Outline) показ соответствующих фрагментов – ячеек таблицы, таблиц, элементов DIV-верстки, границ рисунков в относительных, абсолютных, постоянных и перемещенных границах. В результате на странице они будут размечены тонкими зелеными линиями.

    Многие средства разработчика HTML и CSS работают с отдельными элементами веб-страницы. Чтобы выбрать элемент, необходимо выделить на вкладке HTML или при нажатии на кнопку "Выбрать элемент щелчком" в меню "Найти" средств разработчика. После нажатия этой кнопки можно будет с помощью мыши выбрать элемент на веб-странице. На рис. 19.4 показаны результаты выбора элемента.

    (рис 19.4) Результаты выбора элемента в Developer Tools

    Developer Tools позволяет настраивать каскадные стили в режиме реального времени

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

    С помощью вкладки CSS можно понять взаимодействие между таблицами стилей. Она в большей степени полезна для сайтов, на которых используется несколько таблиц стилей. Для переключения между таблицами стилей используйте кнопку выбора таблиц стилей. При выборе таблицы стилей правила и связанные с ними свойства стилей появляются в основной области содержимого. Эта информация сгруппирована по правилам стилей. По умолчанию на этой кнопке отображается первая таблица стилей, на которую ссылается веб-страница. Как показано на рис. 19.5, правила таблиц стилей отображаются под кнопкой выбора таблиц стилей.

    (рис 19.5) Вкладка CSS в Developer Tools

    С помощью средства Layout можно вывести следующие значения:

  • Значения смещений, то есть расстояния между выбранным элементом и его родительскими элементами. Смещения представлены свойствами offsetLeft и offsetTop.
  • Значения величин Margin, Border и Padding, которые соответствуют значениям, установленным на веб-странице. Если в исходном коде веб-страницы значения для этих величин не указаны, используются значения по умолчанию Windows Internet Explorer.
  • Глубже других внутри находятся высота и ширина элемента, которые определяются свойствами offsetHeight и offsetWidth.
    •

    Для каждого атрибута рамочной модели указаны его величина и единица измерения. По умолчанию значения атрибутов рамочной модели указываются в точках; если единица измерения средством "Layout" не показана, значит, величина задана в точках. На рис. 19.6 изображено средство "Layout" вместе с выбранным на панели HTML (слева) элементом.

    (рис 19.6) Раскладка в Developer Tools

    Все изменения, внесенные с помощью средств разработчика, применяются только к внутреннему представлению сайта в браузере Internet Explorer. При обновлении страницы или при переходе на другую страницу вновь откроется исходный сайт. Однако в некоторых случаях может потребоваться сохранить изменения. На вкладках "HTML" и "CSS" нажмите кнопку "Сохранить" для сохранения текущего HTML- или, соответственно, CSS-кода в файл. Помните, что отличия от исходного кода могут быть не только в измененных вами фрагментах, но и в других частях, поскольку в средствах разработчика сайт отображается в соответствии с кодом в Internet Explorer, а не с кодом исходного сайта. Чтобы избежать случайной перезаписи кода, выходные данные сохраняются в виде текста, а в начало файла добавляется комментарий.

    19.2.2.3. Отладка JScript

    Отладка JScript – это важнейший этап в разработке веб-приложений. Благодаря интуитивно понятному упрощенному отладчику JScript средства разработчика позволяют существенно упростить весь процесс отладки JScript. Установив Internet Explorer 8, разработчики могут отлаживать JScript на любом сайте, загруженном в Internet Explorer (рис. 19.7).

    Developer Tools может использоваться также и как отладчик JavaScript. Для его запуска нужно перейти во вкладку "Сценарий" (Script) и нажать на кнопку Start Debugging. В результате произойдет перезагрузка текущей страницы в открытой вкладке (если в настройках браузера запрещена отладка скриптов), а Developer Tools "открепятся" от нижней части экрана. Остановка процесса отладки производится по нажатию на клавиатурное сочетание Shift+F5 или нажав на кнопку Stop Debugging.

    (рис 19.7) Отладка в Developer Tools

    Консоль JavaScript-кода может отслеживать вызов тех или иных переменных, выражений и стеков вызовов.

    В ходе процесса возможна установка контрольных точек автоматической остановки выполнения – для этого нужно выделить нужное место в коде скрипта, после чего нажать на кнопку F9. Есть также и запуск отладчика с пропуском ошибок исполнения (во избежание остановок) – для этого можно или щелкнуть по кнопке "Остановка при ошибке" или же продублировать это действие командой Ctrl+Shift+E. Кроме того, в случае, если установленная контрольная точка становится неактуальной (код на странице поменялся, указан неправильный путь до сценария и так далее), то в отладчике можно задать условия, при которых будет выполняться остановка (устанавливается в свойствах точки остановки). Наконец, в случае, когда выполнение сценария приостановлено, пользователь может вручную продолжить работу отладчика (кнопка F5), остановить процесс (Ctrl+Shift+B), перейти на следующий этап (F11) или предыдущий шаг (F10), повторить последний цикл скрипта до текущего состояния (Shift+F11).

    Любая ошибка во время выполнения приводит к тому, что отладчик автоматически останавливается в месте возникновения ошибки [30]. Windows Internet Explorer остановится и выделит строку, вызвавшую ошибку, в окне просмотра исходного кода.

    Примечание. Пока Windows Internet Explorer ожидает ввода от отладчика сценариев, он не отвечает ни на какие воздействия пользователя.

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

    На вкладке Breakpoints изображен список всех доступных точек останова. На рис. 19.8 показана вкладка Breakpoints, выбранная в правой части панели отладчика.

    (рис 19.8) Вкладка "Точки останова" в Developer Tools

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

    Примечание. Даже если перейти со страницы текущего веб-узла, Windows Internet Explorer сохранит информацию о точках останова до тех пор, пока не будут закрыты средства разработчика.

    Консоль JavaScript-кода может отслеживать вызов тех или иных переменных, выражений и стеков вызовов. Все полученные результаты могут протоколироваться. Еще одна полезная для веб-разработчика функция в Developer Tools связана с измерением производительности JavaScript на страницах. Под страницу могут создаваться специальные профили, которые показывают, какое количество времени было затрачено на исполнение того или иного сценария, а также число вызовов его при открытии страницы. Соответственно, под каждый сеанс будут создавать соответствующие отчеты, которые можно экспортировать в CSV-файл. Помимо этого, профили можно сохранять для сравнения между разными версиями кода.

    В любой момент, когда исполнение сценария приостановлено точкой останова, можно просмотреть значения переменных. С помощью средства Locals отладчика можно вывести имена, значения и типы всех переменных, существующих в текущей области видимости сценария. Значения переменных вне области видимости не определены. Область видимости – это интервал, в котором можно обращаться к некоторой переменной. На рис. 19.9 показан вид средства Locals во время отладки.

    (рис 19.9) Средства "Локальные" в Developer Tools

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

    (рис 19.10) Средства "Смотреть" в Developer Tools

    Еще один способ добавить точку наблюдения переменной – щелкнуть текст "Click to add…" в окне Watch и ввести имя переменной.

    Заметим, что функция профилирования JavaScript добавляет к функциональности отладчика возможность оптимизации кода. Иными словами, Developer Tools содержат инструмент, позволяющий выявить "узкие места" в веб-приложениях – обычно это наиболее часто используемые скрипты. Для этого вебмастеру необходимо инициировать процесс профилирования, чтобы увидеть скорость обработки сценариев. Результат будет представлен в виде списка последовательных вызовов скрипта или отдельных его функций. Чтобы увидеть URL, который относится к данному фрагменту и строку на странице, в IE8 должен быть включен отладчик сценариев.

    19.2.2.4. Профилирование JavaScript

    Благодаря профилированию сценариев можно улучшить работу веб-сайта посредством идентификации и исправления связанных с производительностью проблем в коде JavaScript (JScript) [30].

    Режим Profiler позволяет собрать информацию о временных характеристиках работы веб-узла, которая собирается по мере визуализации страниц веб-узла обозревателем Windows Internet Explorer. Данная информация помогает оптимизировать участки кода, на исполнение которых уходит слишком много времени, то есть узкие места.

    На вкладке "Профили" начните сеанс профилирования сценария нажатием кнопки "Запуск создания профилей". При этом обработчик сценариев переключается в режим профилирования, и на кнопке появляется текст "Остановка создания профилей". Выполните сценарий, который хотите профилировать на веб-странице. Щелкните "Остановка создания профилей" для завершения сеанса. Автоматически отображается отчет о только что созданном профиле.

    На рис. 19.11 показан основной пользовательский интерфейс вкладки "Профили".

    (рис 19.11) Вкладка "Профили" в Developer Tools

    Отчеты о профилях можно просматривать в представлении "Функции" или "Дерево вызовов", которое можно выбрать из раскрывающегося списка "Текущее представление".

  • В представлении "Функции" перечисляются все используемые функции.
  • В представлении "Дерево вызовов" показана иерархия вызовов.
    •

    В отчете показаны функции, использовавшиеся обозревателем Windows Internet Explorer для визуализации URL-адреса. Выводится название функции, число ее вызовов, включительное и исключительное время. Включительное время – это время, затраченное на исполнение самой функции и всех функций, из нее вызванных. Исключительное время – это время, затраченное на исполнение самой функции без учета функций, из нее вызванных.

    С помощью собранной профилировщиком информации легко найти узкие места в коде вашего веб-узла. Если обнаружить и изменить структуру неэффективного кода или медленных алгоритмов, то можно сократить время, которое обозреватель Windows Internet Explorer тратит на визуализацию веб-страниц.

    Данные профиля можно экспортировать из текущего отчета в CSV-файл.

    19.2.2.5. Другие возможности Developer Tools

    При создании средств разработчика в IE8 Microsoft учла современные требования к подобным инструментам. В частности, особое внимание было уделено к юзабилити решения. Так, в Developer Tools поддерживается полнотекстовый поиск фрагментов HTML (окно поиска расположено в верхнем правом углу окна), а также быстрый поиск всех вхождений тега на основе совместимых с W3C-стандартами селекторов (например, "@table"). Просмотр с помощью Developer Tools включен в контекстное меню IE8. В Developer Tools модули подгружаются по мере необходимости и под конкретную страницу, не затрагивая производительность IE8 на других открытых вкладках.

    Среди прочих возможностей Developer Tools есть расширенные инструменты работы с рисунками (показ путей, размеров, отчетов об изображениях, блокировка их на странице), ссылками на странице (генерация отчета обо всех внешних и внутренних гиперссылках с их атрибутами), кэшем браузера (просмотр и удаление cookies сайта или страницы, политика обновления кэша обозревателя для страницы или всего домена), а также полезные для верстальщика линейка масштаба, палитра цветов и подгонка страницы по определенное разрешение (есть предустановки под стандартные 800*600 и 1024*768 пикселей и возможность задать свой произвольный размер). Кроме того, рядом расположен переключатель отображения веб-документа под разные версии IE – режим совместимости с IE7/IE8, а также более старшими билдами браузера.

    Developer Tools являются удобным и эффективным инструментом для решения повседневных задач веб-мастера. В отличие от плагинов, которые загружают дополнительно не без того ресурсоемкий процесс любого браузера (этим особенно отличаются браузеры на движке Gecko, работающие под Windows), решение от Microsoft выглядит достойной и современной альтернативой.

    19.2.3. Отладка и профилирование в Firebug

    Firebug – расширение для браузера Firefox, являющееся консолью, отладчиком, и DOM-инспектором JavaScript, DHTML, CSS, XMLHttpRequest. Firebug показывает в консоли вызвавшую ошибку функцию, стек вызовов функций, вызвавших эту ошибку. Он предупреждает, что CSS-правило или JavaScript-метод/свойство, которое вы пытаетесь использовать, не существует [24].

    Основные возможности Firebug:

  • Удобный просмотр HTML-кода страницы. Функция Inspect позволяет точно определить местонахождение тега того или иного элемента, просмотреть все "привязанные" к нему свойства и стили.
  • Редактирование HTML и CSS прямо в браузере. Можно изменять атрибуты тегов и значения свойств для того, чтобы пронаблюдать изменения. Удобно для тех случаев, когда нужно путём экспериментов найти наиболее приемлемый вариант оформления создаваемой страницы.
  • Отладка JavaScript.
  • Отслеживание процесса загрузки страницы.
  • Просмотр HTTP-заголовков обычных и AJAX-запросов.
    •

    Firebug вызывается также при нажатии на клавишу F12 или при нажатии на изображение "жука" в статус баре браузера (рис. 19.12).

    (рис 19.12) "Жук" в статус баре браузера

    При нажатии на Control+F12 (или Command+F12 для Mac) Firebug откроется в отдельном окне (рис. 19.13).

    (рис 19.13) FireBug в отдельном окне

    Firebug, как и Developer Tools, можно "прикреплять" к инспектируемой странице (рис. 19.14).

    (рис 19.14) FireBug в виде панели браузера

    19.2.3.1. Отладка HTML и CSS

    В Firefox есть окно "View Source", но оно не покажет, как HTML выглядит на самом деле, после трансформаций JavaScript. Вкладка HTML в Firebug показывает, как HTML выглядит в данный момент времени.

    В дополнение, вкладки справа позволят выяснить свойства индивидуальных элементов, включая правила CSS, которые их стилизуют, размер и позицию в пикселях, и свойства DOM, к которым есть доступ из JavaScript.

    В любом сайте, основанном на JavaScript, HTML-элементы все время создаются, удаляются и изменяются. Firebug подсвечивает изменения HTML желтым цветом, как только они происходят.

    Firebug дает возможность делать изменения в HTML и смотреть, как они тут же отражаются на странице. Можно создавать, удалять или редактировать HTML-атрибуты и текст, просто кликая на них и табом перемещаясь от одного к другому (рис. 19.15). Изменения применяются мгновенно, в момент печати.

    (рис 19.15) Изменение HTML-атрибутов в FireBug

    Помимо этого Firebug позволяет редактировать HTML-исходник любого элемента, нажав правой кнопкой на элементе и выбрав "Edit HTML..." в меню.

    При помощи функции "Inspect" в панели Firebug можно, выделив мышью по странице элемент, увидеть его HTML и CSS (рис. 19.16).

    (рис 19.16) Выделение элемента на странице с помощью FireBug

    Firebug предоставляет инструменты для отладки CSS. Firebug показывает правила, которые работают в CSS, стилизуя каждый элемент (рис. 19.17). Правила отсортированы в восходящем порядке, и overridden-свойства вычеркнуты. У каждого правила есть ссылка на файл, из которого оно пришло.

    (рис 19.17) Выделение элемента на странице с помощью FireBug

    Редактирование CSS происходит также как и HTML (рис. 19.18). Во время печати, изменения тут же применяются к странице.

    (рис 19.18) Редактирование CSS с помощью FireBug

    При желании можно добавить новое CSS свойство (рис. 19.19).

    (рис 19.19) Добавление CSS-свойства с помощью FireBug

    Можно также отключать некоторые CSS свойства (рис. 19.20).

    (рис 19.20) Отключение CSS-свойства с помощью FireBug

    Вкладка "Макет" (Layout) визуально разбивает каждый контейнер в контейнерной модели и дает ширину каждого ребра (рис. 19.21). Дополнительно, она показывает ширину и высоту внутреннего контейнера, и сдвиги по x и y относительно родителя.

    (рис 19.21) Вкладка "Макет" в FireBug

    Двигая мышью по контейнерам во вкладке Layout, на странице появляются линейки и направляющие (рис. 19.22).

    (рис 19.22) Линейки и направляющие на HTML-странице

    Линейки окружают родителя текущего элемента, относительно которого заданы CSS-свойства left, top, bottom и right. Направляющие касаются каждого края элемента и являются отличным способом показать с точностью до пикселя, насколько точно сведены края нескольких контейнеров.

    Как и всякую другую вкладку Firebug, вкладку Layout можно редактировать.

    19.2.3.2. Отладка JavaScript

    Firebug содержит мощный JavaScript-отладчик, который дает Вам возможность приостановить выполнение в любой момент и просмотреть каждую переменную на этот момент.

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

    (рис 19.23) Выбор скриптового файла в FireBug

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

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

    Firebug позволяет Вам устанавливать "условные" брейпкойнты (рис. 19.24). Они проверяют выражение, которое должно быть истинным, чтобы брейкпойнт сработал.

    (рис 19.24) Точки останова в FireBug

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

    Также Firebug дает возможность заходить в отладчик автоматически, когда происходит ошибка (рис. 19.25).

    (рис 19.25) Отладчик в FireBug

    Когда отладчик приостанавливает выполнение, Firebug показывает стек вызова, т.е. набор вложенных вызовов функций, которые сейчас запущены и ждут возврата. Стек вызовов представлен компактной полоской кнопок в панели, каждая – с именем функции в стеке.

    19.2.3.3. Профилирование

    Чтобы использовать профилировщик, необходимо зайти во вкладку Console и кликнуть кнопку "Profile". После этого можно увидеть детальный отчет, который показывает, какие функции были вызваны и сколько времени заняла каждая (рис. 19.26).

    (рис 19.26) Профилирование в FireBug

    Помимо этого у каждого файла во вкладке "Сеть" (Net) есть полоска, которая показывает, когда началась и закончилась загрузка, относительно других файлов. Полоски могут показать, например, что JavaScript файлы загружаются по очереди, и никогда – параллельно. Это поможет оптимизировать порядок файлов на странице, чтобы пользователь проводил меньше времени, ожидая показа страницы. Также в панели Net можно фильтровать список по типам файлов (JavaScript, картинки и др.).

    (рис 19.27) Вкладка "Сеть" в FireBug

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

    Плюс ко всему Firebug показывает каждый XMLHttpRequest (например, используемые AJAX), и во вкладке Net, и в Console, вместе с текстом, который был отправлен и получен (рис. 19.28).

    (рис 19.28) XMLHttpRequest в FireBug

    19.2.4. Ключевые термины

    Отладка, Профилирование, Internet Explorer Developer Tools, Firebug.

    19.3. Краткие итоги

    Функциональное тестирование – процесс верификации соответствия функционирования продукта его начальным спецификациям.

    Методы функционального тестирования веб-приложений:

  • Record Play;
  • Functional Decomposition;
  • Data-driven;
  • Keyword-driven;
  • Object-driven;
  • Model-based.
    •

    Функциональное тестирование пользовательского интерфейса состоит из пяти фаз:

  • анализ требований к пользовательскому интерфейсу;
  • разработка тест-требований и тест-планов для проверки пользовательского интерфейса;
  • выполнение тестовых примеров и сбор информации о выполнении тестов;
  • определение полноты покрытия пользовательского интерфейса требованиями.
  • составление отчетов о проблемах в случае несовпадения поведения системы и требований, либо в случае отсутствия требований на отдельные интерфейсные элементы.
    •

    Тестирование удобства пользования дает оценку уровня удобства использования приложения по следующим пунктам:

  • производительность, эффективность;
  • правильность;
  • активизация в памяти;
  • эмоциональная реакция;
    •

    В нагрузочное тестирование входят следующие тесты:

  • Тестирование производительности ;
  • Стрессовое тестирование ;
  • Объемное тестирование ;
  • Тестирование стабильности или надежности;
  • Моделирование Транзакций ;
  • Метод "Анализ данных на стороне клиента" ;
  • Метод "Анализ Сетевого Трафика" ;
    •

    Другие виды тестирования Веб-приложений: проверка ссылок, тестирование безопасности, проверка верности HTML-кода.

    Процесс автоматизации тестирования делится на три этапа [20]:

  • Запись;
  • Улучшение;
  • Воспроизведение;
    •

    Для автоматизации тестирования существует большое количество приложений.

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

    Профилирование – сбор характеристик работы программы, таких как время выполнения отдельных фрагментов (обычно подпрограмм), число верно предсказанных условных переходов, число кэш промахов и т. д.

    Internet Explorer Developer Tools, входящий в комплект IE8 – инструмент для разработчика, требующийся для быстрой проверки кода страницы на его валидность, а также для отладки различных сценариев и отображения стилей.

    Firebug – расширение для браузера Firefox, являющееся консолью, отладчиком, и DOM-инспектором JavaScript, DHTML, CSS, XMLHttpRequest.

    Предыдущее занятие Следующее занятие
    Вернуться к учебному плану
    ^