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

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

Кроссбраузерность

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

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

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

Необходимо понимать, что тестировать надо все основные браузеры, однако отдельное внимание следует уделить браузеру Internet Explorer. Именно в с этим браузером чаще всего возникают проблемы. Особое внимание тут следует обращать на фокус полей, масштабируемость, работу JavaScript.

Web-формы

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

На что стоит обращать особое внимание: — обязательные поля для заполнения: отмечено ли, что они являются обязательными, а также являются ли они обязательными на самом деле, по факту (проверка пустых значений); — ввод специальных данных — спецсимволов: #%@№&^$*<>{}[]; — наличие валидации (что происходит, когда пользователь вводит невалидные значения, получает ли пользователь сообщение об ошибке, что происходит с данными после их ввода).

Хорошая практика — составлять чек-лист UI-компонентов, которые нужно проверить (радио-баттоны, дроп-дауны, чек-боксы).

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

Валидация со стороны сервера

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

Валидация со стороны клиента

Речь идет о выполнении проверки значений непосредственно при вводе данных. Для этого в Presentation Layer подключают специальные скрипты валидации (Presentation Layer — слой представления веб-приложения — то, что мы видим, UI).

Что такие скрипты могут проверять: — ввел ли пользователь в поле email символ @; — заполнены ли обязательные поля; — ввел ли пользователь цифры в поле ввода номера телефона; — не совпадают ли поля, которые не должны совпадать, и т. п.

Для чего это нужно? Ответ очевиден: валидация на стороне клиента уменьшает число обращений к серверу, снижая нагрузку на него.

База данных

При тестировании web-приложений не забываем про базы данных.

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

Сервер

Сервер тестируется отдельно от клиента. Проверяем: — наличие валидации со стороны сервера (о ней упоминали выше); — корректность ответа сервера на подаваемый запрос со стороны клиента (правильный код состояния, заголовок, тело и т. д.) — тут используют такие инструменты, как Fiddler и Postman; — скорость обработки запросов.

Пользователи, multiple users

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