Home

Testing web-based Applications, Analyzing and reproducing errors in a Web environment

Источник: StickyMinds.Com, "Testing&Quality" magazine
Автор: Hung Nguyen

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

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

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

Давайте рассмотрим эти 5 утверждений более детально:

1. Что мы видим на самом деле, ошибку или симптом?

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

Вот пример. Я тестирую web-приложение для отслеживания дефектов и нахожусь в процессе создания нового сообщения об ошибке. При нажатии NEW , появляется сообщение об ошибке, выглядящее следующим образом:

Microsoft OLE DB Provider for ODBC Drivers error '8004014'.

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

2. Является ли ошибка зависимой от среды?

Чтобы воспроизвести зависимую от среды ошибку, нам необходимо идеально дублировать как точную последовательность действий, так и условия среды, в которой и будет работать приложение (операционной системы, версии браузера, дополнительных компонентов, сервера базы данных, web-сервера, третьестепенных компонентов, серверных/клиентских ресурсов, пропускной способности сети, трафика и т.д.). К примеру, если вы пытаетесь войти в ваше web-приложение, используя диал-ап соединение на скорости 28.8 кб/с, вы будете сталкиваться со сбоями в регистрации до тех пор, пока процесс авторизации не прервется в связи с истечением выделенного для этой цели времени. Однако регистрация в сети, проведенная в таком же порядке, но с использованием подключения T-1 на скорости 1.54 Мб/с, пройдет успешно. В этом случае вы имеете зависимую от среды ошибку, где зависимость связана с пропускной способностью сети.

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

3. Что это, ошибка кодировки или проблема конфигурации?

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

Microsoft OLE DB Provider for ODBC Drivers error '80004005'

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

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

Виртуальная директория web-сервера (IIS) не была установлена должным образом.

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

Директория приложения не была сконфигурирована как следует для корректного выполнения скриптов.

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

Установленная по умолчанию web-страница не была установлена должным образом.

Неполадка аналогична проблеме, описанной выше.

SQL Server неактивен.

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

Объекты DLL/COM отсутствуют или не были успешно зарегистрированы.

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

Возможно, инсталляционная программа правильно скопировала все необходимые модули, но не смогла зарегистрировать один или более из их числа. К примеру, в таких объектах, базирующихся на OLE, как COM или DCOM , их классовый ID (CLSID) должен быть зарегистрирован в базе данных системного реестра, прежде чем они станут доступными к использованию. Если приложение пытается получить доступ к COM объекту, который не был успешно зарегистрирован, то оно не будет работать.

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

Установки JavaScript со стороны браузера были дезактивированы.

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

4. Какой же уровень действительно создает проблему?

Зачастую ошибки в web-системах сложно воспроизвести последовательно, так как большое кол-во переменных представлено распределенным характером структуры системы клиент/сервер. Существует как минимум 3 «обычных подозреваемых» в web-окружении. Это клиент, сервер и сеть.

И клиент, и сервер являются носителями несоответствий конфигурации и совместимости, которые подобны окружениям ПК, где все компоненты находятся «в одной коробке». Однако эти несоответствия приумножаются в рамках систем клиент/сервер, потому как к сети может быть подключено множество клиентов и серверов. Типичные несоответствия конфигурации и совместимости приводит к смешению технического обеспечения и операционной системы (например, блоки, базирующиеся на UNIX в противовес таковым, базирующимся на Windows ) и смешению программного обеспечения со стороны сервера (web-серверные пакеты, пакеты сервера базы данных, брандмауэры, COM объекты, CORBA объекты и т.д.). Несоответствия могут также привести к смешению программного обеспечения со стороны клиента (очереди TCP/IP, ПО дозвона, компоненты помощи, брэнды браузеров и их версии). В дополнение, такие установки браузера, как общие настройки, настройки соединений, настройки безопасности (включая ActiveX контроллеры, дополнительные программные модули (плагины), Java , скрипты, загрузки, авторизацию пользователя и т.д.), настройки содержания, программные настройки и другие расширенные настройки (включая опции просмотра, мультимедийные опции, опции Java VM , опции печати и HTTP опции), предоставляют множество переменных, которые должны быть протестированы и включены в исследования.

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

5. Статические и динамические операционные среды отличаются друг от друга.

Существует 2 класса операционных сред, каждая из которых обладает своими собственными уникальными тестовыми включениями:

Статические среды (Static Environments), в которых проблемы несовместимости могут существовать независимо от таких переменных условий, как скорость обработки данных и доступная память.

