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-приложение: среда функционирования очень разнообразна и может оказать серьезное влияние на работоспособность и серверной, и клиентской части.

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

Всё это требует определённого опыта и практики.

Ниже перечислено 7 лайфхаков, которые используются для автоматизации web – тестов, и которые должны оправдать вложенные в неё инвестиции.

  1. Выполнение реальных сценариев

Очень важно знать реальный сценарий, чтобы правильно заавтоматизировать тест-кейс. По возможности надо избегать mock-и и выполнять всё на “живом” приложении. В таком случае можно быть увереным в результате автотеста и в том, что проверка прошла, как надо.

  1. Запускать автотесты ежедневно после последнего коммита

Тут двоякая ситуация. На некоторых проектах коммиты мержатся в течении всего дня. И такого понятия, как “дневной коммит” не существует. В таком случае следует выбрать время для запуска автотестов. С одной стороны это кажется утомительным, но с другой – очень полезно при частых обновлениях приложения. Баги отлавливаются на ранних стадиях, когда проблемные участки ещё не пустили корни.

  1. Сокращение времени выполнения теста и увеличение тестового покрытия

Порой этого трудно добиться, тут нужен определённый опыт и технические знания. При правильном применении методологий тестирования и оптимального использования программных инструментов можно, если и не сократить время пробега теста до минимума, то хотя бы как-то его уменьшить. Также большую роль играет и вид тестирования: API и end-to-end тестирования гораздо быстрее UI – тестирования.

  1. Проверить браузерную и платформенную совместимости

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

  1. Составить отчёт по найденным багам в самом начале

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

  1. Переиспользование тестовых методов и сценариев

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

  1. Регулярная отчётность

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

    7 хаков автоматизированного тестирования web-приложений, которые вы должны знать

    http://сайт/wp-content/uploads/2017/04/website-test-automation-150x150.jpg

    Будучи автоматизированным тестировщиком вы ежедневно должны отлавливать различные баги, даже в своём фреймворке. Это ничего не говорит о вашей компетентности или о том, что компания вкладывает мало ресурсов в тестирование. В основном проблемы кроются в слабосвязанном коде, сложных процессах и интеграциях. Кроме того, процесс непрерывной интеграции требует много усилий и времени, чтобы гарантировать, что приложение […]

Тестирование 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/

Немного нетривиальная задача мне выпала. Девушка, можно сказать, моя гражданская жена, хочет стать тестировщиком. Сама не особо знает, каким именно, но хочет в 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) реальных сайтов, на кнопочки нажимаем, поля заполняем, по страницам ходим. Иногда я пишу тестовые странички, где надо мышой подвигать, покликать, ховеры разные и визибилити проверить, чтобы было посложнее. Все это надуманные примеры, но суть объясняет.

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

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

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

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