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

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

Тестирование WEB-Приложений

*
Какими бывают Web – приложения?
1. «Простые» сайты и веб-приложения:
-
Информационные сайты
Электронные магазины
Простые веб-приложения

Тестирование WEB-Приложений

*
2. Комплексные приложения и порталы
-
Решения с расширенной функциональностью
Горизонтальные порталы и социальные сети
Решения по потоковой передаче данных
Интернет-аукционы и торговые площадки

Тестирование WEB-Приложений

*
3. Веб-продукты повышенной сложности и облачные решения
- Инновационные продукты
- SaaS-решения
-Поисковые системы
-Трейдинговые системы
-Системы онлайн-платежей

Клиент-серверная архитектура

*

Клиент-серверная архитектура

*
2-х уровневая клиент-серверная архитектура

Тестирование WEB-Приложений

*
С чего состоит тестирование WEB-приложений?

10. Тестирование WEB-Приложений

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

11.

3. Тестирования Верстки - при проверке верстки первым делом
тестировщик проверяет расположения элементов, соответствие их
позиций предоставленным макетам, а так же проверяет оптимизацию
изображений и графики. Далее осуществляется проверка валидности
кода.
В процессе вёрстки важно соблюдать корректную иерархию объектов,
и важно удостовериться в её валидности по факту завершения работ.
Браузеры, несмотря на явно неверный код, в любом случае
постараются отобразить веб-страницу. Но поскольку не существует
единого регламента о том, как же должен быть показан «кривой»
документ, каждый браузер пытается сделать это по-своему. А это в
свою очередь приводит к тому, что один и тот же документ может
выглядеть по-разному в различных браузерах.
Исправление явных промахов и систематизация кода приводит, как
правило, к стабильному результату. Завершив проверку на
валидность, специалист приступает к проверке на кроссбраузерность,
т.е. проверяет работоспособность сайта в различных браузерах, а так
же при различных параметрах настройки экрана.

12.

Зачем проверять сайт на кроссбраузерность? На сегодняшний день
существует ряд наиболее популярных веб-браузеров, таких как Google
Chrome, Safari, Mozilla Firefox, Internet Explorer и Opera. Каждый из
них придерживается общих рекомендаций визуализации разметки
страницы, однако в то же время каждый обрабатывает код в
соответствии с особенности собственного движка. Осложняется всё
тем, что достаточно часто появляются новые версии браузеров, и
ресурс, который отлично смотрится, к примеру, в IE9, не обязательно
будет выглядеть корректно в IE7 или IE8. Поэтому в процессе
тестирования учитывается перечень браузеров, поддержка которых
оговаривалась с заказчиком на ранних этапах обсуждения проекта.
Этап проверки сайта на кроссбраузерность при различных
разрешениях достаточно долгий по времени, но результат того стоит -
с вашим сайтом сможет ознакомиться любой представитель целевой
аудитории.

13.

Usability тестирование - проводится для оценки удобства
продукта в использовании, основанный на привлечении
пользователей в качестве тестировщиков и анализ полученных
результатов.
Несмотря на тот факт, что проработка удобства использования
ресурса осуществляется в процессе составления технического
задания, разработки макетов, бывают ситуации, когда
полученный результат не является оптимальным. Хотя такое и
происходит достаточно редко, оптимальное решение в данном
случае - внести изменения в реализованный продукт.
Тестирование проводится с участием нескольких человек из
целевой аудитории, так называемых респондентов. Для
проведения тестирования достаточно 4-6 человек. Существует
правило 80/20, которое гласит, что 20% пользователей дают 80%
результата. Поэтому такое количество респондентов
максимально эффективно с точки зрения экономии времени и
затрат.

14.

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

15.

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

16. Особенности тестирования web-приложений:

