Web-приложение — это клиент-серверное приложение, в котором клиентом выступает браузер, а сервером web-сервер, что уже является по сути двумя разнополыми программами, которые необходимо тестировать как отдельно, так и в связке.
Почти все современные программы ориентированы на работу с сетью. Хранение данных web-приложений осуществляется, преимущественно, на сервере, обмен информацией происходит по сети. Когда мы видим ошибку в сетевой среде, то зачастую сложно точно указать, где именно она произошла, и потому режим работы, или сообщение об ошибке которое мы получаем, может быть результатом ошибок, случившихся в разных частях сетевой системы.
Имея много общего с тестированием классических приложений, тестирование web-ориентированных приложений имеет свои особенности, связанные прежде всего со средой функционирования. Имея компонентные, структурные и технологические особенности, web-приложениям присущи особенности режимов работы, инсталляции, запуска, остановки и удаления, а также формирования интерфейсов. Работая всегда с сетью и с большим количеством пользователей, web-приложения подразумевают под собой разные права доступа для разных пользователей.
Логика web-приложения распределена между сервером и клиентом, хранение данных осуществляется на сервере, обмен информацией происходит по сети.
Одним из преимуществ подхода является тот факт, что клиенты не зависят от конкретной операционной системы пользователя, поэтому web-приложения являются межплатформенными сервисами.
Особенности тестирования web-приложений
Технологические отличия
Классическое приложение работает с использованием одной или семейства родственных технологий.
Web-приложение работает с использованием принципиально различных технологий.
Структурные отличия
Классическое приложение “монолитное”. Состоит из одного или небольшого количества модулей. Не использует серверы БД, web-серверы и т.д.
Web-приложение — “многокомпонентное”. Состоит из большого числа модулей. Обязательно использует серверы БД, web-серверы, серверы приложений.
Отличия режимов работы
Классическое приложение работает в режиме реального времени, т.е. известно о действиях пользователя сразу же, как только оно выполнено.
Web-приложение работает в режиме “запрос-ответ”, т.е. известно о некотором наборе действий только после запроса на сервер.
Отличия формирования интерфейса
Классическое приложение использует для формирования интерфейса пользователя относительно устоявшиеся и стандартизированные технологии.
Web-приложение использует для формирования пользовательского интерфейса стремительно развивающиеся технологии, множество которых конкурирует между собой.
Отличия работы с сетью
Классическое приложение практически не использует сетевые каналы передачи данных.
Web-приложение активно использует сетевые каналы передачи данных.
Отличия запуска и остановки
Классическое приложение запускается и останавливается редко.
Web-приложение запускается и останавливается по факту поступления каждого запроса, т.е. очень часто.
Разница в количестве пользователей
Классическое приложение: количество пользователей, одновременно использующих приложение, подвержено контролю, ограничено и легко прогнозируемо.
Web-приложение: количество пользователей, одновременно использующих приложение, сложнопрогнозируемо и может скачкообразно меняться в широких диапазонах.
Особенности сбоев и отказов
Классическое приложение: выход из строя тех или иных компонентов сразу становится очевидным.
Web-приложение: выход из строя некоторых компонентов оказывает непредсказуемое влияние на работоспособность приложения в целом.
Отличия в инсталляции
Классическое приложение — процесс инсталляции стандартизирован и максимально ориентирован на широкую аудиторию пользователей. Не требует специфических знаний. Добавление компонентов приложения выполняется стандартным способом с использованием одного и того же инсталлятора.
Web-приложение — процесс инсталляции часто недоступен конечному пользователю. Инсталляция требует специфических знаний. Процесс изменения компонент приложения не предусматривается или требует квалификации пользователей. инсталлятор отсутствует.
Отличия в деинсталляции
Классическое приложение: процесс деинсталляции стандартизирован и выполняется автоматически или полуавтоматически.
Web-приложение: процесс деинсталляции требует специфических знаний для вмешательства администратора и часто сопряжен с изменением кода среды функционирования приложения, БД, настройки системного ОС.
Особенности среды функционирования
Классическое приложение: среда функционирования стандартизирована и не сильно влияет на функционирование приложения.
Web-приложение: среда функционирования очень разнообразна и может оказать серьезное влияние на работоспособность и серверной, и клиентской части.
Подходы к функциональному тестированию Веб-приложений
Функциональное тестирование (functional testing) – процесс верификации соответствия функционирования продукта его начальным спецификациям.
Подходы: ручное, с использованием инструментов автоматическоготестирования.
Самым распространенным является подход, называемый Capture & Playback (другие названия – Record & Playback, Capture & Replay). Суть этого подхода заключается в том, что сценарии тестирования создаются на основе работы пользователя с тестируемым приложением. Инструмент перехватывает и записывает действия пользователя, результат каждого действия также запоминается и служит эталоном для последующих проверок. При этом в большинстве инструментов, реализующих этот подход, воздействия (например, нажатие кнопки мыши) связываются не с координатами текущего положения мыши, а с объектами HTML-интерфейса (кнопки, поля ввода и т.д.), на которые происходит воздействие, и их атрибутами. При тестировании инструмент автоматически воспроизводит ранее записанные действия и сравнивает их результаты с эталонными, точность сравнения может настраиваться. Можно также добавлять дополнительные проверки – задавать условия на свойства объектов (цвет, расположение, размер и т.д.) или на функциональность приложения (содержимое сообщения и т.д.).
Тестирование пользовательского интерфейса
Функциональное тестирование пользовательского интерфейса состоит из пяти фаз:
- анализ требований к пользовательскому интерфейсу;
- разработка тест-требований и тест-планов для проверки пользовательского интерфейса;
- выполнение тестовых примеров и сбор информации о выполнении тестов;
- определение полноты покрытия пользовательского интерфейса требованиями.
- составление отчетов о проблемах в случае несовпадения поведения системы и требований, либо в случае отсутствия требований на отдельные интерфейсные элементы.
Так, тест-планы для проверки пользовательского интерфейса, как правило, представляют собой сценарии, описывающие действия пользователя при работе с системой. Сценарии могут быть записаны либо на естественном языке, либо на формальном языке какой-либо системы автоматизации пользовательского интерфейса. Выполнение тестов при этом производится либо оператором в ручном режиме, либо системой, которая эмулирует поведение оператора.
Под полнотой покрытия пользовательского интерфейса понимается то, что в результате выполнения всех тестовых примеров каждый интерфейсный элемент был использован хотя бы один раз во всех доступных режимах.
Тестирование пользовательского интерфейса может проводиться различными методами – как вручную при непосредственном участии оператора, так и при помощи различного инструментария, автоматизирующего выполнение тестовых примеров. Рассмотрим эти методы более подробно.
Ручное тестирование пользовательского интерфейса проводится тестировщиком-оператором, который руководствуется в своей работе описанием тестовых примеров в виде набора сценариев. Каждый сценарий включает в себя перечисление последовательности действий, которые должен выполнить оператор и описание важных для анализа результатов тестирования ответных реакций системы, отражаемых в пользовательском интерфейсе. Типичная форма записи сценария для проведения ручного тестирования – таблица, в которой в одной колонке описаны действия (шаги сценария ), в другой – ожидаемая реакция системы, а третья предназначена для записи того, совпала ли ожидаемая реакция системы с реальной и перечисления несовпадений.
Ручное тестирование пользовательского интерфейса удобно тем, что контроль корректности интерфейса проводится человеком, т.е. основным "потребителем" данной части программной системы.
При этом ручное тестирование имеет и существенный недостаток – для его проведения требуются значительные человеческие и временные ресурсы. Особенно сильно этот недостаток проявляется при проведении регрессионного тестирования и вообще любого повторного тестирования – на каждой итерации повторного тестирования пользовательского интерфейса требуется участие тестировщика-оператора. В связи с этим в последнее десятилетие получили распространение средства автоматизации тестирования пользовательского интерфейса, снижающие нагрузку на тестировщика-оператора.
Естественный способ автоматизации тестирования пользовательского интерфейса – использование программных инструментов, эмулирующих поведение тестировщика-оператора при ручном тестировании пользовательского интерфейса.
Такие инструменты используют в качестве входной информации сценарии тестовых примеров, записанные на некотором формальном языке, операторы которого соответствуют действиям пользователя – вводу команд, перемещению курсора, активизации пунктов меню и других интерфейсных элементов.
При выполнении автоматизированного теста инструмент тестирования имитирует действия пользователя, описанные в сценарии, и анализирует интерфейсную реакцию системы.
И при передаче информации в тестируемый интерфейс и при получении информации для анализа могут использоваться два способа доступа к элементам интерфейса:
- позиционный, при котором доступ к элементу осуществляется при помощи задания его абсолютных (относительно экрана) или относительных (относительно окна) координат и размеров;
- по идентификатору, при котором доступ к элементу осуществляется при помощи получения интерфейсного элемента при помощи его уникального идентификатора в пределах окна.
Тестирование удобства пользования
Тестирование удобства пользования – тест, который можно назвать практически главным для всех интерактивных сервисов, взаимодействующих с пользователем – это тест на "usability" или на удобство использования. Такое тестирование одно из самых дорогих, потому что наиболее ценную информацию можно получить только от реальных пользователей, наблюдая за их работой с вашим сайтом – а такие исследования требуют дорогостоящей инфраструктуры и времени, их сложно автоматизировать. Это метод тестирования, направленный на установление степени удобства использования, обучаемости, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий.
Выделяют следующие этапы тестирования удобства использования пользовательского интерфейса:
- Исследовательское – проводится после формулирования требований к системе и разработки прототипа интерфейса. Основная цель на этом этапе – провести высокоуровневое обследование интерфейса и выяснить, позволяет ли он с достаточной степенью эффективности решать задачи пользователя.
- Оценочное – проводится после разработки низкоуровневых требований и детализированного прототипа пользовательского интерфейса. Оценочное тестирование углубляет исследовательское и имеет ту же цель. На данном этапе уже проводятся количественные измерения характеристик пользовательского интерфейса: измеряются количество обращений к системе помощи по отношению к количеству совершенных операций, количество ошибочных операций, время устранения последствий ошибочных операций и т.п.
- Валидационное – проводится ближе к этапу завершения разработки. На этом этапе проводится анализ соответствия интерфейса программной системы стандартам, регламентирующим вопросы удобства интерфейса, проводится общее тестирование всех компонент пользовательского интерфейса с точки зрения конечного пользователя. Под компонентами интерфейса здесь понимается как его программная реализация, так и система помощи и руководство пользователя. Также на данном этапе проверяется отсутствие дефектов удобства использования интерфейса, выявленных на предыдущих этапах.
- Сравнительное – данный вид тестирования может проводиться на любом этапе разработки интерфейса. В ходе сравнительного тестирования сравниваются два или более вариантов реализации пользовательского интерфейса.
Тестирование удобства пользования дает оценку уровня удобства использования приложения по следующим пунктам:
- производительность, эффективность (efficiency) – сколько времени и шагов понадобится пользователю для завершения основных задач приложения, например, размещение новости, регистрации, покупка и т.д.
- правильность (accuracy) – сколько ошибок сделал пользователь во время работы с приложением
- активизация в памяти (recall) – как много пользователь помнит о работе приложения после приостановки работы с ним на длительный период времени? (повторное выполнение операций после перерыва должно проходить быстрее, чем у нового пользователя)
- эмоциональная реакция (emotional response) – как пользователь себя чувствует после завершения задачи – растерян, испытал стресс. Порекомендует ли пользователь систему своим друзьям.
Проверка ссылок
Еще один вид тестирования – проверка ссылок. В больших тестовых комплексах он интегрирован в проверку юзабилити, или же в проверку правильности HTML-кода, но существует и множество простеньких утилит для такого рода проверок. Такое тестирование актуально и для внутренних ссылок (в случае больших и разветвленных порталов), и для внешних – если это, к примеру, каталог сайтов, или просто обычная страница "Ссылки". Пожалуй, такой тест – это один из немногих тестов, специфический для веб-приложений и сайтов. Кроме того, такой тест можно и необходимо периодически проводить на работающем сайте – ведь со временем структура меняется, и некоторые ссылки могут стать неверными.
Тестирование безопасности
Отдельно следует отметить тест на безопасность. Это очень важный тип тестов, так как от безопасности сервера зависит практически все – и сам бизнес, и доверие пользователей, и сохранность информации. Правда, в отличие от других тестов, тестирование безопасности следует проводить регулярно. Кроме того, тестированию подвергается не только сам конкретный сайт или веб-приложение, а весь сервер полностью – и веб-сервер, и операционная система, и все сетевые сервисы. Как и в случае других тестов, программа "прикидывается" реальным пользователем-взломщиком и пытается применить к серверу все известные ей методы атаки и проверяет все уязвимости. Результатом работы будет отчет о найденных уязвимостях и рекомендации по их устранению.
Существуют различные инструменты позволяющие производить автоматическое тестирование безопасности, выполняя такие задачи как cross site scripting, SQL injection, включая переполнение буфера, подделка параметра, несанкционированный доступ, манипуляции с HTTP запросами и т.д.
Нагрузочное тестирование
Следующим видом тестирования является тест на устойчивость к большим нагрузкам – Load-testing, stress-test или performance test [15]. Такой тест имитирует одновременную работу нескольких сотен или тысяч посетителей (каждый из которых может "ходить" по сайту в соответствии со своим сценарием ), проверяя, будет ли устойчивой работа сайта под большой нагрузкой. Кроме этого, можно имитировать кратковременные пики нагрузки, когда количество посетителей скачкообразно увеличивается – это очень актуально для новостных ресурсов и других сайтов с неравномерной аудиторией. В таком тесте проверяется не только и не столько сам сайт, сколько совместная слаженная работа всего комплекса – аппаратной части сервера, веб-сервера, программного ядра (engine) и других компонентов сайта.
Основными целями нагрузочного тестирования являются:
- оценка производительности и работоспособности приложения на этапе разработки и передачи в эксплуатацию;
- оценка производительности и работоспособности приложения на этапе выпуска новых релизов, патч-сетов;
- оптимизация производительности приложения, включая настройки серверов и оптимизацию кода;
- подбор соответствующей для данного приложения аппаратной (программной платформы) и конфигурации сервера.
В нагрузочное тестирование входят следующие тесты:
Тестирование производительности (Performance testing)
Задачей тестирования производительности является определение масштабируемости приложения под нагрузкой, при этом происходит:
- измерение времени выполнения выбранных операций при определенных интенсивностях выполнения этих операций;
- определение количества пользователей, одновременно работающих с приложением;
- определение границ приемлемой производительности при увеличении нагрузки (при увеличении интенсивности выполнения этих операций);
- исследование производительности на высоких, предельных, стрессовых нагрузках.
Стрессовое тестирование (Stress Testing)
Стрессовое тестирование позволяет проверить насколько приложение и система в целом работоспособны в условиях стресса и также оценить способность системы к регенерации, т.е. к возвращению к нормальному состоянию после прекращения воздействия стресса. Стрессом в данном контексте может быть повышение интенсивности выполнения операций до очень высоких значений или аварийное изменение конфигурации сервера. Также одной из задач при стрессовом тестировании может быть оценка деградации производительности, таким образом, цели стрессового тестирования могут пересекаться с целями тестирования производительности.
Объемное тестирование (Volume Testing)
Задачей объемного тестирования является получение оценки производительности при увеличении объемов данных в базе данных приложения, при этом происходит:
- измерение времени выполнения выбранных операций при определенных интенсивности выполнения этих операций;
- может производиться определение количества пользователей, одновременно работающих с приложением.
Тестирование стабильности или надежности (Stability / Reliability Testing)
Задачей тестирования стабильности (надежности) является проверка работоспособности приложения при длительном (многочасовом) тестировании со средним уровнем нагрузки. Времена выполнения операций могут играть в данном виде тестирования второстепенную роль. При этом на первое место выходит отсутствие утечек памяти, перезапусков серверов под нагрузкой и другие аспекты, влияющие именно на стабильность работы.
Моделирование Транзакций (Transaction Simulation, TS)
Этот метод используется в большом числе различных продуктов, в частности, в пакетах AppManager и Vivinet Manager компании NetlQ.
Метод TS основан на использовании программных GUI-роботов (GUI -Graphical User Interface). GUI-робот – это специальная программа, которая "заставляет" реальное пользовательское приложение работать в автоматическом режиме, без участия самого пользователя (человека). Примерами средств, предназначенных для создания GUI-роботов, являются пакеты Rational Visual Test и Rational Robot компании Rational Software, а также пакет WinRunner компании Mercury Interactive.
Программный GUI-робот, как и реальный пользователь приложения, анализирует содержимое экрана и вводит данные с клавиатуры. Другими словами, он взаимодействует с пользовательским приложением через тот же интерфейс, что и человек. При этом GUI-робот работает по программе (скрипту), к коду которой всегда есть доступ (в отличие от кода самого пользовательского приложения). Поэтому, если в скрипт GUI-робота встроить специальные вызовы, например, перед началом и после окончания транзакции, то можно измерить время выполнения этой транзакции.
Основное достоинство метода TS заключается в том, что он позволяет измерять производительность работы приложения "с точки зрения пользователя" и, при этом, не требует доступа к коду пользовательского приложения [18]. Недостаток же метода в том, что он позволяет измерять время выполнения только рабочих транзакций и не может использоваться для измерения времени выполнения системных транзакций.
Метод "Анализ данных на стороне клиента" (Client Capture, CC)
Данный метод реализован, например, в программном пакете Vital Suite компании Lucent [17]. Метод основан на извлечении данных о работе приложения из операционной системы компьютера, где установлено пользовательское приложение. Для этого на компьютере пользователя устанавливается специальный Агент, который отслеживает взаимодействие приложения и ОС и, таким образом, получает информацию о доступности и времени реакции пользовательского приложения. Достоинство данного метода в том, что при его использовании нет необходимости модернизировать код приложения. Недостаток – дополнительные накладные расходы на компьютере пользователя (клиента) и ограниченный набор поддерживаемых приложений.
Метод "Анализ Сетевого Трафика" (Network Sniffing, NS)
Примером такого устройства является NetScout WAN Probes, компании NetScout [17].Он основан на извлечении информации о производительности приложений из сетевого трафика. Для этого в сети устанавливаются специальные Зонды (как правило, аппаратные), которые в режиме реального времени захватывают сетевой трафик, анализируют его и "извлекают" данные о времени реакции приложений, доступности приложения и т.п. АРМ-средства на базе метода "Network Sniffing" выпускаются, в основном, производителями аппаратных анализаторов сетевых протоколов.
Проверка HTML-кода
Еще одним типом тестирования является проверка верности HTML-кода страниц сайта. Для такого рода тестирования написано множество утилит – от простых скриптов на Perl до мощных валидаторов, проверяющих весь сайт на соответствие стандартам (а некоторые валидаторы могут в автоматическом режиме исправлять найденные недочеты, например, пропущенные закрывающие теги и т.д.). Часто такие средства встраивают в Веб-редакторы, существуют браузеры с встроенными валидаторами.
Например, FireBug интегрируется с браузером Firefox, чтобы обогатить инструментарий разработчика. Вы сможете редактировать, отлаживать и исследовать CSS, HTML и JavaScript вживую, на любой веб-странице. Firebug предоставляет возможность делать экспериментальные изменения в HTML и смотреть, как они тут же отображаются на странице, производить мониторинг сетевых запросов.
В комплекте с IE8 поставляется инструмент "средства разработчика", который, по сути, является аналогом FireBug.
Обзор автоматизации тестирования
Контроль качества ПО невозможен сегодня без автоматизации всех задач тестирования.
Ручное тестирование является затратным по времени, трудоемким и часто монотонным процессом. Оно приводит к возникновению проблем, особенно при ограниченных ресурсах и жестких сроках. Если вам нужно улучшить тестирование приложений для проверки корректности их работы, важно двигаться в сторону автоматизации всех ручных задач тестирования.
Процесс автоматизации тестирования делится на три этапа:
- Запись. Сценарий тестирования записывается "на лету" по мере работы пользователя с приложением. Можно также вставить точки верификации (verification points) для проверки ответа системы и сделать сценарии тестирования зависящими от данных, чтобы выполнять один и тот же сценарий с различными наборами входных данных.
- Улучшение. Добавление кода, выполняющего разнообразные функции. Типичные изменения сценариев тестирования – условное ветвление, рефакторинг и обработка исключительных ситуаций.
- Воспроизведение. Выполнение сценариев, эмулирующих действия, которые выполнял пользователь приложения при записи теста. Расхождения регистрируются, и тестировщик может сделать вывод о том, хорошо ли функционирует приложение или регрессионное тестирование выявило проблемы.
Для автоматизации тестирования существует большое количество приложений.
Источники:
