Всем привет! Сегодня хочу рассказать, как можно протестировать Личный кабинет банка с помощью таких инструментов, как: Postman, dBeaver, MySQL, DevTools на примере простого Веб-приложения. Будет проверено: создание пользователя, авторизация, отображение продуктов клиента в Личном кабинете, подача заявки на потребительский кредит и отображение результатов ее рассмотрения в ЛК. Приступим

Было разработано небольшое Веб-приложение на Node.js. После запуска приложения и открытия его на локальной машине по адресу - http://localhost:5000/, на странице отображается форма входа в Личный кабинет.

Для того, чтобы войти в ЛК, нам нужно указать логин и пасс пользователя. Но так как приложение было только разработано и передано в тестирование, в БД, скорее всего, еще нет пользователей, их логинов и паролей. Чтобы войти в ЛК, нам нужно сначала создать клиента и его данные в БД. Подключаемся через dBeaver к базе данных, созданной также на локальной машине. БД создается стандартно через - http://localhost/phpmyadmin/. Создать БД не сложно, в интернете есть много информации по этой теме, можно ознакомиться. Для поднятия БД использовалась программа - XAMPP. В ней в XAMPP Control Panel достаточно запустить два сервиса: Apache и MySQL. Да, для работы с БД будет использоваться MySQL.

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

Среди таблиц мы видим таблицу - credentials. В ней хранятся логины и пароли пользователей. Посмотрим, что в ней сейчас есть.

Оказывается в таблице уже есть логины и пароли для двух клиентов. Так как мы тестируем на примере простого приложения, то пароли хранятся в БД в открытом виде. На Бою, они, конечно, будут зашифрованы. Эти логины и пароли, скорее всего, были созданы разработчиком, когда он тоже предварительно тестировал, правильно ли все работает или, кто-то уже начинал тестировать приложение раньше. Можно использовать эти логины и пароли для входа в ЛК, но это будет совсем просто. Лучше создадим свои данные клиента. По таблице - bank.credentials видно, что в ней есть поле - Client_id. По этому полю логин и пасс связаны с клиентом в таблице - bank.clients. Посмотрим какие клиенты есть в этой таблице.

Видно, что в таблице - bank.clients тоже уже есть клиенты. Найдем соответствие клиентов с кредами от входа в ЛК.

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

И так, нам надо создать клиента в таблице с клиентами и логин + пароль в таблице с кредами, чтобы они сопоставлялись друг с другом по полю - Id клиента.

Разработчик для тестирования мне прислал описание API запросов, с помощью которых можно обращаться к back-части приложения, создавать, получать, изменять данные.

Из первого запроса видно, что одним запросом на создание пользователя, в БД сразу создаются персональные данные клиента и логи + пароль для входа в ЛК банка. Так как мы будем отправлять еще и другие API запросы в back приложения, то в Postman можно создать глобальную переменную, в которую указать адрес для обращения к бэку. Это позволит указывать более короткое название переменной в адресе и не писать каждый раз в запросе длинное название адреса - https://2d26t28n-5000.euw.devtunnels.ms

После создания и активирования глобальной переменной, создаем POST запрос на создание нового пользователя. В начале адреса запроса указываем созданную переменную, далее указываем API адрес по которому back обрабатывает запросы на создание клиентов - /api/add/user . У меня уже создана коллекция запросов для тестирования, поэтому приведу пример запроса на создание пользователя.

Отправляем запрос и смотрим, что пришло в ответе

В ответе вернулось 200 - ОК и данные которые были созданы в БД (кроме логина и пароля), значит клиент воздан в БД. Давайте это проверим

Да, действительно, пользователь был создан. В БД и в ответе на POST запрос, видно, что пользователю был назначен Id = 4. Давайте это запомним. В будущем нам это может пригодиться для отправлению других запросов в back.

Пробуем войти в ЛК банка под этим новым пользователем. Вводим логин + пароль на станице входа - http://localhost:5000/

На странице авторизации нам важно проверить:

1. что страница соответствует ее макету, который был согласован и по которому она была разработана. Ссылка на макет, например, в Figma, как правило, есть в Постановке задачи на разработку (в том числе, что в заголовке указано - Login)

2. введенное в поле Password значение отображается в виде точке

3. после нажатия на значок "глаз" в строке с введенным паролем, пароль отображается в явном виде. После повторного нажатия на значок - пароль снова скрывается

4. при вводе значений пар Login + Password, которых нет в БД - вход в ЛК не происходит

5. также в большинстве случаев в поле Login не допускается указывать спец. символы и количество знаков для полей Login и Password ограничено - это тоже нужно проверить.

Указываем логин и пароль от нового созданного пользователя, нажимаем Enter

После входа в ЛК важно проверить:

• что страница соответствует макету (в том числе, в заголовке указано - Bank)

• в правом верхнем углу отображается значение из поля - FullName (ФИО клиента) и кнопка Выход.

• слева отображаются разделы, в которых будут выводиться продукты клиента, если они есть. И есть кнопка - "Подать заявку на кредит", по нажатию на которую, происходит переход на форму подачи заявки.

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

Нажмем на все кнопки "Загрузить" в каждом из разделов.

Чтобы данные о продуктах клиента отобразились, нужно их сначала создать в БД. Отправляем POST запросы для каждого из видов продуктов банка. Так как у каждого продукта есть свои собственные свойства и характеристики, то набор полей при отправке запросов будет отличаться. Набор полей и возможных значений можно также посмотреть в Постановке на разработку задачи. При отправке запросов важно в теле запроса указывать Id нашего клиента с которым мы работаем, чтобы продукты создавались именно для него.

После выполнения запросов на создание, например, карт, можно нажать на кнопку - "Подать заявку на кредит", чтобы перейти на другую страницы, а потом на странице "Заявка на потребительский кредит" нажать на кнопку "Назад", чтобы данные на странице - "Личный кабинет" обновились. И теперь снова нажать на кнопку "Загрузить" в разделе "Карты". Или же можно выйти и зайти заново в Личный кабинет и потом нажать на кнопку "Загрузить".

Здесь нужно проверить:

• что по кнопке "Свернуть" происходит сворачивание данных карты, по "Развернуть" - данные снова отображаются

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

• статус и тип карты соответствует тем, что были отправлены в запросе через Postman

• отображаются именно те даты, которые были отправлены в запросе. Например, если была отправлена дата - "next_payment_date": "12.04.2025", то на странице, для карты в поле "Дата следующего платежа" тоже отображается отправленная дата. В примере видно, что на странице в поле "Дата следующего платежа" отображается дата = "4.12.2025". То есть видно, что в дате число и месяц поменялись местами. Здесь важно понять, это в поле таблицы БД дата записалась неправильно, или уже при выведении в UI дата изменилась. Нужно выполнить запрос в БД и проверить, какое значение, указано в таблице. Id карты можно найти в ответе на запрос на создание карты.

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

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

• потребительских кредитов

• авто-кредитов

• вкладов

При отправке запросов, лучше суммы всегда отправлять с копейками, чтобы сразу проверить, что значения из всех полей, на стороне бэка принимаются правильно и записываются в таблицы, в соответствии с форматом из Постановки задачи. Даты лучше отправлять таким образом, чтобы первое значение в дате было = 0. Например, 02.03.2028. При обработке бэком первого нуля могут возникнуть ошибки. Так как, если указано число 10.10.2010 - тут явно видно, что пришли значения 10, 10 и 2010 и тут ошибка при обработке маловероятна. А когда приходит дата с первым нулем, то тут вполне может быть ошибка. Так как back может ждать значение из 2 знаков, а первый ноль может посчитаться за null и тогда придет 1 знак и тут непонятно, как такую ситуацию обработает back.

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

• ввод значений в другом формате

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

• перезагрузка страницы / перелогин в приложение в процессе заполнения, каких-то данных

• нажатие на кнопку "Отправить", когда отключился интернет

• любые нестандартные ситуации в работе приложения

Создаем кредиты на авто

При отображении авто-кредитов в UI, видно, что, скорее всего, Дата следующего платежа - "next_payment_date": "13.09.2025", "перевернулась" при обработке фронтом в 09.13.2025 и так как 13 месяца не существует, то вывелось значение - NaN.NaN.NaN.

Нужно проверить правильность округления Суммы вклада. Обратить внимание, что была отправлена "start_date": "08.07.2024", а в UI отобразилась - 7.8.2024. Была отправлена дата "end_date": "11.12.2032", а на странице выводится - 12.11.2032. Тут тоже есть баги с датами. Скорее всего, все баги с отображением сумм и дат, можно будет поправить в одном тикете на исправление. Просто фреймворк фронта неправильно обрабатывает полученные из БД значения.

Теперь перейдем на страницу подачи заявки на кредит. Нажимаем на кнопку - "Подать заявку на кредит".

На форме заявке нужно проверить:

• соответствие формы заявки макету

• предзаполнение полей, данные по которым уже есть в БД (ФИО клиента, Дата рождения)

• отображение в полях значений по умолчанию

• возможность указания значений не по формату полей

• возможность выбора из выпадающего списка

• отсутствие орфографических ошибок и опечаток в названиях полей

• работу приложения при попытке отправить заявку, когда в одном из полей указано значение больше предусмотренного (если в поле "Место работы" указано значение больше 20 символов, должна выводится ошибка)

