НТВ плюс 

Тестирование веб ориентированных приложений. Просмотр на мобильных устройствах. Тестирование файлов cookie

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

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

Systems Sciences Institute при IBM выявили, что стоимость исправления ошибки, выявленной после релиза, была в 4-5 раз выше, чем стоимость выявленной и исправленной ошибки во время разработки. Следовательно, стоит тщательно тестировать веб-приложение до его выпуска.

Ниже приведен обзор 6 шагов, которые помогут в этом.

Шаг 1. Функциональное тестирование (Functional Testing)

Первым шагом тестирования веб-приложения является проверка функциональности системы.

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

Обычно функциональное тестирование включает в себя:

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

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

Шаг 2. Юзабилити тестирование (Usability Testing)

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

Юзабилити тестирование включает в себя следующие шаги:

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

Шаг 3. Тестирование интерфейса (Interface Testing)

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

Шаг 4. Тестирование совместимости (Compatibility Testing)

Ключевой шаг в тестировании веб-приложений - это обеспечение совместимости приложения со всеми веб-браузерами и устройствами.

Совместимость с веб-браузерами.

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

Кроме тестирования приложения на различных браузерах (и даже на Internet Explorer! :)), следует убедиться, что и другие версии одного и того же браузера обеспечивают корректную работу приложения.

Совместимость с мобильными устройствами.

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

Шаг 5. Тестирование производительности.

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

Чтобы определить предел работы приложения, оно подвергается высокому (стрессовому) уровню нагрузки до тех пор, пока не нарушится его функциональность (stress testing). Также это помогает проверить, как приложение восстанавливается после сбоев.

Шаг 6. Тестирование безопасности.

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

Тестирование безопасности включает в себя следующие шаги:

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

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

  • Безопасная передача данных;
  • Аутентификация;
  • Управление сеансом;
  • Авторизация;
  • Криптография;
  • Проверка данных;
  • Отказ в обслуживании (Denial of Service);
  • Специфические функциональные тесты;
  • Обработка ошибок.

Заключение.

Мы провели обзор 6 шагов в тестировании веб-приложений. Если выполнять эти действия в процессе разработки приложения, они помогут найти и исправить как можно больше ошибок до того, как уже будет поздно.

, информационный шум , логические ошибки , раскрытие информации , SQL Injection , "stress" , Нагрузочное тестирование , тестирование производительности , Объемное тестирование , Объемное стабильности , visual test , probing , sniffing , firebug , RDP , load generation , tester , quality manager , тестирование web-сервера , Моделирование Транзакций , Метод Метод "Анализ данных на стороне клиента"Анализ данных на стороне клиентаМетод "Анализ данных на стороне клиента" , Метод Анализ Сетевого Трафика , Проверка HTML-кода , профилировщик , граф вызовов , call graph , code coverage , подсветка синтаксиса , Вьювер , development tools , смещение элементов , иерархический список , breakpoint , билд , Internet Explorer Developer Tools , functional decomposition , data-driven , время выполнения , кэш , валидность , DHTML , css

Презентацию к данной лекции Вы можете скачать .

19.1. Тестирование Веб-приложений

19.1.1. Введение

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

В первой части данной лекции мы рассмотрим вопросы специфичные для тестирования и отладки Веб-приложений.

Будут рассмотрены принципы следующих подходов к тестированию Веб-приложений [ , ]:

  • функциональное тестирование ;
  • тестирование пользовательского интерфейса ;
  • тестирование удобства использования ;
  • нагрузочное и стрессовое тестирование ;
  • проверка ссылок и HTML-кода;
  • тестирование безопасности .

Также будет приведен обзор средств автоматизации тестирования Веб-приложений.

С общими вопросами тестирования и верификации информационных систем предлагается ознакомиться в курсе Интернет Университета Информационных Технологий "Верификация программного обеспечения" .

Во второй части лекции будут рассмотрены подходы и инструментальные средства отладки CSS, а также отладки и профилирования JavaScript.