Динамические среды (Dynamic Environments). В них все наоборот - совместимые компоненты могут выявлять ошибки в соответствии с зависимыми от памяти ошибками и скрытыми условиями. (Мы обсудим динамические среды более детально далее в этом разделе).

Статическая операционная среда (Static Operating Environment): конфигурация и переменные совместимости.

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

Проблемы конфигурации затрагивают различные установки программного и технического обеспечения сервера, настройки браузера, соединения сети и настройки TCP / IP очередей. Пример с настройками браузера и JavaScript , рассмотренный ранее, иллюстрировал один тип конфигурационной проблемы. Другой тип показан на Схеме 1 и Схеме 2. Они представлены в двух возможных физических серверных конфигурациях: одно- и двухблочной.

Схема 1: Web-сервер, сервер приложений и сервер баз данных на одной платформе

Схема 2: WEB-сервер и сервер приложений на одной платформе, сервер баз данных на другой

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

1. Подключение к серверу базы данных и осуществление запроса.

2. Запись результата запроса в виде файла с названием c:\temp\chart.val

3. Выполнение Chart Java Applet. Считывание и использование данных из файла c:\temp\chart.val для возможности нарисовать график.

4. Отправка Java Applet браузеру.

В процессе тестирования приложения мною было обнаружено, что особенностью в построении графика была работа только с одной из вышеуказанных конфигураций. В результате дальнейшего рассмотрения стало ясно, что проблема относилась только к двухблочной конфигурации. После проверки кода выяснилось, что проблема заключалась в пунктах 2 и 3. Во втором пункте результат запроса c:\temp\chart.val был записан налокальный дисковод сервера базы данных. В третьем пункте Chart Java Applet был запущен на сервере приложений, который находился на разных с сервером базы данных блоках. При попытке открыть файл c:\temp\chart.val на локальном дисководе сервера приложений оказывается, что этого файла там просто-напросто нет.

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

Проблемы соответствия также важны в статических операционных средах. В виде примера можно рассмотреть Схему 3, где мы видим различие в совместимости между Netscape Navigator и Internet Explorer.

Схема 3: Проблема совместимости браузеров

Это никоим образом не значит, что Internet Explorer лучше, чем Netscape Navigator. Это всего лишь значит, что между браузерами бывают проблемы несоответствия, и что код может не предполагать работу относительных путей (к файлу) для всех браузеров. Что еще важнее, это означает, что если вы сталкиваетесь с ошибкой в одной среде, в другой среде она может не возникнуть, при условии, что это ошибка, зависимая от среды.

Динамическая операционная среда (Dynamic Operating Environment): вещи не остаются неизменными.

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

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

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

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

Требования спецификации:

1. Названия проектов в пределах системы должны быть уникальны.
2. Определение ошибок и обработка для потенциального копирования со стороны клиента должны быть представлены с использованием JavaScript.
3. Пользователи могут добавлять или удалять названия проектов, запрашивая страницу Setting Up Projects.
4. Когда пользователь создает новое проектное название, JavaScript со стороны браузера проверяет вводимое имя относительно выборочного списка, расположенного на HTML странице (как показано на Схеме 4)

Посмотрите на связанную со временем ошибку, показанную на Схеме 5. Эти скриншоты страницы Setting Up Projects, сделанные до и после, позволяют нам увидеть, что приложению не удалось определить дублированное название "Doomed". В Схеме 4 приводится объяснение этой связанной со временем ошибки, которая приводит к тому, что оба пользователя добавляют новые проектные названия в одну и ту же базу данных.

Схема 4: Java-script на стороне браузера проверяет введённые значения

Схема 5: Ошибка связанная со временем

Как показано в Таблице 1, пользователь А и пользователь В создают новые проекты хоть и одновременно, но без ведома о действиях друг друга. В соответствии с пунктом 3, пользователь А добавляет проект под названием Another. Но так как такое имя уже существует, JavaScript его браузера отображает сообщение, подсказывающее ему использовать другое название.

Таблица 1: Активности пользователей А и В
[ открыть крупнее ]

Пользователь В добавляет проектное название Doomed. JavaScript ее браузера не определяет его как существовавшее ранее, а потому добавляет название как в базу данных, так и в возвратный список. Обновленный список проектных названий отправляется обратно пользователю В.

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

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

Заключение

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

Помните, что ничто не сможет заменить ваши навыки тестирования и ваше умение предлагать хорошие контрольные примеры. Не бойтесь спрашивать «А что если...?», делайте подробные заметки и методично исследуйте тяжело воспроизводимые ошибки. Это как раз те навыки, которые будут вашими помощниками не только в изучении ошибок, но и в нахождении других неполадок, с ними связанных.