*
Технологические отличия.
Классическое приложение работает с использованием одной
или семейства родственных технологий.
Web-приложение работает с использованием принципиально
различных технологий.
Структурные отличия.
Классическое приложение “монолитное”. Состоит из одного или
небольшого количества модулей. Не использует серверы БД,
web-серверы и т.д.
Web-приложение - “многокомпонентное”. Состоит из большого
числа модулей. Обязательно использует серверы БД, webсерверы, серверы приложений.

17.

Отличия режимов работы.
Классическое приложение работает в режиме реального
времени, т.е. известно о действиях пользователя сразу же, как
только оно выполнено.
Web-приложение работает в режиме “запрос-ответ”, т.е.
известно о некотором наборе действий только после запроса на
сервер.

18.

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

19.

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

20.

Особенности сбоев и отказов.
Классическое приложение: выход из строя тех или иных компонентов
сразу становится очевидным.
Web-приложение: выход из строя некоторых компонентов оказывает
непредсказуемое влияние на работоспособность приложения в целом.
Отличия в инсталляции.
Классическое приложение - процесс инсталляции стандартизирован и
максимально ориентирован на широкую аудиторию пользователей. Не
требует специфических знаний. Добавление компонентов приложения
выполняется стандартным способом с использованием одного и того
же инсталлятора.
Web-приложение - процесс инсталляции часто недоступен конечному
пользователю. Инсталляция требует специфических знаний. Процесс
изменения компонент приложения не предусматривается или требует
квалификации пользователей. инсталлятор отсутствует.

21.

Отличия в деинсталляции.
Классическое приложение: процесс деинсталляции
стандартизирован и выполняется автоматически или
полуавтоматически.
Web-приложение: процесс деинсталляции требует
специфических знаний для вмешательства администратора и
часто сопряжен с изменением кода среды функционирования
приложения, БД, настройки системного ОС.
Особенности среды функционирования.
Классическое приложение: среда функционирования
стандартизирована и не сильно влияет на функционирование
приложения.
Web-приложение: среда функционирования очень разнообразна
и может оказать серьезное влияние на работоспособность и
серверной, и клиентской части.

22. Практическое задание:

*
Протестировать ресурс.
Завести баг репорты на найденные баги.
http://mines.pp.ua/

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

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

Подход Webmart QA к тестированию веб приложений

В рамках тестирования веб-приложений нашей командой осуществляются:

• Тестирование функциональности (проверка реализации функционального наполнения приложения на соответствие требованиям и общепринятым стандартам).
• Тестирование кроссбраузерности и кроссплатформенности (выявление дефектов и различий в поведении системы при взаимодействии пользователя с продуктом в разных операционных системах, браузерах и на разных устройствах).
• Тестирование веб-сервисов (проверка корректности вызываемых веб-приложением сервисов на предмет корректной обработки данных, изменения статусов объектов, возвращение информации из БД и проч.).
• Интеграционное тестирование, E2E (тестирование сквозных сценариев для комплекса взаимодействующих подсистем, включающий валидацию подключений и коннективностей, подготовку тестовых данных в определенных компонентах и проверку результатов проведения бизнес-процессов пошагово всей системы в целом).
• Юзабилити-тестирование (проверка удобства пользования, обнаружение изъянов в навигации и интерфейсе, а также избыточной или недостаточной информативности).
• Нагрузочное и стресс-тестирование (проверка стабильности и устойчивости к сбоям системы при нормальных рабочих условиях и пиковых нагрузках в течение длительного времени).

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

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

Только подходящие комбинации

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

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

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