19.1.2. Подходы к функциональному тестированию Веб-приложений

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

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

  1. Record & Play – основан на возможности средств автоматизации тестирования автоматически генерировать код.
  2. Functional Decomposition – в основе лежит разбиение всех компонент фреймворка по функциональному признаку на бизнес-функции (реализуют/проверяют бизнес-функциональность приложения), user-defined функции (вспомогательные функции, которые еще имеют привязку к тестируемому приложению или к конкретному проекту), утилиты (функции общего назначения, не привязанные к конкретному приложению, технологии, проекту).
  3. Data-driven – основан на том, что к некоторому тесту или группе тестов привязывается источник данных, и этот тест или набор тестов циклически выполняется для каждой записи из этого источника данных. Вполне может применяться в комбинации с другими подходами.
  4. Keyword-driven – представляет собой фактически движок для обработки посылаемых ему команд, а сами инструкции выносятся во внешний источник данных.
  5. Object-driven – основан на том, что основные ходовые части фреймворка реализованы в виде объектов, что позволяет собирать тесты по кирпичикам.
  6. Model-based – основан на том, что тестируемое приложение (или его части) описывается в виде некоторой поведенческой модели.

Самым распространенным является подход, называемый Capture & Playback (другие названия – Record & Playback , Capture & Replay) . Суть этого подхода заключается в том, что сценарии тестирования создаются на основе работы пользователя с тестируемым приложением. Инструмент перехватывает и записывает действия пользователя, результат каждого действия также запоминается и служит эталоном для последующих проверок. При этом в большинстве инструментов, реализующих этот подход, воздействия (например, нажатие кнопки мыши) связываются не с координатами текущего положения мыши, а с объектами HTML-интерфейса (кнопки, поля ввода и т.д.), на которые происходит воздействие, и их атрибутами. При тестировании инструмент автоматически воспроизводит ранее записанные действия и сравнивает их результаты с эталонными, точность сравнения может настраиваться. Можно также добавлять дополнительные проверки – задавать условия на свойства объектов (цвет, расположение, размер и т.д.) или на функциональность приложения (содержимое сообщения и т.д.).

Основное достоинство этого подхода – простота освоения. Создавать тесты с помощью инструментов, реализующих данный подход, могут даже пользователи, не имеющие навыков программирования.

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

19.1.3. Тестирование пользовательского интерфейса

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

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

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

Функциональное тестирование пользовательского интерфейса состоит из пяти фаз :

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

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

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

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

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

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

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

19.1.3.1. Ручное тестирование

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

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

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

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

Тестирование веб-приложений 2.0

Duration 11:28:40

Тестирование веб-приложений 2.0 - Полный список уроков

Развернуть / Свернуть
  • Урок 1. Общая теория. Что такое тестирование и что такое программа 00:07:27
  • Урок 2. Что нужно тестировать 00:09:53
  • Урок 3. Структура программы и её интерфейсы 00:10:45
  • Урок 4. Внутреннее устройство браузера 00:05:38
  • Урок 5. HyperText Markup Language (HTML) 00:11:02
  • Урок 6. Тестирование разметки 00:18:14
  • Урок 7. Тестирование текстового содержимого страниц 00:06:03
  • Урок 8. Тестирование ссылок 00:12:17
  • Урок 9. Тестирование локализации 00:06:51
  • Урок 10. Клиент-серверная архитектура 00:14:01
  • Урок 11. HyperText Transfer Protocol (HTTP) 00:09:58
  • Урок 12. Перехват запросов и ответов 00:14:52
  • Урок 13. HTTP. Продолжение 00:22:10
  • Урок 14. Протоколирование запросов и ответов на сервере 00:12:35
  • Урок 15. User-Agent - браузеры и боты 00:12:36
  • Урок 16. Отправка на сервер поддельных запросов 00:07:59
  • Урок 17. Адреса ресурсов. Domain Name Service (DNS) 00:13:47
  • Урок 18. Что происходит с запросом на сервере 00:14:08
  • Урок 19. Генерация полезной нагрузки 00:14:24
  • Урок 20. Источники данных (файлы, база данных) 00:15:46
  • Урок 21. Кеширование данных на стороне сервера 00:12:06
  • Урок 22. Многоуровневая архитектура 00:12:01
  • Урок 23. Аутентификация и авторизация 00:21:46
  • Урок 24. Тестирование прав доступа 00:13:19
  • Урок 25. Тестирование производительности серверной части 00:12:15
  • Урок 26. Ввод данных в формы 00:14:32
  • Урок 27. Типы запросов GET и POST 00:09:41
  • Урок 28. Неявные параметры запроса 00:07:32
  • Урок 29. Функциональное тестирование 00:18:04
  • Урок 30. Автоматизация функционального тестирования 00:19:35
  • Урок 31. Тестирование производительности 00:13:23
  • Урок 32. Тестирование защищенности 00:18:14
  • Урок 33. Cascading Style Sheets (CSS) 00:09:03
  • Урок 34. Cascading Style Sheets (CSS), продолжение 00:14:41
  • Урок 35. Автоматическая проверка CSS 00:12:09
  • Урок 36. Тестирование верстки (layout) 00:10:43
  • Урок 37. Адаптивная верстка 00:10:44
  • Урок 38. Семантическая верстка 00:06:40
  • Урок 39. JavaScript 00:13:33
  • Урок 40. Анимация без JavaScript 00:04:53
  • Урок 41. Document Object Model (DOM) 00:12:48
  • Урок 42. Валидация данных в формах 00:14:06
  • Урок 43. Асинхронные запросы (AJAX) 00:13:27
  • Урок 44. Одностраничники (Single Page Application, SPA) 00:10:16
  • Урок 45. REST API 00:16:09
  • Урок 46. Клиентская производительность 00:10:59
  • Урок 47. Инструменты для оценки клиентской производительности 00:14:18
  • Урок 48. Оптимизация клиентской производительности 00:13:45
  • Урок 49. Тестирование функциональности 00:18:13
  • Урок 50. Тестирование производительности 00:13:30
  • Урок 51. Тестирование удобства использования и доступности 00:19:13
  • Урок 52. Мониторинг 00:13:02
  • Урок 53. Сплит-тестирование 00:14:09
  • Урок 54. Оптимизация для поисковиков и социальных сетей 00:09:25

