Лабораторные работы Цифровая кафедра ФЭА 4 семестр / Введение в тестирование ПО / cktestpothird
.pdfМИНОБРНАУКИ РОССИИ САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ ЭЛЕКТРОТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ «ЛЭТИ» ИМ. В.И. УЛЬЯНОВА (ЛЕНИНА) Цифровая Кафедра
ПРАКТИЧЕСКАЯ РАБОТА №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-диаграмм автоматов (прецедентов), а также детально описаны два варианта использования («Принять оплату» для кассира и
«Оформить заявку» для менеджера по продажам) с применением отраслевого шаблона.
В процессе выполнения работы были детально проработаны нормальные и альтернативные ходы событий, а также выделены исключительные ситуации (системные ошибки), что является критически важным шагом для последующей разработки качественных тест-кейсов как для позитивного, так и для негативного тестирования. Возникшая необходимость четко разделять альтернативные сценарии (бизнес-
отклонения) и исключения (системные сбои) была успешно разрешена путем анализа теоретической части методических указаний.
Список использованных источников.
1.Аграновский, А.В. Универсальные средства визуального моделирования информационных транспортных систем: учебно-
методическое пособие / А.В. Аграновский; С.-Петерб. гос. ун-т
аэрокосм. приборостроения. – Санкт-Петербург: Изд-во ГУАП,
2023. – 48 с.(дата обращения: 29.05.2026)
2.Фаулер, М. UML. Основы: Краткое руководство по стандартному языку объектного моделирования / М. Фаулер. – 3-е изд. – СПб.:
Символ, 2014. – 192 с. (дата обращения: 29.05.2026)