Немного нетривиальная задача мне выпала. Девушка, можно сказать, моя гражданская жена, хочет стать тестировщиком. Сама не особо знает, каким именно, но хочет в IT на начальные позиции. После некоторых раздумий остановились на тестировании интерфейсов веб-приложений, т.к. это, во-первых, тренд (время SPA), который будет только расти, а во-вторых, в вебе огромная свобода в тестировании. Иные виды приложений (мобильные, десктоп), решили отсечь, т.к. входной порог выше (узкие инструменты, менее популярные, более привязывающие к технологии). Иные виды тестирования - тем более. Во-первых, значительную часть тестов, которые "близко к коду" или "близко к критическим фичам", делают программисты, во-вторых, про далекие тесты (вроде нагрузочного, дымового и т.п.) можно забыть на начальном этапе. Сам я с вебом очень давно знаком, фулстек разработчик, как щас говорят. Из технологий: python/js/django/flask/backbone и всякое смежное. В основном пишу модульные тесты (питоний unittest), фронтенд тестил редко, ибо фриланс и проекты не такие большие, но есть опыт с mocha/jasmine + selenium, а также python + selenium для e2e тестирования. Для себя я много что пробую, но все-таки я не тестировщик, просто приходится знать и интересоваться, как оно, плюс есть вещи, где нельзя без тестирования.

Так вот, в общем, имеем мое понимание, как оно устроено и может быть устроено, и практически нулевые знания у девушки. У нее за плечами довольно техническое образование (безопасность в IT), что-то она кодила, про веб знает немного. Можно охарактеризовать так: html/css, немного питона (по моей инициативе), примерное представление о парадигмах программирования (ООП), что-то знает про сети (шлюз, роут, днс, дхцп, скорее всего, помнит даже, что такое бгп (sic!) и т.п.), но опыта нет ни в чем вообще. Есть аналитическое мышление, но нет уверенности, "нет наглости делать так, как кажется правильным и не бояться писать велики".

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

Но с моей точки зрения знать надо много: у меня есть ощущение, что тестировщик - это почти разработчик. Как можно тестить интерфейс без понимания того, как устроена верстка (html/css/svg, особенно фичи с селекторами)? Как можно тестировать сложные сценарии без знания основ взаимодействия фронтенда и бэкенда (кукисы, аякс, основы js, чтобы не пугаться, если что)? Кроме того, хорошо было бы знать что-нибудь про бекенд. Кроме того, в реальном месте вообще может оказаться какая-нибудь связка ангуляра, кармы тест раннера, жасмина или чего-то в этом роде, надо бы быть в теме.

Что я сделал: решил начать с питона, потому как JS учить как первый язык и умереть в прототипах, очень интересном приведении типов, 100 способах объявить приватный член и стрелять по ногам, с миллионами фреймворков/парадигм/стандартов/модулей/классов... Это очень сложный язык, я считаю. Начинать с популярной джавы - это вообще провал, потому как я сам с ним знаком на уровне универа всего лишь, во-вторых, я считаю, что это не лучший язык для разработки и обучения, кроме того, мы все-таки в области фронтенда. На питоне мы уже написали тестовый класс и юнит-тестик для него, чтобы примерно понимать суть тестирования. Потом я сказал, что если сделать наоборот, то это будет TDD. А если перед TDD подумать и описать, что надо, то это будет BDD. Понимаю, что нюансов много, но стараюсь сделать так, чтобы возникли вопросы у человека, и он пошел гуглить. По пути я объясняю некоторые фичи вроде того, зачем нужен self (для непитонистов - this - указатель на текущий объект), что такое типизация, ООП, даю ссылки на хабру, в доки, показываю, как дебажить, разбирать ошибки, в общем, стараюсь объяснить как можно больше всего из программирования вообще, могу параллельно залечивать на темы "а ты знаешь, вот в си есть указатели, и они там работают вот так...", потому как язык - это все фигня. С вероятностью значительной ей придется учить либо js, либо, прости господи, джаву. И все это будет очень просто, я считаю, если она будет знать базовые концепции.

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

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

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

