Лабораторные работы Цифровая кафедра ФЭА 4 семестр / Введение в тестирование ПО / cktestpothird
.docxМИНОБРНАУКИ РОССИИ
Санкт-Петербургский государственный
электротехнический университет
«ЛЭТИ» им. В.И. Ульянова (Ленина)
Цифровая Кафедра
ПРАКТИЧЕСКАЯ РАБОТА №3
Тестирование на основе UML-диаграммы автомата
Студенты гр. 4404 |
|
Комарницкий М. С. Коншин М. В. Кудрявцев С. А. |
Преподаватель |
|
Турнецкая Е.Л. |
Санкт-Петербург
2026
Цель.
Цель: получение базовых навыков описания вариантов использования (Use Cases, прецедентов) для подготовки тестирования.
Описание назначения техники тестирования на основе вариантов использования.
Тестирование на основе вариантов использования (Use Cases) базируется на спецификации внешних требований к системе и описании ее поведения с точки зрения пользователя. Основное назначение данной техники - проверка того, насколько корректно система реализует бизнес-сценарии и позволяет акторам (пользователям или внешним системам) достигать конкретных, измеримых целей.
Использование прецедентов для тестирования позволяет:
Построить тестовые сценарии на основе реальных пользовательских путей (нормальный поток событий).
Спроектировать проверки для нестандартных ситуаций (альтернативные потоки).
Предусмотреть обработку ошибок и системных сбоев (поток исключений).
Сформировать позитивные и негативные тест-кейсы, которые понятны как разработчикам, так и заказчикам благодаря описанию на языке предметной области.
Полная диаграмма вариантов использования.
Рисунок
1 — Диаграмма прецедентов для офиса
продаж
5. Описание вариантов использования
5.1. Вариант использования для актора «Кассир»
Поле |
Описание |
ID Варианта использования: |
UC-01 |
Наименование варианта использования: |
Принять оплату за товар или услугу |
Кем создан: |
Студент |
Дата создания: |
29.05.2026 |
Акторы: |
Кассир (главный) |
Описание: |
Кассир проводит расчет с покупателем за выбранные товары или услуги, выбирая способ оплаты (наличные или карта) и фиксируя факт успешной транзакции в системе. |
Предварительные условия: |
1. Кассир авторизован в системе. 2. В системе открыт чек для совершения продажи. |
Постусловие: |
1. Статус чека изменяется на «Оплачено». 2. Данные о транзакции зафиксированы в финансовом отчете. 3. Система готова к печати чека. |
Нормальный ход событий: |
1. Прецедент начинается, когда Кассир нажимает кнопку «К оплате». 2. Система отображает итоговую сумму и запрашивает выбор способа оплаты (Наличные / Банковская карта). 3. Кассир выбирает способ оплаты и подтверждает транзакцию. 4. Система проводит оплату. 5. Система выводит сообщение об успешной оплате и меняет статус заказа. |
Альтернативный ход событий: |
1. Недостаточно средств (Оплата картой): Банк отклоняет операцию из-за нехватки средств. Система выдает уведомление об отказе. Кассир предлагает покупателю другой способ оплаты. 2. Неверная сумма (Наличные): Кассир ввел сумму, которая меньше итоговой. Система предупреждает о недоплате и блокирует завершение чека до внесения полной суммы. 3. Отмена оплаты: Покупатель отказывается от покупки до проведения транзакции. Кассир отменяет операцию, система возвращается в режим редактирования чека. |
Исключения: |
Потеря связи с банковским терминалом: При выборе оплаты картой система не может связаться с эквайрингом. Система выводит сообщение «Ошибка связи с терминалом» и переводит операцию в режим ожидания до восстановления соединения. |
Содержит: |
Распечатать чек (вызывается после успешной оплаты) |
Приоритет: |
Высший |
Частота использования: |
При каждой покупке на кассе |
Бизнес-правила: |
Оплата должна быть проведена строго в валюте РФ. |
Специальные требования: |
Время отклика эквайринга не должно превышать 10 секунд. |
Рисунок
2 -
Графическое представление прецедента
«Принять оплату»
5.2. Вариант использования для актора «Менеджер по продажам»
Поле |
Описание |
ID Варианта использования: |
UC-02 |
Наименование варианта использования: |
Оформить заявку клиента |
Кем создан: |
Студент |
Дата создания: |
29.05.2026 |
Акторы: |
Менеджер по продажам (главный) |
Описание: |
Менеджер вносит в систему данные клиента и требуемые товары для формирования новой заявки на продажу или обслуживание. |
Предварительные условия: |
Менеджер по продажам авторизован в системе. |
Постусловие: |
В базе данных создана новая заявка со статусом «В обработке» или «Создана». |
Нормальный ход событий: |
1. Прецедент начинается, когда Менеджер выбирает пункт меню «Создать новую заявку». 2. Система открывает форму создания заявки. 3. Менеджер вводит контактные данные клиента и выбирает нужные позиции из каталога. 4. Система проверяет наличие выбранных товаров на складе. 5. Менеджер нажимает кнопку «Сохранить заявку». 6. Система генерирует уникальный номер заявки и сохраняет её. |
Альтернативный ход событий: |
1. Отсутствие товара на складе: На шаге 4 система сообщает, что товара нет в наличии. Менеджер сохраняет заявку со статусом «Ожидание товара» и переходит к прецеденту «Заказать товар». 2. Некорректные данные клиента: Менеджер не заполнил обязательное поле (например, номер телефона). Система подсвечивает поле красным и блокирует кнопку сохранения до исправления ошибки. |
Исключения: |
Сбой БД: База данных временно недоступна при попытке сохранения. Система выводит сообщение «Ошибка сохранения: сервер недоступен, попробуйте позже» и локально кеширует введенные данные. |
Содержит: |
Нет |
Приоритет: |
Высокий |
Частота использования: |
Многократно в течение рабочего дня менеджера |
Бизнес-правила: |
Заявка не может быть создана без указания контактного номера клиента. |
Специальные требования: |
Доступ к каталогу должен подгружаться без задержек. |
Рисунок
3 - Графическое представление прецедента
«Оформить заявку»
Вывод.
В ходе выполнения практической работы была достигнута поставленная цель: получены и закреплены базовые навыки описания вариантов использования (Use Cases) для подготовки к процессу тестирования. Были решены следующие задачи: изучены особенности и элементы UML-диаграмм автоматов (прецедентов), а также детально описаны два варианта использования («Принять оплату» для кассира и «Оформить заявку» для менеджера по продажам) с применением отраслевого шаблона.
В процессе выполнения работы были детально проработаны нормальные и альтернативные ходы событий, а также выделены исключительные ситуации (системные ошибки), что является критически важным шагом для последующей разработки качественных тест-кейсов как для позитивного, так и для негативного тестирования. Возникшая необходимость четко разделять альтернативные сценарии (бизнес-отклонения) и исключения (системные сбои) была успешно разрешена путем анализа теоретической части методических указаний.
Список использованных источников.
Аграновский, А.В. Универсальные средства визуального моделирования информационных транспортных систем: учебно-методическое пособие / А.В. Аграновский; С.-Петерб. гос. ун-т аэрокосм. приборостроения. – Санкт-Петербург: Изд-во ГУАП, 2023. – 48 с.(дата обращения: 29.05.2026)
Фаулер, М. UML. Основы: Краткое руководство по стандартному языку объектного моделирования / М. Фаулер. – 3-е изд. – СПб.: Символ, 2014. – 192 с. (дата обращения: 29.05.2026)