Перед отправкой новой заявки, проверить, заявки на кредит от нашего текущего клиента (Client_id = 4) в таблице - bank.credit_requests

Открыть DevTools по F12 в браузере, например, Chrome и попытаться отправить заявку не по формату полей (Место работы = "НоваяТестоваяКомпа201"), нажав на "Отправить заявку" в UI.

На форме заявки отобразилось сообщение об ошибке. На вкладке Network в ответе (вкладка Response) видно, что по значению "value": "НоваяТестоваяКомпа201" вернулось сообщение - "msg": "Invalid value". Если перейти на вкладку Headers, то там отображается - 400 Bad Request. Разработчик реализовал так, что в поле "Место работы" нельзя передать значение больше 20 символов. При отправке через UI - проверка работает. Нужно сверить соответствует ли реализация Постановке задачи.

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

Отправляем POST запрос через Postman, указав нужные значения в соответствующих форматах.

Отправляем запрос на создания заявки с Clinet_id = 4, "WorkCompany": "НоваяТестоваяКомпа201",

В Postman тоже вернулось тоже самое сообщение об ошибке - 400 Bad Request, из-за того, что было указано невалидное значение "НоваяТестоваяКомпа201". Выявлено, что проверка на размерность поля проводится не только во фронте приложения, но и на уровне бэка.

Пробуем отправить заявку на кредит с корректными данными через Веб форму. Перед отправкой отрывает DevTools -> Network, чтобы видеть ответ, который придет от сервера.

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

Заявка создалась в таблице. Проверяем, что полученные значения записались именно в те поля, которые им соответствуют. Например, в поле "Стаж на текущей работы" (здесь опечатка, которая выявлена при тестировании:) ) был указан вариант - "От 1 до 3 лет", но в поле таблицы записалось значение = 0. Здесь, видимо, должен был быть предусмотрен какой-то маппинг значений, которые приходят из UI, с теми значениями, которые должны им соответствовать в поле таблице. Или, может быть, прямо так и должно записываться - "От 1 до 3 лет". Этот момент лучше прояснить с разработчиком и аналитиком по задаче. Остальные поля, вроде, заполнились правильно. SalaryInCompany - такого поля не было в заявке, поэтому оно равно 0. Этот момент тоже лучше прояснить. Не совсем понятно, зачем нужно это поле в таблице, если оно не заполняется. Поля ApprovedAmount и ApprovedTerm равны 0, так как заявка пока находится на рассмотрении Status = Request.

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

Эту же информацию можно получить отправив запрос через Postman

В Postman вернулась та же информация по заявке, что и отображается в UI.

Далее мы можем подать еще две заявки на кредит. Первую одобрим через БД. Вторую отклоним через запрос из Postman. Одну из заявок лучше подать через Postman, проверив таким образом, что отправление заявок из Postman тоже работает.

И подаем еще одну заявку через UI. В результате у нас получается 3 заявки в статусе "На рассмотрении".

Для второй заявки (id = №7) изменяем ее статус в таблице на - Rejected

Нажимаем на кнопку "Узнать статус заявки" в области заявки №7. Таким образом будет отправлен запрос - GET /api/loans/status?request_id=7 для получения статуса этой заявки.

Через Postman одобряем заявку №8 и указываем какая сумма и на какой срок может быть выдана клиенту.

Вернулась ошибка запроса - 401 Unauthorized. Для изменения данных по уже поданной заявке нужно отправлять запрос с токеном. Токен можно найти в DevTools после авторизации пользователя в ЛК.

Повторяем отправку запроса, но уже указав токен в Postman на вкладке - Authorization, Auth Type = Bearer Token. Токен пользователя автоматически пересоздается после каждого нового входа клиента в Личный кабинет. В Postman нужно указывать актуальный токен на момент последнего входа в ЛК.

В UI нажать на кнопку "Узнать статус заявки" для заявки №8.

На этом можно сказать, что в целом тестирование ЛК банка было проведено. Все основные моменты работы приложения были проверены. Выявлен ряд ошибок, определены вопросы, требующие дополнительного обсуждения и прояснения с разработчиком и аналитиком. Через Postman еще можно проверить все оставшиеся API запросы, которые не были рассмотрены выше. Но фактически они будут повторять те запросы, которые отправляются из UI в back приложения. И так как запросы через UI работаю, то и через Postman они будут работать. Единственное, что в API запросах можно попробовать отправлять запросы в не тех форматах, которые ожидаются на бэке и посмотреть, как будет отрабатывать. Но, возможно, что это и не нужно проверять, так как пользователь же будет работать через UI, а UI мы проверили. Подобные вопросы лучше выяснять у аналитика.

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

И так, выше было рассмотрено тестирование Веб-приложения на примере упрощенного Личного кабинета банка. Надеюсь статья будет полезна. Спасибо за уделенное время