Так вот. Прав ли я вообще? Моя задача объяснить основы веба, в т.ч. программирования, популярные инструменты для тестирования, популярные парадигмы, чтобы можно было пойти джуном тестером. Я чувствую, что я не учитель, ибо у меня есть какое-то видение автоматически, как должно быть, и я строю все уже из него. Есть ощущение, что говорю очень много инфы сразу, что вводит в ступор. Есть ощущение, что я не могу передать все, что знаю, ибо всего очень много и часто все затягивается на длинные монологи, когда я что-то показываю, делаю, но у человека разрывает мозг. Кто-нибудь считает, что я дико не прав, возможно? Может, есть фундаментальная литература с основами по тестированию веба вообще? Она начинала читать "тестирование дот ком" от кого-то, по моему мнению ее вообще читать не стоит, ибо все, что там есть, можно увидеть на вики, немного подумав. Может, есть какие-то прямо суперские книги, такие как Кормен в алгоритмах, например? Или мне стоит вообще изменить подход?

Сам нахожусь в некотором замешательстве, ибо начал чувствовать, что я, скорее, "укладываю инфу в своей голове", чем что-то объясняю ей... %)

Доводилось ли вам тестировать веб-приложения? Практически любой специалист по тестированию программного обеспечения с опытом более года даст утвердительный ответ на этот вопрос, ведь существуют вполне объективные причины такого положения дел:

На данный момент в сети Интернет действует более миллиарда сайтов, и пользуются ими более 3,5 млрд. людей по всему миру (по данным Международного союза электросвязи на июль 2016 года);
- в России более 70% взрослого населения являются интернет-пользователями, а общий оборот средств на российском рынке интернет-торговли за первое полугодие 2016 года вырос на 26% в сравнении с аналогичным периодом 2015 года и достиг 405 млрд. рублей.

При взгляде на эти баснословные цифры становится понятным, почему в мире разрабатывается так много новых веб-приложений. Этот процесс приводит к необходимости привлечения большого количества специалистов. То, что веб (в широком смысле) будет продолжать наращивать темпы своего развития, подтверждается и набирающим силу «мейнстримом»: всё «переезжает» в облака. Облачные технологии становятся новой реальностью современного Интернета: даже некогда привычные нам десктопные Word и Excel сегодня представлены в виде веб-альтернатив от Microsoft. Исходя из сказанного, можно утверждать, что потребность в хороших инженерах по обеспечению качества, специализирующихся на веб-продуктах, будет только расти.

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

Клиент, сервер и база данных

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

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

Веб-приложение представлено следующими составляющими («сторонами»):
1. Клиент.
Как правило, клиент – это браузер, но встречаются и исключения (в тех случаях, когда один веб-сервер (ВС1) выполняет запрос к другому (ВС2), роль клиента играет веб-сервер ВС1). В классической ситуации (когда роль клиента выполняет браузер) для того, чтобы пользователь увидел графический интерфейс приложения в окне браузера, последний должен обработать полученный ответ веб-сервера, в котором будет содержаться информация, реализованная с применением HTML, CSS, JS (самые используемые технологии). Именно эти технологии «дают понять» браузеру, как именно необходимо «отрисовать» все, что он получил в ответе.

2. Сервер.
Веб-сервер – это сервер, принимающий HTTP-запросы от клиентов и выдающий им HTTP-ответы. Дабы избежать возможной путаницы, отметим, что веб-сервером называют как программное обеспечение, выполняющее функции веб-сервера, так и непосредственно компьютер, на котором это программное обеспечение работает. Наиболее распространенными видами ПО веб-серверов являются Apache, IIS и NGINX. На веб-сервере функционирует тестируемое приложение, которое может быть реализовано с применением самых разнообразных языков программирования: PHP, Python, Ruby, Java, Perl и пр.

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

База данных – довольно широкое понятие, которое используется не только в сфере информационных технологий. В контексте моей статьи это – информационная модель, позволяющая упорядоченно хранить данные об объекте или группе объектов, обладающих набором свойств, которые можно категоризировать. Базы данных функционируют под управлением так называемых систем управления базами данных (далее – СУБД). Самыми популярными СУБД являются MySQL, MS SQL Server, PostgreSQL, Oracle (все – клиент-серверные).