Курс посвящен особенностям тестирования веб-приложений (HTML, CSS, JavaScript) и специфике применения техник тест-дизайна для приложений такого типа. Тренинг полностью перезаписан весной 2018 года. Чем тестирование веб-приложений отличается от тестирования каких-нибудь других приложений? При тестировании веб-приложений применяются те же самые классические методы и техники проектирования тестов. Веб-приложения обычно имеют более простой интерфейс, чем "десктопные" программы. Браузером все умеют пользоваться, для этого не нужны какие-то специальные навыки.

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

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

После прохождения тренинга учащийся будет:

  • понимать принципы работы веб-приложений и знать, какие технологии при этом используются,
  • знать особенности тестирования веб-приложений по сравнению с десктопными приложениями,
  • уметь проектировать тесты с учётом особенностей веб-приложений и оценивать покрытие тестами функциональности приложения,
  • уметь выполнять тесты, при необходимости используя инструментальные средства для преодоления ограничений, накладываемых браузером,
  • владеть инструментами, для выполнения специфических проверок, характерных для веб-приложений:
    • анализ целостности ссылок,
    • анализ соответствия веб-стандартам,
  • понимать причины возникновения уязвимостей в веб-приложениях и уметь обнаруживать наиболее критические уязвимости в веб-приложениях,
  • понимать принципы оценки производительности веб-приложений и уметь выполнять анализ серверной и клиентской производительности веб-приложений,
  • уметь рассуждать об удобстве использования веб-приложений:)

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

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

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

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

Курсы тестирования

Если вы хотите освоить профессию тестировщика , советуем записаться на курс тестирования от Lemon.School.
Курс не только даст общее понимание такого понятия, как тестирование, но и научит выявлять баги на всех этапах разработки.

Как тестировать сайт?

Тестирование может происходить самыми разными способами, однако не стоит забывать о самом процессе и стратегии тестирования. От него зависит последовательность ваших действий. На сегодняшний день, специалисты по тестированию веб-сайтов применяют такие виды как:

  • Функциональное тестирование
  • Тестирования удобства пользования (юзабилити)
  • Тестирование производительности
  • Тестирование интерфейса пользователя (UI testing)
  • Тестирование безопасности.

Рассмотрим более подробно эти виды тестирования:

Функциональное тестирование

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

  • поиск и покупка товара, оформление заказа
  • навигация
  • формы аутентификация
  • добавление, удаление, редактирование товара, заказа и т.д.

Юзабилити тестирование сайта

Тестирование удобства пользования (юзабилити) – это вид тестирования, который делает для сайта удобство и практичность в использовании. Основная цель показать пользователю:

  • Понятен ли ваш сайт для окружающих и удобен ли?
  • Удобная навигация?
  • Какое впечатление создается у пользователя?
  • Что может быть лишним или не нужным.

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

