Курсовой проект представляет собой автоматизацию тестирования комплексного сервиса, взаимодействующего с СУБД и API Банка.
Что следует делать, чтобы все получилось:
- Попробовать найти ответ сначала самому в интернете. Ведь, именно скилл поиска ответов пригодится вам на первой работе. И только после этого спрашивать вашего наставника.
- В одном вопросе должна быть заложена одна проблема.
- Как правильно оформлять вопросы:
- публикуете самую последнюю версию вашего кода на GitHub
- включаете в репозитории Issues
- заводите новое Issue, в котором пишете:
- в чём проблема;
- прикладываете скриншот (чтобы все понимали куда смотреть);
- если в консоли любого сервиса есть ошибки - не поленитесь скопировать их тоже (не отпринскринить, а скопировать - Ctrl + C, Ctrl + V).
- Начинать работу над проектом как можно раньше! Чтобы было больше времени на правки.
- Делать проект по частям, а не все сразу. Иначе, есть шанс, что нужно будет все переделывать :)
Что следует делать, чтобы ничего не получилось:
- Никому ничего не говорить.
- Писать вопросы вида “Я не знаю, что делать. Я ничего не понял. Ничего не работает. Не запускается. Всё работало, а теперь не работает. Да и вообще никогда не работало.”
- Думать “вы такого не проходили, вас к этому не готовили и вообще, почему всё так сложно???“
- Присылать скриншоты (или ещё хуже - фотографии экрана), не показывая код.
- Откладывать курсовой проект на потом.
- Ждать того, что оно "заработает само".
- Ждать ответ на свой вопрос моментально. Ваши наставники - работающие специалисты, которые занимаются кроме преподавания, своими проектами. Их время ограничено, поэтому постарайтесь задавать правильные вопросы, чтобы получать быстрые ответы!
В любом случае: задавайте вопрос, вы обязательно получите на него ответ.
Приложение представляет из себя веб-сервис.
Приложение предлагает купить тур по определённой цене с помощью двух способов:
- Обычная оплата по дебетовой карте
- Уникальная технология: выдача кредита по данным банковской карты
Само приложение не обрабатывает данные по картам, а пересылает их банковским сервисам:
- сервису платежей (далее - Payment Gate)
- кредитному сервису (далее - Credit Gate)
Приложение должно в собственной СУБД сохранять информацию о том, каким способом был совершён платёж и успешно ли он был совершён (при этом данные карт сохранять не допускается).
Важно: в реальной жизни приложение не должно через себя даже пропускать данные карт, если у него нет PCI DSS, но мы сделали именно так 😈.
Само приложение расположено в файле aqa-shop.jar и запускается стандартным способом java -jar aqa-shop.jar на порту 8080.
В файле application.properties приведён ряд типовых настроек:
- учётные данные и url для подключения к СУБД (необходимо заполнить самостоятельно)
- url-адреса банковских сервисов (уже заполнены)
Вы можете подключить к приложению любую из двух баз данных:
- MySQL
- PostgreSQL
Учётные данные и url для подключения задаются в файле application.properties.
Симулятор банковских сервисов запущен по адресу 185.119.57.197:9999 (этот адрес уже указан в файле application.properties)
Все запросы симулятора логируются, логи можно посмотреть тут 185.119.57.197:9998 (student/logviewer). На левой панеле выбираете контейнер с сервисами (он там один) и открываете для просмотра логов. Данный сервис является общим для всех студентов, поэтому логов может быть очень много и в них тяжело будет ориентироваться. Для упрощения работы к логам привязывается ip, с которого пришел запрос в сервис. Вам нужно в окне с логами нажать комбинацию CTRL + F (CMD + F для MacOS) и в строку поиска ввести свой ip и вы будете видеть только свои логи в реальном времени. Узнать свой ip легко, для этого есть множество сервисов.
Сервис обрабатывает только специальные номера карт, которые предоставлены для тестирования:
- APPROVED карта -
1111 2222 3333 4444 - DECLINED карта -
5555 6666 7777 8888
Остальные данные карт могут быть любыми (не забываем про здравый смысл - год не должен быть прошлым, cvc из трех цифр и тд)
Обратите внимание, разработчики сделали один сервис, симулирующий и Payment Gate, и Credit Gate.
Ваша ключевая задача - автоматизировать сценарии (как позитивные, так и негативные) покупки тура.
Задача разложена на 4 этапа:
- Планировании автоматизации тестирования
- Тестирование сервиса покупки тура. Тестируем обе формы, баги оформляем в issues
- Непосредственно сама автоматизация. Тесты пишем для ОДНОЙ формы, выбирайте любую.
- Подготовке отчётных документов по итогам тестирования
- Подготовка отчётных документов по итогам автоматизации
Все материалы (документы, автотесты, открытые issue, отчёты и т.д.) должны быть размещены в одном публичном репозитории, ссылку на который вы и будете отправлять наставнику.
После начала работы над проектом в течение 3 рабочих дней вы должны сдать наставнику план автоматизации, в котором описано:
- Перечень автоматизируемых сценариев
- Перечень используемых инструментов с обоснованием выбора
- Перечень и описание возможных рисков при автоматизации
- Интервальная оценка с учётом рисков (в часах)
- План сдачи работ (когда будут автотесты, результаты их прогона и отчёт по автоматизации)
Отчёт оформляется в виде файла с именем Plan.md и заливается в репозиторий вашего проекта.
На этом этапе вы непосредственно пишете автотесты и прогоняете их. Требования по подключению CI нет, но есть требования к самим тестам:
- Обязательно должны быть тесты UI
- Обязательно должны быть репорты (Gradle/Allure/Report Portal)
- Обязательно должны быть запросы в базу, проверяющие корректность внесения приложением информации
- Автоматизировать тесты для двух форм покупки тура
- Автоматизировать API тесты для приложения. Имейте в виду, что автоматизировать нужно именно запросы, которые отправляются из браузера после заполнения формы, а не те, которые приложение отправляет в банковский сервис. Банковский сервис - не ваша ответственность, но у вас есть доступ к логам
- Запустить в контейнерах две базы данных (Mysql и Postgres) и параметризировать запуск приложения и тестов, передавая в параметрах разные конфиги для подключения к любой из запущенных баз данных
Код автотестов заливается в репозиторий вашего проекта вместе с отчётными документами, всеми необходимыми для запуска файлами и конфигурациями.
В файле README.md должна быть описана полная инструкция для запуска автотестов (если для запуска необходимо заранее установить, настроить, запустить какое-то ПО - это тоже должно быть описано).
Важно: наставник по курсовому проекту не будет за вас "допридумывать" как запускать ваши тесты, если после git clone и выполнения шагов, описанные в README.md автотесты не запускаются, то проект отправляется на доработку.
В качестве отчётных документов прикладываются issue со скриншотами и описанием багов + формируется документ Report.md, в котором содержится отчёт о проведённом тестировании:
- Краткое описание
- Количество тест-кейсов
- % успешных/не успешных
- Общие рекомендации
Не забудьте о том, что помимо документа, в систему автоматизации должны быть интегрированы отчёты: Gradle, Allure или Report Portal.
В качестве отчётных документов формируется документ Summary.md, в котором содержится отчёт о проведённой автоматизации:
- Что было запланировано и что было сделано
- Причины, по которым что-то не было сделано
- Сработавшие риски
- Общий итог по времени (сколько запланировали/сколько потратили с обоснованием расхождения)
Важно: когда мы просим вас написать любые документы - мы не требуем творений на 10 страниц, документ должен, максимум, занимать один лист A4.
Когда вы придёте на работу, то нужно делать так, как требует тот, кто ставит задачи. Естественно, это можно обсуждать, но ключевое - заранее привыкнуть к тому, что придётся подстраиваться под стиль работы команды и это (смена стиля) - не должно вызывать у вас дискомфорта (вы должны быть к этому готовы). Постановщик задач в данном случае для вас - ваш наставник и если он требует что-то изменить/добавить/скорректировать - то это нужно сделать даже несмотря на то, что ДЗ у вас принимались в том виде, в котором вы делаете сейчас. Это часть обучения.
Важно: выполнение или не выполнение этого раздела не влияет на зачет по курсовому проекту
Если вы чувствуете в себе силы, мы предлагаем вам попробовать интегрировать всю систему с Appveyor CI/GitHub Actions или любой другой CI.
Немного подсказок:
- на большинстве CI есть Docker (и, возможно даже, Docker Compose)
- на большинстве CI либо предустановлены Node.js, MySQL, PostgreSQL, либо их можно установить
- вы можете вставлять простейшие
sleep'ы прямо в сценариях командной строки, чтобы дать "подняться" СУБД, SUT или симулятору (хотя есть и техники получше)
Если вы это сделаете, не забудьте выставить бейджик сборки.
Спойлеры
Смотреть спойлеры не хорошо 😈!
Но раз уж вы посмотрели, то вот вам подсказки:
- приложение просто усыпано багами - от безобидных до супер-критичных, поэтому если вы не нашли ни одного, то плохо искали
- если есть баги, то тесты не должны быть зелёными
- если есть баги, то должны быть баг-репорты в issue
- обращайте внимание на все баги (особенно внимательно смотрите на обработку платежей и их фиксацию)