Также существуют встраиваемые и файл-серверные СУБД. Для общего развития отмечу лишь одну популярную встраиваемую СУБД – SQLite, которая используется в некоторых браузерах, Android API, Skype и других известных приложениях. Взаимодействие с перечисленными СУБД основано на специальном языке структурированных запросов – SQL.

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

Особенности архитектуры: «под прицелом» клиент

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

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

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

Что необходимо проверять при кроссбраузерном тестировании:

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

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

Отдельно рекомендую не забывать о всякого рода валидаторах верстки, например https://validator.w3.org/ . Даже если у вас недостаточно знаний, чтобы оценить соответствие верстки стандартам, можно использовать для этого автоматические средства и, проанализировав результат, указать разработчикам на самые серьезные «оплошности». Не стоит забывать, что иногда валидаторы обращают внимание на самые «мелочные мелочи», которые никто и никогда исправлять не будет. Если вы и заводите баг-репорты на подобного рода замечания, то удобнее будет собрать их в единый документ и прикрепить к репорту. К такого рода «мелочам» можно отнести всевозможные рекомендации, которые не имеют своего влияния на отображение и функционирование контента.

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

Как же не пропустить дефекты в формах на продакшен? Рассмотрим несколько простых шагов:
1. Тщательно проверяем обязательность заполнения полей и наличие соответствующей маркировки у них.
2. Заполнив и отправив форму, убеждаемся в том, что с данными происходит именно то, что запланировано. Если данные должны быть внесены в базу данных, проверяем, корректно ли завершился процесс (в конце концов, об этом можно попросить разработчика, если не хватает своих знаний SQL или прав доступа к БД).
3. Используем чит-листы для тестирования форм, например или
4. Проверяем, выводятся ли понятные пользователю информационные сообщения о необходимости заполнения пустых полей после попытки отправить форму.
5. Обращаем пристальное внимание на реализацию экранирования символов в полях форм, являющихся потенциальным источником уязвимостей для приложения и пользователей. Экранирование должно осуществляться на уровне не только клиента, но и сервера, отключить который в клиенте довольно просто (например, с помощью специальных плагинов, снимающих все возможные ограничения в несколько кликов, таких как Web Developer Toolbar – Forms).
6. Убеждаемся, что после заполнения формы пользователю приходит подтверждающее письмо с указанием соответствующего отправителя, а само тело письма соответствует требованиям (в том числе и на работоспособность ссылок).
7. Используем вспомогательные специальные инструменты для тестирования форм (например, Web Developer Toolbar).

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

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

Да, мы не всегда имеем достаточно времени для вычитывания всех текстов, но в таких ситуациях на помощь приходят «SpellCheker-ы» (программы для проверки орфографии, онлайн или в виде плагинов для браузеров), например, Яндекс.Спеллер .

Веб-сервер: «долой клиент, тестим без него»

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

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

В чем же заключаются эти нюансы?

1. Большая часть веб-приложений требует для инсталляции специфических знаний в администрировании ОС. Попробуйте установить приложение на нескольких веб-серверах. В оптимальном случае это будут самые популярные технологии среди ваших пользователей, для установления списка которых потребуется предварительное исследование.
2. Инсталлируя веб-приложение, обращайте внимание на то, действительно ли приложение устанавливается в указанную вами директорию, базу данных, использует выбранный вами префикс и соблюдает прочие конфигурационные моменты.
3. Убедитесь, что приложение можно установить как из localhost, так и удаленно.
4. Если процесс инсталляции является интерактивным, и каждый выбор пользователя на определенном шаге влияет на последующие действия, то необходимо будет пройти все ветви, так как именно инсталляция является первым шагом пользователя в работе с вашим приложением.
5. Не забывайте о негативных тестах: проверки в условиях недостаточности ресурсов (места на диске, оперативной памяти) или привилегий, прерывание процесса установки во время активной его фазы (например, отправляя сервер в перезагрузку).

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

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

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

