Аннотация. Статья рассказывает о подходе к тестированию Web-приложений, основанных на скриптовых языках, позволяющем за короткое время создать достаточно качественный набор тестов. Описываемый подход основан на анализе исходного кода (т.е. относится к методам тестирования на основе «белого ящика») и использует некоторые особенности кода приложений, предназначенных для работы в Web. Рассматриваются возможные процедуры вынесения вердикта об успешности прохождения теста, не требующие вмешательства человека. Также описано применение предложенной методики к тестированию LSB Навигатора — Web-инструмента для просмотра и анализа содержимого спецификационной базы данных стандарта Linux Standard Base, разрабатываемого в ИСП РАН в рамках совместного проекта с Linux Foundation.

Содержание

1. Введение

2. Существующие подходы к тестированию Web-приложений

3. Использование исходного кода для генерации тестов

3.1. Извлечение имен параметров и их значений

3.2. Зависимости параметров

4. Вынесение вердикта о правильности работы приложения

4.1. Ошибки взаимодействия с внешними системами

4.2. Соответствие спецификации XHTML

4.3. Анализ лог-файлов Web-сервера

5. Тестирование LSB Навигатора

5.1. Анализ кода

5.2. Генерация тестов

5.3. Вынесение вердикта

5.4. Результаты

6. Заключение

Литература

1. Введение

В настоящее время все большее распространение получают приложения, взаимодействующие с пользователем посредством Web-интерфейса. Такие приложения не занимаются непосредственно отображением пользовательского интерфейса, а перекладывают эту задачу на посредника — как правило, в этой роли выступает Web-браузер, получающий от приложения документы в формате HTML [1], отображающий их в своем окне, и передающий приложению информацию о различных действиях, совершаемых пользователем. В зависимости от этих действий приложение создает и передает Web-браузеру новую страницу HTML, и работа продолжается дальше.

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

Для написания программ, генерирующих страницы HTML с использованием данных из внешнего хранилища, широко используются скриптовые языки программирования [2], например, Perl и PHP. Такие языки являются интерпретируемыми, что позволяет программистам не беспокоиться о том, на какой программно-аппаратной платформе будет работать приложение (естественно, при условии, что для данной платформы существует интерпретатор соответствующего языка).

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

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

2. Существующие подходы к тестированию Web-приложений

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

Существует много решений, позволяющих записывать сценарии поведения пользователя (т.е. цепочку ссылок, по которым осуществлялся переход) — IBM Rational Robot [3], HP WinRunner [4], Empirix e-TEST [5] и другие. Записанный единожды сценарий может далее воспроизводиться автоматически. Однако создание сценариев — трудоемкое занятие, причем отдельной задачей является анализ требований к приложению с целью определить, какие именно сценарии должны быть созданы для обеспечения хорошего качества тестирования. Некоторые инструменты (например, компонент PureAgent в системе PureTest [6]) позволяют создавать сценарии на основе действий реальных пользователей, работающих с приложением. Однако и при таком подходе при достаточно большом количестве пользователей встает вопрос о выборе из множества возможных сценариев относительно небольшого набора, который, тем не менее, обеспечит хорошее качество тестирования.

Существуют инструменты, позволяющие автоматически генерировать ссылки для обращения к приложению по протоколу HTTP, получать соответствующие страницы и производить их анализ. Однако при генерации ссылок также обычно применяется подход «черного ящика» — исходный код приложений не анализируется, а ссылки, которые необходимо генерировать, должен описать тестировщик с использованием специфических для каждого инструмента средств. Например, eValid [7] позволяет перебирать значения параметров для скриптов, которые будут подставляться в создаваемые ссылки, но список параметров с возможными значениями для каждого скрипта должен составлять тестировщик. При достаточно большом количестве скриптов и параметров создание такого списка потребует много времени; кроме того, список должен постоянно поддерживаться в актуальном состоянии — тестировщик должен следить за изменением состава скриптов и их параметров. Инструмент Puffin [8] позволяет генерировать для параметров произвольные значения, однако такой подход во многих случаях сильно снижает качество тестирования по сравнению с ручным заданием значений. В случае Puffin, опять же, список имен параметров должен составлять и поддерживать тестировщик. Кроме того, существующие инструменты не предоставляют удобных средств для перебора различных комбинаций параметров, а во многих случаях интерес представляет именно перебор комбинаций, поскольку разные сочетания параметров могут задействовать различные части приложения.

Многие инструменты анализируют получаемые в процессе тестирования страницы, извлекая из них ссылки на другие части приложения и имитируя переход по ним (опять же, с дальнейшим анализом получаемых страниц; например, для таких целей предназначен компонент 'Web Crawler', входящий в PureTest). Таким образом, осуществляется переход по всем ссылкам, которые могут быть достигнуты, начиная с определенной страницы. Поскольку все части приложения, как правило, взаимосвязаны, то в идеале, начав с некоторой стартовой страницы и посетив все достижимые из нее ссылки, можно протестировать всю функциональность приложения, доступную пользователю. Однако число ссылок может быть чрезвычайно велико, и лавинообразно расти с увеличением числа посещенных страниц. К сожалению, современные средства перехода по ссылкам достаточно примитивны и просто осуществляют переходы по всем встреченным ссылкам (ввиду чего они часто используются при нагрузочном тестировании [9]). Настройка либо доработка инструментов для более «интеллектуального» выбора ссылок, по которым надо осуществлять переходы, требует тщательного анализа самого приложения.

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

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

В качестве альтернативы предлагаются менее строгие проверки; так, уже упоминавшийся eValid позволяет производить более 20 сравнений, среди которых можно отметить следующие:

• 'URL' — проверка ссылки, на которой оказался пользователь после совершения определенных действий, записанных в сценарии;

• 'Title' — проверка названия страницы;

• 'Elements' — проверка числа элементов в DOM-модели страницы;

• 'Byte Size' — проверка размера страницы;

• 'Last Modified Date' — проверка даты последнего изменения страницы;

• 'Checksum' — проверка контрольной суммы для текста страницы;

• 'Text' — проверка выделенных участков текста страницы;

• 'Screen Rectangle' — сравнение изображения определенного участка страницы с тем, что наблюдал тестировщик во время записи сценария.

Остальные проверки являются вариациями проверки части страницы как изображения либо являются комбинациями указанных проверок.

Можно отметить, что несмотря на достаточно большое количество доступных проверок, ни одна из них не пригодна в случае, когда изменяется содержательная часть страницы — часть проверок (такие, как 'Title' и 'URL') могут вообще не зависеть от этой составляющей документа, а другие ('Byte Size', 'Checksum', 'Screen Rectangle') с большой вероятностью сообщат об ошибке (т.е. об отличии полученного на новых данных результата от эталонного), но такие сообщения скорее всего не будут свидетельствовать о реальном нарушении функциональности приложения.

Существуют и более сложные подходы к разработке тестов для Web-приложений, позволяющие абстрагироваться от различных аспектов, связанных непосредственно с языком разметки HTML, и генерировать тесты на основе формальной модели данных, передаваемых приложению — см., например, [10]. Однако такие подходы трудоемки и требуют достаточно высокой квалификации тестировщиков.

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