Нагрузочное тестирование сайтов

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

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

Тестирование пользовательского интерфейса

UI testing - это тестирование графического интерфейса пользователя, которая предполагает проверить сайт на соответствия требованиям к графическому интерфейсу, профессионально ли оно выглядит, выполнено ли оно в едином стиле.

В большинстве случаев, тестирование интерфейса пользователя, осуществляется вместе со следующими видами тестирования(UI):

  1. Тестирование на соответствие стандартам графических интерфейсов
  2. Тестирование с различными разрешениями экрана
  3. Тестирование кроссбраузерности, или совместимости с разными интернет браузерами и их версиями
  4. Тестирование локализованных версий: точность перевода (мультиязычность, мультивалютность), проверка длины названий элементов интерфейса и т.д
  5. Тестирование графического интерфейса пользователя на целевых устройствах (смартфоны, кпп, планшеты).

Тестирование сайта на уязвимости

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

SQL-инъекции - это вредоносный код в запросах базы данных - наиболее опасный вид атак. Если это различные формы общественные (гостевая книга), то проверка на XSS инъекции. Дает возможность внедрить произвольный код, и атаковать компьютер пользователей, просматривающих зараженные страницы.

Вот, пожалуй, основные виды, которые используют для тестирования сайта.

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

  • проверки веб-форм
  • проверки правильности данных
  • тестирования интерфейса пользователя
  • тестирования оплаты
  • тестирования версий для печати
  • тестирования отчетов.

Современные web-приложения зачастую содержат множество "движущихся частей" и сторонних зависимостей. В процессе рефакторинга и добавления/изменения функциональности в таком приложении может произойти поломка существующих use-case сценариев и нестабильная работа в определенных браузерах.

Для своевременного обнаружения таких ситуаций и выполнения непрерывной интеграции необходимо функциональное тестирование web-приложения. В статье пойдет речь о двух бесплатных open-source решениях:



Рассматриваемые решения обеспечивают похожий, на первый взгляд, ряд возможностей.

  • Автоматизированное функциональное тестирование с последовательным и параллельным выполнением тестов и их группировкой, интеграция с Gulp и Mocha.
  • Поддержка большинства десктопных и мобильных браузеров; выполнение взаимодействия с реальным DOM API (web-приложение открывается в нескрытом окне браузера в обычной вкладке - тест максимально приближен к жизни).
  • Широкая поддержка селекторов элементов страницы: document.querySelector, CSS-селекторы и даже XPath; комбинация этих вариантов позволяет сохранить работоспособность функционального теста при внесении изменений в разметку.
  • Автоматическое ожидание готовности DOM-модели браузера, синхронная подача команд визуального взаимодействия (щелчки по кнопкам, ввод в текстовые поля); удобные инструменты для ожидания клиентского JS-кода и сетевой AJAX-активности.
  • Поддержка iframe-ов - за счет выбора текущего контекста DOMWindow - окна для теста и выполнении команд в его пределах с возможностью переключения в любой момент.
  • Возможности для расширения - оба решения предоставляют возможности по добавлению поддержки кастомных браузеров и расширению собственной функциональности, в том числе добавления новых команд.

Пример функционального теста

Примером для тестирования будет web-приложение вида TodoMVC, с сервером на node.js и клиентской SPA-страницей на React+Redux-е. Для приближения условий тестирования к реальным, во все redux-овские action-ы добавлены случайные задержки, эмулирующие сетевое взаимодействие с backend-ом (за основу взято это).


В дальнейшем будет предполагаться, что тестовое web-приложение запущено по адресу http://localhost:4000/ . Функциональный тест будет простым и включать в себя добавление todo-элемента, правку его содержимого, отметку как выполненное/невыполненное задание и удаление.


Языком для написания тестов в обоих фреймворках является JS (ES2016 и ES5 соответственно для TestCafe и Nightwatch), однако это прекрасно подходит для web-приложений, написанных на любом языке. Если Вы давно не разрабатывали на JS, то необходимо учитывать, что современные редакции ушли очень далеко от старого ES3, и включают удобные средства для написания кода, объектно-ориентированного и функционального программирования и многое другое.


Установка TestCafe производится всего одной командой npm install -g testcafe . После выполнения загрузки и установки необходимых зависимостей, выполнение теста производится командой testcafe / в соответствующей директории.


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