База данных: «хранить нельзя удалить»

Еще одной ранее рассмотренной составляющей веб-приложений является база данных, в которой приложение хранит всю необходимую информацию. Для того, чтобы база данных служила достойным хранилищем информации для вашего приложения, при тестировании необходимо обращать внимание на следующие основные моменты:
1. Вносимая через интерфейс информация должна быть сохранена в базе данных в неизменном (первоначальном) виде.
2. Сохраненная в базе данных информация должна отображаться в любой части приложения одинаково (если иного не требует бизнес-логика приложения).
3. Названия таблиц и структура БД должны соответствовать проектной документации.
4. Нужно следить за тем, чтобы запросы не обрабатывались слишком долго, а количество соединений было достаточным. Мониторинг состояния БД – один из важных моментов тестирования.
5. Стоит учитывать, что удаление записи в БД не всегда сопровождается полным удалением сущности. Иногда используется так называемое «псевдоудаление», и нужно проверить, правильно ли оно выполняется.
6. Пустую БД на тестовом стенде рекомендуется либо заполнять сгенерированными случайными данными, либо снимать дамп с продакшена и после обфускации данных «заливать» их в тестируемую БД. Иногда квалификация тестировщика (или иная причина) не позволяет выполнить этот процесс самостоятельно: в таком случае рекомендуется обратиться за помощью к специалистам инфраструктуры или разработчикам.

Запросы : do you speak computish?
Все составляющие веб-приложения должны взаимодействовать между собой, и происходит это благодаря HTTP(s). Без HTTP наша многосторонняя система не функционировала бы в принципе, так как HTTP – это протокол передачи данных, занимающий одно из основных мест в нашей клиент-серверной архитектуре.

Взаимодействие осуществляется через сообщения (запросы и ответы): на отправленный запрос от клиента должен прийти ответ сервера. Классический запрос/ответ состоит из 3 составляющих:

Стартовая строка;
- заголовок;
- тело сообщения.

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

Самыми популярными методами являются GET, HEAD и POST:

1. Метод GET. Используется для запроса содержимого, размещенного на сервере (например, GET /path/resource?param1=value1¶m2=value2 HTTP/1.1).
2. Метод HEAD. По своей сути не отличается от вышеупомянутого метода, однако ответ сервера на такой запрос лишен «тела», а практическое применение ориентировано на облегченное использование с целью получения минимальной информации о сервере/продукте или его статусе.
3. Метод POST. Данный метод используется для передачи данных на сервер, однако его основа «прячется» в тело, что отличает его от GET. Во время публикации этой статьи, например весь текст будет помещен в тело POST-запроса; после обработки его сервером на сайт будет добавлена статья.

Существуют и другие методы: PUT, DELETE, CONNECT, TRACE, PATCH и т. д.

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

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

На что обращать внимание в запросах?

1. Правильный ли метод используется для того или иного запроса? Если вы отправляете сообщение, а на сервер уходит только GET-запрос, то что-то здесь явно не так.
2. Казалось бы, клик по одной и той же функциональной клавише генерирует один и тот же запрос. Но есть прецеденты, когда клик по кнопке приводил к ситуации, в которой JavaScript переписывал запрос рядом находящейся кнопки, таким образом меняя ее предназначение.
3. Вникайте в отправляемые запросы. В них довольно легко разобраться, особенно если это GET – они логически понятны даже рядовому пользователю. Анализ запросов – это возможность обнаружить спрятавшийся дефект гораздо быстрее, чем осуществляя его поиск в интерфейсе.
4. Мониторьте трафик на предмет запросов на другие (не ваши) сервера. Пример из жизни: фронтэнд сайта делал фриланс-разработчик, по завершению работы которого мы принялись за тестирование. Я имею привычку мониторить весь трафик тестируемого приложения: это позволило обнаружить, что вышеупомянутый разработчик без зазрения совести спрятал в «фронт» сайта запросы, которые работали на благо его личного интернет-магазина.
5. Мониторя трафик, внимательно следите за кодами состояний. Мы подробнее остановимся на этом пункте.

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

Все коды можно поделить на группы (сотые, двухсотые, трехсотые, четырехсотые и пятисотые) каждая группа-«сотня» несет свой тип информации.

Нажмите на картинку, чтобы увеличить изображение

Более детально с кодами состояния можно ознакомиться на Wikipedia .

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

Чем еще отличается веб-приложение от десктопного: больше особенностей – больше проблем!

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

Нажмите на картинку, чтобы увеличить изображение

3. Пользователи с одним уровнем доступа могут обращаться к одним и тем же сущностям, что приводит к конкурентному доступу. Тестируется это довольно просто. Для примера рассмотрим систему, имеющую дело с договорами, которые можно создавать, публиковать, редактировать, аннулировать. Алгоритм работы таков: под несколькими окнами в режиме инкогнито авторизуемся в приложении под пользователями с разными уровнями доступа; далее выбранную для теста сущность открываем на редактирование, а под второй учетной записью эту же сущность пробуем перевести в статус «Аннулировано» – на этом этапе должен сработать контроль на конкурентный доступ. Операция аннулирования блокируется, а пользователю выдается сообщение о том, что сущность редактируется другим пользователем (поведение и приоритет действий определяются в соответствии с требованиями и особенностями продукта, но логика не меняется).
4. Широта аудитории говорит о том, что за монитором может находиться человек, имеющий злой умысел в отношении вашего ПО.

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

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

Тестирование безопасности веб-приложения: спаси, сохрани, защити
Тестирование безопасности – отдельное направление тестирования, которое требует от специалиста фундаментальных знаний технического характера и хорошей профильной квалификации. Я отмечу ряд общих моментов, которые могут помочь любому тестировщику находить классические уязвимости, не допуская их выход на продакшен. Вопросы безопасности приложений регламентируются OWASP Guide , CHECK , ISACA , NIST Guideline, OSSTMM .

Существует ряд принципов безопасности, к которым относятся конфиденциальность, целостность и доступность:
1) Конфиденциальность – ограничение доступа к той или иной информации для определенной категории пользователей (или наоборот предоставление доступа только ограниченной категории).
2) Целостность включает в себя:
а) возможность восстановить данные в полном объеме при их повреждении;
б) доступ на изменение информации только определенной категории пользователей.
3) Доступность – иерархия уровней доступа и четкое их соблюдение.

Перечислим классические уязвимости современных веб-приложений:
1. XSS – генерация на странице продукта скриптов, представляющих опасность для пользователей продукта;
2. XSRF – уязвимость, при которой пользователь переходит с доверенной страницы на вредоносную, где воруются представляющие ценность пользовательские данные;
3. сode injection (PHP, SQL) – инъекция части исполнительного кода, которая делает возможным получить несанкционированный доступ к программному коду или базе данных и вносить в них изменения;
4. authorization bypass – это вид уязвимости, при котором можно получить несанкционированный доступ к учетной записи или документам другого пользователя;
5. переполнение буфера – явление, которого можно достичь во вредоносных целях, по своей сути представляет использование места для записи данных далеко за пределами выделенного буфера памяти.

При тестировании рекомендую использовать чит-листы уязвимостей XSS Filter Evasion Cheat Sheet и MySQL SQL Injection Cheat Sheet .

Практические советы: еще раз о насущном

Начинаем тестировать не с тестирования: с чего начать?

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

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

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

Некогда думать, нужно тестировать!
Любое тестирование требует содержательного подхода с применением техник тест-анализа и тест-дизайна. В противном случае вы рискуете навсегда остаться «monkey-тестером», ценность труда которого будет мизерна. В целом, ключевые положения тест-анализа и тест-дизайна применимы как к тестированию десктоп-приложений, так и к веб-у, но с существенной оговоркой: вы должны учитывать все упомянутые в статье нюансы. Отдельно хочу акцентировать внимание на том, что без стойкого понимания методик и способов применения тест-анализа и тест-дизайна тестировать качественно ПО практически невозможно.