import { expect } from "chai"; import { Selector } from "testcafe"; const MAX_TIME_AJAX_WAIT = 2500; // 2.5 seconds by default const querySelector = Selector((val) => document.querySelector(val), { timeout: MAX_TIME_AJAX_WAIT }); const querySelectorCondition = Selector((val, checkFunc) => { const foundElems = document.querySelectorAll(val); if(!foundElems) return null; for(let i=0; i < foundElems.length; i++) { if(checkFunc(foundElems[i])) return foundElems[i]; } return null; }, { timeout: MAX_TIME_AJAX_WAIT }); fixture `Example page` .page `http://localhost:4000/`; test("Emulate user actions and perform a verification", async t => { await t.setNativeDialogHandler(() => true); const inputNewTodo = await querySelector("header.header input.new-todo"); await t.typeText(inputNewTodo, "New TODO element\r\n"); const addedTodoElement = await querySelectorCondition("section.main label", (elm) => (elm.innerText === "New TODO element")); await t.doubleClick(addedTodoElement); const addedTodoEditInput = await querySelectorCondition("section.main input", (elm) => (elm.value === "New TODO element")); await t.typeText(addedTodoEditInput, " changed\r\n"); const addedTodoCheckboxAC = await querySelectorCondition("section.main input:not()", (elm) => (elm.nextSibling.innerText === "New TODO element changed")); await t.click(addedTodoCheckboxAC); const addedTodoCheckboxBC = await querySelectorCondition("section.main input", (elm) => (elm.nextSibling.innerText === "New TODO element changed")); await t.click(addedTodoCheckboxBC); const addedTodoDelBtn = await querySelectorCondition("button.destroy", (elm) => (elm.previousSibling.innerText === "New TODO element changed")); await t.click(addedTodoDelBtn); });

Адрес тестируемой web-страницы определяется в fixture-части, за которыми следуют функциональные тесты, по завершении каждого из которых web-страница автоматически восстанавливается в исходное состояние. Для поиска DOM-элементов на странице используются testcafe-специфические Selector-ы, использующиеся в качестве обертки для функции, которая будет выполнять запрос к DOM-модели, возможно используя аргументы.


В этом примере первый селектор представляет обертку над document.querySelector, а второй - над document.querySelectorAll с callback-функцией, помогающей выбрать нужный элемент из списка. Обертка Selector принимает опции, здесь в частности устанавливается максимальное время, в течении которого testcafe будет ожидает появление элемента с заданными характеристиками в DOM-модели.


Сам функциональный тест представляет собой набор асинхронных вызовов Selector-ов, между которыми производятся действия посредством test controller-а, инстанцированного переменной t. Назначение большинства его методов очевидно из названий (click, typeText и т.д.), а t.setNativeDialogHandler используется для предотвращения генерации alert-подобных окон, которые могут “подвесить” тест - что очень удобно.


Установка Nightwatch тоже начинается с простой команды npm install -g nightwatch , однако для запуска функциональных тестов еще потребуется Selenuim-server (можно загрузить , на компьютере должен быть установлен Java SE runtime) и webdriver-ы для каждого из браузеров, в которых будет запускаться тест.


Для запуска тестов сначала надо создать конфигурационный файл nightwatch.json, описывающий расположение тестов, пути и настройки для selenium-server и webdriver-ов, а далее использовать простую команду nightwatch в текущей директории.
Если использовать Microsoft Web Driver (Edge), то nightwatch.json может выглядеть примерно так:


{ "src_folders" : ["nightwatch-tests"], "output_folder" : "reports", "custom_commands_path" : "", "custom_assertions_path" : "", "page_objects_path" : "", "globals_path" : "", "selenium" : { "start_process" : true, "server_path" : "nightwatch-bin/selenium-server-standalone-3.0.1.jar", "log_path" : "", "port" : 4444, "cli_args" : { "webdriver.edge.driver" : "nightwatch-bin/MicrosoftWebDriver.exe" } }, "test_settings" : { "default" : { "selenium_port" : 4444, "selenium_host" : "localhost", "desiredCapabilities": { "browserName": "MicrosoftEdge", "acceptSslCerts": true } } } }

Исходный код функционального теста, проверяющий аналогичный рассмотренному выше use-case-сценарий, может выглядеть так:


module.exports = { "Demo test" : function (client) { client.url("http://localhost:4000/") .waitForElementVisible("body", 1000) // May use CSS selectors for element search .waitForElementVisible("header.header input.new-todo", 1000) .setValue("header.header input.new-todo", ["New TODO element", client.Keys.ENTER]) // Or use Xpath - it"s more powerful tool .useXpath() .waitForElementVisible("//section[@class=\"main\"]//label", 2000) .execute(function() { // For dispatch double click - Nightwatch doesn"t support it by default var evt = new MouseEvent("dblclick", {"view": window, "bubbles": true,"cancelable": true}); var foundElems = document.querySelectorAll("section.main label"); if(!foundElems) return; var elm = null; for(var i=0; i < foundElems.length; i++) { if(foundElems[i].innerText === "New TODO element") { elm = foundElems[i]; break; } } elm.dispatchEvent(evt); }) .waitForElementVisible("//section[@class=\"main\"]//input[@type=\"text\"]", 2000) .clearValue("//section[@class=\"main\"]//input[@type=\"text\"]") .setValue("//section[@class=\"main\"]//input[@type=\"text\"]", ["New TODO element changed", client.Keys.ENTER]) .waitForElementVisible("//section[@class=\"main\"]//label" + "/preceding-sibling::input[@type=\"checkbox\" and not(@checked)]", 2000) .click("//section[@class=\"main\"]//label" + "/preceding-sibling::input[@type=\"checkbox\" and not(@checked)]") .waitForElementVisible("//section[@class=\"main\"]//label" + "/preceding-sibling::input[@type=\"checkbox\"]", 2000) .click("//section[@class=\"main\"]//label" + "/preceding-sibling::input[@type=\"checkbox\"]") .waitForElementVisible("//section[@class=\"main\"]//label" + "/following-sibling::button[@class=\"destroy\"]", 2000) .click("//section[@class=\"main\"]//label" + "/following-sibling::button[@class=\"destroy\"]") .waitForElementNotPresent("//section[@class=\"main\"]//label", 2000) .pause(2000) .end(); } }

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


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

Сравнение функциональности TestCafe и Nightwatch

Установка :
[T]estCafe : Достаточно одной команды npm install -g testcafe , и можно сразу приступать к написанию и запуску тестов в текущей директории web-проекта
[N]ightwatch : Хотя установка npm-модуля делается просто - npm install -g nightwatch , потребуется мануальная загрузка selenium-standalone-server, webdriver-ов для всех интересующих браузеров, ручное создание конфигурационного файла (А может даже загрузка Java, если она не установлена)


Выборка DOM-элементов :
T : Используется механизм Selector-ов - оберток над клиентскими JS-функциями, выбирающими один или множество DOM-узлов; это обеспечивает практически неограниченные возможности для селекции, начиная от простой обертки над document.querySelector или document.getElementById , и заканчивая произвольной логикой прохода по DOM-элементам. При этом TestCafe самостоятельно обеспечивает проверку наличия/отсутствия элементов по заданному Selector-у в течении указанного времени.
N : На выбор предоставляется CSS selectors или XPath - в принципе, второго варианта достаточно для решения большинства задач по выборке элементов на странице, хотя это конечно не сравнится с возможностью задания сложной произвольной логики поиска.


Язык написания тестов :
T : Из коробки предоставляется возможность написания тестов непосредственно на языке ES2016, что позволяет писать простой и читабельный код тестов на том же языке, что и само web-приложение Это также удобно в случаях, когда требуется импортировать определенный модуль из тестируемого проекта.
N : Устаревший ES5-синтаксис и exports-конструкции в исходном коде функционального теста (Возможность прикрутить ES6 все-таки есть, но на костылях)


Поддержка асинхронных операций :
T : Все API-функции основаны на Promise-ах, что позволяет описывать произвольную асинхронную логику работы теста, и при этом интегрировать собственные функции со стороны node.js. Благодаря поддержке ES2016, этот код можно записывать при помощи async и await конструкций в последовательном стиле.
N : В тесте можно реализовать последовательность команд по анализу и управлению содержимым web-страницы, однако они складываются во внутреннюю очередь событий, и интегрировать собственные асинхронные функции с ними проблематично.


Вставка клиентского кода на лету :
T : Легко осуществляется при помощи соответствующего API, поддерживается создание и последующее выполнение клиентских функций, однократное исполнение injected-кода, замена существующих функций в исходной web-странице, а также исполнение клиентских функций в callback-ах node.js-функций с привязкой к тестовому контроллеру.
N : Есть функциональность для выполнение JS-кода на клиентской стороне, или даже вставки целого script-блока, но средств интеграции с тест-контроллером не предоставляется. Подходит для простого синхронного интегрируемого JS-кода, но в более общем случае интеграция проблематична.


Описания утверждений и ожиданий :
T : По умолчанию - обычный язык утверждений chai/expect, можно использовать и любую другую совместимую библиотеку утверждений.
N : Расширенный язык assert и expect , включающий средства для описания состояния страницы, в том числе наличия элемента и фокуса на нем, принадлежность к CSS-классу и так далее. Выглядит удобно, однако в первую очередь обусловлено отсутствием полноценной поддержки асинхронных операций в тесте, при необходимости наличия утверждений и ожиданий.


Управление тестируемой web-страницей :
T : Предполагает возможность mock-а для блокирующих исполнение сценариев функций alert , confirm и так далее, с возможностью задания возвращаемого значения. Поддерживаются сложные манипуляции с DOM-моделью, эмуляция пользовательского взаимодействия с элементами управления, и даже возможность приостановки JS-сценария за счет обертывания клиентских JS-функций
N : Поддерживаются команды для непосредственного управления отображаемым окном браузера и подлежащей DOM-моделью, интеграция с клиентским JS-сценарием затруднена


Работа с курсором мыши :
T : Предоставляется виртуальный курсор, посредством которого осуществляются hover, click и drag-события для целевым визуальных элементов страницы. В процессе выполнения теста можно наблюдать за перемещением курсора и выполняемыми действиями.
N : Средства для работы с курсором вообще есть - это функции из webdriver api, однако работать с действиями, сложнее одиночного левого клика, довольно проблематично - взять хотя бы двойной щелчок.

Реализация взаимодействия с браузером в TestCafe и NightWatch

Фреймворк NightWatch основывается на известной, в некоторой мере уже традиционной, библиотеке Selenium webdriver, преимущества которой включают устоявшееся API, высокую степень документированности и обширное Q&A в интернете, а также универсальный и достаточно низкоуровневый доступ к браузеру… Взаимодействие с браузерами организуется посредством webdriver-ов, по одному на каждый обозреватель.
Основной недостаток - webdriver-ы существуют далеко не для всех браузеров, а также требуют отдельного обновления при смене версии самого браузера, а еще для работы необходимо наличие внешней зависимости от Java. Более подробно о технологии webdriver можно прочесть в http://www.w3.org/TR/webdriver/



Метод TestCafe более универсален, поскольку может потенциально работать с любым браузером, поддерживающим HTML5 и ES 5+, в то время как NightWatch требует соответствующий webdriver. Кроме того, это позволяет прогонять тесты не только на локальном браузере, но на любом браузере в сети, включая любые мобильные - без установки какого-либо ПО на телефоне.


Пример тестирования вышерассмотренного web-приложения в браузере на Android показан в следующем видео: https://youtu.be/2na5jkqvUx0


Однако testcafe-hammerhead имеет и потенциальные недостатки: накладные расходы на анализ и модификацию исходного JS-кода тестируемой страницы, производимые в свою очередь JS-коде ядра Testcafe, а также теоретически некорректная работа тестируемой web-страницы или интеграции теста, если исходный код был проксирован неверно. (К примеру, замещение alert-окна в testcafe можно обойти таким примером http://pastebin.com/p6gLWA75 - и неумешленно или специально “подвесить” его выполнение)

Выводы

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


Однако для функционального тестирования разрабатываемого или поддерживаемого web-приложения TestCafe несомненно впереди по широкому ряду причин:


1) Запуск тестов в любом браузере, в том числе мобильных телефонах и планшетах, причем это может производиться пакетным образом для всех интересуемых браузеров и не требует установки никакого дополнительного ПО.
2) Удобство написания теста на ES2016, включающее async/await-конструкции для последовательной записи кода, импорт программных элементов из самого проекта, передачу функций в клиент и обратно и так далее - широкие возможности по интеграции и управлению клиентским web-приложением.
3) Широкая поддержка selector-ов для визуальных элементов, легкое взаимодействие с DOM-моделью, виртуальный курсор мыши, эмуляция разнообразных и сложных взаимодействий пользователя со страницей. Добавить метки