Рассмотрим классический набор методик тест-дизайна, которые можно применять при тестировании веб-приложений:

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

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

– ПО для отслеживания всего вашего трафика. Я всегда сопровождаю любое тестирование его фоновой работой, а потом сортирую по ошибкам и анализирую трафик. Также с помощью этого приложения можно отправлять ложные запросы на сервер с нужными вам параметрами.
- Xenu Link Evaluator (альтернатива – Black Widow) – «чекер» веб-приложения на предмет наличия в нем «битых» ссылок. Также можно использовать его для формирования карты приложения.
- Skipfish – активный сканер уязвимостей веб-приложений.
- OpenVAS – бесплатный сканер уязвимостей.
- Nikto – веб-сканер, проверяющий веб-серверы на самые частые ошибки, возникающие обычно из-за человеческого фактора.

Выводы и напутствия

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

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

Каждый из этих навыков QA Engineer должен развивать постоянно, и тогда он сможет избежать многих возможных проблем и остаться востребованным высококвалифицированным профессионалом. Остановка в развитии для специалиста из сферы обеспечения качества фактически приравнивается к профессиональной смерти (как минимум, «клинической» в том случае, если стремление к новым знаниям со временем возвращается). Движение – это жизнь. Всем добра!

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

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

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

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

Логика web-приложения распределена между сервером и клиентом, хранение данных осуществляется на сервере, обмен информацией происходит по сети.

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

Особенности тестирования web-приложений:

1. Технологические отличия .

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

Web-приложение работает с использованием принципиально различных технологий.

1. Структурные отличия .

Классическое приложение “ монолитно е”. Состоит из одного или небольшого количества модулей. Не использует серверы БД, web-серверы и т.д.

Web-приложение — “ многокомпонентное ”. Состоит из большого числа модулей. Обязательно использует серверы БД, web-серверы, серверы приложений.

1. Отличия режимов работы.

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

Web-приложение работает в режиме “запрос-ответ”, т.е. известно о некотором наборе действий только после запроса на сервер.

1. Отличия формирования интерфейса .

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

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

1. Отличия работы с сетью .

Классическое приложение практически не использует сетевые каналы передачи данных.

Web-приложение активно использует сетевые каналы передачи данных.

1. Отличия запуска и остановки .

Классическое приложение запускается и останавливается редко.

Web-приложение запускается и останавливается по факту поступления каждого запроса, т.е. очень часто.

1. Разница в количестве пользователей .

Классическое приложение: количество пользователей, одновременно использующих приложение, подвержено контролю, ограничено и легко прогнозируемо.

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

1. Особенности сбоев и отказов .

Классическое приложение: выход из строя тех или иных компонентов сразу становится очевидным.

Web-приложение: выход из строя некоторых компонентов оказывает непредсказуемое влияние на работоспособность приложения в целом.

1. Отличия в инсталляции .

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

Web-приложение — процесс инсталляции часто недоступен конечному пользователю. Инсталляция требует специфических знаний. Процесс изменения компонент приложения не предусматривается или требует квалификации пользователей. инсталлятор отсутствует.

1. Отличия в деинсталляции.

Классическое приложение: процесс деинсталляции стандартизирован и выполняется автоматически или полуавтоматически.

Web-приложение: процесс деинсталляции требует специфических знаний для вмешательства администратора и часто сопряжен с изменением кода среды функционирования приложения, БД, настройки системного ОС.

1. Особенности среды функционирования .

Классическое приложение: среда функционирования стандартизирована и не сильно влияет на функционирование приложения.

Web-приложение: среда функционирования очень разнообразна и может оказать серьезное влияние на работоспособность и серверной, и клиентской части.